Eine Liste der 13 häufigsten Pipeline-Datenprobleme (mit Beispielen)

Der vielleicht kniffligste Teil bei der Verwaltung von Datenpipelines besteht darin, den Geist in der Maschine zu verstehen - die Daten ex machina, wenn Sie so wollen.

Wie lassen sich Probleme mit der Datenqualität beheben? Es beginnt mit dem Wissen, dass das, was herausragende Dateningenieure von den anderen unterscheidet, ihre Fähigkeit ist, die Ursache von Datenproblemen aufzuspüren. Jeder kann die Pipeline zurücksetzen, mit den Schultern zucken und die Arbeit wieder aufnehmen. Nur sehr wenige spielen Detektiv, um dem Problem auf den Grund zu gehen, obwohl genau das nötig ist.

Das ist der Unterschied zwischen Zufriedenheit mit proximalen Ursachen oder Grundursachen. Proximale Ursachen sind die Dinge, die offenbar schiefgelaufen sind – wie ein Laufzeitfehler. Die eigentliche Ursache ist das, was die unmittelbare Ursache hervorgerufen hat, und sie ist viel schwieriger herauszufinden. Manchmal sind proximale Ursachen die Hauptursachen, aber selten.

Stellen Sie sich proximale Ursachen als bloße Warnungen vor. Sie sagen Ihnen, dass irgendwo in Ihrer Datenverarbeitungskette ein grundlegender Fehler vorliegt. Wer das ignoriert, handelt auf eigene Gefahr, denn diese Datenschuld wächst mit der Zeit.

Ein Unglück kommt selten allein, und wenn Sie ein Problem haben, haben Sie in der Regel viele. Im Folgenden sind die häufigsten Möglichkeiten von Problemen mit proximalen Daten aufgeführt – diese Probleme schließen sich nicht gegenseitig aus, und die Liste ist bei weitem nicht vollständig:

• Der Zeitplan hat sich geändert
• Die Pipeline ist aufgrund eines Timeouts ausgefallen.
• Ein Auftrag ist in einer Warteschlange stecken geblieben
• Es gab eine unerwartete Transformation
• Ein bestimmter Lauf ist fehlgeschlagen (vielleicht schlägt er gleich beim Start fehl)
• Der Lauf dauerte ungewöhnlich lang
• Es gab einen systemweiten Ausfall
• Bei der Transformation ist ein Fehler aufgetreten
• Viele Jobs scheiterten in der Nacht zuvor
• Es gab eine anomale Eingabegröße
• Es gab eine anomale Ausgabegröße
• Es gab eine anomale Laufzeit
• Eine Aufgabe wurde unerwartet abgebrochen
• Es ist ein Laufzeitfehler aufgetreten.

Aber das ist noch nicht alles, oder? Betrachten Sie dies also nicht als Probleme, sondern als Signale. Das sind all die Dinge, die schief gehen können und darauf hindeuten, dass etwas Beunruhigendes passiert ist. Viele werden gleichzeitig auftreten.
Eine Observability-Plattform kann dabei sehr hilfreich sein. So können Sie gleichzeitig auftretende Probleme gruppieren, um sie besser zu verstehen.

Sie können Probleme auch nach der Dimension der Datenqualität gruppieren, zu der sie sich summieren, z. B. Eignung, Herkunft, Governance oder Stabilität. Wenn Sie Datenprobleme auf diese Weise gruppieren, werden Ihnen die Dimensionen angezeigt, in denen Sie die meisten Probleme haben, und Sie können scheinbar isolierte Probleme in einen Kontext stellen.

Und natürlich müssen Sie nicht erst warten, bis ein Auftrag scheitert, um dies auszuprobieren. Mit Databand können Sie Anomalien nachträglich untersuchen (es erfasst alle historischen Metadaten), sodass Sie genau feststellen können, was zufällig und was lediglich korreliert ist.

Auf diese Weise können Sie ein Problem, z. B. eine Aufgabe, die ins Stocken gerät, unter einem Dutzend Fehlern auswählen und anhand vieler Probleme testen, ob die Ursache wahrscheinlich ein Fehler bei der Cluster-Bereitstellung ist. Und so sollten Sie es auch betrachten. Suchen Sie immer nach der Grundursache des Datenproblems.

Die Ursachen sind das Ende des Weges. Sie sollten das ursprüngliche Ereignis in der Kausallinie sein - sozusagen der erste Dominostein - und das Problem weitgehend erklären. Wenn die Grundursache des Datenproblems nicht auftritt, sollte auch keine der proximalen Ursachen auftreten. Es ist die direkte Ursache für alle diese Probleme.

Die Ursachen sind natürlich nicht immer klar, und die Korrelationen sind nicht immer exakt. Wenn Sie sich Ihrer Antwort nicht sicher sind, können Sie Ihren wahren Vertrauenswert auf probabilistische Weise herausfinden, indem Sie dieses Gedankenexperiment ausprobieren: Sagen wir, Ihr Chef sagt Ihnen, Ihr Team wird Ihre Hypothese voll und ganz verfolgen und niemand wird sie überprüfen, bevor sie in Produktion geht, und Ihr Name wird überall darauf stehen. Wenn etwas falsch ist, ist alles Ihre Schuld. Welchen Konfidenzwert auf einer Skala von 0 bis 100 würden Sie Ihrer Hypothese geben? Wenn der Wert unter 70 liegt, sollten Sie weiter ermitteln.

