ETL verstehen

Kapitel 4. Pipeline-Probleme und Fehlerbehebung

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

Wie wir bereits angedeutet haben, besteht das Hauptziel jeder ETL darin, einen Geschäftswert zu schaffen. Dieses Ziel wird jedoch oft durch anfällige Systeme mit langen Wiederherstellungszeiten behindert, was dazu führt, dass zu viele Ressourcen für die Fehlerbehebung statt für Innovation und Wertschöpfung eingesetzt werden.

Eine gut konzipierte ETL-Pipeline muss daher robust und wartbar sein und Schlüsselmerkmale wie eine hohe Datenqualität, eine effiziente Fehlerbehandlung und eine effektive Problemerkennung aufweisen - alles wesentliche Bestandteile der Systembeobachtbarkeit. Unabhängig von deinen technischen Fähigkeiten werden deine Systeme fehlschlagen - nicht alles liegt in unserer Hand!

Planung für den Fall des Scheiterns bedeutet, dass wir Pipelines bauen, die:

• sind einfach zu pflegen und zu erweitern, d.h. sie ermöglichen eine schnelle Fehlersuche und die Entwicklung neuer Funktionen

• Automatisierte Möglichkeiten zur Fehlerbehandlung in Echtzeit und zur Wiederherstellung nach einem Ausfall bieten

• Einen Rahmen für Verbesserungen auf der Grundlage von Lernen und Erfahrung einbeziehen

Dieser Ansatz sorgt für Wartungsfreundlichkeit und knüpft nahtlos an einen weiteren kritischen Aspekt von ETL-Systemen an: die Skalierbarkeit.

Wir werden untersuchen, wie die Wartung eines Systems mit seiner Skalierung einhergeht und welche Herausforderungen und Strategien es gibt, um sicherzustellen, dass deine ETL-Pipeline sowohl belastbar als auch anpassungsfähig an sich verändernde Geschäftsanforderungen ist.

Instandhaltbarkeit

In einem Kapitel über Probleme und Fehlerbehebung geht es vor allem um das Thema Wartbarkeit - im wahrsten Sinne des Wortes um die Fähigkeit, die Dinge zu warten, die du bereits gebaut hast.

Als Ingenieure sind wir manchmal ausschließlich auf Lösungen fixiert. Wir sind zwar große Befürworter von Minimum Viable Products und dem 80/20-Prinzip, aber bei der Zusammenarbeit an Systemen zur Steigerung des Geschäftswerts ist die Fähigkeit, diese Systeme zu warten und zu skalieren (das Thema von Kapitel 5), unerlässlich. Die Unfähigkeit, eine Pipeline aufrechtzuerhalten, hat direkte und indirekte Kosten für dein Team zur Folge. Während Ersteres offensichtlich wichtiger ist, ist Letzteres wahrscheinlicher, dass dein Schlachtschiff untergeht:

Direkte Kosten

Die meisten sind sich der direkten Kosten bewusst - wenn du etwas Teures haben willst, musst du in der Regel Geld ausgeben und es gut begründen. Als die Zinssätze nahe Null waren und das Risikokapital wie der Rio Grande floss, haben viele die Kosten für Dinge wie Cloud Computing, Speicherung und DataOps übersehen. Effizienz beginnt mit dem Entwurf von Mustern. Schlechte Muster bedeuten geringe Effizienz in der gesamten Organisation.

Ein ETL-System mit geringer Wartungsfreundlichkeit verursacht hohe direkte Kosten in Form von ineffizienten Abläufen und langen Laufzeiten. Dies führt nicht nur zu einer hohen Rechnung des Anbieters deiner Wahl, sondern auch zu langsamen Aufträgen und verzögerten Daten deines Teams.

Indirekte Kosten

Indirekte Kosten können die direkten Kosten bei weitem übersteigen. Wenn du Systeme entwickelst, die häufig fehlschlagen und ständig überprüft werden müssen, kann sich das negativ auf die Ressourcenverteilung auswirken. Die Zeit und Energie deines Teams sind die wertvollsten Güter, die du hast.

Wenn du den Großteil deiner Arbeitszeit damit verbringst, DAGs zu reparieren, auf Alarme zu reagieren und Brände zu bekämpfen, mag das zwar fleißig aussehen, aber in der Regel ist es nicht nachhaltig und unproduktiv. Teams, die gewinnen, bauen effiziente Systeme auf, die es ihnen ermöglichen, sich auf die Entwicklung von Funktionen und die Demokratisierung von Daten zu konzentrieren. Ineffiziente Systeme bedeuten mehr Brandschutzübungen, mehr schlaflose Nächte und weniger Stunden, die damit verbracht werden, Dinge zu entwickeln, die wichtig sind.

