Messtypen

Diese Seite bezieht sich auf den Parameter type, der Teil einer Kennung ist.

type kann auch als Teil einer Dimension oder eines Filters verwendet werden, wie auf der Dokumentationsseite zu Dimensionen, Filtern und Parametertypen beschrieben.

type kann auch als Teil einer Dimensionsgruppe verwendet werden, wie auf der Dokumentationsseite zum Parameter dimension_group beschrieben.

Nutzung

view: view_name {
measure: Feldname {
type: measure_field_type
}
}
Hierarchie
type
Mögliche Feldtypen
Messen

Akzeptiert
Messwerttyp

Diese Seite enthält Details zu den verschiedenen Typen, die einer Messung zugewiesen werden können. Ein Messwert kann nur einen Typ haben. Wenn kein Typ angegeben ist, wird standardmäßig string verwendet.

Einige Messtypen haben unterstützende Parameter, die im entsprechenden Abschnitt beschrieben werden.

Typkategorien messen

Jeder Messwerttyp fällt in eine der folgenden Kategorien. Diese Kategorien bestimmen, ob der Messwerttyp Aggregationen durchführt, auf welche Felder der Messwerttyp verweisen kann und ob der Messwerttyp mit dem Parameter filters gefiltert werden kann:

  • Zusammengefasste Messwerte: Mit zusammengefassten Messwerttypen werden Aggregationen wie sum und average durchgeführt. Aggregierte Messwerte können sich nur auf Dimensionen und nicht auf andere Messwerte beziehen. Dies ist der einzige Messtyp, der mit dem Parameter filters funktioniert.
  • Nicht zusammengefasste Messwerte: Messwerte, die nicht aggregiert sind, wie number und yesno, werden nicht aggregiert. Diese Messwerttypen führen einfache Transformationen durch. Da sie keine Aggregationen ausführen, können sie nur auf zusammengefasste Messwerte oder zuvor aggregierte Dimensionen verweisen. Sie können den Parameter filters nicht mit diesen Messwerttypen verwenden.
  • Post-SQL-Messungen: Post-SQL-Messungen sind spezielle Messtypen, die spezifische Berechnungen ausführen, nachdem Looker die Abfrage-SQL generiert hat. Sie können nur auf numerische Maße oder numerische Dimensionen verweisen. Sie können den Parameter filters nicht mit diesen Messwerttypen verwenden.

Liste der Typdefinitionen

Typ Kategorie Beschreibung
average Aggregat Generiert einen Durchschnitt (Mittelwert) von Werten in einer Spalte
average_distinct Aggregat Erzeugt bei Verwendung denormalisierter Daten einen durchschnittlichen (mittleren) Wert. Eine vollständige Beschreibung finden Sie unten.
count Aggregat Anzahl der Zeilen generieren
count_distinct Aggregat Anzahl der eindeutigen Werte in einer Spalte generieren
date Nicht aggregiert Für Maßnahmen mit Datumsangaben
list Aggregat Erstellt eine Liste eindeutiger Werte innerhalb einer Spalte
max Aggregat Generiert den Höchstwert innerhalb einer Spalte
median Aggregat Generiert den Medianwert (Mittelwert) von Werten in einer Spalte
median_distinct Aggregat Erzeugt ordnungsgemäß einen Medianwert (Mittelpunktwert) der Werte, wenn ein Join einen Fanout verursacht. Eine vollständige Beschreibung finden Sie unten.
min Aggregat Erzeugt den Mindestwert in einer Spalte
number Nicht aggregiert Bei Messwerten, die Zahlen enthalten
percent_of_previous Post-SQL Erzeugt den prozentualen Unterschied zwischen angezeigten Zeilen
percent_of_total Post-SQL Generiert den Prozentsatz der Gesamtzahl für jede angezeigte Zeile
percentile Aggregat Erzeugt den Wert im angegebenen Perzentil in einer Spalte
percentile_distinct Aggregat Erzeugt ordnungsgemäß den Wert im angegebenen Perzentil, wenn ein Join einen Fan-out verursacht. Eine vollständige Beschreibung finden Sie unten.
running_total Post-SQL Generiert die laufende Summe für jede angezeigte Zeile
string Nicht aggregiert Für Maße, die Buchstaben oder Sonderzeichen enthalten (wie bei der GROUP_CONCAT-Funktion von MySQL)
sum Aggregat Generiert eine Summe von Werten in einer Spalte
sum_distinct Aggregat Erzeugt ordnungsgemäß eine Summe von Werten, wenn denormalisierte Daten verwendet werden.
Eine vollständige Beschreibung finden Sie unten.
yesno Nicht aggregiert Für Felder, die angezeigt werden, wenn etwas wahr oder falsch ist
int Nicht aggregiert REMOVED 5.4 Ersetzt durch type: number

average

type: average mittelt die Werte in einem bestimmten Feld. Es ähnelt der SQL-Funktion AVG. Anders als beim Schreiben von Roh-SQL berechnet Looker jedoch den Durchschnitt auch dann, wenn die Joins Ihrer Abfrage Fanouts enthalten.

Der Parameter sql für type: average-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

type: average-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Mit der folgenden LookML wird beispielsweise ein Feld namens avg_order erstellt, indem die Dimension sales_price gemittelt und dann in einem Geldformat angezeigt wird (1.234,56 $):

