Verbesserung der Datenqualität: Erkundung von Datenverträgen mit Lyft

Sieht so aus, als wäre es Teil 2 meiner Serie zum Thema Datenqualität!

In einem früheren Beitrag habe ich die Strategie von Airbnb zur Verbesserung der Datenqualität durch Anreize untersucht. Sie implementierten eine einzige Bewertung und klare Bewertungskriterien, um ein gemeinsames Verständnis zwischen Datenproduzenten und -konsumenten zu schaffen und ein echtes Gefühl der Eigenverantwortung zu fördern.

Jetzt verfolgt Lyft einen ganz eigenen Ansatz und versucht nicht dasselbe auf unterschiedliche Weise, sondern konzentriert sich vielmehr auf unterschiedliche Aspekte der Datenqualität. Und die Strategie von Lyft ergänzt die Bemühungen von Airbnb. Während ich den DQ-Score von Airbnb (oder einen ähnlichen Score) als wirksames Mittel zur Konsolidierung verschiedener Versuche zur Verbesserung der Datenqualität betrachte, geht Lyft diese Herausforderung aus einem anderen Blickwinkel an.

Der DQ-Score von Airbnb dient als wertvolles Instrument zur konkreten Visualisierung der Datenqualität. Im Wesentlichen sollte jede Initiative zur Verbesserung der Datenqualität einen erkennbaren Einfluss auf diesen Wert haben. Andererseits stellt Lyft eine mögliche Initiative zur proaktiven Verbesserung der Qualität vor, indem Daten anhand spezifischer Qualitätskriterien getestet und validiert werden.

Grundsätzlich handelt es sich um einen anderen Punkt im Lebenszyklus der Datenqualität. Die Einführung eines Mechanismus zur Qualitätsverbesserung erfordert zunächst die Fähigkeit, diese zu messen.

Während der Schwerpunkt von Airbnb auf der Messung und Beobachtung der Datenqualität liegt und man sich dabei auf das Interesse des Herstellers verlässt, diese Qualität zu verbessern und „gut auszusehen“, verfolgt Lyft einen anderen Ansatz. Lyft legt Wert auf das aktive Testen und Validieren der Datenqualität und bietet sowohl Produzenten als auch Verbrauchern die Möglichkeit, die Qualität effektiv zu verbessern und zu kontrollieren.

Zusammengenommen stellen diese Ansätze eine umfassende Strategie zur Bewältigung und Verbesserung der Datenqualität während ihres gesamten Lebenszyklus dar.

Aus diesem Grund war es für mich besonders interessant, den Ansatz von Lyft genauer unter die Lupe zu nehmen.

Ein weiterer Faktor, der mich faszinierte, ist das Testen, genauer gesagt das Vertragstesten, das seit vielen Jahren mit dem Aufkommen der Microservice-Architektur in der grundlegenden Softwareentwicklung eingesetzt wird. Datenverträge sind jedoch etwas Neueres im Bereich der Datentechnik und gelten als Höhepunkt oder einer der ultimativen Schritte auf dem Weg zum Aufbau hochwertiger Datenpipelines. Aus diesem Grund wollte ich den Ansatz von Lyft genauer untersuchen und einige mögliche Parallelen untersuchen.

Wie bereits erwähnt, ergänzen sich die Ansätze von Airbnb und Lyft und zielen auf dasselbe Ziel ab: die Verbesserung der Datenqualität.

Airbnb hat den DQ-Score entwickelt, der sich auf die Messung und Verbesserung von vier verschiedenen Aspekten der Datenqualität konzentriert:

DQ Score hat Leitprinzipien, darunter vollständige Abdeckung, Automatisierung, Umsetzbarkeit, Mehrdimensionalität und Entwickelbarkeit. Es umfasst Dimensionen wie Genauigkeit, Zuverlässigkeit, Verwaltung und Benutzerfreundlichkeit.

Verity von Lyft ist eine Plattform zur Verbesserung der Datenqualität in fünf Dimensionen

Definiert Datenqualität als Maß dafür, wie gut Daten bestimmungsgemäß verwendet werden können, und deckt Aspekte wie semantische Korrektheit, Konsistenz, Vollständigkeit, Einzigartigkeit, Wohlgeformtheit und Aktualität ab.

