Veröffentlicht am 01-05-2019

Principled Data Engineering, Teil II: Data Governance

Der zweite Teil einer zweiteiligen Serie befasst sich mit den grundlegenden Themen der Architektur und Verwaltung eines Datensees.

Der grundlegende Auftrag eines Data Engineers besteht darin, saubere, genaue und sorgfältig überwachte Daten zu liefern. Hierin liegt der Unterschied zwischen einem Daten- und Software-Ingenieur - für letztere ist das Produkt die Software, während für uns unser Produkt die Daten sind und jede von uns erstellte Software den Daten als Hilfsmittel dient. Mit anderen Worten, es liegt in der Verantwortung eines Data Engineers, Daten (und nicht Software) als "erstklassige Entität" zu behandeln. Es versteht sich von selbst, dass Data Governance ein zentrales Thema der Data Engineering ist.

Unsere Branche hat noch keinen Konsens darüber gefunden, was mit Data Governance zu tun hat. Faktoren wie gesetzliche Bestimmungen sowie Art und Umfang der Daten spielen eine wichtige Rolle bei der Festlegung der Art und Weise der Datensteuerung. Allerdings gibt es ein allgemeines Grundthema - das Konzept einer sorgfältigen Beaufsichtigung. Dies kann weiter in drei Hauptpunkte unterteilt werden:

Metadaten-Management - Datenherkunft und Katalogisierung

Die eigentliche Grundlage von Data Governance ist wohl das Metadaten-Management. In diesem Fall beziehen sich Metadaten auf Daten zu Ihren Daten - dazu gehören alle aussagekräftigen Informationen zu Ihren Daten, die Ihnen helfen können, sie besser zu verstehen. Zumindest für jeden Datensatz, den Sie speichern, sollten Ihre Metadaten in der Lage sein, zwei Fragen zu beantworten: Welche Daten befinden sich im Datensatz und woher stammen diese Daten? Die Frage „Was“ wird normalerweise von einem Datenkatalog (manchmal auch als Meta-Store, Metadatenkatalog usw. bezeichnet) beantwortet. Ein Datenkatalog ist normalerweise eine Darstellung des Schemas für eine bestimmte Datenmenge. Dies kann Informationen zu Bezeichnungen (Spaltennamen, Schlüssel usw.), Datentypen, Partitionierungsregeln, Speicherbedarf und andere relevante Informationen zu bestimmten Dateneinheiten (z. B. Spalten) enthalten.

Bei SSENSE verwenden wir den AWS Glue Catalog zum Katalogisieren unserer Daten. Beachten Sie hierbei, dass Frameworks wie Glue normalerweise Schemainferenzfunktionen bieten. Es ist jedoch immer ratsam, abgeleitete Schemas zu überarbeiten und einen Dateityp zu verwenden, der explizite Schemas unterstützt (z. B. Parquet). Dies ist vorzugsweise mit dem automatischen Inferenzwerkzeug Ihres Frameworks kompatibel.

Ein Beispiel-Glue-Katalog aus den AWS-Dokumenten

Um die zweite Frage zu beantworten, woher die Daten stammen, sind Metadaten zur Datenherkunft erforderlich. Gespräche über die Nachverfolgung der Herkunft von Daten in Datenökosystemen sind noch nicht weit fortgeschritten, um Best Practices zu ermitteln oder vorzuschreiben. Während Projekte wie Apache Atlas versuchen, Best Practices für die Nachverfolgung der Datenherkunft zu standardisieren, hat die Data-Engineering-Branche insgesamt nur das Problem und nicht die Lösung vereinbart. Im Wesentlichen beinhaltet das Verfolgen von Datenlinien die Aufrechterhaltung einer aufgezeichneten Historie des Ursprungs, der Transformation und der Bewegung jeder Dateneinheit. Die Granularität einer „Einheit“ kann von einem gesamten Datensatz bis zu einzelnen Datenpunkten variieren. Normalerweise führt mehr Granularität zu einer besseren Governance. Wenn Sie es richtig gemacht haben, können Sie durch das Aufzeichnen der Datenlinie Ihre Daten viel leichter verstehen, reproduzieren und debuggen.

Bei SSENSE werden alle unsere Datenpipelines von Apache Airflow-DAGs (Distributed Acyclic Graphs) verwaltet. Dies ermöglichte uns die Entwicklung einer benutzerdefinierten Abstammungslösung, bei der jedes Mal, wenn wir Daten in unseren See laden (in einem beliebigen S3-Bucket), das Objekt, das die Daten speichert, mit bestimmten Metadaten markiert wird, die Abstammungsinformationen enthalten. Die eigentliche Logik zum Hinzufügen von Metadaten zu jedem Objekt wird zu den Ladeaufgaben unserer Airflow-Pipelines hinzugefügt. Einige der Metadaten werden leicht von den Metadaten der DAG zur Verfügung gestellt, und einige davon werden basierend auf der Programmierlogik generiert. Zumindest verfolgen wir die folgenden Daten:

  1. Datenquelle (data_src): Die unmittelbare Quelle der Daten. Wenn die Daten beispielsweise von unserem Interim-Bucket in den Business-Bucket verschoben werden, wird der Dateipfad des Interim-Bucket zur Datenquelle. Wenn eine Datei Daten aus mehreren Dateien im vorherigen Bucket erbt, werden alle Pfade erwähnt oder das Präfix des übergeordneten Pfads wird verwendet. Dies stellt sicher, dass wir für alle gespeicherten Daten Datei für Datei zurückverfolgen können, um den vollständigen Pfad vom Ursprung bis zum endgültigen Ziel zu verfolgen.
  2. ETL-Datum (etl_date): Während dies in der Regel den vom System zuletzt geänderten Metadaten für S3-Objekte entspricht, bevorzugen wir ein benutzerdefiniertes Feld mit diesem Datum, das von unserer DAG festgelegt wurde. Dadurch wird sichergestellt, dass keine unvorhergesehenen Inkonsistenzen wie Zeitzonenprobleme auftreten.
  3. ETL-Quelle (etl_src): Wir verwalten alle unsere ETL-Logik in einem unabhängigen Pip-Paket. Dies ermöglicht uns, die Quelle unserer Transformationslogik auf einfache Weise als Punktnotationspfad des Moduls anzugeben, z.
  4. ETL-Version (etl_version): Unser vorgenanntes pip-Paket ist auch semantisch versioniert. Das bedeutet, dass wir nicht nur angeben können, welches Python-Skript die Logik für die Transformation der Daten enthält, sondern auch die Versionsnummer des für die Transformation verwendeten pip-Pakets. Zusammen mit der ETL-Quelle wird so sichergestellt, dass alle unsere Datentransformationen geprüft und Reverse Engineering ausgeführt werden können.
Eine Illustration, wie wir die Datenherkunft für aggregierte Datensätze verfolgen.

Ein richtiges Metadaten-Management bietet zwar einen unbestreitbaren geschäftlichen Wert, doch ist es eines unserer vorrangigen Ziele, die persönlichen Daten unserer Kunden und Geschäftspartner zu schützen und dabei das Recht jedes Kunden auf Vergessenheit zu respektieren. Dies ist nicht nur für die Einhaltung gesetzlicher Compliance-Standards wie der EU-Datenschutzgrundverordnung (DSGVO) von entscheidender Bedeutung, sondern ist auch eine ethische Verpflichtung gegenüber allen Personen, die unsere Organisation mit ihren Daten betrauen. Wir sind außerdem der Meinung, dass es ungeachtet der Größe und Art einer Organisation ratsam ist, persönliche Daten streng zu regeln und zu vermeiden, dass personenbezogene Daten (PII) gespeichert werden, wenn dies nicht unbedingt geschäftskritisch ist. Nach unserer Erfahrung stört die Anonymisierung von PII fast nie Analyse- und maschinelle Lernsysteme.

Datenverträge und Service Level Agreements

Während das Metadaten-Management für die Verwaltung der Daten zuständig ist, müssen Sie auch die Beziehungen Ihres Data Store mit der Außenwelt, den Quellen und Verbrauchern Ihrer Daten, regeln. Aufgrund der rasanten Veränderungen im Datenökosystem gibt es wiederum keine einstimmig akzeptierten Standards, wie dies zu tun ist. Wir können uns jedoch darauf einigen, dass es wichtig ist, diese Beziehungen sorgfältig zu regeln. Alle Datenspeicher stützen sich auf bestimmte Erwartungen sowohl ihrer Datenquellen als auch der Verbraucher. Sie erwartet, dass die Schnittstelle für ihre Datenquellen unter bestimmten Einschränkungen zugänglich ist, und dass ihre Verbraucher unter bestimmten Bedingungen auf ihre Daten zugreifen können.

Good Governance beinhaltet, dass alle impliziten, informellen oder mehrdeutigen Einschränkungen in explizite, formelle und spezifische Vereinbarungen (oder Verträge) umgewandelt werden. Hier werden Konzepte wie Datenverträge und SLAs (Service Level Agreements) praktisch. Ein SLA definiert explizit und genau für den Benutzer eines Softwaredienstes die Einschränkungen, unter denen der Dienst erwartet wird. In der Regel können die zugrunde liegende Infrastruktur und Software Ihrer Datenquelle (z. B. ein S3-Bucket) eindeutige SLAs hinsichtlich Betriebszeit, Konsistenz, Zuverlässigkeit usw. bereitstellen. In einigen Fällen können Ihre Datenquellen dasselbe tun (z. B. gut gebaut) REST-APIs). Im Idealfall, in dem all Ihre zugrunde liegende Software und alle Ihre Datenquellen solche SLAs bereitstellen können, kann Ihr Datenspeicher seinen Verbrauchern möglicherweise auch zuverlässige SLAs bereitstellen. Dies ist besonders nützlich, wenn es sich bei vielen Ihrer Verbraucher um andere automatisierte Dienste handelt, die nicht mehrdeutige Einschränkungen berücksichtigen können.

Ein Datenvertrag wirkt wie ein SLA, jedoch für jede einzelne Dateneinheit. Ein Vertrag kann beispielsweise vorschreiben, dass eine bestimmte Spalte die Summe bestimmter anderer Spalten enthalten muss. Abhängig von der Reife Ihres Daten-Ökosystems können diese als Codemodule implementiert werden, die Daten zur Laufzeit (wie hier gezeigt) validieren, oder sie können manuell als eine Vereinbarung zwischen dem Team des Data Store und den Stakeholdern implementiert werden, um die Einschränkungen für festzulegen jede Dateneinheit.

Bei SSENSE erstellen wir für jede von uns unterstützte Datenpipeline zunächst einen Vertrag mit unseren Stakeholdern manuell und implementieren dann die Einschränkungen programmgesteuert als Laufzeitprüfer. In Bezug auf SLAs können wir dank des zuverlässigen Abhängigkeitsmanagements von Airflow sehr spezifische Konsistenzgarantien wie 100% zeitliche Konsistenz bieten. Für andere Garantien wie Verfügbarkeit und Haltbarkeit bleiben die SLAs der von uns verwendeten AWS-Services (wie S3 und Athena) gültig.

Datenprüfung

Das Thema Testcode wird seit Jahrzehnten intensiv diskutiert. Software-Ingenieure haben einen langen Weg zurückgelegt, von Unit-Tests auf Code zu streuen, um umfassende Paradigmen wie Behavior Driven Development zu übernehmen und eine 100% ige Testabdeckung anzustreben. Data Engineering ist jedoch etwas anders. Traditionelle Teststrategien berücksichtigen häufig nicht die spezifischen Anliegen von Datenpipelines. Im Gegensatz zu den meisten Services, die sich auf den Client beziehen, unterliegt eine Datenpipeline keiner großen Anzahl unvorhersehbarer Benutzer. Ein Großteil des Codes, den ein Data Engineer schreibt, wird nur von anderen Data Engineers auf sehr vorhersagbare und spezifische Weise verwendet. Dies macht es unnötig, sich um viele Verhaltenstests zu kümmern, die für APIs so wichtig sind. Wie bereits erwähnt, handelt es sich bei dem Produkt für einen Dateningenieur um die Daten und nicht um die Software selbst. Dies bedeutet, dass beim Testen im Data Engineering die Datenqualität der Codequalität Vorrang haben sollte. Dies kann besonders schwierig sein, da Ihre Datenquellen normalerweise außerhalb Ihrer Kontrolle liegen und das Anpassen aller eingehenden Datenanomalien in Komponententests praktisch unmöglich ist.

