Best Practice: Best Practices 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 mit Looker-Kunden – von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so formuliert, dass sie für die meisten Nutzer und Situationen funktionieren. Entscheiden Sie sich aber wie immer für die Umsetzung der Empfehlungen auf dieser Seite.

LookML-Tipps

• Richtig: Definieren Sie den Parameter relationship für alle Joins.
  Dadurch wird sichergestellt, dass die Metriken ordnungsgemäß in Looker 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 mit den Best Practices unter Richtigen relationship-Parameters finden.
• Richtig: Definieren Sie in jeder Ansicht einen Primärschlüssel, einschließlich abgeleiteter Tabellen.
  Alle Ansichten, unabhängig davon, ob sie abgeleitet wurden oder direkt aus der Datenbank stammen, sollten einen Primärschlüssel enthalten. Dieser Primärschlüssel sollte ein eindeutiger Wert sein, damit Looker einen bestimmten Eintrag eindeutig identifizieren kann. Dieser Primärschlüssel kann eine einzelne Spalte oder eine Verkettung von Spalten sein. Er muss lediglich eine eindeutige Kennzeichnung 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 als Leerzeichen.
  Der label-Parameter kann für eine zusätzliche Formatierung eines Namensfelds sowie zum Anpassen der Darstellung von Ansichtsnamen, Explore-Namen und Modellnamen verwendet werden. Im folgenden LookML-Code wird beispielsweise der Parameter label verwendet, um dem Messwert customer_count_distinct das Label Anzahl der Kunden zuzuweisen.

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

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

Das ist bei LookML nicht zulässig

• Falsch: Verwenden Sie den Parameter from, um Ansichten innerhalb eines Explores 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 den folgenden Situationen verwendet werden:
  • Polymorphe Joins (mehrfache Verknüpfung derselben Tabelle)
  • Self-Joins (die Verknüpfung einer Tabelle mit sich selbst)
  • Geltungsbereich einer erweiterten Ansicht wieder auf ihren ursprünglichen Ansichtsnamen zurücksetzen
• Falsch: das Wort „Datum“ verwenden oder „Uhrzeit“ in den Namen einer Dimensionsgruppe ein.
  Looker hängt jeden Zeitrahmen an das Ende des Dimensionsgruppennamens an. Das bedeutet, dass eine Dimensionsgruppe mit dem Namen created_date zu Feldern mit den Namen created_date_date, created_date_month usw. führt. Verwenden Sie einfach created als Namen für die Dimensionsgruppe, da dies zu Feldern mit den Namen created_date, created_month usw. führt.
• Falsch: Verwenden Sie in Joins formatierte Zeitstempel.
  Verwenden Sie stattdessen die Option Rohzeitraum, um beliebige Datums- oder Uhrzeitfelder zusammenzuführen. Dadurch wird vermieden, dass Streaming und Zeitzonenkonvertierung in Join-Prädikate einbezogen werden.