Best Practices für Repositories

Dieses Dokument enthält die folgenden Informationen zu Dataform-Repositories:

Übersicht über Best Practices für Repositorys in Dataform

In diesem Abschnitt finden Sie eine Übersicht über Best Practices für die Verwaltung der Repository-Größe, der Repository-Struktur und des Codelebenszyklus in Dataform.

Best Practices für die Repository-Größe

Die Repository-Größe wirkt sich auf mehrere Aspekte der Entwicklung in Dataform aus, darunter:

  • Zusammenarbeit
  • Lesbarkeit der Codebasis
  • Entwicklungsprozesse
  • Workflow-Kompilierung
  • Workflowausführung

Dataform erzwingt API-Kontingente und -Limits für Kompilierungsressourcen. Ein großes Repository kann dazu führen, dass diese Kontingente und Limits überschritten werden. Dies kann dazu führen, dass die Kompilierung und Ausführung Ihres Workflows fehlschlägt.

Um dieses Risiko zu minimieren, empfehlen wir, große Repositories aufzuteilen. Wenn Sie ein großes Repository aufteilen, teilen Sie einen großen Workflow in mehrere kleinere Workflows auf, die in verschiedenen Repositories gespeichert und durch Repository-übergreifende Abhängigkeiten verbunden sind.

Mit diesem Ansatz können Sie Dataform-Kontingente und -Limits einhalten, detaillierte Prozesse und Berechtigungen implementieren und die Lesbarkeit der Codebasis und die Zusammenarbeit verbessern. Die Verwaltung aufgeteilter Repositories kann jedoch schwieriger sein als die Verwaltung eines einzelnen Repositorys.

Weitere Informationen zu den Auswirkungen der Repository-Größe in Dataform finden Sie unter Repository-Größe – Übersicht. Weitere Informationen zu Best Practices für das Aufteilen von Repositories finden Sie unter Repositories aufteilen.

Best Practices für die Repository-Struktur

Wir empfehlen, die Dateien im Verzeichnis definitions so zu strukturieren, dass sie die Phasen Ihres Workflows widerspiegeln. Sie können eine benutzerdefinierte Struktur verwenden, die Ihren Anforderungen am besten entspricht.

Die folgende empfohlene Struktur von definitions-Unterverzeichnissen spiegelt die wichtigsten Phasen der meisten Workflows wider:

  • sources zum Speichern von Datenquellendeklarationen.
  • intermediate zum Speichern der Datentransformationslogik.
  • output zum Speichern von Definitionen von Ausgabetabellen.
  • extras (optional) zum Speichern zusätzlicher Dateien.

Die Namen aller Dateien in Dataform müssen den Benennungsrichtlinien für BigQuery-Tabelle entsprechen. Wir empfehlen, dass die Namen der Dateien im Verzeichnis definitions in einem Dataform-Repository die Unterverzeichnisstruktur widerspiegeln.

Weitere Informationen zu Best Practices für die Strukturierung und Benennung von Dateien in einem Repository finden Sie unter Code in einem Repository strukturieren.

Best Practices für den Code-Lebenszyklus

Der Standardcodelebenszyklus in Dataform besteht aus den folgenden Phasen:

Wenn Sie den Codelebenszyklus in Dataform verwalten möchten, können Sie Ausführungsumgebungen wie Entwicklung, Staging und Produktion erstellen.

Weitere Informationen zum Codelebenszyklus in Dataform finden Sie unter Einführung in den Codelebenszyklus in Dataform.

Sie können Ihre Ausführungsumgebungen in einem einzelnen Repository oder in mehreren Repositories speichern.

Ausführungsumgebungen in einem einzelnen Repository

Sie können isolierte Ausführungsumgebungen wie Entwicklung, Staging und Produktion in einem einzelnen Dataform-Repository mit Überschreibungen von Arbeitsbereichskompilierungen und Releasekonfigurationen erstellen.

