Datengruppe

Nutzung

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}
Hierarchie
datagroup
Standardwert
Keine

Akzeptiert
Eine Kennung für Ihre Datengruppe sowie untergeordnete Parameter, die die Eigenschaften Ihrer Datengruppe definieren.

Definition

Verwenden Sie datagroup, um eine Caching-Richtlinie für Explores zuzuweisen und/oder eine Persistenzstrategie für persistente abgeleitete Tabellen (PDTs) anzugeben. Wenn Sie mehrere Richtlinien für verschiedene Explores und PDTs verwenden möchten, geben Sie jede Richtlinie mit einem separaten datagroup-Parameter an.

Geben Sie einen eindeutigen Namen für die Datengruppe an, der nur Buchstaben, Ziffern und Unterstriche enthält. Andere Zeichen sind nicht zulässig.

Sie können ein Label und eine Beschreibung für die Datengruppe hinzufügen:

  • label: Gibt ein optionales Label für die Datengruppe an. Weitere Informationen finden Sie im Abschnitt label und description auf dieser Seite.
  • description: Gibt eine optionale Beschreibung für die Datengruppe an, mit der der Zweck und Mechanismus der Datengruppe erläutert werden kann. Weitere Informationen finden Sie im Abschnitt label und description auf dieser Seite.

Geben Sie die Details der Richtlinie für Zwischenspeicherung und Persistenz mit den datagroup-Unterparametern an:

  • max_cache_age: Gibt einen String an, der einen Zeitraum definiert. Wenn das Alter des Cache einer Abfrage den Zeitraum überschreitet, wird der Cache in Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker sie an die Datenbank, um aktuelle Ergebnisse zu erhalten. Weitere Informationen finden Sie im Abschnitt max_cache_age auf dieser Seite.
  • sql_trigger: Gibt eine SQL-Abfrage an, die eine Zeile mit einer Spalte zurückgibt. Wenn sich der von der Abfrage zurückgegebene Wert von den vorherigen Ergebnissen der Abfrage unterscheidet, wechselt die Datengruppe in den Status „Ausgelöst“. Weitere Informationen finden Sie im Abschnitt sql_trigger auf dieser Seite.
  • interval_trigger: Gibt einen Zeitplan für das Auslösen der Datengruppe an, z. B. "24 hours". Weitere Informationen finden Sie im Abschnitt interval_trigger auf dieser Seite.

Oft ist es am besten, max_cache_age in Kombination mit sql_trigger oder interval_trigger zu verwenden. Geben Sie entweder einen sql_trigger- oder einen interval_trigger-Wert an, der dem Datenladevorgang (ETL) in Ihre Datenbank entspricht. Geben Sie dann einen max_cache_age-Wert an, mit dem alte Daten ungültig werden, wenn Ihr ETL-Vorgang fehlschlägt. Der Parameter max_cache_age sorgt dafür, dass die Cache-Einträge nach einer bestimmten Zeit ablaufen, wenn der Cache für eine Datengruppe nicht durch sql_trigger oder interval_trigger geleert wird. So wird bei einem Fehler in einer Datengruppe die Datenbank abgefragt, anstatt veraltete Daten aus dem Looker-Cache zu verwenden.

Eine Datengruppe kann nicht sowohl sql_trigger- als auch interval_trigger-Parameter enthalten. Wenn Sie eine Datengruppe mit beiden Parametern definieren, wird der interval_trigger-Wert verwendet und der sql_trigger-Wert ignoriert, da für den Parameter sql_trigger Datenbankressourcen erforderlich sind, wenn die Datenbank abgefragt wird.

Bei Verbindungen, bei denen Nutzerattribute zum Angeben der Verbindungsparameter verwendet werden, müssen Sie eine separate Verbindung mit den PDT-Überschreibungsfeldern erstellen, wenn Sie eine Datengruppen-Caching-Richtlinie mit einem SQL-Abfrage-Trigger definieren möchten.

Auch ohne die PDT-Überschreibungen können Sie eine Datengruppe für das Modell und die zugehörigen Explores verwenden, sofern Sie die Caching-Richtlinie der Datengruppe nur mit max_cache_age und nicht mit sql_trigger definieren.

max_cache_age

Mit dem Parameter max_cache_age wird ein String angegeben, der eine Ganzzahl gefolgt von „seconds“, „minutes“ oder „hours“ enthält. Dieser Zeitraum ist der maximale Zeitraum, in dem die im Cache gespeicherten Ergebnisse für Explore-Abfragen verwendet werden, die die Datengruppe verwenden.

Wenn das Alter des Cache einer Abfrage den Wert von max_cache_age überschreitet, wird der Cache in Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker sie an die Datenbank, um aktuelle Ergebnisse zu erhalten. Informationen dazu, wie lange Daten im Cache gespeichert werden, finden Sie auf der Dokumentationsseite Abfragen im Cache speichern.

