Das beste Datenqualitäts-Framework für leitende Plattformingenieure
12. November 2021
Lesedauer: 7 Minuten

Man ist in vielerlei Hinsicht immer nur so gut wie die letzte Leistung, und für viele von uns bedeutet kontinuierliche Leistung auch kontinuierliche Überprüfung. Sie müssen die Qualität aufrechterhalten, aber auch die Wahrnehmung der Qualität, denn wenn das Vertrauen in die Daten einmal gebrochen ist, wird Ihre Arbeit viel schwieriger.

Deshalb muss jedes Unternehmen, das Daten für das Funktionieren seines Geschäfts für wichtig hält – ob interne oder externe Datennutzer –, eine Datenverwaltung einführen und ein Framework zur Datenqualität implementieren. So klingt es: Entwicklung wiederholbarer, idealerweise automatischer Prozesse und Muster, um sicherzustellen, dass die in Ihr System eingegebenen und nachgelagerten Daten den Erwartungen Ihrer Kunden und Verbraucher entsprechen.

Und wie Sie als Senior Data Engineer wissen, ist es schon die halbe Miete, diese Erwartungen zu verstehen. Ein Großteil der anderen Hälfte wird dafür aufgewendet, diese Erwartungen in Nachverfolgung und Warnmeldungen umzusetzen, die Ihnen helfen, Probleme in komplizierten Aufnahmeprozessen zu finden und zu beheben.

In diesem Leitfaden stellen wir verschiedene Strategien vor, mit denen Sie sicherstellen können, dass die Datenverwaltung nicht einfach auf Ihre bestehenden fest programmierten Prozesse aufgesetzt wird, sondern in jede DAG integriert wird. Für eine gute Verwaltung müssen Sie Anomalien erkennen, lange bevor minderwertige Daten in Ihre Transformationsschicht gelangen.

 

Was ist ein Datenqualitäts-Framework?

Beginnen wir mit einer Definition. Ein Datenqualitäts-Framework ist ein Tool, das ein Unternehmen verwenden kann, um relevante Datenqualitätsattribute zu definieren und eine Anleitung für einen Datenqualitätsmanagementprozess bereitzustellen, der kontinuierlich sicherstellt, dass die Datenqualität den Erwartungen der Verbraucher (SLAs) entspricht.

Dieser Satz ist trügerisch komplex, also lassen Sie uns ihn einmal genauer betrachten:

  1. Sie benötigen einen Prozess: Sofern Sie nicht über unbegrenzt viele Ingenieursstunden verfügen, sollte ein Prozess wiederholbare und idealerweise automatische Komponententests in jeder Phase Ihrer Datenpipeline (insbesondere bei der Aufnahme, wenn Sie Probleme proaktiv erkennen möchten) sowie einen Workflow für den Umgang mit Datenproblemen umfassen.
  2. Sie sollten kontinuierlich Folgendes sicherstellen: Ihre Datenqualität nimmt proportional zur Datengeschwindigkeit ab – auch als Datendrift bekannt. Hochgeschwindigkeitsdaten, mit denen viele von uns heute zu tun haben, erfordern häufige Überprüfungen.
  3. Sie müssen die Erwartungen der Verbraucher erfüllen, nicht Ihre eigenen: Datenqualität ist im Grunde ein Geschäftsprozess. Ihre Daten-SLAs oder „Servicevereinbarungen“ gelten für Verbraucher, und nichts auf der technischen Seite ist von Bedeutung, wenn Data Scientists ihre Modelle nicht ausführen können, wenn Kunden ungenaue Schätzungen für die Versandzustellung erhalten oder wenn Ihr Regional Vice President mit leeren Händen in die Vorstandssitzung gehen muss, weil das Dashboard nicht geladen wurde.

Es gehört viel dazu, das oben genannte Versprechen zu erfüllen, und jedes dieser Versprechen ist mit zahlreichen Abhängigkeiten verbunden. Wenn Sie sich beispielsweise fragen, wie ein solches System aufgebaut werden kann, würden Sie folgende Fragen stellen:

  1. Wie werden Sie die Erwartungen der Verbraucher in Bezug auf die Datenqualität verstehen?
  2. Wie werden Sie diese Erwartungen in quantifizierbare Messgrößen für die Datenqualität umsetzen?
  3. Wie werden Sie automatische Qualitätsmaßnahmen für jede Ihrer Pipelines umsetzen?
  4. Wie werden Sie die Schwellenwerte für jede Dimension der Datenqualität festlegen?
  5. Wie werden Sie Ihr Team benachrichtigen, wenn Daten diese Schwellenwerte überschreiten?
  6. Was wird Ihr Team tun, wenn es einen Alert erhält?
  7. Wie werden sie die Gültigkeit und Dringlichkeit des Alerts beurteilen?
  8. Wenn es ein Problem gibt, wie werden sie die unmittelbare(n) Ursache(n) ermitteln?
  9. Wie werden sie die Ursache(n) ermitteln?
  10. Wie werden sie die Verbraucher darüber informieren, was sie erwartet?
  11. Wie wollen sie die Ursache beheben?
  12. Wie werden sie überprüfen, ob sie die Ursache behoben haben?
  13. Wie dokumentieren sie, was passiert ist, um Wissen aufzubauen?