Sie können isolierte Ausführungsumgebungen auf folgende Arten erstellen:

  • Trennen Sie Entwicklungs- und Produktionstabellen nach Schema.
  • Entwicklungs- und Produktionstabellen nach Schema und Google Cloud -Projekt aufteilen.
  • Teilen Sie Entwicklungs-, Staging- und Produktionstabellen nach Google Cloud -Projekt auf.

Anschließend können Sie Ausführungen in Staging- und Produktionsumgebungen mit Workflowkonfigurationen planen. Wir empfehlen, Ausführungen in der Entwicklungsumgebung manuell auszulösen.

Weitere Informationen zu Best Practices für die Verwaltung des Workflow-Lebenszyklus in Dataform finden Sie unter Best Practices für den Workflow-Lebenszyklus.

Code-Lebenszyklus in mehreren Repositories

Wenn Sie Identity and Access Management-Berechtigungen auf jede Phase des Codelebenszyklus zuschneiden möchten, können Sie mehrere Kopien eines Repositorys erstellen und in verschiedenen Google Cloud Projekten speichern.

Jedes Google Cloud -Projekt dient als Ausführungsumgebung, die einer Phase des Codelebenszyklus entspricht, z. B. Entwicklung und Produktion.

Bei diesem Ansatz empfehlen wir, die Codebasis des Repositorys in allen Projekten gleich zu halten. Wenn Sie die Kompilierung und Ausführung in jeder Kopie des Repositorys anpassen möchten, verwenden Sie Überschreibungen von Arbeitsbereichskompilierungen, Releasekonfigurationen und Workflowkonfigurationen.

Übersicht über die Repository-Größe

In diesem Abschnitt erfahren Sie, wie sich die Repository-Größe auf die Workflowentwicklung und die Nutzung von Dataform-Kompilierungsressourcen auswirkt und wie Sie die Nutzung von Kompilierungsressourcen für Ihr Repository schätzen können.

Repository-Größe in Dataform

Die Größe eines Repositorys wirkt sich auf die folgenden Aspekte der Entwicklung in Dataform aus:

  • Zusammenarbeit: Wenn mehrere Mitbearbeiter an einem großen Repository arbeiten, kann dies zu einer übermäßigen Anzahl von Pull-Anfragen führen, was das Risiko von Zusammenführungskonflikten erhöht.

  • Lesbarkeit der Codebasis: Eine größere Anzahl von Dateien, die einen Workflow in einem einzelnen Repository bilden, kann die Navigation im Repository erschweren.

  • Entwicklungsprozesse: Für einige Bereiche eines großen Workflows in einem einzelnen Repository sind möglicherweise benutzerdefinierte Berechtigungen oder Prozesse erforderlich, z. B. die Planung, die sich von den Berechtigungen und Prozessen unterscheiden, die auf den Rest des Workflows angewendet werden. Eine große Repository-Größe erschwert es, Entwicklungsprozesse auf bestimmte Bereiche des Workflows zuzuschneiden.

  • Workflow-Kompilierung. Dataform erzwingt Nutzungslimits für Kompilierungsressourcen. Ein großes Repository kann dazu führen, dass diese Limits überschritten werden und die Kompilierung fehlschlägt.

  • Workflowausführung. Während der Ausführung führt Dataform Repository-Code in Ihrem Arbeitsbereich aus und stellt Assets in BigQuery bereit. Je größer das Repository, desto länger dauert die Ausführung in Dataform.

Wenn sich die Größe Ihres Repositorys negativ auf Ihre Entwicklung in Dataform auswirkt, können Sie das Repository in mehrere kleinere Repositorys aufteilen.

Ressourcenlimits für die Repository-Kompilierung

Während der Entwicklung kompiliert Dataform den gesamten Repository-Code in Ihrem Arbeitsbereich, um eine Darstellung des Workflows in Ihrem Repository zu generieren. Dies wird als Kompilierungsergebnis bezeichnet. Dataform erzwingt Nutzungslimits für Kompilierungsressourcen.

