Open Source DataHub: LinkedIns Metadaten-Such- und Discovery-Plattform
Das schnelle Auffinden der benötigten Daten ist für jedes Unternehmen, das auf große Datenmengen angewiesen ist, um datengesteuerte Entscheidungen zu treffen, von entscheidender Bedeutung. Dies wirkt sich nicht nur auf die Produktivität der Datennutzer aus (einschließlich Analysten, Entwickler für maschinelles Lernen, Datenwissenschaftler und Dateningenieure), sondern hat auch direkte Auswirkungen auf die Endprodukte, die von einer hochwertigen Pipeline für maschinelles Lernen (ML) abhängen. Darüber hinaus wirft der Trend zur Implementierung oder zum Aufbau von Plattformen für maschinelles Lernen natürlich die Frage auf: Mit welcher Methode können Sie intern Funktionen, Modelle, Metriken, Datensätze usw. entdecken?
In diesem Artikel werden wir darüber sprechen, wie wir eine Datenquelle unter einer offenen Lizenz veröffentlicht haben in unserer Metadaten-Such- und Entdeckungsplattform, beginnend in den frühen Tagen des Projekts . LinkedIn pflegt seine eigene Version von DataHub getrennt von der Open-Source-Version. Wir erklären zunächst, warum wir zwei separate Entwicklungsumgebungen benötigen, diskutieren dann erste Ansätze zur Verwendung des Open-Source-WhereHows und vergleichen unsere interne (Produktions-)Version von DataHub mit der Version darauf . Wir werden auch Details zu unserer neuen automatisierten Lösung zum Pushen und Empfangen von Open-Source-Updates mitteilen, um beide Repositorys synchron zu halten. Abschließend geben wir Anweisungen für die ersten Schritte mit dem Open-Source-DataHub und besprechen kurz seine Architektur.
WhereHows ist jetzt ein DataHub!
Das Metadaten-Team von LinkedIn hat zuvor vorgestellt (Nachfolger von WhereHows), der Such- und Metadaten-Erkennungsplattform von LinkedIn, und gemeinsame Pläne zu deren Eröffnung. Kurz nach dieser Ankündigung haben wir eine Alpha-Version von DataHub veröffentlicht und diese mit der Community geteilt. Seitdem haben wir kontinuierlich zum Repository beigetragen und mit interessierten Benutzern zusammengearbeitet, um die am häufigsten nachgefragten Funktionen hinzuzufügen und Probleme zu lösen. Wir freuen uns nun, die offizielle Veröffentlichung bekannt zu geben .
Open-Source-Ansätze
WhereHows, LinkedIns ursprüngliches Portal zum Auffinden von Daten und deren Herkunft, begann als internes Projekt; Das Metadaten-Team hat es geöffnet . Seitdem hat das Team immer zwei unterschiedliche Codebasen gepflegt – eine für Open Source und eine für den internen Gebrauch von LinkedIn – da nicht alle für LinkedIn-Anwendungsfälle entwickelten Produktfunktionen allgemein auf die breitere Zielgruppe anwendbar waren. Darüber hinaus verfügt WhereHows über einige interne Abhängigkeiten (Infrastruktur, Bibliotheken usw.), die nicht Open Source sind. In den folgenden Jahren durchlief WhereHows viele Iterationen und Entwicklungszyklen, was es zu einer großen Herausforderung machte, die beiden Codebasen synchron zu halten. Das Metadaten-Team hat im Laufe der Jahre verschiedene Ansätze ausprobiert, um die interne und Open-Source-Entwicklung synchron zu halten.
Erster Versuch: „Open Source zuerst“
Wir folgten zunächst einem „Open Source First“-Entwicklungsmodell, bei dem die meiste Entwicklung in einem Open-Source-Repository erfolgt und Änderungen für die interne Bereitstellung vorgenommen werden. Das Problem bei diesem Ansatz besteht darin, dass der Code immer zuerst an GitHub gepusht wird, bevor er intern vollständig überprüft wurde. Bis Änderungen am Open-Source-Repository vorgenommen und eine neue interne Bereitstellung durchgeführt werden, werden wir keine Produktionsprobleme feststellen. Bei mangelhafter Bereitstellung war es außerdem sehr schwierig, den Schuldigen zu ermitteln, da die Änderungen stapelweise vorgenommen wurden.
Darüber hinaus verringerte dieses Modell die Produktivität des Teams bei der Entwicklung neuer Funktionen, die schnelle Iterationen erforderten, da alle Änderungen zunächst in ein Open-Source-Repository und dann in ein internes Repository übertragen werden mussten. Um die Verarbeitungszeit zu verkürzen, konnte die erforderliche Korrektur oder Änderung zuerst im internen Repository durchgeführt werden. Dies wurde jedoch zu einem großen Problem, als es darum ging, diese Änderungen wieder in das Open-Source-Repository zusammenzuführen, da die beiden Repositorys nicht synchron waren.
Dieses Modell lässt sich für gemeinsam genutzte Plattformen, Bibliotheken oder Infrastrukturprojekte viel einfacher implementieren als für benutzerdefinierte Webanwendungen mit vollem Funktionsumfang. Darüber hinaus ist dieses Modell ideal für Projekte, die vom ersten Tag an mit Open Source beginnen, WhereHows wurde jedoch als vollständig interne Webanwendung erstellt. Es war wirklich schwierig, alle internen Abhängigkeiten vollständig zu abstrahieren, also mussten wir den internen Zweig behalten, aber den internen Zweig beizubehalten und größtenteils Open Source zu entwickeln, hat nicht ganz geklappt.
Zweiter Versuch: „Inner zuerst“
**Als zweiten Versuch sind wir zu einem „Internal First“-Entwicklungsmodell übergegangen, bei dem der Großteil der Entwicklung intern erfolgt und regelmäßig Änderungen am Open-Source-Code vorgenommen werden. Obwohl dieses Modell für unseren Anwendungsfall am besten geeignet ist, weist es inhärente Probleme auf. Alle Unterschiede direkt in das Open-Source-Repository zu übertragen und später zu versuchen, Zusammenführungskonflikte zu lösen, ist eine Option, aber zeitaufwändig. Entwickler versuchen in den meisten Fällen, dies nicht jedes Mal zu tun, wenn sie ihren Code überprüfen. Dies führt dazu, dass dies viel seltener in Stapeln erfolgt und es somit schwieriger wird, Zusammenführungskonflikte später zu lösen.
Beim dritten Mal hat es geklappt!
Die beiden oben erwähnten Fehlversuche führten dazu, dass das GitHub-Repository von WhereHows für lange Zeit veraltet blieb. Das Team verbesserte die Funktionen und Architektur des Produkts weiter, sodass die interne Version von WhereHows für LinkedIn fortschrittlicher wurde als die Open-Source-Version. Es hatte sogar einen neuen Namen – DataHub. Basierend auf früheren gescheiterten Versuchen beschloss das Team, eine skalierbare, langfristige Lösung zu entwickeln.
Für jedes neue Open-Source-Projekt berät und unterstützt das Open-Source-Team von LinkedIn ein Entwicklungsmodell, bei dem die Module des Projekts vollständig in Open Source entwickelt werden. Versionierte Artefakte werden in einem öffentlichen Repository bereitgestellt und dann mithilfe von wieder in das interne LinkedIn-Artefakt eingecheckt . Die Befolgung dieses Entwicklungsmodells ist nicht nur gut für diejenigen, die Open Source verwenden, sondern führt auch zu einer modulareren, erweiterbareren und steckbareren Architektur.
Eine ausgereifte Back-End-Anwendung wie DataHub benötigt jedoch viel Zeit, um diesen Zustand zu erreichen. Dies schließt auch die Möglichkeit aus, eine voll funktionsfähige Implementierung als Open Source bereitzustellen, bevor alle internen Abhängigkeiten vollständig abstrahiert wurden. Aus diesem Grund haben wir Tools entwickelt, die uns helfen, Open-Source-Beiträge schneller und mit viel weniger Aufwand zu erstellen. Von dieser Lösung profitieren sowohl das Metadatenteam (DataHub-Entwickler) als auch die Open-Source-Community. In den folgenden Abschnitten wird dieser neue Ansatz besprochen.
Open-Source-Publishing-Automatisierung
Der neueste Ansatz des Metadata-Teams für den Open-Source-DataHub besteht in der Entwicklung eines Tools, das die interne Codebasis und das Open-Source-Repository automatisch synchronisiert. Zu den High-Level-Funktionen dieses Toolkits gehören:
- Synchronisieren Sie LinkedIn-Code mit/von Open Source, ähnlich .
- Lizenz-Header-Generierung, ähnlich wie .
- Generieren Sie automatisch Open-Source-Commit-Protokolle aus internen Commit-Protokollen.
- Verhindern Sie interne Änderungen, die Open-Source-Builds beeinträchtigen .
Die folgenden Unterabschnitte befassen sich mit den oben genannten Funktionen, die interessante Probleme aufweisen.
Synchronisierung des Quellcodes
Im Gegensatz zur Open-Source-Version von DataHub, bei der es sich um ein einzelnes GitHub-Repository handelt, ist die LinkedIn-Version von DataHub eine Kombination aus mehreren Repositorys (intern aufgerufen). ). Die DataHub-Schnittstelle, die Metadatenmodellbibliothek, der Metadata Warehouse-Backend-Dienst und Streaming-Jobs befinden sich in separaten Repositorys auf LinkedIn. Um es Open-Source-Benutzern jedoch einfacher zu machen, verfügen wir über ein einziges Repository für die Open-Source-Version von DataHub.
Abbildung 1: Synchronisierung zwischen Repositories LinkedIn DataHub und ein einziges Repository DataHub Open Source
Um automatisierte Build-, Push- und Pull-Workflows zu unterstützen, erstellt unser neues Tool automatisch eine Zuordnung auf Dateiebene, die jeder Quelldatei entspricht. Das Toolkit erfordert jedoch eine Erstkonfiguration und Benutzer müssen eine übergeordnete Modulzuordnung bereitstellen, wie unten gezeigt.
{
"datahub-dao": [
"${datahub-frontend}/datahub-dao"
],
"gms/impl": [
"${dataset-gms}/impl",
"${user-gms}/impl"
],
"metadata-dao": [
"${metadata-models}/metadata-dao"
],
"metadata-builders": [
"${metadata-models}/metadata-builders"
]
}Die Zuordnung auf Modulebene ist ein einfaches JSON, dessen Schlüssel die Zielmodule im Open-Source-Repository und die Werte die Liste der Quellmodule in den LinkedIn-Repositorys sind. Jedes Zielmodul in einem Open-Source-Repository kann von einer beliebigen Anzahl von Quellmodulen gespeist werden. Um die internen Namen von Repositorys in Quellmodulen anzugeben, verwenden Sie im Bash-Stil. Mithilfe einer Zuordnungsdatei auf Modulebene erstellen die Tools eine Zuordnungsdatei auf Dateiebene, indem sie alle Dateien in den zugehörigen Verzeichnissen scannen.
{
"${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
"${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
"${metadata-models}/metadata-builders/build.gradle": null,
}Die Dateiebenenzuordnung wird von den Tools automatisch erstellt; Es kann jedoch auch manuell vom Benutzer aktualisiert werden. Dabei handelt es sich um eine 1:1-Zuordnung einer LinkedIn-Quelldatei zu einer Datei im Open-Source-Repository. Mit dieser automatischen Erstellung von Dateizuordnungen sind mehrere Regeln verbunden:
- Bei mehreren Quellmodulen für ein Zielmodul in Open Source kann es zu Konflikten kommen, z.B. gleich , in mehr als einem Quellmodul vorhanden. Als Konfliktlösungsstrategie verwenden unsere Tools standardmäßig die Option „Der Letzte gewinnt“.
- „null“ bedeutet, dass die Quelldatei nicht Teil des Open-Source-Repositorys ist.
- Nach jeder Open-Source-Einreichung oder -Extraktion wird diese Zuordnung automatisch aktualisiert und ein Snapshot erstellt. Dies ist notwendig, um Hinzufügungen und Löschungen im Quellcode seit der letzten Aktion zu identifizieren.
Commit-Protokolle erstellen
Commit-Protokolle für Open-Source-Commits werden ebenfalls automatisch generiert, indem die Commit-Protokolle interner Repositorys zusammengeführt werden. Nachfolgend finden Sie ein Beispiel für ein Commit-Protokoll, das die Struktur des von unserem Tool generierten Commit-Protokolls zeigt. Ein Commit gibt deutlich an, welche Versionen der Quellrepositorys in diesem Commit enthalten sind, und stellt eine Zusammenfassung des Commit-Protokolls bereit. Schauen Sie sich das hier an anhand eines realen Beispiels eines von unserem Toolkit generierten Commit-Protokolls.
metadata-models 29.0.0 -> 30.0.0
Added aspect model foo
Fixed issue bar
dataset-gms 2.3.0 -> 2.3.4
Added rest.li API to serve foo aspect
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Abhängigkeitstests
LinkedIn hat , wodurch sichergestellt wird, dass Änderungen an einem internen Multiprodukt nicht dazu führen, dass die Anordnung abhängiger Multiprodukte beschädigt wird. Das Open-Source-DataHub-Repository ist kein Multiprodukt und kann keine direkte Abhängigkeit von einem Multiprodukt sein. Mit Hilfe eines Multiprodukt-Wrappers, der den Open-Source-DataHub-Quellcode abruft, können wir diese Abhängigkeitstests jedoch trotzdem verwenden Daher löst jede Änderung (die später offengelegt werden kann) an einem der Multiprodukte, die das Open-Source-DataHub-Repository versorgen, ein Build-Ereignis im Shell-Multiprodukt aus. Daher besteht jede Änderung, die beim Erstellen eines Wrapper-Produkts fehlschlägt, die Tests nicht, bevor das ursprüngliche Produkt festgeschrieben wird, und wird rückgängig gemacht.
Dies ist ein nützlicher Mechanismus, der dabei hilft, jeglichen internen Commit zu verhindern, der den Open-Source-Build unterbricht und ihn zum Commit-Zeitpunkt erkennt. Ohne dies wäre es ziemlich schwierig zu bestimmen, welches interne Commit zum Scheitern der Open-Source-Repository-Erstellung geführt hat, da wir interne Änderungen am DataHub-Open-Source-Repository stapelweise durchführen.
Unterschiede zwischen Open Source DataHub und unserer Produktionsversion
Bisher haben wir unsere Lösung für die Synchronisierung zweier Versionen von DataHub-Repositories besprochen, aber wir haben immer noch nicht die Gründe dargelegt, warum wir überhaupt zwei verschiedene Entwicklungsströme benötigen. In diesem Abschnitt werden wir die Unterschiede zwischen der öffentlichen Version von DataHub und der Produktionsversion auf LinkedIn-Servern auflisten und die Gründe für diese Unterschiede erläutern.
Eine Quelle der Diskrepanz ergibt sich aus der Tatsache, dass unsere Produktionsversion Abhängigkeiten von Code aufweist, der noch nicht Open Source ist, wie z. B. Offspring von LinkedIn (LinkedIns internes Dependency-Injection-Framework). Offspring wird häufig in internen Codebasen verwendet, da es die bevorzugte Methode zur Verwaltung dynamischer Konfigurationen ist. Aber es ist kein Open Source; Deshalb mussten wir Open-Source-Alternativen zum Open-Source-DataHub finden.
Es gibt auch andere Gründe. Da wir Erweiterungen des Metadatenmodells für die Bedürfnisse von LinkedIn erstellen, sind diese Erweiterungen in der Regel sehr spezifisch für LinkedIn und können möglicherweise nicht direkt auf andere Umgebungen angewendet werden. Wir haben beispielsweise sehr spezifische Bezeichnungen für Teilnehmer-IDs und andere Arten übereinstimmender Metadaten. Daher haben wir diese Erweiterungen nun aus dem Open-Source-Metadatenmodell von DataHub ausgeschlossen. Während wir mit der Community zusammenarbeiten und ihre Bedürfnisse verstehen, werden wir bei Bedarf an gemeinsamen Open-Source-Versionen dieser Erweiterungen arbeiten.
Benutzerfreundlichkeit und einfachere Anpassung für die Open-Source-Community führten auch zu einigen Unterschieden zwischen den beiden Versionen von DataHub. Ein gutes Beispiel hierfür sind Unterschiede in der Stream-Verarbeitungsinfrastruktur. Obwohl unsere interne Version ein verwaltetes Stream-Verarbeitungsframework verwendet, haben wir uns für die integrierte (eigenständige) Stream-Verarbeitung für die Open-Source-Version entschieden, da dadurch die Schaffung einer weiteren Infrastrukturabhängigkeit vermieden wird.
Ein weiteres Beispiel für den Unterschied ist die Verwendung eines einzigen GMS (Generalized Metadata Store) in einer Open-Source-Implementierung anstelle mehrerer GMS. GMA (Generalized Metadata Architecture) ist der Name der Back-End-Architektur für DataHub und GMS ist der Metadatenspeicher im Kontext von GMA. GMA ist eine sehr flexible Architektur, die es Ihnen ermöglicht, jedes Datenkonstrukt (z. B. Datensätze, Benutzer usw.) in seinem eigenen Metadatenspeicher zu verteilen oder mehrere Datenkonstrukte in einem einzigen Metadatenspeicher zu speichern, solange die Registrierung die Datenstrukturzuordnung enthält GMS wird aktualisiert. Aus Gründen der Benutzerfreundlichkeit haben wir eine einzige GMS-Instanz ausgewählt, die alle verschiedenen Datenkonstrukte im Open-Source-DataHub speichert.
Eine vollständige Liste der Unterschiede zwischen den beiden Implementierungen finden Sie in der folgenden Tabelle.
Produkt-Eigenschaften
LinkedIn DataHub
Open-Source-DataHub
Unterstützte Datenkonstrukte
1) Datensätze 2) Benutzer 3) Metriken 4) ML-Funktionen 5) Diagramme 6) Dashboards
1) Datensätze 2) Benutzer
Unterstützte Metadatenquellen für Datensätze
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Hive Kafka RDBMS
Pub-sub
Konfluenter Kafka
Stream Processing
Managed
Eingebettet (eigenständig)
Abhängigkeitsinjektion und dynamische Konfiguration
LinkedIn Nachwuchs
Bauwerkzeuge
Ligradle (LinkedIns interner Gradle-Wrapper)
CI / CD
CRT (LinkedIns internes CI/CD)
und
Metadatenspeicher
Verteilte mehrere GMS: 1) Datensatz-GMS 2) Benutzer-GMS 3) Metrik-GMS 4) Feature-GMS 5) Diagramm-/Dashboard-GMS
Einzelnes GMS für: 1) Datensätze 2) Benutzer
Microservices in Docker-Containern
vereinfacht die Anwendungsbereitstellung und -verteilung mit . Jeder Teil des Dienstes in DataHub ist Open Source, einschließlich Infrastrukturkomponenten wie Kafka, , и , hat ein eigenes Docker-Image. Zur Orchestrierung von Docker-Containern haben wir verwendet .
Abbildung 2: Architektur DataHub *Open Source**
Sie können die High-Level-Architektur von DataHub im Bild oben sehen. Neben den Infrastrukturkomponenten verfügt es über vier verschiedene Docker-Container:
datahub-gms: Metadatenspeicherdienst
datahub-frontend: Anwendung , die die DataHub-Schnittstelle bedient.
datahub-mce-consumer: Anwendung , das den MCE-Stream (Metadata Change Event) verwendet und den Metadatenspeicher aktualisiert.
datahub-mae-consumer: Anwendung , das einen Metadaten-Audit-Ereignisstrom (MAE) verwendet und einen Suchindex und eine Diagrammdatenbank erstellt.
Open-Source-Repository-Dokumentation und enthalten detailliertere Informationen zu den Funktionen verschiedener Dienste.
CI/CD auf DataHub ist Open Source
Das Open-Source-DataHub-Repository verwendet für kontinuierliche Integration und für den kontinuierlichen Einsatz. Beide verfügen über eine gute GitHub-Integration und sind einfach einzurichten. Für die meisten Open-Source-Infrastrukturen, die von der Community oder privaten Unternehmen entwickelt wurden (z. B. ) werden Docker-Images erstellt und im Docker Hub bereitgestellt, um die Nutzung durch die Community zu vereinfachen. Jedes im Docker Hub gefundene Docker-Image kann einfach mit einem einfachen Befehl verwendet werden .
Bei jedem Commit zum DataHub-Open-Source-Repository werden alle Docker-Images automatisch erstellt und mit dem Tag „latest“ im Docker Hub bereitgestellt. Wenn Docker Hub mit einigen konfiguriert ist Alle Tags im Open-Source-Repository werden auch mit entsprechenden Tag-Namen im Docker Hub veröffentlicht.
Verwendung von DataHub
ist sehr einfach und besteht aus drei einfachen Schritten:
- Klonen Sie das Open-Source-Repository und führen Sie alle Docker-Container mit Docker-Compose aus, indem Sie für einen schnellen Einstieg das bereitgestellte Docker-Compose-Skript verwenden.
- Laden Sie die im Repository bereitgestellten Beispieldaten mit dem ebenfalls bereitgestellten Befehlszeilentool herunter.
- Durchsuchen Sie DataHub in Ihrem Browser.
Aktiv verfolgt auch für schnelle Fragen konfiguriert. Benutzer können Issues auch direkt im GitHub-Repository erstellen. Am wichtigsten ist, dass wir jedes Feedback und alle Vorschläge willkommen heißen und schätzen!
Pläne für die Zukunft
Derzeit ist jede Infrastruktur oder jeder Microservice für Open Source DataHub als Docker-Container aufgebaut und das gesamte System wird mithilfe von Docker orchestriert . Angesichts der Beliebtheit und Verbreitung möchten wir in naher Zukunft auch eine Kubernetes-basierte Lösung anbieten.
Wir planen außerdem die Bereitstellung einer schlüsselfertigen Lösung für die Bereitstellung von DataHub in einem öffentlichen Cloud-Dienst wie z , oder . Angesichts der jüngsten Ankündigung der Migration von LinkedIn zu Azure wird dies mit den internen Prioritäten des Metadatenteams übereinstimmen.
Zu guter Letzt danken wir allen frühen Anwendern von DataHub in der Open-Source-Community, die DataHub-Alphas bewertet und uns dabei geholfen haben, Probleme zu identifizieren und die Dokumentation zu verbessern.
Source: habr.com