Vor diesem Hintergrund haben wir einen zweifachen Testansatz entwickelt. Erstens verwenden wir Snapshot-Tests, um den Code für unsere Datentransformationen zu testen. Für jede Pipeline führen wir einige statische Eingabedaten und die daraus resultierenden Ausgaben - die transformierten Daten (validiert von den relevanten Interessengruppen) - als Modelldaten für unsere Tests. Während dies für den Rest unseres Codes durch einige traditionelle Unit-Tests ergänzt wird, streben wir nur eine 100% ige Abdeckung unserer Transformationslogik an. Diese Tests werden dann in unseren CICD-Pipelines ausgeführt, um sicherzustellen, dass jeglicher Code, den wir in die Produktion bringen, unsere Daten nicht beschädigt. Zweitens haben wir, um korrupte eingehende Daten zu berücksichtigen, Laufzeit-Validierungen in unsere Datenpipelines eingebaut, die unmittelbar nach der Transformation der eingehenden Daten ausgeführt werden. Diese Validierungen spiegeln unsere Datenverträge mit unseren Stakeholdern wider und sorgen dafür, dass schlechte Daten niemals in den Datensee gelangen. Im Gegensatz zu Services, die sich auf Kunden konzentrieren, sind wir häufig mit unseren Pipeline-Aufgaben zufrieden, was zu Fehlern führt und in der Produktion ausfällt. Airflow ermöglicht es uns, dies sehr leicht zu handhaben, indem das Problem behoben und die fehlgeschlagenen Aufgaben erneut ausgeführt werden. Was wir uns nicht leisten können, ist die unbemerkte Korruption unserer Daten.

Fazit

In Teil I der Reihe Principled Data Engineering haben wir unsere Data-Lake-Architektur als Referenzpunkt für die Diskussion der Herausforderungen beim Speichern und Pipelining von Daten im Unternehmensmaßstab vorgestellt. In Teil II haben wir uns ausschließlich auf das Thema Data Governance konzentriert. Es mag ungewöhnlich erscheinen, dass wir die Hälfte der Serie in die Diskussion über Data Governance investiert haben, ein Thema, das in Industrie und Wissenschaft häufig als nachträglich betrachtet wird. Unserer Ansicht nach hat diese Vernachlässigung einer guten Datenverwaltung jedoch zu ernsthaften Problemen in der Tech-Industrie geführt. Als Dateningenieure müssen wir eine ethische Verantwortung übernehmen, um die Integrität, Gültigkeit, Vertraulichkeit und Verantwortlichkeit unserer Daten sicherzustellen. Dies sind wir unseren Kunden, Mitarbeitern und dem Unternehmen selbst schuldig. Nachdem Sie beide Teile dieser Serie gelesen haben, sollten Sie jetzt einen mentalen Rahmen für die praktische und prinzipielle Architektur eines Datensystems haben. Wir möchten Sie dazu auffordern, die geschäftlichen Anforderungen bei Ihren technischen Entscheidungen bestimmen zu lassen und alle derartigen Entscheidungen in der Philosophie zu begründen, dass Ihre Daten Ihr Produkt und damit auch Ihre Verantwortung sind.

Redaktionelle Rezensionen von Hussein Danish & Liela Touré.

Willst du mit uns zusammenarbeiten? Hier finden Sie alle offenen Stellen bei SSENSE!

Siehe auch

Ein Gespräch mit Suji Yan & Katt Gu: Wir arbeiten immer noch für J.P.Morgan'sWie ist es, ein Mentor zu sein?Worum geht es in diesem neuen Tech Stack?Die "Jetsons" -Liste