Es ist leicht, Parallelen zwischen den fünf durch Lyfts Verity verbesserten Datenqualitätsaspekten und den vier durch den DQ-Score von Airbnb gemessenen Datenqualitätsdimensionen zu ziehen. Beispielsweise würden Aspekte wie Aktualität sicherlich zur Zuverlässigkeit des DQ-Scores beitragen, während Genauigkeit von der semantischen Korrektheit, Vollständigkeit und Einzigartigkeit der Daten abhängen würde. Der Usability-Score hingegen wird unter anderem von der Konsistenz der Daten beeinflusst.

Lyfts Verity konzentriert sich auf die Definition von Prüfungen im Zusammenhang mit semantischer Korrektheit, Konsistenz, Vollständigkeit, Einzigartigkeit, Wohlgeformtheit und Aktualität . Es folgt einem Test-First- und Validierungsansatz, während der einheitliche DQ-Score von Airbnb den Schwerpunkt auf die Bewertung der Datenqualität anhand verschiedener Dimensionen legt.

Wenn wir den DQ-Score in dieses letzte Schema integrieren wollten, wäre dies auf der Seite der Alert-/Debug-Schritte.

Der DQ-Score von Airbnb verwendet verschiedene Signale, um die Datenqualität in Bezug auf die Aspekte Genauigkeit, Zuverlässigkeit, Verwaltung und Benutzerfreundlichkeit zu bewerten.

Wir verfügten auch über eine Reihe von Eingangssignalen, die die Qualität direkter messen (Midas-Zertifizierung, Datenvalidierung, Fehler, SLAs, automatisierte DQ-Prüfungen usw.), während andere eher Stellvertreter für die Qualität waren (z. B. gültiger Besitz, gute Governance-Hygiene, die Verwendung von Werkzeugen für gepflasterte Wege).

Wie bereits erwähnt, gibt es wahrscheinlich Überschneidungen zwischen dem DQ-Score von Airbnb und dem von Verity. Während sich Airbnb darauf konzentriert, die Datenqualität nach rechts zu verschieben und dabei den Schwerpunkt auf Messung und Bewertung legt, verfolgt Verity von Lyft einen proaktiven Ansatz, indem es die Prüfdefinitionskonfigurationen, Tests und Validierungsprozesse nach links verlagert und dabei den Schwerpunkt auf die proaktive Verbesserung der Datenqualität legt.

Nun liegt mein Hauptinteresse auf der linken Seite, nämlich den Prüfdefinitionskonfigurationen, Tests und Validierungsaspekten.

Wie integriert Lyft Datenqualitätstests in seine Prozesse?

Schauen wir uns zunächst die Ausführungspfade an.

Derzeit konzentriert sich Verity von Lyft vor allem auf die Sicherstellung der Qualität der in seinem Hive-Data-Warehouse gespeicherten Daten. Es gibt jedoch Pläne, seine Fähigkeiten zu erweitern, um in Zukunft auch andere Datenquellen zu unterstützen.

Beachten Sie, dass sie Hive zwar als „Data Workhouse“ bezeichnen, es jedoch tatsächlich als hybride Datenspeicherlösung nutzen, die als Data Warehouse für strukturierte, verarbeitete und bereinigte Daten (Silver Layer) fungiert und gleichzeitig als Data Lake für Rohereignisse dient Daten (Bronzeschicht).

Schlechte Datenqualität in Hive führte zu fehlerhaften Experimentiermetriken, ungenauen Funktionen für maschinelles Lernen und fehlerhaften Dashboards für Führungskräfte.

Die Prüfungen von Verity können in einen Airflow DAG integriert werden, um sicherzustellen, dass nur hochwertige Rohdaten verarbeitet und als abgeleitete Daten in Hive gespeichert werden.

Datenproduzenten und -konsumenten können ihre Datenqualitätsprüfungen definieren und die Daten überprüfen, wenn sie erzeugt werden oder bevor sie intern verbraucht werden Luftstrom oder Flyte .

…

Der VerityAirflowOperator kann auf blockierende Weise verwendet werden, um einen DAG bei einem Prüffehler anzuhalten und so zu verhindern, dass fehlerhafte Daten jemals in die Produktion gelangen. Dies nutzt die „ Stage-Check-Exchange „Muster: Wir erstellen Daten in einem abgestuften Schema, überprüfen die Daten mit einem Blockierungsoperator und befördern sie dann in die Produktion, wenn sie die Qualitätsprüfungen bestehen.

Prüfungen können auch manuell durchgeführt oder automatisch geplant werden, um sowohl Rohdaten als auch abgeleitete Daten zu überprüfen.

Verity Scheduled Checks sind von allen Datenorchestrierungs-Engines isoliert, sodass sie auch dann noch ausgeführt werden, wenn Airflow oder Flyte vollständig ausfallen. Dies behebt ein häufiges Problem, bei dem Prüfungen keine Warnungen auslösen, weil die Airflow-Aufgabe nie ausgeführt wurde.

Es gibt also im Wesentlichen drei Möglichkeiten, eine Prüfung auszulösen: als Teil eines Airflow DAG, manuell oder geplant über die Verity-Plattform/Benutzeroberfläche.

Ich glaube nicht, dass aktuelle Prüfungen in Echtzeit-Streaming-Pipelines (wie Flink + Kafka) integriert werden können, um beispielsweise Daten beim Eintritt in Hive (oder sogar früher) zu validieren.

Die Implementierung dieser Art von Echtzeitprüfung würde eine sofortige Erkennung von Unstimmigkeiten ermöglichen, was zu geringeren Speicher- und Verarbeitungskosten und einer allgemeinen Verbesserung der Datenqualität führen würde.

Um es genau zu sagen: Verity-Prüfungen werden über einen API-Server verwaltet, der verwendet werden könnte, um Prüfungen programmgesteuert über einige APIs auszulösen.

Verity API Server – Dieser Dienst verwaltet alle externen APIs bezüglich der Durchführung von Prüfungen sowie der Beibehaltung und dem Abruf ihrer Ergebnisse. Der API-Server führt keine Prüfungen durch, sondern schreibt eine Nachricht in unsere Prüfwarteschlange, die verwendet wird SimpleQueueService (SQS).

Vielleicht könnten Sie diese Jobs also möglicherweise in Echtzeit auslösen, beispielsweise über einen Streaming-Job oder sogar, auf lange Sicht, durch die Integration mit Hive Change Data Capture (CDC).

Wenn diese Jobs jedoch außerhalb von Airflow ausgeführt werden, können sie den Datenverarbeitungsjob nicht blockieren. Stattdessen würden sie asynchrone Warnungen generieren, die an die Prüfwarteschlange weitergeleitet werden. Einige Verbraucher würden es vorziehen, wenn die Datenverarbeitung verzögert würde, wenn eine Prüfung fehlschlägt, während andere lieber fortfahren und eine Benachrichtigung erhalten würden.

Schauen wir uns nun diese Datenqualitätstests an.

Hier ist ein Beispiel, das prüft, ob rider_events.session_id niemals null ist. Dies wird durch eine Kombination aus Abfrage- und Bedingungskomponenten erreicht.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity konzentriert sich in erster Linie auf die Definition und Durchsetzung von Datenqualitätsprüfungen und nicht auf die Definition vollständiger Datenschemata.

Schemavalidierung ist kein neues Konzept. Es gibt mehrere Methoden zum Definieren von Ereignisdatenschemata in ereignisbasierten Systemen, z. B. JSON-Schema, Protokollpuffer, Avro oder Speicherformate wie Parquet. Die optimale Wahl hängt von Ihrem Tech-Stack, Ihrer Nutzung und Ihren spezifischen Anforderungen ab.

Während Datenschemata für die Definition der Gesamtstruktur von Datenobjekten oder Tabellenzeilen nützlich sind, reichen sie nicht aus, um komplexere, verbraucherspezifische Validierungsprüfungen wie Datenverteilung, Geschäftsregeln, SLAs und Schwellenwerte zu erfassen.

Datenverträge gehen über die Schemavalidierung hinaus, die sich auf die Identifizierung syntaktischer Fehler konzentriert. Ich persönlich finde, dass JSON Schema hier eine geeignetere und lesbarere Option bietet und diese strukturellen und syntaktischen Validierungsfunktionen effektiv von Serialisierungs- oder Speicherproblemen trennt.

Um jedoch semantische Fehler zu beheben und die Datengenauigkeit zu verbessern, können mit einem effektiven Mittel zur Definition von Datenprüfungen auch die anderen Aspekte von Datenverträgen definiert werden.

Hier kommt Verity DSL ins Spiel.

Über die semantische Validierung hinaus bieten Datenverträge einen weiteren entscheidenden Aspekt, der Aufmerksamkeit verdient.

Aus syntaktischer Sicht bleiben Validierungsprüfungen unabhängig vom beteiligten Verbraucher oder Produzenten konsistent. Der Satz an Validierungsregeln ist nicht an einen bestimmten Konsumenten oder Produzenten gebunden und kann ein für alle Mal als ein einziges Schema definiert werden.

Der Verity-Datenvertrag DSL bietet jedoch eine feinere Granularität, die kleine unabhängige Regeln definiert, was für diesen Kontext besonders gut geeignet ist: Die semantische Bedeutung und Verwendung der Daten variiert je nach spezifischem Verbraucher. Darüber hinaus müssen nicht alle Verbraucher alle Eigenschaften eines Objekts nutzen. Ihre Erwartungen sind unterschiedlich. Dies bedeutet nicht, dass sie widersprüchlich sind (was sicherlich ein Problem wäre), sondern vielmehr, dass sie sich ergänzen und unterschiedlich sind.

Daher ist es von entscheidender Bedeutung, allen Verbrauchern die Festlegung einzigartiger Regeln zu ermöglichen, die bei gemeinsamer Kombination ein umfassendes Verständnis der semantischen Bedeutung der Datenqualität ermöglichen können.

Und es ist dieser kollaborative Aspekt, der mich besonders berührt. Haben Sie etwas Geduld, das mag etwas weit hergeholt erscheinen, aber aus meiner Sicht ist es erwähnenswert. :) :)

Durch den Datenaustausch können verschiedene Teams (Produzenten und Konsumenten) effektiv zusammenarbeiten. Genau wie bei APIs in der traditionellen Softwareentwicklung ist es von größter Bedeutung, ein gemeinsames Verständnis für diesen Datenaustausch zu schaffen. In Microservice-Architekturen hat sich ein kollaborativer Testansatz herausgebildet, der als Consumer-Driven Contracts (CDC) bekannt ist und bei dem Verbraucher das erwartete Verhalten der von Herstellern bereitgestellten APIs definieren. Die Hersteller sind dafür verantwortlich, diese Verträge zu überprüfen, bevor sie neue Versionen veröffentlichen.

Ich denke, dass bei Datenverträgen ein ähnlicher Geist der Zusammenarbeit herrscht. Auch wenn die Datenvalidierung anhand realer Daten und nicht zum Zeitpunkt der Veröffentlichung erfolgt und Veröffentlichungen nicht blockiert, basiert sie auf Zusammenarbeit und fördert die Teamarbeit zwischen Datenproduzenten und -konsumenten. Ich bin fest davon überzeugt, dass dieser kollaborative Ansatz der Schlüssel zur Verbesserung der Datenqualität ist und weiter in den Prozess integriert werden sollte.

Na ja, ich bin ein großer Fan davon, Parallelen zu ziehen …

Beachten Sie, dass dieser Aspekt der Zusammenarbeit auch Teil der Wahrheitscharta von Lyft ist.

Die VerityUI bietet eine optimierte Datenerkennungserfahrung über die Verity-Homepage. Unsere Volltextsuche in den Metadaten der Prüfdefinition ermöglicht es Benutzern, alle derzeit durchgesetzten Prüfungen und deren Prüfergebnisse anzuzeigen. Dies verfügt über nützliche Aggregationen wie Eigentümerteam, Tabellenname und Tags.

Mir ist nicht ganz klar, wie Datenvertragsfragen zwischen Verbrauchern und Produzenten über die Benutzeroberfläche der Verity-Plattform ausgetauscht werden, aber ich erkenne definitiv die Bedeutung der Zusammenarbeit über die Dashboards:

• Der Hersteller einer Datenproduktschnittstelle kann sicher sein, dass er nicht unbeabsichtigt zu nachgelagerten Störungen führt, mit denen er nicht gerechnet hat.

