Avaallika DataHub: LinkedIn'i metaandmete otsimise ja avastamise platvorm

Avaallika DataHub: LinkedIn'i metaandmete otsimise ja avastamise platvorm

Kiire andmete leidmine on vajalik igas ettevõttes, mis tugineb suurtele andmemassidele nende andmete põhjal tehtavate otsuste langetamiseks. See mõjutab mitte ainult andmekasutajate tootlikkust (sealhulgas analüütikuid, masinõppe arendajaid, andmetöötlejaid ja andengineere), vaid ka otseselt lõppprodukte, mis sõltuvad kvaliteetsest masinõppe (ML) torustikust. Lisaks kutsub trend masinõppe platvormide rakendamisel või loomisel loomulikult esile küsimuse: kuidas toimub teie sisene funktsioonide, mudelite, näitajate, andmestike jne avastamine?

Selles artiklis räägime, kuidas me avaldasime andmeallika avatud litsentsiga DataHub meie metaandmete otsingu ja avastamise platvormil, alustades projekti esimestest päevadest WhereHows. LinkedIn toetab oma versiooni DataHubi eraldi avatud lähtekoodiga versioonist. Alustame selgitusest, miks on meil vaja kahte eraldi arenduskeskkonda, seejärel arutame esimesi lähenemisviise WhereHows'i kasutamiseks avatud lähtekoodiga ning teeme võrdluse meie sisemise (tootmis) versiooni DataHubist avatud versiooniga. GitHub. Jagame ka üksikasju meie uue automatiseeritud lahenduse kohta avatud lähtekoodiga versioonide saatmiseks ja vastuvõtmiseks, et sünkroonida kahte hoidlat. Lõpuks anname juhised, kuidas alustada DataHubi kasutamist avatud lähtekoodiga ning arutame lühidalt selle arhitektuuri.

WhereHows on nüüd DataHub!

LinkedIn'i metaandmete meeskond tutvustas varem DataHub (WhereHows'i järglane), LinkedIn'i metaandmete otsingu ja avastamise platvorm, ning jagasime tulevikuplaane selle avamiseks. Peale selle teadaande avaldamist lasime välja DataHubi alfa versiooni ja jagasime selle kogukonnaga. Sellest ajast alates oleme pidevalt panustanud hoidlasse ja teinud koostööd huvirühmadega, et lisada kõige nõutumaid funktsioone ja lahendada probleeme. Nüüd oleme uhked, et saame kuulutada ametlikku väljalaskmist. DataHub GitHub'is.

Avaallika lähenemised

WhereHows, LinkedIn'i algne andmete otsimise ja päritolu portaal, avati siseprojektina; metaandmete meeskond avas selle avaldatud kood 2016. aastal. Sellest ajast alates on meeskond alati hoidnud kahte erinevat koodibaasi - ühte avatud lähtekoodiga ja teist LinkedIni sisekasutuseks, kuna mitte kõik LinkedIni kasutusjuhtide jaoks välja töötatud tootefunktsioonid ei olnud laiemale publikule rakendatavad. Lisaks on WhereHows'il mõned sisemised sõltuvused (infrastruktuur, raamatukogud jne), mille lähtekood ei ole avatud. Järgnevate aastate jooksul on WhereHows läbinud mitmeid iteratsioone ja arendus-tsükleid, mis on muutnud kahe koodibaasi sünkroonimise suureks väljakutseks. Metaandmete meeskond on aastate jooksul püüdnud kasutada erinevaid lähenemisviise, et proovida sünkroonida sisearendust ja avatud lähtekoodi arendust.

Esimene katse: „Esiteks avatud kood“

Alguses järgnesime arendustegevuse mudelile "esiteks avatud lähtekood", kus põhialused arendatakse avatud lähtekoodiga hoidlas ja muudatused kantakse üle sisemisse juurutamisse. Selle lähenemise probleem seisneb selles, et kood saadetakse alati esmalt GitHubi, enne kui see on täielikult sisemiselt kontrollitud. Seni, kuni muudatused avatud lähtekoodiga hoidlast ei rakendata ja uut sisemist juurutamist ei toimu, ei avasta me tootmisprobleeme. Halva juurutamise korral oli samuti väga keeruline teha kindlaks süüdlane, kuna muudatusi tehti partiidena.

