Data Mess? Oder Data Mesh?
Daten sind der "Treibstoff" für ML. Dennoch ist es in vielen Projekten immer noch eine Herausforderung, die Daten richtig zu nutzen. Gründe dafür sind fehlende Dokumentation, Probleme mit der Datenqualität, fehlende historische Daten, Skalierbarkeitsprobleme mit Datenplattformen und ein allgemeiner Mangel an Verantwortung.
Bei ML6 empfehlen wir unseren Kunden, sich mit "Data Mesh" zu beschäftigen.
Vielleicht haben Sie bemerkt, dass dieses Konzept in den letzten Monaten von mehreren Personen, in Blogbeiträgen und Whitepapers erwähnt wurde. Es wurde sogar von McKinsey in "How to build a data architecture to drive innovation - today and tomorrow" aufgegriffen und war einer der Architekturtrends für 2020.
Bei Data Mesh geht es um die Rollen und Verantwortlichkeiten im Zusammenhang mit Daten sowie um die technischen und funktionalen Anforderungen an eine zukunftssichere Datenplattform für Analysen und KI.
Wir sind überzeugt, dass es die Art und Weise, wie eine Organisation mit Daten arbeitet, verbessern wird. Da wir jedoch festgestellt haben, dass das Konzept nicht leicht zu verstehen ist, wird es in diesem Blogbeitrag in drei leicht verständlichen Grundsätzen erklärt.
Die Ursprünge des "Data Mesh"
Zhamak Dehghani hat Data Mesh mit dem ursprünglichen Beitrag "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh" auf der Martin Fowler Website vorgestellt.
Ein Folge-Blogpost, "Data Mesh Principles and Logical Architecture", wurde veröffentlicht und Zhamaks Ansicht über die verfügbare Technologie wird 2021 verfügbar sein.
Unsere Interpretation von Data Mesh
Als wir den ursprünglichen Blogpost intern und mit mehreren Kunden geteilt haben, haben wir festgestellt, dass die Konzepte nicht leicht zu verstehen sind.
Personen mit technischem Hintergrund suchten sofort nach technischen Lösungen und ignorierten die erforderlichen organisatorischen Änderungen. Manager, die für Data Engineering oder traditionelle Business Intelligence-Teams verantwortlich sind, versuchen, die Konzepte zu ignorieren, die ihre Rolle und ihre Verantwortlichkeiten betreffen. Führungskräfte auf C-Level haben keine Zeit, den ausführlichen Blogbeitrag zu lesen und bitten um eine kurze Zusammenfassung und die nächsten Schritte.
Ich habe die wichtigsten Prinzipien eines Datennetzes in 3 leicht verständlichen Grundsätzen zusammengefasst.
- Jeder Bereich ist dafür verantwortlich und rechenschaftspflichtig, die von ihm erzeugten Daten als Datenprodukt zur Verfügung zu stellen.
Ein Datenprodukt ist
- Leichte Auffindbarkeit und Nutzung mit den im Unternehmen verwendeten Datenwerkzeugen und Anwendungen
- Bietet alle relevanten aktuellen und historischen Daten
- Dokumentiert
- vertrauenswürdig, d. h. die Daten müssen rechtzeitig und mit einer bestimmten Datenqualität verfügbar sein
- Sicher
2. Sie benötigen ein zentral verwaltetes Datenplattformteam mit Schwerpunkt auf
- Schaffung von "Selbstbedienungs"-Bausteinen für Domänen zur einfachen Erstellung hochskalierbarer Datenprodukte
- Unterstützung von Domains durch Hosting der Datenprodukte
- Gewährleistung eines reibungslosen Ablaufs in einer sicheren und vollständig konformen Umgebung
- Definition von Daten/MLOps-Grundsätzen und -Tools
- Überwachung der Daten/ML-Pipelines
Neben den technischen Komponenten müssen Sie sich auch um die Governance kümmern.
3. Eine zentralisierte Verwaltung ist erforderlich.
- Verwendung von Tools, die offenen Standards folgen, um Interoperabilität und einfachen, aber sicheren Datenzugriff und -integration zu gewährleisten
- Eine funktionellere Data Governance ist unerlässlich, um sicherzustellen, dass die Datenprodukte denselben Datendefinitionen folgen.
- dass Probleme mit der Datenqualität erkannt, verfolgt und in den Fahrplänen der einzelnen Bereiche behandelt werden.
Was passiert, wenn Sie dies in einer Organisation anwenden?
Erstens ist die funktionelle Verantwortung für die Bereitstellung von Daten dezentralisiert.
Indem Sie den Bereich, der die Daten erzeugt, dafür verantwortlich und rechenschaftspflichtig machen, seine Daten vollständig als Datenprodukt offenzulegen, vermeiden Sie mehrere Probleme:
- Die Domäne kennt die Geschäftslogik hinter den Daten, so dass Sie vermeiden, dass Dateningenieure, Datenanalysten und Datenwissenschaftler die Vorgänge zurückentwickeln müssen.
- Der Bereich hat einen Blick auf die Roadmap und (daten-)bezogene Änderungswünsche, so dass das Datenprodukt dem Release-Zyklus folgen muss, was oft vergessen wird, wenn die Verantwortung für die Daten bei einem anderen Team liegt.
- Die Domäne kann sich nicht vor Datenqualitätsproblemen verstecken, die andere Domänen betreffen, und es gibt keine Diskussionen mehr über "das funktioniert bei uns in der Anwendung".
Herausforderungen der Datenvernetzung
Die Rolle des Datenplattformteams und die Art der erforderlichen Werkzeuge sorgen für viel Verwirrung.
Was ist zum Beispiel Selbstbedienung?!?
Ist es ein Klick auf ein paar Schaltflächen in einer SaaS-Anwendung, um auf magische Weise alle Daten zu synchronisieren? Kann es ausreichen, die in Apache Airflow verfügbaren Operatoren zu erklären, um Daten aus einer operativen Anwendung in einen verteilten Speicher zu verschieben und in ein Cloud Data Warehouse zu laden?
Untersuchen Sie zunächst das Datenvolumen und die Arten von Anwendungsfällen, die den Datenprodukten zugrunde liegen. Wenn der Tech-Stack des Bereichs das Datenprodukt gemäß den Regeln des Datennetzes vollständig unterstützen kann, brauchen Sie die Daten nicht zu verschieben. Verschieben Sie sie nicht, sondern lassen Sie sie dezentralisiert.
Zweitens müssen Sie die Art der von den Bereichen genutzten Datenspeicher und SaaS-Dienste analysieren. Auf dieser Grundlage ist es möglich, einen unternehmensspezifischen Technologie-Stack zu definieren und den Bereichen eine ausreichende Anleitung für den Einstieg mit Unterstützung durch einen zentralen Pool von Daten-/Analyse- und ML-Ingenieuren zu bieten.
Wenn die Bereiche viel Unterstützung benötigen, empfiehlt es sich, diese Fähigkeiten dauerhaft in das Team des Bereichs einzubringen, aber sicherzustellen, dass diese Teammitglieder sich regelmäßig mit Personen mit ähnlichen Rollen und Verantwortlichkeiten und dem Datenplattformteam abstimmen.
Wir raten dazu, die Job-Orchestrierung vollständig zu zentralisieren.
Es ist wichtig, einen genauen Überblick über die Vorgänge in der Produktionsumgebung zu haben.
Das Datenplattformteam fungiert als Gatekeeper, um sicherzustellen, dass alles den Qualitätsstandards entspricht und die erforderlichen Supportprozesse vorhanden sind.
Je nach Art der Organisation und der Geschäftsprozesse ist der Reifegrad der Datenverwaltung sehr unterschiedlich. Für bestimmte Einheiten, z. B. Kunden, ist der gesamte Datenlebenszyklus oft vollständig geregelt und dokumentiert, und die Daten werden mit eindeutigen Kennungen in allen Anwendungen gespeichert. Bei anderen Geschäftsprozessen ist dies nicht der Fall, sobald man beginnt, Daten zu kombinieren, treten erhebliche Probleme auf.
Das vorzugsweise zentralisierte Data-Governance-Team ist für die Überwachung der Metadaten, der Datendefinitionen einschließlich der KPIs und der Datenqualität zuständig und bemüht sich um maximale Interoperabilität.
Fazit
Einige Teile der Datenverflechtungsmethodik und deren Zuordnung zur Technologie sind noch nicht vollständig geklärt und hängen in hohem Maße von der Unternehmenskultur, dem Budget und der technischen Ausstattung Ihres Unternehmens ab.
Auf dem Markt sehen wir zahlreiche Wettbewerber und Technologieunternehmen, die Data Mesh nutzen, um fortschrittliches Datenmanagement, DataOps/MLOps-Software und Datenvirtualisierungslösungen zu verkaufen.
Je nach Unternehmen werden diese Lösungen einen Mehrwert bieten, aber wir haben fantastische Ergebnisse gesehen, wenn wir es einfach halten und Technologien verwenden, die heute leicht verfügbar und erschwinglich sind.
Wir haben bei unseren Kunden großartige Ergebnisse mit Domänen gesehen, die mit ein wenig datentechnischer Unterstützung permanent Daten mit BigQuery synchronisieren und dabei vollständig serverlose Datenpipelines verwenden, die mit Cloud Composer/Apache Airflow geplant und überwacht werden.
Dies bietet genügend Beobachtbarkeit und Datenabfolge für technische Teams.
Google Data Catalog ermöglicht die Erkennung von Daten mit einigen zusätzlichen Tags und einem Link zu einem Wiki für tiefer gehende Informationen.
Jede Domäne veröffentlicht mehrere Dashboards mit der aktuellen Ansicht der Leistung/des rechtzeitigen Eintreffens der Datenpipelines, Datenqualitäts-KPIs und Beispiele für Betriebs-/Management-Dashboards, die die Daten in der Domäne präsentieren.
Da die Daten in BigQuery leicht zugänglich und vollständig verfügbar sind, verringerte sich der Zeitaufwand des Domänen- und Datentechnikteams für Punkt-zu-Punkt-Datensynchronisierungen.
Dies inspirierte andere Bereiche, mehr Daten in BigQuery zu übertragen.
Probleme mit der Datenqualität tauchen viel schneller auf und sind leichter zu verfolgen und zu beheben.
Nun, dies ist unsere Interpretation von Data Mesh.
Kontaktieren Sie uns, wenn Sie Fragen oder Kommentare haben!
In Zukunft werden wir weitere Blogbeiträge veröffentlichen, in denen wir moderne Technologien hervorheben, die im Zusammenhang mit Data Mesh nützlich sind, und wie wir sehen, dass moderne Datenteams die Einführung fortschrittlicher Analysen und KI beschleunigen können.