Filtervorlagen und Liquid-Parameter

Dieses Thema richtet sich an fortgeschrittene Benutzer mit guten Vorkenntnissen über SQL und LookML.

Looker bietet Nutzern automatisch die Möglichkeit, ihre Abfragen zu bearbeiten, indem sie Filter erstellen, die auf Dimensionen und Messwerten basieren. Diese einfache Methode erfüllt zwar viele Anwendungsfälle, kann jedoch nicht alle Analyseanforderungen aktivieren. Durch Filtervorlagen und Liquid-Parameter nimmt die Zahl der möglichen Anwendungsfälle, die Sie unterstützen können, enorm zu.

Aus SQL-Perspektive können Dimensionen und Messwerte nur die äußersten WHERE- oder HAVING-Klauseln Ihrer Abfrage ändern. Vielleicht möchten Sie aber auch, dass die Benutzer andere Teile des SQL-Codes bearbeiten können. Das Ändern eines Teils einer abgeleiteten Tabelle, das Anpassen der abgefragten Datenbanktabelle oder das Erstellen von Mehrzweckdimensionen und -filtern sind nur einige der Funktionen, die Sie mit Vorlagenfiltern und Flüssigkeitsparametern aktivieren können.

Filtervorlagen und Liquid-Parameter verwenden die Liquid-Vorlagensprache, um Benutzereingaben in SQL-Abfragen einzufügen. Zunächst erstellen Sie mithilfe eines LookML-Parameters ein Feld, mit dem Benutzer interagieren können. Als Nächstes verwenden Sie eine Liquid-Variable, um die Benutzereingabe in SQL-Abfragen einzufügen.

Beispiele

Sehen wir uns ein paar Beispiele an, um zu verdeutlichen, welchen Wert Vorlagenfilter und Flüssigkeitsparameter haben.

Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen

In einer abgeleiteten Tabelle werden die Gesamtausgaben eines Kunden im Nordosten berechnet:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,                        -- Can be made a dimension
        SUM(sale_price) AS lifetime_spend   -- Can be made a dimension
      FROM
        order
      WHERE
        region = 'northeast'                -- Can NOT be made a dimension
      GROUP BY 1
    ;;
  }
}

In dieser Abfrage können Sie Dimensionen aus customer_id und lifetime_spend erstellen. Angenommen, Sie möchten, dass der Nutzer region angeben kann, statt ihn auf „Nordost“ zu codieren. region kann nicht als Dimension offengelegt werden. Daher kann der Nutzer nicht wie gewohnt filtern.

Eine Option wäre in dem Fall, eine Filtervorlage zu verwenden, die folgendermaßen aussehen würde:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition order_region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  filter: order_region {
    type: string
  }
}

Eine detaillierte Anleitung finden Sie unten.

Wenn in einer abgeleiteten Tabelle ein Vorlagenfilter verwendet wird, können Sie die Tabelle nicht dauerhaft erstellen.

Einen dynamischen Messwert mit einem Liquid-Parameter erstellen

Nehmen wir einen gefilterten Messwert als Beispiel, der die Anzahl der verkauften Hosen addiert:

measure: pants_count {
  filters: [category: "pants"]
}

Dieses Verfahren ist leicht nachzuvollziehen, doch hätte man Dutzende Kategorien, würde es eine Menge Aufwand bedeuten, für jede einen Messwert zu erstellen. Zudem wird das Explore dadurch für die Benutzer unübersichtlich.

Als Alternative könnten Sie einen dynamischen Messwert wie folgt erstellen:

measure: category_count {
  type: sum
  sql:
    CASE
      WHEN ${category} = '{% parameter category_to_count %}'
      THEN 1
      ELSE 0
    END
  ;;
}

parameter: category_to_count {
  type: string
}

Eine detaillierte Anleitung finden Sie unten.

Grundlegende Verwendung

Schritt 1: Erstellen Sie etwas, mit dem der Nutzer interagieren kann.

  • Fügen Sie bei Vorlagenfiltern einen filter hinzu.
  • Füge für Flüssigkeitsparameter eine parameter hinzu.

In beiden Fällen werden die Felder dem Nutzer im Bereich Nur-Filter-Felder der Feldauswahl angezeigt.

Die Felder filter und parameter können eine Reihe von untergeordneten Parametern akzeptieren, sodass Sie deren Funktionsweise anpassen können. Eine vollständige Liste finden Sie auf der Dokumentationsseite zu Feldparametern. Es gibt zwei Optionen, bei denen parameter-Felder besonders erwähnt werden.

Die parameter-Felder können einen speziellen Typ namens ohne Anführungszeichen haben:

parameter: table_name {
  type: unquoted
}

Mit diesem Typ können Werte in SQL eingefügt werden, ohne von Anführungszeichen umschlossen zu sein, wie es bei einer Zeichenfolge der Fall wäre. Dies kann sinnvoll sein, wenn Sie SQL-Werte wie Tabellennamen einfügen müssen.