Klingt das nach einer langen, möglicherweise unglücklich nummerierten Liste? Keine Sorge. Sie können delegieren.

Frage 1 ist am besten für den Business Analysten in Ihrem Pod oder Team geeignet. Es liegt an ihnen, mit den Geschäftsbereichen zu sprechen, um Benutzergeschichten, geäußerte Präferenzen, implizite Präferenzen, Anfragen und Ereignisnachbesprechungen in eine Liste von „Anforderungen“ an die Daten zu zerlegen. Dies sind die qualitativen Erwartungen, die Verbraucher an die Daten haben, und es ist ein bisschen wie ein wechselseitiges Gespräch, denn sie haben vielleicht nicht die Worte, um genau zu beschreiben, was sie wollen. (Es sei denn, Ihre Datennutzer sind Ihre Data Scientists, was dies wirklich beschleunigen kann.)

 

Frage 2 ist von Ihnen und Ihren Data Scientists gemeinsam zu beantworten (insbesondere, wenn sie auch die Verbraucher sind). Welche Attribute können Sie angesichts der Eigenschaften Ihrer Daten für jede Pipeline tatsächlich messen, um die Liste der qualitativen Erwartungen in eine Liste quantitativer Messungen weiter aufzuschlüsseln?

Je nachdem, welches Datenqualitätsmodell Sie verwenden, gibt es entweder vier oder fünf Qualitätsdimensionen, die Sie berücksichtigen müssen. Bei IBM Databand bevorzugen wir ein Modell mit vier Merkmalen:

  • Fitness
    • Genauigkeit – die Daten spiegeln die Realität wider
    • Integrität – Qualität / Zeit
  • Abstammung
    • Quelle – Erfüllt der Anbieter Ihre Erwartungen?
    • Ursprung – woher kam es?
  • Governance
    • Datenkontrollen
    • Datenschutz
    • Verordnung
    • Sicherheit
  • Stabilität
    • Konsistenz
    • Verlässlichkeit
    • Aktualität
    • Bias

Mit diesen Metriken können Data Engineers die Fragen 3 bis 13 beantworten und mit der Entwicklung einer Strategie zur Datenqualitätsverwaltung beginnen. Und bevor wir uns damit befassen, wie das genau geht, lohnt es sich zu fragen, warum man sich all diese Mühe macht.

 

Warum ein Datenqualitäts-Framework so wichtig ist

Vor einigen Jahren führte eine harmlose Konfigurationsänderung in Microsoft Dynamics CRM eines großen Einzelhändlers dazu, dass die Anzahl der online angezeigten Bestände pro Artikel nicht mehr der Realität entsprach. Der Zähler wurde einfach nicht mehr aktualisiert.

Die Leute kauften weiterhin, aber die Stückzahl blieb konstant. Als das Datenverarbeitungsteam alarmiert wurde, war es bereits zu spät.

Die meisten Artikel konnten online gekauft, aber auch im Geschäft abgeholt werden. Viele Kunden haben sich für die Abholung im Geschäft entschieden. Die Bestellungen wurden bearbeitet und Artikel, die es nicht gab, wurden trotzdem verkauft. Die Kunden gingen also in die Geschäfte, wo die Verkäufer sich bemühten, Ersatz zu finden oder Rabatte zu versprechen oder sie irgendwie zu beschwichtigen. Es bildeten sich Schlangen. Die Kunden mussten warten, um etwas zu kaufen, und waren genervt von so vielen Menschen, die wütend auf ihre Telefone starrten. Und da es Tage dauerte, bis das Problem entdeckt und die Pipeline repariert wurde, dauerte es noch ein paar Tage länger, bis alles geklärt war.

Unter Berücksichtigung des Imageverlusts für die Marke hat der Fehler zig Millionen gekostet und hätte nicht passieren müssen.

Das heißt, die Datenprobleme häufen sich. Sie sind manchmal schwer zu erkennen und anzugehen und können unbemerkt wachsen. Es ist leicht, in ein Muster zu verfallen, bei dem man davon ausgeht, dass alles funktioniert, nur weil man immer noch einige wenige Erkenntnisse gewinnt, selbst wenn man eine zunehmende Menge an verdeckten Daten anhäuft.

Darüber hinaus sind die deutlichsten Anzeichen für Datenqualitätsprobleme in der Regel Spätindikatoren. Zum Beispiel Verbraucher, die es Ihnen sagen. Oder wie im vorherigen Beispiel für ein Einzelhandels-CRM, das Ihnen Tausende von Verkaufsleiter und regionalen Vizepräsidenten bestätigen. Das ist schlecht. Das bedeutet, dass die Daten schon seit einiger Zeit in Ihrem System sind und es Tage dauern wird, bis eine Lösung Ergebnisse bringt. Dies zum Thema fehlende Kundenerwartungen.

