Entwerfen der Erfassungslogik und der Datenquellenkonfiguration

Das Entwerfen von Aufnahmelogik erfordert, dass Sie wichtige Entscheidungen darüber treffen, wie Daten von Quellsystemen in Azure Databricks verschoben werden. Diese Entscheidungen wirken sich auf Aktualität, Verarbeitungseffizienz und Systemsicherheit aus. Bevor Sie Tools auswählen oder Code schreiben, müssen Sie die Merkmale Ihrer Datenquellen verstehen und Extraktionsstrategien definieren, die ihren Geschäftsanforderungen entsprechen.

In dieser Lektion untersuchen Sie die wichtigsten Entwurfsaspekte für die Datenaufnahmelogik und die Datenquellenkonfiguration in Azure Databricks. Der Schwerpunkt liegt hier auf konzeptionellen Logik- und Entwurfsmustern– spezifische Toolauswahl- und Implementierungsdetails werden in späteren Einheiten behandelt.

Grundlegendes zu Extraktionstypen

Der Extraktionstyp bestimmt, wie Sie Daten aus Quellsystemen erfassen und beeinflusst sowohl die Aktualität als auch die Effizienz Ihrer Datenpipeline. Azure Databricks unterstützt drei primäre Extraktionsmuster, die jeweils für unterschiedliche Szenarien geeignet sind.

Vollständige Extraktion

Vollständige Extraktion liest bei jedem Erfassungslauf den gesamten Datensatz aus dem Quellsystem.

Dieser Ansatz funktioniert gut, wenn:

• Quellsysteme unterstützen die Änderungsnachverfolgung nicht
• Die Datenvolumen sind klein genug, um sie effizient neu zu verarbeiten.
• Sie müssen die Zieltabellen regelmäßig von Grund auf neu erstellen.
• Datenbeziehungen sind komplex und inkrementelle Logik wäre fehleranfällig

Die vollständige Extraktion wird unpraktisch, da Datenvolumes wachsen. Die Neuverarbeitung von Millionen von Datensätzen, wenn sich nur ein paar Tausend geändert haben, verschwendet Computerressourcen und verzögert nachgelagerte Verbraucher.

Inkrementelle Extraktion

Inkrementelle Extraktion verarbeitet nur neue oder geänderte Datensätze seit der letzten Aufnahmeausführung. Das Modul verfolgt, welche Daten verarbeitet wurden, und fragt nur nach Updates ab.

Dieses Muster erfordert Folgendes:

• Ein zuverlässiger Änderungsindikator in den Quelldaten (Zeitstempel, Sequenznummer oder Versionsspalte)
• Zustandsverwaltung zum Nachverfolgen der letzten verarbeiteten Position
• Logik für die Behandlung von spät ankommenden oder unreihenfolgegemäßen Datensätzen

Die inkrementelle Extraktion verbessert die Effizienz für große Datasets erheblich. Anstatt Millionen von Zeilen zu lesen, können Sie nur Tausende von Änderungen pro Ausführung verarbeiten.

Streamingextraktion

Die Streamingextraktion bietet nahezu Echtzeitdatenerfassung durch kontinuierliche Verarbeitung. Anstatt nach einem Zeitplan auszuführen, bleiben Streamingaufträge aktiv und verarbeiten Datensätze, sobald sie eingehen.

Ziehen Sie Streaming in Betracht, wenn:

• Geschäftsprozesse erfordern aktuelle Daten in einem Zeitrahmen von Sekunden oder Minuten.
• Quellsysteme veröffentlichen Ereignisse in Nachrichtenbussen oder Änderungsfeeds
• Sie müssen auf auftretende Ereignisse reagieren.

Die Streamingextraktion erfordert eine ständig verfügbare Infrastruktur, liefert aber die niedrigste Latenz zur Sicherstellung der Datenverfügbarkeit.

Entwurf für die Datenerfassung von Änderungen