Der Parameter max_cache_age definiert nur, wann der Cache ungültig gemacht wird. Er löst nicht die Neuerstellung von PDTs aus. Wenn Sie eine Datengruppe nur mit max_cache_age definieren, erhalten Sie eine LookML-Validierungswarnung, wenn abgeleitete Tabellen der Datengruppe zugewiesen sind. Wenn Sie eine abgeleitete Tabelle einer Datengruppe mit nur einem max_cache_age-Parameter zuweisen, wird die abgeleitete Tabelle erstellt, wenn sie zum ersten Mal abgefragt wird. Sie verbleibt jedoch auf unbestimmte Zeit im Scratch-Schema und wird nie neu erstellt, auch wenn sie noch einmal abgefragt wird. Wenn Sie möchten, dass eine PDT in einem bestimmten Zeitintervall neu erstellt wird, sollten Sie Ihrer Datengruppe den Parameter interval_trigger hinzufügen, um einen Zeitplan für die Neuerstellung von PDTs zu definieren.

sql_trigger

Mit dem Parameter sql_trigger geben Sie eine SQL-Abfrage an, die genau eine Zeile mit einer Spalte zurückgibt. Looker führt die SQL-Abfrage in Intervallen aus, die im Feld Datagroup and PDT Maintenance Schedule der Datenbankverbindung angegeben sind. Wenn die Abfrage einen anderen Wert als das vorherige Ergebnis zurückgibt, wechselt die Datengruppe in den Status „Ausgelöst“. Nach Auslösen der Datengruppe erstellt Looker alle PDTs neu, für die diese Datengruppe im Parameter datagroup_trigger angegeben ist. Nachdem die Neuerstellung der PDT abgeschlossen ist, wechselt die Datengruppe in den Status „Bereit“ und Looker macht die im Cache gespeicherten Ergebnisse aller Explores, die diese Datengruppe verwenden, ungültig.

Normalerweise wird mit sql_trigger eine SQL-Abfrage angegeben, die angibt, wann ein neuer Datenladevorgang (ETL) stattgefunden hat, z. B. durch Abfragen von max(ID) in einer Tabelle. Sie können auch sql_trigger verwenden, um eine bestimmte Uhrzeit anzugeben. Dazu fragen Sie das aktuelle Datum ab und fügen dem Zeitstempel bei Bedarf zusätzliche Stunden hinzu, um die gewünschte Uhrzeit zu erreichen, z. B. 4:00 Uhr.

Beachten Sie die folgenden wichtigen Punkte zu sql_trigger:

  • Sie können sql_trigger nicht verwenden, wenn für Ihre Datenbankverbindung OAuth oder Nutzerattribute verwendet werden und Sie PATs für die Verbindung deaktiviert haben. Das liegt daran, dass Looker statische Anmeldedaten benötigt, um auf Ihre Datenbank zuzugreifen und die im Parameter sql_trigger angegebene Abfrage auszuführen. Wenn PDTs aktiviert sind, können Sie die Felder PDT Overrides verwenden, um Looker separate, statische Anmeldedaten für PDT-Prozesse zur Verfügung zu stellen, auch wenn für Ihre Verbindung dynamische Anmeldedaten wie OAuth oder Nutzerattribute verwendet werden. Wenn PDTs deaktiviert sind und für Ihre Verbindung OAuth oder Nutzerattribute verwendet werden, können Sie Looker nicht die statischen Nutzeranmeldedaten zur Verfügung stellen, die für sql_trigger-Abfragen erforderlich sind.
  • In Looker wird keine Zeitzonenumwandlung für sql_trigger durchgeführt. Wenn Sie Ihre Datengruppe zu einer bestimmten Tageszeit auslösen möchten, legen Sie den Trigger in der Zeitzone fest, für die Ihre Datenbank konfiguriert ist.

Beispiele aus der Dokumentation zum Parameter sql_trigger

interval_trigger

Mit dem optionalen Unterparameter interval_trigger können Sie eine Zeitdauer für die Neuerstellung angeben. Im Parameter interval_trigger übergeben Sie einen String mit einer Ganzzahl, gefolgt von „seconds“, „minutes“ oder „hours“.

label und description

Mit den optionalen Unterparametern label und description können Sie ein benutzerdefiniertes Label und eine Beschreibung der Datengruppe hinzufügen. Sie können diese Unterparameter auch mit Gebietsschema-String-Dateien lokalisieren.

Diese Unterparameter werden im Bereich Datenbank des Admin-Bereichs auf der Seite Datengruppen angezeigt. Weitere Informationen zur Darstellung finden Sie auf der Dokumentationsseite Administratoreinstellungen – Datengruppen.