Zweitens gibt es in parameter-Feldern die Option Zulässige Werte, mit der Sie dem nutzerfreundlichen Namen einen aussagekräftigen Namen geben können. Beispiel:

  parameter: sale_price_metric_picker {

    type: unquoted
    allowed_value: {
      label: "Total Sale Price"
      value: "SUM"
    }
    allowed_value: {
      label: "Average Sale Price"
      value: "AVG"
    }
    allowed_value: {
      label: "Maximum Sale Price"
      value: "MAX"
    }
    allowed_value: {
      label: "Minimum Sale Price"
      value: "MIN"
    }
  }

Schritt 2: Nutzereingabe anwenden

Im zweiten Schritt können Sie den Vorlagenfilter oder den Flüssigkeitsparameter mit Liquid hinzufügen.

Filtervorlagen

Die Syntax für Filtervorlagen gestaltet sich wie folgt:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
  • Die Wörter condition und endcondition ändern sich nie.
  • Ersetzen Sie filter_name durch den Namen des Filters, den Sie im ersten Schritt erstellt haben. Sie können auch eine Dimension verwenden, wenn Sie kein Filterfeld erstellen konnten.
  • Ersetzen Sie sql_or_lookml_reference durch die SQL- oder LookML-Datei, für die „gleich“ auf die Nutzereingabe festgelegt werden soll. Weitere Informationen finden Sie unten. Wenn Sie LookML verwenden, nutzen Sie die LookML-Syntax ${view_name.field_name}.

Im Beispiel oben haben wir Folgendes verwendet:

{% condition order_region %} order.region {% endcondition %}

Es ist wichtig, dass Sie die Interaktion zwischen den Liquid-Tags und dem SQL-Code, den sie dazwischen schreiben, verstehen. Die Tags der Vorlagenfilter werden immer in einen logischen Ausdruck umgewandelt. Wenn der Nutzer beispielsweise „Northeast“ in den Filter order_region eingegeben hat, würde Looker diese Tags in order.region = 'Northeast' umwandeln. Anders ausgedrückt erkennt Looker die Benutzereingabe und generiert den entsprechenden logischen Ausdruck.

Dies sorgt unter Looker-Entwicklern oftmals für Verwirrung. Filtervorlagen ergeben immer einen logischen Ausdruck in irgendeiner Form und nicht den einzelnen Wert, den ein Benutzer eingegeben hat.

Da Vorlagenvorlagen einen logischen Ausdruck zurückgeben, können Sie sie mit anderen logischen Operatoren und logischen Ausdrücken verwenden, die in der SQL-WHERE-Anweisung gültig sind. Wenn Sie mit dem obigen Beispiel alle Werte mit Ausnahme der vom Nutzer ausgewählten Region zurückgeben möchten, können Sie Folgendes in der WHERE-Anweisung verwenden:

NOT ({% condition order_region %} order.region {% endcondition %})

Ein LookML-Feld kann auf als Filterbedingung verwendet werden. Alle Filter, die direkt auf das LookML-Feld angewendet werden, bestimmen den Wert der WHERE-Anweisung:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  dimension: region {
    type: string
    sql: ${TABLE}.region ;;
}

Liquid-Parameter

Die Syntax für Liquid-Parameter gestaltet sich wie folgt:

{% parameter parameter_name %}
  • Das Wort parameter ändert sich nie.
  • Ersetzen Sie parameter_name durch den Namen parameter, den Sie im ersten Schritt erstellt haben.

Wenn Sie beispielsweise die Eingabe aus dem Feld parameter in Schritt 1 anwenden möchten, können Sie folgende Messung verwenden:

  measure: sale_price_metric {

    type: number
    label_from_parameter: sale_price_metric_picker
    sql: {% parameter sale_price_metric_picker %}(${sale_price}) ;;
    value_format_name: usd
  }

Zwischen Filtervorlagen und Liquid-Parametern wählen

Zwar ähneln sich Filtervorlagen und Liquid-Parameter, doch es gibt einen entscheidenden Unterschied:

  • Flüssigkeitsparameter fügen Nutzereingaben direkt ein oder verwenden die Werte, die Sie mit zulässigen Werten definieren.
  • In Vorlagen werden Werte wie oben beschrieben als logische Anweisungen eingefügt.

Wenn Sie den Benutzern flexiblere Eingabemöglichkeiten bieten möchten (etwa verschiedene Arten von Datumsbereichen oder Zeichenfolgen-Suchläufen), sollten Sie nach Möglichkeit Filtervorlagen verwenden. Looker kann die Benutzereingabe interpretieren und im Hintergrund den entsprechenden SQL-Code schreiben. So müssen Sie nicht jede nur erdenkliche Benutzereingabe einzeln berücksichtigen.

In Situationen, in denen eine logische Anweisung nicht eingefügt werden kann oder bei denen Sie eine begrenzte Auswahl von Optionen kennen, die der Nutzer eingeben könnte, verwenden Sie Flüssigkeitsparameter.