Lisaks vähendas see mudel meeskonna tootlikkust uute funktsioonide arendamisel, mis nõudsid kiireid iteratsioone, kuna see sundis kõiki muudatusi esmalt avatud lähtekoodiga hoidlasse panema ja seejärel sisemisse hoidlasse üle kandma. Töötlusaegade lühendamiseks võis vajaliku paranduse või muudatuse esmalt teha sisehoidlas, kuid see tekitas tohutu probleemi, kui tuli need muudatused tagasi avatud lähtekoodiga hoidlasse ühendada, sest kaks hoidlat olid desünkroonitud.

Seda mudelit on palju lihtsam rakendada üldiste platvormide, raamatukogude või infrastruktuuri projektide jaoks kui täiesti funktsionaalsete kasutajate veebirakenduste jaoks. Lisaks sobib see mudel ideaalselt projektidele, mis algavad avatud lähtekoodiga esimesest päevast, kuid WhereHows loodi täiesti sisemise veebirakendusena. Oli tõesti keeruline täielikult eralduda kõigist sisemistest sõltuvustest, seetõttu pidime säilitama sisemise haru, kuid sisemise haru säilitamine ja peamiselt avatud lähtekoodiga arendus ei töötanud päris hästi.

Teine katse: «Esiteks sisemine»

** Teise katse raames oleme läinud üle „esmajärjekorras siseveebiarendusele” mudelile, kus peamine arendus toimub ettevõtte siseselt ning muudatused tehakse avatud lähtekoodiga regulaarselt. Kuigi see mudel sobib meie kasutusele kõige paremini, kaasnevad sellega probleemid. Kõikide erinevuste otsene edastamine avatud lähtekoodiga hoidlasse ning seejärel jõudude jagamine sulandumisprobleemide lahendamiseks hiljem - see on variant, kuid see on aeganõudev. Arendajad püüavad enamikul juhtudel seda mitte igal koodikontrollil teha. Seetõttu toimub see palju harvemini, partiidena, ja seega raskendab see hilisemaid sulandumisprobleemide lahendusi.

Kolmandal korral läks kõik korda!

Kaks varem mainitud ebaõnnestumist tõid kaasa selle, et WhereHows GitHub'i hoidla jäi pikaks ajaks ajakohastamata. Meeskond jätkas toote funktsioonide ja arhitektuuri täiustamist, mistõttu LinkedIn'i siseversioon WhereHowsist muutus järjest arenenumaks avatud lähtekoodiga versioonist. Sellel oli isegi uus nimi — DataHub. Eelnevatest ebaõnnestumistest lähtuvalt otsustas meeskond välja töötada skaleeritava pikaajalise lahenduse.

Iga uue avatud lähtekoodiga projekti puhul nõustab ja toetab LinkedIn'i avatud lähtekoodiga arendajate meeskond arendusmudelit, kus projekti moodulid välja töötatakse täielikult avatud lähtekoodiga. Versioonitoega artefaktid paigutatakse avalikku hoidlasse ning seejärel tuuakse tagasi LinkedIn'i siseartefakti kaudu välistel raamatukogudel põhineva taotluse (ELR). Selle arendusmudeli järgimine on mitte ainult kasulik avatud lähtekoodi kasutajatele, vaid toob kaasa ka modulaarse, laiendatava ja ühendatava arhitektuuri loomise.

Kuid selle saavutamiseks küpse sisemise rakenduse, näiteks DataHubi puhul, on vajalik märkimisväärne aeg. See välistab täielikult avatud lähtekoodiga rakenduse võimaluse enne, kui kõik sisemised sõltuvused on täielikult abstraheeritud. Seetõttu oleme tutvustanud tööriistu, mis aitavad meil avatud lähtekoodi panuseid kiiremini ja oluliselt valutumalt teha. See lahendus on kasulik nii metadatatmeeskonnale (DataHubi arendaja) kui ka avatud lähtekoodi kogukonnale. Järgmistes osades käsitletakse seda uut lähenemist.

Avatud lähtekoodiga avaldamise automatiseerimine

Metadatatmeeskonna uus lähenemine avatud lähtekoodiga DataHubile hõlmab tööriista loomist, mis automaatselt sünkroniseerib sisemise koodibaasi ja avatud lähtekoodiga hoidla. Selle tööriista kõrgetasemelised funktsioonid hõlmavad:

1. LinkedIni koodi sünkroonimine avatud lähtekoodiga ja tagasi, sarnaselt rsync.
2. Licensi pealkirja genereerimine, sarnaselt Apache Rat.
3. Automaatne avatud lähtekoodiga pühenduste logide genereerimine sisesisestest pühenduste logidest.
4. Siseste muudatuste takistamine, mis võivad rikkuda avatud lähtekoodiga kogumit, läbi sõltuvuste testimise.