measure: avg_order {
  type: average
  sql: ${sales_price} ;;
  value_format_name: usd
}

average_distinct

type: average_distinct wird für denormalisierte Datasets verwendet. Er mittelt die nicht wiederkehrenden Werte in einem bestimmten Feld basierend auf den eindeutigen Werten, die durch den Parameter sql_distinct_key definiert werden.

Dies ist ein erweitertes Konzept, das anhand eines Beispiels ausführlicher erläutert werden kann. Nehmen wir als Beispiel eine denormalisierte Tabelle:

Auftragsartikel-ID Bestell-ID Versand der Bestellung
1 1 10,00
2 1 10,00
3 2 20,00
4 2 20,00
5 2 20,00

In diesem Fall sehen Sie, dass es für jeden Auftrag mehrere Zeilen gibt. Wenn Sie daher eine einfache type: average-Messung für die Spalte order_shipping hinzufügen, erhalten Sie einen Wert von 16,00, obwohl der tatsächliche Durchschnitt 15,00 beträgt.

 # Will NOT calculate the correct average
measure: avg_shipping {
  type: average
  sql: ${order_shipping} ;;
}

Für ein genaues Ergebnis können Sie Looker erklären, wie jede einzelne Entität (in diesem Fall jede einzelne Reihenfolge) mit dem Parameter sql_distinct_key identifiziert werden sollte. So wird der richtige Betrag von 15,00 berechnet:

 # Will calculate the correct average
measure: avg_shipping {
  type: average_distinct
  sql_distinct_key: ${order_id} ;;
  sql: ${order_shipping} ;;
}

Beachten Sie, dass jeder eindeutige Wert von sql_distinct_key nur einen entsprechenden Wert in sql haben muss. Mit anderen Worten: Das Beispiel oben funktioniert, weil jede Zeile mit einem order_id von 1 denselben order_shipping von 10,00 hat, jede Zeile mit einem order_id von 2 denselben order_shipping von 20,00 usw.

type: average_distinct-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

count

type: count führt eine Tabellenzählung aus, ähnlich wie bei der COUNT-Funktion von SQL. Anders als beim Schreiben von Roh-SQL berechnet Looker die Anzahl auch dann korrekt, wenn die Joins Ihrer Abfrage Fanouts enthalten.

type: count-Messungen unterstützen den Parameter sql nicht, da eine type: count-Messung Tabellenzahlen basierend auf dem Primärschlüssel der Tabelle ausführt. Wenn Sie eine Tabellenanzahl für ein anderes Feld als den Primärschlüssel der Tabelle ausführen möchten, verwenden Sie den Messwert type: count_distinct.

Die folgende LookML erstellt beispielsweise das Feld number_of_products:

view: products {
  measure: number_of_products {
    type: count
    drill_fields: [product_details*]  # optional
  }
}

Beim Definieren einer type: count-Kennung wird häufig der Parameter drill_fields (für Felder) angegeben, damit Nutzer beim Anklicken die einzelnen Datensätze sehen können.

Wenn Sie in einer explorativen Datenanalyse ein Messwert type: count verwenden, werden die resultierenden Werte in der Visualisierung mit dem Namen der Datenansicht statt dem Wort „Anzahl“ gekennzeichnet. Um Verwechslungen zu vermeiden, empfehlen wir, den Ansichtsnamen zu Pluralformen auszuwählen, in den Visualisierungseinstellungen unter Reihe die Option Vollständigen Feldnamen anzeigen auszuwählen oder view_label mit einer Pluralform der Ansicht zu verwenden.

Wenn Sie ein COUNT (nicht COUNT_DISTINCT) für ein Feld ausführen möchten, das nicht der Primärschlüssel ist, können Sie dafür ein Maß von type: number verwenden. Weitere Informationen finden Sie im Hilfeartikel Der Unterschied zwischen count- und count_distinct-Messtypen.

Mit dem Parameter filters können Sie einen Messwert in type: count filtern.

count_distinct

type: count_distinct berechnet die Anzahl der verschiedenen Werte in einem bestimmten Feld. Dabei wird die COUNT DISTINCT-Funktion von SQL verwendet.

Der Parameter sql für type: count_distinct-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

Die folgende LookML erstellt beispielsweise das Feld number_of_unique_customers, das die Anzahl der eindeutigen Kundennummern zählt:

measure: number_of_unique_customers {
  type: count_distinct
  sql: ${customer_id} ;;
}

Mit dem Parameter filters können Sie einen Messwert in type: count_distinct filtern.

date

type: date wird mit Feldern verwendet, die Datumsangaben enthalten.

Der Parameter sql für type: date-Messungen kann jeden gültigen SQL-Ausdruck verwenden, der zu einem Datum führt. In der Praxis wird dieser Typ nur selten verwendet, da die meisten SQL-Aggregatfunktionen keine Daten zurückgeben. Eine häufige Ausnahme ist ein MIN oder MAX einer Datumsdimension.

Höchst- oder Mindestdatumsmesswert mit type: date erstellen

Wenn Sie ein Maß für ein Höchst- oder Mindestdatum erstellen möchten, sollten Sie anfangs davon ausgehen, einen Messwert von type: max oder type: min zu verwenden. Diese Messwerttypen sind jedoch nur mit numerischen Feldern kompatibel. Stattdessen können Sie ein maximales oder minimales Datum erfassen, indem Sie einen Messwert von type: date definieren und das Datumsfeld umschließen, auf das im Parameter sql in einer MIN()- oder MAX()-Funktion verwiesen wird.

