Open Source DataHub: LinkedIn's Metadaten Sich an Entdeckungsplattform
D'Donnéeën ze fannen déi Dir braucht séier ze fannen ass essentiell fir all Firma déi op grouss Quantitéiten un Daten hänkt fir date-driven Entscheedungen ze treffen. Dëst beaflosst net nëmmen d'Produktivitéit vun Daten Benotzer (inklusiv Analysten, Maschinn Léieren Entwéckler, Datewëssenschaftler, an Dateingenieuren), awer et huet och en direkten Impakt op d'Endprodukter, déi vun enger Qualitéit Maschinn Léieren (ML) Pipeline ofhänken. Zousätzlech stellt den Trend fir Maschinnléierplattformen ëmzesetzen oder ze bauen natierlech d'Fro op: wat ass Är Method fir intern Features, Modeller, Metriken, Datesätz z'entdecken, etc.
An dësem Artikel schwätze mir iwwer wéi mir eng Datequell ënner enger oppener Lizenz publizéiert hunn an eiser Metadaten Sich an Entdeckung Plattform, ugefaange vun de fréie Deeg vum Projet . LinkedIn hält seng eege Versioun vum DataHub getrennt vun der Open Source Versioun. Mir fänken u mat ze erklären firwat mir zwee separat Entwécklungsëmfeld brauchen, diskutéieren dann fréi Approche fir d'Open Source WhereHows ze benotzen a vergläichen eis intern (Produktioun) Versioun vum DataHub mat der Versioun op . Mir deelen och Detailer iwwer eis nei automatiséiert Léisung fir Open Source Updates ze drécken an ze kréien fir béid Repositories synchroniséiert ze halen. Schlussendlech wäerte mir Instruktiounen ubidden wéi Dir mat der Open Source DataHub unzefänken a kuerz iwwer seng Architektur diskutéieren.
WhereHows ass elo en DataHub!
LinkedIn's Metadatenteam virdru virgestallt (Nofolger vun WhereHows), LinkedIn Sich- a Metadaten-Entdeckungsplattform, a gemeinsame Pläng fir se opzemaachen. Kuerz no dëser Ukënnegung hu mir eng Alpha Versioun vum DataHub verëffentlecht an et mat der Gemeinschaft gedeelt. Zënterhier hu mir kontinuéierlech zum Repository bäigedroen a mat interesséierte Benotzer geschafft fir déi meescht ugefrote Funktiounen derbäi ze ginn a Probleemer ze léisen. Mir sinn elo frou déi offiziell Verëffentlechung matzedeelen .
Open Source Approche
WhereHows, dem LinkedIn säin originelle Portal fir Daten ze fannen a wou se hierkënnt, huet als internen Projet ugefaang; d'Metadatenteam huet et opgemaach . Zënterhier huet d'Team ëmmer zwou verschidde Codebasen behalen - eng fir Open Source an eng fir den internen Gebrauch vun LinkedIn - well net all Produktfeatures, déi fir LinkedIn Benotzungsfäll entwéckelt goufen, allgemeng fir de breede Publikum applicabel waren. Zousätzlech, WhereHows huet e puer intern Ofhängegkeeten (Infrastruktur, Bibliothéiken, etc.) déi net Open Source sinn. An de Joeren duerno, WhereHows ass duerch vill Iteratiounen an Entwécklungszyklen gaang, wouduerch déi zwee Codebasen an der Synchroniséierung eng grouss Erausfuerderung halen. D'Metadatenteam huet iwwer d'Jore verschidde Approche probéiert fir ze probéieren intern an Open Source Entwécklung synchroniséiert ze halen.
Éischt Versuch: "Open Source éischt"
Mir hunn am Ufank en "Open Source First" Entwécklungsmodell gefollegt, wou déi meescht Entwécklung an engem Open Source Repository geschitt an Ännerungen fir intern Deployment gemaach ginn. De Problem mat dëser Approche ass datt de Code ëmmer fir d'éischt op GitHub gedréckt gëtt ier en intern komplett iwwerpréift gouf. Bis Ännerungen aus dem Open Source Repository gemaach ginn an eng nei intern Deployment gemaach gëtt, fanne mir keng Produktiounsprobleemer. Am Fall vun engem schlechten Asaz war et och ganz schwéier den Täter ze bestëmmen, well Ännerungen a Chargen gemaach goufen.
Zousätzlech huet dëse Modell d'Produktivitéit vum Team reduzéiert wann se nei Features entwéckelt hunn, déi séier Iteratiounen erfuerderen, well et all Ännerungen gezwongen huet fir d'éischt an en Open Source Repository gedréckt ze ginn an duerno an en internen Repository gedréckt ze ginn. Fir d'Veraarbechtungszäit ze reduzéieren, konnt déi erfuerderlech Fixéierung oder Ännerung als éischt am internen Repository gemaach ginn, awer dëst gouf e grousse Problem wann et drëm komm ass fir dës Ännerungen zréck an den Open Source Repository ze fusionéieren well déi zwee Repositories aus der Synchroniséierung waren.
Dëse Modell ass vill méi einfach ze implementéieren fir gemeinsame Plattformen, Bibliothéiken oder Infrastrukturprojeten wéi fir voll Feature personaliséiert Webapplikatiounen. Zousätzlech ass dëse Modell ideal fir Projeten déi Open Source vum Dag starten, awer WhereHows gouf als komplett intern Webapplikatioun gebaut. Et war wierklech schwéier all intern Ofhängegkeeten komplett abstrakéieren ze loossen, sou datt mir déi intern Gabel musse behalen, awer déi intern Gabel halen an haaptsächlech Open Source entwéckelen huet net ganz geklappt.
Zweete Versuch: "Inner éischt"
** Als zweete Versuch si mir op en "intern éischt" Entwécklungsmodell geplënnert, wou déi meescht Entwécklung intern geschitt an Ännerungen am Open Source Code regelméisseg gemaach ginn. Och wann dëse Modell am Beschten fir eise Gebrauchsfall gëeegent ass, huet et inherent Probleemer. Direkt all Differenzen op den Open Source Repository drécken an dann probéieren d'Fusiounskonflikter méi spéit ze léisen ass eng Optioun, awer et ass Zäitopwendeg. Entwéckler an de meeschte Fäll probéieren dëst net all Kéier wann se hire Code iwwerpréiwen. Als Resultat gëtt dëst vill manner dacks gemaach, a Chargen, a mécht et also méi schwéier fir Konflikter méi spéit ze léisen.
Déi drëtte Kéier huet et geschafft!
Déi zwee gescheitert Versich uewe genannten hunn dozou gefouert datt de WhereHows GitHub Repository fir eng laang Zäit aus dem Datum bleift. D'Team huet weider d'Features an d'Architektur vum Produkt verbessert, sou datt déi intern Versioun vu WhereHows fir LinkedIn méi fortgeschratt gouf wéi d'Open Source Versioun. Et hat souguer en neien Numm - DataHub. Baséierend op fréiere gescheitert Versich, huet d'Team decidéiert eng skalierbar, laangfristeg Léisung z'entwéckelen.
Fir all neien Open Source Projet beréit an ënnerstëtzt d'Linkedin Open Source Team en Entwécklungsmodell an deem d'Module vum Projet ganz an Open Source entwéckelt ginn. Versionéiert Artefakte ginn op en ëffentleche Repository ofgesat an dann zréck an den internen LinkedIn Artefakt iwwerpréift mat . No dësem Entwécklungsmodell ass net nëmme gutt fir déi, déi Open Source benotzen, mee resultéiert och zu enger méi modulärer, erweiterbarer a pluggbarer Architektur.
Wéi och ëmmer, eng reife Back-End Applikatioun wéi DataHub erfuerdert eng bedeitend Zäit fir dësen Zoustand z'erreechen. Dëst schléisst och d'Méiglechkeet aus fir eng voll funktionéierend Ëmsetzung opzemaachen ier all intern Ofhängegkeete komplett abstrakéiert goufen. Dofir hu mir Tools entwéckelt déi eis hëllefen Open Source Bäiträg méi séier a mat vill manner Péng ze maachen. Dës Léisung profitéiert souwuel d'Metadatenteam (DataHub Entwéckler) wéi och d'Open Source Gemeinschaft. Déi folgend Rubriken wäerten dës nei Approche diskutéieren.
Open Source Publishing Automation
Déi lescht Approche vum Metadata Team zum Open Source DataHub ass en Tool z'entwéckelen dat automatesch déi intern Codebase an den Open Source Repository synchroniséiert. High-level Features vun dësem Toolkit enthalen:
- Synchroniséiert LinkedIn Code op / vun Open Source, ähnlech .
- Lizenz Header Generatioun, ähnlech wéi .
- Generéiere automatesch Open Source commit Logs aus internen commit Logs.
- Verhënnert intern Ännerungen déi Open Source Builds duerchbriechen .
Déi folgend Ënnersektiounen verdéiwen an déi uewe genannte Funktiounen déi interessant Problemer hunn.
Quelltext Synchroniséierung
Am Géigesaz zu der Open Source Versioun vum DataHub, wat en eenzegen GitHub Repository ass, ass d'Linkedin Versioun vum DataHub eng Kombinatioun vu multiple Repositories (intern genannt) ). D'DataHub Interface, Metadatenmodellbibliothéik, Metadaten Warehouse Backend Service, a Streaming Jobs wunnen an getrennten Repositories op LinkedIn. Wéi och ëmmer, fir Open Source Benotzer méi einfach ze maachen, hu mir en eenzege Repository fir d'Open Source Versioun vun DataHub.
Figur 1: Synchroniséierung tëscht Repositories LinkedIn DataHub an engem eenzege Repository DataHub oppe Quell
Fir automatiséiert Bau-, Push- a Pull-Workflows z'ënnerstëtzen, erstellt eisen neien Tool automatesch eng Datei-Niveau Mapping entsprécht all Quelldatei. Wéi och ëmmer, den Toolkit erfuerdert eng initial Konfiguratioun an d'Benotzer mussen eng Héichniveau Modulmapping ubidden wéi hei ënnendrënner.
{
"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"
]
}De Modul-Niveau Mapping ass en einfachen JSON deem seng Schlësselen d'Zilmoduler am Open Source Repository sinn an d'Wäerter sinn d'Lëscht vun de Quellmodulen an de LinkedIn Repositories. All Zilmodul an engem Open Source Repository ka vun all Zuel vu Quellmoduler gefüttert ginn. Fir déi intern Nimm vu Repositories a Quellmoduler unzeginn, benotzt am Bash-Stil. Mat enger Modul-Niveau Mapping-Datei erstellen d'Tools eng Datei-Niveau Mapping-Datei andeems Dir all Dateien an assoziéierte Verzeichnisser scannt.
{
"${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,
}D'Dateiniveau Mapping gëtt automatesch vun den Tools erstallt; et kann awer och manuell vum Benotzer aktualiséiert ginn. Dëst ass eng 1:1 Mapping vun enger LinkedIn Quelldatei op eng Datei am Open Source Repository. Et gi verschidde Reegele mat dëser automatescher Schafung vun Dateiassociatiounen assoziéiert:
- Am Fall vu multiple Quellmoduler fir en Zilmodul an Open Source kënnen Konflikter entstoen, z.B , existéierend a méi wéi engem Quellmodul. Als Konfliktléisungsstrategie sinn eis Tools Standard op d'Optioun "Leschte gewënnt".
- "null" heescht datt d'Quelldatei net Deel vum Open Source Repository ass.
- No all Open Source Soumissioun oder Extraktioun gëtt dës Mapping automatesch aktualiséiert an e Snapshot gëtt erstallt. Dëst ass néideg fir Ergänzunge a Läschen aus dem Quellcode zanter der leschter Handlung z'identifizéieren.
Engagement Logbicher erstellen
Engagement Logbicher fir Open Source Verpflichtungen ginn och automatesch generéiert andeems d'Verpflichtungsprotokoller vun internen Repositories fusionéieren. Drënner ass e Probe Verpflichtungslog fir d'Struktur vum Engagement Log ze weisen, deen vun eisem Tool generéiert gëtt. Eng Verpflichtung weist kloer un wéi eng Versioune vun de Quellrepositories an deem Verpflichtung verpackt sinn a liwwert e Resumé vum Verpflichtungslog. Check dës eraus mat engem richtege Beispill vun engem Verpflichtungsprotokoll generéiert vun eisem Toolkit.
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.0Ofhängegkeet Testen
LinkedIn huet , wat hëlleft sécherzestellen datt Ännerungen an engem internen Multiprodukt d'Versammlung vun ofhängege Multiprodukte net briechen. Den Open Source DataHub Repository ass kee Multi-Produkt, an et kann net eng direkt Ofhängegkeet vun engem Multi-Produkt sinn, awer mat der Hëllef vun engem Multi-Produkt Wrapper deen den Open Source DataHub Quellcode hëlt, kënne mir nach ëmmer dës Ofhängegkeetstest benotzen Also, all Ännerung (déi spéider ausgesat ka ginn) zu engem vun de Multiprodukter, déi den Open Source DataHub Repository fidderen, e Build Event am Shell Multiprodukt ausléisen. Dofir fällt all Ännerung, déi et net fäerdeg bréngt e Wrapperprodukt ze bauen, d'Tester ier en d'Originalprodukt engagéiert a gëtt zréckgezunn.
Dëst ass en nëtzlechen Mechanismus deen hëlleft all intern Engagement ze verhënneren, deen den Open Source Build brécht an et zu der Verpflichtungszäit erkennt. Ouni dëst wier et zimmlech schwéier ze bestëmmen wéi eng intern Verpflichtung den Open Source Repository Build versoen huet, well mir intern Ännerungen am DataHub Open Source Repository batchéieren.
Differenzen tëscht Open Source DataHub an eiser Produktiounsversioun
Bis zu dësem Zäitpunkt hu mir eis Léisung fir d'Synchroniséierung vun zwou Versiounen vun DataHub Repositories diskutéiert, awer mir hunn nach ëmmer net d'Grënn beschriwwen firwat mir an der éischter Plaz zwee verschidden Entwécklungsstroum brauchen. An dëser Sektioun wäerte mir d'Ënnerscheeder tëscht der ëffentlecher Versioun vum DataHub an der Produktiounsversioun op LinkedIn Serveren oplëschten an d'Grënn fir dës Differenzen erklären.
Eng Quell vun Diskrepanz staamt aus der Tatsaach datt eis Produktiounsversioun Ofhängegkeete vu Code huet deen nach net Open Source ass, sou wéi LinkedIn's Offspring (LinkedIn internen Ofhängegkeet Injektiouns Kader). Offspring gëtt vill an internen Codebasen benotzt well et déi bevorzugt Method ass fir dynamesch Konfiguratioun ze managen. Awer et ass net Open Source; also musse mir Open Source Alternativen zu der Open Source DataHub fannen.
Et ginn och aner Grënn. Wéi mir Extensiounen op de Metadatenmodell fir d'Bedierfnesser vun LinkedIn erstellen, sinn dës Extensiounen typesch ganz spezifesch fir LinkedIn a kënnen net direkt op aner Ëmfeld gëllen. Zum Beispill hu mir ganz spezifesch Etiketten fir Participant IDen an aner Zorte vu passende Metadaten. Also, mir hunn elo dës Extensiounen aus dem DataHub Open Source Metadatenmodell ausgeschloss. Wéi mir mat der Gemeinschaft engagéieren an hir Bedierfnesser verstoen, wäerte mir un gemeinsame Open Source Versioune vun dësen Extensiounen schaffen, wou néideg.
Einfach ze benotzen a méi einfach Adaptatioun fir d'Open Source Gemeinschaft inspiréiert och e puer vun den Ënnerscheeder tëscht den zwou Versiounen vun DataHub. Differenzen an der Stroumveraarbechtungsinfrastruktur sinn e gutt Beispill dovun. Och wann eis intern Versioun e verwalteten Streamveraarbechtungsframework benotzt, hu mir gewielt fir eng agebaute (standalone) Streamveraarbechtung fir d'Open Source Versioun ze benotzen, well et vermeit eng aner Infrastrukturabhängegkeet ze kreéieren.
En anert Beispill vum Ënnerscheed ass en eenzegen GMS (Generalized Metadata Store) an enger Open Source Implementatioun ze hunn anstatt verschidde GMSen. GMA (Generalized Metadata Architecture) ass den Numm vun der Back-End Architektur fir DataHub, an GMS ass de Metadatengeschäft am Kontext vu GMA. GMA ass eng ganz flexibel Architektur déi Iech erlaabt all Datekonstruktioun (zB Datesätz, Benotzer, asw.) an säin eegene Metadatengeschäft ze verdeelen, oder multiple Datekonstruktiounen an engem eenzegen Metadatengeschäft ze späicheren soulaang de Registry enthält d'Datenstruktur Mapping an GMS gëtt aktualiséiert. Fir einfach ze benotzen hu mir eng GMS Instanz gewielt déi all déi verschidden Datekonstruktiounen an der Open Source DataHub späichert.
Eng komplett Lëscht vun Differenzen tëscht den zwou Implementatioune gëtt an der Tabell hei ënnen uginn.
Produkt Features
LinkedIn DataHub
Open Source DataHub
Ënnerstëtzt Data Konstruktiounen
1) Datesets 2) Benotzer 3) Metriken 4) ML Features 5) Charts 6) Dashboards
1) Datesets 2) Benotzer
Ënnerstëtzt Metadatenquellen fir Datesets
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
Konfluent Kafka
Stream Veraarbechtung
wonnerbar
Embedded (standalone)
Ofhängegkeet Injektioun & dynamesch Konfiguratioun
LinkedIn Nofolger
Bauen Tooling
Ligradle (LinkedIn internen Gradle Wrapper)
CI / CD
CRT (LinkedIn internen CI/CD)
an
Metadaten Stores
Multiple GMS verdeelt: 1) Dataset GMS 2) Benotzer GMS 3) Metresch GMS 4) Feature GMS 5) Chart/Dashboard GMS
Single GMS fir: 1) Datesets 2) Benotzer
Mikroservicer an Docker Container
vereinfacht Applikatioun Détachement a Verdeelung mat . All Deel vum Service am DataHub ass Open Source, och Infrastrukturkomponenten wéi Kafka, , и , huet säin eegent Docker-Bild. Fir Docker Container ze orchestréieren hu mir benotzt .
Figur 2: Architektur DataHub *Open Source**
Dir kënnt d'High-Level Architektur vun DataHub am Bild hei uewen gesinn. Nieft den Infrastrukturkomponenten huet et véier verschidden Docker Container:
datahub-gms: Metadatenlagerservice
datahub-frontend: Applikatioun , Déngscht der DataHub Interface.
datahub-mce-consumer: Applikatioun , déi de Metadaten Changement Event (MCE) Stream benotzt an de Metadaten Store aktualiséiert.
datahub-mae-consumer: Applikatioun , déi e Metadaten Audit Event Stream (MAE) benotzt an e Sichindex a Grafikdatenbank erstellt.
Open Source Repository Dokumentatioun an enthalen méi detailléiert Informatiounen iwwer d'Funktioune vu verschiddene Servicer.
CI / CD op DataHub ass Open Source
Den Open Source DataHub Repository benotzt fir kontinuéierlech Integratioun an fir kontinuéierlech Asaz. Béid hu gutt GitHub Integratioun a si einfach opzestellen. Fir déi meescht Open Source Infrastrukturen entwéckelt vun der Gemeinschaft oder privaten Firmen (z. ), Docker Biller ginn erstallt an op Docker Hub ofgesat fir d'Benotzung vun der Gemeinschaft einfach ze benotzen. All Docker Bild am Docker Hub fonnt ka ganz einfach mat engem einfachen Kommando benotzt ginn .
Mat all Engagement fir den DataHub Open Source Repository, ginn all Docker Biller automatesch gebaut an op Docker Hub mat dem "läschte" Tag ofgesat. Wann Docker Hub mat e puer konfiguréiert ass , all Tags am Open Source Repository ginn och mat entspriechend Tag Nimm am Docker Hub verëffentlecht.
Benotzt DataHub
ass ganz einfach a besteet aus dräi einfache Schrëtt:
- Klon den Open Source Repository a fuert all Docker Container mat Docker-compose mat dem ugebueden Docker-compose Skript fir e schnelle Start.
- Luet d'Proufdaten, déi am Repository zur Verfügung gestallt ginn, mat dem Kommandozeilinstrument dat och geliwwert gëtt.
- Browst DataHub an Ärem Browser.
Aktiv verfollegt och fir séier Froen konfiguréiert. D'Benotzer kënnen och Themen direkt am GitHub Repository erstellen. Virun allem, mir begréissen a schätzen all Feedback a Virschléi!
Pläng fir d'Zukunft
De Moment ass all Infrastruktur oder Mikroservice fir Open Source DataHub als Docker Container gebaut, an de ganze System ass orchestréiert mat . Kritt der Popularitéit a verbreet , mir wëllen och an der nächster Zukunft eng Kubernetes-baséiert Léisung ubidden.
Mir plangen och eng schlësselfäerdeg Léisung ze bidden fir DataHub op engem ëffentleche Cloud Service z , oder . Mat der rezenter Ukënnegung vun der Migratioun vu LinkedIn op Azure, wäert dëst mat den internen Prioritéite vum Metadatenteam ausriichten.
Lescht awer net zulescht, merci un all déi fréi Adoptateuren vun DataHub an der Open Source Gemeinschaft déi DataHub Alphas bewäert hunn an eis gehollef hunn Themen z'identifizéieren an d'Dokumentatioun ze verbesseren.
Source: will.com