Open Source DataHub: LinkedInova platforma za iskanje in odkrivanje metapodatkov
Hitro iskanje podatkov, ki jih potrebujete, je bistvenega pomena za vsako podjetje, ki se zanaša na velike količine podatkov za sprejemanje odločitev na podlagi podatkov. To ne vpliva samo na produktivnost uporabnikov podatkov (vključno z analitiki, razvijalci strojnega učenja, podatkovnimi znanstveniki in podatkovnimi inženirji), ampak ima tudi neposreden vpliv na končne izdelke, ki so odvisni od kakovostnega strojnega učenja (ML). Poleg tega trend izvajanja ali gradnje platform za strojno učenje seveda postavlja vprašanje: kakšna je vaša metoda za interno odkrivanje funkcij, modelov, metrik, naborov podatkov itd.
V tem članku bomo govorili o tem, kako smo objavili vir podatkov pod odprto licenco v naši platformi za iskanje in odkrivanje metapodatkov, od zgodnjih dni projekta . LinkedIn vzdržuje lastno različico DataHub ločeno od odprtokodne različice. Začeli bomo z razlago, zakaj potrebujemo dve ločeni razvojni okolji, nato bomo razpravljali o zgodnjih pristopih k uporabi odprtokodnega WhereHows in primerjali našo interno (produkcijsko) različico DataHub z različico na . Delili bomo tudi podrobnosti o naši novi avtomatizirani rešitvi za pošiljanje in prejemanje odprtokodnih posodobitev, da bosta obe repozitoriji sinhronizirani. Na koncu bomo podali navodila, kako začeti uporabljati odprtokodno središče DataHub, in na kratko razpravljali o njegovi arhitekturi.
WhereHows je zdaj DataHub!
Prej predstavljena skupina za metapodatke LinkedIn (naslednik WhereHows), LinkedInova platforma za iskanje in odkrivanje metapodatkov ter skupni načrti za njeno odprtje. Kmalu po tej objavi smo izdali alfa različico DataHub in jo delili s skupnostjo. Od takrat smo nenehno prispevali k repozitoriju in sodelovali z zainteresiranimi uporabniki, da bi dodali najbolj zahtevane funkcije in rešili težave. Zdaj z veseljem oznanjamo uradno izdajo .
Odprtokodni pristopi
WhereHows, prvotni LinkedInov portal za iskanje podatkov in od kod prihajajo, se je začel kot notranji projekt; ekipa za metapodatke ga je odprla . Od takrat je ekipa vedno vzdrževala dve različni kodni bazi – eno za odprtokodno in eno za interno uporabo LinkedIna – saj niso bile vse funkcije izdelkov, razvite za primere uporabe LinkedIna, na splošno uporabne za širšo publiko. Poleg tega ima WhereHows nekaj notranjih odvisnosti (infrastruktura, knjižnice itd.), ki niso odprtokodne. V letih, ki so sledila, je WhereHows šel skozi številne ponovitve in razvojne cikle, zaradi česar je bilo ohranjanje sinhronizacije obeh kodnih zbirk velik izziv. Skupina za metapodatke je v preteklih letih preizkušala različne pristope, da bi ohranila sinhronizacijo notranjega in odprtokodnega razvoja.
Prvi poskus: "Najprej odprta koda"
Sprva smo sledili razvojnemu modelu "najprej odprtokodni sistem", kjer se večina razvoja odvija v odprtokodnem repozitoriju, spremembe pa so narejene za interno uvajanje. Težava pri tem pristopu je, da se koda vedno najprej potisne v GitHub, preden je interno v celoti pregledana. Dokler ne izvedemo sprememb iz odprtokodnega repozitorija in ne izvedemo nove notranje uvedbe, ne bomo našli nobenih težav s proizvodnjo. V primeru slabe razmestitve je bilo tudi zelo težko določiti krivca, ker so se spremembe izvajale v serijah.
Poleg tega je ta model zmanjšal produktivnost ekipe pri razvoju novih funkcij, ki so zahtevale hitre iteracije, saj je vse spremembe prisilil, da se najprej potisnejo v odprtokodno skladišče in nato potisnejo v notranje skladišče. Da bi skrajšali čas obdelave, bi lahko zahtevani popravek ali spremembo najprej naredili v notranjem repozitoriju, vendar je to postala velika težava, ko je prišlo do združitve teh sprememb nazaj v odprtokodno repozitorij, ker repozitorija nista bila sinhronizirana.
Ta model je veliko lažje implementirati za skupne platforme, knjižnice ali infrastrukturne projekte kot za spletne aplikacije po meri s polnimi funkcijami. Poleg tega je ta model idealen za projekte, ki se od prvega dne začnejo z odprto kodo, vendar je bil WhereHows zgrajen kot popolnoma interna spletna aplikacija. Resnično je bilo težko popolnoma abstrahirati vse notranje odvisnosti, zato smo morali obdržati notranji fork, vendar ohranjanje notranjega forka in razvoj večinoma odprtokodnega sistema nista uspela.
Drugi poskus: "Najprej notranji"
**V drugem poskusu smo prešli na razvojni model »najprej interno«, kjer večina razvoja poteka v podjetju in se redno spreminja odprtokodna koda. Čeprav je ta model najprimernejši za naš primer uporabe, ima inherentne težave. Neposredno potiskanje vseh razlik v odprtokodno skladišče in nato poskus reševanja sporov pri spajanju pozneje je možnost, vendar je zamudno. Razvijalci se v večini primerov trudijo, da tega ne storijo vsakič, ko pregledajo svojo kodo. Posledično se bo to izvajalo veliko redkeje, v paketih, zaradi česar bo pozneje težje reševati spore združevanja.
Tretjič je uspelo!
Dva zgoraj omenjena neuspešna poskusa sta privedla do tega, da je repozitorij WhereHows GitHub dolgo časa zastarel. Ekipa je še naprej izboljševala funkcije in arhitekturo izdelka, tako da je interna različica WhereHows za LinkedIn postala naprednejša od odprtokodne različice. Imel je celo novo ime - DataHub. Na podlagi prejšnjih neuspelih poskusov se je ekipa odločila razviti razširljivo, dolgoročno rešitev.
Za vsak nov odprtokodni projekt LinkedInova odprtokodna ekipa svetuje in podpira razvojni model, v katerem so moduli projekta v celoti razviti v odprtokodni obliki. Artefakti z različicami so razporejeni v javno skladišče in nato preverjeni nazaj v notranji artefakt LinkedIn z uporabo . Sledenje temu razvojnemu modelu ni dobro samo za tiste, ki uporabljajo odprtokodno kodo, ampak ima za posledico tudi bolj modularno, razširljivo in vtičnico arhitekturo.
Vendar pa bo zrela zaledna aplikacija, kot je DataHub, potrebovala precej časa, da doseže to stanje. To prav tako izključuje možnost odprtokodne popolnoma delujoče izvedbe, preden so vse notranje odvisnosti popolnoma abstrahirane. Zato smo razvili orodja, ki nam pomagajo narediti odprtokodne prispevke hitreje in z veliko manj bolečin. Ta rešitev koristi tako skupini za metapodatke (razvijalec DataHub) kot odprtokodni skupnosti. Naslednji razdelki bodo razpravljali o tem novem pristopu.
Avtomatizacija odprtokodnega objavljanja
Najnovejši pristop ekipe Metadata k odprtokodnemu DataHubu je razvoj orodja, ki samodejno sinhronizira notranjo kodno zbirko in odprtokodno skladišče. Funkcije tega kompleta orodij na visoki ravni vključujejo:
- Sinhronizirajte kodo LinkedIn v/iz odprte kode, podobno .
- Generiranje glave licence, podobno .
- Samodejno ustvari odprtokodne dnevnike objave iz notranjih dnevnikov objave.
- Preprečite notranje spremembe, ki zlomijo odprtokodne zgradbe .
Naslednji pododdelki se bodo poglobili v zgoraj omenjene funkcije, ki imajo zanimive težave.
Sinhronizacija izvorne kode
Za razliko od odprtokodne različice DataHub, ki je en sam repozitorij GitHub, je LinkedIn različica DataHub kombinacija več repozitorijev (imenovanih interno ). Vmesnik DataHub, knjižnica modelov metapodatkov, zaledna storitev skladišča metapodatkov in pretočna opravila so v ločenih repozitorijih na LinkedInu. Da bi uporabnikom odprte kode olajšali delo, imamo en sam repozitorij za odprtokodno različico DataHub.
Slika 1: Sinhronizacija med repozitoriji LinkedIn DataHub in eno samo skladišče DataHub odprtokodno
Za podporo avtomatiziranih delovnih tokov gradnje, potiskanja in vlečenja naše novo orodje samodejno ustvari preslikavo na ravni datoteke, ki ustreza vsaki izvorni datoteki. Vendar komplet orodij zahteva začetno konfiguracijo in uporabniki morajo zagotoviti preslikavo modulov na visoki ravni, kot je prikazano spodaj.
{
"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"
]
}Preslikava na ravni modula je preprost JSON, katerega ključi so ciljni moduli v odprtokodnem repozitoriju, vrednosti pa so seznam izvornih modulov v repozitorijih LinkedIn. Vsak ciljni modul v odprtokodnem repozitoriju lahko napaja poljubno število izvornih modulov. Če želite označiti notranja imena repozitorijev v izvornih modulih, uporabite v bash stilu. Z uporabo datoteke za preslikavo na ravni modula orodja ustvarijo datoteko za preslikavo na ravni datoteke s skeniranjem vseh datotek v povezanih imenikih.
{
"${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,
}Orodja samodejno ustvarijo preslikavo na ravni datoteke; lahko pa ga uporabnik tudi ročno posodobi. To je preslikava 1:1 izvorne datoteke LinkedIn v datoteko v odprtokodnem repozitoriju. S tem samodejnim ustvarjanjem povezav datotek je povezanih več pravil:
- V primeru več izvornih modulov za ciljni modul v odprti kodi lahko pride do konfliktov, npr. , ki obstaja v več kot enem izvornem modulu. Kot strategija reševanja sporov so naša orodja privzeto nastavljena na možnost »zadnji zmaga«.
- "null" pomeni, da izvorna datoteka ni del odprtokodnega repozitorija.
- Po vsaki odprtokodni predložitvi ali ekstrakciji se ta preslikava samodejno posodobi in ustvari se posnetek. To je potrebno za prepoznavanje dodatkov in izbrisov iz izvorne kode od zadnjega dejanja.
Ustvarjanje dnevnikov objave
Dnevniki odobritev za odprtokodne objave se samodejno ustvarijo tudi z združitvijo dnevnikov odobritev notranjih skladišč. Spodaj je vzorec dnevnika odobritev, ki prikazuje strukturo dnevnika odobritev, ki ga ustvari naše orodje. Potrditev jasno nakazuje, katere različice izvornih repozitorijev so zapakirane v to potrditev, in nudi povzetek dnevnika potrditev. Preverite tole z uporabo pravega primera dnevnika objave, ki ga je ustvaril naš komplet orodij.
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.0Testiranje odvisnosti
LinkedIn ima , ki pomaga zagotoviti, da spremembe notranjega večizdelka ne prekinejo sestava odvisnih večizdelkov. Odprtokodni repozitorij DataHub ni večizdelkovni in ne more biti neposredna odvisnost od katerega koli večizdelkovnega izdelka, vendar lahko s pomočjo ovoja večizdelkovnega sistema, ki pridobi odprtokodno izvorno kodo DataHub, še vedno uporabimo to testiranje odvisnosti. Tako vsaka sprememba (ki je lahko pozneje izpostavljena) katerega koli večizdelka, ki napaja odprtokodno skladišče DataHub, sproži dogodek gradnje v lupinskem večizdelku. Zato vsaka sprememba, ki ne uspe zgraditi ovojnega izdelka, ne prestane preizkusov pred potrditvijo izvirnega izdelka in je razveljavljena.
To je uporaben mehanizem, ki pomaga preprečiti kakršno koli notranjo objavo, ki prekine odprtokodno zgradbo, in jo zazna ob času objave. Brez tega bi bilo zelo težko ugotoviti, katera notranja potrditev je povzročila neuspeh gradnje odprtokodnega repozitorija, ker notranje spremembe v odprtokodnem repozitoriju DataHub združimo v pakete.
Razlike med odprtokodnim DataHubom in našo produkcijsko različico
Do te točke smo razpravljali o naši rešitvi za sinhronizacijo dveh različic repozitorijev DataHub, vendar še vedno nismo orisali razlogov, zakaj sploh potrebujemo dva različna razvojna toka. V tem razdelku bomo našteli razlike med javno različico DataHub in produkcijsko različico na strežnikih LinkedIn ter pojasnili razloge za te razlike.
Eden od virov neskladja izhaja iz dejstva, da je naša produkcijska različica odvisna od kode, ki še ni odprtokodna, kot je LinkedInovo Offspring (LinkedInovo interno ogrodje za vstavljanje odvisnosti). Offspring se pogosto uporablja v notranjih kodnih bazah, ker je prednostna metoda za upravljanje dinamične konfiguracije. Vendar ni odprtokoden; zato smo morali najti odprtokodne alternative odprtokodnemu DataHubu.
Obstajajo tudi drugi razlogi. Ker ustvarjamo razširitve modela metapodatkov za potrebe LinkedIna, so te razširitve običajno zelo specifične za LinkedIn in morda ne veljajo neposredno za druga okolja. Na primer, imamo zelo specifične oznake za ID udeležencev in druge vrste ujemajočih se metapodatkov. Tako smo zdaj te razširitve izključili iz odprtokodnega modela metapodatkov DataHub. Ko sodelujemo s skupnostjo in razumemo njene potrebe, bomo po potrebi delali na skupnih odprtokodnih različicah teh razširitev.
Enostavna uporaba in lažja prilagoditev za odprtokodno skupnost sta prav tako navdihnila nekatere razlike med obema različicama DataHub. Dober primer tega so razlike v infrastrukturi za obdelavo tokov. Čeprav naša interna različica uporablja ogrodje za obdelavo upravljanega toka, smo se odločili za uporabo vgrajene (samostojne) obdelave toka za odprtokodno različico, ker se s tem izognemo ustvarjanju druge odvisnosti od infrastrukture.
Drug primer razlike je uporaba enega samega GMS (generalized Metadata Store) v odprtokodni izvedbi namesto več GMS. GMA (Generalized Metadata Architecture) je ime zaledne arhitekture za DataHub, GMS pa je shramba metapodatkov v kontekstu GMA. GMA je zelo prilagodljiva arhitektura, ki vam omogoča, da vsak konstrukt podatkov (npr. nabore podatkov, uporabnike itd.) razdelite v lastno shrambo metapodatkov ali shranite več konstruktov podatkov v eno samo shrambo metapodatkov, če register vsebuje preslikavo strukture podatkov v GMS je posodobljen. Za lažjo uporabo smo izbrali en primerek GMS, ki shranjuje vse različne konstrukcije podatkov v odprtokodnem DataHubu.
Celoten seznam razlik med obema izvedbama je podan v spodnji tabeli.
Lastnosti izdelka
LinkedIn DataHub
Odprtokodni DataHub
Podprti podatkovni konstrukti
1) Nabori podatkov 2) Uporabniki 3) Meritve 4) Funkcije ML 5) Grafi 6) Nadzorne plošče
1) Nabori podatkov 2) Uporabniki
Podprti viri metapodatkov za nabore podatkov
1) 2) Kavč 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
Sotočna Kafka
Stream Processing
upravlja
Vdelano (samostojno)
Vstavljanje odvisnosti in dinamična konfiguracija
LinkedIn potomci
Orodje za gradnjo
Ligradle (LinkedIn-ov interni ovoj Gradle)
CI / CD
CRT (LinkedIn-ov notranji CI/CD)
in
Shramba metapodatkov
Porazdeljeni več GMS: 1) GMS nabora podatkov 2) GMS uporabnika 3) GMS metrike 4) GMS funkcij 5) GMS grafikona/nadzorne plošče
Enotni GMS za: 1) Nabore podatkov 2) Uporabnike
Mikrostoritve v vsebnikih Docker
poenostavlja uvajanje in distribucijo aplikacij z . Vsak del storitve v DataHubu je odprtokoden, vključno s komponentami infrastrukture, kot je Kafka, , и , ima svojo sliko Dockerja. Za orkestracijo Dockerjevih vsebnikov smo uporabili .
Slika 2: Arhitektura DataHub *odprtokodno**
Na zgornji sliki si lahko ogledate visokonivojsko arhitekturo DataHub. Poleg komponent infrastrukture ima štiri različne vsebnike Docker:
datahub-gms: storitev za shranjevanje metapodatkov
datahub-frontend: aplikacija , ki služi vmesniku DataHub.
datahub-mce-consumer: aplikacija , ki uporablja tok dogodka spremembe metapodatkov (MCE) in posodablja shrambo metapodatkov.
datahub-mae-consumer: aplikacija , ki uporablja tok dogodkov revizije metapodatkov (MAE) in ustvari iskalni indeks in bazo podatkov grafov.
Dokumentacija odprtokodnega repozitorija in vsebujejo podrobnejše informacije o funkcijah različnih storitev.
CI/CD na DataHubu je odprtokoden
Odprtokodni repozitorij DataHub uporablja za stalno integracijo in za neprekinjeno uvajanje. Oba imata dobro integracijo GitHub in ju je enostavno nastaviti. Za večino odprtokodne infrastrukture, ki jo je razvila skupnost ali zasebna podjetja (npr. ), so slike Docker ustvarjene in nameščene v Docker Hub za lažjo uporabo s strani skupnosti. Vsako sliko Docker, ki jo najdete v Docker Hubu, je mogoče preprosto uporabiti s preprostim ukazom .
Z vsako predajo odprtokodnemu repozitoriju DataHub se vse slike Docker samodejno zgradijo in razmestijo v Docker Hub z oznako »najnovejše«. Če je Docker Hub konfiguriran z nekaterimi , so vse oznake v odprtokodnem repozitoriju izdane tudi z ustreznimi imeni oznak v Docker Hubu.
Uporaba DataHub
je zelo preprosta in je sestavljena iz treh preprostih korakov:
- Klonirajte odprtokodno skladišče in zaženite vse vsebnike Docker z docker-compose z uporabo priloženega skripta docker-compose za hiter začetek.
- Prenesite vzorčne podatke iz repozitorija z orodjem ukazne vrstice, ki je prav tako na voljo.
- Prebrskajte DataHub v brskalniku.
Aktivno sleden konfiguriran tudi za hitra vprašanja. Uporabniki lahko tudi ustvarjajo težave neposredno v repozitoriju GitHub. Najpomembneje pa je, da pozdravljamo in cenimo vse povratne informacije in predloge!
Načrti za prihodnost
Trenutno je vsaka infrastruktura ali mikrostoritev za odprtokodni DataHub zgrajena kot vsebnik Docker, celoten sistem pa je orkestriran z . Glede na priljubljenost in razširjenost , bi radi v bližnji prihodnosti ponudili tudi rešitev, ki temelji na Kubernetesu.
Prav tako nameravamo zagotoviti rešitev na ključ za uvedbo DataHuba v javni storitvi v oblaku, kot je npr , ali . Glede na nedavno napoved selitve LinkedIna na Azure bo to usklajeno z notranjimi prednostnimi nalogami skupine za metapodatke.
Nenazadnje gre zahvala vsem prvim uporabnikom DataHub v odprtokodni skupnosti, ki so ocenili DataHub alfa in nam pomagali prepoznati težave in izboljšati dokumentacijo.
Vir: www.habr.com