Avatud lähtekoodiga DataHub: LinkedIni metaandmete otsingu ja avastamise platvorm
Vajalike andmete kiire leidmine on oluline iga ettevõtte jaoks, kes tugineb andmepõhiste otsuste tegemisel suurele andmemahule. See ei mõjuta mitte ainult andmekasutajate (sealhulgas analüütikute, masinõppe arendajate, andmeteadlaste ja andmeinseneride) tootlikkust, vaid sellel on ka otsene mõju lõpptoodetele, mis sõltuvad kvaliteetsest masinõppe (ML) torustikust. Lisaks tekitab masinõppeplatvormide juurutamise või ehitamise suundumus loomulikult küsimuse: milline on teie meetod funktsioonide, mudelite, mõõdikute, andmekogumite jms sisemiseks avastamiseks.
Selles artiklis räägime sellest, kuidas avaldasime andmeallika avatud litsentsi alusel meie metaandmete otsingu ja avastamise platvormil, alates projekti algusaegadest . LinkedIn haldab oma DataHubi versiooni avatud lähtekoodiga versioonist eraldi. Alustuseks selgitame, miks meil on vaja kahte eraldi arenduskeskkonda, seejärel arutame avatud lähtekoodiga WhereHowsi kasutamise varaseid lähenemisviise ja võrdleme DataHubi sisemist (tootmis-)versiooni veebilehel oleva versiooniga. . Samuti jagame üksikasju meie uue automaatse lahenduse kohta avatud lähtekoodiga värskenduste edastamiseks ja vastuvõtmiseks, et hoida mõlemad hoidlad sünkroonis. Lõpuks anname juhised avatud lähtekoodiga DataHubi kasutamise alustamiseks ja räägime lühidalt selle arhitektuurist.
WhereHows on nüüd DataHub!
Varem esitletud LinkedIni metaandmete meeskond (WhereHowsi järglane), LinkedIni otsingu- ja metaandmete avastamise platvorm ning jagatud plaanid selle avamiseks. Vahetult pärast seda teadaannet andsime välja DataHubi alfaversiooni ja jagasime seda kogukonnaga. Sellest ajast alates oleme hoidlasse pidevalt panustanud ja teinud koostööd huvitatud kasutajatega, et lisada enim nõutud funktsioone ja lahendada probleeme. Meil on nüüd hea meel teatada ametlikust väljalasest .
Avatud lähtekoodiga lähenemisviisid
Siseprojektina sai alguse LinkedIni algne portaal WhereHows andmete leidmiseks ja kust need pärinevad; metaandmete meeskond avas selle . Sellest ajast alates on meeskond alati säilitanud kahte erinevat koodibaasi – üht avatud lähtekoodiga ja ühte LinkedIni sisekasutuseks –, kuna kõik LinkedIni kasutusjuhtude jaoks välja töötatud tootefunktsioonid ei olnud üldiselt laiemale vaatajaskonnale rakendatavad. Lisaks on WhereHowsil mõned sisemised sõltuvused (infrastruktuur, teegid jne), mis ei ole avatud lähtekoodiga. Järgnevatel aastatel läbis WhereHows palju iteratsioone ja arendustsükleid, muutes kahe koodibaasi sünkroonis hoidmise suureks väljakutseks. Metaandmete meeskond on aastate jooksul proovinud erinevaid lähenemisviise, et hoida sisemist ja avatud lähtekoodiga arendust sünkroonis.
Esimene proovimine: "Kõigepealt avatud lähtekoodiga"
Algselt järgisime arendusmudelit "kõigepealt avatud lähtekoodiga", kus suurem osa arendustest toimub avatud lähtekoodiga hoidlas ja muudatusi tehakse sisemise juurutamise jaoks. Selle lähenemisviisi probleem seisneb selles, et kood lükatakse alati kõigepealt GitHubisse, enne kui see on sisemiselt täielikult üle vaadatud. Kuni avatud lähtekoodiga hoidlast tehtud muudatusi ja uut sisemist juurutamist pole tehtud, ei leia me tootmisprobleeme. Halva kasutuselevõtu korral oli ka süüdlast väga raske kindlaks teha, sest muudatusi tehti partiidena.
Lisaks vähendas see mudel meeskonna tootlikkust uute funktsioonide väljatöötamisel, mis nõudsid kiireid iteratsioone, kuna see sundis kõik muudatused esmalt lükkama avatud lähtekoodiga hoidlasse ja seejärel lükkama sisemisse hoidlasse. Töötlemisaja lühendamiseks võis vajaliku paranduse või muudatuse teha esmalt sisemises hoidlas, kuid sellest sai suur probleem nende muudatuste taasühendamisel avatud lähtekoodiga hoidlasse, kuna need kaks hoidlat olid sünkroonist väljas.
Seda mudelit on palju lihtsam rakendada jagatud platvormide, teekide või infrastruktuuriprojektide jaoks kui täisfunktsionaalsete kohandatud veebirakenduste jaoks. Lisaks sobib see mudel ideaalselt projektidele, mis alustavad avatud lähtekoodiga esimesest päevast, kuid WhereHows ehitati täielikult sisemise veebirakendusena. Kõigi sisemiste sõltuvuste täielik eemaldamine oli tõesti raske, nii et pidime sisemise kahvli säilitama, kuid sisemise kahvli hoidmine ja peamiselt avatud lähtekoodiga arendamine ei õnnestunud.
Teine katse: "Kõigepealt sisemine"
**Teise katsena läksime üle "sisemise esimese" arendusmudelile, kus suurem osa arendustest toimub ettevõttesiseselt ja avatud lähtekoodis tehakse muudatusi regulaarselt. Kuigi see mudel sobib meie kasutusjuhtumiks kõige paremini, on sellel omased probleemid. Võimalik on kõigi erinevuste otsene edastamine avatud lähtekoodiga hoidlasse ja seejärel ühendamiskonfliktide hilisema lahendamise proovimine, kuid see on aeganõudev. Arendajad püüavad enamikul juhtudel seda mitte teha iga kord, kui nad oma koodi üle vaatavad. Seetõttu tehakse seda palju harvemini, pakettidena, mis muudab liitmiskonfliktide hilisema lahendamise keerulisemaks.
Kolmas kord töötas!
Kahe ülalmainitud ebaõnnestunud katse tulemusel jäi WhereHows GitHubi hoidla pikka aega aegunuks. Meeskond jätkas toote funktsioonide ja arhitektuuri täiustamist, nii et saidi WhereHows for LinkedIn siseversioon muutus arenenumaks kui avatud lähtekoodiga versioon. Sellel oli isegi uus nimi - DataHub. Varasemate ebaõnnestunud katsete põhjal otsustas meeskond välja töötada skaleeritava pikaajalise lahenduse.
Iga uue avatud lähtekoodiga projekti puhul nõustab ja toetab LinkedIni avatud lähtekoodiga meeskond arendusmudelit, mille puhul projekti moodulid töötatakse välja täielikult avatud lähtekoodiga. Versioonitud artefaktid juurutatakse avalikku hoidlasse ja kontrollitakse seejärel LinkedIni sisesesse artefakti, kasutades . Selle arendusmudeli järgimine pole kasulik mitte ainult avatud lähtekoodiga kasutajatele, vaid annab ka modulaarsema, laiendatavama ja ühendatavama arhitektuuri.
Küpsed taustarakendused, nagu DataHub, vajavad selle oleku saavutamiseks siiski palju aega. See välistab ka võimaluse täielikult toimiva teostuse avatud hankimiseks enne, kui kõik sisemised sõltuvused on täielikult eemaldatud. Seetõttu oleme välja töötanud tööriistad, mis aitavad meil teha avatud lähtekoodiga kaastöid kiiremini ja palju väiksema vaevaga. See lahendus on kasulik nii metaandmete meeskonnale (DataHubi arendaja) kui ka avatud lähtekoodiga kogukonnale. Järgmistes osades käsitletakse seda uut lähenemisviisi.
Avatud lähtekoodiga avaldamise automatiseerimine
Metaandmete meeskonna uusim lähenemisviis avatud lähtekoodiga DataHubile on töötada välja tööriist, mis sünkroonib automaatselt sisemise koodibaasi ja avatud lähtekoodiga hoidla. Selle tööriistakomplekti kõrgetasemelised funktsioonid hõlmavad järgmist:
- Sünkrooni LinkedIn kood avatud lähtekoodiga/avatud lähtekoodist, sarnane .
- Litsentsi päise genereerimine, sarnane .
- Looge sisemistest kinnistamislogidest automaatselt avatud lähtekoodiga täitmislogid.
- Vältige sisemisi muudatusi, mis katkestavad avatud lähtekoodiga järge .
Järgmistes alajaotistes käsitletakse ülalnimetatud funktsioone, millel on huvitavaid probleeme.
Lähtekoodi sünkroonimine
Erinevalt DataHubi avatud lähtekoodiga versioonist, mis on üks GitHubi hoidla, on DataHubi LinkedIn versioon kombinatsioon mitmest hoidlast (nimetatakse sisemiselt ). DataHubi liides, metaandmete mudeliteek, metaandmete lao taustateenus ja voogedastustööd asuvad LinkedInis eraldi hoidlates. Kuid avatud lähtekoodiga kasutajatele lihtsamaks muutmiseks on meil DataHubi avatud lähtekoodiga versiooni jaoks üks hoidla.
Joonis 1: hoidlate vaheline sünkroonimine LinkedIn DataHub ja üks hoidla DataHub avatud lähtekoodiga
Automaatsete koostamise, lükkamise ja tõmbamise töövoogude toetamiseks loob meie uus tööriist automaatselt igale lähtefailile vastava failitaseme vastenduse. Tööriistakomplekt nõuab aga esialgset konfigureerimist ja kasutajad peavad esitama kõrgetasemelise mooduli kaardistamise, nagu allpool näidatud.
{
"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"
]
}Moodulitaseme vastendamine on lihtne JSON, mille võtmed on sihtmoodulid avatud lähtekoodiga hoidlas ja väärtused on LinkedIni hoidlate lähtemoodulite loend. Mis tahes sihtmoodulit avatud lähtekoodiga hoidlas saab toita suvalise arvu lähtemoodulitega. Lähtemoodulite hoidlate sisenimede märkimiseks kasutage bashi stiilis. Moodulitaseme vastendusfaili kasutades loovad tööriistad failitaseme vastendusfaili, skannides kõiki seotud kataloogides olevaid faile.
{
"${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,
}Tööriistad loovad failitaseme vastenduse automaatselt; aga kasutaja saab seda ka käsitsi värskendada. See on LinkedIni lähtefaili 1:1 vastendamine avatud lähtekoodiga hoidlas oleva failiga. Selle failiseoste automaatse loomisega on seotud mitu reeglit:
- Kui avatud lähtekoodiga sihtmooduli jaoks on mitu lähtemoodulit, võivad tekkida konfliktid, nt sama , mis on olemas rohkem kui ühes lähtemoodulis. Konfliktide lahendamise strateegiana kasutavad meie tööriistad vaikimisi valikut „Viimane võidab”.
- "null" tähendab, et lähtefail ei kuulu avatud lähtekoodiga hoidlasse.
- Pärast iga avatud lähtekoodiga esitamist või ekstraktimist värskendatakse seda vastendust automaatselt ja luuakse hetktõmmis. See on vajalik lähtekoodi lisamiste ja kustutamiste tuvastamiseks pärast viimast toimingut.
Kinnituslogide loomine
Avatud lähtekoodiga täitmislogid genereeritakse automaatselt ka sisemiste hoidlate täitmislogide liitmisel. Allpool on täitmislogi näidis, mis näitab meie tööriista poolt loodud täitmislogi struktuuri. Kinnitamine näitab selgelt, millised lähtevarahoidlate versioonid on sellesse sissekandmisse pakitud, ja annab kokkuvõtte täitmislogi kohta. Kontrollige seda kasutades ehtsat näidet meie tööriistakomplekti loodud täitmislogist.
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.0Sõltuvustest
LinkedInil on , mis aitab tagada, et sisemise mitmetoote muudatused ei katkesta sõltuvate mitmetoote koostu. Avatud lähtekoodiga DataHubi hoidla ei ole mitme tootega ja see ei saa olla ühegi mitme toote otsene sõltuvus, kuid avatud lähtekoodiga DataHubi lähtekoodi hangiva mitme toote ümbrise abil saame seda sõltuvustesti siiski kasutada. Seega käivitavad kõik avatud lähtekoodiga DataHubi hoidlat varustava mitme toote muudatused (mis võivad hiljem ilmneda) kesta mitme toote koostamise sündmuse. Seetõttu ei läbi kõik muudatused, mis ei suuda ümbristoote luua, enne algse toote kasutuselevõttu testimist ja see tühistatakse.
See on kasulik mehhanism, mis aitab vältida mis tahes sisemist kinnipidamist, mis rikub avatud lähtekoodiga järge ja tuvastab selle täitmise ajal. Ilma selleta oleks üsna raske kindlaks teha, milline sisemine lubamine põhjustas avatud lähtekoodiga hoidla ehituse ebaõnnestumise, kuna koondame DataHubi avatud lähtekoodiga hoidlasse sisemised muudatused.
Erinevused avatud lähtekoodiga DataHubi ja meie tootmisversiooni vahel
Siiani oleme arutanud oma lahendust DataHubi hoidlate kahe versiooni sünkroonimiseks, kuid me pole ikka veel välja toonud põhjuseid, miks vajame kahte erinevat arendusvoogu. Selles jaotises loetleme erinevused DataHubi avaliku versiooni ja LinkedIn serverite tootmisversiooni vahel ning selgitame nende erinevuste põhjuseid.
Üks lahknevuste allikas tuleneb asjaolust, et meie tootmisversioonil on sõltuvused koodist, mis ei ole veel avatud lähtekoodiga, näiteks LinkedIn's Offspring (LinkedIni sisemine sõltuvuse süstimise raamistik). Järglasi kasutatakse sisemistes koodibaasides laialdaselt, kuna see on eelistatud meetod dünaamilise konfiguratsiooni haldamiseks. Kuid see ei ole avatud lähtekoodiga; seega pidime leidma avatud lähtekoodiga DataHubile avatud lähtekoodiga alternatiivid.
On ka muid põhjuseid. Kuna loome LinkedIni vajaduste jaoks metaandmete mudelile laiendusi, on need laiendused tavaliselt LinkedInile spetsiifilised ega pruugi teistes keskkondades otseselt kehtida. Näiteks on meil väga spetsiifilised sildid osalejate ID-de ja muud tüüpi sobivate metaandmete jaoks. Seega oleme nüüd need laiendused DataHubi avatud lähtekoodiga metaandmete mudelist välja jätnud. Kui suhtleme kogukonnaga ja mõistame nende vajadusi, töötame vajaduse korral nende laienduste tavaliste avatud lähtekoodiga versioonide kallal.
Kasutuslihtsus ja lihtsam kohandamine avatud lähtekoodiga kogukonna jaoks inspireerisid ka mõningaid erinevusi DataHubi kahe versiooni vahel. Selle heaks näiteks on erinevused vootöötluse infrastruktuuris. Kuigi meie siseversioon kasutab hallatud vootöötluse raamistikku, valisime avatud lähtekoodiga versiooni jaoks sisseehitatud (eraldi) vootöötluse, kuna see väldib uue infrastruktuuri sõltuvuse loomist.
Teine näide erinevusest on ühe GMS-i (generaliseeritud metaandmete pood) kasutamine avatud lähtekoodiga rakenduses mitme GMS-i asemel. GMA (Generalized Metadata Architecture) on DataHubi taustaarhitektuuri nimi ja GMS on metaandmete salvestuskoht GMA kontekstis. GMA on väga paindlik arhitektuur, mis võimaldab jaotada iga andmekonstruktsiooni (nt andmekogumid, kasutajad jne) oma metaandmesalve või salvestada mitu andmekonstruktsiooni ühte metaandmesalve seni, kuni register sisaldab andmestruktuuri vastendust. GMS on uuendatud. Kasutamise hõlbustamiseks valisime ühe GMS-i eksemplari, mis salvestab kõik erinevad andmekonstruktsioonid avatud lähtekoodiga DataHubis.
Täielik loetelu kahe teostuse erinevustest on toodud allolevas tabelis.
Toote omadused
LinkedIn DataHub
Avatud lähtekoodiga DataHub
Toetatud andmekonstruktsioonid
1) Andmestikud 2) Kasutajad 3) Mõõdikud 4) ML-i funktsioonid 5) Diagrammid 6) Armatuurlauad
1) Andmestikud 2) Kasutajad
Andmekogumite toetatud metaandmete allikad
1) 2) Diivani alus 3) 4) 5) HDFS 6) taru 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Taru Kafka RDBMS
Pub-sub
Sujuv Kafka
Voo töötlemine
juhitud
Manustatud (eraldi)
Sõltuvuse süstimine ja dünaamiline konfiguratsioon
LinkedIn järglased
Ehitustööriistad
Ligradle (LinkedIni sisemine Gradle'i ümbris)
CI / CD
CRT (LinkedIni sisemine CI/CD)
ja
Metaandmete poed
Jaotatud mitu GMS-i: 1) Andmekogu GMS 2) Kasutaja GMS 3) Meetriline GMS 4) Funktsioon GMS 5) Diagramm/armatuurlaud GMS
Üksik GMS: 1) andmekogumid 2) kasutajad
Mikroteenused Dockeri konteinerites
lihtsustab rakenduse juurutamist ja levitamist . Kõik DataHubi teenuse osad on avatud lähtekoodiga, sealhulgas infrastruktuuri komponendid, nagu Kafka, , и , sellel on oma Dockeri pilt. Kasutasime Dockeri konteinerite orkestreerimiseks .
Joonis 2: Arhitektuur DataHub *avatud lähtekoodiga**
DataHubi kõrgetasemelist arhitektuuri näete ülaloleval pildil. Lisaks infrastruktuuri komponentidele on sellel neli erinevat Dockeri konteinerit:
datahub-gms: metaandmete salvestusteenus
datahub-frontend: rakendus , mis teenindab DataHubi liidest.
datahub-mce-consumer: rakendus , mis kasutab metaandmete muutmise sündmuse (MCE) voogu ja värskendab metaandmete salve.
datahub-mae-consumer: rakendus , mis kasutab metaandmete auditi sündmuste voogu (MAE) ning loob otsinguindeksi ja graafikute andmebaasi.
Avatud lähtekoodiga hoidla dokumentatsioon ja sisaldab üksikasjalikumat teavet erinevate teenuste funktsioonide kohta.
DataHubi CI/CD on avatud lähtekoodiga
Kasutab avatud lähtekoodiga DataHubi hoidla pidevaks integreerimiseks ja pidevaks kasutuselevõtuks. Mõlemal on hea GitHubi integratsioon ja neid on lihtne seadistada. Enamiku avatud lähtekoodiga infrastruktuuride jaoks, mille on välja töötanud kogukond või eraettevõtted (nt. ), luuakse Dockeri kujutised ja juurutatakse Docker Hubis kogukonna hõlpsaks kasutamiseks. Kõiki Docker Hubis leitud Dockeri kujutisi saab lihtsa käsuga hõlpsasti kasutada .
Iga DataHubi avatud lähtekoodiga hoidlasse pühendumisega luuakse kõik Dockeri pildid automaatselt ja juurutatakse Docker Hubi "viimase" sildiga. Kui Docker Hub on mõnega konfigureeritud , vabastatakse kõik avatud lähtekoodiga hoidlas olevad sildid koos vastavate sildinimedega Docker Hubis.
DataHubi kasutamine
on väga lihtne ja koosneb kolmest lihtsast sammust:
- Kloonige avatud lähtekoodiga hoidla ja käivitage kõik Dockeri konteinerid docker-compose'iga, kasutades kiireks alustamiseks kaasasolevat docker-compose skripti.
- Laadige hoidlas olevad näidisandmed alla, kasutades samuti kaasasolevat käsurea tööriista.
- Sirvige oma brauseris DataHubi.
Aktiivselt jälgitud konfigureeritud ka kiirete küsimuste jaoks. Kasutajad saavad probleeme luua ka otse GitHubi hoidlas. Kõige tähtsam on see, et me tervitame ja hindame kõiki tagasisidet ja ettepanekuid!
Tuleviku plaanid
Praegu on avatud lähtekoodiga DataHubi iga infrastruktuur või mikroteenus üles ehitatud Dockeri konteinerina ja kogu süsteem on orkestreeritud . Arvestades populaarsust ja laialdast levikut , sooviksime lähitulevikus pakkuda ka Kubernetesi lahendust.
Samuti plaanime pakkuda võtmed kätte lahendust DataHubi juurutamiseks avalikus pilveteenuses, näiteks , või . Arvestades hiljutist teadet LinkedIni üleminekust Azure'i, on see vastavuses metaandmete meeskonna sisemiste prioriteetidega.
Viimaseks, kuid mitte vähemtähtsaks, tänu kõigile avatud lähtekoodiga kogukonnas DataHubi varajastele kasutuselevõtjatele, kes on hinnanud DataHubi alfasid ja aidanud meil probleeme tuvastada ja dokumentatsiooni täiustada.
Allikas: www.habr.com