Kapitel 1. Datenerfassung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Beim Data Ingestion geht es im Wesentlichen darum, Daten von einer Quelle zu einem bestimmten Ziel zu übertragen. Das Hauptziel ist es, die Daten in eine Umgebung zu bringen, die für die Bereitstellung, Verarbeitung, Analyse und künstliche Intelligenz/Maschinenlernen (KI/ML) geeignet ist. Während sich große Unternehmen darauf konzentrieren, Daten intern (zwischen den Teams) zu verschieben, geht es den meisten von uns beim Data Ingestion darum, Daten aus externen Quellen zu ziehen und sie an interne Ziele zu leiten.

In einer Zeit, in der Daten sowohl in der Wirtschaft als auch in der Produktentwicklung eine zentrale Rolle spielen, kann die Bedeutung genauer und aktueller Daten gar nicht hoch genug eingeschätzt werden. Die zunehmende Abhängigkeit von Daten hat zu einer Vielzahl von "Quellen" geführt, aus denen Teams Informationen ziehen, um Entscheidungsprozesse zu verfeinern, herausragende Produkte zu entwickeln und eine Vielzahl anderer Aktionen durchzuführen. Ein Marketingteam muss zum Beispiel Daten von verschiedenen Werbe- und Analyseplattformen wie Meta, Google (einschließlich Ads und Analytics), Snapchat, LinkedIn und Mailchimp abrufen.

Im Laufe der Zeit werden APIs und Datenquellen jedoch verändert. Spalten können hinzugefügt oder entfernt werden, Felder können umbenannt werden und neue Versionen können veraltete ersetzen. Änderungen aus einer einzigen Quelle zu verarbeiten, mag machbar sein, aber wie sieht es mit Änderungen aus mehreren Quellen aus - fünf, zehn oder sogar hundert? Die dringende Herausforderung ist diese: "Wie kann ein angehendes Datenteam diese verschiedenen Quellen effizient, konsistent und erweiterbar handhaben?" Wie können wir als Dateningenieure unserem Ruf gerecht werden, einen zuverlässigen und unkomplizierten Datenzugang zu bieten, vor allem wenn die Anforderungen jeder Abteilung ständig steigen?

Datenerfassung - heute und damals

Auch wenn die Grundsätze der Datenerfassung weitgehend gleich geblieben sind, hat sich doch vieles verändert. Mit dem Volumen, der Geschwindigkeit und der Vielfalt der Daten müssen sich auch unsere Methoden weiterentwickeln.

Um dem gerecht zu werden, gab es zahlreiche Veränderungen in der Branche - die Verlagerung in die Cloud, das Warehouse, der Data Lake, das Lakehouse und die Vereinfachung von Streaming-Technologien, um nur einige zu nennen. Dies hat sich in einem Wechsel von ETL-Workflows (Extract-Transform-Load) zu ELT (Extract-Load-Transform) niedergeschlagen, wobei der Hauptunterschied darin besteht, dass alle Daten jetzt in ein Zielsystem geladen werden. Wir werden diese Umgebungen im Zusammenhang mit der Transformation in Kapitel 2 besprechen.

Wir wollen nicht zu pedantisch mit den Begriffen ETL und ELT umgehen, aber wir möchten betonen, dass fast jeder moderne Data-Engineering-Workflow die Bereitstellung fast aller Daten in der Cloud vorsieht. Eine Ausnahme bilden Fälle, in denen täglich Hunderte von Billionen Zeilen hochgranularer Daten verarbeitet werden (z. B. Internet of Things [IoT] oder Sensordaten), bei denen es sinnvoll ist, die Daten vor der Bereitstellung zu aggregieren oder zu verwerfen.

Trotz ständiger Veränderungen ist die grundlegende Wahrheit der Extraktion, dass Daten aus einer Quelle gezogen und in ein Ziel geschrieben werden. Daher muss sich die Diskussion über die Extraktion auf genau das konzentrieren.

Quellen und Ziele

Die meisten verbinden Ingestion mit Extraktion, aber es ist auch eng mit Loading gekoppelt; schließlich braucht jede Quelle ein Ziel. In diesem Leitfaden gehen wir davon aus, dass du ein bestehendes Warehouse oder einen Data Lake hast; daher wird die Speicherung in diesem Kapitel nicht das Hauptthema sein. Stattdessen werden wir sowohl bewährte Methoden für das Staging als auch die Merkmale idealer Speicherimplementierungen beleuchten.

Unser Ziel ist es, dir ein Instrumentarium für die Gestaltung der Architektur an die Hand zu geben und dabei zu bedenken, dass es die "perfekte" Lösung vielleicht gar nicht gibt. Wir geben dir einen Leitfaden an die Hand, mit dem du die Quellen bewerten und die einzigartigen Knoten der Datenerfassung entwirren kannst. Unser übergeordneter Ansatz soll dir einen Überblick über die Landschaft verschaffen, damit du fundierte und angemessene Entscheidungen treffen kannst.

Die Quelle

Unser Hauptaugenmerk beim Ingesting von Daten liegt auf der Quelle und ihren Eigenschaften. Wenn du nicht sehr viel Glück hast, wirst du viele Quellen haben. Jede muss separat bewertet werden, um angemessene Ressourcen sicherzustellen und die Kriterien für deine Ingestion-Lösung(en) festzulegen.

Bei der schieren Menge an Datenquellen und der Art der geschäftlichen Anforderungen (ich wurde selten gebeten, Quellen zu entfernen, aber das Hinzufügen einer Quelle ist nur ein weiterer Donnerstag), ist es sehr wahrscheinlich, dass du auf eine oder mehrere Quellen stößt, die nicht in eine einzige Lösung passen. Während der Aufbau von Vertrauen Wochen, Monate und Jahre dauert, kann es an einem Tag verloren gehen. Eine verlässliche, zeitnahe Aufnahme ist das A und O. Worauf kommt es also bei der Auswahl einer Quelle an?

Quellen prüfen

Als praktischer Leitfaden stellen wir dir bewährte Fragen, die dir helfen, die Quelldaten zu verstehen, sowohl ihre Eigenschaften als auch den Nutzen für das Unternehmen.

Wir empfehlen, eine äußerst kritische Haltung einzunehmen: Es ist immer möglich, dass die Quelldaten nicht benötigt werden oder eine andere Quelle besser für das Unternehmen geeignet ist. Du bist der Datenexperte deines Unternehmens, und es ist deine Aufgabe, Annahmen zu überprüfen und zu hinterfragen. Es ist normal, dass wir zu Aktionismus und Komplexität neigen, aber wir müssen unbedingt auf Essentialismus und Einfachheit achten.

