Open Source DataHub: Metadata Search and Discovery Platform ng LinkedIn
Ang paghahanap ng data na kailangan mo nang mabilis ay mahalaga para sa anumang kumpanya na umaasa sa malaking halaga ng data upang makagawa ng mga desisyon na batay sa data. Hindi lang ito nakakaapekto sa pagiging produktibo ng mga user ng data (kabilang ang mga analyst, machine learning developer, data scientist, at data engineer), ngunit mayroon din itong direktang epekto sa mga end product na nakadepende sa isang dekalidad na machine learning (ML) pipeline. Bukod pa rito, ang trend patungo sa pagpapatupad o pagbuo ng mga platform sa pag-aaral ng machine ay natural na itinataas ang tanong: ano ang iyong pamamaraan para sa panloob na pagtuklas ng mga feature, modelo, sukatan, dataset, atbp.
Sa artikulong ito ay pag-uusapan natin kung paano namin nai-publish ang isang mapagkukunan ng data sa ilalim ng isang bukas na lisensya sa aming platform ng paghahanap at pagtuklas ng metadata, simula sa mga unang araw ng proyekto . Pinapanatili ng LinkedIn ang sarili nitong bersyon ng DataHub nang hiwalay sa open source na bersyon. Magsisimula tayo sa pagpapaliwanag kung bakit kailangan natin ng dalawang magkahiwalay na development environment, pagkatapos ay talakayin ang mga maagang diskarte sa paggamit ng open source WhereHows at ihambing ang aming panloob (produksyon) na bersyon ng DataHub sa bersyon sa . Magbabahagi din kami ng mga detalye tungkol sa aming bagong automated na solusyon para sa pagtulak at pagtanggap ng mga open source na update upang panatilihing naka-sync ang parehong mga repository. Panghuli, magbibigay kami ng mga tagubilin sa kung paano magsimula gamit ang open source na DataHub at maikling talakayin ang arkitektura nito.
Ang WhereHows ay isa na ngayong DataHub!
Nauna nang ipinakita ang metadata team ng LinkedIn (kapalit ng WhereHows), ang platform ng paghahanap at pagtuklas ng metadata ng LinkedIn, at mga nakabahaging plano para buksan ito. Di-nagtagal pagkatapos ng anunsyo na ito, naglabas kami ng alpha na bersyon ng DataHub at ibinahagi ito sa komunidad. Simula noon, patuloy kaming nag-ambag sa repository at nakipagtulungan sa mga interesadong user upang idagdag ang mga pinaka-hinihiling na feature at lutasin ang mga problema. Ikinalulugod naming ipahayag ang opisyal na pagpapalabas .
Mga Open Source Approach
WhereHows, ang orihinal na portal ng LinkedIn para sa paghahanap ng data at kung saan ito nanggaling, ay nagsimula bilang isang panloob na proyekto; binuksan ito ng metadata team . Simula noon, palaging pinapanatili ng team ang dalawang magkaibang codebaseβisa para sa open source at isa para sa panloob na paggamit ng LinkedInβdahil hindi lahat ng feature ng produkto na binuo para sa mga kaso ng paggamit ng LinkedIn ay karaniwang naaangkop sa mas malawak na audience. Bukod pa rito, ang WhereHows ay may ilang mga panloob na dependency (imprastraktura, mga aklatan, atbp.) na hindi open source. Sa mga sumunod na taon, ang WhereHows ay dumaan sa maraming mga pag-ulit at pag-unlad ng mga siklo, na ginagawang isang malaking hamon ang pagpapanatiling naka-sync sa dalawang codebase. Sinubukan ng metadata team ang iba't ibang diskarte sa paglipas ng mga taon upang subukang panatilihing naka-sync ang internal at open source development.
Unang pagsubok: "Open source muna"
Una naming sinundan ang isang "open source first" development model, kung saan ang karamihan sa development ay nangyayari sa isang open source na repository at ang mga pagbabago ay ginawa para sa internal deployment. Ang problema sa diskarteng ito ay ang code ay palaging itinutulak sa GitHub muna bago ito ganap na masuri sa loob. Hanggang sa magawa ang mga pagbabago mula sa open source na repository at isang bagong panloob na deployment ay ginawa, hindi kami makakahanap ng anumang mga isyu sa produksyon. Sa kaso ng mahinang pag-deploy, napakahirap ding matukoy ang may kasalanan dahil ang mga pagbabago ay ginawa sa mga batch.
Bukod pa rito, binawasan ng modelong ito ang pagiging produktibo ng team kapag bumubuo ng mga bagong feature na nangangailangan ng mabilis na pag-ulit, dahil pinilit nito na ang lahat ng pagbabago ay unang itulak sa isang open source na repositoryo at pagkatapos ay itinulak sa isang panloob na imbakan. Upang mabawasan ang oras ng pagpoproseso, ang kinakailangang pag-aayos o pagbabago ay maaaring gawin muna sa panloob na imbakan, ngunit ito ay naging isang malaking problema pagdating sa pagsasama-sama ng mga pagbabagong iyon pabalik sa open source na imbakan dahil ang dalawang mga imbakan ay hindi naka-sync.
Ang modelong ito ay mas madaling ipatupad para sa mga nakabahaging platform, aklatan, o mga proyektong pang-imprastraktura kaysa sa mga ganap na tampok na custom na web application. Bukod pa rito, mainam ang modelong ito para sa mga proyektong nagsisimula sa open source mula sa unang araw, ngunit ang WhereHows ay binuo bilang isang ganap na panloob na web application. Talagang mahirap na ganap na alisin ang lahat ng mga panloob na dependency, kaya kailangan naming panatilihin ang panloob na tinidor, ngunit ang pagpapanatiling panloob na tinidor at pagbuo ng karamihan sa open source ay hindi masyadong gumana.
Pangalawang pagsubok: "Una sa loob"
**Bilang pangalawang pagtatangka, lumipat kami sa isang "internal first" na modelo ng pag-develop, kung saan ang karamihan sa pag-develop ay nangyayari sa loob ng bahay at ang mga pagbabago ay ginagawa sa open source code nang regular. Bagama't ang modelong ito ay pinakaangkop para sa aming kaso ng paggamit, mayroon itong mga likas na problema. Ang direktang pagtutulak ng lahat ng pagkakaiba sa open source na repository at pagkatapos ay sinusubukang lutasin ang mga pagsasanib sa paglaon ay isang opsyon, ngunit ito ay nakakaubos ng oras. Sa karamihan ng mga kaso, sinusubukan ng mga developer na huwag gawin ito sa tuwing susuriin nila ang kanilang code. Bilang resulta, ito ay gagawin nang hindi gaanong madalas, sa mga batch, at sa gayon ay nagiging mas mahirap na lutasin ang mga pagsasalungat sa pagsasanib sa ibang pagkakataon.
Sa pangatlong beses na gumana!
Ang dalawang nabigong pagtatangka na binanggit sa itaas ay nagresulta sa WhereHows GitHub repository na hindi napapanahon sa mahabang panahon. Ang koponan ay nagpatuloy sa pagpapahusay sa mga tampok at arkitektura ng produkto, upang ang panloob na bersyon ng WhereHows para sa LinkedIn ay naging mas advanced kaysa sa open source na bersyon. Mayroon pa itong bagong pangalan - DataHub. Batay sa mga nakaraang nabigong pagtatangka, nagpasya ang koponan na bumuo ng isang nasusukat, pangmatagalang solusyon.
Para sa anumang bagong open source na proyekto, ang open source na koponan ng LinkedIn ay nagpapayo at sumusuporta sa isang modelo ng pagpapaunlad kung saan ang mga module ng proyekto ay ganap na binuo sa open source. Na-deploy ang mga versioned artifact sa isang pampublikong repository at pagkatapos ay i-check muli sa isang panloob na artifact ng LinkedIn na ginagamit . Ang pagsunod sa modelong ito ng pag-unlad ay hindi lamang mabuti para sa mga gumagamit ng open source, ngunit nagreresulta din sa isang mas modular, extensible, at pluggable na arkitektura.
Gayunpaman, ang isang mature na back-end na application tulad ng DataHub ay mangangailangan ng malaking tagal ng oras upang maabot ang estadong ito. Pinipigilan din nito ang posibilidad ng open sourcing ng isang ganap na gumaganang pagpapatupad bago ang lahat ng mga panloob na dependency ay ganap na ma-abstract. Iyon ang dahilan kung bakit nakabuo kami ng mga tool na makakatulong sa aming gumawa ng mga open source na kontribusyon nang mas mabilis at may mas kaunting sakit. Nakikinabang ang solusyong ito sa metadata team (DataHub developer) at sa open source na komunidad. Tatalakayin ng mga sumusunod na seksyon ang bagong pamamaraang ito.
Open Source Publishing Automation
Ang pinakabagong diskarte ng Metadata team sa open source na DataHub ay ang bumuo ng tool na awtomatikong nagsi-sync sa internal codebase at sa open source na repository. Ang mataas na antas ng mga tampok ng toolkit na ito ay kinabibilangan ng:
- I-sync ang LinkedIn code sa/mula sa open source, katulad .
- License header generation, katulad ng .
- Awtomatikong bumuo ng open source commit logs mula sa internal commit logs.
- Pigilan ang mga panloob na pagbabago na sumisira sa mga open source build .
Ang mga sumusunod na subsection ay susuriin ang mga nabanggit na function na may mga kawili-wiling problema.
Pag-synchronize ng source code
Hindi tulad ng open source na bersyon ng DataHub, na isang solong GitHub repository, ang LinkedIn na bersyon ng DataHub ay isang kumbinasyon ng maraming repository (tinatawag na panloob ). Ang interface ng DataHub, metadata model library, metadata warehouse backend service, at streaming na mga trabaho ay nasa magkakahiwalay na mga repositoryo sa LinkedIn. Gayunpaman, upang gawing mas madali para sa mga open source na user, mayroon kaming iisang repository para sa open source na bersyon ng DataHub.
Figure 1: Pag-synchronize sa pagitan ng mga repository LinkedIn DataHub at isang solong imbakan DataHub open source
Para suportahan ang mga automated na build, push, at pull workflow, awtomatikong gumagawa ang aming bagong tool ng file-level na mapping na naaayon sa bawat source file. Gayunpaman, ang toolkit ay nangangailangan ng paunang pagsasaayos at ang mga user ay dapat magbigay ng mataas na antas ng pagmamapa ng module tulad ng ipinapakita sa ibaba.
{
"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"
]
}Ang pagmamapa sa antas ng module ay isang simpleng JSON na ang mga susi ay ang mga target na module sa open source na repository at ang mga value ay ang listahan ng mga source module sa LinkedIn na mga repository. Ang anumang target na module sa isang open source na repository ay maaaring pakainin ng anumang bilang ng mga source module. Upang ipahiwatig ang mga panloob na pangalan ng mga repositoryo sa mga source module, gamitin sa estilo ng Bash. Gamit ang isang module-level na mapping file, ang mga tool ay gumagawa ng isang file-level na mapping file sa pamamagitan ng pag-scan sa lahat ng mga file sa nauugnay na mga direktoryo.
{
"${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,
}Ang pagmamapa sa antas ng file ay awtomatikong nilikha ng mga tool; gayunpaman, maaari rin itong manu-manong i-update ng user. Ito ay isang 1:1 na pagmamapa ng isang LinkedIn source file sa isang file sa open source na repository. Mayroong ilang mga panuntunan na nauugnay sa awtomatikong paggawa ng mga asosasyon ng file:
- Sa kaso ng maraming source module para sa target na module sa open source, maaaring magkaroon ng mga salungatan, hal. , umiiral sa higit sa isang source module. Bilang isang diskarte sa pagresolba ng salungatan, ang aming mga tool ay nagde-default sa opsyon na "huling nanalo."
- Ang ibig sabihin ng "null" ay hindi bahagi ng open source na repository ang source file.
- Pagkatapos ng bawat pagsusumite o pagkuha ng open source, awtomatikong ina-update ang pagmamapa na ito at gagawa ng snapshot. Ito ay kinakailangan upang matukoy ang mga karagdagan at pagtanggal mula sa source code mula noong huling pagkilos.
Paglikha ng mga commit log
Ang mga commit log para sa mga open source commit ay awtomatikong nabubuo sa pamamagitan ng pagsasama ng mga commit log ng mga panloob na repositoryo. Nasa ibaba ang isang sample na commit log upang ipakita ang istruktura ng commit log na nabuo ng aming tool. Ang commit ay malinaw na nagsasaad kung aling mga bersyon ng source repository ang naka-package sa commit na iyon at nagbibigay ng buod ng commit log. Suriin ang isang ito gamit ang isang tunay na halimbawa ng isang commit log na nabuo ng aming toolkit.
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.0Pagsubok sa dependency
Mayroon ang LinkedIn , na tumutulong na matiyak na ang mga pagbabago sa isang panloob na multiproduct ay hindi masira ang pagpupulong ng mga umaasang multiproduct. Ang open source DataHub repository ay hindi multi-product, at hindi ito maaaring direktang dependency ng anumang multi-product, ngunit sa tulong ng multi-product wrapper na kumukuha ng open source DataHub source code, magagamit pa rin natin ang dependency testing na ito. system. Kaya, ang anumang pagbabago (na maaaring malantad sa ibang pagkakataon) sa alinman sa mga multiproduct na nagpapakain sa open source na repositoryo ng DataHub ay nagti-trigger ng build event sa shell multiproduct. Samakatuwid, ang anumang pagbabago na nabigong bumuo ng isang produkto ng wrapper ay nabigo sa mga pagsubok bago gawin ang orihinal na produkto at ibinalik.
Ito ay isang kapaki-pakinabang na mekanismo na nakakatulong na pigilan ang anumang panloob na commit na sumisira sa open source na build at nakakakita nito sa oras ng commit. Kung wala ito, magiging mahirap matukoy kung aling internal commit ang naging sanhi ng pagbagsak ng open source repository, dahil batch namin ang mga internal na pagbabago sa DataHub open source repository.
Mga pagkakaiba sa pagitan ng open source na DataHub at ng aming bersyon ng produksyon
Hanggang sa puntong ito, tinalakay namin ang aming solusyon para sa pag-synchronize ng dalawang bersyon ng mga repositoryo ng DataHub, ngunit hindi pa rin namin binalangkas ang mga dahilan kung bakit kailangan namin ng dalawang magkaibang stream ng pag-unlad sa unang lugar. Sa seksyong ito, ililista namin ang mga pagkakaiba sa pagitan ng pampublikong bersyon ng DataHub at ang bersyon ng produksyon sa mga server ng LinkedIn, at ipaliwanag ang mga dahilan para sa mga pagkakaibang ito.
Ang isang pinagmumulan ng pagkakaiba ay nagmumula sa katotohanan na ang aming bersyon ng produksyon ay may mga dependencies sa code na hindi pa open source, gaya ng LinkedIn's Offspring (internal dependency injection framework ng LinkedIn). Ang mga offspring ay malawakang ginagamit sa mga panloob na codebase dahil ito ang ginustong paraan para sa pamamahala ng dynamic na configuration. Ngunit hindi ito open source; kaya kailangan naming maghanap ng mga alternatibong open source sa open source na DataHub.
May iba pang dahilan din. Habang gumagawa kami ng mga extension sa modelo ng metadata para sa mga pangangailangan ng LinkedIn, ang mga extension na ito ay karaniwang napakaespesipiko sa LinkedIn at maaaring hindi direktang nalalapat sa ibang mga kapaligiran. Halimbawa, mayroon kaming napakapartikular na mga label para sa mga ID ng kalahok at iba pang mga uri ng pagtutugma ng metadata. Kaya, ibinukod na namin ang mga extension na ito mula sa open source metadata model ng DataHub. Habang nakikipag-ugnayan kami sa komunidad at nauunawaan ang kanilang mga pangangailangan, gagawa kami ng mga karaniwang open source na bersyon ng mga extension na ito kung saan kinakailangan.
Ang kadalian ng paggamit at mas madaling pagbagay para sa open source na komunidad ay nagbigay inspirasyon din sa ilan sa mga pagkakaiba sa pagitan ng dalawang bersyon ng DataHub. Ang mga pagkakaiba sa imprastraktura sa pagpoproseso ng stream ay isang magandang halimbawa nito. Bagama't ang aming panloob na bersyon ay gumagamit ng pinamamahalaang balangkas sa pagpoproseso ng stream, pinili naming gumamit ng built-in (standalone) na pagpoproseso ng stream para sa open source na bersyon dahil iniiwasan nitong lumikha ng isa pang dependency sa imprastraktura.
Ang isa pang halimbawa ng pagkakaiba ay ang pagkakaroon ng isang GMS (Generalized Metadata Store) sa isang open source na pagpapatupad sa halip na maraming GMS. Ang GMA (Generalized Metadata Architecture) ay ang pangalan ng back-end na arkitektura para sa DataHub, at ang GMS ay ang metadata store sa konteksto ng GMA. Ang GMA ay isang napaka-flexible na arkitektura na nagbibigay-daan sa iyong ipamahagi ang bawat data construct (hal. mga dataset, user, atbp.) sa sarili nitong metadata store, o mag-store ng maramihang data construct sa isang solong metadata store hangga't ang registry na naglalaman ng data structure na pagmamapa sa Ang GMS ay na-update. Para sa kadalian ng paggamit, pumili kami ng isang instance ng GMS na nag-iimbak ng lahat ng iba't ibang construct ng data sa open source na DataHub.
Ang kumpletong listahan ng mga pagkakaiba sa pagitan ng dalawang pagpapatupad ay ibinigay sa talahanayan sa ibaba.
Tampok ng Produkto
LinkedIn DataHub
Open Source DataHub
Mga Suportadong Data Construct
1) Mga Dataset 2) Mga User 3) Mga Sukatan 4) Mga Feature ng ML 5) Mga Chart 6) Mga Dashboard
1) Mga Dataset 2) Mga User
Mga Sinusuportahang Pinagmumulan ng Metadata para sa Mga Dataset
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
Pagproseso ng Stream
Pinamamahalaan
Naka-embed (nag-iisa)
Dependency Injection at Dynamic na Configuration
Mga Anak ng LinkedIn
Paggawa ng Tooling
Ligradle (panloob na Gradle wrapper ng LinkedIn)
CI / CD
CRT (panloob na CI/CD ng LinkedIn)
at
Mga Tindahan ng Metadata
Naipamahagi ang maramihang GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Isang GMS para sa: 1) Mga Dataset 2) Mga User
Mga microservice sa mga lalagyan ng Docker
pinapasimple ang pag-deploy at pamamahagi ng application gamit ang . Ang bawat bahagi ng serbisyo sa DataHub ay open source, kabilang ang mga bahagi ng imprastraktura gaya ng Kafka, , ΠΈ , ay may sariling imahe ng Docker. Para i-orkestrate ang mga container ng Docker na ginamit namin .
Larawan 2: Arkitektura DataHub *open source**
Makikita mo ang mataas na antas na arkitektura ng DataHub sa larawan sa itaas. Bukod sa mga bahagi ng imprastraktura, mayroon itong apat na magkakaibang container ng Docker:
datahub-gms: serbisyo sa imbakan ng metadata
datahub-frontend: application , na naghahatid ng interface ng DataHub.
datahub-mce-consumer: application , na gumagamit ng metadata change event (MCE) stream at nag-a-update sa metadata store.
datahub-mae-consumer: application , na gumagamit ng metadata audit event stream (MAE) at gumagawa ng search index at graph database.
Open source repository documentation at naglalaman ng mas detalyadong impormasyon tungkol sa mga function ng iba't ibang serbisyo.
Ang CI/CD sa DataHub ay open source
Ginagamit ng open source na imbakan ng DataHub para sa patuloy na pagsasama at para sa tuluy-tuloy na pag-deploy. Parehong may magandang GitHub integration at madaling i-set up. Para sa karamihan ng open source na imprastraktura na binuo ng komunidad o mga pribadong kumpanya (hal. ), Ang mga imahe ng Docker ay ginawa at ini-deploy sa Docker Hub para sa kadalian ng paggamit ng komunidad. Ang anumang imahe ng Docker na makikita sa Docker Hub ay madaling magamit gamit ang isang simpleng command .
Sa bawat commit sa DataHub open source repository, lahat ng Docker images ay awtomatikong binuo at na-deploy sa Docker Hub gamit ang "pinakabagong" tag. Kung ang Docker Hub ay na-configure sa ilan , ang lahat ng mga tag sa open source na repository ay inilabas din na may kaukulang mga pangalan ng tag sa Docker Hub.
Gamit ang DataHub
ay napakasimple at binubuo ng tatlong simpleng hakbang:
- I-clone ang open source na repository at patakbuhin ang lahat ng Docker container na may docker-compose gamit ang ibinigay na docker-compose script para sa mabilis na pagsisimula.
- I-download ang sample na data na ibinigay sa repository gamit ang command line tool na ibinigay din.
- I-browse ang DataHub sa iyong browser.
Aktibong Sinusubaybayan na-configure din para sa mabilis na mga tanong. Ang mga user ay maaari ding direktang gumawa ng mga isyu sa GitHub repository. Pinakamahalaga, tinatanggap at pinahahalagahan namin ang lahat ng feedback at mungkahi!
ΠΠ»Π°Π½Ρ Π½Π° Π±ΡΠ΄ΡΡΠ΅Π΅
Sa kasalukuyan, ang bawat imprastraktura o microservice para sa open source na DataHub ay binuo bilang isang Docker container, at ang buong system ay inayos gamit ang . Dahil sa kasikatan at laganap , gusto rin naming magbigay ng Kubernetes based na solusyon sa malapit na hinaharap.
Plano rin naming magbigay ng turnkey solution para sa pag-deploy ng DataHub sa isang pampublikong serbisyo sa cloud gaya ng , o . Dahil sa kamakailang anunsyo ng paglipat ng LinkedIn sa Azure, ito ay makakaayon sa mga panloob na priyoridad ng metadata team.
Panghuli ngunit hindi bababa sa, salamat sa lahat ng mga naunang gumagamit ng DataHub sa open source na komunidad na nag-rate ng DataHub alpha at tumulong sa amin na matukoy ang mga isyu at mapabuti ang dokumentasyon.
Pinagmulan: www.habr.com