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

Artikel
04/23/2024

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 in diesem Artikel gelten sowohl für die SQL- als auch für die Python-Codeentwicklung.

Verwenden des Entwicklungsmodus zum Ausführen von Pipelineupdates

Delta Live Tables bietet eine Benutzeroberfläche, über die gesteuert werden kann, 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 Updates der Pipeline auszuführen, ohne auf den Start eines Clusters zu warten.
Im Entwicklungsmodus werden Vorgangsfehler nicht automatisch wiederholt, sodass Sie logische oder syntaktische Fehler in Ihrer Pipeline sofort erkennen und beheben können.

Databricks empfiehlt, den Entwicklungsmodus bei Entwicklung und Tests zu verwenden und bei der Bereitstellung in einer Produktionsumgebung immer in den Produktionsmodus zu wechseln.

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 virtuelle Schema LIVE, auf das außerhalb der Pipeline nicht zugegriffen werden kann. Wenn ein Zielschema angegeben wird, zeigt das virtuelle Schema LIVE auf dieses Zielschema. Um die während einer Aktualisierung in die einzelnen Tabellen geschriebenen Ergebnisse zu überprüfen, müssen Sie ein Zielschema angeben.

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.

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

Weitere Informationen finden Sie unter Veröffentlichen von Daten aus Delta Live Tables im Hive-Metastore.

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 der Änderungen von mehreren Entwickler*innen.
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 übernehmen die Benutzer*innen einen Commit und pushen Änderungen zurück an ihren Branch im zentralen Git-Repository. Anschließend öffnen sie einen Pull Request für den Test- oder QA-Branch.

Der resultierende Branch sollte in einem Databricks-Git-Ordner und einer Pipeline ausgecheckt werden, die mithilfe von Testdatasets und einem Entwicklungsschema konfiguriert wurde. 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 in verschiedenen Umgebungen zu synchronisieren, müssen Pipelineeinstellungen manuell oder mithilfe von 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).

Segmentieren von Bibliotheken für Erfassungs- und Transformationsschritte

Databricks empfiehlt, Abfragen für die Erfassung von Daten aus Transformationslogik, die Daten anreichert und überprüft, zu isolieren. Sie können dann Bibliotheken zum Erfassen von Daten aus Entwicklungs- oder Testdatenquellen in einem getrennten Verzeichnis von der Produktionsdaten-Erfassungslogik organisieren und dadurch sehr einfach Pipelines für verschiedene Umgebungen konfigurieren. Anschließend können Sie kleinere Datasets für Tests verwenden, um die Entwicklung zu beschleunigen. 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. Weitere Informationen finden Sie unter Steuern von Datenquellen mit Parametern.

Da Delta Live Tables-Pipelines für die Verwaltung aller Datasetbeziehungen das virtuelle Schema LIVE verwenden, können Sie Beispieldatasets mithilfe von Produktionstabellennamen zum Testen von Code konfigurieren, indem Sie Entwicklungs- und Testpipelines mit Erfassungsbibliotheken konfigurieren, die Beispieldatasets laden. Dieselbe Transformationslogik kann in allen Umgebungen verwendet werden.

Erstellen von Beispieldatasets für Entwicklung und Tests

Databricks empfiehlt das Erstellen von Entwicklungs- und Testdatasets, um die Pipelinelogik sowohl mit erwarteten Daten als auch mit potenziell beschädigten oder nicht wohlgeformten Datensätzen zu testen. 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 cloud_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 LIVE TABLE 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 LIVE TABLE 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.

Steuern von Datenquellen mit Parametern

Sie können in Ihren Bibliotheken auf Parameter verweisen, die bei der Pipelinekonfiguration festgelegt werden. Diese Parameter werden auf der Benutzeroberfläche der Pipelineeinstellungen im Bereich Compute > Erweitert > Konfigurationen als Schlüssel-Wert-Paare festgelegt. Mit diesem Muster können Sie verschiedene Datenquellen in unterschiedlichen Konfigurationen derselben Pipeline angeben.

Sie können beispielsweise verschiedene Pfade in Entwicklungs-, Test- und Produktionskonfigurationen für eine Pipeline mithilfe der Variablen data_source_path angeben und dann mit dem folgenden Code darauf verweisen:

SQL

CREATE STREAMING TABLE bronze
AS (
    SELECT
    *,
    _metadata.file_path AS source_file_path
    FROM cloud_files( '${data_source_path}', 'csv',
            map("header", "true"))
)

Python

import dlt
from pyspark.sql.functions import col

data_source_path = spark.conf.get("data_source_path")

@dlt.table
def bronze():
    return (spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "csv")
        .option("header", True)
        .load(data_source_path )
        .select("*", col("_metadata.file_path").alias("source_file_name"))
    )

Dieses Muster ist besonders nützlich, wenn Sie testen müssen, wie die Erfassungslogik Änderungen am Schema oder nicht wohlgeformte Daten bei der ersten Erfassung behandeln kann. Sie können den identischen Code in der gesamten Pipeline in allen Umgebungen verwenden, während Sie Datasets austauschen.

Freigeben über