Tipps, Empfehlungen und Features für das Entwickeln und Testen von Delta Live Tables-Pipelines

In diesem Artikel werden Muster beschrieben, die Sie zum Entwickeln und Testen von Delta Live Tables-Pipelines verwenden können. Über die Pipelineeinstellungen können Sie mit Delta Live Tables Konfigurationen angeben, um Pipelines in Entwicklungs-, Test- und Produktionsumgebungen zu isolieren. Die Empfehlungen dieses Artikels gelten für die Entwicklung von SQL- und Python-Code.

Databricks empfiehlt die Verwendung von Parametern zum Schreiben von erweiterbaren Delta Live Tables-Code. Dies ist besonders hilfreich beim Schreiben von portablem Code zwischen Entwicklungs-, Test- und Prod-Umgebungen. Beispielsweise können Sie Ihre Pipelines auf Testdaten mit bekannten Problemen verweisen, um die Coderesilienz zu testen. Weitere Informationen finden Sie unter Steuern von Datenquellen mit Parametern.

Verwenden des Entwicklungsmodus zum Ausführen von Pipelineupdates

Delta Live Tables verfügt über einen Benutzeroberflächenschalter, um zu steuern, ob Ihre Pipelineupdates im Entwicklungs- oder Produktionsmodus ausgeführt werden. Dieser Modus steuert die Verarbeitung von Pipelineupdates, einschließlich folgender Aspekte:

• Der Entwicklungsmodus beendet Computeressourcen nicht sofort, nachdem ein Update erfolgreich war oder ein Fehler dabei auftritt. Sie können dieselben Computeressourcen wiederverwenden, um mehrere Pipelineupdates auszuführen, ohne auf den Start eines Clusters zu warten.
• Im Entwicklungsmodus wird der Vorgangsfehler nicht automatisch wiederholt, sodass Sie logische oder syntaktische Fehler in Ihrer Pipeline sofort erkennen und beheben können.

Databricks empfiehlt die Verwendung des Entwicklungsmodus während der Entwicklung und tests. Wenn Sie jedoch in einer Produktionsumgebung bereitstellen, wechseln Sie immer in den Produktionsmodus.

Siehe Entwicklungs- und Produktionsmodi.

Testen des Pipelinequellcodes, ohne auf die Aktualisierung von Tabellen zu warten

Um Probleme mit Ihrem Pipelinequellcode zu untersuchen (z. B. Syntax- und Analysefehler während Entwicklung und Tests), können Sie ein Validate-Update ausführen. Da ein Validate-Update nur die Richtigkeit des Pipelinequellcodes überprüft, ohne ein tatsächliches Update für Tabellen auszuführen, können Sie Probleme schneller identifizieren und beheben, bevor Sie tatsächlich ein Pipelineupdate ausführen.

Angeben eines Zielschemas in allen Entwicklungs-Lebenszyklusphasen

Alle Datasets in einer Delta Live Tables-Pipeline verweisen auf das LIVE virtuelle Schema, auf das außerhalb der Pipeline nicht zugegriffen werden kann. Wenn ein Zielschema angegeben wird, zeigt das virtuelle Schema LIVE auf dieses Zielschema. Sie müssen ein Zielschema angeben, um die Ergebnisse zu überprüfen, die während einer Aktualisierung in jede Tabelle geschrieben wurden.

Sie müssen ein Zielschema angeben, das für Ihre Umgebung eindeutig ist. Jede Tabelle in einem bestimmten Schema kann nur von einer einzelnen Pipeline aktualisiert werden.

Sie können diese Umgebungen isolieren, indem Sie separate Pipelines für Entwicklung, Tests und Produktion mit unterschiedlichen Zielen erstellen. Mithilfe des Zielschemaparameters können Sie Logik entfernen, die Zeichenfolgeninterpolation oder andere Widgets oder Parameter zum Steuern von Datenquellen und Zielen verwendet.

Siehe Verwenden des Unity-Katalogs mit Ihren Delta Live Tables-Pipelines und Verwenden von Delta Live Tables-Pipelines mit legacy-Hive-Metaspeicher.

Verwenden von Databricks Git-Ordnern zum Verwalten von Delta Live Tables-Pipelines

Databricks empfiehlt die Verwendung von Git-Ordnern während Entwicklung und Tests von Delta Live Tables-Pipelines sowie bei der Bereitstellung in die Produktion. Git-Ordner ermöglichen Folgendes:

• Nachverfolgen der Veränderungen von Code im Lauf der Zeit.
• Zusammenführen von Änderungen, die mehrere Entwickler vornehmen.
• Softwareentwicklungsmethoden wie Codeüberprüfungen.

Databricks empfiehlt, ein einzelnes Git-Repository für den gesamten Code im Zusammenhang mit einer Pipeline zu konfigurieren.

Alle Entwickler*innen sollten einen eigenen Databricks-Git-Ordner für die Entwicklung konfiguriert haben. Während der Entwicklung konfigurieren Benutzer*innen eigene Pipelines aus dem Databricks-Git-Ordner und testen neue Logik mithilfe von Entwicklungsdatasets und isolierten Schemas und Speicherorten. Nach Abschluss der Entwicklungsarbeit verpflichtet sich der Benutzer und verschiebt Änderungen an seine Verzweigung im zentralen Git-Repository zurück und öffnet eine Pullanforderung für den Test- oder QA-Zweig.

Die resultierende Verzweigung sollte in einem Git-Ordner "Databricks" ausgecheckt werden, und eine Pipeline sollte mit Test-Datasets und einem Entwicklungsschema konfiguriert werden. Unter der Annahme, dass die Logik wie erwartet ausgeführt wird, sollte ein Pull Request oder Releasebranch vorbereitet werden, um die Änderungen in die Produktion zu übertragen.

Während Git-Ordner verwendet werden können, um Code über Umgebungen hinweg zu synchronisieren, müssen Pipelineeinstellungen manuell oder mit Tools wie Terraform auf dem neuesten Stand gehalten werden.

Dieser Workflow ähnelt der Verwendung von Git-Ordnern für CI/CD in allen Databricks-Aufträgen. Siehe CI/CD-Techniken mit Git- und Databricks-Git-Ordnern (Repos).

Segmentquellcode für Aufnahme- und Transformationsschritte

Databricks empfiehlt, Abfragen für die Erfassung von Daten aus Transformationslogik, die Daten anreichert und überprüft, zu isolieren. Wenn Sie Quellcode zum Aufnehmen von Daten aus Entwicklungs- oder Testdatenquellen in einem Verzeichnis organisieren, das von der Logik für die Erfassung von Produktionsdaten getrennt ist, können Sie Pipelines für verschiedene Umgebungen mit datenspezifischen Datasets für diese Umgebungen konfigurieren. Beispielsweise können Sie die Entwicklung beschleunigen, indem Sie kleinere Datasets zum Testen verwenden. Weitere Informationen finden Sie unter Erstellen von Beispieldatasets für Entwicklungen und Tests.

Sie können auch über Parameter Datenquellen für Entwicklung, Tests und Produktion steuern. Siehe Verwenden von Parametern mit Delta Live Tables-Pipelines.

Da Delta Live Tables-Pipelines das virtuelle Schema für die LIVE Verwaltung aller Datasetbeziehungen verwenden, können Sie durch Konfigurieren von Entwicklungs- und Testpipelines mit Ingestion-Quellcode, der Beispieldaten lädt, Beispieldaten mithilfe von Produktionstabellennamen zum Testen von Code ersetzen. Dieselbe Transformationslogik kann in allen Umgebungen verwendet werden.

Erstellen von Beispieldatasets 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, darunter die folgenden:

• Auswählen einer Teilmenge von Daten aus einem Produktionsdataset
• Verwenden von anonymisierten oder künstlich generierten Daten für Quellen mit personenbezogenen Informationen
• Erstellen von Testdaten mit klar definierten Ergebnissen basierend auf der nachgelagerten Transformationslogik
• Antizipieren von potenziellen Datenbeschädigungen, nicht wohlgeformten Datensätzen und Upstream-Datenänderungen durch Erstellen von Datensätzen, die nicht den Erwartungen des Datenschemas entsprechen

Beispielsweise können Sie über ein Notebook verfügen, das ein Dataset mit dem folgenden Code definiert:

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

Sie können ein Beispieldataset mit bestimmten Datensätzen erstellen, 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

Das folgende Beispiel veranschaulicht das Filtern veröffentlichter Daten, um eine Teilmenge der Produktionsdaten für 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 Notebooks, die die Transformationslogik implementieren. Jede Pipeline kann Daten aus dem LIVE.input_data-Dataset lesen, ist aber so konfiguriert, dass sie das Notebook enthält, das das für die Umgebung spezifische Dataset erstellt.