Code mit extends wiederverwenden

Dieses Thema richtet sich an fortgeschrittene Nutzer mit guten Vorkenntnissen über LookML.

Übersicht

Je größer und komplexer Ihr LookML-Modell wird, desto sinnvoller ist es, die LookML an mehreren Stellen wiederzuverwenden. Mit dem Parameter extends können Sie Code wiederverwenden. Das bietet folgende Vorteile:

  • Schreiben Sie DRY-Code (Don't Repeat Yourself), damit Sie Dinge nur an einer Stelle definieren können. Dadurch wird Ihr Code konsistenter und schneller zu bearbeiten.
  • Unterschiedliche Feldsätze für verschiedene Nutzer verwalten
  • Designmuster in verschiedenen Teilen Ihres Projekts verwenden
  • Zusammenstellungen von Joins, Dimensionen oder Messwerten projektübergreifend wiederverwenden

Wenn Sie ein LookML-Objekt erweitern möchten, erstellen Sie ein neues LookML-Objekt und fügen Sie 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 erweiterte Objekt Vorrang und überschreibt die Einstellungen des erweiterten Objekts. Weitere Informationen finden Sie weiter unten auf dieser Seite im Abschnitt Implementierungsdetails für extends.

LookML-Optimierungen ansehen:Das Erweitern einer Datenansicht oder eines Explores eignet sich ideal für Szenarien, in denen Sie mehrere Versionen der Datenansicht oder des Explores benötigen. Wenn Sie jedoch nur eine Ansicht oder ein Explore ändern möchten, ohne die zugehörige LookML-Datei zu bearbeiten, sollten Sie stattdessen eine Verfeinerung verwenden. Sie können auch einen extends-Parameter in einer Verfeinerung verwenden. Weitere Informationen und Anwendungsfälle finden Sie auf der Dokumentationsseite LookML-Optimierungen.

Sie können Ansichten, explorative Datenanalysen 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 stattdessen in mehreren Modellen wiederverwenden oder erweitern möchten, können Sie eine separate Explore-Datei erstellen und diese dann in eine Modelldatei einfügen.

In den folgenden Beispielen wird gezeigt, wie Sie ein Explore und ein LookML-Dashboard erweitern.

Explores erweitern

Hier ein Beispiel für die Erweiterung eines explorativen Datenanalysetools:

explore: customer {
  persist_for: "12 hours"
}

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

In diesem Beispiel haben wir ein Explore namens Kunde und ein zweites Explore namens Transaktion erstellt, das es erweitert. Alles, was in Kunden enthalten ist, z. B. Joins, wird in Transaktion aufgenommen. Alles, was sich unter Transaktion befindet, bleibt unter Transaktion.

Beachten Sie jedoch, dass es einen Konflikt gibt: Im explorativen Datenbestand Kunden sollte die Einstellung persist_for 12 Stunden betragen, im explorativen Datenbestand Transaktionen jedoch 5 Minuten. Für das explorative Datenanalysetool Transaktion wird die Einstellung persist_for: "5 minutes" verwendet, da sie die Einstellung des erweiterten explorativen Datenanalysetools überschreibt.

LookML-Dashboard erweitern

Wenn Sie ein LookML-Dashboard erweitern möchten, müssen sowohl das erweiterte als auch das erweiternde Dashboard in der Modelldatei enthalten sein. Wenn ein Dashboard mit dem Parameter extends in einer Modelldatei enthalten ist, aber das Basis-Dashboard, das es erweitert, nicht, erhalten Sie unter anderem einen LookML-Validierungsfehler, dass das Basis-Dashboard nicht gefunden werden kann.

Hier sehen Sie eine Beispiel-Dashboarddatei:

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 um eine neue 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-Dashboard erweitert, enthält das FAA Additional-Dashboard alle Kacheln, die in der Datei faa.dashboard.lookml definiert sind. Außerdem enthält das Dashboard FAA Additional alle Kacheln, die in einer eigenen faa_additional.dashboard.lookml-Datei definiert sind.

Am einfachsten erstellen Sie ein LookML-Dashboard, indem Sie die LookML aus einem benutzerdefinierten Dashboard abrufen. So können Sie auch die LookML für einzelne Dashboard-Kacheln 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 in der obersten Zeile des Dashboards, die durch row: 0 gekennzeichnet ist:

Datei: faa.dashboard.lookml


    row: 0
    col: 0
    width: 8
    height: 6

Die neue Kachel, die wir dem Dashboard FAA Additional 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 einem erweiterten Dashboard Kacheln hinzufügen, prüfen Sie, ob es zu Platzierungskonflikten zwischen den Kacheln im erweiterten Dashboard und den Kacheln im erweiterten Dashboard kommt.

Verlängerung erforderlich

Mit dem Parameter extension: required können Sie ein LookML-Objekt als Erweiterung kennzeichnen, was bedeutet, dass es nicht alleine verwendet werden kann. Ein Objekt mit extension: required ist für Nutzer nicht sichtbar. Es dient nur als Ausgangspunkt, der von einem anderen LookML-Objekt erweitert werden kann. 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 gibt dann den Fehler zurück, dass die explore_source nicht gefunden werden kann.

Erweiterungen für ein Objekt anhand von Metadaten ansehen

Klicken Sie in der Looker-IDE auf einen explore- oder view-Parameter und sehen Sie sich im Metadatenbereich an, ob es Erweiterungen für das Objekt gibt oder um welches Objekt es sich handelt. Weitere Informationen finden Sie auf der Dokumentationsseite Metadaten für LookML-Objekte.

Implementierungsdetails für extends

So erweitert Looker ein LookML-Objekt:

  1. Objekt kopieren, das erweitert wird: In Looker wird eine Kopie der LookML für die Ansicht, das Explore oder das LookML-Dashboard erstellt, das erweitert wird. Diese neue Kopie ist das erweiterte Objekt.
  2. LookML der beiden Kopien zusammenführen: In Looker wird die LookML des erweiterten Objekts mit dem erweiternden Objekt zusammengeführt.
  3. Konflikte zwischen den Kopien beheben: Wenn ein LookML-Element sowohl im erweiterten als auch im erweiternden Objekt definiert ist, wird in den meisten Fällen die Version im erweiterten Objekt verwendet. In anderen Fällen werden Parameterwerte jedoch kombiniert, anstatt sie zu überschreiben. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Parameter kombinieren.
  4. LookML anwenden: Sobald alle Konflikte behoben sind, interpretiert Looker die resultierende LookML mit der Standardlogik. Mit anderen Worten: Looker verwendet alle Standardeinstellungen und -annahmen wie bei jeder anderen Ansicht, jedem Explore oder jedem LookML-Dashboard.

In den folgenden Abschnitten werden die einzelnen Schritte beschrieben. Als Beispiel wird die Erweiterung einer Ansicht gezeigt. Hier ist die LookML für unsere Basisansicht, die Nutzer-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 Altersgruppen, 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 user-Ansicht in die user_with_age_extensions-Ansicht erweitert. Da user die Ansicht ist, die erweitert wird, wird vor dem Zusammenführen eine Kopie davon erstellt. Dass eine Kopie erstellt wird, ist hier nicht besonders wichtig. Wichtig ist, dass die ursprüngliche user-Ansicht unverändert bleibt und wie gewohnt verwendet werden kann.

Schritt 2: Kopien zusammenführen

Im nächsten Schritt wird die gesamte LookML aus der erweiterten Ansicht (user) in die erweiternde Ansicht (user_with_age_extensions) zusammengeführt. Es ist wichtig, die Art dieser Zusammenführung zu verstehen. Es handelt sich dabei einfach um eine Zusammenführung von LookML-Objekten. In der Praxis bedeutet das, dass alle explizit geschriebenen LookML-Werte zusammengeführt werden, die standardmäßigen LookML-Werte, die Sie nicht selbst eingegeben haben, werden nicht zusammengeführt. Es wird also nur der Text der LookML zusammengesetzt, nicht die Bedeutung dieses Textes.

Schritt 3: Konflikte beheben

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

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

Im Beispiel für user_with_age_extensions sind keine der Parameter additiv und es sind keine speziellen Listenoptionen oder sql-Keywords angegeben. Daher werden die Parameterwerte in der erweiterten Ansicht durch die Parameterwerte in der erweiterten Ansicht überschrieben:

  • Der Name der erweiterten Ansicht (user_with_age_extensions) überschreibt den Namen der erweiterten Ansicht (user).
  • Der Wert „extending“ (in der Ausweitung befindlich) für suggestions: no überschreibt den Wert „extended“ (ausgeweitet) suggestions: yes.
  • Die erweiterte Ansicht enthält eine Dimension namens age, die in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt).
  • Die erweiterte Ansicht enthält eine Dimension namens name, die in der erweiterten Ansicht nicht vorhanden ist (kein Konflikt).
  • Der Wert type: string der Dimension status in der erweiterten Ansicht ü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).