Wenn du die Quellen untersuchst, solltest du bedenken, dass du wahrscheinlich mit Softwareentwicklern an vorgelagerten Daten arbeitest, aber nachgelagerte Aspekte sind genauso wichtig. Wenn du diese vernachlässigst, kann das sehr kostspielig sein, da sich dein Fehler vielleicht erst nach Wochen der Arbeit bemerkbar macht.

Zu stellende Fragen

Mit wem werden wir zusammenarbeiten?

Im Zeitalter der künstlichen Intelligenz legen wir Wert auf echte Intelligenz. Der wichtigste Teil jeder Datenpipeline sind die Menschen, denen sie dienen soll. Wer sind die beteiligten Akteure? Was sind ihre primären Motive - OKRs (Ziele und Schlüsselergebnisse) oder organisatorische Mandate können nützlich sein, um Anreize zu schaffen und Projekte schnell voranzutreiben.

Wie werden die Daten verwendet?

Eng mit dem "Wer" verbunden ist die Frage, wie die Daten verwendet werden sollen, und wie die nachfolgenden Entscheidungen aussehen sollen. Auf diese Weise können wir die Anforderungen unserer Stakeholder überprüfen und das "Problem hinter dem Problem" erfahren, das unsere Stakeholder zu lösen versuchen. Wir empfehlen dringend eine Liste mit technischen Ja/Nein-Anforderungen, um Unklarheiten zu vermeiden.

Wie hoch ist die Frequenz?

Wie wir später im Detail besprechen werden, denken die meisten Praktiker sofort an Batch oder Streaming. Alle Daten können als Batch oder Stream verarbeitet werden, aber wir beziehen uns in der Regel auf die Eigenschaften der Daten, die wir streamen möchten. Wir plädieren dafür, zunächst zu überlegen, ob die Daten begrenzt oder unbegrenztsind , d.h .ob sie enden (z.B. der Datensatz der Volkszählung 2020) oder ob sie kontinuierlich sind (z.B. Protokolldaten aus einem Glasfaserschrank).

Nachdem die Grenzen berücksichtigt wurden, setzt die verfügbare Mindesthäufigkeit eine harte Grenze dafür, wie oft wir die Daten aus der Quelle abrufen können. Wenn eine API nur täglich aktualisiert wird, gibt es eine harte Grenze für die Häufigkeit deiner Berichterstattung. Grenzen, Geschwindigkeit und Geschäftsanforderungen bestimmen die Häufigkeit, mit der wir Daten abrufen.

Wie hoch ist das erwartete Datenvolumen?

Das Datenvolumen ist kein Hindernis mehr, wenn es darum geht, Daten zu speichern - schließlich ist "Speicherung billig", und auch wenn Rechenleistung teuer sein kann, ist sie heute billiger als je zuvor (um einen Faktor von Millionen; siehe Abbildungen 1-1 und 1-2). Allerdings hängt das Volumen stark davon ab, wie wir unsere Daten schreiben und verarbeiten und wie skalierbar die gewünschte Lösung ist.

Abbildung 1-1. Festplattenkosten pro GB, 1980 bis 2015 (Quelle: Matt Komorowski); die Werte auf der y-Achse sind in logarithmischem Maßstab
Abbildung 1-2. Rechenkosten, Millionen Instruktionen pro Sekunde (MIPS) (Quelle: Field Robotics Center); die Werte auf der y-Achse sind logarithmisch skaliert
Was ist das Format?

Auch wenn wir uns letztendlich für ein Format zur Speicherung entscheiden werden, ist das Eingabeformat eine wichtige Überlegung. Wie werden die Daten geliefert? Über eine JavaScript Object Notation (JSON) Payload über eine API? Vielleicht über einen FTP-Server? Wenn du Glück hast, befinden sie sich bereits in einer relationalen Datenbank. Wie sieht das Schema aus? Gibt es ein Schema? Die unendliche Anzahl von Datenformaten macht unseren Lebensunterhalt interessant, stellt aber auch eine Herausforderung dar.

Wie sieht es mit der Qualität aus?

Die Qualität des Datensatzes bestimmt weitgehend, ob eine Umwandlung notwendig ist. Als Datentechniker/innen ist es unsere Aufgabe, konsistente Datensätze für unsere Nutzer/innen sicherzustellen. Es kann sein, dass die Daten stark bearbeitet oder sogar aus externen Quellen angereichert werden müssen, um fehlende Merkmale zu ergänzen.

Wir werden diese Merkmale nutzen, um unsere letzte Frage zu beantworten:

Wie werden die Daten gespeichert?

Wie bereits erwähnt, geht dieses Buch von einem festen Ziel für deine Daten aus. Aber auch dann gibt es bei der Speicherung von Daten ein paar wichtige Überlegungen: Die wichtigsten sind die Frage, ob man die Daten bereitstellen soll oder nicht (ist das wirklich eine Frage?), die Geschäftsanforderungen und die Eignung für die Interessengruppen.

Quelle: Checkliste

Beachte bei jeder Quelle, die du findest, diese Leitfragen. Auch wenn die Anzahl der Quellen entmutigend erscheinen mag, erinnere dich: Das ist keine Schreibaufgabe. Es ist ein Rahmen, um die Herausforderungen jeder Quelle zu entschlüsseln und dir zu helfen, passende Lösungen zu entwerfen, die deine Ziele erreichen.

Auch wenn es sich wiederholend anfühlen mag, spart diese Vorarbeit langfristig Zeit und Ressourcen.

Frage Beispiel
Mit wem werden wir zusammenarbeiten? Technik (Zahlungen)
Wie werden die Daten verwendet? Finanzielle Berichterstattung und vierteljährliche Strategieplanung
Gibt es mehrere Quellen? Ja
Was ist das Format? Semi-strukturierte APIs (Stripe und intern)
Wie hoch ist die Frequenz? Stündlich
Wie hoch ist die Lautstärke? Ungefähr 1K neue Zeilen/Tag, mit einem bestehenden Pool von ~100K
Welche Bearbeitung ist erforderlich? Datenbereinigung, z. B. Umbenennung von Spalten, und Anreicherung aus zusätzlichen Quellen
Wie werden die Daten gespeichert? Speichern von Stagedaten in Delta-Tabellen über Databricks

Das Ziel

Während End-to-End-Systeme nur hypothetische Überlegungen erfordern, gehen wir davon aus, dass die meisten Leser/innen vor der Aufgabe stehen, eine Pipeline in ein bestehendes System einzubauen, bei dem die Speichertechnologie bereits ausgewählt wurde.