Häufige Ursachen für Datenprobleme sind:

1. Benutzerfehler: Wir beginnen mit Benutzerfehlern, da diese häufig vorkommen. Möglicherweise hat jemand das falsche Schema oder einen falschen Wert eingegeben, was bedeutet, dass die Pipeline die Daten nicht lesen kann, oder es wurde zwar das Richtige mit falschen Werten getan, aber jetzt ist eine Aufgabe fehlgeschlagen.

2. Unsachgemäß beschriftete Daten: Manchmal verschieben sich Zeilen in einer Tabelle und die richtigen Beschriftungen werden auf die falschen Spalten angewendet.

3. Der Datenpartner hat eine Lieferung verpasst: Ebenfalls sehr häufig. Sie können ein sicheres System bauen, aber Sie können nicht kontrollieren, was Sie nicht sehen können, und wenn die Datenprobleme in den Quelldaten liegen, führt dies dazu, dass sich perfekt funktionierende Pipelines falsch verhalten.

4. Es gibt einen Fehler im Code: Dies kommt häufig vor, wenn es eine neue Version der Pipeline gibt. Mit Versionierungssoftware wie Git oder GitLab können Sie das ziemlich schnell herausfinden. Vergleichen Sie den Produktionscode mit einer früheren Version und führen Sie einen Test mit dieser vorherigen Version durch.

5. OCR-Datenfehler: Ihr optischer Scanner liest die Daten falsch aus, was zu seltsamen (oder fehlenden) Werten führt.

6. Problem mit verfallenen Daten: Der Datensatz ist so veraltet, dass er nicht mehr gültig ist.

7. Problem mit doppelten Daten: Oft kann ein Anbieter keine Daten liefern, so dass die Pipeline mit den Daten der letzten Woche lief.

8. Berechtigungsproblem: Die Pipeline ist fehlgeschlagen, weil dem System die Berechtigung zum Abrufen der Daten oder zur Durchführung einer Transformation fehlte.

9. Infrastrukturfehler: Vielleicht haben Sie Ihr verfügbares Speicher- oder API-Aufruflimit ausgeschöpft, Ihr Apache Spark-Cluster lief nicht oder Ihr Data Warehouse ist ungewöhnlich langsam, sodass der Lauf ohne die Daten fortgesetzt wird.

10. Zeitplanänderungen: Jemand (oder etwas) hat den Zeitplan geändert, was dazu führt, dass die Pipeline nicht mehr richtig oder gar nicht läuft.

11. Voreingenommener Datensatz: Sehr schwierig zu sortieren. Es gibt keine gute Möglichkeit, dies herauszufinden, außer indem man einige Tests durchführt, um zu sehen, ob die Daten im Vergleich zu einem ähnlichen echten Datensatz ungewöhnlich sind, oder herauszufinden, wie sie erfasst oder erzeugt wurden.

12. Ausfall des Orchestrators: Ihr Pipeline-Planer konnte den Auftrag nicht planen oder ausführen.

13. Der Geist in der Maschine (Data ex machina): Er ist wahrhaft unergründlich. Es ist schwer, das zuzugeben, aber für manche Dinge stimmt es. Das Beste, was Sie tun können, ist zu dokumentieren und bereit für das nächste Mal zu sein, wenn Sie mehr Daten sammeln und anfangen können, Korrelationen zu ziehen.

Und dann gibt es natürlich noch die Realität, in der die eigentliche Ursache nicht ganz klar ist. Viele Dinge hängen miteinander zusammen und sind wahrscheinlich voneinander abhängig, aber es gibt keine einfache Antwort – und nachdem Sie Änderungen vorgenommen haben, haben Sie das Datenproblem behoben, obwohl Sie sich nicht sicher sind, warum.

Notieren Sie in solchen Fällen, wie in allen anderen auch, Ihre Hypothese im Protokoll und fahren Sie fort, sobald Sie dazu zurückkehren können, mit dem Testen historischer Daten und achten Sie dabei auf neue Probleme und weitere Erklärungsansätze.

Die Eigenschaft, die den Amateur-Datentechniker am meisten vom Experten unterscheidet, ist seine Fähigkeit, die Ursachen herauszufinden und mit mehrdeutigen Antworten umzugehen. Proximale Ursachen sind manchmal Grundursachen, aber nicht immer. Grundlegende Ursachen sind manchmal mit spezifischen proximalen Ursachen korreliert, aber nicht immer. Manchmal lässt sich nicht unterscheiden, was auf Datenverzerrung und was auf menschliches Versagen zurückzuführen ist.

Gute Data Engineers wissen, dass ihre Pipelines wankelmütig sind und manchmal Persönlichkeiten haben. Aber sie sind darauf eingestellt, haben Werkzeuge zur Messung und sind immer auf der Suche nach einer verlässlicheren Erklärung.

Erfahren Sie, wie IBM Databand eine Überwachung der Datenpipeline bereitstellt, um Daten-Vorfälle wie fehlgeschlagene Jobs und Ausführungen schnell zu erkennen, damit Sie für Ihr Pipeline-Wachstum gerüstet sind. Wenn Sie bereit sind, einen genaueren Blick darauf zu werfen, buchen Sie noch heute eine Demo.