Change Data Capture (CDC) ist ein spezielles Extraktionsmuster, das einzelne Änderungen auf Zeilenebene erfasst, einschließlich Einfügungen, Aktualisierungen und Löschungen. CDC unterscheidet sich von der einfachen inkrementellen Extraktion, da der Vorgangstyp für jede Änderung erhalten bleibt.

Berücksichtigen Sie beim Entwerfen für CDC, wie Ihr Quellsystem Änderungsdatensätze erzeugt:

• Datenbanktransaktionsprotokolle: Datenbanken wie SQL Server können Änderungen auf Zeilenebene mithilfe der auf transaktionsprotokollbasierten CDC-Funktion verfügbar machen. Nachgeschaltete Systeme wie Azure Databricks können diese Änderungen dann lesen und als Teil der Aufnahmepipeline verarbeiten.
• Änderungsdatenfeeds: Delta-Tabellen und einige Datenbanken wie Azure Cosmos DB bieten integrierte Änderungsnachverfolgung, die Zeilenänderungen mit Metadaten anzeigt.
• Regelmäßige Momentaufnahmen: Einige Systeme unterstützen kein kontinuierliches CDC, sodass Sie Momentaufnahmen vergleichen müssen, um Änderungen zu bestimmen.

CDC ermöglicht Anwendungsfälle, die eine einfache inkrementelle Extraktion nicht unterstützen können. Sie können Löschungen präzise replizieren, Audit-Trails verwalten und Aktualisierungen verarbeiten, die Schlüsselspalten ändern.

Identifizieren der Eigenschaften des Quelldateityps

Wenn Daten als Dateien statt von Transaktionssystemen eintreffen, beeinflusst das Dateiformat Ihren Aufnahmeentwurf. Jedes Format weist unterschiedliche Merkmale auf, die sich auf die Verarbeitung auswirken.

Textbasierte Formate

CSV- und JSON-Dateien sind gängige Quellformate, da sie lesbar und weit verbreitet sind. Sie stellen jedoch Herausforderungen für eine effiziente Verarbeitung dar:

• Schemavariabilität: Dateien können inkonsistente Spaltenreihenfolgen, fehlende Felder oder Datentypvariationen aufweisen.
• Keine Komprimierungseffizienz: Textformate verbrauchen in der Regel mehr Speicher als binäre Alternativen
• Analyseaufwand: Jeder Wert erfordert eine Konvertierung von Text zu Typ während der Lesevorgänge.

Verwenden Sie textbasierte Formate, wenn Quellsysteme diese Formate nur erzeugen können oder wenn Datenvolumes klein genug sind, sodass Effizienzprobleme nicht gelten.

Spaltenformate

Parkett - und ORC-Dateien speichern Daten im Spaltenformat, wodurch effiziente analytische Abfragen ermöglicht werden. Diese Formate bieten:

• Komprimierung: Spaltenspeicher erzielt bessere Komprimierungsverhältnisse durch Gruppieren ähnlicher Werte
• Spaltenkürzung: Abfragen lesen nur die benötigten Spalten, wodurch E/A reduziert wird
• Eingebettetes Schema: Die Datei enthält Metadaten zur Beschreibung von Spaltennamen und -typen.

Entwerfen Sie Ihr Ingestion-Design so, dass spaltenbasierte Quellformate bevorzugt werden, wenn Sie kontrollieren können, wie Upstream-Systeme Daten exportieren.

Semistrukturierte Formate

XML- und geschachtelte JSON-Dateien stellen hierarchische Daten dar, die nicht in eine flache tabellarische Struktur passen. Beim Aufnehmen halbstrukturierter Daten:

• Planung der Schemaextraktion oder -definition.
• Entscheiden Sie, ob Sie die Struktur abflachen oder die Schachtelung beibehalten wollen.
• Berücksichtigen Sie unterschiedliche Dokumentstrukturen innerhalb derselben Quelle.

Überlegungen zur Datenquellenverbindung