Angenommen, Sie haben eine Dimensionsgruppe von type: time namens updated:

dimension_group: updated {
  type: time
  timeframes: [time, date, week, month, raw]
  sql: ${TABLE}.updated_at ;;
}

Sie können einen Messwert für type: date erstellen, um das maximale Datum dieser Dimensionsgruppe zu erfassen:

measure: last_updated_date {
  type: date
  sql: MAX(${updated_raw}) ;;
  convert_tz: no
}

In diesem Beispiel wird anstelle des Messwerts type: max zum Erstellen des Messwerts last_updated_date die Funktion MAX() im Parameter sql angewendet. Bei dem Messwert last_updated_date ist der Parameter convert_tz auch auf no festgelegt, um eine Doppelkonvertierung der Zeitzone in den Messwert zu verhindern, da die Zeitzonenkonvertierung bereits in der Definition der Dimensionsgruppe updated stattgefunden hat. Weitere Informationen finden Sie in der Dokumentation zum Parameter convert_tz.

Im Beispiel-LookML für die last_updated_date-Messung kann type: date weggelassen werden. Der Wert würde dann als String behandelt, da string der Standardwert für type ist. Wenn Sie type: date verwenden, haben Sie jedoch bessere Filtermöglichkeiten für Nutzer.

Sie werden auch feststellen, dass die last_updated_date-Messdefinition auf den ${updated_raw}-Zeitraum statt auf den ${updated_date}-Zeitraum verweist. Da der von ${updated_date} zurückgegebene Wert ein String ist, muss mit ${updated_raw} auf den tatsächlichen Datumswert verwiesen werden.

Sie können auch den Parameter datatype mit type: date verwenden, um die Abfrageleistung zu verbessern. Geben Sie dazu den Datentyp an, der in Ihrer Datenbanktabelle verwendet wird.

Höchst- oder Mindestmaß für eine Datum/Uhrzeit-Spalte erstellen

Das Berechnen des Maximums für eine type: datetime-Spalte ist etwas anders. In diesem Fall erstellen Sie einen Messwert, ohne den Typ zu deklarieren:

measure: last_updated_datetime {
  sql: MAX(${TABLE}.datetime_string_field) ;;
}

list

type: list erstellt eine Liste der eindeutigen Werte in einem bestimmten Feld. Es ähnelt der MySQL-Funktion GROUP_CONCAT.

Für type: list-Messwerte müssen Sie keinen sql-Parameter angeben. Stattdessen geben Sie mit dem Parameter list_field die Dimension an, aus der Sie Listen erstellen möchten.

Die Nutzung sieht so aus:

view: view_name {
measure: field_name {
type: list
list_field: my_field_name
}
}

Mit dem folgenden LookML wird beispielsweise ein Messwert name_list basierend auf der Dimension name erstellt:

measure: name_list {
  type: list
  list_field: name
}

Hinweise zu list:

  • Der Messwerttyp list unterstützt keine Filterung. Der Parameter filters kann nicht für Messwerte vom Typ type: list verwendet werden.
  • Auf den Messwerttyp list kann nicht mit dem Substitutionsoperator ($) verwiesen werden. Die Syntax ${} kann nicht für einen Verweis auf ein type: list-Attribut verwendet werden.

Unterstützte Datenbankdialekte für list

Damit Looker type: list in Ihrem Looker-Projekt unterstützt, muss es auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte type: list in der neuesten Version von Looker unterstützen:

max

type: max ermittelt den größten Wert in einem bestimmten Feld. Dabei wird die MAX-Funktion von SQL verwendet.

Der Parameter sql für Maße von type: max kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

Da Messwerte von type: max nur mit numerischen Feldern kompatibel sind, können Sie mit dem Messwert type: max kein Maximum finden. Stattdessen können Sie die MAX()-Funktion im Parameter sql einer Metrik von type: date verwenden, um ein maximales Datum zu erfassen, wie zuvor in den Beispielen im date-Abschnitt gezeigt.

type: max-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Im folgenden LookML wird beispielsweise ein Feld namens largest_order erstellt, indem die Dimension sales_price betrachtet und dieses dann in einem Geldformat angezeigt wird (1.234,56 $):

measure: largest_order {
  type: max
  sql: ${sales_price} ;;
  value_format_name: usd
}

Sie können derzeit keine type: max-Messwerte für Strings oder Datumsangaben verwenden. Sie können aber die MAX-Funktion manuell hinzufügen, um ein solches Feld zu erstellen:

measure: latest_name_in_alphabet {
  type: string
  sql: MAX(${name}) ;;
}

median

type: median gibt den Mittelpunktwert für die Werte in einem bestimmten Feld zurück. Dies ist insbesondere dann hilfreich, wenn die Daten einige sehr große oder kleine Ausreißerwerte haben, die einen einfachen Durchschnitt (Durchschnitt) verzerren würden.

Betrachten Sie eine Tabelle wie diese:

Auftrags-Artikel-ID | Kosten | Mittelpunkt? -------------:|--------------: 2 | 10,00 | 4 | 10,00 | 3 | 20,00 | Mittelpunkt |1 | 80,00 | 5 | 90,00 |

