Open Source DataHub: LinkedIn platforma za pretraživanje i otkrivanje metapodataka
Brzo pronalaženje podataka koji su vam potrebni ključno je za svaku kompaniju koja se oslanja na velike količine podataka kako bi donosila odluke zasnovane na podacima. Ovo ne samo da utiče na produktivnost korisnika podataka (uključujući analitičare, programere mašinskog učenja, naučnike i inženjere podataka), već takođe ima direktan uticaj na krajnje proizvode koji zavise od kvalitetnog procesa mašinskog učenja (ML). Uz to, trend implementacije ili izgradnje platformi za strojno učenje prirodno postavlja pitanje: koja je vaša metoda za interno otkrivanje karakteristika, modela, metrika, skupova podataka itd.
U ovom članku ćemo govoriti o tome kako smo objavili izvor podataka pod otvorenom licencom u našoj platformi za pretraživanje i otkrivanje metapodataka, počevši od prvih dana projekta . LinkedIn održava vlastitu verziju DataHub-a odvojeno od verzije otvorenog koda. Počećemo tako što ćemo objasniti zašto su nam potrebna dva odvojena razvojna okruženja, zatim ćemo razmotriti rane pristupe korišćenju otvorenog koda WhereHows i uporediti našu internu (proizvodnu) verziju DataHub-a sa verzijom na . Također ćemo podijeliti detalje o našem novom automatiziranom rješenju za slanje i primanje ažuriranja otvorenog koda kako bi oba spremišta bila sinhronizirana. Konačno, daćemo uputstva o tome kako da počnete da koristite DataHub otvorenog koda i ukratko razgovaramo o njegovoj arhitekturi.
WhereHows je sada DataHub!
LinkedIn-ov tim za metapodatke je ranije predstavljen (nasljednik WhereHows), LinkedIn-ova platforma za pretraživanje i otkrivanje metapodataka i zajednički planovi za njeno otvaranje. Ubrzo nakon ove objave, objavili smo alfa verziju DataHub-a i podijelili je sa zajednicom. Od tada smo kontinuirano doprinosili spremištu i radili sa zainteresiranim korisnicima na dodavanju najtraženijih karakteristika i rješavanju problema. Sada sa zadovoljstvom najavljujemo zvanično izdanje .
Pristupi otvorenog koda
WhereHows, LinkedIn-ov originalni portal za pronalaženje podataka i odakle dolaze, započeo je kao interni projekat; tim za metapodatke ga je otvorio . Od tada, tim je uvijek održavao dvije različite baze koda – jednu za otvoreni kod i jednu za internu upotrebu LinkedIn-a – jer nisu sve funkcije proizvoda razvijene za slučajeve korištenja LinkedIn-a općenito primjenjive na širu publiku. Uz to, WhereHows ima neke interne zavisnosti (infrastruktura, biblioteke, itd.) koje nisu otvorenog koda. U godinama koje su uslijedile, WhereHows je prošao kroz mnoge iteracije i razvojne cikluse, čineći sinhronizaciju dvije baze koda velikim izazovom. Tim za metapodatke je isprobao različite pristupe tokom godina kako bi pokušao da zadrži interni razvoj i razvoj otvorenog koda u sinhronizaciji.
Prvi pokušaj: "Prvo otvoreni izvor"
Prvobitno smo slijedili razvojni model "prvo otvorenog koda", gdje se većina razvoja odvija u spremištu otvorenog koda, a promjene se vrše za internu implementaciju. Problem s ovim pristupom je taj što se kod uvijek prvo prosljeđuje na GitHub prije nego što se u potpunosti interno pregleda. Sve dok se ne izvrše promjene iz repozitorija otvorenog koda i ne izvrši nova interna implementacija, nećemo pronaći nikakve probleme u proizvodnji. U slučaju lošeg rasporeda bilo je i vrlo teško utvrditi krivca jer su se izmjene vršile u serijama.
Dodatno, ovaj model je smanjio produktivnost tima pri razvoju novih funkcija koje su zahtijevale brze iteracije, jer je prisilio da se sve promjene prvo gurnu u spremište otvorenog koda, a zatim u interno spremište. Da bi se smanjilo vrijeme obrade, potrebna popravka ili promjena mogla bi se prvo izvršiti u internom spremištu, ali je to postao veliki problem kada je došlo do spajanja tih promjena natrag u spremište otvorenog koda jer dva spremišta nisu bila sinhronizirana.
Ovaj model je mnogo lakši za implementaciju za zajedničke platforme, biblioteke ili infrastrukturne projekte nego za potpuno opremljene prilagođene web aplikacije. Dodatno, ovaj model je idealan za projekte koji počinju sa otvorenim kodom od prvog dana, ali WhereHows je izgrađen kao potpuno interna web aplikacija. Bilo je zaista teško potpuno apstrahovati sve unutrašnje zavisnosti, tako da smo morali da zadržimo interni fork, ali zadržavanje interne vilice i razvoj uglavnom otvorenog koda nije baš išlo.
Drugi pokušaj: "Prvo iznutra"
**Kao drugi pokušaj, prešli smo na razvojni model "prvo interno", gdje se većina razvoja odvija unutar kuće i redovno se vrše promjene otvorenog koda. Iako je ovaj model najprikladniji za naš slučaj upotrebe, on ima inherentne probleme. Direktno prebacivanje svih razlika u spremište otvorenog koda, a zatim pokušaj kasnijeg rješavanja sukoba spajanja je opcija, ali to oduzima mnogo vremena. Programeri se u većini slučajeva trude da to ne rade svaki put kada pregledaju svoj kod. Kao rezultat toga, to će se raditi mnogo rjeđe, u grupama, što otežava kasnije rješavanje sukoba spajanja.
Treći put je upalilo!
Dva gore spomenuta neuspjela pokušaja dovela su do toga da je WhereHows GitHub spremište dugo zastarjelo. Tim je nastavio da poboljšava karakteristike i arhitekturu proizvoda, tako da je interna verzija WhereHows za LinkedIn postala naprednija od verzije otvorenog koda. Čak je imao i novo ime - DataHub. Na osnovu prethodnih neuspjelih pokušaja, tim je odlučio razviti skalabilno, dugoročno rješenje.
Za svaki novi projekat otvorenog koda, LinkedInov tim otvorenog koda savetuje i podržava razvojni model u kojem su moduli projekta u potpunosti razvijeni u otvorenom kodu. Versionirani artefakti se postavljaju u javno spremište, a zatim se provjeravaju natrag u interni LinkedIn artefakt koristeći . Praćenje ovog razvojnog modela nije samo dobro za one koji koriste otvoreni kod, već takođe rezultira modularnijom, proširivom arhitekturom koja se može priključiti.
Međutim, zreloj pozadinskoj aplikaciji kao što je DataHub biće potrebno dosta vremena da dostigne ovo stanje. Ovo također isključuje mogućnost otvorenog izvora za potpuno funkcionalnu implementaciju prije nego što se u potpunosti apstrahuju sve interne zavisnosti. Zato smo razvili alate koji nam pomažu da dajemo doprinose otvorenog koda brže i sa mnogo manje muke. Ovo rješenje koristi i timu za metapodatke (programer DataHub-a) i zajednici otvorenog koda. U sljedećim odjeljcima će se raspravljati o ovom novom pristupu.
Open Source Publishing Automation
Najnoviji pristup Metadata tima DataHub-u je razvoj alata koji automatski sinhronizuje internu kodnu bazu i repozitorijum otvorenog koda. Karakteristike visokog nivoa ovog kompleta alata uključuju:
- Sinhronizacija LinkedIn koda sa/iz otvorenog koda, slično .
- Generiranje zaglavlja licence, slično .
- Automatski generirajte dnevnike urezivanja otvorenog koda iz internih dnevnika urezivanja.
- Spriječite interne promjene koje prekidaju gradnje otvorenog koda .
Sljedeći pododjeljci će se baviti gore navedenim funkcijama koje imaju zanimljive probleme.
Sinhronizacija izvornog koda
Za razliku od open source verzije DataHub-a, koja je jedno GitHub spremište, LinkedIn verzija DataHub-a je kombinacija više spremišta (nazvanih interno ). DataHub interfejs, biblioteka modela metapodataka, backend usluga skladišta metapodataka i poslovi striminga nalaze se u zasebnim spremištima na LinkedIn-u. Međutim, da bismo olakšali korisnicima otvorenog koda, imamo jedno spremište za verziju DataHub-a otvorenog koda.
Slika 1: Sinhronizacija između spremišta LinkedIn DataHub i jedno spremište DataHub open source
Kako bi podržao automatizirani radni proces izgradnje, guranja i povlačenja, naš novi alat automatski kreira mapiranje na nivou datoteke koje odgovara svakoj izvornoj datoteci. Međutim, komplet alata zahtijeva početnu konfiguraciju i korisnici moraju osigurati mapiranje modula na visokom nivou kao što je prikazano u nastavku.
{
"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"
]
}Mapiranje na nivou modula je jednostavan JSON čiji su ključevi ciljni moduli u spremištu otvorenog koda, a vrijednosti su lista izvornih modula u LinkedIn repozitorijumima. Bilo koji ciljni modul u spremištu otvorenog koda može se hraniti bilo kojim brojem izvornih modula. Za označavanje internih imena spremišta u izvornim modulima, koristite u Bash stilu. Koristeći datoteku za mapiranje na razini modula, alati kreiraju datoteku za mapiranje na razini datoteke skeniranjem svih datoteka u pridruženim direktorijima.
{
"${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,
}Alati automatski kreiraju mapiranje nivoa datoteke; međutim, korisnik ga također može ručno ažurirati. Ovo je 1:1 mapiranje LinkedIn izvorne datoteke u datoteku u spremištu otvorenog koda. Postoji nekoliko pravila povezanih s ovim automatskim kreiranjem asocijacija datoteka:
- U slučaju više izvornih modula za ciljni modul u otvorenom kodu, može doći do sukoba, npr. , koji postoji u više od jednog izvornog modula. Kao strategija za rješavanje sukoba, naši alati zadano koriste opciju „posljednji pobjeđuje“.
- "null" znači da izvorna datoteka nije dio spremišta otvorenog koda.
- Nakon svakog podnošenja ili izdvajanja otvorenog koda, ovo mapiranje se automatski ažurira i kreira se snimak. Ovo je neophodno za identifikaciju dodavanja i brisanja iz izvornog koda od posljednje akcije.
Kreiranje dnevnika urezivanja
Dnevnici urezivanja za urezivanje otvorenog koda se takođe automatski generišu spajanjem dnevnika urezivanja internih spremišta. Ispod je primjer dnevnika urezivanja koji prikazuje strukturu dnevnika urezivanja koji je generirao naš alat. Urezivanje jasno pokazuje koje su verzije izvornih spremišta upakovane u to urezivanje i daje sažetak dnevnika urezivanja. Pogledaj ovo koristeći pravi primjer dnevnika urezivanja koji je generirao naš komplet alata.
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.0Testiranje zavisnosti
LinkedIn ima , što pomaže da se osigura da promjene na internom multiproizvodu ne razbiju sklop zavisnih više proizvoda. DataHub spremište otvorenog koda nije višeproizvodno i ne može biti direktna ovisnost o bilo kojem višeproizvodu, ali uz pomoć omotača za više proizvoda koji dohvaća izvorni kod otvorenog koda DataHub, još uvijek možemo koristiti ovo testiranje zavisnosti Prema tome, svaka promjena (koja kasnije može biti izložena) bilo kojeg od više proizvoda koji napaja spremište otvorenog koda DataHub pokreće događaj izgradnje u višeproizvodu ljuske. Stoga, svaka promjena koja ne uspije izgraditi proizvod omota ne prođe testove prije urezivanja originalnog proizvoda i poništi se.
Ovo je koristan mehanizam koji pomaže u sprečavanju bilo kakvog internog urezivanja koje prekida gradnju otvorenog koda i otkriva je u vrijeme urezivanja. Bez toga, bilo bi prilično teško odrediti koje interno urezivanje je uzrokovalo neuspjeh izgradnje spremišta otvorenog koda, jer skupljamo interne promjene u spremište otvorenog koda DataHub.
Razlike između otvorenog koda DataHub i naše produkcijske verzije
Do ove tačke smo raspravljali o našem rješenju za sinhronizaciju dvije verzije DataHub spremišta, ali još uvijek nismo naveli razloge zašto su nam uopće potrebna dva različita razvojna toka. U ovom odeljku ćemo navesti razlike između javne verzije DataHub-a i proizvodne verzije na LinkedIn serverima i objasniti razloge za ove razlike.
Jedan izvor neslaganja proizilazi iz činjenice da naša proizvodna verzija ima zavisnosti od koda koji još nije otvorenog koda, kao što je LinkedIn's Offspring (LinkedIn-ov interni okvir za ubrizgavanje zavisnosti). Offspring se široko koristi u internim kodnim bazama jer je poželjna metoda za upravljanje dinamičkom konfiguracijom. Ali to nije open source; tako da smo morali pronaći alternative otvorenog koda za DataHub otvorenog koda.
Postoje i drugi razlozi. Kako kreiramo proširenja za model metapodataka za potrebe LinkedIn-a, ova proširenja su obično vrlo specifična za LinkedIn i možda se ne primjenjuju direktno na druga okruženja. Na primjer, imamo vrlo specifične oznake za ID-ove učesnika i druge vrste podudarnih metapodataka. Dakle, sada smo isključili ove ekstenzije iz DataHub-ovog modela metapodataka otvorenog koda. Dok se sarađujemo sa zajednicom i razumijemo njihove potrebe, radit ćemo na zajedničkim verzijama ovih ekstenzija otvorenog koda gdje je to potrebno.
Lakoća korišćenja i lakša adaptacija za zajednicu otvorenog koda takođe su inspirisali neke od razlika između dve verzije DataHub-a. Razlike u infrastrukturi za obradu toka dobar su primjer za to. Iako naša interna verzija koristi upravljani okvir za obradu toka, odlučili smo koristiti ugrađenu (samostalnu) obradu toka za verziju otvorenog koda jer izbjegava stvaranje druge ovisnosti o infrastrukturi.
Još jedan primjer razlike je postojanje jednog GMS-a (generaliziranog skladišta metapodataka) u implementaciji otvorenog koda umjesto više GMS-ova. GMA (Generalized Metadata Architecture) je naziv pozadinske arhitekture za DataHub, a GMS je skladište metapodataka u kontekstu GMA. GMA je vrlo fleksibilna arhitektura koja vam omogućava da distribuirate svaki konstrukt podataka (npr. skupove podataka, korisnike, itd.) u vlastitu spremište metapodataka, ili pohranite više konstrukcija podataka u jedno spremište metapodataka sve dok registar sadrži mapiranje strukture podataka u GMS je ažuriran. Radi lakšeg korištenja, odabrali smo jednu GMS instancu koja pohranjuje sve različite konstrukcije podataka u DataHub otvorenog koda.
Potpuna lista razlika između ove dvije implementacije data je u tabeli ispod.
Karakteristike proizvoda
LinkedIn DataHub
Open Source DataHub
Podržane konstrukcije podataka
1) Skupovi podataka 2) Korisnici 3) metrika 4) ML karakteristike 5) grafikoni 6) Nadzorne ploče
1) Skupovi podataka 2) Korisnici
Podržani izvori metapodataka za skupove podataka
1) 2) Podloga za kauč 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
Konfluentni Kafka
Stream Processing
Managed
Ugrađeno (samostalno)
Injekcija zavisnosti i dinamička konfiguracija
LinkedIn Offspring
Build Tooling
Ligradle (LinkedIn-ov interni Gradle omot)
CI / CD
CRT (Interni CI/CD LinkedIn-a)
i
Prodavnice metapodataka
Distribuirani višestruki GMS: 1) Skup podataka GMS 2) Korisnički GMS 3) Metrički GMS 4) GMS karakteristika 5) GMS grafikon/kontrolna tabla
Jedinstveni GMS za: 1) Skupove podataka 2) Korisnici
Mikroservis u Docker kontejnerima
pojednostavljuje implementaciju i distribuciju aplikacija sa . Svaki dio usluge u DataHubu je otvorenog koda, uključujući infrastrukturne komponente kao što su Kafka, , и , ima svoj Docker imidž. Za orkestriranje Docker kontejnera koristili smo se .
Slika 2: Arhitektura DataHub *otvoreni izvor**
Možete vidjeti arhitekturu visokog nivoa DataHub-a na gornjoj slici. Osim infrastrukturnih komponenti, ima četiri različita Docker kontejnera:
datahub-gms: usluga skladištenja metapodataka
datahub-frontend: aplikacija , koji opslužuje DataHub interfejs.
datahub-mce-consumer: aplikacija , koji koristi tok događaja promjene metapodataka (MCE) i ažurira skladište metapodataka.
datahub-mae-consumer: aplikacija , koji koristi tok događaja revizije metapodataka (MAE) i kreira indeks pretraživanja i bazu podataka grafikona.
Dokumentacija repozitorija otvorenog koda i sadrže detaljnije informacije o funkcijama različitih usluga.
CI/CD na DataHubu je otvorenog koda
Koristi se DataHub spremište otvorenog koda za kontinuiranu integraciju i za kontinuirano raspoređivanje. Oba imaju dobru GitHub integraciju i lako se postavljaju. Za većinu infrastrukture otvorenog koda koju je razvila zajednica ili privatne kompanije (npr. ), Docker slike se kreiraju i postavljaju na Docker Hub radi lakšeg korištenja od strane zajednice. Bilo koja Docker slika pronađena u Docker Hub-u može se lako koristiti jednostavnom komandom .
Sa svakim urezivanjem u spremište otvorenog koda DataHub, sve Docker slike se automatski grade i postavljaju na Docker Hub sa "najnovijom" oznakom. Ako je Docker Hub konfiguriran s nekim , sve oznake u repozitorijumu otvorenog koda se takođe objavljuju sa odgovarajućim nazivima oznaka u Docker Hub-u.
Korištenje DataHub-a
je vrlo jednostavan i sastoji se od tri jednostavna koraka:
- Klonirajte spremište otvorenog koda i pokrenite sve Docker kontejnere sa docker-compose koristeći priloženu skriptu docker-compose za brzi početak.
- Preuzmite uzorke podataka koji su dani u spremištu koristeći alat komandne linije koji je također dostavljen.
- Pregledajte DataHub u svom pretraživaču.
Aktivno praćeno također konfiguriran za brza pitanja. Korisnici također mogu kreirati probleme direktno u GitHub spremištu. Ono što je najvažnije, pozdravljamo i cijenimo sve povratne informacije i sugestije!
Planovi za budućnost
Trenutno je svaka infrastruktura ili mikroservis za Open Source DataHub izgrađen kao Docker kontejner, a cijeli sistem je orkestriran pomoću . S obzirom na popularnost i rasprostranjenost , takođe bismo želeli da obezbedimo rešenje zasnovano na Kubernetesu u bliskoj budućnosti.
Takođe planiramo da obezbedimo rešenje po principu „ključ u ruke“ za implementaciju DataHub-a na javni cloud servis kao što je npr , ili . S obzirom na nedavnu najavu LinkedIn-ove migracije na Azure, ovo će biti usklađeno s internim prioritetima tima za metapodatke.
Na kraju, ali ne i najmanje važno, hvala svim ranim usvojiteljima DataHub-a u zajednici otvorenog koda koji su ocijenili DataHub alfa i pomogli nam da identificiramo probleme i poboljšamo dokumentaciju.
izvor: www.habr.com