Ochiq manbali DataHub: LinkedIn metadata qidiruvi va kashfiyot platformasi
Ma'lumotlarga asoslangan qarorlar qabul qilish uchun katta hajmdagi ma'lumotlarga tayanadigan har qanday kompaniya uchun kerakli ma'lumotlarni tezda topish juda muhimdir. Bu nafaqat ma'lumotlardan foydalanuvchilarning (jumladan, tahlilchilar, mashinani o'rganishni ishlab chiquvchilari, ma'lumotlar olimlari va ma'lumotlar muhandislari) samaradorligiga ta'sir qiladi, balki sifatli mashinani o'rganish (ML) quvur liniyasiga bog'liq bo'lgan yakuniy mahsulotlarga ham bevosita ta'sir qiladi. Bundan tashqari, mashinani o'rganish platformalarini joriy etish yoki qurish tendentsiyasi tabiiy ravishda savol tug'diradi: xususiyatlar, modellar, o'lchovlar, ma'lumotlar to'plami va boshqalarni ichki kashf qilish usuli qanday?
Ushbu maqolada biz ochiq litsenziya ostida ma'lumotlar manbasini qanday nashr etganimiz haqida gaplashamiz loyihaning dastlabki kunlaridan boshlab metadata qidirish va kashf qilish platformamizda . LinkedIn o'zining DataHub versiyasini ochiq manba versiyasidan alohida saqlaydi. Biz nima uchun bizga ikkita alohida ishlab chiqish muhiti kerakligini tushuntirishdan boshlaymiz, so‘ngra WhereHows ochiq manbasidan foydalanishning dastlabki yondashuvlarini muhokama qilamiz va DataHub ning ichki (ishlab chiqarish) versiyasini quyidagi versiya bilan solishtiramiz. . Biz, shuningdek, ikkala omborni sinxronlashtirish uchun ochiq manba yangilanishlarini yuborish va qabul qilish bo‘yicha yangi avtomatlashtirilgan yechimimiz haqida ma’lumotlarni baham ko‘ramiz. Nihoyat, biz ochiq manba DataHub-dan qanday foydalanishni boshlash bo'yicha ko'rsatmalar beramiz va uning arxitekturasini qisqacha muhokama qilamiz.
WhereHow endi DataHub!
LinkedIn metadata jamoasi ilgari taqdim etilgan (WhereHows vorisi), LinkedIn qidiruv va metadata kashfiyot platformasi va uni ochish boʻyicha umumiy rejalar. Ushbu e'londan ko'p o'tmay, biz DataHub-ning alfa versiyasini chiqardik va uni hamjamiyat bilan baham ko'rdik. O'shandan beri biz doimiy ravishda omborga o'z hissamizni qo'shdik va eng ko'p talab qilinadigan xususiyatlarni qo'shish va muammolarni hal qilish uchun qiziqqan foydalanuvchilar bilan ishladik. Endi biz rasmiy nashrni e'lon qilishdan mamnunmiz .
Ochiq manbali yondashuvlar
WhereHows, LinkedIn-ning ma'lumotlar va ular qayerdan kelganini topish uchun original portali ichki loyiha sifatida boshlangan; metadata jamoasi uni ochdi . O'shandan beri jamoa har doim ikkita turli kod bazasini saqlab kelmoqda - biri ochiq manba uchun va ikkinchisi LinkedInning ichki foydalanishi uchun - chunki LinkedIn foydalanish holatlari uchun ishlab chiqilgan barcha mahsulot xususiyatlari odatda kengroq auditoriya uchun qo'llanilmaydi. Bundan tashqari, WhereHows ochiq manba bo'lmagan ba'zi ichki bog'liqliklarga (infratuzilma, kutubxonalar va boshqalar) ega. Keyingi yillarda WhereHows ko'plab iteratsiyalar va rivojlanish davrlarini bosib o'tdi, bu ikki kod bazasini sinxronlashtirishni katta muammoga aylantirdi. Metadata jamoasi yillar davomida ichki va ochiq manbali rivojlanishni sinxronlashtirishga harakat qilish uchun turli yondashuvlarni sinab ko'rdi.
Birinchi urinib ko'ring: "Avval ochiq manba"
Biz dastlab "birinchi navbatda ochiq manba" ishlab chiqish modeliga amal qildik, bunda ko'pchilik ishlanmalar ochiq manba omborida sodir bo'ladi va ichki joylashtirish uchun o'zgarishlar kiritiladi. Ushbu yondashuv bilan bog'liq muammo shundaki, kod har doim to'liq ichki ko'rib chiqilishidan oldin GitHub-ga yuboriladi. Ochiq manba omboridan o'zgarishlar kiritilmaguncha va yangi ichki joylashtirish amalga oshirilmaguncha, biz ishlab chiqarish bilan bog'liq hech qanday muammoni topa olmaymiz. Yomon joylashtirilsa, aybdorni aniqlash ham juda qiyin edi, chunki o'zgarishlar partiyalarda amalga oshirildi.
Bundan tashqari, ushbu model tez takrorlashni talab qiladigan yangi xususiyatlarni ishlab chiqishda jamoaning unumdorligini pasaytirdi, chunki u barcha o'zgarishlarni avval ochiq manba omboriga, keyin esa ichki omborga o'tkazishga majbur qildi. Qayta ishlash vaqtini qisqartirish uchun avvalo ichki omborda kerakli tuzatish yoki o'zgartirishlar amalga oshirilishi mumkin edi, lekin bu o'zgarishlarni ochiq manbali omborga birlashtirishga kelganda katta muammo bo'lib qoldi, chunki ikkita ombor sinxronlashtirilmagan.
Ushbu modelni umumiy platformalar, kutubxonalar yoki infratuzilma loyihalari uchun to'liq xususiyatli maxsus veb-ilovalarga qaraganda amalga oshirish ancha oson. Bundan tashqari, ushbu model ochiq manba kodini birinchi kundan boshlab ishga tushiradigan loyihalar uchun juda mos keladi, ammo WhereHows butunlay ichki veb-ilova sifatida yaratilgan. Barcha ichki bog'liqliklarni butunlay yo'q qilish juda qiyin edi, shuning uchun biz ichki vilkani saqlashimiz kerak edi, lekin ichki vilkani saqlab qolish va asosan ochiq manbani ishlab chiqish to'liq ish bermadi.
Ikkinchi urinish: "Avval ichki"
**Ikkinchi urinish sifatida biz "ichki birinchi" rivojlanish modeliga o'tdik, bunda ko'p ishlanmalar uyda sodir bo'ladi va ochiq manba kodiga muntazam ravishda o'zgartirishlar kiritiladi. Ushbu model bizning foydalanish holatlarimiz uchun eng mos bo'lsa-da, u o'ziga xos muammolarga ega. Barcha farqlarni to'g'ridan-to'g'ri ochiq manba omboriga o'tkazish va keyin birlashma nizolarini keyinroq hal qilishga urinish - bu variant, ammo bu vaqt talab etadi. Ko'p hollarda ishlab chiquvchilar o'z kodlarini har safar ko'rib chiqqanlarida buni qilmaslikka harakat qilishadi. Natijada, bu kamroq tez-tez, to'plamlarda amalga oshiriladi va shuning uchun keyinchalik birlashma nizolarini hal qilishni qiyinlashtiradi.
Uchinchi marta u ishladi!
Yuqorida aytib o'tilgan ikkita muvaffaqiyatsiz urinishlar GitHub omborining uzoq vaqt davomida eskirganligiga olib keldi. Jamoa mahsulotning xususiyatlari va arxitekturasini yaxshilashda davom etdi, shuning uchun LinkedIn uchun WhereHows ning ichki versiyasi ochiq manba versiyasiga qaraganda ancha rivojlangan. U hatto yangi nomga ega edi - DataHub. Avvalgi muvaffaqiyatsiz urinishlar asosida jamoa kengaytiriladigan, uzoq muddatli yechim ishlab chiqishga qaror qildi.
Har qanday yangi ochiq kodli loyiha uchun LinkedIn’ning ochiq manbalar jamoasi loyiha modullari butunlay ochiq manbada ishlab chiqilgan rivojlanish modelini maslahat beradi va qo‘llab-quvvatlaydi. Versiyalangan artefaktlar umumiy omborga joylashtiriladi va keyin ichki LinkedIn artefaktiga qayta tekshiriladi. . Ushbu ishlab chiqish modeliga rioya qilish nafaqat ochiq manbadan foydalanadiganlar uchun yaxshi, balki yanada modulli, kengaytiriladigan va ulanadigan arxitekturaga olib keladi.
Biroq, DataHub kabi etuk dastur bu holatga erishish uchun katta vaqt talab qiladi. Bu, shuningdek, barcha ichki bog'liqliklar to'liq mavhum bo'lgunga qadar ochiq manbalardan to'liq ishlaydigan amalga oshirish imkoniyatini istisno qiladi. Shuning uchun biz ochiq manbali hissalarni tezroq va kamroq og'riq bilan amalga oshirishga yordam beradigan vositalarni ishlab chiqdik. Ushbu yechim metadata jamoasi (DataHub dasturchisi) va ochiq manbalar hamjamiyatiga foyda keltiradi. Keyingi bo'limlarda ushbu yangi yondashuv muhokama qilinadi.
Ochiq manbali nashriyotlarni avtomatlashtirish
Metadata jamoasining ochiq manbali DataHubga boʻlgan soʻnggi yondashuvi ichki kod bazasi va ochiq manba omborini avtomatik sinxronlashtiradigan vositani ishlab chiqishdan iborat. Ushbu asboblar to'plamining yuqori darajadagi xususiyatlariga quyidagilar kiradi:
- LinkedIn kodini ochiq manbadan sinxronlash, shunga o'xshash .
- Litsenziya sarlavhasini yaratish, shunga o'xshash .
- Ichki topshiriq jurnallaridan avtomatik ravishda ochiq kodli majburiy jurnallarni yarating.
- Ochiq manbali tuzilmalarni buzadigan ichki o'zgarishlarni oldini oling .
Quyidagi kichik bo'limlar yuqorida aytib o'tilgan qiziqarli muammolarga ega bo'lgan funktsiyalarni ko'rib chiqadi.
Manba kodini sinxronlashtirish
Yagona GitHub ombori boʻlgan DataHub’ning ochiq manbali versiyasidan farqli oʻlaroq, LinkedIn DataHub versiyasi bir nechta omborlar (ichki deb ataladi) birikmasidir. ). DataHub interfeysi, metadata modellari kutubxonasi, metadata ombori backend xizmati va oqim ishlari LinkedIn’ning alohida omborlarida joylashgan. Biroq, ochiq manba foydalanuvchilari uchun qulaylik yaratish uchun bizda DataHub ning ochiq manbali versiyasi uchun bitta ombor mavjud.
1-rasm: omborlar o'rtasida sinxronizatsiya LinkedIn DataHub va bitta ombor DataHub ochiq manba
Avtomatlashtirilgan yaratish, surish va tortish ish oqimlarini qo'llab-quvvatlash uchun bizning yangi vositamiz avtomatik ravishda har bir manba faylga mos keladigan fayl darajasidagi xaritalashni yaratadi. Biroq, asboblar to'plami dastlabki konfiguratsiyani talab qiladi va foydalanuvchilar quyida ko'rsatilganidek, yuqori darajadagi modul xaritasini taqdim etishlari kerak.
{
"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"
]
}Modul darajasidagi xaritalash oddiy JSON bo'lib, uning kalitlari ochiq manba omboridagi maqsadli modullar va qiymatlar LinkedIn omborlaridagi manba modullari ro'yxatidir. Ochiq manba omboridagi har qanday maqsadli modul istalgan sonli manba modullari bilan ta'minlanishi mumkin. Manba modullarida omborlarning ichki nomlarini ko'rsatish uchun foydalaning Bash uslubida. Modul darajasidagi xaritalash faylidan foydalanib, asboblar bog'langan kataloglardagi barcha fayllarni skanerlash orqali fayl darajasidagi xaritalash faylini yaratadi.
{
"${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,
}Fayl darajasining xaritasi asboblar tomonidan avtomatik ravishda yaratiladi; ammo, u foydalanuvchi tomonidan qo'lda ham yangilanishi mumkin. Bu LinkedIn manba faylini ochiq manba omboridagi faylga 1:1 oʻlchamdagi xaritalash. Fayl assotsiatsiyasini avtomatik yaratish bilan bog'liq bir nechta qoidalar mavjud:
- Ochiq manbadagi maqsadli modul uchun bir nechta manba modullari bo'lsa, nizolar paydo bo'lishi mumkin, masalan, bir xil , bir nechta manba modullarida mavjud. Mojarolarni hal qilish strategiyasi sifatida bizning vositalarimiz sukut bo'yicha "oxirgisi g'alaba qozonadi" variantiga mos keladi.
- "null" manba fayli ochiq manba omborining bir qismi emasligini anglatadi.
- Har bir ochiq manbadan yuborilgandan yoki chiqarib olingandan so'ng, ushbu xaritalash avtomatik ravishda yangilanadi va oniy rasm yaratiladi. Bu oxirgi harakatdan keyin manba kodidan qo'shimchalar va o'chirishlarni aniqlash uchun kerak.
Qabul qilish jurnallarini yaratish
Ochiq manba kodlari uchun majburiy jurnallar ham ichki omborlarning majburiy jurnallarini birlashtirish orqali avtomatik ravishda yaratiladi. Quyida bizning vositamiz tomonidan yaratilgan majburiyat jurnalining tuzilishini ko'rsatish uchun namunaviy majburiy jurnali keltirilgan. Majburiyat manba omborlarining qaysi versiyalari ushbu majburiyatda to'planganligini aniq ko'rsatadi va topshiriqlar jurnalining qisqacha mazmunini taqdim etadi. Buni tekshiring asboblar to'plamimiz tomonidan yaratilgan majburiy jurnalning haqiqiy misolidan foydalanish.
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.0Qaramlik testi
LinkedIn mavjud , bu ichki ko'p mahsulotga o'zgartirishlar bog'liq multiproduktlar yig'ilishini buzmasligini ta'minlashga yordam beradi. Ochiq manbali DataHub ombori ko‘p mahsulotli emas va u har qanday ko‘p mahsulotga bevosita bog‘liq bo‘la olmaydi, lekin ochiq manbali DataHub manba kodini oladigan ko‘p mahsulotli o‘ram yordamida biz ushbu qaramlik testidan foydalanishimiz mumkin. Shunday qilib, ochiq manbali DataHub omborini taʼminlovchi har qanday koʻp mahsulotning har qanday oʻzgarishi (keyinroq paydo boʻlishi mumkin) qobiq koʻp mahsulotida qurilish hodisasini ishga tushiradi. Shuning uchun, o'rash mahsulotini yaratishda muvaffaqiyatsizlikka uchragan har qanday o'zgarish asl mahsulotni amalga oshirishdan oldin sinovlardan o'tmaydi va qaytariladi.
Bu ochiq manba tuzilishini buzadigan va uni bajarish vaqtida aniqlaydigan har qanday ichki majburiyatlarning oldini olishga yordam beradigan foydali mexanizm. Busiz, qaysi ichki majburiyat ochiq kodli omborni yaratish muvaffaqiyatsizlikka uchraganligini aniqlash juda qiyin bo'lar edi, chunki biz DataHub ochiq manba omboriga ichki o'zgarishlarni to'playmiz.
Ochiq manba DataHub va bizning ishlab chiqarish versiyamiz o'rtasidagi farqlar
Shu paytgacha biz DataHub omborlarining ikkita versiyasini sinxronlashtirish bo‘yicha yechimimizni muhokama qildik, biroq biz hali ham birinchi navbatda ikki xil rivojlanish oqimiga ehtiyoj borligi sabablarini aytib o‘tmadik. Ushbu bo'limda biz DataHub ning ommaviy versiyasi va LinkedIn serverlaridagi ishlab chiqarish versiyasi o'rtasidagi farqlarni sanab o'tamiz va bu farqlarning sabablarini tushuntiramiz.
Mos kelmaslik manbalaridan biri bizning ishlab chiqarish versiyamiz LinkedIn's Offspring (LinkedIn'ning ichki qaramlik in'ektsiya tizimi) kabi hali ochiq manba bo'lmagan kodga bog'liqligi bilan bog'liq. O'smir ichki kod bazalarida keng qo'llaniladi, chunki bu dinamik konfiguratsiyani boshqarishning afzal usuli hisoblanadi. Lekin bu ochiq manba emas; shuning uchun biz ochiq manbali DataHubga ochiq manba muqobillarini topishimiz kerak edi.
Boshqa sabablar ham bor. Biz LinkedIn ehtiyojlari uchun metadata modeliga kengaytmalar yaratganimizda, bu kengaytmalar odatda LinkedIn uchun juda xos va boshqa muhitlarga bevosita taalluqli boʻlmasligi mumkin. Misol uchun, bizda ishtirokchi identifikatorlari va mos keladigan metama'lumotlarning boshqa turlari uchun juda aniq teglar mavjud. Shunday qilib, biz endi bu kengaytmalarni DataHub’ning ochiq kodli metadata modelidan chiqarib tashladik. Biz hamjamiyat bilan aloqada bo'lib, ularning ehtiyojlarini tushunar ekanmiz, kerak bo'lganda ushbu kengaytmalarning umumiy ochiq manba versiyalari ustida ishlaymiz.
Foydalanishning qulayligi va ochiq manbalar hamjamiyatiga moslashishning qulayligi DataHub-ning ikkita versiyasi o'rtasidagi ba'zi farqlarni ham ilhomlantirdi. Oqimlarni qayta ishlash infratuzilmasidagi farqlar bunga yaxshi misoldir. Garchi bizning ichki versiyamiz boshqariladigan oqimni qayta ishlash tizimidan foydalansa-da, biz ochiq manba versiyasi uchun o‘rnatilgan (mustaqil) oqimni qayta ishlashdan foydalanishni tanladik, chunki u boshqa infratuzilmaga bog‘liqlikni keltirib chiqarmaydi.
Farqning yana bir misoli - bir nechta GMS emas, balki ochiq kodli dasturda bitta GMS (Umumiy metadata do'koni) mavjud. GMA (Umumiy metadata arxitekturasi) DataHub uchun back-end arxitekturasining nomi, GMS esa GMA kontekstidagi metama’lumotlar omboridir. GMA juda moslashuvchan arxitektura boʻlib, har bir maʼlumot konstruksiyasini (masalan, maʼlumotlar toʻplami, foydalanuvchilar va h.k.) oʻzining metamaʼlumotlar doʻkoniga tarqatish yoki bir nechta maʼlumotlar konstruksiyalarini bitta metamaʼlumotlar doʻkonida saqlash imkonini beradi. GMS yangilandi. Foydalanish qulayligi uchun biz ochiq manba DataHub-da barcha turli ma'lumotlar konstruksiyalarini saqlaydigan yagona GMS nusxasini tanladik.
Ikki dastur o'rtasidagi farqlarning to'liq ro'yxati quyidagi jadvalda keltirilgan.
Mahsulot xususiyatlari
LinkedIn DataHub
Ochiq manbali DataHub
Qo'llab-quvvatlanadigan ma'lumotlar konstruktsiyalari
1) Maʼlumotlar toʻplami 2) Foydalanuvchilar 3) Koʻrsatkichlar 4) ML xususiyatlari 5) Diagrammalar 6) Boshqaruv paneli
1) Ma'lumotlar to'plami 2) Foydalanuvchilar
Ma'lumotlar to'plamlari uchun qo'llab-quvvatlanadigan metama'lumotlar manbalari
1) 2) Divan 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
Pub-sub
Birlashgan Kafka
Oqimni qayta ishlash
muvaffaq
Oʻrnatilgan (mustaqil)
Bog'liqlik kiritish va dinamik konfiguratsiya
LinkedIn avlodlari
Qurilish asboblari
Ligradle (LinkedIn ichki Gradle o'rami)
CI / CD
CRT (LinkedIn ichki CI/CD)
va
Metadata do'konlari
Tarqatilgan bir nechta GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Quyidagilar uchun yagona GMS: 1) Ma'lumotlar to'plami 2) Foydalanuvchilar
Docker konteynerlarida mikroservislar
bilan ilovalarni joylashtirish va tarqatishni soddalashtiradi . DataHub-dagi xizmatning har bir qismi ochiq manba, jumladan Kafka kabi infratuzilma komponentlari, , и , o'zining Docker tasviriga ega. Docker konteynerlarini tashkil qilish uchun biz foydalandik .
2-rasm: Arxitektura DataHub *ochiq manba**
Yuqoridagi rasmda DataHub ning yuqori darajadagi arxitekturasini ko'rishingiz mumkin. Infratuzilma komponentlaridan tashqari, u to'rt xil Docker konteyneriga ega:
datahub-gms: metama'lumotlarni saqlash xizmati
datahub-frontend: ilova , DataHub interfeysiga xizmat qiladi.
datahub-mce-consumer: ilova , bu metadata o'zgarishi hodisasi (MCE) oqimidan foydalanadi va metadata do'konini yangilaydi.
datahub-mae-consumer: ilova , bu metadata audit hodisalar oqimidan (MAE) foydalanadi va qidiruv indeksi va grafik ma'lumotlar bazasini yaratadi.
Ochiq manbalar ombori hujjatlari va turli xizmatlarning funktsiyalari haqida batafsil ma'lumotni o'z ichiga oladi.
DataHub-dagi CI/CD ochiq manba hisoblanadi
Ochiq manbali DataHub ombori foydalanadi uzluksiz integratsiya uchun va uzluksiz joylashtirish uchun. Ikkalasi ham yaxshi GitHub integratsiyasiga ega va ularni sozlash oson. Jamiyat yoki xususiy kompaniyalar tomonidan ishlab chiqilgan ochiq manba infratuzilmalarining aksariyati uchun (masalan, ), Docker tasvirlari hamjamiyat tomonidan foydalanish qulayligi uchun yaratilgan va Docker Hub-ga joylashtirilgan. Docker Hub-da topilgan har qanday Docker tasvirini oddiy buyruq bilan osongina ishlatish mumkin .
DataHub ochiq manba omboriga har bir topshiriq bilan, barcha Docker tasvirlari avtomatik ravishda quriladi va "eng so'nggi" teg bilan Docker Hub-ga joylashtiriladi. Agar Docker Hub ba'zilari bilan tuzilgan bo'lsa , ochiq manba omboridagi barcha teglar ham Docker Hub-da mos teg nomlari bilan chiqariladi.
DataHub-dan foydalanish
juda oddiy va uchta oddiy bosqichdan iborat:
- Ochiq manba omborini klonlash va tez boshlash uchun taqdim etilgan docker-compose skriptidan foydalanib, barcha Docker konteynerlarini docker-compose bilan ishga tushiring.
- Shuningdek, taqdim etilgan buyruq qatori vositasidan foydalanib, omborda taqdim etilgan namuna ma'lumotlarini yuklab oling.
- Brauzeringizda DataHub-ni ko'rib chiqing.
Faol kuzatilgan tez savollar uchun ham sozlangan. Foydalanuvchilar muammoni bevosita GitHub omborida ham yaratishi mumkin. Eng muhimi, barcha fikr-mulohazalar va takliflarni mamnuniyat bilan qabul qilamiz va qadrlaymiz!
Kelajak uchun rejalar
Hozirda ochiq manbali DataHub uchun har bir infratuzilma yoki mikroservis Docker konteyneri sifatida qurilgan va butun tizim yordamida tartibga solinadi. . Mashhurlik va keng tarqalganlikni hisobga olgan holda , biz ham yaqin kelajakda Kubernetes asosidagi yechimni taqdim qilmoqchimiz.
Shuningdek, biz DataHub-ni ommaviy bulut xizmatida joylashtirish uchun kalit taslim yechimni taqdim etishni rejalashtirmoqdamiz , yoki . Yaqinda LinkedIn-ning Azure-ga ko'chishi haqidagi e'lonni hisobga olsak, bu metadata jamoasining ichki ustuvorliklariga mos keladi.
Va nihoyat, DataHub alfasini baholagan va muammolarni aniqlash va hujjatlarni yaxshilashga yordam bergan ochiq manbalar hamjamiyatidagi DataHub-ni dastlabki qabul qiluvchilarga rahmat.
Manba: www.habr.com