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 durch Erstellen von Filtern zu bearbeiten, die auf Dimensionen und Messwerten basieren. Diese einfache Methode erfüllt zwar viele Anwendungsfälle, kann jedoch nicht alle Analyseanforderungen erfüllen. 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 in Ihrer 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.

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 Liquid-Parametern zu veranschaulichen.

Eine dynamische abgeleitete Tabelle mit einer Filtervorlage erstellen

Nehmen wir als Beispiel eine abgeleitete Tabelle, in 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 die region angeben kann, anstatt ihn für „northeast“ hartzucodieren. region kann nicht als Dimension verwendet werden, d. h., Nutzer können nicht wie gewohnt 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
  }
}

Unten findest du eine detaillierte Anleitung.

Wenn in einer abgeleiteten Tabelle eine Filtervorlage 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
}

Unten findest du eine detaillierte Anleitung.

Grundlegende Verwendung

Schritt 1: Etwas erstellen, mit dem die Nutzenden interagieren können

  • Fügen Sie für Filtervorlagen eine filter hinzu.
  • Fügen Sie für Liquid-Parameter einen parameter hinzu.

In beiden Fällen werden diese Felder im Field Picker unter Nur-Filter-Felder angezeigt.

Die Felder filter und parameter können eine Reihe von untergeordneten Parametern aufnehmen, sodass Sie ihre Funktionsweise anpassen können. Eine vollständige Liste finden Sie auf der Dokumentationsseite Feldparameter. Es gibt zwei Optionen, die für parameter-Felder besonders erwähnt werden sollten.

Erstens können parameter-Felder einen speziellen Typ mit dem Namen nicht in 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 denen Sie dem einzufügenden Wert einen nutzerfreundlichen Namen zuordnen 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: Nutzereingabe anwenden

Der zweite Schritt besteht darin, mit Liquid den Vorlagenfilter oder den Liquid-Parameter nach Bedarf 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 den SQL- oder LookML-Code, der auf „gleich“ für die Nutzereingabe festgelegt werden soll (siehe unten). 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, 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 „Nordost“ in den order_region-Filter eingegeben hat, wandelt Looker diese Tags in order.region = 'Northeast' um. 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 Filtervorlagen 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 vorherigen 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. 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.

Um beispielsweise die Eingabe aus dem Feld parameter in Schritt 1 anzuwenden, 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:

  • Liquid-Parameter fügen Nutzereingaben direkt ein oder verwenden die Werte, die Sie mit zulässigen Werten definieren.
  • Mit Filtervorlagen werden Werte als logische Anweisungen eingefügt, wie im Abschnitt Filtervorlagen 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 Sie nur eine begrenzte Anzahl von Optionen kennen, die der Nutzer eingeben kann.