Transformieren von Daten
In diesem Artikel finden Sie eine Einführung und eine Übersicht über das Transformieren von Daten mit Azure Databricks. Das Transformieren von Daten oder das Vorbereiten von Daten ist ein wichtiger Schritt in allen Datentechnik-, Analyse- und ML-Workloads.
Der Schwerpunkt der Beispielmuster und Empfehlungen in diesem Artikel liegt auf die Arbeit mit Lakehousetabellen, die auf Delta Lake basieren. Da Delta Lake die ACID-Garantien eines Databricks-Lakehouse bietet, werden Sie beim Arbeiten mit Daten in anderen Formaten oder Datensystemen möglicherweise abweichende Verhaltensweisen beobachten.
Databricks empfiehlt das Erfassen von Daten in einem Lakehouse in einem unformatierten oder nahezu unformatierten Zustand und das anschließende Anwenden von Transformationen und Anreicherung in einem separaten Verarbeitungsschritt. Dieses Muster wird als Medaillenarchitektur bezeichnet. Siehe Worum handelt es sich bei der Medallion- Lakehouse-Architektur?.
Wenn Sie wissen, dass die Daten, die Sie transformieren müssen, noch nicht in ein Lakehouse geladen wurden, lesen Sie Erfassen von Daten in einem Databricks-Lakehouse. Wenn Sie versuchen, Lakehousedaten zu finden, um dafür Transformationen zu schreiben, lesen Sie Entdecken von Daten.
Alle Transformationen beginnen mit dem Schreiben einer Batch- oder Streamingabfrage für eine Datenquelle. Wenn Sie mit dem Abfragen von Daten nicht vertraut sind, lesen Sie Abfragen von Daten.
Nachdem Sie transformierte Daten in einer Delta-Tabelle gespeichert haben, können Sie diese Tabelle als Featuretabelle für Machine Learning verwenden. Siehe Feature Engineering und Featurebereitstellung.
Hinweis
In diesen Artikeln werden Transformationen in Azure Databricks behandelt. Azure Databricks unterstützt auch Verbindungen mit vielen gängigen Plattformen zur Datenaufbereitung. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit einem Partner für die Datenaufbereitung mithilfe von Partner Connect.
Spark-Transformationen im Vergleich zu Lakehousetransformationen
In diesem Artikel geht es die Definition von Tranformationen im Zusammenhang mit dem T in ETL oder ELT. Beim Apache Spark-Verarbeitungsmodell wird das Wort Transformation auf ähnliche Weise verwendet. Kurz gesagt: In Apache Spark sind alle Vorgänge entweder als Transformationen oder Aktionen definiert.
- Transformationen: fügen dem Plan Verarbeitungslogik hinzu. Beispiele sind das Lesen von Daten, Joins, Aggregationen und Typumwandlungen.
- Aktionen: lösen Verarbeitungslogik zum Auswerten und Ausgeben von Ergebnissen aus. Beispiele sind Schreibvorgänge, das Anzeigen der Ergebnisse oder einer Vorschau der Ergebnisse, das manuelle Zwischenspeichern oder das Abrufen der Zeilenanzahl.
Apache Spark verwendet ein Modell mit verzögerter Ausführung. Das bedeutet, dass die durch eine Sammlung von Vorgängen definierte Logik er ausgewertet wird, wenn eine Aktion ausgelöst wird. Dieses Modell hat eine erhebliche Auswirkung auf das Definieren von Datenverarbeitungspipelines: Verwenden Sie Aktionen nur, um Ergebnisse wieder in einer Zieltabelle zu speichern.
Da Aktionen einen Verarbeitungsengpass bei der Optimierung der Logik darstellen, bietet Azure Databricks zahlreiche Optimierungen, die bereits in Apache Spark vorhanden sind, um eine optimale Ausführung der Logik zu gewährleisten. Diese Optimierungen berücksichtigen alle Transformationen, die von einer bestimmten Aktion gleichzeitig ausgelöst werden, um den optimalen Plan basierend auf dem physischen Layout der Daten zu ermitteln. Das manuelle Zwischenspeichern von Daten oder das Zurückgeben von Vorschauergebnissen in Produktionspipelines kann diese Optimierungen unterbrechen und zu einem erheblichen Anstieg bei Aufwand und Latenz führen.
Aus diesem Grund können Sie eine Lakehousetransformation definieren, um eine beliebige Sammlung von Vorgängen zu definieren, die auf einen oder mehrere Lakehousetabellen angewandt werden und zu einer neuen Lakehousetabelle führen. Beachten Sie, dass Transformationen wie Joins und Aggregationen zwar separat behandelt werden, Sie aber viele dieser Muster in einem einzigen Verarbeitungsschritt kombinieren können. Die Optimierer in Azure Databricks werden dann den effizientesten Plan finden.
Was sind die Unterschiede zwischen Streaming- und Batchverarbeitung?
Streaming- und Batchverarbeitung sind bei der Syntax in Azure Databricks größtenteils identisch, verfügen alle über eine eigene spezifische Semantik.
Mit der Batchverarbeitung können Sie explizite Anweisungen zum Verarbeiten einer festen Menge statischer, nicht veränderlicher Daten in einem einzelnen Vorgang definieren.
Bei der Streamingverarbeitung können Sie eine Abfrage für ein ungebundenes, kontinuierlich wachsendes Dataset definieren und dann Daten in kleinen, inkrementellen Batches verarbeiten.
Für Batchvorgänge werden in Azure Databricks Spark SQL oder DataFrames verwendet, während für die Streamingverarbeitung das strukturiertes Streaming genutzt wird.
Sie können Apache Spark-Batchbefehle von strukturiertem Streaming unterscheiden, indem Sie die Lese- und Schreibvorgänge vergleichen, wie in der folgenden Tabelle dargestellt:
| Apache Spark | Strukturiertes Streaming | |
|---|---|---|
| Lesen | spark.read.load() |
spark.readStream.load() |
| Schreiben | spark.write.save() |
spark.writeStream.start() |
Materialisierte Sichten erfüllen in der Regel die Garantien der Batchverarbeitung, obwohl zum inkrementellen Berechnen der Ergebnisse nach Möglichkeit Delta Live Tables verwendet wird. Die von einer materialisierten Sicht zurückgegebenen Ergebnisse entsprechen immer der Batchauswertung der Logik, Azure Databricks versucht aber, diese Ergebnisse nach Möglichkeit inkrementell zu verarbeiten.
Streamingtabellen berechnen die Ergebnisse immer inkrementell. Da viele Streamingdatenquellen Datensätze nur für einen Zeitraum von einigen Stunden oder Tagen aufbewahren, wird bei dem von Streamingtabellen verwendeten Verarbeitungsmodell davon ausgegangen, dass jeder Datensatzbatch aus einer Datenquelle nur einmal verarbeitet wird.
Azure Databricks unterstützt die Verwendung von SQL zum Schreiben von Streamingabfragen in den folgenden Anwendungsfällen:
- Definieren von Streamingtabellen in Unity Catalog mithilfe von Databricks SQL
- Definieren des Quellcodes für Delta Live Tables-Pipelines
Hinweis
Sie können Streamingtabellen auch in Delta Live Tables mithilfe von Python-Code für strukturiertes Streaming deklarieren.
Batchtransformationen
Batchtransformationen werden zu einem bestimmten Zeitpunkt mit gut definierten Datenressourcen ausgeführt. Batchtransformationen können einmalige Vorgänge sein. Häufig sind sie jedoch Teil geplanter Aufträge oder Pipelines, die regelmäßig ausgeführt werden, um Produktionssysteme auf dem neuesten Stand zu halten.
Inkrementelle Transformationen
Bei inkrementellen Mustern wird in der Regel davon ausgegangen, dass die Datenquelle nur Anfügungen zulässt und über ein stabiles Schema verfügt. In den folgenden Artikeln finden Sie Details zu Eigenheiten von inkrementellen Transformationen in Tabellen mit Aktualisierungen, Löschungen oder Schemaänderungen:
- APPLY CHANGES-API: Vereinfachtes CDC (Change Data Capture) in Delta Live Tables
- Verwenden Sie den Delta Lake-Änderungs-Datenfeed in Azure Databricks
- Aktualisieren des Delta Lake-Tabellenschemas
- Delta-Tabelle: Streaming für Lese- und Schreibvorgänge
Echtzeittransformationen
Delta Lake zeichnet sich durch die Bereitstellung von Zugriff in Quasi-Echtzeit auf große Datenmengen für alle Benutzerinnen/Benutzer und Anwendungen aus, die Ihr Lakehouse abfragen. Aufgrund des Aufwands beim Schreiben von Dateien und Metadaten in den Cloudobjektspeicher kann die tatsächliche Echtzeitlatenz für viele Workloads, die in Delta Lake-Senken schreiben, nicht erreicht werden.
Für extrem latenzarme Streaminganwendungen empfiehlt Databricks die Auswahl von Quell- und Senkensystemen, die für Echtzeitworkloads konzipiert wurden, wie z. B. Kafka. Sie können Azure Databricks verwenden, um Daten anzureichern. Dies schließt auch Aggregationen, Joins über Streams hinweg und das Verknüpfen von Streamingdaten mit langsam veränderlichen Dimensionsdaten ein, die im Lakehouse gespeichert sind.