Wenn Sie Veränderungen nicht mögen, ist Data Engineering nichts für Sie. In diesem Bereich gibt es kaum etwas, das nicht neu erfunden wurde.
Die bekanntesten Beispiele aus jüngster Zeit sind Snowflake und Databricks, die das Konzept der Datenbank auf den Kopf gestellt und die Ära des modernen Datenstapels eingeläutet haben.
Als Teil dieser Bewegung haben Fivetran und dbt die Datenpipeline von ETL zu ELT grundlegend verändert. Hightouch unterbrach die SaaS-Bewegung in dem Versuch, den Schwerpunkt auf das Data Warehouse zu verlagern. Monte Carlo schloss sich dem Kampf an und sagte: „Vielleicht ist es nicht der beste Weg, Datenqualität zu gewährleisten, wenn Ingenieure Unit-Tests manuell programmieren.“
Heute stapfen Dateningenieure weiterhin auf hart kodierten Pipelines und lokalen Servern herum, während sie den modernen Data stapleauf dem Weg der Erleuchtung erklimmen. Die unvermeidliche Konsolidierung und der Tiefpunkt der Desillusionierung erscheinen in sicherer Entfernung am Horizont.
Und so scheint es fast unfair, dass bereits neue Ideen auftauchen, um die Disruptoren zu stören:
- Zero-ETL hat die Dateneingabe im Visier
- KI und große Sprachmodelle könnten die Transformation verändern
- Datenprodukt-Container haben den Tisch als Kernbaustein der Daten im Visier
Müssen wir jetzt (wieder) alles neu aufbauen? Die Leiche der Hadoop-Ära ist noch nicht einmal ganz so kalt.
Die Antwort lautet: Ja, natürlich werden wir unsere Datensysteme neu aufbauen müssen. Wahrscheinlich sogar mehrmals im Laufe unserer Karriere. Die wirklichen Fragen sind das Warum, das Wann und das Wie (in dieser Reihenfolge).
Ich behaupte nicht, alle Antworten zu kennen oder eine Kristallkugel zu haben. Aber in diesem Artikel werden einige der wichtigsten Ideen der nahen Zukunft, die Teil des postmodernen Datenstapels werden könnten, sowie ihre potenziellen Auswirkungen auf die Datentechnik näher untersucht.
Praktische Aspekte und Abwägungen
Der moderne Data-Stack ist nicht entstanden, weil er alles besser kann als sein Vorgänger. Es gibt echte Kompromisse. Daten sind größer und schneller, aber sie sind auch unübersichtlicher und weniger kontrolliert. Die Frage der Kosteneffizienz ist noch nicht geklärt.
Der moderne Daten-Stack ist die Nummer eins, weil er Anwendungsfälle unterstützt und den Wert von Daten auf eine Art und Weise freisetzt, die früher wenn nicht unmöglich, dann doch sehr schwierig war. Das maschinelle Lernen hat sich vom Schlagwort zum Umsatzbringer entwickelt. Analysen und Experimente können tiefer gehen, um größere Entscheidungen zu unterstützen.
Das Gleiche gilt für jeden der folgenden Trends. Es wird Vor- und Nachteile geben, aber die Akzeptanz wird davon abhängen, wie sie oder die noch unentdeckte Idee neue Wege zur Nutzung von Daten erschließen. Schauen wir uns jeden Trend genauer an.
Zero-ETL
Was es ist: Eine falsche Bezeichnung, denn die Datenpipeline gibt es immer noch.
Heutzutage werden die Daten oft von einem Dienst generiert und in eine Transaktionsdatenbank geschrieben. Es wird eine automatische Pipeline eingesetzt, die nicht nur die Rohdaten in das analytische Data Warehouse transportiert, sondern sie auf dem Weg dorthin auch noch leicht modifiziert.
APIs exportieren beispielsweise Daten im JSON-Format, und die Ingestion-Pipeline muss die Daten nicht nur transportieren, sondern auch eine leichte Transformation vornehmen, um sicherzustellen, dass sie in einem Tabellenformat vorliegen, das in das Data Warehouse geladen werden kann. Andere gängige leichte Transformationen, die in der Ingestion-Phase durchgeführt werden, sind Datenformatierung und Deduplizierung.
Sie können zwar schwerere Transformationen durchführen, indem Sie Pipelines in Python hart kodieren, und einige haben sich dafür ausgesprochen, genau das zu tun, um Daten vormodelliert an das Warehouse zu liefern, aber die meisten Datenteams entscheiden sich aus Gründen der Zweckmäßigkeit und Sichtbarkeit/Qualität dagegen.
Zero-ETL ändert diesen Aufnahmeprozess, indem es die Transaktionsdatenbank die Datenbereinigung und ‑normalisierung durchführen lässt, bevor sie automatisch in das Data Warehouse geladen werden. Es ist wichtig zu beachten, dass die Daten immer noch in einem relativ rohen Zustand sind.
Derzeit ist diese enge Integration möglich, weil die meisten Zero-ETL-Architekturen voraussetzen, dass sowohl die Transaktionsdatenbank als auch das Data Warehouse vom selben Cloud-Anbieter stammen.
Vorteile: Geringere Latenzzeit. Keine doppelte Datenspeicherung. Eine Fehlerquelle weniger.
Nachteile: Weniger Möglichkeiten, die Behandlung der Daten während der Ingestionsphase anzupassen. Gewisse Anbieterbindung.
Wer ist die treibende Kraft? AWS ist die treibende Kraft hinter dem Schlagwort (Aurora zu Redshift), aber GCP (BigTable zu BigQuery) und Snowflake (Unistore) bieten alle ähnliche Funktionen. Snowflake (Secure Data Sharing) und Databricks (Delta Sharing) verfolgen ebenfalls das, was sie „No Copy Data Sharing“ nennen. Dieser Prozess kommt ohne ETL aus und bietet stattdessen einen erweiterten Zugriff auf die Daten dort, wo sie gespeichert sind.
Zweckmäßigkeit und Wert erschließen Potenzial: Einerseits scheint Zero-ETL mit der Unterstützung der Tech-Giganten und den einsatzbereiten Funktionen nur noch eine Frage der Zeit zu sein. Andererseits habe ich beobachtet, dass Datenteams ihre operativen und analytischen Datenbanken eher entkoppeln, als sie enger zu integrieren, um zu verhindern, dass unerwartete Schemaänderungen den gesamten Betrieb zum Erliegen bringen.
Diese Neuerung könnte die Sichtbarkeit und Verantwortlichkeit von Softwareingenieuren für die Daten, die ihre Dienste produzieren, weiter verringern. Warum sollten sie sich um das Schema kümmern, wenn die Daten bereits auf dem Weg zum Warehouse sind, kurz nachdem der Code übergeben wurde?
Da Data Steaming und Micro-Batch-Ansätze im Moment die meisten Anforderungen an „Echtzeit“-Daten zu erfüllen scheinen, sehe ich den primären geschäftlichen Antrieb für diese Art von Innovation in der Vereinfachung der Infrastruktur. Und obwohl das nicht zu verachten ist, könnte die Möglichkeit, Daten ohne Kopie auszutauschen und damit die Hindernisse für langwierige Sicherheitsüberprüfungen zu beseitigen, langfristig zu einer größeren Akzeptanz führen (wobei es sich natürlich nicht um ein Entweder-Oder handelt).
Eine große Tabelle und große Sprachmodelle
Was es ist: Gegenwärtig müssen die Stakeholder des Unternehmens ihre Anforderungen, Metriken und Logik den Datenexperten mitteilen, die das Ganze dann in eine SQL-Abfrage und vielleicht sogar in ein Dashboard umsetzen. Dieser Prozess nimmt Zeit in Anspruch, selbst wenn alle Daten bereits im Data Warehouse vorhanden sind. Ganz zu schweigen davon, dass Ad-hoc-Datenanfragen auf der Liste der Lieblingsaktivitäten des Datenteams irgendwo zwischen Wurzelbehandlung und Dokumentation rangieren.
Es gibt eine ganze Reihe von Start-ups, die darauf abzielen, die Leistungsfähigkeit großer Sprachmodelle wie GPT‑4 zu nutzen, um diesen Prozess zu automatisieren, indem sie den Kunden die Möglichkeit geben, die Daten in ihrer natürlichen Sprache über eine elegante Schnittstelle abzufragen.
Dies würde den Selbstbedienungs-Analyseprozess radikal vereinfachen und die Daten weiter demokratisieren, aber angesichts der Komplexität der Datenpipelines für fortschrittlichere Analysen wird es schwierig sein, eine Lösung zu finden, die über das grundlegende „Abrufen von Metriken“ hinausgeht.
Aber was wäre, wenn diese Komplexität vereinfacht werden könnte, indem man alle Rohdaten in eine große Tabelle packt?
Das war die Idee von Benn Stancil, einem der besten und fortschrittlichsten Autoren/Gründer der Datenbranche. Niemand hat sich den Tod des modernen Datenstapels besser vorgestellt.
Als Konzept ist es gar nicht so weit hergeholt. Einige Datenteams setzen bereits eine One Big Table (OBT)-Strategie ein, die sowohl Befürworter als auch Gegner hat.
Die Nutzung großer Sprachmodelle scheint eine der größten Herausforderungen bei der Verwendung einer einzigen großen Tabelle zu überwinden, nämlich die Schwierigkeit der Entdeckung, der Mustererkennung und des völligen Mangels an Organisation. Für Menschen ist es hilfreich, ein Inhaltsverzeichnis und gut gekennzeichnete Kapitel für ihre Geschichte zu haben, aber KI interessiert das nicht.
Vorteile: Vielleicht wird das Versprechen der Selbstbedienung bei der Datenanalyse endlich eingelöst. Schneller zu Erkenntnissen. Ermöglicht dem Datenteam, mehr Zeit mit der Erschließung des Datenwerts und dem Aufbau zu verbringen und weniger Zeit mit der Beantwortung von Ad-hoc-Anfragen.
Nachteile: Zu viel Freiheit? Datenexperten sind mit den schmerzhaften Eigenheiten von Daten (Zeitzonen! Was ist ein „Konto“?) in einem Maße vertraut, wie es die meisten Geschäftsinteressenten nicht sind. Profitieren wir von einer repräsentativen statt einer direkten Datendemokratie?
Wer das vorantreibt: Sehr frühe Startups wie Delphi und GetDot.AI. Startups wie Narrator. Etablierte Unternehmen wie Amazon QuickSight, Tableau Ask Data oder ThoughtSpot, die eine Version dieser Technologie anbieten.
Praxisnähe und Nutzen erschließen das Potenzial: Erfrischenderweise handelt es sich hier nicht um eine Technologie auf der Suche nach einem Anwendungsfall. Der Wert und die Effizienz sind offensichtlich – aber auch die technischen Herausforderungen. Diese Vision befindet sich noch im Aufbau und wird mehr Zeit zur Entwicklung benötigen. Das vielleicht größte Hindernis für die Einführung ist die erforderliche Störung der Infrastruktur, die für etablierte Unternehmen wahrscheinlich zu riskant ist.
Datenprodukt-Container
Was es ist: Eine Datentabelle ist der Datenbaustein, aus dem Datenprodukte erstellt werden. Tatsächlich betrachten viele Datenverantwortliche Produktionstabellen als ihre Datenprodukte. Damit eine Datentabelle jedoch wie ein Produkt behandelt werden kann, müssen viele Funktionen wie Zugriffsmanagement, Erkennung und Datenzuverlässigkeit hinzugefügt werden.
Die Containerisierung ist ein wesentlicher Bestandteil der Microservices-Bewegung in der Softwareentwicklung. Sie verbessern die Übertragbarkeit, die Abstraktion der Infrastruktur und ermöglichen es Unternehmen letztlich, Microservices zu skalieren. Das Konzept der Datenprodukt-Container sieht eine ähnliche Containerisierung der Datentabelle vor.
Datenproduktcontainer können sich als effektiver Mechanismus erweisen, um Daten zuverlässiger und kontrollierbarer zu machen, insbesondere wenn sie Informationen wie die semantische Definition, die Datenherkunft und Qualitätsmetriken, die mit der zugrunde liegenden Dateneinheit verbunden sind, besser sichtbar machen können.
Vorteile: Datenproduktcontainer scheinen eine Möglichkeit zu sein, die vier Grundsätze des Data Mesh (föderierte Governance, Datenselbstbedienung, Behandlung von Daten wie ein Produkt, Domain-First-Infrastruktur) besser zu bündeln und umzusetzen.
Nachteile: Erleichtert oder erschwert dieses Konzept den Unternehmen die Skalierung ihrer Datenprodukte? Eine weitere grundlegende Frage, die man sich bei vielen dieser futuristischen Datentrends stellen könnte, lautet: Enthalten die Nebenprodukte von Datenpipelines (Code, Daten, Metadaten) einen Wert für Datenteams, der es wert ist, erhalten zu werden?
Wer ist der Treiber? Nextdata, das von Zhamak Dehgahni, dem Erfinder von Data Mesh, gegründete Startup. Auch Nexla hat sich in diesem Bereich engagiert.
Praktikabilität und Nutzen erschließen das Potenzial: Obwohl Nextdata erst vor kurzem aus dem Verborgenen aufgetaucht ist und Datenprodukt-Container sich noch in der Entwicklung befinden, haben viele Datenteams bereits nachweisliche Ergebnisse mit der Implementierung von Datennetzen erzielt. Die Zukunft der Datentabelle wird von der genauen Form und Ausführung dieser Container abhängen.
Die endlose Neuplanung des Datenlebenszyklus
Um einen Blick in die Datenzukunft zu werfen, müssen wir der Datenvergangenheit und ‑gegenwart über die Schulter schauen. Vergangenheit, Gegenwart, Zukunft – Dateninfrastrukturen befinden sich in einem ständigen Zustand der Unterbrechung und Wiedergeburt (obwohl wir vielleicht noch etwas mehr Chaos brauchen).
Die Bedeutung von Data Warehouse hat sich seit der Einführung des Begriffs durch Bill Inmon in den 1990er Jahren drastisch verändert. ETL-Pipelines sind jetzt ELT-Pipelines. Der Data Lake ist nicht mehr so amorph, wie er noch vor zwei Jahren war.
Mit diesen Innovationen, die durch den modernen Data Stack eingeführt wurden, haben Dateningenieure immer noch eine zentrale, technische Rolle dabei gespielt, wie Daten bewegt werden und wie Datenkonsumenten auf sie zugreifen. Doch einige Veränderungen sind größer und beängstigender als andere.
Der Begriff Zero-ETL erscheint bedrohlich, weil er (fälschlicherweise) den Tod von Pipelines suggeriert, und brauchen wir ohne Pipelines Dateningenieure?
Trotz des ganzen Hypes um die Fähigkeit von ChatGPT, Code zu generieren, liegt dieser Prozess immer noch sehr stark in den Händen von technischen Dateningenieuren, die ihn überprüfen und debuggen müssen. Das Beängstigende an großen Sprachmodellen ist, dass sie die Datenpipeline oder unsere Beziehung zu den Datenkonsumenten (und die Art und Weise, wie ihnen die Daten bereitgestellt werden) grundlegend verändern könnten.
Diese Zukunft, falls und wenn sie eintritt, ist jedoch immer noch stark von den Dateningenieuren abhängig.
Was sich seit Anbeginn der Zeit gehalten hat, ist der allgemeine Lebenszyklus von Daten. Sie werden ausgegeben, geformt, verwendet und dann archiviert (am besten vermeiden wir es, hier über unsere eigene Sterblichkeit nachzudenken).
Die zugrundeliegende Infrastruktur mag sich zwar ändern und Automatisierungen werden Zeit und Aufmerksamkeit nach rechts oder links verlagern, aber menschliche Dateningenieure werden auf absehbare Zeit weiterhin eine entscheidende Rolle bei der Gewinnung von Werten aus Daten spielen.
Das liegt nicht daran, dass künftige Technologien und Innovationen die komplexen Dateninfrastrukturen von heute nicht vereinfachen können, sondern daran, dass unser Bedarf und unsere Nutzung von Daten immer ausgefeilter und umfangreicher werden.
Big Data ist und wird immer ein Pendel sein, das hin und her schwingt. Wir machen einen Kapazitätssprung, und dann finden wir genauso schnell einen Weg, diese Grenzen zu erreichen, bis der nächste Sprung erforderlich ist. Trösten Sie sich mit diesem Zyklus – es ist schön, gebraucht zu werden.
Quelle: medium.com
Erfahren Sie hier mehr über Lösungen im Bereich Data Engineering oder besuchen Sie eines unserer kostenlosen Webinare.