• Der Benutzer der Schnittstelle kann sicher sein, dass sein Vertrauen in die Schnittstelle nicht beeinträchtigt wird und auch nicht beeinträchtigt wird.

Obwohl Verity ein bemerkenswertes Tool zur Definition von Datenqualitätsprüfungen ist, ist es leider kein Open-Source-Tool.

Glücklicherweise gibt es ein anderes Open-Source-Datenqualitäts-Framework namens Soda Core, das ähnliche Funktionen bietet.

Soda Core ist ein kostenloses Open-Source-Befehlszeilentool und eine Python-Bibliothek, die es Dateningenieuren ermöglicht, die Datenqualität zu testen. Es nutzt benutzerdefinierte Eingaben, um SQL-Abfragen zu generieren, die Datensätze in einer Datenquelle prüfen, um ungültige, fehlende oder unerwartete Daten zu finden. Wenn Prüfungen fehlschlagen, werden die Daten angezeigt, die Sie bei der Prüfung als „schlecht“ definiert haben.

Während eines Scans eines Datensatzes wertet Soda Core die vordefinierten Prüfungen aus, um ungültige, fehlende oder unerwartete Daten zu identifizieren.

Hier ist die entsprechende Prüfung mit der Soda.core-Syntax für den zuvor definierten Verity DSL-Test.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core ist ein leistungsstarkes Tool zur Sicherstellung der Qualität Ihrer Daten. Es kann Ihnen dabei helfen, Datenprobleme frühzeitig zu erkennen und zu beheben, bevor sie zu Problemen für Ihr Unternehmen führen können.

Es ist erwähnenswert, dass Soda Core durch die nahtlose Integration mit Spark DataFrames auch Datenqualitätsprüfungen für Streaming-Daten erleichtern kann.

Während die Datenqualitätsprüfungen von Verity für Hive auf statische Datensätze angewendet werden, müssen die Prüfungen für Streaming-Daten einfacher und effizienter sein.

Daten werden typischerweise in kleinen Ereignisstapeln mit sehr geringer Latenz verarbeitet, wodurch sie sich für Echtzeitprüfungen und spezifische Anwendungsfälle wie die Erkennung von Anomalien eignen.

Abschließend möchten wir noch erwähnen, dass es noch andere Datenvalidierungstools gibt, wie DeeQu, Great Expectations, …

Zum Abschluss hoffe ich, dass Sie ein klareres Verständnis für die Schritte haben, die Sie unternehmen können, um Ihren Weg zur Datenqualität zu verbessern.

Wir haben zwei unterschiedliche Ansätze zur Verbesserung der Datenqualität gesehen, jeder mit seinen eigenen Stärken und Methoden. Einer konzentriert sich auf die Erhöhung der Sichtbarkeit und Beobachtbarkeit und motiviert Datenproduzenten, die Qualitätsmaßstäbe höher zu legen. Die andere Priorität besteht darin, den Qualitätsstandard durch einen Test- und Validierungsansatz zu erhöhen. Beide ergänzen sich.

Verity ist nicht nur eine domänenspezifische Sprache (DSL) zum Definieren von Datenprüfungen; Es handelt sich um eine zentralisierte Plattform, die es Datenexperten ermöglicht, effektiv zusammenzuarbeiten. Diese Plattform hilft Produzenten und Verbrauchern dabei, die Erwartungen an die Datenqualität, einschließlich Format, Struktur und Genauigkeit, aufeinander abzustimmen.

Die Datenvertragsverwaltungsfunktionen von Verity könnten (werden?) durch die Integration mit einer breiteren Palette von Funktionen, wie z. B. Metadatenverwaltung und -erkennung, weiter verbessert, um anspruchsvolleren Anforderungen an die Datenqualität gerecht zu werden.

Ähnlich wie der DQ-Score von Airbnb fördert Verity von Lyft eine kollaborative Feedbackschleife zwischen Datenproduzenten und -konsumenten. Indem Verity jedes Team dazu anregt und befähigt, Verantwortung für die Datenqualität zu übernehmen, schafft es ein unterstützendes Umfeld, in dem sich die Datenqualität kontinuierlich verbessert.

Fanden Sie diesen Artikel nützlich? Folge mir auf Linkedin , Hackernoon , Und Mittel ! Bitte 👏 diesen Artikel, um ihn zu teilen!