Die Tabelle wird hier aufgeführt, um die Ansicht zu erleichtern. Sie ist jedoch nicht von den Ergebnissen betroffen. Während für den Typ average der Wert 42 zurückgegeben würde (alle Werte addieren und durch 5 teilen), wird vom Typ median der Mittelpunktwert zurückgegeben: 20,00.

Wenn eine gerade Anzahl von Werten vorhanden ist, wird der Medianwert mithilfe des Mittelwerts der zwei Werte berechnet, die dem Mittelpunkt am nächsten sind. Betrachten Sie eine Tabelle wie diese mit einer geraden Anzahl von Zeilen:

Auftrags-Artikel-ID | Kosten | Mittelpunkt? -------------:|--------------: 2 | 10 | 3 | 20 | Am nächsten vor dem Mittelpunkt 1 | 80 | Am nächsten nach dem Mittelpunkt 4 | 90

Der Medianwert, der mittlere Wert, ist (20 + 80)/2 = 50.

Der Median entspricht ebenfalls dem Wert beim 50. Perzentil.

Der Parameter sql für type: median-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

type: median-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Beispiel

Mit der folgenden LookML wird beispielsweise ein Feld namens median_order erstellt, indem die Dimension sales_price gemittelt und dann in einem Geldformat angezeigt wird (1.234,56 $):

measure: median_order {
  type: median
  sql: ${sales_price} ;;
  value_format_name: usd
}

Was Sie für median beachten sollten

Wenn Sie median für ein Feld verwenden, das an einem Fanout beteiligt ist, versucht Looker stattdessen, median_distinct zu verwenden. medium_distinct wird jedoch nur für bestimmte Dialekte unterstützt. Wenn median_distinct für Ihren Dialekt nicht verfügbar ist, gibt Looker einen Fehler zurück. Da median als 50. Perzentil angesehen werden kann, gibt der Fehler an, dass der Dialekt keine unterschiedlichen Perzentile unterstützt.

Unterstützte Datenbankdialekte für median

Damit Looker den Typ median in Ihrem Looker-Projekt unterstützt, muss er auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte den Typ median im neuesten Release von Looker unterstützen:

Wenn an einer Abfrage ein Fanout beteiligt ist, versucht Looker, die median in median_distinct umzuwandeln. Dies funktioniert nur in Dialekten, die median_distinct unterstützen.

median_distinct

Verwenden Sie type: median_distinct, wenn Ihr Joint einen Fan-Out beinhaltet. Er mittelt die nicht wiederkehrenden Werte in einem bestimmten Feld basierend auf den eindeutigen Werten, die durch den Parameter sql_distinct_key definiert werden. Wenn der Messwert keinen sql_distinct_key-Parameter hat, versucht Looker, das Feld primary_key zu verwenden.

Betrachten Sie das Ergebnis einer Abfrage, die die Tabellen „Order Item“ und „Order“ verknüpft:

Auftragsartikel-ID Bestell-ID Versand der Bestellung
1 1 10
2 1 10
3 2 20
4 3 50
5 3 50
6 3 50

In diesem Fall sehen Sie, dass es für jeden Auftrag mehrere Zeilen gibt. Diese Abfrage enthielt einen Fanout, da jede Bestellung mehreren Bestellelementen zugeordnet ist. median_distinct berücksichtigt dies und ermittelt den Medianwert zwischen den unterschiedlichen Werten 10, 20 und 50, sodass Sie den Wert 20 erhalten.

Für ein genaues Ergebnis können Sie Looker erklären, wie jede einzelne Entität (in diesem Fall jede einzelne Reihenfolge) mit dem Parameter sql_distinct_key identifiziert werden sollte. So wird der richtige Betrag berechnet:

measure: median_shipping {
  type: median_distinct
  sql_distinct_key: ${order_id} ;;
  sql: ${order_shipping} ;;
}

Beachten Sie, dass jeder eindeutige Wert für sql_distinct_key nur einen entsprechenden Wert im sql-Parameter haben muss. Mit anderen Worten: Das Beispiel oben funktioniert, weil jede Zeile mit einem order_id von 1 denselben order_shipping von 10, jede Zeile mit einem order_id von 2 den gleichen order_shipping von 20 usw. hat.

type: median_distinct-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Was Sie für median_distinct beachten sollten

Der Messwerttyp medium_distinct wird nur für bestimmte Dialekte unterstützt. Wenn median_distinct für den Dialekt nicht verfügbar ist, gibt Looker einen Fehler zurück. Da median als 50. Perzentil angesehen werden kann, gibt der Fehler an, dass der Dialekt keine unterschiedlichen Perzentile unterstützt.

Unterstützte Datenbankdialekte für median_distinct

Damit Looker den Typ median_distinct in Ihrem Looker-Projekt unterstützt, muss er auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte den Typ median_distinct im neuesten Release von Looker unterstützen:

min

type: min sucht den kleinsten Wert in einem bestimmten Feld. Dabei wird die MIN-Funktion von SQL verwendet.

Der Parameter sql für Maße von type: min kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

Da Messwerte von type: min nur mit numerischen Feldern kompatibel sind, können Sie mit dem Messwert type: min kein Mindestdatum ermitteln. Stattdessen können Sie die Funktion MIN() im Parameter sql eines Maßs von type: date verwenden, um einen Minimalwert zu erfassen, und die Funktion MAX() mit einem Messwert von type: date, um ein Maximum zu erfassen. Dies wird zuvor auf dieser Seite im Abschnitt date gezeigt. Hier finden Sie Beispiele für die Verwendung der Funktion MAX() im Parameter sql, um ein maximales Datum zu finden.

