Iturburu irekiko DataHub: LinkedIn-en metadatuen bilaketa eta aurkikuntza plataforma
Behar dituzun datuak azkar aurkitzea ezinbestekoa da datu-kopuru handietan oinarritzen den edozein enpresarentzat, datuetan oinarritutako erabakiak hartzeko. Horrek datu-erabiltzaileen produktibitatean eragiten du (analistak, ikaskuntza automatikoaren garatzaileak, datu-zientzialariak eta datu-ingeniariak barne), baizik eta kalitatezko ikaskuntza automatikoaren (ML) kanalizazio baten menpe dauden amaierako produktuetan ere eragin zuzena du. Gainera, ikaskuntza automatikoko plataformak inplementatzeko edo eraikitzeko joerak galdera hau sortzen du: zein da barnean ezaugarriak, ereduak, metrikak, datu multzoak eta abar ezagutzeko zure metodoa.
Artikulu honetan datu-iturburu bat lizentzia irekiarekin nola argitaratu dugun hitz egingo dugu gure metadatuen bilaketa eta aurkikuntza plataforman, proiektuaren hasierako egunetatik hasita . LinkedIn-ek DataHub-en bere bertsioa mantentzen du kode irekiko bertsiotik bereizita. Hasteko, bi garapen-ingurune bereizi behar ditugun azaltzen hasiko gara, ondoren kode irekiko WhereHows erabiltzeko lehen hurbilketak eztabaidatuko ditugu eta DataHub-en barneko (ekoizpeneko) bertsioa bertsioarekin alderatu. . Bi biltegiak sinkronizatuta mantentzeko kode irekiko eguneraketak bultzatzeko eta jasotzeko gure soluzio automatizatu berriari buruzko xehetasunak ere partekatuko ditugu. Azkenik, kode irekiko DataHub erabiltzen hasteko argibideak emango ditugu eta bere arkitektura laburki eztabaidatuko dugu.
WhereHows DataHub da orain!
LinkedInen metadatuen taldea aurrez aurkeztutakoa (WheHows-en ondorengoa), LinkedIn-en bilaketa eta metadatuak aurkitzeko plataforma eta irekitzeko plan partekatuak. Iragarpen honen ondoren, DataHub-en alfa bertsio bat kaleratu genuen eta komunitatearekin partekatu genuen. Geroztik, biltegian etengabe lagundu dugu eta interesa duten erabiltzaileekin lan egin dugu gehien eskatutako ezaugarriak gehitzeko eta arazoak konpontzeko. Orain pozik gaude kaleratze ofiziala iragartzeko .
Kode irekiko ikuspegiak
WhereHows, LinkedIn-en jatorrizko ataria datuak aurkitzeko eta nondik datorren, barne proiektu gisa hasi zen; metadatuen taldeak ireki zuen . Orduz geroztik, taldeak beti mantendu ditu bi kode-oinarri ezberdin βkode irekiko bat eta LinkedIn-en barneko erabilerarakoβ, LinkedIn erabilera kasuetarako garatutako produktu-ezaugarri guztiak ez baitziren orokorrean publiko zabalarentzat aplikagarriak izan. Gainera, WhereHows-ek barne-mendekotasun batzuk ditu (azpiegiturak, liburutegiak, etab.) kode irekikoak ez direnak. Ondorengo urteetan, WhereHows-ek hainbat iterazio eta garapen-ziklo igaro zituen, bi kode-oinarriak sinkronizatuta mantentzea erronka handia bihurtuz. Metadatuen taldeak hainbat ikuspegi probatu ditu urteetan zehar barneko eta kode irekiko garapena sinkronizatuta mantentzen saiatzeko.
Lehenengo saiakera: "Kode irekia lehenik"
Hasieran "kode irekiko lehenik" garapen eredua jarraitu genuen, non garapen gehiena kode irekiko biltegi batean gertatzen den eta aldaketak barne hedapenerako egiten diren. Ikuspegi honen arazoa da kodea beti GitHubera bultzatzen dela, barnean guztiz berrikusi aurretik. Kode irekiko biltegitik aldaketak egin eta barne inplementazio berri bat egin arte, ez dugu produkzio-arazorik aurkituko. Hedapen txarraren kasuan, erruduna zehaztea ere oso zaila zen aldaketak sortaka egiten zirelako.
Gainera, eredu honek taldearen produktibitatea murriztu zuen iterazio azkarrak behar zituzten ezaugarri berriak garatzean, aldaketa guztiak lehenik kode irekiko biltegi batera eraman eta gero barne biltegi batera eraman behar baitzituen. Prozesatzeko denbora murrizteko, beharrezkoa den konponketa edo aldaketa barne-biltegian egin zitekeen lehenik, baina hau arazo handi bat bihurtu zen aldaketa horiek kode irekiko biltegian batzeko orduan, bi biltegiak sinkronizatuta zeudelako.
Eredu hau askoz errazagoa da partekatutako plataformetan, liburutegietan edo azpiegitura-proiektuetan inplementatzen, ezaugarri osoko web aplikazio pertsonalizatuetarako baino. Gainera, eredu hau aproposa da lehen egunetik kode irekian hasten diren proiektuetarako, baina WhereHows guztiz barneko web aplikazio gisa eraiki zen. Benetan zaila zen barne-menpekotasun guztiak guztiz abstraitzea, beraz, barne-sardexka mantendu behar genuen, baina barne-sardexka mantentzea eta gehienbat kode irekia garatzea ez zen oso ondo atera.
Bigarren saiakera: "Barruko lehena"
**Bigarren saiakera gisa, "barne-lehenengo" garapen-eredu batera joan ginen, non garapen gehiena barnean gertatzen den eta kode irekiko kodean aldaketak egiten diren aldian-aldian. Eredu hau gure erabilera kasurako egokiena den arren, berezko arazoak ditu. Desberdintasun guztiak kode irekiko biltegira zuzenean bultzatzea eta gero bateratze-gatazkak konpontzen saiatzea aukera bat da, baina denbora asko eskatzen du. Garatzaileak kasu gehienetan saiatzen dira hau ez egiten beren kodea berrikusten duten bakoitzean. Ondorioz, hori askoz ere gutxiagotan egingo da, multzoka, eta horrela zailagoa da gero bateratze-gatazkak konpontzea.
Hirugarren aldiz funtzionatu zuen!
Goian aipatutako bi saiakera hutsek WhereHows GitHub biltegia denbora luzez zaharkituta geratu zen. Taldeak produktuaren ezaugarriak eta arkitektura hobetzen jarraitu zuen, eta, horrela, WhereHows for LinkedIn-en barneko bertsioa kode irekiko bertsioa baino aurreratuagoa izan zen. Izen berri bat ere izan zuen - DataHub. Aurreko porrot egindako saiakeretan oinarrituta, taldeak epe luzerako irtenbide eskalagarri bat garatzea erabaki zuen.
Kode irekiko edozein proiektu berrirako, LinkedIn-en kode irekiko taldeak garapen-eredu bat aholkatzen eta onartzen du, non proiektuaren moduluak guztiz kode irekian garatzen diren. Bertsiodun artefaktuak biltegi publiko batean zabaltzen dira eta, ondoren, berriro LinkedIn barneko artefaktuan egiaztatzen dira. . Garapen-eredu horri jarraitzea ez da ona kode irekia erabiltzen dutenentzat bakarrik, baizik eta arkitektura modularagoa, hedagarriagoa eta entxufagarriagoa izateaz gain.
Hala ere, DataHub bezalako back-end aplikazio heldu batek denbora kopuru handia beharko du egoera horretara iristeko. Horrek, gainera, guztiz funtzionatzen duen inplementazio bat irekitzeko aukera baztertzen du barne-mendekotasun guztiak guztiz abstraitu aurretik. Horregatik, kode irekiko ekarpenak azkarrago eta askoz min gutxiagorekin egiten laguntzen diguten tresnak garatu ditugu. Irtenbide honek metadatuen taldeari (DataHub garatzailea) eta kode irekiko komunitateari mesede egiten dio. Hurrengo ataletan ikuspegi berri hau eztabaidatuko da.
Kode irekiko argitalpenen automatizazioa
Metadatuen taldeak DataHub kode irekirako egin duen azken ikuspegia barneko kode-basea eta kode irekiko biltegia automatikoki sinkronizatzen dituen tresna bat garatzea da. Tresna-kit honen goi-mailako ezaugarriak hauek dira:
- Sinkronizatu LinkedIn kodea kode irekiarekin/tik, antzekoa .
- Lizentziaren goiburua sortzea, antzekoa .
- Sortu automatikoki kode irekiko konpromisoen erregistroak barneko konpromisoen erregistroetatik.
- Saihestu kode irekiko eraikuntzak hausten dituzten barne-aldaketak .
Ondorengo azpiataletan arazo interesgarriak dituzten aipatutako funtzioetan sakonduko da.
Iturburu-kodeen sinkronizazioa
DataHub-en kode irekiko bertsioa ez bezala, hau da, GitHub biltegi bakarra dena, DataHub-en LinkedIn bertsioa hainbat biltegiren konbinazioa da (barneko deitzen dena). ). DataHub interfazea, metadatu ereduen liburutegia, metadatuen biltegiaren backend zerbitzua eta streaming-lanak LinkedIn-en biltegi ezberdinetan daude. Hala ere, kode irekiko erabiltzaileei errazago egiteko, DataHub-en kode irekiko bertsiorako biltegi bakarra dugu.
1. Irudia: Biltegien arteko sinkronizazioa LinkedIn DataHub eta biltegi bakarra DataHub kode irekia
Lan-fluxu automatizatuak sortzeko, bultzatzeko eta ateratzeko, gure tresna berriak automatikoki sortzen du iturburu-fitxategi bakoitzari dagokion fitxategi-mailako mapaketa. Hala ere, tresna-kitak hasierako konfigurazioa behar du eta erabiltzaileek goi-mailako moduluen mapak eman behar dituzte behean erakusten den moduan.
{
"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"
]
}Modulu-mailako mapea JSON sinple bat da, zeinaren gakoak kode irekiko biltegiko xede-moduluak dira eta balioak LinkedIn biltegietako iturburu-moduluen zerrenda dira. Iturburu irekiko biltegiko edozein helburu-modulu iturburu-moduluren bidez elikatu daiteke. Iturburu-moduluetan biltegien barne-izenak adierazteko, erabili Bash estiloan. Modulu-mailako mapa-fitxategi bat erabiliz, tresnek fitxategi-mailako mapa-fitxategi bat sortzen dute, erlazionatutako direktorioetako fitxategi guztiak eskaneatuz.
{
"${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,
}Fitxategi-mailako mapak automatikoki sortzen ditu tresnek; hala ere, eskuz ere egunera dezake erabiltzaileak. Hau LinkedIn iturburu-fitxategi baten 1:1-ko mapaketa da kode irekiko biltegiko fitxategi batekin. Fitxategi-elkarteen sorkuntza automatiko honekin lotutako hainbat arau daude:
- Kode irekiko xede-modulu baterako hainbat iturburu-moduluren kasuan, gatazkak sor daitezke, adibidez, berdinak. , iturri-modulu batean baino gehiagotan dagoena. Gatazkak konpontzeko estrategia gisa, gure tresnek "azkenak irabazten du" aukera lehenetsi dute.
- "null" esan nahi du iturburu-fitxategia ez dela kode irekiko biltegiaren parte.
- Kode irekiko bidalketa edo erauzketa bakoitzaren ondoren, mapa hau automatikoki eguneratzen da eta argazki bat sortzen da. Beharrezkoa da iturburu-kodetik egindako gehiketak eta ezabaketak identifikatzeko azken ekintzatik.
Konpromisoen erregistroak sortzea
Kode irekiko konpromisoen erregistroak ere automatikoki sortzen dira barne biltegietako konpromezuen erregistroak batuz. Jarraian, gure tresnak sortutako konpromezu erregistroaren egitura erakusteko adibide bat dago. Konpromiso batek argi adierazten du iturburu-biltegien zein bertsio dauden konpromezu horretan paketatuta eta konpromezuen erregistroaren laburpena eskaintzen du. Begiratu hau gure tresna-tresnak sortutako konpromezu erregistro baten adibide erreal bat erabiliz.
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.0Mendekotasun-probak
LinkedInek dauka , eta horrek barne-produktu anitzeko aldaketek menpeko produktu anitzekoen muntaia hautsi ez dezaten laguntzen du. Kode irekiko DataHub biltegia ez da produktu anitzekoa, eta ezin da edozein produktu anitzeko menpekotasun zuzena izan, baina DataHub iturburu-kodea eskuratzen duen produktu anitzeko bilgarri baten laguntzarekin, oraindik ere mendekotasun-proba hau erabil dezakegu. Horrela, kode irekiko DataHub biltegia elikatzen duten produktu anitzeko edozein aldaketak (geroago jasan daitekeena) shell multiproduktuan eraikitze-gertaera bat abiarazten du. Hori dela eta, bilgarri-produktu bat eraikitzen ez duen edozein aldaketak huts egiten du jatorrizko produktua konprometitu aurretik probak eta atzera egiten da.
Mekanismo erabilgarria da, kode irekiko eraikuntza apurtzen duen barne-konpromisoa saihesten laguntzen duena eta konpromisoaren unean detektatzen duena. Hori gabe, nahiko zaila izango litzateke zehaztea zein barne-konpromisek eragin duen kode irekiko biltegiaren eraikuntza huts egitea, DataHub kode irekiko biltegian barne-aldaketak biltzen ditugulako.
Kode irekiko DataHub eta gure ekoizpen bertsioaren arteko desberdintasunak
Orain arte, DataHub biltegien bi bertsio sinkronizatzeko gure soluzioa eztabaidatu dugu, baina oraindik ez dugu azaldu bi garapen-korronte ezberdin behar ditugun arrazoiak lehenik. Atal honetan, DataHub-en bertsio publikoaren eta LinkedIn zerbitzarietako ekoizpen-bertsioaren arteko desberdintasunak zerrendatuko ditugu, eta desberdintasun horien arrazoiak azalduko ditugu.
Desadostasun-iturri bat gure ekoizpen-bertsioak oraindik kode irekia ez den kodeekiko menpekotasunak dituelako dator, hala nola LinkedIn-en Offspring-en (LinkedIn-en barne-mendekotasunen injekzio-esparrua). Offspring oso erabilia da barne-kode-oinarrietan, konfigurazio dinamikoa kudeatzeko hobetsitako metodoa delako. Baina ez da kode irekia; beraz, kode irekiko alternatibak aurkitu behar genituen kode irekiko DataHub-en.
Beste arrazoi batzuk ere badaude. LinkedIn-en beharretarako metadatuen eredurako luzapenak sortzen ditugun heinean, luzapen hauek LinkedIn-en oso espezifikoak dira normalean eta baliteke beste ingurune batzuei zuzenean ez aplikatzea. Adibidez, etiketa oso zehatzak ditugu parte-hartzaileen IDetarako eta bat datozen beste metadatu mota batzuentzat. Beraz, orain luzapen hauek DataHub-en kode irekiko metadatuen eredutik kanpo utzi ditugu. Komunitatearekin harremanetan jartzen garen heinean eta haien beharrak ulertzen ditugun heinean, luzapen hauen kode irekiko bertsio arruntetan lan egingo dugu behar denean.
Kode irekiko komunitatearentzat erabiltzeko erraztasunak eta egokitzapen errazak ere inspiratu zituzten DataHub-en bi bertsioen arteko desberdintasun batzuk. Korronteen prozesatzeko azpiegituretan dauden desberdintasunak horren adibide ona dira. Gure barneko bertsioak kudeatutako korronteen prozesatzeko esparrua erabiltzen badu ere, korronteen prozesamendu integratua (autonomoa) erabiltzea aukeratu dugu kode irekiko bertsiorako, azpiegituraren beste menpekotasun bat sortzea saihesten duelako.
Desberdintasunaren beste adibide bat kode irekiko inplementazio batean GMS (Metadatu Orokorren Denda) bakarra izatea da, GMS anitz baino. GMA (Generalized Metadata Architecture) DataHub-en back-end arkitekturaren izena da, eta GMS metadatuen biltegia GMAren testuinguruan. GMA oso arkitektura malgua da, datu-konstrukzio bakoitza (adibidez, datu-multzoak, erabiltzaileak, etab.) bere metadatu-biltegira banatzeko aukera ematen duena, edo datu-eraikuntza anitz metadatu-biltegi bakarrean gordetzeko, betiere datu-egituraren mapak dituen erregistroak. GMS eguneratuta dago. Erabilera errazteko, kode irekiko DataHub-en datu-eraikuntza desberdinak gordetzen dituen GMS instantzia bakarra aukeratu dugu.
Beheko taulan bi inplementazioen arteko desberdintasunen zerrenda osoa dago.
Produktuen Ezaugarriak
LinkedIn DataHub
Kode irekiko DataHub
Onartutako datu-eraikuntzak
1) Datu multzoak 2) Erabiltzaileak 3) Metrikoak 4) ML Ezaugarriak 5) Diagramak 6) Arbelak
1) Datu multzoak 2) Erabiltzaileak
Datu-multzoetarako metadatu-iturriak onartzen dira
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Bektorea 14)
Hive Kafka RDBMS
Pub-sub
Kafka konfluentea
Korronteen tratamendua
Kudeatzen
Txertatua (autonomia)
Mendekotasun-injekzioa eta konfigurazio dinamikoa
LinkedIn Offspring
Tresneria eraikitzea
Ligradle (LinkedIn-en barneko Gradle bilgarria)
CI/CD
CRT (LinkedIn-en barneko CI/CD)
Metadatu biltegiak
Hainbat GMS banatuta: 1) Datu multzoa GMS 2) Erabiltzailearen GMS 3) Metriko GMS 4) Ezaugarri GMS 5) Diagrama/Arbel GMS
GMS bakarra: 1) Datu multzoak 2) Erabiltzaileak
Mikrozerbitzuak Docker edukiontzietan
aplikazioen hedapena eta banaketa errazten ditu . DataHub-eko zerbitzuaren zati guztiak kode irekikoak dira, besteak beste, Kafka bezalako azpiegitura osagaiak barne. , ΠΈ , bere Docker irudia du. Erabili ditugun Docker edukiontziak orkestratzeko .
2. irudia: Arkitektura DataHub *kode irekia**
DataHub-en goi-mailako arkitektura ikus dezakezu goiko irudian. Azpiegitura osagaiez gain, lau Docker edukiontzi ezberdin ditu:
datahub-gms: metadatuak biltegiratzeko zerbitzua
datahub-frontend: aplikazioa , DataHub interfazea zerbitzatzen duena.
datahub-mce-consumer: aplikazioa , metadatuen aldaketa gertaera (MCE) korrontea erabiltzen duena eta metadatuen biltegia eguneratzen duena.
datahub-mae-consumer: aplikazioa , metadatuen auditoria-gertaeren korrontea (MAE) erabiltzen duena eta bilaketa-indize eta datu-base grafiko bat sortzen du.
Kode irekiko biltegiko dokumentazioa eta hainbat zerbitzuren funtzioei buruzko informazio zehatzagoa edukitzea.
DataHub-eko CI/CD kode irekia da
Kode irekiko DataHub biltegia erabiltzen du etengabeko integraziorako eta etengabe hedatzeko. Biek GitHub integrazio ona dute eta erraz konfiguratzen dira. Komunitateak edo enpresa pribatuek garatutako kode irekiko azpiegitura gehienetarako (adibidez. ), Docker irudiak Docker Hub-era sortu eta zabaltzen dira komunitateak errazteko. Docker Hub-en aurkitutako edozein Docker irudi erraz erabil daiteke komando sinple batekin .
DataHub kode irekiko biltegian konpromiso bakoitzarekin, Dockerren irudi guztiak automatikoki eraikitzen eta zabaltzen dira Docker Hub-era "azken" etiketarekin. Docker Hub batzuekin konfiguratuta badago , kode irekiko biltegiko etiketa guztiak Docker Hub-en dagozkien etiketa-izenekin ere kaleratzen dira.
DataHub erabiliz
oso erraza da eta hiru urrats erraz ditu:
- Klonatu kode irekiko biltegia eta exekutatu Docker-eko edukiontzi guztiak docker-compose-rekin emandako docker-compose script-a azkar hasteko.
- Deskargatu biltegian emandako lagin-datuak ere eskaintzen den komando lerroko tresna erabiliz.
- Arakatu DataHub zure arakatzailean.
Jarraipen aktiboa galdera azkarretarako ere konfiguratuta. Erabiltzaileek zuzenean arazoak sor ditzakete GitHub biltegian. Garrantzitsuena, iritzi eta iradokizun guztiak ongi etorri eta eskertzen ditugu!
Etorkizunerako planak
Gaur egun, kode irekiko DataHub-erako azpiegitura edo mikrozerbitzu guztiak Docker edukiontzi gisa eraikitzen dira, eta sistema osoa erabiliz orkestratuta dago. . Ospea eta hedapena emanda , Kubernetesen oinarritutako irtenbide bat ere eman nahiko genuke etorkizun hurbilean.
Era berean, DataHub hodeiko zerbitzu publiko batean hedatzeko giltza eskuan irtenbide bat eskaintzeko asmoa dugu , edo . LinkedIn-en Azurera migratzeko azken iragarpena ikusita, metadatuen taldearen barneko lehentasunekin bat egingo da.
Azkenik, eskerrak DataHub-en kode irekiko komunitateko lehen erabiltzaile guztiei, DataHub alfa baloratu eta arazoak identifikatzen eta dokumentazioa hobetzen lagundu diguten guztiei.
Iturria: www.habr.com