DataHub avatud koodiga: LinkedIni metaandmete otsingu ja avastamise platvorm

DataHub avatud koodiga: LinkedIni metaandmete otsingu ja avastamise platvorm

Kiire andmete leidmine on vajalik igale ettevõttele, mis toetub suurtele andmehulkadele otsuste tegemiseks. See mõjutab mitte ainult andmeanalüütikute, masinõppe arendajate, andmete töötlemise spetsialistide ja andmeinseneride tootlikkust, vaid ka lõpptooteid, mis sõltuvad kvaliteetsest masinõppe (ML) torustikust. Lisaks tekitab masinõppe platvormide rakendamine või loomine loomulikult küsimuse: milline on teie sisemine meetod funktsioonide, mudelite, mõõdikute, andmehulkade jne avastamiseks?

Selles artiklis räägime sellest, kuidas me avaldasime avatud litsentsiga andmeallika DataHub meie metadsete otsingu ja avastamise platvormis, alates projekti esimestest päevadest WhereHows. LinkedIn toetab oma versiooni DataHubist eraldi avatud lähtekoodiga versioonist. Alustame selgitusega, miks vajame kahte eraldi arenduskeskkonda, seejärel arutame avatud lähtekoodiga WhereHows’i kasutamise esimesi lähenemisviise ja võrdleme meie sisemist (tootmis)versiooni DataHubi versiooniga GitHub. Jagame ka üksikasju meie uue automatiseeritud lahenduse kohta, et edastada ja vastaan võtta avatud lähtekoodiga värskendusi, et sünkroniseerida mõlemat repot. Lõpuks anname juhised, kuidas alustada DataHubiga avatud lähtekoodiga ning arutame lühidalt selle arhitektuuri.

WhereHows on nüüd DataHub!

LinkedIni metadsete meeskond esitles varem DataHub (WhereHowsi järeltulija), LinkedIni metadsete otsingu ja avastamise platvormi, ning jagas plaane selle avamine. Peagi pärast seda teadet vabastasime DataHubi alfa versiooni ja jagasime seda kogukonnaga. Alates sellest ajast oleme pidevalt panustanud repo ning töötanud koos huvilistega, et lisada kõige nõutavaid funktsioone ja lahendada probleeme. Nüüd rõõmustame, et saame ametlikult kuulutada DataHubi vabastamist GitHubis.

Avatud lähtekoodiga lähenemisviisid

WhereHows, LinkedIni originaalne portaal andmete leidmiseks ja nende päritolu määramiseks, avati sisemise projektina; metadsete meeskond avas selle lähtekoodi 2016. aastal. Alates sellest ajast hoidis meeskond pidevalt kahte erinevat koodibaasi - ühte avatud lähtekoodiga ja teist LinkedIni sisemiseks kasutamiseks, kuna mitte kõik LinkedIns kasutamiseks loodud toote funktsioonid ei sobinud laiemale publikule. 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äbi teinud mitmeid iteratsioone ja arendustsükleid, mis on teinud kahe koodibaasi sünkroonimise suureks probleemiks. Metaandmete meeskond on aastate jooksul proovinud erinevaid lähenemisviise, et püüda sünkroonida sisemist ja avatud lähtekoodiga arendust.

Esimene katse: "Esiteks avatud lähtekood"

Alguses järgnesime arendusmudelile "esiteks avatud lähtekood", kus põhiarendus toimub avatud lähtekoodiga repositooriumis ja muudatused tehakse sisemiseks kasutamiseks. Selle lähenemise probleem on see, et kood saadetakse alati esmalt GitHubi, enne kui see on täielikult sisemiselt kontrollitud. Enne kui muudatused on tehtud avatud lähtekoodiga repositooriumist ja uus sisemine juurutamine on toimunud, ei avastata tootmisprobleeme. Halva juurutamise korral on samuti väga keeruline tuvastada 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 repositooriumisse esitama ja seejärel sisemisse repositooriumisse kandma. Töötlusaja lühendamiseks võis vajaliku paranduse või muudatuse esmalt teha sisemises repositooriumis, kuid see kujunes tohutuks probleemiks, kui tuli need muudatused tagasi avatud lähtekoodiga repositooriumisse ühendama, kuna kaks repositooriumi olid sünkroonimisest väljas.