Allpool olevates alajaotustes käsitletakse üksikasjalikult ülaltoodud funktsioone, millega seotud on huvitavad probleemid.

Allika koodi sünkroonimine

Erinevalt avatud lähtekoodiga DataHub versioonist, mis on üksik GitHubi hoidla, on LinkedIn'i DataHub versioon mitmete hoidlate kombinatsioon (töötajate seas tuntud kui multiproducts). DataHubi kasutajaliides, metaandmete mudelite teek, metaandmete salvestamisteenuse server ja voogedastustööd asuvad LinkedIn'is erinevates hoidlates. Siiski, et hõlbustada avatud lähtekoodiga kasutajate tööd, on meil olemas üksik hoidla avatud lähtekoodiga DataHubi versiooni jaoks.

Joonis 1: Sünkroonimine hoidlate vahel LinkedIn DataHub ja ühes hoidlas DataHub on avatud lähtekoodiga

Automatiseeritud töövoogude toetamiseks, koostamiseks, saatmiseks ja eraldamiseks loob meie uus tööriist automaatselt faili tasemel vaste igale algfailile. Kuid tööriistade jaoks on vajalik esialgne konfigureerimine ning kasutajad peavad esitama kõrgema taseme 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"
  ]
}

Mooduli taseme kaardistamine on lihtne JSON, mille võtmed on sihitud moodulid avatud lähtekoodiga hoidlates ja väärtused on loetelu algmoodulitest LinkedIn'i hoidlates. Iga sihitud moodul avatud lähtekoodiga hoidlates võib olla toidetud mistahes arvu algmoodulitest. Algmoodulites kasutatavaid sisehoidlate nimesid eristatakse string interpolation Bash'i stiilis. Kasutades mooduli taseme kaardistamise faili, loob tööriistade komplekt faili taseme kaardistamise, skanneerides kõik failid seotud kataloogides.

{
  "${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,
}

Failitasandi loomine toimub automaatselt tööriistade kaudu; siiski võib seda ka kasutaja käsitsi uuendada. See on 1:1 seos LinkedIn'i algfaili ja avatud lähtekoodiga hoidlas oleva faili vahel. Sellega seoses on mitmeid reegleid failitasandi automaatseks loomiseks:

• Kui avatud lähtekoodiga sihmodule jaoks on mitmeid algmodule, võivad tekkida konfliktid, näiteks sama FQCN, mis eksisteerib enam kui ühes algmodulis. Konfliktide lahendamise strateegiana kasutavad meie tööriistad vaikimisi valikut "viimane võidab".
• "null" tähendab, et algfail ei kuulu avatud lähtekoodiga hoidla hulka.
• Pärast iga avatud lähtekoodi saatmist või selle väljavõtmist värskendatakse see seos automaatselt ja luuakse hetkepilt. See on vajalik, et määrata, millisest lähtekoodist pärast viimast tegevust on lisatud või eemaldatud.

Kohandatud logide loomine

Avatud lähtekoodi commit-logid luuakse automaatselt ka siserepositooriumide logide ühendamise teel. Allpool on toodud commit-logi näidis, et näidata meie tööriista loodud commit-logi struktuuri. Commit näitab selgelt, millised versioonid lähte-repositooriumidest on selle commit'i pakitud, ja annab kokkuvõtte commit-logist. Vaadake see kommitt reaalses commit-logi näites, mis on loodud meie tööriista abil.

metadata-models 29.0.0 -> 30.0.0
    Lisatud aspekti mudel foo
    Probleem lahendatud bar

dataset-gms 2.3.0 -> 2.3.4
    Lisatud rest.li API foo aspekti teenindamiseks

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

Sõltuvuste testimine

LinkedInil on sõltuvuste testimise infrastruktuur, mis aitab tagada, et sisemised mitme toote muudatused ei riku seotud mitme toote kogumist. Avohutusallikaga DataHub'i hoidla ei ole mitme toote, ja see ei saa olla otsene sõltuvus ükskõik millisest mitmest tootest, kuid mitme toote kestaga, mis ekstraktib avohutusallika DataHub'i lähtekoodi, saame me endiselt seda sõltuvuskatsetuse süsteemi kasutada. Seega, iga muudatus (mille võib hiljem avalikustada) millisestki mitmest tootest, mis toidab avohutusallikaga DataHub'i hoidlat, käivitab kestatootes ehitamise sündmuse. Seega, iga muudatus, mis ei võimalda mitme toote kestat ehitada, ei läbinud testimist enne lähte mitme toote kommitimist ja tagastatakse.

