DataHub me burim të hapur: platforma për kërkimin dhe zbulimin e metadata nga LinkedIn
Kërkimi i shpejtë i të dhënave është të domosdoshëm për çdo kompani që mbështetet në një sasi të madhe të dhënash për të marrë vendime të bazuara në këto të dhëna. Kjo nuk ndikon vetëm në produktivitetin e përdoruesve të të dhënave (përfshirë analistët, zhvilluesit e mësimit automatik, specialistët e përpunimit të të dhënave dhe inxhinierët e të dhënave), por gjithashtu ka një ndikim të drejtpërdrejtë në produktet përfundimtare që varen nga një pipeline cilësor i mësimit automatik (ML). Për më tepër, tendenca për të implementuar ose krijuar platforma mësimi automatik, natyrshëm ngre pyetjen: cila është metoda juaj për zbulimin e brendshëm të veçorive, modeleve, metrikave, grupeve të të dhënave, etj.
Në këtë artikull do të flasim për mënyrën se si e publikuam burimin e të dhënave nën një licencë të hapur në platformën tonë të kërkimit dhe zbulimit të metadatave, që nga ditët e para të projektit . LinkedIn mbështet versionin e vet DataHub, veçmas nga versioni me burim të hapur. Ne do të fillojmë me shpjegimin e arsyeve pse na duhen dy ambiente të ndryshme zhvillimi, pas të cilat do të diskutojmë qasjet e para për përdorimin e WhereHows me burim të hapur dhe do të bëjmë një krahasim mes versionit tonë të brendshëm (prodhues) të DataHub dhe versionit në . Ne gjithashtu do të ndajmë detaje për zgjidhjen tonë të re automatizuar për dërgimin dhe marrjen e azhurnimeve me burim të hapur, për të sinkronizuar të dy depozitë. Së fundi, do t'i japim udhëzime se si të filloni të përdorni DataHub me burim të hapur dhe do të diskutojmë shkurtimisht arkitekturën e saj.
WhereHows tani është DataHub!
Ekipi i metadatave të LinkedIn më parë prezantoi (pasardhësi i WhereHows), platformën e kërkimit dhe zbulimit të metadatave të LinkedIn dhe ndau planet për hapjen e saj. Së shpejti pas këtij njoftimi, ne lëshuam versionin alpha të DataHub dhe e ndamë atë me komunitetin. Që atëherë, ne kemi kontribuar vazhdimisht në depo dhe kemi punuar me përdoruesit e interesuar për të shtuar karakteristikat më të kërkuara dhe për të zgjidhur problemet. Tani jemi të lumtur të njoftojmë lëshimin zyrtar të .
Qasjet me burim të hapur
WhereHows, portali origjinal i LinkedIn pĂ«r kĂ«rkimin e tĂ« dhĂ«nave dhe origjinĂ«n e tyre, u hap si njĂ« projekt i brendshĂ«m; ekipi i metadatave e publikoi . QĂ« atĂ«herĂ«, ekipi ka mbajtur gjithmonĂ« dy baza tĂ« ndryshme koduese â njĂ« pĂ«r burim tĂ« hapur dhe njĂ« tjetĂ«r pĂ«r pĂ«rdorimin e brendshĂ«m tĂ« LinkedIn, pasi jo tĂ« gjitha funksionalitetet e produktit, tĂ« zhvilluara pĂ«r rastet e pĂ«rdorimit tĂ« LinkedIn, ishin tĂ« aplikueshme pĂ«r njĂ« audiencĂ« mĂ« tĂ« gjerĂ«. PĂ«r mĂ« tepĂ«r, WhereHows ka disa varĂ«si tĂ« brendshme (infrastrukturĂ«, biblioteka etj.), kodi burimor i tĂ« cilave nuk Ă«shtĂ« i hapur. NĂ« vitet nĂ« vazhdim, WhereHows ka kaluar nĂ«pĂ«r shumĂ« iteracione dhe cikle zhvillimi, duke bĂ«rĂ« qĂ« sinkronizimi i dy bazave tĂ« kodit tĂ« ishte njĂ« sfidĂ« e madhe. Ekipi i metadatave ka pĂ«rpiquar pĂ«r vite me radhĂ« tĂ« pĂ«rdorĂ« qasje tĂ« ndryshme pĂ«r tĂ« provuar tĂ« sinkronizojĂ« zhvillimin e brendshĂ«m dhe zhvillimin e burimit tĂ« hapur.
Përpjekja e parë: "Së pari burimi i hapur"
Fillimisht, ne ndoqëm modelin e zhvillimit "së pari burimi i hapur", ku zhvillimi kryesor ndodh në depoziten me burim të hapur, dhe ndryshimet bëhen për implementimin e brendshëm. Problemi me këtë qasje është se kodi dërgohet gjithmonë fillimisht në GitHub, para se të kontrollohet plotësisht brenda. Deri sa të bëhen ndryshimet nga depozita me burim të hapur dhe të bëhet një implementim i ri i brendshëm, ne nuk do të zbulojmë asnjë problem në prodhim. Në rastin e një implementimi të keq, gjithashtu ishte shumë e vështirë të përcaktoheshin fajtorët, sepse ndryshimet bëheshin me grupe.
Për më tepër, ky model zvogëloi produktivitetin e ekipit në zhvillimin e funksionaliteteve të reja që kërkonin iteracione të shpejta, pasi detyronte të gjitha ndryshimet fillimisht të vendoseshin në depozitën me burim të hapur dhe më pas të transferoheshin në depozita të brendshme. Për të shkurtuar kohën e përpunimit, çdo korrigjim ose ndryshim mund të bëhej fillimisht në depozitën e brendshme, por kjo u bë një problem i madh kur erdhi puna për bashkimin e këtyre ndryshimeve mbrapsht në depoziten me burim të hapur, sepse dy depozitat kishin dalë nga sinkronizimi.
Ky model është shumë më i lehtë për t'u implementuar për platforma të përgjithshme, biblioteka ose projekte infrastrukturore sesa për aplikacione web përdoruesish të plota. Për më tepër, ky model është i përshtatshëm për projekte që fillojnë me kod të hapur qysh në ditën e parë, por WhereHows është krijuar si një aplikacion web tërësisht brenda kompanisë. Ishte vërtet e vështirë të abstrahoheshim plotësisht nga të gjitha varësitë brenda, kështu që na duhej të ruanim një degë të brendshme, por ruajtja e një dege të brendshme dhe zhvillimi kryesisht me kod të hapur nuk funksionoi plotësisht.
Përpjekja e dytë: "Fillimisht brenda"
** Si një përpjekje e dytë, ne kaluam në modelin e zhvillimit "fillimisht brenda", ku zhvillimi kryesor ndodh brenda kompanisë dhe ndryshimet janë bërë në kodin e hapur në një bazë të rregullt. Megjithëse ky model është më i përshtatshëm për rastin tonë të përdorimit, ai ka disa probleme. Dërgimi i drejtpërdrejtë i të gjithë ndryshimeve në depozitat e kodit të hapur dhe më pas përpjekja për të zgjidhur konfliktet e bashkimit është një opsion, por merr shumë kohë. Zhvilluesit në shumicën e rasteve përpiqen të mos e bëjnë këtë në çdo kontroll të kodit. Si rezultat, kjo do të ndodhë shumë më rrallë, në grupe, duke e përkeqësuar kështu zgjidhjen e pasme të konflikteve të bashkimit.
Përsëri e arritëm këtë herë!
Dy pĂ«rpjekjet e pĂ«rmendura mĂ« lart çuan nĂ« faktin se depozita WhereHows nĂ« GitHub mbeti me vonesĂ« pĂ«r njĂ« periudhĂ« tĂ« gjatĂ«. Ekipi vazhdoi tĂ« pĂ«rmirĂ«sojĂ« karakteristikat dhe arkitekturĂ«n e produktit, kĂ«shtu qĂ« versioni i brendshĂ«m i WhereHows pĂ«r LinkedIn po bĂ«hej gjithnjĂ« e mĂ« i avancuar se versioni me kod tĂ« hapur. Ai madje kishte njĂ« emĂ«r tĂ« ri â DataHub. Duke u bazuar nĂ« pĂ«rpjekjet e mĂ«parshme qĂ« kishin dĂ«shtuar, ekipi vendosi tĂ« zhvillonte njĂ« zgjidhje afatgjatĂ« qĂ« ishte e gjithanshme.
Për çdo projekt të ri me kod të hapur, ekipi i zhvilluesve të kodit të hapur në LinkedIn konsulton dhe mbështet modelin e zhvillimit, ku modulet e projektit zhvillohen krejtësisht me kod të hapur. Artifaktet me version të mbështetur publikohen në një depo publik, dhe pastaj kthehen në artifaktin e brendshëm të LinkedIn me anë të . Ndjekja e këtij modeli zhvillimi jo vetëm që është e mirë për ata që përdorin kod të hapur, por gjithashtu çon në krijimin e një arkitekture më modulare, të zgjerueshme dhe të lidhshme.
Megjithatë, për të arritur këtë gjendje për një aplikacion të brendshëm të pjekur si DataHub, do të jetë e nevojshme një sasi e konsiderueshme kohe. Kjo gjithashtu përjashton mundësinë e kodit të hapur një implementimi funksional derisa të gjitha varësitë e brendshme të jenë plotësisht të abstrahuara. Prandaj, ne zhvilluam mjete që na ndihmojnë të kontribuojmë me kod të hapur më shpejt dhe më pak me dhimbje. Kjo zgjidhje është e dobishme si për ekipin e metadata (zhvilluesin e DataHub), ashtu dhe për komunitetin e kodit të hapur. Seksionet në vijim do të diskutojnë këtë qasje të re.
Automatizimi i publikimit të kodit të hapur
Qasja më e fundit e grupit të metadata për DataHub me kod të hapur merr formën e krijimit të një instrumenti që sinjalizon automatikisht bazën e kodit të brendshëm dhe depozitën e kodit të hapur. Karakterisat e nivelit të lartë të këtij instrumenti përfshijnë:
- Sinkronizimin e kodit të LinkedIn me / nga kodi i hapur, në mënyrë të ngjashme me .
- Krijimin e titullit të licencës, e ngjashme me .
- Krijimin automatik të regjistrave të ndryshimeve të kodit të hapur nga regjistrat e ndryshimeve të brendshme.
- Parandalimin e ndryshimeve të brendshme që dëmtojnë ndërtimin e kodit të hapur duke .
Në seksionet e ardhshme do të shqyrtohen në detaje karakteristikat e përmendura më sipër, të cilat kanë probleme interesante.
Sinkronizimi i kodit burimor
Në dallim nga versioni i DataHub me kod të hapur, i cili është një depo e vetme në GitHub, versioni i DataHub për LinkedIn është një kombinim i disa depozitave (të quajtura brenda kompanisë ). Ndërfaqja e DataHub, biblioteka e modeleve të metadata, shërbimi i serverëve për ruajtjen e metadata dhe punët streaming janë në depo të ndryshme në LinkedIn. Megjithatë, për të lehtësuar punën e përdoruesve me kod të hapur, ne kemi një depo të vetme për versionin e DataHub me kod të hapur.
Figura 1: Sinkronizimi midis depozitave LinkedIn DataHub dhe depozita e vetme DataHub me kod të hapur
Për të mbështetur proceset automatike të ndërtimit, dërgimit dhe nxjerrjes, mjeti ynë i ri krijon automatikisht një përputhje në nivel skedari për çdo skedar burimi. Megjithatë, për mjetin kërkohet një konfigurim fillestar, dhe përdoruesit duhet të ofrojnë një vizatim në nivel të lartë të moduleve, siç tregohet më poshtë.
{
"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"
]
}PĂ«rputhja nĂ« nivel moduli Ă«shtĂ« njĂ« JSON i thjeshtĂ«, ku çelĂ«sat janĂ« module tĂ« synuara nĂ« depo me kod tĂ« hapur, dhe vlerat janĂ« lista e moduleve burimore nĂ« depozitĂ« tĂ« LinkedIn. Ădo modul i synuar nĂ« depo me kod tĂ« hapur mund tĂ« ushqehet nga njĂ« numĂ«r tĂ« pakufizuar modulash burimore. PĂ«r tĂ« treguar emrat e brendshĂ«m tĂ« depove nĂ« modulat burimore pĂ«rdoren nĂ« stilin Bash. Duke pĂ«rdorur skedarin e pĂ«rputhjes nĂ« nivel moduli, mjetet krijojnĂ« njĂ« skedar pĂ«rputhjeje nĂ« nivel skedari duke skanuar tĂ« gjithĂ« skedarĂ«t nĂ« katalogĂ«t e lidhur.
{
"${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,
}Përputhja në nivel skedari krijohet automatikisht nga mjetet; megjithatë, ajo mund të përditësohet gjithashtu manualisht nga përdoruesi. Kjo është një përputhje 1:1 e skedarit burimor të LinkedIn me një skedar në depo me kod të hapur. Ka disa rregulla të lidhura me këtë krijim automatik të përputhjes së skedarëve:
- Në rastin e disa moduleve burimore për modul të synuar në kod të hapur, mund të ndodhin konflikte, për shembull, të njëjtin , që ekziston në më shumë se një modul burimi. Si një strategji për zgjidhjen e konflikteve, mjetet tona përdorin në parazgjedhje opsionin "i fundit fiton".
- "null" do të thotë se skedari burimor nuk është pjesë e depozitës me kod të hapur.
- Pas çdo dërgimi në kod të hapur ose nxjerrjeje prej tij, kjo përputhje përditësohet automatikisht dhe krijohet një momentin e fotografisë. Kjo është e nevojshme për të identifikuar shtesat dhe fshirjet e kodit burimor pas veprimit të fundit.
Krijimi i regjistrave të komiteve
Regjistrat e komiteve për komitetet me kod të hapur gjithashtu krijohen automatikisht duke bashkuar regjistrat e komiteve të depozita të brendshme. Më poshtë është një shembull i regjistrit të komitetit, për të treguar strukturën e regjistrit të komitetit të krijuar nga mjeti ynë. Komiteti tregon qartë se cilat versione të depove burimore janë paketuar në këtë komitet dhe ofron një informacion të përmbledhur të regjistrit të komitetit. Kontrolloni këtë në një shembull të vërtetë të regjistrit të komitetit të krijuar nga mjeti ynë.
metadata-models 29.0.0 -> 30.0.0
Shtuar modelin aspekt foos
Zgjidhur problemin bar
dataset-gms 2.3.0 -> 2.3.4
Shtuar API rest.li për të shërbyer aspektin foo
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Testimi i varësive
LinkedIn ka , e cila ndihmon për të garantuar që ndryshimet në shumëprodukte të brendshme nuk e prishin ndërtimin e shumëprodukteve të varura. Depozita DataHub me kod të hapur nuk është një shumëprodukt dhe nuk mund të jetë një varësi e drejtpërdrejtë nga ndonjë shumëprodukt, por me ndihmën e një mase shumëprodukti, që nxjerr kodin burimor të DataHub-it me kod të hapur, ne ende mund të përdorim këtë sistem testimi të varësive. Kështu, çdo ndryshim (që ndoshta do të hapet më vonë) në cilin do nga shumëproduktet që ushqejnë depozita DataHub me kod të hapur, iniciaton një ngjarje ndërtimi në shumëproduktin masë. Si rezultat, çdo ndryshim që nuk lejon ndërtimin e shumëproduktit massë, nuk kalon testet para komitimit të shumëproduktit burimor dhe kthehet.
Ky është një mekanizëm i dobishëm, që ndihmon për të parandaluar çdo komitim të brendshëm që prish ndërtimin e kodit të hapur dhe e zbulon atë gjatë krijimit të komitetit. Pa këtë, do të ishte mjaft e vështirë të përcaktohej se cili komitim i brendshëm çoi në dështimin e ndërtimit të depozitës me kod të hapur, sepse ne vendosim ndryshimet e brendshme në depozinë DataHub me kod të hapur.
Dallimet midis DataHub me kod të hapur dhe versionit tonë prodhues
Deri në këtë moment kemi diskutuar zgjidhjen tonë për sinkronizimin e dy versioneve të depozitave DataHub, por deri tani nuk kemi shpjeguar arsyet përse na nevojiten dy rrjedha të ndryshme zhvillimi. Në këtë Seksion, ne do të listojmë diferencat midis versionit publik të DataHub dhe versionit prodhues në serverët LinkedIn, si dhe do të shpjegojmë arsyet për këto diferenca.
Një nga burimet e mosmarrëveshjeve buron nga fakti që versioni ynë prodhues ka varësi nga kodi me burim të mbyllur, siç është Offspring i LinkedIn (struktura e brendshme për menaxhimin e varësive të LinkedIn). Offspring përdoret gjerësisht në kodin e brendshëm, sepse është metoda e preferuar për menaxhimin e konfigurimit dinamik. Por nuk është me burim të hapur; prandaj na duhej të gjenim alternativa me burim të hapur për DataHub me burim të hapur.
Ka edhe arsye të tjera. Ndërsa krijojmë zgjerime të modelit të të dhënave të metadatas për nevojat e LinkedIn, këto zgjerime zakonisht janë shumë specifike për LinkedIn dhe nuk mund të aplikohen drejtpërdrejt në mjedise të tjera. Për shembull, ne kemi etiketa shumë specifike për identifikuesit e përdoruesve dhe lloje të tjera të metadatas të përputhjes. Pra, aktualisht kemi përjashtuar këto zgjerime nga modeli i metadatas së DataHub me burim të hapur. Ndërsa ndërveprojmë me komunitetin dhe kuptojmë nevojat e tyre, ne do të punojmë në versione të të këtyre zgjerimeve me burim të hapur, kur të jetë e nevojshme.
Thjeshtësia e përdorimit dhe adaptimi më i lehtë për komunitetin me burim të hapur gjithashtu kanë frymëzuar disa diferenca midis dy versioneve të DataHub. Diferencat në infrastrukturën e përpunimit të rrjedhës janë një shembull i mirë. Ndërsa versioni ynë i brendshëm përdor infrastrukturën e përpunimit të menaxhuar, ne vendosëm të përdorim përpunimin e integruar (standalone) për versionin me burim të hapur, pasi kjo shmang krijimin e një varësie infrastrukture të re.
Një shembull tjetër i diferencës është prania e një GMS (Sistemi i Menaxhimit të Metadatas) në implementimin me burim të hapur, në vend të disa GMS. GMA (Arkitektura e Përbashkët e Metadatas) është emri i arkitekturës së brendshme për DataHub, dhe GMS është depoja e metadatas në kontekstin e GMA. GMA është një arkitekturë shumë fleksibël, e cila ju lejon të shpërndani çdo konstrukcion të dhënash (p.sh. grupe të dhënash, përdorues, etj.) Në depo të saj të metadatas ose të ruani disa konstrukcione të dhënash në një depo metadatas derisa regjistri, që përmban hartimin e strukturës së dhënave në GMS, është përditësuar. Për thjeshtësi përdorimi ne zgjodhëm një ekzemplar të vetëm GMS, i cili ruan të gjitha konstrukcionet e ndryshme të dhënave në DataHub me burim të hapur.
Lista e plotë e diferencave midis dy implementimeve është e paraqitur në tabelën më poshtë.
Veçoritë e Produktit
LinkedIn DataHub
Open Source DataHub
Konstruksionet e Dhënave të Mbështetura
1) Grupa të dhënash 2) Përdorues 3) Metrika 4) Veçori ML 5) Grafika 6) Tabelat e kontrollit
1) Grupa të dhënash 2) Përdorues
Burimet e Metadatas të Mbështetura për Grupet e Dhënash
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
PĂ«rpunimi i Rrjedhave
Menaxhuar
I inkorporuar (standalone)
Injektimi i Varësive dhe Konfigurimi Dinamik
LinkedIn Offspring
Mjetet e Ndërtimit
Ligradle (dërrasa e brendshme e Gradle të LinkedIn)
CI/CD
CRT (CI/CD e brendshme e LinkedIn)
and
Depot e Metadatas
Shumë GMS të shpërndarë: 1) GMS i grupit të dhënash 2) GMS i përdoruesve 3) GMS i metrikave 4) GMS i veçorive 5) GMS i grafike/tabelave të kontrollit
GMS i vetëm për: 1) Grupa të dhënash 2) Përdorues
Mikroshërbime në kontejnerë Docker
lehtĂ«son shpĂ«rndarjen dhe pĂ«rhapjen e aplikacioneve pĂ«rmes Ădo pjesĂ« e shĂ«rbimit nĂ« DataHub me burim tĂ« hapur, duke pĂ«rfshirĂ« komponentĂ«t e infrastrukturĂ«s, si Kafka, , dhe , ka imazhin e saj Docker. PĂ«r orkestrimin e kontejnerĂ«ve Docker ne pĂ«rdorĂ«m .
Figura 2: Arkitektura DataHub *me burim të hapur**
Ju mund të shihni arkitekturën e nivelit të lartë të DataHub në figurën më lart. Përveç komponentëve të infrastrukturës, ai ka katër kontejnerë të ndryshëm Docker:
datahub-gms: shërbimi i depozitës së metadatas
datahub-frontend: aplikacioni , që ofron ndërfaqen e DataHub.
datahub-mce-consumer: aplikacioni , i cili përdor rrjedhën e ngjarjeve të ndryshimeve të metadatas (MCE) dhe përditëson depozitën e metadatas.
datahub-mae-consumer: aplikacioni , i cili përdor rrjedhën e ngjarjeve të auditimit të metadatas (MAE) dhe krijon një bazë të dhënash për indekset e kërkimit dhe grafit.
Dokumentacioni për depozitimin me burim të hapur dhe përmbajnë më shumë informacion në lidhje me veçoritë e shërbimeve të ndryshme.
CI / CD në DataHub me burim të hapur
Depozita DataHub me burim tĂ« hapur pĂ«rdor pĂ«r integrim tĂ« vazhdueshĂ«m dhe pĂ«r shpĂ«rndarje tĂ« vazhdueshme. TĂ« dy kanĂ« integrim tĂ« mirĂ« me GitHub dhe janĂ« tĂ« lehtĂ« pĂ«r t'u konfiguruar. PĂ«r shumicĂ«n e infrastrukturĂ«s me kod tĂ« hapur, e zhvilluar nga komuniteti ose kompani private (p.sh., ), janĂ« krijuar imazhe Docker, dhe ato shpĂ«rndahen nĂ« Docker Hub pĂ«r tĂ« lehtĂ«suar pĂ«rdorimin nga komuniteti. Ădo imazh Docker, qĂ« gjendet nĂ« Docker Hub, mund tĂ« pĂ«rdoret lehtĂ«sisht me njĂ« komandĂ« tĂ« thjeshtĂ« .
Me çdo commit në depozitën me kod të hapur DataHub, të gjitha imazhet Docker krijohen dhe shpërndahen automatikisht në Docker Hub me etiketën "latest". Nëse në Docker Hub është e konfiguruar ndonjë , të gjitha etiketat në depozitën me kod të hapur gjithashtu lëshohen me emrat përkatës të etiketave në Docker Hub.
PĂ«rdorimi i DataHub
është shumë i thjeshtë dhe përbëhet nga tre hapa të thjeshtë:
- Klononi depozitën me kod të hapur dhe nisni të gjitha kontejnerët Docker me docker-compose duke përdorur skriptin e ofruar docker-compose për një nisje të shpejtë.
- Shkarkoni mostrat e të dhënave të ofruara në depo, duke përdorur mjetin e komandës që gjithashtu ofrohet.
- Shikoni DataHub në shfletuesin tuaj.
Gjitë aktivisht është gjithashtu e konfiguruar për pyetje të shpejta. Përdoruesit gjithashtu mund të krijojnë probleme direkt në depozitën GitHub. Më e rëndësishmja, ne miratojmë dhe vlerësojmë çdo feedback dhe propozim!
Planet për të ardhmen
Aktualisht, çdo infrastrukturë ose mikroshërbim për DataHub me kod të hapur është ndërtuar si një kontejner Docker, dhe e gjithë sistemi orkestrohet me . Duke marrë parasysh popullaritetin dhe shpërndarjen e gjerë , ne gjithashtu duam të ofrojmë një zgjidhje të bazuar në Kubernetes në të ardhmen e afërt.
Ne gjithashtu planifikojmë të ofrojmë një zgjidhje gati për shpërndarjen e DataHub në një shërbim të përbashkët të cloud, si , ose . Duke marrë parasysh njoftimin e fundit mbi migrimin e LinkedIn në Azure, kjo do të përputhej me prioritetet e brendshme të grupit të të dhënave të metadatas.
Dhe e fundit, por jo më pak e rëndësishmja: falenderojmë të gjithë përdoruesit e parë të DataHub në komunitetin e kodit të hapur që e vlerësuan versionin alfa të DataHub dhe na ndihmuan të identifikojmë probleme dhe të përmirësojmë dokumentacionin.
Burimi: habr.com
