DataHub ya Chanzo Huria: Utafutaji wa Metadata wa LinkedIn na Jukwaa la Ugunduzi
Kupata data unayohitaji haraka ni muhimu kwa kampuni yoyote inayotegemea kiasi kikubwa cha data kufanya maamuzi yanayotokana na data. Hii haiathiri tu tija ya watumiaji wa data (ikiwa ni pamoja na wachambuzi, wasanidi programu wa kujifunza mashine, wanasayansi wa data na wahandisi wa data), lakini pia ina athari ya moja kwa moja kwa bidhaa za mwisho ambazo zinategemea bomba la ubora wa kujifunza mashine (ML). Zaidi ya hayo, mwelekeo wa kutekeleza au kujenga mifumo ya kujifunza ya mashine kwa kawaida huzua swali: ni ipi mbinu yako ya ugunduzi wa ndani wa vipengele, miundo, vipimo, seti za data n.k.
Katika makala hii tutazungumzia jinsi tulivyochapisha chanzo cha data chini ya leseni wazi katika mfumo wetu wa utafutaji na ugunduzi wa metadata, kuanzia siku za mwanzo za mradi . LinkedIn hudumisha toleo lake la DataHub kando na toleo huria. Tutaanza kwa kueleza kwa nini tunahitaji mazingira mawili tofauti ya ukuzaji, kisha tujadili mbinu za mapema za kutumia chanzo huria cha WhereHows na tulinganishe toleo letu la ndani (la uzalishaji) la DataHub na toleo lililowashwa. . Pia tutashiriki maelezo kuhusu suluhisho letu jipya la kiotomatiki la kusukuma na kupokea masasisho ya chanzo huria ili kuweka hazina zote mbili katika usawazishaji. Hatimaye, tutatoa maagizo ya jinsi ya kuanza kutumia DataHub ya chanzo huria na kujadili kwa ufupi usanifu wake.
WhereHows sasa ni DataHub!
Timu ya metadata ya LinkedIn iliwasilishwa hapo awali (mrithi wa WhereHows), jukwaa la utafutaji na ugunduzi wa metadata la LinkedIn, na mipango iliyoshirikiwa ya kulifungua. Muda mfupi baada ya tangazo hili, tulitoa toleo la alpha la DataHub na tukaishiriki na jumuiya. Tangu wakati huo, tumekuwa tukichangia kwenye hazina na kufanya kazi na watumiaji wanaovutiwa ili kuongeza vipengele vilivyoombwa zaidi na kutatua matatizo. Sasa tunayo furaha kutangaza kutolewa rasmi .
Njia za Chanzo Huria
WhereHows, tovuti ya asili ya LinkedIn ya kutafuta data na inakotoka, ilianza kama mradi wa ndani; timu ya metadata iliifungua . Tangu wakati huo, timu imedumisha misingi miwili tofauti ya msimboβmoja kwa ajili ya chanzo huria na nyingine kwa matumizi ya ndani ya LinkedInβkwani si vipengele vyote vya bidhaa vilivyoundwa kwa ajili ya matukio ya utumiaji ya LinkedIn kwa ujumla vilitumika kwa hadhira pana. Zaidi ya hayo, WhereHows ina baadhi ya tegemezi za ndani (miundombinu, maktaba, n.k.) ambazo si chanzo wazi. Katika miaka iliyofuata, WhereHows ilipitia marudio mengi na mizunguko ya ukuzaji, na kufanya kuweka misingi miwili katika kusawazisha kuwa changamoto kubwa. Timu ya metadata imejaribu mbinu tofauti kwa miaka mingi ili kujaribu kuweka maendeleo ya ndani na chanzo huria katika kusawazisha.
Jaribu kwanza: "Chanzo wazi kwanza"
Hapo awali tulifuata muundo wa ukuzaji wa "chanzo huria kwanza", ambapo usanidi mwingi hutokea katika hazina ya chanzo huria na mabadiliko hufanywa kwa ajili ya matumizi ya ndani. Shida ya mbinu hii ni kwamba msimbo huwa unasukumwa kwa GitHub kwanza kabla ya kukaguliwa kikamilifu ndani. Hadi mabadiliko yafanywe kutoka hazina ya chanzo huria na utumaji mpya wa ndani kufanywa, hatutapata matatizo yoyote ya uzalishaji. Katika kesi ya upelekaji duni, pia ilikuwa ngumu sana kubaini mhalifu kwa sababu mabadiliko yalifanywa katika vikundi.
Zaidi ya hayo, muundo huu ulipunguza tija ya timu wakati wa kuunda vipengele vipya vilivyohitaji marudio ya haraka, kwa kuwa ililazimisha mabadiliko yote kusukumwa kwanza kwenye hazina ya chanzo huria na kisha kusukumwa hadi kwenye hifadhi ya ndani. Ili kupunguza muda wa usindikaji, urekebishaji au mabadiliko yanayohitajika yanaweza kufanywa kwenye hazina ya ndani kwanza, lakini hili likawa tatizo kubwa linapokuja suala la kuunganisha mabadiliko hayo kwenye hazina ya chanzo wazi kwa sababu hazina hizo mbili hazikuwa na usawazishaji.
Muundo huu ni rahisi zaidi kutekeleza kwa majukwaa, maktaba, au miradi ya miundombinu iliyoshirikiwa kuliko kwa programu maalum za wavuti zilizoangaziwa kikamilifu. Zaidi ya hayo, mtindo huu ni bora kwa miradi inayoanza chanzo wazi kutoka siku ya kwanza, lakini WhereHows ilijengwa kama programu ya ndani kabisa ya wavuti. Ilikuwa ngumu sana kuondoa tegemezi zote za ndani, kwa hivyo tulihitaji kuweka uma wa ndani, lakini kuweka uma wa ndani na kutengeneza chanzo wazi hakufaulu kabisa.
Jaribio la pili: "Ndani kwanza"
**Kama jaribio la pili, tulihamia kwenye muundo wa ukuzaji wa "ndani ya kwanza", ambapo maendeleo mengi hutokea nyumbani na mabadiliko hufanywa kwa msimbo wa chanzo huria mara kwa mara. Ingawa mtindo huu unafaa zaidi kwa kesi yetu ya utumiaji, una shida za asili. Kusukuma moja kwa moja tofauti zote kwenye hazina ya chanzo huria na kisha kujaribu kusuluhisha mizozo baadaye ni chaguo, lakini linatumia muda. Wasanidi programu katika hali nyingi hujaribu kutofanya hivi kila wakati wanapokagua misimbo yao. Kama matokeo, hii itafanywa mara chache sana, kwa vikundi, na kwa hivyo inafanya kuwa ngumu zaidi kusuluhisha mizozo ya kuunganisha baadaye.
Mara ya tatu ilifanya kazi!
Majaribio mawili yaliyoshindwa yaliyotajwa hapo juu yalisababisha hazina ya WhereHows GitHub kubaki nje ya tarehe kwa muda mrefu. Timu iliendelea kuboresha vipengele na usanifu wa bidhaa, ili toleo la ndani la WhereHows for LinkedIn liwe la juu zaidi kuliko toleo la programu huria. Hata ilikuwa na jina jipya - DataHub. Kulingana na majaribio yaliyoshindwa hapo awali, timu iliamua kuunda suluhisho la muda mrefu.
Kwa mradi wowote mpya wa chanzo huria, timu huria ya LinkedIn inashauri na kuunga mkono modeli ya ukuzaji ambapo moduli za mradi hutengenezwa katika chanzo huria. Vizalia vya programu vilivyotolewa vinatumwa kwenye hazina ya umma na kisha kuangaliwa tena kwenye vizalia vya ndani vya LinkedIn kwa kutumia . Kufuata mtindo huu wa ukuzaji sio mzuri tu kwa wale wanaotumia chanzo wazi, lakini pia husababisha usanifu wa kawaida zaidi, unaopanuka na unaoweza kuzibika.
Hata hivyo, programu tumizi iliyokomaa kama vile DataHub itahitaji muda mwingi kufikia hali hii. Hii pia inazuia uwezekano wa kupata wazi utekelezaji unaofanya kazi kikamilifu kabla tegemezi zote za ndani hazijatolewa kikamilifu. Ndiyo maana tumeunda zana zinazotusaidia kutoa michango ya tovuti huria haraka na bila maumivu kidogo. Suluhisho hili linanufaisha timu ya metadata (Msanidi wa DataHub) na jumuiya ya chanzo huria. Sehemu zifuatazo zitajadili mbinu hii mpya.
Open Source Publishing Automation
Mbinu ya hivi punde ya timu ya Metadata kwa DataHub ya chanzo huria ni kutengeneza zana ambayo husawazisha kiotomatiki msingi wa msimbo wa ndani na hazina ya chanzo huria. Vipengele vya kiwango cha juu cha zana hii ni pamoja na:
- Sawazisha msimbo wa LinkedIn kwa/kutoka kwa chanzo huria, sawa .
- Uzalishaji wa kichwa cha leseni, sawa na .
- Tengeneza kumbukumbu za ahadi za chanzo huria kiotomatiki kutoka kwa kumbukumbu za ahadi za ndani.
- Zuia mabadiliko ya ndani ambayo yanavunja chanzo wazi .
Vifungu vifuatavyo vitaangazia vipengele vilivyotajwa hapo juu ambavyo vina matatizo ya kuvutia.
Usawazishaji wa msimbo wa chanzo
Tofauti na toleo la chanzo huria la DataHub, ambalo ni hazina moja ya GitHub, toleo la LinkedIn la DataHub ni mchanganyiko wa hazina nyingi (zinazoitwa ndani. ) Kiolesura cha DataHub, maktaba ya kielelezo cha metadata, huduma ya nyuma ya ghala la metadata, na kazi za utiririshaji ziko katika hazina tofauti kwenye LinkedIn. Hata hivyo, ili kurahisisha watumiaji programu huria, tuna hazina moja ya toleo huria la DataHub.
Kielelezo cha 1: Usawazishaji kati ya hazina LinkedIn DataHub na hifadhi moja DataHub chanzo wazi
Ili kusaidia uundaji otomatiki, kusukuma na kuvuta utendakazi, zana yetu mpya huunda kiotomatiki ramani ya kiwango cha faili inayolingana na kila faili chanzo. Hata hivyo, seti ya zana inahitaji usanidi wa awali na watumiaji lazima watoe ramani ya moduli ya kiwango cha juu kama inavyoonyeshwa hapa chini.
{
"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"
]
}Ramani ya kiwango cha moduli ni JSON rahisi ambayo funguo zake ni moduli lengwa katika hazina ya chanzo huria na thamani ni orodha ya moduli za chanzo katika hazina za LinkedIn. Moduli yoyote inayolengwa katika hazina ya chanzo huria inaweza kulishwa na idadi yoyote ya moduli chanzo. Ili kuonyesha majina ya ndani ya hazina katika moduli za chanzo, tumia kwa mtindo wa Bash. Kwa kutumia faili ya ramani ya kiwango cha moduli, zana huunda faili ya ramani ya kiwango cha faili kwa kuchanganua faili zote katika saraka zinazohusiana.
{
"${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,
}Ramani ya kiwango cha faili imeundwa kiotomatiki na zana; hata hivyo, inaweza pia kusasishwa kwa mikono na mtumiaji. Huu ni muunganisho wa 1:1 wa faili ya chanzo cha LinkedIn hadi faili iliyo katika hazina ya chanzo huria. Kuna sheria kadhaa zinazohusiana na uundaji huu wa kiotomatiki wa vyama vya faili:
- Kwa upande wa moduli nyingi za vyanzo vya moduli inayolengwa katika chanzo huria, migogoro inaweza kutokea, k.m. sawa. , iliyopo katika zaidi ya moduli moja ya chanzo. Kama mkakati wa kutatua mizozo, zana zetu ni chaguo msingi kwa chaguo la "mwisho atashinda".
- "null" inamaanisha kuwa faili ya chanzo si sehemu ya hazina ya chanzo huria.
- Baada ya kila uwasilishaji au uchimbaji wa chanzo huria, ramani hii inasasishwa kiotomatiki na muhtasari huundwa. Hii ni muhimu ili kutambua nyongeza na ufutaji kutoka kwa msimbo wa chanzo tangu hatua ya mwisho.
Kuunda kumbukumbu za ahadi
Kumbukumbu za ahadi za ahadi huria pia hutolewa kiotomatiki kwa kuunganisha kumbukumbu za ahadi za hazina za ndani. Ifuatayo ni mfano wa logi ya ahadi ili kuonyesha muundo wa logi ya ahadi iliyotolewa na zana yetu. Ahadi inaonyesha wazi ni matoleo gani ya hazina za chanzo zilizowekwa katika ahadi hiyo na hutoa muhtasari wa logi ya ahadi. Angalia hii kwa kutumia mfano halisi wa logi ya ahadi iliyotolewa na zana yetu ya zana.
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.0Mtihani wa utegemezi
LinkedIn ina , ambayo husaidia kuhakikisha kuwa mabadiliko kwenye bidhaa nyingi za ndani hayavunji mkusanyiko wa bidhaa nyingi tegemezi. Hazina ya chanzo huria ya DataHub si ya bidhaa nyingi, na haiwezi kuwa tegemezi moja kwa moja kwa bidhaa nyingi, lakini kwa usaidizi wa kanga ya bidhaa nyingi ambayo huleta msimbo wa chanzo huria wa DataHub, bado tunaweza kutumia jaribio hili la utegemezi. Kwa hivyo, mabadiliko yoyote (ambayo yanaweza kufichuliwa baadaye) kwa bidhaa nyingi zinazolisha hazina ya chanzo huria ya DataHub huanzisha tukio la muundo katika ganda la bidhaa nyingi. Kwa hivyo, mabadiliko yoyote ambayo yanashindwa kutengeneza bidhaa ya kanga hushindwa majaribio kabla ya kufanya bidhaa asilia na hurejeshwa.
Huu ni utaratibu muhimu ambao husaidia kuzuia ahadi yoyote ya ndani ambayo inavunja muundo wa chanzo wazi na kugundua kwa wakati wa kujitolea. Bila hili, itakuwa vigumu sana kubainisha ni ahadi gani ya ndani iliyosababisha uundaji wa hazina ya chanzo huria kushindwa, kwa sababu tunabanisha mabadiliko ya ndani kwenye hazina ya chanzo huria ya DataHub.
Tofauti kati ya DataHub ya chanzo huria na toleo letu la uzalishaji
Kufikia wakati huu, tumejadili suluhisho letu la kusawazisha matoleo mawili ya hazina za DataHub, lakini bado hatujaelezea sababu kwa nini tunahitaji mitiririko miwili tofauti ya ukuzaji kwanza. Katika sehemu hii, tutaorodhesha tofauti kati ya toleo la umma la DataHub na toleo la uzalishaji kwenye seva za LinkedIn, na kueleza sababu za tofauti hizi.
Chanzo kimoja cha tofauti kinatokana na ukweli kwamba toleo letu la uzalishaji lina utegemezi wa msimbo ambao bado si chanzo wazi, kama vile LinkedIn's Offspring (Mfumo wa sindano wa utegemezi wa ndani wa LinkedIn). Watoto hutumika sana katika misingi ya kanuni za ndani kwa sababu ndiyo njia inayopendekezwa ya kudhibiti usanidi unaobadilika. Lakini sio chanzo wazi; kwa hivyo tulihitaji kutafuta njia mbadala za chanzo huria kwa DataHub ya chanzo huria.
Kuna sababu zingine pia. Tunapounda viendelezi kwa muundo wa metadata kwa mahitaji ya LinkedIn, viendelezi hivi kwa kawaida ni mahususi sana kwa LinkedIn na huenda visitumike moja kwa moja kwa mazingira mengine. Kwa mfano, tuna lebo mahususi za vitambulisho vya washiriki na aina nyingine za metadata zinazolingana. Kwa hivyo, sasa tumetenga viendelezi hivi kwenye modeli ya metadata ya chanzo huria ya DataHub. Tunapojihusisha na jumuiya na kuelewa mahitaji yao, tutafanya kazi kwenye matoleo ya kawaida ya programu huria ya viendelezi hivi inapohitajika.
Urahisi wa kutumia na urekebishaji rahisi kwa jumuiya ya programu huria pia ulihimiza baadhi ya tofauti kati ya matoleo mawili ya DataHub. Tofauti katika miundombinu ya usindikaji wa mkondo ni mfano mzuri wa hii. Ingawa toleo letu la ndani linatumia mfumo unaodhibitiwa wa uchakataji wa mtiririko, tulichagua kutumia uchakataji wa mtiririko uliojengewa ndani (wa pekee) kwa toleo huria kwa sababu inaepuka kuunda utegemezi mwingine wa miundombinu.
Mfano mwingine wa tofauti ni kuwa na GMS moja (Duka la Metadata la Jumla) katika utekelezaji wa chanzo huria badala ya GMS nyingi. GMA (Usanifu wa Jumla wa Metadata) ni jina la usanifu wa nyuma wa DataHub, na GMS ni hifadhi ya metadata katika muktadha wa GMA. GMA ni usanifu unaonyumbulika sana unaokuruhusu kusambaza kila muundo wa data (k.m. seti za data, watumiaji, n.k.) kwenye hifadhi yake ya metadata, au kuhifadhi miundo mingi ya data katika hifadhi moja ya metadata mradi tu sajili iliyo na muundo wa muundo wa data ndani. GMS imesasishwa. Kwa urahisi wa matumizi, tulichagua mfano mmoja wa GMS ambao huhifadhi miundo yote tofauti ya data katika chanzo huria cha DataHub.
Orodha kamili ya tofauti kati ya utekelezaji mbili imetolewa katika jedwali hapa chini.
Bidhaa Features
LinkedIn DataHub
Fungua Chanzo DataHub
Miundo ya Data Inayotumika
1) Seti za data 2) Watumiaji 3) Vipimo 4) Vipengele vya ML 5) Chati 6) Dashibodi
1) Hifadhidata 2) Watumiaji
Vyanzo vya Metadata Vinavyotumika vya Seti za Data
1) 2) Couchbase 3) 4) 5) HDFS 6) Mzinga 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vekta 14)
Hive Kafka RDBMS
Pub-ndogo
Kafka mwenye ushawishi
Inachakata Mtiririko
Imeweza
Iliyopachikwa (inayojitegemea)
Sindano ya Kutegemea & Usanidi Inayobadilika
Kizazi cha LinkedIn
Kujenga Vifaa
Ligradle (kifuniko cha ndani cha Gradle cha LinkedIn)
CI / CD
CRT ( CI/CD ya ndani ya LinkedIn)
na
Maduka ya Metadata
Imesambazwa GMS nyingi: 1) Seti ya data ya GMS 2) Mtumiaji GMS 3) Metric GMS 4) Kipengele cha GMS 5) Chati/Dashibodi ya GMS
GMS Moja ya: 1) Hifadhidata 2) Watumiaji
Huduma ndogo katika vyombo vya Docker
hurahisisha uwekaji na usambazaji wa programu na . Kila sehemu ya huduma katika DataHub ni chanzo huria, ikijumuisha vipengele vya miundombinu kama vile Kafka, , ΠΈ , ina picha yake ya Docker. Kupanga vyombo vya Docker tulitumia .
Kielelezo 2: Usanifu DataHub *chanzo wazi**
Unaweza kuona usanifu wa kiwango cha juu wa DataHub kwenye picha iliyo hapo juu. Kando na vifaa vya miundombinu, ina vyombo vinne tofauti vya Docker:
datahub-gms: huduma ya kuhifadhi metadata
datahub-frontend: maombi , inayohudumia kiolesura cha DataHub.
datahub-mce-consumer: maombi , ambayo hutumia mtiririko wa tukio la mabadiliko ya metadata (MCE) na kusasisha hifadhi ya metadata.
datahub-mae-consumer: maombi , ambayo hutumia mkondo wa tukio la ukaguzi wa metadata (MAE) na kuunda faharasa ya utafutaji na hifadhidata ya grafu.
Nyaraka za hazina ya chanzo wazi na vyenye maelezo zaidi kuhusu kazi za huduma mbalimbali.
CI/CD kwenye DataHub ni chanzo wazi
Hifadhi ya chanzo huria ya DataHub hutumia kwa ushirikiano endelevu na kwa usambazaji endelevu. Zote zina muunganisho mzuri wa GitHub na ni rahisi kusanidi. Kwa miundombinu mingi ya chanzo huria iliyotengenezwa na jumuiya au makampuni binafsi (k.m. ), Picha za Docker huundwa na kutumwa kwa Docker Hub kwa urahisi wa matumizi na jamii. Picha yoyote ya Docker inayopatikana kwenye Docker Hub inaweza kutumika kwa urahisi na amri rahisi .
Kwa kila ahadi ya hazina ya chanzo huria ya DataHub, picha zote za Docker hujengwa kiotomatiki na kutumwa kwa Docker Hub na lebo "ya hivi punde". Ikiwa Docker Hub imeundwa na zingine , lebo zote kwenye hazina ya chanzo huria pia hutolewa na majina ya lebo yanayolingana katika Docker Hub.
Kwa kutumia DataHub
ni rahisi sana na ina hatua tatu rahisi:
- Sambaza hazina ya chanzo huria na uendeshe vyombo vyote vya Docker na docker-compose kwa kutumia hati iliyotolewa ya kutunga docker kwa kuanza haraka.
- Pakua data ya sampuli iliyotolewa kwenye hifadhi kwa kutumia zana ya mstari wa amri ambayo pia hutolewa.
- Vinjari DataHub kwenye kivinjari chako.
Imefuatiliwa kikamilifu pia imeundwa kwa maswali ya haraka. Watumiaji wanaweza pia kuunda maswala moja kwa moja kwenye hazina ya GitHub. Muhimu zaidi, tunakaribisha na kuthamini maoni na mapendekezo yote!
Mipango ya siku zijazo
Kwa sasa, kila miundombinu au huduma ndogo ya DataHub ya chanzo huria hujengwa kama chombo cha Docker, na mfumo mzima unaratibiwa kwa kutumia. . Kwa kuzingatia umaarufu na kuenea , tungependa pia kutoa suluhisho la msingi la Kubernetes katika siku za usoni.
Pia tunapanga kutoa suluhisho la turnkey kwa kupeleka DataHub kwenye huduma ya wingu ya umma kama vile , au . Kwa kuzingatia tangazo la hivi majuzi la kuhamia kwa LinkedIn hadi Azure, hii italingana na vipaumbele vya ndani vya timu ya metadata.
Mwisho kabisa, shukrani kwa watumiaji wote wa mapema wa DataHub katika jumuiya ya programu huria ambao wamekadiria DataHub alphas na kutusaidia kutambua matatizo na kuboresha uhifadhi.
Chanzo: mapenzi.com