Ihr Repository überschreitet die Nutzungslimits möglicherweise aus folgenden Gründen:

  • Ein Endlosschleifenfehler im Repository-Code.
  • Ein Speicherleckfehler im Repository-Code.
  • Ein großes Repository mit mehr als 1.000 Workflowaktionen.

Weitere Informationen zu Nutzungslimits für Kompilierungsressourcen finden Sie unter Limits für Dataform-Kompilierungsressourcen.

Kompilierungsressourcennutzung Ihres Repositorys schätzen

Sie können die Nutzung der folgenden Kompilierungsressourcen für Ihr Repository schätzen:

  • CPU-Zeit-Nutzung.
  • Echtzeit-Nutzung.
  • Maximale Gesamtgröße der serialisierten Daten des generierten Aktionsdiagramms, das in Ihrem Repository definiert ist.

Um eine grobe Schätzung der aktuellen Kompilierungszeit für die Kompilierung Ihres Repositorys zu erhalten, können Sie die Kompilierung Ihres Dataform-Workflows auf einem lokalen Linux- oder macOS-Computer messen.

  • Wenn Sie die Kompilierung Ihres Workflows zeitlich planen möchten, führen Sie in Ihrem Repository den Dataform-CLI-Befehl dataform compile im folgenden Format aus:

    time dataform compile

    Das folgende Codebeispiel zeigt ein Ergebnis der Ausführung des Befehls time dataform compile:

    real    0m3.480s
user    0m1.828s
sys     0m0.260s

Sie können das real-Ergebnis als groben Indikator für die Nutzung der Wandzeit und das user-Ergebnis als groben Indikator für die CPU-Zeit für die Kompilierung Ihres Repositorys betrachten.

Wenn Sie eine grobe Schätzung der Gesamtgröße des generierten Aktionsgraphen in Ihrem Repository erhalten möchten, können Sie die Ausgabe des Graphen in eine JSON-Datei schreiben. Die Größe der unkomprimierten JSON-Datei ist ein grober Indikator für die Gesamtgröße des Graphen.

  • Führen Sie den folgenden Dataform-CLI-Befehl in Ihrem Repository aus, um die Ausgabe des kompilierten Graphen Ihres Workflows in eine JSON-Datei zu schreiben:

    dataform compile --json > graph.json

Repositories aufteilen

In diesem Abschnitt werden Strategien zum Aufteilen eines Dataform-Repositorys und zum Verwalten von Repository-übergreifenden Abhängigkeiten erläutert.

Repositories sind die Kerneinheiten in Dataform. In einem Repository werden alle SQLX- und JavaScript-Dateien, aus denen Ihr Workflow besteht, sowie die Dataform-Konfigurationsdateien und -Pakete gespeichert. Sie können einen Workflow in einem einzelnen Repository speichern oder einen Workflow auf mehrere Repositories aufteilen.

Das Aufteilen eines Repositorys in Dataform bietet die folgenden Vorteile:

  • Einhaltung der Ressourcenlimits für die Dataform-Kompilierung. Wenn Sie einen großen Workflow in mehrere kleinere Repositories aufteilen, sinkt das Risiko, dass die Dataform-Limits für Kompilierungsressourcen überschritten werden.
  • Feinkörnige Prozesse. Sie können Prozesse wie Regeln für die kontinuierliche Integration (CI) für jedes einzelne Fragment Ihres Workflows und das Team, das es entwickelt, individuell festlegen.
  • Detaillierte Berechtigungen Sie können Berechtigungen für jedes einzelne Fragment Ihres Workflows und das Team, das es entwickelt, individuell festlegen, um die allgemeine Sicherheit des Workflows zu verbessern.
  • Verbesserung der Zusammenarbeit durch Minimierung der Anzahl der Mitbearbeiter, die an den einzelnen Fragmenten Ihres Workflows arbeiten.
  • Verbesserung der Lesbarkeit der Codebasis. Wenn Sie die Dateien, aus denen ein großer Workflow besteht, in mehrere Repositories aufteilen, ist es einfacher, jedes Repository einzeln zu durchsuchen, als den gesamten Workflow auf einmal zu durchsuchen.
  • Beschleunigung der Workflowausführung jedes aufgeteilten Fragments Ihres Workflows im Vergleich zur Ausführung des gesamten Workflows.

