Best Practice: Empfohlene und zu vermeidende Vorgehensweisen für LookML

Diese Best Practices spiegeln Empfehlungen wider, die von einem funktionsübergreifenden Team erfahrener Lookers geteilt wurden. Diese Erkenntnisse stammen aus jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden von der Implementierung bis zum langfristigen Erfolg. Die beschriebenen Vorgehensweisen sind so formuliert, dass sie für die meisten Nutzer und Situationen geeignet sind. Bei der Umsetzung der auf dieser Seite genannten Empfehlungen sollten Sie jedoch nach eigenem Ermessen vorgehen.

LookML – Dos

• Richtig: Definieren Sie den Parameter relationship für alle Joins.
  So wird sichergestellt, dass Messwerte in Looker korrekt aggregiert werden. Standardmäßig verwendet Looker eine many_to_one-Join-Beziehung für alle Joins, in denen keine Beziehung definiert ist. Weitere Informationen zur korrekten Definition des relationship-Parameters finden Sie auf der Seite Best Practices zur richtigen Verwendung des relationship-Parameters.
• Richtig: Definieren Sie in jeder Ansicht, einschließlich abgeleiteter Tabellen, einen Primärschlüssel.
  Alle Ansichten, ob sie abgeleitet sind oder direkt aus der Datenbank stammen, sollten einen Primärschlüssel enthalten. Dieser Primärschlüssel muss ein eindeutiger Wert sein, damit Looker einzelne Datensätze eindeutig identifizieren kann. Dieser Primärschlüssel kann eine einzelne Spalte oder eine Verkettung von Spalten sein. Er muss lediglich eine eindeutige Kennung für die Tabelle oder abgeleitete Tabelle sein.
• Richtig: Benennen Sie Dimensionen, Messwerte und andere LookML-Objekte und verwenden Sie dabei nur Kleinbuchstaben und Unterstriche für Leerzeichen.
  Mit dem Parameter label lässt sich das Namensfeld zusätzlich formatieren. Außerdem lässt sich damit die Darstellung von Ansichtsnamen, Explore-Namen und Modellnamen anpassen. In der folgenden LookML wird der Parameter label beispielsweise verwendet, um dem Messwert customer_count_distinct das Label Anzahl Kunden zuzuweisen.

        measure: customer_count_distinct {
          label: "Number of Customers"
          type: count_distinct
          sql: ${customer.id} ;;
        }

• Richtig: Verwenden Sie Datengruppen, um die Generierung von nichtflüchtigen abgeleiteten Tabellen (PDTs) abzustimmen, und untersuchen Sie das Caching mit zugrunde liegenden ETL-Prozessen. Datengruppen können auch verwendet werden, um die Bereitstellung von Dashboards oder Looks auszulösen, damit aktuelle Daten an die Empfänger gesendet werden.

Zu vermeidende Vorgehensweisen in LookML

• Falsch: Verwenden Sie den Parameter from, um Ansichten in einem Explore umzubenennen.
  Verwenden Sie stattdessen den Parameter view_label. Weitere Informationen zum Unterschied zwischen from und view_label finden Sie auf der Dokumentationsseite zum Parameter from (für Explores). Der Parameter from sollte hauptsächlich in folgenden Situationen verwendet werden:
  • Polymorphe Joins (mehrfache Verknüpfung derselben Tabelle)
  • Self-Joins, mit denen eine Tabelle mit sich selbst verknüpft wird
  • Zuweisen einer erweiterten Ansicht zurück zu ihrem ursprünglichen Namen
• Falsch: Verwenden Sie das Wort „Datum“ oder „Uhrzeit“ im Namen einer Dimensionsgruppe.
  Looker hängt jeden Zeitraum an das Ende des Dimensionsgruppennamens an. Das bedeutet, dass eine Dimensionsgruppe namens created_date zu Feldern mit dem Namen created_date_date, created_date_month usw. führt. Verwenden Sie einfach created als Dimensionsgruppennamen, da dadurch Felder mit dem Namen created_date, created_month usw. erzeugt werden.
• Falsch: Verwenden Sie in Joins formatierte Zeitstempel.
  Verwenden Sie stattdessen die Option unverarbeiteter Zeitraum, um Daten in beliebigen Datums- oder Uhrzeitfeldern zusammenzuführen. Dadurch wird verhindert, dass die Umwandlung und die Zeitzonenkonvertierung in Join-Prädikate eingeschlossen werden.