Open Source DataHub: LinkedInova platforma za pretraživanje i otkrivanje metapodataka
Brzo pronalaženje podataka koji su vam potrebni ključno je za svaku tvrtku koja se oslanja na velike količine podataka za donošenje odluka na temelju podataka. Ne samo da to utječe na produktivnost korisnika podataka (uključujući analitičare, programere strojnog učenja, podatkovne znanstvenike i podatkovne inženjere), već također ima izravan utjecaj na krajnje proizvode koji ovise o kvalitetnom strojnom učenju (ML). Osim toga, trend implementacije ili izgradnje platformi za strojno učenje prirodno postavlja pitanje: koja je vaša metoda za interno otkrivanje značajki, modela, metrika, skupova podataka itd.
U ovom ćemo članku 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 ranih dana projekta . LinkedIn održava vlastitu verziju DataHuba odvojeno od verzije otvorenog koda. Započet ćemo s objašnjenjem zašto su nam potrebna dva odvojena razvojna okruženja, zatim ćemo razgovarati o ranim pristupima korištenju Open Source WhereHows i usporediti našu internu (produkcijsku) verziju DataHuba s 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 repozitorija bila sinkronizirana. Na kraju, pružit ćemo upute o tome kako početi koristiti DataHub otvorenog koda i ukratko raspraviti o njegovoj arhitekturi.
WhereHows je sada DataHub!
LinkedInov tim za metapodatke koji je prethodno predstavljen (nasljednik WhereHowsa), LinkedInova platforma za pretraživanje i otkrivanje metapodataka, te zajednički planovi za njezino otvaranje. Ubrzo nakon ove objave, izdali smo alfa verziju DataHuba i podijelili je sa zajednicom. Od tada smo neprestano pridonosili repozitoriju i radili sa zainteresiranim korisnicima na dodavanju najtraženijih značajki i rješavanju problema. Sada sa zadovoljstvom najavljujemo službeno izdanje .
Pristupi otvorenom kodu
WhereHows, izvorni portal LinkedIna za pronalaženje podataka i odakle oni dolaze, započeo je kao interni projekt; tim za metapodatke ga je otvorio . Od tada, tim je uvijek održavao dvije različite baze kodova – jednu za otvoreni izvor i jednu za internu upotrebu LinkedIna – jer nisu sve značajke proizvoda razvijene za slučajeve upotrebe LinkedIna bile općenito primjenjive na širu publiku. Osim toga, WhereHows ima neke interne ovisnosti (infrastruktura, knjižnice itd.) koje nisu otvorenog koda. U godinama koje su uslijedile, WhereHows je prošao kroz mnoge iteracije i razvojne cikluse, čineći održavanje sinkronizacije dviju baza koda velikim izazovom. Tim za metapodatke isprobao je različite pristupe tijekom godina kako bi pokušao održati sinkronizaciju internog i otvorenog izvornog koda.
Prvi pokušaj: "Prvo otvoreni kod"
U početku smo slijedili razvojni model "prvo otvoreni kod", gdje se većina razvoja odvija u repozitoriju otvorenog koda, a promjene se unose za internu implementaciju. Problem s ovim pristupom je taj što se kod uvijek prvo šalje na GitHub prije nego što se u potpunosti interno pregleda. Sve dok se ne izvrše promjene iz repozitorija otvorenog izvornog koda i dok se ne izvrši nova interna implementacija, nećemo pronaći probleme u proizvodnji. U slučaju lošeg rasporeda, također je bilo vrlo teško utvrditi krivca jer su promjene rađene u serijama.
Osim toga, ovaj je model smanjio produktivnost tima pri razvoju novih značajki koje su zahtijevale brze iteracije, jer je prisiljavao da se sve promjene prvo pošalju u repozitorij otvorenog koda, a zatim u interni repozitorij. Kako bi se smanjilo vrijeme obrade, potrebni popravak ili promjena mogli su se prvo napraviti u internom repozitoriju, ali to je postao veliki problem kada je došlo do spajanja tih promjena natrag u repozitorij otvorenog koda jer dva repozitorija nisu bila sinkronizirana.
Ovaj je model puno lakše implementirati za zajedničke platforme, knjižnice ili infrastrukturne projekte nego za prilagođene web aplikacije s punim značajkama. Osim toga, ovaj je model idealan za projekte koji započinju s otvorenim kodom od prvog dana, ali WhereHows je izgrađen kao potpuno interna web aplikacija. Bilo je stvarno teško potpuno apstrahirati sve unutarnje ovisnosti, pa smo morali zadržati interni fork, ali zadržavanje internog forka i razvijanje uglavnom otvorenog koda nije baš išlo.
Drugi pokušaj: “Prvo unutarnji”
**Kao drugi pokušaj, prešli smo na "interni prvi" model razvoja, gdje se većina razvoja odvija unutar kuće i redovito se unose promjene u otvoreni kod. Iako je ovaj model najprikladniji za naš slučaj upotrebe, on ima inherentne probleme. Izravno guranje svih razlika u repozitorij otvorenog izvornog koda i pokušaj kasnijeg rješavanja sukoba spajanja je opcija, ali oduzima puno vremena. Programeri u većini slučajeva pokušavaju to ne činiti svaki put kad pregledavaju svoj kod. Kao rezultat toga, to će se raditi puno rjeđe, u serijama, i time otežava kasnije rješavanje sukoba spajanja.
Treći put je upalilo!
Dva gore navedena neuspjela pokušaja rezultirala su time da je WhereHows GitHub repozitorij ostao zastario dugo vremena. Tim je nastavio poboljšavati značajke i arhitekturu proizvoda, tako da je interna verzija WhereHows za LinkedIn postala naprednija od verzije otvorenog koda. Imao je čak i novo ime - DataHub. Na temelju prethodnih neuspjelih pokušaja, tim je odlučio razviti skalabilno, dugoročno rješenje.
Za svaki novi projekt otvorenog izvornog koda, LinkedInov tim otvorenog izvornog koda savjetuje i podržava razvojni model u kojem se moduli projekta razvijaju u potpunosti u otvorenom izvornom kodu. Artefakti s verzijama raspoređuju se u javno spremište, a zatim se provjeravaju natrag u interni LinkedIn artefakt pomoću . Slijeđenje ovog razvojnog modela nije dobro samo za one koji koriste otvoreni kod, već također rezultira modularnijom, proširivom i priključnom arhitekturom.
Međutim, zreloj pozadinskoj aplikaciji kao što je DataHub trebat će dosta vremena da postigne ovo stanje. Ovo također isključuje mogućnost otvorenog izvornog koda za potpuno radnu implementaciju prije nego što su sve interne ovisnosti potpuno apstrahirane. Zato smo razvili alate koji nam pomažu da brže i uz mnogo manje bola napravimo doprinose otvorenog koda. Ovo rješenje koristi i timu za metapodatke (razvojniku DataHuba) i zajednici otvorenog koda. Sljedeći odjeljci raspravljat će o ovom novom pristupu.
Automatizacija objavljivanja otvorenog koda
Najnoviji pristup tima Metadata DataHubu otvorenog koda je razvoj alata koji automatski sinkronizira internu bazu koda i repozitorij otvorenog koda. Značajke visoke razine ovog kompleta alata uključuju:
- Sinkronizirajte LinkedIn kod na/iz otvorenog koda, slično .
- Generiranje zaglavlja licence, slično .
- Automatski generirajte zapisnike predaje otvorenog koda iz internih zapisa predaje.
- Spriječite interne promjene koje kvare nadogradnje otvorenog koda .
Sljedeći pododjeljci bavit će se gore navedenim funkcijama koje imaju zanimljive probleme.
Sinkronizacija izvornog koda
Za razliku od verzije DataHuba otvorenog koda, koja je jedno GitHub spremište, LinkedIn verzija DataHuba je kombinacija više spremišta (interno se nazivaju ). DataHub sučelje, biblioteka modela metapodataka, pozadinska usluga skladišta metapodataka i poslovi strujanja nalaze se u zasebnim spremištima na LinkedInu. Međutim, kako bismo olakšali korisnicima otvorenog koda, imamo jedno spremište za verziju DataHuba otvorenog koda.
Slika 1: Sinkronizacija između repozitorija LinkedIn DataHub i jedno spremište DataHub otvoreni izvor
Kako bi podržali automatizirane tijekove rada izgradnje, guranja i povlačenja, naš novi alat automatski stvara mapiranje na razini datoteke koje odgovara svakoj izvornoj datoteci. Međutim, skup alata zahtijeva početnu konfiguraciju i korisnici moraju osigurati mapiranje modula visoke razine 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 razini modula jednostavan je JSON čiji su ključevi ciljni moduli u repozitoriju otvorenog koda, a vrijednosti su popis izvornih modula u repozitoriju LinkedIn. Bilo koji ciljni modul u repozitoriju 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 stvaraju 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 na razini datoteke; međutim, korisnik ga također može ažurirati ručno. Ovo je mapiranje 1:1 LinkedIn izvorne datoteke u datoteku u repozitoriju otvorenog koda. Postoji nekoliko pravila povezanih s ovim automatskim stvaranjem asocijacija datoteka:
- U slučaju više izvornih modula za ciljni modul u otvorenom kodu, mogu se pojaviti sukobi, npr. isti , postoje u više od jednog izvornog modula. Kao strategija rješavanja sukoba, naši alati postavljaju zadanu opciju "posljednji pobjeđuje".
- "null" znači da izvorna datoteka nije dio repozitorija otvorenog koda.
- Nakon svakog podnošenja ili izdvajanja otvorenog koda, ovo se mapiranje automatski ažurira i stvara se snimka. Ovo je neophodno za identifikaciju dodavanja i brisanja iz izvornog koda od zadnje akcije.
Stvaranje dnevnika predaje
Zapisnici predaja za predaje otvorenog koda također se automatski generiraju spajanjem zapisnika obveza internih repozitorija. Ispod je primjer dnevnika predaje koji prikazuje strukturu dnevnika predaje koju je generirao naš alat. Obaveza jasno pokazuje koje su verzije izvornih repozitorija zapakirane u tom predanju i daje sažetak dnevnika predaje. Pogledaj ovu korištenjem stvarnog primjera dnevnika predaje koji je generirao naš alat.
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 ovisnosti
LinkedIn ima , što pomaže osigurati da promjene internog multiproizvoda ne prekinu sklop zavisnih multiproizvoda. Repozitorij DataHub otvorenog koda nije multi-proizvod i ne može biti izravna ovisnost o bilo kojem više proizvoda, ali uz pomoć omotača više proizvoda koji dohvaća izvorni kod DataHuba otvorenog koda, još uvijek možemo koristiti ovo testiranje ovisnosti Dakle, bilo koja promjena (koja bi kasnije mogla biti izložena) bilo kojeg od multiproizvoda koji se napajaju repozitorijem DataHub otvorenog koda pokreće događaj izgradnje u multiproizvodu ljuske. Stoga svaka promjena koja ne uspije izgraditi omotni proizvod ne prolazi testove prije predaje originalnog proizvoda i vraća se.
Ovo je koristan mehanizam koji pomaže spriječiti bilo kakvo interno uvrštavanje koje razbija međugradnju otvorenog koda i otkriva ga u vrijeme predaje. Bez toga, bilo bi prilično teško utvrditi koji je interni commit uzrokovao neuspjeh izgradnje repozitorija otvorenog koda, jer grupiramo interne promjene u repozitoriju otvorenog koda DataHub.
Razlike između DataHuba otvorenog koda i naše proizvodne verzije
Do ove točke razgovarali smo o našem rješenju za sinkronizaciju dviju verzija DataHub repozitorija, ali još uvijek nismo naveli razloge zašto su nam uopće potrebna dva različita razvojna toka. U ovom ćemo odjeljku navesti razlike između javne verzije DataHuba i proizvodne verzije na LinkedIn poslužiteljima te objasniti razloge za te razlike.
Jedan izvor odstupanja proizlazi iz činjenice da naša proizvodna verzija ima ovisnosti o kodu koji još nije otvorenog koda, kao što je LinkedIn Offspring (LinkedIn interni okvir za ubrizgavanje ovisnosti). Offspring se naširoko koristi u internim bazama kodova jer je to preferirana metoda za upravljanje dinamičkom konfiguracijom. Ali nije open source; pa smo morali pronaći alternative otvorenog koda DataHubu otvorenog koda.
Postoje i drugi razlozi. Budući da stvaramo proširenja modela metapodataka za potrebe LinkedIna, ta su proširenja obično vrlo specifična za LinkedIn i možda se neće izravno primijeniti na druga okruženja. Na primjer, imamo vrlo specifične oznake za ID-ove sudionika i druge vrste podudarnih metapodataka. Dakle, sada smo isključili ova proširenja iz DataHubovog modela metapodataka otvorenog koda. Kako budemo surađivali sa zajednicom i razumijevali njihove potrebe, radit ćemo na zajedničkim verzijama otvorenog koda ovih proširenja gdje je to potrebno.
Jednostavnost korištenja i lakša prilagodba za zajednicu otvorenog koda također su nadahnule neke od razlika između dviju verzija DataHuba. Razlike u infrastrukturi za obradu toka dobar su primjer za to. Iako naša interna verzija koristi okvir za upravljanu obradu toka, odlučili smo koristiti ugrađenu (samostalnu) obradu toka za verziju otvorenog koda jer izbjegava stvaranje još jedne ovisnosti o infrastrukturi.
Još jedan primjer razlike je postojanje jednog GMS-a (generalizirane memorije metapodataka) u implementaciji otvorenog koda umjesto više GMS-ova. GMA (Generalized Metadata Architecture) naziv je pozadinske arhitekture za DataHub, a GMS je pohrana metapodataka u kontekstu GMA. GMA je vrlo fleksibilna arhitektura koja vam omogućuje distribuciju svake konstrukcije podataka (npr. skupova podataka, korisnika itd.) u vlastitu pohranu metapodataka ili pohranjivanje višestrukih konstrukcija podataka u jednu pohranu metapodataka sve dok registar koji sadrži preslikavanje strukture podataka u GMS je ažuriran. Radi lakšeg korištenja odabrali smo jednu instancu GMS-a koja pohranjuje sve različite konstrukcije podataka u DataHub otvorenog koda.
Kompletan popis razlika između dvije implementacije dan je u tablici u nastavku.
Značajke proizvoda
LinkedIn DataHub
Open Source DataHub
Podržani podatkovni konstrukti
1) Skupovi podataka 2) Korisnici 3) Mjerni podaci 4) ML značajke 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)
Košnica Kafka RDBMS
Pub-sub
Utočna Kafka
Obrada toka
Managed
Ugrađeno (samostalno)
Uvođenje ovisnosti i dinamička konfiguracija
LinkedIn potomstvo
Alat za izradu
Ligradle (Interni omotač Gradle LinkedIna)
CI / CD
CRT (interni CI/CD LinkedIna)
i
Spremišta metapodataka
Distribuirani višestruki GMS: 1) Skup podataka GMS 2) Korisnički GMS 3) Metrički GMS 4) Funkcijski GMS 5) Grafikon/nadzorna ploča GMS
Jedinstveni GMS za: 1) skupove podataka 2) korisnike
Mikroservisi u Docker spremnicima
pojednostavljuje implementaciju i distribuciju aplikacija s . Svaki dio usluge u DataHubu je otvorenog koda, uključujući komponente infrastrukture kao što su Kafka, , и , ima vlastitu Docker sliku. Za orkestriranje Docker kontejnera koristili smo se .
Slika 2: Arhitektura DataHub *otvoreni izvor**
Na gornjoj slici možete vidjeti arhitekturu visoke razine DataHuba. Osim infrastrukturnih komponenti, ima četiri različita Docker spremnika:
datahub-gms: usluga pohrane metapodataka
datahub-frontend: aplikacija , koji služi sučelju DataHub.
datahub-mce-consumer: aplikacija , koji koristi tok događaja promjene metapodataka (MCE) i ažurira pohranu metapodataka.
datahub-mae-consumer: aplikacija , koji koristi tok događaja revizije metapodataka (MAE) i stvara 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
DataHub repozitorij otvorenog koda koristi za kontinuiranu integraciju i za kontinuiranu implementaciju. Oba imaju dobru GitHub integraciju i lako se postavljaju. Za većinu infrastrukture otvorenog koda koju je razvila zajednica ili privatne tvrtke (npr. ), Docker slike se stvaraju i postavljaju na Docker Hub radi lakšeg korištenja od strane zajednice. Bilo koja Docker slika pronađena u Docker Hubu može se jednostavno koristiti jednostavnom naredbom .
Sa svakim predanjem DataHub repozitoriju otvorenog koda, sve Docker slike automatski se izgrađuju i postavljaju na Docker Hub s oznakom "najnovije". Ako je Docker Hub konfiguriran s nekim , sve oznake u repozitoriju otvorenog koda također su objavljene s odgovarajućim nazivima oznaka u Docker Hubu.
Korištenje DataHuba
vrlo je jednostavan i sastoji se od tri jednostavna koraka:
- Klonirajte repozitorij otvorenog koda i pokrenite sve Docker spremnike s docker-compose koristeći isporučenu docker-compose skriptu za brzi početak.
- Preuzmite uzorke podataka koji se nalaze u repozitoriju pomoću alata naredbenog retka koji je također dostupan.
- Pregledajte DataHub u svom pregledniku.
Aktivno praćeno također konfiguriran za brza pitanja. Korisnici također mogu stvarati probleme izravno u GitHub repozitoriju. Što je najvažnije, pozdravljamo i cijenimo sve povratne informacije i prijedloge!
Planovi za budućnost
Trenutačno je svaka infrastruktura ili mikroservis za DataHub otvorenog koda izgrađen kao Docker spremnik, a cijeli je sustav orkestriran pomoću . S obzirom na popularnost i raširenost , također bismo željeli ponuditi rješenje temeljeno na Kubernetesu u bliskoj budućnosti.
Također planiramo ponuditi ključ u ruke rješenje za implementaciju DataHuba na javnu uslugu u oblaku kao što je , ili . S obzirom na nedavnu najavu migracije LinkedIna na Azure, to će se uskladiti s internim prioritetima tima za metapodatke.
Posljednje, ali ne i najmanje važno, hvala svim prvim korisnicima DataHuba u zajednici otvorenog koda koji su ocijenili DataHub alfa verzije i pomogli nam da identificiramo probleme i poboljšamo dokumentaciju.
Izvor: www.habr.com