Das Aufteilen eines Repositorys in Dataform hat die folgenden Nachteile:

  • Für jedes Dataform-Repository und das entsprechende Git-Repository ist eine benutzerdefinierte CI/CD-Konfiguration (Continuous Integration/Continuous Development) erforderlich.
  • Für jedes Dataform-Repository und das zugehörige Git-Repository ist eine benutzerdefinierte Zeitplankonfiguration erforderlich.
  • Schwierigkeiten bei der Verwaltung von Abhängigkeiten zwischen den Objekten Ihres Workflows, die in mehreren Repositories gespeichert sind.
  • Fehlende umfassende Visualisierung des gerichteten azyklischen Graphen (DAG) des SQL-Workflows, der auf mehrere Repositories aufgeteilt ist. In jedem Repository stellt der generierte DAG nur einen Teil des gesamten Workflows dar.

Strategien zum Aufteilen eines Repositorys

Wenn Sie ein Repository aufteilen, teilen Sie die Dateien, aus denen ein übergeordneter SQL-Workflow besteht, in kleinere untergeordnete Workflows auf, die in separaten Dataform-Repositories gespeichert werden.

Sie können ein Repository auf eine der folgenden Arten aufteilen:

  • Ein Repository pro Entwicklungsteam.
  • Ein Repository pro Domain, z. B. Vertrieb, Marketing oder Logistik.
  • Ein zentrales Repository und ein Repository pro Domain, das die Inhalte des zentralen Repositorys als Datenquellen verwendet.

Wenn Sie den übergeordneten Workflow auf einer Git-Hostingplattform eines Drittanbieters hosten möchten, müssen Sie jedes der separaten Repositories mit untergeordneten Workflows einzeln mit einem dedizierten Git-Repository eines Drittanbieters verbinden.

Repository-übergreifende Abhängigkeiten verwalten

Am effizientesten lässt sich ein Repository aufteilen, indem Sie den übergeordneten SQL-Workflow in eigenständige untergeordnete Workflows aufteilen und so unabhängige Repositorys erstellen. Ein unabhängiges Repository verwendet nicht den Inhalt eines anderen Repositorys als Datenquelle. Bei diesem Ansatz müssen keine Repository-übergreifenden Abhängigkeiten verwaltet werden.

Wenn Sie Repository-übergreifende Abhängigkeiten nicht vermeiden können, können Sie sie verwalten, indem Sie ein Repository in eine Reihe von Repositories aufteilen, wobei ein Repository von seinem Vorgänger abhängt und eine Datenquelle für seinen Nachfolger ist. Die Abfolge der Repositories und ihrer Abhängigkeiten muss die Struktur Ihres übergeordneten Workflows am besten widerspiegeln.

Sie können Abhängigkeiten zwischen Repositories mit Dataform-Datenquellendeklarationen erstellen. Sie können einen BigQuery-Tabellentyp aus einem anderen Dataform-Repository als Datenquelle im bearbeiteten Repository deklarieren. Nachdem Sie eine Datenquelle deklariert haben, können Sie sie wie jede andere Dataform-Workflow-Aktion referenzieren und zum Entwickeln Ihres Workflows verwenden.

Wenn Sie die Ausführung eines Workflows planen, der auf Repositories mit Repository-übergreifenden Abhängigkeiten aufgeteilt ist, müssen Sie die Repositories nacheinander in der Reihenfolge der Repository-übergreifenden Abhängigkeiten ausführen.

Wir empfehlen, ein Repository nicht in eine Gruppe von Repositorys mit bidirektionalen Abhängigkeiten aufzuteilen. Eine bidirektionale Abhängigkeit zwischen Repositories tritt auf, wenn ein Repository eine Datenquelle für ein anderes Repository ist und dieses Repository auch als Datenquelle verwendet. Zweiseitige Abhängigkeiten zwischen Repositories erschweren die Planung und Ausführung des übergeordneten Workflows sowie die Entwicklungsprozesse.

