DataHub mit offenem Quellcode: Plattform zur Suche und Entdeckung von Metadaten von LinkedIn
Eine schnelle Suche nach den benötigten Daten ist fĂŒr jedes Unternehmen unerlĂ€sslich, das auf eine groĂe Menge an Daten angewiesen ist, um Entscheidungen auf der Grundlage dieser Daten zu treffen. Dies beeinflusst nicht nur die ProduktivitĂ€t der Datenverwender (einschlieĂlich Analysten, Entwicklern von Machine Learning, Datenbearbeitungsspezialisten und Data Engineers), sondern hat auch direkte Auswirkungen auf die Endprodukte, die von einem qualitativ hochwertigen Machine Learning (ML)-Pipeline abhĂ€ngen. DarĂŒber hinaus wirft der Trend zur Implementierung oder Schaffung von Machine Learning-Plattformen selbstverstĂ€ndlich die Frage auf: Wie sieht Ihre Methode zur internen Entdeckung von Funktionen, Modellen, Kennzahlen, DatensĂ€tzen usw. aus?
In diesem Artikel werden wir erlĂ€utern, wie wir die Datenquelle unter einer offenen Lizenz veröffentlicht haben in unserer Plattform zur Suche und Entdeckung von Metadaten, seit den frĂŒhen Tagen des Projekts . LinkedIn betreibt eine eigene Version von DataHub unabhĂ€ngig von der Open-Source-Version. Wir beginnen damit, zu erklĂ€ren, warum wir zwei separate Entwicklungsumgebungen benötigen, und werden dann die ersten AnsĂ€tze zur Nutzung von WhereHows mit Open Source erörtern und unsere interne (Produktions-)Version von DataHub mit der Version auf vergleichen. Wir werden auch Einzelheiten ĂŒber unsere neue automatisierte Lösung zum Senden und Empfangen von Open Source-Updates teilen, um beide Repositories zu synchronisieren. SchlieĂlich geben wir Anleitungen, wie Sie mit der Open Source-Version von DataHub beginnen können, und besprechen kurz seine Architektur.
WhereHows ist jetzt DataHub!
Das LinkedIn-Metadaten-Team hat zuvor den Nachfolger von WhereHows, die Plattform zur Suche und Entdeckung von Metadaten von LinkedIn, vorgestellt und PlĂ€ne zur Ăffnung damit geteilt. Kurz nach dieser AnkĂŒndigung veröffentlichten wir die Alpha-Version von DataHub und teilten diese mit der Community. Seitdem haben wir kontinuierlich zum Repository beigetragen und mit interessierten Nutzern zusammengearbeitet, um die am meisten nachgefragten Funktionen hinzuzufĂŒgen und Probleme zu beheben. Jetzt freuen wir uns, die offizielle Veröffentlichung von .
Open-Source-AnsÀtze
WhereHows, das ursprĂŒngliche Portal von LinkedIn zur Datensuche und -herkunft, wurde als internes Projekt gestartet; das Metadaten-Team hat den . Seitdem hat das Team stets zwei verschiedene Codebasen unterstĂŒtzt â eine fĂŒr den Open-Source-Code und eine fĂŒr die interne Nutzung bei LinkedIn, da nicht alle Produktfunktionen, die fĂŒr die AnwendungsfĂ€lle von LinkedIn entwickelt wurden, im Allgemeinen fĂŒr ein breiteres Publikum anwendbar waren. DarĂŒber hinaus hat WhereHows einige interne AbhĂ€ngigkeiten (Infrastruktur, Bibliotheken usw.), deren Quellcode nicht öffentlich ist. In den folgenden Jahren durchlief WhereHows zahlreiche Iterationen und Entwicklungszyklen, was die Synchronisation der beiden Codebasen zu einer groĂen Herausforderung machte. Das Metadaten-Team hat ĂŒber die Jahre hinweg versucht, verschiedene AnsĂ€tze zu verfolgen, um die interne Entwicklung und die Open-Source-Entwicklung zu synchronisieren.
Erster Versuch: âZuerst Open Sourceâ
UrsprĂŒnglich folgten wir dem Entwicklungsmodell âzuerst Open Sourceâ, bei dem die Hauptentwicklung in einem Repository fĂŒr Open Source erfolgt und Ănderungen fĂŒr die interne Bereitstellung vorgenommen werden. Das Problem mit diesem Ansatz besteht darin, dass der Code immer zuerst auf GitHub hochgeladen wird, bevor er vollstĂ€ndig intern geprĂŒft wird. Solange keine Ănderungen aus dem Open-Source-Repository vorgenommen werden und kein neues internes Deployment erfolgt, entdecken wir keine Produktionsprobleme. Im Falle eines fehlerhaften Deployments war es zudem sehr schwierig, den Verursacher zu ermitteln, da die Ănderungen in Chargen vorgenommen wurden.
ZusĂ€tzlich hat dieses Modell die ProduktivitĂ€t des Teams bei der Entwicklung neuer Funktionen, die schnelle Iterationen erforderten, verringert, da es erforderte, dass alle Ănderungen zunĂ€chst im Open-Source-Repository vorgenommen und dann in das interne Repository ĂŒbertragen werden. Um die erforderliche Bearbeitungszeit zu verkĂŒrzen, konnten notwendige Korrekturen oder Ănderungen zunĂ€chst im internen Repository erfolgen, was jedoch zu einem enormen Problem wurde, als es darum ging, diese Ănderungen wieder in das Open-Source-Repository einzugliedern, da die beiden Repositories nicht mehr synchron waren.
Dieses Modell ist viel einfacher fĂŒr allgemeine Plattformen, Bibliotheken oder Infrastrukturprojekte umzusetzen als fĂŒr voll funktionsfĂ€hige benutzerdefinierte Webanwendungen. DarĂŒber hinaus eignet sich dieses Modell perfekt fĂŒr Projekte, die von Anfang an mit Open Source beginnen, aber WhereHows wurde als vollstĂ€ndig internes Webanwendungsprojekt entwickelt. Es war wirklich schwierig, sich vollstĂ€ndig von allen internen AbhĂ€ngigkeiten zu abstrahieren, sodass wir eine interne Abspaltung behalten mussten, aber die Beibehaltung einer internen Abspaltung und die Entwicklung hauptsĂ€chlich mit Open Source haben nicht ganz funktioniert.
Zweiter Versuch: âZuerst internâ
** Als zweiten Versuch sind wir zu einem Entwicklungsmodell âzuerst internâ ĂŒbergegangen, bei dem die Hauptentwicklung innerhalb des Unternehmens stattfindet und Ănderungen regelmĂ€Ăig in den Open Source Code ĂŒbernommen werden. Obwohl dieses Modell am besten zu unserem Anwendungsfall passt, bringt es Herausforderungen mit sich. Das direkte Hochladen aller Unterschiede in das Open Source Repository und dann der Versuch, Merge-Konflikte spĂ€ter zu lösen, ist eine Möglichkeit, erfordert aber viel Zeit. Entwickler versuchen in den meisten FĂ€llen, dies bei jeder CodeĂŒberprĂŒfung zu vermeiden. Infolgedessen wird dies viel seltener, in gröĂeren Chargen durchgefĂŒhrt, was die nachtrĂ€gliche Lösung von Merge-Konflikten erschwert.
Beim dritten Mal hat es geklappt!
Die beiden oben genannten erfolglosen Versuche fĂŒhrten dazu, dass das WhereHows-Repository auf GitHub lange Zeit veraltet blieb. Das Team arbeitete weiterhin an der Verbesserung der Funktionen und der Architektur des Produkts, sodass die interne Version von WhereHows fĂŒr LinkedIn immer perfekter wurde als die Open Source-Version. Es hatte sogar einen neuen Namen â DataHub. Basierend auf den vorherigen Misserfolgen entschied das Team, eine skalierbare langfristige Lösung zu entwickeln.
FĂŒr jedes neue Open Source-Projekt berĂ€t und unterstĂŒtzt das Open Source-Entwicklungsteam von LinkedIn ein Entwicklungsmodell, bei dem die Projektmodule vollstĂ€ndig Open Source entwickelt werden. Versionierte Artefakte werden in einem öffentlich zugĂ€nglichen Repository bereitgestellt und dann mit Hilfe von . Die Befolgung dieses Entwicklungsmodells ist nicht nur vorteilhaft fĂŒr diejenigen, die Open-Source-Software verwenden, sondern fĂŒhrt auch zur Schaffung einer modulĂ€reren, erweiterbaren und anpassbaren Architektur.
Um diesen Zustand fĂŒr eine ausgereifte interne Anwendung wie DataHub zu erreichen, wird jedoch eine erhebliche Zeitmenge benötigt. Dies schlieĂt auch die Möglichkeit aus, eine vollstĂ€ndig funktionierende Open-Source-Implementierung bereitzustellen, bevor alle internen AbhĂ€ngigkeiten vollstĂ€ndig abstrahiert sind. Daher haben wir Werkzeuge entwickelt, die uns helfen, schneller und mit weniger Aufwand BeitrĂ€ge zu Open-Source-Projekten zu leisten. Diese Lösung ist sowohl fĂŒr das Metadaten-Team (Entwickler von DataHub) als auch fĂŒr die Open-Source-Community vorteilhaft. In den folgenden Abschnitten wird dieser neue Ansatz erörtert.
Automatisierung der Veröffentlichung mit Open Source
Der letzte Ansatz der Metadaten-Gruppe zum Open-Source-DataHub besteht darin, ein Tool zu entwickeln, das die interne Codebasis und das Open-Source-Repository automatisch synchronisiert. Die hochrangigen Funktionen dieses Werkzeugs umfassen:
- Synchronisierung des LinkedIn-Codes mit / aus dem Open Source, Àhnlich .
- Generierung eines Lizenzkopfs, Àhnlich .
- Automatische Erstellung von Open-Source-Commit-Protokollen aus internen Commit-Protokollen.
- Verhinderung interner Ănderungen, die den Open-Source-Build gefĂ€hrden, durch .
In den folgenden Unterabschnitten werden die oben genannten Funktionen mit interessanten Problemen ausfĂŒhrlich behandelt.
Synchronisierung des Quellcodes
Im Gegensatz zur Open-Source-Version von DataHub, die ein einziges GitHub-Repository darstellt, ist die LinkedIn-Version von DataHub eine Kombination mehrerer Repositories (intern als ). Die DataHub-Schnittstelle, die Bibliothek fĂŒr Metadatenmodelle, der Backend-Dienst fĂŒr das Metadaten-Repository und Streaming-Jobs befinden sich in verschiedenen Repositories bei LinkedIn. Um die Nutzung von Open Source zu erleichtern, haben wir jedoch ein einziges Repository fĂŒr die Open-Source-Version von DataHub.
Abbildung 1: Synchronisierung zwischen Repositories LinkedIn DataHub und einem einzigen Repository DataHub mit offenem Quellcode
Um die automatischen ArbeitsablĂ€ufe fĂŒr den Zusammenbau, das Versenden und das Abrufen zu unterstĂŒtzen, erstellt unser neues Tool automatisch eine dateibasierte Zuordnung, die jeder Quelldatei entspricht. FĂŒr die Nutzung des Tools ist jedoch eine anfĂ€ngliche Konfiguration erforderlich, und die Benutzer mĂŒssen eine hochrangige Zuordnung der Module 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 sind und dessen Werte eine Liste der Quelmodule in den LinkedIn-Repositories darstellen. Jedes Zielmodul im Open-Source-Repository kann von beliebig vielen Quelmodulen gespeist werden. Zur Bezeichnung der internen Repository-Namen in den Quelmodulen wird im Bash-Stil verwendet. Mit der Zuordnungsdatei auf Modulebene erstellen die Tools eine dateibasierte Zuordnungsdatei, 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 dateibasierte Zuordnung wird automatisch von den Tools erstellt; sie kann jedoch auch vom Benutzer manuell aktualisiert werden. Dieses Mapping stellt eine 1:1-Zuordnung der LinkedIn-Quelldatei zu einer Datei im Open-Source-Repository dar. Es gibt einige Regeln, die mit dieser automatischen Erstellung der dateibasierten Zuordnung verbunden sind:
- Bei mehreren Quelmodulen fĂŒr ein Zielmodul im Open Source kann es zu Konflikten kommen, beispielsweise wenn dasselbe , in mehr als einem Quelmodul existiert. Als Strategie zur Konfliktlösung verwenden unsere Tools standardmĂ€Ăig die Regel âder letzte gewinntâ.
- "null" bedeutet, dass die Quelldatei nicht Teil des Open-Source-Repositories ist.
- Nach jeder Ăbermittlung in den offenen Quellcode oder aus ihm heraus wird diese Zuordnung automatisch aktualisiert und ein Schnappschuss erstellt. Dies ist notwendig, um Ănderungen und Löschungen im Quellcode nach der letzten Aktion zu bestimmen.
Erstellung von Commit-Protokollen
Commit-Protokolle fĂŒr Commits mit offenem Quellcode werden ebenfalls automatisch erstellt, indem die Commit-Protokolle interner Repositories zusammengefĂŒhrt werden. Unten sehen Sie ein Beispiel eines Commit-Protokolls, das die Struktur eines von unserem Tool erstellten Commit-Protokolls zeigt. Der Commit zeigt deutlich an, welche Versionen der Quellrepositorien in diesem Commit verpackt sind, und bietet eine Zusammenfassung des Commit-Protokolls. PrĂŒfen Sie dieses an einem realen Beispiel eines Commit-Protokolls, das von unserem Werkzeug erstellt wurde.
metadata-models 29.0.0 -> 30.0.0
HinzugefĂŒgt: Aspektmodell foo
Fehler behoben: bar
dataset-gms 2.3.0 -> 2.3.4
HinzugefĂŒgt: rest.li API zur Bereitstellung des foo-Aspekts
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Testen von AbhÀngigkeiten
LinkedIn hat , die hilft sicherzustellen, dass Ănderungen der internen Multi-Produkt-Umgebung die Builds der abhĂ€ngigen Multi-Produkte nicht beeintrĂ€chtigen. Das DataHub-Repository mit offenem Quellcode ist kein Multi-Produkt und kann nicht von einem Multi-Produkt direkt abhĂ€ngen, aber durch ein Multi-Produkt-Wrapper, das den Quellcode von DataHub mit offenem Quellcode abruft, können wir dieses Testsystem fĂŒr AbhĂ€ngigkeiten trotzdem nutzen. Somit fĂŒhrt jede Ănderung (die möglicherweise spĂ€ter offenbart wird) in einem der Multi-Produkte, die das DataHub-Repository mit offenem Quellcode speisen, ein Build-Ereignis im Multi-Produkt-Wrapper aus. Folglich besteht die Regel, dass jede Ănderung, die das Erstellen des Multi-Produkt-Wrappers verhindert, die Tests vor dem Commit des ursprĂŒnglichen Multi-Produkts nicht besteht und zurĂŒckgewiesen wird.
Dies ist ein nĂŒtzliches Verfahren, das dabei hilft, jeden internen Commit zu verhindern, der den Build des offenen Quellcodes beeintrĂ€chtigt, und ihn wĂ€hrend des Erstellens des Commits zu erkennen. Ohne dies wĂ€re es ziemlich schwierig zu bestimmen, welcher interne Commit zum Build-Ausfall des Repositories mit offenem Quellcode gefĂŒhrt hat, da wir batchmĂ€Ăige interne Ănderungen im DataHub-Repository mit offenem Quellcode ablegen.
Unterschiede zwischen DataHub mit offenem Quellcode und unserer Produktionsversion
Bis zu diesem Zeitpunkt haben wir unsere Lösung zur Synchronisierung von zwei Versionen der DataHub-Repositories besprochen, aber noch nicht die GrĂŒnde definiert, warum wir ĂŒberhaupt zwei verschiedene Entwicklungsschienen benötigen. In diesem Abschnitt listen wir die Unterschiede zwischen der öffentlichen Version von DataHub und der Produktionsversion auf den LinkedIn-Servern auf und erklĂ€ren die GrĂŒnde fĂŒr diese Unterschiede.
Eine der Quellen fĂŒr die Unterschiede ergibt sich aus der Tatsache, dass unsere Produktionsversion von Code abhĂ€ngt, der noch nicht offen ist, wie LinkedIn's Offspring (die interne Struktur zur Implementierung von AbhĂ€ngigkeiten bei LinkedIn). Offspring wird in der internen Codebasis hĂ€ufig verwendet, da es die bevorzugte Methode zur Verwaltung dynamischer Konfiguration ist. Da dies jedoch kein Open Source ist, mussten wir Alternativen mit offenem Quellcode fĂŒr den open-source DataHub finden.
Es gibt auch andere GrĂŒnde. WĂ€hrend wir Metadatenmodell-Erweiterungen fĂŒr die BedĂŒrfnisse von LinkedIn erstellen, sind diese Erweiterungen in der Regel sehr spezifisch fĂŒr LinkedIn und lassen sich möglicherweise nicht direkt auf andere Umgebungen anwenden. Zum Beispiel haben wir sehr spezifische Labels fĂŒr Teilnehmer-IDs und andere Arten von MetadatenĂŒbereinstimmungen. Daher haben wir diese Erweiterungen derzeit aus dem Metadatenmodell des open-source DataHub ausgeschlossen. WĂ€hrend wir mit der Community interagieren und ihre BedĂŒrfnisse verstehen, werden wir an allgemeinen Versionen dieser Erweiterungen mit offenem Quellcode arbeiten, wo dies erforderlich ist.
Die Benutzerfreundlichkeit und eine einfachere Anpassung fĂŒr die Open-Source-Community haben auch einige Unterschiede zwischen den beiden Versionen von DataHub inspiriert. Unterschiede in der Streaming-Verarbeitungsinfrastruktur sind ein gutes Beispiel dafĂŒr. WĂ€hrend unsere interne Version eine Infrastruktur fĂŒr verwaltete Streaming-Verarbeitung nutzt, haben wir uns entschieden, fĂŒr die Open-Source-Version eine integrierte (autonome) Streaming-Verarbeitung zu verwenden, da dies weitere InfrastrukturabhĂ€ngigkeiten vermeidet.
Ein weiteres Beispiel fĂŒr den Unterschied ist die Existenz eines GMS (Generisches Metadaten-Repository) in der Open-Source-Implementierung, anstelle mehrerer GMS. GMA (Generische Metadatenarchitektur) ist der Name der internen Architektur fĂŒr DataHub, wĂ€hrend GMS das Metadatenrepository im Kontext von GMA ist. GMA ist eine sehr flexible Architektur, die es Ihnen ermöglicht, jede Datenstruktur (z. B. DatensĂ€tze, Benutzer usw.) in ein eigenes Metadatenrepository zu verteilen oder mehrere Datenstrukturen in einem einzigen Metadatenrepository zu speichern, solange das Verzeichnis, das die Zuordnung der Datenstruktur zu GMS enthĂ€lt, aktualisiert wird. Zur Vereinfachung haben wir eine Instanz von GMS gewĂ€hlt, die alle verschiedenen Datenstrukturen im Open-Source-DataHub speichert.
Die vollstÀndige Liste der Unterschiede zwischen den beiden Implementierungen finden Sie in der Tabelle unten.
Produktmerkmale
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) Vector 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Stream-Verarbeitung
Verwaltet
Eingebettet (eigenstÀndig)
Dependency Injection & Dynamische Konfiguration
LinkedIn Offspring
Build-Tools
Ligradle (LinkedInâs interner Gradle-Wrapp)
CI/CD
CRT (LinkedInâs interne CI/CD)
and
MetadatenstÀnde
Verteilte mehrere GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Einzelnes GMS fĂŒr: 1) DatensĂ€tze 2) Benutzer
Mikroservices in Docker-Containern
vereinfachen das Bereitstellen und Verteilen von Anwendungen mithilfe von Jeder Teil des Dienstes im Open-Source-DataHub, einschlieĂlich Infrastrukturkomponenten wie Kafka, , und , hat sein eigenes Docker-Image. FĂŒr die Orchestrierung der Docker-Container haben wir verwendet .
Abbildung 2: Architektur DataHub *Open Source*
Sie können die hochrangige Architektur von DataHub auf dem Bild oben sehen. Neben den Infrastrukturkomponenten hat es vier verschiedene Docker-Container:
datahub-gms: Metadatenrepository-Dienst
datahub-frontend: Anwendung , die die DataHub-OberflÀche bereitstellt.
datahub-mce-consumer: Anwendung , die den Ănderungsereignisstrom von Metadaten (MCE) verwendet und das Metadatenrepository aktualisiert.
datahub-mae-consumer: Anwendung , die den Audit-Eventstrom von Metadaten (MAE) verwendet und eine Suchindex- und Graphdatenbank erstellt.
Dokumentation zum Open-Source-Repository und enthĂ€lt detailliertere Informationen ĂŒber die Funktionen verschiedener Dienste.
CI / CD in DataHub mit Open Source
Das Open-Source-Repository von DataHub verwendet fĂŒr die kontinuierliche Integration und fĂŒr das kontinuierliche Deployment. Beide haben eine gute Integration mit GitHub und sind einfach einzurichten. FĂŒr den GroĂteil der Open-Source-Infrastruktur, die von der Community oder von privaten Unternehmen (z.B. ), wurden Docker-Images erstellt, die im Docker Hub bereitgestellt werden, um die Nutzung fĂŒr die Community zu vereinfachen. Jedes Docker-Image, das im Docker Hub gefunden wird, kann einfach mit einem einfachen Befehl verwendet werden. .
Bei jedem Commit im Open-Source-Repository von DataHub werden alle Docker-Images automatisch erstellt und im Docker Hub mit dem Tag âlatestâ bereitgestellt. Wenn im Docker Hub eine , werden alle Tags im Open-Source-Repository ebenfalls mit den entsprechenden Tag-Namen im Docker Hub veröffentlicht.
Nutzung von DataHub
ist sehr einfach und besteht aus drei einfachen Schritten:
- Klonen Sie das Open-Source-Repository und starten Sie alle Docker-Container mit docker-compose unter Verwendung des bereitgestellten Docker-Compose-Skripts fĂŒr eine schnelle Einrichtung.
- Laden Sie die im Repository bereitgestellten Beispieldaten mit dem ebenfalls bereitgestellten Kommandozeilenwerkzeug herunter.
- Durchsuchen Sie DataHub in Ihrem Browser.
Ein aktiver ist ebenfalls eingerichtet fĂŒr schnelle Fragen. Benutzer können auch direkt im GitHub-Repository Issues erstellen. Am wichtigsten ist, dass wir alle RĂŒckmeldungen und VorschlĂ€ge willkommen heiĂen und schĂ€tzen!
ZukunftsplÀne
Derzeit wird jede Infrastruktur oder Mikrodienst fĂŒr DataHub mit Open Source als Docker-Container aufgebaut, und das gesamte System wird mithilfe von orchestriert. In Anbetracht der Beliebtheit und breiten VerfĂŒgbarkeit möchten wir auch bald eine auf Kubernetes basierende Lösung anbieten.
Wir planen auch, eine schlĂŒsselfertige Lösung fĂŒr die Bereitstellung von DataHub in einem öffentlichen Cloud-Dienst wie , oder anzubieten. Angesichts der jĂŒngsten AnkĂŒndigung von LinkedIn zur Migration zu Azure wird dies den internen PrioritĂ€ten der Metadaten-Gruppe entsprechen.
Und zuletzt, aber nicht weniger wichtig: Vielen Dank an alle ersten Benutzer von DataHub in der Open-Source-Community, die die Alpha-Versionen von DataHub geschÀtzt und uns geholfen haben, Probleme zu identifizieren und die Dokumentation zu verbessern.
Quelle: habr.com