Seda mudelit on palju lihtsam rakendada üldiste platvormide, raamatukogude või infrastruktuuri projektide jaoks kui täisfunktsionaalsete kasutajate veebirakenduste jaoks. Lisaks on see mudel ideaalselt sobiv projektide jaoks, mis alustavad avatud lähtekoodiga algusest peale, kuid WhereHows loodi täielikult sisemise veebirakendusena. Oli tõeliselt keeruline täielikult abstraktselt kõrvale jätta kõik sisemised sõltuvused, seega pidime säilitama sisemise haru, kuid sisemise haru säilitamine ja peamine arendamine avatud lähtekoodiga ei töötanud päris hästi.

Teine katse: "Esmalt sisemine"

** Teise katse käigus liikusime "esmalt sisemine" arendusmudeli suunas, kus põhiarendus toimub ettevõtte sees ja muudatused tuuakse avatud lähtekoodis regulaarselt sisse. Kuigi see mudel sobib meie kasutusjuhtumiks kõige paremini, on sellega kaasnevaid probleeme. Kõigi erinevuste otse avatud lähtekoodi kogu sisse saatmine ja siis ühinemiskonfliktide lahendamine hiljem on variant, kuid see nõuab palju aega. Enamik arendajatest püüab seda vältida iga koodi kontrollimisel. Seetõttu tehakse seda palju harvemini, gruppide kaupa, mis muudab edasise ühinemiskonfliktide lahendamise keeruliseks.

Kolmandal korral õnnestus kõik!

Kaks eespool mainitud ebaõnnestunud katset tõid kaasa selle, et WhereHows GitHubi hoidla jäi pikka aega aegunud. Meeskond jätkas toote funktsioonide ja arhitektuuri täiustamist, seega muutus LinkedInile mõeldud sisemine versioon WhereHowsist järjest täiuslikumaks kui avatud lähtekoodiga versioon. Sellel oli isegi uus nimi - DataHub. Varasemate ebaõnnestunud katsete põhjal otsustas meeskond arendada skaleeritavat pikaajalist lahendust.

Iga uue avatud lähtekoodiga projekti jaoks toetab ja nõustab LinkedIn avatud lähtekoodiga arendajate meeskond arendusmudelit, kus projekti moodulid arendatakse täielikult avatud lähtekoodiga. Versiooniga toe artefaktid paigaldatakse avalikku hoidlasse ja seejärel tuuakse tagasi LinkedIn'i sisemisse artefakti kaudu välimise raamatukogu päringu (ELR) kauduSelle arendusmudeli järgimine on hea mitte ainult avatud lähtekoodiga kasutajatele, vaid toob kaasa ka modulaarse, laiendatava ja ühendatava arhitektuuri loomise.

Kuid selle saavutamiseks küpse sisemise rakenduse, nagu DataHub, puhul on vajalik märkimisväärne aeg. See välistab ka täielikult töötava avatud lähtekoodiga rakenduse võimaluse, kuni kõik sisemised sõltuvused on täielikult abstrakteeritud. Seetõttu oleme välja töötanud tööriistad, mis aitavad meil avatud lähtekoodiga panuseid teha kiiremini ja palju vähem valusalt. See lahendus on kasulik nii metadatameeskonnale (DataHubi arendaja) kui ka avatud lähtekoodiga kogukonnale. Järgmistes osades käsitleme seda uut lähenemist.

Avatud lähtekoodiga avaldamise automatiseerimine

Metadatameeskonna viimane lähenemine DataHubile avatud lähtekoodiga on tööriista arendamine, mis automaatselt sünkroniseerib sisemise koodibaasi ja avatud lähtekoodiga hoidla. Selle tööriista kõrgtaseme funktsioonid hõlmavad:

1. LinkedIni koodi sünkroniseerimine avatud lähtekoodiga, nagu rsync.
2. Litsentsipealkirja genereerimine, nagu Apache Rat.
3. Avatud lähtekoodiga commit logide automaatne loomine sisemistest commit logidest.
4. Sisemiste muudatuste vältimine, mis rikuvad avatud lähtekoodiga koostamist, läbi sõltuvuste testimise.

Järgmistes alajaotustes käsitletakse üksikasjalikult eespool mainitud funktsioone, mis sisaldavad huvitavaid väljakutseid.

Koodi sünkroniseerimine

