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 viele Anwendungsfälle, ermöglicht aber nicht alle Analyseanforderungen. Durch Filtervorlagen und Liquid-Parameter nimmt die Zahl der möglichen Anwendungsfälle, die Sie unterstützen können, enorm zu.

Aus SQL-Sicht können Dimensionen und Messwerte nur die äußersten WHERE- oder HAVING-Klauseln in der Abfrage ändern. Vielleicht möchten Sie aber auch, dass die Benutzer andere Teile des SQL-Codes bearbeiten können. Sie können einen Teil einer abgeleiteten Tabelle anpassen, die Datenbanktabelle abfragen, die abgefragt wird, oder Mehrfachdimensionen und -filter erstellen. Das 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 einige Beispiele an, um den Wert von Vorlagenfiltern und Flüssigkeitsparametern zu veranschaulichen.

Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen

In einer abgeleiteten Tabelle werden die Lifetime-Ausgaben eines Kunden innerhalb der nordöstlichen Region 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, anstatt ihn hartcodiert zu haben. region kann nicht als Dimension angezeigt werden und der Nutzer kann daher 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
  }
}

Weitere Informationen finden Sie unten.

Wenn in einer abgeleiteten Tabelle ein Vorlagenfilter verwendet wird, können Sie die Tabelle nicht dauerhaft 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
}

Weitere Informationen finden Sie unten.

Grundlegende Verwendung

Schritt 1: Inhalte für den Nutzer erstellen

• Füge bei Vorlagenfiltern filter hinzu.
• Füge für Flüssigkeitsparameter ein parameter hinzu.

In beiden Fällen werden die folgenden Felder in der Feldauswahl im Bereich Nur-Filter-Felder angezeigt:

Sowohl das Feld filter als auch das Feld parameter kann eine Reihe von untergeordneten Parametern akzeptieren, sodass Sie die Funktionsweise anpassen können. Eine vollständige Liste finden Sie auf der Dokumentationsseite Feldparameter. Es gibt zwei Optionen, die in parameter-Feldern besonders erwähnt werden.

Erstens können parameter-Felder den speziellen Typ 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 haben parameter-Felder eine Option namens zulässige Werte, mit der Sie einen nutzerfreundlichen Namen mit dem Wert verknüpfen können, den Sie einfügen möchten. 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: Nutzereingabe anwenden

Verwenden Sie im zweiten Schritt Liquid, um den Vorlagenfilter oder den Flüssigkeitsparameter 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 Filterfeld erstellen konnten.
• Ersetzen Sie sql_or_lookml_reference durch SQL oder LookML, die auf die Nutzereingabe gesetzt werden soll (weitere Informationen weiter unten). Wenn du LookML verwendest, verwende 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 den Filter „Nordost“ in den Filter „order_region“ eingegeben hat, sieht Looker diese Tags so aus: order.region = 'Northeast'. 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 Vorlagenfilter 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 im obigen Beispiel alle Werte außer der vom Nutzer ausgewählten Region zurückgeben möchten, können Sie in der WHERE-Anweisung Folgendes verwenden:

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

Ein LookML-Feld kann auf als Filterbedingung verwendet werden. Alle direkt auf das LookML-Feld angewendeten Filter 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 einen Messwert 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:

• Bei flüssigen Parametern wird die Nutzereingabe direkt eingefügt oder es werden die Werte verwendet, die Sie mit zulässigen Werten festgelegt haben.
• In Vorlagenvorlagen werden Werte wie oben 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 Anzahl von Optionen kennen, die der Nutzer eingeben kann, verwenden Sie Flüssigkeitsparameter.