Beachten Sie, dass Sie sich die Looker-Dokumentation ansehen. Dokumentation zu Looker Studio finden Sie unter https://support.google.com/looker-studio.

Code mit Erweiterungen wiederverwenden

Dies ist ein Thema für Fortgeschrittene, bei dem vorausgesetzt wird, dass der Leser über solide Kenntnisse von LookML verfügt.

Überblick

Mit zunehmender Größe und Komplexität Ihres LookML-Modells wird es immer nützlicher, Ihren LookML-Code an mehreren Stellen wiederzuverwenden. Mit dem Parameter extends können Sie Code wiederverwenden. Dies ermöglicht Ihnen Folgendes:

Schreiben Sie DRY-Code (wiederholen Sie sich nicht selbst), damit Sie alles an einem Ort definieren können. Dadurch wird der Code einheitlicher und lässt sich schneller bearbeiten.
Verschiedene Feldsätze für verschiedene Nutzer verwalten
Designmuster in verschiedenen Teilen Ihres Projekts teilen
Gruppen von Verknüpfungen, Dimensionen oder Messungen projektübergreifend wiederverwenden

Um ein LookML-Objekt zu erweitern, 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 haben wird. Bei Konflikten hat das erweiternde Objekt Vorrang und überschreibt die Einstellungen des erweiterten Objekts. 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 Sie jedoch einfach eine Ansicht oder ein Explore ändern möchten, ohne die darin enthaltene LookML-Datei zu bearbeiten, können Sie stattdessen eine Verfeinerung verwenden. Sie können auch einen extends-Parameter innerhalb eines Suchfilters verwenden. Weitere Informationen und Anwendungsfälle finden Sie auf der Dokumentationsseite LookML-Verfeinerungen.

Sie können Ansichten, Explores und LookML-Dashboards erweitern:

Modelle können nicht erweitert werden und Sie können eine Modelldatei nicht 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.

Sehen Sie sich die folgenden Beispiele zum Erweitern eines Explores und zum Erweitern eines LookML-Dashboards an.

Explore erweitern

Hier ist ein Beispiel für das Erweitern eines Explores:

explore: customer {
  persist_for: "12 hours"
}

explore: transaction {
  extends: [customer]
  persist_for: "5 minutes"
}

In diesem Beispiel haben wir ein Explore mit dem Namen Kunde und wir haben ein zweites Explore namens Transaktion erstellt, um es zu erweitern. Alle Elemente in Customer, einschließlich Verknüpfungen, werden in Transaktion aufgenommen. Alle Inhalte in der Spalte Transaktion verbleiben in Transaktion.

Beachten Sie jedoch, dass es einen Konflikt gibt: Im explorativen Kunden-Explore wird angegeben, dass die Einstellung persist_for 12 Stunden betragen sollte, aber laut Transaction-Explore sind es 5 Minuten. Für das Explore Transaktion wird die Einstellung persist_for: "5 minutes" verwendet, da sie die Einstellung des Explores überschreibt, das erweitert wird.

LookML-Dashboard erweitern

Zum Erweitern eines LookML-Dashboards müssen sowohl das erweiterte als auch das Erweiterungs-Dashboard in der Modelldatei enthalten sein. Wenn ein Dashboard mit dem Parameter extends in einer Modelldatei ohne das erweiterte Dashboard enthalten ist, erhalten Sie einen LookML-Validierungsfehler, der (und andere Fehler) das Basis-Dashboard nicht finden kann.

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

