Best Practices für Repositories

In diesem Dokument finden Sie die folgenden Informationen zu Dataform-Repositories:

Übersicht über Best Practices für Repositories 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 Code-Lebenszyklus in Dataform.

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

Die Repository-Größe wirkt sich auf verschiedene Aspekte der Entwicklung in Dataform aus, z. B. auf:

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

Dataform erzwingt API-Kontingente und ‑Limits für Kompilierungsressourcen. Wenn Ihr Repository sehr groß ist, kann es sein, dass es diese Kontingente und Limits überschreitet. Dies kann dazu führen, dass die Kompilierung und Ausführung Ihres Workflows fehlschlagen.

Um dieses Risiko zu minimieren, empfehlen wir, große Repositories aufzuteilen. Wenn Sie ein großes Repository aufteilen, unterteilen Sie einen großen Workflow in eine Reihe kleinerer Workflows, die sich in verschiedenen Repositories befinden und durch repositoryübergreifende Abhängigkeiten verbunden sind.

Mit diesem Ansatz können Sie die Dataform-Kontingente und ‑Limits einhalten, präzise Prozesse und Berechtigungen implementieren und die Lesbarkeit und Zusammenarbeit im Code 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. Weitere Informationen zu Best Practices für das Aufteilen von Repositorys finden Sie unter Repositorys aufteilen.

Best Practices für die Repository-Struktur

Wir empfehlen, 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 BigQuery-Richtlinien für die Benennung von Tabellen entsprechen. Wir empfehlen, dass die Namen der Dateien im definitions-Verzeichnis 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 Standard-Codelebenszyklus in Dataform besteht aus den folgenden Phasen:

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

Weitere Informationen zum Code-Lebenszyklus in Dataform finden Sie unter Einführung in den Code-Lebenszyklus 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:

  • Entwicklungs- und Produktionstabellen nach Schema aufteilen
  • Entwicklungs- und Produktionstabellen nach Schema und Google Cloud -Projekt aufteilen.
  • Entwicklungs-, Staging- und Produktionstabellen nach Google Cloud Projekt aufteilen.

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

Um Identity and Access Management-Berechtigungen an jede Phase des Codelebenszyklus anzupassen, 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 Workflow-Entwicklung 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 Mitarbeiter an einem großen Repository arbeiten, kann dies zu einer übermäßigen Anzahl von Pull-Anfragen führen, was das Risiko von Merge-Konflikten erhöht.

  • Lesbarkeit der Codebasis: Eine größere Anzahl von Dateien, aus denen ein Workflow in einem einzelnen Repository besteht, 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. Bei einem großen Repository ist es schwierig, Entwicklungsprozesse an bestimmte Bereiche des Workflows anzupassen.

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

  • Workflow-Ausfü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 ist, desto länger dauert es, bis Dataform es ausführt.

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

Limits für Repository-Kompilierungsressourcen

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. In Dataform gelten Nutzungslimits für Kompilierungsressourcen.

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

  • Ein Fehler in Form einer Endlosschleife im Repository-Code.
  • Ein Speicherleck im Repository-Code.
  • Ein großes Repository mit etwa mehr als 1.000 Workflowaktionen.

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

Ressourcennutzung für die Kompilierung Ihres Repositorys schätzen

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

  • CPU-Zeitnutzung.
  • Maximale Gesamtgröße der serialisierten Daten des generierten Diagramms der in Ihrem Repository definierten Aktionen.

Um eine ungefähre Schätzung der aktuellen CPU-Zeit für die Kompilierung für die Kompilierung Ihres Repositorys zu erhalten, können Sie die Kompilierung Ihres Dataform-Workflows auf einem lokalen Linux- oder macOS-Computer zeitlich erfassen.

  • Um die Kompilierung Ihres Workflows zu messen, 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 ungefähren Indikator für die CPU-Zeit verwenden, die für die Kompilierung Ihres Repositorys benötigt wird.

