Eine Antwort und viele Greatest Practices dazu, wie größere Organisationen Datenqualitätsprogramme für moderne Datenplattformen operationalisieren können
Ich habe mit Dutzenden von Unternehmensdatenexperten bei den größten Unternehmen der Welt gesprochen und eine der am häufigsten gestellten Fragen zur Datenqualität lautet: „Wer macht was?“ Darauf folgt schnell die Frage: „Warum und wie?“
Dafür gibt es einen Grund. Datenqualität ist wie ein Staffellauf. Der Erfolg jeder Etappe – Erkennung, Sichtung, Lösung und Messung – hängt von der anderen ab. Mit jeder Weitergabe des Staffelstabs steigt die Wahrscheinlichkeit eines Misserfolgs sprunghaft an.
Praktische Fragen verdienen praktische Antworten.
Allerdings ist jede Organisation im Hinblick auf Daten etwas anders organisiert. Ich habe Organisationen mit 15.000 Mitarbeitern erlebt, die den Besitz aller kritischen Daten zentralisierten, während Organisationen, die halb so groß sind, sich dazu entschieden, den Datenbesitz vollständig über Geschäftsdomänen hinweg zu föderieren.
In diesem Artikel werde ich mich auf die gängigste Unternehmensarchitektur beziehen, die eine Mischung aus beiden ist. Dies ist das Ziel der meisten Datenteams und weist auch viele teamübergreifende Verantwortlichkeiten auf, die es besonders komplex und diskussionswürdig machen.
Denken Sie einfach daran, dass es sich bei dem Folgenden um EINE Antwort handelt und nicht um DIE Antwort.
In diesem Artikel:
Ob Sie eine Datennetz Strategie oder etwas ganz anderes, eine gemeinsame Erkenntnis für moderne Datenteams ist die Notwendigkeit, sich auf ihre wertvollsten Datenprodukte.
Diese Bezeichnung wird einem Datensatz, einer Anwendung oder einem Dienst gegeben, dessen Ergebnisse für das Unternehmen besonders wertvoll sind. Dies könnte eine umsatzgenerierende Anwendung für maschinelles Lernen oder eine Reihe von Erkenntnissen sein, die aus sorgfältig kuratierten Daten gewonnen wurden.
Mit zunehmendem Umfang und Komplexität werden Datenteams stärker differenzieren zwischen Grundlegende und abgeleitete Datenprodukte. Ein grundlegendes Datenprodukt gehört normalerweise einem zentralen Datenplattformteam (manchmal auch einem auf die Quelle ausgerichteten Datenentwicklungsteam). Sie sind darauf ausgelegt, Hunderte von Anwendungsfällen in vielen Groups oder Geschäftsbereichen abzudecken.
Abgeleitete Datenprodukte werden auf diesen grundlegenden Datenprodukten aufgebaut. Sie sind Eigentum von domänenspezifischen Datenteams und für einen bestimmten Anwendungsfall konzipiert.
Beispielsweise ist eine „Einzelansicht des Kunden“ ein gängiges grundlegendes Datenprodukt, das abgeleitete Datenprodukte wie ein Produkt-Upselling-Modell, eine Abwanderungsprognose und ein Unternehmens-Dashboard speisen kann.
Für die Erkennung, Priorisierung, Lösung und Messung von Datenqualitätsvorfällen gibt es bei diesen beiden Datenprodukttypen unterschiedliche Prozesse. Es ist wichtig, die Kluft zwischen ihnen zu überbrücken. Hier ist eine beliebte Methode, die ich bei Datenteams gesehen habe.
Grundlegende Datenprodukte
Bevor sie auffindbar werden, sollte es eine bestimmte Eigentümer der Datenplattformentwicklung für jeder Grundlegendes Datenprodukt. Dies ist das Staff, das für die Überwachung von Aktualität, Volumen, Schema und Basisqualität über die gesamte Pipeline hinweg verantwortlich ist. Eine gute Faustregel, der die meisten Groups folgen, lautet: „Wer es gebaut hat, besitzt es.“
Mit Basisqualität meine ich ganz konkret Anforderungen, die allgemein auf viele Datensätze und Domänen verallgemeinert werden können. Sie werden häufig von einem zentralen Governance-Staff für kritische Datenelemente definiert und entsprechen im Allgemeinen den 6 Dimensionen der Datenqualität. Anforderungen wie „ID-Spalten sollten immer eindeutig sein“ oder „Dieses Feld ist immer als gültiger US-Bundesstaatscode formatiert.“
Mit anderen Worten: Die Eigentümer grundlegender Datenprodukte können nicht einfach sicherstellen, dass die Daten pünktlich eintreffen. Sie müssen sicherstellen, dass die Quelldaten vollständig und gültig sind, dass die Daten über alle Quellen und nachfolgenden Ladevorgänge hinweg konsistent sind und dass kritische Felder fehlerfrei sind. Modelle zur Anomalieerkennung auf Foundation maschinellen Lernens können in dieser Hinsicht besonders effektiv sein.
Präzisere und individuellere Anforderungen an die Datenqualität hängen normalerweise vom Anwendungsfall ab und lassen sich besser von den Besitzern abgeleiteter Datenprodukte und den nachgelagerten Analysten anwenden.
Abgeleitete Datenprodukte
Die Überwachung der Datenqualität muss auch auf der Ebene der abgeleiteten Datenprodukte erfolgen, da fehlerhafte Daten zu jedem Zeitpunkt im Datenlebenszyklus eindringen können.
Auf dieser Ebene muss jedoch eine größere Oberfläche abgedeckt werden. „Alle Tabellen auf jede Möglichkeit hin zu überwachen“ ist keine praktische Possibility.
Es gibt viele Faktoren, die bestimmen, wann eine Sammlung von Tabellen zu einem abgeleiteten Datenprodukt werden sollte, aber sie alle lassen sich auf eine Beurteilung des nachhaltigen Werts reduzieren. Dies wird oft am besten umgesetzt durch Domänenbasierte Datenverwalter die dem Geschäft nahe stehen und befugt sind, allgemeine Richtlinien hinsichtlich Häufigkeit und Kritikalität der Nutzung zu befolgen.
So ließ beispielsweise einer meiner Kollegen in seiner früheren Place als Leiter der Datenplattform bei einem nationalen Medienunternehmen einen Analysten ein Grasp Content material-Dashboard entwickeln, das in der gesamten Redaktion schnell beliebt wurde. Nachdem es in den Arbeitsablauf genügender Benutzer integriert warfare, wurde ihnen klar, dass dieses Advert-hoc-Dashboard produktisiert werden musste.
Wenn ein abgeleitetes Datenprodukt erstellt oder identifiziert wird, sollte es einen domänenspezifischen Eigentümer haben, der für die Finish-to-Finish-Überwachung und die Qualität der Basisdaten verantwortlich ist. In vielen Organisationen handelt es sich dabei um Domänendatenverwalter, da diese mit globalen und lokalen Richtlinien am besten vertraut sind. Andere Eigentumsmodelle umfassen die Benennung des eingebetteten Dateningenieurs, der die abgeleitete Datenproduktpipeline erstellt hat, oder des Analysten, der für die Final-Mile-Tabelle verantwortlich ist.
Der andere wesentliche Unterschied im Erkennungsworkflow auf der Ebene abgeleiteter Datenprodukte sind Geschäftsregeln.
Manche Datenqualitätsregeln können weder automatisiert noch aus zentralen Requirements generiert werden. Sie können nur aus dem Unternehmen kommen. Regeln wie: „Das Feld „discount_percentage“ kann nie größer als 10 sein, wenn „account_type“ gewerblich und „customer_region“ EMEA ist.“
Die beste Vorgehensweise bei der Anwendung dieser Regeln liegt in der Verantwortung von Analysten, insbesondere dem Tabellenbesitzer, auf der Grundlage ihrer Erfahrungen und des Feedbacks aus dem Unternehmen. Es ist nicht notwendig, dass jede Regel die Erstellung eines Datenprodukts auslöst, das wäre zu aufwändig und belastend. Dieser Prozess sollte vollständig dezentralisiert, selbsterklärend und leichtgewichtig sein.
Grundlegende Datenprodukte
In mancher Hinsicht ist die Sicherstellung der Datenqualität für grundlegende Datenprodukte weniger komplex als für abgeleitete Datenprodukte. Es gibt per Definition weniger grundlegende Produkte und diese sind in der Regel im Besitz technischer Groups.
Das bedeutet, dass der Datenproduktbesitzer oder ein Dateningenieur auf Abruf innerhalb des Plattformteams für allgemeine Triage-Aufgaben verantwortlich sein kann. Dazu zählen beispielsweise das Reagieren auf Warnmeldungen, das Bestimmen des wahrscheinlichen Ursprungsorts, das Einschätzen des Schweregrads und die Kommunikation mit den Verbrauchern.
Jedes grundlegende Datenprodukt sollte mindestens einen dedizierten Warnkanal in Slack oder Groups haben.
Dies vermeidet die Alarmmüdigkeit und kann als zentraler Kommunikationskanal für alle Besitzer abgeleiteter Datenprodukte mit Abhängigkeiten dienen. Soweit sie es wünschen, können sie über Probleme auf dem Laufenden bleiben und proaktiv über bevorstehende Schema- oder andere Änderungen informiert werden, die sich auf ihre Abläufe auswirken können.
Abgeleitete Datenprodukte
Normalerweise gibt es zu viele abgeleitete Datenprodukte, als dass Dateningenieure angesichts ihrer Bandbreite eine ordnungsgemäße Sichtung durchführen könnten.
Eine häufig angewandte Strategie besteht darin, jedem Besitzer eines abgeleiteten Datenprodukts die Verantwortung für die Priorisierung von Warnmeldungen zu übertragen (siehe Abbildung unten). Diese Strategie kann jedoch auch scheitern, wenn die Anzahl der Abhängigkeiten zunimmt.
Ein fehlgeschlagener Orchestrierungsjob kann sich beispielsweise kaskadierend auf die weitere Entwicklung auswirken und Dutzende von Warnmeldungen bei mehreren Datenproduktbesitzern auslösen. Die sich überschneidenden Feueralarme sind ein Albtraum.
Eine immer häufiger eingesetzte Greatest Follow besteht darin, dass ein dediziertes Triage-Staff (häufig als Dataops bezeichnet) alle Produkte innerhalb einer bestimmten Domäne unterstützt.
Dies kann eine Goldlöckchen-Zone sein, die die Vorteile der Spezialisierung nutzt, ohne so unvorstellbar groß zu werden, dass sie zu einem Engpass ohne Kontext wird. Diese Groups muss Lassen Sie sich coachen und befähigen, bereichsübergreifend zu arbeiten. Andernfalls werden Sie einfach die Silos und sich überschneidenden Notfallübungen wieder einführen.
In diesem Modell trägt der Datenproduktbesitzer Rechenschaftspflicht, jedoch keine Verantwortung.
Wakefield Analysis befragte mehr als 200 Datenexperten, die durchschnittliche Anzahl der Vorfälle professional Monat betrug 60 und die mittlere Zeit zur Lösung jedes erkannten Vorfalls betrug 15 Stunden. Es ist leicht zu erkennen, wie Dateningenieure im Rückstand versinken.
Dafür gibt es viele Faktoren, aber der wichtigste ist, dass wir die Anomalie sowohl technologisch als auch verfahrenstechnisch von der Grundursache getrennt haben. Dateningenieure kümmern sich um ihre Pipelines und Analysten um ihre Metriken. Dateningenieure legen ihre Airflow-Warnmeldungen fest und Analysten schreiben ihre SQL-Regeln.
Aber Pipelines – die Datenquellen, die Systeme, die die Daten bewegen, und der Code, der sie transformiert – sind die Hauptursache für das Auftreten von Metrikanomalien..
Um die durchschnittliche Zeit bis zur Lösung zu verkürzen, benötigen diese technischen Problemlöser eine Datenbeobachtungsplattform oder eine Artwork zentrale Kontrollebene, die die Anomalie mit der Grundursache verbindet. Beispielsweise eine Lösung, die aufzeigt, wie eine Verteilungsanomalie im Feld discount_amount mit einer gleichzeitig aufgetretenen Änderung der Upstream-Abfrage zusammenhängt.
Grundlegende Datenprodukte
Apropos proaktive Kommunikation: Das Messen und Aufzeigen der Integrität grundlegender Datenprodukte ist für deren Akzeptanz und Erfolg von entscheidender Bedeutung. Wenn die nachgelagerten Konsumbereiche der Qualität der Daten oder der Zuverlässigkeit ihrer Bereitstellung nicht vertrauen, gehen sie direkt zur Quelle. Und zwar jedes Mal.
Dies macht natürlich den gesamten Zweck grundlegender Datenprodukte zunichte. Skaleneffekte, standardmäßige Onboarding-Governance-Kontrollen, klare Transparenz hinsichtlich Herkunft und Nutzung sind damit alle hinfällig.
Es kann eine Herausforderung sein, einen allgemeinen Customary für Datenqualität bereitzustellen, der auf eine Vielzahl von Anwendungsfällen anwendbar ist. Was die nachgelagerten Datenteams jedoch wirklich wissen möchten, ist:
- Wie oft werden die Daten aktualisiert?
- Wie intestine ist die Wartung? Wie schnell werden Störungen behoben?
- Wird es häufige Schemaänderungen geben, die meine Pipelines beschädigen?
Knowledge Governance-Groups können hier helfen, indem sie diese gemeinsamen Anforderungen aufdecken und kritische Datenelemente um intelligente SLAs in einem Marktplatz oder Katalog einzurichten und anzuzeigen (mehr Einzelheiten, als Sie sich bei der Implementierung jemals wünschen könnten Hier).
Das ist die Ansatz des Roche-Datenteams das eines der erfolgreichsten Enterprise-Datennetze der Welt geschaffen hat, die sie schätzen hat etwa 200 Datenprodukte und einen geschätzten Wert von 50 Millionen US-Greenback generiert.
Abgeleitete Datenprodukte
Für abgeleitete Datenprodukte sollten explizite SLAs basierend auf dem definierten Anwendungsfall festgelegt werden. Beispielsweise muss ein Finanzbericht möglicherweise hochpräzise sein und einen gewissen Spielraum hinsichtlich der Aktualität haben, während bei einem maschinellen Lernmodell das genaue Gegenteil der Fall sein kann.
Integritätsbewertungen auf Tabellenebene können hilfreich sein, aber häufig wird fälschlicherweise angenommen, dass die von einem Analysten für eine gemeinsam genutzte Tabelle festgelegten Geschäftsregeln auch für einen anderen related sind. Eine Tabelle scheint von geringer Qualität zu sein, aber bei näherer Betrachtung sind einige veraltete Regeln Tag für Tag wiederholt fehlgeschlagen, ohne dass Maßnahmen zur Behebung des Issues oder zur Überschreitung des Regelgrenzwerts ergriffen wurden.
Wir haben viel erreicht. Dieser Artikel warfare eher ein Marathon als ein Staffellauf.
Die oben genannten Workflows sind A Weg, um mit Datenqualität und Datenbeobachtungsprogrammen erfolgreich zu sein, aber sie sind nicht die einzige Weg. Wenn Sie klare Prozesse priorisieren für:
- Erstellung und Besitz von Datenprodukten;
- Anwenden einer Finish-to-Finish-Abdeckung für diese Datenprodukte;
- Selbstbedienungs-Geschäftsregeln für nachgelagerte Belongings;
- Reagieren auf und Untersuchen von Warnungen;
- Beschleunigung der Ursachenanalyse; und
- Vertrauensbildung durch Kommunikation der Datenintegrität und operativer Reaktion
…Sie werden feststellen, dass Ihr Staff die Ziellinie in Sachen Datenqualität überquert.
Folgen Sie mir auf Medium für weitere Geschichten zu Datentechnik, Datenqualität und verwandten Themen.