Sie können eine neue LookML-Dashboard-Datei erstellen und das FAA-Dashboard erweitern, indem Sie eine neue Kachel hinzufügen:

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-Dashboard erweitert, enthält das Dashboard FAA Zusätzlich alle Kacheln, die in der Datei faa.dashboard.lookml definiert sind. Darüber hinaus enthält das Dashboard Zusätzliche FAA alle Kacheln, 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. Sie können diese Technik auch verwenden, um den LookML-Code für einzelne Dashboardkacheln abzurufen. Wenn du diese Methode verwendest, musst du darauf achten, dass sich die Positionen deiner Kacheln nicht überschneiden. Im obigen Beispiel befinden sich die Kacheln 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 im Dashboard Zusätzliche FAA hinzufügen, befindet sich jedoch in col: 8 und wird daher neben der Kachel aus dem erweiterten Dashboard 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, dass es Positionskonflikte zwischen den Kacheln im erweiterten Dashboard und den Kacheln im erweiterten Dashboard gibt.

Verlängerung erforderlich

Sie können den Parameter extension: required verwenden, um ein LookML-Objekt als Erweiterung zu kennzeichnen. Das bedeutet, dass das Objekt nicht allein verwendet werden kann. Ein Objekt mit extension: required ist für Nutzer nicht sichtbar. Es dient nur als Ausgangspunkt für die Erweiterung durch ein anderes LookML-Objekt. Der Parameter extension wird für Explores, Views 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 die Fehlermeldung, dass explore_source nicht gefunden werden kann.

Erweiterungen für ein Objekt mithilfe von Metadaten aufrufen

Sie können in der Looker-IDE auf einen explore- oder view-Parameter klicken und im Metadatenbereich alle Erweiterungen des Objekts sehen oder sehen, welches Objekt damit erweitert wird. Weitere Informationen finden Sie auf der Dokumentationsseite Metadaten für LookML-Objekte.

Implementierungsdetails für `extends`

Looker führt beim Erweitern eines LookML-Objekts folgende Schritte aus:

Kopieren Sie das Objekt, das erweitert wird: Looker erstellt eine Kopie des LookML-Codes für die Ansicht, das Explore oder das 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 erweitertened-Objekts mit dem Erweiterning-Objekt zusammen.
Konflikte zwischen den Kopien beheben: Wenn ein LookML-Element sowohl im erweiterten-Objekt als auch im ling-Objekt definiert ist, wird zumeist die Version im Erweiterungsobjekt verwendet. In anderen Fällen werden Parameterwerte kombiniert, anstatt sie zu überschreiben. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Parameter kombinieren.
LookML anwenden: Sobald alle Konflikte gelöst sind, interpretiert Looker den resultierenden LookML-Code mithilfe der Standardlogik. Mit anderen Worten: Looker verwendet wie bei allen anderen Ansichten, Explores oder LookML-Dashboards alle Standardeinstellungen und ‐annahmen.

In den folgenden Abschnitten werden diese Schritte ausführlich beschrieben. Es wird als Beispiel eine Ansicht erweitert. Dies ist der LookML-Code für unsere Basisansicht, die Ansicht User:

view: user {
  suggestions: yes

  dimension: name {
    sql: ${TABLE}.name ;;

  }
  dimension: status {
    sql: ${TABLE}.status ;;
    type: number
  }
}

Hier sehen Sie den LookML-Code für die Ansicht Nutzer mit Alterserweiterungen, die die Ansicht Nutzer 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 user die Ansicht ist, die erweitert wird, wird vor dem Zusammenführen eine Kopie davon erstellt. Die Tatsache, dass eine Kopie erstellt wird, ist hier nicht besonders wichtig. Es ist wichtig zu wissen, dass die ursprüngliche user-Ansicht unverändert geblieben ist und wie gewohnt verwendet werden kann.

Schritt 2: Kopien zusammenführen

Im nächsten Schritt wird der gesamte LookML-Code aus der erweitertening-Ansicht (user) in der erweitertening-Ansicht (user_with_age_extensions) zusammengeführt. Es ist wichtig, die Art dieser Zusammenführung zu verstehen. Dabei handelt es sich einfach um eine Zusammenführung von LookML-Objekten. Praktisch bedeutet dies, dass alle explizit geschriebenen LookML-Werte zusammengeführt werden, aber die Standard-LookML-Werte, die Sie nicht notiert haben, nicht. In gewisser Weise wird nur der Text des LookML-Codes zusammengefügt, und es liegt nicht an der Bedeutung dieses Textes.

