Açıq Mənbə DataHub: LinkedIn Metadata Axtarış və Kəşf Platforması
Məlumata əsaslanan qərarlar qəbul etmək üçün böyük həcmdə məlumatlara güvənən hər bir şirkət üçün sizə lazım olan məlumatları tez tapmaq vacibdir. Bu, təkcə məlumat istifadəçilərinin (analitiklər, maşın öyrənməsi tərtibatçıları, məlumat alimləri və məlumat mühəndisləri daxil olmaqla) məhsuldarlığına təsir etmir, həm də keyfiyyətli maşın öyrənməsi (ML) boru kəmərindən asılı olan son məhsullara birbaşa təsir göstərir. Bundan əlavə, maşın öyrənmə platformalarının tətbiqi və ya qurulması tendensiyası təbii olaraq sual doğurur: xüsusiyyətləri, modelləri, ölçüləri, məlumat dəstlərini və s. daxili aşkar etmək üçün metodunuz nədir.
Bu yazıda açıq lisenziya altında məlumat mənbəyini necə dərc etdiyimizdən danışacağıq layihənin ilk günlərindən başlayaraq metadata axtarışı və kəşf platformamızda . LinkedIn öz DataHub versiyasını açıq mənbə versiyasından ayrı saxlayır. Biz nə üçün iki ayrı inkişaf mühitinə ehtiyacımız olduğunu izah etməklə başlayacağıq, sonra açıq mənbə WhereHow-dan istifadə etmək üçün ilkin yanaşmaları müzakirə edəcəyik və DataHub-ın daxili (istehsal) versiyasını aşağıdakı versiya ilə müqayisə edəcəyik. . Biz həmçinin hər iki deponu sinxronizasiya etmək üçün açıq mənbə yeniləmələrini itələmək və qəbul etmək üçün yeni avtomatlaşdırılmış həllimiz haqqında təfərrüatları paylaşacağıq. Nəhayət, açıq mənbə DataHub-dan istifadə etməyə necə başlamaq barədə təlimatları təqdim edəcəyik və onun arxitekturasını qısa şəkildə müzakirə edəcəyik.
WhereHow indi DataHub-dır!
LinkedIn-in metadata komandası daha əvvəl təqdim edildi (WhereHows-un davamçısı), LinkedIn-in axtarış və metadata kəşf platforması və onu açmaq üçün paylaşılan planlar. Bu elandan qısa müddət sonra biz DataHub-ın alfa versiyasını buraxdıq və onu cəmiyyətlə paylaşdıq. O vaxtdan bəri biz davamlı olaraq depoya töhfə vermişik və ən çox tələb olunan funksiyaları əlavə etmək və problemləri həll etmək üçün maraqlı istifadəçilərlə işləmişik. İndi rəsmi buraxılışı elan etməkdən məmnunuq .
Açıq mənbə yanaşmaları
LinkedIn-in verilənləri və haradan gəldiyini tapmaq üçün orijinal portalı olan WhereHows, daxili bir layihə olaraq başladı; metadata komandası onu açdı . O vaxtdan bəri komanda həmişə iki fərqli kod bazasını qoruyub saxlayır - biri açıq mənbə və digəri LinkedIn-in daxili istifadəsi üçün - çünki LinkedIn istifadə halları üçün hazırlanmış bütün məhsul xüsusiyyətləri ümumiyyətlə daha geniş auditoriyaya aid deyildi. Bundan əlavə, WhereHows-un açıq mənbə olmayan bəzi daxili asılılıqları (infrastruktur, kitabxanalar və s.) var. Sonrakı illərdə WhereHows bir çox iterasiya və inkişaf dövründən keçdi və bu, iki kod bazasını sinxronizasiyada saxlamağı böyük problemə çevirdi. Metadata komandası daxili və açıq mənbə inkişafını sinxronlaşdırmağa çalışmaq üçün illər ərzində müxtəlif yanaşmaları sınadı.
İlk cəhd: "Əvvəlcə mənbəni açın"
Biz əvvəlcə "öncə açıq mənbə" inkişaf modelini izlədik, burada ən çox inkişaf açıq mənbə deposunda baş verir və daxili yerləşdirmə üçün dəyişikliklər edilir. Bu yanaşmanın problemi kodun daxili olaraq tam nəzərdən keçirilməmişdən əvvəl həmişə GitHub-a göndərilməsidir. Açıq mənbə deposundan dəyişikliklər edilənə və yeni daxili yerləşdirmə edilənə qədər heç bir istehsal problemi tapa bilməyəcəyik. Zəif yerləşdirmə vəziyyətində, günahkarı müəyyən etmək də çox çətin idi, çünki dəyişikliklər partiyalar şəklində edildi.
Bundan əlavə, bu model sürətli təkrarlamalar tələb edən yeni funksiyalar hazırlayarkən komandanın məhsuldarlığını azaldıb, çünki o, bütün dəyişiklikləri əvvəlcə açıq mənbə deposuna, sonra isə daxili repozitoriyaya köçürməyə məcbur edib. Emal müddətini azaltmaq üçün tələb olunan düzəliş və ya dəyişiklik əvvəlcə daxili repozitoriyada edilə bilərdi, lakin iki depo sinxronizasiya olunmadığından həmin dəyişiklikləri yenidən açıq mənbə repozitoriyasına birləşdirməyə gəldikdə bu, böyük problemə çevrildi.
Bu modeli paylaşılan platformalar, kitabxanalar və ya infrastruktur layihələri üçün həyata keçirmək, tam xüsusiyyətli xüsusi veb tətbiqləri ilə müqayisədə daha asandır. Bundan əlavə, bu model ilk gündən açıq mənbəyə başlayan layihələr üçün idealdır, lakin WhereHows tamamilə daxili veb tətbiqi kimi qurulmuşdur. Bütün daxili asılılıqları tamamilə aradan qaldırmaq həqiqətən çətin idi, ona görə də biz daxili çəngəli saxlamalı olduq, lakin daxili çəngəli saxlamaq və əsasən açıq mənbəni inkişaf etdirmək heç də nəticə vermədi.
İkinci cəhd: "Əvvəlcə daxili"
**İkinci cəhd olaraq biz "daxili ilk" inkişaf modelinə keçdik, burada ən çox inkişaf şirkət daxilində baş verir və müntəzəm olaraq açıq mənbə kodunda dəyişikliklər edilir. Bu model bizim istifadə vəziyyətimiz üçün ən uyğun olsa da, onun özünəməxsus problemləri var. Bütün fərqləri birbaşa açıq mənbə anbarına köçürmək və sonra birləşmə münaqişələrini daha sonra həll etməyə çalışmaq bir seçimdir, lakin bu, çox vaxt aparır. Tərtibatçılar əksər hallarda kodlarını hər dəfə nəzərdən keçirəndə bunu etməməyə çalışırlar. Nəticə etibarı ilə, bu, daha az tez-tez, partiyalar şəklində həyata keçiriləcək və beləliklə, birləşmə münaqişələrinin sonradan həllini çətinləşdirir.
Üçüncü dəfə işlədi!
Yuxarıda qeyd olunan iki uğursuz cəhd, WhereHows GitHub repozitoriyasının uzun müddət köhnəlməsi ilə nəticələndi. Komanda məhsulun xüsusiyyətlərini və arxitekturasını təkmilləşdirməyə davam etdi ki, LinkedIn üçün WhereHows-un daxili versiyası açıq mənbə versiyasından daha təkmilləşdi. Onun hətta yeni adı var idi - DataHub. Əvvəlki uğursuz cəhdlərə əsaslanaraq, komanda genişləndirilə bilən, uzunmüddətli həll yolu hazırlamağa qərar verdi.
İstənilən yeni açıq mənbə layihəsi üçün LinkedIn-in açıq mənbə komandası layihənin modullarının tamamilə açıq mənbədə işləndiyi inkişaf modelini məsləhət görür və dəstəkləyir. Versiyalaşdırılmış artefaktlar ictimai depoya yerləşdirilir və sonra daxili LinkedIn artefaktına yenidən yoxlanılır. . Bu inkişaf modelini izləmək yalnız açıq mənbədən istifadə edənlər üçün yaxşı deyil, həm də daha modul, genişləndirilə bilən və qoşula bilən bir arxitektura ilə nəticələnir.
Bununla belə, DataHub kimi yetkin arxa proqram bu vəziyyətə çatmaq üçün xeyli vaxt tələb edəcək. Bu, həm də bütün daxili asılılıqlar tam mücərrədləşdirilməmişdən əvvəl tam işlək həyata keçirmənin açıq mənbə imkanını istisna edir. Buna görə də biz açıq mənbə töhfələrini daha sürətli və daha az ağrı ilə etməyə kömək edən alətlər hazırlamışıq. Bu həll həm metadata komandasına (DataHub tərtibçisi), həm də açıq mənbə icmasına fayda verir. Növbəti bölmələrdə bu yeni yanaşma müzakirə olunacaq.
Açıq Mənbəli Nəşriyyatın Avtomatlaşdırılması
Metadata komandasının açıq mənbə DataHub-a ən son yanaşması daxili kod bazası və açıq mənbə deposunu avtomatik sinxronlaşdıran alət hazırlamaqdır. Bu alət dəstinin yüksək səviyyəli xüsusiyyətlərinə aşağıdakılar daxildir:
- LinkedIn kodunu açıq mənbə ilə sinxronlaşdırın, oxşar .
- Lisenziya başlığının yaradılması, buna bənzər .
- Daxili icra qeydlərindən avtomatik olaraq açıq mənbə qeydləri yaradın.
- Açıq mənbə quruluşlarını pozan daxili dəyişikliklərin qarşısını alın .
Aşağıdakı alt bölmələr maraqlı problemləri olan yuxarıda qeyd olunan funksiyaları araşdıracaq.
Mənbə kodu sinxronizasiyası
Tək GitHub repozitoriyası olan DataHub-un açıq mənbə versiyasından fərqli olaraq, DataHub-un LinkedIn versiyası çoxsaylı depoların (daxili olaraq adlandırılır) birləşməsidir. ). DataHub interfeysi, metadata model kitabxanası, metadata anbarı backend xidməti və axın işləri LinkedIn-də ayrıca depolarda yerləşir. Bununla belə, açıq mənbə istifadəçiləri üçün işi asanlaşdırmaq üçün DataHub-ın açıq mənbə versiyası üçün tək repozitorumuz var.
Şəkil 1: Repozitoriyalar arasında sinxronizasiya LinkedIn DataHub və tək depo DataHub açıq mənbə
Avtomatlaşdırılmış qurma, itələmə və çəkmə iş axınlarını dəstəkləmək üçün yeni alətimiz avtomatik olaraq hər bir mənbə faylına uyğun olan fayl səviyyəli xəritəni yaradır. Bununla belə, alətlər dəsti ilkin konfiqurasiya tələb edir və istifadəçilər aşağıda göstərildiyi kimi yüksək səviyyəli modul xəritəsini təqdim etməlidirlər.
{
"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 səviyyəsində xəritəçəkmə sadə JSON-dur, onun açarları açıq mənbə deposundakı hədəf modullar və dəyərlər LinkedIn repozitoriyalarındakı mənbə modullarının siyahısıdır. Açıq mənbə deposundakı istənilən hədəf modul istənilən sayda mənbə modulu ilə qidalana bilər. Mənbə modullarında depoların daxili adlarını göstərmək üçün istifadə edin Bash üslubunda. Modul səviyyəli xəritələşdirmə faylından istifadə edərək, alətlər əlaqəli qovluqlardakı bütün faylları skan edərək fayl səviyyəli xəritələşdirmə faylı yaradır.
{
"${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 səviyyəsinin xəritəsi avtomatik olaraq alətlər tərəfindən yaradılır; lakin istifadəçi tərəfindən əl ilə də yenilənə bilər. Bu, LinkedIn mənbə faylının açıq mənbə deposundakı fayla 1:1 nisbətində təsviridir. Fayl assosiasiyalarının bu avtomatik yaradılması ilə bağlı bir neçə qayda var:
- Açıq mənbədə bir hədəf modul üçün bir neçə mənbə modulu olduqda, münaqişələr yarana bilər, məsələn, eyni , birdən çox mənbə modulunda mövcuddur. Münaqişənin həlli strategiyası olaraq alətlərimiz defolt olaraq “sonuncu qalib gəlir” seçiminə uyğundur.
- "null" mənbə faylının açıq mənbə deposunun bir hissəsi olmadığını bildirir.
- Hər açıq mənbə təqdim etməsindən və ya çıxarılmasından sonra bu xəritələmə avtomatik olaraq yenilənir və snapshot yaradılır. Bu, son hərəkətdən sonra mənbə kodundan əlavə və silinmələri müəyyən etmək üçün lazımdır.
Öhdəlik qeydlərinin yaradılması
Açıq mənbə öhdəliyi üçün öhdəçilik qeydləri də daxili repozitoriyaların icra qeydlərini birləşdirməklə avtomatik olaraq yaradılır. Aşağıda alətimiz tərəfindən yaradılan öhdəlik qeydinin strukturunu göstərmək üçün nümunə öhdəçilik jurnalı verilmişdir. Öhdəlik, mənbə anbarlarının hansı versiyalarının həmin öhdəlikdə paketləndiyini aydın şəkildə göstərir və öhdəlik jurnalının xülasəsini təqdim edir. Bunu yoxlayın alət dəstimiz tərəfindən yaradılan öhdəçilik jurnalının real nümunəsindən istifadə etməklə.
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.0Asılılıq testi
LinkedIn var , bu, daxili çoxməhsulda dəyişikliklərin asılı çoxməhsulların birləşməsini pozmamasını təmin edir. Açıq mənbəli DataHub repozitoriyası çoxməhsul deyil və o, hər hansı bir çox məhsuldan birbaşa asılı ola bilməz, lakin açıq mənbəli DataHub mənbə kodunu gətirən çox məhsullu paketin köməyi ilə biz hələ də bu asılılıq testindən istifadə edə bilərik. Beləliklə, açıq mənbəli DataHub repozitoriyasını qidalandıran hər hansı bir çoxməhsulda hər hansı dəyişiklik (sonradan məruz qala bilər) qabıq multiməhsulunda qurulma hadisəsini tetikler. Buna görə də, qablaşdırma məhsulu yaratmaqda uğursuz olan hər hansı dəyişiklik orijinal məhsulu təqdim etməzdən əvvəl sınaqlardan keçmir və geri qaytarılır.
Bu, açıq mənbə quruluşunu pozan hər hansı daxili öhdəliyin qarşısını almağa kömək edən faydalı mexanizmdir və onu icra zamanı aşkar edir. Bu olmadan, açıq mənbə repozitoriyasının qurulmasının uğursuzluğuna hansı daxili öhdəliyin səbəb olduğunu müəyyən etmək olduqca çətin olardı, çünki biz DataHub açıq mənbə deposuna daxili dəyişiklikləri toplu şəkildə həyata keçiririk.
Açıq mənbə DataHub ilə istehsal versiyamız arasındakı fərqlər
Bu nöqtəyə qədər biz DataHub repozitoriyalarının iki versiyasını sinxronlaşdırmaq üçün həll yollarımızı müzakirə etdik, lakin biz hələ də ilk növbədə iki fərqli inkişaf axınına ehtiyacımızın səbəblərini açıqlamamışıq. Bu bölmədə DataHub-ın ictimai versiyası ilə LinkedIn serverlərində istehsal versiyası arasındakı fərqləri sadalayacaq və bu fərqlərin səbəblərini izah edəcəyik.
Uyğunsuzluğun bir mənbəyi istehsal versiyamızın LinkedIn-in Övladları (LinkedIn-in daxili asılılıq inyeksiya çərçivəsi) kimi hələ açıq mənbə olmayan koddan asılılıqları olmasından irəli gəlir. Nəsil daxili kod bazalarında geniş istifadə olunur, çünki bu, dinamik konfiqurasiyanın idarə edilməsi üçün üstünlük verilən üsuldur. Amma açıq mənbə deyil; ona görə də açıq mənbə DataHub-a açıq mənbə alternativləri tapmalı olduq.
Başqa səbəblər də var. LinkedIn-in ehtiyacları üçün metadata modelinə genişlənmələr yaratdığımız üçün bu genişləndirmələr adətən LinkedIn-ə çox xasdır və birbaşa digər mühitlərə tətbiq olunmaya bilər. Məsələn, iştirakçı ID-ləri və digər uyğun metadata növləri üçün çox xüsusi etiketlərimiz var. Beləliklə, biz indi bu genişləndirmələri DataHub-un açıq mənbəli metadata modelindən çıxardıq. İcma ilə əlaqə saxladıqca və onların ehtiyaclarını başa düşdükcə, lazım olduqda bu genişləndirmələrin ümumi açıq mənbə versiyaları üzərində işləyəcəyik.
İstifadə asanlığı və açıq mənbə icması üçün asan uyğunlaşma DataHub-ın iki versiyası arasındakı bəzi fərqləri də ilhamlandırdı. Axın emalı infrastrukturundakı fərqlər bunun yaxşı nümunəsidir. Daxili versiyamız idarə olunan axın emal çərçivəsindən istifadə etsə də, biz açıq mənbə versiyası üçün daxili (müstəqil) axın emalından istifadə etməyi seçdik, çünki o, başqa bir infrastruktur asılılığı yaratmağın qarşısını alır.
Fərqin başqa bir nümunəsi, birdən çox GMS-dən daha çox açıq mənbə tətbiqində tək bir GMS-in (Ümumiləşdirilmiş Metadata Mağazası) olmasıdır. GMA (Ümumiləşdirilmiş Metadata Architecture) DataHub üçün back-end arxitekturasının adıdır və GMS GMA kontekstində metadata anbarıdır. GMA çox çevik bir arxitekturadır ki, hər bir məlumat konstruksiyasını (məsələn, verilənlər dəstləri, istifadəçilər və s.) öz metadata anbarına paylamağa və ya bir metadata anbarında birdən çox məlumat konstruksiyasını saxlamağa imkan verir ki, reyestrdə verilənlər strukturunun xəritələşdirilməsini ehtiva edir. GMS yenilənir. İstifadə rahatlığı üçün biz açıq mənbə DataHub-da bütün müxtəlif məlumat konstruksiyalarını saxlayan tək GMS nümunəsini seçdik.
İki tətbiq arasındakı fərqlərin tam siyahısı aşağıdakı cədvəldə verilmişdir.
Product Features
LinkedIn DataHub
Açıq Mənbə DataHub
Dəstəklənən Məlumat Konstruksiyaları
1) Məlumat dəstləri 2) İstifadəçilər 3) Metriklər 4) ML Xüsusiyyətləri 5) Diaqramlar 6) İdarə Panelləri
1) Datasets 2) İstifadəçilər
Datasets üçün dəstəklənən metadata mənbələri
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
Qarışıq Kafka
Axın Emalı
Managed
Daxili (müstəqil)
Asılılıq Enjeksiyonu və Dinamik Konfiqurasiya
LinkedIn Övladları
Quraşdırma Alətləri
Ligradle (LinkedIn daxili Gradle sarğısı)
CI / CD
CRT (LinkedIn daxili CI/CD)
və
Metadata Mağazaları
Paylanmış çoxsaylı GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Üçün tək GMS: 1) Datasets 2) İstifadəçilər
Docker konteynerlərində mikroservislər
ilə tətbiqin yerləşdirilməsini və paylanmasını asanlaşdırır . DataHub-da xidmətin hər bir hissəsi açıq mənbədir, o cümlədən Kafka kimi infrastruktur komponentləri, , и , öz Docker təsvirinə malikdir. Docker konteynerlərini təşkil etmək üçün istifadə etdik .
Şəkil 2: Memarlıq DataHub *açıq mənbə**
Yuxarıdakı şəkildə DataHub-un yüksək səviyyəli arxitekturasını görə bilərsiniz. İnfrastruktur komponentləri ilə yanaşı, dörd fərqli Docker konteynerinə malikdir:
datahub-gms: metadata saxlama xidməti
datahub-frontend: proqram , DataHub interfeysinə xidmət edir.
datahub-mce-consumer: proqram , metadata dəyişdirmə hadisəsi (MCE) axınından istifadə edir və metadata anbarını yeniləyir.
datahub-mae-istehlakçı: proqram , metadata audit hadisə axınından (MAE) istifadə edir və axtarış indeksi və qrafik verilənlər bazası yaradır.
Açıq mənbə depo sənədləri və müxtəlif xidmətlərin funksiyaları haqqında daha ətraflı məlumatları ehtiva edir.
DataHub-da CI/CD açıq mənbədir
Açıq mənbə DataHub repozitoriyası istifadə edir davamlı inteqrasiya üçün və davamlı yerləşdirmə üçün. Hər ikisi yaxşı GitHub inteqrasiyasına malikdir və qurmaq asandır. İcma və ya özəl şirkətlər tərəfindən hazırlanmış açıq mənbə infrastrukturunun əksəriyyəti üçün (məs. ), Docker şəkilləri cəmiyyət tərəfindən istifadənin asanlığı üçün yaradılır və Docker Hub-da yerləşdirilir. Docker Hub-da tapılan istənilən Docker təsviri sadə bir əmrlə asanlıqla istifadə edilə bilər .
DataHub açıq mənbə repozitoriyasına hər bir öhdəlik götürdükdə, bütün Docker şəkilləri avtomatik olaraq qurulur və "ən son" teqlə Docker Hub-da yerləşdirilir. Docker Hub bəziləri ilə konfiqurasiya olunarsa , açıq mənbə deposundakı bütün teqlər də Docker Hub-da müvafiq teq adları ilə buraxılır.
DataHub-dan istifadə
çox sadədir və üç sadə addımdan ibarətdir:
- Açıq mənbə anbarını klonlayın və sürətli bir başlanğıc üçün təqdim edilmiş docker-compose skriptindən istifadə edərək bütün Docker konteynerlərini docker-compose ilə işlədin.
- Təqdim olunan əmr satırı alətindən istifadə edərək, repozitoriyada təqdim olunan nümunə məlumatları endirin.
- Brauzerinizdə DataHub-a baxın.
Aktiv İzlənir həmçinin sürətli suallar üçün konfiqurasiya edilmişdir. İstifadəçilər həmçinin GitHub repozitoriyasında problem yarada bilərlər. Ən əsası, biz bütün rəy və təklifləri alqışlayırıq və qiymətləndiririk!
Gələcək üçün planlar
Hal-hazırda, açıq mənbə DataHub üçün hər bir infrastruktur və ya mikroservis Docker konteyneri kimi qurulub və bütün sistem istifadə edərək idarə olunur. . Populyarlığı və geniş yayılmasını nəzərə alaraq , biz də yaxın gələcəkdə Kubernetes əsaslı həll təqdim etmək istərdik.
Biz həmçinin DataHub-u ictimai bulud xidmətində yerləşdirmək üçün açar təslim həll təqdim etməyi planlaşdırırıq , və ya . LinkedIn-in Azure-a miqrasiyasının son elanını nəzərə alsaq, bu, metadata komandasının daxili prioritetləri ilə uyğunlaşacaq.
Nəhayət, açıq mənbə icmasında DataHub alfalarını qiymətləndirən və problemlərin müəyyən edilməsinə və sənədlərin təkmilləşdirilməsinə kömək edən bütün DataHub-u ilk tətbiq edənlərə təşəkkür edirik.
Mənbə: www.habr.com