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-DOS

• Empfohlen: Definieren Sie den Parameter relationship für alle Zusammenführungen.
  So werden die Messwerte in Looker korrekt zusammengefasst. In Looker wird standardmäßig eine many_to_one-Join-Beziehung für alle Joins verwendet, für die keine Beziehung definiert ist. Weitere Informationen zur korrekten Definition des relationship-Parameters finden Sie auf der Seite mit Best Practices zum richtigen Festlegen des relationship-Parameters.
• 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 jeden Datensatz 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.
• Empfohlen: Verwenden Sie für Dimensionen, Messwerte und andere LookML-Objekte ausschließlich Kleinbuchstaben und Unterstriche für 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} ;;
        }

• Empfohlen: Verwenden Sie Datengruppen, um die Generierung von persistenten abgeleiteten Tabellen (PDTs) und das Explore-Caching mit den zugrunde liegenden ETL-Prozessen abzugleichen. Mit Datengruppen können Sie auch die Übermittlung von Dashboards oder Looks auslösen, damit Empfänger immer aktuelle Daten erhalten.

Das ist bei LookML nicht zulässig

• Nicht: Verwenden Sie den Parameter from nicht zum Umbenennen von Ansichten in einem Explore.
  Verwenden Sie stattdessen den Parameter view_label. Weitere Informationen zum Unterschied zwischen from und view_label finden Sie auf der Seite mit der Parameterdokumentation from (für Explores). Der Parameter from sollte hauptsächlich in den folgenden Fällen verwendet werden:
  • Polymorphe Joins (mehrfache Verknüpfung derselben Tabelle)
  • Self-Joins (die Verknüpfung einer Tabelle mit sich selbst)
  • Eine erweiterte Ansicht auf den ursprünglichen Ansichtsnamen zurücksetzen
• Falsch: das Wort „Datum“ verwenden oder „Uhrzeit“ in den Namen einer Dimensionsgruppe ein.
  In Looker wird jeder Zeitraum an den Namen der Dimensionsgruppe angehängt. 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.
• Nicht: Verwenden Sie keine formatierten Zeitstempel in Joins.
  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.