Freigeben über

Entwickeln von Delta Live Tables-Pipelines

  • Artikel

Das Entwickeln und Testen von Pipelinecode unterscheidet sich von anderen Apache Spark-Workloads. Dieser Artikel enthält eine Übersicht über unterstützte Funktionen, bewährte Methoden und Überlegungen bei der Entwicklung von Pipelinecode. Weitere Empfehlungen und bewährte Methoden finden Sie unter Anwenden bewährter Methoden für Softwareentwicklung und DevOps auf Delta Live Table-Pipelines.

Anmerkung

Sie müssen einer Pipelinekonfiguration Quellcode hinzufügen, um Code zu überprüfen oder ein Update auszuführen. Siehe Konfigurieren einer Delta Live Tables-Pipeline.

Welche Dateien sind für Pipelinequellcode gültig?

Pipelinecode für Delta Live Tables kann Python oder SQL sein. Sie können eine Mischung aus Python- und SQL-Quellcodedateien haben, die eine einzelne Pipeline sichern, aber jede Datei kann nur eine Sprache enthalten. Siehe Entwickeln von Pipelinecode mit Python und Entwickeln von Pipelinecode mit SQL.

Sie können Notizbücher und Arbeitsbereichsdateien verwenden, wenn Sie Quellcode für eine Pipeline angeben. Arbeitsbereichsdateien stellen Python- oder SQL-Skripts dar, die in Ihrer bevorzugten IDE oder dem Databricks-Datei-Editor erstellt wurden. Siehe Was sind Arbeitsbereichsdateien?.

Wenn Sie Python-Code als Module oder Bibliotheken entwickeln, müssen Sie den Code installieren und importieren und dann Methoden aus einem Python-Notizbuch oder einer Arbeitsbereichsdatei aufrufen, die als Quellcode konfiguriert ist. Siehe Verwalten von Python-Abhängigkeiten für Delta Live Tables-Pipelines.

Anmerkung

Wenn Sie beliebige SQL-Befehle in einem Python-Notizbuch verwenden müssen, können Sie das Syntaxmuster spark.sql("<QUERY>") verwenden, um SQL als Python-Code auszuführen.

Unity Catalog-Funktionen ermöglichen es Ihnen, beliebige benutzerdefinierte Python-Funktionen für die Verwendung in SQL zu registrieren. Siehe Benutzerdefinierte Funktionen (USER-Defined Functions, UDFs) im Unity-Katalog.

Übersicht über die Entwicklungsfeatures von Delta Live Tables

Delta Live Tables erweitert und nutzt viele Azure Databricks-Features und führt neue Features und Konzepte ein. Die folgende Tabelle enthält eine kurze Übersicht über Konzepte und Features, die die Entwicklung von Pipelinecode unterstützen:

Merkmal Beschreibung
Entwicklungsmodus Neue Pipelines sind standardmäßig so konfiguriert, dass sie im Entwicklungsmodus ausgeführt werden. Databricks empfiehlt die Verwendung des Entwicklungsmodus für interaktive Entwicklung und Tests. Siehe Entwicklungs- und Produktionsmodi.
Validieren Ein Validate Update überprüft die Richtigkeit des Pipelinequellcodes, ohne eine Aktualisierung in Tabellen durchzuführen. Siehe Überprüfen einer Pipeline auf Fehler, ohne darauf zu warten, dass Tabellenaktualisiert werden.
Notebooks Notizbücher, die als Quellcode für eine Delta Live Tables-Pipeline konfiguriert sind, bieten interaktive Optionen zum Überprüfen von Code und Ausführen von Updates. Siehe Entwickeln und Debuggen von Delta Live Tables-Pipelines in Notebooks.
Parameter Nutzen Sie Parameter in Quellcode- und Pipelinekonfigurationen, um Tests und Erweiterbarkeit zu vereinfachen. Siehe Verwenden von Parametern mit Delta Live Tables-Pipelines.
Databricks-Ressourcenbundles Databricks Asset Bundles ermöglichen es Ihnen, Pipelinekonfigurationen und Quellcode zwischen Arbeitsbereichen zu verschieben. Siehe Konvertieren einer Delta Live Tables-Pipeline in ein Databricks Asset Bundle-Projekt.

Erstellen von Beispieldatensätzen für Entwicklung und Tests

Databricks empfiehlt das Erstellen von Entwicklungs- und Testdatensätzen zum Testen der Pipelinelogik mit erwarteten Daten und potenziell fehlerhaften oder beschädigten Datensätzen. Es gibt mehrere Möglichkeiten zum Erstellen von Datasets, die für die Entwicklung und tests nützlich sein können, einschließlich der folgenden:

  • Wählen Sie eine Teilmenge von Daten aus einem Produktions-Dataset aus.
  • Verwenden Sie anonymisierte oder künstlich generierte Daten für Quellen, die PII enthalten.
  • Erstellen Sie Testdaten mit gut definierten Ergebnissen basierend auf der nachgeschalteten Transformationslogik.
  • Bereiten Sie sich auf potenzielle Datenbeschädigungen, falsch formatierte Datensätze und Änderungen an vorgelagerten Daten vor, indem Sie Datensätze erstellen, die die Vorgaben des Datenschemas nicht erfüllen.

Wenn Sie beispielsweise über ein Notizbuch verfügen, das ein Dataset mithilfe des folgenden Codes definiert:

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

Sie können ein Beispiel-Dataset erstellen, das bestimmte Datensätze enthält, indem Sie eine Abfrage wie die folgende verwenden:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

Im folgenden Beispiel wird das Filtern veröffentlichter Daten veranschaulicht, um eine Teilmenge der Produktionsdaten für die Entwicklung oder Tests zu erstellen:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Um diese verschiedenen Datasets zu verwenden, erstellen Sie mehrere Pipelines mit den Notizbüchern, die die Transformationslogik implementieren. Jede Pipeline kann Daten aus dem input_data-Dataset lesen, ist jedoch so konfiguriert, dass es das Notizbuch enthält, das das dataset speziell für die Umgebung erstellt.