Code mit Erweiterung wiederverwenden

In diesem fortgeschrittenen Thema wird davon ausgegangen, dass der Leser über gute ML-Kenntnisse verfügt.

Übersicht

Wenn Ihr LookML-Modell an Größe und Komplexität wächst, wird es immer hilfreicher, Ihr LookML an mehreren Stellen wiederzuverwenden. Mit dem Parameter extends können Sie Code wiederverwenden, um Folgendes zu tun:

  • Schreiben Sie DRY-Code (nicht sich selbst wiederholen), damit Sie Elemente an einem zentralen Ort definieren und so Ihren Code einheitlicher und schneller bearbeiten können.
  • Verschiedene Feldsätze für verschiedene Nutzer verwalten
  • Designmuster in verschiedenen Teilen Ihres Projekts freigeben
  • Join-Gruppen, Dimensionen oder Messwerte in einem Projekt wiederverwenden

Zur Erweiterung 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. Bei Konflikten hat das Erweiterungsobjekt Vorrang und überschreibt die Einstellungen des erweiterten Objekts. Weitere Informationen finden Sie weiter unten auf dieser Seite im Abschnitt Implementierungsdetails für extends.

Verfeinern Sie LookML-Optimierungen.
Das Erweitern einer Ansicht oder eines explorativen Analysetools ist ideal, wenn Sie mehrere Versionen der Ansicht oder des explorativen Analysetools verwenden möchten. Wenn Sie lediglich eine Ansicht oder eine explorative Datenanalyse ändern möchten, ohne die zugehörige MLML-Datei zu bearbeiten, können Sie stattdessen einen Suchfilter verwenden. Sie können auch einen Parameter extends innerhalb eines Suchfilters verwenden. Weitere Informationen und Anwendungsfälle finden Sie auf der Dokumentationsseite zu LookML-Optimierungen.

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

Modelle können nicht erweitert werden und Sie können keine Modelldatei in eine andere Modelldatei aufnehmen. Wenn Sie die Funktion „Erkunden“ für mehrere Modelle wiederverwenden oder erweitern möchten, können Sie stattdessen eine separate Datei „Erkunden“ erstellen und dann diese Datei in eine Modelldatei aufnehmen.

Sehen Sie sich dazu die folgenden Beispiele für die Erweiterung eines Explore und die Erweiterung eines LookML-Dashboards an.

Erkundungstour verlängern

Hier ein Beispiel für die Erweiterung eines Explore:

explore: customer {
  persist_for: "12 hours"
}

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

In diesem Beispiel haben wir ein neues Konto mit dem Namen Kunde, das wir als zweites Element mit dem Namen Transaktion erstellt haben. Alle Elemente in Customer, einschließlich ihrer Joins, werden in Transaction einbezogen. Alles in Transaktion verbleibt in Transaktion.

Aber beachten Sie, dass es einen Konflikt gibt: Der Kunden sagt, dass die Einstellung persist_for 12 Stunden betragen sollte, die Transaktion hingegen schon. Für die Option Transaktion „Entdecken“ wird die Einstellung persist_for: "5 minutes" verwendet, da sie die Einstellung der Erweiterung „Erkunden“ überschreibt.

LookML-Dashboard erweitern

Zum Erweitern eines LookML-Dashboards müssen sowohl die erweiterten als auch die erweiterten Dashboards in der Modelldatei enthalten sein. Wenn ein Dashboard, das den Parameter extends verwendet, in einer Modelldatei enthalten ist, ohne das darauf zu erweiternde Basis-Dashboard, wird ein LookML-Validierungsfehler ausgegeben, der unter anderem beim Finden des Basis-Dashboards nicht zu finden ist.

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 erweitern, indem wir 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 FAA Zusätzliche-Dashboard alle Kacheln, die in der Datei faa.dashboard.lookml definiert sind. Darüber hinaus enthält das Dashboard Weitere FAA alle Kacheln, die in einer eigenen faa_additional.dashboard.lookml-Datei definiert sind.

Am einfachsten erstellen Sie ein LookML-Dashboard, indem Sie LookML aus einem benutzerdefinierten Dashboard abrufen. Sie können diese Technik auch verwenden, um die LookML für einzelne Dashboard-Kacheln abzurufen. Achte bei dieser Methode darauf, dass sich die Positionen der Kacheln nicht überschneiden. Im obigen Beispiel befinden sich beide Kacheln in der obersten Reihe 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 FAA Zusätzliches Dashboard 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

Das ist leicht zu übersehen, da sich diese Elemente in verschiedenen Dashboard-Dateien befinden. Wenn Sie also Kacheln zu einem erweiterten Dashboard hinzufügen, sollten Sie prüfen, ob es zwischen den Kacheln im erweiterten Dashboard und den Kacheln im erweiterten Dashboard Konflikte gibt.

Erweiterung erforderlich