Die Datenquellenkonfiguration definiert, wie Azure Databricks eine Verbindung mit Quellsystemen herstellt und authentifiziert. Ihr Design muss die Verbindungssicherheit, die Anmeldeinformationsverwaltung und Zugriffsmuster adressieren.

Cloudobjektspeicherquellen

Cloudspeicher (Azure Data Lake Storage, Amazon S3 oder Google Cloud Storage) dient als häufigste Anlaufstelle für die Datenerfassung. Beim Konfigurieren von Speicherverbindungen:

• Verwenden Sie externe Speicherorte des Unity-Katalogs, um den Zugriff auf Speicherpfade zu steuern.
• Konfigurieren Sie geeignete Authentifizierungsmethoden (verwaltete Identität, Dienstprinzipale oder Speicheranmeldeinformationen).
• Entwerfen Sie Ordnerstrukturen, die eine effiziente inkrementelle Verarbeitung unterstützen.

Die Ordnerstruktur beeinflusst erheblich, wie effizient Azure Databricks neue Dateien identifizieren und verarbeiten kann. Berücksichtigen Sie diese Muster:

Datumsbasierte Partitionierung: Organisieren Sie Dateien nach Datumshierarchie, um die Partitionsbereinigung während inkrementeller Lesevorgänge zu ermöglichen:

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

Diese Struktur ermöglicht Abfragen, nur relevante Datumspartitionen zu scannen, anstatt alle Dateien aufzulisten.

Quellbasierte Organisation: Wenn Sie aus mehreren Quellen aufnehmen, trennen Sie Daten nach Quellsystem, um die Verarbeitungslogik zu vereinfachen:

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

Verarbeiten von Statusordnern: Verwenden Sie separate Ordner, um den Dateiverarbeitungsstatus nachzuverfolgen:

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

Berücksichtigen Sie beim Entwerfen von Ordnerstrukturen Folgendes:

• Dateiermittlungsaufwand: Flache Strukturen mit Tausenden von Dateien verlangsamen auflistungsvorgänge. Partitionierte Strukturen verringern die Dateien, die Azure Databricks aufzählen müssen.
• Kompatibilität des automatischen Ladevorgangs: Azure Databricks Auto Loader verfolgt neue Dateien im Cloudspeicher effizient nach. Strukturieren Sie die Ordner so, dass sie mit der Art und Weise übereinstimmen, wie der Auto Loader Dateien findet und überprüft.
• Partitionsspaltenextraktion: Verwenden Sie strukturbasierte Partitionierung (key=value), damit Azure Databricks Partitionswerte automatisch als Spalten extrahieren können, ohne Dateiinhalte zu analysieren.

Datenbankquellen

Das Herstellen einer Verbindung mit Transaktionsdatenbanken erfordert unterschiedliche Überlegungen als Cloudspeicher:

• Netzwerkkonnektivität zwischen Azure Databricks und dem Datenbankserver.
• Die sicher gespeicherten Authentifizierungsanmeldeinformationen (verwenden geheime Schlüssel anstelle hartcodierter Werte).
• Verbindungspooling- und Abfrage-Pushdownfunktionen.
• Auswirkungen auf die Leistung des Quellsystems während der Extraktion.

Streamingquellen

Nachrichtenbusse und Ereignisstreams (z. B. Azure Event Hubs oder andere gängige Messagingplattformen) erfordern Folgendes:

• Brokerverbindungsdetails und Authentifizierung.
• Konfiguration der Konsumentengruppe für die parallele Verarbeitung.
• Offset-Verwaltung zur Verfolgung der Verbrauchsposition.
• Schema-Registrierungs-Integration für die Validierung des Nachrichtenformats.

SaaS-Anwendungsquellen

Unternehmensanwendungen wie Salesforce, ServiceNow oder SAP machen Daten über APIs mit eindeutigen Merkmalen verfügbar:

• API-Geschwindigkeitsbeschränkungen, die den Extraktionsdurchsatz einschränken.
• Paginierungsstrategien für große Ergebnismengen.
• Authentifizierungsflüsse (OAuth, API-Schlüssel oder zertifikatbasiert).
• Verfügbare Änderungsnachverfolgungs- oder Webhook-Funktionen.

