Datenformular-Terminologie und Authentifizierungsprozesse verstehen |. Von Kabir Akande |

Verständnis der Dataform-Terminologien und des Authentifizierungsflusses: Dataform, ein GCP-Dienst, optimiert Datenpipelines durch die Einbindung bewährter Engineering-Praktiken und die Automatisierung der Workflow-Orchestrierung. Durch die Organisation von Code in Arbeitsbereichen, die Verwaltung von Konfigurationen und die Definition von Umgebungen ermöglicht Dataform eine effiziente Datentransformation und eine strukturierte Datenausgabe. Dieser Artikel befasst sich mit wichtigen Dataform-Terminologien, einschließlich Entwicklungsarbeitsbereichen, Release-Konfigurationen und Workflow-Konfigurationen, und untersucht den Authentifizierungsprozess mithilfe von Dienstkonten und Identitätswechsel.

MLOps: Data Pipeline Orchestration

MLOps: Datenpipeline-Orchestrierung

A Comprehensive Guide to Dataform Terminologies and Authentication Flow

Ein umfassender Leitfaden zu Datenform-Terminologien und Authentifizierungsfluss

Part 1 of Dataform 101: Fundamentals of a Single Repo, Multi-Environment Dataform with Least-Privilege Access Control and Infrastructure as Code Setup

Teil 1 von Dataform 101: Grundlagen eines Single-Repo-, Multi-Environment-Dataform mit Least-Privilege-Zugriffskontrolle und Infrastructure-as-Code-Setup

Introduction

Einführung

Dataform is an innovative service offered by Google Cloud Platform (GCP) that empowers teams to develop and operationalize sophisticated, SQL-based data pipelines. This groundbreaking platform seamlessly integrates software engineering best practices into the data pipeline lifecycle, unlocking a world of possibilities, including testing, environments, version control, dependency management, orchestration, and automated documentation. Essentially, Dataform serves as a serverless, SQL workflow orchestration engine within the GCP ecosystem. It ingests raw data, transforms it with the utmost engineering rigor, and produces meticulously structured data ready for consumption.

Dataform ist ein innovativer Dienst der Google Cloud Platform (GCP), der es Teams ermöglicht, anspruchsvolle, SQL-basierte Datenpipelines zu entwickeln und zu betreiben. Diese bahnbrechende Plattform integriert Best Practices für die Softwareentwicklung nahtlos in den Lebenszyklus der Datenpipeline und eröffnet so eine Welt voller Möglichkeiten, darunter Tests, Umgebungen, Versionskontrolle, Abhängigkeitsmanagement, Orchestrierung und automatisierte Dokumentation. Im Wesentlichen dient Dataform als serverlose SQL-Workflow-Orchestrierungs-Engine innerhalb des GCP-Ökosystems. Es nimmt Rohdaten auf, wandelt sie mit höchster technischer Präzision um und erzeugt sorgfältig strukturierte, gebrauchsfertige Daten.

Dataform Terminologies

Datenform-Terminologien

Navigating the world of Dataform can be a daunting task, especially for those new to its terminologies. To bridge this knowledge gap, let's delve into some key terms that will serve as a compass on your Dataform journey:

Sich in der Welt von Dataform zurechtzufinden, kann eine entmutigende Aufgabe sein, insbesondere für diejenigen, die mit deren Terminologie noch nicht vertraut sind. Um diese Wissenslücke zu schließen, befassen wir uns mit einigen Schlüsselbegriffen, die als Kompass auf Ihrer Dataform-Reise dienen:

Development Workspaces:

Entwicklungsarbeitsbereiche:

Similar to local GitHub branches, Dataform development workspaces provide an editable copy of the main Dataform repository code. Within these workspaces, code development and experimentation flourish. When the time comes to share your masterpiece with the world, simply commit and push your changes, and voilà, a remote branch will emerge, mirroring your development workspace.

Ähnlich wie lokale GitHub-Zweige stellen Dataform-Entwicklungsarbeitsbereiche eine bearbeitbare Kopie des Hauptcodes des Dataform-Repositorys bereit. In diesen Arbeitsbereichen gedeihen Codeentwicklung und Experimente. Wenn es an der Zeit ist, Ihr Meisterwerk mit der Welt zu teilen, schreiben Sie einfach Ihre Änderungen fest und pushen Sie sie, und voilà, es entsteht ein Remote-Zweig, der Ihren Entwicklungsarbeitsbereich widerspiegelt.

Release Configuration:

Release-Konfiguration:

Dataform seamlessly blends .sqlx scripts with JavaScript (.js) for data transformations and logic. To ensure the codebase is standardized and reproducible, Dataform employs a compilation process that transforms it into a machine-readable JSON config file. The orchestrator behind this compilation process is none other than release configuration. At a predetermined time, Dataform will diligently check out the code from a remote repository (which can be configured to target any branch) and weave its transformation magic, generating the JSON config file.

Dataform verbindet nahtlos .sqlx-Skripte mit JavaScript (.js) für Datentransformationen und Logik. Um sicherzustellen, dass die Codebasis standardisiert und reproduzierbar ist, verwendet Dataform einen Kompilierungsprozess, der sie in eine maschinenlesbare JSON-Konfigurationsdatei umwandelt. Der Orchestrator hinter diesem Kompilierungsprozess ist nichts anderes als die Release-Konfiguration. Zu einem festgelegten Zeitpunkt prüft Dataform sorgfältig den Code aus einem Remote-Repository (das so konfiguriert werden kann, dass es auf einen beliebigen Zweig abzielt) und webt seine Transformationsmagie, um die JSON-Konfigurationsdatei zu generieren.

Workflow Configuration:

Workflow-Konfiguration:

The output of release configuration – the JSON config file – serves as the foundation for workflow configuration. This configuration dictates when the config file should be executed, who should execute it, and where the config file's output should reside.

Die Ausgabe der Release-Konfiguration – die JSON-Konfigurationsdatei – dient als Grundlage für die Workflow-Konfiguration. Diese Konfiguration bestimmt, wann die Konfigurationsdatei ausgeführt werden soll, wer sie ausführen soll und wo sich die Ausgabe der Konfigurationsdatei befinden soll.

Since workflow configuration relies heavily on the JSON config file generated by release configuration, it's imperative to ensure that it runs after release configuration. This ensures that the latest changes are reflected in the BigQuery (BQ) tables without delay. If scheduled simultaneously, workflow configuration may utilize the previous compilation, resulting in a lag in reflecting the most up-to-date changes in the BQ tables until the next workflow configuration run.

Da die Workflow-Konfiguration stark von der durch die Release-Konfiguration generierten JSON-Konfigurationsdatei abhängt, muss unbedingt sichergestellt werden, dass sie nach der Release-Konfiguration ausgeführt wird. Dadurch wird sichergestellt, dass die neuesten Änderungen ohne Verzögerung in den BigQuery-Tabellen (BQ) widergespiegelt werden. Bei gleichzeitiger Planung nutzt die Workflow-Konfiguration möglicherweise die vorherige Kompilierung, was zu einer Verzögerung bei der Wiedergabe der aktuellsten Änderungen in den BQ-Tabellen bis zur nächsten Workflow-Konfigurationsausführung führt.

Environments:

Umgebungen:

One of Dataform's most sought-after features is its ability to manifest code into multiple environments, such as development, staging, and production. This flexibility poses a question: should repositories be created in multiple environments or consolidated into a single environment? Google, in its infinite wisdom, has weighed the pros and cons in its Dataform best practices section. This article will demonstrate how to configure Dataform for staging and production environments, with data materialized into both environments from a single repository.

Eine der gefragtesten Funktionen von Dataform ist die Fähigkeit, Code in mehreren Umgebungen wie Entwicklung, Staging und Produktion zu manifestieren. Diese Flexibilität wirft die Frage auf: Sollten Repositorys in mehreren Umgebungen erstellt oder in einer einzigen Umgebung konsolidiert werden? Google hat in seiner unendlichen Weisheit die Vor- und Nachteile im Abschnitt „Best Practices“ für Dataform abgewogen. In diesem Artikel wird gezeigt, wie Sie Dataform für Staging- und Produktionsumgebungen konfigurieren, wobei Daten aus einem einzigen Repository in beiden Umgebungen materialisiert werden.

Authentication

Authentifizierung

Authentication within Dataform can be a labyrinthine maze, especially when navigating multiple environments. To shed light on this intricate matter, we will delve into the specifics of staging and production environments.

Die Authentifizierung innerhalb von Dataform kann ein labyrinthisches Labyrinth sein, insbesondere beim Navigieren in mehreren Umgebungen. Um Licht in diese komplizierte Angelegenheit zu bringen, werden wir uns mit den Besonderheiten von Staging- und Produktionsumgebungen befassen.

Dataform Authentication Flow:

Datenform-Authentifizierungsablauf:

The diagram below captures the intricate dance of authentication within Dataform:

Das folgende Diagramm zeigt den komplizierten Ablauf der Authentifizierung innerhalb von Dataform:

[Image of Dataform authentication flow]

[Bild des Dataform-Authentifizierungsablaufs]

Machine User:

Maschinenbenutzer:

Dataform requires credentials to access GitHub when retrieving code stored on a remote repository. While using individual credentials is an option, the recommended path is to employ a machine user within an organization. This strategy ensures that Dataform's pipeline orchestration remains independent of individual identities and is not susceptible to their departure or whims. Setting up a machine user involves creating an identity that is not tied to an individual and using it to establish a GitHub account. For Dataform, a personal access token (PAT) is generated for the machine user account and safely tucked away as a secret in GCP's secret manager. The machine user should also be added as an outside collaborator to the Dataform remote repository with read and write access. We will unravel how Dataform is configured to access this secret in the Terraform code. If the user opts to use their own identity instead of a machine user, a token should be generated using the steps outlined here.

Dataform erfordert Anmeldeinformationen für den Zugriff auf GitHub, wenn Code abgerufen wird, der in einem Remote-Repository gespeichert ist. Die Verwendung individueller Anmeldeinformationen ist zwar eine Option, der empfohlene Weg besteht jedoch darin, einen Computerbenutzer innerhalb einer Organisation zu beschäftigen. Diese Strategie stellt sicher, dass die Pipeline-Orchestrierung von Dataform unabhängig von individuellen Identitäten bleibt und nicht anfällig für deren Abweichung oder Launen ist. Beim Einrichten eines Maschinenbenutzers muss eine Identität erstellt werden, die nicht an eine Person gebunden ist, und diese zum Einrichten eines GitHub-Kontos verwendet werden. Für Dataform wird ein persönliches Zugriffstoken (PAT) für das Maschinenbenutzerkonto generiert und sicher als Geheimnis im Secret Manager von GCP verstaut. Der Maschinenbenutzer sollte auch als externer Mitarbeiter zum Dataform-Remote-Repository mit Lese- und Schreibzugriff hinzugefügt werden. Wir werden enthüllen, wie Dataform konfiguriert ist, um auf dieses Geheimnis im Terraform-Code zuzugreifen. Wenn sich der Benutzer dafür entscheidet, seine eigene Identität anstelle eines Maschinenbenutzers zu verwenden, sollte mithilfe der hier beschriebenen Schritte ein Token generiert werden.

GitHub Authentication Flow:

GitHub-Authentifizierungsablauf:

Dataform leverages its default service account for implementation. When a Dataform action is initiated, it commences with the default service account. Assuming you have created a machine user, added them as a collaborator to the remote repository, and securely stored their PAT as a secret in GCP's secret manager, let's delve into the authentication process:

Dataform nutzt sein Standarddienstkonto für die Implementierung. Wenn eine Dataform-Aktion initiiert wird, beginnt sie mit dem Standarddienstkonto. Angenommen, Sie haben einen Maschinenbenutzer erstellt, ihn als Mitarbeiter zum Remote-Repository hinzugefügt und seine PAT sicher als Geheimnis im Secret Manager der GCP gespeichert. Sehen wir uns den Authentifizierungsprozess genauer an:

1. Extracting the Secret: The default service account requires the secretAccessor role to extract the secret from the secret manager.
2. Impersonating the Machine User: Armed with the secret, the default service account can now impersonate the machine user. Since the machine user is a collaborator on the remote Git repository, the default service account inherits access to the repository.

[Image of GitHub authentication workflow]

Extrahieren des Geheimnisses: Das Standarddienstkonto benötigt die Rolle „secretAccessor“, um das Geheimnis vom Geheimmanager zu extrahieren. Imitieren des Maschinenbenutzers: Ausgestattet mit dem Geheimnis kann das Standarddienstkonto nun die Identität des Maschinenbenutzers annehmen. Da der Maschinenbenutzer ein Mitarbeiter im Remote-Git-Repository ist, erbt das Standarddienstkonto den Zugriff auf das Repository. [Bild des GitHub-Authentifizierungsworkflows]

Development Workspace Authentication:

Authentifizierung des Entwicklungsarbeitsbereichs:

When execution is initiated from the development workspace, the default service account assumes the identity of the staging environment's custom service account to manifest the output within the staging environment. To successfully impersonate the staging environment's custom service account, the default service account must possess the iam.serviceAccountTokenCreator role. This role empowers the default service account to craft a short-lived token, akin to the PAT used to impersonate the machine user, for the staging custom service account and, thus, impersonate it. Consequently, the staging custom service account inherits all the necessary permissions to modify BQ tables, which are then inherited by the default service account when it impersonates the staging custom service account.

