Datengruppe

Nutzung

datagroup: datagroup_name {
max_cache_age: "24 Stunden"
sql_trigger: SELECT max(id) FROM my_tablename ;;
interval_trigger: "12 Stunden"
Beschreibung:
Hierarchie
datagroup
Standardwert
Keine

Akzeptiert
Eine Kennung für die Datengruppe sowie Unterparameter, mit denen die Eigenschaften der Datengruppe definiert werden.

Definition

Verwenden Sie datagroup, um eine Caching-Richtlinie für Erkundungen und/oder persistente abgeleitete Tabellen zuzuweisen. Wenn du für unterschiedliche Erkundungen und/oder PDTs unterschiedliche Caching-Richtlinien verwenden möchtest, verwende zum Festlegen der einzelnen Richtlinien einen separaten datagroup-Parameter.

Sie können der Datengruppe ein Label und eine Beschreibung 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, die verwendet werden kann, um den Zweck und den Mechanismus der Datengruppe zu erläutern. Weitere Informationen finden Sie im Abschnitt label und description auf dieser Seite.

Geben Sie die Details der Caching-Richtlinie mithilfe der Unterparameter datagroup 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 von Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker die Abfrage an die Datenbank, um neue 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, wird die Datengruppe in den Modus „Ausgelöst“ versetzt. Weitere Informationen finden Sie im Abschnitt sql_trigger auf dieser Seite.
  • interval_trigger: Gibt einen Zeitplan für das Auslösen der Gruppe an, z. B. "24 hours". Weitere Informationen finden Sie im Abschnitt interval_trigger auf dieser Seite.

Häufig ist die beste Lösung, 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 der Datenlast (ETL) in Ihrer Datenbank entspricht, und geben Sie dann einen max_cache_age-Wert an, der alte Daten ungültig macht, wenn Ihr ETL fehlschlägt. Der Parameter max_cache_age sorgt dafür, dass die Cache-Einträge mit einer bestimmten Zeit ablaufen, wenn der Cache für eine Datengruppe nicht von sql_trigger oder interval_trigger geleert wird. Auf diese Weise wird für eine Datengruppe der Fehlermodus verwendet, um die Datenbank abzufragen, anstatt veraltete Daten aus dem Looker-Cache bereitzustellen.

Eine Datengruppe kann nicht gleichzeitig die Parameter sql_trigger und interval_trigger enthalten. Wenn Sie eine Datengruppe mit beiden Parametern definieren, verwendet die Datengruppe den Wert interval_trigger und ignoriert den Wert sql_trigger, da der Parameter sql_trigger beim Abfragen der Datenbank Datenbankressourcen erfordert.

Für Verbindungen, die Nutzerattribute zum Angeben der Verbindungsparameter verwenden, müssen Sie eine separate Verbindung mit den PDT-Überschreibungsfeldern erstellen, wenn Sie eine Caching-Richtlinie für die Gruppe mit einem SQL-Abfragetrigger definieren möchten.

Ohne die PDT-Überschreibungen können Sie eine Datengruppe für das Modell und seine explorativen Datenanalysen verwenden, solange Sie die Caching-Richtlinie der Gruppe nur mit max_cache_age und nicht mit sql_trigger definieren.

max_cache_age

Der Parameter max_cache_age gibt einen String mit einer Ganzzahl an, gefolgt von „Sekunden“, „Minuten“ oder „Stunden“. Dieser Zeitraum ist der maximale Zeitraum für die im Cache gespeicherten Ergebnisse, die von „Erkunden“-Abfragen verwendet werden, die die Datengruppe verwenden.

Wenn das Alter des Cache einer Abfrage den Wert max_cache_age überschreitet, wird der Cache von Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker die Abfrage an die Datenbank, um neue Ergebnisse zu erhalten. Wenn das Alter des Cache einer Abfrage den Wert max_cache_age überschreitet, wird der Cache von Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker die Abfrage an die Datenbank, um neue Ergebnisse zu erhalten. Informationen dazu, wie lange Daten im Cache gespeichert werden, finden Sie auf der Dokumentationsseite Caching-Abfragen und Neuerstellung von PDTs mit Datengruppen.

Wenn die Funktion Instant Dashboards Looker Labs aktiviert ist, werden Abfragen, die über ein Dashboard ausgeführt werden, immer für die Datenbank ausgeführt; die Daten der vorherigen Ausführungen werden auf dem Dashboard angezeigt, bis die Abfrageergebnisse zurückgegeben werden (unabhängig vom Wert max_cache_age).

Der Parameter max_cache_age definiert nur, wenn der Cache entwertet wird. Er löst keine Neuerstellung von PDTs aus. Wenn Sie eine Datengruppe nur mit max_cache_age definieren, erhalten Sie eine LookML-Validierungswarnung, wenn der Datengruppe abgeleitete Tabellen zugewiesen sind. Wenn Sie einer abgeleiteten Tabelle nur eine abgeleitete Tabelle mit einem max_cache_age-Parameter zuweisen, wird die abgeleitete Tabelle beim ersten Abfragen der Tabelle erstellt. Die abgeleitete Tabelle befindet sich jedoch auf unbestimmte Zeit im Scratch-Schema und wird nicht neu erstellt, auch wenn sie noch einmal abgefragt wird. Wenn Sie in einem bestimmten Zeitraum eine PDT-Neuerstellung durchführen möchten, sollten Sie Ihrer Datengruppe einen interval_trigger-Parameter hinzufügen, um einen PDT-Neuerstellungszeitplan zu definieren.

sql_trigger

Verwenden Sie den Parameter sql_trigger, um eine SQL-Abfrage anzugeben, die genau eine Zeile mit einer Spalte zurückgibt. Looker führt die SQL-Abfrage in den Intervallen aus, die im Feld PDT und Datagroup-Wartungsplan der Datenbankverbindung angegeben sind. Wenn die Abfrage einen anderen Wert als das vorherige Ergebnis zurückgibt, wird die Datengruppe in den Modus „Ausgelöst“ versetzt. Nachdem die Datengruppe ausgelöst wurde, erstellt Looker alle PDTs neu, deren Datengruppe im Parameter datagroup_trigger angegeben ist. Nachdem die Neuerstellung der PDT abgeschlossen ist, wird die Datengruppe in den Status „Bereit“ versetzt und Looker entwertet die im Cache gespeicherten Ergebnisse aller explorativen Datenanalysen, die diese Datengruppe verwenden.

In der Regel gibt sql_trigger eine SQL-Abfrage an, die angibt, wann ein neuer Datenladevorgang (ETL) stattgefunden hat, z. B. durch Abfrage des max(ID) in einer Tabelle. Sie können auch sql_trigger verwenden, um eine bestimmte Tageszeit anzugeben. Fragen Sie dazu das aktuelle Datum ab und fügen Sie dem Zeitstempel bei Bedarf weitere Stunden hinzu, z. B. 4:00 Uhr.

Looker führt keine Zeitzonenkonvertierung für sql_trigger durch. Wenn Sie die Datengruppe zu einer bestimmten Tageszeit auslösen möchten, legen Sie den Trigger in der Zeitzone fest, für die Ihre Datenbank konfiguriert ist.

In diesen Beispielen aus dem Parameter sql_trigger finden Sie Ideen zum Einrichten von SQL-Abfragen zum Auslösen einer Datengruppe.

interval_trigger

Mit dem optionalen Unterparameter interval_trigger können Sie eine Dauer für die Neuerstellung festlegen. Im Parameter interval_trigger übergeben Sie einen String mit einer Ganzzahl, gefolgt von „Sekunden“, „Minuten“ oder „Stunden“.

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 mithilfe von Locale String-Dateien lokalisieren.

Diese Unterparameter werden auf der Seite Datengruppen im Bereich Datenbank des Steuerfelds Verwaltung angezeigt. Weitere Informationen zur Anzeige finden Sie auf der Dokumentationsseite Administratoreinstellungen – Anzeigengruppen.

Beispiele

Die folgenden Beispiele veranschaulichen die Anwendungsfälle von datagroup, darunter:

Erstellung einer Caching-Richtlinie zum Abrufen neuer Ergebnisse, wenn neue Daten verfügbar sind oder mindestens alle 24 Stunden

So erstellen Sie eine Caching-Richtlinie, die neue Ergebnisse abruft, wenn neue Daten verfügbar sind oder mindestens alle 24 Stunden:

  • Verwenden Sie die Datengruppe orders_datagroup (in der Modelldatei), um die Caching-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. Bei jeder Aktualisierung der Daten wird eine neue Zahl zurückgegeben.
  • Verwenden Sie die Einstellung max_cache_age, um Daten zu entwerten, wenn sie 24 Stunden lang im Cache gespeichert waren.
  • 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 Caching-Richtlinie orders_datagroup als Standard für „Erkunden“ 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 Caching-Richtlinie orders_datagroup für eine bestimmte Erkundung 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 die Standardeinstellung mit dem Parameter persist_with unter einem explore überschreiben.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Wenn Sie die Zwischenspeicherrichtlinie orders_datagroup für die Neuerstellung einer PDT verwenden möchten, können Sie datagroup_trigger unter dem Parameter derived_table hinzufügen und die orders_datagroup angeben:

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

Datengruppe erstellen, um Lieferungen am letzten Tag jedes Monats zu planen

Sie können einen Zeitplan erstellen, an dem am Ende jedes Monats eine Inhaltsübermittlung gesendet wird. Nicht alle Monate haben jedoch dieselbe Anzahl von Tagen. Sie können eine Datengruppe erstellen, um Inhaltsübermittlungen am Ende jedes Monats auszulösen – unabhängig von der Anzahl der Tage in einem bestimmten Monat.

  1. 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 Redshift-SQL und erfordert möglicherweise leichte Anpassungen für verschiedene Datenbanken.

Diese SQL-Anweisung gibt den Monat zurück, in dem sich morgen befindet. Am letzten Tag des Monats ist morgen der nächste Monat. Somit wird die Datengruppe ausgelöst. Für alle zwei Tage ist morgen im selben Monat, sodass die Datengruppe nicht ausgelöst wird.

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

Zeitpläne, die auf Datengruppen basieren, werden erst nach Abschluss der Neugenerierung für alle PDTs gesendet, die mit diesem Parameter in der Gruppe gespeichert wurden. So ist sichergestellt, dass Ihre Übermittlung die neuesten Daten enthält.

Datengruppe mit kaskadierenden PDTs verwenden

Bei persistenten kaskadierenden abgeleiteten Tabellen, bei denen auf eine nichtflüchtige abgeleitete Tabelle (PDT) in der Definition einer anderen verwiesen wird, können Sie eine Datengruppe verwenden, um eine Persistenzstrategie für die kaskadierende PDT-Kette anzugeben.

Dies ist beispielsweise ein Teil einer Modelldatei, die eine Datengruppe namens user_facts_etl und eine explorative Datenanalyse mit dem Namen user_stuff definiert. Die user_stuff-Ermittlung bleibt mit der user_facts_etl-Datengruppe bestehen:

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 {
    ...
  }
  ...
}