Mit dem Parameter extension: required können Sie ein LookML-Objekt als erforderlich kennzeichnen, sodass es nicht allein verwendet werden kann. Ein Objekt mit extension: required ist für Nutzer allein nicht sichtbar. Es dient nur als Ausgangspunkt für die Erweiterung durch ein anderes LookML-Objekt. Der Parameter extension wird für explorative Datenanalysen, 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 eine Fehlermeldung mit dem Hinweis, dass explore_source nicht gefunden werden kann.

Metadaten zum Anzeigen von Erweiterungen für ein Objekt verwenden

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

Details zur Implementierung von extends

Dies sind die Schritte, die Looker beim Erweitern eines LookML-Objekts ausführt:

  1. Objekt erweitern, das erweitert wird: Looker erstellt eine Kopie des LookML für das erweiterte Ansichts-, Erkundungs- oder LookML-Dashboard. Diese neue Kopie ist das Objekt „exting“ing.
  2. LookML der beiden Kopien zusammenführen: Looker führt die LookML des Objekts ext zu dem Objekt expand zusammen.
  3. Konflikte zwischen den Kopien lösen: Wenn hauptsächlich ein LookML-Element sowohl im Objekt erweitern als auch imerweiternObjekt definiert ist, wird die Version im Erweiterungsobjekt verwendet. In anderen Fällen kombinieren die Parameter jedoch Parameterwerte, anstatt die Werte zu überschreiben. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Parameter kombinieren.
  4. LookML anwenden: Sobald alle Konflikte gelöst sind, interpretiert Looker die resultierende LookML mithilfe der Standardlogik. Anders ausgedrückt: Looker verwendet alle Standardeinstellungen und -annahmen wie bei jeder anderen Ansicht, dem Tab „Entdecken“ oder jedem LookML-Dashboard.

In den folgenden Abschnitten werden die Details dieser Schritte gezeigt, wobei eine Ansicht als Beispiel erweitert wird. Hier ist die LookML für unsere Basisansicht, die User-Ansicht:

view: user {
  suggestions: yes

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

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

Hier ist die LookML für die Ansicht Nutzer mit Alterserweiterung, 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. Die Tatsache, dass die ursprüngliche user-Ansicht unverändert bleibt und verwendet werden kann, ist wichtig.

Schritt 2: Kopien zusammenführen

Im nächsten Schritt werden alle LookML aus der erweiterten Ansicht (user) mit der Erweiterungsansicht (user_with_age_extensions) zusammengeführt. Es ist wichtig, die Art dieser Zusammenführung zu verstehen, bei der einfach die LookML-Objekte zusammengeführt werden. In der Praxis bedeutet dies, dass alle explizit geschriebenen LookML-Werte zusammengeführt werden, die Standard-LookML-Werte, die Sie nicht notiert haben, werden jedoch zusammengeführt. Es entspricht also in Wirklichkeit nur dem Text von LookML, der zusammengefügt wird, und ohne die Bedeutung des Textes.

Schritt 3: Konflikte lösen

Im dritten Schritt werden Konflikte zwischen den zusammengeführten Ansichten behoben.

Wenn in den meisten Fällen ein LookML-Element sowohl für das Objekt expand als auch für das Objekt expand definiert ist, wird die Version im Erweiterungsobjekt verwendet. In anderen Fällen kombinieren die Parameter jedoch Parameterwerte, anstatt die Werte zu überschreiben. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Parameter kombinieren.

Im Beispiel user_with_age_extensions ist keiner der Parameter additiv und es gibt keine speziellen Listenoptionen oder sql-Keywords. Die Parameterwerte in der erweiterten Ansicht überschreiben die Parameterwerte in der erweiterten Ansicht:

  • Der Erweiterungsansichtsname (user_with_age_extensions) überschreibt den erweiterten Ansichtsnamen (user).
  • Der Erweiterungswert für suggestions: no überschreibt den erweiterten Wert suggestions: yes.
  • Die Erweiterungsansicht hat die Dimension age, die in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt).
  • Die erweiterte View-Ansicht hat die Dimension name, die in der Erweiterungsansicht nicht vorhanden ist.
  • Der Wert type: string für die Dimension status in der Erweiterungsansicht überschreibt den Wert type: number in der erweiterten Ansicht.
  • Die Dimension status hat einen Parameter sql, der in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt).

Die Tatsache, dass LookML-Standardwerte noch nicht berücksichtigt werden, ist wichtig, da Sie nicht irrtümlich darstellen möchten, dass Konflikte zwischen Standardwerten behoben 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:

In diesem Beispiel haben wir nichtsql_table_name der Ansicht User hinzugefügt, was im nächsten Schritt Probleme verursachen wird.

Schritt 4: LookML wie gewohnt interpretieren

Im letzten Schritt wird das Ergebnis in LookML wie üblich interpretiert, einschließlich aller Standardwerte. In diesem Beispiel haben wir am Ende „LookML“, das 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 dem Namen der Ansicht entspricht:

Das Problem ist, dass es wahrscheinlich keine Tabelle mit dem Namen user_with_age_extensions in unserer Datenbank gibt. Aus diesem Grund müssen wir jeder Ansicht, die erweitert wird, den Parameter sql_table_name hinzufügen. Wenn Sie view_name und view_label zu den erweiterten Funktionen für „Erkunden“ hinzufügen, werden ähnliche Probleme vermieden.

Erweiterungskombinationen

Es gibt verschiedene Möglichkeiten, LookML-Objekte mit Erweiterungen zu nutzen:

Ein Beispiel für einen erweiterten Anwendungsfall und Tipps zur Fehlerbehebung finden Sie im Hilfeartikel Beispiele für einen erweiterten extends-Anwendungsfall.

Mehrere Objekte gleichzeitig verlängern

Sie können auch mehrere Dashboards, Datenansichten oder „Erkunden“ gleichzeitig auswählen. Beispiel:

explore: orders {
  extends: [user_info, marketing_info]
}
# Also works for dashboards and views

Der Prozess für die Erweiterung funktioniert genau wie im Beispiel für die Implementierung beschrieben. Es gibt jedoch eine zusätzliche Regel zur Behebung von Konflikten. Bei Konflikten zwischen mehreren Elementen, die im Parameter extends aufgeführt sind, hat die Priorität die Elemente, die zuletzt aufgeführt sind. Wenn es im obigen Beispiel einen Konflikt zwischen user_info und marketing_info gäbe, würde die marketing_info-Erkundung gewinnen.

Mehrere Ketten verketten

Sie können auch beliebig viele Erweiterungen verketten. Beispiel:

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

Auch hier gilt: Das Erweiterungsverfahren funktioniert genau wie im Beispiel der Implementierung beschrieben, es gibt jedoch eine zusätzliche Regel zur Konfliktlösung. Bei Konflikten hat das letzte Element in der Erweiterungskette Vorrang. In diesem Fall gilt Folgendes:

  • orders hätte Vorrang vor user_info und marketing_info.
  • user_info hätte Vorrang vor marketing_info.

Parameter kombinieren

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

In den folgenden Fällen kombinieren Erweiterungen jedoch Parameterwerte kombinieren, anstatt die Werte zu überschreiben:

Einige Parameter sind additiv

In vielen Fällen enthält das verlängernde Objekt denselben Parameter wie das zu erweiternde Objekt. Die Werte des erweiterten Objekts überschreiben die Parameterwerte des erweiterten Objekts. Für einige Parameter können Erweiterungen jedoch additiv sein. Das bedeutet, dass die Werte des erweiterten Objekts in Verbindung mit den Werten des erweiterten Objekts verwendet werden.

Die folgenden Parameter sind additiv:

Im folgenden Beispiel hat die Ansicht carriers eine Dimension name mit einem 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"
    }
  }
}

Und hier ist die Ansicht carriers_extended, die die Ansicht carriers erweitert. Die Ansicht carriers_extended enthält außerdem eine Dimension name mit verschiedenen Einstellungen für den 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 Parameter link additiv. Die Dimension name enthält also beide Links. Die Dimension in einem Tab „Entdecken“ sieht so aus:

Zusätzliche Optionen mit Listen

Wenn Sie mit Listen arbeiten, können Sie sie kombinieren, statt die Liste der erweiterten Objekte zu gewinnen. Nehmen wir diese einfache Erweiterung mit einer in Konflikt stehenden Liste namens animals:

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

In diesem Fall wird die Erweiterung pets ausgeführt und gewinnt daher den Status animals, sodass sie [dog, cat] enthält. Sie können jedoch die Listen mithilfe der speziellen EXTENDED*-Gruppe 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 und nicht ersetzen, um Konflikte zu lösen

In den meisten Fällen, falls während der Erweiterung Konflikte auftreten, gewinnt das Erweiterungsobjekt. 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 des Parameters sql in der Dimension description. In der Regel überschreibt die Definition von product_short_descriptions die Definition von products, weil die Erweiterung durchgeführt wird.

Wenn Sie möchten, können Sie 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 ;;
  }
}

Der Konflikt des Parameters sql wird nun unterschiedlich behandelt. Anstatt die Definition product_short_descriptions zu gewinnen, wird die Definition von products verwendet und dort eingefügt, wo ${EXTENDED} verwendet wird. Die entsprechende 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 auch die Lokalisierungsregeln für Ihre Erweiterungen gelten. Wenn Sie ein Objekt erweitern und dann neue Labels oder Beschreibungen definieren, sollten Sie Lokalisierungsdefinitionen in den Sprachschemadateien Ihres Projekts angeben. Weitere Informationen finden Sie auf der Dokumentationsseite LookML-Modell lokalisieren.