type: min-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Im folgenden LookML wird beispielsweise ein Feld namens smallest_order erstellt, indem die Dimension sales_price betrachtet und dieses dann in einem Geldformat angezeigt wird (1.234,56 $):

measure: smallest_order {
  type: min
  sql: ${sales_price} ;;
  value_format_name: usd
}

Sie können derzeit keine type: min-Messwerte für Strings oder Datumsangaben verwenden. Sie können aber die MIN-Funktion manuell hinzufügen, um ein solches Feld zu erstellen:

measure: earliest_name_in_alphabet {
  type: string
  sql: MIN(${name}) ;;
}

number

type: number wird mit Zahlen oder Ganzzahlen verwendet. Ein Messwert von type: number führt keine Aggregation durch und ist für einfache Transformationen anderer Messwerte vorgesehen. Wenn Sie einen Messwert auf der Grundlage eines anderen Messwerts definieren, muss der neue Messwert type: number sein, um verschachtelte Aggregationsfehler zu vermeiden.

Der Parameter sql für type: number-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer Zahl oder Ganzzahl führt.

type: number-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Im folgenden LookML wird beispielsweise ein Messwert namens total_gross_margin_percentage basierend auf den aggregierten Messwerten total_sale_price und total_gross_margin erstellt und dann in einem Prozentsatzformat mit zwei Dezimalstellen (12,34%) angezeigt:

measure: total_sale_price {
  type: sum
  value_format_name: usd
  sql: ${sale_price} ;;
}

measure: total_gross_margin {
  type: sum
  value_format_name: usd
  sql: ${gross_margin} ;;
}

measure: total_gross_margin_percentage {
  type: number
  value_format_name: percent_2
  sql: ${total_gross_margin}/ NULLIF(${total_sale_price},0) ;;
}

Im Beispiel oben wird außerdem die SQL-Funktion NULLIF() verwendet, um die Division durch Null zu vermeiden.

Was Sie für type: number beachten sollten

Bei type: number-Maßnahmen sind einige wichtige Punkte zu beachten:

  • Ein Messwert von type: number kann nur bei anderen Maßen arithmetisch sein, nicht bei anderen Dimensionen.
  • Die symmetrischen Aggregate von Looker schützen die Aggregatfunktionen in SQL eines Messwerts type: number nicht, wenn sie für einen Join berechnet werden.
  • Der Parameter filters kann nicht mit type: number-Messwerten verwendet werden, in der filters-Dokumentation wird jedoch eine Umgehungslösung erläutert.
  • Bei type: number Maßnahmen erhalten Nutzer keine Vorschläge.

percent_of_previous

type: percent_of_previous berechnet den prozentualen Unterschied zwischen einer Zelle und der vorherigen Zelle in der Spalte.

Der Parameter sql für type: percent_of_previous-Messwerte muss auf einen anderen numerischen Messwert verweisen.

type: percent_of_previous-Felder können mit den Parametern value_format oder value_format_name formatiert werden. Die Prozentformate des Parameters value_format_name funktionieren jedoch nicht mit type: percent_of_previous-Messwerten. Bei diesen Prozentwerten werden die Werte mit 100 multipliziert, wodurch die Ergebnisse eines Prozentsatzes der vorherigen Berechnung verzerrt werden.

Im folgenden Beispiel erstellt diese LookML einen Messwert count_growth basierend auf dem Messwert count:

measure: count_growth {
  type: percent_of_previous
  sql: ${count} ;;
}

In der Looker-UI würde das so aussehen:

Beachten Sie, dass percent_of_previous-Werte von der Sortierreihenfolge abhängen. Wenn Sie die Sortierung ändern, müssen Sie die Abfrage noch einmal ausführen, um die percent_of_previous-Werte neu zu berechnen. In Fällen, in denen eine Abfrage pivotiert ist, wird percent_of_previous über die Zeile hinaus ausgeführt, nicht nach unten in der Spalte. Dieses Verhalten kann derzeit nicht geändert werden.

Darüber hinaus werden percent_of_previous-Messwerte berechnet, nachdem Daten aus Ihrer Datenbank zurückgegeben wurden. Das bedeutet, dass Sie nicht innerhalb eines anderen Messwerts auf einen percent_of_previous-Messwert verweisen sollten, weil die Messwerte möglicherweise zu unterschiedlichen Zeitpunkten berechnet werden, sodass Sie möglicherweise keine genauen Ergebnisse erhalten. Das bedeutet auch, dass percent_of_previous Messwerte nicht gefiltert werden können.

percent_of_total

type: percent_of_total berechnet den Anteil einer Zelle in der Summe. Der Prozentsatz wird anhand der Gesamtzahl der von Ihrer Abfrage zurückgegebenen Zeilen berechnet, nicht der Summe aller möglichen Zeilen. Wenn die von der Abfrage zurückgegebenen Daten jedoch ein Zeilenlimit überschreiten, werden die Werte des Felds als Nullen angezeigt, da sie die vollständigen Ergebnisse benötigen, um den Prozentsatz der Gesamtsumme zu berechnen.

Der Parameter sql für type: percent_of_total-Messwerte muss auf einen anderen numerischen Messwert verweisen.