Schritt 3: Konflikte lösen

Der dritte Schritt besteht darin, Konflikte zwischen den zusammengeführten Ansichten zu lösen.

Wenn ein LookML-Element sowohl im erweitertened-Objekt als auch im expanding-Objekt definiert ist, wird in den meisten Fällen die Version im Erweiterungsobjekt verwendet. In anderen Fällen werden Parameterwerte kombiniert, anstatt sie zu überschreiben. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Parameter kombinieren.

Im Fall des Beispiels user_with_age_extensions ist keiner der Parameter additiv und es sind keine speziellen Listenoptionen oder sql-Keywords angegeben. Daher überschreiben die Parameterwerte in der Erweiterungsansicht die Parameterwerte in der erweiterten Ansicht:

Der Name der erweiterten Ansicht (user_with_age_extensions) überschreibt den Namen der erweiterten Ansicht (user).
Der Erweiterning-Wert für suggestions: no überschreibt den erweitertened-Wert suggestions: yes.
Die Ansicht erweitern hat die Dimension age, die in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt).
Die erweiterte Ansicht hat die Dimension name, die in der Ansicht Erweitern nicht vorhanden ist (kein Konflikt).
Der Wert type: string der Dimension „type: string“ in der Ansicht „Erweitern“ überschreibt den Wert „type: number“ in der Ansicht Erweiterte Ansicht.status
Die Dimension „status“ hat einen sql-Parameter, der in der Ansicht „Erweitern“ nicht vorhanden ist (kein Konflikt).

Die Tatsache, dass LookML-Standardwerte noch nicht berücksichtigt werden, ist wichtig, da Sie nicht den Fehler machen möchten, dass Konflikte zwischen Standardwerten gelöst werden. Tatsächlich werden sie in diesem Schritt einfach ignoriert. Aus diesem Grund müssen wir beim Erweitern von Objekten explizit zusätzliche Parameter hinzufügen:

Beim Verlängern einer Ansicht fügen wir die Parameter sql_table_name und include hinzu.
Beim Erweitern eines Explores fügen wir die Parameter view_name und view_label hinzu.

In diesem Beispiel wurde sql_table_name nicht zur Ansicht Nutzer hinzugefügt. Dies führt im nächsten Schritt zu Problemen.

Schritt 4: LookML wie gewohnt interpretieren

Im letzten Schritt wird der resultierende LookML-Code als normal interpretiert, einschließlich aller Standardwerte. In diesem speziellen Beispiel würde der resultierende LookML-Code für die Ansicht so interpretiert werden:

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 der resultierende LookML-Code view: user_with_age_extensions, aber keinen sql_table_name-Parameter enthält. Daher geht Looker davon aus, dass der Wert von sql_table_name mit dem Ansichtsnamen übereinstimmt.

Das Problem ist, dass in unserer Datenbank wahrscheinlich keine Tabelle namens user_with_age_extensions vorhanden ist. Aus diesem Grund müssen wir jeder Datenansicht, die erweitert werden soll, den Parameter sql_table_name hinzufügen. Wenn Sie view_name und view_label zu Explores hinzufügen, die erweitert werden, werden ähnliche Probleme vermieden.

Kombinieren erweitert

Es gibt verschiedene 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 LookML-Verfeinerungen.

Ein Beispiel für einen erweiterten Anwendungsfall und Tipps zur Fehlerbehebung findest du auf der Seite Best Practices zur Fehlerbehebung bei einem erweiterten extends-Anwendungsfall.

Mehrere Objekte gleichzeitig erweitern

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 Erweiterungsprozess funktioniert genau wie im Implementierungsbeispiel beschrieben. Es gibt jedoch eine weitere Regel dazu, wie Konflikte gelöst werden können. Bei Konflikten zwischen den mehreren im Parameter extends aufgeführten Elementen haben die zuletzt aufgeführten Elemente Priorität. Bei Konflikten zwischen user_info und marketing_info im Beispiel oben würde also das Explore marketing_info erfolgreich sein.