Code in einem Repository strukturieren

In diesem Abschnitt werden Best Practices für die Strukturierung und Benennung von Workflowdateien im Stammverzeichnis definitions eines Dataform-Repositorys beschrieben. Die empfohlene Struktur des Verzeichnisses definitions spiegelt die Phasen eines Workflows wider. Sie können jede Struktur verwenden, die Ihren Geschäftsanforderungen entspricht.

Es kann sinnvoll sein, den Workflowcode im Verzeichnis definitions aus folgenden Gründen zu strukturieren:

  • Verbesserung der Zusammenarbeit an der Codebasis durch Zuweisung von Teams zu ausgewählten Teilen Ihres Workflows.
  • Verbesserung der Wartbarkeit des Workflows bei organisatorischen Änderungen.
  • Verbesserung der Navigation in Ihrer Codebasis.
  • Verbesserung der Skalierbarkeit der Codebasis.
  • Minimierung des Verwaltungsaufwands für Ihr Team.

Das Stammverzeichnis definitions in einem Dataform-Repository enthält Code, mit dem Elemente Ihres Workflows erstellt werden. Sie können Dateien im Verzeichnis definitions in einer Verzeichnisstruktur organisieren, die die Struktur des Workflows widerspiegelt.

Wenn Sie einen Workflow entwickeln, deklarieren Sie Quelltabellen und transformieren sie, um Ausgabetabellen zu erstellen, die Sie für Geschäfts- oder Analysezwecke verwenden können.

Ein Workflow lässt sich in drei Hauptphasen unterteilen:

  1. Deklaration von Datenquellen.
  2. Transformation von Quelldaten.
  3. Definition von Ausgabetabellen aus den transformierten Quelldaten.

Die folgende Struktur von Unterverzeichnissen im Verzeichnis definitions spiegelt die wichtigsten Phasen eines Workflows wider:

sources
Datenquellendeklarationen und grundlegende Transformation von Quelldaten, z. B. Filtern.
intermediate
-Tabellen und -Aktionen, die Daten aus sources lesen und transformieren, bevor Sie die transformierten Daten zum Definieren von outputs-Tabellen verwenden. Tabellen, die in der Regel nicht für zusätzliche Prozesse oder Tools wie Business-Intelligence-Tools (BI) verfügbar gemacht werden, nachdem sie von Dataform in BigQuery ausgeführt wurden.
outputs
Definitionen von Tabellen, die von Prozessen oder Tools wie BI verwendet werden, nachdem Dataform sie in BigQuery ausgeführt hat.
extra
Dateien außerhalb der Hauptpipeline Ihres Workflows, z. B. Dateien, die Workflowdaten enthalten, die für eine zusätzliche Verwendung wie maschinelles Lernen vorbereitet wurden. Ein optionales und benutzerdefiniertes Unterverzeichnis.

Best Practices für sources

Das Unterverzeichnis sources enthält die erste Phase Ihres Workflows: die Deklaration und grundlegende Transformation von Quelldaten.

Speichern Sie im Unterverzeichnis sources Datenquellendeklarationen und Tabellen, die Spalten filtern, kategorisieren, umwandeln oder umbenennen.

Vermeiden Sie das Speichern von Tabellen, in denen Daten aus mehreren Quellen kombiniert werden.

sources-Daten in Tabellen transformieren, die im Unterverzeichnis intermediate gespeichert sind.

Wenn Sie Datenquellen aus mehreren Pools deklarieren, z. B. Google Ads oder Google Analytics, sollten Sie für jeden Pool ein eigenes Unterverzeichnis erstellen.

Das folgende Beispiel zeigt eine Unterverzeichnisstruktur von sources mit zwei Quellpools:

