Best Practice: Nachhaltige, wartbare LookML schreiben

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

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