Open Source DataHub: Platforma de căutare și descoperire a metadatelor LinkedIn
Găsirea rapidă a datelor de care aveți nevoie este esențială pentru orice companie care se bazează pe cantități mari de date pentru a lua decizii bazate pe date. Acest lucru nu numai că afectează productivitatea utilizatorilor de date (inclusiv analiști, dezvoltatori de învățare automată, cercetători de date și ingineri de date), dar are și un impact direct asupra produselor finale care depind de o conductă de învățare automată (ML) de calitate. În plus, tendința de a implementa sau construi platforme de învățare automată ridică în mod firesc întrebarea: care este metoda dvs. de descoperire internă a caracteristicilor, modelelor, metricilor, seturilor de date etc.
În acest articol vom vorbi despre cum am publicat o sursă de date sub o licență deschisă în platforma noastră de căutare și descoperire a metadatelor, începând din primele zile ale proiectului . LinkedIn își menține propria versiune de DataHub separat de versiunea open source. Vom începe prin a explica de ce avem nevoie de două medii de dezvoltare separate, apoi vom discuta despre abordările timpurii ale utilizării sursei deschise WhereHows și vom compara versiunea noastră internă (de producție) a DataHub cu versiunea de pe . De asemenea, vom împărtăși detalii despre noua noastră soluție automată pentru împingerea și primirea de actualizări open source pentru a menține ambele depozite sincronizate. În cele din urmă, vom oferi instrucțiuni despre cum să începeți să utilizați DataHub open source și vom discuta pe scurt arhitectura acestuia.
WhereHows este acum un DataHub!
Echipa de metadate a LinkedIn a prezentat anterior (succesorul WhereHows), platforma de căutare și descoperire a metadatelor LinkedIn și planuri comune de deschidere. La scurt timp după acest anunț, am lansat o versiune alfa a DataHub și am distribuit-o comunității. De atunci, am contribuit continuu la depozit și am lucrat cu utilizatorii interesați pentru a adăuga cele mai solicitate funcții și pentru a rezolva probleme. Acum suntem încântați să anunțăm lansarea oficială .
Abordări cu sursă deschisă
WhereHows, portalul original LinkedIn pentru găsirea datelor și de unde provin acestea, a început ca un proiect intern; echipa de metadate a deschis-o . De atunci, echipa a menținut întotdeauna două baze de cod diferite – una pentru sursă deschisă și una pentru uz intern al LinkedIn – deoarece nu toate caracteristicile produsului dezvoltate pentru cazurile de utilizare LinkedIn au fost în general aplicabile unui public mai larg. În plus, WhereHows are unele dependențe interne (infrastructură, biblioteci etc.) care nu sunt open source. În anii care au urmat, WhereHows a trecut prin multe iterații și cicluri de dezvoltare, făcând ca menținerea celor două baze de cod sincronizate să fie o mare provocare. Echipa de metadate a încercat diferite abordări de-a lungul anilor pentru a încerca să mențină sincronizate dezvoltarea internă și open source.
Prima încercare: „Open source întâi”
Inițial am urmat un model de dezvoltare „în primul rând open source”, în care majoritatea dezvoltării are loc într-un depozit open source și se fac modificări pentru implementarea internă. Problema cu această abordare este că codul este întotdeauna trimis mai întâi în GitHub înainte de a fi revizuit complet intern. Până când nu se fac modificări din depozitul open source și nu se face o nouă implementare internă, nu vom găsi probleme de producție. În caz de desfășurare proastă, a fost, de asemenea, foarte dificil să se determine vinovatul deoarece modificările au fost făcute în loturi.
În plus, acest model a redus productivitatea echipei la dezvoltarea de noi funcții care necesitau iterații rapide, deoarece a forțat ca toate modificările să fie mai întâi împinse într-un depozit cu sursă deschisă și apoi către un depozit intern. Pentru a reduce timpul de procesare, reparația sau modificarea necesară ar putea fi făcută mai întâi în depozitul intern, dar aceasta a devenit o problemă uriașă când a fost vorba de îmbinarea acestor modificări înapoi în depozitul open source, deoarece cele două depozite nu erau sincronizate.
Acest model este mult mai ușor de implementat pentru platforme partajate, biblioteci sau proiecte de infrastructură decât pentru aplicații web personalizate cu funcții complete. În plus, acest model este ideal pentru proiectele care încep open source din prima zi, dar WhereHows a fost construit ca o aplicație web complet internă. A fost cu adevărat dificil să abstragem complet toate dependențele interne, așa că trebuia să păstrăm furk-ul intern, dar păstrarea furk-ului intern și dezvoltarea în mare parte open source nu prea a funcționat.
A doua încercare: „Primul interior”
**Ca o a doua încercare, am trecut la un model de dezvoltare „în primul rând intern”, în care majoritatea dezvoltării are loc în interior și se fac modificări la codul open source în mod regulat. Deși acest model este cel mai potrivit pentru cazul nostru de utilizare, are probleme inerente. Împingerea directă a tuturor diferențelor către depozitul open source și apoi încercarea de a rezolva conflictele de îmbinare mai târziu este o opțiune, dar necesită mult timp. În majoritatea cazurilor, dezvoltatorii încearcă să nu facă acest lucru de fiecare dată când își revizuiesc codul. Ca urmare, acest lucru se va face mult mai rar, în loturi, și astfel este mai dificilă rezolvarea conflictelor de îmbinare mai târziu.
A treia oară a funcționat!
Cele două încercări eșuate menționate mai sus au dus la ca depozitul WhereHows GitHub să rămână neactualizat pentru o lungă perioadă de timp. Echipa a continuat să îmbunătățească caracteristicile și arhitectura produsului, astfel încât versiunea internă a WhereHows pentru LinkedIn a devenit mai avansată decât versiunea open source. A avut chiar un nume nou - DataHub. Pe baza încercărilor eșuate anterioare, echipa a decis să dezvolte o soluție scalabilă, pe termen lung.
Pentru orice nou proiect open source, echipa open source a LinkedIn consiliază și susține un model de dezvoltare în care modulele proiectului sunt dezvoltate în întregime în open source. Artefactele cu versiuni sunt implementate într-un depozit public și apoi verificate înapoi într-un artefact intern LinkedIn folosind . Urmărirea acestui model de dezvoltare nu este bună numai pentru cei care folosesc sursa deschisă, dar are ca rezultat și o arhitectură mai modulară, extensibilă și conectabilă.
Cu toate acestea, o aplicație back-end matură, cum ar fi DataHub, va necesita o perioadă semnificativă de timp pentru a ajunge la această stare. Acest lucru exclude, de asemenea, posibilitatea unei surse deschise pentru o implementare complet funcțională înainte ca toate dependențele interne să fie complet abstractizate. De aceea, am dezvoltat instrumente care ne ajută să facem contribuții open source mai rapid și cu mult mai puțin durere. Această soluție aduce beneficii atât echipei de metadate (dezvoltator DataHub), cât și comunității open source. Următoarele secțiuni vor discuta despre această nouă abordare.
Automatizarea publicării cu sursă deschisă
Cea mai recentă abordare a echipei Metadate față de DataHub open source este de a dezvolta un instrument care sincronizează automat baza de cod intern și depozitul open source. Caracteristicile de nivel înalt ale acestui set de instrumente includ:
- Sincronizați codul LinkedIn cu/de la sursă deschisă, similar .
- Generarea antetului de licență, similar cu .
- Generați automat jurnalele de comitere open source din jurnale de comitere interne.
- Preveniți modificările interne care întrerup construirea open source .
Următoarele subsecțiuni vor aprofunda în funcțiile menționate mai sus care au probleme interesante.
Sincronizarea codului sursă
Spre deosebire de versiunea open source a DataHub, care este un singur depozit GitHub, versiunea LinkedIn a DataHub este o combinație de mai multe depozite (numite intern ). Interfața DataHub, biblioteca de modele de metadate, serviciul de backend al depozitului de metadate și joburile de streaming se află în depozite separate de pe LinkedIn. Cu toate acestea, pentru a facilita utilizatorii open source, avem un singur depozit pentru versiunea open source a DataHub.
Figura 1: Sincronizarea între depozite LinkedIn DataHub și un singur depozit DataHub sursa deschisa
Pentru a sprijini fluxurile de lucru automate de build, push și pull, noul nostru instrument creează automat o mapare la nivel de fișier corespunzătoare fiecărui fișier sursă. Cu toate acestea, setul de instrumente necesită o configurare inițială, iar utilizatorii trebuie să furnizeze o mapare a modulului la nivel înalt, așa cum se arată mai jos.
{
"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"
]
}Maparea la nivel de modul este un simplu JSON ale cărui chei sunt modulele țintă din depozitul open source, iar valorile sunt lista modulelor sursă din depozitele LinkedIn. Orice modul țintă dintr-un depozit open source poate fi alimentat de orice număr de module sursă. Pentru a indica numele interne ale depozitelor din modulele sursă, utilizați în stilul Bash. Folosind un fișier de mapare la nivel de modul, instrumentele creează un fișier de mapare la nivel de fișier prin scanarea tuturor fișierelor din directoarele asociate.
{
"${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,
}Maparea la nivel de fișier este creată automat de instrumente; cu toate acestea, poate fi actualizat și manual de către utilizator. Aceasta este o mapare 1:1 a unui fișier sursă LinkedIn la un fișier din depozitul open source. Există mai multe reguli asociate cu această creare automată de asocieri de fișiere:
- În cazul mai multor module sursă pentru un modul țintă în sursă deschisă, pot apărea conflicte, de ex , existent în mai mult de un modul sursă. Ca strategie de soluționare a conflictelor, instrumentele noastre folosesc implicit opțiunea „ultimul câștigă”.
- „null” înseamnă că fișierul sursă nu face parte din depozitul open source.
- După fiecare trimitere sau extragere open source, această mapare este actualizată automat și este creat un instantaneu. Acest lucru este necesar pentru a identifica completările și ștergerile din codul sursă de la ultima acțiune.
Crearea jurnalelor de comitere
Jurnalele de comitere pentru comiterile open source sunt, de asemenea, generate automat prin îmbinarea jurnalelor de comitere ale depozitelor interne. Mai jos este un exemplu de jurnal de comitere pentru a arăta structura jurnalului de comitere generat de instrumentul nostru. Un commit indică în mod clar care versiuni ale depozitelor sursă sunt împachetate în acel commit și oferă un rezumat al jurnalului de comitere. Verifică-l pe acesta folosind un exemplu real de jurnal de comitere generat de setul nostru de instrumente.
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.0Testarea dependenței
LinkedIn are , care ajută la asigurarea faptului că modificările aduse unui produs multiplu intern nu distrug ansamblul multiproduselor dependente. Depozitul DataHub cu sursă deschisă nu este multi-produs și nu poate fi o dependență directă a unui produs multiplu, dar cu ajutorul unui wrapper cu mai multe produse care preia codul sursă DataHub open source, putem folosi în continuare această testare a dependenței. Astfel, orice modificare (care poate fi expusă ulterior) la oricare dintre produsele multiple care alimentează depozitul DataHub open source declanșează un eveniment de compilare în multiprodusul shell. Prin urmare, orice modificare care nu reușește să construiască un produs de ambalare eșuează testele înainte de comiterea produsului original și este anulată.
Acesta este un mecanism util care ajută la prevenirea oricărei comenzi interne care rupe versiunea open source și o detectează la momentul comiterii. Fără aceasta, ar fi destul de dificil să se determine ce comitere internă a cauzat eșuarea construcției depozitului open source, deoarece procesăm modificări interne în depozitul open source DataHub.
Diferențele dintre DataHub open source și versiunea noastră de producție
Până în acest moment, am discutat despre soluția noastră pentru sincronizarea a două versiuni de depozite DataHub, dar încă nu am subliniat motivele pentru care avem nevoie de două fluxuri de dezvoltare diferite în primul rând. În această secțiune, vom enumera diferențele dintre versiunea publică a DataHub și versiunea de producție pe serverele LinkedIn și vom explica motivele acestor diferențe.
O sursă de discrepanță provine din faptul că versiunea noastră de producție are dependențe de cod care nu este încă open source, cum ar fi LinkedIn's Offspring (cadru de injecție de dependență intern al LinkedIn). Offspring este utilizat pe scară largă în bazele de cod interne, deoarece este metoda preferată pentru gestionarea configurației dinamice. Dar nu este open source; așa că trebuia să găsim alternative open source la DataHub open source.
Există și alte motive. Pe măsură ce creăm extensii la modelul de metadate pentru nevoile LinkedIn, aceste extensii sunt de obicei foarte specifice LinkedIn și este posibil să nu se aplice direct altor medii. De exemplu, avem etichete foarte specifice pentru ID-urile participanților și alte tipuri de metadate potrivite. Deci, am exclus acum aceste extensii din modelul de metadate open source al DataHub. Pe măsură ce ne angajăm cu comunitatea și înțelegem nevoile acestora, vom lucra la versiuni open source comune ale acestor extensii acolo unde este necesar.
Ușurința de utilizare și adaptarea mai ușoară pentru comunitatea open source au inspirat, de asemenea, unele dintre diferențele dintre cele două versiuni de DataHub. Diferențele în infrastructura de procesare a fluxului sunt un bun exemplu în acest sens. Deși versiunea noastră internă folosește un cadru de procesare a fluxului gestionat, am ales să folosim procesarea fluxului încorporată (autonomă) pentru versiunea open source, deoarece evită crearea unei alte dependențe de infrastructură.
Un alt exemplu al diferenței este acela de a avea un singur GMS (Magazin de metadate generalizate) într-o implementare open source, mai degrabă decât mai multe GMS-uri. GMA (Generalized Metadata Architecture) este numele arhitecturii back-end pentru DataHub, iar GMS este depozitul de metadate în contextul GMA. GMA este o arhitectură foarte flexibilă care vă permite să distribuiți fiecare construcție de date (de exemplu, seturi de date, utilizatori etc.) în propriul magazin de metadate sau să stocați mai multe constructe de date într-un singur depozit de metadate, atâta timp cât registrul care conține maparea structurii de date în GMS este actualizat. Pentru ușurință în utilizare, am ales o singură instanță GMS care stochează toate constructele de date diferite în DataHub open source.
O listă completă a diferențelor dintre cele două implementări este dată în tabelul de mai jos.
Caracteristici produs
LinkedIn DataHub
DataHub cu sursă deschisă
Construcții de date acceptate
1) Seturi de date 2) Utilizatori 3) Valori 4) Caracteristici ML 5) Diagrame 6) Tablouri de bord
1) Seturi de date 2) Utilizatori
Surse de metadate acceptate pentru seturile de date
1) 2) Baza canapea 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Kafka confluent
Procesarea fluxului
Gestionat
Încorporat (autonom)
Injecție de dependență și configurație dinamică
LinkedIn Offspring
Construiți scule
Ligradle (învelișul intern Gradle al LinkedIn)
CI / CD
CRT (CI/CD intern LinkedIn)
și
Magazine de metadate
Distribuit mai multe GMS: 1) Set de date GMS 2) GMS utilizator 3) GMS metric 4) Caracteristică GMS 5) Diagramă/Tablou de bord GMS
Unic GMS pentru: 1) Seturi de date 2) Utilizatori
Microservicii în containerele Docker
simplifică implementarea și distribuirea aplicațiilor cu . Fiecare parte a serviciului din DataHub este open source, inclusiv componente de infrastructură precum Kafka, , и , are propria sa imagine Docker. Pentru a orchestra containerele Docker pe care le-am folosit .
Figura 2: Arhitectură DataHub *sursa deschisa**
Puteți vedea arhitectura de nivel înalt a DataHub în imaginea de mai sus. Pe lângă componentele de infrastructură, are patru containere Docker diferite:
datahub-gms: serviciu de stocare a metadatelor
datahub-frontend: aplicație , care servește interfața DataHub.
datahub-mce-consumer: aplicație , care utilizează fluxul de evenimente de modificare a metadatelor (MCE) și actualizează depozitul de metadate.
datahub-mae-consumer: aplicație , care utilizează un flux de evenimente de audit al metadatelor (MAE) și creează un index de căutare și o bază de date grafice.
Documentația de depozit open source și conțin informații mai detaliate despre funcțiile diferitelor servicii.
CI/CD de pe DataHub este open source
Depozitul DataHub cu sursă deschisă îl utilizează pentru integrare continuă şi pentru desfășurare continuă. Ambele au o bună integrare GitHub și sunt ușor de configurat. Pentru majoritatea infrastructurii open source dezvoltate de comunitate sau companii private (de ex. ), Imaginile Docker sunt create și implementate în Docker Hub pentru a fi ușor de utilizat de către comunitate. Orice imagine Docker găsită în Docker Hub poate fi utilizată cu ușurință cu o comandă simplă .
Cu fiecare angajare în depozitul cu sursă deschisă DataHub, toate imaginile Docker sunt create și implementate automat în Docker Hub cu cea mai recentă etichetă. Dacă Docker Hub este configurat cu unele , toate etichetele din depozitul open source sunt, de asemenea, lansate cu nume de etichete corespunzătoare în Docker Hub.
Folosind DataHub
este foarte simplu și constă din trei pași simpli:
- Clonează depozitul open source și rulează toate containerele Docker cu docker-compose folosind scriptul docker-compose furnizat pentru o pornire rapidă.
- Descărcați eșantionul de date furnizate în depozit folosind instrumentul de linie de comandă care este, de asemenea, furnizat.
- Răsfoiți DataHub în browserul dvs.
Urmărit activ configurat și pentru întrebări rapide. De asemenea, utilizatorii pot crea probleme direct în depozitul GitHub. Cel mai important, salutăm și apreciem toate feedback-urile și sugestiile!
Planurile de viitor
În prezent, fiecare infrastructură sau microserviciu pentru DataHub open source este construită ca un container Docker, iar întregul sistem este orchestrat folosind . Având în vedere popularitatea și răspândirea , am dori, de asemenea, să oferim o soluție bazată pe Kubernetes în viitorul apropiat.
De asemenea, intenționăm să oferim o soluție la cheie pentru implementarea DataHub pe un serviciu public cloud, cum ar fi , sau . Având în vedere recentul anunț privind migrarea LinkedIn la Azure, acest lucru se va alinia cu prioritățile interne ale echipei de metadate.
Nu în ultimul rând, mulțumim tuturor primilor care au adoptat DataHub din comunitatea open source care au evaluat DataHub alpha și ne-au ajutat să identificăm problemele și să îmbunătățim documentația.
Sursa: www.habr.com