Mehrere Erweiterungen verketten

Sie können beliebig viele Erweiterungen verketten. Beispiel:

explore: orders {
  extends: [user_info]
  ...
}
explore: user_info {
  extends: [marketing_info]
  ...
}

Auch hier funktioniert der Erweiterungsprozess genau wie im Implementierungsbeispiel beschrieben, mit einer zusätzlichen Regel zur Konfliktlösung. Im Falle von Konflikten erhält das letzte Element in der Erweiterungskette Priorität. In diesem Fall gilt Folgendes:

orders hat Vorrang vor user_info und marketing_info.
user_info hat Priorität vor marketing_info.

Parameter kombinieren

Wenn ein LookML-Element sowohl im erweitertened-Objekt als auch im expanding-Objekt definiert ist, wird in den meisten Fällen die Version im Erweiterungsobjekt verwendet. Dies war im Implementierungsbeispiel auf dieser Seite der Fall.

In den folgenden Fällen werden Parameterwerte von Erweiterungen combine, statt sie zu überschreiben:

Für additive Parameter
Mit dem Keyword EXTENDED*-Liste
Mit dem Schlüsselwort ${EXTENDED} für den Parameter sql

Einige Parameter sind additiv

Wenn das Erweiterungsobjekt denselben Parameter wie das erweiterte Objekt enthält, überschreiben die Werte des Erweiterungsobjekts in vielen Fällen die Parameterwerte des erweiterten Objekts. Erweiterungen können jedoch für einige Parameter additiv sein, was bedeutet, dass die Werte aus dem Erweiterungsobjekt zusammen mit den Werten aus dem erweiterten Objekt verwendet werden.

Die folgenden Parameter sind additiv:

Für Dimensionen und Messungen:
Für Parameter:
- allowed_value
Für abgeleitete Tabellen:
Für Ansichten:
- extends
Für Explores:

Im folgenden Beispiel enthält die Ansicht carriers eine name-Dimension mit einem link-Parameter:

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"
    }
  }
}

Und 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 link-Parameter:


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, sodass mit der Dimension name beide Links angezeigt werden.

Zusätzliche Optionen mit Listen

Bei der Arbeit mit Listen können Sie diese kombinieren, anstatt die Liste des Erweiterungsobjekts zum Sieger zu ziehen. Betrachten Sie diese einfache Erweiterung mit der widersprüchlichen Liste animals:

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

In diesem Fall übernimmt die Ansicht pets die Erweiterung und gewinnt daher, sodass animals den Wert [dog, cat] enthält. Mithilfe des speziellen Satzes EXTENDED* können Sie die Listen jedoch stattdessen kombinieren:

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat, EXTENDED*]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

Die Liste animals enthält jetzt [dog, cat, goldfish, guppy].

Kombinieren statt Ersetzen während der Konfliktlösung

Bei Konflikten während der Erweiterung gewinnt das Erweiterungsobjekt meistens. Nehmen wir zum Beispiel diese einfache Erweiterung:

view: product_short_descriptions {
  extends: products
  dimension: description {
    sql: ${TABLE}.short_description ;;
  }
}
view: products {
  dimension: description {
    sql: ${TABLE}.full_description ;;
  }
}

Sie sehen, dass ein Konflikt des sql-Parameters innerhalb der description-Dimension vorliegt. In der Regel überschreibt die Definition aus product_short_descriptions einfach die Definition aus products, da sie die Erweiterung durchführt.

Sie können die Definitionen aber auch combine, wenn Sie möchten. 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 genommen und 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 Sprachstringdateien Ihres Projekts angeben. Weitere Informationen finden Sie auf der Dokumentationsseite LookML-Modell lokalisieren.