Anwenden eines anforderungsgesteuerten Entwurfsframeworks

Der effektive Erfassungsentwurf beginnt mit der Analyse von Anforderungen, bevor Extraktionstypen oder Dateiformate ausgewählt werden. Verwenden Sie das folgende wiederholbare Framework, um Ihre Entwurfsentscheidungen zu leiten.

Schritt 1: Erfassen der Anforderungen

Beantworten Sie diese wichtigen Fragen, bevor Sie technische Entscheidungen treffen:

Kategorie der Anforderung	Zu beantwortende Fragen
Datenvolumen	Wie viele Daten sind in der Quelle vorhanden? Wie viele Änderungen zwischen den Durchläufen? Was ist die Wachstumsrate?
Latenzanforderungen	Wie frisch müssen Daten für nachgeschaltete Verbraucher sein? Gibt es SLAs einzuhalten?
Quellfunktionen	Unterstützt die Quelle die Änderungsnachverfolgung, CDC oder nur die vollständige Extraktion? Welche Dateiformate können sie erzeugen?
Datenqualität	Wie zuverlässig sind die Quelldaten? Welche Validierung oder Reinigung ist erforderlich?
Netzwerkeinschränkungen	Welche Bandbreite gibt es zwischen Quelle und Azure Databricks? Gibt es Firewall- oder VPN-Anforderungen?
Kostenauswirkungen	Was sind die Berechnungs-, Speicher- und Datenübertragungskosten verschiedener Ansätze?

Schritt 2: Ordnen Sie Anforderungen dem Extraktionstyp zu

Verwenden Sie Ihre Anforderungsanalyse, um das entsprechende Extraktionsmuster auszuwählen:

Wenn Ihre Anforderungen besagen...	Wählen Sie dann ...
Kleines Datenvolumen (< 100K-Zeilen), keine Änderungsnachverfolgung verfügbar, einfache Neuerstellung akzeptabel	Vollständige Extraktion
Großes Datenvolumen, zuverlässige Änderungsanzeige (Zeitstempel/Sequenz), stündliche oder tägliche Frische ausreichend	Inkrementelle Extraktion
Echtzeit- oder Nahezu-Echtzeit-Aktualität erforderlich, Quelle veröffentlicht Ereignisse, Streaming-Infrastruktur verfügbar	Streamingextraktion
Löschvorgänge und Vorgangstypen müssen erfasst werden, ein Prüfungspfad ist erforderlich, die Quelle unterstützt die Erfassung von Transaktionsprotokollen.	CDC-Extraktion

Schritt 3: Auswählen des Quelldateiformats

Wenn Sie das Quellformat steuern oder ein Zielzonenformat auswählen müssen, passen Sie das Format an Ihre Anforderungen an:

Wenn Ihr Szenario umfasst...	Dann bevorzugen Sie...
Große analytische Datasets, Spaltenabfragen, benötigen Komprimierung	Parquet
Interoperabilität mit vielen Systemen, menschliche Lesbarkeit erforderlich	CSV oder JSON
Hierarchische oder geschachtelte Datenstrukturen	JSON oder XML
Hochfrequenzstreaming mit Schemaentwicklung	Avro mit Schemaregistrierung

Schritt 4: Überprüfen Des Designs

Bevor Sie die Implementierung durchführen, überprüfen Sie, ob Ihr Design diese Bedenken erfüllt:

• Der Extraktionstyp erfüllt die Latenzanforderungen. Andernfalls erhalten nachgelagerte Verbraucher veraltete Daten, was möglicherweise zu falschen Geschäftsentscheidungen oder SLA-Verstößen führt.

• Der Ansatz wird skaliert, um das projizierte Datenwachstum zu bewältigen. Andernfalls können Pipelines, die heute funktionieren, fehlschlagen oder unerschwinglich langsam werden, da die Datenvolumes steigen.

