Best Practices für den Workflow-Lebenszyklus

In diesem Dokument werden Best Practices für die Verwaltung des Workflow-Lebenszyklus in Dataform beschrieben: Erstellen von Entwicklungs-, Staging- und Produktionsumgebungen sowie Konfigurieren von Kompilierungs- und Ausführungseinstellungen für jede Umgebung.

Um einen standardisierten Lebenszyklus von Dataform-Workflows zu erstellen, der die Datenhygiene aufrechterhält und Entwicklungsprozesse optimiert, empfehlen wir Folgendes:

  • Erstellen Sie Ausführungsumgebungen, um Tabellen, die während der Entwicklung erstellt wurden, von Tabellen zu isolieren, die Endnutzern zur Verfügung stehen.

  • Release- und Workflowkonfigurationen konfigurieren, um Workflows in einer Produktionsumgebung und optional in einer Stagingumgebung auszuführen

In diesem Dokument werden Lösungen zum Isolieren von Entwicklungstabellen mit Überschreibungen von Arbeitsbereichskompilierungen und zum Konfigurieren von Staging- und Produktionsumgebungen mit Releasekonfigurationen und Workflowkonfigurationen beschrieben.

Mit diesen Lösungen können Sie Ausführungsumgebungen in einem einzelnen Dataform-Repository und Google Cloud -Projekt erstellen. Sie können mehrere Kopien eines Dataform-Repositorys in verschiedenenGoogle Cloud -Projekten haben. Jedes Projekt entspricht einer Phase des Code-Lebenszyklus, z. B. Entwicklung, Staging und Produktion. Mit diesem Ansatz können Sie IAM-Berechtigungen (Identity and Access Management) in jeder Phase des Codelebenszyklus anpassen.

Best Practices für isolierte Ausführungsumgebungen

Wir empfehlen, Tabellen, die während der Ausführung des Entwicklungs-Workflows erstellt werden, von Produktionstabellen in BigQuery zu isolieren. So können Endnutzer zu Produktionstabellen navigieren und das Risiko, dass sie versehentlich auf falsche Daten zugreifen, wird ausgeschlossen.

Sie haben folgende Möglichkeiten, isolierte Ausführungsumgebungen zu erstellen:

Entwicklungs- und Produktionstabellen nach Schema aufteilen
Empfohlen für kleine Teams. In Dataform werden Entwicklungs- und Produktionstabellen in verschiedenen Schemas in BigQuery erstellt. Dataform führt alle Entwicklungstabellen in Schemas mit demselben Suffix aus, das angibt, dass sie während der Entwicklung erstellt wurden. Entwickler können die Entwicklungstabellen anderer Entwickler überschreiben.
Entwicklungs- und Produktionstabellen nach Schema und Google Cloud Projekt aufteilen
Empfohlen für mittelgroße Teams. In Dataform werden Entwicklungs- und Produktionstabellen in verschiedenen Schemas und Projekten in BigQuery erstellt. Dataform hat alle Entwicklungstabellen in einem dedizierten Google Cloud -Entwicklungsprojekt veröffentlicht. Jeder Dataform-Entwickler hat ein eigenes Schema für Entwicklungstabellen. Diese Lösung schließt das Risiko aus, dass Entwickler versehentlich die Entwicklungstabellen anderer Entwickler überschreiben. Der Nachteil dieses Ansatzes ist, dass das Löschen von Entwicklungstabellen und ‑schemas und das Neuerstellen aller Tabellen in jeder Umgebung mehr Zeit in Anspruch nehmen kann.
Entwicklungs-, Staging- und Produktionstabellen nach Google Cloud Projekt aufteilen
Empfohlen für große Teams oder Teams, die eine Staging-Umgebung benötigen. Dataform führt Tabellen aus jeder Umgebung in einem dediziertenGoogle Cloud -Projekt in BigQuery aus. Diese Lösung bietet Ihnen die größte Kontrolle über den Code-Lebenszyklus.