Die Wahl der Technologie für die Speicherung von Daten geht über den Rahmen dieses Leitfadens hinaus, aber wir werden kurz auf die Ziele eingehen, da sie für den Gesamtwert eines Datensystems sehr wichtig sind. Wenn du ein Ziel analysierst (oder in Betracht ziehst), empfehlen wir dir daher, eine ähnliche Checkliste wie bei einer Quelle zu verwenden. In der Regel gibt es viel weniger Ziele als Quellen, so dass dies eine viel einfachere Übung sein sollte.

Reiseziele prüfen

Ein wesentliches Unterscheidungsmerkmal von Reisezielen ist, dass die Interessengruppen im Mittelpunkt stehen. Destinationen haben eine einzigartige Eigenschaft: Sie drehen sich um die Stakeholder. Diese Ziele dienen entweder direkt als Grundlage für BI-, Analyse- und KI/ML-Anwendungen oder indirekt, wenn es um gestaffelte Daten geht, ganz zu schweigen von nutzerorientierten Anwendungen. Obwohl wir dieselbe Checkliste empfehlen, schlagen wir vor, sie ein wenig auf den Stakeholder auszurichten, um sicherzugehen, dass sie seinen Anforderungen entspricht, während wir auf die technischen Ziele hinarbeiten.

Wir wissen, dass das nicht immer möglich ist. Als Ingenieur/in ist es deine Aufgabe, die beste Lösung zu finden, auch wenn das bedeutet, dass du dich auf einen Mittelweg einigen oder zugeben musst, dass es keine eindeutige Antwort gibt. Trotz des unglaublichen Fortschritts der Technik gibt es für bestimmte logische Dilemmas keine einfachen Lösungen.

Bereitstellen der aufgenommenen Daten

Wir plädieren für einen Data-Lake-Ansatz zur Datenaufnahme. Das bedeutet, dass die meisten Daten in Cloud-Speichersysteme wie S3, Google Cloud Platform oder Azure eingespeist werden, bevor sie zur Analyse in ein Data Warehouse geladen werden.

Ein Lakehouse geht noch einen Schritt weiter und nutzt Protokolle zur Speicherung von Daten wie Delta Lake, die Metadaten verwenden, um die Leistung, Zuverlässigkeit und die Möglichkeiten zu erweitern. Lakehouses können sogar einige Warehouse-Funktionen replizieren, so dass die Daten nicht in ein separates Warehouse-System geladen werden müssen. Das Hinzufügen einer Data-Governance-Ebene wie dem Unity Catalog von Databricks kann die Auffindbarkeit, das Zugriffsmanagement und die Zusammenarbeit für alle Datenbestände in einem Unternehmen verbessern.

Eine vorherrschende und effektive Praxis für die Bereitstellung von Daten ist die Verwendung von metadatenzentrierten Parquet-basierten Dateiformaten, wie Delta Lake, Apache Iceberg oder Apache Hudi. Diese Formate basieren auf Parquet - einem komprimierten, spaltenbasierten Format, das für große Datenmengen entwickelt wurde - und enthalten eine Metadatenschicht, die Funktionen wie Zeitreisen, ACID (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) und mehr bietet.

Durch die Integration dieser Formate in die Medaillon-Architektur, die gestaffelte Daten in drei verschiedenen Qualitätsstufen verarbeitet, wird sichergestellt, dass die gesamte Datenhistorie erhalten bleibt. Das erleichtert das Hinzufügen neuer Spalten, das Abrufen verlorener Daten und das Auffüllen historischer Daten.

Die Feinheiten der Medaillon-Architektur werden in unserem Kapitel über Datenumwandlung(Kapitel 2) näher erläutert. Für die aktuelle Diskussion ist es wichtig zu wissen, ob es sinnvoll ist, alle Daten in eine "Staging-Ebene" bei dem von dir gewählten Cloud-Provider zu leiten.

Datenerfassung ändern

Die Änderungsdatenerfassung (Change Data Capture, CDC) ist ein Entwurfsmuster der Datentechnik, das Änderungen in Quelldatenbanken erfasst und verfolgt, um nachgelagerte Systeme zu aktualisieren. Anstatt ganze Datenbanken im Stapelverfahren zu laden, überträgt CDC nur die geänderten Daten und optimiert so sowohl die Geschwindigkeit als auch den Ressourcenverbrauch.

