Open Source DataHub: LinkedIn's Metadata Search and Discovery Platform
It finen fan de gegevens dy't jo nedich binne fluch is essensjeel foar elk bedriuw dat fertrout op grutte hoemannichten gegevens om gegevens-oandreaune besluten te nimmen. Dit hat net allinich ynfloed op de produktiviteit fan gegevensbrûkers (ynklusyf analisten, ûntwikkelders foar masine-learen, gegevenswittenskippers en gegevens-yngenieurs), mar it hat ek in direkte ynfloed op 'e einprodukten dy't ôfhinklik binne fan in pipeline fan kwaliteit masine learen (ML). Derneist ropt de trend nei it ymplementearjen of bouwen fan masine-learplatfoarms de fraach op: wat is jo metoade foar ynterne ûntdekking fan funksjes, modellen, metriken, datasets, ensfh.
Yn dit artikel sille wy prate oer hoe't wy publisearre in gegevens boarne ûnder in iepen lisinsje yn ús platfoarm foar sykjen en ûntdekking fan metadata, begjinnend fan 'e iere dagen fan it projekt . LinkedIn ûnderhâldt har eigen ferzje fan DataHub apart fan 'e iepen boarne ferzje. Wy sille begjinne mei út te lizzen wêrom't wy twa aparte ûntwikkelomjouwings nedich binne, besprekke dan iere oanpakken foar it brûken fan de iepen boarne WhereHows en fergelykje ús ynterne (produksje) ferzje fan DataHub mei de ferzje op . Wy sille ek details diele oer ús nije automatisearre oplossing foar it pushen en ûntfangen fan iepen boarne updates om beide repositories syngronisearre te hâlden. Uteinlik sille wy ynstruksjes leverje oer hoe't jo kinne begjinne mei it brûken fan de iepen boarne DataHub en koart besprekke de arsjitektuer.
WhereHows is no in DataHub!
It metadatateam fan LinkedIn earder presintearre (opfolger fan WhereHows), LinkedIn's syk- en metadata-ûntdekkingsplatfoarm, en dielde plannen om it te iepenjen. Koart nei dizze oankundiging hawwe wy in alfaferzje fan DataHub frijlitten en dielde mei de mienskip. Sûnt dy tiid hawwe wy kontinu bydroegen oan it repository en wurke mei ynteressearre brûkers om de meast frege funksjes ta te foegjen en problemen op te lossen. Wy binne no bliid om de offisjele release oan te kundigjen .
Open Source Approaches
WhereHows, it orizjinele portaal fan LinkedIn foar it finen fan gegevens en wêr't it weikomt, begon as in ynterne projekt; it metadatateam iepene it . Sûnt dy tiid hat it team altyd twa ferskillende koadebases ûnderhâlden - ien foar iepen boarne en ien foar ynterne gebrûk fan LinkedIn - om't net alle produktfunksjes ûntwikkele foar LinkedIn gebrûksgefallen oer it algemien fan tapassing wiene op it bredere publyk. Dêrnjonken hat WhereHows wat ynterne ôfhinklikens (ynfrastruktuer, biblioteken, ensfh.) dy't net iepen boarne binne. Yn 'e jierren dy't folgen, gie WhereHows troch in protte iteraasjes en ûntwikkelingssyklusen, wêrtroch it hâlden fan de twa koadebasen syngronisearje in grutte útdaging. It metadatateam hat yn 'e rin fan' e jierren ferskate oanpak besocht om te besykjen om ynterne en iepen boarne-ûntwikkeling yn syngronisaasje te hâlden.
Earste poging: "Earst iepen boarne"
Wy folgen ynearsten in "iepen boarne earst" ûntwikkelingsmodel, wêrby't de measte ûntwikkeling plakfynt yn in iepen boarne repository en wizigingen wurde makke foar ynterne ynset. It probleem mei dizze oanpak is dat de koade altyd earst nei GitHub wurdt skood foardat it yntern folslein hifke is. Oant feroarings wurde makke fanút it iepen boarne repository en in nije ynterne ynset wurdt makke, sille wy gjin produksjeproblemen fine. By minne ynset wie it ek hiel lestich om de dieder te bepalen, om't der yn batches feroarings makke waarden.
Derneist fermindere dit model de produktiviteit fan it team by it ûntwikkeljen fan nije funksjes dy't rappe iteraasjes easke, om't it twong om alle wizigingen earst yn in iepen boarne repository te skowen en dan nei in ynterne repository te skowen. Om de ferwurkingstiid te ferminderjen, koe de fereaske fix of feroaring earst dien wurde yn it ynterne repository, mar dit waard in enoarm probleem as it gie om it gearfoegjen fan dy wizigingen werom yn it iepen boarne repository, om't de twa repositories net syngronisearre wiene.
Dit model is folle makliker te ymplementearjen foar dielde platfoarms, biblioteken of ynfrastruktuerprojekten dan foar oanpaste webapplikaasjes mei folsleine funksjes. Derneist is dit model ideaal foar projekten dy't iepen boarne begjinne fan dei ien, mar WhereHows waard boud as in folslein ynterne webapplikaasje. It wie echt lestich om alle ynterne ôfhinklikens folslein te abstraheren, dus wy moasten de ynterne foarke hâlde, mar it hâlden fan de ynterne foarke en it ûntwikkeljen fan meast iepen boarne wurke net hielendal út.
Twadde poging: "Inner earst"
** As twadde besykjen binne wy ferhuze nei in "ynterne earste" ûntwikkelingsmodel, wêr't de measte ûntwikkeling yn eigen hûs plakfynt en feroarings wurde makke oan 'e iepen boarne koade op in reguliere basis. Hoewol dit model it meast geskikt is foar ús gebrûk, hat it ynherinte problemen. Alle ferskillen direkt nei it iepen boarne-repository drukke en dan besykje om fúzjekonflikten letter op te lossen is in opsje, mar it is tiidslinend. Untwikkelders besykje dit yn 'e measte gefallen net te dwaan elke kear as se har koade besjen. Dêrtroch sil dat folle minder dien wurde, yn batches, en makket it sadwaande dreger om fúzjekonflikten letter op te lossen.
De tredde kear wurke it!
De hjirboppe neamde twa mislearre besykjen resultearren yn dat it WhereHows GitHub-repository in lange tiid ferâldere bleau. It team bleau de funksjes en arsjitektuer fan it produkt te ferbetterjen, sadat de ynterne ferzje fan WhereHows foar LinkedIn mear avansearre waard dan de iepen boarne ferzje. It hie sels in nije namme - DataHub. Op grûn fan eardere mislearre besykjen besleat it team in skalberbere oplossing op lange termyn te ûntwikkeljen.
Foar elk nij iepen boarne-projekt advisearret en stipet it iepen boarne-team fan LinkedIn in ûntwikkelingsmodel wêryn de modules fan it projekt folslein yn iepen boarne ûntwikkele wurde. Ferzjearde artefakten wurde ynset nei in iepenbier repository en dan werom kontrolearre yn in ynterne LinkedIn artefakt mei . It folgjen fan dit ûntwikkelingsmodel is net allinich goed foar dyjingen dy't iepen boarne brûke, mar resultearret ek yn in mear modulêre, útbreidbere en pluggable arsjitektuer.
In folwoeksen back-end-applikaasje lykas DataHub sil lykwols in wichtige hoemannichte tiid fereaskje om dizze steat te berikken. Dit slút ek de mooglikheid foar iepen boarnen fan in folslein wurkjende ymplemintaasje foar foardat alle ynterne ôfhinklikens folslein abstrahearre binne. Dêrom hawwe wy ark ûntwikkele dy't ús helpe om iepen boarne bydragen rapper en mei folle minder pine te leverjen. Dizze oplossing profiteart sawol it metadatateam (DataHub-ûntwikkelder) as de iepen boarne-mienskip. De folgjende seksjes sille dizze nije oanpak besprekke.
Open Source Publishing Automatisearring
De lêste oanpak fan it Metadata-team foar de iepen boarne DataHub is om in ark te ûntwikkeljen dat de ynterne koadebase en it iepen boarne repository automatysk syngroniseart. Funksjes op hege nivo fan dizze toolkit omfetsje:
- Syngronisearje LinkedIn-koade nei/fan iepen boarne, ferlykber .
- Lisinsje header generaasje, fergelykber mei .
- Generearje automatysk iepen boarne commit logs út ynterne commit logs.
- Foarkom ynterne wizigingen dy't iepen boarne builds trochbrekke .
De folgjende subseksjes sille dûke yn 'e boppeneamde funksjes dy't ynteressante problemen hawwe.
Boarnekoade syngronisaasje
Oars as de iepen boarne ferzje fan DataHub, dat is in inkele GitHub repository, de LinkedIn ferzje fan DataHub is in kombinaasje fan meardere repositories (neamd yntern ). De DataHub-ynterface, metadata-modelbibleteek, metadata warehouse backend-tsjinst, en streamingbanen wenje yn aparte repositories op LinkedIn. Om it lykwols makliker te meitsjen foar brûkers fan iepen boarne, hawwe wy in inkele repository foar de iepen boarne ferzje fan DataHub.
figuer 1: Syngronisaasje tusken repositories LinkedIn DataHub en in inkele repository DataHub iepen Boarne
Om automatisearre workflows foar bouwen, pushen en pullen te stypjen, makket ús nije ark automatysk in mappen op bestânnivo oerienkomt mei elk boarnebestân. De toolkit fereasket lykwols inisjele konfiguraasje en brûkers moatte in module-mapping op hege nivo leverje lykas hjirûnder werjûn.
{
"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 mapping op modulenivo is in ienfâldige JSON wêrfan de kaaien de doelmodules binne yn it iepen boarne repository en de wearden binne de list mei boarne modules yn 'e LinkedIn repositories. Elke doelmodule yn in iepen boarne repository kin fiede wurde troch elk oantal boarnemodules. Om de ynterne nammen fan repositories yn boarnemodules oan te jaan, brûk yn Bash styl. Mei help fan in module-nivo mapping triem, de ark meitsje in triem-nivo mapping triem troch it scannen fan alle triemmen yn assosjearre mappen.
{
"${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,
}De triemnivo mapping wurdt automatysk makke troch de ark; lykwols, it kin ek wurde mei de hân bywurke troch de brûker. Dit is in 1: 1-mapping fan in LinkedIn-boarnebestân nei in bestân yn it iepen boarne repository. D'r binne ferskate regels ferbûn mei dizze automatyske oanmeitsjen fan triemferienings:
- Yn it gefal fan meardere boarnemodules foar in doelmodule yn iepen boarne kinne konflikten ûntstean, bygelyks itselde , besteande yn mear as ien boarne module. As in strategy foar konfliktoplossing, binne ús ark standert de opsje "lêste wint".
- "null" betsjut dat it boarnebestân gjin diel is fan it iepen boarne repository.
- Nei elke yntsjinjen of ekstraksje fan iepen boarne wurdt dizze mapping automatysk bywurke en wurdt in momintopname makke. Dit is nedich om tafoegings en wiskjen fan boarnekoade te identifisearjen sûnt de lêste aksje.
It meitsjen fan commit logs
Commit logs foar iepen boarne commits wurde ek automatysk oanmakke troch it gearfoegjen fan de commit logs fan ynterne repositories. Hjirûnder is in foarbyld fan commit-log om de struktuer fan 'e commit-log te sjen oanmakke troch ús ark. In commit jout dúdlik oan hokker ferzjes fan 'e boarne repositories yn dat commit binne ferpakt en jout in gearfetting fan it commit-log. Kontrolearje dizze út mei help fan in echt foarbyld fan in commit log generearre troch ús 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.0Ofhinklikens testen
LinkedIn hat , dat helpt te soargjen dat feroarings oan in ynterne multiproduct net brekke de gearkomste fan ôfhinklike multiproducts. De iepen boarne DataHub-repository is gjin multi-produkt, en it kin net in direkte ôfhinklikens wêze fan in multi-produkt, mar mei help fan in multi-produkt wrapper dy't de iepen boarne DataHub boarnekoade ophellet, kinne wy dizze ôfhinklikheidstest noch brûke Sadwaande, elke feroaring (dy't letter kin wurde bleatsteld) oan ien fan 'e multiprodukten dy't de iepen boarne DataHub-repository fiede, triggert in build-evenemint yn' e shell-multyprodukt. Dêrom, elke feroaring dy't net slagget om in wrapperprodukt te bouwen, mislearret de tests foardat jo it orizjinele produkt ynsette en wurdt werombrocht.
Dit is in nuttich meganisme dat helpt foar te kommen dat elke ynterne commit dy't de iepen boarne-build brekt en it detektearret op 'e commit-tiid. Sûnder dit soe it frijwat lestich wêze om te bepalen hokker ynterne commit feroarsake hat dat de bou fan iepen boarne repository mislearre, om't wy ynterne wizigingen batchje oan it DataHub iepen boarne repository.
Ferskillen tusken iepen boarne DataHub en ús produksjeferzje
Oant dit punt hawwe wy ús oplossing besprutsen foar syngronisaasje fan twa ferzjes fan DataHub-repositories, mar wy hawwe noch net de redenen omskreaun wêrom't wy yn it earste plak twa ferskillende ûntwikkelingsstreamen nedich binne. Yn dizze seksje sille wy de ferskillen listje tusken de iepenbiere ferzje fan DataHub en de produksjeferzje op LinkedIn-tsjinners, en de redenen foar dizze ferskillen útlizze.
Ien boarne fan diskrepânsje komt út it feit dat ús produksjeferzje ôfhinklikens hat fan koade dy't noch net iepen boarne is, lykas LinkedIn's Offspring (linkedIn's ynterne ôfhinklikensynjeksjekader). Offspring wurdt in protte brûkt yn ynterne koadebasen, om't it de foarkar metoade is foar it behearen fan dynamyske konfiguraasje. Mar it is net iepen boarne; dus wy moasten iepen boarne-alternativen fine foar de iepen boarne DataHub.
D'r binne ek oare redenen. Wylst wy tafoegings meitsje foar it metadatamodel foar de behoeften fan LinkedIn, binne dizze tafoegings typysk heul spesifyk foar LinkedIn en kinne net direkt fan tapassing wêze op oare omjouwings. Wy hawwe bygelyks heul spesifike labels foar dielnimmers-ID's en oare soarten oerienkommende metadata. Dat, wy hawwe no dizze tafoegings útsletten fan DataHub's iepen boarne metadatamodel. Wylst wy mei de mienskip omgean en har behoeften begripe, sille wy wurkje oan mienskiplike iepen boarne ferzjes fan dizze tafoegings wêr nedich.
Gebrûksgemak en maklikere oanpassing foar de iepen boarne-mienskip ynspireare ek guon fan 'e ferskillen tusken de twa ferzjes fan DataHub. Ferskillen yn streamferwurkingsynfrastruktuer binne dêr in goed foarbyld fan. Hoewol ús ynterne ferzje in ramt foar beheare streamferwurking brûkt, hawwe wy der foar keazen om ynboude (standalone) streamferwurking te brûken foar de iepen boarne ferzje, om't it it meitsjen fan in oare ynfrastruktuerôfhinklikens foarkomt.
In oar foarbyld fan it ferskil is it hawwen fan in inkele GMS (Generalized Metadata Store) yn in iepen boarne ymplemintaasje ynstee fan meardere GMS's. GMA (Generalized Metadata Architecture) is de namme fan 'e back-end-arsjitektuer foar DataHub, en GMS is de metadata-winkel yn' e kontekst fan GMA. GMA is in heul fleksibele arsjitektuer wêrmei jo elke gegevenskonstruksje (bgl GMS wurdt bywurke. Foar gemak fan gebrûk hawwe wy keazen foar ien GMS-eksimplaar dy't alle ferskillende gegevenskonstruksjes opslaat yn 'e iepen boarne DataHub.
In folsleine list mei ferskillen tusken de twa ymplemintaasjes wurdt jûn yn 'e tabel hjirûnder.
Produkteigenskippen
LinkedIn DataHub
Open Source DataHub
Stipe datakonstruksjes
1) Datasets 2) Brûkers 3) Metriken 4) ML-funksjes 5) Charts 6) Dashboards
1) Datasets 2) Brûkers
Stipe metadataboarnen foar datasets
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 ferwurkjen
Bestjoerd
Ynbêde (stand-alone)
Ofhinklikensynjeksje & dynamyske konfiguraasje
LinkedIn Offspring
Bouwe Tooling
Ligradle (linkedIn's ynterne Gradle wrapper)
CI / CD
CRT (ynterne CI/CD fan LinkedIn)
en
Metadata Stores
Ferdield meardere GMS: 1) Dataset GMS 2) Brûker GMS 3) Metryske GMS 4) Funksje GMS 5) Chart / Dashboard GMS
Single GMS foar: 1) Datasets 2) Brûkers
Mikrotsjinsten yn Docker-konteners
simplifies applikaasje ynset en distribúsje mei . Elk diel fan 'e tsjinst yn DataHub is iepen boarne, ynklusyf ynfrastruktuerkomponinten lykas Kafka, , и , hat in eigen Docker-ôfbylding. Om Docker-konteners te orkestrearjen hawwe wy brûkt .
figuer 2: Architecture DataHub *iepen Boarne**
Jo kinne de arsjitektuer op hege nivo fan DataHub sjen yn 'e ôfbylding hjirboppe. Njonken de ynfrastruktuerkomponinten hat it fjouwer ferskillende Docker-konteners:
datahub-gms: tsjinst foar opslach fan metadata
datahub-frontend: applikaasje , betsjinje de DataHub ynterface.
datahub-mce-konsumint: applikaasje , dy't de metadata change event (MCE) stream brûkt en de metadata store bywurket.
datahub-mae-konsumint: applikaasje , dy't in metadata-audit-evenemintstream (MAE) brûkt en in sykyndeks en grafykdatabase makket.
Iepen boarne repository dokumintaasje en befetsje mear detaillearre ynformaasje oer de funksjes fan ferskate tsjinsten.
CI / CD op DataHub is iepen boarne
De iepen boarne DataHub repository brûkt foar trochgeande yntegraasje en foar trochgeande ynset. Beide hawwe goede GitHub-yntegraasje en binne maklik yn te stellen. Foar de measte iepen boarne-ynfrastruktuer ûntwikkele troch de mienskip as partikuliere bedriuwen (bgl. ), Docker-ôfbyldings wurde makke en ynset nei Docker Hub foar maklik gebrûk troch de mienskip. Elke Docker-ôfbylding fûn yn Docker Hub kin maklik brûkt wurde mei in ienfâldich kommando .
Mei elke ynset foar it Open source-repository fan DataHub, wurde alle Docker-ôfbyldings automatysk boud en ynset op Docker Hub mei de "lêste" tag. As Docker Hub is konfigurearre mei guon , wurde alle tags yn it iepen boarne repository ek frijjûn mei oerienkommende tagnammen yn Docker Hub.
Mei help fan DataHub
is heul ienfâldich en bestiet út trije ienfâldige stappen:
- Kloon it iepen boarne repository en rinne alle Docker-konteners mei docker-compose mei it levere docker-compose-skript foar in rappe start.
- Download de foarbyldgegevens dy't yn 'e repository levere wurde mei it kommandorigelark dat ek wurdt levere.
- Blêdzje troch DataHub yn jo browser.
Aktyf folge ek ynsteld foar rappe fragen. Brûkers kinne ek problemen direkt oanmeitsje yn it GitHub-repository. It wichtichste, wy ferwolkomje en wurdearje alle feedback en suggestjes!
Plannen foar de takomst
Op it stuit is elke ynfrastruktuer of mikrotsjinst foar iepen boarne DataHub boud as in Docker-kontener, en it heule systeem wurdt orkestreare mei . Sjoen de populariteit en wiidferspraat , wolle wy ek graach in Kubernetes-basearre oplossing leverje yn 'e heine takomst.
Wy binne ek fan plan in turnkey-oplossing te leverjen foar it ynsetten fan DataHub op in iepenbiere wolktsjinst lykas , of . Sjoen de resinte oankundiging fan LinkedIn's migraasje nei Azure, sil dit oerienkomme mei de ynterne prioriteiten fan it metadatateam.
As lêste, mar net it minste, tank oan alle iere adopters fan DataHub yn 'e iepen boarne-mienskip dy't DataHub-alfa's hawwe beoardiele en ús holpen problemen te identifisearjen en dokumintaasje te ferbetterjen.
Boarne: www.habr.com