type: percent_of_total-Felder können mit den Parametern value_format oder value_format_name formatiert werden. Die Prozentformate des Parameters value_format_name funktionieren jedoch nicht mit type: percent_of_total-Messwerten. Bei diesen Prozentwerten werden Werte mit 100 multipliziert, wodurch die Ergebnisse einer percent_of_total-Berechnung verzerrt werden.

Im folgenden Beispiel erstellt diese LookML einen Messwert percent_of_total_gross_margin basierend auf dem Messwert total_gross_margin:

measure: percent_of_total_gross_margin {
  type: percent_of_total
  sql: ${total_gross_margin} ;;
}

In der Looker-UI würde das so aussehen:

In Fällen, in denen eine Abfrage pivotiert ist, wird percent_of_total über die Zeile hinaus ausgeführt, nicht nach unten in der Spalte. Wenn Sie das nicht möchten, fügen Sie der Messwertdefinition direction: "column" hinzu.

Darüber hinaus werden percent_of_total-Messwerte berechnet, nachdem Daten aus Ihrer Datenbank zurückgegeben wurden. Das bedeutet, dass Sie nicht innerhalb eines anderen Messwerts auf einen percent_of_total-Messwert verweisen sollten, weil die Messwerte möglicherweise zu unterschiedlichen Zeitpunkten berechnet werden, sodass Sie möglicherweise keine genauen Ergebnisse erhalten. Das bedeutet auch, dass percent_of_total Messwerte nicht gefiltert werden können.

percentile

type: percentile gibt den Wert beim angegebenen Perzentil der Werte in einem bestimmten Feld zurück. Wenn Sie beispielsweise das 75. Perzentil angeben, wird der Wert zurückgegeben, der größer als 75% der anderen Werte im Dataset ist.

Zur Bestimmung des zurückzugebenden Werts berechnet Looker die Gesamtzahl der Datenwerte und multipliziert das angegebene Perzentil mit der Gesamtzahl der Datenwerte. Unabhängig davon, wie die Daten tatsächlich sortiert sind, ermittelt Looker die relative Reihenfolge der Datenwerte in aufsteigender Reihenfolge. Welcher Datenwert von Looker zurückgegeben wird, hängt davon ab, ob die Berechnung, wie unten erläutert, zu einer Ganzzahl führt oder nicht.

Wenn der berechnete Wert keine Ganzzahl ist

Looker rundet den berechneten Wert auf und verwendet ihn, um den zurückzugebenden Datenwert zu identifizieren. In diesem Beispielsatz mit 19 Testpunkten wird das 75. Perzentil mit 19 * 0,75 = 14,25 angegeben. Das bedeutet, dass 75% der Werte in den ersten 14 Datenwerten liegen, also unter der 15. Position. Daher gibt Looker den 15. Datenwert (87) als größer als 75% der Datenwerte zurück.

Wenn der berechnete Wert eine Ganzzahl ist

In diesem etwas komplexeren Fall gibt Looker einen Durchschnitt des Datenwerts an dieser Position und den folgenden Datenwert zurück. Sehen wir uns das einmal mit 20 Testergebnissen an: Das 75. Perzentil wird mit 20 * 0, 75 = 15 angegeben. Das bedeutet, dass der Datenwert an der 15. Position Teil des 75. Perzentils ist und wir einen Wert zurückgeben müssen, der über 75% der Datenwerte liegt. Durch die Rückgabe des Durchschnitts der Werte an der 15. Position (82) und der 16. Position (87) stellt Looker sicher, dass 75 % vorhanden sind. Dieser Durchschnitt (84,5) ist in den Datenwerten nicht vorhanden, würde aber größer als 75% der Datenwerte sein.

Erforderliche und optionale Parameter

Verwenden Sie das Keyword percentile:, um den Bruchwert anzugeben. Das ist der Prozentsatz der Daten, die unter dem zurückgegebenen Wert liegen sollen. Verwenden Sie beispielsweise percentile: 75, um den Wert im 75. Perzentil in der Reihenfolge der Daten anzugeben, oder percentile: 10, um den Wert im 10. Perzentil zurückzugeben. Wenn Sie den Wert für das 50. Perzentil ermitteln möchten, können Sie percentile: 50 angeben oder einfach den Typ median verwenden.

Der Parameter sql für type: percentile-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

type: percentile-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Beispiel

Mit der folgenden LookML wird beispielsweise ein Feld namens test_scores_75th_percentile erstellt, das den Wert beim 75. Perzentil in der Dimension test_scores zurückgibt:

measure: test_scores_75th_percentile {
  type: percentile
  percentile: 75
  sql: ${TABLE}.test_scores ;;
}

Was Sie für percentile beachten sollten

Wenn Sie percentile für ein Fanfan-Feld verwenden, versucht Looker stattdessen, percentile_distinct zu verwenden. Wenn percentile_distinct für den Dialekt nicht verfügbar ist, gibt Looker einen Fehler zurück. Weitere Informationen finden Sie unter Unterstützte Dialekte für percentile_distinct.

Unterstützte Datenbankdialekte für percentile

Damit Looker den Typ percentile in Ihrem Looker-Projekt unterstützt, muss er auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte den Typ percentile im neuesten Release von Looker unterstützen:

percentile_distinct