Es ist wichtig, dass Standard-LookML-Werte noch nicht berücksichtigt werden, da Sie sonst den Fehler machen könnten, zu glauben, dass Konflikte zwischen Standardwerten behoben werden. In Wirklichkeit werden sie in diesem Schritt einfach ignoriert. Deshalb müssen wir beim Erweitern von Objekten zusätzliche Parameter explizit hinzufügen:

In diesem Beispiel haben wir sql_table_name nicht der Ansicht Nutzer hinzugefügt. Dies führt im nächsten Schritt zu einigen Problemen.

Schritt 4: LookML wie gewohnt interpretieren

Im letzten Schritt wird die resultierende LookML wie gewohnt interpretiert, einschließlich aller Standardwerte. In diesem Beispiel wird die resultierende Looker-Ansichts-LookML 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-Datei 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 in unserer Datenbank wahrscheinlich keine Tabelle mit dem Namen user_with_age_extensions gibt. Deshalb müssen wir jeder Ansicht, die erweitert werden soll, einen sql_table_name-Parameter hinzufügen. Wenn Sie view_name und view_label zu Erkundungen hinzufügen, die erweitert werden sollen, lassen sich ähnliche Probleme vermeiden.

Kombination erweitert

Es gibt verschiedene Möglichkeiten, LookML-Objekte mit „extends“ zu verwenden:

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