In dieser Situation befand sich das Versand-Startup Shipper und deshalb investierte es so viel, um zu verhindern, dass es jemals dazu kommt. Ihr Datenentwicklungsteam liefert Daten so nah wie möglich in Echtzeit an eine Anwendung, die E-Commerce-Anbietern dabei hilft, ihren Bestand an einen Versandhafen zu liefern. Sie müssen sich nicht nur um die Erwartungen ihrer eigenen Kunden sorgen, sondern auch um die der Kunden ihrer Kunden. Und wenn ihr System manchmal zwei Tage veraltet war, führte dies zu einer Welle von enttäuschten Erwartungen. Daher investierten sie stark in das Datenqualitätsmanagement und in Tools, die ihnen Frühwarnmeldungen mit automatischen Überprüfungen liefern konnten.

Datenqualitätsmanagement ist eine Möglichkeit, die Datenqualitätsprüfungen automatisch und umfassend durchzuführen, sodass Sie den Kräften der Entropie in Ihren Datensätzen und Pipelines mit einer gleichen und entgegengesetzten Kraft entgegenwirken.

 

Aufbau Ihres Datenqualitäts-Framework

Kehren wir zu unserem früheren Beispiel und der Liste der Fragen zurück. Ihre Analysten sprechen mit dem Unternehmen, um die Anforderungen zu ermitteln, und Sie erhalten von Ihren Data Scientists eine Liste mit quantitativen Verbrauchererwartungen. Wie geht es dann weiter und wie wird das System aufgebaut?

Sie entwerfen Ihr Datenqualitäts-Framework. Ihr Framework sollte in erster Linie anerkennen, dass das System ein Kreislauf ist und alles, was Sie über die sich ständig weiterentwickelnden Erwartungen der Verbraucher lernen, sollte das System beeinflussen.

 

Betrachten wir jede dieser Phasen einmal genauer:

  1. Qualifizieren: Unternehmensanalysten gliedern die Bedürfnisse der Verbraucher in eine Liste von Anforderungen auf.
  2. Quantifizieren: Data Scientist zerlegen Anforderungen in quantifizierbare Messgrößen für die Datenqualität, die zu diesem Zeitpunkt noch rein theoretisch sind.
  3. Planen: Dateningenieure übersetzen quantitative Messungen der Datenqualität in Prüfungen, die sie in ihrer Data-Pipeline-Observability-Plattform ausführen können. Eine solche Plattform ist von entscheidender Bedeutung – Workflow- und Pipeline-Planungssysteme wie Airflow und Spark können Probleme in einer Pipeline selbst erkennen, jedoch nicht innerhalb der Daten, wo die meisten Probleme auftreten. Ihre Ingenieure müssen verstehen, was in Ihrem System nachverfolgt werden kann und was nicht.
  4. Implementieren: Dateningenieure implementieren das Tracking und testen sie. Ein sehr einfaches Beispiel: Wenn alle Daten vorhanden sein müssen und keine Felder oder Spalten fehlen dürfen, können Sie eine Warnung für die Parameter der Datenvollständigkeit einrichten. Eine Observability-Plattform wie Databand macht dies möglich und kann Ihnen die Einrichtung einer Anomalieerkennung ermöglichen, sodass Sie nicht jeden Wert manuell einstellen müssen.
  5. Verwalten: Dateningenieure führen einen Backtest dieser Warnmeldungen anhand historischer Pipeline-Daten durch, um zu überprüfen, ob sie tatsächlich wie vorgesehen funktioniert hätten. Wenn dies zutrifft, werden sie zusammen mit einem Plan für das Vorfallsmanagement in die Produktion aufgenommen, der festlegt, wer bei Auslösung eines Alarms verantwortlich ist und was zu tun ist, wenn ein solcher Alarm eingeht.
  6. Verifizieren: Dateningenieure und Data Scientists bestätigen, dass das Framework zur Datenverwaltung die Leistung entlang der gewünschten Metriken messbar verbessert hat. Die Unternehmensanalysten bestätigen dies durch Befragungen von Verbrauchern.

Und was machen Sie mit Ihrem Framework? Sie setzen es in die Praxis um.

 

Ein gutes Datenqualitäts-Framework bedeutet keine Überraschungen mehr

Wie wir in vielen unserer Beispiele untersucht haben, ist der schlechteste Indikator für ein Datenqualitätsproblem ein Spätindikator – beispielsweise wenn ein Verbraucher Ihnen mitteilt, dass etwas defekt ist. Ein Großteil unserer Arbeit im Bereich Datenverarbeitung besteht darin, Vertrauen aufzubauen und Pipelines zu entwickeln.

Durch die Investition in ein Framework zur Datenqualitätsverwaltung, das Ihrem Team hilft, Probleme automatisch zu erkennen, schaffen Sie vertrauenswürdige Daten. Und das erleichtert Ihnen die Arbeit erheblich.

Erkunden Sie, wie IBM Databand eine bessere Überwachung der Datenqualität ermöglicht, indem es unerwartete Spaltenänderungen und Nulldatensätze erkennt, um Sie bei der Einhaltung von Daten-SLAs zu unterstützen. Wenn Sie bereit sind, einen genaueren Blick darauf zu werfen, buchen Sie noch heute eine Demo.