Open Source DataHub: Platform Panelusuran lan Penemuan Metadata LinkedIn
Nemokake data sing dibutuhake kanthi cepet iku penting kanggo perusahaan apa wae sing ngandelake data sing akeh kanggo nggawe keputusan sing didorong data. Iki ora mung mengaruhi produktivitas pangguna data (kalebu analis, pangembang machine learning, ilmuwan data, lan insinyur data), nanging uga duwe pengaruh langsung ing produk pungkasan sing gumantung ing pipeline machine learning (ML) sing berkualitas. Kajaba iku, tren kanggo ngleksanakake utawa mbangun platform pembelajaran mesin kanthi alami nuwuhake pitakon: apa cara sampeyan nemokake fitur, model, metrik, set data, lsp.
Ing artikel iki, kita bakal ngomong babagan carane nerbitake sumber data miturut lisensi sing mbukak ing platform panelusur lan panemuan metadata, wiwit wiwitan proyek kasebut . LinkedIn njaga versi DataHub dhewe kanthi kapisah saka versi open source. Kita bakal miwiti kanthi nerangake kenapa kita butuh rong lingkungan pangembangan sing kapisah, banjur ngrembug pendekatan awal kanggo nggunakake sumber terbuka WhereHows lan mbandhingake versi internal (produksi) DataHub karo versi ing . Kita uga bakal nuduhake rincian babagan solusi otomatis anyar kanggo meksa lan nampa nganyari sumber terbuka supaya loro repositori tetep sinkron. Pungkasan, kita bakal menehi pitunjuk babagan cara miwiti nggunakake DataHub sumber terbuka lan ngrembug babagan arsitekture.
WhereHows saiki dadi DataHub!
Tim metadata LinkedIn sadurunge ditampilake (penerus WhereHows), platform panemuan lan metadata LinkedIn, lan rencana bareng kanggo mbukak. Sakcepete sawise woro-woro iki, kita ngeculake versi alpha saka DataHub lan bareng karo masyarakat. Wiwit iku, kita terus-terusan nyumbang kanggo gudang lan nggarap pangguna sing kasengsem kanggo nambah fitur sing paling dijaluk lan ngrampungake masalah. Saiki kita seneng ngumumake rilis resmi .
Pendekatan Open Source
WhereHows, portal asli LinkedIn kanggo nemokake data lan saka ngendi asale, diwiwiti minangka proyek internal; tim metadata mbukak . Wiwit kuwi, tim kasebut tansah njaga rong basis kode sing beda - siji kanggo sumber terbuka lan siji kanggo panggunaan internal LinkedIn - amarga ora kabeh fitur produk sing dikembangake kanggo kasus panggunaan LinkedIn umume ditrapake kanggo pamirsa sing luwih akeh. Kajaba iku, WhereHows duwe sawetara dependensi internal (infrastruktur, perpustakaan, lsp) sing ora mbukak sumber. Ing taun-taun sabanjure, WhereHows ngliwati pirang-pirang siklus lan siklus pangembangan, nggawe loro basis kode kasebut sinkron dadi tantangan gedhe. Tim metadata wis nyoba pendekatan sing beda-beda sajrone pirang-pirang taun kanggo nyoba njaga pangembangan internal lan sumber terbuka kanthi sinkron.
Coba pisanan: "Open source pisanan"
Kaping pisanan, kita ngetutake model pangembangan "open source pisanan", sing paling akeh pangembangan ana ing repositori open source lan owah-owahan digawe kanggo penyebaran internal. Masalah karo pendekatan iki yaiku kode kasebut tansah di-push menyang GitHub dhisik sadurunge wis dideleng kanthi lengkap. Nganti owah-owahan digawe saka repositori open source lan penyebaran internal anyar digawe, kita ora bakal nemokake masalah produksi. Ing kasus panyebaran sing ora apik, uga angel banget kanggo nemtokake panyebabe amarga owah-owahan digawe ing batch.
Kajaba iku, model iki nyuda produktivitas tim nalika ngembangake fitur-fitur anyar sing mbutuhake iterasi kanthi cepet, amarga kabeh owah-owahan kudu di-push menyang repositori open source lan banjur di-push menyang repositori internal. Kanggo nyuda wektu pangolahan, ndandani utawa owah-owahan sing dibutuhake bisa ditindakake ing repositori internal dhisik, nanging iki dadi masalah gedhe nalika nggabungake owah-owahan kasebut bali menyang repositori open source amarga loro repositori kasebut ora sinkron.
Model iki luwih gampang dileksanakake kanggo platform, perpustakaan, utawa proyek infrastruktur sing dienggo bareng tinimbang kanggo aplikasi web khusus kanthi fitur lengkap. Kajaba iku, model iki cocog kanggo proyek sing miwiti open source wiwit dina pisanan, nanging WhereHows dibangun minangka aplikasi web internal sing lengkap. Pancen angel banget kanggo ngilangi kabeh dependensi internal, mula kita kudu njaga garpu internal, nanging njaga garpu internal lan ngembangake sumber terbuka biasane ora bisa ditindakake.
Upaya kapindho: "Batin pisanan"
** Minangka upaya kapindho, kita pindhah menyang model pangembangan "internal pisanan", ing ngendi pangembangan paling akeh dumadi ing omah lan owah-owahan ing kode open source kanthi rutin. Sanajan model iki paling cocok kanggo kasus panggunaan kita, model iki nduweni masalah sing ana. Langsung push kabeh beda menyang repositori open source lan banjur nyoba kanggo mutusake masalah nggabung konflik mengko iku pilihan, nanging akeh wektu. Umume pangembang nyoba ora nindakake iki saben-saben mriksa kode kasebut. AkibatΓ©, iki bakal rampung luwih jarang, ing batch, lan kanthi mangkono nggawe luwih angel kanggo ngrampungake konflik gabungan mengko.
Kaping telune kerjane!
Kalih upaya gagal kasebut ing ndhuwur nyebabake repositori WhereHows GitHub tetep ora ana ing wektu sing suwe. Tim kasebut terus nambah fitur lan arsitektur produk, supaya versi internal WhereHows kanggo LinkedIn dadi luwih maju tinimbang versi open source. Malah duwe jeneng anyar - DataHub. Adhedhasar upaya sing gagal sadurunge, tim mutusake kanggo ngembangake solusi jangka panjang sing bisa diukur.
Kanggo proyek open source anyar apa wae, tim open source LinkedIn menehi saran lan ndhukung model pangembangan ing ngendi modul proyek dikembangake kabeh ing open source. Artefak versi disebarake menyang gudang umum banjur dipriksa maneh menyang artefak LinkedIn internal nggunakake . Dipuntedahaken model pembangunan iki ora mung apik kanggo wong-wong sing nggunakake open source, nanging uga asil ing arsitektur luwih modular, extensible, lan pluggable.
Nanging, aplikasi back-end sing diwasa kayata DataHub bakal mbutuhake wektu sing akeh kanggo nggayuh negara kasebut. Iki uga ngalangi kemungkinan mbukak sumber implementasine kanthi lengkap sadurunge kabeh dependensi internal wis diabstraksi kanthi lengkap. Pramila kita wis ngembangake alat sing mbantu kita nggawe kontribusi open source kanthi luwih cepet lan ora lara. Solusi iki entuk manfaat kanggo tim metadata (pengembang DataHub) lan komunitas open source. Bagean ing ngisor iki bakal ngrembug pendekatan anyar iki.
Otomasi Penerbitan Open Source
Pendekatan paling anyar saka tim Metadata menyang DataHub open source yaiku ngembangake alat sing otomatis nyelarasake basis kode internal lan gudang sumber terbuka. Fitur tingkat dhuwur saka toolkit iki kalebu:
- Nyelarasake kode LinkedIn menyang/saka open source, padha .
- Lisensi generasi header, padha karo .
- Ngasilake log commit open source kanthi otomatis saka log commit internal.
- Nyegah owah-owahan internal sing break open source mbangun dening .
Bagean ing ngisor iki bakal njlentrehake fungsi kasebut ing ndhuwur sing duwe masalah sing menarik.
Sinkronisasi kode sumber
Ora kaya versi open source saka DataHub, sing minangka gudang GitHub siji, versi LinkedIn saka DataHub minangka kombinasi saka pirang-pirang repositori (disebut sacara internal). ). Antarmuka DataHub, perpustakaan model metadata, layanan backend gudang metadata, lan proyek streaming dumunung ing repositori sing kapisah ing LinkedIn. Nanging, kanggo nggampangake pangguna open source, kita duwe gudang siji kanggo versi open source saka DataHub.
Gambar 1: Sinkronisasi antarane repositori LinkedIn DataHub lan gudang siji DataHub mbukak sumber
Kanggo ndhukung alur kerja mbangun, push, lan narik otomatis, alat anyar kita kanthi otomatis nggawe pemetaan tingkat file sing cocog karo saben file sumber. Nanging, toolkit mbutuhake konfigurasi awal lan pangguna kudu nyedhiyakake pemetaan modul tingkat dhuwur kaya sing kapacak ing ngisor iki.
{
"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 minangka JSON prasaja sing kuncine minangka modul target ing repositori sumber terbuka lan nilai kasebut minangka dhaptar modul sumber ing repositori LinkedIn. Sembarang modul target ing repositori open source bisa diisi karo jumlah modul sumber. Kanggo nunjukake jeneng internal repositori ing modul sumber, gunakake ing gaya Bash. Nggunakake file pemetaan tingkat modul, alat kasebut nggawe file pemetaan tingkat file kanthi mindhai kabeh file ing direktori sing gegandhengan.
{
"${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 kanthi otomatis digawe dening alat; nanging, uga bisa dianyari kanthi manual dening pangguna. Iki minangka pemetaan 1: 1 saka file sumber LinkedIn menyang file ing gudang sumber terbuka. Ana sawetara aturan sing ana gandhengane karo nggawe asosiasi file otomatis iki:
- Ing kasus sawetara modul sumber kanggo modul target ing open source, konflik bisa uga muncul, contone, padha. , ana ing luwih saka siji modul sumber. Minangka strategi resolusi konflik, alat kita gawan kanggo pilihan "sing pungkasan menang".
- "null" tegese file sumber dudu bagean saka repositori open source.
- Sawise saben pengajuan utawa ekstraksi open source, pemetaan iki kanthi otomatis dianyari lan snapshot digawe. Iki perlu kanggo ngenali tambahan lan pambusakan saka kode sumber wiwit tumindak pungkasan.
Nggawe log komit
Log komit kanggo komit open source uga digawe kanthi otomatis kanthi nggabungake log komit repositori internal. Ing ngisor iki minangka conto log commit kanggo nuduhake struktur log commit sing digawe dening alat kita. Komit kanthi jelas nuduhake versi repositori sumber sing dikemas ing komit kasebut lan menehi ringkesan log komit. Priksa iki nggunakake conto nyata saka log commit sing digawe dening toolkit kita.
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.0Tes ketergantungan
LinkedIn wis , sing mbantu mesthekake yen owah-owahan menyang multiproduk internal ora ngrusak perakitan multiproduk sing gumantung. Repositori DataHub open source dudu multi-produk, lan ora bisa dadi ketergantungan langsung saka macem-macem produk, nanging kanthi bantuan pambungkus multi-produk sing njupuk kode sumber DataHub open source, kita isih bisa nggunakake testing dependensi iki. Mangkono, owah-owahan apa wae (sing bisa uga katon mengko) menyang macem-macem multiproduk sing nyedhiyakake repositori DataHub sumber terbuka bakal nyebabake acara mbangun ing multiproduk cangkang. Mula, owah-owahan apa wae sing gagal nggawe produk bungkus gagal tes sadurunge nindakake produk asli lan dibalekake.
Iki minangka mekanisme sing migunani sing mbantu nyegah komit internal sing ngrusak mbangun open source lan ndeteksi ing wektu komit. Tanpa iki, bakal cukup angel kanggo nemtokake komit internal sing nyebabake mbangun repositori open source gagal, amarga kita nggawe owah-owahan internal menyang repositori open source DataHub.
Bedane antarane DataHub open source lan versi produksi kita
Nganti saiki, kita wis ngrembug solusi kanggo nyinkronake rong versi repositori DataHub, nanging kita isih durung mbatesi alasan kenapa kita butuh rong aliran pangembangan sing beda. Ing bagean iki, kita bakal dhaptar beda antarane versi umum saka DataHub lan versi produksi ing server LinkedIn, lan nerangake alasan kanggo prabΓ©dan iki.
Salah sawijining sumber bedho asale saka kasunyatan manawa versi produksi kita duwe dependensi ing kode sing durung mbukak sumber, kayata LinkedIn's Offspring (kerangka kerja injeksi dependensi internal LinkedIn). Keturunan digunakake akeh ing basis kode internal amarga minangka cara sing disenengi kanggo ngatur konfigurasi dinamis. Nanging iku ora mbukak sumber; mula kita kudu golek alternatif open source kanggo DataHub open source.
Ana uga alasan liyane. Nalika kita nggawe ekstensi kanggo model metadata kanggo kabutuhan LinkedIn, ekstensi iki biasane khusus banget kanggo LinkedIn lan bisa uga ora langsung ditrapake ing lingkungan liyane. Contone, kita duwe label khusus banget kanggo ID peserta lan jinis metadata sing cocog. Dadi, saiki kita wis ngilangi ekstensi kasebut saka model metadata sumber terbuka DataHub. Nalika kita melu komunitas lan ngerti kabutuhane, kita bakal nggarap versi open source umum saka ekstensi kasebut yen perlu.
Gampang panggunaan lan adaptasi sing luwih gampang kanggo komunitas open source uga menehi inspirasi sawetara beda antarane rong versi DataHub. Beda ing infrastruktur pangolahan stream minangka conto sing apik. Sanajan versi internal kita nggunakake kerangka pangolahan stream sing dikelola, kita milih nggunakake pangolahan stream sing dibangun ing (mandiri) kanggo versi open source amarga ora nggawe ketergantungan infrastruktur liyane.
Conto liyane sing beda yaiku nduwe GMS tunggal (Generalized Metadata Store) ing implementasine open source tinimbang sawetara GMS. GMA (Arsitektur Metadata Umum) yaiku jeneng arsitektur mburi kanggo DataHub, lan GMS minangka toko metadata ing konteks GMA. GMA minangka arsitektur sing fleksibel banget sing ngidini sampeyan nyebarake saben konstruksi data (contone, dataset, pangguna, lan sapiturute) menyang toko metadata dhewe, utawa nyimpen pirang-pirang konstruksi data ing siji toko metadata yen registri ngemot pemetaan struktur data ing. GMS dianyari. Kanggo gampang digunakake, kita milih siji conto GMS sing nyimpen kabeh konstruksi data sing beda-beda ing DataHub open source.
Dhaptar lengkap beda antarane rong implementasi diwenehi ing tabel ing ngisor iki.
Fitur Product
LinkedIn DataHub
Open Source DataHub
Konstruksi Data sing Didhukung
1) Set Data 2) Pangguna 3) Metrik 4) Fitur ML 5) Bagan 6) Dasbor
1) Dataset 2) Pangguna
Sumber Metadata sing Didhukung kanggo Set Data
1) 2) Kursi 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Prastawa 12) 13) Teradata 13) Vektor 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Pangolahan Stream
ngatur
Embedded (mandiri)
Injeksi Ketergantungan & Konfigurasi Dinamis
Keturunan LinkedIn
Mbangun Tooling
Ligradle (pembungkus Gradle internal LinkedIn)
CI / CD
CRT (CI/CD internal LinkedIn)
lan
Toko Metadata
RUPS berganda terdistribusi: 1) GMS kumpulan data 2) GMS pengguna 3) GMS metrik 4) GMS Fitur 5) GMS Bagan/Dasbor
RUPS Tunggal kanggo: 1) Dataset 2) Pangguna
Microservices ing kontaner Docker
simplifies penyebaran aplikasi lan distribusi karo . Saben bagean layanan ing DataHub mbukak sumber, kalebu komponen infrastruktur kayata Kafka, , ΠΈ , duwe gambar Docker dhewe. Kanggo orchestrate kontaner Docker digunakake .
Gambar 2: Arsitektur DataHub *open source**
Sampeyan bisa ndeleng arsitektur tingkat dhuwur saka DataHub ing gambar ing ndhuwur. Kejabi komponen infrastruktur, ana papat wadah Docker sing beda:
datahub-gms: layanan panyimpenan metadata
datahub-frontend: aplikasi , nglayani antarmuka DataHub.
datahub-mce-consumer: aplikasi , sing nggunakake aliran acara pangowahan metadata (MCE) lan nganyari nyimpen metadata.
datahub-mae-consumer: aplikasi , sing nggunakake aliran acara audit metadata (MAE) lan nggawe indeks panelusuran lan database grafik.
Dokumentasi repositori sumber terbuka lan ngemot informasi sing luwih rinci babagan fungsi saka macem-macem layanan.
CI/CD ing DataHub punika open source
Repositori DataHub open source digunakake kanggo integrasi terus-terusan lan kanggo penyebaran terus. Loro-lorone duwe integrasi GitHub sing apik lan gampang diatur. Kanggo umume infrastruktur open source sing dikembangake dening komunitas utawa perusahaan swasta (contone. ), Gambar Docker digawe lan disebarake menyang Docker Hub supaya gampang digunakake dening masyarakat. Sembarang gambar Docker sing ditemokake ing Docker Hub bisa gampang digunakake kanthi prentah sing gampang .
Kanthi saben komitmen menyang repositori sumber terbuka DataHub, kabeh gambar Docker kanthi otomatis dibangun lan disebarake menyang Docker Hub kanthi tag "paling anyar". Yen Docker Hub dikonfigurasi karo sawetara , kabeh tag ing repositori open source uga dirilis kanthi jeneng tag sing cocog ing Docker Hub.
Nggunakake DataHub
banget prasaja lan kasusun saka telung langkah prasaja:
- Kloning repositori open source lan mbukak kabeh kontaner Docker kanthi docker-compose nggunakake skrip docker-compose sing kasedhiya kanggo wiwitan cepet.
- Ngundhuh data sampel sing kasedhiya ing repositori nggunakake alat baris perintah sing uga kasedhiya.
- Telusuri DataHub ing browser sampeyan.
Dilacak kanthi aktif uga diatur kanggo pitakonan cepet. Pangguna uga bisa nggawe masalah langsung ing repositori GitHub. Sing paling penting, kita nampani lan ngormati kabeh saran lan saran!
Rencana kanggo masa depan
Saiki, saben infrastruktur utawa layanan mikro kanggo open source DataHub dibangun minangka wadah Docker, lan kabeh sistem diatur kanthi nggunakake . Diwenehi popularitas lan nyebar , kita uga pengin menehi solusi adhedhasar Kubernetes ing mangsa cedhak.
Kita uga rencana nyedhiyakake solusi turnkey kanggo nyebarake DataHub ing layanan maya umum kayata , utawa . Amarga woro-woro anyar babagan migrasi LinkedIn menyang Azure, iki bakal selaras karo prioritas internal tim metadata.
Pungkasan, nanging paling ora, matur nuwun kanggo kabeh pangguna awal DataHub ing komunitas open source sing wis menehi rating Alphas DataHub lan mbantu kita ngenali masalah lan nambah dokumentasi.
Source: www.habr.com