See on kasulik mehhanism, mis aitab vältida mis tahes sisemist commit'i, mis rikub avatud lähtekoodiga ehitamist, ning tuvastab selle commit'i loomise ajal. Ilma selleta oleks üsna keeruline määrata, milline sisemine commit viis avatud lähtekoodiga hoidla ehituse ebaõnnestumiseni, kuna me paigutame paketiga seotud sisemised muudatused DataHub avatud lähtekoodiga hoidlasse.

Erinevused DataHub avatud lähtekoodiga ja meie tootmisversiooni vahel

Seni oleme arutanud meie lahendust kahe DataHub hoidla versiooni sünkroonimiseks, kuid me ei ole seni määratlenud põhjuseid, miks meil üldse on vaja kahte erinevat arendusteed. Käesolevas peatükis toome välja erinevused DataHubi avaliku versiooni ja LinkedIn'i serverites kasutatava tootmisversiooni vahel ning selgitame nende erinevuste põhjuseid.

Üks lahknevuse allikas tuleneb tõsiasjast, et meie tootmisversioon sõltub veel avatud lähtekoodiga koodist, näiteks LinkedIn’i Offspring (LinkedIn’i sisemiste sõltuvuste struktuur). Offspring on laialdaselt kasutusel meie sisemises koodibaasis, kuna see on eelistatud meetod dünaamilise konfiguratsiooni haldamiseks. Kuid see ei ole avatud lähtekoodiga; seetõttu pidime leidma avatud lähtekoodiga alternatiivid DataHubile.

On ka teisi põhjuseid. Kui me arendame metadata mudeleid LinkedIni vajaduste jaoks, on need laiendused tavaliselt väga spetsiifilised LinkedInile ega pruugi otse teiste keskkondadega seostatavad olla. Näiteks on meil väga spetsiifilised sildid osalejate identifikaatorite ja teiste vastavuse metadata tüüpide jaoks. Seega oleme praegu need laiendused avatud lähtekoodiga DataHubi metadata mudelist välja jätnud. Kui me suhtleme kogukonnaga ja mõistame nende vajadusi, töötame nende laienduste avatud lähtekoodiga versioonide kallal, kui see on vajalik.

Kasutusmugavust ja lihtsamat kohandamist avatud lähtekoodiga kogukonna jaoks on ka inspireerinud mõned erinevused kahe DataHubi versiooni vahel. Erinevused voogedastuse taristutes on hea näide. Kuigi meie sisemine versioon kasutab hallatavat voogedastustaristut, otsustasime avatud lähtekoodiga versioonis kasutada integreeritud (iseisev) voogedastust, kuna see võimaldab vältida veel ühe taristus sõltuvuse loomist.

Teine näide erinevusest on üks GMS (Üldine Metainfode Mälukoht) avatud lähtekoodiga rakenduses, mitte mitu GMS-i. GMA (Üldine Metainfode Arhitektuur) on DataHubi sisemise arhitektuuri nimetus, samas kui GMS on metainfode mälukoht GMA kontekstis. GMA on väga paindlik arhitektuur, mis võimaldab teil jagada iga andmekonstruktsiooni (nt andmestikud, kasutajad jne) omaenda metainfode mälukohta või hoida mitut andmekonstruktsiooni ühes metainfode mälukohas, kuni GMS-is andmestruktuuri kuvamise registrit värskendatakse. Lihtsuse huvides valisime ühe GMS-i, mis salvestab kõik erinevad andmekonstruktsioonid avatud lähtekoodiga DataHubis.

Kaks rakendust eristavate erinevuste täiendav loetelu on toodud tabelis allpool.

Toote omadused
LinkedIn DataHub
Avatud Lähtekoodiga DataHub

Toetatud andmekonstruktsioonid
1) Andmestikud 2) Kasutajad 3) Näitajad 4) ML omadused 5) Diagrammid 6) Armatuurlaud
1) Andmestikud 2) Kasutajad

Toetatud metainfode allikad andmestike jaoks
1) Ambry 2) Couchbase 3) Dalids 4) Espresso 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) Presto 12) Seas 13) Teradata 13) Vector 14) Venice
Hive Kafka RDBMS

Pub-sub
LinkedIn Kafka
Confluent Kafka

Voogedetöötlus
Haldatud
Sisseehitatud (iseseisev)

Sõltuvuste sisestamine ja dünaamiline konfigureerimine
LinkedIn'i järglased
Spring

Ehitusriistad
Ligradle (LinkedIn'i sisemine Gradle'i wrapper)
Gradlew

CI/CD
CRT (LinkedIn'i sisemine CI/CD)
TravisCI ja Docker Hub

Metadaatide salvestused
Jaotatud mitme GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Üksik GMS: 1) Andmestikud 2) Kasutajad

Mikroteenused Docker'i konteinerites

Docker lihtsustab rakenduste juurutamist ja levitamist konteinerimisega. Iga DataHub'i avatud lähtekoodiga teenuse osa, sealhulgas infrastruktuuri komponendid nagu Kafka, Elasticsearch, Neo4j ja MySQL, omab oma Docker'i pilti. Docker'i konteinerite orkestreerimiseks kasutasime Docker Compose.

Joonis 2: Arhitektuur DataHub *avamooduli*

Saate näha DataHub'i kõrgetasemelist arhitektuuri eespool olevast pildist. Lisaks infrastruktuuri komponentidele on tal neli erinevat Docker'i konteinerit:

datahub-gms: metadaatide salvestusteenus

datahub-frontend: rakendus Play, mis teenindab DataHub'i liidest.

datahub-mce-consumer: rakendus Kafka Streams, mis kasutab metadaatide muutmise sündmuste voogu (MCE) ja uuendab metadaatide salvestust.

datahub-mae-consumer: rakendus Kafka Streams, mis kasutab metadaatide auditi sündmuste voogu (MAE) ja loob otsinguindeksi ja graafi andmebaasi.

Avatud lähtekoodiga repository dokumentatsioon ja DataHubi blogi algne postitus sisaldab põhjalikku teavet erinevate teenuste omaduste kohta.

CI / CD DataHubis avatud lähtekoodiga

DataHubi avatud lähtekoodiga hoidla kasutab TravisCI katkestusteta integreerimist ja Docker Hub katkestusteta juurutamist. Mõlemad integreeruvad hästi GitHubiga ja neid on lihtne seadistada. Suurema osa avatud lähtekoodiga infrastruktuurist, mille on välja töötanud kogukond või eraettevõtted (näiteks Confluent), on loodud Docker'i pildid ja need on juurutatud Docker Hub's, et kogukond saaks neid hõlpsasti kasutada. Iga Docker'i pilt, mille leiab Docker Hub'ist, on lihtne kasutada lihtsa käsu abil docker pull.

Iga kord, kui DataHubi avatud lähtekoodiga hoidlas toimub commit, luuakse ja juurutatakse kõik Docker'i pildid automaatselt Docker Hub's koos 'latest' sildiga. Kui Docker Hub's on seadistatud mõningaid harude nimede regulaaravaldisi, siis vabastatakse kõik sildid avatud lähtekoodiga hoidlas ka vastavate siltide nimedega Docker Hub's.

DataHubi kasutamine

DataHubi seadistamine on väga lihtne ja koosneb kolmest lihtsast sammust:

1. Kloonige avatud lähtekoodiga repot ja käivitage kõik Docker konteinerid docker-compose abil, kasutades pakutud docker-compose skripti kiireks käivitamiseks.
2. Laadige alla andmemustrid, mis on esitatud reposis, kasutades ka käsurea tööriista, mis on samuti saadud.
3. Sirvige DataHub'i oma brauseris.

Aktiivselt jälgitud Gitteri vestlus on samuti seadistatud kiirete küsimuste jaoks. Kasutajad saavad luua probleeme otse GitHubi repole. Eriti hindame ja ootame kõiki tagasiside ja ettepanekuid!

Tulevikuplaanid

Praegu on iga DataHub'i avatud lähtekoodiga infrastruktuur või mikroteenus ehitatud kui Docker konteiner, ja kogu süsteem orkestreeritakse docker-compose. Arvestades selle populaarsust ja laialdast kasutust Kubernetes, tahame lähitulevikus pakkuda ka Kubernetes'i põhist lahendust.

Kavandame pakkuda ka valmis lahendust DataHub'i juurutamiseks avalikus pilveteenuses, näiteks Azure, AWS või Google Cloud. Arvestades LinkedIn'i hiljutist teadet migratsioonist Azure'i, vastab see rühma metainformatsiooni sisemistele prioriteetidele.

Ja viimane, kuid mitte vähem tähtis: suur tänu kõigile DataHubi esimestele kasutajatele avatud lähtekoodiga kogukonnas, kes hindasid DataHubi alfa versioone ja aitasid meil tuvastada probleeme ning parandada dokumentatsiooni.

Allikas: habr.com