Diese Best Practices spiegeln die Empfehlungen eines interdisziplinären Teams erfahrener Looker wider. Diese Erkenntnisse stammen aus jahrelanger Erfahrung mit Looker-Kunden – von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so konzipiert, dass sie für die meisten Nutzer und Situationen geeignet sind. Wie immer sollten Sie jedoch Ihr Urteilsvermögen nutzen, wenn Sie die Vorschläge auf dieser Seite umsetzen.
Auf dieser Seite finden Sie Empfehlungen für die Erstellung nachhaltiger, wartungsfreundlicher LookML-Codes. Diese Empfehlungen werden in den folgenden Abschnitten genauer beschrieben:
- Substitutionsoperatoren verwenden
- Feldsätze definieren
- Codewiederholungen vermeiden
- Elemente wie Kartenebenen und Werteformate zusammenführen
- Entwicklungsrichtlinien erstellen
Substitutionsoperatoren verwenden
Substitutionsoperatoren sollten in allen LookML-Dateien verwendet werden. Ein LookML-Modell sollte nur einen einzigen Referenzpunkt auf ein Objekt im physischen Datenmodell haben. Alle nachfolgenden Definitionen, die auf dieses Objekt verweisen müssen, sollten auf das bereits definierte LookML-Objekt verweisen.
Verwenden Sie die Syntax ${TABLE}.field_name
, wenn Sie auf die zugrunde liegende Datenbanktabelle verweisen, für alle Basisdimensionen, bei denen Daten direkt aus den zugrunde liegenden Datenbankspalten abgerufen werden. Wenn sich ein Schema- oder Tabellenname ändert, können Entwickler den Schema- oder Tabellennamen an einer Stelle (im Parameter sql_table_name
) aktualisieren und die Änderung im Rest des Codes übernehmen lassen.
Verwenden Sie die Syntax ${field_name}
, wenn Sie auf Dimensionen oder Messwerte verweisen, die bereits in LookML definiert wurden. Wenn sich ein Spaltenname ändert, muss diese Änderung nur im Parameter sql
der Basisdimension oder der Messwerte aktualisiert werden. Diese Änderung wird dann automatisch auf alle anderen Felder angewendet, die auf die Spalte verweisen. Wenn sich beispielsweise der Name einer Spalte in Ihrer Datenbank von usersid
in users_id
ändert, müssen Sie die Referenz in Looker ändern. Bei Verwendung von ${field_name}
müssen Sie nur eine Zeile aktualisieren.
Wenn mehrere Dimensionen und Messwerte mit ${TABLE}.field_name
auf ein vorhandenes LookML-Feld verweisen, sind viele Änderungen erforderlich. Sehen wir uns beispielsweise die Messwerte this_week_count
und this_month_count
im folgenden LookML-Codebeispiel an:
dimension: usersid { type: number sql: ${TABLE}.usersid ;; # Change here } measure: this_week_count { type: count_distinct sql: ${TABLE}.usersid ;; # Change here filters: [created_date: "7 days"] } measure: this_month_count { type: count_distinct sql: ${TABLE}.usersid ;; # Change here filters: [created_date: "1 month"] }
Da sowohl this_week_count
als auch this_month_count
die Syntax ${TABLE}.usersid
im Parameter sql
verwenden, muss der Parameter sql
für alle drei Felder aktualisiert werden.
Bei der Referenz ${field_name}
ist nur eine Änderung erforderlich:
dimension: usersid { type: number sql: ${TABLE}.usersid ;; # Change here } measure: this_week_count { type: count_distinct sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid` filters: [created_date: "7 days"] } measure: this_month_count { type: count_distinct sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid` filters: [created_date: "1 month"] }
Weitere Verwendungsmöglichkeiten von Substitutionsoperatoren finden Sie auf der Dokumentationsseite SQL-Einbindung und Verweise auf LookML-Objekte.
Feldsätze definieren
Verwenden Sie Sätze zum Verwalten wiederverwendbarer Feldlisten im Modell. Alle Listen mit Feldern, die wiederholt werden, sei es mit dem Parameter fields
oder in Aufschlüsselungsfeldern, sollten in Sätze aufgenommen werden, um einen zentralen Ort im Modell zu erstellen, an dem die Feldliste aktualisiert oder Feldverweise geändert werden kann. Weitere Informationen zu Gruppen finden Sie auf der Dokumentationsseite für den Parameter set
.
Codewiederholung vermeiden
Betrachten Sie LookML-Objekte als Bausteine und verwenden Sie den Parameter extends
, um Objekte auf unterschiedliche Weise zu kombinieren, ohne Code zu wiederholen. Ausführliche Informationen und Beispiele zur Codewiederverwendung finden Sie auf der Dokumentationsseite Code mit „extends“ wiederverwenden. Weitere Beispiele finden Sie auf den Dokumentationsseiten zu den Parametern extends
(für Aufrufe) und extends
(für Explores) sowie im Communitybeitrag Erweiterungen zum Definieren von Joins verwenden.
Achten Sie darauf, Code nicht an mehreren Stellen zu wiederholen, damit die explorativen Datenanalysen einheitlich sind. Weitere Vorschläge dazu finden Sie im Looker-Communitybeitrag zum Vermeiden von Inkonsistenzen in Explores.
Elemente wie Kartenebenen und Werteformate zusammenführen
Definieren Sie benutzerdefinierte Kartenebenen zentral in einer LookML-Datei namens map_layers.lkml
. Eine solche Datei können Sie anhand der Looker-Dokumentation zu Projektdateien erstellen. Diese Datei kann dann nach Bedarf in alle Modelle aufgenommen werden. Alternativ können Sie JSON-Dateien direkt dem Repository hinzufügen, indem Sie Datendateien per Drag-and-drop in Ihr LookML-Projekt ziehen und dort darauf verweisen.
Angenommen, Sie haben eine Kartenebenendatei namens map_layers.base.lkml
, die den folgenden LookML-Code enthält:
map_layer: example_africa { file: "africa_file_name.json" property_key: "geounit" } map_layer: example_asia { file: "asia_file_name.json" property_key: "geounit" } map_layer: example_europe { file: "europe_file_name.json" property_key: "geounit" }
Sie können die Kartenebenendatei map_layers.base.lkml
in jedes Modell im Projekt einbinden. Dazu fügen Sie der gewünschten Modelldatei den LookML-Code include: "map_layers.base.lkml"
hinzu.
Sie können alle benutzerdefinierten Wertformate zentral im Modell festlegen. Verwenden Sie den Parameter named_value_format
, um benutzerdefinierte Formate im Modell festzulegen, und verweisen Sie dann mit dem Parameter value_format_name
in Dimensionen und Messwerten darauf.
Entwicklungsrichtlinien erstellen
Definieren Sie Entwicklungsrichtlinien, die das Entwickeln und Skalieren eines LookML-Modells erleichtern. Im Looker-Communitybeitrag zu den Beispiel-Entwicklungsrichtlinien für LookML finden Sie eine Schritt-für-Schritt-Anleitung mit einer Liste mit Beispielentwicklungsrichtlinien. Zu den allgemeinen Richtlinien gehören Anforderungen für:
- Klare Strukturierung von LookML-Dateien, sodass sie einheitlich und einfach zu navigieren sind
- Kommentare in den Ansichten und Modellen verwenden, um der geschriebenen LookML Kontext hinzuzufügen
- Dokumentation in Looker mithilfe von Markdown-Dateien erstellen