Wenn die Ausführung über den Entwicklungsarbeitsbereich initiiert wird, übernimmt das Standarddienstkonto die Identität des benutzerdefinierten Dienstkontos der Staging-Umgebung, um die Ausgabe in der Staging-Umgebung zu manifestieren. Um erfolgreich die Identität des benutzerdefinierten Dienstkontos der Staging-Umgebung zu übernehmen, muss das Standarddienstkonto über die Rolle „iam.serviceAccountTokenCreator“ verfügen. Diese Rolle ermächtigt das Standarddienstkonto, ein kurzlebiges Token zu erstellen, ähnlich dem PAT, das zum Nachahmen des Maschinenbenutzers für das benutzerdefinierte Staging-Dienstkonto verwendet wird, und so dieses nachzuahmen. Folglich erbt das benutzerdefinierte Staging-Dienstkonto alle erforderlichen Berechtigungen zum Ändern von BQ-Tabellen, die dann vom Standarddienstkonto geerbt werden, wenn es die Identität des benutzerdefinierten Staging-Dienstkontos annimmt.

Workflow Configuration Authentication:

Authentifizierung der Workflow-Konfiguration:

After successfully retrieving the code from the repository, release configuration generates a compiled config JSON file, which workflow configurations utilize to generate data. To commit this data to production BQ tables, the default service account requires the iam.serviceAccountTokenCreator role on the production custom service account. Similar to the process employed for the staging custom service account, the production service account is granted all the necessary permissions to modify production environment BQ tables, which are inherited by the default service account when it impersonates the production custom service account.

Nach dem erfolgreichen Abrufen des Codes aus dem Repository generiert die Release-Konfiguration eine kompilierte JSON-Konfigurationsdatei, die von Workflow-Konfigurationen zum Generieren von Daten verwendet wird. Um diese Daten in Produktions-BQ-Tabellen zu übernehmen, benötigt das Standarddienstkonto die Rolle „iam.serviceAccountTokenCreator“ für das benutzerdefinierte Produktionskonto. Ähnlich wie bei dem für das benutzerdefinierte Staging-Dienstkonto verwendeten Prozess werden dem Produktionsdienstkonto alle erforderlichen Berechtigungen zum Ändern der BQ-Tabellen der Produktionsumgebung erteilt, die vom Standarddienstkonto geerbt werden, wenn es die Identität des benutzerdefinierten Produktionsdienstkontos annimmt.

Conclusion

Abschluss

In summary, the default service account plays a pivotal role in Dataform's authentication architecture. It assumes the identity of the machine user to authenticate with GitHub as a collaborator, leveraging the machine user's PAT. It also authenticates with the staging and production environments by impersonating their respective custom service accounts using short-lived tokens generated with the serviceAccountTokenCreator role. Armed with this newfound understanding, we can confidently embark on the journey of provisioning Dataform within GCP using Terraform. Stay tuned for Part 2 of this article, where we will tackle this very subject. In the meantime, feel free to explore the code repository for further insights.

Zusammenfassend lässt sich sagen, dass das Standarddienstkonto eine zentrale Rolle in der Authentifizierungsarchitektur von Dataform spielt. Es geht von der Identität des Maschinenbenutzers aus, um sich bei GitHub als Mitarbeiter zu authentifizieren, und nutzt dabei die PAT des Maschinenbenutzers. Es authentifiziert sich auch bei den Staging- und Produktionsumgebungen, indem es die Identität der jeweiligen benutzerdefinierten Dienstkonten mithilfe kurzlebiger Token annimmt, die mit der Rolle „serviceAccountTokenCreator“ generiert wurden. Mit diesem neu gewonnenen Verständnis können wir uns getrost auf den Weg machen, Dataform innerhalb der GCP mithilfe von Terraform bereitzustellen. Seien Sie gespannt auf Teil 2 dieses Artikels, in dem wir uns genau diesem Thema widmen. In der Zwischenzeit können Sie gerne das Code-Repository erkunden, um weitere Einblicke zu erhalten.

References:

Verweise:

• [Dataform: Google Cloud](https://cloud.google.com/dataform?hl=en)
• [Dataform Migration: Google Cloud](https://cloud.google.com/dataform/docs/migration)
• [Dataform Best Practices: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)

[Dataform: Google Cloud](https://cloud.google.com/dataform?hl=en)[Dataform-Migration: Google Cloud](https://cloud.google.com/dataform/docs/migration)[Dataform Best Praktiken: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)