Mehrere Objekte gleichzeitig verlängern

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

Die Erweiterung funktioniert genau wie im Implementierungsbeispiel beschrieben. Es gibt jedoch eine zusätzliche Regel für die Konfliktlösung. Bei Konflikten zwischen den im Parameter extends aufgeführten Elementen hat das zuletzt aufgeführte Element Vorrang. Wenn also im vorherigen Beispiel Konflikte zwischen user_info und marketing_info auftreten, wird die explorative Datenanalyse marketing_info verwendet.

Mehrere Extend-Elemente verketten

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

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

Auch hier funktioniert die Erweiterung genau wie im Implementierungsbeispiel beschrieben, mit einer zusätzlichen Regel zur Konfliktlösung. Bei Konflikten hat das letzte Element in der Erweiterungskette Vorrang. Für dieses Beispiel gilt Folgendes:

  • orders hat dann Vorrang vor user_info und marketing_info.
  • user_info hat Vorrang vor marketing_info.

Parameter kombinieren

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

In den folgenden Fällen werden Parameterwerte jedoch von Erweiterungen kombiniert, anstatt sie zu überschreiben:

Einige Parameter sind additiv

Wenn das erweiterte Objekt denselben Parameter wie das erweiterte Objekt enthält, werden in vielen Fällen die Werte des erweiterten Objekts über die Parameterwerte des erweiterten Objekts hinweggeschrieben. Für einige Parameter können Erweiterungen jedoch additiv sein, d. h., die Werte des erweiterten Objekts werden in Verbindung mit den Werten des erweiterten Objekts verwendet.

Die folgenden Parameter sind additiv:

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

Und hier ist die carriers_extended-Ansicht, die die carriers-Ansicht erweitert. Die carriers_extended-Ansicht enthält außerdem die Dimension name mit unterschiedlichen 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 carriers_extended-Ansicht sind die beiden link-Parameter additiv. Daher werden in der Dimension name beide Links angezeigt.

Zusätzliche Optionen mit Listen

Wenn Sie mit Listen arbeiten, können Sie sie kombinieren, anstatt dass die Liste des erweiterten Objekts als Gewinner ausgewählt wird. Betrachten Sie diese einfache Erweiterung mit einer Konfliktliste namens animals:

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

In diesem Fall wird die pets-Ansicht erweitert und sie gewinnt daher. animals enthält dann [dog, cat]. Mit dem speziellen Satz EXTENDED* können Sie die Listen jedoch 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].

Bei der Konfliktlösung kombinieren statt ersetzen

In den meisten Fällen gewinnt das Objekt, das erweitert wird, wenn es bei der Erweiterung zu Konflikten kommt. Betrachten wir beispielsweise 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 es einen Konflikt mit dem Parameter sql in der Dimension description gibt. Normalerweise überschreibt die Definition von product_short_descriptions einfach die Definition von products, da sie die Erweiterung vornimmt.

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 Parameters sql anders behandelt. Anstatt dass die Definition für product_short_descriptions verwendet wird, wird die Definition von products eingefügt, wo ${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 die Lokalisierungsregeln auch auf Ihre Erweiterungen angewendet werden. Wenn Sie ein Objekt erweitern und dann neue Labels oder Beschreibungen definieren, sollten Sie Lokalisierungsdefinitionen in den Gebietsschema-Zeichenfolgendateien Ihres Projekts angeben. Weitere Informationen finden Sie auf der Dokumentationsseite Ihr LookML-Modell lokalisieren.