DataHub Sumber Terbuka: Platform Pencarian dan Penemuan Metadata LinkedIn
Menemukan data yang Anda perlukan dengan cepat sangatlah penting bagi perusahaan mana pun yang mengandalkan data dalam jumlah besar untuk membuat keputusan berdasarkan data. Hal ini tidak hanya berdampak pada produktivitas pengguna data (termasuk analis, pengembang pembelajaran mesin, ilmuwan data, dan insinyur data), namun juga berdampak langsung pada produk akhir yang bergantung pada jalur pembelajaran mesin (ML) yang berkualitas. Selain itu, tren penerapan atau pembuatan platform pembelajaran mesin tentu saja menimbulkan pertanyaan: apa metode Anda untuk menemukan fitur, model, metrik, kumpulan data, dll secara internal.
Pada artikel ini kita akan membahas tentang bagaimana kami menerbitkan sumber data di bawah lisensi terbuka di platform pencarian dan penemuan metadata kami, mulai dari awal proyek . LinkedIn mengelola DataHub versinya sendiri secara terpisah dari versi sumber terbuka. Kami akan mulai dengan menjelaskan mengapa kami memerlukan dua lingkungan pengembangan terpisah, kemudian mendiskusikan pendekatan awal untuk menggunakan WhereHows sumber terbuka dan membandingkan DataHub versi internal (produksi) kami dengan versi di . Kami juga akan membagikan detail tentang solusi otomatis baru kami untuk mendorong dan menerima pembaruan sumber terbuka agar kedua repositori tetap sinkron. Terakhir, kami akan memberikan petunjuk tentang cara mulai menggunakan DataHub sumber terbuka dan membahas secara singkat arsitekturnya.
WhereHows sekarang menjadi DataHub!
Tim metadata LinkedIn sebelumnya telah memaparkan (penerus WhereHows), platform pencarian dan penemuan metadata LinkedIn, dan berbagi rencana untuk membukanya. Tak lama setelah pengumuman ini, kami merilis DataHub versi alfa dan membagikannya kepada komunitas. Sejak itu, kami terus berkontribusi pada repositori dan bekerja dengan pengguna yang tertarik untuk menambahkan fitur yang paling banyak diminta dan memecahkan masalah. Kami sekarang dengan senang hati mengumumkan rilis resminya .
Pendekatan Sumber Terbuka
WhereHows, portal asli LinkedIn untuk menemukan data dan dari mana asalnya, dimulai sebagai proyek internal; tim metadata membukanya . Sejak itu, tim selalu mempertahankan dua basis kode yang berbedaβsatu untuk sumber terbuka dan satu lagi untuk penggunaan internal LinkedInβkarena tidak semua fitur produk yang dikembangkan untuk kasus penggunaan LinkedIn dapat diterapkan secara umum untuk khalayak yang lebih luas. Selain itu, WhereHows memiliki beberapa dependensi internal (infrastruktur, perpustakaan, dll.) yang bukan open source. Pada tahun-tahun berikutnya, WhereHows mengalami banyak iterasi dan siklus pengembangan, sehingga menjaga sinkronisasi kedua basis kode menjadi sebuah tantangan besar. Tim metadata telah mencoba pendekatan berbeda selama bertahun-tahun untuk mencoba menjaga sinkronisasi pengembangan internal dan open source.
Percobaan pertama: "Open source dulu"
Kami awalnya mengikuti model pengembangan "open source first", di mana sebagian besar pengembangan terjadi di repositori open source dan perubahan dilakukan untuk penerapan internal. Masalah dengan pendekatan ini adalah kode selalu dikirim ke GitHub terlebih dahulu sebelum ditinjau sepenuhnya secara internal. Hingga perubahan dilakukan pada repositori sumber terbuka dan penerapan internal baru dilakukan, kami tidak akan menemukan masalah produksi apa pun. Dalam kasus penerapan yang buruk, juga sangat sulit untuk menentukan penyebabnya karena perubahan dilakukan secara bertahap.
Selain itu, model ini mengurangi produktivitas tim saat mengembangkan fitur baru yang memerlukan iterasi cepat, karena model ini memaksa semua perubahan untuk dimasukkan terlebih dahulu ke dalam repositori sumber terbuka dan kemudian dimasukkan ke dalam repositori internal. Untuk mengurangi waktu pemrosesan, perbaikan atau perubahan yang diperlukan dapat dilakukan di repositori internal terlebih dahulu, namun hal ini menjadi masalah besar ketika harus menggabungkan kembali perubahan tersebut ke dalam repositori sumber terbuka karena kedua repositori tersebut tidak sinkron.
Model ini jauh lebih mudah diterapkan untuk platform bersama, perpustakaan, atau proyek infrastruktur dibandingkan untuk aplikasi web kustom berfitur lengkap. Selain itu, model ini ideal untuk proyek yang memulai open source sejak hari pertama, namun WhereHows dibangun sebagai aplikasi web yang sepenuhnya internal. Sangat sulit untuk sepenuhnya mengabstraksi semua ketergantungan internal, jadi kami perlu mempertahankan fork internal, namun mempertahankan fork internal dan mengembangkan sebagian besar open source tidaklah berhasil.
Upaya kedua: βBatin duluβ
**Sebagai upaya kedua, kami beralih ke model pengembangan "internal pertama", di mana sebagian besar pengembangan dilakukan secara internal dan perubahan dilakukan pada kode sumber terbuka secara berkala. Meskipun model ini paling cocok untuk kasus penggunaan kita, model ini memiliki masalah yang melekat. Mendorong semua perbedaan secara langsung ke repositori sumber terbuka dan kemudian mencoba menyelesaikan konflik penggabungan nanti adalah sebuah pilihan, tetapi ini memakan waktu. Pengembang dalam banyak kasus mencoba untuk tidak melakukan ini setiap kali mereka meninjau kode mereka. Akibatnya, hal ini akan lebih jarang dilakukan, secara berkelompok, dan dengan demikian akan lebih sulit menyelesaikan konflik penggabungan di kemudian hari.
Ketiga kalinya berhasil!
Dua upaya gagal yang disebutkan di atas mengakibatkan repositori WhereHows GitHub ketinggalan zaman untuk waktu yang lama. Tim terus menyempurnakan fitur dan arsitektur produk, sehingga versi internal WhereHows untuk LinkedIn menjadi lebih canggih dibandingkan versi sumber terbuka. Bahkan ada nama baru - DataHub. Berdasarkan upaya sebelumnya yang gagal, tim memutuskan untuk mengembangkan solusi jangka panjang yang terukur.
Untuk setiap proyek sumber terbuka baru, tim sumber terbuka LinkedIn menyarankan dan mendukung model pengembangan di mana modul proyek dikembangkan seluruhnya dalam sumber terbuka. Artefak berversi disebarkan ke repositori publik dan kemudian diperiksa kembali ke artefak internal LinkedIn menggunakan . Mengikuti model pengembangan ini tidak hanya baik bagi mereka yang menggunakan open source, namun juga menghasilkan arsitektur yang lebih modular, dapat diperluas, dan dapat dipasang.
Namun, aplikasi back-end yang matang seperti DataHub akan memerlukan banyak waktu untuk mencapai kondisi ini. Hal ini juga menghalangi kemungkinan penerapan open source yang berfungsi penuh sebelum semua dependensi internal diabstraksi sepenuhnya. Itu sebabnya kami mengembangkan alat yang membantu kami memberikan kontribusi open source lebih cepat dan lebih mudah. Solusi ini menguntungkan tim metadata (pengembang DataHub) dan komunitas sumber terbuka. Bagian berikut akan membahas pendekatan baru ini.
Otomatisasi Penerbitan Sumber Terbuka
Pendekatan terbaru tim Metadata terhadap DataHub sumber terbuka adalah mengembangkan alat yang secara otomatis menyinkronkan basis kode internal dan repositori sumber terbuka. Fitur tingkat tinggi dari perangkat ini meliputi:
- Sinkronkan kode LinkedIn ke/dari sumber terbuka, serupa .
- Pembuatan header lisensi, mirip dengan .
- Secara otomatis menghasilkan log komit sumber terbuka dari log komit internal.
- Cegah perubahan internal yang merusak pembuatan sumber terbuka .
Subbagian berikut akan mempelajari fungsi-fungsi yang disebutkan di atas yang memiliki masalah menarik.
Sinkronisasi kode sumber
Berbeda dengan DataHub versi open source, yang merupakan repositori GitHub tunggal, DataHub versi LinkedIn adalah kombinasi beberapa repositori (disebut secara internal ). Antarmuka DataHub, pustaka model metadata, layanan backend gudang metadata, dan pekerjaan streaming berada di repositori terpisah di LinkedIn. Namun, untuk memudahkan pengguna open source, kami memiliki satu repositori untuk DataHub versi open source.
Gambar 1: Sinkronisasi antar repositori LinkedIn Pusat Data dan satu repositori Pusat Data sumber terbuka
Untuk mendukung alur kerja build, push, dan pull otomatis, alat baru kami secara otomatis membuat pemetaan tingkat file yang sesuai dengan setiap file sumber. Namun, toolkit ini memerlukan konfigurasi awal dan pengguna harus menyediakan pemetaan modul tingkat tinggi seperti yang ditunjukkan di bawah ini.
{
"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 adalah JSON sederhana yang kuncinya adalah modul target di repositori sumber terbuka dan nilainya adalah daftar modul sumber di repositori LinkedIn. Modul target apa pun dalam repositori sumber terbuka dapat diumpankan oleh sejumlah modul sumber berapa pun. Untuk menunjukkan nama internal repositori dalam modul sumber, gunakan dalam gaya Bash. Dengan menggunakan file pemetaan tingkat modul, alat ini membuat file pemetaan tingkat file dengan memindai semua file di direktori terkait.
{
"${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 secara otomatis dibuat oleh alat; namun, ini juga dapat diperbarui secara manual oleh pengguna. Ini adalah pemetaan 1:1 dari file sumber LinkedIn ke file di repositori sumber terbuka. Ada beberapa aturan yang terkait dengan pembuatan asosiasi file otomatis ini:
- Dalam kasus beberapa modul sumber untuk modul target di sumber terbuka, konflik mungkin timbul, misalnya sama , ada di lebih dari satu modul sumber. Sebagai strategi penyelesaian konflik, alat kami secara default menggunakan opsi βyang terakhir menangβ.
- "null" berarti file sumber bukan bagian dari repositori sumber terbuka.
- Setelah setiap pengiriman atau ekstraksi sumber terbuka, pemetaan ini diperbarui secara otomatis dan snapshot dibuat. Hal ini diperlukan untuk mengidentifikasi penambahan dan penghapusan dari kode sumber sejak tindakan terakhir.
Membuat log komit
Log komit untuk komit sumber terbuka juga dibuat secara otomatis dengan menggabungkan log komit dari repositori internal. Di bawah ini adalah contoh log komit untuk menunjukkan struktur log komit yang dihasilkan oleh alat kami. Komit dengan jelas menunjukkan versi repositori sumber mana yang dikemas dalam komit tersebut dan memberikan ringkasan log komit. Lihat yang ini menggunakan contoh nyata dari log komit yang dihasilkan oleh 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.0Pengujian ketergantungan
LinkedIn punya , yang membantu memastikan bahwa perubahan pada multiproduk internal tidak merusak perakitan multiproduk yang bergantung. Repositori DataHub sumber terbuka bukanlah multi-produk, dan tidak dapat menjadi ketergantungan langsung dari multi-produk apa pun, namun dengan bantuan pembungkus multi-produk yang mengambil kode sumber DataHub sumber terbuka, kita masih dapat menggunakan pengujian ketergantungan ini Oleh karena itu, perubahan apa pun (yang nantinya dapat diekspos) pada multiproduk apa pun yang memberi makan repositori DataHub sumber terbuka akan memicu peristiwa pembangunan di multiproduk shell. Oleh karena itu, setiap perubahan yang gagal membuat produk pembungkus gagal dalam pengujian sebelum melakukan produk asli dan dikembalikan.
Ini adalah mekanisme berguna yang membantu mencegah penerapan internal apa pun yang merusak build sumber terbuka dan mendeteksinya pada waktu penerapan. Tanpa hal ini, akan sangat sulit untuk menentukan penerapan internal mana yang menyebabkan kegagalan pembuatan repositori sumber terbuka, karena kami melakukan batch perubahan internal pada repositori sumber terbuka DataHub.
Perbedaan antara DataHub sumber terbuka dan versi produksi kami
Hingga saat ini, kami telah membahas solusi kami untuk menyinkronkan dua versi repositori DataHub, namun kami masih belum menguraikan alasan mengapa kami memerlukan dua aliran pengembangan yang berbeda. Di bagian ini, kami akan mencantumkan perbedaan antara DataHub versi publik dan versi produksi di server LinkedIn, dan menjelaskan alasan perbedaan tersebut.
Salah satu sumber perbedaan berasal dari fakta bahwa versi produksi kami memiliki ketergantungan pada kode yang belum open source, seperti Offspring LinkedIn (kerangka injeksi ketergantungan internal LinkedIn). Keturunan banyak digunakan dalam basis kode internal karena merupakan metode pilihan untuk mengelola konfigurasi dinamis. Tapi ini bukan open source; jadi kami perlu mencari alternatif sumber terbuka selain DataHub sumber terbuka.
Ada alasan lain juga. Saat kami membuat ekstensi pada model metadata untuk kebutuhan LinkedIn, ekstensi ini biasanya sangat spesifik untuk LinkedIn dan mungkin tidak berlaku langsung untuk lingkungan lain. Misalnya, kami memiliki label yang sangat spesifik untuk ID peserta dan jenis metadata lain yang cocok. Jadi, kami sekarang telah mengecualikan ekstensi ini dari model metadata sumber terbuka DataHub. Saat kami terlibat dengan komunitas dan memahami kebutuhan mereka, kami akan mengerjakan versi open source umum dari ekstensi ini jika diperlukan.
Kemudahan penggunaan dan adaptasi yang lebih mudah bagi komunitas open source juga menginspirasi beberapa perbedaan antara kedua versi DataHub. Perbedaan dalam infrastruktur pemrosesan aliran adalah contoh bagusnya. Meskipun versi internal kami menggunakan kerangka pemrosesan aliran terkelola, kami memilih untuk menggunakan pemrosesan aliran bawaan (mandiri) untuk versi sumber terbuka karena hal ini menghindari ketergantungan infrastruktur lainnya.
Contoh lain dari perbedaan ini adalah memiliki satu GMS (Generalized Metadata Store) dalam implementasi open source, bukan beberapa GMS. GMA (Arsitektur Metadata Umum) adalah nama arsitektur back-end untuk DataHub, dan GMS adalah penyimpanan metadata dalam konteks GMA. GMA adalah arsitektur yang sangat fleksibel yang memungkinkan Anda mendistribusikan setiap konstruksi data (misalnya kumpulan data, pengguna, dll.) ke dalam penyimpanan metadatanya sendiri, atau menyimpan beberapa konstruksi data dalam satu penyimpanan metadata selama registri berisi pemetaan struktur data di RUPS diperbarui. Untuk kemudahan penggunaan, kami memilih satu instans GMS yang menyimpan semua konstruksi data berbeda di DataHub sumber terbuka.
Daftar lengkap perbedaan antara kedua implementasi tersebut diberikan pada tabel di bawah.
Fitur Produk
Pusat Data LinkedIn
DataHub Sumber Terbuka
Konstruksi Data yang Didukung
1) Kumpulan Data 2) Pengguna 3) Metrik 4) Fitur ML 5) Bagan 6) Dasbor
1) Kumpulan Data 2) Pengguna
Sumber Metadata yang Didukung untuk Kumpulan Data
1) 2) Basis Sofa 3) 4) 5) HDFS 6) Sarang 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Sarang Kafka RDBMS
Pub-sub
Kafka yang Konfluen
Pemrosesan Aliran
dikelola
Tertanam (mandiri)
Injeksi Ketergantungan & Konfigurasi Dinamis
Keturunan LinkedIn
Bangun Perkakas
Ligradle (pembungkus Gradle internal LinkedIn)
CI / CD
CRT (CI/CD internal LinkedIn)
dan
Penyimpanan Metadata
Beberapa RUPS yang didistribusikan: 1) RUPS Dataset 2) RUPS Pengguna 3) RUPS Metrik 4) RUPS Fitur 5) RUPS Bagan/Dasbor
RUPS Tunggal untuk: 1) Dataset 2) User
Layanan mikro dalam wadah Docker
menyederhanakan penerapan dan distribusi aplikasi dengan . Setiap bagian layanan di DataHub bersifat open source, termasuk komponen infrastruktur seperti Kafka, , ΠΈ , memiliki image Docker sendiri. Untuk mengatur kontainer Docker yang kami gunakan .
Gambar 2: Arsitektur Pusat Data *sumber terbuka**
Anda dapat melihat arsitektur DataHub tingkat tinggi pada gambar di atas. Selain komponen infrastruktur, ia memiliki empat container Docker yang berbeda:
datahub-gms: layanan penyimpanan metadata
datahub-frontend: aplikasi , melayani antarmuka DataHub.
datahub-mce-consumer: aplikasi , yang menggunakan aliran peristiwa perubahan metadata (MCE) dan memperbarui penyimpanan metadata.
datahub-mae-konsumen: aplikasi , yang menggunakan aliran peristiwa audit metadata (MAE) dan membuat indeks pencarian dan database grafik.
Dokumentasi repositori sumber terbuka dan berisi informasi lebih rinci tentang fungsi berbagai layanan.
CI/CD di DataHub bersifat open source
Repositori DataHub sumber terbuka menggunakan untuk integrasi berkelanjutan dan untuk penyebaran berkelanjutan. Keduanya memiliki integrasi GitHub yang baik dan mudah diatur. Untuk sebagian besar infrastruktur sumber terbuka yang dikembangkan oleh komunitas atau perusahaan swasta (mis. ), Gambar Docker dibuat dan disebarkan ke Docker Hub untuk kemudahan penggunaan oleh komunitas. Gambar Docker apa pun yang ditemukan di Docker Hub dapat digunakan dengan mudah hanya dengan perintah sederhana .
Dengan setiap penerapan ke repositori sumber terbuka DataHub, semua image Docker secara otomatis dibuat dan disebarkan ke Docker Hub dengan tag "terbaru". Jika Docker Hub dikonfigurasi dengan beberapa , semua tag di repositori sumber terbuka juga dirilis dengan nama tag yang sesuai di Docker Hub.
Menggunakan DataHub
sangat sederhana dan terdiri dari tiga langkah sederhana:
- Kloning repositori sumber terbuka dan jalankan semua container Docker dengan docker-compose menggunakan skrip docker-compose yang disediakan untuk memulai dengan cepat.
- Unduh contoh data yang disediakan di repositori menggunakan alat baris perintah yang juga disediakan.
- Jelajahi DataHub di browser Anda.
Dilacak Secara Aktif juga dikonfigurasi untuk pertanyaan cepat. Pengguna juga dapat membuat masalah secara langsung di repositori GitHub. Yang terpenting, kami menyambut dan menghargai semua masukan dan saran!
ΠΠ»Π°Π½Ρ Π½Π° Π±ΡΠ΄ΡΡΠ΅Π΅
Saat ini, setiap infrastruktur atau layanan mikro untuk DataHub sumber terbuka dibangun sebagai wadah Docker, dan seluruh sistem diatur menggunakan . Mengingat popularitas dan luasnya , kami juga ingin memberikan solusi berbasis Kubernetes dalam waktu dekat.
Kami juga berencana untuk memberikan solusi siap pakai untuk menerapkan DataHub pada layanan cloud publik seperti , ΠΈΠ»ΠΈ . Mengingat pengumuman migrasi LinkedIn ke Azure baru-baru ini, hal ini akan selaras dengan prioritas internal tim metadata.
Yang terakhir, terima kasih kepada semua pengguna awal DataHub di komunitas sumber terbuka yang telah memberikan peringkat Alfa pada DataHub dan membantu kami mengidentifikasi masalah serta meningkatkan dokumentasi.
Sumber: www.habr.com