Open Source DataHub: het platform voor het zoeken en ontdekken van metadata van LinkedIn
Het snel vinden van de gegevens die u nodig heeft, is essentieel voor elk bedrijf dat afhankelijk is van grote hoeveelheden gegevens om datagestuurde beslissingen te nemen. Dit heeft niet alleen invloed op de productiviteit van datagebruikers (waaronder analisten, machine learning-ontwikkelaars, datawetenschappers en data-ingenieurs), maar het heeft ook een directe impact op de eindproducten die afhankelijk zijn van een hoogwaardige machine learning (ML)-pijplijn. Bovendien roept de trend naar het implementeren of bouwen van machine learning-platforms uiteraard de vraag op: wat is uw methode voor het intern ontdekken van functies, modellen, statistieken, datasets, enz.
In dit artikel zullen we bespreken hoe we een gegevensbron onder een open licentie hebben gepubliceerd in ons zoek- en ontdekkingsplatform voor metadata, vanaf de begindagen van het project . LinkedIn onderhoudt een eigen versie van DataHub, los van de open source-versie. We beginnen met uit te leggen waarom we twee afzonderlijke ontwikkelomgevingen nodig hebben, bespreken vervolgens de eerste benaderingen voor het gebruik van de open source WhereHows en vergelijken onze interne (productie)versie van DataHub met de versie op . We zullen ook details delen over onze nieuwe geautomatiseerde oplossing voor het pushen en ontvangen van open source-updates om beide repository's gesynchroniseerd te houden. Ten slotte geven we instructies over hoe u aan de slag kunt gaan met het gebruik van de open source DataHub en bespreken we kort de architectuur ervan.
WhereHows is nu een DataHub!
Het metadatateam van LinkedIn presenteerde eerder (opvolger van WhereHows), het zoek- en metadata-ontdekkingsplatform van LinkedIn, en gedeelde plannen om het te openen. Kort na deze aankondiging hebben we een alfaversie van DataHub uitgebracht en deze met de community gedeeld. Sindsdien hebben we voortdurend bijgedragen aan de repository en samengewerkt met geïnteresseerde gebruikers om de meest gevraagde functies toe te voegen en problemen op te lossen. We zijn nu blij om de officiële release aan te kondigen .
Open source-benaderingen
WhereHows, het oorspronkelijke LinkedIn-portaal voor het vinden van gegevens en waar deze vandaan komen, begon als een intern project; het metadatateam heeft het geopend . Sindsdien heeft het team altijd twee verschillende codebases onderhouden – één voor open source en één voor intern gebruik van LinkedIn – omdat niet alle productfuncties die voor LinkedIn-gebruiksscenario's waren ontwikkeld, algemeen toepasbaar waren op het bredere publiek. Bovendien heeft WhereHows enkele interne afhankelijkheden (infrastructuur, bibliotheken, enz.) die niet open source zijn. In de jaren die volgden onderging WhereHows vele iteraties en ontwikkelingscycli, waardoor het synchroniseren van de twee codebases een grote uitdaging werd. Het metadatateam heeft in de loop der jaren verschillende benaderingen geprobeerd om de interne en open source-ontwikkeling synchroon te houden.
Eerste poging: "Eerst open source"
In eerste instantie volgden we een 'open source first'-ontwikkelingsmodel, waarbij de meeste ontwikkeling plaatsvindt in een open source-repository en wijzigingen worden aangebracht voor interne implementatie. Het probleem met deze aanpak is dat de code altijd eerst naar GitHub wordt gepusht voordat deze intern volledig is beoordeeld. Totdat er wijzigingen worden aangebracht in de open source-repository en er een nieuwe interne implementatie wordt gemaakt, zullen we geen productieproblemen vinden. Bij een slechte inzet was het bovendien erg lastig om de boosdoener te achterhalen, omdat wijzigingen batchgewijs werden doorgevoerd.
Bovendien verminderde dit model de productiviteit van het team bij het ontwikkelen van nieuwe functies die snelle iteraties vereisten, omdat het dwong alle wijzigingen eerst naar een open source-repository te pushen en vervolgens naar een interne repository. Om de verwerkingstijd te verkorten, kon de vereiste oplossing of wijziging eerst in de interne repository worden uitgevoerd, maar dit werd een groot probleem als het ging om het samenvoegen van die wijzigingen in de open source-repository, omdat de twee repository's niet gesynchroniseerd waren.
Dit model is veel eenvoudiger te implementeren voor gedeelde platforms, bibliotheken of infrastructuurprojecten dan voor volledig uitgeruste webapplicaties op maat. Bovendien is dit model ideaal voor projecten die vanaf dag één open source starten, maar WhereHows is gebouwd als een volledig interne webapplicatie. Het was erg moeilijk om alle interne afhankelijkheden volledig weg te vagen, dus moesten we de interne fork behouden, maar het behouden van de interne fork en het ontwikkelen van voornamelijk open source werkte niet helemaal.
Tweede poging: “Inner eerst”
**Bij een tweede poging zijn we overgestapt op een 'intern eerst' ontwikkelingsmodel, waarbij de meeste ontwikkeling intern plaatsvindt en er regelmatig wijzigingen in de open source-code worden aangebracht. Hoewel dit model het meest geschikt is voor onze use case, kent het inherente problemen. Alle verschillen rechtstreeks naar de open source-repository pushen en vervolgens samenvoegconflicten later proberen op te lossen, is een optie, maar het is tijdrovend. Ontwikkelaars proberen dit in de meeste gevallen niet elke keer te doen als ze hun code beoordelen. Als gevolg hiervan zal dit veel minder vaak in batches worden gedaan, en wordt het dus moeilijker om samenvoegconflicten later op te lossen.
De derde keer lukte het!
De twee hierboven genoemde mislukte pogingen hadden tot gevolg dat de WhereHows GitHub-repository lange tijd verouderd bleef. Het team bleef de functies en architectuur van het product verbeteren, zodat de interne versie van WhereHows voor LinkedIn geavanceerder werd dan de open source-versie. Het had zelfs een nieuwe naam: DataHub. Op basis van eerdere mislukte pogingen besloot het team een schaalbare langetermijnoplossing te ontwikkelen.
Voor elk nieuw open source-project adviseert en ondersteunt het open source-team van LinkedIn een ontwikkelmodel waarbij de modules van het project volledig in open source worden ontwikkeld. Versiegebonden artefacten worden geïmplementeerd in een openbare opslagplaats en vervolgens opnieuw ingecheckt in het interne LinkedIn-artefact met behulp van . Het volgen van dit ontwikkelingsmodel is niet alleen goed voor degenen die open source gebruiken, maar resulteert ook in een meer modulaire, uitbreidbare en plug-in architectuur.
Een volwassen back-end-applicatie zoals DataHub zal echter een aanzienlijke hoeveelheid tijd nodig hebben om deze status te bereiken. Dit sluit ook de mogelijkheid uit om een volledig werkende implementatie open source te maken voordat alle interne afhankelijkheden volledig zijn geabstraheerd. Daarom hebben we tools ontwikkeld waarmee we sneller en met veel minder pijn open source-bijdragen kunnen leveren. Deze oplossing komt zowel het metadatateam (DataHub-ontwikkelaar) als de open source-gemeenschap ten goede. In de volgende secties wordt deze nieuwe aanpak besproken.
Open source publicatieautomatisering
De nieuwste benadering van het Metadata-team van de open source DataHub is het ontwikkelen van een tool die automatisch de interne codebase en de open source repository synchroniseert. Kenmerken van deze toolkit op hoog niveau zijn onder meer:
- Synchroniseer LinkedIn-code van/naar open source, vergelijkbaar .
- Genereren van licentieheaders, vergelijkbaar met .
- Genereer automatisch open source commit-logboeken op basis van interne commit-logboeken.
- Voorkom interne veranderingen die open source-builds kapot maken .
In de volgende subsecties wordt dieper ingegaan op de hierboven genoemde functies die interessante problemen hebben.
Synchronisatie van broncode
In tegenstelling tot de open source-versie van DataHub, die één enkele GitHub-repository is, is de LinkedIn-versie van DataHub een combinatie van meerdere repository's (intern genoemd ). De DataHub-interface, de metadatamodelbibliotheek, de metadatawarehouse-backendservice en streaming-taken bevinden zich in afzonderlijke repository's op LinkedIn. Om het echter gemakkelijker te maken voor open source-gebruikers, hebben we één enkele repository voor de open source-versie van DataHub.
Figuur 1: Synchronisatie tussen repositories LinkedIn DataHub en één enkele opslagplaats DataHub open source
Om geautomatiseerde build-, push- en pull-workflows te ondersteunen, creëert onze nieuwe tool automatisch een mapping op bestandsniveau die overeenkomt met elk bronbestand. De toolkit vereist echter een initiële configuratie en gebruikers moeten een moduletoewijzing op hoog niveau opgeven, zoals hieronder weergegeven.
{
"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"
]
}De mapping op moduleniveau is een eenvoudige JSON waarvan de sleutels de doelmodules in de open source-repository zijn en de waarden de lijst met bronmodules in de LinkedIn-repository's zijn. Elke doelmodule in een open source-repository kan worden gevoed door een willekeurig aantal bronmodules. Gebruik om de interne namen van repository's in bronmodules aan te geven in Bash-stijl. Met behulp van een toewijzingsbestand op moduleniveau creëren de tools een toewijzingsbestand op bestandsniveau door alle bestanden in de bijbehorende mappen te scannen.
{
"${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,
}De mapping op bestandsniveau wordt automatisch door de tools gemaakt; het kan echter ook handmatig door de gebruiker worden bijgewerkt. Dit is een 1:1-toewijzing van een LinkedIn-bronbestand aan een bestand in de open source-repository. Er zijn verschillende regels verbonden aan het automatisch aanmaken van bestandsassociaties:
- Bij meerdere bronmodules voor een doelmodule in open source kunnen er conflicten ontstaan, bijvoorbeeld hetzelfde , bestaande in meer dan één bronmodule. Als strategie voor het oplossen van conflicten gebruiken onze tools standaard de optie ‘de laatste wint’.
- "null" betekent dat het bronbestand geen deel uitmaakt van de open source-repository.
- Na elke open source-inzending of -extractie wordt deze mapping automatisch bijgewerkt en wordt er een momentopname gemaakt. Dit is nodig om toevoegingen en verwijderingen uit de broncode sinds de laatste actie te identificeren.
Vastleggingslogboeken maken
Commit-logboeken voor open source-commits worden ook automatisch gegenereerd door de commit-logboeken van interne opslagplaatsen samen te voegen. Hieronder vindt u een voorbeeld van een commitlogboek om de structuur te tonen van het commitlogboek dat door onze tool is gegenereerd. Een commit geeft duidelijk aan welke versies van de bronrepository's in die commit zijn verpakt en geeft een samenvatting van het commit-logboek. Bekijk deze eens met behulp van een echt voorbeeld van een commitlog gegenereerd door onze 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.0Afhankelijkheidstesten
LinkedIn heeft , wat ervoor zorgt dat wijzigingen aan een intern multiproduct de samenstelling van afhankelijke multiproducten niet verbreken. De open source DataHub-repository is niet multi-product en kan geen directe afhankelijkheid zijn van een multi-product, maar met behulp van een multi-product wrapper die de open source DataHub-broncode ophaalt, kunnen we deze afhankelijkheidstest nog steeds gebruiken Elke wijziging (die later mogelijk aan het licht komt) in een van de multiproducten die de open source DataHub-repository voeden, activeert dus een build-gebeurtenis in het shell-multiproduct. Elke wijziging die er niet in slaagt een wrapper-product te bouwen, slaagt daarom niet in de tests voordat het oorspronkelijke product wordt vastgelegd en wordt teruggedraaid.
Dit is een handig mechanisme dat helpt bij het voorkomen van interne commits die de open source-build verbreken en deze op het moment van committen detecteren. Zonder dit zou het behoorlijk moeilijk zijn om te bepalen welke interne commit ervoor zorgde dat het bouwen van de open source-repository mislukte, omdat we interne wijzigingen in de open source-repository van DataHub in batches verwerken.
Verschillen tussen open source DataHub en onze productieversie
Tot nu toe hebben we onze oplossing voor het synchroniseren van twee versies van DataHub-repository's besproken, maar we hebben nog steeds niet uiteengezet waarom we überhaupt twee verschillende ontwikkelingsstromen nodig hebben. In deze sectie zullen we de verschillen tussen de openbare versie van DataHub en de productieversie op LinkedIn-servers opsommen en de redenen voor deze verschillen uitleggen.
Eén bron van discrepantie komt voort uit het feit dat onze productieversie afhankelijk is van code die nog niet open source is, zoals LinkedIn's Offspring (LinkedIn's interne afhankelijkheidsinjectieframework). Offspring wordt veel gebruikt in interne codebases omdat dit de voorkeursmethode is voor het beheren van dynamische configuraties. Maar het is geen open source; dus moesten we open source-alternatieven vinden voor de open source DataHub.
Er zijn ook andere redenen. Omdat we uitbreidingen maken op het metadatamodel voor de behoeften van LinkedIn, zijn deze uitbreidingen doorgaans zeer specifiek voor LinkedIn en zijn ze mogelijk niet direct van toepassing op andere omgevingen. We hebben bijvoorbeeld zeer specifieke labels voor deelnemers-ID's en andere soorten overeenkomende metadata. Daarom hebben we deze extensies nu uitgesloten van het open source metadatamodel van DataHub. Terwijl we met de gemeenschap samenwerken en hun behoeften begrijpen, zullen we waar nodig werken aan gemeenschappelijke open source-versies van deze extensies.
Gebruiksgemak en eenvoudiger aanpassing voor de open source-gemeenschap vormden ook de inspiratiebron voor enkele verschillen tussen de twee versies van DataHub. Verschillen in de infrastructuur voor stroomverwerking zijn hiervan een goed voorbeeld. Hoewel onze interne versie gebruikmaakt van een beheerd raamwerk voor streamverwerking, hebben we ervoor gekozen om ingebouwde (standalone) streamverwerking te gebruiken voor de open source-versie, omdat hiermee wordt vermeden dat er nog een infrastructuurafhankelijkheid ontstaat.
Een ander voorbeeld van het verschil is het hebben van één GMS (Generalized Metadata Store) in een open source-implementatie in plaats van meerdere GMS'en. GMA (Generalized Metadata Architecture) is de naam van de back-endarchitectuur voor DataHub, en GMS is de metadata-opslag in de context van GMA. GMA is een zeer flexibele architectuur waarmee u elke dataconstructie (bijvoorbeeld datasets, gebruikers, enz.) kunt distribueren in zijn eigen metadata-archief, of meerdere dataconstructies kunt opslaan in één enkele metadata-store, zolang het register met de datastructuurtoewijzing in GMS is bijgewerkt. Voor gebruiksgemak hebben we gekozen voor één GMS-instantie die alle verschillende dataconstructies opslaat in de open source DataHub.
Een volledige lijst met verschillen tussen de twee implementaties wordt gegeven in de onderstaande tabel.
Producteigenschappen
LinkedIn DataHub
Opensource DataHub
Ondersteunde gegevensconstructies
1) Datasets 2) Gebruikers 3) Metrieken 4) ML-functies 5) Grafieken 6) Dashboards
1) Datasets 2) Gebruikers
Ondersteunde metadatabronnen voor datasets
1) 2) Bankbasis 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Vooruit 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Samenvloeiende Kafka
Stroomverwerking
Managed
Ingebed (standalone)
Afhankelijkheidsinjectie en dynamische configuratie
LinkedIn-nakomelingen
Bouw gereedschap
Ligradle (de interne Gradle-wrapper van LinkedIn)
CI / CD
CRT (interne CI/CD van LinkedIn)
en
Metagegevenswinkels
Gedistribueerde meerdere GMS: 1) Dataset GMS 2) Gebruiker GMS 3) Metrische GMS 4) Functie GMS 5) Grafiek/Dashboard GMS
Eén GMS voor: 1) Datasets 2) Gebruikers
Microservices in Docker-containers
vereenvoudigt de implementatie en distributie van applicaties met . Elk onderdeel van de dienst in DataHub is open source, inclusief infrastructuurcomponenten zoals Kafka, , и , heeft een eigen Docker-installatiekopie. Om Docker-containers te orkestreren hebben we gebruikt .
Figuur 2: Architectuur DataHub *open source**
U kunt de architectuur op hoog niveau van DataHub zien in de afbeelding hierboven. Naast de infrastructuurcomponenten beschikt het over vier verschillende Docker-containers:
datahub-gms: opslagservice voor metadata
datahub-frontend: applicatie , ten behoeve van de DataHub-interface.
datahub-mce-consumer: applicatie , dat gebruikmaakt van de metadata change event (MCE)-stream en de metadata-opslag bijwerkt.
datahub-mae-consumer: applicatie , dat gebruikmaakt van een metadata audit event stream (MAE) en een zoekindex en grafiekdatabase creëert.
Open source repository-documentatie en bevatten meer gedetailleerde informatie over de functies van verschillende diensten.
CI/CD op DataHub is open source
De open source DataHub-repository maakt gebruik van voor continue integratie en voor continue inzet. Beide hebben een goede GitHub-integratie en zijn eenvoudig in te stellen. Voor de meeste open source-infrastructuur ontwikkeld door de gemeenschap of particuliere bedrijven (bijv. ), worden Docker-images gemaakt en geïmplementeerd in Docker Hub voor gebruiksgemak door de community. Elke Docker-image in Docker Hub kan eenvoudig worden gebruikt met een eenvoudige opdracht .
Bij elke commit aan de open source-repository van DataHub worden alle Docker-images automatisch gebouwd en geïmplementeerd in Docker Hub met de "nieuwste" tag. Als Docker Hub met sommige is geconfigureerd , worden alle tags in de open source repository ook vrijgegeven met bijbehorende tagnamen in Docker Hub.
Met behulp van DataHub
is heel eenvoudig en bestaat uit drie eenvoudige stappen:
- Kloon de open source-repository en voer alle Docker-containers uit met docker-compose met behulp van het meegeleverde docker-compose-script voor een snelle start.
- Download de voorbeeldgegevens uit de repository met behulp van het opdrachtregelprogramma dat ook wordt meegeleverd.
- Blader door DataHub in uw browser.
Actief gevolgd ook geconfigureerd voor snelle vragen. Gebruikers kunnen ook rechtstreeks in de GitHub-repository problemen aanmaken. Het belangrijkste is dat we alle feedback en suggesties verwelkomen en waarderen!
Plannen voor de toekomst
Momenteel wordt elke infrastructuur of microservice voor open source DataHub gebouwd als een Docker-container en wordt het hele systeem georkestreerd met behulp van . Gezien de populariteit en wijdverspreid , willen we in de nabije toekomst ook een op Kubernetes gebaseerde oplossing aanbieden.
We zijn ook van plan een kant-en-klare oplossing te bieden voor de implementatie van DataHub op een openbare cloudservice zoals , of . Gezien de recente aankondiging van de migratie van LinkedIn naar Azure zal dit aansluiten bij de interne prioriteiten van het metadatateam.
Last but not least, dank aan alle early adopters van DataHub in de open source-gemeenschap die de Alpha's van DataHub hebben beoordeeld en ons hebben geholpen problemen te identificeren en de documentatie te verbeteren.
Bron: www.habr.com