Für alle Lösungen ist ein einzelnes Dataform-Repository erforderlich, das mit einem einzelnen Remote-Repository eines Drittanbieters verbunden ist.

Bei allen Lösungen lösen Entwickler Ausführungen von Entwicklungstabellen in ihren Dataform-Arbeitsbereichen manuell aus. In Dataform werden Produktions- und Staging-Tabellen in einer Releasekonfiguration automatisch kompiliert und mit der in einer Workflowkonfiguration festgelegten Häufigkeit ausgeführt.

Entwicklung und Produktion nach Schema aufteilen

Mit dieser Lösung werden zwei Ausführungsumgebungen erstellt, in denen Dataform Ihre Workflows ausführt: Entwicklung und Produktion. Wenn Sie Entwicklungs- und Produktionstabellen nach Schema aufteilen möchten, müssen Sie Workfloweinstellungen, Überschreibungen von Arbeitsbereichskompilierungen und eine Releasekonfiguration konfigurieren. Wenn Sie Produktionsläufe planen möchten, müssen Sie eine Workflowkonfiguration erstellen.

Dataform führt alle Entwicklungstabellen in den Schemas mit demselben Suffix aus, das angibt, dass sie während der Entwicklung erstellt wurden. Dataform führt alle Produktionstabellen in den Schemas ohne Suffix aus.

In der folgenden Tabelle sehen Sie eine Konfiguration, bei der Entwicklungs- und Produktionstabellen nach Schema aufgeteilt werden, mit einem Entwicklungsschema:

Einstellung Entwicklung Produktion
Google Cloud -Projekt enterprise-analytics enterprise-analytics
Git-Zweig Name des Arbeitsbereichs main
Überschreibungen von Arbeitsbereichskompilierungen Schemasuffix: dev -
Releasekonfiguration - production
Workflowkonfiguration - production

In dieser Lösung werden Entwicklungs- und Produktionstabellen in einem einzigenGoogle Cloud -Projekt gespeichert.

Entwickler lösen die Ausführung manuell in ihren Dataform-Arbeitsbereichen aus. Bei allen manuell ausgelösten Ausführungen werden Tabellen in Schemas mit demselben Suffix ausgeführt, das angibt, dass sie während der Entwicklung erstellt wurden. Entwickler müssen sich darüber im Klaren sein, dass sie die Tabellen der anderen überschreiben können.

In Dataform führen Entwickler Commits durch und übertragen ihre Änderungen per Push an ihre benutzerdefinierten Zweige des Remote-Repositorys. Anschließend senden sie Pull-Anfragen auf der Git-Hostingplattform des Drittanbieters. Durch die Genehmigung einer Pull-Anfrage werden Änderungen mit dem main-Zweig des Remote-Repository zusammengeführt.

Dataform kompiliert automatisch Produktionstabellen aus dem main-Zweig des Remote-Repositorys in ein Kompilierungsergebnis gemäß den Einstellungen der production-Releasekonfiguration.

Dataform führt das production-Kompilierungsergebnis automatisch gemäß dem in der production-Workflowkonfiguration festgelegten Zeitplan aus.

So implementieren Sie diese Lösung:

Workfloweinstellungen

Je nach Ihrer Version von Dataform Core werden die Workfloweinstellungen in workflow_settings.yaml oder dataform.json gespeichert. Weitere Informationen finden Sie unter Dataform-Workflow-Einstellungen konfigurieren.

Konfigurieren Sie in workflow_settings.yaml die folgenden Einstellungen:

defaultProject: enterprise-analytics
defaultDataset: analytics

Konfigurieren Sie in dataform.json die folgenden Einstellungen:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-analytics"
}

Überschreibungen von Arbeitsbereichen

Schema suffix: "dev"

Releasekonfiguration

Git Commitish: "main"

