DataHub Sumber Terbuka: Platform Carian dan Penemuan Metadata LinkedIn
Mencari data yang anda perlukan dengan cepat adalah penting bagi mana-mana syarikat yang bergantung pada jumlah data yang besar untuk membuat keputusan berdasarkan data. Ini bukan sahaja memberi kesan kepada produktiviti pengguna data (termasuk penganalisis, pembangun pembelajaran mesin, saintis data dan jurutera data), tetapi ia juga mempunyai kesan langsung pada produk akhir yang bergantung pada saluran paip pembelajaran mesin (ML) yang berkualiti. Selain itu, trend ke arah melaksanakan atau membina platform pembelajaran mesin secara semula jadi menimbulkan persoalan: apakah kaedah anda untuk menemui ciri, model, metrik, set data, dsb.
Dalam artikel ini kita akan bercakap tentang cara kami menerbitkan sumber data di bawah lesen terbuka dalam platform carian dan penemuan metadata kami, bermula dari hari-hari awal projek . LinkedIn mengekalkan versi DataHubnya sendiri secara berasingan daripada versi sumber terbuka. Kami akan mulakan dengan menerangkan sebab kami memerlukan dua persekitaran pembangunan yang berasingan, kemudian membincangkan pendekatan awal untuk menggunakan sumber terbuka WhereHows dan membandingkan versi dalaman (pengeluaran) DataHub kami dengan versi pada . Kami juga akan berkongsi butiran tentang penyelesaian automatik baharu kami untuk menolak dan menerima kemas kini sumber terbuka untuk memastikan kedua-dua repositori disegerakkan. Akhir sekali, kami akan memberikan arahan tentang cara untuk mula menggunakan DataHub sumber terbuka dan membincangkan secara ringkas seni binanya.
WhereHows kini menjadi DataHub!
Pasukan metadata LinkedIn telah dibentangkan sebelum ini (pengganti WhereHows), platform carian dan penemuan metadata LinkedIn dan rancangan kongsi untuk membukanya. Tidak lama selepas pengumuman ini, kami mengeluarkan versi alfa DataHub dan berkongsinya dengan komuniti. Sejak itu, kami terus menyumbang kepada repositori dan bekerjasama dengan pengguna yang berminat untuk menambah ciri yang paling diminta dan menyelesaikan masalah. Kami kini berbesar hati untuk mengumumkan pelepasan rasmi .
Pendekatan Sumber Terbuka
WhereHows, portal asal LinkedIn untuk mencari data dan dari mana ia datang, bermula sebagai projek dalaman; pasukan metadata membukanya . Sejak itu, pasukan itu sentiasa mengekalkan dua pangkalan kod yang berbezaβsatu untuk sumber terbuka dan satu untuk kegunaan dalaman LinkedInβkerana tidak semua ciri produk yang dibangunkan untuk kes penggunaan LinkedIn biasanya digunakan untuk khalayak yang lebih luas. Selain itu, WhereHows mempunyai beberapa kebergantungan dalaman (infrastruktur, perpustakaan, dll.) yang bukan sumber terbuka. Pada tahun-tahun berikutnya, WhereHows telah melalui banyak lelaran dan kitaran pembangunan, menjadikan mengekalkan kedua-dua pangkalan kod dalam penyegerakan satu cabaran besar. Pasukan metadata telah mencuba pendekatan yang berbeza selama bertahun-tahun untuk cuba memastikan pembangunan sumber dalaman dan terbuka disegerakkan.
Cubaan pertama: "Sumber terbuka dahulu"
Kami pada mulanya mengikuti model pembangunan "sumber terbuka didahulukan", di mana kebanyakan pembangunan berlaku dalam repositori sumber terbuka dan perubahan dibuat untuk penggunaan dalaman. Masalah dengan pendekatan ini ialah kod itu sentiasa ditolak ke GitHub terlebih dahulu sebelum ia disemak sepenuhnya secara dalaman. Sehingga perubahan dibuat daripada repositori sumber terbuka dan penggunaan dalaman baharu dibuat, kami tidak akan menemui sebarang isu pengeluaran. Dalam kes penempatan yang lemah, ia juga amat sukar untuk menentukan puncanya kerana perubahan dibuat secara berkelompok.
Selain itu, model ini mengurangkan produktiviti pasukan apabila membangunkan ciri baharu yang memerlukan lelaran pantas, kerana ia memaksa semua perubahan untuk pertama kali ditolak ke dalam repositori sumber terbuka dan kemudian ditolak ke repositori dalaman. Untuk mengurangkan masa pemprosesan, pembetulan atau perubahan yang diperlukan boleh dilakukan dalam repositori dalaman terlebih dahulu, tetapi ini menjadi masalah besar apabila ia datang untuk menggabungkan semula perubahan tersebut ke dalam repositori sumber terbuka kerana kedua-dua repositori tidak segerak.
Model ini lebih mudah dilaksanakan untuk platform kongsi, perpustakaan atau projek infrastruktur berbanding aplikasi web tersuai berciri penuh. Selain itu, model ini sesuai untuk projek yang memulakan sumber terbuka dari hari pertama, tetapi WhereHows dibina sebagai aplikasi web dalaman sepenuhnya. Sungguh sukar untuk mengasingkan sepenuhnya semua kebergantungan dalaman, jadi kami perlu mengekalkan garpu dalaman, tetapi mengekalkan garpu dalaman dan membangunkan kebanyakannya sumber terbuka tidak berjaya.
Percubaan kedua: "Dalaman dahulu"
**Sebagai percubaan kedua, kami beralih kepada model pembangunan "dalaman pertama", di mana kebanyakan pembangunan berlaku secara dalaman dan perubahan dibuat pada kod sumber terbuka secara tetap. Walaupun model ini paling sesuai untuk kes penggunaan kami, ia mempunyai masalah yang wujud. Menolak terus semua perbezaan ke repositori sumber terbuka dan kemudian cuba menyelesaikan konflik gabungan kemudian adalah pilihan, tetapi ia memakan masa. Pembangun dalam kebanyakan kes cuba untuk tidak melakukan ini setiap kali mereka menyemak kod mereka. Akibatnya, ini akan dilakukan dengan lebih jarang, secara berkelompok, dan dengan itu menjadikannya lebih sukar untuk menyelesaikan konflik gabungan kemudian.
Kali ketiga ia berkesan!
Kedua-dua percubaan gagal yang dinyatakan di atas menyebabkan repositori WhereHows GitHub kekal ketinggalan zaman untuk masa yang lama. Pasukan ini terus menambah baik ciri dan seni bina produk, supaya versi dalaman WhereHows untuk LinkedIn menjadi lebih maju daripada versi sumber terbuka. Ia juga mempunyai nama baharu - DataHub. Berdasarkan percubaan yang gagal sebelum ini, pasukan memutuskan untuk membangunkan penyelesaian jangka panjang yang boleh skala.
Untuk sebarang projek sumber terbuka baharu, pasukan sumber terbuka LinkedIn menasihati dan menyokong model pembangunan di mana modul projek dibangunkan sepenuhnya dalam sumber terbuka. Artifak versi digunakan ke repositori awam dan kemudian disemak semula ke dalam artifak LinkedIn dalaman yang digunakan . Mengikuti model pembangunan ini bukan sahaja baik untuk mereka yang menggunakan sumber terbuka, tetapi juga menghasilkan seni bina yang lebih modular, boleh dipanjangkan dan boleh dipasang.
Walau bagaimanapun, aplikasi bahagian belakang yang matang seperti DataHub akan memerlukan sejumlah besar masa untuk mencapai keadaan ini. Ini juga menghalang kemungkinan penyumberan terbuka pelaksanaan yang berfungsi sepenuhnya sebelum semua kebergantungan dalaman telah diabstrakkan sepenuhnya. Itulah sebabnya kami telah membangunkan alat yang membantu kami membuat sumbangan sumber terbuka dengan lebih pantas dan dengan lebih sedikit kesakitan. Penyelesaian ini memberi manfaat kepada kedua-dua pasukan metadata (pembangun DataHub) dan komuniti sumber terbuka. Bahagian berikut akan membincangkan pendekatan baharu ini.
Automasi Penerbitan Sumber Terbuka
Pendekatan terkini pasukan Metadata terhadap DataHub sumber terbuka adalah untuk membangunkan alat yang menyegerakkan pangkalan kod dalaman dan repositori sumber terbuka secara automatik. Ciri tahap tinggi kit alat ini termasuk:
- Segerakkan kod LinkedIn ke/daripada sumber terbuka, serupa .
- Penjanaan pengepala lesen, serupa dengan .
- Menjana log komit sumber terbuka secara automatik daripada log komit dalaman.
- Cegah perubahan dalaman yang memecahkan binaan sumber terbuka oleh .
Subseksyen berikut akan menyelidiki fungsi yang disebutkan di atas yang mempunyai masalah menarik.
Penyegerakan kod sumber
Tidak seperti versi sumber terbuka DataHub, yang merupakan satu repositori GitHub, versi LinkedIn DataHub ialah gabungan berbilang repositori (dipanggil secara dalaman ). Antara muka DataHub, perpustakaan model metadata, perkhidmatan hujung belakang gudang metadata dan kerja penstriman berada dalam repositori berasingan di LinkedIn. Walau bagaimanapun, untuk memudahkan pengguna sumber terbuka, kami mempunyai satu repositori untuk versi sumber terbuka DataHub.
Rajah 1: Penyegerakan antara repositori LinkedIn DataHub dan satu repositori DataHub sumber terbuka
Untuk menyokong aliran kerja bina, tolak dan tarik automatik, alat baharu kami secara automatik mencipta pemetaan peringkat fail yang sepadan dengan setiap fail sumber. Walau bagaimanapun, kit alat memerlukan konfigurasi awal dan pengguna mesti menyediakan pemetaan modul peringkat tinggi seperti yang ditunjukkan di bawah.
{
"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 peringkat modul ialah JSON mudah yang kuncinya ialah modul sasaran dalam repositori sumber terbuka dan nilainya ialah senarai modul sumber dalam repositori LinkedIn. Mana-mana modul sasaran dalam repositori sumber terbuka boleh disuap oleh sebarang bilangan modul sumber. Untuk menunjukkan nama dalaman repositori dalam modul sumber, gunakan dalam gaya Bash. Menggunakan fail pemetaan peringkat modul, alatan mencipta fail pemetaan peringkat fail dengan mengimbas semua fail dalam direktori yang berkaitan.
{
"${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 peringkat fail dibuat secara automatik oleh alatan; walau bagaimanapun, ia juga boleh dikemas kini secara manual oleh pengguna. Ini ialah pemetaan 1:1 fail sumber LinkedIn ke fail dalam repositori sumber terbuka. Terdapat beberapa peraturan yang dikaitkan dengan penciptaan automatik persatuan fail ini:
- Dalam kes modul berbilang sumber untuk modul sasaran dalam sumber terbuka, konflik mungkin timbul, mis. , wujud dalam lebih daripada satu modul sumber. Sebagai strategi penyelesaian konflik, alatan kami lalai kepada pilihan "yang terakhir menang".
- "null" bermaksud bahawa fail sumber bukan sebahagian daripada repositori sumber terbuka.
- Selepas setiap penyerahan atau pengekstrakan sumber terbuka, pemetaan ini dikemas kini secara automatik dan syot kilat dibuat. Ini adalah perlu untuk mengenal pasti penambahan dan pemadaman daripada kod sumber sejak tindakan terakhir.
Mencipta log komit
Log komit untuk komit sumber terbuka juga dijana secara automatik dengan menggabungkan log komit repositori dalaman. Di bawah ialah contoh log komit untuk menunjukkan struktur log komit yang dijana oleh alat kami. Komit dengan jelas menunjukkan versi repositori sumber yang dibungkus dalam komit itu dan menyediakan ringkasan log komit. Semak yang ini menggunakan contoh sebenar log komit yang dijana oleh kit alat 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.0Ujian kebergantungan
LinkedIn mempunyai , yang membantu memastikan bahawa perubahan pada multiproduk dalaman tidak memecahkan pemasangan multiproduk bergantung. Repositori DataHub sumber terbuka bukan berbilang produk dan ia tidak boleh menjadi pergantungan langsung mana-mana berbilang produk, tetapi dengan bantuan pembungkus berbilang produk yang mengambil kod sumber DataHub sumber terbuka, kami masih boleh menggunakan ujian pergantungan ini. Oleh itu, sebarang perubahan (yang mungkin terdedah kemudian) kepada mana-mana berbilang produk yang memberi suapan kepada repositori DataHub sumber terbuka mencetuskan peristiwa binaan dalam pelbagai produk shell. Oleh itu, sebarang perubahan yang gagal membina produk pembungkus gagal dalam ujian sebelum melakukan produk asal dan dikembalikan.
Ini ialah mekanisme berguna yang membantu menghalang sebarang komit dalaman yang memecahkan binaan sumber terbuka dan mengesannya pada masa komit. Tanpa ini, agak sukar untuk menentukan komit dalaman yang menyebabkan binaan repositori sumber terbuka gagal, kerana kami menyusun perubahan dalaman pada repositori sumber terbuka DataHub.
Perbezaan antara DataHub sumber terbuka dan versi pengeluaran kami
Sehingga tahap ini, kami telah membincangkan penyelesaian kami untuk menyegerakkan dua versi repositori DataHub, tetapi kami masih belum menggariskan sebab mengapa kami memerlukan dua aliran pembangunan yang berbeza di tempat pertama. Dalam bahagian ini, kami akan menyenaraikan perbezaan antara versi awam DataHub dan versi pengeluaran pada pelayan LinkedIn, dan menerangkan sebab perbezaan ini.
Satu sumber percanggahan berpunca daripada fakta bahawa versi pengeluaran kami mempunyai pergantungan pada kod yang belum lagi menjadi sumber terbuka, seperti LinkedIn's Offspring (rangka kerja suntikan pergantungan dalaman LinkedIn). Keturunan digunakan secara meluas dalam pangkalan kod dalaman kerana ia adalah kaedah pilihan untuk mengurus konfigurasi dinamik. Tetapi ia bukan sumber terbuka; jadi kami perlu mencari alternatif sumber terbuka kepada DataHub sumber terbuka.
Ada sebab lain juga. Semasa kami membuat sambungan kepada model metadata untuk keperluan LinkedIn, sambungan ini biasanya sangat khusus untuk LinkedIn dan mungkin tidak digunakan secara langsung pada persekitaran lain. Sebagai contoh, kami mempunyai label yang sangat khusus untuk ID peserta dan jenis metadata sepadan yang lain. Jadi, kami kini telah mengecualikan sambungan ini daripada model metadata sumber terbuka DataHub. Semasa kami melibatkan diri dengan komuniti dan memahami keperluan mereka, kami akan mengusahakan versi sumber terbuka biasa sambungan ini jika diperlukan.
Kemudahan penggunaan dan penyesuaian yang lebih mudah untuk komuniti sumber terbuka juga memberi inspirasi kepada beberapa perbezaan antara kedua-dua versi DataHub. Perbezaan dalam infrastruktur pemprosesan aliran adalah contoh yang baik untuk ini. Walaupun versi dalaman kami menggunakan rangka kerja pemprosesan strim terurus, kami memilih untuk menggunakan pemprosesan strim terbina dalam (berdiri sendiri) untuk versi sumber terbuka kerana ia mengelak daripada mewujudkan pergantungan infrastruktur yang lain.
Satu lagi contoh perbezaan ialah mempunyai satu GMS (Kedai Metadata Umum) dalam pelaksanaan sumber terbuka dan bukannya berbilang GMS. GMA (Generalized Metadata Architecture) ialah nama seni bina bahagian belakang untuk DataHub, dan GMS ialah stor metadata dalam konteks GMA. GMA ialah seni bina yang sangat fleksibel yang membolehkan anda mengedarkan setiap binaan data (cth. set data, pengguna, dsb.) ke dalam stor metadatanya sendiri, atau menyimpan berbilang binaan data dalam stor metadata tunggal selagi pendaftaran yang mengandungi pemetaan struktur data dalam GMS dikemas kini. Untuk kemudahan penggunaan, kami memilih satu tika GMS yang menyimpan semua binaan data yang berbeza dalam DataHub sumber terbuka.
Senarai lengkap perbezaan antara kedua-dua pelaksanaan diberikan dalam jadual di bawah.
Ciri-ciri Produk
LinkedIn DataHub
DataHub Sumber Terbuka
Konstruk Data yang Disokong
1) Set Data 2) Pengguna 3) Metrik 4) Ciri ML 5) Carta 6) Papan Pemuka
1) Set Data 2) Pengguna
Sumber Metadata yang Disokong untuk Set Data
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Hive Kafka RDBMS
Subtitle pub
Konfluen Kafka
Pemprosesan Stream
Diuruskan
Terbenam (berdiri sendiri)
Suntikan Ketergantungan & Konfigurasi Dinamik
Keturunan LinkedIn
Membina Alatan
Ligradle (pembungkus Gradle dalaman LinkedIn)
CI / CD
CRT (CI/CD dalaman LinkedIn)
and
Kedai Metadata
GMS berbilang yang diedarkan: 1) GMS Set Data 2) GMS Pengguna 3) GMS Metrik 4) GMS Ciri 5) GMS Carta/Papan Pemuka
GMS Tunggal untuk: 1) Set Data 2) Pengguna
Perkhidmatan mikro dalam bekas Docker
memudahkan penggunaan dan pengedaran aplikasi dengan . Setiap bahagian perkhidmatan dalam DataHub adalah sumber terbuka, termasuk komponen infrastruktur seperti Kafka, , ΠΈ , mempunyai imej Docker sendiri. Untuk mengatur bekas Docker yang kami gunakan .
Rajah 2: Seni Bina DataHub *sumber terbuka**
Anda boleh melihat seni bina peringkat tinggi DataHub dalam imej di atas. Selain komponen infrastruktur, ia mempunyai empat bekas Docker berbeza:
datahub-gms: perkhidmatan storan metadata
datahub-frontend: aplikasi , menyediakan antara muka DataHub.
datahub-mce-consumer: aplikasi , yang menggunakan strim peristiwa perubahan metadata (MCE) dan mengemas kini stor metadata.
datahub-mae-consumer: aplikasi , yang menggunakan aliran peristiwa audit metadata (MAE) dan mencipta indeks carian dan pangkalan data graf.
Dokumentasi repositori sumber terbuka dan mengandungi maklumat yang lebih terperinci tentang fungsi pelbagai perkhidmatan.
CI/CD pada DataHub ialah sumber terbuka
Repositori DataHub sumber terbuka menggunakan untuk integrasi berterusan dan untuk penempatan berterusan. Kedua-duanya mempunyai integrasi GitHub yang baik dan mudah disediakan. Untuk kebanyakan infrastruktur sumber terbuka yang dibangunkan oleh komuniti atau syarikat swasta (cth. ), imej Docker dicipta dan digunakan ke Docker Hub untuk kemudahan penggunaan oleh komuniti. Mana-mana imej Docker yang terdapat dalam Docker Hub boleh digunakan dengan mudah dengan arahan mudah .
Dengan setiap komitmen kepada repositori sumber terbuka DataHub, semua imej Docker dibina secara automatik dan digunakan ke Docker Hub dengan teg "terkini". Jika Docker Hub dikonfigurasikan dengan beberapa , semua teg dalam repositori sumber terbuka juga dikeluarkan dengan nama teg yang sepadan dalam Docker Hub.
Menggunakan DataHub
adalah sangat mudah dan terdiri daripada tiga langkah mudah:
- Klon repositori sumber terbuka dan jalankan semua bekas Docker dengan docker-compose menggunakan skrip docker-compose yang disediakan untuk permulaan yang pantas.
- Muat turun data sampel yang disediakan dalam repositori menggunakan alat baris arahan yang turut disediakan.
- Semak imbas DataHub dalam penyemak imbas anda.
Dijejaki secara aktif juga dikonfigurasikan untuk soalan cepat. Pengguna juga boleh membuat isu terus dalam repositori GitHub. Paling penting, kami mengalu-alukan dan menghargai semua maklum balas dan cadangan!
ΠΠ»Π°Π½Ρ Π½Π° Π±ΡΠ΄ΡΡΠ΅Π΅
Pada masa ini, setiap infrastruktur atau perkhidmatan mikro untuk DataHub sumber terbuka dibina sebagai bekas Docker dan keseluruhan sistem diatur menggunakan . Memandangkan populariti dan meluas , kami juga ingin menyediakan penyelesaian berasaskan Kubernetes dalam masa terdekat.
Kami juga merancang untuk menyediakan penyelesaian turnkey untuk menggunakan DataHub pada perkhidmatan awan awam seperti , atau . Memandangkan pengumuman baru-baru ini mengenai penghijrahan LinkedIn ke Azure, ini akan sejajar dengan keutamaan dalaman pasukan metadata.
Akhir sekali, terima kasih kepada semua pengguna awal DataHub dalam komuniti sumber terbuka yang telah menilai alfa DataHub dan membantu kami mengenal pasti isu dan menambah baik dokumentasi.
Sumber: www.habr.com