• Die Quellsystemfunktionen unterstützen Ihr ausgewähltes Muster. Andernfalls schlägt die Pipeline während der Laufzeit fehl oder erfordert kostspielige Problemumgehungen, die die Komplexität erhöhen.

• Kostenschätzungen liegen innerhalb von Budgeteinschränkungen. Wenn nicht, kann die Lösung technisch solide, aber finanziell unhaltbar für den Produktionseinsatz sein.

• Für die Pipeline sind Datenqualitätsprüfungen geplant. Andernfalls werden ungültige oder beschädigte Daten an nachgelagerte Systeme weitergegeben, was zu Fehlern oder falschen Analysen führt.

Anwenden des Frameworks: Ein praktisches Beispiel

Eine E-Commerce-Plattform muss Bestelldaten aufnehmen. Bestellungen werden in einer PostgreSQL-Datenbank gespeichert, und das Unternehmen erfordert stündliche Berichte.

Schritt 1 : Sammeln von Anforderungen:

• Volumen: 50.000 Neuaufträge täglich, 2 Millionen Gesamtzeilen, 15% jährliches Wachstum.
• Latenz: Eine Stunde Aktualisierung ist für Berichte akzeptabel.
• Quelle: PostgreSQL unterstützt zeitstempelbasierte Abfragen, aber keine native CDC.
• Qualität: Quelldaten werden bei der Eingabe überprüft; Minimale Reinigung erforderlich.
• Netzwerk: Direkte Konnektivität über azure Private Link.
• Kosten: Minimieren der Berechnungsnutzung; Die Speicherkosten sind sekundär.

Schritt 2 : Zuordnung zum Extraktionstyp:

Großes Volumen mit zuverlässiger Zeitstempelspalte und stündliche Latenzanforderung → inkrementelle Extraktion.

Warum nicht die anderen?

• Vollständige Extraktion: Die Neuprozessierung von 2 Millionen Datensätzen pro Stunde verschwendet Rechenleistung, wenn sich nur circa 2.000 Bestellungen pro Stunde ändern.
• Streaming: Die 1-Stunden-Latenz rechtfertigen nicht die Kosten der always-on-Streaming-Infrastruktur.
• CDC: PostgreSQL macht kein systemeigenes Transaktionsprotokoll-CDC verfügbar, und der Anwendungsfall erfordert keine Nachverfolgung von Lösch- oder Vorgangstypen.

Schritt 3 : Dateiformat auswählen:

Daten landen in Azure Data Lake Storage zur Verarbeitung → Parquet für eine effiziente spaltenorientierte Speicherung. Layout mit Datumspartitionierung für inkrementelle Ermittlung → /landing/orders/year=2025/month=11/day=28/.

Warum nicht die anderen?

• CSV/JSON: Größere Dateigrößen, keine Komprimierungsvorteile und langsamere Abfrageleistung für analytische Workloads.
• Avro: Besser geeignet für Streaming mit Schemaentwicklung; Die Batchaufnahme benötigt keine streamingorientierten Features.
• XML: Fügt die Analysekomplexität ohne Vorteile für strukturierte Tabellenreihenfolgedaten hinzu.

Schritt 4 – Überprüfen des Entwurfs:

• ✓ Stündlich inkrementell erfüllt die Anforderung einer einstündigen Latenzzeit.
• ✓ Die Verarbeitung ändert nur die Skalierung mit dem Wachstum effizient.
• • PostgreSQL-Spalte order_updated_at ermöglicht inkrementelle Abfragen.
• • Die Verarbeitung von Tausenden und Millionen von Zeilen reduziert die Berechnungskosten.

Endgültige Entscheidung: Inkrementelle Extraktion unter Verwendung der Spalte order_updated_at Zeitstempel, stündlich geplant, Landing-Daten als Parquet-Dateien in Azure Data Lake Storage.

Basierend auf dieser anforderungsgetriebenen Grundlage können Sie die spezifischen Tools und Lademethoden auswerten, die Ihr Ingestions-Design implementieren.