Atvirojo kodo „DataHub“: „LinkedIn“ metaduomenų paieškos ir atradimo platforma
Greitai rasti reikiamus duomenis būtina bet kuriai įmonei, kuri remiasi dideliais duomenų kiekiais, kad galėtų priimti duomenimis pagrįstus sprendimus. Tai ne tik daro įtaką duomenų naudotojų (įskaitant analitikus, mašininio mokymosi kūrėjus, duomenų mokslininkus ir duomenų inžinierius) produktyvumui, bet ir turi tiesioginės įtakos galutiniams produktams, kurie priklauso nuo kokybiško mašininio mokymosi (ML) dujotiekio. Be to, tendencija diegti ar kurti mašininio mokymosi platformas natūraliai iškelia klausimą: koks yra jūsų būdas viduje atrasti funkcijas, modelius, metrikas, duomenų rinkinius ir kt.
Šiame straipsnyje kalbėsime apie tai, kaip paskelbėme duomenų šaltinį pagal atvirą licenciją mūsų metaduomenų paieškos ir atradimo platformoje, pradedant nuo pirmųjų projekto dienų . „LinkedIn“ palaiko savo „DataHub“ versiją atskirai nuo atvirojo kodo versijos. Pradėsime paaiškindami, kodėl mums reikia dviejų atskirų kūrimo aplinkų, tada aptarsime ankstyvus atvirojo kodo „WhereHows“ naudojimo būdus ir palyginsime savo vidinę (gamybinę) „DataHub“ versiją su „DataHub“ versija. . Taip pat pasidalinsime informacija apie mūsų naują automatinį atvirojo kodo naujinimų siuntimo ir gavimo sprendimą, kad abi saugyklos būtų sinchronizuojamos. Galiausiai pateiksime instrukcijas, kaip pradėti naudoti atvirojo kodo „DataHub“, ir trumpai aptarsime jo architektūrą.
„WhereHows“ dabar yra „DataHub“!
Anksčiau pristatyta „LinkedIn“ metaduomenų komanda („WhereHows“ įpėdinis), „LinkedIn“ paieškos ir metaduomenų aptikimo platforma ir pasidalino planais ją atidaryti. Netrukus po šio pranešimo išleidome „DataHub“ alfa versiją ir pasidalinome ja su bendruomene. Nuo tada mes nuolat prisidedame prie saugyklos ir dirbome su suinteresuotais vartotojais, kad pridėtume labiausiai pageidaujamas funkcijas ir išspręstume problemas. Džiaugiamės galėdami pranešti apie oficialų leidimą .
Atvirojo kodo metodai
Originalus „LinkedIn“ portalas „WhereHows“, skirtas duomenims rasti ir iš kur jie gaunami, prasidėjo kaip vidinis projektas; metaduomenų komanda jį atidarė . Nuo tada komanda visada palaikė dvi skirtingas kodų bazes – vieną atvirojo kodo, o kitą – vidiniam LinkedIn naudojimui, nes ne visos „LinkedIn“ naudojimo atvejams sukurtos produkto funkcijos paprastai buvo taikomos platesnei auditorijai. Be to, WhereHows turi tam tikrų vidinių priklausomybių (infrastruktūra, bibliotekos ir kt.), kurios nėra atvirojo kodo. Vėlesniais metais „WhereHows“ patyrė daugybę iteracijų ir kūrimo ciklų, todėl dviejų kodų bazių sinchronizavimas buvo didelis iššūkis. Metaduomenų komanda daugelį metų išbandė skirtingus metodus, siekdama, kad vidinis ir atvirojo kodo kūrimas būtų sinchronizuojamas.
Pirmas bandymas: „Pirmiausia atvirasis šaltinis“
Iš pradžių vadovavomės „pirmiausia atvirojo kodo“ kūrimo modeliu, kai dauguma kūrimo vyksta atvirojo kodo saugykloje, o pakeitimai atliekami vidiniam diegimui. Šio metodo problema yra ta, kad kodas visada pirmiausia siunčiamas į „GitHub“, kol jis nėra visiškai peržiūrėtas viduje. Kol nebus atlikti pakeitimai atvirojo kodo saugykloje ir nebus atliktas naujas vidinis diegimas, nerasime jokių gamybos problemų. Esant prastam dislokavimui, taip pat buvo labai sunku nustatyti kaltininką, nes pakeitimai buvo atliekami partijomis.
Be to, šis modelis sumažino komandos produktyvumą kuriant naujas funkcijas, kurioms reikėjo greitų iteracijų, nes dėl jo visi pakeitimai pirmiausia buvo perkelti į atvirojo kodo saugyklą, o paskui perkelti į vidinę saugyklą. Norint sutrumpinti apdorojimo laiką, reikiamus pataisymus ar pakeitimus pirmiausia buvo galima atlikti vidinėje saugykloje, tačiau tai tapo didele problema, kai reikėjo sujungti šiuos pakeitimus atgal į atvirojo kodo saugyklą, nes dvi saugyklos buvo nesinchronizuotos.
Šį modelį daug lengviau įdiegti bendroms platformoms, bibliotekoms ar infrastruktūros projektams, nei naudojant visas tinkintas žiniatinklio programas. Be to, šis modelis idealiai tinka projektams, kurie pradedami atviro kodo nuo pirmos dienos, tačiau „WhereHows“ buvo sukurta kaip visiškai vidinė žiniatinklio programa. Buvo tikrai sunku visiškai abstrahuoti visas vidines priklausomybes, todėl reikėjo išlaikyti vidinę šakę, tačiau išlaikyti vidinę šakę ir kurti daugiausia atvirojo kodo nepavyko.
Antras bandymas: „Pirmiausia vidinis“
**Kaip antrąjį bandymą, perėjome prie „pirmojo vidinio“ kūrimo modelio, kuriame dauguma kūrimo vyksta įmonės viduje ir atvirojo kodo pakeitimai atliekami reguliariai. Nors šis modelis geriausiai tinka mūsų naudojimo atveju, jis turi būdingų problemų. Galimas pasirinkimas tiesiogiai perkelti visus skirtumus į atvirojo kodo saugyklą ir vėliau bandyti išspręsti sujungimo konfliktus, tačiau tai užima daug laiko. Daugeliu atvejų kūrėjai stengiasi to nedaryti kiekvieną kartą, kai peržiūri savo kodą. Dėl to tai bus daroma daug rečiau, paketais, todėl vėliau bus sunkiau išspręsti sujungimo konfliktus.
Trečią kartą pavyko!
Dėl dviejų pirmiau minėtų nesėkmingų bandymų „WhereHows GitHub“ saugykla ilgą laiką buvo pasenusi. Komanda toliau tobulino produkto funkcijas ir architektūrą, kad vidinė „WhereHows“, skirta „LinkedIn“, versija tapo pažangesnė nei atvirojo kodo versija. Jis netgi turėjo naują pavadinimą – DataHub. Remdamasi ankstesniais nesėkmingais bandymais, komanda nusprendė sukurti keičiamo dydžio ilgalaikį sprendimą.
Kiekvienam naujam atvirojo kodo projektui LinkedIn atvirojo kodo komanda pataria ir palaiko kūrimo modelį, pagal kurį projekto moduliai yra visiškai kuriami atvirojo kodo. Versijuoti artefaktai yra diegiami viešoje saugykloje ir vėl patikrinami į vidinį „LinkedIn“ artefaktą naudojant . Vadovautis šiuo kūrimo modeliu ne tik naudinga tiems, kurie naudoja atvirą kodą, bet ir sukuria modulinę, išplečiamesnę ir prijungiamą architektūrą.
Tačiau brandžiai galinei programai, tokiai kaip „DataHub“, prireiks daug laiko, kad pasiektų šią būseną. Tai taip pat neleidžia naudoti atvirojo šaltinio visiškai veikiančio diegimo, kol visos vidinės priklausomybės nėra visiškai pašalintos. Štai kodėl sukūrėme įrankius, kurie padeda greičiau ir su daug mažiau skausmo įnešti atvirojo kodo. Šis sprendimas naudingas ir metaduomenų komandai („DataHub“ kūrėjui), ir atvirojo kodo bendruomenei. Tolesniuose skyriuose bus aptariamas šis naujas požiūris.
Atvirojo kodo leidybos automatizavimas
Naujausias metaduomenų komandos požiūris į atvirojo kodo „DataHub“ yra sukurti įrankį, kuris automatiškai sinchronizuoja vidinę kodų bazę ir atvirojo kodo saugyklą. Aukšto lygio šio įrankių rinkinio funkcijos apima:
- Sinchronizuoti „LinkedIn“ kodą į atvirąjį kodą / iš atvirojo kodo, panašiai .
- Licencijos antraštės generavimas, panašus į .
- Automatiškai generuokite atvirojo kodo patvirtinimo žurnalus iš vidinių įteikimo žurnalų.
- Užkirsti kelią vidiniams pakeitimams, kurie sutrikdo atvirojo kodo kūrimą .
Tolesniuose poskyriuose bus išsamiai aptariamos pirmiau minėtos funkcijos, kurios turi įdomių problemų.
Šaltinio kodo sinchronizavimas
Skirtingai nuo atvirojo kodo „DataHub“ versijos, kuri yra viena „GitHub“ saugykla, „LinkedIn“ „DataHub“ versija yra kelių saugyklų (vadinamų viduje) derinys. ). „DataHub“ sąsaja, metaduomenų modelio biblioteka, metaduomenų sandėlio užpakalinė paslauga ir srautinio perdavimo užduotys yra atskirose „LinkedIn“ saugyklose. Tačiau, kad atvirojo kodo vartotojams būtų lengviau, turime vieną atvirojo kodo „DataHub“ versijos saugyklą.
1 pav. Sinchronizavimas tarp saugyklų "LinkedIn DataHub ir viena saugykla DataHub atviro kodo
Kad būtų palaikomos automatizuotos kūrimo, stūmimo ir ištraukimo darbo eigos, mūsų naujasis įrankis automatiškai sukuria failo lygio susiejimą, atitinkantį kiekvieną šaltinio failą. Tačiau įrankių rinkiniui reikalinga pradinė konfigūracija, o vartotojai turi pateikti aukšto lygio modulio atvaizdavimą, kaip parodyta toliau.
{
"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"
]
}Modulio lygio atvaizdavimas yra paprastas JSON, kurio raktai yra tiksliniai moduliai atvirojo kodo saugykloje, o reikšmės yra šaltinio modulių sąrašas „LinkedIn“ saugyklose. Bet kuris tikslinis modulis atvirojo kodo saugykloje gali būti maitinamas bet kokiu šaltinio modulių skaičiumi. Norėdami nurodyti vidinius saugyklų pavadinimus šaltinio moduliuose, naudokite Bash stiliumi. Naudodami modulio lygio susiejimo failą, įrankiai sukuria failo lygio susiejimo failą, nuskaitydami visus susijusiuose kataloguose esančius failus.
{
"${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,
}Įrankiai automatiškai sukuria failo lygio atvaizdavimą; tačiau jį vartotojas gali atnaujinti ir rankiniu būdu. Tai 1:1 „LinkedIn“ šaltinio failo susiejimas su failu atvirojo kodo saugykloje. Yra keletas taisyklių, susijusių su šiuo automatiniu failų asociacijų kūrimu:
- Jei atvirojo kodo tiksliniame modulyje yra keli šaltinio moduliai, gali kilti konfliktų, pvz. , yra daugiau nei viename šaltinio modulyje. Kaip konfliktų sprendimo strategija, mūsų įrankiai pagal numatytuosius nustatymus yra parinktis „laimi paskutinis“.
- „null“ reiškia, kad šaltinio failas nėra atvirojo kodo saugyklos dalis.
- Po kiekvieno atvirojo kodo pateikimo arba išskleidimo šis atvaizdavimas automatiškai atnaujinamas ir sukuriama momentinė nuotrauka. Tai būtina norint nustatyti šaltinio kodo papildymus ir ištrynimus po paskutinio veiksmo.
Įsipareigojimo žurnalų kūrimas
Atvirojo kodo įpareigojimų įteikimo žurnalai taip pat automatiškai generuojami sujungiant vidinių saugyklų įsipareigojimų žurnalus. Žemiau pateikiamas patvirtinimo žurnalo pavyzdys, rodantis mūsų įrankio sugeneruoto patvirtinimo žurnalo struktūrą. Įsipareigojimas aiškiai nurodo, kurios šaltinio saugyklų versijos yra supakuotos tame įsipareigojime, ir pateikia įsipareigojimų žurnalo santrauką. Patikrinkite šį naudojant tikrą mūsų įrankių rinkinio sugeneruoto įsipareigojimų žurnalo pavyzdį.
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.0Priklausomybės testas
LinkedIn turi , kuri padeda užtikrinti, kad vidinio kelių produktų pakeitimai nepažeistų priklausomų kelių produktų rinkinio. Atvirojo kodo „DataHub“ saugykla nėra kelių produktų ir ji negali būti tiesioginė priklausomybė nuo kelių produktų, tačiau naudojant kelių produktų paketą, kuris gauna atvirojo kodo „DataHub“ šaltinio kodą, vis tiek galime naudoti šį priklausomybės testą. Taigi bet koks pakeitimas (kuris vėliau gali būti atskleistas) bet kuriame iš kelių produktų, kurie tiekia atvirojo kodo „DataHub“ saugyklą, suaktyvina kūrimo įvykį apvalkalo daugiaprodukte. Todėl bet koks pakeitimas, dėl kurio nepavyksta sukurti įvyniojamo produkto, neatlaiko bandymų prieš pradedant naudoti pradinį produktą ir yra grąžinamas.
Tai naudingas mechanizmas, padedantis užkirsti kelią bet kokiam vidiniam įsipareigojimui, kuris sulaužo atvirojo kodo kūrimą ir aptinka jį įvykdymo metu. Be to būtų gana sunku nustatyti, dėl kurio vidinio įpareigojimo atvirojo kodo saugyklos kūrimas nepavyko, nes vidinius pakeitimus kaupiame į DataHub atvirojo kodo saugyklą.
Atvirojo kodo „DataHub“ ir mūsų gamybinės versijos skirtumai
Iki šiol aptarėme dviejų „DataHub“ saugyklų versijų sinchronizavimo sprendimą, tačiau vis dar nenurodėme priežasčių, kodėl mums pirmiausia reikia dviejų skirtingų kūrimo srautų. Šiame skyriuje išvardinsime viešosios „DataHub“ versijos ir „LinkedIn“ serverių gamybinės versijos skirtumus ir paaiškinsime šių skirtumų priežastis.
Vienas neatitikimų šaltinių kyla dėl to, kad mūsų gamybinė versija priklauso nuo kodo, kuris dar nėra atvirojo kodo, pvz., „LinkedIn's Offspring“ („LinkedIn“ vidinė priklausomybės įterpimo sistema). Palikuonys plačiai naudojami vidinėse kodų bazėse, nes tai yra tinkamiausias dinaminės konfigūracijos valdymo metodas. Bet tai nėra atvirojo kodo; todėl mums reikėjo rasti atvirojo kodo alternatyvų atvirojo kodo „DataHub“.
Yra ir kitų priežasčių. Kadangi „LinkedIn“ poreikiams kuriame metaduomenų modelio plėtinius, šie plėtiniai paprastai yra labai specifiniai „LinkedIn“ ir negali būti tiesiogiai taikomi kitoms aplinkoms. Pavyzdžiui, turime labai konkrečias dalyvių ID ir kitų tipų atitinkančių metaduomenų etiketes. Taigi, mes pašalinome šiuos plėtinius iš „DataHub“ atvirojo kodo metaduomenų modelio. Bendraudami su bendruomene ir suprasdami jos poreikius, kur reikės, dirbsime su įprastomis atvirojo kodo šių plėtinių versijomis.
Lengvas naudojimas ir lengvesnis pritaikymas atvirojo kodo bendruomenei taip pat įkvėpė kai kuriuos skirtumus tarp dviejų „DataHub“ versijų. Geras to pavyzdys yra srauto apdorojimo infrastruktūros skirtumai. Nors mūsų vidinėje versijoje naudojama valdoma srauto apdorojimo sistema, atvirojo kodo versijai pasirinkome naudoti integruotą (atskirą) srauto apdorojimą, nes taip išvengiama kitos infrastruktūros priklausomybės.
Kitas skirtumo pavyzdys yra viena GMS (generalizuota metaduomenų saugykla) atvirojo kodo diegime, o ne keliose GMS. GMA (generalizuota metaduomenų architektūra) yra „DataHub“ pagrindinės architektūros pavadinimas, o GMS yra metaduomenų saugykla GMA kontekste. GMA yra labai lanksti architektūra, leidžianti paskirstyti kiekvieną duomenų konstrukciją (pvz., duomenų rinkinius, vartotojus ir kt.) į savo metaduomenų saugyklą arba saugoti kelias duomenų konstrukcijas vienoje metaduomenų saugykloje tol, kol registre yra duomenų struktūros atvaizdavimas. GMS atnaujintas. Kad būtų lengviau naudoti, pasirinkome vieną GMS egzempliorių, kuris saugo visas skirtingas duomenų konstrukcijas atvirojo kodo „DataHub“.
Išsamus dviejų įgyvendinimų skirtumų sąrašas pateiktas toliau esančioje lentelėje.
Produkto savybės
„LinkedIn DataHub“.
Atvirojo kodo DataHub
Palaikomos duomenų konstrukcijos
1) duomenų rinkiniai 2) vartotojai 3) metrika 4) ML funkcijos 5) diagramos 6) prietaisų skydeliai
1) Duomenų rinkiniai 2) Vartotojai
Palaikomi duomenų rinkinių metaduomenų šaltiniai
1) 2) Couchbase 3) 4) 5) HDFS 6) Avilys 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Susiliejusi Kafka
Srauto apdorojimas
Tvarko
Įterptas (atskiras)
Priklausomybės įpurškimas ir dinaminė konfigūracija
LinkedIn palikuonys
Konstravimo įrankiai
„Ligradle“ („LinkedIn“ vidinis „Gradle“ įvynioklis)
CI / CD
CRT („LinkedIn“ vidinis CI / CD)
ir
Metaduomenų parduotuvės
Paskirstytos kelios GMS: 1) duomenų rinkinys GMS 2) naudotojo GMS 3) metrinis GMS 4) funkcija GMS 5) diagrama / prietaisų skydelio GMS
Vienas GMS skirtas: 1) duomenų rinkiniams 2) vartotojams
Mikropaslaugos Docker konteineriuose
supaprastina programų diegimą ir platinimą . Kiekviena „DataHub“ paslaugos dalis yra atvirojo kodo, įskaitant infrastruktūros komponentus, tokius kaip „Kafka“, , и , turi savo Docker vaizdą. Mes naudojome „Docker“ konteineriams orkestruoti .
2 pav. Architektūra DataHub *atviro kodo**
Aukšto lygio DataHub architektūrą galite pamatyti aukščiau esančiame paveikslėlyje. Be infrastruktūros komponentų, jame yra keturi skirtingi „Docker“ konteineriai:
datahub-gms: metaduomenų saugojimo paslauga
Datahub-frontend: programa , aptarnaujantis „DataHub“ sąsają.
datahub-mce-consumer: programa , kuris naudoja metaduomenų keitimo įvykio (MCE) srautą ir atnaujina metaduomenų saugyklą.
datahub-mae-consumer: programa , kuris naudoja metaduomenų audito įvykių srautą (MAE) ir sukuria paieškos indeksą bei grafikų duomenų bazę.
Atvirojo kodo saugyklos dokumentacija ir yra išsamesnės informacijos apie įvairių tarnybų funkcijas.
CI / CD „DataHub“ yra atvirojo kodo
Naudoja atvirojo kodo „DataHub“ saugykla nuolatinei integracijai ir nuolatiniam diegimui. Abu turi gerą GitHub integraciją ir yra lengvai nustatomi. Daugumai atvirojo kodo infrastruktūrų, kurias sukūrė bendruomenė ar privačios įmonės (pvz., ), „Docker“ vaizdai sukuriami ir diegiami „Docker Hub“, kad bendruomenė galėtų juos lengviau naudoti. Bet kurį „Docker Hub“ rastą „Docker“ vaizdą galima lengvai naudoti naudojant paprastą komandą .
Su kiekvienu įsipareigojimu „DataHub“ atvirojo kodo saugykloje visi „Docker“ vaizdai automatiškai sukuriami ir diegiami „Docker Hub“ su „naujausia“ žyma. Jei „Docker Hub“ sukonfigūruotas su kai kuriais , visos atvirojo kodo saugykloje esančios žymos taip pat išleidžiamos su atitinkamais žymų pavadinimais „Docker Hub“.
Naudojant DataHub
yra labai paprastas ir susideda iš trijų paprastų žingsnių:
- Klonuokite atvirojo kodo saugyklą ir paleiskite visus „Docker“ konteinerius naudodami „Docker-compose“, naudodami pateiktą „docker-compose“ scenarijų, kad galėtumėte greitai pradėti.
- Atsisiųskite saugykloje pateiktų duomenų pavyzdį naudodami komandų eilutės įrankį, kuris taip pat yra pateiktas.
- Naršykite „DataHub“ naršyklėje.
Aktyviai sekamas taip pat sukonfigūruotas greitiems klausimams. Vartotojai taip pat gali kurti problemas tiesiogiai „GitHub“ saugykloje. Svarbiausia, laukiame ir vertiname visus atsiliepimus ir pasiūlymus!
Ateities planai
Šiuo metu kiekviena atvirojo kodo „DataHub“ infrastruktūra arba mikropaslauga yra sukurta kaip „Docker“ konteineris, o visa sistema yra surengta naudojant . Atsižvelgiant į populiarumą ir plačiai paplitusią , taip pat artimiausiu metu norėtume pateikti Kubernetes pagrįstą sprendimą.
Taip pat planuojame pateikti galutinį sprendimą, skirtą „DataHub“ diegti viešoje debesijos paslaugoje, pvz., , arba . Atsižvelgiant į neseniai paskelbtą „LinkedIn“ perkėlimą į „Azure“, tai atitiks metaduomenų komandos vidinius prioritetus.
Paskutinis, bet ne mažiau svarbus dalykas – dėkojame visiems pirmiesiems DataHub naudotojams atvirojo kodo bendruomenėje, kurie įvertino DataHub alfa versijas ir padėjo mums nustatyti problemas bei tobulinti dokumentaciją.
Šaltinis: www.habr.com