Open Source DataHub: Milarian Metadata sareng Platform Papanggihan LinkedIn
Milarian data anu anjeun peryogikeun gancang penting pisan pikeun perusahaan naon waé anu ngandelkeun data anu ageung pikeun nyandak kaputusan anu didorong ku data. Ieu mah ngan ukur mangaruhan produktivitas pamaké data (kaasup analis, pamekar pembelajaran mesin, élmuwan data, jeung insinyur data), tapi ogé boga dampak langsung kana produk ahir nu gumantung kana kualitas mesin learning (ML) pipa. Salaku tambahan, tren pikeun nerapkeun atanapi ngawangun platform pembelajaran mesin sacara alami nyababkeun patarosan: naon metode anjeun pikeun mendakan fitur, modél, métrik, set data, jsb.
Dina tulisan ieu kami bakal ngobrol ngeunaan kumaha kami nyebarkeun sumber data dina lisénsi kabuka dina platform teang jeung pamanggihan metadata urang, mimitian ti poé mimiti proyek . LinkedIn ngajaga versi DataHub sorangan sacara misah ti versi open source. Urang bakal ngamimitian ku ngajelaskeun naha urang peryogi dua lingkungan pamekaran anu misah, teras bahas pendekatan awal pikeun ngagunakeun sumber terbuka WhereHows sareng ngabandingkeun versi internal (produksi) DataHub urang sareng versi dina. . Kami ogé bakal ngabagi detil ngeunaan solusi otomatis anyar kami pikeun ngadorong sareng nampi apdet sumber terbuka pikeun ngajaga duanana repositori singkronisasi. Tungtungna, kami bakal masihan pitunjuk ngeunaan cara ngamimitian nganggo open source DataHub sareng ngabahas sakedap arsitékturna.
WhereHows ayeuna janten DataHub!
tim metadata LinkedIn urang saméméhna dibere (paneruskeun WhereHows), teang sareng platform panemuan metadata LinkedIn, sareng rencana dibagikeun pikeun muka éta. Teu lami saatos pengumuman ieu, kami ngaluarkeun versi alfa DataHub sareng ngabagikeunana ka masarakat. Ti saprak éta, kami terus-terusan nyumbang kana gudang sareng damel sareng pangguna anu kabetot pikeun nambihan fitur anu paling dipénta sareng ngarengsekeun masalah. Kami ayeuna gumbira ngumumkeun pelepasan resmi .
Pendekatan Open Source
WhereHows, portal asli LinkedIn pikeun milarian data sareng ti mana asalna, dimimitian salaku proyék internal; tim metadata dibuka eta . Ti saprak éta, tim éta salawasna ngajaga dua basis kode anu béda-hiji pikeun open source sareng hiji pikeun panggunaan internal LinkedIn-sabab henteu sadaya fitur produk anu dikembangkeun pikeun kasus panggunaan LinkedIn umumna tiasa dianggo pikeun pamiarsa anu langkung lega. Salaku tambahan, WhereHows ngagaduhan sababaraha katergantungan internal (infrastruktur, perpustakaan, jsb) anu henteu open source. Dina taun-taun saatosna, WhereHows ngalangkungan seueur iterasi sareng siklus pangembangan, ngajantenkeun dua basis kode sinkron janten tantangan anu ageung. Tim metadata parantos nyobian pendekatan anu béda-béda salami mangtaun-taun pikeun nyobian ngajaga pangembangan internal sareng open source dina singkronisasi.
Cobaan heula: "Open source heula"
Urang mimitina nuturkeun modél pamekaran "open source munggaran", dimana kalolobaan pamekaran lumangsung dina gudang sumber terbuka sareng parobihan dilakukeun pikeun panyebaran internal. Masalah sareng pendekatan ieu nya éta kodeu sok kadorong ka GitHub heula sateuacan parantos diulas sacara internal. Dugi parobihan dilakukeun tina gudang sumber terbuka sareng panyebaran internal énggal, urang moal mendakan masalah produksi. Dina hal deployment goréng, éta ogé hésé pisan pikeun nangtukeun palaku sabab parobahan dijieun dina bets.
Salaku tambahan, modél ieu ngirangan produktivitas tim nalika ngembangkeun fitur-fitur énggal anu peryogi iterasi gancang, sabab maksa sadaya parobihan kedah didorong heula kana gudang sumber terbuka teras kadorong ka gudang internal. Pikeun ngirangan waktos pamrosésan, perbaikan atanapi parobihan anu diperyogikeun tiasa dilakukeun dina gudang internal heula, tapi ieu janten masalah anu ageung nalika ngahijikeun parobihan éta deui kana gudang open source sabab dua repositori teu sinkron.
Modél ieu langkung gampang diimplementasikeun pikeun platform, perpustakaan, atanapi proyék infrastruktur anu dibagikeun tibatan pikeun aplikasi wéb khusus anu lengkep. Salaku tambahan, modél ieu idéal pikeun proyék-proyék anu ngamimitian open source ti mimiti dinten, tapi WhereHows diwangun salaku aplikasi wéb internal lengkep. Hese pisan pikeun ngaleungitkeun sadayana katergantungan internal, janten urang kedah ngajaga garpu internal, tapi ngajaga garpu internal sareng ngembangkeun sumber terbuka biasana henteu cekap.
Usaha kadua: "Batin heula"
** Salaku usaha kadua, urang dipindahkeun ka "internal munggaran" modél ngembangkeun, dimana paling ngembangkeun lumangsung di-imah jeung parobahan dijieun kana kode open source on rutin. Sanaos modél ieu paling cocog pikeun pamakean urang, éta ngagaduhan masalah anu alami. Langsung ngadorong sadaya bédana kana gudang open source teras nyobian ngabéréskeun konflik gabungan engké mangrupikeun pilihan, tapi nyéépkeun waktos. Pamekar dina kalolobaan kasus nyobian henteu ngalakukeun ieu unggal waktos aranjeunna marios kodena. Hasilna, ieu bakal dilakukeun langkung jarang, dina bets, sahingga janten langkung hese pikeun ngabéréskeun konflik gabungan engké.
Katilu kalina gawéna!
Dua usaha anu gagal anu disebatkeun di luhur nyababkeun Repositori WhereHows GitHub tetep lami. Tim éta terus ningkatkeun fitur sareng arsitéktur produk, supados versi internal WhereHows pikeun LinkedIn janten langkung maju tibatan versi open source. Éta malah ngagaduhan nami énggal - DataHub. Dumasar usaha gagal saméméhna, tim mutuskeun pikeun ngembangkeun hiji scalable, solusi jangka panjang.
Pikeun naon waé proyék open source anyar, tim open source LinkedIn mamatahan sareng ngadukung modél pamekaran dimana modul proyék dikembangkeun sapinuhna dina open source. Artefak versioned disebarkeun ka gudang umum lajeng dipariksa deui kana artifak LinkedIn internal maké . Nuturkeun modél pamekaran ieu sanés ngan ukur saé pikeun anu nganggo open source, tapi ogé ngahasilkeun arsitektur anu langkung modular, extensible, sareng pluggable.
Nanging, aplikasi back-end anu dewasa sapertos DataHub ngabutuhkeun waktos anu ageung pikeun ngahontal kaayaan ieu. Ieu ogé ngahalangan kamungkinan open sourcing hiji palaksanaan anu tiasa dianggo sapinuhna sateuacan sadaya katergantungan internal parantos diabstraksi. Éta sababna kami parantos ngembangkeun alat anu ngabantosan urang ngadamel kontribusi open source langkung gancang sareng kalayan nyeri anu langkung sakedik. Solusi ieu nguntungkeun tim metadata (pamekar DataHub) sareng komunitas open source. Bagian di handap ieu bakal ngabahas pendekatan anyar ieu.
Open Source Publishing Automation
Pendekatan panganyarna tim Metadata kana open source DataHub nyaéta pikeun ngembangkeun alat anu otomatis nyingkronkeun basis kode internal sareng gudang open source. Fitur tingkat luhur tina toolkit ieu kalebet:
- Singkronkeun kode LinkedIn ka/tina open source, sarupa .
- Lisensi generasi lulugu, sarupa jeung .
- Ngahasilkeun log commit open source sacara otomatis tina log commit internal.
- Nyegah parobahan internal nu megatkeun open source ngawangun ku .
Subsections handap bakal delve kana fungsi disebutkeun di luhur nu boga masalah metot.
Sinkronisasi kode sumber
Beda sareng versi open source DataHub, anu mangrupikeun gudang GitHub tunggal, versi LinkedIn DataHub mangrupikeun kombinasi sababaraha repositori (disebut sacara internal. ). Antarbeungeut DataHub, perpustakaan modél metadata, jasa backend gudang metadata, sareng padamelan streaming cicing di repositori anu misah di LinkedIn. Nanging, pikeun ngagampangkeun pangguna open source, kami gaduh gudang tunggal pikeun versi open source DataHub.
Gambar 1: Sinkronisasi antara repositories LinkedIn DataHub sarta gudang tunggal DataHub open source
Pikeun ngadukung alur kerja ngawangun, nyorong, sareng narik otomatis, alat anyar kami sacara otomatis nyiptakeun pemetaan tingkat file anu cocog sareng unggal file sumber. Tapi, toolkit butuh konfigurasi awal sareng pangguna kedah nyayogikeun pemetaan modul tingkat luhur sapertos anu dipidangkeun di handap.
{
"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"
]
}Pemetaan tingkat modul mangrupikeun JSON saderhana anu koncina nyaéta modul target dina gudang open source sareng nilaina mangrupikeun daptar modul sumber dina repositori LinkedIn. Sakur modul target dina gudang sumber terbuka tiasa dipasihan ku sajumlah modul sumber. Pikeun nunjukkeun nami internal repositories dina modul sumber, paké dina gaya Bash. Nganggo file pemetaan tingkat modul, alat-alat nyiptakeun file pemetaan tingkat-file ku nyeken sadaya file dina diréktori anu aya hubunganana.
{
"${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,
}Pemetaan tingkat file otomatis dijieun ku parabot; kumaha oge, eta oge bisa diropéa sacara manual ku pamaké. Ieu mangrupikeun pemetaan 1: 1 tina file sumber LinkedIn kana file dina gudang open source. Aya sababaraha aturan anu aya hubunganana sareng nyiptakeun asosiasi file otomatis ieu:
- Dina kasus sababaraha modul sumber pikeun modul target dina open source, konflik bisa timbul, misalna sami. , aya dina leuwih ti hiji modul sumber. Salaku strategi résolusi konflik, alat kami ditunakeun kana pilihan "pamungkas meunang".
- "null" hartosna yén file sumber sanés bagian tina gudang open source.
- Sanggeus unggal kiriman open source atawa ékstraksi, pemetaan ieu otomatis diropéa sarta snapshot dijieun. Ieu diperlukeun pikeun ngaidentipikasi tambahan sarta ngahapus tina kode sumber saprak aksi panungtungan.
Nyieun commit logs
Log commit pikeun open source commits ogé otomatis dihasilkeun ku merging log commit of repositories internal. Di handap ieu conto commit log pikeun nunjukkeun struktur commit log anu dihasilkeun ku alat urang. A commit jelas nunjukkeun versi mana repositories sumber anu dibungkus dina commit éta sareng nyayogikeun kasimpulan log commit. Pariksa hiji ieu kaluar ngagunakeun conto nyata log komitmen anu dihasilkeun ku toolkit kami.
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.0Uji katergantungan
LinkedIn boga , nu mantuan mastikeun yén parobahan multiproduct internal teu megatkeun assembly of multiproducts gumantung. Repository DataHub open source sanes multi-produk, sareng teu tiasa janten katergantungan langsung tina sagala multi-produk, tapi kalayan bantosan bungkus multi-produk anu nyandak kode sumber DataHub open source, urang masih tiasa nganggo uji dependensi ieu. Ku kituna, sagala parobahan (anu engké bisa kakeunaan) kana salah sahiji multiproducts nu feed open source Repository DataHub micu acara ngawangun dina cangkang multiproduct. Ku alatan éta, sagala parobahan anu gagal ngawangun produk wrapper gagal dina tés saméméh committing produk aslina tur dibalikkeun.
Ieu mangrupikeun mékanisme mangpaat anu ngabantosan nyegah komitmen internal anu ngarecah ngawangun open source sareng ngadeteksi dina waktos komitmen. Tanpa ieu, bakal rada hese pikeun nangtukeun mana komitmen internal anu nyababkeun pangwangunan gudang open source gagal, sabab urang bets parobahan internal kana gudang open source DataHub.
Beda antara DataHub open source sareng versi produksi urang
Nepi ka titik ieu, urang geus ngabahas solusi urang pikeun nyingkronkeun dua vérsi repositori DataHub, tapi urang masih teu outlined alesan naha urang peryogi dua aliran ngembangkeun béda dina tempat munggaran. Dina bagian ieu, urang bakal daptar béda antara versi umum tina DataHub jeung versi produksi dina server LinkedIn, sarta ngajelaskeun alesan béda ieu.
Salah sahiji sumber bédana asalna tina kanyataan yén versi produksi urang gaduh katergantungan kana kode anu henteu acan open source, sapertos LinkedIn's Offspring (kerangka suntikan dependensi internal LinkedIn). Katurunan loba dipaké dina basis kode internal sabab éta métode pikaresep pikeun ngatur konfigurasi dinamis. Tapi éta henteu open source; janten urang kedah milarian alternatif open source pikeun open source DataHub.
Aya ogé alesan séjén. Nalika urang nyiptakeun ekstensi kana modél metadata pikeun kabutuhan LinkedIn, ekstensi ieu biasana khusus pisan pikeun LinkedIn sareng henteu langsung dilarapkeun ka lingkungan anu sanés. Contona, urang boga labél pisan husus pikeun ID pamilon sarta tipe séjén metadata cocog. Janten, ayeuna urang parantos ngaluarkeun ekstensi ieu tina modél metadata sumber terbuka DataHub. Nalika kami kalibet sareng komunitas sareng ngartos kabutuhanna, kami bakal ngerjakeun versi open source umum tina ekstensi ieu upami diperyogikeun.
Gampang dianggo sareng adaptasi anu langkung gampang pikeun komunitas open source ogé ngainspirasi sababaraha bédana antara dua vérsi DataHub. Bédana dina infrastruktur pamrosésan aliran mangrupikeun conto anu saé ieu. Sanajan versi internal urang ngagunakeun kerangka processing stream junun, kami milih ngagunakeun built-in (mandiri) processing stream pikeun versi open source sabab ulah nyieun kagumantungan infrastruktur sejen.
Conto sejen tina bédana nyaéta gaduh GMS tunggal (Generalized Metadata Store) dina palaksanaan open source tinimbang sababaraha GMS. GMA (Generalized Metadata Arsitéktur) nyaeta nami arsitektur back-end pikeun DataHub, sarta GMS teh toko metadata dina konteks GMA. GMA mangrupa arsitektur pisan fléksibel nu ngidinan Anjeun pikeun ngadistribusikaeun unggal ngawangun data (misalna datasets, pamaké, jsb) kana toko metadata sorangan, atawa nyimpen sababaraha constructs data dina toko metadata tunggal salami pendaptaran ngandung pemetaan struktur data dina. GMS diropéa. Pikeun ngagampangkeun panggunaan, kami milih hiji conto GMS tunggal anu nyimpen sadaya konstruksi data anu béda dina DataHub open source.
Daptar lengkep béda antara dua palaksanaan dirumuskeun dina tabel di handap ieu.
Fitur produk
LinkedIn DataHub
Open Source DataHub
Dirojong Data Constructs
1) Dataset 2) Pamaké 3) Métrik 4) Fitur ML 5) Bagan 6) Dasbor
1) Datasets 2) Pamaké
Sumber Metadata Dirojong pikeun Datasets
1) 2) Kurungan 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Véktor 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Ngolah aliran
junun
Dipasang (mandiri)
Depéndensi suntik & Konfigurasi dinamis
turunan LinkedIn
Ngawangun Tooling
Ligradle (pembungkus Gradle internal LinkedIn)
CI / CD
CRT (CI/CD internal LinkedIn)
jeung
Toko Metadata
Disebarkeun sababaraha RUPS: 1) Dataset GMS 2) User GMS 3) Métrik RUPS 4) Fitur RUPS 5) Bagan/Dasbor GMS
RUPS Tunggal pikeun: 1) Datasets 2) Pamaké
Microservices dina peti Docker
simplifies deployment aplikasi tur distribusi kalawan . Saban bagian tina jasa di DataHub mangrupikeun sumber terbuka, kalebet komponén infrastruktur sapertos Kafka, , и , boga gambar Docker sorangan. Pikeun orchestrate wadah Docker kami dipaké .
Gambar 2: Arsitéktur DataHub *open source**
Anjeun tiasa ningali arsitektur tingkat luhur DataHub dina gambar di luhur. Salian komponén infrastruktur, éta ngagaduhan opat wadah Docker anu béda:
datahub-gms: jasa neundeun metadata
datahub-frontend: aplikasi , ngalayanan panganteur DataHub.
datahub-mce-consumer: aplikasi , nu ngagunakeun aliran metadata change event (MCE) jeung ngamutahirkeun toko metadata.
datahub-mae-consumer: aplikasi , anu ngagunakeun aliran acara audit metadata (MAE) sareng nyiptakeun indéks pilarian sareng database grafik.
Dokuméntasi gudang sumber terbuka sareng ngandung inpo nu leuwih lengkep ngeunaan pungsi rupa-rupa layanan.
CI/CD on DataHub mangrupa open source
Repositori DataHub open source ngagunakeun pikeun integrasi kontinyu jeung pikeun deployment kontinyu. Duanana gaduh integrasi GitHub anu saé sareng gampang disetél. Kanggo sabagéan ageung infrastruktur open source anu dikembangkeun ku komunitas atanapi perusahaan swasta (misalna. ), Gambar Docker diciptakeun sareng disebarkeun ka Docker Hub pikeun gampang dianggo ku masarakat. Sakur gambar Docker anu aya dina Docker Hub tiasa gampang dianggo kalayan paréntah anu saderhana .
Kalayan unggal komitmen ka Repositori open source DataHub, sadaya gambar Docker otomatis diwangun sareng disebarkeun ka Docker Hub kalayan tag "panganyarna". Upami Docker Hub dikonpigurasi sareng sababaraha , kabéh tag dina gudang open source ogé dileupaskeun kalawan ngaran tag pakait dina Docker Hub.
Ngagunakeun DataHub
saderhana pisan sareng diwangun ku tilu léngkah saderhana:
- Kloning repositori open source sareng ngajalankeun sadaya wadah Docker kalayan docker-compose nganggo skrip docker-compose anu disayogikeun pikeun ngamimitian gancang.
- Unduh data sampel anu disayogikeun dina gudang nganggo alat garis paréntah anu ogé disayogikeun.
- Kotektak DataHub dina panyungsi anjeun.
Dilacak aktip ogé ngonpigurasi pikeun patarosan gancang. Pamaké ogé tiasa nyiptakeun masalah langsung dina gudang GitHub. Anu paling penting, kami ngabagéakeun sareng ngahargaan sadaya eupan balik sareng saran!
Rencana pikeun mangsa nu bakal datang
Ayeuna, unggal infrastruktur atanapi jasa mikro pikeun open source DataHub diwangun salaku wadah Docker, sareng sadayana sistem ditata nganggo . Dibikeun popularitas sareng nyebar , urang ogé hoyong nyadiakeun solusi dumasar Kubernetes dina mangsa nu bakal datang.
Kami ogé ngarencanakeun nyayogikeun solusi turnkey pikeun nyebarkeun DataHub dina layanan awan umum sapertos , atawa . Dibikeun pengumuman panganyarna ngeunaan migrasi LinkedIn ka Azure, ieu bakal saluyu sareng prioritas internal tim metadata.
Panungtungan tapi teu saeutik, hatur nuhun ka sadaya adopters awal DataHub dina komunitas open source anu geus dipeunteun DataHub alphas tur mantuan kami ngaidentipikasi masalah jeung ningkatkeun dokuméntasi.
sumber: www.habr.com