Wenn Sie Ausführungen von production-Kompilierungsergebnissen planen möchten, erstellen Sie eine Workflowkonfiguration.

Beispiel für den Entwicklungsprozess

In diesem Beispiel arbeiten die Entwickler Sasha und Kai im selben Dataform-Repository. Das Dataform-Repository ist mit einem Remote-Git-Repository eines Drittanbieters verbunden.

Sie führen Commits durch und übertragen Änderungen per Push an benutzerdefinierte Zweige im Remote-Repository mit den Namen sasha und kai.

In der folgenden Tabelle sind die angewendeten Umgebungseinstellungen für Sasha, Kai und die Produktionsumgebung aufgeführt:

Einstellung Sasha Kai Produktion
Google Cloud -Projekt enterprise-analytics enterprise-analytics enterprise-analytics
Git-Zweig sasha kai main
Schema analytics_dev analytics_dev analytics

Sasha erstellt eine neue Tabelle und stellt sie in der Produktion bereit:

  1. Sasha erstellt im Dataform-Arbeitsbereich die Tabelle user_stats.
  2. Im Arbeitsbereich löst Sasha die Ausführung der Tabelle manuell aus.
  3. Dataform erstellt die Tabelle enterprise-analytics.analytics_dev.user_stats im Schema analytics_dev im Projekt enterprise-analytics Google Cloud in BigQuery.
  4. Im Arbeitsbereich führt Sasha ein Commit der Änderung durch und überträgt sie per Push an den sasha-Zweig im Remote-Git-Repository.
  5. Sasha sendet im Remote-Repository eine Pull-Anfrage.
  6. Im Remote-Repository prüft und genehmigt Kai die Pull-Anfrage und führt die Änderung mit dem main-Zweig zusammen.
  7. Dataform aktualisiert das Kompilierungsergebnis in der production-Version automatisch in der angegebenen Häufigkeit. Beim nächsten Update des production-Kompilierungsergebnisses fügt Dataform die Tabelle enterprise-analytics.analytics.user_stats dem Kompilierungsergebnis hinzu.
  8. Bei einer geplanten Ausführung einer Workflowkonfiguration führt Dataform die Tabelle enterprise-analytics.analytics.user_stats im Schema analytics im Projekt enterprise-analytics Google Cloud in BigQuery aus.
  9. Die Tabelle user_stats ist für Endnutzer im Schema analytics im Projekt enterprise-analytics Google Cloud in BigQuery verfügbar.

Entwicklung und Produktion nach Schema und Projekt aufteilen

Mit dieser Lösung werden zwei Ausführungsumgebungen erstellt: Entwicklung und Produktion. Wenn Sie Entwicklungs- und Produktionstabellen nach Schema und Google Cloud Projekt aufteilen möchten, müssen Sie Workflow-Einstellungen, Überschreibungen von Arbeitsbereichskompilierungen und eine Releasekonfiguration konfigurieren. Wenn Sie Produktionsläufe planen möchten, müssen Sie eine Workflowkonfiguration erstellen.

In dieser Lösung führt Dataform die Entwicklung in einem dedizierten Google Cloud -Entwicklungsprojekt in Schemas mit einem anderen Schema-Suffix für jeden Arbeitsbereich aus.

Dataform führt alle Produktionstabellen in BigQuery in einem dedizierten Produktions Google Cloud -Projekt ohne Schemasuffix aus.

In der folgenden Tabelle sehen Sie eine Konfiguration, bei der Entwicklungs- und Produktionstabellen nach Schema und Google Cloud Projekt aufgeteilt werden. Dabei gibt es ein Entwicklungsschema pro Dataform-Arbeitsbereich:

Einstellung Entwicklung Produktion
Google Cloud -Projekt enterprise-dev enterprise-prod
Git-Zweig Name des Arbeitsbereichs main
Überschreibungen von Arbeitsbereichskompilierungen Schemasuffix: ${workspaceName} -
Releasekonfiguration - production
Workflowkonfiguration - production

In dieser Lösung werden Entwicklungs- und Produktionstabellen in Dataform in verschiedenen Schemas und Google Cloud Projekten in BigQuery ausgeführt.

Entwickler lösen die Ausführung manuell in ihren Dataform-Arbeitsbereichen aus. Jeder Entwickler arbeitet in seinem eigenen Workspace, der nach ihm benannt ist, z. B. sasha.

Wenn ein Entwickler die Ausführung in seinem Arbeitsbereich auslöst, hängt Dataform den Arbeitsbereichsnamen als Schemasuffix an alle Schemas an. Anschließend werden Tabellen im benutzerdefinierten Schema in Dataform ausgeführt.

Dataform erstellt beispielsweise Tabellen aus dem sasha-Arbeitsbereich im analytics_sasha-Schema in BigQuery. So speichert jeder Entwickler seine Entwicklungstabellen in eigenen Schemas. Es besteht kein Risiko, dass Tabellen anderer Entwickler versehentlich überschrieben werden.

In Dataform führen Entwickler Commits durch und übertragen ihre Änderungen per Push an ihre benutzerdefinierten Zweige des Remote-Repositorys. Anschließend senden sie Pull-Anfragen auf der Git-Hostingplattform des Drittanbieters. Durch die Genehmigung einer Pull-Anfrage werden Änderungen mit dem main-Zweig des Remote-Repository zusammengeführt.

Dataform kompiliert automatisch Produktionstabellen aus dem main-Zweig des Remote-Repositorys in ein Kompilierungsergebnis gemäß den Einstellungen der production-Releasekonfiguration.

Dataform führt das production-Kompilierungsergebnis automatisch gemäß dem in der production-Workflowkonfiguration festgelegten Zeitplan aus.

So implementieren Sie diese Lösung:

Workfloweinstellungen

Je nach Ihrer Version von Dataform Core werden die Workfloweinstellungen in workflow_settings.yaml oder dataform.json gespeichert. Weitere Informationen finden Sie unter Dataform-Workflow-Einstellungen konfigurieren.

Konfigurieren Sie in workflow_settings.yaml die folgenden Einstellungen:

defaultProject: enterprise-dev
defaultDataset: analytics

Konfigurieren Sie in dataform.json die folgenden Einstellungen:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

Überschreibungen von Arbeitsbereichen

Schema suffix: "${workspaceName}"

Releasekonfiguration

  • Git Commitish: "main"
  • Google Cloud Projekt-ID: "enterprise-prod"

Wenn Sie Ausführungen von production-Kompilierungsergebnissen planen möchten, erstellen Sie eine Workflowkonfiguration mit einem benutzerdefinierten Zeitplan, der Ihren Anforderungen am besten entspricht.

Beispiel für den Entwicklungsprozess

In diesem Beispiel arbeiten die Entwickler Sasha und Kai am selben Dataform-Repository. Das Dataform-Repository ist mit einem Remote-Git-Repository eines Drittanbieters verbunden.

Sasha arbeitet in ihrem eigenen Arbeitsbereich namens sasha und Kai in seinem eigenen Arbeitsbereich namens Kai. Sie führen Commits durch und übertragen Änderungen per Push an benutzerdefinierte Zweige im Remote-Repository mit den Namen sasha und kai.

In der folgenden Tabelle sind die angewendeten Umgebungseinstellungen für Sasha, Kai und die Produktionsumgebung aufgeführt:

Einstellung Sasha Kai Produktion
Google Cloud -Projekt enterprise-dev enterprise-dev enterprise-prod
Git-Zweig sasha kai main
Überschreibungen von Arbeitsbereichskompilierungen Schemasuffix: ${workspaceName} Schemasuffix: ${workspaceName} -
Releasekonfiguration - - production
Workflowkonfiguration - - production

