Oopbron DataHub: LinkedIn Metadata Search and Discovery Platform
Dit is noodsaaklik om vinnig die data te vind wat jy nodig het vir enige maatskappy wat staatmaak op groot hoeveelhede data om data-gedrewe besluite te neem. Nie net het dit 'n impak op die produktiwiteit van datagebruikers (insluitend ontleders, masjienleerontwikkelaars, datawetenskaplikes en data-ingenieurs nie), maar dit het ook 'n direkte impak op die eindprodukte wat afhanklik is van 'n kwaliteit masjienleer (ML) pyplyn. Boonop laat die neiging na die implementering of bou van masjienleerplatforms natuurlik die vraag ontstaan: wat is jou metode om kenmerke, modelle, statistieke, datastelle, ens intern te ontdek.
In hierdie artikel sal ons praat oor hoe ons 'n databron onder 'n oop lisensie gepubliseer het in ons metadata-soek- en ontdekkingsplatform, vanaf die vroeë dae van die projek . LinkedIn onderhou sy eie weergawe van DataHub apart van die oopbronweergawe. Ons sal begin deur te verduidelik hoekom ons twee afsonderlike ontwikkelingsomgewings nodig het, bespreek dan vroeë benaderings tot die gebruik van die oopbron WhereHows en vergelyk ons interne (produksie) weergawe van DataHub met die weergawe op . Ons sal ook besonderhede deel oor ons nuwe outomatiese oplossing vir die stoot en ontvang van oopbronopdaterings om beide bewaarplekke gesinchroniseer te hou. Ten slotte sal ons instruksies verskaf oor hoe om die oopbron DataHub te begin gebruik en kortliks die argitektuur daarvan bespreek.
WhereHows is nou 'n DataHub!
LinkedIn se metadata-span wat voorheen aangebied is (opvolger van WhereHows), LinkedIn se soek- en metadata-ontdekkingsplatform, en gedeelde planne om dit oop te maak. Kort na hierdie aankondiging het ons 'n alfa-weergawe van DataHub vrygestel en dit met die gemeenskap gedeel. Sedertdien het ons voortdurend bygedra tot die bewaarplek en saam met belangstellende gebruikers gewerk om die mees gevraagde kenmerke by te voeg en probleme op te los. Ons is nou bly om die amptelike vrystelling aan te kondig .
Oopbronbenaderings
WhereHows, LinkedIn se oorspronklike portaal om data te vind en waar dit vandaan kom, het as 'n interne projek begin; die metadata-span het dit oopgemaak . Sedertdien het die span nog altyd twee verskillende kodebasisse gehandhaaf—een vir oopbron en een vir LinkedIn se interne gebruik—aangesien nie alle produkkenmerke wat vir LinkedIn-gebruiksgevalle ontwikkel is oor die algemeen van toepassing was op die breër gehoor nie. Daarbenewens het WhereHows 'n paar interne afhanklikhede (infrastruktuur, biblioteke, ens.) wat nie oopbron is nie. In die daaropvolgende jare het WhereHows deur baie iterasies en ontwikkelingsiklusse gegaan, wat dit 'n groot uitdaging gemaak het om die twee kodebasisse sinchroniseer te hou. Die metadata-span het oor die jare verskillende benaderings probeer om interne en oopbron-ontwikkeling gesinchroniseer te hou.
Eerste probeerslag: "Open source eerste"
Ons het aanvanklik 'n "oopbron-eerste"-ontwikkelingsmodel gevolg, waar die meeste ontwikkeling in 'n oopbronbewaarplek plaasvind en veranderinge gemaak word vir interne ontplooiing. Die probleem met hierdie benadering is dat die kode altyd eers na GitHub gedruk word voordat dit intern volledig hersien is. Totdat veranderinge vanaf die oopbronbewaarplek gemaak word en 'n nuwe interne ontplooiing gemaak word, sal ons geen produksieprobleme vind nie. In die geval van swak ontplooiing was dit ook baie moeilik om die skuldige te bepaal omdat veranderinge in groepe aangebring is.
Boonop het hierdie model die span se produktiwiteit verminder wanneer nuwe kenmerke ontwikkel word wat vinnige herhalings vereis het, aangesien dit gedwing het om alle veranderinge eers in 'n oopbron-bewaarplek in te stoot en dan na 'n interne bewaarplek gedruk te word. Om die verwerkingstyd te verminder, kon die vereiste regstelling of verandering eers in die interne bewaarplek gedoen word, maar dit het 'n groot probleem geword toe dit kom by die samevoeging van daardie veranderinge terug in die oopbronbewaarplek omdat die twee bewaarplekke nie gesinchroniseer was nie.
Hierdie model is baie makliker om te implementeer vir gedeelde platforms, biblioteke of infrastruktuurprojekte as vir gepasmaakte webtoepassings met volledige funksies. Boonop is hierdie model ideaal vir projekte wat oopbron vanaf dag een begin, maar WhereHows is gebou as 'n heeltemal interne webtoepassing. Dit was regtig moeilik om al die interne afhanklikhede heeltemal te onttrek, so ons moes die interne vurk behou, maar om die interne vurk te behou en meestal oopbron te ontwikkel, het nie heeltemal uitgewerk nie.
Tweede poging: “Innere eerste”
**As 'n tweede poging het ons na 'n "interne eerste" ontwikkelingsmodel beweeg, waar die meeste ontwikkeling intern plaasvind en veranderinge op 'n gereelde basis aan die oopbronkode aangebring word. Alhoewel hierdie model die beste geskik is vir ons gebruiksgeval, het dit inherente probleme. Om alle verskille direk na die oopbronbewaarplek te stoot en dan later saamsmeltkonflikte te probeer oplos is 'n opsie, maar dit is tydrowend. Ontwikkelaars probeer in die meeste gevalle om dit nie te doen elke keer as hulle hul kode hersien nie. Gevolglik sal dit baie minder gereeld gedoen word, in bondels, en dit maak dit dus moeiliker om samesmeltingskonflikte later op te los.
Die derde keer het dit gewerk!
Die twee mislukte pogings wat hierbo genoem is, het daartoe gelei dat die WhereHows GitHub-bewaarplek vir 'n lang tyd verouderd gebly het. Die span het voortgegaan om die produk se kenmerke en argitektuur te verbeter, sodat die interne weergawe van WhereHows vir LinkedIn meer gevorderd geword het as die oopbronweergawe. Dit het selfs 'n nuwe naam gehad - DataHub. Op grond van vorige mislukte pogings het die span besluit om 'n skaalbare, langtermynoplossing te ontwikkel.
Vir enige nuwe oopbronprojek adviseer en ondersteun LinkedIn se oopbronspan 'n ontwikkelingsmodel waarin die projek se modules geheel en al in oopbron ontwikkel word. Weergawe artefakte word na 'n publieke bewaarplek ontplooi en dan teruggeboek na die interne LinkedIn-artefak met behulp van . Om hierdie ontwikkelingsmodel te volg, is nie net goed vir diegene wat oopbron gebruik nie, maar lei ook tot 'n meer modulêre, uitbreidbare en inpropbare argitektuur.
'n Volwasse back-end-toepassing soos DataHub sal egter 'n aansienlike hoeveelheid tyd benodig om hierdie toestand te bereik. Dit sluit ook die moontlikheid uit om 'n volledig werkende implementering oop te verkry voordat alle interne afhanklikhede ten volle geabstraheer is. Daarom het ons nutsmiddels ontwikkel wat ons help om oopbronbydraes vinniger en met baie minder pyn te maak. Hierdie oplossing bevoordeel beide die metadata-span (DataHub-ontwikkelaar) en die oopbrongemeenskap. Die volgende afdelings sal hierdie nuwe benadering bespreek.
Oopbron-publiseringoutomatisering
Die Metadata-span se jongste benadering tot die oopbron DataHub is om 'n instrument te ontwikkel wat die interne kodebasis en die oopbronbewaarplek outomaties sinkroniseer. Hoëvlakkenmerke van hierdie gereedskapstel sluit in:
- Sinkroniseer LinkedIn-kode na/van oopbron, soortgelyk .
- Generasie van lisensiekopskrif, soortgelyk aan .
- Genereer outomaties oopbron-toewysingslogboeke vanaf interne toewysingslogboeke.
- Voorkom interne veranderinge wat oopbronbou deurbreek .
Die volgende onderafdelings sal in die bogenoemde funksies delf wat interessante probleme het.
Bronkode sinchronisasie
Anders as die oopbron-weergawe van DataHub, wat 'n enkele GitHub-bewaarplek is, is die LinkedIn-weergawe van DataHub 'n kombinasie van veelvuldige bewaarplekke (intern genoem ). Die DataHub-koppelvlak, metadatamodelbiblioteek, metadatapakhuis-agtergronddiens en stroomtake is in aparte bewaarplekke op LinkedIn. Om dit egter vir oopbrongebruikers makliker te maak, het ons 'n enkele bewaarplek vir die oopbronweergawe van DataHub.
Figuur 1: Sinchronisasie tussen bewaarplekke LinkedIn DataHub en 'n enkele bewaarplek DataHub oop bron
Om outomatiese bou-, druk- en trekwerkvloei te ondersteun, skep ons nuwe hulpmiddel outomaties 'n lêervlak-kartering wat ooreenstem met elke bronlêer. Die gereedskapstel vereis egter aanvanklike konfigurasie en gebruikers moet 'n hoëvlak module-kartering verskaf soos hieronder getoon.
{
"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"
]
}Die modulevlak-kartering is 'n eenvoudige JSON waarvan die sleutels die teikenmodules in die oopbronbewaarplek is en die waardes die lys bronmodules in die LinkedIn-bewaarplekke is. Enige teikenmodule in 'n oopbronbewaarplek kan deur enige aantal bronmodules gevoer word. Om die interne name van bewaarplekke in bronmodules aan te dui, gebruik in Bash-styl. Met behulp van 'n module-vlak kartering lêer, die gereedskap skep 'n lêer-vlak kartering lêer deur alle lêers in geassosieerde dopgehou te skandeer.
{
"${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,
}Die lêervlakkartering word outomaties deur die gereedskap geskep; dit kan egter ook handmatig deur die gebruiker opgedateer word. Dit is 'n 1:1-kartering van 'n LinkedIn-bronlêer na 'n lêer in die oopbronbewaarplek. Daar is verskeie reëls wat verband hou met hierdie outomatiese skepping van lêerassosiasies:
- In die geval van veelvuldige bronmodules vir 'n teikenmodule in oopbron, kan konflikte ontstaan, bv. , wat in meer as een bronmodule bestaan. As 'n konflikoplossingstrategie, is ons gereedskap verstek na die opsie "laaste een wen".
- "nul" beteken dat die bronlêer nie deel is van die oopbronbewaarplek nie.
- Na elke open source indiening of onttrekking, word hierdie kartering outomaties opgedateer en 'n momentopname word geskep. Dit is nodig om toevoegings en skrappings van bronkode sedert die laaste aksie te identifiseer.
Skep commit logs
Commit logs vir oopbron commits word ook outomaties gegenereer deur die commit logs van interne bewaarplekke saam te voeg. Hieronder is 'n voorbeeld van 'n commit-logboek om die struktuur van die commit-log wat deur ons instrument gegenereer word, te wys. 'n Toewysing dui duidelik aan watter weergawes van die bronbewaarplekke in daardie toewysing verpak is en verskaf 'n opsomming van die toewysingslogboek. Check hierdie een uit met behulp van 'n werklike voorbeeld van 'n commit log gegenereer deur ons toolkit.
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.0Afhanklikheidstoetsing
LinkedIn het , wat help verseker dat veranderinge aan 'n interne multiproduk nie die samestelling van afhanklike multiprodukte breek nie. Die oopbron DataHub-bewaarplek is nie multi-produk nie, en dit kan nie 'n direkte afhanklikheid van enige multi-produk wees nie, maar met die hulp van 'n multi-produk omhulsel wat die oopbron DataHub bronkode haal, kan ons steeds hierdie afhanklikheidstoets gebruik Dus, enige verandering (wat later blootgestel kan word) aan enige van die multiprodukte wat die oopbron DataHub-bewaarplek voed, veroorsaak 'n bougebeurtenis in die dop-multiproduk. Daarom, enige verandering wat nie daarin slaag om 'n omhulproduk te bou nie, druip die toetse voordat die oorspronklike produk toegepas word en word teruggekeer.
Dit is 'n nuttige meganisme wat help om enige interne commit te voorkom wat die oopbronbou breek en dit op commit-tyd bespeur. Sonder dit sou dit nogal moeilik wees om te bepaal watter interne commit veroorsaak het dat die oopbronbewaarplekbou misluk het, want ons het interne veranderinge aan die DataHub oopbronbewaarplek saamgevoeg.
Verskille tussen oopbron DataHub en ons produksieweergawe
Tot op hierdie stadium het ons ons oplossing vir die sinchronisering van twee weergawes van DataHub-bewaarplekke bespreek, maar ons het steeds nie die redes uiteengesit waarom ons in die eerste plek twee verskillende ontwikkelingstrome benodig nie. In hierdie afdeling sal ons die verskille tussen die publieke weergawe van DataHub en die produksieweergawe op LinkedIn-bedieners lys, en die redes vir hierdie verskille verduidelik.
Een bron van teenstrydigheid spruit uit die feit dat ons produksieweergawe afhanklikhede het van kode wat nog nie oopbron is nie, soos LinkedIn se Offspring (LinkedIn se interne afhanklikheidsinspuitingsraamwerk). Nageslag word wyd gebruik in interne kodebasisse omdat dit die voorkeurmetode is om dinamiese konfigurasie te bestuur. Maar dit is nie oopbron nie; daarom moes ons oopbron-alternatiewe vir die oopbron-DataHub vind.
Daar is ook ander redes. Aangesien ons uitbreidings vir die metadatamodel vir LinkedIn se behoeftes skep, is hierdie uitbreidings tipies baie spesifiek vir LinkedIn en is dit dalk nie direk van toepassing op ander omgewings nie. Ons het byvoorbeeld baie spesifieke etikette vir deelnemer-ID's en ander soorte ooreenstemmende metadata. Dus, ons het nou hierdie uitbreidings uitgesluit van DataHub se oopbron-metadatamodel. Terwyl ons met die gemeenskap inskakel en hul behoeftes verstaan, sal ons aan algemene oopbronweergawes van hierdie uitbreidings werk waar nodig.
Gebruiksgemak en makliker aanpassing vir die oopbrongemeenskap het ook sommige van die verskille tussen die twee weergawes van DataHub geïnspireer. Verskille in stroomverwerkingsinfrastruktuur is 'n goeie voorbeeld hiervan. Alhoewel ons interne weergawe 'n bestuurde stroomverwerkingsraamwerk gebruik, het ons gekies om ingeboude (selfstandige) stroomverwerking vir die oopbronweergawe te gebruik, want dit vermy die skep van 'n ander infrastruktuurafhanklikheid.
Nog 'n voorbeeld van die verskil is om 'n enkele GMS (Generalized Metadata Store) in 'n oopbronimplementering te hê eerder as veelvuldige GMS'e. GMA (Generalized Metadata Architecture) is die naam van die back-end-argitektuur vir DataHub, en GMS is die metadata-stoor in die konteks van GMA. GMA is 'n baie buigsame argitektuur wat jou toelaat om elke datakonstruksie (bv. datastelle, gebruikers, ens.) in sy eie metadata-stoor te versprei, of om veelvuldige datakonstruksies in 'n enkele metadata-stoor te stoor solank die register wat die datastruktuurkartering bevat in GMS is opgedateer. Vir gebruiksgemak het ons 'n enkele GMS-instansie gekies wat al die verskillende datakonstruksies in die oopbron DataHub stoor.
'n Volledige lys van verskille tussen die twee implementerings word in die tabel hieronder gegee.
Product Features
LinkedIn DataHub
Oopbron DataHub
Ondersteunde datakonstruksies
1) Datastelle 2) Gebruikers 3) Metrieke 4) ML-kenmerke 5) Grafieke 6) Dashboards
1) Datastelle 2) Gebruikers
Ondersteunde metadatabronne vir datastelle
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Korf Kafka RDBMS
Pub-sub
Samevloeiende Kafka
Stroomverwerking
Bestuur
Ingebed (selfstandig)
Afhanklikheidsinspuiting en dinamiese konfigurasie
LinkedIn Nageslag
Bou gereedskap
Ligradle (LinkedIn se interne Gradle-omhulsel)
CI / CD
CRT (LinkedIn se interne CI/CD)
en
Metadatawinkels
Verspreide veelvuldige GMS: 1) Datastel GMS 2) Gebruiker GMS 3) Metrieke GMS 4) Funksie GMS 5) Grafiek/Dashboard GMS
Enkele GMS vir: 1) Datastelle 2) Gebruikers
Mikrodienste in Docker-houers
vereenvoudig toepassing ontplooiing en verspreiding met . Elke deel van die diens in DataHub is oopbron, insluitend infrastruktuurkomponente soos Kafka, , и , het sy eie Docker-beeld. Ons het gebruik om Docker-houers te orkestreer .
Figuur 2: Argitektuur DataHub *oop bron**
U kan die hoëvlak-argitektuur van DataHub in die prent hierbo sien. Benewens die infrastruktuurkomponente, het dit vier verskillende Docker-houers:
datahub-gms: metadatabergingsdiens
datahub-frontend: toepassing , wat die DataHub-koppelvlak bedien.
datahub-mce-consumer: toepassing , wat die metadata change event (MCE) stroom gebruik en die metadata stoor opdateer.
datahub-mae-consumer: toepassing , wat 'n metadata-ouditgebeurtenisstroom (MAE) gebruik en 'n soekindeks en grafiekdatabasis skep.
Oopbron-bewaarplekdokumentasie en bevat meer gedetailleerde inligting oor die funksies van verskeie dienste.
CI/CD op DataHub is oopbron
Die oopbron DataHub-bewaarplek gebruik vir deurlopende integrasie en vir deurlopende ontplooiing. Albei het goeie GitHub-integrasie en is maklik om op te stel. Vir die meeste oopbron-infrastruktuur wat deur die gemeenskap of private maatskappye ontwikkel is (bv. ), Docker-beelde word geskep en na Docker Hub ontplooi vir die gemak van gebruik deur die gemeenskap. Enige Docker-prent wat in Docker Hub gevind word, kan maklik met 'n eenvoudige opdrag gebruik word .
Met elke verbintenis tot die DataHub oopbronbewaarplek, word alle Docker-beelde outomaties gebou en na Docker Hub ontplooi met die "nuutste" merker. As Docker Hub gekonfigureer is met sommige , word alle merkers in die oopbronbewaarplek ook vrygestel met ooreenstemmende merkername in Docker Hub.
Gebruik DataHub
is baie eenvoudig en bestaan uit drie eenvoudige stappe:
- Kloon die oopbronbewaarplek en voer alle Docker-houers met docker-compose uit met behulp van die verskafde docker-compose-skrip vir 'n vinnige begin.
- Laai die voorbeelddata af wat in die bewaarplek verskaf word met behulp van die opdragreëlinstrument wat ook verskaf word.
- Blaai deur DataHub in jou blaaier.
Aktief nagespoor ook opgestel vir vinnige vrae. Gebruikers kan ook probleme direk in die GitHub-bewaarplek skep. Die belangrikste is dat ons alle terugvoer en voorstelle verwelkom en waardeer!
Planne vir die toekoms
Tans is elke infrastruktuur of mikrodiens vir oopbron DataHub gebou as 'n Docker-houer, en die hele stelsel word georkestreer met . Gegewe die gewildheid en wydverspreide , wil ons ook in die nabye toekoms 'n Kubernetes-gebaseerde oplossing verskaf.
Ons beplan ook om 'n sleuteloplossing te verskaf vir die implementering van DataHub op 'n publieke wolkdiens soos , of . Gegewe die onlangse aankondiging van LinkedIn se migrasie na Azure, sal dit ooreenstem met die metadata-span se interne prioriteite.
Laastens, maar nie die minste nie, dankie aan al die vroeë aannemers van DataHub in die oopbrongemeenskap wat DataHub-alfas gegradeer het en ons gehelp het om probleme te identifiseer en dokumentasie te verbeter.
Bron: will.com