Um eine ungefähre Schätzung der Gesamtgröße des generierten Diagramms der Aktionen in Ihrem Repository zu erhalten, können Sie die Ausgabe des Diagramms in eine JSON-Datei schreiben. Die Größe der unkomprimierten JSON-Datei kann als grober Indikator für die Gesamtgröße des Diagramms betrachtet werden.

  • Wenn Sie die Ausgabe des kompilierten Diagramms Ihres Workflows in eine JSON-Datei schreiben möchten, führen Sie den folgenden Dataform-CLI-Befehl in Ihrem Repository aus:

    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 beschrieben.

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

Das Aufteilen eines Repositorys in Dataform bietet folgende Vorteile:

  • Dataform-Limits für die Nutzung von Kompilierungsressourcen einhalten. Wenn Sie einen großen Workflow in mehrere kleinere Repositorys aufteilen, sinkt das Risiko, dass die Dataform-Limits für Kompilierungsressourcen überschritten werden.
  • Prozesse verfeinern. Sie können Prozesse wie CI-Regeln (Continuous Integration) für jedes Split-Fragment Ihres Workflows und das dafür zuständige Team individuell festlegen.
  • Detaillierte Berechtigungen. Sie können Berechtigungen für jedes Split-Fragment Ihres Workflows und das dafür zuständige Team individuell festlegen, um die allgemeine Sicherheit des Workflows zu erhöhen.
  • Die Zusammenarbeit wird verbessert, indem die Anzahl der Mitbearbeiter minimiert wird, die an den einzelnen aufgeteilten Fragmenten Ihres Workflows arbeiten.
  • Bessere Lesbarkeit der Codebasis. Wenn Sie die Dateien, aus denen ein großer Workflow besteht, in mehrere Repositorys aufteilen, ist es einfacher, in jedem Repository einzeln zu navigieren, als den gesamten Workflow auf einmal zu durchsuchen.
  • Die Workflowausführung jedes aufgeteilten Fragments Ihres Workflows wird im Vergleich zur Ausführung des gesamten Workflows beschleunigt.

Das Aufteilen eines Repositorys in Dataform hat folgende Nachteile:

  • Benutzerdefinierte CI/CD-Konfiguration (Continuous Integration/Continuous Development), die für jedes Dataform-Repository und das zugehörige Git-Repository erforderlich ist.
  • Für jedes Dataform-Repository und das zugehörige Git-Repository ist eine benutzerdefinierte Konfiguration für die Zeitplanung erforderlich.
  • Schwierigkeiten bei der Verwaltung von Abhängigkeiten zwischen den Objekten Ihres Workflows, die in mehreren Repositories gespeichert sind.
  • Es gibt keine 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 vollständigen 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 sich in separaten Dataform-Repositories befinden.

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, in dem die Inhalte des zentralen Repositorys als Datenquellen verwendet werden.

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

Repository-übergreifende Abhängigkeiten verwalten

Die effizienteste Methode zum Aufteilen eines Repository besteht darin, den übergeordneten SQL-Workflow in in sich geschlossene untergeordnete Workflows aufzuteilen und so unabhängige Repositorys zu 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 Repositorys aufteilen, in denen ein Repository von seinem Vorgänger abhängt und eine Datenquelle für seinen Nachfolger ist. Die Reihenfolge der Repositories und ihrer Abhängigkeiten muss die Struktur Ihres übergeordneten Workflows am besten widerspiegeln.

Mit Dataform-Datenquellendeklarationen können Sie Abhängigkeiten zwischen Repositories erstellen. Sie können einen BigQuery-Tabellentyp aus einem anderen Dataform-Repository als Datenquelle in dem Repository deklarieren, das gerade bearbeitet wird. Nachdem Sie eine Datenquelle deklariert haben, können Sie darauf wie auf jede andere Dataform-Workflow-Aktion verweisen und sie zum Entwickeln Ihres Workflows verwenden.

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