Das Hauptargument für SaaS ist, dass der Nutzen die Kosten überwiegt, nämlich die Kosten für die Entwicklung und Wartung von Inhouse-Lösungen. Wenn du in einem Team mit begrenzten Ressourcen oder Erfahrungen arbeitest, ist die Lösung, die du kaufst, vielleicht die wartungsfreundlichste.

Natürlich haben diese Ausfälle nicht nur Auswirkungen auf die Dateningenieure, sondern auch auf die nachgelagerten Bereiche. Das bedeutet einen Vertrauensverlust bei den Stakeholdern, Umsatzeinbußen bei den Kunden und sogar einen Verlust des Ansehens in der Öffentlichkeit. Die indirekten Kosten eines Datenausfalls, vor allem, wenn dabei personenbezogene Daten preisgegeben werden, können katastrophal sein.

Warum sollte man sich also auf die Wartbarkeit konzentrieren? Erfolgreiche Teams bauen auf wartbaren Systemen auf.

Wenn es dein Ziel ist, dein Unternehmen mit zeitnahen, effizienten Daten voranzubringen, musst du Probleme und Fehlerbehebungen minimieren und die direkten und indirekten Kosten des Betriebs senken. Im weiteren Verlauf dieses Kapitels werden wir genau besprechen, wie du das durch Beobachtbarkeit, Datenqualität, Fehlerbehandlung und verbesserte Arbeitsabläufe erreichen kannst.

Überwachung und Benchmarking

Hier unterscheiden wir zwischen Beobachtbarkeit und Überwachung/Benchmarking. Das Benchmarking und die Überwachung von Systemen sind wichtig - ein Teilbereich der Beobachtbarkeit. Aber bei der Beobachtbarkeit geht es nicht nur um Fehlerbehebung und Wartung. Die Überwachung und das Benchmarking unserer Systeme sind notwendig, um Probleme in der Pipeline zu minimieren und die Fehlerbehebung zu beschleunigen.

Engmaschig überwachte und ordentlich geprüfte Systeme sind sehr schön "beobachtbar" und machen es einfacher, die Wartbarkeit unserer Datensysteme zu verbessern und die Kosten zu senken, die mit fehlerhaften Daten verbunden sind. Ohne angemessene Überwachung und Alarmierung weiß dein Team vielleicht nicht einmal, dass etwas schief gelaufen ist! Das Letzte, was wir wollen, ist, dass die Stakeholder diejenigen sind, die einen Datenfehler entdecken... oder noch schlimmer, dass der Fehler unentdeckt bleibt und zu schlechten Geschäftsentscheidungen führt.

Wir sollten die Daten während der Aufnahme, Umwandlung und Speicherung beobachten, Fehler behandeln, sobald sie auftreten (möglichst elegant) und das Team alarmieren, wenn etwas nicht funktioniert.

Die Beobachtbarkeit ist aber nicht nur für die Fehlersuche wichtig. Sie hilft uns auch bei der Skalierung, wie wir in Kapitel 5 besprechen werden.

Metriken

Hier sind einige wichtige Kennzahlen, mit denen die Zuverlässigkeit und Nützlichkeit von Daten in einer Organisation bewertet werden kann. Diese Kennzahlen tragen dazu bei, dass die gesammelten und verarbeiteten Daten bestimmten Standards entsprechen und ihren Zweck effektiv erfüllen:

Frische

Freshness bezieht sich auf die Aktualität und Relevanz von Daten in einem System. Sie ist das Maß dafür, wie aktuell die Daten im Vergleich zu den realen Ereignissen sind, die sie darstellen. Die Aufrechterhaltung der Datenfrische ist entscheidend dafür, dass Analysen, Entscheidungsfindung und andere datengesteuerte Prozesse auf genauen und aktuellen Informationen basieren. Dateningenieure entwerfen und implementieren Systeme, die die Latenzzeit bei Datenaktualisierungen minimieren und so sicherstellen, dass alle Beteiligten für ihre Analysen und Tätigkeiten auf die aktuellsten Daten zugreifen können.

Zu den gängigen Freshness-Metriken für einen Datensatz gehören:

• Die Länge zwischen dem jüngsten Zeitstempel (in deinen Daten) und dem aktuellen Zeitstempel

• Der Abstand zwischen den Quelldaten und deinem Datensatz

• Die Aktualisierungsrate, z. B. pro Minute, stündlich, täglich

• Latenz (die Gesamtzeit zwischen der Erfassung der Daten und ihrer Bereitstellung)

Band

Das Volumen bezieht sich auf die schiere Menge an Daten, die in einem System verarbeitet, gespeichert und verwaltet werden müssen. Das ist ein grundlegender Aspekt der Datenverarbeitung. Der Umgang mit großen Datenmengen bringt Herausforderungen mit sich, wie z. B. eine effiziente Speicherung, ein schnelles Abrufen und eine hohe Verarbeitungsgeschwindigkeit. Große Datenmengen erfordern eine spezielle Infrastruktur und Techniken wie verteiltes Rechnen, Parallelverarbeitung und Datenkompression.