Die Funktion user_stuff Entdecken verbindet die Ansicht user_facts_pdt_1 mit der Ansicht user_facts_pdt_2. Beide Ansichten basieren auf PDTs, die die Datengruppe user_facts_etl als Persistenztrigger 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 sind einige der LookML-Dateien 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 verwenden, müssen Sie darauf achten, dass die PDTs keine inkompatiblen Caching-Richtlinien für Datengruppen haben.

Der Looker-Regenerator prüft den Status und initiiert Neuerstellungen dieser PDTs so:

  • Standardmäßig prüft der Regenerator von Looker alle fünf Minuten die sql_trigger-Abfrage der Datengruppe. Ihr Looker-Administrator kann dieses Intervall mit der Einstellung PDT und Datagroup-Wartungsplan in Ihrer Datenbankverbindung angeben.
  • Wenn sich der Wert, der von der sql_trigger-Abfrage zurückgegeben wird, vom Ergebnis der Abfrage aus der vorherigen Prüfung unterscheidet, wechselt die Datengruppe in den ausgelösten Status. Wenn in diesem Beispiel die Tabelle etl_jobs einen neuen ID-Wert hat, wird die Datengruppe user_facts_etl ausgelöst.

  • Nachdem die Datengruppe user_facts_etl ausgelöst wurde, erstellt der Looker alle PDTs, die die Datengruppe verwenden, neu (mit anderen Worten: Alle PDTs, die mit datagroup_trigger: user_facts_etl definiert sind). In diesem Beispiel erstellt der Regenerator user_facts_pdt_1 neu und erstellt dann user_facts_pdt_2.

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

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

  • Sobald sich die Datengruppe user_facts_etl nicht mehr im ausgelösten Zustand befindet, setzt Looker den Cache für alle Modelle und explorativen Datenanalysen zurück, die die Datengruppe user_facts_etl verwenden, d. h. alle Modelle und explorativen Datenanalysen, die mit persist_with: user_facts_etl definiert sind. In diesem Beispiel setzt Looker den Cache für die Analyse von user_stuff zurück.

  • Alle geplanten Inhaltsübermittlungen, die auf der Datengruppe user_facts_etl basieren, werden gesendet. Wenn es in diesem Beispiel eine geplante Bereitstellung mit einer Abfrage aus dem user_stuff-explorativen Analysetool gibt, wird die geplante Abfrage aus der Datenbank für aktuelle Ergebnisse abgerufen.

Datengruppen für mehrere Modelldateien freigeben

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

Wenn Sie Datengruppen mit mehreren 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 den Modelldateien include anzugeben.

Datengruppendatei erstellen

Erstellen Sie eine separate .lkml-Datei für Ihre Datengruppen. Das Erstellen einer .lkml-Datengruppendatei funktioniert auf dieselbe Weise wie eine separate .lkml Erkundungsdatei.

In diesem Beispiel heißt die Dateidatei datagroups.lkml:

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

Die Datengruppendatei in Ihre Modelldateien einbeziehen

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

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

Diese Datei heißt ecommerce.model.lkml. Die Datengruppe daily wird auf der Ebene explore verwendet, sodass sie nur für die Funktion orders Erkunden gilt:

include: "datagroups.model.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 explorativen Datenanalysen in der Modelldatei gilt:

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

explore: items {
}

explore: products {
}