Filtervorlagen und Liquid-Parameter

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

Looker bietet Nutzern automatisch die Möglichkeit, ihre Abfrage durch Erstellen von Filtern zu bearbeiten, die auf Dimensionen und Messwerten beruhen. Diese Methode deckt zwar viele Anwendungsfälle ab, kann jedoch nicht alle Analyseanforderungen erfüllen. Mit Filtervorlagen und Liquid-Parametern können Sie eine große Anzahl von Anwendungsfällen unterstützen.

Aus SQL-Perspektive können Dimensionen und Messwerte lediglich die äußersten WHERE- oder HAVING-Klauseln der Abfrage ändern. Vielleicht möchten Sie aber auch, dass die Benutzer andere Teile des SQL-Codes bearbeiten können. Mithilfe von Filtervorlagen und Liquid-Parametern können Sie unter anderem einen Teil einer abgeleiteten Tabelle anpassen, festlegen, welche Datenbanktabelle abgefragt werden soll, oder Mehrzweckdimensionen und ‑filter erstellen.

Warnung: Persistenz wird für abgeleitete Tabellen, die Filtervorlagen oder Liquid-Parameter verwenden, nicht unterstützt.

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

Beispiele

Sehen wir uns einige Beispiele an, um den Nutzen von Filtervorlagen und Liquid-Parameter zu veranschaulichen.

Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen

Als Beispiel verwenden wir eine abgeleitete Tabelle, die die Gesamtausgaben eines Kunden (lifetime spend) in der Region Nordost (northeast) 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. Jetzt nehmen wir jedoch an, dass der Nutzer die region selbst festlegen können soll und die Region daher nicht als „northeast“ fest programmiert wird. Die region kann nicht als Dimension dargestellt werden. Das heißt, der Benutzer kann nicht wie üblich danach 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 im Abschnitt Einfache Nutzung.

Hinweis: Wenn eine abgeleitete Tabelle einen Filter mit Vorlage verwendet, können Sie sie nicht persistent machen.

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. Außerdem kann das Explore dadurch für die Nutzer unübersichtlich werden.

Alternativ können Sie einen dynamischen Messwert wie diesen 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 im Abschnitt Einfache Nutzung.

Grundlegende Nutzung

Schritt 1: Etwas erstellen, mit dem der Nutzer interagieren kann

• Fügen Sie bei Vorlagenfiltern ein filter hinzu.
• Fügen Sie für Liquid-Parameter ein parameter hinzu.

In beiden Fällen werden diese Felder dem Nutzer im Field Picker im Abschnitt Nur-Filterfelder angezeigt.

Sowohl filter- als auch parameter-Felder können eine Reihe untergeordneter Parameter akzeptieren, sodass Sie deren Funktionsweise anpassen können. Eine vollständige Liste finden Sie auf der Seite Feldparameter. Bei parameter-Feldern gibt es zwei Optionen, die besonders erwähnt werden sollten.

Erstens können parameter-Felder einen speziellen Typ namens unquoted 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: parameter-Felder haben die Option Zulässige Werte, mit der Sie dem einzufügenden Wert einen nutzerfreundlichen Namen zuweisen können. Beispiel:

  parameter: sale_price_metric_picker {
    description: "Use with the Sale Price Metric measure"
    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: Die Benutzereingabe anwenden

Der zweite Schritt ist die Verwendung von Liquid, um die Filtervorlage bzw. den Liquid-Parameter wie gewünscht hinzuzufü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 reines Filterfeld erstellt haben.
• Ersetzen Sie sql_or_lookml_reference durch den SQL- oder LookML-Code, der der Benutzereingabe entsprechen sollte (mehr dazu erfahren Sie weiter unten in diesem Abschnitt). Wenn Sie LookML verwenden, nutzen Sie die ${view_name.field_name}-LookML-Syntax.

Im vorherigen Beispiel Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen 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. Diese Tags für Filtervorlagen werden immer in einen logischen Ausdruck umgewandelt. Wenn der Nutzer beispielsweise „Nordost“ in den Filter order_region eingegeben hat, wandelt Looker diese Tags in Folgendes um:

order.region = 'Northeast'

Anders ausgedrückt erkennt Looker die Benutzereingabe und generiert den entsprechenden logischen Ausdruck.

Hinweis: 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 vordefinierte Filter einen logischen Ausdruck zurückgeben, können Sie sie mit anderen logischen Operatoren und logischen Ausdrücken verwenden, die in der SQL-Anweisung WHERE gültig sind. Wenn Sie im obigen Beispiel alle Werte außer der Region zurückgeben möchten, die der Nutzer ausgewählt hat, können Sie Folgendes in der WHERE-Anweisung verwenden:

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

Ein LookML-Feld kann als Filterbedingung verwendet werden. Mit allen direkt auf das LookML-Feld angewendeten Filtern wird der Wert der WHERE-Anweisung festgelegt.

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 der parameter, die Sie im ersten Schritt erstellt haben.

Soll beispielsweise die Eingabe aus dem Feld parameter in Schritt 1 angewendet werden, könnten Sie über eine Kennzahl Folgendes erstellen:

  measure: sale_price_metric {
    description: "Use with the Sale Price Metric Picker filter-only field"
    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:

• Mit Liquid-Parametern wird die Nutzereingabe direkt eingefügt (oder die Werte, die Sie mit zulässigen Werten definieren).
• Bei vorlagebasierten Filtern werden Werte als logische Anweisungen eingefügt, wie im Abschnitt zu vorlagebasierten Filtern beschrieben.

Wenn Sie den Nutzern flexiblere Eingabemöglichkeiten bieten möchten (z. B. 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.

Verwenden Sie Liquid-Parameter, wenn ein logischer Ausdruck nicht eingefügt werden kann oder die Anzahl der möglichen Benutzereingaben überschaubar ist.