definitions/
    sources/
        google_ads/
            google_ads_filtered.sqlx
            google_ads_criteria_metrics.sqlx
            google_ads_criteria_metrics_filtered.sqlx
            google_ads_labels.sqlx
            google_ads_labels_filtered.sqlx
        google_analytics/
            google_analytics_users.sqlx
            google_analytics_users_filtered.sqlx
            google_analytics_sessions.sqlx

Wenn Sie mehrere Datenquellentabellen innerhalb desselben Schemas deklarieren, können Sie ihre Deklarationen in einer einzigen JavaScript-Datei zusammenfassen.

Weitere Informationen zum Erstellen von Datenquellendeklarationen mit JavaScript finden Sie unter Workflows ausschließlich mit JavaScript erstellen.

Das folgende Codebeispiel zeigt mehrere Datenquellen innerhalb eines Schemas, die in einer einzelnen JavaScript-Datei deklariert sind:

[
  "source_table_1",
  "source_table_2",
  "source_table_3"
].forEach((name) =>
  declare({
    database: "gcp_project",
    schema: "source_dataset",
    name,
  })
);

Um Ihren Workflow vor Änderungen an der Datenquelle zu schützen, können Sie für jede Datenquellendeklaration eine Ansicht erstellen, z. B. analytics_users_filtered.sqlx. Die Ansicht kann die grundlegende Filterung und Formatierung der Quelldaten enthalten. Speichern Sie die Ansichten im Unterverzeichnis sources.

Wenn Sie dann intermediate- oder outputs-Tabellen erstellen, verweisen Sie auf die Ansichten anstelle der Rohquelltabellen. Mit diesem Ansatz können Sie die Quelltabellen testen. Wenn sich eine Quelltabelle ändert, können Sie ihre Ansicht ändern, z. B. durch Hinzufügen von Filtern oder Neufassen von Daten.

Best Practices für intermediate

Das Unterverzeichnis intermediate enthält die zweite Phase Ihres Workflows: die Transformation und Aggregation der Quelldaten aus einer oder mehreren Quellen.

Speichern Sie im Unterverzeichnis intermediate Dateien, die Quelldaten aus einer oder mehreren Quellen im Unterverzeichnis sources erheblich transformieren, z. B. Tabellen, die Daten zusammenführen. Tabellen im Unterverzeichnis intermediate fragen in der Regel Daten aus Quelltabellen oder anderen intermediate-Tabellen ab.

Verwenden Sie intermediate-Tabellen, um outputs-Tabellen zu erstellen. In der Regel werden intermediate-Tabellen nicht für zusätzliche Zwecke verwendet, z. B. für Datenanalysen, nachdem Dataform sie in BigQuery ausgeführt hat. Sie können sich intermediate-Tabellen als die Datentransformationslogik vorstellen, die die Erstellung von Ausgabetabellen ermöglicht.

Wir empfehlen, alle intermediate-Tabellen zu dokumentieren und zu testen.

Best Practices für outputs

Das Unterverzeichnis outputs enthält die letzte Phase Ihres Workflows: die Erstellung von Ausgabetabellen für Ihre geschäftlichen Zwecke aus den transformierten Daten.

Speichern Sie im Verzeichnis outputs Tabellen, die Sie in zusätzlichen Prozessen oder Tools verwenden möchten, nachdem Dataform sie in BigQuery ausgeführt hat, z. B. Berichte oder Dashboards. Tabellen im Verzeichnis outputs fragen in der Regel Daten aus den intermediate-Tabellen ab.

Gruppieren Sie outputs-Tabellen nach dem Unternehmen, mit dem sie verknüpft sind, z. B. Marketing, Bestellungen oder Analysen. Richten Sie für jedes Unternehmen ein eigenes Unterverzeichnis ein.

Wenn Sie Ausgabetabellen separat in BigQuery speichern möchten, können Sie ein dediziertes Schema für Ausgabetabellen konfigurieren. Eine Anleitung zum Konfigurieren des Tabellenschemas finden Sie unter Tabelleneinstellungen überschreiben.