Sasha erstellt eine neue Tabelle und stellt sie in der Produktion bereit:

  1. Im sasha-Dataform-Arbeitsbereich erstellt Sasha die Tabelle user_stats.
  2. Im Arbeitsbereich sasha löst Sasha die Ausführung der Tabelle manuell aus.
  3. Dataform führt die Tabelle enterprise-dev.analytics_sasha.user_stats im Schema analytics_sasha im Projekt enterprise-dev Google Cloud in BigQuery aus.
  4. Im Arbeitsbereich sasha führt Sasha ein Commit der Änderung durch und überträgt sie per Push an den Branch sasha im Remote-Git-Repository.
  5. Sasha sendet im Remote-Repository eine Pull-Anfrage.
  6. Im Remote-Repository prüft und genehmigt Kai die Pull-Anfrage und führt die Änderung mit dem main-Zweig zusammen.
  7. Dataform aktualisiert das Kompilierungsergebnis in der production-Version automatisch in der angegebenen Häufigkeit. Beim nächsten Update des production-Kompilierungsergebnisses fügt Dataform die Tabelle enterprise-prod.analytics.user_stats dem Kompilierungsergebnis hinzu.
  8. Bei einer geplanten Ausführung einer Workflowkonfiguration führt Dataform die Tabelle enterprise-prod.analytics.user_stats im Schema analytics im Projekt enterprise-prod Google Cloud in BigQuery aus.
  9. Die Tabelle user_stats ist für Endnutzer im Schema analytics im Projekt enterprise-prod Google Cloud in BigQuery verfügbar.

Außerdem ist es möglich, Entwicklungs- und Produktionsdatenquellendeklarationen nach Projekt aufzuteilen und Entwicklungs- und Produktionsdatenquellendeklarationen nach Schema und Projekt aufzuteilen.

Entwicklung, Staging und Produktion nach Schema und Projekt aufteilen

Mit dieser Lösung werden drei Ausführungsumgebungen erstellt: Entwicklung, Staging und Produktion. Alle Umgebungen sind nach Google Cloud Projekt aufgeteilt. Außerdem wird die Entwicklung durch Schemata von Staging und Produktion getrennt.

Wenn Sie Entwicklungs-, Staging- und Produktionstabellen nach Schema und Google Cloud Projekt aufteilen möchten, müssen Sie Workfloweinstellungen, Überschreibungen von Arbeitsbereichskompilierungen und zwei Releasekonfigurationen konfigurieren. Wenn Sie Staging- und Produktionsausführungen planen möchten, müssen Sie zwei separate Workflowkonfigurationen erstellen.

In dieser Lösung werden Entwicklungstabellen in BigQuery in mehreren Entwicklungsschemas ausgeführt, eines pro Dataform-Arbeitsbereich, in einem dedizierten Google Cloud -Entwicklungsprojekt.

Dataform führt alle Staging-Tabellen in BigQuery in einem dedizierten Google Cloud -Staging-Projekt in Schemas mit demselben Suffix aus, das angibt, dass sie in der Staging-Umgebung erstellt wurden.

Dataform führt alle Produktionstabellen in BigQuery in einem dedizierten Google Cloud Produktionsprojekt in Schemas mit demselben Suffix aus, das angibt, dass sie in der Produktion erstellt wurden.

Die folgende Tabelle zeigt eine Beispielkonfiguration, in der Entwicklungs-, Staging- und Produktionstabellen nach Schema und Google Cloud -Projekt aufgeteilt sind. Dabei gibt es ein Entwicklungsschema pro Dataform-Arbeitsbereich:

Einstellung Entwicklung Staging Produktion
Google Cloud -Projekt enterprise-dev enterprise-staging enterprise-prod
Git-Zweig Name des Arbeitsbereichs main prod
Überschreibungen von Arbeitsbereichskompilierungen Schemasuffix: ${workspaceName} - -
Releasekonfiguration - staging production
Workflowkonfiguration - staging production