Zu den Volumenmetriken gehören:

• Die Größe eines Data Lake (Gigabytes, Terabytes, Petabytes)

• Die Anzahl der Zeilen in einer Datenbank

• Das Volumen der täglichen Transaktionen in einem System

Qualität

Bei der Qualität geht es darum sicherzustellen, dass die Daten während ihres gesamten Lebenszyklus korrekt, konsistent und zuverlässig sind. Bei der Datenqualität geht es um Genauigkeit, Konsistenz, Zuverlässigkeit, Aktualität, Vollständigkeit, Sicherheit, Dokumentation und Überwachung. Die Berücksichtigung dieser Aspekte garantiert qualitativ hochwertige Daten für eine fundierte Entscheidungsfindung und Analyse.

Hier sind einige Beispiele für Datenqualitätskennzahlen:

• Einzigartigkeit: Gibt es doppelte Zeilen in deinem Datensatz?

• Vollständigkeit: Wie viele Nullen gibt es? Werden sie erwartet?

• Gültigkeit: Sind die Daten einheitlich formatiert? Liegen sie im richtigen Bereich, z.B. größer als Null?

Methoden

Überwachung bedeutet, dass du alles, was in deinem Stack passiert, sehen und Fehler rechtzeitig erkennen kannst. Datenqualität bedeutet, strenge Maßnahmen zu ergreifen, um die Qualität der beobachteten Daten zu verbessern.

Im Folgenden findest du Muster und Techniken, die du anwenden kannst, um die Qualität der von dir überwachten Daten direkt zu verbessern, was hoffentlich zu weniger Fehlern und weniger Ausfallzeiten führt:

Protokollierung und Überwachung

Der erste Schritt zur Fehlersuche ist die Überprüfung der Logs. Aber um die Logs zu prüfen, muss es auch Logs geben, die man prüfen kann! Achte darauf, dass deine Systeme die Daten ausführlich protokollieren. Für Systeme, die du entwickelst, solltest du die Protokollierung zur Pflicht machen. Definiere und kodifiziere bewährte Methoden für die Protokollierung, einschließlich der Bibliotheken und der zu protokollierenden Daten . Du musst nicht nur ein hervorragender Datenklempner sein, sondern auch ein Datenholzfäller, ein Begriff, den wir für viel schmeichelhafter halten.

Abstammung

Das einfache Konzept der Lineage - der Weg, den die Daten durch ihren Lebenszyklus zurücklegen - ist eine der wichtigsten Methoden, um deine Daten zu beobachten. Eine visuelle und codierte Darstellung deiner Pipelines und Systeme ist wichtig für den täglichen Betrieb und spart dir unendlich viel Zeit bei der Fehlersuche und -behebung.

Damit der Stammbaum nützlich ist, muss er sowohl vollständig als auch granular sein. Vollständig in dem Sinne, dass alle Systeme beobachtet werden, einschließlich der Verflechtungen zwischen den Systemen. Im Idealfall ist dein Stammbaum auf der granularsten Ebene, die möglich ist. Bei tabellarischen Daten ist das die Spaltenebene. Metadaten auf Spaltenebene geben den detailliertesten Einblick, der möglich ist. Sie erleichtern dem Team die Fehlersuche, vereinfachen die Arbeitsabläufe und verbessern die Produktivität... und die Erfahrung bei der Arbeit mit Daten. Wie in Abbildung 4-1 zu sehen ist, beginnen Lineage-Übungen mit der Spalte.

Abbildung 4-1. Eine erste grundsätzliche Bewertung der Datenherkunft zeigt die Komplexität der Abstammung

Ein guter Anfang ist die Implementierung von Systemen mit in sich geschlossenen Lineage-Lösungen. Ein umfassenderes Lineage-System könnte alle deine Datenprozesse überwachen. Verwaltete Plattformen sind dafür gut geeignet, da sie in der Regel in sich geschlossen sind. Andere Tools, wie Monte Carlo, können Einblicke in den gesamten Stack geben.

Erkennung von Anomalien

Das Schwierigste an Daten ist, dass man sie nicht alle sehen kann. Die meisten unserer Fehler entstehen dadurch, dass Stakeholder oder Analysten unerwartete Ergebnisse zurückgeben.

Die Erkennung von Anomalien ist eine Möglichkeit, um zu wissen, dass es innerhalb eines bestimmten Schwellenwerts keine anomalen Daten gibt. Systeme zur Erkennung von Anomalien arbeiten mit grundlegenden statistischen Vorhersagen, um Zeitreihendaten zu analysieren und Daten zurückzugeben, die außerhalb eines Vertrauensintervalls liegen.

Die Erkennung von Anomalien kann eine großartige Möglichkeit sein, um Fehler zu erkennen, die außerhalb deiner Systeme entstehen - zum Beispiel, wenn ein Team für die Zahlungsabwicklung einen Fehler einführt, der dazu führt, dass Käufe in Europa zu wenig gemeldet werden. Es wird kein Alarm ausgelöst, aber ein Anomalieerkennungssystem, das auf den richtigen Tisch gerichtet ist, wird den Fehler erkennen.

Datenunterschiede

Die Datenentwicklung enthält eine zusätzliche Dimension, die die Softwareentwicklung nicht hat: die Datenqualität. Wenn du den Code änderst, ändert sich die Ausgabe auf eine Art und Weise, die schwer zu verstehen sein kann. Was ist das Schwierigste an Daten?

Data Diffs sind Systeme, die über die Datenänderungen berichten, die durch Änderungen im Code entstehen. Diese Tools informieren über Zeilen- und Spaltenänderungen, die Anzahl der Primärschlüssel und weitere spezifische Auswirkungen. Ihr Hauptzweck ist es, sicherzustellen, dass genaue Systeme genau bleiben.

Für Lösungen zur Datendiffusion empfehlen wir Tools wie Datafold. Neuere SQL-Orchestratoren wie SQLMesh verfügen ebenfalls über Datenverteilungsfunktionen. Data Diffing ist eng mit CI/CD verknüpft und wird durch Assertions und Tests gut unterstützt. Wir werden alle diese Funktionen in Kürze besprechen.

Behauptungen

Assertions sind Einschränkungen, die auf Datenausgaben angewendet werden, um die Quelldaten zu überprüfen. Im Gegensatz zur Anomalieerkennung sind Assertions viel einfacher. Du könntest zum Beispiel sagen: "Bestätige, dass users.purchases nur Preise aus der Tabelle plans.pricing enthält." Wenn ein Wert, der in der Preistabelle nicht vorhanden ist, in den Einkäufen auftaucht, weißt du, dass entweder(a) ein neuer Preis eingeführt wurde oder(b) ein Fehler in deinem System vorliegt.

Auch wenn es sich dabei um eine manuelle Aufgabe handelt (Behauptungen erfordern einen gewissen geschäftlichen Kontext und ein Verständnis dafür, was sein sollte), sind Behauptungen eine der wenigen Möglichkeiten, wie wir sicher sein können, dass die Daten nicht fehlerhaft sind (zumindest in der von uns angegebenen Weise). Wenn du Lösungen für Assertions suchst, schau dir Bibliotheken wie Great Expectations an oder halte nach Systemen Ausschau, die die Möglichkeit haben, Assertions zu definieren.

Fehler

Nachdem wir nun über die Beobachtung und Vermeidung von Fehlern gesprochen haben, kommen wir zu der einfachen Wahrheit. Egal, wie robust deine Lösung ist, es wird immer Fehler geben! Daher ist der Umgang mit Fehlern unglaublich wichtig, sowohl für deinen Verstand als auch für den deines Teams.

Neben dem Umgang mit Fehlern ist es wichtig, sich von ihren Auswirkungen zu erholen, egal ob es sich um verlorene Daten oder Ausfallzeiten handelt. Ein wichtiger Teil der Wiederherstellung sind Rückblicke, Postmortems und Überlegungen, wie ähnliche Fehler in Zukunft vermieden werden können.

Fehlerbehandlung

Bei der Fehlerbehandlung geht es darum, wie wir Fehlerreaktionen oder Grenzbedingungen automatisieren, um entweder unsere Datensysteme am Laufen zu halten oder unser Team rechtzeitig und diskret zu alarmieren. Die folgenden Ansätze beschreiben einige Methoden, um Fehler elegant und effizient zu behandeln:

Bedingte Logik

Beim Aufbau deiner Datenpipelines kann die bedingte Logik bei unzuverlässigen oder inkonsistenten Quellen nützlich sein. Die Möglichkeit zu sagen: "Wenn X dann A, sonst wenn Y dann B", fügt deinem Orchestrierungs- und Transformations-Tooling eine leistungsstarke Komponente hinzu. Halte Ausschau nach Lösungen, die bedingte Logik ermöglichen.

Wiederholungsmechanismen

Systeme, selbst gut gebaute, schlagen fehl. Unvorhergesehene Fehler können zu einmaligen API-Zeitüberschreitungen oder anderen Merkwürdigkeiten führen. Aus diesem Grund kann auch gut funktionierender Code Fehler produzieren. Eine Wiederholungslogik ist in jedem Orchestrierungswerkzeug wichtig. Damit diese funktioniert, müssen natürlich sinnvolle Wiederholungseinstellungen konfiguriert werden. Achte darauf, dass du eine Wiederholungsstrategie einbaust, die mit Datenunregelmäßigkeiten umgehen kann, die aber nicht verschwenderisch ist und nicht zu endlosen Durchläufen führt.

Zerlegung der Pipeline

Wir haben das Konzept der Modularität bereits in Kapitel 3 erwähnt, aber die Aufteilung von Pipelines in "Microservices" ist eine effektive Methode, um die Auswirkungen von Fehlern einzudämmen. Erwäge den Aufbau von DAGs und Systemen, die nur die absolut notwendigen Tabellen und Verbindungen benötigen.

Graceful Degradation und Fehlerisolierung

Die Isolierung von Fehlern wird durch die Zerlegung von Pipelines ermöglicht - wann immer möglich, sollten Systeme so konzipiert sein, dass sie nicht fehlschlagen. Du würdest zum Beispiel nicht wollen, dass deine Produktnutzungsdaten einer Finanzberichterstattungs-Pipeline vorgelagert sind, denn sonst könnte es passieren, dass dein CFO aufgrund eines unvorhergesehenen Fehlers verspätete Zahlen an den Vorstand übermittelt - eine Situation, die für niemanden gut ausgehen würde.

Graceful Degradation ist die Fähigkeit, eine begrenzte Funktionalität beizubehalten, auch wenn ein Teil des Systems fehlschlägt. Indem wir Fehler isolieren und Pipelines zerlegen, ermöglichen wir Graceful Degradation. Es kann sein, dass du einen Fehler erlebst, den nur ein Teil des Unternehmens bemerkt, weil der Rest deiner Systeme so gut funktioniert. Glaub uns, das ist viel besser als Fehler, die jeder bemerkt.

Alerting

Die Alarmierung sollte die letzte Verteidigungslinie sein - der Empfang von Alarmen ist zwangsläufig reaktiv. Wir sehen, dass etwas Schlimmes passiert ist und lassen alles stehen und liegen, um es zu beheben. Auch wenn es am besten ist, häufige Fehler proaktiv zu beheben, wird sich das Unerwartete irgendwann durchsetzen. Warnungen können in Form einer E-Mail oder einer Slack-Nachricht eingehen - wir bevorzugen Slack, da es gut sichtbar ist und die Teammitglieder Kommentare mit hilfreichem Kontext hinzufügen können.

Achte bei der Alarmierung auf die Alarmierungsmüdigkeit. Alarmmüdigkeit bedeutet, dass eine überwältigende Anzahl von Benachrichtigungen die Bedeutung zukünftiger Alarme schmälert. Die Isolierung von Fehlern und der Aufbau von Systemen, die sich langsam abbauen, können zusammen mit durchdachten Benachrichtigungen ein wirksames Mittel sein, um die Alarmmüdigkeit zu verringern und deinem Team eine gute Entwicklererfahrung zu bieten.

Erholung

Wir haben jetzt also Einblick in unsere Systeme, wir setzen aktiv Qualitätsbeschränkungen durch und wir haben spezielle Methoden für den Umgang mit Fehlern. Der letzte Teil ist der Aufbau von Systemen zur Wiederherstellung nach Katastrophen, zu denen auch Datenverluste gehören können. Im Folgenden findest du einige Methoden und Konzepte, die dir helfen werden, nach einem unvermeidlichen Ausfall wieder auf die Beine zu kommen:

Inszenierung

Wir haben das Staging schon oft erwähnt, aber ein weiterer Vorteil von Stagedaten ist die Wiederherstellung im Notfall. Mit Parquet-basierten Formaten wie Delta Lake und Mustern wie der Medaillon-Architektur ist es möglich, Daten durch Zeitreisen wiederherzustellen (bis zu einem bestimmten Punkt). Obwohl Staged Data als kurzlebig betrachtet werden sollte, ist es ein wichtiges Muster für Redundanz.

Verfüllung

Es ist wahrscheinlich, dass du entweder(a) Daten aus einem Zeitraum vor dem Start deiner Pipeline benötigst oder(b) Daten verloren hast, die nachgefüllt werden müssen. Beim Backfilling werden historische Durchläufe einer Pipeline simuliert, um einen vollständigen Datensatz zu erstellen. Airflow verfügt zum Beispiel über einen Backfill-Befehl, der eine Pipeline für jedes Datum zwischen zwei Daten ausführt.

Wenn du Systeme baust, solltest du an die Verfüllung denken. Systeme, die einfach zu befüllen sind, sparen dir eine Menge Zeit, wenn etwas kaputt geht. Suche nach Tools, die einfache Backfills unterstützen, denn die Backfill-Logik kann sehr schnell sehr komplex werden. Idempotente Pipelines machen dir das Leben ebenfalls leichter. Überprüfe, ob der Orchestrator deiner Wahl Backfill-Funktionen bietet, die sofort einsatzbereit sind.

Verbesserung der Arbeitsabläufe

So sehr wir uns auch wünschen, dass die Verbesserung von Prozessen allein in unserer Hand läge, so ist es doch nicht. Unser Job ist von Natur aus kollaborativ - wir sind die sprichwörtlichen "Klempner", die den Stakeholdern Leitungen für interne und externe Daten zur Verfügung stellen. Das macht unsere Arbeit von Natur aus kollaborativ.

Wir haben es kurz erwähnt, aber bei der Datentechnik geht es wirklich darum, wann etwas kaputt geht, nicht ob. Selbst bei den besten Systemen treten Anomalien auf, es passieren Fehler und die Dinge fallen auseinander. Die Titanic ist nicht umsonst eine Lektion, oder?

Der entscheidende Faktor ist deine Fähigkeit, dich anzupassen und Probleme zu lösen... und genau darum geht es in diesem Kapitel! Wenn du mit einem System beginnst, das Fehlerbehebung, Anpassungsfähigkeit und Wiederherstellung in den Vordergrund stellt, kannst du dir spätere Kopfschmerzen ersparen. In diesem Abschnitt stellen wir dir einige Möglichkeiten vor, wie du deine Prozesse kontinuierlich verbessern kannst.

Mit Beziehungen beginnen

Nehmen wir folgendes Beispiel: Dein Software-Team ändert halbjährlich ein Produktionsschema ohne Vorwarnung. Dadurch wird nicht nur dein täglicher ETL-Job aus dem Prod-Datensatz unterbrochen, sondern es besteht auch die Gefahr, dass Daten verloren gehen, da deine Exportmethode keine CDC hat.

Verständlicherweise ist dein Team dann ziemlich frustriert. Du verlierst nicht nur Zeit und Ressourcen, indem du diese Probleme behebst, sondern sie scheinen auch völlig vermeidbar zu sein. Bevor du harsch reagierst, solltest du dir die Frage stellen: " Versucht das Softwareteam, die Gesamtproduktivität zu verringern und schlechtere Ergebnisse zu erzielen?" Wenn die Antwort ja lautet, empfehlen wir eine Stellensuche, aber in 99,999% der Fälle wird die Antwort "Nein, natürlich nicht" lauten.

Wenn du dich fragst, was genau dieses Team erreichen will, ist es wahrscheinlich dasselbe wie du - die bestmögliche Arbeit mit den vorhandenen Ressourcen zu leisten. Toll, jetzt kannst du ihre Beweggründe nachempfinden.

Als Nächstes musst du ihre Arbeitsabläufe verstehen und deine Frustrationen mitteilen. Von dort aus könnt ihr einen Prozess zur Verbesserung der Effizienz entwickeln. Hier sind einige Möglichkeiten, wie du durch einen strukturierten, pragmatischen Ansatz gesunde Beziehungen sicherstellen kannst:

SLAs

Service-Level-Agreements (SLAs) sind bei Providern üblich, um Laufzeit- und Betriebsgarantien zu geben, aber sie können genauso effektiv innerhalb und zwischen Teams eingesetzt werden. Wenn du Probleme mit der Datenqualität hast, solltest du eine SLA in Erwägung ziehen, in der Dinge wie Leistungskennzahlen, Verantwortlichkeiten, Reaktions- und Lösungszeiten sowie Eskalationsverfahren formell festgelegt werden, damit jeder weiß, was für die eingehenden Daten erforderlich ist.

Indem du die Anforderungen klar kommunizierst und die Verantwortlichkeiten festlegst, können SLAs ein überraschend effektives Mittel sein, um die Qualität von Daten zu verbessern, die sich deiner Kontrolle entziehen, indem du einfach ein paar Vereinbarungen zu Papier bringst.

Daten Verträge

Datenverträge haben sich in den letzten Jahren als effektive Methode zur Steuerung von Daten aus externen Quellen etabliert. Verträge sind eine Art Assertion, die Metadaten (in der Regel Spaltennamen und -typen) überprüfen, bevor ein Teil oder die gesamte ETL-Pipeline ausgeführt wird.

Wir mögen den Begriff "Vertrag", weil er eine Vereinbarung zwischen zwei Parteien impliziert, wie ein SLA. Wir empfehlen, zunächst ein SLA zu definieren, auch wenn es sich nur um eine Vereinbarung auf dem Papier handelt, und dieses SLA dann in Form von Datenverträgen für externe Ressourcen umzusetzen. Für den Fall, dass ein Vertrag einen Fehler meldet, wird in der SLA genau festgelegt, wer für die Behebung des Fehlers verantwortlich ist und wie schnell dies zu erwarten ist.

APIs

APIs können eine formalere Methode zur Durchsetzung von Verträgen und SLAs sein. In gewisser Weise ist SQL selbst eine API, aber es gibt keinen Grund, warum interne Daten nicht über eine API abgerufen (oder bereitgestellt) werden können. APIs sind nur eine Methode, um einen erwarteten Datensatz zu übermitteln, aber wenn sie richtig implementiert sind, bieten sie eine zusätzliche Ebene der Standardisierung und Konsistenz der Quelle. APIs bieten außerdem eine detailliertere Zugriffskontrolle, Vorteile bei der Skalierbarkeit und Versionskontrolle, was für die Einhaltung von Vorschriften nützlich sein kann.

Mitgefühl und Empathie

Du bist es vielleicht gewohnt, dass diese Begriffe in Texten auftauchen, in denen dbt großgeschrieben wird und sich auf etwas anderes als ein Transformationswerkzeug bezieht, aber sie sind in der Technik genauso wichtig wie in der Psychologie. Wenn du deine Mitarbeiter/innen (und Partner/innen) und ihre Beweggründe, Probleme und Arbeitsabläufe verstehst, kannst du deine Anliegen effektiv vermitteln und an ihre Anreize appellieren.

Im digitalen Zeitalter ist es viel zu leicht, eine feindselige Haltung einzunehmen oder böse Absichten zu unterstellen, vor allem bei vagen Videomeetings und knappen Textfetzen. Wir plädieren dafür, die Extrameile zu gehen, um deine Kolleginnen und Kollegen zu verstehen, sei es durch persönliche Gespräche, lange schriftliche Kommunikation oder persönliche Treffen, wenn möglich.

Anreize ausrichten

Um sinnvollen Fortschritt zu fördern, müssen wir Anreize und Ergebnisse aufeinander abstimmen.¹ Wenn der einzige Auftrag deines Teams darin besteht, "viel zu bauen", wird nur wenig Zeit darauf verwendet, diese Dinge widerstandsfähig und robust zu machen. Die Festlegung von Leistungsindikatoren (Key Performance Indicators, KPIs) rund um die gängigen Kennzahlen für das Incident Management kann helfen, die Zeit und Energie zu rechtfertigen, die nötig sind, um die Arbeit richtig zu machen:

Anzahl der Vorfälle (N)

Wenn du die Anzahl der Vorfälle über einen bestimmten Zeitraum zählst, erhältst du einen Überblick über die Häufigkeit von falschen, unvollständigen oder fehlenden Daten.

Zeit bis zur Entdeckung (TTD)

Die TTD beschreibt die durchschnittliche Zeit, die es dauert, bis ein Vorfall entdeckt wird.

Zeit bis zur Auflösung (TTR)

Diese Kennzahl misst, wie schnell deine Systeme nach einer Störung den normalen Betrieb wieder aufnehmen können. Sie ist ein direktes Maß für die Widerstandsfähigkeit und Wiederherstellungsfähigkeit deines Systems.

Datenausfallzeit (N × [TTD + TTR])

Anhand der drei oben genannten Messgrößen können wir eine durchschnittliche "Datenausfallzeit" ermitteln. Diese zusammenfassende Kennzahl kann dir helfen, den Schweregrad deiner Ausfälle und den Zustand deiner Systeme zu verstehen.

Kosten

Aus den Ausfallzeiten kannst du die Kosten für diese Ausfälle berechnen. Die Kosten sind sehr spezifisch für dein Team und deine Organisation. Wir empfehlen eine maßgeschneiderte Kostenberechnung, die die Besonderheiten deines Einsatzes berücksichtigt.

Ergebnisse verbessern

Thomas Edisons berühmtes Zitat: "Ich bin nicht gescheitert, ich habe nur 10.000 Wege gefunden, die nicht funktionieren", trifft auf den Aufbau außergewöhnlicher Datenpipelines und der sie unterstützenden Systeme sehr gut zu. Der Weg zu Spitzenleistungen in diesem Bereich ist gekennzeichnet durch eine Reihe von Vermutungen, Experimenten und vor allem durch die Fähigkeit, sich anzupassen und den Kurs zu korrigieren, wenn es Herausforderungen gibt.

Wenn du uns bis hierher gefolgt bist, weißt du, dass großartige Systeme auf großartigen Frameworks aufbauen. Hier sind ein paar Möglichkeiten, wie du deine Prozesse nach Fehlschlägen verbessern und deine guten Pipelines anpassen kannst, um sie großartig zu machen:

Dokumentation

Wenn deine Daten aufbereitet sind und zurückgespielt werden können, musst du nur noch wissen, wie du sie reparieren kannst! Sei mühsam und pedantisch, wenn es darum geht, deine Systemprozesse und deinen Code zu dokumentieren. Es mag sich zwar wie eine lästige Pflicht anfühlen, aber wir können dir garantieren, dass es weniger zeitaufwändig (und stressig!) ist, als wenn du deinen Code im Falle eines Fehlers überarbeiten musst.

Postmortale

Bei großen Ereignissen oder Ausfällen kann ein Postmortem wertvoll sein, um den Ausfall zu analysieren. Bei einem Postmortem wird darüber nachgedacht, was schief gelaufen ist, und es wird eine Analyse durchgeführt, um zu verstehen, warum. Postmortem und Reflexion im Allgemeinen sind hervorragende Möglichkeiten, um zu lernen, sich weiterzubilden und zu wachsen. Im Idealfall führen deine Postmortems zu weniger Ereignissen, die eine Wiederherstellung überhaupt erst erforderlich machen.

Einheitstests

Beim Unit-Testing werden kleine Teile des Codes (die Komponenten eines Systems) validiert, um sicherzustellen, dass sie die erwarteten Ergebnisse liefern. Wie jedes andere technische System sollte auch der Code in einem Datenverarbeitungssystem einem Unit-Test unterzogen werden. Das bedeutet, dass jeder benutzerdefinierte Code oder jedes maßgeschneiderte System, das du erstellst, getestet werden sollte, um sicherzustellen, dass es die gewünschten Ergebnisse liefert.

Sie unterscheiden sich deutlich von Assertions, da Unit-Tests den zugrunde liegenden Code und nicht die Ausgabedaten überprüfen. Der Einbau von Unit-Tests in deinen Code ist eine hervorragende Präventivmaßnahme, um zukünftige Fehler zu minimieren.

Während viele Plattformen langsam Unit-Tests/Assertions einführen, gibt es eine überraschende Anzahl von Datenteams, die ohne sie arbeiten. Wir plädieren für ihre Einführung in jedem Datensystem.

CI/CD

Continuous Integration/Continuous Deployment (CI/CD) ist ein Begriff, der sich auf die Art und Weise bezieht, wie du deinen Code integrierst und bereitstellst, d.h. wie Änderungen (z.B. Pull Requests) in deine Codebasis aufgenommen, getestet und ausgerollt werden.

In der Praxis kann CI/CD für Data Engineering viele Dinge beinhalten, die wir bereits besprochen haben, aber auch ein paar Dinge, die wir nicht besprochen haben. Unit-Tests, Assertions, Linting und Daten-Diffs sorgen für eine konsistente Codebasis, die gut funktioniert und es dir ermöglicht, nahtlos mit anderen zusammenzuarbeiten, um etwas Großartiges (in großem Maßstab) zu entwickeln.

Vereinfachung und Abstraktion

Als Ingenieur solltest du versuchen, so viel komplexe Logik wie möglich aus deinem Code herauszuholen und zu vereinfachen. Das macht nicht nur die Zusammenarbeit einfacher, sondern verringert auch die Wahrscheinlichkeit, dass du Fehler machst.

Wenn du einen Code schreibst, überlege dir: "Wenn ich mir das sechs Monate lang nicht ansehe, wie schwer wird es dann für mich sein, ihn zu verstehen?" Wenn in sechs Monaten etwas kaputt geht, wirst du wahrscheinlich unter Druck stehen, also denke daran.

Datensysteme als Code

Data Diffs stoßen auf ein Konzept, das wir bisher noch nicht besprochen haben: die Erstellung von Datensystemen als Code. Indem jedes System versioniert und kodifiziert wird, ist es möglich, Änderungen rückgängig zu machen und zu früheren Zuständen zurückzukehren. In gewisser Weise können wir mit Staging-Systemen mit Medaillon-Architektur etwas Ähnliches mit Zeitreisen machen.

Wenn du deine Datensysteme nach bewährten Methoden der Softwareentwicklung aufbaust und die Logik in Form von versionskontrolliertem Code implementierst, kannst du deine Beobachtbarkeit, Disaster Recovery und Zusammenarbeit drastisch verbessern. Sei vorsichtig mit Werkzeugen, die nur schwer oder gar nicht versioniert oder anderweitig durch Code manipuliert werden können, selbst wenn es sich nur um JSON- oder YAML-Konfigurationen handelt.

Wenn du die Verantwortlichkeiten festgelegt, Anreize geschaffen und ein komplettes Toolkit zur Überwachung und Fehlerbehebung entwickelt hast, kannst du mit der Automatisierung und Optimierung deiner Daten-Workflows beginnen. Da einige Aufgaben nicht automatisiert werden können und es immer Kanten geben wird, besteht die Kunst der Datentechnik darin, ein Gleichgewicht zwischen Automatisierung und Praktikabilität herzustellen. Mit robusten, widerstandsfähigen Systemen sind wir jetzt bereit, zu skalieren.

¹ Dieser Abschnitt stammt aus dem Monte-Carlo-Leitfaden von Barr Moses, "12 Data Quality Metrics That ACTUALLY Matter".