Wir empfehlen, ein Repository nicht in eine Gruppe von Repositories mit bidirektionalen Abhängigkeiten aufzuteilen. Eine bidirektionale Abhängigkeit zwischen Repositorys tritt auf, wenn ein Repository eine Datenquelle für ein anderes Repository ist und dieses Repository auch als Datenquelle verwendet. Zwei-Wege-Abhängigkeiten zwischen Repositorys 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 Workflow-Dateien 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 gibt folgende Gründe, den Workflow-Code im Verzeichnis definitions zu strukturieren:

  • Die Zusammenarbeit am Code verbessern, indem Sie Teams bestimmten Teilen Ihres Workflows zuweisen.
  • Die Wartungsfreundlichkeit des Workflows bei organisatorischen Änderungen wird verbessert.
  • Die Navigation durch Ihren Code verbessern
  • Die Skalierbarkeit der Codebasis verbessern.
  • Der Verwaltungsaufwand für Ihr Team wird minimiert.

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äftliche oder analytische Zwecke 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 keinen zusätzlichen Prozessen oder Tools wie Business Intelligence-Tools (BI) ausgesetzt sind, nachdem Dataform sie in BigQuery ausgeführt hat.
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 die zusätzliche Verwendung vorbereitet wurden, z. B. für maschinelles Lernen. 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.

Im Unterverzeichnis sources werden Datenquellendeklarationen und Tabellen gespeichert, mit denen Spalten gefiltert, kategorisiert, umgewandelt oder umbenannt werden.

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, weisen Sie jedem Pool ein Unterverzeichnis zu.

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 im selben Schema 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.

Im folgenden Codebeispiel sind mehrere Datenquellen in einem Schema zu sehen, die in einer einzelnen JavaScript-Datei deklariert werden:

[
  "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 Datenquelldeklaration 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 von Rohdaten-Quelltabellen. Mit diesem Ansatz können Sie die Quelltabellen testen. Wenn sich eine Quelltabelle ändert, können Sie ihre Ansicht anpassen, z. B. durch Hinzufügen von Filtern oder Umwandeln 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, mit denen Quelldaten aus einer oder mehreren Quellen im Unterverzeichnis sources erheblich transformiert werden, z. B. Tabellen, in denen Daten zusammengeführt werden. In Tabellen im Unterverzeichnis intermediate werden in der Regel Daten aus Quelltabellen oder anderen intermediate-Tabellen abgefragt.

Mit intermediate-Tabellen können Sie outputs-Tabellen erstellen. In der Regel werden intermediate-Tabellen nach der Ausführung durch Dataform in BigQuery nicht für zusätzliche Zwecke verwendet, z. B. für die Datenanalyse. intermediate-Tabellen können als die Logik für die Datentransformation betrachtet werden, die die Erstellung von Ausgabetabellen ermöglicht.

Wir empfehlen, alle intermediate-Tabellen zu dokumentieren und 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. In Tabellen im Verzeichnis outputs werden in der Regel Daten aus den Tabellen intermediate abgefragt.

Gruppieren Sie outputs-Tabellen nach der Geschäftseinheit, auf die sie sich beziehen, z. B. Marketing, Bestellungen oder Analysen. Weisen Sie jeder Rechtspersönlichkeit ein Unterverzeichnis zu.

Wenn Sie Ausgabetabellen separat in BigQuery speichern möchten, können Sie ein separates 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 Rechtssubjekten 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 testen.

Namenskonvention

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

Wir empfehlen, dass die Namen der Dateien im definitions-Verzeichnis 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 angeben, damit Mitarbeiter intermediate-Dateien eindeutig 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 Unterverzeichnissen für Rechtspersönlichkeiten haben, fügen Sie ein Präfix hinzu, das die Rechtspersönlichkeit identifiziert, z. B. sales_revenue.sqlx oder ads_revenue.sqlx.

Im folgenden Beispiel sehen Sie 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

Nächste Schritte