In dieser Lösung werden Entwicklungs-, Staging- und Produktionstabellen in verschiedenen Google Cloud Projekten in BigQuery ausgeführt. Außerdem werden Entwicklungstabellen in Dataform in mehreren benutzerdefinierten Schemas ausgeführt, eines pro Arbeitsbereich. Dataform führt Staging- und Produktionstabellen im selben Schema, aber in verschiedenen Google Cloud Projekten aus.

Entwickler lösen die Ausführung manuell in ihren Dataform-Arbeitsbereichen aus. Jeder Entwickler arbeitet in seinem eigenen Workspace, der nach ihm benannt ist, z. B. sasha.

Jeder Arbeitsbereich entspricht einem benutzerdefinierten BigQuery-Schema, das nach dem Arbeitsbereich benannt ist. Wenn ein Entwickler die Ausführung in seinem Arbeitsbereich auslöst, hängt Dataform den Arbeitsbereichsnamen als Schemasuffix an das Standardschema an. Anschließend werden Tabellen im benutzerdefinierten Schema in BigQuery ausgeführt.

Dataform führt beispielsweise Tabellen aus dem sasha-Arbeitsbereich im Schema analytics_sasha in BigQuery aus. So speichert jeder Entwickler seine Entwicklungstabellen in seinem eigenen Schema. Es besteht kein Risiko, dass Tabellen anderer Entwickler versehentlich überschrieben werden.

In Dataform führen Entwickler Commits durch und übertragen ihre Änderungen per Push an ihre benutzerdefinierten Zweige des Remote-Repositorys. Anschließend senden sie auf der Git-Hostingplattform des Drittanbieters Pull-Anfragen für den main-Zweig. Durch die Genehmigung einer Pull-Anfrage werden Änderungen im main-Zweig des Remote-Repository zusammengeführt.

Dataform kompiliert Staging-Tabellen automatisch aus dem main-Branch des Remote-Repositorys in ein Kompilierungsergebnis gemäß den Einstellungen der staging-Releasekonfiguration.

Dataform führt das staging-Kompilierungsergebnis automatisch gemäß dem in der staging-Workflowkonfiguration festgelegten Zeitplan aus.

Um Tabellen vom Staging- in die Produktionsumgebung zu übertragen, senden Entwickler auf der Git-Hostingplattform eines Drittanbieters Pull-Anfragen vom main-Zweig an den prod-Zweig. Durch die Genehmigung einer Pull-Anfrage werden Änderungen im prod-Zweig des Remote-Repository zusammengeführt.

Dataform kompiliert automatisch Produktionstabellen aus dem prod-Zweig des Remote-Repositorys in ein Kompilierungsergebnis gemäß den Einstellungen der production-Releasekonfiguration.

Dataform führt das production-Kompilierungsergebnis automatisch gemäß dem in der production-Workflowkonfiguration festgelegten Zeitplan aus.

So implementieren Sie diese Lösung:

Workfloweinstellungen

Je nach Ihrer Version von Dataform Core werden die Workfloweinstellungen in workflow_settings.yaml oder dataform.json gespeichert. Weitere Informationen finden Sie unter Dataform-Workflow-Einstellungen konfigurieren.

Konfigurieren Sie in workflow_settings.yaml die folgenden Einstellungen:

defaultProject: enterprise-dev
defaultDataset: analytics

Konfigurieren Sie in dataform.json die folgenden Einstellungen:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

Überschreibungen von Arbeitsbereichen

Schema suffix: "${workspaceName}"

staging-Releasekonfiguration

  • Git Commitish: "main"
  • Google Cloud Projekt-ID: "enterprise-staging"

prod Releasekonfiguration

  • Git Commitish: "prod"
  • Google Cloud Projekt-ID: "enterprise-prod"

