20 Punkte von xguru 2020-11-23 | 2 Kommentare | Auf WhatsApp teilen

Eine Zusammenfassung, warum Nemo, Amundsen, DataHub usw. gebraucht werden und welche Funktionen sie bieten

„Warum braucht man eine DDP? Was macht sie überhaupt?“

→ Eine Plattform, die dabei hilft, die benötigten Daten innerhalb einer Organisation schnell zu finden, zu verstehen, was sie sind, und zu lernen, wie man sie verwendet

[ Fragen, die beim Suchen von Daten häufig gestellt werden ]

→ Wo finde ich die „_____“-Daten? : Manchmal weiß man nicht einmal, nach welchen Begriffen man suchen soll. Man sucht nach Tabellen-/Spaltennamen mit Begriffen wie click, page view usw.

→ Was sind das für Daten? : Welche Spalten hat diese Tabelle, welche Datentypen haben sie, und was bedeuten diese Werte?

→ Wen muss ich um Zugriffsrechte bitten? : Informationen zu Data Ownership und Berechtigungen sollten ebenfalls Teil der Metadaten sein

→ Wie wurden diese Daten erzeugt? Sind sie vertrauenswürdig? : Wer hat sie erstellt, und über welchen Weg wurden sie erzeugt? Wurden sie manuell monatlich von einem Analysten erstellt? Wie stark werden sie im Unternehmen genutzt? Wie sieht die Lineage dieser Daten aus?

→ Wie sollte ich diese Daten verwenden? : Welche Spalten hängen zusammen? Mit welcher Tabelle sollte ich sie joinen? Welche Filter sollte ich verwenden, um die Daten aufzubereiten? Wer nutzt diese Tabelle hauptsächlich? (Dann kann man diese Person einfach fragen.) Welche Spalten werden hauptsächlich verwendet?

→ Wie oft werden diese Daten aktualisiert? : Falls es gelegentlich Verzögerungen gibt, wie häufig passiert das? Über welchen Zeitraum erstrecken sich die Daten? Wenn es nur ein paar Wochen sind, eignen sie sich wahrscheinlich nicht für Machine Learning.

[ Funktionen, um Daten zu finden, zu verstehen und zu nutzen ]

  • Daten suchen oder auf intelligentere Weise finden

→ Die grundlegende Methode, gewünschte Daten zu finden, ist die Suche in ElasticSearch über Metadaten wie Spaltennamen, Tabellen- und Spaltenbeschreibungen sowie von Nutzern eingegebene Beschreibungen oder Kommentare

→ Wenn es viele Suchergebnisse gibt, müssen diese priorisiert werden. Bei Lyft und Spotify wird das Ranking danach bestimmt, wie häufig eine Tabelle verwendet wird. Dazu werden Query-Logs geparst und die Tabellennutzung als Ranking-Information in ElasticSearch eingespeist.

→ Facebooks Nemo erweitert das noch weiter. Es parst Suchbegriffe mit spaCy als natürliche Sprache und bestimmt das Ranking unter anderem über kNN-basiertes Scoring mit Unicorn, das auch für die Suche im Social Graph verwendet wird.

→ Eine weitere Methode ist die Empfehlung. Dabei werden die Daten empfohlen, auf die innerhalb der Organisation und des Teams am häufigsten zugegriffen und die am häufigsten genutzt werden.

  • Daten mithilfe von Schema, Vorschau, Statistiken und Lineage verstehen

→ Die grundlegenden Informationen zum Verständnis einer Tabelle sind das Datenschema: Spaltenname, Datentyp, Beschreibung (Description)

→ Wenn ein Nutzer Leserechte hat, kann eine Vorschau der Daten bereitgestellt werden (etwa 100 Zeilen)

→ Es können auch vorab berechnete Statistiken auf Spaltenebene bereitgestellt werden: Anzahl der Rows je Spalte, Anzahl der Null-Rows, Maximum/Minimum/Durchschnitt/Median/Standardabweichung, Anzahl eindeutiger Rows und bei Datumsspalten der gesamte Zeitbereich der Daten

→ Durch Bereitstellung der Daten-Lineage lassen sich auch Abhängigkeitsbeziehungen davor und danach prüfen: Bei ETL-Jobs (die mit Airflow geplant werden) kann man Dinge wie Schedule und Verzögerungen prüfen.

  • Über das Nutzungsverhalten anderer lernen, wie Daten verwendet werden

→ Wenn man eine Tabelle gefunden hat, wie kann man dann dabei helfen, sie zu verwenden? Eine einfache Methode ist, die Personen anzuzeigen, die mit dieser Tabelle in Verbindung stehen.

→ Data Owner können Zugriffsrechte vergeben, und häufige Nutzer können Einführungen oder Besonderheiten zu den Daten erläutern: Amundsen und DataHub können Personen als Entitäten mit einer Tabelle verknüpfen

→ Wenn man sich aber nur auf Experten verlässt, die diese Daten gut kennen, kann daraus ein Flaschenhals entstehen. Zusätzliche Metadaten zu verknüpfen ist daher der skalierbarere Ansatz.

→ Es ist möglich, Nutzungsstatistiken für jede Spalte bereitzustellen, damit Nutzer die relevantesten Spalten leichter finden können.

→ Um außerdem zu erkennen, mit welchen Tabellen eine gegebene Tabelle gejoint werden sollte, ist es hilfreich, eine Liste der häufig gejointen Tabellen und der verwendeten Join-Spalten bereitzustellen. Dafür müssen Query-Logs geparst werden.

→ Um detailliertere Informationen zur Datennutzung bereitzustellen, können auch aktuelle Queries für die betreffende Tabelle angezeigt werden. So lässt sich erkennen, welche Daten tatsächlich gefiltert werden.

→ Auch Daten-Lineage ist nützlich. Man kann nachgelagerte Tabellen identifizieren, die die aktuelle Tabelle verwenden, und sogar die Query anzeigen, mit der sie erzeugt werden. Dadurch lässt sich nachvollziehen, wie die Tabelle in anderen Use Cases genutzt wird.

→ Wenn eine so entdeckte Downstream-Tabelle mit dem eigenen Ziel übereinstimmt, kann man stattdessen diese verwenden und so Rechen- und Speicherkosten sparen.

→ Twitters Data Access Layer, Ubers Databook und Netflix’ Metacat unterstützen Lineage

→ Bevor man Daten tatsächlich verwendet, möchte man auch wissen, wie oft sie aktualisiert werden. Es ist hilfreich, anzugeben, in welchen Zeiteinheiten die Daten partitioniert sind (Tag/Stunde usw.).

→ Eine DDP kann mit Plattformen wie Airflow integriert werden, um geplante ETL-Jobs zu untersuchen und zu sehen, wie lange sie dauern usw.

[ Vergleich auf hoher Ebene der einzelnen DDPs ]

→ Alle unterstützen Free-Text-Suche auf Basis von ElasticSearch oder Solr. Amundsen und Lexikon bieten auf ihrer Startseite Empfehlungsfunktionen.

→ Alle zeigen grundlegende Tabelleninformationen an (Schema, Beschreibung). Amundsen und Databook bieten Datenvorschau und Spaltenstatistiken.

→ Die meisten Plattformen haben Daten-Lineage bereits eingebaut. Amundsen unterstützt das derzeit noch nicht, es steht aber auf der Roadmap für 2020.

→ Fünf der Plattformen sind als Open Source veröffentlicht

[ Vergleich von Open-Source-DDPs ]

→ Veröffentlicht im Februar 2020

→ Unterstützt Suche, Tabellenschema, Ownership und Lineage

→ Unterstützt drei Entitäten: Dataset, User, Group. Entitäten wie Schemas/Jobs/Metrics/Dashboards sollen noch hinzukommen.

→ Unterstützt Hive-, Kafka- und RDB-Metadaten (intern wird noch mehr unterstützt, und möglicherweise wird weiteres öffentlich gemacht)

→ Von Expedia und TypeForm übernommen; auch MS, Morgan Stanley, Orange Telecom, ThoughtWorks usw. führen POCs durch

→ Veröffentlicht im Oktober 2019

