Open Source DataHub: LinkedIn Metadata Search and Discovery Platform
Å finne dataene du trenger raskt er avgjørende for ethvert selskap som er avhengig av store datamengder for å ta datadrevne beslutninger. Ikke bare påvirker dette produktiviteten til databrukere (inkludert analytikere, maskinlæringsutviklere, dataforskere og dataingeniører), men det har også en direkte innvirkning på sluttproduktene som er avhengige av en pipeline for maskinlæring av høy kvalitet (ML). I tillegg reiser trenden mot å implementere eller bygge maskinlæringsplattformer naturligvis spørsmålet: hva er din metode for internt å oppdage funksjoner, modeller, beregninger, datasett, etc.
I denne artikkelen vil vi snakke om hvordan vi publiserte en datakilde under en åpen lisens i vår metadatasøk- og oppdagelsesplattform, fra begynnelsen av prosjektet . LinkedIn opprettholder sin egen versjon av DataHub separat fra åpen kildekode-versjonen. Vi starter med å forklare hvorfor vi trenger to separate utviklingsmiljøer, og diskuterer deretter tidlige tilnærminger til bruk av åpen kildekode WhereHows og sammenligner vår interne (produksjons)versjon av DataHub med versjonen på . Vi vil også dele detaljer om vår nye automatiserte løsning for å skyve og motta åpen kildekodeoppdateringer for å holde begge depotene synkronisert. Til slutt vil vi gi instruksjoner om hvordan du kommer i gang med å bruke åpen kildekode DataHub og kort diskutere arkitekturen.
WhereHows er nå en DataHub!
LinkedIns metadatateam tidligere presentert (etterfølger til WhereHows), LinkedIns søke- og metadataoppdagingsplattform og delte planer om å åpne den. Kort tid etter denne kunngjøringen ga vi ut en alfaversjon av DataHub og delte den med fellesskapet. Siden den gang har vi kontinuerlig bidratt til depotet og jobbet med interesserte brukere for å legge til de mest etterspurte funksjonene og løse problemer. Vi er nå glade for å kunngjøre den offisielle utgivelsen .
Åpen kildekode-tilnærminger
WhereHows, LinkedIns originale portal for å finne data og hvor de kommer fra, startet som et internt prosjekt; metadatateamet åpnet den . Siden den gang har teamet alltid opprettholdt to forskjellige kodebaser – én for åpen kildekode og én for LinkedIns intern bruk – ettersom ikke alle produktfunksjoner utviklet for brukstilfeller for LinkedIn var generelt anvendelige for et bredere publikum. I tillegg har WhereHows noen interne avhengigheter (infrastruktur, biblioteker, etc.) som ikke er åpen kildekode. I årene som fulgte gikk WhereHows gjennom mange iterasjoner og utviklingssykluser, noe som gjorde det til en stor utfordring å holde de to kodebasene synkronisert. Metadatateamet har prøvd forskjellige tilnærminger gjennom årene for å prøve å holde intern og åpen kildekodeutvikling synkronisert.
Første forsøk: "Åpen kildekode først"
Vi fulgte i utgangspunktet en "open source first"-utviklingsmodell, der mesteparten av utviklingen skjer i et åpen kildekodelager og endringer gjøres for intern distribusjon. Problemet med denne tilnærmingen er at koden alltid blir sendt til GitHub først før den har blitt fullstendig gjennomgått internt. Inntil endringer er gjort fra åpen kildekode-repositoriet og en ny intern distribusjon er gjort, vil vi ikke finne noen produksjonsproblemer. Ved dårlig utplassering var det også svært vanskelig å fastslå den skyldige fordi endringer ble gjort i partier.
I tillegg reduserte denne modellen teamets produktivitet når de utviklet nye funksjoner som krevde raske iterasjoner, siden den tvang alle endringer til først å bli presset inn i et åpen kildekodelager og deretter til et internt depot. For å redusere behandlingstiden kunne den nødvendige reparasjonen eller endringen gjøres i det interne depotet først, men dette ble et stort problem når det kom til å slå sammen disse endringene tilbake til åpen kildekode-depotet fordi de to depotene var ute av synkronisering.
Denne modellen er mye enklere å implementere for delte plattformer, biblioteker eller infrastrukturprosjekter enn for tilpassede nettapplikasjoner med alle funksjoner. I tillegg er denne modellen ideell for prosjekter som starter åpen kildekode fra dag én, men WhereHows ble bygget som en helt intern webapplikasjon. Det var virkelig vanskelig å fullstendig abstrahere alle interne avhengigheter, så vi trengte å beholde den interne gaffelen, men å beholde den interne gaffelen og utvikle stort sett åpen kildekode fungerte ikke helt.
Andre forsøk: "Indre først"
**Som et andre forsøk gikk vi over til en "intern først" utviklingsmodell, der mesteparten av utviklingen skjer internt og endringer gjøres i den åpne kildekoden med jevne mellomrom. Selv om denne modellen er best egnet for vårt bruksområde, har den iboende problemer. Å skyve alle forskjeller direkte til åpen kildekodelagret og deretter prøve å løse flettekonflikter senere er et alternativ, men det er tidkrevende. Utviklere prøver i de fleste tilfeller å ikke gjøre dette hver gang de gjennomgår koden sin. Som et resultat vil dette gjøres mye sjeldnere, i batch, og dermed gjøre det vanskeligere å løse sammenslåingskonflikter senere.
Tredje gang fungerte det!
De to mislykkede forsøkene nevnt ovenfor resulterte i at WhereHows GitHub-depotet forble utdatert i lang tid. Teamet fortsatte å forbedre produktets funksjoner og arkitektur, slik at den interne versjonen av WhereHows for LinkedIn ble mer avansert enn åpen kildekode-versjonen. Den hadde til og med et nytt navn - DataHub. Basert på tidligere mislykkede forsøk bestemte teamet seg for å utvikle en skalerbar, langsiktig løsning.
For ethvert nytt åpen kildekode-prosjekt gir LinkedIns åpen kildekode-team råd og støtter en utviklingsmodell der prosjektets moduler er utviklet utelukkende i åpen kildekode. Versjonsartefakter distribueres til et offentlig depot og sjekkes deretter tilbake til en intern LinkedIn-artefakt ved hjelp av . Å følge denne utviklingsmodellen er ikke bare bra for de som bruker åpen kildekode, men resulterer også i en mer modulær, utvidbar og pluggbar arkitektur.
Imidlertid vil en moden back-end-applikasjon som DataHub kreve en betydelig mengde tid for å nå denne tilstanden. Dette utelukker også muligheten for åpen kilde til en fullt fungerende implementering før alle interne avhengigheter er fullstendig abstrahert. Det er derfor vi har utviklet verktøy som hjelper oss å gi åpen kildekode-bidrag raskere og med mye mindre smerte. Denne løsningen kommer både metadatateamet (DataHub-utvikler) og åpen kildekode-fellesskapet til gode. De følgende avsnittene vil diskutere denne nye tilnærmingen.
Publiseringsautomatisering med åpen kildekode
Metadata-teamets siste tilnærming til åpen kildekode DataHub er å utvikle et verktøy som automatisk synkroniserer den interne kodebasen og åpen kildekodelagret. Høynivåfunksjoner i dette verktøysettet inkluderer:
- Synkroniser LinkedIn-kode til/fra åpen kildekode, lignende .
- Generering av lisenshode, lik .
- Generer automatisk åpen kildekode-forpliktelseslogger fra interne forpliktelseslogger.
- Forhindre interne endringer som bryter åpen kildekodebygging .
Følgende underavsnitt vil fordype seg i de ovennevnte funksjonene som har interessante problemer.
Kildekodesynkronisering
I motsetning til åpen kildekode-versjonen av DataHub, som er et enkelt GitHub-depot, er LinkedIn-versjonen av DataHub en kombinasjon av flere depoter (kalt internt ). DataHub-grensesnittet, metadatamodellbiblioteket, metadatavarehus-backend-tjenesten og strømmejobber ligger i separate depoter på LinkedIn. For å gjøre det enklere for brukere av åpen kildekode, har vi imidlertid ett enkelt depot for åpen kildekode-versjonen av DataHub.
Figur 1: Synkronisering mellom depoter Linkedin DataHub og et enkelt depot DataHub åpen kilde
For å støtte automatiserte bygge-, push- og pull-arbeidsflyter, oppretter vårt nye verktøy automatisk en tilordning på filnivå som tilsvarer hver kildefil. Verktøysettet krever imidlertid innledende konfigurasjon og brukere må oppgi en modultilordning på høyt nivå som vist nedenfor.
{
"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"
]
}Kartleggingen på modulnivå er en enkel JSON hvis nøkler er målmodulene i open source-depotet, og verdiene er listen over kildemoduler i LinkedIn-repositoriene. Enhver målmodul i et åpen kildekodelager kan mates av et hvilket som helst antall kildemoduler. For å indikere de interne navnene på depoter i kildemoduler, bruk i Bash-stil. Ved å bruke en tilordningsfil på modulnivå oppretter verktøyene en tilordningsfil på filnivå ved å skanne alle filene i tilknyttede kataloger.
{
"${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,
}Filnivåtilordningen opprettes automatisk av verktøyene; den kan imidlertid også oppdateres manuelt av brukeren. Dette er en 1:1-tilordning av en LinkedIn-kildefil til en fil i åpen kildekode-repositoriet. Det er flere regler knyttet til denne automatiske opprettelsen av filtilknytninger:
- Ved flere kildemoduler for en målmodul i åpen kildekode kan det oppstå konflikter, for eksempel det samme , som finnes i mer enn én kildemodul. Som en konfliktløsningsstrategi bruker verktøyene våre som standard alternativet "siste vinner".
- "null" betyr at kildefilen ikke er en del av depotet for åpen kildekode.
- Etter hver åpen kildekode-innsending eller uttrekking oppdateres denne kartleggingen automatisk og et øyeblikksbilde opprettes. Dette er nødvendig for å identifisere tillegg og slettinger fra kildekoden siden siste handling.
Opprette forpliktelseslogger
Commit-logger for åpen kildekode-commits genereres også automatisk ved å slå sammen commit-loggene til interne repositories. Nedenfor er et eksempel på forpliktelseslogg for å vise strukturen til forpliktelsesloggen generert av verktøyet vårt. En commit indikerer tydelig hvilke versjoner av kildedepotene som er pakket i den commit og gir et sammendrag av commit-loggen. Sjekk ut denne ved å bruke et ekte eksempel på en forpliktelseslogg generert av verktøysettet vårt.
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.0Avhengighetstesting
LinkedIn har , som bidrar til å sikre at endringer i et internt multiprodukt ikke bryter sammenstillingen av avhengige multiprodukter. DataHub-depotet med åpen kildekode er ikke multi-produkt, og det kan ikke være en direkte avhengighet av noe multi-produkt, men ved hjelp av en multi-produkt wrapper som henter åpen kildekode DataHub-kildekoden, kan vi fortsatt bruke denne avhengighetstestingen Enhver endring (som senere kan bli eksponert) til alle multiproduktene som mater datahub-depotet med åpen kildekode, utløser derfor en byggehendelse i skall-multiproduktet. Derfor vil enhver endring som mislykkes i å bygge et innpakningsprodukt mislykkes i testene før det opprinnelige produktet forpliktes og blir tilbakeført.
Dette er en nyttig mekanisme som hjelper til med å forhindre intern commit som bryter open source-bygget og oppdager det ved commit-tidspunktet. Uten dette ville det være ganske vanskelig å avgjøre hvilken intern commit som forårsaket at open source-repository-byggingen mislyktes, fordi vi batcher interne endringer i DataHub open source-repository.
Forskjeller mellom åpen kildekode DataHub og vår produksjonsversjon
Frem til dette punktet har vi diskutert løsningen vår for å synkronisere to versjoner av DataHub-depoter, men vi har fortsatt ikke skissert årsakene til at vi trenger to forskjellige utviklingsstrømmer i utgangspunktet. I denne delen vil vi liste opp forskjellene mellom den offentlige versjonen av DataHub og produksjonsversjonen på LinkedIn-servere, og forklare årsakene til disse forskjellene.
En kilde til avvik stammer fra det faktum at vår produksjonsversjon har avhengigheter av kode som ennå ikke er åpen kildekode, for eksempel LinkedIns Offspring (LinkedIns interne avhengighetsinjeksjonsrammeverk). Avkom er mye brukt i interne kodebaser fordi det er den foretrukne metoden for å administrere dynamisk konfigurasjon. Men det er ikke åpen kildekode; så vi trengte å finne åpen kildekode-alternativer til åpen kildekode DataHub.
Det er andre grunner også. Ettersom vi lager utvidelser til metadatamodellen for LinkedIns behov, er disse utvidelsene vanligvis veldig spesifikke for LinkedIn og gjelder kanskje ikke direkte for andre miljøer. For eksempel har vi veldig spesifikke etiketter for deltaker-ID-er og andre typer samsvarende metadata. Så vi har nå ekskludert disse utvidelsene fra DataHubs open source-metadatamodell. Når vi engasjerer oss i fellesskapet og forstår deres behov, vil vi jobbe med vanlige åpen kildekode-versjoner av disse utvidelsene der det er nødvendig.
Brukervennlighet og enklere tilpasning for åpen kildekode-fellesskapet inspirerte også noen av forskjellene mellom de to versjonene av DataHub. Forskjeller i strømbehandlingsinfrastruktur er et godt eksempel på dette. Selv om den interne versjonen vår bruker et rammeverk for administrert strømbehandling, valgte vi å bruke innebygd (frittstående) strømbehandling for åpen kildekode-versjonen fordi den unngår å skape en annen infrastrukturavhengighet.
Et annet eksempel på forskjellen er å ha en enkelt GMS (Generalized Metadata Store) i en åpen kildekode-implementering i stedet for flere GMS. GMA (Generalized Metadata Architecture) er navnet på back-end-arkitekturen for DataHub, og GMS er metadatalageret i GMA-sammenheng. GMA er en veldig fleksibel arkitektur som lar deg distribuere hver datakonstruksjon (f.eks. datasett, brukere osv.) inn i sitt eget metadatalager, eller lagre flere datakonstruksjoner i et enkelt metadatalager så lenge registeret som inneholder datastrukturen som er kartlagt i GMS er oppdatert. For enkel bruk valgte vi en enkelt GMS-forekomst som lagrer alle de forskjellige datakonstruksjonene i åpen kildekode DataHub.
En fullstendig liste over forskjeller mellom de to implementeringene er gitt i tabellen nedenfor.
Produktegenskaper
LinkedIn DataHub
Open Source DataHub
Støttede datakonstruksjoner
1) Datasett 2) Brukere 3) Beregninger 4) ML-funksjoner 5) Diagrammer 6) Dashboards
1) Datasett 2) Brukere
Støttede metadatakilder for datasett
1) 2) Sofabase 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
Sammenflytende Kafka
Strømbehandling
Forvaltes
Innebygd (frittstående)
Dependency Injection & Dynamic Configuration
LinkedIn Avkom
Bygg verktøy
Ligradle (LinkedIns interne Gradle-omslag)
CI / CD
CRT (LinkedIns interne CI/CD)
og
Metadatalagre
Distribuert flere GMS: 1) Datasett GMS 2) Bruker GMS 3) Metrisk GMS 4) Funksjon GMS 5) Kart/Dashboard GMS
Enkelt GMS for: 1) Datasett 2) Brukere
Mikrotjenester i Docker-containere
forenkler applikasjonsdistribusjon og distribusjon med . Hver del av tjenesten i DataHub er åpen kildekode, inkludert infrastrukturkomponenter som Kafka, , и , har sitt eget Docker-bilde. For å orkestrere Docker-containere brukte vi .
Figur 2: Arkitektur DataHub *åpen kilde**
Du kan se høynivåarkitekturen til DataHub i bildet ovenfor. Foruten infrastrukturkomponentene, har den fire forskjellige Docker-containere:
datahub-gms: metadatalagringstjeneste
datahub-frontend: applikasjon , som betjener DataHub-grensesnittet.
datahub-mce-consumer: applikasjon , som bruker metadata change event (MCE)-strømmen og oppdaterer metadatalageret.
datahub-mae-consumer: applikasjon , som bruker en metadatarevisjonshendelsesstrøm (MAE) og oppretter en søkeindeks og grafdatabase.
Dokumentasjon for åpen kildekode og inneholder mer detaljert informasjon om funksjonene til ulike tjenester.
CI/CD på DataHub er åpen kildekode
DataHub-depotet med åpen kildekode bruker for kontinuerlig integrasjon og for kontinuerlig utplassering. Begge har god GitHub-integrasjon og er enkle å sette opp. For det meste av åpen kildekode-infrastruktur utviklet av fellesskapet eller private selskaper (f.eks. ), Docker-bilder opprettes og distribueres til Docker Hub for enkel bruk av fellesskapet. Ethvert Docker-bilde som finnes i Docker Hub kan enkelt brukes med en enkel kommando .
Med hver forpliktelse til DataHub åpen kildekode-depot, bygges alle Docker-bilder automatisk og distribueres til Docker Hub med den "siste" taggen. Hvis Docker Hub er konfigurert med noen , er alle tagger i åpen kildekode-repositoriet også utgitt med tilsvarende taggnavn i Docker Hub.
Bruker DataHub
er veldig enkel og består av tre enkle trinn:
- Klon depotet med åpen kildekode og kjør alle Docker-beholdere med docker-compose ved å bruke det medfølgende docker-compose-skriptet for en rask start.
- Last ned eksempeldataene i depotet ved å bruke kommandolinjeverktøyet som også følger med.
- Bla gjennom DataHub i nettleseren din.
Aktivt sporet også konfigurert for raske spørsmål. Brukere kan også opprette problemer direkte i GitHub-depotet. Det viktigste er at vi tar imot og setter pris på alle tilbakemeldinger og forslag!
Planer for fremtiden
For øyeblikket er hver infrastruktur eller mikrotjeneste for åpen kildekode DataHub bygget som en Docker-beholder, og hele systemet er orkestrert ved hjelp av . Gitt populariteten og utbredt , ønsker vi også å tilby en Kubernetes-basert løsning i nær fremtid.
Vi planlegger også å tilby en nøkkelferdig løsning for å distribuere DataHub på en offentlig skytjeneste som f.eks , eller . Gitt den nylige kunngjøringen av LinkedIns migrering til Azure, vil dette samsvare med metadatateamets interne prioriteringer.
Sist, men ikke minst, takk til alle de tidlige brukerne av DataHub i open source-fellesskapet som har vurdert DataHub-alfaer og hjulpet oss med å identifisere problemer og forbedre dokumentasjonen.
Kilde: www.habr.com