Open Source DataHub: LinkedIn Metadata Search and Discovery Platform
Rýchle nájdenie údajov, ktoré potrebujete, je nevyhnutné pre každú spoločnosť, ktorá sa pri rozhodovaní na základe údajov spolieha na veľké množstvo údajov. Ovplyvňuje to nielen produktivitu používateľov údajov (vrátane analytikov, vývojárov strojového učenia, údajových vedcov a údajových inžinierov), ale má to aj priamy vplyv na konečné produkty, ktoré závisia od kvalitného kanála strojového učenia (ML). Okrem toho trend implementácie alebo budovania platforiem strojového učenia prirodzene vyvoláva otázku: aká je vaša metóda na interné objavovanie funkcií, modelov, metrík, súborov údajov atď.
V tomto článku si povieme, ako sme publikovali zdroj údajov pod otvorenou licenciou v našej platforme na vyhľadávanie a zisťovanie metadát, a to už od prvých dní projektu . LinkedIn udržiava svoju vlastnú verziu DataHub oddelene od verzie s otvoreným zdrojom. Začneme vysvetlením, prečo potrebujeme dve samostatné vývojové prostredia, potom prediskutujeme prvé prístupy k používaniu open source WhereHows a porovnáme našu internú (produkčnú) verziu DataHub s verziou na . Budeme tiež zdieľať podrobnosti o našom novom automatizovanom riešení na odosielanie a prijímanie aktualizácií s otvoreným zdrojovým kódom, aby boli obe úložiská synchronizované. Nakoniec poskytneme návod, ako začať používať open source DataHub a stručne rozoberieme jeho architektúru.
WhereHows je teraz DataHub!
Tím metadát LinkedIn bol predtým predstavený (nástupca WhereHows), platforma na vyhľadávanie a zisťovanie metadát LinkedIn a zdieľané plány na jej otvorenie. Krátko po tomto oznámení sme vydali alfa verziu DataHubu a zdieľali ju s komunitou. Odvtedy neustále prispievame do úložiska a spolupracujeme so zainteresovanými používateľmi na pridávaní najžiadanejších funkcií a riešení problémov. Teraz s potešením oznamujeme oficiálne vydanie .
Open Source prístupy
WhereHows, pôvodný portál LinkedIn na vyhľadávanie údajov a odkiaľ pochádzajú, začal ako interný projekt; tím metadát ho otvoril . Odvtedy tím vždy udržiaval dve rôzne kódové základne – jednu pre open source a jednu pre interné použitie LinkedIn – keďže nie všetky funkcie produktov vyvinuté pre prípady použitia LinkedIn boli všeobecne použiteľné pre širšie publikum. Okrem toho má WhereHows niektoré vnútorné závislosti (infraštruktúra, knižnice atď.), ktoré nie sú open source. V nasledujúcich rokoch prešiel WhereHows mnohými iteráciami a vývojovými cyklami, vďaka čomu bolo udržanie týchto dvoch kódových báz v synchronizácii veľkou výzvou. Tím metaúdajov v priebehu rokov vyskúšal rôzne prístupy, aby sa pokúsil synchronizovať interný a open source vývoj.
Prvý pokus: „Najskôr otvorený zdroj“
Spočiatku sme postupovali podľa vývojového modelu „najskôr open source“, kde väčšina vývoja prebieha v úložisku s otvoreným zdrojom a zmeny sa vykonávajú pre interné nasadenie. Problém s týmto prístupom je v tom, že kód sa vždy najprv odošle na GitHub a až potom sa úplne interne skontroluje. Kým sa nevykonajú zmeny z úložiska s otvoreným zdrojovým kódom a nevykoná sa nové interné nasadenie, nenájdeme žiadne produkčné problémy. V prípade zlého nasadenia bolo tiež veľmi ťažké určiť vinníka, pretože zmeny sa robili v dávkach.
Tento model navyše znížil produktivitu tímu pri vývoji nových funkcií, ktoré si vyžadovali rýchle iterácie, pretože si vynútil, aby sa všetky zmeny najskôr vložili do úložiska s otvoreným zdrojovým kódom a potom sa presunuli do interného úložiska. Aby sa skrátil čas spracovania, požadovaná oprava alebo zmena sa mohla vykonať najskôr v internom úložisku, čo sa však stalo obrovským problémom, keď došlo k zlúčeniu týchto zmien späť do úložiska s otvoreným zdrojom, pretože tieto dva úložiská neboli synchronizované.
Tento model je oveľa jednoduchšie implementovať pre zdieľané platformy, knižnice alebo infraštruktúrne projekty ako pre plnohodnotné vlastné webové aplikácie. Okrem toho je tento model ideálny pre projekty, ktoré začínajú s otvoreným zdrojom od prvého dňa, ale WhereHows bol vytvorený ako úplne interná webová aplikácia. Bolo naozaj ťažké úplne abstrahovať všetky interné závislosti, takže sme si potrebovali ponechať internú vidlicu, ale ponechať si internú vidlicu a vyvíjať väčšinou open source úplne nevyšlo.
Druhý pokus: „Najskôr vnútorný“
**Ako druhý pokus sme prešli na model vývoja „najprv interne“, kde väčšina vývoja prebieha interne a zmeny v otvorenom zdrojovom kóde sa vykonávajú pravidelne. Aj keď je tento model najvhodnejší pre náš prípad použitia, má svoje vlastné problémy. Priame presunutie všetkých rozdielov do úložiska s otvoreným zdrojovým kódom a následné pokusy o vyriešenie konfliktov pri zlúčení neskôr je možnosťou, ale je to časovo náročné. Vývojári sa to vo väčšine prípadov snažia nerobiť zakaždým, keď kontrolujú svoj kód. V dôsledku toho sa to bude robiť oveľa menej často, v dávkach, a preto je neskoršie riešenie konfliktov pri zlučovaní ťažšie.
Tretíkrát to vyšlo!
Dva neúspešné pokusy uvedené vyššie viedli k tomu, že úložisko WhereHows GitHub zostalo po dlhú dobu neaktuálne. Tím pokračoval vo vylepšovaní funkcií a architektúry produktu, takže interná verzia WhereHows pre LinkedIn bola pokročilejšia ako verzia s otvoreným zdrojom. Dokonca mal aj nový názov – DataHub. Na základe predchádzajúcich neúspešných pokusov sa tím rozhodol vyvinúť škálovateľné, dlhodobé riešenie.
Pri každom novom projekte s otvoreným zdrojovým kódom tím open source na LinkedIn radí a podporuje vývojový model, v ktorom sú moduly projektu vyvinuté výhradne v open source. Verzované artefakty sa nasadia do verejného úložiska a potom sa skontrolujú späť do interného artefaktu LinkedIn pomocou . Nasledovanie tohto modelu vývoja je dobré nielen pre tých, ktorí používajú open source, ale výsledkom je aj modulárnejšia, rozšíriteľnejšia a pripojiteľnejšia architektúra.
Vyspelá back-endová aplikácia, akou je napríklad DataHub, však bude vyžadovať značné množstvo času na dosiahnutie tohto stavu. To tiež vylučuje možnosť otvoreného zdroja plne funkčnej implementácie pred úplným odstránením všetkých vnútorných závislostí. To je dôvod, prečo sme vyvinuli nástroje, ktoré nám pomáhajú vytvárať open source príspevky rýchlejšie a s oveľa menšou námahou. Toto riešenie je prínosom pre tím metadát (vývojár DataHub) aj pre komunitu s otvoreným zdrojom. Nasledujúce časti budú diskutovať o tomto novom prístupe.
Automatizácia publikovania s otvoreným zdrojom
Najnovším prístupom tímu Metadata k open source DataHub je vývoj nástroja, ktorý automaticky synchronizuje internú kódovú základňu a open source úložisko. Funkcie na vysokej úrovni tejto sady nástrojov zahŕňajú:
- Synchronizujte kód LinkedIn do/z open source, podobne .
- Generovanie hlavičky licencie, podobne ako .
- Automaticky generujte protokoly odovzdania s otvoreným zdrojom z interných protokolov odovzdania.
- Zabráňte interným zmenám, ktoré porušujú zostavy s otvoreným zdrojom .
Nasledujúce podkapitoly sa budú ponoriť do vyššie uvedených funkcií, ktoré majú zaujímavé problémy.
Synchronizácia zdrojového kódu
Na rozdiel od verzie DataHub s otvoreným zdrojovým kódom, ktorá je jediným úložiskom GitHub, verzia LinkedIn DataHub je kombináciou viacerých úložísk (nazývaných interne ). Rozhranie DataHub, knižnica modelov metadát, backendová služba skladu metadát a úlohy streamovania sa nachádzajú v samostatných úložiskách na LinkedIn. Aby sme to však používateľom s otvoreným zdrojovým kódom uľahčili, máme pre open source verziu DataHubu jedno úložisko.
Obrázok 1: Synchronizácia medzi úložiskami LinkedIn DataHub a jediné úložisko DataHub otvorený zdroj
Náš nový nástroj automaticky vytvorí mapovanie na úrovni súboru zodpovedajúce každému zdrojovému súboru, aby sme podporili automatizované pracovné postupy zostavovania, push a pull. Súprava nástrojov však vyžaduje počiatočnú konfiguráciu a používatelia musia poskytnúť mapovanie modulov na vysokej úrovni, ako je uvedené nižšie.
{
"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"
]
}Mapovanie na úrovni modulu je jednoduchý JSON, ktorého kľúče sú cieľové moduly v úložisku s otvoreným zdrojovým kódom a hodnoty predstavujú zoznam zdrojových modulov v úložiskách LinkedIn. Akýkoľvek cieľový modul v úložisku s otvoreným zdrojovým kódom môže byť napájaný ľubovoľným počtom zdrojových modulov. Ak chcete uviesť interné názvy archívov v zdrojových moduloch, použite v štýle Bash. Pomocou mapovacieho súboru na úrovni modulu nástroje vytvárajú mapovací súbor na úrovni súboru skenovaním všetkých súborov v priradených adresároch.
{
"${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,
}Mapovanie úrovne súboru je automaticky vytvorené nástrojmi; používateľ ho však môže aktualizovať aj manuálne. Toto je mapovanie zdrojového súboru LinkedIn v pomere 1:1 na súbor v úložisku otvoreného zdroja. S týmto automatickým vytváraním asociácií súborov je spojených niekoľko pravidiel:
- V prípade viacerých zdrojových modulov pre cieľový modul v open source môžu nastať konflikty, napr. existujúci vo viac ako jednom zdrojovom module. Ako stratégiu riešenia konfliktov naše nástroje predvolene používajú možnosť „posledný vyhráva“.
- „null“ znamená, že zdrojový súbor nie je súčasťou úložiska s otvoreným zdrojovým kódom.
- Po každom odoslaní alebo extrakcii otvoreného zdroja sa toto mapovanie automaticky aktualizuje a vytvorí sa snímka. Je to potrebné na identifikáciu pridania a vymazania zo zdrojového kódu od poslednej akcie.
Vytváranie protokolov odovzdania
Protokoly odovzdania pre odovzdania s otvoreným zdrojom sa tiež automaticky generujú zlúčením protokolov odovzdania interných repozitárov. Nižšie je uvedený vzorový protokol odovzdania, ktorý zobrazuje štruktúru protokolu odovzdania vygenerovaného naším nástrojom. Potvrdenie jasne uvádza, ktoré verzie zdrojových archívov sú zabalené v tomto odovzdaní, a poskytuje súhrn protokolu odovzdania. Pozrite si toto pomocou skutočného príkladu protokolu odovzdania vygenerovaného našou súpravou nástrojov.
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.0Testovanie závislosti
LinkedIn má , ktorá pomáha zabezpečiť, aby zmeny interného multiproduktu nenarušili zostavu závislých multiproduktov. Úložisko DataHub s otvoreným zdrojovým kódom nie je viacproduktové a nemôže byť priamou závislosťou od žiadneho z viacerých produktov, ale s pomocou obalu viacerých produktov, ktorý načítava zdrojový kód DataHub s otvoreným zdrojovým kódom, môžeme stále používať toto testovanie závislosti. Akákoľvek zmena (ktorá môže byť neskôr odhalená) na ktoromkoľvek z multiproduktov, ktoré napájajú open source úložisko DataHub, spúšťa udalosť zostavenia v multiprodukte shellu. Preto každá zmena, pri ktorej sa nepodarí vytvoriť obalový produkt, neprejde testami pred odovzdaním pôvodného produktu a vráti sa späť.
Toto je užitočný mechanizmus, ktorý pomáha predchádzať akémukoľvek internému odovzdaniu, ktoré naruší zostavenie otvoreného zdroja a zistí ho v čase odovzdania. Bez toho by bolo dosť ťažké určiť, ktoré interné potvrdenie spôsobilo zlyhanie zostavenia úložiska s otvoreným zdrojovým kódom, pretože interné zmeny v úložisku s otvoreným zdrojom DataHub dávkujeme.
Rozdiely medzi open source DataHub a našou produkčnou verziou
Až do tohto bodu sme diskutovali o našom riešení na synchronizáciu dvoch verzií DataHub úložísk, ale stále sme nenačrtli dôvody, prečo v prvom rade potrebujeme dva rôzne vývojové prúdy. V tejto časti uvedieme rozdiely medzi verejnou verziou DataHubu a produkčnou verziou na serveroch LinkedIn a vysvetlíme dôvody týchto rozdielov.
Jeden zdroj nezrovnalostí pramení zo skutočnosti, že naša produkčná verzia má závislosti od kódu, ktorý ešte nie je otvoreným zdrojom, ako napríklad LinkedIn's Offspring (interný rámec na vkladanie závislostí LinkedIn). Offspring je široko používaný v interných kódových základniach, pretože je to preferovaná metóda na správu dynamickej konfigurácie. Ale nie je to open source; takže sme potrebovali nájsť open source alternatívy k open source DataHub.
Existujú aj iné dôvody. Keďže vytvárame rozšírenia modelu metadát pre potreby LinkedIn, tieto rozšírenia sú zvyčajne veľmi špecifické pre LinkedIn a nemusia sa priamo vzťahovať na iné prostredia. Máme napríklad veľmi špecifické štítky pre ID účastníkov a iné typy zodpovedajúcich metadát. Teraz sme teda tieto rozšírenia vylúčili z modelu metadát s otvoreným zdrojom DataHub. Keď sa zapojíme do komunity a pochopíme jej potreby, budeme v prípade potreby pracovať na spoločných verziách týchto rozšírení s otvoreným zdrojom.
Jednoduché použitie a jednoduchšie prispôsobenie pre komunitu s otvoreným zdrojovým kódom tiež inšpirovalo niektoré rozdiely medzi týmito dvoma verziami DataHub. Rozdiely v infraštruktúre spracovania toku sú toho dobrým príkladom. Aj keď naša interná verzia používa riadený rámec na spracovanie toku, rozhodli sme sa použiť vstavané (samostatné) spracovanie toku pre verziu s otvoreným zdrojovým kódom, pretože to zabraňuje vytváraniu ďalšej závislosti na infraštruktúre.
Ďalším príkladom rozdielu je mať jeden GMS (Generalized Metadata Store) v implementácii s otvoreným zdrojom namiesto viacerých GMS. GMA (Generalized Metadata Architecture) je názov back-end architektúry pre DataHub a GMS je úložisko metadát v kontexte GMA. GMA je veľmi flexibilná architektúra, ktorá vám umožňuje distribuovať každý dátový konštrukt (napr. množiny údajov, používateľov atď.) do vlastného úložiska metadát alebo ukladať viacero konštruktov údajov do jedného úložiska metadát, pokiaľ register obsahuje mapovanie štruktúry údajov v GMS je aktualizovaný. Pre jednoduché používanie sme vybrali jedinú inštanciu GMS, ktorá ukladá všetky rôzne dátové konštrukcie v otvorenom zdroji DataHub.
Úplný zoznam rozdielov medzi týmito dvoma implementáciami je uvedený v tabuľke nižšie.
Vlastnosti produktu
LinkedIn DataHub
Open Source DataHub
Podporované dátové konštrukcie
1) Množiny údajov 2) Používatelia 3) Metriky 4) Funkcie ML 5) Grafy 6) Informačné panely
1) Súbory údajov 2) Používatelia
Podporované zdroje metadát pre množiny údajov
1) 2) Pohovka 3) 4) 5) HDFS 6) Úľ 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Úľ Kafka RDBMS
Pub-sub
Splývajúci Kafka
Spracovanie toku
Organizovaný
Vložené (samostatné)
Dependency Injection & Dynamic Configuration
LinkedIn Offspring
Build Tooling
Ligradle (interný obal Gradle na LinkedIn)
CI / CD
CRT (interné CI/CD LinkedIn)
a
Úložisko metadát
Distribuované viaceré GMS: 1) GMS množiny údajov 2) Používateľské GMS 3) Metrické GMS 4) Hlavné GMS 5) Graf/Dashboard GMS
Jediný GMS pre: 1) množiny údajov 2) používateľov
Mikroslužby v kontajneroch Docker
zjednodušuje nasadenie a distribúciu aplikácií s . Každá časť služby v DataHub je open source, vrátane komponentov infraštruktúry ako Kafka, , и , má svoj vlastný obrázok Docker. Na organizáciu kontajnerov Docker, ktoré sme použili .
Obrázok 2: Architektúra DataHub *otvorený zdroj**
Na obrázku vyššie môžete vidieť architektúru DataHub na vysokej úrovni. Okrem komponentov infraštruktúry má štyri rôzne kontajnery Docker:
datahub-gms: služba ukladania metadát
datahub-frontend: aplikácia , slúžiace na rozhranie DataHub.
datahub-mce-consumer: aplikácia , ktorý používa stream udalosti zmeny metadát (MCE) a aktualizuje úložisko metadát.
datahub-mae-consumer: aplikácia , ktorý používa tok udalostí auditu metadát (MAE) a vytvára databázu indexov vyhľadávania a grafov.
Dokumentácia k úložisku s otvoreným zdrojovým kódom a obsahujú podrobnejšie informácie o funkciách rôznych služieb.
CI/CD na DataHub je open source
Používa sa open source úložisko DataHub pre nepretržitú integráciu a pre nepretržité nasadenie. Oba majú dobrú integráciu GitHub a ľahko sa nastavujú. Pre väčšinu open source infraštruktúry vyvinutej komunitou alebo súkromnými spoločnosťami (napr. ), Obrazy Docker sa vytvárajú a nasadzujú do centra Docker, aby ich komunita mohla jednoducho používať. Akýkoľvek obrázok Docker nájdený v Docker Hub možno ľahko použiť pomocou jednoduchého príkazu .
S každým odovzdaním do úložiska s otvoreným zdrojom DataHub sa všetky obrázky Docker automaticky zostavia a nasadia do centra Docker s najnovšou značkou. Ak je Docker Hub nakonfigurovaný s niektorými , všetky značky v úložisku s otvoreným zdrojovým kódom sú tiež uvoľnené so zodpovedajúcimi názvami značiek v Docker Hub.
Pomocou DataHubu
je veľmi jednoduchý a pozostáva z troch jednoduchých krokov:
- Naklonujte úložisko otvoreného zdroja a spustite všetky kontajnery Docker s docker-compose pomocou poskytnutého skriptu docker-compose pre rýchly štart.
- Stiahnite si vzorové údaje poskytnuté v úložisku pomocou nástroja príkazového riadka, ktorý je tiež k dispozícii.
- Prehľadávajte DataHub vo svojom prehliadači.
Aktívne sledované nakonfigurovaný aj na rýchle otázky. Používatelia môžu tiež vytvárať problémy priamo v úložisku GitHub. A čo je najdôležitejšie, vítame a vážime si každú spätnú väzbu a návrhy!
Plány do budúcnosti
V súčasnosti je každá infraštruktúra alebo mikroslužba pre open source DataHub postavená ako kontajner Docker a celý systém je riadený pomocou . Vzhľadom na popularitu a rozšírenosť , v blízkej budúcnosti by sme tiež radi poskytli riešenie založené na Kubernetes.
Plánujeme tiež poskytnúť riešenie na kľúč pre nasadenie DataHubu na verejnej cloudovej službe ako napr , alebo . Vzhľadom na nedávne oznámenie o migrácii LinkedIn na Azure to bude v súlade s internými prioritami tímu metadát.
V neposlednom rade ďakujeme všetkým prvým používateľom DataHub v komunite s otvoreným zdrojom, ktorí hodnotili DataHub alfa a pomohli nám identifikovať problémy a zlepšiť dokumentáciu.
Zdroj: hab.com