Diese Technik ist entscheidend für Echtzeit-Analysen und Data Warehousing, da sie sicherstellt, dass die Daten in den Zielsystemen aktuell und mit der Quelle synchron sind. Indem CDC inkrementelle Aktualisierungen ermöglicht, verbessert es die Datenverfügbarkeit und -konsistenz in der gesamten Datenpipeline. Joe Reis und Matt Housley beschreiben in Fundamentals of Data Engineering (O'Reilly, 2022): "CDC... ist der Prozess der Übernahme von Änderungen aus einem Quelldatenbanksystem".

CDC wird bei Analysen und technischen Mustern wichtig, wie z. B. bei der Erstellung von Tabellen des Typs 1 und 2 der Slowly Changing Dimension (SCD), ein Prozess, der unnötig komplex und zeitaufwändig sein kann. Wenn du dich für Plattformen oder Lösungen entscheidest, die CDC von Haus aus unterstützen, kannst du gängige Aufgaben beschleunigen und dich auf das Wesentliche konzentrieren. Ein Beispiel dafür sind Delta Live Tables (DLT) auf Databricks, die SCD Typ 1 und 2 sowohl in Batch- als auch in Streaming-Pipelines nativ unterstützen.

Checkliste für das Reiseziel

Hier ist eine Beispiel-Checkliste für Fragen, die du bei der Auswahl eines Reiseziels beachten solltest:

Frage Beispiel
Mit wem werden wir zusammenarbeiten? Personalwesen
Wie werden die Daten verwendet? Verstehe, wie sich die Dauer der Betriebszugehörigkeit/Vertragslaufzeit auf das Endergebnis in einem multinationalen Unternehmen auswirkt.
Gibt es mehrere Ziele? Die Daten werden in Delta Lake bereitgestellt; die endgültigen Tabellen werden in Databricks SQL erstellt.
Was ist das Format? Parkett in Delta Lake. Strukturiert/Semi-Strukturiert in Databricks SQL.
Wie hoch ist die Frequenz? Batch
Wie hoch ist die Lautstärke? Ungefähr 1K neue Zeilen/Tag, mit einem bestehenden Pool von ~100K
Welche Bearbeitung ist erforderlich? Nachgelagerte Verarbeitung mit DLT. ML-Modelle und generative KI-Anwendungen in Spark.
Wie werden die Daten gespeichert? Eine Mischung aus Databricks SQL und externen Tabellen in Delta Lake.

Überlegungen zum Verschlucken

In diesem Abschnitt stellen wir die wichtigsten Datenmerkmale vor. Auch wenn diese Liste nicht vollständig ist und von spezifischen Kontexten beeinflusst wird, kristallisieren sich Aspekte wie Häufigkeit, Volumen, Format und Verarbeitung als Hauptanliegen heraus.

Frequenz

Wir haben bereits erwähnt, dass die erste Überlegung bei der Häufigkeit die Grenzen sein sollten, d.h. ob der Datensatz begrenzt oder unbegrenzt ist. Die Grenzen und die geschäftlichen Anforderungen diktieren die Häufigkeit der Datenaufnahme - entweder im Batch- oder im Streaming-Format. Abbildung 1-3 zeigt den Unterschied zwischen Batch- und Streaming-Prozessen: Beim Streaming werden Ereignisse erfasst, sobald sie auftreten, während sie beim Batch, wie der Name schon sagt, zusammengefasst werden.

Abbildung 1-3. Die Latenz ist die Eigenschaft, die "Batch"- oder "Streaming"-Prozesse definiert; bei Überschreiten einer beliebigen Latenzschwelle betrachten wir die Daten als "gestreamt" (mit freundlicher Genehmigung von Denny Lee)

Wir stellen Batch, Micro-Batch und Streaming vor und erläutern unsere Überlegungen, um dir bei der Auswahl der am besten geeigneten Frequenz und einer kompatiblen Ingestion-Lösung zu helfen.

Batch

Bei der Stapelverarbeitung werden die Daten nicht auf einmal, sondern in Stapeln verarbeitet. Wie bei einer for-Schleife, die über eine Quelle iteriert, wird bei der Stapelverarbeitung entweder ein begrenzter Datensatz in Teile zerlegt und jede Komponente verarbeitet , oder es werden unbegrenzte Datensätze verarbeitet, sobald Daten eintreffen.

Mikro-Batch

Ein Micro-Batch ist einfach ein "Herunterdrehen" der Batch-Verarbeitung. Während ein typischer Batch-Ingest täglich läuft, kann ein Micro-Batch stündlich oder sogar minütlich funktionieren. Natürlich könntest du sagen: "Ab welchem Punkt ist das nur noch Semantik? Eine Micro-Batch-Pipeline mit einer Latenzzeit von 100 ms kommt mir sehr nach Streaming vor."

Wir sind einverstanden!

Im weiteren Verlauf dieses Kapitels (und des Buches) werden wir Micro-Batch-Lösungen mit niedriger Latenz als Streaming-Lösungen bezeichnen - am offensichtlichsten ist Spark Structured Streaming. Obwohl es sich "technisch" um Micro-Batch handelt, ist Spark Structured Streaming mit einer Latenz von Hunderten von Millisekunden praktisch eine Echtzeitlösung.

Streaming

Unter Streaming versteht man das kontinuierliche Lesen von Datensätzen, die entweder begrenzt oder unbegrenzt sind, während sie generiert werden. Wir werden Streaming zwar nicht im Detail besprechen, aber es lohnt sich, sich damit zu beschäftigen. Um ein umfassendes Verständnis von Streaming-Datenquellen zu erlangen, empfehlen wir Ressourcen wie Streaming 101, Streaming Databases und natürlich Fundamentals of Data Engineering.

Methoden

Zu den gängigen Methoden für das Streaming unbegrenzter Daten gehören:

Fenstern

Segmentierung einer Datenquelle in endliche Teile, die auf zeitlichen Grenzen basieren.

Feste Fenster

Die Daten werden im Wesentlichen "mikro-gebündelt" und in kleinen festen Fenstern auf ein Ziel hin gelesen.

Schiebefenster

Ähnlich wie bei festen Fenstern, aber mit überlappenden Grenzen.

Sitzungen

Dynamische Fenster, in denen Ereignisfolgen durch Lücken der Inaktivität getrennt sind - das "Fenster" wird durch die Daten selbst definiert.

Zeitunabhängig

Geeignet für Daten, bei denen es nicht auf die Zeit ankommt und die oft in Batch-Workloads verarbeitet werden.

Abbildung 1-4 veranschaulicht den Unterschied zwischen festen Fenstern, gleitenden Fenstern und Sitzungen. Es ist wichtig, zwischen der tatsächlichen Ereigniszeit und der Bearbeitungszeit zu unterscheiden, da es zu Diskrepanzen kommen kann.

Abbildung 1-4. Feste Fenster, gleitende Fenster und Sitzungen behandeln das Eintreffen von Streaming-Daten ganz unterschiedlich

Nachrichten-Dienste

Wenn wir von "Nachrichtendiensten" sprechen, beziehen wir uns auf "Transportschichten" oder Systeme für die Kommunikation und den Transport von Streaming-Daten. Ein wichtiger Hinweis ist, dass dies kein direkter Vergleich ist. Es gibt zwar Überschneidungen bei diesen Diensten, aber viele arbeiten mit grundlegend unterschiedlichen Architekturen, so dass Diskussionen über "Kafka versus Pub/Sub" oder "Kinesis versus Redpanda" weitgehend irrelevant sind.

Apache Kafka

Apache Kafka wurde 2011 bei LinkedIn entwickelt und begann als Warteschlangensystem für Nachrichten, entwickelte sich aber schnell zu einer verteilten Streaming-Plattform. Das Design von Kafka ermöglicht zwar einen hohen Durchsatz und eine hohe Skalierbarkeit, aber die damit verbundene Komplexität bleibt für viele eine Hürde.

Redpanda

Redpanda wurde als Alternative zu Kafka entwickelt und bietet eine ähnliche Leistung bei einer vereinfachten Konfiguration und Einrichtung. Redpanda basiert auf C++ und nicht auf Java und ist mit den Kafka-APIs kompatibel.

Kneipe/Verleih

Pub/Sub ist das Google Cloud-Angebot für eine langlebige, dynamische Messaging-Queue. Im Gegensatz zu Kafka lässt sich Google Pub/Sub dynamisch skalieren, um variable Arbeitsbelastungen zu bewältigen. Anstatt mit "Streams" und "Shards" zu arbeiten, setzt Pub/Sub auf "Topics" und "Subscriptions". Ein großer Vorteil von Pub/Sub ist der Wegfall der meisten "Wartungsaufgaben" - es wird fast vollständig verwaltet.

Kinesis

Kinesis ist ein weiterer robuster, vollständig verwalteter Dienst. Als Amazon-Service bietet Kinesis die offensichtliche Einfachheit der Integration mit anderen Amazon Web Services (AWS)-Angeboten und bietet gleichzeitig automatische Skalierbarkeit und Datenverarbeitung in Echtzeit. Wie Pub/Sub zeichnet sich auch Kinesis durch einen verwalteten Service aus, der einen geringeren Betriebsaufwand als Apache Kafka bietet.

Stream Processing Engines

Bei der Stream-Verarbeitung geht es um die Analyse und Verarbeitung von Echtzeitdaten (Streams). Angesichts der Langlebigkeit von Kafka sind die drei beliebtesten und bekanntesten Stream-Processing-Tools:

Apache Flink

Eine Open-Source-Engine, die kontinuierlich sowohl unbegrenzte als auch begrenzte Datensätze mit minimaler Ausfallzeit verarbeitet. Apache Flink sorgt für niedrige Latenzzeiten durch In-Memory-Berechnungen, bietet hohe Verfügbarkeit durch die Beseitigung von Single Points of Failure und ist horizontal skalierbar.

Apache Spark Strukturiertes Streaming

Ein Zweig des Apache Spark-Ökosystems, der für die Verarbeitung von Echtzeitdaten entwickelt wurde. Er überträgt die Vertrautheit und Leistungsfähigkeit der DataFrame- und Dataset-APIs von Spark auf Streaming-Daten. Angesichts der Beliebtheit von Apache Spark in der Datenverarbeitung und der Allgegenwärtigkeit der Engine in Tools wie Databricks könnte Structured Streaming eine attraktive Option sein.

Apache Kafka Streams

Eine Bibliothek, die auf Kafka aufbaut und zustandsbehaftete Verarbeitungsfunktionen bietet, aber die Bindung an Java kann einschränkend sein.

Vereinfachung der Stream-Verarbeitung

Mehrere relativ neue Lösungen vereinfachen die Stream-Verarbeitung, indem sie unkomplizierte Clients anbieten, die sich auf Leistung und einfache Entwicklungszyklen konzentrieren.

Verwaltete Plattformen

Nehmen wir Databricks als Beispiel: Der Einsatz von Tools wie Delta Live Tables (DLT) oder die Ausführung von Spark Streaming-Aufträgen auf der Databricks-Laufzeitumgebung kann die Komplexität stark abstrahieren und den Aufbau von Streaming-Systemen drastisch vereinfachen.

Konfluentes Kafka

Ein Versuch, Apache Kafka-Funktionen in Python zu integrieren, auch wenn es im Vergleich zu seinem Java-Pendant rudimentär bleibt. Confluent Kafka ist einfach eine Client-Bibliothek, so wie psycopg2 eine Postgres-Client-Bibliothek ist.

Bytewax

Bytewax ist eine Bibliothek, die die Lücke schließen soll, indem sie einen intuitiveren, pythonischen Weg zur Stream-Verarbeitung bietet, der sie für eine größere Anzahl von Entwicklern zugänglich macht. Bytewax basiert auf Rust, ist hochperformant, einfacher als Flink und zeichnet sich durch kürzere Feedbackschleifen und einfache Bereitstellung/Skalierbarkeit aus.

Noch neuere Tools, die versuchen, die Stream-Verarbeitung zu vereinheitlichen - wie Apache Beam oder Estuary Flow - oder die Stream-Verarbeitung direkt mit Datenbanken (Streaming-Datenbanken) zu kombinieren, werden immer beliebter. Wir empfehlen Streaming Systems und Streaming Databases für einen detaillierten Einblick.

Die Streaming-Landschaft ist zwar komplex, hat aber Fortschritte bei der Vereinfachung und Benutzerfreundlichkeit gemacht, insbesondere wenn man verwaltete Plattformen wie Databricks und Mikrobatch-Lösungen mit niedriger Latenz wie Spark Structured Streaming in Betracht zieht.

Während viele von Echtzeitdaten als dem ultimativen Ziel ausgehen, legen wir Wert auf einen "Right-Time"-Ansatz. Wie bei jeder Lösung kann die Latenzzeit unendlich optimiert werden, aber die Kosten der Lösung (und die Komplexität) steigen proportional dazu. Für die meisten ist der Wechsel von täglichen oder halbtäglichen Daten zu stündlichen/substündlichen Daten eine durchaus akzeptable Lösung.

Nutzlast

Der Begriff "Nutzdaten" bezieht sich auf die eigentliche Nachricht, die übertragen wird, sowie auf alle Metadaten oder Header, die für die Weiterleitung, Verarbeitung oder Formatierung der Daten verwendet werden. Der Begriff "Nutzdaten" ist sehr weit gefasst, da sie fast jede erdenkliche Form annehmen können. In diesem Abschnitt gehen wir auf typische Merkmale von Nutzdaten ein.

Band

Das Datenvolumen ist ein entscheidender Faktor bei der Dateneingabe und beeinflusst die Skalierbarkeit von Verarbeitungs- und Speicherlösungen. Bei der Bewertung des Datenvolumens solltest du Faktoren wie folgende berücksichtigen:

Kosten

Höhere Volumina führen oft zu höheren Kosten, sowohl bei der Speicherung als auch bei den Rechenressourcen. Achte darauf, den Kostenfaktor mit deinem Budget und deinen Projektanforderungen abzugleichen, einschließlich der Kosten für die Speicherung/Staging in Lagerhäusern, Seen oder Seegebäuden, je nach deiner Lösung.

Latenz

Je nachdem, ob du Echtzeit-, Fast-Echtzeit- oder Stapeldaten verarbeiten musst, kann die Latenz ein kritischer Faktor sein. Die Verarbeitung in Echtzeit erfordert nicht nur mehr Ressourcen, sondern auch eine höhere Effizienz, wenn das Datenvolumen in die Höhe schießt. Achte bei jedem Datenvolumen darauf, dass dein System die Latenzanforderungen erfüllen kann.

Durchsatz/Skalierbarkeit

Es ist wichtig zu wissen, ob das Ingestion Tool in der Lage ist, das schiere Volumen der eingehenden Daten zu verarbeiten. Wenn die Datenquelle große Datenmengen erzeugt, sollte das Ingestion-Tool in der Lage sein, diese Daten ohne Engpässe zu verarbeiten.

Rückhaltung

Je größer das Datenvolumen ist, desto wichtiger werden Richtlinien zur Datenaufbewahrung. Du brauchst eine Strategie, um alte Daten auszulagern oder sie in eine billigere, langfristige Speicherung zu verschieben. Neben der Speicherung alter Daten sollten auch die Sicherheit und das Backfilling (Wiederherstellen) verlorener Daten berücksichtigt werden.

Für die Bearbeitung großer Datenmengen ist die Verwendung komprimierter Formate wie Apache Avro oder Parquet entscheidend. Jedes dieser Formate bietet bestimmte Vorteile und Einschränkungen, insbesondere im Hinblick auf die Schemaentwicklung. Bei all diesen Überlegungen solltest du in die Zukunft blicken - dauerhafte Lösungen können sich bei einem Anstieg des Datenvolumens in Größenordnungen schnell auflösen.

Struktur und Form

Die Form und Struktur von Daten ist sehr unterschiedlich und reicht von sauberen, relationalen "strukturierten" Daten bis hin zu "unstrukturierten" Daten in freier Form. Wichtig ist, dass Struktur nicht gleichbedeutend mit Qualität ist; sie bedeutet lediglich, dass ein Schema vorhanden ist.

In der heutigen KI-gesteuerten Landschaft steigt der Wert unstrukturierter Daten rapide an, da die Fortschritte bei großen Sprach- und maschinellen Lernmodellen es uns ermöglichen, reichhaltige Erkenntnisse aus diesen Daten zu gewinnen. Trotzdem haben Menschen eine Vorliebe für strukturierte Daten, wenn es um tiefgreifende Analysen geht. Das zeigt die ungebrochene Beliebtheit der SQL-Structured Query Language, die seit fast einem halben Jahrhundert in der Datenanalyse zum Einsatz kommt.

Unstrukturiert

Wie bereits erwähnt, handelt es sich bei unstrukturierten Daten um Daten ohne ein vordefiniertes Schema oder eine Struktur. Meistens werden sie in Form von Text dargestellt, aber auch andere Medienformen stellen unstrukturierte Daten dar. Video-, Audio- und Bilddaten haben alle Elemente, die numerisch analysiert werden können. Unstrukturierte Daten können auch der Text eines Pierce Brown-Romans sein:

"Ein Mann denkt, er kann fliegen, aber er hat Angst zu springen. Ein armer Freund stößt ihn von hinten an." Er schaut zu mir auf. "Ein guter Freund springt mit."

Solche Daten fließen oft in maschinelles Lernen oder KI-Anwendungen ein, was die Notwendigkeit unterstreicht, die Anforderungen der Interessengruppen umfassend zu verstehen. Angesichts der Komplexität des maschinellen Lernens ist es wichtig zu verstehen, wie diese unstrukturierten Daten genutzt werden sollen, bevor sie aufgenommen werden. Metriken wie Textlänge oder unkomprimierte Größe können als Maß für die Form dienen.

Halbstrukturiert

Semi-strukturierte Daten liegen irgendwo zwischen strukturierten und unstrukturierten Daten - XML und JSON sind zwei beliebte Formate. Semi-strukturierte Daten können die Form eines JSON-Payloads haben: 

'{"friends": ["steph", "julie", "thomas", "tommy", "michelle", "tori", “larry”]}'

Mit der Weiterentwicklung von Datenplattformen werden auch die Möglichkeiten zur direkten Verarbeitung und Analyse halbstrukturierter Daten immer besser. Das folgende Snippet zeigt, wie man halb-strukturiertes JSON in Google BigQuery parst, um eine Liste in Datenzeilen zu zerlegen:

WITH j_data AS (
        SELECT
            (
            JSON '{"friends": ["steph", "julie", "thomas", "tommy", "michelle", "tori", “larry”]}'
            ) AS my_friends_json
), l_data AS (
    SELECT
        JSON_EXTRACT_ARRAY(
            JSON_QUERY(j_data.my_friends_json, "$.friends"), '$'
        ) as my_friends_list
    FROM j_data
)
    SELECT
        my_friends
FROM l_data, UNNEST(l_data.my_friends_list) as my_friends
ORDER BY RAND()

In manchen Situationen lohnt es sich, die Datenverarbeitung in die Analyseschicht zu verlagern - sie ermöglicht Analysten und Analysetechnikern mehr Flexibilität bei der Abfrage und Speicherung von Daten. Halbstrukturierte Daten in einem Warehouse (oder der Zugriff über externe Tabellen) ermöglichen Flexibilität bei sich ändernden Schemata oder fehlenden Daten und bieten gleichzeitig alle Vorteile der tabellarischen Datenverarbeitung und von SQL.

Dennoch müssen wir darauf achten, diese Daten richtig zu validieren, um sicherzustellen, dass fehlende Daten keine Fehler verursachen. Viele ungültige Abfragen entstehen durch die unsachgemäße Berücksichtigung von NULL Daten.

Bei der Beschreibung der Form von JSON geht es häufig um Schlüssel, Werte und die Anzahl der verschachtelten Elemente. Zu diesem Zweck empfehlen wir Tools wie JSONLint und JSON Crack. Es gibt auch Erweiterungen für VS Code, um JSON/XML-Daten zu validieren und zu formatieren.

Strukturiert

Die goldenen "idealen" Daten, strukturierte Quellen sind ordentlich organisiert mit festen Schemata und unveränderlichen Schlüsseln. Seit über 50 Jahren ist SQL die Sprache der Wahl, um strukturierte Daten abzufragen. Bei der Speicherung strukturierter Daten achten wir häufig auf die Anzahl der Spalten und die Länge der Tabelle (in Zeilen). Diese Merkmale bestimmen unsere Verwendung von Materialisierung, inkrementellen Builds und insgesamt die Unterscheidung zwischen einer OLAP- und einer OLTP-Datenbank (spalten-/zeilenorientiert).

Obwohl viele Daten heute unstrukturiert sind, ist SQL immer noch das vorherrschende Werkzeug für die Analyse. Wird sich das ändern? Möglicherweise, aber wie wir gezeigt haben, ist es wahrscheinlicher, dass sich SQL einfach an semi-strukturierte Formate anpassen wird. Obwohl sprachbasierte Abfragetools mit den Fortschritten der KI auf den Markt gekommen sind, ist SQL oft nur ein Zwischenglied. Wenn SQL aus der Datenanalyse verschwindet, wird es wahrscheinlich als API weiterleben.

Format

Welches ist das beste Format für Quelldaten? JSON und CSV (kommagetrennte Werte) sind zwar gängige Formate, aber es gibt noch unendlich viele andere Möglichkeiten. Einige ältere SFTP/FTP-Übertragungen kommen zum Beispiel komprimiert an, so dass ein zusätzlicher Extraktionsschritt erforderlich ist.

Das Datenformat bestimmt oft die Verarbeitungsanforderungen und die verfügbaren Lösungen. Während sich ein Tool wie Airbyte nahtlos in eine CSV-Quelle integrieren lässt, kann es mit einer benutzerdefinierten Komprimierungsmethode oder einer eigenartigen Windows-Kodierung ins Straucheln geraten (glaub uns, das kommt vor).

Wenn es möglich ist, raten wir dazu, bekannte und beliebte Datenformate zu verwenden. Wie bei der Reparatur eines Fahrzeugs gilt: Je bekannter das Format ist, desto einfacher ist es, Ressourcen, Bibliotheken und Anleitungen zu finden. Wir haben die Erfahrung gemacht, dass es eine Herausforderung ist, sich mit einem verwirrenden Format auseinanderzusetzen, aber das ist ein Teil dessen, was unsere Aufträge so interessant macht!

Sorte

Es ist sehr wahrscheinlich, dass du es mit mehreren Quellen und damit mit unterschiedlichen Nutzdaten zu tun hast. Die Datenvielfalt spielt bei der Auswahl deiner Ingestion-Lösung eine große Rolle - sie muss nicht nur in der Lage sein, unterschiedliche Datentypen zu verarbeiten, sondern auch flexibel genug sein, um sich an Schemaänderungen und unterschiedliche Formate anzupassen. Die Vielfalt macht Governance und Beobachtbarkeit zu einer besonderen Herausforderung, auf die wir in Kapitel 5 eingehen werden.

Wird die Datenvielfalt nicht berücksichtigt, kann dies zu Engpässen, erhöhter Latenz und einer planlosen Pipeline führen, die die Integrität und den Nutzen der eingelesenen Daten beeinträchtigt.

Die Wahl einer Lösung

Die besten Tools für dein Team sind die, die deine Quellen und Ziele unterstützen. Da jedes Unternehmen seine eigenen Datenanforderungen hat, wird die Wahl des Tools vom jeweiligen Kontext abhängen. Wir können jedoch nicht genug betonen, wie wichtig es ist, das Wissen von Mentoren, Kollegen und Branchenexperten zu nutzen. Konferenzen können zwar teuer sein, aber ihr Wissensgewinn ist unbezahlbar. Für diejenigen, die ein knappes Budget haben, können Daten-Communities von unschätzbarem Wert sein. Halte Ausschau nach ihnen auf Plattformen wie Slack und LinkedIn und in Branchen-Newslettern.

Wenn wir eine Ingestion-Lösung in Betracht ziehen, denken wir an allgemeine und lösungsspezifische Überlegungen - erstere gelten für alle Tools, die wir in Betracht ziehen, und letztere sind spezifisch für die Klasse der Tools.

Zu den allgemeinen Überlegungen gehören die Erweiterbarkeit, die Kosten für die Erstellung, die Kosten für die Wartung, die Kosten für den Wechsel und andere Aspekte auf Systemebene.

Lösungsspezifische Überlegungen hängen von der Art des Werkzeugs ab, das in der Regel eine von zwei Formen annimmt:

  • Deklarative Lösungen geben die Ergebnisse vor. Zum Beispiel: "Ich verwende die AWS Glue UI, um einen Crawler zu erstellen, der systematisch Daten verarbeitet" oder "Ich erstelle eine neue Airbyte-Verbindung über eine UI".

  • Imperative Lösungen schreiben Aktionen vor. Zum Beispiel: "Ich baue ein Lambda, das die Stripe-API aufruft, Daten kodiert/dekodiert und sie schrittweise in Snowflake lädt."

Jede dieser Lösungen hat ihre Vor- und Nachteile. Wir werden sie kurz besprechen und unsere empfohlene Methode für die Datenintegration vorstellen.

Deklarative Lösungen

Wir klassifizieren deklarative Lösungen als "legacy", "modern" oder "nativ", was vor allem davon abhängt, ob sie die Prinzipien des Modern Data Stack (MDS) wie Infrastructure-as-Code, DRY (don't repeat yourself) und andere bewährte Methoden der Softwareentwicklung befolgen. Native Plattformen unterscheiden sich von den ersten beiden - sie sind direkt in einen Cloud-Provider integriert:

Erbe

Denk an Talend, WhereScape und Pentaho. Diese Tools haben robuste Konnektoren und profitieren von einer großen Community und umfangreichem Support. Da sich die Datenlandschaft jedoch weiterentwickelt, hinken viele dieser Tools hinterher und sind nicht auf die Anforderungen der MDS abgestimmt. Wenn es keinen zwingenden Grund gibt, empfehlen wir, sich nach anderen Tools umzusehen.

Modern

Hier kommen Fivetran, Stitch und Airbyte ins Spiel. Diese Tools wurden auf der Grundlage von "Konnektoren" entwickelt und können verschiedene Quellen und Ziele nahtlos miteinander verbinden, wobei sie auf modernster Technologie basieren und das Beste aus dem MDS nutzen.

Einheimische

Bei den ersten beiden Lösungen gehen wir davon aus, dass Daten von einer Quelle in eine andere verschoben werden müssen - aber was wäre, wenn du eine verwaltete Plattform hättest, die Ingestion von Anfang an unterstützt? Databricks zum Beispiel kann von Haus aus Daten aus Message Bussen und Cloud-Speichern einlesen:

CREATE STREAMING TABLE raw_data 
AS select * 
FROM cloud_files(“/raw_data”, “json”);

CREATE STREAMING TABLE clean_data
AS SELECT SUM(profit)...
FROM raw_data;

Es gibt zwar nicht die "richtige" Art von deklarativer Lösung, aber viele werden von den geringeren Kosten für die Erstellung und Wartung dieser Lösungen profitieren, insbesondere von denen, die für deinen bestehenden Cloud-Provider/deine Plattform entwickelt wurden.

Kosten für Bau/Unterhalt

Deklarative Lösungen sind weitgehend handlungsunabhängig - hier bekommst du ein gutes Gefühl für dein Geld! Engagierte Ingenieure kümmern sich um die Entwicklung und Pflege der Konnektoren. Das bedeutet, dass du die schwere Arbeit an Spezialisten delegierst. Die meisten kostenpflichtigen Lösungen verfügen über Support-Teams oder engagierte Kundenbetreuer, die dir Einblicke und Ratschläge geben, die auf deine Bedürfnisse zugeschnitten sind. Diese Experten kennen die Datenlandschaft aus der Vogelperspektive und können dir helfen, Unklarheiten bei bestimmten Datenproblemen zu beseitigen oder dich mit anderen Fachleuten zusammenzubringen.

Erweiterbarkeit

Bei der Erweiterbarkeit geht es darum, wie einfach es ist, auf bestehenden Lösungen aufzubauen. Wie wahrscheinlich ist es, dass dieser neue Anschluss zu Airbyte oder Fivetran hinzugefügt wird? Kannst du es selbst tun, indem du auf demselben Framework aufbaust? Oder musst du Wochen/Monate/Jahre auf ein Produktteam warten? Reicht es aus, Stitch zu benutzen, oder brauchst du eine ergänzende Lösung? Denke daran, dass das Jonglieren mit mehreren Lösungen die Kosten in die Höhe treiben und die Arbeitsabläufe verkomplizieren kann. Bei deklarativen Lösungen ist die Erweiterbarkeit von großer Bedeutung. Niemand möchte eine Lösung einführen, um dann festzustellen, dass sie nur 15 % seiner Bedürfnisse erfüllt.

Kosten für den Wechsel

Die Kosten für den Wechsel sind der Punkt, an dem die Grenzen deklarativer Tools deutlich werden. Proprietäre Frameworks und spezielle CDC-Methoden machen die Migration zu einem anderen Tool teuer. Auch wenn das Festhalten an einem Anbieter ein notwendiger Kompromiss sein kann, ist es wichtig, dies bei der Bewertung potenzieller Lösungen zu berücksichtigen.

Imperative Lösungen

Bei den Ansätzen zur Datenaufnahme kann es sich um hauseigene Singer Taps, Lambda-Funktionen, Apache Beam Templates oder Aufträge handeln, die über Systeme wie Apache Airflow orchestriert werden.

In der Regel sind größere Unternehmen mit umfangreichen Ressourcen am meisten von einer imperativen Methodik überzeugt. Die Pflege und Skalierung eines benutzerdefinierten, internen Ingestion-Frameworks erfordert in der Regel das Fachwissen mehrerer Dateningenieure oder sogar eines eigenen Teams.

Der größte Vorteil von imperativen Lösungen ist ihre Erweiterbarkeit.

Erweiterbarkeit

Es liegt in der Natur der Sache, dass Imperative maßgeschneidert sind - das bedeutet, dass jeder Tap und jedes Ziel auf die Bedürfnisse des Unternehmens zugeschnitten ist. Bei der Erkundung von Datenintegrationsoptionen wird schnell klar, dass kein einziges Tool alle Kriterien erfüllt. Standardlösungen sind zwangsläufig mit Kompromissen verbunden. Bei einem imperativen Ansatz hast du jedoch die Freiheit, ihn genau nach den gewünschten Vorgaben zu gestalten. Leider ist es ohne eine große, engagierte Data-Engineering-Organisation unglaublich teuer, diese Erweiterbarkeit aufzubauen und zu pflegen.

Kosten für Bau/Unterhalt

Imperative Lösungen können zwar komplexe und schwierige Ingestion-Probleme lösen, aber sie erfordern eine Menge Entwicklungsarbeit. Ein Blick auf das Beziehungsdiagramm von Stripe sollte ausreichen, um dich davon zu überzeugen, dass dies unglaublich zeitaufwändig sein kann. Hinzu kommt, dass die Komplexität der Daten durch Veränderungen im Schema oder durch die Abschaffung einer API noch erhöht wird. Die Verwaltung einer einzelnen Datenquelle ist eine Sache, aber was ist, wenn du mehrere Quellen verwaltest?

Ein wirklich widerstandsfähiges System sollte bewährte Methoden des Softwaredesigns berücksichtigen und den Schwerpunkt auf Modularität, Testbarkeit und Klarheit legen. Die Vernachlässigung dieser Grundsätze kann die Wiederherstellungszeiten des Systems beeinträchtigen und die Skalierbarkeit behindern, was sich letztendlich auf den Geschäftsbetrieb auswirkt. Daher empfehlen wir, dass nur Unternehmen mit einer robusten Data-Engineering-Infrastruktur die Umstellung auf ein Imperativ-System in Betracht ziehen.

Kosten für den Wechsel

Der Wechsel von einer imperativen Lösung zu einer anderen ist angesichts der möglichen Inkompatibilität zwischen den Formaten der verschiedenen Anbieter nicht immer einfach. Plattformen, die auf gemeinsamen Frameworks wie Singer basieren, sind jedoch besser kompatibel und können einen reibungsloseren Wechsel ermöglichen als rein deklarative Tools wie Fivetran oder Airbyte.

Hybride Lösungen

Die richtige Balance bei der Integration zu finden, bedeutet oft, einen hybriden Ansatz zu wählen. Das kann bedeuten, dass man für die meisten Integrationsaufgaben Tools wie Fivetran einsetzt, während man für spezielle Quellen eigene Lösungen entwickelt, oder dass man sich für Plattformen wie Airbyte/Meltano entscheidet und eigene Komponenten für nicht unterstützte Datenquellen erstellt.

Auch in einer hybriden Umgebung kann es sich lohnen, zu Open Source beizutragen. Obwohl sie nicht fehlerfrei sind, profitieren hybride Anschlüsse wie die von Airbyte oder Singer Taps von der umfassenden Unterstützung der Community. Die Beiträge von Airbyte haben die Marktdynamik positiv beeinflusst und Konkurrenten wie Fivetran dazu gezwungen, kostenlose Tiers einzuführen. Wir ermutigen auch zu einem proaktiven Ansatz bei der Erkundung neuer Bibliotheken und Tools. Zum Beispiel ist dlt (data load tool - nicht zu verwechseln mit Delta Live Tables!) eine vielversprechende Open-Source-Bibliothek.

Betrachte die Datenintegration wie die Wahl eines Autos. Nicht jede Aufgabe erfordert die Fähigkeiten eines Formel-1-Autos. Meistens ist ein zuverlässiges, vielseitiges Fahrzeug gefragt. Ein Toyota erfüllt zwar 99 % aller Aufgaben, aber einen Sienna wirst du in einem Formel-1-Rennen nicht finden. Die optimale Strategie? Verlass dich auf ein zuverlässiges Alltagsfahrzeug, aber sorge dafür, dass du bei Bedarf Zugang zu leistungsstarken Werkzeugen hast.

Get ETL verstehen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial