Grundlagen der Beobachtbarkeit von Daten

Kapitel 1. Einführung in die Beobachtbarkeit von Daten

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Es war einmal ein junger Datenanalyst namens Alex, der eine große Leidenschaft für Daten hatte. Alex liebte die Art und Weise, wie Daten Unternehmen helfen können, fundierte Entscheidungen zu treffen, ihr Wachstum voranzutreiben und erfolgreich zu sein. Alex war sich aber auch der Gefahren bewusst, die entstehen, wenn Daten falsch interpretiert werden oder man nicht genug Einblick in die Daten hat.

Alex arbeitete zusammen mit einer Dateningenieurin namens Sarah an einem wichtigen Projekt. Sarah war dafür verantwortlich, die Daten vorzubereiten und sicherzustellen, dass sie für die Analyse bereit waren. Als sie tiefer in das Projekt eintauchten, stellten Alex und Sarah fest, dass viele Variablen im Spiel waren und dass die Daten, mit denen sie arbeiteten, nicht so einfach waren, wie sie anfangs dachten.

Eines Tages, als Alex seine Analyse wiederholte, um neue Erkenntnisse zu gewinnen, fiel ihm auf, dass die Ergebnisse, die er an diesem Tag präsentierte, seltsam aussahen und nur schwer mit dem in Verbindung gebracht werden konnten, was er bis dahin gesehen hatte. Er ging zu Sarah, um den Fall zu besprechen, aber Sarah brauchte mehr Kontext zu seiner bisherigen Interpretation oder zu seinen Erwartungen und was er von ihr überprüfen lassen wollte.

Nach vier Tagen Zusammenarbeit, Paarprüfungen und mehreren Brainstorming-Sitzungen entdeckten Sarah und Alex, dass subtile Veränderungen in der Verteilung von einem halben Dutzend Variablen der eingehenden Daten die gewonnenen Erkenntnisse nach mehreren Transformationsschritten veränderten. Einige Variablen wiesen mehr fehlende Werte auf und wurden daher bei der bereinigenden Transformation weggelassen, bei anderen wurde der Durchschnittswert stark erhöht und einer der Datensätze wurde dank einer besseren Extraktion aus den operativen Quellen mit fast doppelt so vielen Daten aufgefrischt wie zuvor.

Obwohl Sarah und Alex ursprünglich dachten, dass die Qualität der Daten gesunken sein könnte, stellte sich heraus, dass sich die Daten einfach verändert hatten und ihre Annahmen über die Daten angepasst werden mussten. Sie erkannten, dass sie Glück hatten, dass dies passiert war, bevor sie das Projekt in die Produktion überführten, und dass diese Art von Situation in Zukunft wahrscheinlich noch oft auftreten würde. Wenn sie diese Änderungen nicht vorhergesehen hätten, wären sie in Schwierigkeiten geraten.

Diese Erfahrung machte ihnen klar, wie wichtig die Beobachtbarkeit der Daten ist. Sie brauchten Einblick in die Daten, ihre Umwandlungen und ihre Nutzung, um schnell auf Veränderungen reagieren zu können. Sie begannen, die Prinzipien der Datenbeobachtung zu übernehmen und instrumentierten ihre Datenpipelines, um die erforderlichen Funktionen hinzuzufügen, die Echtzeiteinblicke in die Daten, ihre Qualität und ihre Nutzung ermöglichen.

Von diesem Tag an wurden sie mit Dashboard- und Benachrichtigungssystemen unterstützt, die den Zustand der Daten in den Pipelines überwachen und sie auf alle Probleme aufmerksam machen, die behoben werden müssen, um sicherzustellen, dass der Kunde immer genaue und zuverlässige Daten erhält.

Durch diese Erfahrung lernten Alex und Sarah, dass Daten eine lebende und atmende Einheit sind, die ständig überwacht und beobachtet werden muss. Sie erkannten, dass sie ohne die Beobachtung der Daten nicht in der Lage wären, schnell auf Veränderungen zu reagieren und damit den Erfolg des Projekts zu gefährden.

Wenn du dieses Buch liest, dann wahrscheinlich, weil du, wie Sarah und Alex, ähnliche Situationen bei deiner eigenen Arbeit mit Daten erlebt hast oder erwartest. Du kennst die Macht der Daten, aber auch die potenziell katastrophalen Folgen, wenn selbst kleinste Veränderungen unbemerkt bleiben.

Aber du weißt nicht, was du tun sollst oder wie du anfangen sollst. Das ist kein Grund zur Sorge. In diesem Buch erfährst du, was Alex und Sarah getan haben, um die Prinzipien der Datenbeobachtung einzuführen und sicherzustellen, dass ihre Datenpipelines zuverlässig sind und ihre Kunden genaue und vertrauenswürdige Daten erhalten. Wenn du diese Prinzipien auf deine eigene Arbeit anwendest, kannst du die Fallstricke unzuverlässiger Daten vermeiden und eine solide Grundlage für den Erfolg deiner datengesteuerten Projekte schaffen.

Bevor ich näher darauf eingehe, was Datenbeobachtung ist und was sie im großen Maßstab bietet, wollen wir uns zunächst ansehen, wie sich Datenteams entwickeln und welche Herausforderungen sie bewältigen müssen.

Skalierung von Datenteams

Mehr Aufgaben, mehr Verantwortung, mehr Technik.

Ein Datenteam ist eine Gruppe von Datenexperten, die zusammenarbeiten, um Daten zu sammeln, zu verarbeiten, zu analysieren und zu interpretieren, um Erkenntnisse zu gewinnen und Entscheidungen zu treffen, die zu besseren Geschäftsergebnissen führen und die Unternehmensleistung verbessern.

Da Datenteams in Unternehmen eine strategische Rolle spielen, kann ihre operative Effizienz zu einem Engpass werden, wenn es darum geht, stark nachgefragte Daten in wichtige Geschäftsabläufe einzubinden. Um dies zu bewältigen, haben sich Datenteams ähnlich wie IT-Teams in den 1950er Jahren weiterentwickelt - es wurden spezielle Rollen wie Systemingenieure, Webingenieure oder Backend-Ingenieure geschaffen, um bestimmte Abläufe zu unterstützen, anstatt Generalisten zu sein.¹

Mit der zunehmenden Komplexität von Datenteams und zusätzlichen Rollen sind mehr Interaktionen und Abhängigkeiten zwischen den Mitgliedern und Teams entstanden, was den Bedarf an mehr Sichtbarkeit, Transparenz und Standardisierung erhöht.

Im weiteren Verlauf dieses Abschnitts werde ich search trends als Beispiel verwenden, um die Bildung und Skalierung von Datenteams und die Rolle des Data Engineers zu veranschaulichen. Die Auswirkungen und Herausforderungen, die damit verbunden sind, werden im folgenden Abschnitt behandelt, in dem auch andere Rollen, wie z. B. die des Analytikers, beschrieben werden.

Beginnen wir mit einer Google Trends-Suche(Abbildung 1-1) nach dem Begriff "Datenteam" von 2004 bis 2020. Wir sehen, dass es Datenteams zwar schon immer gab, das Interesse an Datenteams aber erst ab 2014 zunahm und sich zwischen 2014 und 2020 deutlich beschleunigte.

Abbildung 1-1. Google-Suche Trend für "Datenteam"

Dies ist , obwohl das Interesse an "Big Data" abnimmt (wie in Abbildung 1-2 dargestellt).

Abbildung 1-2. Analyse des Suchbegriffs "Big Data" bei Google Trends²

Das bedeutet natürlich nicht, dass Big Data nicht mehr gebraucht wurde, aber wie Abbildung 1-3 zeigt, verlagerte sich der Schwerpunkt 2014 auf Data Science, weil die Verbindung zur Wertschöpfung intuitiver war.

Abbildung 1-3. Google-Trends für die Suchbegriffe "Data Engineer" und "Data Scientist"

Doch selbst als das Interesse an Data Science ( ) zu steigen begann, war klar, dass die Verfügbarkeit von Daten ein Hindernis für viele Data-Science-Projekte darstellte.

Data Science Teams haben Big Data Teams nicht ersetzt. Stattdessen haben sich die Datenteams die Analytik zu eigen gemacht und damit auch die relativ neue Rolle des Datenwissenschaftlers.

Da Daten und Analysen für den Erfolg von Unternehmen immer wichtiger werden, bleibt die Bereitstellung der richtigen Daten für die richtigen Personen eine ständige Herausforderung. Gartner stellte fest, dass im Jahr 2018,³ Dateningenieure bei der Bewältigung der Herausforderungen in Bezug auf die Datenverfügbarkeit von entscheidender Bedeutung geworden sind und dass die Verantwortlichen für Daten und Analysen daher "eine Data-Engineering-Disziplin als Teil ihrer Datenmanagement-Strategie entwickeln" müssen.

Es wurde also deutlich, dass eine Funktion fehlte, die sich mit der Produktion von Daten für nachgelagerte Anwendungsfälle befasst. Deshalb ist das Suchvolumen für Data Engineers seit etwa 2020 deutlich gestiegen, als Unternehmen begannen, Ingenieure speziell für den Aufbau von Datenpipelines und die Zusammenführung von Daten aus verschiedenen Quellsystemen einzustellen. Wie in Abbildung 1-3 zu sehen ist, ist Data Engineering heute auf dem besten Weg, den Data Scientist in der Beliebtheit der Suche einzuholen.

Daten als Metrik

Die Datenverfügbarkeit ist eine der Kennzahlen, die die Beobachtbarkeit von Daten bestimmen. Es gibt wichtige Metriken und Metadaten, die sich auf die Datenverfügbarkeit beziehen, z. B. die Time to Live (TTL) und die Aktualisierungsrate (Freshness) eines Datensatzes. Es gibt aber auch Feinheiten, auf die wir im Laufe des Buches eingehen werden, wie z. B. die Beschaffung von Daten, Datenschutz- und Sicherheitsaspekte usw. In der Zwischenzeit ermöglicht die Trennung der Rollen jedoch, dass die verschiedenen Kompetenzen Zeit und Raum erhalten und die Ressourcen auf die verschiedenen Phasen der Datenprojekte konzentriert werden können.

Wie bereits erwähnt, bringt die Skalierung von Datenteams mit mehr Mitarbeitern, Rollen und Verantwortlichkeiten eigene Herausforderungen mit sich. Im nächsten Abschnitt werden wir dieses Thema näher beleuchten.

Herausforderungen bei der Skalierung von Datenteams

Wenn Unternehmen ihre Datennutzung skalieren wollen, müssen sie auch ihre Datenteams skalieren. Ich werde die Herausforderungen und ihre Folgen anhand der folgenden Beispiele erläutern:

• Eine Beschreibung der Entstehung von Rollen und Verantwortlichkeiten in einem Datenteam.

• Eine Analyse der operativen Komplexität, wenn das Team wächst.

• Eine Veranschaulichung der Herausforderungen des (Daten-)Ausgabemanagements und deren Auswirkungen auf die Stimmung und Effizienz des Datenteams.

• Ein Hinweis zur Vorsicht, um Misserfolge auf dem Weg zu ML/AI zu vermeiden.

Stell dir ein Datenteam vor, das mit einer einzigen Person beginnt, die mit der Datenaufnahme, der Datenintegration und sogar dem Abschlussbericht beauftragt ist. Für diese Person könnte ein erstes Projekt darin bestehen, eine Übersicht über die letzten Kundenakquisitionen zu erstellen.

Der Dateningenieur müsste die Quelldaten aus dem CRM-System ( Customer Relationship Management ) des Unternehmens abfragen und in den Data Lake einlesen, sie in das Data Warehouse integrieren und einen Bericht erstellen, der dem Vertriebsleiter einen Einblick in den Verlauf der Verkäufe der letzten Wochen gibt.

Dieses erste Mitglied des Datenteams ist im Grunde ein Schweizer Taschenmesser: Es ist sowohl für die Datentechnik als auch für die Datenanalyse zuständig, um das Projektergebnis (den Bericht) zu liefern.

In einem größeren Datenteam sind die Fähigkeiten, die für diese Arbeit erforderlich sind, ausgewogen zwischen Datentechnik, Datenanalyse und Geschäftsanalyse. In einem Ein-Mann-Team muss eine Person jedoch die Technologien beherrschen, die für den Aufbau und den Betrieb der Pipeline erforderlich sind, sowie die Reporting-Tools und die geschäftlichen Leistungskennzahlen (KPIs) verstehen. Jeder dieser Bereiche erfordert spezielle Fachkenntnisse.

Bis jetzt ist diese Person zufrieden, und der Arbeitsumfang und die Verantwortlichkeiten sind wie in Abbildung 1-4 dargestellt.

Abbildung 1-4. Ein glückliches Ein-Personen-Daten-Team und seine Arbeit

Natürlich ist der Prozess nicht ganz so einfach. So sollte zum Beispiel ein ganzer Systementwicklungszyklus (SDLC) durchlaufen werden, damit die Daten in Produktion gehen und dem Endnutzer zur Analyse zur Verfügung stehen können. Auf einer sehr abstrakten Ebene ist dieser grundlegende Prozess jedoch das, was wir meist als "Wertschöpfung" bei einem Datenprojekt verstehen.

Mit nur einem Teammitglied und einem Datenprojekt hast du das gesamte Datenökosystem relativ gut im Griff.

Der Prozess ist einfach genug für eine Person, und die Verantwortung für das gesamte Projekt wird ebenfalls dieser Person zugeschrieben. Da nur eine Person im Team ist, hat sie auch eine enge Beziehung zu den Stakeholdern des Unternehmens - wie z. B. dem Vertriebsleiter - und hat daher ein gewisses Fachwissen über den Anwendungsfall und das Geschäftsziel des Projekts aufgebaut. Obwohl diese Aufgabe normalerweise von einem Business-Analysten übernommen wird, übernimmt in diesem Fall auch der Data Engineer diese Funktion.

Wenn der/die Nutzer/in also Probleme aufwirft, ist klar, wer sich um die Fehlerbehebung kümmern sollte. Schließlich haben sie nicht nur jeden Schritt des Prozesses ausgeführt, sondern kennen auch jeden Bereich des Prozesses.

Wenn die Interessengruppen jedoch das Potenzial und den Wert von Daten erkennen, werden immer mehr Anfragen für neue Berichte, Informationen, Projekte usw. an diese Person gestellt. Infolgedessen werden die Anforderungen immer komplexer, und schließlich stößt die Person unter den derzeitigen Bedingungen an die Grenzen ihrer Produktionskapazität. Folglich wird es dringend notwendig, das Team zu vergrößern und in spezialisierte Mitglieder zu investieren, um die Produktivität zu optimieren.

Im nächsten Abschnitt werden wir sehen, wie dieses Team wächst, wenn bestimmte Rollen geschaffen werden, wie in Tabelle 1-1 dargestellt, die auch die Verantwortlichkeiten und Abhängigkeiten jeder Rolle hervorhebt.

Tabelle 1-1. Rollen, Verantwortlichkeiten und Abhängigkeiten des (erweiterten) Datenteams.^a

Titel/Rolle	Zuständigkeiten	Abhängigkeiten
Softwareentwicklung und Betriebsingenieur	Aufbau und Wartung der Plattform; Verwaltung von Sicherheit und Compliance; Überwachung des Site Reliability Engineering (SRE)	Empfehlungen von anderen Teams erhalten, was zu überwachen ist und was als Fehler zu betrachten ist
Dateningenieur	Baue die Datenpipelines auf und verwalte die Daten von der Bereitstellung bis zur Produktion	Verlasse dich auf die IT-Abteilung, um die Plattform aufzubauen und die Tools für die Überwachung der Pipeline und der Systeme einzurichten, einschließlich der Tools für die Beobachtung der Daten
Analytik-Ingenieur	Ähnlich wie beim Data Engineering mit einem stärkeren Fokus auf Datenmodellierung und Wiederverwendbarkeit	Verlasse dich auf das Data-Engineering-Team, um die operativen Datenquellen in der Analyseplattform verfügbar zu machen
Analytiker/Datenwissenschaftler	Erstelle Analyse- und KI/ML-Modelle, die Daten für die Anwendungsfälle des business Teams analysieren und interpretieren können.	Verlasse dich auf das Daten- und Analyseteam, um die Pipeline zur Generierung der Daten zu erstellen, die sie für ihre Berichte und maschinellen Lernmodelle verwenden werden.
Datenverwalter	Sicherstellen, dass die Daten unter Kontrolle sind und die Data-Governance-Richtlinien eingehalten werden; mit ihrem Verständnis der Daten, ihres Potenzials und ihrer Qualität auch das Scoping von Datenprodukten oder Projekten erleichtern	Verlassen Sie sich auf die Metadaten und andere Informationen zu den Daten, die von den vorgelagerten Teams zur Verfügung gestellt werden, um Vertrauen in die von den nachgelagerten Nutzern verwendeten Daten zu schaffen und zu erhalten
Business/Domain Stakeholder	Entwickle Anwendungsfälle und nutze Datenanalysen, um Geschäftsentscheidungen zu treffen	Verlasse dich auf alle vorgelagerten Teams (wahrscheinlich auch in anderen Bereichen), um sicherzustellen, dass die Daten und Analysen korrekt sind
a Anmerkung: Ich habe die Dateneigentümer und Datenprodukteigentümer/-manager nicht hinzugefügt, weil ihre Bedürfnisse und Abhängigkeiten von den Stewards und Stakeholdern relativ gut abgedeckt werden. Natürlich sage ich nicht, dass sie dasselbe sind!

Außerdem gibt es auf dem Markt einen Mangel an Fachkräften in den Bereichen Data Engineering, Data Science und Datenanalysten, so dass es eine große Herausforderung ist, ein Team aufzubauen.⁴

Das gilt vor allem am Anfang, wenn alles parallel aufgebaut werden muss, z. B. die Kultur, der Reifegrad, die Organisationsstruktur usw. Umso wichtiger ist es, die Talente, die du hast, zu halten, und das bedeutet, dass ihre Rollen und Aufgaben mit ihren Fähigkeiten übereinstimmen müssen. Im nächsten Abschnitt werden wir herausfinden, wie diese Rollen hinzugefügt werden, was von ihnen erwartet wird und was mit dem Team im Laufe der Zeit passiert.

Getrennte Rollen und Zuständigkeiten und organisatorische Komplexität

Das Ein-Personen-Team hat seine maximale Kapazität für die Erstellung neuer Berichte erreicht und hat ein weiteres Mitglied eingestellt, um mit dem Tempo der eingehenden Anfragen wieder Schritt zu halten. Wie bereits erwähnt, ist es wichtig, die Teammitglieder zu spezialisieren, um ihren Output, ihre Zufriedenheit und natürlich auch die Qualität ihrer Arbeit zu maximieren. Wir haben jetzt also einen Datenanalysten, der die mit den Stakeholdern festgelegten Berichte auf der Grundlage der von einem Dateningenieur erstellten Datensätze erstellt.

Die Trennung der Rollen hat zur Folge, dass der Dateningenieur nun weiter von den Stakeholdern entfernt ist und den direkten Kontakt zu den Geschäftsanforderungen verliert. In gewisser Weise verliert der Dateningenieur einen Teil des Überblicks über den Endzweck des Projekts und einen Teil der Verantwortung für das Endergebnis. Stattdessen konzentriert sich der Dateningenieur mit aller Kraft auf seine Ergebnisse - ETL, SQL oder welches Framework oder System auch immer zur Erstellung der Daten verwendet wurde.

Das Team und seine Lieferungen sind in Abbildung 1-5 dargestellt, wo wir die Entfernungen und Abhängigkeiten sehen.

Abbildung 1-5. Das Team wächst, ebenso wie die Komplexität

Abbildung 1-5 zeigt auch den Umfang der vom Datenteam im Rahmen des neuen Managementsystems geleisteten Arbeit, nachdem ein paar Projekte durchgeführt wurden. Das Datenökosystem beginnt zu wachsen, und es gibt weniger End-to-End-Transparenz, da es über beide Gehirne verstreut ist und die Verantwortung zwischen den Teammitgliedern beginnt, sich zu verteilen.

Als Nächstes wird ein Datenwissenschaftler in das Team aufgenommen, da die Beteiligten bereit sind, die Einrichtung automatischer Entscheidungsfindungssysteme zu prüfen, die keinen Menschen in der Schleife benötigen, oder jemanden im Team zu haben, der die Ergebnisse überwacht und den aus den Daten generierten Wert skaliert.

Wie in Abbildung 1-6 zu sehen ist, führt dies zu einem größeren Umfang, und für diese Projekte werden mehr Daten in einer schnelleren Geschwindigkeit und komplexere Mechanismen benötigt, da der gesamte Prozess automatisiert werden muss, um die erwarteten Ergebnisse zu erzielen.

Abbildung 1-6. Das Datenteam entwickelt sich hin zur automatisierten Entscheidungsfindung mit KI

Wenn die Zeit vergeht und das ganze System skaliert, treten unweigerlich Probleme auf. Wie in dem Google-Papier "Data Cascades in High-Stakes AI" festgestellt wird⁵ ist die Wahrscheinlichkeit, dass in jedem Projekt mindestens ein Datenproblem auftritt, 92 %.

Weil sich das System so schnell weiterentwickelt hat, ist es schwierig, diese Probleme zu beheben. Was ist passiert? Das weiß eigentlich niemand.

Der Mangel an Transparenz innerhalb des Systems in Kombination mit seiner Komplexität macht es zu einer kompletten Blackbox, selbst für diejenigen, die es (vor einiger Zeit) gebaut haben.

Wie du in Abbildung 1-7 siehst, ist das Datenökosystem des Unternehmens wie ein "Altsystem" in der IT geworden - nur dass es schneller passiert ist.

Abbildung 1-7. Effizientes Datenteam, das Projekte nach einiger Zeit in Produktion bringt

In den nächsten Abschnitten werde ich dir zeigen, wie du mit diesen Problemen umgehst und welche Auswirkungen sie auf die Dynamik der Datenteams haben. Zuvor wollen wir jedoch die Anatomie solcher Datenprobleme analysieren.

Anatomie von Datenproblemen und Konsequenzen

Datenprobleme sind für die meisten Unternehmen eine ständige und häufige Herausforderung. In einer Umfrage von Dun & Bradstreet,⁶ gaben 42% der Unternehmen an, dass sie mit ungenauen Daten zu kämpfen haben.

Die häufigsten Gründe für Datenprobleme sind:

Regulatorische

Datenschutz- oder andere Datenvorschriften erfordern Änderungen in der Art und Weise, wie Daten gesammelt, aufgenommen oder gespeichert werden, was zu unvorhergesehenen Problemen führen kann. Die Verabschiedung der GDPR zwang Einzelhandelsunternehmen zum Beispiel dazu, die von ihnen gesammelten Daten zu ändern und sie auf die Daten zu beschränken, die für die Optimierung ihrer Empfehlungsmaschine benötigt werden, wobei die Integrität der Kunden voll und ganz gewahrt bleibt.

Geschäftliche Anforderungen

Verschiedene geschäftliche Anwendungsfälle erfordern unterschiedliche Datenkonfigurationen. Ein geschäftlicher Anwendungsfall würde sich zum Beispiel auf die Lieferadresse verlassen und nicht auf die Rechnungsadresse. Daher kann die Rechnungsadresse aus den Daten entfernt werden. Wenn jedoch das Finanzamt dieselben Daten verwendet, benötigt es möglicherweise die Rechnungsadressen, hat aber keinen Zugriff darauf, weil diese Verwendung nicht "bekannt" war.

Menschliches Versagen

Oft werden Datenprobleme durch einfache menschliche Fehler verursacht. Zum Beispiel veröffentlicht ein Dateningenieur versehentlich eine Transformationsanwendung, die alle negativen Werte für eine Betragsspalte löscht, anstatt sie mit dem Nullwert zu belegen. Folglich erhält der Datennutzer weniger Daten als erwartet, was die Genauigkeit seiner Analysen verringert.

Latenter Informationsfehler

Dabei handelt es sich nicht um einen Datenfehler, sondern um einen Fehler bei der Interpretation der Daten. Ein Beispiel: Wegen eines Transporterstreiks ging der Absatz von blauen Turnschuhen stark zurück, weil die Lagerbestände nicht aufgefüllt wurden. Die Turnschuhe waren aber so beliebt, dass die Käufer stattdessen braune kauften. Das Marketingteam, das die tatsächliche Situation nicht kannte (z. B. eine latente Variable, die mit der Transporteffizienz und der Verfügbarkeit der Lagerbestände zusammenhängt), schätzte, dass Braun das neue Blau war. Also wurden mehr braune Turnschuhe produziert, die eine Woche später, als der Streik endete, unverkauft blieben.

Fehler bei der Datenabweichung

Noch heimtückischer ist, dass es sich bei diesem Fehler auch um eine Fehlinterpretation der Daten handelt, die wahrscheinlich auf eine latente Variable zurückzuführen ist; allerdings war die Interpretation ursprünglich richtig. Im Laufe der Zeit verändern sich die Daten tatsächlich so sehr, dass die Annahmen nicht mehr zutreffen und die Erkenntnisse daher falsch sind. Ein Beispiel für solche Abweichungen kann in der Modebranche auftreten, wenn ein Produkt von Menschen im Alter von 28-31 Jahren geschätzt wird, die Daten aber zwischen 25-30 und 30-35 liegen. In diesem Fall ist es wahrscheinlich, dass im nächsten Jahr das Interesse an den 25- bis 30-Jährigen (den 29-Jährigen) drastisch sinkt und sich auf die 30- bis 35-Jährigen (die 30- bis 32-Jährigen) verlagert; daher müssen die zu empfehlenden Produkte geändert werden, um dem am stärksten vertretenen Bereich gerecht zu werden.

Einer der schwierigsten Aspekte bei der Entstehung von Datenproblemen ist, dass die Ingenieure, die an der Änderung der Daten oder der Anwendung beteiligt sind, oft nicht wissen, welche Auswirkungen die von ihnen vorgenommenen Änderungen haben. Und leider wird das Problem meist erst am Ende der Datenwertschöpfungskette entdeckt. Alles in allem geht es in diesem Buch darum, zu zeigen, wie alle Beteiligten die Verantwortung übernehmen können, um schnell auf solche Situationen zu reagieren und gleichzeitig ihr Verständnis und ihre Annahmen über die Daten zu bewerten, zu kommunizieren und zu überprüfen.

Wie wir bereits in der Geschichte über die Skalierung von Datenteams beschrieben haben, arbeiten die Geschäftsanwender in der Regel ganz normal weiter, führen Berichte aus usw. und stellen dann aufgrund ihres Bauchgefühls und ihrer eigenen früheren Erfahrungen mit den Daten fest, dass die Zahlen "nicht richtig aussehen".

Aber zu diesem Zeitpunkt ist es bereits zu spät. Geschäftsentscheidungen können bereits auf der Grundlage fehlerhafter Daten getroffen worden sein, bevor die Ungenauigkeiten entdeckt wurden.

Da keine Zeit für die Behebung von Datenproblemen bleibt, versuchen die Datenteams herauszufinden, wer das Wissen und die Fähigkeiten hat, um das Problem zu beheben. Doch oft ist unklar, wer verantwortlich ist oder welche Kenntnisse und Fähigkeiten du brauchst, um das Problem zu lösen. Analytiker? Ingenieure? IT?

Und die Verantwortung kann sich von einem Moment auf den anderen ändern. Vielleicht hat der Analyst die Art und Weise geändert, wie eine Information berechnet wird, die sich nun auf die Vertriebsberichte auswirkt, aber vielleicht hat das Data Engineering Team auch schon vorher eine der Verbindungen angepasst, die das Vertriebsanalysetool unterstützen, mit dem die Geschäftsanwender die Vertriebsberichte erstellen.

Bei dem Versuch, das Problem zu lösen, verlässt sich jeder auf das Wissen der anderen, was gemacht wurde, wie die Dinge funktionieren, wo die Dokumentation ist, ob sie korrekt ist, wie die letzten Änderungen in der (Code-)Geschichte aussehen und so weiter. Letztendlich läuft es darauf hinaus, dass du versuchst, das Problem kollegial oder auf die harte Tour (allein und im Dunkeln) zu finden und zu beheben. Das liegt daran, dass niemand genau weiß, welche Felder oder Tabellen sich auf die nachgelagerten Datenkonsumenten auswirken werden.

Die Kosten und der Zeitaufwand für die Behebung des Problems und die negativen Auswirkungen auf die Produktivität, den Umsatz, den Gesamtumsatz und sogar den Ruf des Unternehmens sind erheblich.

Aus dem Bericht von Dun & Bradstreet geht außerdem hervor, dass fast jedes fünfte Unternehmen aufgrund unvollständiger oder ungenauer Daten Kunden verloren hat. Fast ein Viertel der Unternehmen gibt an, dass eine schlechte Datenqualität zu ungenauen Finanzprognosen geführt hat, und natürlich haben auch die restlichen 75% wahrscheinlich unter ungenauen Daten gelitten, allerdings für andere Zwecke. Dennoch ist eine falsche Finanzprognose von 25 % für ein so wichtiges Thema für die Stabilität eines Unternehmens beeindruckend.

Ständige Datenprobleme können zu einem Mangel an Vertrauen in Geschäftsentscheidungen führen, die auf Datenerkenntnissen basieren. In einer kürzlich durchgeführten Studie mit 1.300 Führungskräften gaben 70 % der Befragten an, dass sie sich nicht sicher sind, ob die Daten, die sie für Analysen und Prognosen verwenden, korrekt sind.

Auswirkungen von Datenproblemen auf die Dynamik von Datenteams

In erster Linie wird das Datenproblem vom Datennutzer entdeckt, der Zweifel hegt, weil entweder die erhaltenen Daten im Vergleich zu den Erwartungen seltsam erscheinen oder die Ergebnisse der Analysen nicht den Erwartungen entsprechen. Der direkte Nebeneffekt dieser Zweifel ist das Misstrauen des Nutzers gegenüber dem Team, das die Daten produziert hat, oder gegenüber der gesamten Datenplattform.

Probleme könnten auch getarnte Datenänderungen sein

Dieser Fall kann auch dann eintreten, wenn die Daten keine "Probleme" haben, denn Daten ändern sich natürlich, da sie die Realität darstellen, die sich ohne Vorankündigung ändert. In einem solchen Fall kann es sein, dass der Nutzer die Änderungen einfach noch nicht bemerkt hat. Der Einfachheit halber gehe ich für den Rest dieser Diskussion jedoch davon aus, dass das Problem real ist.

Abbildung 1-8 zeigt die aktuelle Situation, in der einer der Verbraucher anfängt, Bedenken bezüglich der Daten zu haben, und sich vorstellt, dass das gerade entdeckte Problem andere, noch nicht entdeckte Folgen in einigen oder allen Anwendungen haben könnte, die die Daten nutzen (auch bekannt als Datenkaskade, Problemausbreitung).

Abbildung 1-8. Ein Nutzer, der nicht weiß, was er entdeckt hat: ein Datenproblem

In diesem Szenario entdecken die Nutzer/innen Probleme immer zum falschen Zeitpunkt. Sie brauchen die Daten in diesem Moment, sonst würden sie nicht auf die Daten zugreifen oder sie überprüfen.

Der Nutzer sitzt also fest und wird natürlich mürrisch. Denn anstatt an den geplanten Aufgaben zu arbeiten, muss der Nutzer herausfinden, wie die Daten "repariert" werden können. Folglich werden die Beteiligten ihre Daten nicht rechtzeitig erhalten.

Außerdem ist es nicht einfach, herauszufinden, wie die Daten repariert werden können, da die empfangenen Daten von einer der Anwendungen, die sie erzeugt haben, beschädigt worden sein könnten. An diesem Punkt hängt der zu befolgende Prozess davon ab, wie die (Daten-)Vorgänge organisiert sind; ein Beispiel wäre, einen "Vorfall" (ein Ticket) mit dem Kommentar "Daten sind nicht in Ordnung, bitte so schnell wie möglich beheben" zu erstellen.

In unserem Beispielprozess werden die fehlerhaften Daten schließlich einem Datenverwalter zugeordnet. Der Datenverantwortliche ist dafür verantwortlich, den Benutzer zu entsperren (zumindest) und das Potenzial für weitere Folgen zu analysieren, die zu weiteren Vorfällen führen können.

Um einen solchen Vorfall zu beheben, muss der Datenverantwortliche das Team oder die Person einbeziehen, die für die Erstellung der Daten verantwortlich ist. Und jetzt hängt der Zeitplan von der Verfügbarkeit derjenigen ab, die Zeit brauchen, um die Symptome zu diagnostizieren und eine Lösung zu erarbeiten.

Das hört sich einfacher an, als es wirklich ist. Der Vorfall muss an den Produzenten weitergeleitet werden, der wahrscheinlich schon mit laufenden Projekten beschäftigt ist und das Problem wahrscheinlich nicht sofort erkennt. Vorausgesetzt, du kannst überhaupt den richtigen Produzenten identifizieren! Stattdessen werden wahrscheinlich alle Produzent/innen kontaktiert und zu einem Treffen eingeladen, um die Situation zu verstehen. Sie werden das "Problem" anzweifeln (z. B. "Sind Sie sicher, dass es sich um ein Problem handelt?") und nach weiteren Details fragen, was wiederum zu dem bereits verärgerten Nutzer zurückführt (der wahrscheinlich nicht sehr kooperativ sein wird).

Folglich müssen die Anwendungen, die diese Daten berühren und als potenzielle Übeltäter identifiziert werden, gründlich analysiert werden, was folgende Aufgaben umfasst:

• Zugriff auf die Produktionsdaten, um das Datenproblem manuell zu überprüfen und zu verstehen, indem du eine Reihe von explorativen Analysen durchführst (z. B. Abfragen, Aggregationsberechnungen in Spark). Daher kann es sein, dass die Erlaubnis zum Zugriff auf die Daten noch nicht erteilt wurde.

• Wiederhole diesen Vorgang, indem du (wenn möglich) eine Zeitreise durch die Daten machst, um herauszufinden, wann das Problem aufgetreten ist (z. B. kann eine Deltatabelle bei der Zeitreise helfen, aber der Zeitpunkt, an dem das Problem aufgetreten ist, muss noch ermittelt werden).

• Zugriff auf die Produktionsprotokolle der Anwendungen (per SSH auf den Rechnern oder von der Protokollierungsplattform aus), um ihr Verhalten zu analysieren und sogar ihren Verlauf (Version usw.) zu überprüfen, falls sich die Geschäftslogik der Anwendung geändert hat, was sich auf die Ergebnisse auswirken könnte. Wie beim Datenzugriff kann es sein, dass für den Zugriff auf die Protokolle besondere Berechtigungen erforderlich sind.

• Analysiere die Geschäftslogik, um die ursprünglichen Daten, die von den Anwendungen verbraucht werden, zurückzuverfolgen und mögliche Datenkaskaden (Problemverschleppung) zu identifizieren.

• Wiederhole den Vorgang so lange, bis du die Ursache gefunden hast und weißt, welche Daten und Anwendungen repariert werden müssen, und führe schließlich das Backfilling durch (um die Wahrheit wiederherzustellen).

Seien wir also ehrlich: Da die Zeit drängt (denk daran, dass der Benutzer verärgert ist), wird die Ursache wahrscheinlich nicht aufgespürt, sondern eine der beiden vorübergehenden Korrekturen angewendet:

• Führe ein Ad-hoc-Skript (auch Datenqualitätstool genannt) aus, um die Daten zu "reparieren", die den Prozess außer Kontrolle geraten lassen (z. B. außerhalb des Lebenszyklus der Daten usw.).

• Aktualisiere eine der Anwendungen, um die empfangenen Daten zu "bereinigen". Das bedeutet, dass das Problem lokal behoben werden muss und wahrscheinlich unangenehme Nebeneffekte hat, wie z. B. das Entfernen oder Imputieren von Nullwerten, die die Verteilung der Variablen verändern können, wenn die Zahl der Variablen steigt und Nebeneffekte nach sich ziehen (z. B. schlechte Entscheidungen).

Tatsächlich hat dieser Prozess, der "Fehlersuche" genannt wird, viele Menschen verwirrt, von denen viele für diesen Vorfall gar nicht gebraucht wurden. Es ist erwähnenswert, dass sich der Umfang des Problems während der Fehlerbehebung erheblich vergrößert hat, wie in Abbildung 1-9 zu sehen ist.

Abbildung 1-9. Personen, die an der Störfallanalyse beteiligt sind (Fehlerbehebung)

Außerdem kann das Problem, das bei diesen Daten entdeckt hat, andere Auswirkungen auf andere Projekte, Nutzer und Entscheidungen haben (denk daran, Datenkaskaden!), was dazu führt, dass das Problem auf alle Verwendungen der Daten ausgeweitet wird.

Ein anderer Prozess, die so genannte Auswirkungsanalyse, ähnelt in gewisser Weise der Fehlerbehebung, die wir gerade behandelt haben. Sie hat jedoch ein etwas anderes Ziel, da sie darauf abzielt, Probleme zu verhindern oder zu kommunizieren.

Tatsächlich ist nicht nur das Ziel ein anderes, sondern eine Wirkungsanalyse ist auch viel kniffliger und sensibler, weil sie von allen Nutzern Zeit verlangt, um ihre Daten, Ergebnisse, Analysen oder Entscheidungen zu überprüfen.

Noch schlimmer ist, dass manche entdecken, dass die Entscheidungen über einen längeren Zeitraum falsch waren, möglicherweise so lange, wie das Problem aufgetaucht ist, wobei alles im Stillen passiert ist.

An diesem Punkt ist der Umfang des Datenproblems unter Berücksichtigung der Fehlerbehebung und der Auswirkungsanalyse so groß, wie in Abbildung 1-10 dargestellt. Und der Datenverwalter muss das Problem so schnell wie möglich lösen.

Abbildung 1-10. Der Umfang zur Lösung eines Datenproblems

Deshalb nennen wir Daten einen "stillen Killer". In unserem Beispiel haben sie alle verlangsamt, jegliches Vertrauen zerstört und Stress, Wut und Angst erzeugt, ohne dass sie irgendwelche Warnungen oder "Ausnahmen" (wie bei Software) auslösten. Tatsächlich lösen Daten keine Alarme oder Ausnahmen aus - bis jetzt jedenfalls. Es gibt jedoch eine Möglichkeit, diese Fähigkeit zu aktivieren, die wir im nächsten Kapitel sehen werden.

In dieser Analyse habe ich die Herausforderungen hervorgehoben, die mit dem Zeitaufwand und dem Personal verbunden sind, das in den Prozess involviert ist, sowie die erheblichen Anstrengungen, die mit Ad-hoc-Patching verschwendet werden, das nur noch mehr Datenschulden schafft. Trotz der Bedeutung dieser Herausforderungen gibt es eine weitere unschätzbare Ressource, die wir sofort verloren haben, als das Problem entdeckt wurde: das Vertrauen in die Daten und das Datenteam.

Dieses Vertrauen hat Monate, wenn nicht sogar Jahre (z.B. bei sensiblen KI-basierten Projekten) gebraucht, um aufgebaut zu werden, aber weil nichts vorgesehen war, um es aufrechtzuerhalten, fiel es innerhalb von Sekunden wie ein Kartenhaus zusammen. Ein solches Szenario und die daraus resultierenden Folgen für die allgemeine Stimmung führen zu Entmutigung und Abwanderung von hochtalentierten Teammitgliedern.

Daher können wir viele Fragen identifizieren, die im Laufe des Incident Management-Prozesses aufgeworfen werden und die die Stimmung zerstören können, wenn sie zum falschen Zeitpunkt gestellt werden:

• Wer ist für dieses Problem verantwortlich?

• Warum bin ich derjenige, der:

  • Hast du das Problem entdeckt?

  • Sollte man sie dazu befragen?

• Warum sagt mir der Nutzer, dass die Daten ungenau zu sein scheinen?

• Sind die Daten wirklich ungenau?

• Welche Apps könnten die Ursache sein?

• Welche vorgelagerten Daten könnten die Ursache sein?

• Was sind die unbekannten Folgen dieses Problems (d.h. in welchen anderen Projekten werden diese Daten verwendet, die ebenfalls betroffen sein könnten)?

Wenn wir verstehen, warum diese Fragen aufgeworfen werden, können wir die eigentliche Ursache des Problems identifizieren, und das geht über Datenprobleme und ihre Ursachen hinaus. Die Herausforderung, die es zu bewältigen gilt, liegt nicht in den Daten selbst, sondern in der mangelnden Klarheit über die Verantwortlichkeit und Zuständigkeit der Mitglieder des Datenteams und der Stakeholder, die durch die mangelnde Transparenz der Datenprozesse in der freien Wildbahn (d.h. bei der Produktion und während der Nutzung) noch verstärkt wird.

Wenn diese Fragen von Datenteams aufgeworfen oder ihnen gestellt werden, können sie folglich Hindernisse für die Wertschöpfung aus der Nutzung von Daten schaffen und verstärken, da sie die folgenden Kosten verursachen:

• Es dauert sehr lange, bis die Daten geklärt sind, und in dieser Zeit sind sie für den Verbraucher immer noch unbrauchbar.

• Benötigen viel Energie und deuten darauf hin, dass die Fähigkeit, das Problem an der Quelle zu lösen, eingeschränkt ist und dass ein lokaler "Flicken" die wahrscheinliche Standardlösung sein wird.

• Ängste schüren und den Vertrauensverlust in Leistungen, Daten und Lieferanten verschärfen.

Hier spielt die Beobachtbarkeit der Daten eine Schlüsselrolle - sie hilft, einen besseren Einblick in den Zustand der Daten und des Datenökosystems zu gewinnen und die Verantwortung besser zuzuweisen (verteilen, dezentralisieren).

KI-Straßenblockaden bei der Skalierung

Im vorigen Abschnitt haben wir uns mit den Herausforderungen befasst, mit denen viele Unternehmen konfrontiert sind, wenn sie ihre Datenteams aufstocken wollen. In diesem Abschnitt werde ich mich auf eine der wichtigsten Leistungen konzentrieren, die jedes Unternehmen von seinen Datenteams erwartet: die Skalierung ihrer KI-Fähigkeiten.

Die gleichen Probleme mit der Sichtbarkeit, die den Wert begrenzen, wenn Probleme auftreten, stellen auch bei der Implementierung von KI eine große Herausforderung dar.

In einer von Gartner durchgeführten Analyse (siehe Abbildung 1-11) waren die wichtigsten Hindernisse, mit denen sich Unternehmen bei der Entwicklung ihrer Daten- und KI-Programme konfrontiert sahen, das Datenvolumen und/oder die Komplexität, Probleme mit dem Datenumfang oder der Datenqualität sowie Herausforderungen bei der Datenzugänglichkeit.

Die gute Nachricht ist, dass die Datenbeobachtung bei diesen Hindernissen hilft, aber bevor wir darauf eingehen, wollen wir uns die wichtigsten Hindernisse und ihre Gründe etwas genauer ansehen.

Die Umfrageergebnisse zeigen, dass technologiebezogene Herausforderungen 29% der Probleme ausmachen und die Komplexität der bestehenden Infrastruktur 11%. Interessanterweise gab fast die Hälfte (48%) der Befragten an, dass die Probleme mit der mangelnden Transparenz aufgrund der Komplexität des bestehenden Systems zusammenhängen und dass nicht klar ist, wer für die Behebung der Probleme zuständig ist.

Abbildung 1-11. Die Ergebnisse der Gartner-Umfrage zu KI-Blockaden. Quelle: Gartner (März 2023)

Werfen wir einen Blick auf einige der häufigsten Hindernisse:

Sicherheits-/Privatsphärenbedenken oder potenzielle Risiken oder Haftung

Fast ein Fünftel (18 %) der Befragten in der Gartner-Umfrage nannte diese Probleme als größtes Hindernis für die Einführung von KI. Beim Risikomanagement geht es vor allem darum zu wissen, wer, warum und zu welchem Zweck die Daten verwendet werden. Es besteht auch ein potenzielles Risiko oder eine Haftung, wenn die Ergebnisse der Daten ungenau sind, weil die Daten selbst falsch sind, was zu schlechten Geschäftsentscheidungen führen kann. Und schließlich besteht die Sorge, dass die Ergebnisse bestimmten ethischen Anforderungen nicht genügen könnten.

Datenvolumen und Komplexität

Dieses Problem war für 8 % der Befragten das größte Hindernis. Die Komplexität und der Umfang der Daten erfordern viele Experimente, um sie zu verstehen und einen Nutzen aus ihnen zu ziehen. Da die durchgeführten Experimente, wie Profiling und Wrangling, nicht sichtbar sind, wiederholen sie sich, wenn sie mit denselben großen und komplexen Datensätzen durchgeführt werden. Dieser Prozess kostet jedoch Zeit und Mühe.

Umfang und Qualität der Daten

Für 6 % der Befragten waren Probleme mit der Datenqualität das größte Hindernis. Wenn die Datenqualität nicht bekannt ist, ist es sehr schwierig, Vertrauen in das Ergebnis oder die endgültigen Ergebnisse zu haben, die aus den Daten gewonnen werden.

Governance-Probleme oder Bedenken, mangelndes Verständnis für die Vorteile und den Nutzen von KI und Schwierigkeiten, Anwendungsfälle zu finden

Insgesamt 16% der Befragten waren der Meinung, dass einer dieser Punkte die größte Herausforderung bei der Implementierung von KI darstellt. Die Datenverwaltung ist ein großes Problem, da die Dokumentation manuell und zeitaufwändig ist, was bedeutet, dass sie nicht immer ordnungsgemäß durchgeführt wird und daher die Gesamtauswirkungen und der Wert nicht immer ersichtlich sind. Ohne eine gute Data Governance könnte die Qualität der Daten, die in die KI-Algorithmen eingespeist werden, beeinträchtigt werden, und ohne Einblick in die Datenqualität können sich die Beteiligten Sorgen um die Sicherheit der Daten und die Genauigkeit der KI-Ergebnisse machen.

Zum Zeitpunkt des Verfassens dieses Artikels ist ein Umbruch in der Nutzung von KI, nämlich ihre Zugänglichkeit für die Öffentlichkeit, mit der Nutzung von generativer KI für die Texterstellung auf der Grundlage eines Modells namens Large Language Model (LLM) zu beobachten. Das beliebteste Tool, das auf dieser Methode basiert, ist ChatGPT von OpenAI. Es ermöglicht allen Menschen ohne KI-Kenntnisse, mit einem Algorithmus zu chatten, d. h. eine strukturierte Diskussion zu führen, bei der jede neue Antwort den Rest der Diskussion (den Kontext) berücksichtigt. Die Diskussion zielt im Allgemeinen darauf ab, auf der Grundlage einiger Anweisungen (ja, wie bei der Codierung) Inhalte zu generieren, z. B. Blogposts, Definitionen, strukturierte Standpunkte, Pitches und so weiter.

Die Genauigkeit der Antworten und die Art und Weise, wie die Daten in diesen großen Modellen verwendet werden, wurde jedoch bereits in den ersten Wochen der allgemeinen Verfügbarkeit kritisiert. Italien beispielsweise verbot den Zugang zu dem Dienst für einige Zeit, da man davon ausging, dass er zur Verbreitung von Fehlinformationen und Verzerrungen beitragen könnte. Obwohl der Dienst wieder geöffnet wurde, nachdem die Einhaltung der Altersrichtlinien überprüft worden war, wurde keine Klarheit über ungenaue oder verzerrte Informationen geschaffen.

Bei solchen Werkzeugen, die von Millionen oder sogar Milliarden von Menschen auf der ganzen Welt genutzt werden, ist es wichtig, die richtigen Erwartungen zu stellen (z. B. Genauigkeit, Aktualität usw.), um zu vermeiden, dass unangemessene Entscheidungen oder globale Bewegungen auf der Grundlage falscher "generierter" Informationen getroffen werden. Das ist nichts anderes, als das, was in diesem Abschnitt besprochen wurde, auf eine weitere Ebene zu bringen, d.h. nicht nur für Unternehmen, die reif genug sind, KI regelmäßig für Geschäftsentscheidungen zu nutzen, was sich wahrscheinlich auf ihr Ökosystem auswirken wird,⁷ sondern auch für kleine Unternehmen und Einzelpersonen.

Bisher habe ich dich auf die Reise zur Skalierung von Datenteams und KI mitgenommen und wir haben mehrere Herausforderungen identifiziert, wie z. B. mangelnde Transparenz (Datenpipelines, Datennutzung) und fehlende Klarheit über Verantwortung und Rechenschaftspflicht, die zu Misstrauen und Chaos führen, was zu einem Verlust des Interesses oder Vertrauens in Daten führt. Dies unterstreicht die allgemeine Bedeutung des Datenmanagements. Der nächste Abschnitt befasst sich daher mit den Herausforderungen, die sich aus der Skalierung ergeben, damit alles zusammenkommt, und stellt die Datenbeobachtung als Klebstoff vor, der eine Lösung für diese Herausforderungen darstellt.

Herausforderungen bei den aktuellen Datenmanagement-Praktiken

Wie bei jeder Unternehmensumwandlung stellt sich auch bei der Datenumwandlung und der damit verbundenen Bildung von Datenteams die Frage nach dem Standort der Teams innerhalb der Organisation. Soll es ein zentrales Datenteam geben? Sollte es in der IT angesiedelt sein? Oder sollte es vielleicht ein Datenteam pro Geschäftsfeld geben? Sollten sie der IT unterstellt sein oder in jedem Bereich? Aber wie arbeiten sie dann zusammen, und wie bleiben sie einheitlich und effizient? Et cetera, et cetera.

Diese Fragen werden auf viele Arten angegangen; Data Mesh (siehe Kapitel 3) ist eine der wenigen (um nicht zu sagen die einzige), die sich damit befasst, indem sie das Datenmanagement auf allen Ebenen neu überdenkt, einschließlich der architektonischen, kulturellen und organisatorischen Ebene.

Unabhängig davon, welche Position die Datenteams in der Struktur einnehmen, sollten wir analysieren, wie sich ihre Vergrößerung auf das Datenmanagement auswirkt.

Datenmanagement ist ein umfangreiches Thema, das in der Literatur breit definiert wird. Für diese Analyse werde ich mich darauf konzentrieren, wie Datenmanagement von der DAMA definiert wird⁸ in ihrem Data Management Body of Knowledge v2 (DMBOK2)⁹ Buch.

Im DMBOK2 umfasst das Datenmanagement viele Bereiche, wie Datenarchitektur, Metadaten und Datenqualität. All diese Bereiche tragen dazu bei, den Wert der Daten zu nutzen, ebenso wie die Data Governance, die die Richtlinien vorgibt, die eingehalten werden müssen, um sicherzustellen, dass der Wert der Daten effizient und im Einklang mit den Grundprinzipien des Unternehmens erzeugt wird.

Dies wird sehr gut in dem in Abbildung 1-12 dargestellten Datenmanagement-Rad des Rahmens dargestellt.

Abbildung 1-12. Datenmanagement-Rad aus DMBOK2 (Copyright © DAMA International)

Da immer mehr Unternehmen zu Datenunternehmen werden, breiten sich sowohl datenversierte Unternehmensteams als auch Datenteams in allen Organisationen aus. Deshalb ist Datenkultur nicht mehr auf ein genau definiertes Kompetenzzentrum beschränkt, sondern ein Wert, der in die Werte der gesamten Organisation aufgenommen werden muss.

Folglich haben sich die durch das Rad abgegrenzten Bereiche weiterentwickelt, um sich den unterschiedlichen Situationen und Bedürfnissen anzupassen. Einer der auffälligsten Bereiche, der seit 2017 weltweit an Bedeutung gewonnen hat, ist die Data Governance, die wir im nächsten Abschnitt behandeln. Wir werden zum Beispiel erörtern, wie sich dieses Thema auf andere Bereiche wie Datenqualität und Metadaten auswirkt.

Auswirkungen von Data Governance im großen Maßstab

Viele Herausforderungen ergeben sich aus der Entwicklung von Datenmanagementpraktiken und -technologien, aber Ich konzentriere mich auf eine spezielle Herausforderung: Wie kann man in großem Maßstab kontrollieren, wie die Datenkultur aufrechterhalten wird, indem man nicht nur die Grundsätze der Data Governance beachtet, sondern auch die Definition und Umsetzung der daraus resultierenden Richtlinien. Data Governance legt die Richtlinien fest, und jeder Bereich ist für die Definition, Planung und Umsetzung verantwortlich.

Mit der Implementierung werden jedoch viele Abhängigkeiten zwischen den verschiedenen Bereichen eingeführt, und außerdem skaliert alles; ohne eine harmonisierte, definierte und globale Kontrollebene kann jeder Bereich, der einen Fehler aufweist, die Maschine kaputt machen.

Deshalb schlage ich vor, die Struktur des Datenmanagements, wie sie im DMBOK2 dargestellt ist, nicht unbedingt zu ändern, sondern sie um einen zusätzlichen Bereich zu erweitern, der den Bereich Data Governance umgibt.

Dieser neue Bereich betrifft die Beobachtbarkeit von Daten, die die Datenmanagementpraktiken von Organisationen erweitern wird, indem sie ihnen die Möglichkeit gibt, den Zustand und die Nutzung der Daten innerhalb ihres Systems sowie Gesundheitsindikatoren des Gesamtsystems zu messen.¹⁰ Eine genauere Definition der Datenbeobachtbarkeit wird jedoch im Abschnitt "Die Bereiche der Beobachtbarkeit" erläutert .

Dass die Datenbeobachtung an dieser Stelle des Rades steht, macht deutlich, dass jeder für ihre Umsetzung verantwortlich ist. Die Grundsätze und Richtlinien sollten in alle Bereiche integriert werden.

Das Ergebnis ist in Abbildung 1-13 dargestellt. Das bedeutet jedoch nicht, dass es unbedingt eine Rolle, ein Team oder eine Abteilung für die Datenbeobachtung geben muss. Es besagt, dass die Kontrolle im großen Maßstab explizit werden muss, da die Datenbeobachtung zu einer Herausforderung wird, während sie in einem kleineren Maßstab eher ad hoc gehandhabt werden kann.

Abbildung 1-13. Datenmanagement-Rad erweitert um die Beobachtbarkeit von Daten (Copyright © DAMA International)

Im weiteren Verlauf dieses Buches werden wir uns ansehen, wie sich die Beobachtbarkeit auf die IT-DevOps-Landschaft ausweitet und wie sie auf Daten und Datenteams angewendet werden kann.

An dieser Stelle sollte klar sein, dass transversale Herausforderungen (Datenmanagement) und lokale Herausforderungen (innerhalb eines Datenteams) in den letzten Jahren zu Engpässen bei der Skalierung von Datenstrategien und der Erzielung einer maximalen Rendite aus den Dateninvestitionen geworden sind. Lassen Sie uns nun über eine Lösung sprechen, mit der diese Herausforderungen auf breiter Front angegangen werden können, nämlich mit der Beobachtbarkeit von Daten.

Die Beobachtbarkeit der Daten ist die Rettung

Bisher habe ich unter die Herausforderungen erörtert, mit denen Datenteams konfrontiert sind, wenn sie wachsen, sowie die Rolle, die mangelnde Sichtbarkeit und unklare Zuständigkeiten dabei spielen, dass Unternehmen ihre Daten- und Analysestrategien nicht skalieren können.

Es ist jedoch nicht das erste Mal, dass wir mit solchen Herausforderungen konfrontiert werden; das nächste Beispiel ist die schnelle Skalierung der IT, die zur Entwicklung der DevOps-Kultur führte.

DevOps hat sich im Laufe der Jahre weiterentwickelt, da immer mehr IT-Praktiken (z.B. das Service Mesh) mehr bewährte Methoden und zugehörige Werkzeuge erfordern, um sie effizient zu unterstützen.

Das bekannteste Beispiel für solche bewährten Methoden ist wahrscheinlich CI/CD (Continuous Integration and Continuous Deployment), aber auch die Beobachtbarkeit auf Infrastruktur- oder Anwendungsebene ist mittlerweile Teil jeder Architektur, die mehr Transparenz und Vertrauen in ihre Anwendungen und Systeme schaffen und gleichzeitig die Markteinführung beschleunigen und Ausfallzeiten reduzieren soll.

Daher sind entsprechende Märkte entstanden und gewachsen, um diese Anforderungen an die Beobachtbarkeit zu unterstützen. Eine Vielzahl von Unternehmen hat DevOps-bezogene Dienste und Technologien für alle Reifegrade der IT-Umgebung entwickelt (z. B. Datadog, Splunk, New Relic, Dynatrace usw.).

In der IT ist "Beobachtbarkeit" die Fähigkeit eines IT-Systems, Verhaltensinformationen zu erzeugen, die es externen Beobachtern ermöglichen, seinen internen Zustand zu rekonstruieren (zu modellieren). Kontinuierliche Beobachtbarkeit bedeutet, dass ein externer Beobachter den internen Zustand kontinuierlich modellieren kann.

Grundsätzlich kann ein Beobachter nicht mit dem System interagieren, während es funktioniert (z. B. können wir uns nicht auf dem Server anmelden); er kann nur Informationen beobachten, die wahrgenommen werden können, die daher "Beobachtungen" genannt werden.

Lasst uns nun besprechen, was diese Beobachtungen sind.

Die Bereiche der Beobachtbarkeit

Ein IT-System ist von Natur aus komplex, da es sich aus mehreren Kategorien zusammensetzt, deren Anzahl sich drastisch erhöhen kann, wie z.B. Infrastruktur, Cloud, verteilt, maschinelles Lernen, Deep Learning, etc.

In diesem Buch vermeide ich es jedoch, zu sehr ins Detail zu gehen, sondern fasse die Kategorien eines IT-Systems, die "beobachtet" werden können, in mehreren Bereichen zusammen, von denen einer mit den Daten zu tun hat (siehe Abbildung 1-14).

Abbildung 1-14. Bereiche der IT-Beobachtbarkeit

Diese Bereiche sind nicht völlig unabhängig voneinander, denn sie haben eine Menge Wechselwirkungen, da sie die Komplexität des Systems kodieren. Aus diesem Grund schien ein Venn-Diagramm die beste Darstellung zu sein.

Bevor wir den Bereich "Daten" und "Datenbeobachtbarkeit" im Detail behandeln, wollen wir kurz auf die anderen Bereiche eingehen:

Infrastruktur

Anhand der Infrastrukturprotokolle kannst du auf die Leistungsmerkmale der internen Infrastrukturkomponenten schließen. Bei einem Ausfall oder der Nichteinhaltung bestimmter Leistungsparameter können proaktive Warnmeldungen ausgegeben werden.

Bewerbung

Durch die Beobachtung von Anwendungsendpunkten, Versionen, offenen Threads, Anzahl der Anfragen, Ausnahmen usw. lässt sich feststellen, wie gut die Anwendung funktioniert und ob oder warum es Probleme gibt.

Benutzer/Zweck

Es ist nützlich zu verstehen und zu "beobachten", wer die Anwendungen nutzt oder einführt, was der Zweck eines Projekts ist und welches Ziel es hat. Das hilft dabei, die häufigsten Projekte oder Ziele zu verstehen, Doppelarbeit zu erkennen oder Kompetenzzentren zu bilden.

Analytik

Die Beobachtung von Analysen, von einfachen Transformationen bis hin zu komplexen KI-Modellen, hilft dabei, die laufende Nutzung von Daten und die daraus gewonnenen Erkenntnisse zu erkennen und daraus zu lernen.

Sicherheit

Die Beobachtung von sicherheitsrelevanten Vorgängen, wie z.B. Änderungen der Personen, denen Zugang gewährt oder Rollen zugewiesen werden, oder Metriken darüber, welche Rollen häufiger als andere genutzt werden, geben Aufschluss über die Effizienz des bestehenden Sicherheitssystems und mögliche Verbesserungsbereiche.

Einige dieser Bereiche sind in der DevOps-Literatur bereits gut behandelt worden. Wir konzentrieren uns jedoch speziell auf die Beobachtbarkeit von Daten. Daher kommen wir zu dem Schluss, dass Datenbeobachtung wie folgt definiert werden kann:

Datenbeobachtbarkeit ist die Fähigkeit eines Systems, Informationen darüber zu generieren, wie die Daten sein Verhalten beeinflussen und umgekehrt, wie das System die Daten beeinflusst.

Ein System ist datenbeobachtbar, wenn es die Fähigkeit zur "Datenbeobachtung" besitzt.

Ein System ist (vollständig) beobachtbar, wenn es über die "Beobachtungsfähigkeit" verfügt (Infrastruktur, Anwendung, Nutzer, Analytik, Sicherheit und Daten).

Es ist erwähnenswert, dass Gartner die Beobachtbarkeit von Daten wie folgt definiert hat, was sich gut mit unserer Definition deckt:¹¹

Datenbeobachtung ist die Fähigkeit eines Unternehmens, jederzeit einen umfassenden Überblick über seine Datenlandschaft und die mehrschichtigen Datenabhängigkeiten (wie Datenpipelines, Dateninfrastruktur, Datenanwendungen) zu haben, um Datenausfälle innerhalb akzeptabler SLAs schnell zu erkennen, zu kontrollieren, zu verhindern, zu eskalieren und zu beheben.

Die Datenbeobachtung nutzt eine kontinuierliche, mehrschichtige Signalerfassung, -konsolidierung und -analyse, um ihre Ziele zu erreichen und ein besseres Design für eine höhere Leistung und eine bessere Governance zu empfehlen, die den Unternehmenszielen entspricht.

In der Gartner-Definition wird auch beschrieben, wie die Beobachtbarkeit von Daten genutzt werden kann (z. B. um Probleme zu vermeiden). Ich habe dies jedoch nicht in meine Definition aufgenommen, weil ich mich darauf konzentrieren möchte, was sie ist und nicht, was sie tut (ich definiere einen Apfel auch nicht als eine Frucht, die meinen Hunger stillen kann).

Trotzdem ist es wichtig, die Vorteile der Datenbeobachtung zu kennen. Im nächsten Abschnitt gehen wir näher auf die Anwendungsfälle der Datenbeobachtung ein.

Dennoch sind sowohl Gartner als auch ich der Meinung, dass es eine wichtige "Multi-Layer"- oder "Multi-Area"-Komponente gibt, die berücksichtigt werden sollte. Ich habe jedoch den Begriff "Bereiche" verwendet, weil Schichten eine gewisse Unabhängigkeit implizieren, was in Wirklichkeit nicht der Fall ist.

Ausgehend von dieser Definition können wir die Dimensionen, aus denen sich die Beobachtbarkeit von Daten zusammensetzt, als Ergebnis ihrer Wechselwirkungen mit den anderen Bereichen der Beobachtbarkeit betrachten.

Ich beginne mit der Hauptdimension, die aus den Beobachtungen des Datensatzes besteht. Bei diesen Beobachtungen handelt es sich im Wesentlichen um Metadaten wie die Felder (z. B. Spalten, JSON-Attribute), das Format (z. B. CSV), die Kodierung (z. B. UTF-8) und bis zu einem gewissen Grad auch die Definitionen der verfügbaren Informationen.

Sie ermöglichen es einem Beobachter, (hauptsächlich) die Struktur des Datensatzes zu verstehen und wie er sich im Laufe der Zeit verändert.

Wenn wir hier aufhören würden, könnten wir die Datenbeobachtung nicht voll ausschöpfen. Deshalb müssen wir diese Kernbeobachtungen mit den anderen Bereichen verbinden, die wir zuvor hervorgehoben haben, um dem Beobachter die folgenden Vorteile zu bieten:

Infrastruktur

Ermitteln Sie, wo die Daten physisch gespeichert sind (z. B. Dateipfad auf einem Server, der Server, auf dem eine Datenbank liegt, d. h. die Verbindungszeichenfolge), und ob die Daten selbst oder die folgenden Bereiche betroffen sein könnten.

Bewerbung

Sei dir bewusst, welche Komponenten des Datensystems deiner Organisation die Daten speichern oder nutzen (z. B. ein Transformationsskript, ein Webservice); dies könnte auch das Code-Repository und die Version umfassen.

