Open Source DataHub: Lýsigagnaleit og uppgötvunarvettvangur LinkedIn
Að finna gögnin sem þú þarft fljótt er nauðsynlegt fyrir öll fyrirtæki sem treysta á mikið magn af gögnum til að taka gagnadrifnar ákvarðanir. Þetta hefur ekki aðeins áhrif á framleiðni gagnanotenda (þar á meðal sérfræðingar, vélanámsframleiðendur, gagnafræðingar og gagnaverkfræðingar), heldur hefur það einnig bein áhrif á lokaafurðir sem eru háðar gæða vélanámi (ML) leiðslu. Að auki vekur tilhneigingin í átt að innleiðingu eða byggingu vélanámsvettvanga spurninguna: hver er aðferð þín til að uppgötva eiginleika, líkön, mælikvarða, gagnapakka o.s.frv.
Í þessari grein munum við tala um hvernig við birtum gagnagjafa undir opnu leyfi í lýsigagnaleitar- og uppgötvunarvettvangi okkar, frá fyrstu dögum verkefnisins . LinkedIn heldur eigin útgáfu af DataHub aðskilið frá opna útgáfunni. Við byrjum á því að útskýra hvers vegna við þurfum tvö aðskilin þróunarumhverfi, ræðum síðan fyrstu aðferðir við að nota opinn uppspretta WhereHows og berum saman innri (framleiðslu) útgáfuna okkar af DataHub við útgáfuna á . Við munum einnig deila upplýsingum um nýju sjálfvirku lausnina okkar til að ýta og taka á móti opnum uppfærslum til að halda báðum geymslum samstilltum. Að lokum munum við veita leiðbeiningar um hvernig á að byrja að nota opinn uppspretta DataHub og fjalla stuttlega um arkitektúr hans.
WhereHows er nú DataHub!
Lýsigagnateymi LinkedIn áður kynnt (arftaki WhereHows), leitar- og lýsigagnauppgötvunarvettvangur LinkedIn og sameiginlegar áætlanir um að opna hann. Stuttu eftir þessa tilkynningu gáfum við út alfa útgáfu af DataHub og deildum henni með samfélaginu. Síðan þá höfum við stöðugt lagt okkar af mörkum til geymslunnar og unnið með áhugasömum notendum til að bæta við þeim eiginleikum sem mest er beðið um og leysa vandamál. Það gleður okkur nú að tilkynna opinbera útgáfuna .
Open Source nálgun
WhereHows, upprunalega vefgátt LinkedIn til að finna gögn og hvaðan þau koma, byrjaði sem innra verkefni; lýsigagnateymið opnaði það . Síðan þá hefur teymið alltaf viðhaldið tveimur mismunandi kóðagrunnum - einn fyrir opinn uppspretta og einn fyrir innri notkun LinkedIn - þar sem ekki allir vörueiginleikar sem þróaðir voru fyrir LinkedIn notkunartilvik áttu almennt við um breiðari markhópinn. Að auki, WhereHows hefur nokkrar innri ósjálfstæði (innviði, bókasöfn, osfrv.) sem eru ekki opinn uppspretta. Á árunum sem fylgdu fór WhereHows í gegnum margar endurtekningar og þróunarlotur, sem gerði það að verkum að það var stór áskorun að halda kóðagrunnunum tveimur í samstillingu. Lýsigagnateymið hefur reynt mismunandi aðferðir í gegnum árin til að reyna að halda innri og opnum uppspretta þróun í takt.
Fyrsta tilraun: "Opinn uppspretta fyrst"
Við fylgdum upphaflega „opinn uppspretta fyrst“ þróunarlíkan, þar sem mest þróun á sér stað í opinni uppspretta geymslu og breytingar eru gerðar fyrir innri uppsetningu. Vandamálið við þessa nálgun er að kóðanum er alltaf ýtt til GitHub fyrst áður en hann hefur verið endurskoðaður að fullu innbyrðis. Við munum ekki finna nein framleiðsluvandamál þar til breytingar eru gerðar úr opna geymslunni og ný innri uppsetning er gerð. Ef um var að ræða lélega dreifingu var einnig mjög erfitt að ákvarða sökudólginn vegna þess að breytingar voru gerðar í lotum.
Að auki minnkaði þetta líkan framleiðni liðsins við þróun nýrra eiginleika sem kröfðust skjótra endurtekningar, þar sem það neyddi allar breytingar til að vera fyrst ýttar inn í opna uppspretta geymslu og síðan ýtt í innri geymslu. Til að draga úr vinnslutíma var hægt að gera nauðsynlega lagfæringu eða breytingu í innri geymslunni fyrst, en þetta varð mikið vandamál þegar kom að því að sameina þessar breytingar aftur í opna geymsluna vegna þess að geymslurnar tvær voru ekki samstilltar.
Þetta líkan er miklu auðveldara í framkvæmd fyrir sameiginlega vettvanga, bókasöfn eða innviðaverkefni en fyrir sérsniðin vefforrit með fullri lögun. Að auki er þetta líkan tilvalið fyrir verkefni sem hefja opinn hugbúnað frá fyrsta degi, en WhereHows var byggt sem algjörlega innra vefforrit. Það var virkilega erfitt að fjarlægja allar innri ósjálfstæðin alveg, þannig að við þurftum að halda innri gafflinum, en að halda innri gafflinum og þróa aðallega opinn uppspretta virkaði ekki alveg.
Önnur tilraun: „Innri fyrst“
**Sem önnur tilraun fórum við yfir í „innra fyrst“ þróunarlíkan, þar sem mest þróun á sér stað innanhúss og breytingar eru gerðar á opna kóðanum reglulega. Þó að þetta líkan henti best fyrir notkunartilvik okkar, hefur það eðlislæg vandamál. Það er valkostur að ýta öllum mismun beint í opna uppspretta geymsluna og reyna síðan að leysa samrunaátök síðar, en það er tímafrekt. Hönnuðir reyna í flestum tilfellum að gera þetta ekki í hvert skipti sem þeir skoða kóðann sinn. Þar af leiðandi verður þetta gert mun sjaldnar, í lotum, og gerir því erfiðara að leysa samrunaárekstra síðar.
Í þriðja skiptið virkaði það!
Misheppnuðu tilraunirnar tvær sem nefndar eru hér að ofan leiddu til þess að WhereHows GitHub geymslan var úrelt í langan tíma. Teymið hélt áfram að bæta eiginleika vörunnar og arkitektúr þannig að innri útgáfan af WhereHows fyrir LinkedIn varð fullkomnari en opinn uppspretta útgáfan. Það hafði meira að segja nýtt nafn - DataHub. Byggt á fyrri misheppnuðum tilraunum ákvað teymið að þróa skalanlega langtímalausn.
Fyrir öll ný opinn uppspretta verkefni ráðleggur og styður opinn uppspretta teymi LinkedIn þróunarlíkan þar sem einingar verkefnisins eru þróaðar algjörlega í opnum uppspretta. Útgáfur gripir eru settir á opinbera geymslu og síðan skráðir aftur inn í innri LinkedIn gripinn með því að nota . Að fylgja þessu þróunarlíkani er ekki aðeins gott fyrir þá sem nota opinn uppspretta, heldur leiðir það einnig af sér máta, stækkanlegri og stinga arkitektúr.
Hins vegar mun þroskað bakendaforrit eins og DataHub þurfa umtalsverðan tíma til að ná þessu ástandi. Þetta útilokar einnig möguleikann á opnum uppsprettum fullvirkri útfærslu áður en öll innri ósjálfstæði hafa verið að fullu tekin úr. Þess vegna höfum við þróað verkfæri sem hjálpa okkur að gera opinn uppspretta framlag hraðar og með mun minni sársauka. Þessi lausn gagnast bæði lýsigagnateyminu (DataHub verktaki) og opinn uppspretta samfélagið. Í eftirfarandi köflum verður fjallað um þessa nýju nálgun.
Open Source útgáfu sjálfvirkni
Nýjasta nálgun Lýsigagnateymis við opinn uppspretta DataHub er að þróa tól sem samstillir sjálfkrafa innri kóðagrunninn og opna uppspretta geymsluna. Hágæða eiginleikar þessa verkfærakassa eru:
- Samstilltu LinkedIn kóða við/frá opnum uppsprettu, svipað .
- Gerð leyfishausa, svipað og .
- Búðu til sjálfkrafa opinn uppspretta skuldbindingaskráa úr innri skuldbindingarskrám.
- Koma í veg fyrir innri breytingar sem brjóta opinn hugbúnað .
Eftirfarandi undirkaflar munu kafa ofan í ofangreindar aðgerðir sem hafa áhugaverð vandamál.
Samstilling frumkóða
Ólíkt opnum útgáfunni af DataHub, sem er ein GitHub geymsla, er LinkedIn útgáfan af DataHub sambland af mörgum geymslum (kallast innbyrðis ). DataHub viðmótið, lýsigagnalíkanasafnið, bakendaþjónusta lýsigagnavöruhússins og streymisstörf eru í aðskildum geymslum á LinkedIn. Hins vegar, til að auðvelda notendum opinn uppspretta, höfum við eina geymslu fyrir opinn uppspretta útgáfu af DataHub.
Mynd 1: Samstilling milli geymsla LinkedIn DataHub og einni geymslu DataHub opinn uppspretta
Til að styðja við sjálfvirka smíði, ýta og draga verkflæði, skapar nýja tólið okkar sjálfkrafa kortlagningu á skráarstigi sem samsvarar hverri frumskrá. Hins vegar krefst verkfærakistan upphafsstillingar og notendur verða að leggja fram einingarkortlagningu á háu stigi eins og sýnt er hér að neðan.
{
"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"
]
}Kortlagning á einingastigi er einfalt JSON þar sem lyklar eru markeiningar í opnu geymslunni og gildin eru listi yfir frumeiningar í LinkedIn geymslunum. Hægt er að mata hvaða markeiningu sem er í opinni geymslu með hvaða fjölda frumeininga sem er. Til að gefa til kynna innri heiti geymsla í frumeiningum, notaðu í Bash stíl. Með því að nota kortlagningarskrá á mátstigi búa verkfærin til kortlagningarskrá á skráarstigi með því að skanna allar skrár í tengdum möppum.
{
"${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,
}Kortlagning skráarstigs er sjálfkrafa búin til af verkfærunum; Hins vegar getur notandinn einnig uppfært það handvirkt. Þetta er 1:1 kortlagning á LinkedIn frumskrá yfir á skrá í opnu geymslunni. Það eru nokkrar reglur tengdar þessari sjálfvirku stofnun skráatenginga:
- Ef um er að ræða margar upprunaeiningar fyrir markeiningu í opnum uppsprettu geta komið upp árekstrar, t.d. , sem eru til í fleiri en einni frumeiningu. Sem aðferð til að leysa átök eru verkfæri okkar sjálfgefið „síðasti vinnur“ valmöguleikann.
- „null“ þýðir að frumskráin er ekki hluti af opnu geymslunni.
- Eftir hverja opinn uppgjöf eða útdrátt er þessi kortlagning sjálfkrafa uppfærð og mynd er búin til. Þetta er nauðsynlegt til að auðkenna viðbætur og eyðingar úr frumkóða frá síðustu aðgerð.
Að búa til skuldbindingar
Skuldbindingarskrár fyrir skuldbindingar með opnum uppruna eru einnig sjálfkrafa búnar til með því að sameina skuldbindingarskrár innri geymslu. Hér að neðan er sýnishorn af skuldbindingarskrá til að sýna uppbyggingu skuldbindingarskrárinnar sem tólið okkar býr til. Skuldbinding gefur skýrt til kynna hvaða útgáfur af frumgagnageymslunum eru pakkaðar í þeirri bindingu og gefur yfirlit yfir vígsluskrána. Skoðaðu þennan með því að nota raunverulegt dæmi um skuldbindingarskrá sem myndast af verkfærakistunni okkar.
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.0Fæðingarpróf
LinkedIn hefur , sem hjálpar til við að tryggja að breytingar á innri fjölvöru rjúfi ekki samsetningu háðra fjölafurða. Opinn uppspretta DataHub geymslan er ekki fjölframleiðsla og hún getur ekki verið bein háð nokkurri fjölvöru, en með hjálp fjölvöru umbúðir sem sækir opinn uppspretta DataHub frumkóðann, getum við samt notað þessa ósjálfstæðisprófun Þess vegna kallar allar breytingar (sem gætu komið í ljós síðar) á einhverri af fjölafurðunum sem fæða opinn uppspretta DataHub geymsluna uppbyggingaratburð í fjölframleiðslu skelinni. Þess vegna falla allar breytingar sem tekst ekki að búa til umbúðavöru í prófunum áður en upphaflega varan er framkvæmd og er afturkallað.
Þetta er gagnlegt kerfi sem hjálpar til við að koma í veg fyrir hvers kyns innri skuldbindingu sem brýtur opna uppsprettubygginguna og skynjar hana við skuldbindingartíma. Án þessa væri frekar erfitt að ákvarða hvaða innri skuldbinding olli því að uppbygging opna geymslunnar mistókst, vegna þess að við tökum innri breytingar á DataHub opna geymslunni.
Mismunur á opnum hugbúnaði DataHub og framleiðsluútgáfu okkar
Hingað til höfum við rætt lausnina okkar til að samstilla tvær útgáfur af DataHub geymslum, en við höfum enn ekki lýst ástæðum þess að við þurfum tvo mismunandi þróunarstrauma í fyrsta lagi. Í þessum hluta munum við skrá muninn á opinberu útgáfunni af DataHub og framleiðsluútgáfunni á LinkedIn netþjónum og útskýra ástæðurnar fyrir þessum mun.
Ein uppspretta misræmis stafar af þeirri staðreynd að framleiðsluútgáfan okkar er háð kóða sem er ekki enn opinn uppspretta, eins og LinkedIn's Offspring (innri dependency injection framework LinkedIn). Afkvæmi er mikið notað í innri kóðabasa vegna þess að það er ákjósanlegasta aðferðin til að stjórna kraftmikilli uppsetningu. En það er ekki opinn uppspretta; svo við þurftum að finna opinn uppspretta valkosti við opinn uppspretta DataHub.
Það eru líka aðrar ástæður. Þar sem við búum til viðbætur við lýsigagnalíkanið fyrir þarfir LinkedIn eru þessar viðbætur venjulega mjög sértækar fyrir LinkedIn og eiga ekki beint við um önnur umhverfi. Til dæmis höfum við mjög sérstakar merkimiða fyrir auðkenni þátttakenda og aðrar gerðir af samsvarandi lýsigögnum. Þannig að við höfum nú útilokað þessar viðbætur frá opnum lýsigagnalíkani DataHub. Þegar við tökum þátt í samfélaginu og skiljum þarfir þess munum við vinna að algengum opnum útgáfum af þessum viðbótum þar sem þörf er á.
Auðvelt í notkun og auðveldari aðlögun fyrir opinn uppspretta samfélagið veitti einnig innblástur til nokkurs munar á tveimur útgáfum af DataHub. Mismunur á straumvinnsluinnviðum er gott dæmi um þetta. Þrátt fyrir að innri útgáfan okkar noti stýrða straumvinnsluramma, völdum við að nota innbyggða (sjálfstæða) straumvinnslu fyrir opna útgáfuna vegna þess að það forðast að búa til aðra háð innviði.
Annað dæmi um muninn er að hafa eitt GMS (Generalized Metadata Store) í opinni útfærslu frekar en mörg GMS. GMA (Generalized Metadata Architecture) er heiti bakenda arkitektúrsins fyrir DataHub og GMS er lýsigagnageymslan í samhengi við GMA. GMA er mjög sveigjanlegur arkitektúr sem gerir þér kleift að dreifa hverri gagnasmíði (t.d. gagnasöfnum, notendum o.s.frv.) í sína eigin lýsigagnageymslu, eða geyma margar gagnasmíði í einni lýsigagnageymslu svo framarlega sem skrásetningin sem inniheldur kortlagningu gagnaskipulagsins í GMS er uppfært. Til að auðvelda notkun völdum við eitt GMS tilvik sem geymir allar mismunandi gagnasmíðar í opnum uppsprettu DataHub.
Heildarlisti yfir muninn á útfærslunum tveimur er að finna í töflunni hér að neðan.
Product Features
LinkedIn DataHub
Open Source DataHub
Stuðningsuppbygging gagna
1) Gagnasett 2) Notendur 3) Mælingar 4) ML Eiginleikar 5) Myndrit 6) Mælaborð
1) Gagnasöfn 2) Notendur
Stuðlar lýsigagnaheimildir fyrir gagnasöfn
1) 2) Sófaborð 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vigur 14)
Hive Kafka RDBMS
Pub-sub
Samrennandi Kafka
Straumvinnsla
Stýrður
Innbyggt (sjálfstætt)
Dependency Injection & Dynamic Configuration
LinkedIn afkvæmi
Byggja verkfæri
Ligradle (innri Gradle umbúðir LinkedIn)
CI / CD
CRT (innri CI/CD frá LinkedIn)
og
Lýsigagnaverslanir
Dreift mörgum GMS: 1) Gagnasett GMS 2) Notenda GMS 3) Metra GMS 4) Eiginleika GMS 5) Myndrit/Mælaborð GMS
Stakur GMS fyrir: 1) Gagnasett 2) Notendur
Örþjónusta í Docker gámum
einfaldar uppsetningu og dreifingu forrita með . Sérhver hluti þjónustunnar í DataHub er opinn uppspretta, þar á meðal innviðahlutar eins og Kafka, , и , hefur sína eigin Docker mynd. Til að skipuleggja Docker gáma sem við notuðum .
Mynd 2: Arkitektúr DataHub *opinn uppspretta**
Þú getur séð háttsettan arkitektúr DataHub á myndinni hér að ofan. Fyrir utan innviðahlutana hefur það fjóra mismunandi Docker gáma:
datahub-gms: lýsigagnageymsluþjónusta
datahub-frontend: forrit , sem þjónar DataHub viðmótinu.
datahub-mce-consumer: forrit , sem notar lýsigagnabreytingarviðburðinn (MCE) strauminn og uppfærir lýsigagnageymsluna.
datahub-mae-consumer: forrit , sem notar lýsigagnaendurskoðun atburðarstraums (MAE) og býr til leitarvísitölu og línuritsgagnagrunn.
Open source geymsluskjöl og innihalda ítarlegri upplýsingar um virkni ýmissa þjónustu.
CI/CD á DataHub er opinn uppspretta
Opinn uppspretta DataHub geymslan notar fyrir stöðuga samþættingu og fyrir stöðuga dreifingu. Báðir hafa góða GitHub samþættingu og auðvelt er að setja upp. Fyrir flesta opna innviði þróað af samfélaginu eða einkafyrirtækjum (t.d. ), Docker myndir eru búnar til og sendar á Docker Hub til að auðvelda samfélagið í notkun. Auðvelt er að nota hvaða Docker mynd sem finnst í Docker Hub með einfaldri skipun .
Með hverri skuldbindingu til DataHub opna geymslunnar eru allar Docker myndir sjálfkrafa smíðaðar og settar á Docker Hub með „nýjasta“ merkinu. Ef Docker Hub er stillt með sumum , öll merki í opnu geymslunni eru einnig gefin út með samsvarandi merkiheitum í Docker Hub.
Að nota DataHub
er mjög einfalt og samanstendur af þremur einföldum skrefum:
- Klónaðu opna uppspretta geymsluna og keyrðu alla Docker gáma með docker-compose með því að nota docker-compose handritið sem fylgir með til að byrja fljótt.
- Sæktu sýnishornsgögnin sem eru til staðar í geymslunni með því að nota skipanalínutólið sem einnig er til staðar.
- Skoðaðu DataHub í vafranum þínum.
Virkt fylgst með einnig stillt fyrir skjótar spurningar. Notendur geta líka búið til mál beint í GitHub geymslunni. Mikilvægast er að við fögnum og þökkum öll viðbrögð og ábendingar!
Áætlanir fyrir framtíðina
Eins og er eru sérhver innviði eða örþjónusta fyrir opinn uppspretta DataHub byggður sem Docker gámur og allt kerfið er skipulagt með því að nota . Miðað við vinsældir og útbreidd , viljum við líka bjóða upp á Kubernetes byggða lausn í náinni framtíð.
Við ætlum einnig að bjóða upp á turnkey lausn til að dreifa DataHub á almennri skýjaþjónustu eins og , eða . Í ljósi nýlegrar tilkynningar um flutning LinkedIn til Azure mun þetta samræmast innri forgangsröðun lýsigagnateymis.
Síðast en ekki síst, þökk sé öllum fyrstu notendum DataHub í open source samfélaginu sem hafa gefið DataHub alfa einkunn og hjálpað okkur að bera kennsl á vandamál og bæta skjöl.
Heimild: www.habr.com