Filtervorlagen und Liquid-Parameter

Dieses Thema für Fortgeschrittene richtet sich an Benutzer, die bereits über gute SQL- und LookML-Kenntnisse verfügen.

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. Filtervorlagen und Liquid-Parameter erweitern die möglichen Anwendungsfälle, die Sie unterstützen können, enorm.

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. Das Anpassen 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 Filtervorlagen und Liquid-Parametern aktivieren können.

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

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 einige Beispiele an, um den Nutzen von Filtervorlagen und Liquid-Parameter zu veranschaulichen.

Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen

Sehen Sie sich eine abgeleitete Tabelle an, mit der die Lifetime-Ausgaben eines Kunden in der Region Nordosten berechnet werden:

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 jedoch, dass der Nutzer region angeben kann, anstatt es für "northeast" hart zu codieren. 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 Grundlegende Verwendung.

Hinweis: Wenn eine abgeleitete Tabelle eine Filtervorlage verwendet, können Sie die Tabelle 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. 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 im Abschnitt Einfache Nutzung.

Grundlegende Nutzung

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

• Fügen Sie für Filter mit Vorlagen ein filter hinzu.
• Fügen Sie für Liquid-Parameter 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 Dokumentationsseite Feldparameter. Bei parameter-Feldern gibt es zwei Optionen, die besonders erwähnt werden sollten.

Erstens können parameter-Felder 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 haben parameter-Felder eine Option namens zulässige Werte, mit der Sie einen nutzerfreundlichen Namen mit dem einzufügenden Wert verknüpfen 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

Fügen Sie im zweiten Schritt mit Liquid die Filtervorlage oder den Liquid-Parameter nach Bedarf hinzu.

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 den SQL- oder LookML-Code, der auf „gleich“ festgelegt werden sollte auf die Nutzereingabe hin (wird später in diesem Abschnitt ausführlicher erläutert). Wenn Sie LookML verwenden, nutzen Sie die LookML-Syntax ${view_name.field_name}.

Im vorherigen Beispiel Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen haben wir Folgendes verwendet:

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

Es ist wichtig, die Interaktion zwischen den Liquid-Tags und dem SQL-Code zu verstehen, den Sie dazwischen schreiben. Diese Vorlagen-Filter-Tags werden immer in einen logischen Ausdruck umgewandelt. Beispiel: Der Nutzer hat „Nordosten“ eingegeben. in den order_region-Filter würde Looker diese Tags so umwandeln:

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 irgendeiner Art und nicht den einzelnen Wert, der von einem Nutzer eingegeben wird.

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 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. 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.

Wenn Sie beispielsweise die Eingabe aus dem Feld parameter in Schritt 1 anwenden möchten, können Sie einen Messwert wie diesen 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 werden Nutzereingaben direkt oder über die Werte, die Sie mit zulässigen Werten definieren, eingefügt.
• Bei vorlagebasierten Filtern werden Werte als logische Anweisungen eingefügt, wie im Abschnitt zu vorlagebasierten Filtern beschrieben.

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.

Verwenden Sie Liquid-Parameter, wenn eine logische Anweisung nicht eingefügt werden kann oder Ihnen eine endliche Anzahl von Optionen bekannt ist, die der Nutzer eingeben könnte.