Open Source DataHub: LinkedIns Metadata Search and Discovery Platform
Att snabbt hitta den data du behöver är avgörande för alla företag som förlitar sig på stora mängder data för att fatta datadrivna beslut. Detta påverkar inte bara produktiviteten hos dataanvändare (inklusive analytiker, maskininlärningsutvecklare, datavetare och dataingenjörer), utan det har också en direkt inverkan på slutprodukterna som är beroende av en pipeline för maskininlärning (ML). Dessutom väcker trenden mot att implementera eller bygga maskininlärningsplattformar naturligtvis frågan: vad är din metod för att internt upptäcka funktioner, modeller, mätvärden, datauppsättningar, etc.
I den här artikeln kommer vi att prata om hur vi publicerade en datakälla under en öppen licens i vår sök- och upptäcktsplattform för metadata, med början från projektets tidiga dagar . LinkedIn underhåller sin egen version av DataHub separat från versionen med öppen källkod. Vi börjar med att förklara varför vi behöver två separata utvecklingsmiljöer, diskuterar sedan tidiga metoder för att använda open source WhereHows och jämför vår interna (produktions)version av DataHub med versionen på . Vi kommer också att dela detaljer om vår nya automatiserade lösning för att skicka och ta emot uppdateringar med öppen källkod för att hålla båda förråden synkroniserade. Slutligen kommer vi att ge instruktioner om hur du kommer igång med att använda öppen källkod DataHub och kort diskutera dess arkitektur.
WhereHows är nu en DataHub!
LinkedIns metadatateam tidigare presenterat (efterföljare till WhereHows), LinkedIns plattform för sök- och metadataupptäckt och delade planer på att öppna den. Kort efter detta tillkännagivande släppte vi en alfaversion av DataHub och delade den med communityn. Sedan dess har vi kontinuerligt bidragit till arkivet och arbetat med intresserade användare för att lägga till de mest efterfrågade funktionerna och lösa problem. Vi är nu glada att kunna meddela den officiella releasen .
Tillvägagångssätt med öppen källkod
WhereHows, LinkedIns ursprungliga portal för att hitta data och var den kommer ifrån, startade som ett internt projekt; metadatateamet öppnade det . Sedan dess har teamet alltid upprätthållit två olika kodbaser – en för öppen källkod och en för LinkedIns internt bruk – eftersom inte alla produktfunktioner som utvecklats för LinkedIns användningsfall var allmänt tillämpliga på den bredare publiken. Dessutom har WhereHows vissa interna beroenden (infrastruktur, bibliotek, etc.) som inte är öppen källkod. Under åren som följde gick WhereHows igenom många iterationer och utvecklingscykler, vilket gjorde det till en stor utmaning att hålla de två kodbaserna synkroniserade. Metadatateamet har provat olika tillvägagångssätt genom åren för att försöka hålla intern och öppen källkodsutveckling synkroniserad.
Första försök: "Öppen källkod först"
Vi följde initialt en utvecklingsmodell med "öppen källkod först", där den mesta utvecklingen sker i ett arkiv med öppen källkod och ändringar görs för intern implementering. Problemet med detta tillvägagångssätt är att koden alltid skickas till GitHub först innan den har granskats fullständigt internt. Förrän ändringar har gjorts från arkivet med öppen källkod och en ny intern distribution har gjorts, kommer vi inte att hitta några produktionsproblem. Vid dålig utplacering var det också mycket svårt att fastställa den skyldige eftersom förändringar gjordes i omgångar.
Dessutom minskade den här modellen teamets produktivitet när de utvecklade nya funktioner som krävde snabba iterationer, eftersom den tvingade alla ändringar att först skjutas in i ett arkiv med öppen källkod och sedan skjutas till ett internt arkiv. För att minska bearbetningstiden kunde den nödvändiga korrigeringen eller ändringen göras i det interna förvaret först, men detta blev ett stort problem när det gällde att slå samman dessa ändringar tillbaka till förvaret med öppen källkod eftersom de två förvaret var osynkroniserade.
Den här modellen är mycket lättare att implementera för delade plattformar, bibliotek eller infrastrukturprojekt än för anpassade webbapplikationer med alla funktioner. Dessutom är denna modell idealisk för projekt som startar öppen källkod från dag ett, men WhereHows byggdes som en helt intern webbapplikation. Det var verkligen svårt att helt abstrahera bort alla interna beroenden, så vi behövde behålla den interna gaffeln, men att behålla den interna gaffeln och utveckla mestadels öppen källkod fungerade inte riktigt.
Andra försöket: "Inre först"
**Som ett andra försök gick vi över till en "internt först" utvecklingsmodell, där den mesta utvecklingen sker internt och ändringar görs i den öppna källkoden på en regelbunden basis. Även om denna modell är bäst lämpad för vårt användningsfall har den inneboende problem. Att direkt skjuta alla skillnader till förvaret med öppen källkod och sedan försöka lösa sammanslagningskonflikter senare är ett alternativ, men det är tidskrävande. Utvecklare försöker i de flesta fall att inte göra detta varje gång de granskar sin kod. Som ett resultat kommer detta att göras mycket mer sällan, i omgångar, och därmed gör det svårare att lösa sammanslagningskonflikter senare.
Tredje gången fungerade det!
De två misslyckade försöken som nämns ovan resulterade i att WhereHows GitHub-förvaret förblev inaktuellt under lång tid. Teamet fortsatte att förbättra produktens funktioner och arkitektur, så att den interna versionen av WhereHows för LinkedIn blev mer avancerad än versionen med öppen källkod. Den hade till och med ett nytt namn - DataHub. Baserat på tidigare misslyckade försök beslutade teamet att utveckla en skalbar, långsiktig lösning.
För alla nya projekt med öppen källkod ger LinkedIns team med öppen källkod råd och stödjer en utvecklingsmodell där projektets moduler utvecklas helt i öppen källkod. Versionerade artefakter distribueras till ett offentligt arkiv och checkas sedan tillbaka till den interna LinkedIn-artefakten med . Att följa denna utvecklingsmodell är inte bara bra för dem som använder öppen källkod, utan resulterar också i en mer modulär, utbyggbar och pluggbar arkitektur.
En mogen back-end-applikation som DataHub kommer dock att kräva en betydande tid för att nå detta tillstånd. Detta utesluter också möjligheten att skapa en fullt fungerande implementering med öppen källa innan alla interna beroenden har abstraherats helt. Det är därför vi har utvecklat verktyg som hjälper oss att göra bidrag med öppen källkod snabbare och med mycket mindre smärta. Denna lösning gynnar både metadatateamet (DataHub-utvecklare) och öppen källkodsgemenskapen. Följande avsnitt kommer att diskutera detta nya tillvägagångssätt.
Open Source Publishing Automation
Metadata-teamets senaste tillvägagångssätt för öppen källkod DataHub är att utveckla ett verktyg som automatiskt synkroniserar den interna kodbasen och arkivet med öppen källkod. Funktioner på hög nivå i denna verktygslåda inkluderar:
- Synkronisera LinkedIn-kod till/från öppen källkod, liknande .
- Generering av licenshuvud, liknande .
- Generera automatiskt loggar för öppen källkod från interna loggar.
- Förhindra interna ändringar som bryter konstruktioner av öppen källkod .
Följande underavsnitt kommer att fördjupa sig i de ovan nämnda funktionerna som har intressanta problem.
Källkodssynkronisering
Till skillnad från open source-versionen av DataHub, som är ett enda GitHub-förråd, är LinkedIn-versionen av DataHub en kombination av flera förråd (som kallas internt ). DataHub-gränssnittet, metadatamodellbiblioteket, backend-tjänsten för metadatalager och strömmande jobb finns i separata arkiv på LinkedIn. Men för att göra det enklare för användare med öppen källkod har vi ett enda arkiv för öppen källkodsversionen av DataHub.
Figur 1: Synkronisering mellan repositories LinkedIn DataHub och ett enda förråd DataHub öppen källa
För att stödja automatiserade bygg-, push- och pull-arbetsflöden skapar vårt nya verktyg automatiskt en mappning på filnivå som motsvarar varje källfil. Verktygslådan kräver dock initial konfiguration och användare måste tillhandahålla en modulmappning på hög nivå som visas nedan.
{
"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"
]
}Mappningen på modulnivå är en enkel JSON vars nycklar är målmodulerna i öppen källkodsförvaret och värdena är listan över källmoduler i LinkedIns förvar. Alla målmoduler i ett arkiv med öppen källkod kan matas av valfritt antal källmoduler. För att ange de interna namnen på förråd i källmoduler, använd i Bash-stil. Med hjälp av en mappningsfil på modulnivå skapar verktygen en mappningsfil på filnivå genom att skanna alla filer i tillhörande 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åmappningen skapas automatiskt av verktygen; men det kan också uppdateras manuellt av användaren. Detta är en 1:1-mappning av en LinkedIn-källfil till en fil i arkivet med öppen källkod. Det finns flera regler förknippade med detta automatiska skapande av filassociationer:
- I fallet med flera källmoduler för en målmodul i öppen källkod kan konflikter uppstå, t ex samma , som finns i mer än en källmodul. Som en konfliktlösningsstrategi använder våra verktyg som standard alternativet "den sista vinner".
- "null" betyder att källfilen inte är en del av arkivet med öppen källkod.
- Efter varje inlämning eller extraktion av öppen källkod uppdateras denna mappning automatiskt och en ögonblicksbild skapas. Detta är nödvändigt för att identifiera tillägg och raderingar från källkoden sedan den senaste åtgärden.
Skapa commit-loggar
Commit-loggar för commits med öppen källkod genereras också automatiskt genom att slå samman commit-loggarna för interna arkiv. Nedan finns ett exempel på en logg för att visa strukturen för loggboken som genereras av vårt verktyg. En commit indikerar tydligt vilka versioner av källarkiven som är paketerade i den commit och ger en sammanfattning av commit-loggen. Kolla in den här med hjälp av ett verkligt exempel på en commit-logg som genereras av vår verktygslåda.
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.0Beroendetestning
LinkedIn har , vilket hjälper till att säkerställa att ändringar av en intern multiprodukt inte bryter sammansättningen av beroende multiprodukter. DataHub-förrådet med öppen källkod är inte multiprodukt, och det kan inte vara ett direkt beroende av någon multiprodukt, men med hjälp av en multiproduktomslag som hämtar källkoden för öppen källkod för DataHub, kan vi fortfarande använda denna beroendetestning Varje förändring (som senare kan exponeras) av någon av multiprodukterna som matar datahubbaren med öppen källkod utlöser alltså en bygghändelse i skal-multiprodukten. Därför misslyckas varje ändring som misslyckas med att bygga en omslagsprodukt i testerna innan originalprodukten utförs och återställs.
Detta är en användbar mekanism som hjälper till att förhindra alla interna commit som bryter open source-bygget och upptäcker det vid commit. Utan detta skulle det vara ganska svårt att avgöra vilken intern commit som orsakade konstruktionen av öppen källkodsrepository att misslyckas, eftersom vi batch interna ändringar i DataHub open source arkivet.
Skillnader mellan öppen källkod DataHub och vår produktionsversion
Fram till denna punkt har vi diskuterat vår lösning för att synkronisera två versioner av DataHub-förråd, men vi har fortfarande inte beskrivit anledningarna till varför vi behöver två olika utvecklingsströmmar i första hand. I det här avsnittet kommer vi att lista skillnaderna mellan den offentliga versionen av DataHub och produktionsversionen på LinkedIns servrar, och förklara orsakerna till dessa skillnader.
En källa till diskrepans härrör från det faktum att vår produktionsversion har beroenden av kod som ännu inte är öppen källkod, såsom LinkedIns Offspring (LinkedIns interna ramverk för beroendeinjektion). Avkomma används ofta i interna kodbaser eftersom det är den föredragna metoden för att hantera dynamisk konfiguration. Men det är inte öppen källkod; så vi behövde hitta öppen källkodsalternativ till öppen källkod DataHub.
Det finns också andra skäl. Eftersom vi skapar tillägg till metadatamodellen för LinkedIns behov är dessa tillägg vanligtvis mycket specifika för LinkedIn och kanske inte direkt gäller för andra miljöer. Vi har till exempel mycket specifika etiketter för deltagar-ID och andra typer av matchande metadata. Så vi har nu uteslutit dessa tillägg från DataHubs open source-metadatamodell. När vi engagerar oss i samhället och förstår deras behov kommer vi att arbeta med vanliga versioner av öppen källkod av dessa tillägg där det behövs.
Användarvänlighet och enklare anpassning för öppen källkodsgemenskap inspirerade också till några av skillnaderna mellan de två versionerna av DataHub. Skillnader i strömbehandlingsinfrastruktur är ett bra exempel på detta. Även om vår interna version använder ett ramverk för hanterad strömbearbetning, valde vi att använda inbyggd (fristående) strömbearbetning för versionen med öppen källkod eftersom det undviker att skapa ett annat infrastrukturberoende.
Ett annat exempel på skillnaden är att ha ett enda GMS (Generalized Metadata Store) i en implementering med öppen källkod snarare än flera GMS. GMA (Generalized Metadata Architecture) är namnet på back-end-arkitekturen för DataHub, och GMS är metadatalagret i GMA-sammanhang. GMA är en mycket flexibel arkitektur som låter dig distribuera varje datakonstruktion (t.ex. datauppsättningar, användare, etc.) till sitt eget metadatalager, eller lagra flera datakonstruktioner i ett enda metadatalager så länge som registret som innehåller datastrukturmappningen i GMS uppdateras. För enkelhetens skull valde vi en enda GMS-instans som lagrar alla olika datakonstruktioner i öppen källkod DataHub.
En komplett lista över skillnader mellan de två implementeringarna ges i tabellen nedan.
Produktegenskaper
LinkedIn DataHub
Open Source DataHub
Datakonstruktioner som stöds
1) Dataset 2) Användare 3) Mätvärden 4) ML-funktioner 5) Diagram 6) Dashboards
1) Datauppsättningar 2) Användare
Stödda metadatakällor för datamängder
1) 2) Soffbas 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
Sammanflytande Kafka
Strömbehandling
Hanterad
Inbäddad (fristående)
Dependency Injection & Dynamic Configuration
LinkedIn Avkomma
Bygg verktyg
Ligradle (LinkedIns interna Gradle-omslag)
CI / CD
CRT (LinkedIns interna CI/CD)
och
Metadatabutiker
Distribuerade flera GMS: 1) Dataset GMS 2) Användar GMS 3) Metriskt GMS 4) Feature GMS 5) Diagram/Dashboard GMS
Enstaka GMS för: 1) Dataset 2) Användare
Mikrotjänster i Docker-containrar
förenklar applikationsdistribution och distribution med . Varje del av tjänsten i DataHub är öppen källkod, inklusive infrastrukturkomponenter som Kafka, , и , har sin egen Docker-bild. För att orkestrera Docker-containrar använde vi .
Figur 2: Arkitektur DataHub *öppen källa**
Du kan se högnivåarkitekturen för DataHub i bilden ovan. Förutom infrastrukturkomponenterna har den fyra olika Docker-containrar:
datahub-gms: metadatalagringstjänst
datahub-frontend: applikation , som betjänar DataHub-gränssnittet.
datahub-mce-consumer: applikation , som använder strömmen metadata change event (MCE) och uppdaterar metadatalagret.
datahub-mae-consumer: applikation , som använder en metadatarevisionshändelseström (MAE) och skapar ett sökindex och en grafdatabas.
Dokumentation för öppen källkod och innehålla mer detaljerad information om olika tjänsters funktioner.
CI/CD på DataHub är öppen källkod
DataHub-förvaret med öppen källkod använder för kontinuerlig integration och för kontinuerlig driftsättning. Båda har bra GitHub-integration och är lätta att ställa in. För de flesta infrastrukturer med öppen källkod som utvecklats av samhället eller privata företag (t.ex. ), Docker-bilder skapas och distribueras till Docker Hub för enkel användning av communityn. Alla Docker-bilder som finns i Docker Hub kan enkelt användas med ett enkelt kommando .
Med varje commit till DataHub open source-förvaret byggs alla Docker-avbildningar automatiskt och distribueras till Docker Hub med den "senaste" taggen. Om Docker Hub är konfigurerad med några , alla taggar i öppen källkodsförvaret släpps också med motsvarande taggnamn i Docker Hub.
Använder DataHub
är mycket enkel och består av tre enkla steg:
- Klona arkivet med öppen källkod och kör alla Docker-behållare med docker-compose med det medföljande docker-compose-skriptet för en snabbstart.
- Ladda ner exempeldata som tillhandahålls i förvaret med hjälp av kommandoradsverktyget som också tillhandahålls.
- Bläddra i DataHub i din webbläsare.
Spåras aktivt även konfigurerad för snabba frågor. Användare kan också skapa problem direkt i GitHub-förvaret. Viktigast av allt, vi välkomnar och uppskattar all feedback och förslag!
Planer för framtiden
För närvarande är varje infrastruktur eller mikrotjänst för öppen källkod DataHub byggd som en Docker-behållare, och hela systemet är orkestrerat med hjälp av . Med tanke på popularitet och utbredd , vi skulle också vilja tillhandahålla en Kubernetes-baserad lösning inom en snar framtid.
Vi planerar också att tillhandahålla en nyckelfärdig lösning för att distribuera DataHub på en offentlig molntjänst som t.ex , eller . Med tanke på det senaste tillkännagivandet om LinkedIns migrering till Azure kommer detta att passa in i metadatateamets interna prioriteringar.
Sist men inte minst, tack till alla tidiga användare av DataHub i open source-gemenskapen som har betygsatt DataHub-alfa och hjälpt oss att identifiera problem och förbättra dokumentationen.
Källa: will.com