Erinevalt avatud lähtekoodiga DataHubi versioonist, mis on üksik GitHubi hoidla, on LinkedIn DataHubi versioon mitme hoidla kombinatsioon (ettevõttes nimetatakse neid multiproducts). DataHubi liides, metadata mudelite teek, metadata salvestamise serveriteenus ja voogedastustööd on LinkedInis erinevates hoidlates. Siiski, et hõlbustada avatud lähtekoodiga kasutajate tööd, on meil avatud lähtekoodiga DataHubi versioonile üksik hoidla.

Joonis 1: Sünkroniseerimine hoidlate vahel LinkedIn DataHub ja üksiku hoidla DataHub avatud lähtekoodiga

Automatiseeritud töötlemise toeks loob meie uus tööriist automaatselt failitasandi vastendusi, mis vastavad igale algfailile. Siiski vajab tööriist algkonfiguratsiooni ning kasutajad peavad esitama kõrgema taseme moodulite vastenduse, nagu on näidatud allpool.

{
  "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 vastendus on lihtne JSON, mille võtmed on avatud lähtekoodiga hoidlate sihtmoodulid ning väärtused on loetelu algmoodulitest LinkedIn'i hoidlatest. Iga avatud lähtekoodiga hoidla sihtmoodul võib kasutada mitut algmoodulit. Algfailide nimetamiseks kasutatakse stringi interpolatsiooni Bash'i stiilis. Kasutades mooduli taseme vastenduse faili, loovad tööriistad failitasandi vastenduse, skaneerides kõiki faile 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 vastendus luuakse tööriistadega automaatselt; siiski saab seda ka kasutaja käsitsi uuendada. See vastendus on 1: 1 seos LinkedIn'i algfaili ja avatud lähtekoodiga hoidla faili vahel. Selle automaatse failivastenduse loomisega on seotud mitmed reeglid:

• Kui avatud lähtekoodiga sihtmooduli jaoks on mitu algmoodulit, võivad tekkida konfliktid, näiteks sama FQCN, mis eksisteerib rohkem kui ühes algmoodulis. Konfliktide lahendamise strateegiana kasutavad meie tööriistad vaikimisi „viimase võidab“ valikut.
• „null“ tähendab, et algfail ei ole osa avatud lähtekoodiga hoidlast.
• Pärast iga avatud lähtekoodiga saatmist või selle välja tõmbamist värskendatakse see vastavus automaatselt ja luuakse hetkepilt. See on vajalik, et tuvastada lähtekoodi lisamisi ja kustutamisi pärast viimast toimingut.

Commit logide loomine

Avatud lähtekoodiga commit logid luuakse automaatselt ka siserepositooriumide commit logide ühendamise kaudu. Allpool on näide commit logist, et näidata meie tööriistaga loodud commit logi struktuuri. Commit näitab selgelt, millised versioonid avatud lähtekoodiga repositooriumidest on antud commit'is pakitud, ning esitab kokkuvõtliku teabe commit logi kohta. Vaadake seda komiteed reaalses commit logi näites, mis on loodud meie tööriistaga.

metadata-models 29.0.0 -> 30.0.0
    Lisatud aspektimudel foo
    Probleem bar lahendatud

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

LinkedIn'il on sõltuvuste testimise infrastruktuur, mis aitab tagada, et sisemiste multiproduktide muudatused ei rikuks sõltuvate multiproduktide koostamist. Andmehubi avatud lähtekoodiga repositoorium ei ole multiprodukt, ja see ei saa olla otseseks sõltuvuseks mistahes multiproduktist, kuid multiprodukti kihiga, mis tõmbab andmehubi avatud lähtekoodi, saame siiski kasutada seda sõltuvuste testimise süsteemi. Seega, iga muudatus (mis võib hiljem avalikuks saada) mistahes multiproduktis, mis toidab andmehubi avatud lähtekoodiga repositooriumit, käivitab ehitamise sündmuse multiprodukti kihis. Seega ei pääse ühtegi muudatust, mis takistab multiprodukti kihi koostamist, testidest enne avatud lähtekoodiga multiprodukti commit't ja see tagastatakse.

See on kasulik mehhanism, mis aitab ennetada mistahes sisemist commit'it, mis rikub avatud lähtekoodiga koostest, ja tuvastab selle commit'i loomise ajal. Ilma selleta oleks üsna keeruline kindlaks teha, milline sisemine commit põhjustas avatud lähtekoodiga repositooriumi koostetuks mineku, kuna me paneme paketina sisemised muudatused avatud lähtekoodiga andmehubi repositooriumisse.

Erinevused avatud lähtekoodiga DataHubi ja meie tootmisversiooni vahel

Kuni tänaseni oleme arutanud meie lahendust kahe DataHubi versiooni sünkroniseerimiseks, kuid pole veel selgitanud põhjuseid, miks meil üldse on vaja kahte erinevat arendusvoogu. Selles osas loetleme eristusi avatud lähtekoodiga DataHubi ja LinkedIni serverites oleva tootmisversiooni vahel ning selgitame nende erinevuste põhjuste taga olevaid põhjuseid.

Üks eristuste allikas tuleneb faktist, et meie tootmisversioon sõltub veel mitteavalikuks muudetud koodist, näiteks LinkedIni Offspring'ist (LinkedIni sisemine sõltuvuste haldamise struktuur). Offspringit kasutatakse laialdaselt sisemises koodibaasis, kuna see on eelistatud meetod dünaamilise konfiguratsiooni haldamiseks. Kuid see pole avatud lähtekoodiga; seega pidi me leidma avatud lähtekoodiga alternatiive avatud lähtekoodiga DataHubile.

On ka teisi põhjuseid. Kuna loome metainformatsiooni mudeli laiendusi LinkedInile, on need laiendused tavaliselt väga spetsiifilised LinkedInile ja ei pruugi otse teiste keskkondadega rakenduda. Näiteks on meil väga spetsiifilised sildid osalejate tuvastajate ja muude metainformatsiooni tüüpide jaoks. Praegu oleme need laiendused avatud lähtekoodiga DataHubi metainformatsiooni mudelist välja jätnud. Kliendiga suhtlemisel ja nende vajaduste mõistmisel töötame avatud lähtekoodiga universaalsete versioonide kallal, kui see on vajalik.

Kasutusmugavus ja avatud lähtekoodiga kogukonnale lihtsam kohandamine on samuti inspireerinud mõningaid erinevusi kahe DataHubi versiooni vahel. Erinevused voogesituse infrastruktuuris on hea näide. Kuigi meie sisemine versioon kasutab hallatud voogesituse infrastruktuuri, otsustasime avatud lähtekoodiga versioonis kasutada integreeritud (iseseisvat) voogesitust, kuna see võimaldab vältida uue infrastruktuuri sõltuvuse loomist.

Teine näide erinevusest on üldise metainformatsiooni hoidla (GMS) olemasolu avatud lähtekoodiga rakenduses, mitte mitme GMS-i olemasolu. Üldine metainformatsiooni arhitektuur (GMA) on DataHubi sisemise arhitektuuri nimetus, samas kui GMS on metainformatsiooni hoidla GMA kontekstis. GMA on väga paindlik arhitektuur, mis võimaldab teil jagada iga andmestruktuuri (nt andmestikud, kasutajad jne) oma metainformatsiooni hoidlasse või hoida mitu andmestruktuuri ühes metainformatsiooni hoids. Seejuures peab olema ajakohane registri GMS-i andmestruktuuri kuvamine. Lihtsuse huvides valisime ühe GMS-i, mis hoiab kõik erinevad andmestruktuurid avatud lähtekoodiga DataHubis.

Kaks erisuunda, nende erinevuste täielik loetelu on esitatud allolevas tabelis.

Toote funktsioonid
LinkedIn DataHub
Avatud lähtekoodiga DataHub

Toetatud andmestruktuurid
1) Andmestikud 2) Kasutajad 3) Näitajad 4) ML-funktsioonid 5) Graafikud 6) Juhtpaneelid
1) Andmestikud 2) Kasutajad

Andmestike toetatud metaandmeallikad
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

Voogedastamine
Haldatud
Integreeritud (iseseisev)

Sõltuvuse süstimise ja dünaamilise konfiguratsiooni
LinkedIn Järeltulija
Spring

Ehitusriistad
Ligradle (LinkedIni sisemine Gradle ümbritseja)
Gradlew

CI/CD
CRT (LinkedIni sisemine CI/CD)
TravisCI ja Docker Hub

Metaandmete hoidlad
Jaotatud mitme GMS-i: 1) Andmestike GMS 2) Kasutaja GMS 3) Näitaja GMS 4) Funktsiooni GMS 5) Graafiku/juhtpaneeli GMS
Ainult GMS-i: 1) Andmestikud 2) Kasutajad

Mikroteenused Docker konteinerites

Docker lihtsustab rakenduste juurutamist ja levitamist konteinerimise teel.Iga avatud lähtekoodiga DataHubi teenuse osa, sealhulgas infrastruktuuri komponendid nagu Kafka, Elasticsearch, Neo4j ja MySQL, omab oma Docker pilti. Docker konteinerite orkestreerimiseks kasutame Docker Compose.

Joonis 2: Arhitektuur DataHub *avatud lähtekoodiga*

Saate vaadata DataHubi kõrgetasemelise arhitektuuri ülaltoodud pildilt. Lisaks infrastruktuuri komponentidele on tal neli erinevat Docker konteinerit:

datahub-gms: metaandmete hoidla teenus

datahub-frontend: rakendus Play, mis teenindab DataHubi liidest.

datahub-mce-consumer: rakendus Kafka Streams, mis kasutab metaandmete muutuste sündmuste voogu (MCE) ja uuendab metaandmete hoidlat.

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

Avatud lähtekoodiga repositooriumi dokumentatsioon ja DataHubi ajaveebipostitus sisaldavad üksikasjalikku teavet erinevate teenuste omaduste kohta.

CI / CD DataHubis avatud lähtekoodiga

DataHubi avatud lähtekoodiga hoidla kasutab TravisCI katkematu integreerimine ja Docker Hub katkematu juurutamine. Mõlemal on hea integreerimine GitHubiga ja need on hõlpsasti seadistatavad. Suurema osa avatud lähtekoodiga infrastruktuurist, mis on loodud kogukonna või erasektori ettevõtete poolt (näiteks Confluent), on loodud Dockeripildid, mis on juurutatud Docker Hubis, et lihtsustada kogukonna kasutamist. Iga Dockeripilt, mis on leitud Docker Hubist, on hõlpsasti kasutatav lihtsa käsuga docker pull.

Iga kord, kui avatud lähtekoodiga DataHubi hoidlas tehakse commit, luuakse kõik Dockeripildid automaatselt ja juurutatakse Docker Hubisse sildiga „latest“. Kui Docker Hubis on seadistatud mingi reeglite jääkide nimekiri, siis vabaneb kõik hoidla avatud lähtekoodiga sildid vastavate siltide nimedega Docker Hubis.

DataHubi kasutamine

DataHubi seadistamine on väga lihtne ja sisaldab kolme lihtsat sammu:

1. Kloonige avatud lähtekoodiga hoidla ja käitage kõik Dockerikonteinerid docker-compose'i abil antud docker-compose'i skripti abil kiireks käivitamiseks.
2. Laadige alla andmeproovid, mis on esitatud hoidlas, kasutades ka käsurea tööriista, mis on samuti saadaval.
3. Vaadake DataHubi oma brauseris.

Aktiivselt jälgitav Gitteri vestlus on samuti seadistatud kiirete küsimuste jaoks. Kasutajad saavad samuti luua probleeme otse GitHubi hoidlas. Mis kõige tähtsam, me tervitame ja hindame kõiki tagasisidet ja ettepanekuid!

Tulevikuplaanid

Praegu on iga DataHubi avatud lähtekoodiga infrastruktuur või mikroteenus üles ehitatud Dockerikonteinerina, kogu süsteem orkestreeritakse version: '1' services: simplesample-sonar: image: sonarqube:lts ports: - 9001:9000 - 9092:9092 network_mode: bridgekasutades. KubernetesArvestades selle populaarsust ja laialdast levikut,

soovime ka peagi pakkuda Kubernetesel põhinevat lahendust. Azure, AWS või Google CloudPlaanime samuti pakkuda valmislahendust DataHubi juurutamiseks avalikus pilveteenuses, nagu näiteks, Arvestades hiljutist LinkedIn'i väljakuulutust Azure'ile migreerimise kohta, see vastab metaandmete meeskonna siseprioriteetidele.

Ja viimane, kuid mitte vähem oluline: suur tänu kõigile DataHubi esimestele kasutajatele avatud lähtekoodiga kogukonnas, kes hindasid DataHubi beetaversioone ja aitasid meil probleemid tuvastada ning dokumentatsiooni täiustada.

Allikas: habr.com