Beispiele

Die folgenden Beispiele veranschaulichen die Anwendungsfälle von datagroup:

Eine Caching-Richtlinie erstellen, um neue Ergebnisse abzurufen, wenn neue Daten verfügbar sind oder mindestens alle 24 Stunden

So erstellen Sie eine Caching-Richtlinie, mit der neue Ergebnisse abgerufen werden, wenn neue Daten verfügbar sind oder mindestens alle 24 Stunden:

  • Verwenden Sie die Datengruppe orders_datagroup (in der Modelldatei), um die Cache-Richtlinie zu benennen.
  • Verwenden Sie den Parameter sql_trigger, um die Abfrage anzugeben, die angibt, dass neue Daten vorhanden sind: select max(id) from my_tablename. Immer wenn die Daten aktualisiert wurden, gibt diese Abfrage eine neue Zahl zurück.
  • Mit der Einstellung max_cache_age können Sie die Daten ungültig machen, wenn sie 24 Stunden lang im Cache gespeichert wurden.
  • Mit den optionalen Parametern label und description können Sie ein benutzerdefiniertes Label und eine Beschreibung der Datengruppe hinzufügen.
datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

Wenn Sie die orders_datagroup-Cache-Richtlinie als Standard für Explores in einem Modell verwenden möchten, verwenden Sie den Parameter persist_with auf Modellebene und geben Sie orders_datagroup an:

persist_with: orders_datagroup

Wenn Sie die orders_datagroup-Richtlinie für die Zwischenspeicherung für ein bestimmtes Explore verwenden möchten, fügen Sie den Parameter persist_with unter dem Parameter explore hinzu und geben Sie orders_datagroup an. Wenn auf Modellebene eine Standarddatengruppe angegeben ist, können Sie den Parameter persist_with unter einem explore verwenden, um die Standardeinstellung zu überschreiben.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Wenn Sie die orders_datagroup-Datengruppenrichtlinie für die Zwischenspeicherung zum Neuerstellen einer PDT verwenden möchten, können Sie datagroup_trigger unter dem Parameter derived_table hinzufügen und orders_datagroup angeben:

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

Datengruppe erstellen, um die Bereitstellung am letzten Tag jedes Monats zu planen

Möglicherweise möchten Sie einen Zeitplan erstellen, mit dem am Ende jedes Monats eine Inhaltsbereitstellung gesendet wird. Allerdings haben nicht alle Monate die gleiche Anzahl von Tagen. Sie können eine Datengruppe erstellen, um die Bereitstellung von Inhalten am Ende jedes Monats auszulösen – unabhängig von der Anzahl der Tage in einem bestimmten Monat.

  1. So erstellen Sie eine Datengruppe mit einer SQL-Anweisung, die am Ende jedes Monats ausgelöst wird:

    datagroup: month_end_datagroup {
sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
description: "Triggered on the last day of each month"
}

    Dieses Beispiel ist in Redshift SQL geschrieben und muss für andere Datenbanken möglicherweise leicht angepasst werden.

    Diese SQL-Anweisung gibt den Monat zurück, in dem der morgige Tag liegt. Am letzten Tag des Monats ist der morgige Tag der nächste Monat. Die Datengruppe wird also ausgelöst. An allen anderen Tagen ist „morgen“ im selben Monat, sodass die Datengruppe nicht ausgelöst wird.

  2. Wählen Sie die Datengruppe in einem neuen oder vorhandenen Zeitplan aus.

Bei auf Datengruppen basierenden Zeitplänen erfolgt der Versand erst, nachdem der Regenerierungsprozess für alle PDTs abgeschlossen ist, die über diesen Datengruppenparameter persistent gemacht wurden. Dadurch wird sichergestellt, dass die Lieferung aktuelle Daten enthält.

Datengruppe mit kaskadierenden PDTs verwenden

Bei persistenten kaskadierenden abgeleiteten Tabellen, bei denen in der Definition einer persistenten abgeleiteten Tabelle (PAT) auf eine andere verwiesen wird, können Sie mit einer Datengruppe eine Persistenzstrategie für die Kette kaskadierender PATs angeben.

Das folgende Beispiel zeigt einen Teil einer Modelldatei, in der eine Datengruppe namens user_facts_etl und ein Explore namens user_stuff definiert sind. Das user_stuff-Explore wird mit der user_facts_etl-Datengruppe beibehalten:

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