type: percentile_distinct ist eine spezielle Form von percentile und sollte verwendet werden, wenn Ihr Joint einen Fan-Out beinhaltet. Es werden die nicht wiederkehrenden Werte in einem bestimmten Feld verwendet, basierend auf den eindeutigen Werten, die durch den Parameter sql_distinct_key definiert werden. Wenn der Messwert keinen sql_distinct_key-Parameter hat, versucht Looker, das Feld primary_key zu verwenden.

Betrachten Sie das Ergebnis einer Abfrage, die die Tabellen „Order Item“ und „Order“ verknüpft:

Auftragsartikel-ID Bestell-ID Versand der Bestellung
1 1 10
2 1 10
3 2 20
4 3 50
5 3 50
6 3 50
7 4 70
8 4 70
9 5 110
10 5 110

In diesem Fall sehen Sie, dass es für jeden Auftrag mehrere Zeilen gibt. Diese Abfrage enthielt einen Fanout, da jede Bestellung mehreren Bestellelementen zugeordnet ist. percentile_distinct berücksichtigt dies und ermittelt den Perzentilwert mit den unterschiedlichen Werten 10, 20, 50, 70 und 110. Für das 25. Perzentil wird der zweite eindeutige Wert (20) zurückgegeben, während für das 80. Perzentil der Durchschnitt des vierten und fünften Werts (90) zurückgegeben wird.

Erforderliche und optionale Parameter

Verwenden Sie das Keyword percentile:, um den Bruchwert anzugeben. Verwenden Sie beispielsweise percentile: 75, um den Wert im 75. Perzentil in der Reihenfolge der Daten anzugeben, oder percentile: 10, um den Wert im 10. Perzentil zurückzugeben. Wenn Sie den Wert im 50. Perzentil ermitteln möchten, können Sie stattdessen den Typ median_distinct verwenden.

Geben Sie mit dem Parameter sql_distinct_key an, wie Looker die einzelnen Entitäten (in diesem Fall jede einzelne Reihenfolge) identifizieren soll.

Hier ein Beispiel für die Verwendung von percentile_distinct, um den Wert im 90. Perzentil zurückzugeben:

measure: order_shipping_90th_percentile {
  type: percentile_distinct
  percentile: 90
  sql_distinct_key: ${order_id} ;;
  sql: ${order_shipping} ;;
}

Beachten Sie, dass jeder eindeutige Wert für sql_distinct_key nur einen entsprechenden Wert im sql-Parameter haben muss. Mit anderen Worten: Das Beispiel oben funktioniert, weil alle Zeilen mit order_id von 1 denselben order_shipping von 10 haben, jede Zeile mit einem order_id von 2 denselben order_shipping von 20 usw.

type: percentile_distinct-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Was Sie für percentile_distinct beachten sollten

Wenn percentile_distinct für den Dialekt nicht verfügbar ist, gibt Looker einen Fehler zurück. Weitere Informationen finden Sie unter Unterstützte Dialekte für percentile_distinct.

Unterstützte Datenbankdialekte für percentile_distinct

Damit Looker den Typ percentile_distinct in Ihrem Looker-Projekt unterstützt, muss er auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte den Typ percentile_distinct im neuesten Release von Looker unterstützen:

running_total

type: running_total berechnet die kumulative Summe der Zellen in einer Spalte. Sie kann nicht verwendet werden, um Summen entlang einer Zeile zu berechnen, es sei denn, die Zeile wurde durch einen Pivot erstellt.

Der Parameter sql für type: running_total-Messwerte muss auf einen anderen numerischen Messwert verweisen.

type: running_total-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Die folgende LookML erstellt beispielsweise einen Messwert cumulative_total_revenue basierend auf dem Messwert total_sale_price:

measure: cumulative_total_revenue {
  type: running_total
  sql: ${total_sale_price} ;;
  value_format_name: usd
}

In der Looker-UI würde das so aussehen:

Beachten Sie, dass running_total-Werte von der Sortierreihenfolge abhängen. Wenn Sie die Sortierung ändern, müssen Sie die Abfrage noch einmal ausführen, um die running_total-Werte neu zu berechnen. In Fällen, in denen eine Abfrage pivotiert ist, wird running_total über die Zeile hinaus ausgeführt, nicht nach unten in der Spalte. Wenn Sie das nicht möchten, fügen Sie der Messwertdefinition direction: "column" hinzu.

Darüber hinaus werden running_total-Messwerte berechnet, nachdem Daten aus Ihrer Datenbank zurückgegeben wurden. Das bedeutet, dass Sie nicht innerhalb eines anderen Messwerts auf einen running_total-Messwert verweisen sollten, weil die Messwerte möglicherweise zu unterschiedlichen Zeitpunkten berechnet werden, sodass Sie möglicherweise keine genauen Ergebnisse erhalten. Das bedeutet auch, dass running_total Messwerte nicht gefiltert werden können.

string

type: string wird mit Feldern verwendet, die Buchstaben oder Sonderzeichen enthalten.

Der Parameter sql für type: string-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einem String führt. In der Praxis wird dieser Typ nur selten verwendet, da die meisten SQL-Aggregatfunktionen keine Strings zurückgeben. Eine häufige Ausnahme ist die MySQL-Funktion GROUP_CONCAT, obwohl Looker für diesen Anwendungsfall type: list bietet.

