Dies ist ein fortgeschrittenes Thema, bei dem vorausgesetzt wird, dass die Lesenden über fundierte Kenntnisse in LookML verfügen.
Übersicht
Mit zunehmender Größe und Komplexität Ihres LookML-Modells wird es immer nützlicher, es an mehreren Stellen wiederzuverwenden. Mit dem Parameter extends
können Sie Code wiederverwenden, um Folgendes zu tun:
- Schreiben Sie DRY-Code (sich nicht wiederholen), damit Sie Dinge an nur einer Stelle definieren können und Ihren Code einheitlicher und schneller bearbeiten können.
- Verschiedene Feldsätze für unterschiedliche Nutzer verwalten
- Designmuster in verschiedenen Teilen Ihres Projekts teilen
- Gruppen von Joins, Dimensionen oder Messwerten in einem Projekt wiederverwenden
Zum Erweitern eines LookML-Objekts erstellen Sie ein neues LookML-Objekt und fügen dann den Parameter extends
hinzu, um anzugeben, dass das neue Objekt eine Erweiterung eines vorhandenen Objekts ist. Das bedeutet, dass Ihr Projekt zwei Versionen des LookML-Objekts hat. Im Falle von Konflikten hat das erweiterbare Objekt Vorrang und überschreibt die Einstellungen des Objekts, das erweitert wird. Weitere Informationen finden Sie im Abschnitt Implementierungsdetails für extends
weiter unten auf dieser Seite.
LookML-Verfeinerungen ansehen: Das Erweitern einer Ansicht oder eines Explores ist ideal für Szenarien, in denen Sie mehrere Versionen der Ansicht oder des Explores haben möchten. Wenn Ihr Ziel jedoch darin besteht, eine Ansicht oder ein Explore zu ändern, ohne die entsprechende LookML-Datei zu bearbeiten, können Sie stattdessen einen Suchfilter verwenden. Sie können auch einen
extends
-Parameter in einem Suchfilter verwenden. Weitere Informationen und Anwendungsfälle finden Sie auf der Dokumentationsseite zu LookML-Verfeinerungen.
Sie können Ansichten, Explores und LookML-Dashboards erweitern:
Modelle können nicht erweitert werden und Sie können keine Modelldatei in eine andere Modelldatei einfügen. Wenn Sie Explores modellübergreifend wiederverwenden oder erweitern möchten, können Sie stattdessen eine separate Explore-Datei erstellen und dann diese Explore-Datei in eine Modelldatei aufnehmen.
Die folgenden Beispiele zeigen, wie Sie ein Explore erweitern und ein LookML-Dashboard erweitern.
Explore erweitern
Hier ist ein Beispiel für die Erweiterung eines Explores:
explore: customer {
persist_for: "12 hours"
}
explore: transaction {
extends: [customer]
persist_for: "5 minutes"
}
In diesem Beispiel haben wir ein Explore namens Customer und ein zweites Explore namens Transaktion erstellt, das es erweitert. Alle Elemente in Customer, z. B. Joins, sind in Transaktion enthalten. Alle Einträge in Transaktion verbleiben in Transaktion.
Es gibt jedoch einen Konflikt: Im Customer Explore wird für die Einstellung persist_for
12 Stunden angegeben, im Transaction Explore sind sie hingegen auf 5 Minuten festgelegt. Für das Explore Transaktion wird die Einstellung persist_for: "5 minutes"
verwendet, da sie die Einstellung im erweiterten Explore überschreibt.
LookML-Dashboard erweitern
Um ein LookML-Dashboard zu erweitern, müssen sowohl das erweiterte als auch das erweiterte Dashboard in der Modelldatei enthalten sein. Wenn ein Dashboard mit dem Parameter extends
in einer Modelldatei ohne das grundlegende Dashboard, das erweitert wird, enthalten ist, erhalten Sie einen LookML-Validierungsfehler, der darauf hinweist, dass das Basis-Dashboard nicht gefunden werden kann (und andere Fehler).
Hier ist ein Beispiel für eine Dashboard-Datei:
Datei: faa.dashboard.lookml
- dashboard: faa
title: FAA Dashboard
layout: newspaper
elements:
- title: Aircraft Location
name: Aircraft Location
model: e_faa
explore: aircraft
type: looker_map
fields:
- aircraft.zip
- aircraft.count
sorts:
- aircraft.count desc
limit: 500
query_timezone: America/Los_Angeles
series_types: {}
row: 0
col: 0
width: 8
height: 6
Wir können eine neue LookML-Dashboard-Datei erstellen und das FAA-Dashboard durch Hinzufügen einer neuen Kachel erweitern:
Datei: faa_additional.dashboard.lookml
- dashboard: faa_additional
title: FAA Additional
extends: faa
elements:
- title: Elevation Count
name: Elevation Count
model: e_faa
explore: airports
type: looker_scatter
fields:
- airports.elevation
- airports.count
sorts:
- airports.count desc
limit: 500
query_timezone: America/Los_Angeles
row: 0
col: 8
width: 8
height: 6
Da es das FAA erweitert, enthält das FAA alle Tiles, die in der faa.dashboard.lookml
-Datei definiert sind. Darüber hinaus enthält das Dashboard Zusätzliche FAA alle Tiles, die in einer eigenen faa_additional.dashboard.lookml
-Datei definiert sind.
Am einfachsten erstellen Sie ein LookML-Dashboard, indem Sie den LookML-Code aus einem benutzerdefinierten Dashboard abrufen. Mit dieser Technik können Sie auch den LookML-Code für einzelne Dashboard-Tiles abrufen. Wenn Sie diese Methode verwenden, achten Sie darauf, dass sich die Positionen Ihrer Kacheln nicht überschneiden. In den Beispielen faa.dashboard.lookml
und faa_additional.dashboard.lookml
befinden sich die Kacheln beide in der obersten Zeile des Dashboards, was durch row: 0
angegeben wird:
Datei: faa.dashboard.lookml
row: 0
col: 0
width: 8
height: 6
Die neue Kachel, die wir dem zusätzlichen FAA-Dashboard hinzufügen, befindet sich jedoch in col: 8
und wird daher neben der Kachel des erweiterten Dashboards angezeigt:
Datei: faa_additional.dashboard.lookml
row: 0
col: 8
width: 8
height: 6
Dies ist leicht zu übersehen, da sich diese Elemente in verschiedenen Dashboard-Dateien befinden. Wenn Sie also Tiles zu einem erweiterten Dashboard hinzufügen, achten Sie darauf, ob Positionierungskonflikte zwischen den Tiles im erweiterten Dashboard und den Tiles im erweiterten Dashboard vorhanden sind.
Verlängerung erforderlich
Sie können den Parameter extension: required
verwenden, um ein LookML-Objekt als Erweiterung zu kennzeichnen, was bedeutet, dass das Objekt nicht alleine verwendet werden kann. Ein Objekt mit extension: required
ist für Nutzer alleine nicht sichtbar. Es soll lediglich als Ausgangspunkt für eine Erweiterung durch ein anderes LookML-Objekt dienen. Der Parameter extension
wird für Explores, Ansichten und LookML-Dashboards unterstützt.
Ein explore
mit extension: required
kann nicht als explore_source
für einen Datentest verwendet werden. Der LookML Validator generiert einen Fehler, der besagt, dass die explore_source
nicht gefunden werden kann.
Metadaten zum Aufrufen von Erweiterungen eines Objekts verwenden
Sie können in der Looker-IDE auf einen Parameter explore
oder view
klicken und im Metadatenbereich sehen, welche Erweiterungen für das Objekt hinzugefügt wurden oder welches Objekt erweitert wird. Weitere Informationen finden Sie auf der Dokumentationsseite Metadaten für LookML-Objekte.
Implementierungsdetails für extends
Beim Erweitern eines LookML-Objekts führt Looker die folgenden Schritte aus:
- Objekt kopieren, das erweitert wird: Looker erstellt eine Kopie des LookML-Codes für das Ansichts-, Explore- oder LookML-Dashboard, das erweitert wird. Diese neue Kopie ist das erweiterte ing-Objekt.
- Führen Sie den LookML-Code der beiden Kopien zusammen: Looker führt den LookML-Code des erweiterten Objekts mit dem erweitertening-Objekt zusammen.
- Konflikte zwischen den Kopien lösen: Wenn ein LookML-Element sowohl im erweiterten als auch im erweitertening-Objekt definiert ist, wird in den meisten Fällen die Version im erweiterten Objekt verwendet. In anderen Fällen kombinieren Erweiterungen jedoch Parameterwerte, anstatt sie zu überschreiben. Weitere Informationen finden Sie im Abschnitt Parameter kombinieren auf dieser Seite.
- LookML anwenden: Sobald alle Konflikte gelöst sind, interpretiert Looker das Ergebnis nach der Standardlogik. Mit anderen Worten: Looker verwendet alle standardmäßigen Standardeinstellungen und Annahmen wie bei jedem anderen Ansichts-, Explore- oder LookML-Dashboard.
In den folgenden Abschnitten werden die einzelnen Schritte beschrieben. Als Beispiel dient das Maximieren einer Ansicht. Hier ist der LookML-Code für unsere Basisansicht, die Ansicht User, zu sehen:
view: user {
suggestions: yes
dimension: name {
sql: ${TABLE}.name ;;
}
dimension: status {
sql: ${TABLE}.status ;;
type: number
}
}
Hier ist der LookML-Code für die Ansicht User with Age Extensions (Nutzer mit Alterserweiterungen), die die Ansicht User erweitert:
include: "/views/user.view"
view: user_with_age_extensions {
extends: [user]
suggestions: no
dimension: age {
type: number
sql: ${TABLE}.age ;;
}
dimension: status {
type: string
}
}
Schritt 1: LookML kopieren
In diesem Fall wird die Ansicht user
auf die Ansicht user_with_age_extensions
erweitert. Da es sich bei user
um die Ansicht handelt, die erweitert wird, wird vor dem Zusammenführen eine Kopie der Ansicht erstellt. Die Tatsache, dass eine Kopie erstellt wird, ist hier nicht besonders wichtig. Die ursprüngliche user
-Ansicht bleibt unverändert und kann wie gewohnt verwendet werden.
Schritt 2: Kopien zusammenführen
Im nächsten Schritt wird der gesamte LookML-Code aus der erweiterten Ansicht (user
) in der erweiterten Ansicht (user_with_age_extensions
) zusammengeführt. Es ist wichtig, die Art dieser Zusammenführung zu verstehen, bei der es sich einfach um eine Zusammenführung von LookML-Objekten handelt. In der Praxis bedeutet dies, dass jeder explizit geschriebene LookML-Code zusammengeführt wird. Die nicht notierten LookML-Standardwerte werden jedoch nicht zusammengeführt. In gewisser Weise ist es eigentlich nur der Text des LookML-Codes, der zusammengesetzt wird, und keine der Bedeutung dieses Textes.
Schritt 3: Konflikte lösen
Im dritten Schritt werden Konflikte zwischen den zusammengeführten Ansichten behoben.
Wenn ein LookML-Element sowohl im erweitertened-Objekt als auch im erweitertening-Objekt definiert ist, wird in den meisten Fällen die Version im erweiterten Objekt verwendet. In anderen Fällen kombinieren Erweiterungen jedoch Parameterwerte, anstatt sie zu überschreiben. Weitere Informationen finden Sie im Abschnitt Parameter kombinieren auf dieser Seite.
Im Fall des user_with_age_extensions
-Beispiels ist keiner der Parameter additiv und es sind keine speziellen Listenoptionen oder sql
-Keywords angegeben. Daher überschreiben die Parameterwerte in der erweiterten Ansicht die Parameterwerte in der erweiterten Ansicht:
- Der Name der erweiterten Ansicht (
user_with_age_extensions
) überschreibt den Namen der erweiterten Ansicht (user
). - Der Wert für die Erweiterunging für
suggestions: no
überschreibt den Wert für die erweiterte Einstellungsuggestions: yes
. - Die erweiternde Ansicht hat die Dimension
age
, die in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt). - Die erweiterte Ansicht hat die Dimension
name
, die in der erweitern Ansicht nicht vorhanden ist (kein Konflikt). - Der Wert „
type: string
“ der Dimension „status
“ in der Ansicht „Erweitern“ überschreibt den Wert „type: number
“ in der Ansicht „Erweitert“. - Die Dimension „
status
“ hat einen Parameter „sql
“, der in der Erweiterungsansicht nicht vorhanden ist (kein Konflikt).
Es ist wichtig, dass die LookML-Standardwerte noch nicht berücksichtigt werden, da Sie nicht den Fehler machen möchten, dass Konflikte zwischen Standardwerten gelöst werden. Tatsächlich werden sie bei diesem Schritt einfach ignoriert. Aus diesem Grund müssen wir beim Erweitern von Objekten explizit zusätzliche Parameter hinzufügen:
- Beim Erweitern einer Ansicht werden die Parameter
sql_table_name
undinclude
hinzugefügt. - Beim Erweitern eines Explores fügen wir die Parameter
view_name
undview_label
hinzu.
In diesem Beispiel haben wir der Ansicht Nutzer nicht sql_table_name
hinzugefügt, was im nächsten Schritt zu Problemen führen wird.
Schritt 4: LookML als normal interpretieren
Im letzten Schritt wird der resultierende LookML-Code einschließlich aller Standardwerte als normal interpretiert. In diesem speziellen Beispiel würde die resultierende LookML-Ansicht so interpretiert:
include: "/views/user.view"
view: user_with_age_extensions {
suggestions: no
dimension: age {
type: number
sql: ${TABLE}.age ;;
}
dimension: name {
sql: ${TABLE}.name ;;
}
dimension: status {
sql: ${TABLE}.status ;;
type: string
}
}
Beachten Sie, dass die resultierende LookML view: user_with_age_extensions
, aber keinen sql_table_name
-Parameter enthält. Daher wird in Looker davon ausgegangen, dass der Wert von sql_table_name
dem Namen der Ansicht entspricht.
Das Problem ist, dass in unserer Datenbank wahrscheinlich keine Tabelle mit dem Namen user_with_age_extensions
vorhanden ist. Aus diesem Grund müssen wir jeder Ansicht, die erweitert werden soll, den Parameter sql_table_name
hinzufügen. Durch das Hinzufügen von view_name
und view_label
zu Explores, die erweitert werden, können ähnliche Probleme vermieden werden.
Kombinieren von Erweiterungen
Es gibt mehrere Möglichkeiten, LookML-Objekte mit Erweiterungen zu nutzen:
- Ein Objekt kann mehrere andere Objekte erweitern.
- Ein Erweiterungsobjekt kann selbst erweitert werden.
- Extends können in Verfeinerungen verwendet werden. Weitere Informationen finden Sie auf der Dokumentationsseite zu LookML-Verfeinerungen.
Ein Beispiel für einen erweiterten Anwendungsfall sowie Tipps zur Fehlerbehebung finden Sie auf der Seite Fehlerbehebung für ein Beispiel für einen erweiterten Anwendungsfall mit
extends
.
Gleichzeitiges Erweitern mehrerer Objekte
Es ist möglich, mehrere Dashboards, Ansichten oder Explores gleichzeitig zu erweitern. Beispiel:
explore: orders {
extends: [user_info, marketing_info]
}
# Also works for dashboards and views
Der Erweiterungsvorgang funktioniert genauso wie im Implementierungsbeispiel beschrieben. Es gibt jedoch eine zusätzliche Regel zur Behebung von Konflikten. Bei Konflikten zwischen den Elementen, die im Parameter extends
aufgeführt sind, werden den zuletzt aufgeführten Elementen Priorität zugewiesen. Bei Konflikten zwischen user_info
und marketing_info
im Beispiel oben würde also das Explore marketing_info
gewinnt.
Verkettung mehrerer Erweiterungen
Sie können auch so viele Verkettungen verketten, wie Sie möchten. Beispiel:
explore: orders {
extends: [user_info]
...
}
explore: user_info {
extends: [marketing_info]
...
}
Auch hier funktioniert die Erweiterung genauso wie im Implementierungsbeispiel beschrieben, mit einer zusätzlichen Regel zur Konfliktlösung. Bei Konflikten erhält das letzte Element in der Erweiterungskette Priorität. In diesem Fall gilt Folgendes:
orders
hat Vorrang voruser_info
undmarketing_info
.user_info
hat Vorrang vormarketing_info
.
Parameter kombinieren
Wenn ein LookML-Element sowohl im erweitertened-Objekt als auch im erweitertening-Objekt definiert ist, wird in den meisten Fällen die Version im erweiterten Objekt verwendet. Dies war auch im Implementierungsbeispiel auf dieser Seite der Fall.
In den folgenden Fällen kombinieren Erweiterungen jedoch Parameterwerte, anstatt die Werte zu überschreiben:
- Für additive Parameter
- Mit dem
EXTENDED*
-Listen-Keyword - Mit dem Keyword
${EXTENDED}
für den Parametersql
Einige Parameter sind additiv
Wenn das erweiterbare Objekt denselben Parameter wie das zu erweiternde Objekt enthält, werden die Parameterwerte des erweiterten Objekts durch die Werte des erweiterten Objekts überschrieben. Erweiterungen können jedoch für einige Parameter additiv sein. Das bedeutet, dass die Werte des erweiterbaren Objekts zusammen mit den Werten aus dem erweiterten Objekt verwendet werden.
Die folgenden Parameter sind additiv:
Für Dimensionen und Messwerte:
Parameter:
Für abgeleitete Tabellen:
Für Ansichten:
Für Explores:
Im folgenden Beispiel enthält die Ansicht carriers
die Dimension name
mit dem Parameter link
:
view: carriers {
sql_table_name: flightstats.carriers ;;
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Google {{ value }}"
url: "http://www.google.com/search?q={{ value }}"
icon_url: "http://google.com/favicon.ico"
}
}
}
Hier ist die Ansicht carriers_extended
, die die Ansicht carriers
erweitert. Die Ansicht carriers_extended
enthält auch eine name
-Dimension mit anderen Einstellungen im Parameter link
:
include: "/views/carriers.view.lkml"
view: carriers_extended {
extends: [carriers]
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Dashboard for {{ value }}"
url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
icon_url: "https://www.looker.com/favicon.ico"
}
}
}
In der Ansicht „carriers_extended
“ sind die beiden link
-Parameter additiv. Für die Dimension „name
“ werden also beide Links angezeigt.
Zusätzliche Optionen mit Listen
Wenn Sie mit Listen arbeiten, können Sie diese kombinieren, anstatt die Liste des erweiterten Objekts zu gewinnen. Sehen Sie sich diese einfache Erweiterung mit einer in Konflikt stehenden Liste namens animals
an:
view: pets {
extends: fish
set: animals {
fields: [dog, cat]
}
}
view: fish {
set: animals {
fields: [goldfish, guppy]
}
}
In diesem Fall führt die Ansicht pets
die Erweiterung durch und gewinnt daher, sodass animals
[dog, cat]
enthält. Wenn Sie jedoch das spezielle Set EXTENDED*
verwenden, können Sie die Listen stattdessen kombinieren:
view: pets {
extends: fish
set: animals {
fields: [dog, cat, EXTENDED*]
}
}
view: fish {
set: animals {
fields: [goldfish, guppy]
}
}
Jetzt enthält die animals
-Liste [dog, cat, goldfish, guppy]
.
Kombinieren statt Ersetzen während der Konfliktlösung
Falls während der Erweiterung Konflikte auftreten, hat in den meisten Fällen das Erweiterungsobjekt Vorrang. Nehmen wir als Beispiel diese einfache Erweiterung:
view: product_short_descriptions {
extends: products
dimension: description {
sql: ${TABLE}.short_description ;;
}
}
view: products {
dimension: description {
sql: ${TABLE}.full_description ;;
}
}
Wie Sie sehen, besteht ein Konflikt beim Parameter sql
in der Dimension description
. In der Regel überschreibt die Definition aus product_short_descriptions
einfach die Definition aus products
, da sie für die Erweiterung verwendet wird.
Sie können die Definitionen aber auch kombinieren. Dazu verwenden Sie das Keyword ${EXTENDED}
so:
view: product_short_descriptions {
extends: products
dimension: description {
sql: LEFT(${EXTENDED}, 50) ;;
}
}
view: products {
dimension: description {
sql: ${TABLE}.full_description ;;
}
}
Jetzt wird der Konflikt des sql
-Parameters anders behandelt. Anstelle der erfolgreichen product_short_descriptions
-Definition wird die Definition aus products
an der Stelle eingefügt, an der ${EXTENDED}
verwendet wird. Die resultierende Definition für description
lautet in diesem Fall LEFT(${TABLE}.full_description, 50)
.
Wichtige Punkte
Projekte mit Lokalisierung
Beachten Sie beim Erweitern eines Objekts, dass Lokalisierungsregeln auch für Ihre Erweiterungen gelten. Wenn Sie ein Objekt erweitern und dann neue Bezeichnungen oder Beschreibungen definieren, sollten Sie Lokalisierungsdefinitionen in den Gebietsschema-Zeichenfolgendateien Ihres Projekts angeben. Weitere Informationen finden Sie auf der Dokumentationsseite LookML-Modell lokalisieren.