Im user_stuff-Explore wird die Ansicht user_facts_pdt_1 mit der Ansicht user_facts_pdt_2 verknüpft. Beide Ansichten basieren auf PDTs, die die Datengruppe user_facts_etl als Persistenz-Trigger verwenden. Die abgeleitete Tabelle user_facts_pdt_2 verweist auf die abgeleitete Tabelle user_facts_pdt_1. Es handelt sich also um kaskadierende PDTs. Hier ist ein Teil des LookML aus den Ansichtsdateien für diese PDTs:

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

Wenn Sie kaskadierende PDTs haben, müssen Sie darauf achten, dass die PDTs keine inkompatiblen Datengruppen-Caching-Richtlinien haben.

Der Looker-Regenerator prüft den Status und löst Neuerstellungen dieser PDTs so aus:

  • Standardmäßig prüft der Regenerator von Looker die sql_trigger-Abfrage der Datengruppe alle fünf Minuten. Ihr Looker-Administrator kann dieses Intervall mit der Einstellung Wartungszeitplan für Datengruppen und PDTs für Ihre Datenbankverbindung festlegen.
  • Wenn sich der von der sql_trigger-Abfrage zurückgegebene Wert vom Ergebnis der Abfrage bei der vorherigen Prüfung unterscheidet, wechselt die Datengruppe in den ausgelösten Status. Wenn die Tabelle etl_jobs in diesem Beispiel einen neuen ID-Wert enthält, wird die Datengruppe user_facts_etl ausgelöst.

  • Wenn die Datengruppe user_facts_etl ausgelöst wird, erstellt der Looker-Regenerator alle PDTs neu, die die Datengruppe verwenden, d. h. alle PDTs, die mit datagroup_trigger: user_facts_etl definiert sind. In diesem Beispiel erstellt der Regenerator zuerst user_facts_pdt_1 und dann user_facts_pdt_2 neu.

    Wenn PDTs denselben datagroup_trigger verwenden, erstellt der Regenerator die PDTs in der Reihenfolge der Abhängigkeit neu. Dabei werden zuerst Tabellen erstellt, auf die von anderen Tabellen verwiesen wird. Weitere Informationen dazu, wie Looker kaskadierende abgeleitete Tabellen neu erstellt, finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

  • Wenn der Regenerator alle PDTs in der Datengruppe neu erstellt, wird die Datengruppe user_facts_etl aus dem ausgelösten Zustand entfernt.

  • Sobald sich die Datengruppe user_facts_etl nicht mehr im ausgelösten Status befindet, setzt Looker den Cache für alle Modelle und Explores zurück, die die Datengruppe user_facts_etl verwenden, d. h. alle Modelle und Explores, die mit persist_with: user_facts_etl definiert sind. In diesem Beispiel bedeutet das, dass Looker den Cache für das Explore user_stuff zurücksetzt.

  • Alle geplanten Content-Auslieferungen, die auf der Datengruppe user_facts_etl basieren, werden gesendet. Wenn es in diesem Beispiel eine geplante Zustellung mit einer Abfrage aus dem Explore user_stuff gibt, wird die geplante Abfrage aus der Datenbank abgerufen, um aktuelle Ergebnisse zu erhalten.

Datengruppen in mehreren Modelldateien freigeben

In diesem Beispiel wird gezeigt, wie Sie Datengruppen für mehrere Modelldateien freigeben. Dieser Ansatz hat den Vorteil, dass Sie eine Datengruppe nur an einer Stelle bearbeiten müssen, damit sich die Änderungen auf alle Ihre Modelle auswirken.

Wenn Sie Datengruppen für mehrere Modelldateien freigeben möchten, erstellen Sie zuerst eine separate Datei, die nur die Datengruppen enthält, und verwenden Sie dann den Parameter include, um die Datengruppendatei in Ihren Modelldateien zu include.

Datengruppendatei erstellen

Erstellen Sie eine separate .lkml-Datei für Ihre Datengruppen. Sie können eine .lkml-Datengruppendatei auf dieselbe Weise erstellen wie eine separate .lkml-Explore-Datei.

In diesem Beispiel heißt die Datei mit den Datengruppen datagroups.lkml:

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

Datengruppendatei in Ihre Modelldateien einfügen

Nachdem Sie die Datengruppendatei erstellt haben, können Sie sie in beiden Modellen include und persist_with verwenden, um die Datengruppe entweder auf einzelne Explores in Ihren Modellen oder auf alle Explores in einem Modell anzuwenden.

Die folgenden beiden Modelldateien include beispielsweise beide die Datei datagroups.lkml.

Diese Datei heißt ecommerce.model.lkml. Die Datengruppe daily wird auf der Ebene explore verwendet, damit sie nur für den Explore orders gilt:

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

Die nächste Datei heißt inventory.model.lkml. Die Datengruppe daily wird auf der Ebene model verwendet, damit sie für alle Explores in der Modelldatei gilt:

include: "datagroups.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}