Benutzer/Zweck

Kontextualisiere und erleichtere die Wissensübergabe mit Informationen darüber, wer an der Datenproduktion oder -nutzung beteiligt war, wie die Sicherheitseinstellungen aussehen und in welchen Projekten (mit welchem Zweck) sich die Daten bewährt haben.

Sicherheit/Privatsphäre

Kontrolliere, wie haftbar und angemessen die Datensammlungen, -zugriffe und -verwendungen sind.

Analytik

Verstehe, wie mit den Daten ein Mehrwert geschaffen wird, sei es durch Umwandlung (Lineage), KI (Training für maschinelles Lernen, Vorhersagen) oder ganz einfach durch Migration.

Wie bei allen neuen Konzepten, vor allem wenn sie die Organisationskultur, Arbeitsweisen und Technologien betreffen, ist es wichtig, ihre Anwendungsfälle zu verstehen. Deshalb werde ich im nächsten Abschnitt die häufigsten und wertvollsten Anwendungsfälle der Datenbeobachtung behandeln.

Wie Datenteams die Beobachtbarkeit von Daten jetzt nutzen können

Die wichtigsten Anwendungsfälle für die Beobachtbarkeit von Daten sind derzeit das Management von Datenproblemen. Mit der zunehmenden Verbreitung von Daten und der Ausweitung ihrer Nutzung wird es jedoch noch viele weitere Anwendungsfälle geben.

Erkennung von Datenproblemen mit niedriger Latenzzeit

Je besser die Datenbeobachtung mit der Anwendung (ihrem Nutzungskontext) synchronisiert ist, desto geringer ist die Verzögerung zwischen den Problemen und ihrer Erkennung. Tatsächlich kann die Datenbeobachtung genau zum Zeitpunkt der Datennutzung genutzt werden, um Verzögerungen zwischen Überwachung und Nutzung zu vermeiden. So kannst du Datenprobleme so schnell wie möglich erkennen und vermeiden, dass die Nutzer/innen Probleme vor dir entdecken.

Die Nutzung der Datenbeobachtung auf diese Weise verkürzt die Zeit bis zur Entdeckung von Problemen, da die Dateningenieure rechtzeitig gewarnt werden, weil alle Probleme bei der Datennutzung in Echtzeit beobachtet werden (auch bekannt als synchronisierte Beobachtung).

Effiziente Fehlerbehebung bei Datenproblemen

Wenn in den meisten Unternehmen Datenprobleme auftreten, verbringen Datentechniker/innen viel Zeit damit, herauszufinden, was das Problem ist, woher es kommt und wie man es beheben kann. Und jeder Schritt in diesem Prozess kostet viel Zeit. Mit Datenbeobachtung ist die Zeit bis zur Problemlösung (TTR) viel kürzer, denn dank kontextbezogener Beobachtung, die Informationen über die Daten und ihren Nutzungskontext liefert, ist das gesamte System sichtbar. So können Dateningenieure Probleme beheben, bevor sie sich auf die nachgelagerten Geschäftskunden auswirken.

Vorbeugung von Datenproblemen

Wenn sie als Teil des gesamten Entwicklungslebenszyklus, einschließlich der Produktion, implementiert wird, bietet die Datenbeobachtung eine kontinuierliche Validierung des Zustands der Daten und des Datenökosystems. Die kontinuierliche Validierung kann die Zuverlässigkeit der Anwendungen spürbar verbessern und Datenprobleme verhindern, was die Gesamtbetriebskosten senkt.

Dezentrales Datenqualitätsmanagement

Service Level Agreements (SLAs) können die Datenqualität verwalten und sicherstellen, genauso wie sie in der IT DevOps verwendet werden, um die Zuverlässigkeit und andere wichtige Metriken zu gewährleisten. Dieses neue Management der Datenqualität erfordert Datenbeobachtung, die einerseits eine synchronisierte (nahezu in Echtzeit) und kontinuierliche Validierung der Daten ermöglicht, was die Effizienz der bestehenden Service Level Agreements (SLOs) weiter verbessert. Noch wichtiger ist jedoch, dass die Beobachtbarkeit der Daten es ermöglicht, SLAs und SLOs in der Granularität ihrer Nutzung und im Kontext (z. B. der Anwendung) zu definieren. Diese Fähigkeit löst eines der wichtigsten Hindernisse für Datenqualitätsmanagementprogramme, nämlich die Definition von SLAs durch Eigentümer, Verwalter oder Fachexperten (KMUs), denen es schwerfällt, einen einzigen Satz von Einschränkungen zu definieren, der alle Nutzungserwartungen erfüllen soll. Daher können sie keine einheitlichen (zentralen) SLAs aufstellen, da jeder Anwendungsfall die SLAs wahrscheinlich anders wahrnehmen wird. Der Hauptunterschied bei Daten-SLAs ist, dass sie eine sehr große Anzahl von Formen annehmen können, die sich schnell unendlich anfühlen; zum Beispiel könntest du SLAs für die Mindestdarstellung, die Anzahl der Nullen, die Anzahl der Kategorien, die Schiefe, das Quantil 0,99 usw. für ein einzelnes Feld aus einer zufälligen CSV-Datei haben. Die Beobachtbarkeit der Daten zu nutzen, um die SLAs kontextbezogen zu dezentralisieren (die Nutzung), ist daher der Schlüssel zum Management der Datenqualität und zur Definition einer Kultur der Verantwortlichkeit und klarer Rollen und Verantwortlichkeiten.

Ergänzung bestehender Data Governance-Fähigkeiten

Erinnerst du dich an das DAMA-DMBKO2 Data Governance Framework von vorhin? Da die Datenbeobachtung Teil dieser Architektur ist und alle Bereiche der Data Governance umfasst, bietet sie einen Einblick in die verschiedenen Komponenten, die auf der Datenebene interagieren. So können Datenteams automatisch Dokumentationen erstellen, die dieselbe Art von Daten, Datenspeicherung und Datenmodellierung verwenden, und sie erhalten einen besseren Einblick in die verschiedenen Datenmodelle, die es gibt, welche Daten im Datenkatalog veröffentlicht wurden, welche Analysen für welche Daten durchgeführt wurden und welche Stammdaten verwendet wurden.

Die Zukunft und darüber hinaus

Wenn du die verschiedenen Anwendungsfälle für Datenbeobachtung besser verstehst, solltest du jetzt in der Lage sein, zu verstehen, wie Datenbeobachtung zur Optimierung deiner Datensysteme und Datenteams eingesetzt werden kann.

In den nächsten Kapiteln gehe ich noch weiter ins Detail und zeige dir, wie du diese Anwendungsfälle einrichtest und welche bewährten Methoden du anwenden kannst, um die für jeden Anwendungsfall benötigten Informationen so effizient und wertvoll wie möglich zu erfassen.

Fazit

Die Beobachtbarkeit von Daten ist eine wesentliche Fähigkeit für moderne Organisationen, die sich auf Daten verlassen, um ihre Ziele zu erreichen. Da die Datenteams immer größer und komplexer werden, wird es immer wichtiger, Praktiken zu etablieren, die Transparenz, Governance und Datenvalidierung fördern. Dieses Buch konzentriert sich auf den technischen Aspekt der Data Governance unter dem Aspekt der Beobachtbarkeit von Daten. Durch die Einführung einfacher, aber wirkungsvoller Gewohnheiten können Unternehmen sicherstellen, dass ihre Datenarbeit über den gesamten Lebenszyklus hinweg sichtbar, kontrollierbar und steuerbar ist. In den folgenden Kapiteln werden die Grundprinzipien der Datenbeobachtung sowie bewährte Methoden und Rezepte für die Datenbeobachtung in einem System vorgestellt.

¹ Mary K. Pratt, "CIO (Chief Information Officer)", TechTarget, abgerufen am 11. April 2022.

² Vgl. meinen O'Reilly-Bericht What Is Data Observability?

³ Roxane Edjlali, Ehtisham Zaidi, und Nick Heudecker, "Data Engineering Is Critical to Driving Data and Analytics Success", Gartner Research, 4. Oktober 2018, https://oreil.ly/EPBEn.

⁴ Jen DuBois, "The Growing Demand for Data Engineers", Quanthub, April 26, 2023, https://oreil.ly/0Yrqo.

⁵ Nithya Sambasivan, Shivani Kapania, Hannah Highfill, Diana Akrong, Praveen Paritosh, und Lora M. Aroyo,"'Everyone wants to do the model work, not the data work': Data Cascades in High-Stakes AI," In proceedings of the 2021 CHI Conference on Human Factors in Computing Systems, pp. 1-15, 2021, https://oreil.ly/EbEAW.

⁶ Dr. Anthony Scriffignano, "Data Management Study: The Past, Present, and Future of Data", Dun & Bradstreet, 24. Juni 2019, https://oreil.ly/s1LVH.

⁷ Natürlich kann das Ökosystem für große Unternehmen dramatisch sein, aber trotzdem...

⁸ DAMA ist eine globale Datenmanagement-Gemeinschaft.

⁹ DAMA International, Data Management Body of Knowledge (DMBOK), Zweite Ausgabe. (Technics Publications, 2017).

¹⁰ Petrella, Was ist Datenbeobachtbarkeit?

¹¹ Gartner®, "Quick Answer: 'What is Data Observability'," Ankush Jain, 8. Juni 2022.