Wenn Sie Ausführungen von staging- und production-Kompilierungsergebnissen planen möchten, erstellen Sie zwei separate Workflowkonfigurationen mit benutzerdefinierten Zeitplänen, die Ihren Anforderungen am besten entsprechen.

Beispiel für den Entwicklungsprozess

In diesem Beispiel arbeiten die Entwickler Sasha und Kai im selben Dataform-Repository. Das Dataform-Repository ist mit einem Remote-Git-Repository eines Drittanbieters verbunden.

Sasha arbeitet in ihrem eigenen Arbeitsbereich namens sasha und Kai in seinem eigenen Arbeitsbereich namens Kai. Sie führen Commits durch und übertragen Änderungen per Push an benutzerdefinierte Zweige im Remote-Repository mit den Namen sasha und kai.

In der folgenden Tabelle sind die angewendeten Umgebungseinstellungen für Sasha, Kai und die Produktionsumgebung aufgeführt:

Einstellung Sasha Kai Staging Produktion
Google Cloud -Projekt enterprise-dev enterprise-dev enterprise-staging enterprise-prod
Git-Zweig sasha kai main prod
Schema analytics_sasha analytics_kai analytics analytics

Sasha erstellt eine neue Tabelle und stellt sie in der Produktion bereit:

  1. Im sasha-Dataform-Arbeitsbereich erstellt Sasha die Tabelle user_stats.
  2. Im Arbeitsbereich sasha löst Sasha die Ausführung der Tabelle manuell aus.
  3. Dataform führt die Tabelle enterprise-dev.analytics_sasha.user_stats im Schema analytics_sasha im Projekt enterprise-dev Google Cloud in BigQuery aus.
  4. Im Arbeitsbereich sasha führt Sasha ein Commit der Änderung durch und überträgt sie per Push an den Branch sasha im Remote-Git-Repository.
  5. Sasha sendet im Remote-Repository eine Pull-Anfrage für den main-Zweig.
  6. Im Remote-Repository prüft und genehmigt Kai die Pull-Anfrage und führt die Änderung im main-Zweig zusammen.
  7. Dataform aktualisiert das Kompilierungsergebnis in der staging-Version automatisch in der angegebenen Häufigkeit. Beim nächsten Update des staging-Kompilierungsergebnisses fügt Dataform die Tabelle enterprise-staging.analytics.user_stats dem Kompilierungsergebnis hinzu.
  8. Bei einer geplanten Ausführung einer Workflowkonfiguration führt Dataform die Tabelle enterprise-staging.analytics.user_stats im Schema analytics im Projekt enterprise-staging Google Cloud in BigQuery aus.
  9. Sasha sendet im Remote-Repository eine Pull-Anfrage für den prod-Zweig.
  10. Im Remote-Repository prüft und genehmigt Kai die Pull-Anfrage und führt die Änderung im prod-Zweig zusammen.
  11. Dataform aktualisiert das Kompilierungsergebnis in der production-Version automatisch in der angegebenen Häufigkeit. Beim nächsten Update des production-Kompilierungsergebnisses fügt Dataform die Tabelle enterprise-prod.analytics.user_stats dem Kompilierungsergebnis hinzu.
  12. Bei einer geplanten Ausführung einer Workflowkonfiguration führt Dataform die Tabelle enterprise-prod.analytics.user_stats im Schema analytics im Projekt enterprise-prod Google Cloud in BigQuery aus.
  13. Die Tabelle user_stats ist für Endnutzer im Schema analytics im Projekt enterprise-prod Google Cloud in BigQuery verfügbar.

Entwicklungs- und Produktionsdatenquellen nach Projekt aufteilen

Bei dieser Lösung werden Deklarationen von Entwicklungs- und Produktionsdatenquellen nach Projekt getrennt. Anstatt eine Datenquelle mit einem statischen Projekt zu deklarieren, können Sie Datenquellendeklarationen dynamisch mit Variablen aus der Workflow-Einstellungsdatei ändern. Das ist nützlich, wenn Ihre Datenquellen in separaten Entwicklungs- und Produktionsprojekten isoliert sind.

