Open Source DataHub: la Metadatuma Serĉo kaj Malkovra Platformo de LinkedIn
Trovi la datumojn, kiujn vi bezonas rapide, estas esenca por iu ajn kompanio, kiu dependas de grandaj kvantoj da datumoj por fari decidojn de datumoj. Ĉi tio ne nur influas la produktivecon de datumuzantoj (inkluzive de analizistoj, programistoj de maŝinlernado, datumsciencistoj kaj datumaj inĝenieroj), sed ĝi ankaŭ havas rektan efikon al la finproduktoj kiuj dependas de kvalita maŝinlernado (ML) dukto. Aldone, la tendenco al efektivigo aŭ konstruado de maŝinlernantaj platformoj nature levas la demandon: kia estas via metodo por interne malkovri funkciojn, modelojn, metrikojn, datumajn arojn, ktp.
En ĉi tiu artikolo ni parolos pri kiel ni publikigis datumfonton sub malferma permesilo en nia metadatuma serĉo kaj malkovra platformo, ekde la fruaj tagoj de la projekto . LinkedIn konservas sian propran version de DataHub aparte de la malfermfonta versio. Ni komencos klarigante kial ni bezonas du apartajn evolumediojn, poste diskutos fruajn alirojn al uzado de la malferma fonto WhereHows kaj komparo nian internan (produktadon) version de DataHub kun la versio sur . Ni ankaŭ dividos detalojn pri nia nova aŭtomatigita solvo por puŝi kaj ricevi malfermfontajn ĝisdatigojn por teni ambaŭ deponejojn sinkronigitaj. Fine, ni provizos instrukciojn pri kiel komenci uzi la malfermfontan DataHub kaj mallonge diskutos ĝian arkitekturon.
WhereHows nun estas DataHub!
La metadatuma teamo de LinkedIn antaŭe prezentita (posteulo al WhereHows), la serĉo kaj metadatuma malkovra platformo de LinkedIn, kaj komunaj planoj malfermi ĝin. Baldaŭ post ĉi tiu anonco, ni publikigis alfa-version de DataHub kaj dividis ĝin kun la komunumo. Ekde tiam, ni daŭre kontribuis al la deponejo kaj laboris kun interesitaj uzantoj por aldoni la plej petitajn funkciojn kaj solvi problemojn. Ni nun ĝojas anonci la oficialan liberigon .
Malfermfontaj Aliroj
WhereHows, la originala portalo de LinkedIn por trovi datumojn kaj de kie ĝi venas, komenciĝis kiel interna projekto; la metadatuma teamo malfermis ĝin . Ekde tiam, la teamo ĉiam konservis du malsamajn kodbazojn - unu por malferma fonto kaj unu por la interna uzo de LinkedIn - ĉar ne ĉiuj produkttrajtoj evoluigitaj por LinkedIn uzkazoj estis ĝenerale uzeblaj al la pli larĝa spektantaro. Aldone, WhereHows havas iujn internajn dependecojn (infrastrukturo, bibliotekoj, ktp.) kiuj ne estas malferma fonto. En la sekvaj jaroj, WhereHows trapasis multajn ripetojn kaj evoluciklojn, igante sinkronigi la du kodbazojn granda defio. La metadatuma teamo provis malsamajn alirojn tra la jaroj por provi sinkronigi internan kaj malfermfontan disvolviĝon.
Unua provo: "Malfermfonto unue"
Ni komence sekvis "malfermfontan unue" evolumodelon, kie la plej granda parto de evoluo okazas en malfermfonta deponejo kaj ŝanĝoj estas faritaj por interna deplojo. La problemo kun ĉi tiu aliro estas, ke la kodo ĉiam estas puŝita al GitHub unue antaŭ ol ĝi estis plene reviziita interne. Ĝis kiam ŝanĝoj estos faritaj de la malfermfonta deponejo kaj nova interna disfaldo estos farita, ni ne trovos produktadajn problemojn. En kazo de malbona deplojo, estis ankaŭ tre malfacile determini la kulpulon ĉar ŝanĝoj estis faritaj en aroj.
Plie, tiu modelo reduktis la produktivecon de la teamo dum evoluigado de novaj funkcioj kiuj postulis rapidajn ripetojn, ĉar ĝi devigis ĉiujn ŝanĝojn unue esti puŝitaj en malfermfontecan deponejon kaj tiam puŝitaj al interna deponejo. Por redukti la pretigtempon, la postulata riparo aŭ ŝanĝo povus esti farita en la interna deponejo unue, sed tio fariĝis grandega problemo kiam temas kunfandi tiujn ŝanĝojn reen en la malfermfontan deponejon ĉar la du deponejoj estis malsinkronigitaj.
Ĉi tiu modelo estas multe pli facile efektivigebla por komunaj platformoj, bibliotekoj aŭ infrastrukturaj projektoj ol por plentaŭgaj kutimaj retejo-aplikoj. Aldone, ĉi tiu modelo estas ideala por projektoj kiuj komencas malferman fonton de la unua tago, sed WhereHows estis konstruita kiel tute interna retejo-aplikaĵo. Estis vere malfacile tute abstrakti ĉiujn internajn dependecojn, do ni bezonis konservi la internan forkon, sed konservi la internan forkon kaj disvolvi plejparte malferman fonton ne tute funkciis.
Dua provo: "Interna unue"
**Kiel dua provo, ni moviĝis al "interna unua" evolumodelo, kie la plej granda parto de evoluo okazas interne kaj ŝanĝoj estas faritaj al la malferma fontkodo regule. Kvankam ĉi tiu modelo plej taŭgas por nia uzokazo, ĝi havas proprajn problemojn. Rekte puŝi ĉiujn diferencojn al la malfermfonta deponejo kaj poste provi solvi kunfandi konfliktojn poste estas eblo, sed ĝi estas tempopostula. Programistoj en la plej multaj kazoj provas ne fari tion ĉiufoje kiam ili revizias sian kodon. Kiel rezulto, tio estos farita multe malpli ofte, en aroj, kaj tiel malfaciligas poste solvi kunfandi konfliktojn.
La trian fojon ĝi funkciis!
La du malsukcesaj provoj menciitaj supre rezultigis, ke la deponejo de WhereHows GitHub restis neaktuala dum longa tempo. La teamo daŭre plibonigis la ecojn kaj arkitekturon de la produkto, tiel ke la interna versio de WhereHows por LinkedIn iĝis pli progresinta ol la malfermfontecversio. Ĝi eĉ havis novan nomon - DataHub. Surbaze de antaŭaj malsukcesaj provoj, la teamo decidis evoluigi skaleblan, longperspektivan solvon.
Por ajna nova malfermkoda projekto, la malfermkoda teamo de LinkedIn konsilas kaj subtenas evolumodelon en kiu la moduloj de la projekto estas evoluigitaj tute en malfermfonteco. Versiitaj artefaktoj estas deplojitaj al publika deponejo kaj poste rekontrolitaj en la internan LinkedIn-artefakto uzante . Sekvi ĉi tiun disvolvan modelon estas ne nur bona por tiuj, kiuj uzas malferman fonton, sed ankaŭ rezultigas pli modulan, etendeblan kaj ŝtopeblan arkitekturon.
Tamen, matura malantaŭa aplikaĵo kiel DataHub postulos signifan tempon por atingi ĉi tiun staton. Ĉi tio ankaŭ malhelpas la eblecon de malferma fonto plene funkcianta efektivigo antaŭ ol ĉiuj internaj dependecoj estis plene abstraktitaj. Tial ni evoluigis ilojn kiuj helpas nin fari malfermkodajn kontribuojn pli rapide kaj kun multe malpli doloro. Ĉi tiu solvo profitigas kaj la metadatuman teamon (DataHub-programisto) kaj la malfermfontan komunumon. La sekvaj sekcioj diskutos ĉi tiun novan aliron.
Malferma Fonta Eldonado Aŭtomatigo
La plej nova aliro de la Metadatuma teamo al la malfermfonta DataHub estas evoluigi ilon kiu aŭtomate sinkronigas la internan kodbazon kaj la malfermfontan deponejon. Altnivelaj trajtoj de ĉi tiu ilaro inkluzivas:
- Sinkronigi LinkedIn-kodon al/de malferma fonto, simile .
- Licenca kapgeneracio, simila al .
- Aŭtomate generu malfermajn fontajn protokolojn el internaj promesaj protokoloj.
- Malhelpu internajn ŝanĝojn, kiuj rompas malfermfontajn konstruaĵojn .
La sekvaj subsekcioj enprofundiĝos en la supre menciitajn funkciojn, kiuj havas interesajn problemojn.
Sinkronigado de fontkodo
Male al la malfermfonta versio de DataHub, kiu estas ununura GitHub-deponejo, la LinkedIn-versio de DataHub estas kombinaĵo de multoblaj deponejoj (nomitaj interne ). La DataHub-interfaco, metadatuma modelbiblioteko, metadatuma stokejo backend servo, kaj fluaj laborpostenoj loĝas en apartaj deponejoj sur LinkedIn. Tamen, por faciligi ĝin por malfermfontaj uzantoj, ni havas ununuran deponejon por la malfermfonta versio de DataHub.
Figuro 1: Sinkronigo inter deponejoj LinkedIn DataHub kaj ununura deponejo DataHub malferma fonto
Por subteni aŭtomatigitajn konstruajn, puŝojn kaj tiri laborfluojn, nia nova ilo aŭtomate kreas dosiero-nivelan mapadon responda al ĉiu fontdosiero. Tamen, la ilaro postulas komencan agordon kaj uzantoj devas disponigi altnivelan modulmapadon kiel montrite sube.
{
"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"
]
}La modul-nivela mapado estas simpla JSON, kies ŝlosiloj estas la celmoduloj en la malfermfonta deponejo kaj la valoroj estas la listo de fontmoduloj en la LinkedIn-deponejoj. Ajna celmodulo en liberkoda deponejo povas esti provizita per iu ajn fontomoduloj. Por indiki la internajn nomojn de deponejoj en fontmoduloj, uzu en Bash-stilo. Uzante modul-nivelan mapan dosieron, la iloj kreas dosiernivelan mapan dosieron skanante ĉiujn dosierojn en rilataj dosierujoj.
{
"${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,
}La dosiernivela mapado estas aŭtomate kreita de la iloj; tamen, ĝi ankaŭ povas esti mane ĝisdatigita de la uzanto. Ĉi tio estas 1:1 mapado de LinkedIn fontdosiero al dosiero en la malfermfonta deponejo. Estas pluraj reguloj asociitaj kun ĉi tiu aŭtomata kreado de dosier-asocioj:
- En la kazo de multoblaj fontmoduloj por celmodulo en malfermfonteco, konfliktoj povas ekesti, ekz. la sama , ekzistanta en pli ol unu fontmodulo. Kiel konfliktsolva strategio, niaj iloj defaŭlte al la opcio "lasta gajnas".
- "null" signifas, ke la fontdosiero ne estas parto de la malfermfonta deponejo.
- Post ĉiu malfermfonta sendado aŭ eltiro, ĉi tiu mapado estas aŭtomate ĝisdatigita kaj momentfoto estas kreita. Ĉi tio estas necesa por identigi aldonojn kaj forigojn de fontkodo ekde la lasta ago.
Kreante kommit protokolojn
Commit-protokoloj por malfermfontaj komitaĵoj ankaŭ estas aŭtomate generitaj kunfandante la commit-protokolojn de internaj deponejoj. Malsupre estas ekzempla protokolo por montri la strukturon de la protokolo generita de nia ilo. Commit klare indikas kiuj versioj de la fontdeponejoj estas pakitaj en tiu kommit kaj disponigas resumon de la kommitprotokolo. Kontrolu ĉi tiun uzante realan ekzemplon de kommitprotokolo generita de nia ilaro.
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.0Dependeco-testado
LinkedIn havas , kiu helpas certigi, ke ŝanĝoj al interna multprodukto ne rompas la kunigon de dependaj multproduktoj. La malfermfonta DataHub-deponejo ne estas plurprodukta, kaj ĝi ne povas esti rekta dependeco de iu ajn multprodukta, sed helpe de plurprodukta envolvaĵo, kiu alportas la malfermfontan fontkodon de DataHub, ni ankoraŭ povas uzi ĉi tiun dependecan testadon. Tiel, ajna ŝanĝo (kiu poste povas esti elmontrita) al iu ajn el la multproduktoj, kiuj nutras la malfermfontan deponejon DataHub, ekigas konstruan eventon en la ŝela multprodukto. Sekve, ĉiu ŝanĝo, kiu malsukcesas konstrui envolvaĵan produkton, malsukcesas la testojn antaŭ ol fari la originan produkton kaj estas revertita.
Ĉi tio estas utila mekanismo, kiu helpas malhelpi ajnan internan transdonon, kiu rompas la malfermfontan konstruaĵon kaj detektas ĝin je la transdono. Sen ĉi tio, estus sufiĉe malfacile determini, kiu interna kompromiso kaŭzis malsukceson de la malfermfonta deponejo, ĉar ni amasigas internajn ŝanĝojn al la malfermfonta deponejo de DataHub.
Diferencoj inter malfermfonteca DataHub kaj nia produktadversio
Ĝis ĉi tiu punkto, ni diskutis nian solvon por sinkronigi du versiojn de DataHub-deponejoj, sed ni ankoraŭ ne skizis la kialojn, kial ni bezonas du malsamajn evolufluojn unue. En ĉi tiu sekcio, ni listigos la diferencojn inter la publika versio de DataHub kaj la produktadversio sur LinkedIn-serviloj, kaj klarigos la kialojn de ĉi tiuj diferencoj.
Unu fonto de diferenco devenas de tio, ke nia produktadversio havas dependecojn de kodo kiu ankoraŭ ne estas malferma fonto, kiel LinkedIn's Offspring (la interna dependeca injektokadro de LinkedIn). Idoj estas vaste uzataj en internaj kodbazoj ĉar ĝi estas la preferata metodo por administri dinamikan agordon. Sed ĝi ne estas malferma fonto; do ni bezonis trovi malfermfontajn alternativojn al la malfermfonta DataHub.
Estas ankaŭ aliaj kialoj. Ĉar ni kreas etendaĵojn al la metadatuma modelo por la bezonoj de LinkedIn, ĉi tiuj etendaĵoj estas kutime tre specifaj por LinkedIn kaj eble ne rekte aplikas al aliaj medioj. Ekzemple, ni havas tre specifajn etikedojn por partoprenantaj identigiloj kaj aliaj specoj de kongruaj metadatenoj. Do, ni nun ekskludis ĉi tiujn etendaĵojn de la malfermfonta metadatuma modelo de DataHub. Dum ni engaĝiĝas kun la komunumo kaj komprenas iliajn bezonojn, ni laboros pri komunaj malfermfontaj versioj de ĉi tiuj etendaĵoj kie necese.
Facileco de uzo kaj pli facila adapto por la malfermkoda komunumo ankaŭ inspiris kelkajn el la diferencoj inter la du versioj de DataHub. Diferencoj en fluo-prilabora infrastrukturo estas bona ekzemplo de tio. Kvankam nia interna versio uzas administritan pritraktadkadron, ni elektis uzi enkonstruitan (sendependan) fluon por la malfermfonta versio ĉar ĝi evitas krei alian infrastrukturan dependecon.
Alia ekzemplo de la diferenco estas havi ununuran GMS (Ĝeneraligita Metadatuma Vendejo) en malfermfonta efektivigo prefere ol multoblaj GMSoj. GMA (Ĝeneraligita Metadatuma Arkitekturo) estas la nomo de la malantaŭa arkitekturo por DataHub, kaj GMS estas la metadatuma butiko en la kunteksto de GMA. GMA estas tre fleksebla arkitekturo kiu permesas vin distribui ĉiun datumkonstruaĵon (ekz. datumaroj, uzantoj, ktp.) en sian propran metadatuman butikon, aŭ stoki plurajn datumkonstruaĵojn en ununura metadatuma vendejo kondiĉe ke la registro enhavanta la datumstrukturmapadon enen. GMS estas ĝisdatigita. Por facileco de uzo, ni elektis ununuran GMS-instancon, kiu stokas ĉiujn malsamajn datumkonstruaĵojn en la malfermfonta DataHub.
Kompleta listo de diferencoj inter la du efektivigoj estas donita en la tabelo malsupre.
produkto Trajtoj
LinkedIn DataHub
Open Source DataHub
Subtenataj Datumaj Konstruoj
1) Datumaroj 2) Uzantoj 3) Metriko 4) ML-Trajtoj 5) Furorlisto 6) Instrumentpaneloj
1) Datumaroj 2) Uzantoj
Subtenataj Metadatumaj Fontoj por Datumaroj
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektoro 14)
Hive Kafka RDBMS
Drinkejo-sub
Kunflua Kafka
Flua Pretigo
sukcesinta
Enigita (sendependa)
Dependa Injekto & Dinamika Agordo
LinkedIn Idoj
Konstruu Tooling
Ligradle (la interna Gradle-envolvaĵo de LinkedIn)
CI / KD
CRT (interna CI/KD de LinkedIn)
kaj
Metadatumoj Stores
Distribuita multobla GMS: 1) Datumaro GMS 2) Uzanto GMS 3) Metrika GMS 4) Karakterizaĵo GMS 5) Diagramo/Dashboard GMS
Ununura GMS por: 1) Datumaroj 2) Uzantoj
Mikroservoj en Docker-ujoj
simpligas aplikaĵan deplojon kaj distribuon kun . Ĉiu parto de la servo en DataHub estas malferma fonto, inkluzive de infrastrukturaj komponantoj kiel Kafka, , и , havas sian propran Docker-bildon. Por reĝisori Docker-ujojn ni uzis .
Figuro 2: Arkitekturo DataHub *malferma fonto**
Vi povas vidi la altnivelan arkitekturon de DataHub en la supra bildo. Krom la infrastrukturaj komponentoj, ĝi havas kvar malsamajn Docker-ujojn:
datahub-gms: servo de konservado de metadatenoj
datahub-frontend: aplikaĵo , servante la DataHub-interfacon.
datahub-mce-consumer: aplikaĵo , kiu uzas la fluon de metadatumoj-ŝanĝokazaĵo (MCE) kaj ĝisdatigas la metadatuman butikon.
datahub-mae-consumer: aplikaĵo , kiu uzas metadatuman revizian eventofluon (MAE) kaj kreas serĉindekson kaj grafikan datumbazon.
Malfermfonta deponejo dokumentado kaj enhavas pli detalajn informojn pri la funkcioj de diversaj servoj.
CI/KD sur DataHub estas malfermfonteco
La malfermfonta deponejo DataHub uzas por kontinua integriĝo kaj por kontinua deplojo. Ambaŭ havas bonan GitHub-integriĝon kaj estas facile instaleblaj. Por la plej multaj malfermfonteca infrastrukturo evoluigita fare de la komunumo aŭ privataj kompanioj (ekz. ), Docker-bildoj estas kreitaj kaj deplojitaj al Docker Hub por facileco de uzo de la komunumo. Ajna bildo de Docker trovita en Docker Hub povas esti facile uzata per simpla komando .
Kun ĉiu engaĝiĝo al la malfermfonta deponejo de DataHub, ĉiuj Docker-bildoj estas aŭtomate konstruitaj kaj deplojitaj al Docker Hub kun la "lasta" etikedo. Se Docker Hub estas agordita kun iuj , ĉiuj etikedoj en la malfermfonta deponejo ankaŭ estas liberigitaj kun respondaj etikednomoj en Docker Hub.
Uzante DataHub
estas tre simpla kaj konsistas el tri simplaj paŝoj:
- Klonu la malfermfontan deponejon kaj rulu ĉiujn Docker-ujojn per docker-compose uzante la provizitan docker-compose-skripton por rapida komenco.
- Elŝutu la specimenajn datumojn provizitajn en la deponejo per la komandlinia ilo, kiu ankaŭ estas provizita.
- Foliumi DataHub en via retumilo.
Aktive Spurita ankaŭ agordita por rapidaj demandoj. Uzantoj ankaŭ povas krei problemojn rekte en la GitHub-deponejo. Plej grave, ni bonvenigas kaj dankas ĉiujn komentojn kaj sugestojn!
Planoj por la estonteco
Nuntempe, ĉiu infrastrukturo aŭ mikroservo por malfermfonteca DataHub estas konstruita kiel Docker-ujo, kaj la tuta sistemo estas reĝisorita uzante . Donita la populareco kaj disvastigita , ni ankaŭ ŝatus provizi solvon bazitan sur Kubernetes en proksima estonteco.
Ni ankaŭ planas disponigi ŝlosilan solvon por deploji DataHub sur publika nuba servo kiel ekzemple , aŭ . Konsiderante la lastatempan anoncon pri la migrado de LinkedIn al Azure, ĉi tio akordiĝos kun la internaj prioritatoj de la metadatuma teamo.
Laste sed ne malpli, dankon al ĉiuj fruaj adoptantoj de DataHub en la malfermkoda komunumo, kiuj taksis DataHub-alfaojn kaj helpis nin identigi problemojn kaj plibonigi dokumentadon.
fonto: www.habr.com