Best Practice: Nachhaltige, wartbare LookML schreiben

Diese Best Practices spiegeln die Empfehlungen eines funktionsübergreifenden Teams erfahrener Lookers wider. Diese Erkenntnisse stammen aus jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden von der Implementierung bis zum langfristigen Erfolg. Diese Vorgehensweisen sind so formuliert, dass sie für die meisten Nutzer und Situationen geeignet sind. Bei der Umsetzung der Vorschläge auf dieser Seite solltest du jedoch nach bestem Wissen und Gewissen handeln.

Diese Seite enthält Empfehlungen zum Schreiben nachhaltiger, wartbarer LookMLs. Diese Empfehlungen werden in den folgenden Abschnitten ausführlicher beschrieben:

Substitutionsoperatoren verwenden

Substitutionsoperatoren sollten in allen LookML-Dateien verwendet werden. Ein LookML-Modell sollte nur einen Referenzpunkt zu einem 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, die Daten direkt aus den zugrunde liegenden Datenbankspalten abrufen. Wenn sich ein Schema- oder Tabellenname ändert, kann ein Entwickler das Schema oder den Tabellennamen an einer Stelle (innerhalb des sql_table_name-Parameters) aktualisieren und ihn über den Rest des Codes weitergeben.

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 Basismesswerte aktualisiert werden. Diese Änderung wird dann automatisch für alle anderen Felder übernommen, die auf die Spalte verweisen. Wenn sich beispielsweise ein Spaltenname in Ihrer Datenbank von usersid zu users_id ändert, müssen Sie den Verweis in Looker ändern. Wenn Sie ${field_name} verwenden, müssen Sie nur eine Zeile aktualisieren.

Wenn mehrere Dimensionen und Messwerte auf ein vorhandenes LookML-Feld mit ${TABLE}.field_name verweisen, sind viele Änderungen erforderlich. Sehen Sie sich beispielsweise die Messwerte this_week_count und this_month_count im folgenden LookML-Beispielcode 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 sql-Parameter verwenden, muss der sql-Parameter für alle drei Felder aktualisiert werden.

Mit dem Verweis ${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 Einsatzmöglichkeiten von Substitutionsoperatoren finden Sie auf der Dokumentationsseite SQL einbinden und auf LookML-Objekte verweisen.

Feldsätze definieren

Verwenden Sie Sätze, um wiederverwendbare Feldlisten innerhalb des Modells zu verwalten. Alle Listen von 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 diese Feldliste aktualisiert oder Feldverweise geändert werden können. Weitere Informationen zu Sätzen finden Sie auf der Dokumentationsseite für den Parameter set.

Wiederholten Code vermeiden

Stellen Sie sich LookML-Objekte als Bausteine vor. Mit dem Parameter extends können Sie Objekte auf verschiedene Weise kombinieren, ohne Code wiederholen zu müssen. Ausführliche Informationen und Beispiele zur Wiederverwendung von Code finden Sie auf der Dokumentationsseite Code mit Erweiterungen wiederverwenden. Weitere Beispiele finden Sie auf den Dokumentationsseiten zu den Parametern extends (für Datenansichten) und extends (für Explores) sowie im Communitybeitrag Joins mithilfe von Erweiterungen definieren.

Sie können die Einheitlichkeit in Explores wahren, indem Sie Code nicht an mehreren Stellen wiederholen. Weitere Ideen dazu finden Sie im Looker-Communitybeitrag zum Vermeiden von Inkonsistenzen in Explores.

Elemente wie Kartenebenen und Werteformate konsolidieren

Definieren Sie benutzerdefinierte Kartenebenen zentral in einer LookML-Datei mit dem Namen map_layers.lkml, die Sie anhand der Looker-Dokumentation zu Projektdateien erstellen können. Diese Datei kann dann bei Bedarf in die verschiedenen Modelle eingefügt 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 im Modell 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 einfügen, indem Sie den LookML-Code include: "map_layers.base.lkml" in die gewünschte Modelldatei einfügen.

Benutzerdefinierte Werteformate können zentral im Modell festgelegt werden. Legen Sie mit dem Parameter named_value_format beliebige benutzerdefinierte Formate im Modell fest und verweisen Sie dann mithilfe des Parameters value_format_name in Dimensionen und Kennzahlen darauf.

Entwicklungsrichtlinien erstellen

Definieren Sie Entwicklungsrichtlinien, um die Entwicklung und Skalierung eines LookML-Modells zu vereinfachen. Im Beitrag der Looker-Community zu den Beispielen für die LookML-Entwicklung finden Sie eine Schritt-für-Schritt-Anleitung für eine Liste mit Beispiel-Entwicklungsrichtlinien. 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 dem geschriebenen LookML Kontext hinzuzufügen
  • Dokumentation in Looker mit Markdown-Dateien erstellen