In diesem Beispiel wird die Projektvariable aus der Datei mit den Workflow-Einstellungen mithilfe der Dataform-Variablen dataform.projectConfig.vars.projectVar in die Datenquellendeklaration eingefügt:

Konfigurieren Sie in der Datei source_declaration.sqlx die folgenden Einstellungen:

config {
  type: "declaration",
  database: dataform.projectConfig.vars.projectVar,
  schema: "source_schema",
  name: "source_name",
}

Wenn ein Workflow ausgeführt wird, fügt Dataform den Standardprojektwert oder alle konfigurierten Überschreibungen für die Projektkompilierung in die Deklaration ein. Wenn Sie in Ihrem Workflow auf diese Datenquelle verweisen, wird je nach Ausführungsumgebung entweder auf die Entwicklungs- oder die Produktionsdatenquelle verwiesen.

Für diese Lösung sind einheitliche Namenskonventionen für Entwicklungs- und Produktionsquellschemas und -tabellen erforderlich. Wenn Sie andere Namenskonventionen benötigen, verwenden Sie benutzerdefinierte Kompilierungsvariablen.

Entwicklungs- und Produktionsdatenquellendeklarationen nach Schema und Projekt aufteilen

Bei dieser Lösung werden Datenquellendeklarationen für Entwicklung und Produktion nach Projekt und Schema getrennt. Zusätzlich zur Verwendung der Projektvariablen aus der Datei mit den Workflow-Einstellungen werden benutzerdefinierte Kompilierungsvariablen definiert, um einen benutzerdefinierten Quellschemanamen und ein benutzerdefiniertes Quelltabellensuffix darzustellen. Die Standardwerte für diese Variablen sind an die Entwicklungsdatenquelle angepasst und können je nach Workflow-Ausführungsumgebung mit Überschreibungswerten für die Produktionsdatenquelle überschrieben werden.

Konfigurieren Sie in der Datei workflow_settings.yaml die folgenden Einstellungen:

defaultProject: development
defaultLocation: US
defaultDataset: development
defaultAssertionDataset: dataform_assertions
dataformCoreVersion: 3.0.0
vars:
 sourceSchema: schema_DEV
 sourceNameSuffix: _DEV

Konfigurieren Sie in der Datei source_declaration.sqlx die folgenden Einstellungen:

config {
  type: "declaration",
  database: dataform.projectConfig.vars.projectVar,
  schema: dataform.projectConfig.vars.sourceSchema,
  name: "source_name"+dataform.projectConfig.vars.sourceNameSuffix,
}
Variable Entwicklung (Standard) Produktion (Überschreibungen)
projectVar development production
sourceSchema schema_DEV schema_PROD
sourceNameSuffix _DEV _PROD
Zusammengestellte Datenquelle development.schema_DEV.source_name_DEV production.schema_PROD.source_name_PROD

In diesem Beispiel werden Entwicklungs- und Produktionsdatenquellen nach Projekt und Schema aufgeteilt. Dazu werden die Variable projectVar bzw. die benutzerdefinierte Variable sourceSchema verwendet. Optional kann die Quelltabelle durch ein Suffix getrennt werden, das an den Tabellennamen angehängt wird.

Im vorherigen Beispiel müssen die Datenquellen vorab in den separaten Entwicklungs- und Produktionsprojekten erstellt werden. Außerdem müssen die Quellschemas und Tabellennamen konsistenten Namenskonventionen folgen. Wenn Sie auf eine Quelltabelle verweisen, muss der Verweis außerdem so geändert werden, dass die benutzerdefinierte Kompilierungsvariable ${ref("source_name"+dataform.projectConfig.vars.sourceNameSuffix)} verwendet wird, damit die Verweise richtig aufgelöst werden.

Nächste Schritte