Warum brauchen wir eine Datenarchitektur?
Eine datengesteuerte Organisation zu werden, ist nach wie vor eines der wichtigsten strategischen Ziele vieler Unternehmen. Datengesteuert bedeutet, Daten in den Mittelpunkt aller Entscheidungen und Prozesse zu stellen, die im Unternehmen getroffen werden.
Führungskräfte wissen, dass eine datengesteuerte Organisation der einzige Weg ist, um das Kundenerlebnis durch Hyperpersonalisierung und Neugestaltung der Customer Journey zu verbessern, die Betriebskosten durch Automatisierung und maschinelles Lernen zu senken und Geschäftstrends zu verstehen, die für die Strategie und Marktpositionierung auf höchster Ebene wichtig sind. Eine Datenplattform schafft ein gedeihliches Umfeld für das Gedeihen von Daten.
Eine Datenplattform ist ein Aufbewahrungs- und Verarbeitungsort für alle Daten eines Unternehmens. Sie kümmert sich um die Sammlung, Bereinigung, Umwandlung und Anwendung von Daten, um geschäftliche Erkenntnisse zu gewinnen. Sie wird manchmal auch als "moderner Datenstapel" bezeichnet, da die Datenplattform oft aus mehreren integrierten Tools besteht, die von verschiedenen Anbietern unterstützt werden (u. a. Dbt, Snowflake, Kafka).Eines der wichtigsten Elemente Ihrer Datenplattform ist die Datenarchitektur. Die Datenarchitektur ist der Prozess der Entwicklung, des Aufbaus und der Verwaltung der Struktur der Datenbestände des Unternehmens. Sie ist eine Art Rahmen für die Integration von Daten aus verschiedenen Quellen und Anwendungen.
Das Hauptziel einer gut konzipierten Datenarchitektur besteht darin, Datensilos zu reduzieren, die Datendopplung zu minimieren und die Gesamteffizienz des Datenverwaltungsprozesses zu verbessern.
Mit der Entwicklung der Datenlandschaft in den letzten Jahrzehnten hat sich auch die Datenarchitektur weiterentwickelt. Schauen wir uns diese Entwicklung im Detail an.
Analytische Daten haben einen evolutionären Wandel durchlaufen, der durch neue Nutzungsmodelle vorangetrieben wird und von der traditionellen Analyse zur Unterstützung von Geschäftsentscheidungen bis hin zu intelligenten Produkten reicht, die durch ML erweitert werden.
Erste Generation: Data-Warehouse-Architektur
Die Data-Warehouse-Architektur wird durch die Datenbewegung von operativen Systemen (SAP, Salesforce) und 1st-Party-Datenbanken (MySQL, SQL Server) zu Business-Intelligence-Systemen definiert. Das Data Warehouse ist der zentrale Punkt, in dem ein Schema definiert wird (Schneeflockenschema, Sternschema) und in dem Daten in Dimensionen und Faktentabellen gespeichert werden, die es Unternehmen ermöglichen, Änderungen in ihren Abläufen und Kundeninteraktionen zu verfolgen.
Daten sind:
- aus vielen operativen Datenbanken und Quellen extrahiert
- in ein universelles Schema umgewandelt, das in einem multidimensionalen und zeitvariablen Tabellenformat dargestellt wird
- über einen CDC-Prozess (Change Data Capture) in die Warehouse-Tabellen geladen
- zugfreifbar über SQL-ähnliche Abfragen
- hauptsächlich für Datenanalysten für Berichte und analytische Visualisierungszwecke
Bei diesem Architekturstil kommen auch Data Marts zum Einsatz. Sie sind eine zusätzliche Schicht (bestehend aus einer oder mehreren Tabellen) über dem Data Warehouse, um spezifische Geschäftsprobleme der Abteilungen mit einem bestimmten Schemaformat zu bedienen. Ohne Data Marts müssten diese Abteilungen mehrere Abfragen im Data Warehouse durchführen und erstellen, um die Daten mit dem von ihnen benötigten Inhalt und Format zu erhalten.
Die größten Herausforderungen bei diesem Ansatz:
- Im Laufe der Zeit werden Tausende von ETL-Aufträgen, Tabellen und Berichten erstellt, die nur eine spezialisierte Gruppe verstehen und pflegen kann.
- Moderne technische Verfahren wie CI/CD werden nicht angewandt.
- Das Datenmodell und das Schema-Design für Data Warehouses sind zu starr, um ein riesiges Volumen an strukturierten und unstrukturierten Daten aus verschiedenen Quellen zu verarbeiten.
Dies führt uns zur nächsten Generation der Datenarchitektur.
Zweite Generation: Data Lake Architektur
Die Data Lake-Architektur wurde 2010 als Antwort auf die Herausforderungen der Data-Warehousing-Architektur bei der Erfüllung der neuen Verwendungszwecke von Daten eingeführt: Zugriff auf Daten durch Datenwissenschaftler beim Trainingsprozess für maschinelles Lernen.
Datenwissenschaftler benötigen Daten in ihrer ursprünglichen Form für den Trainingsprozess von Modellen des maschinellen Lernens (ML). ML-Modelle erfordern außerdem große Datenmengen, die in einem Data Warehouse nur schwer zu speichern sind.
Bei den ersten Data Lakes wurden die Daten im Hadoop Distributed File System (HDFS) über eine Reihe von geclusterten Rechenknoten gespeichert. Die Daten wurden mithilfe von MapReduce, Spark und anderen Datenverarbeitungs-Frameworks extrahiert und verarbeitet.
Die Data Lake-Architektur arbeitet nach dem ELT-Prozess und nicht nach dem ETL-Prozess. Die Daten werden aus den operativen Systemen extrahiert (E) und in ein zentrales Speicherrepository geladen (L). Im Gegensatz zum Data Warehousing setzt ein Data Lake jedoch nur eine sehr geringe oder gar keine Transformation und Modellierung der Daten im Vorfeld voraus. Das Ziel ist es, die Daten in ihrer ursprünglichen Form zu erhalten. Sobald die Daten in den See gelangen, wird die Architektur um Datenumwandlungspipelines (T) erweitert, um die Rohdaten zu modellieren und sie im Data Warehouse oder in Feature Stores zu speichern.
Data-Engineering-Teams schaffen verschiedene „Zonen“, um den See besser zu organisieren. Ziel ist es, die Daten je nach Bereinigungs- und Transformationsgrad zu speichern, von den rohesten Daten über Datenanreicherungsschritte bis hin zu den saubersten und am besten zugänglichen Daten.
Diese Datenarchitektur zielt darauf ab, die Ineffektivität und die Reibungsverluste der umfangreichen Up-Front-Modellierung, die das Data Warehousing erfordert, zu verbessern. Die Up-Front-Transformation ist ein Hemmschuh und führt zu langsameren Iterationen für den Datenzugriff und das Modelltraining.
Die größten Herausforderungen bei diesem Ansatz:
- Die Data-Lake-Architektur leidet unter der Komplexität und Verschlechterung der Datenqualität und ‑zuverlässigkeit.
- Komplexe Pipelines aus Batch- oder Streaming-Aufträgen, die von einem zentralen Team aus hochspezialisierten Dateningenieuren betrieben werden.
- Es werden nicht verwaltete Datensätze erstellt, die oft nicht vertrauenswürdig und unzugänglich sind und wenig Wert bieten.
- Die Datenherkunft und die Abhängigkeiten sind schwer zu verfolgen
- Das Fehlen einer umfassenden Datenmodellierung im Vorfeld führt zu Schwierigkeiten bei der Erstellung einer semantischen Zuordnung zwischen verschiedenen Datenquellen und damit zur Entstehung von Datensümpfen.
Dritte Generation: Cloud-Data-Lake-Architektur
Die größten Veränderungen von der Datenarchitektur der zweiten Generation zur dritten Generation waren der Wechsel zur Cloud, die Verfügbarkeit von Daten in Echtzeit und die Konvergenz zwischen Data Warehouse und Data Lake. Mehr im Detail:
- Unterstützung von Streaming für Datenverfügbarkeit nahezu in Echtzeit mit Architekturen wie Kappa.
- Vereinheitlichung der Batch- und Stream-Verarbeitung für die Datentransformation mit Frameworks wie Apache Beam.
- Vollständige Nutzung von Cloud-basierten verwalteten Diensten und Verwendung moderner Cloud-nativer Implementierungen mit isolierter Datenverarbeitung und Speicherung. Die Speicherung von Daten wird viel billiger.
- Konvergenz von Data Warehouse und Data Lake in einer Technologie, entweder durch Erweiterung des Data Warehouse um eingebettetes ML-Training oder durch die Integration von Data-Warehouse-Integrität, Transaktionsfähigkeit und Abfragesystemen in Data-Lake-Lösungen. Databricks Lakehouse ist ein Beispiel für eine herkömmliche Lake-Storage-Lösung mit warehouseähnlichen Transaktionen und Abfrageunterstützung.
Der Cloud Data Lake schließt einige der Lücken, die die vorherigen Generationen hinterlassen haben. Dennoch bleiben einige Herausforderungen bestehen:
- Die Verwaltung der Data Lake-Architektur ist nach wie vor sehr komplex und beeinträchtigt die Datenqualität und ‑zuverlässigkeit.
- Das Architekturdesign bleibt zentralisiert und erfordert ein Team von hochspezialisierten Dateningenieuren.
- Lange Zeit für Erkenntnisse. Datenkonsumenten müssen nach wie vor mehrere Monate warten, bis sie einen Datensatz für Analysen oder maschinelle Lernverfahren erhalten.
- Data Warehouses sind keine Nachbildung der realen Welt durch Daten mehr, was sich auf die Erfahrung der Datenkonsumenten bei der Erkundung von Daten auswirkt.
All diese Herausforderungen haben uns zur Datenarchitektur der vierten Generation geführt, die sich zum Zeitpunkt der Veröffentlichung dieses Artikels noch in der Anfangsphase befindet.
Vierte Generation: Data Mesh-Architektur
Die Data-Mesh-Architektur ist ein relativ neuer Ansatz für die Datenarchitektur, der versucht, einige der Herausforderungen zu bewältigen, die bei früheren zentralisierten Architekturen festgestellt wurden.
Die Data Mesh-Architektur bringt für die Datenarchitektur das, was Microservices für monolithische Anwendungen gebracht haben.
In einem Datengeflecht sind die Daten dezentralisiert und das Eigentum an den Daten ist auf verschiedene Domänen verteilt. Jede Domäne ist für die Daten in ihrem Bereich verantwortlich, einschließlich Datenmodellierung, ‑speicherung und ‑verwaltung, und die Architektur muss eine Reihe von Praktiken bereitstellen, die es jeder Domäne ermöglichen, ihre Daten unabhängig zu verwalten.
Hier sind die wichtigsten Komponenten einer Data-Mesh-Architektur:
- Domänen – Eine Domäne ist eine in sich geschlossene Geschäftseinheit, die ihre eigenen Daten besitzt und verwaltet. Jede Domäne hat einen klaren Geschäftszweck und ist für die Definition von Datenmodellierung, Entitäten, Schema und Richtlinien für die Datenverwaltung verantwortlich. Dieses Konzept unterscheidet sich von den Data Marts in der Data Warehouse-Architektur, die für verschiedene Teams wie Marketing oder Vertrieb konzipiert sind. In einer Data-Mesh-Architektur kann der Vertrieb mehrere Domänen haben, je nach den verschiedenen Schwerpunkten/Bereichen, die das Team haben könnte.
- Datenprodukte – Ein Datenprodukt ist das Endergebnis dessen, was von einer Domäne produziert und anderen Domänen oder Anwendungen zur Verfügung gestellt wird. Jedes Datenprodukt hat einen klaren Geschäftszweck. Eine Domäne kann mit mehreren Datenprodukten arbeiten. Nicht alle Datenbestände werden als Datenprodukt betrachtet oder sollten als Datenprodukt behandelt werden (obwohl dies in einer perfekten Welt der Fall wäre). Datenprodukte sind Datenbestände, die in der Organisation eine Schlüsselrolle spielen.
- Dateninfrastruktur – Die Dateninfrastruktur umfasst die Tools und Technologien, die zur Verwaltung von Daten innerhalb einer Domäne benötigt werden, ähnlich wie ein containerisierter Microservice für eine Softwareanwendung. Dazu gehören Tools für die Speicherung, Verarbeitung und Analyse von Daten.
- Data Governance – Data Governance wird von jeder Domäne verwaltet. Dies bezieht sich auf eine Reihe von Verfahren zur Regelung der Datenqualität, des Datenschutzes und der Sicherheit.
- Mesh-API - So wie ein Microservice alles über HTTP-REST-APIs offenlegt, würde eine Data-Mesh-Domäne alles über eine klar definierte Schnittstelle offenlegen, die von anderen Domänen und Datenprodukten genutzt werden kann.
Data Mesh ist ein Paradigmenwechsel in der Art und Weise, wie Datenarchitekturen entworfen werden und wie Datenteams heutzutage organisiert sind:
- Datenteams werden zu funktionsübergreifenden Teams, die auf einen oder mehrere Geschäftsbereiche (nicht auf Technologie) spezialisiert sind, so wie Softwareproduktteams sehr serviceorientiert sind.
- Jede Geschäftsdomäne, die aus einem oder mehreren Microservices besteht, verfügt über eine eigene OLAP-Datenbank und ein verteiltes Dateispeichersystem, so wie jedes Teil eines Microservices in einem Container untergebracht ist, um unabhängig zu arbeiten.
- Datenprodukt A wird von Datenprodukt B konsumiert, und beide kommunizieren mit anderen Datenprodukten über Streaming oder REST-API, genau wie Anwendungs-Microservices miteinander kommunizieren.
- Die Datenprodukt-APIs werden von der traditionellen REST-API-Dokumentation begleitet, und die Datenprodukte können über den Mesh-Datenkatalog gefunden werden.
Was ändert sich bei Data Mesh außer der Architektur noch?
Die einschneidendste Veränderung durch Data Mesh ist die Architektur. Aber der Übergang von einem zentralisierten Data Lake zu einem dezentralisierten Data Mesh ist ein soziotechnisches Phänomen, das mehrere zusätzliche Änderungen mit sich bringt.
Wenn Sie sich erinnern, hat der Übergang von monolithischen Anwendungen zu Microservice-Anwendungen dazu geführt, dass Software-Engineering-Teams ihren Entwicklungslebenszyklus, ihre Organisationsstruktur, ihre Motivationen, ihre Fähigkeiten und ihre Governance ändern mussten. Damals entstand die Rolle des Produktmanagers, um sicherzustellen, dass die Anwendungen echte Benutzerprobleme lösen.
Das Gleiche muss bei der Anwendung einer Datengitterarchitektur geschehen.
Quelle: medium
Erfahren Sie hier mehr über Lösungen im Bereich Data Architecture oder besuchen Sie eines unserer kostenlosen Webinare.
