Open Source DataHub: LinkedIns Metadata Search and Discovery Platform
At finde de data, du har brug for hurtigt, er afgørende for enhver virksomhed, der er afhængig af store mængder data til at træffe datadrevne beslutninger. Dette påvirker ikke kun produktiviteten hos databrugere (herunder analytikere, maskinlæringsudviklere, dataforskere og dataingeniører), men det har også en direkte indvirkning på slutprodukterne, der afhænger af en pipeline af høj kvalitet i maskinlæring (ML). Derudover rejser tendensen til at implementere eller bygge maskinlæringsplatforme naturligvis spørgsmålet: hvad er din metode til internt at opdage funktioner, modeller, metrikker, datasæt osv.
I denne artikel vil vi tale om, hvordan vi udgav en datakilde under en åben licens i vores metadata-søgnings- og opdagelsesplatform, startende fra projektets tidlige dage . LinkedIn vedligeholder sin egen version af DataHub adskilt fra open source-versionen. Vi starter med at forklare, hvorfor vi har brug for to separate udviklingsmiljøer, og diskuterer derefter tidlige tilgange til brug af open source WhereHows og sammenligner vores interne (produktions)version af DataHub med versionen på . Vi deler også detaljer om vores nye automatiserede løsning til at skubbe og modtage open source-opdateringer for at holde begge lagre synkroniseret. Til sidst vil vi give instruktioner om, hvordan du kommer i gang med at bruge open source DataHub og kort diskutere dens arkitektur.
WhereHows er nu en DataHub!
LinkedIns metadata-team tidligere præsenteret (efterfølger til WhereHows), LinkedIns søge- og metadataopdagelsesplatform og fælles planer om at åbne den. Kort efter denne meddelelse udgav vi en alfaversion af DataHub og delte den med fællesskabet. Siden da har vi løbende bidraget til depotet og arbejdet med interesserede brugere for at tilføje de mest efterspurgte funktioner og løse problemer. Vi er nu glade for at kunne annoncere den officielle udgivelse .
Open Source-tilgange
WhereHows, LinkedIns originale portal til at finde data og hvor de kommer fra, startede som et internt projekt; metadata-teamet åbnede det . Siden da har teamet altid opretholdt to forskellige kodebaser – én til open source og én til LinkedIns interne brug – da ikke alle produktfunktioner udviklet til LinkedIn-brugssager generelt var anvendelige til det bredere publikum. Derudover har WhereHows nogle interne afhængigheder (infrastruktur, biblioteker osv.), som ikke er open source. I årene efter gennemgik WhereHows mange iterationer og udviklingscyklusser, hvilket gjorde det til en stor udfordring at holde de to kodebaser synkroniseret. Metadata-teamet har prøvet forskellige tilgange gennem årene for at forsøge at holde intern og open source-udvikling synkroniseret.
Første forsøg: "Open source først"
Vi fulgte oprindeligt en "open source first" udviklingsmodel, hvor det meste af udviklingen foregår i et open source repository, og der foretages ændringer til intern implementering. Problemet med denne tilgang er, at koden altid skubbes til GitHub først, før den er blevet fuldt gennemgået internt. Indtil der er foretaget ændringer fra open source-lageret og en ny intern implementering er foretaget, vil vi ikke finde nogen produktionsproblemer. I tilfælde af dårlig indsættelse var det også meget vanskeligt at fastslå synderen, fordi der blev foretaget ændringer i partier.
Derudover reducerede denne model teamets produktivitet, når de udviklede nye funktioner, der krævede hurtige iterationer, da den tvang alle ændringer til først at blive skubbet ind i et open source-lager og derefter til et internt lager. For at reducere behandlingstiden kunne den nødvendige rettelse eller ændring først udføres i det interne lager, men dette blev et stort problem, når det kom til at flette disse ændringer tilbage til open source-depotet, fordi de to depoter var ude af sync.
Denne model er meget nemmere at implementere for delte platforme, biblioteker eller infrastrukturprojekter end for brugerdefinerede webapplikationer med alle funktioner. Derudover er denne model ideel til projekter, der starter open source fra dag ét, men WhereHows blev bygget som en helt intern webapplikation. Det var virkelig svært helt at abstrahere alle de interne afhængigheder, så vi var nødt til at beholde den interne fork, men det lykkedes ikke helt at beholde den interne fork og udvikle for det meste open source.
Andet forsøg: "Indre først"
**Som et andet forsøg gik vi over til en "internt først" udviklingsmodel, hvor det meste af udviklingen foregår in-house, og der foretages ændringer i den åbne kildekode med jævne mellemrum. Selvom denne model er bedst egnet til vores anvendelsestilfælde, har den iboende problemer. Direkte at skubbe alle forskelle til open source-depotet og derefter forsøge at løse flettekonflikter senere er en mulighed, men det er tidskrævende. Udviklere forsøger i de fleste tilfælde ikke at gøre dette, hver gang de gennemgår deres kode. Som følge heraf vil dette blive gjort meget sjældnere, i batches, og dermed gøre det sværere at løse flettekonflikter senere.
Tredje gang virkede det!
De to mislykkede forsøg nævnt ovenfor resulterede i, at WhereHows GitHub-lageret forblev forældet i lang tid. Teamet fortsatte med at forbedre produktets funktioner og arkitektur, så den interne version af WhereHows til LinkedIn blev mere avanceret end open source-versionen. Det havde endda et nyt navn - DataHub. Baseret på tidligere mislykkede forsøg besluttede teamet at udvikle en skalerbar, langsigtet løsning.
Til ethvert nyt open source-projekt rådgiver og understøtter LinkedIns open source-team en udviklingsmodel, hvor projektets moduler udvikles udelukkende i open source. Versionerede artefakter implementeres til et offentligt lager og tjekkes derefter tilbage i den interne LinkedIn-artefakt ved hjælp af . At følge denne udviklingsmodel er ikke kun godt for dem, der bruger open source, men resulterer også i en mere modulær, udvidelsesbar og pluggbar arkitektur.
En moden back-end-applikation som DataHub vil dog kræve en betydelig mængde tid at nå denne tilstand. Dette udelukker også muligheden for open source en fuldt fungerende implementering, før alle interne afhængigheder er blevet fuldstændig abstraheret. Det er derfor, vi har udviklet værktøjer, der hjælper os med at lave open source-bidrag hurtigere og med meget mindre smerte. Denne løsning gavner både metadata-teamet (DataHub-udvikler) og open source-fællesskabet. De følgende afsnit vil diskutere denne nye tilgang.
Open Source Publishing Automation
Metadata-teamets seneste tilgang til open source DataHub er at udvikle et værktøj, der automatisk synkroniserer den interne kodebase og open source-depotet. Funktioner på højt niveau i dette værktøjssæt inkluderer:
- Synkroniser LinkedIn-kode til/fra open source, lignende .
- Generering af licensheader, svarende til .
- Generer automatisk open source commit logs fra interne commit logs.
- Forebyg interne ændringer, der bryder open source builds af .
De følgende underafsnit vil dykke ned i de ovennævnte funktioner, som har interessante problemer.
Kildekodesynkronisering
I modsætning til open source-versionen af DataHub, som er et enkelt GitHub-lager, er LinkedIn-versionen af DataHub en kombination af flere depoter (kaldet internt ). DataHub-grænsefladen, metadatamodelbiblioteket, metadatavarehus-backend-tjenesten og streamingjob ligger i separate arkiver på LinkedIn. For at gøre det lettere for open source-brugere har vi dog et enkelt lager til open source-versionen af DataHub.
Figur 1: Synkronisering mellem depoter LinkedIn DataHub'en og et enkelt depot DataHub'en open source
For at understøtte automatiserede build-, push- og pull-arbejdsgange opretter vores nye værktøj automatisk en kortlægning på filniveau, der svarer til hver kildefil. Værktøjssættet kræver dog indledende konfiguration, og brugere skal levere en modulkortlægning på højt niveau 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"
]
}Kortlægningen på modulniveau er en simpel JSON, hvis nøgler er målmodulerne i open source-depotet, og værdierne er listen over kildemoduler i LinkedIn-lagrene. Ethvert målmodul i et open source-lager kan fodres af et hvilket som helst antal kildemoduler. For at angive de interne navne på depoter i kildemoduler, brug i Bash-stil. Ved hjælp af en kortlægningsfil på modulniveau opretter værktøjerne en tilknytningsfil på filniveau ved at scanne alle filer i tilknyttede mapper.
{
"${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,
}Filniveautilknytningen oprettes automatisk af værktøjerne; den kan dog også opdateres manuelt af brugeren. Dette er en 1:1-mapping af en LinkedIn-kildefil til en fil i open source-depotet. Der er flere regler forbundet med denne automatiske oprettelse af filtilknytninger:
- I tilfælde af flere kildemoduler til et målmodul i open source kan der opstå konflikter, fx de samme , der findes i mere end ét kildemodul. Som en konfliktløsningsstrategi har vores værktøjer som standard indstillingen "sidste vinder".
- "null" betyder, at kildefilen ikke er en del af open source-depotet.
- Efter hver open source-indsendelse eller udtrækning opdateres denne kortlægning automatisk, og der oprettes et øjebliksbillede. Dette er nødvendigt for at identificere tilføjelser og sletninger fra kildekoden siden sidste handling.
Oprettelse af commit logs
Commit logs for open source commits genereres også automatisk ved at flette commit logs fra interne lagre. Nedenfor er et eksempel på commit-log for at vise strukturen af commit-loggen genereret af vores værktøj. En commit angiver tydeligt, hvilke versioner af kildedepoterne der er pakket i den commit og giver en oversigt over commit-loggen. Tjek denne ud ved at bruge et rigtigt eksempel på en commit-log genereret af vores værktøjskasse.
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.0Afhængighedstest
LinkedIn har , som hjælper med at sikre, at ændringer af et internt multiprodukt ikke bryder samlingen af afhængige multiprodukter. Open source DataHub-lageret er ikke multi-produkt, og det kan ikke være en direkte afhængighed af noget multi-produkt, men ved hjælp af en multi-produkt wrapper, der henter open source DataHub-kildekoden, kan vi stadig bruge denne afhængighedstest Enhver ændring (som senere kan blive eksponeret) til et hvilket som helst af de multiprodukter, der føder open source DataHub-lageret, udløser således en build-hændelse i shell-multiproduktet. Enhver ændring, der ikke bygger et indpakningsprodukt, svigter derfor testene, før de forpligter det originale produkt og vendes tilbage.
Dette er en nyttig mekanisme, der hjælper med at forhindre enhver intern commit, der bryder open source-bygningen og registrerer den på commit-tidspunktet. Uden dette ville det være ret svært at afgøre, hvilken intern commit, der forårsagede, at opbygningen af open source-depotet mislykkedes, fordi vi batcher interne ændringer til DataHub open source-depotet.
Forskelle mellem open source DataHub og vores produktionsversion
Indtil nu har vi diskuteret vores løsning til synkronisering af to versioner af DataHub-lagre, men vi har stadig ikke skitseret årsagerne til, hvorfor vi har brug for to forskellige udviklingsstrømme i første omgang. I dette afsnit vil vi liste forskellene mellem den offentlige version af DataHub og produktionsversionen på LinkedIn-servere og forklare årsagerne til disse forskelle.
En kilde til uoverensstemmelse stammer fra det faktum, at vores produktionsversion har afhængigheder af kode, der endnu ikke er open source, såsom LinkedIns Offspring (LinkedIns interne afhængighedsindsprøjtningsramme). Afkom er meget udbredt i interne kodebaser, fordi det er den foretrukne metode til styring af dynamisk konfiguration. Men det er ikke open source; så vi var nødt til at finde open source-alternativer til open source DataHub.
Der er også andre grunde. Da vi opretter udvidelser til metadatamodellen til LinkedIns behov, er disse udvidelser typisk meget specifikke for LinkedIn og gælder muligvis ikke direkte for andre miljøer. For eksempel har vi meget specifikke etiketter for deltager-id'er og andre typer matchende metadata. Så vi har nu udelukket disse udvidelser fra DataHubs open source-metadatamodel. Når vi engagerer os i fællesskabet og forstår deres behov, vil vi arbejde på almindelige open source-versioner af disse udvidelser, hvor det er nødvendigt.
Brugervenlighed og lettere tilpasning til open source-fællesskabet inspirerede også nogle af forskellene mellem de to versioner af DataHub. Forskelle i strømbehandlingsinfrastruktur er et godt eksempel på dette. Selvom vores interne version bruger en managed stream processing framework, valgte vi at bruge indbygget (standalone) stream processing til open source versionen, fordi den undgår at skabe en anden infrastruktur afhængighed.
Et andet eksempel på forskellen er at have en enkelt GMS (Generalized Metadata Store) i en open source-implementering i stedet for flere GMS'er. GMA (Generalized Metadata Architecture) er navnet på backend-arkitekturen til DataHub, og GMS er metadatalageret i forbindelse med GMA. GMA er en meget fleksibel arkitektur, der giver dig mulighed for at distribuere hver datakonstruktion (f.eks. datasæt, brugere osv.) i sit eget metadatalager eller gemme flere datakonstruktioner i et enkelt metadatalager, så længe registreringsdatabasen, der indeholder datastrukturen, GMS er opdateret. For at lette brugen valgte vi en enkelt GMS-instans, der gemmer alle de forskellige datakonstruktioner i open source DataHub.
En komplet liste over forskelle mellem de to implementeringer er givet i tabellen nedenfor.
produktegenskaber
LinkedIn DataHub
Open Source DataHub
Understøttede datakonstruktioner
1) Datasæt 2) Brugere 3) Metrics 4) ML-funktioner 5) Diagrammer 6) Dashboards
1) Datasæt 2) Brugere
Understøttede metadatakilder til datasæt
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)
Hive Kafka RDBMS
Pub-sub
Sammenflydende Kafka
Streambehandling
Managed
Indlejret (standalone)
Dependency Injection & Dynamic Configuration
LinkedIn Afkom
Byg værktøj
Ligradle (LinkedIns interne Gradle-indpakning)
CI / CD
CRT (LinkedIns interne CI/CD)
,
Metadata lagre
Distribueret flere GMS: 1) Datasæt GMS 2) Bruger GMS 3) Metrisk GMS 4) Feature GMS 5) Diagram/Dashboard GMS
Enkelt GMS for: 1) Datasæt 2) Brugere
Mikrotjenester i Docker-containere
forenkler applikationsimplementering og distribution med . Hver del af tjenesten i DataHub er open source, inklusive infrastrukturkomponenter såsom Kafka, , и , har sit eget Docker-billede. Til at orkestrere Docker-containere brugte vi .
Figur 2: Arkitektur DataHub'en *open source**
Du kan se højniveauarkitekturen i DataHub på billedet ovenfor. Udover infrastrukturkomponenterne har den fire forskellige Docker-containere:
datahub-gms: metadatalagringstjeneste
datahub-frontend: applikation , der betjener DataHub-grænsefladen.
datahub-mce-consumer: applikation , som bruger metadata change event (MCE)-strømmen og opdaterer metadatalageret.
datahub-mae-consumer: applikation , som bruger en metadata audit event stream (MAE) og opretter et søgeindeks og en grafdatabase.
Open source repository dokumentation og indeholde mere detaljerede oplysninger om forskellige tjenesters funktioner.
CI/CD på DataHub er open source
Open source DataHub-lageret bruger for løbende integration og til kontinuerlig udbredelse. Begge har god GitHub-integration og er nemme at sætte op. For de fleste open source-infrastrukturer udviklet af samfundet eller private virksomheder (f.eks. ), Docker-billeder oprettes og implementeres til Docker Hub for at lette brugen af fællesskabet. Ethvert Docker-billede, der findes i Docker Hub, kan nemt bruges med en simpel kommando .
Med hver forpligtelse til DataHub open source-lageret bygges alle Docker-billeder automatisk og implementeres til Docker Hub med det "seneste" tag. Hvis Docker Hub er konfigureret med nogle , frigives alle tags i open source-lageret også med tilsvarende tagnavne i Docker Hub.
Brug af DataHub
er meget enkel og består af tre enkle trin:
- Klon open source-depotet og kør alle Docker-containere med docker-compose ved hjælp af det medfølgende docker-compose-script for en hurtig start.
- Download eksempeldataene i depotet ved hjælp af kommandolinjeværktøjet, der også leveres.
- Gennemse DataHub i din browser.
Aktivt sporet også konfigureret til hurtige spørgsmål. Brugere kan også oprette problemer direkte i GitHub-lageret. Vigtigst af alt, vi hilser og værdsætter al feedback og forslag!
Planer for fremtiden
I øjeblikket er enhver infrastruktur eller mikroservice til open source DataHub bygget som en Docker-container, og hele systemet er orkestreret vha. . I betragtning af populariteten og udbredelsen , vil vi også gerne levere en Kubernetes-baseret løsning i den nærmeste fremtid.
Vi planlægger også at levere en nøglefærdig løsning til implementering af DataHub på en offentlig cloud-tjeneste som f.eks , eller . I betragtning af den nylige meddelelse om LinkedIns migrering til Azure, vil dette stemme overens med metadatateamets interne prioriteter.
Sidst, men ikke mindst, tak til alle de tidlige brugere af DataHub i open source-fællesskabet, som har bedømt DataHub-alfaer og hjulpet os med at identificere problemer og forbedre dokumentationen.
Kilde: www.habr.com