→ Unterstützt Suche, Empfehlungen sowie eine gut gestaltete Detailseite für Tabellen mit Vorschau/Spaltenstatistiken/Ownern/Hauptnutzern. Lineage gibt es noch nicht, ist aber geplant.

→ Die Integration mit einem Data Quality System ist ebenfalls geplant (vermutlich Great Expectations - https://greatexpectations.io/)

→ Es gibt eine hervorragende Community: Beiträge wie Integrationen mit BigQuery/Redshift/Apache Atlas usw. wurden entwickelt und beigesteuert

→ Unterstützt die Integration mit mehr als 15 Arten von Datenquellen (Redshift, Cassandra, Hive, Snowflake und verschiedene RDBs), Tableau-, Redash- und Mode-Analytics-Dashboards, Airflow usw.

→ Die Dokumentation ist gut, und Tests lokal per Docker sind möglich

→ Von mehr als 30 Organisationen eingeführt, darunter Asana, Instacart, iRobot und Square.

→ Im Juli 2020 als neues Inkubationsprojekt der Linux AI Foundation aufgenommen.

→ Veröffentlicht im Juni 2018

→ Enthält Suche, Schemaansicht und Metriken zur Analyse von Kosten und Speicherplatz.

→ Es gibt eine Benachrichtigungsfunktion für Änderungen an Tabellen/Partitionen. Man kann Benachrichtigungen erhalten, wenn Daten aus Kostengründen usw. gelöscht werden.

→ Unterstützt Integrationen mit Hive, Teradata, Redshift, S3, Cassandra und RDS

→ Es wurde erwähnt, dass an Versionierung/Validierung von Schemas/Metadaten gearbeitet wird.

→ Ist zwar Open Source, aber da es überhaupt keine Dokumentation gibt, hat es bisher kein Unternehmen eingeführt.

→ Veröffentlicht im Oktober 2018

→ Fokus auf Datenqualität und Lineage

→ Unterstützt Data Governance, Datenqualität über Great Expectations sowie Kataloge für Datasets und Jobs

→ Bietet WebUI sowie Airflow-Komponenten und Java-/Python-Clients

→ Lokale Tests per Docker sind möglich, aber es gibt nicht viele Dokumente

→ Gestartet im Juli 2015 als Teil der Data Governance Initiative

→ Version 1.0 wurde im Juni 2018 veröffentlicht, aktuell ist 2.1

→ Hauptziel ist Data Governance, also Organisationen dabei zu helfen, Sicherheits- und Compliance-Anforderungen einzuhalten.

→ Bietet umfangreiche Funktionen wie Tagging von Ressourcen, Vererbung von Tags auf Downstream-Datasets sowie Sicherheit beim Zugriff auf Metadaten

→ Auch Benachrichtigungen über Metadatenänderungen sind möglich

→ Unterstützt Free-Text-Suche, detaillierte Schemaansicht und Daten-Lineage

→ Unterstützt auch erweiterte Suche mit einer SQL-ähnlichen Syntax

→ Unterstützt die Integration mit Metadatenquellen wie HBase, Hive, Kaflka usw.

→ Metadaten können auch per REST API erstellt/geändert werden

→ Die Dokumentation ist ebenfalls gut

  • Der Fall von ING, die Atlas und Amundsen gemeinsam eingeführt haben, ist interessant: https://medium.com/wbaa/…

  • Zwar keine vollständige DDP, aber das Open-Source-Projekt Whale ist ein extrem einfaches DDP-Tool, das Inhalte eines Data Warehouse in Markdown indexiert und Suche, Bearbeitung, Versionierung usw. unterstützt

→ Als DDP-Tool für Entwickler einen Blick wert: https://github.com/dataframehq/whale

  • Nicht so sexy wie Machine Learning, aber Data Discovery ist ein wichtiger erster Schritt im Data-Science-Workflow

2 Kommentare

 
toughrogrammer 2020-11-23

Oh, wirklich eine sehr gute Zusammenfassung. Ich sollte Amundsen mal ausprobieren.

 
xguru 2020-11-23

Nemo – Facebooks Data-Discovery-Plattform https://de.news.hada.io/topic?id=3024

Ein Beispiel für den Aufbau einer DDP, wie es in Korea nur selten zu finden ist