Im folgenden LookML wird beispielsweise das Feld category_list erstellt, indem die eindeutigen Werte eines Felds mit dem Namen category kombiniert werden:

measure: category_list {
  type: string
  sql: GROUP_CONCAT(${category}) ;;
}

In diesem Beispiel könnte type: string weggelassen werden, da string der Standardwert für type ist.

sum

type: sum addiert die Werte in einem bestimmten Feld. Es ähnelt der SQL-Funktion SUM. Anders als beim Schreiben von Roh-SQL berechnet Looker jedoch die Summen ordnungsgemäß, selbst wenn die Joins in einer Abfrage Fanouts enthalten.

Der Parameter sql für type: sum-Messungen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer numerischen Tabellenspalte, einer LookML-Dimension oder einer Kombination von LookML-Dimensionen führt.

type: sum-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Im folgenden LookML wird beispielsweise ein Feld namens total_revenue erstellt, indem die Dimension sales_price addiert und anschließend in einem Geldformat angezeigt wird (1.234,56 $):

measure: total_revenue {
  type: sum
  sql: ${sales_price} ;;
  value_format_name: usd
}

sum_distinct

type: sum_distinct wird für denormalisierte Datasets verwendet. Addiert die nicht wiederkehrenden Werte in einem bestimmten Feld basierend auf den eindeutigen Werten, die durch den Parameter sql_distinct_key definiert wurden.

Dies ist ein erweitertes Konzept, das anhand eines Beispiels ausführlicher erläutert werden kann. Nehmen wir als Beispiel eine denormalisierte Tabelle:

Auftragsartikel-ID Bestell-ID Versand der Bestellung
1 1 10,00
2 1 10,00
3 2 20,00
4 2 20,00
5 2 20,00

In diesem Fall sehen Sie, dass es für jeden Auftrag mehrere Zeilen gibt. Wenn Sie eine einfache Messung type: sum für die Spalte order_shipping hinzufügen, erhalten Sie daher insgesamt 80, 00, obwohl die erfassten Versandkosten insgesamt 30 sind.

 # Will NOT calculate the correct shipping amount
measure: total_shipping {
  type: sum
  sql: ${order_shipping} ;;
}

Für ein genaues Ergebnis können Sie Looker erklären, wie jede einzelne Entität (in diesem Fall jede einzelne Reihenfolge) mit dem Parameter sql_distinct_key identifiziert werden sollte. So wird der richtige Betrag von 30 $ berechnet:

 # Will calculate the correct shipping amount
measure: total_shipping {
  type: sum_distinct
  sql_distinct_key: ${order_id} ;;
  sql: ${order_shipping} ;;
}

Beachten Sie, dass jeder eindeutige Wert von sql_distinct_key nur einen entsprechenden Wert in sql haben muss. Mit anderen Worten: Das Beispiel oben funktioniert, weil jede Zeile mit einem order_id von 1 denselben order_shipping von 10,00 hat, jede Zeile mit einem order_id von 2 denselben order_shipping von 20,00 usw.

type: sum_distinct-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

yesno

type: yesno erstellt ein Feld, das angibt, ob etwas wahr oder falsch ist. In der Benutzeroberfläche von „Entdecken“ werden die Werte Ja und Nein angezeigt.

Der Parameter sql für eine type: yesno-Messung verwendet einen gültigen SQL-Ausdruck, der als TRUE oder FALSE ausgewertet wird. Lautet die Bedingung TRUE, wird dem Nutzer Ja angezeigt, andernfalls Nein.

Der SQL-Ausdruck für type: yesno-Messwerte darf nur Aggregationen enthalten, also SQL-Aggregationen oder Verweise auf LookML-Messwerte. Wenn Sie ein yesno-Feld erstellen möchten, das einen Verweis auf eine LookML-Dimension oder einen SQL-Ausdruck enthält, der keine Aggregation ist, verwenden Sie eine Dimension mit type: yesno und nicht mit einem Messwert.

Ähnlich wie bei Messwerten mit type: number werden für einen Messwert mit type: yesno keine Aggregationen durchgeführt, sondern lediglich andere Aggregationen referenziert.

Das Maß total_sale_price unten ist beispielsweise die Summe des Gesamtpreises der Artikel in einer Bestellung. Ein zweiter Messwert mit dem Namen is_large_total ist type: yesno. Das Maß is_large_total hat den Parameter sql, der auswertet, ob der Wert total_sale_price größer als 1.000 € ist.

measure: total_sale_price {
  type: sum
  value_format_name: usd
  sql: ${sale_price} ;;
  drill_fields: [detail*]
}
measure: is_large_total {
  description: "Is order total over $1000?"
  type: yesno
  sql: ${total_sale_price} > 1000 ;;
}

Wenn Sie in einem anderen Feld auf ein type: yesno-Feld verweisen möchten, sollten Sie das Feld type: yesno als booleschen Wert behandeln (d. h., es enthält bereits den Wert „true“ oder „false“). Beispiel:

measure: is_large_total {
  description: "Is order total over $1000?"
  type: yesno
  sql: ${total_sale_price} > 1000 ;;
}
}
# This is correct
measure: reward_points {
  type: number
  sql: CASE WHEN ${is_large_total} THEN 200 ELSE 100 END ;;
}
# This is NOT correct
measure: reward_points {
  type: number
  sql: CASE WHEN ${is_large_total} = 'Yes' THEN 200 ELSE 100 END ;;
}