Das folgende Beispiel zeigt eine Unterverzeichnisstruktur von outputs mit den Unternehmen sales und marketing:

definitions/
    outputs/
        orders/
            orders.sqlx
            returns.sqlx
        sales/
            sales.sqlx
            revenue.sqlx
        marketing/
            campaigns.sqlx

Wir empfehlen, alle outputs-Tabellen zu dokumentieren und zu testen.

Namensstrategie

Die Namen aller Dateien in Dataform müssen den Richtlinien für die Benennung von BigQuery-Tabellen entsprechen.

Wir empfehlen, dass die Namen der Dateien im Verzeichnis definitions in einem Dataform-Repository die Unterverzeichnisstruktur widerspiegeln.

Im Unterverzeichnis sources sollten die Dateinamen auf die Quelle verweisen, auf die sich die Datei bezieht. Fügen Sie den Namen der Quelle als Präfix zu den Dateinamen hinzu, z. B. analytics_filtered.sqlx.

Im Unterverzeichnis intermediate sollten die Dateinamen das Unterverzeichnis identifizieren, damit Mitbearbeiter intermediate-Dateien klar unterscheiden können. Wählen Sie ein eindeutiges Präfix aus und wenden Sie es nur auf Dateien im Verzeichnis intermediate an, z. B. stg_ads_concept.sqlx.

Im Unterverzeichnis outputs sollten die Dateinamen kurz sein, z. B. orders.sqlx. Wenn Sie outputs-Tabellen mit denselben Namen in verschiedenen Entitätsunterverzeichnissen haben, fügen Sie ein Präfix hinzu, das die Entität identifiziert, z. B. sales_revenue.sqlx oder ads_revenue.sqlx.

Das folgende Beispiel zeigt eine Unterverzeichnisstruktur im Verzeichnis definitions mit Dateinamen, die der empfohlenen Benennungsstrategie entsprechen:

definitions/
    sources/
        google_analytics.sqlx
        google_analytics_filtered.sqlx
    intermediate/
        stg_analytics_concept.sqlx
    outputs/
        customers.sqlx
        sales/
            sales.sqlx
            sales_revenue.sqlx
        ads/
            campaigns.sqlx
            ads_revenue.sqlx

Best Practices für Kompilierung und Planung

Beachten Sie beim Konfigurieren geplanter Ausführungen und Orchestrierungs-Workflows für Ihr Repository die folgenden Best Practices, um eine zuverlässige Kompilierung zu gewährleisten:

  • Release-Konfigurationen für geplante Produktionsausführungen verwenden: Eine Release-Konfiguration kompiliert Ihren Repository-Code nach einem vorhersehbaren Zeitplan und speichert das resultierende Kompilierungsergebnis. Wenn Ihre Produktionsausführungspipelines ausgeführt werden, werden sie sofort für dieses gespeicherte Ergebnis ausgeführt, ohne dass Netzwerkanfragen an Ihr Remote-Git-Repository initiiert werden.
  • Commitish-Kompilierung auf Entwicklungs- und selten ausgeführte Aufgaben beschränken: Wenn Sie CreateCompilationResult direkt für einen Git-Commitish aufrufen, z. B. einen Branch, ein Tag oder einen Commit-SHA, muss Dataform das Repository bei jedem Aufruf über das Netzwerk klonen. Vermeiden Sie es, Cronjobs oder Orchestrierungs-DAGs für die Produktion so zu konfigurieren, dass sie wiederholt und mit hoher Frequenz aus einem Git-Commitish kompilieren.
  • Automatische Wiederholungsversuche und gestaffelte Zeitpläne konfigurieren: Wenn Ihre Architektur die Kompilierung aus einem Git-Commitish in externen Planern erfordert, konfigurieren Sie automatische Wiederholungsversuche mit exponentiellem Backoff und gestaffelten gleichzeitigen Cron-Timern. Detaillierte Codebeispiele für Wiederholungsversuche und Schritte zur Fehlerbehebung finden Sie unter Remote-Repository kann nicht erreicht werden.

Nächste Schritte