DataHub open source: piattaforma di ricerca e rilevamento dei metadati di LinkedIn
Trovare rapidamente i dati di cui hai bisogno è essenziale per qualsiasi azienda che fa affidamento su grandi quantità di dati per prendere decisioni basate sui dati. Ciò non ha solo un impatto sulla produttività degli utenti dei dati (inclusi analisti, sviluppatori di machine learning, data scientist e data engineer), ma ha anche un impatto diretto sui prodotti finali che dipendono da una pipeline di machine learning (ML) di qualità. Inoltre, la tendenza verso l’implementazione o la costruzione di piattaforme di machine learning solleva naturalmente la domanda: qual è il tuo metodo per scoprire internamente funzionalità, modelli, metriche, set di dati, ecc.
In questo articolo parleremo di come abbiamo pubblicato una fonte dati con una licenza aperta nella nostra piattaforma di ricerca e scoperta dei metadati, a partire dai primi giorni del progetto . LinkedIn mantiene la propria versione di DataHub separatamente dalla versione open source. Inizieremo spiegando il motivo per cui abbiamo bisogno di due ambienti di sviluppo separati, quindi discuteremo i primi approcci all'utilizzo di WhereHows open source e confronteremo la nostra versione interna (di produzione) di DataHub con la versione su . Condivideremo anche i dettagli sulla nostra nuova soluzione automatizzata per inviare e ricevere aggiornamenti open source per mantenere sincronizzati entrambi i repository. Infine, forniremo istruzioni su come iniziare a utilizzare il DataHub open source e discuteremo brevemente la sua architettura.
WhereHows è ora un DataHub!
Il team dei metadati di LinkedIn presentato in precedenza (successore di WhereHows), la piattaforma di ricerca e rilevamento dei metadati di LinkedIn, e piani condivisi per aprirla. Poco dopo questo annuncio, abbiamo rilasciato una versione alpha di DataHub e l'abbiamo condivisa con la community. Da allora, abbiamo contribuito continuamente al repository e lavorato con gli utenti interessati per aggiungere le funzionalità più richieste e risolvere i problemi. Siamo ora lieti di annunciare il rilascio ufficiale .
Approcci Open Source
WhereHows, il portale originale di LinkedIn per la ricerca dei dati e la loro provenienza, è iniziato come un progetto interno; il team dei metadati l'ha aperto . Da allora, il team ha sempre mantenuto due basi di codice diverse, una per l'open source e una per l'uso interno di LinkedIn, poiché non tutte le funzionalità del prodotto sviluppate per i casi d'uso di LinkedIn erano generalmente applicabili a un pubblico più ampio. Inoltre, WhereHows ha alcune dipendenze interne (infrastruttura, librerie, ecc.) che non sono open source. Negli anni successivi, WhereHows ha attraversato molte iterazioni e cicli di sviluppo, rendendo la sincronizzazione delle due basi di codice una grande sfida. Il team dei metadati ha provato diversi approcci nel corso degli anni per cercare di mantenere sincronizzato lo sviluppo interno e quello open source.
Primo tentativo: "Prima l'open source"
Inizialmente abbiamo seguito un modello di sviluppo "open source first", in cui la maggior parte dello sviluppo avviene in un repository open source e le modifiche vengono apportate per la distribuzione interna. Il problema con questo approccio è che il codice viene sempre inviato a GitHub prima di essere completamente rivisto internamente. Fino a quando non verranno apportate modifiche dal repository open source e non verrà effettuata una nuova distribuzione interna, non troveremo alcun problema di produzione. In caso di implementazione inadeguata era anche molto difficile determinare il colpevole perché le modifiche venivano apportate in batch.
Inoltre, questo modello riduceva la produttività del team durante lo sviluppo di nuove funzionalità che richiedevano iterazioni rapide, poiché imponeva che tutte le modifiche venissero prima inserite in un repository open source e quindi in un repository interno. Per ridurre i tempi di elaborazione, la correzione o la modifica richiesta poteva essere eseguita prima nel repository interno, ma questo diventava un grosso problema quando si trattava di unire nuovamente tali modifiche nel repository open source perché i due repository non erano sincronizzati.
Questo modello è molto più semplice da implementare per piattaforme condivise, librerie o progetti infrastrutturali che per applicazioni Web personalizzate con funzionalità complete. Inoltre, questo modello è ideale per progetti che iniziano con l'open source fin dal primo giorno, ma WhereHows è stato creato come un'applicazione web completamente interna. È stato davvero difficile eliminare completamente tutte le dipendenze interne, quindi abbiamo dovuto mantenere il fork interno, ma mantenere il fork interno e sviluppare principalmente open source non ha funzionato.
Secondo tentativo: “Prima interiore”
**Come secondo tentativo, siamo passati a un modello di sviluppo "prima interno", in cui la maggior parte dello sviluppo avviene internamente e le modifiche vengono apportate al codice open source su base regolare. Sebbene questo modello sia più adatto al nostro caso d'uso, presenta problemi intrinseci. L'invio diretto di tutte le differenze al repository open source e il tentativo di risolvere i conflitti di unione in un secondo momento è un'opzione, ma richiede molto tempo. Nella maggior parte dei casi gli sviluppatori cercano di non farlo ogni volta che rivedono il proprio codice. Di conseguenza, questa operazione verrà eseguita molto meno frequentemente, in batch, e quindi renderà più difficile risolvere i conflitti di unione in un secondo momento.
La terza volta ha funzionato!
I due tentativi falliti menzionati sopra hanno fatto sì che il repository GitHub di WhereHows rimanesse obsoleto per molto tempo. Il team ha continuato a migliorare le funzionalità e l'architettura del prodotto, in modo che la versione interna di WhereHows per LinkedIn diventasse più avanzata rispetto alla versione open source. Aveva anche un nuovo nome: DataHub. Sulla base dei precedenti tentativi falliti, il team ha deciso di sviluppare una soluzione scalabile e a lungo termine.
Per ogni nuovo progetto open source, il team open source di LinkedIn consiglia e supporta un modello di sviluppo in cui i moduli del progetto sono sviluppati interamente in open source. Gli artefatti con versione vengono distribuiti in un repository pubblico e quindi ricontrollati nell'artefatto interno di LinkedIn utilizzando . Seguire questo modello di sviluppo non è solo positivo per coloro che utilizzano l'open source, ma si traduce anche in un'architettura più modulare, estensibile e collegabile.
Tuttavia, un'applicazione back-end matura come DataHub richiederà una notevole quantità di tempo per raggiungere questo stato. Ciò preclude anche la possibilità di rendere open source un'implementazione pienamente funzionante prima che tutte le dipendenze interne siano state completamente astratte. Ecco perché abbiamo sviluppato strumenti che ci aiutano a fornire contributi open source più velocemente e con molta meno fatica. Questa soluzione avvantaggia sia il team dei metadati (sviluppatore DataHub) che la comunità open source. Le sezioni seguenti discuteranno di questo nuovo approccio.
Automazione della pubblicazione Open Source
L'ultimo approccio del team Metadata al DataHub open source consiste nello sviluppare uno strumento che sincronizzi automaticamente la codebase interna e il repository open source. Le funzionalità di alto livello di questo toolkit includono:
- Sincronizza il codice LinkedIn da/verso open source, simile .
- Generazione dell'intestazione della licenza, simile a .
- Genera automaticamente log di commit open source dai log di commit interni.
- Previeni le modifiche interne che interrompono le build open source .
Le seguenti sottosezioni approfondiranno le funzioni sopra menzionate che presentano problemi interessanti.
Sincronizzazione del codice sorgente
A differenza della versione open source di DataHub, che è un singolo repository GitHub, la versione LinkedIn di DataHub è una combinazione di più repository (chiamati internamente ). L'interfaccia DataHub, la libreria di modelli di metadati, il servizio backend di metadata warehouse e i processi di streaming risiedono in repository separati su LinkedIn. Tuttavia, per facilitare gli utenti open source, abbiamo un unico repository per la versione open source di DataHub.
Figura 1: sincronizzazione tra repository LinkedIn Hub dati e un unico repository Hub dati open source
Per supportare flussi di lavoro automatizzati di creazione, push e pull, il nostro nuovo strumento crea automaticamente una mappatura a livello di file corrispondente a ciascun file di origine. Tuttavia, il toolkit richiede una configurazione iniziale e gli utenti devono fornire una mappatura del modulo di alto livello come mostrato di seguito.
{
"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"
]
}La mappatura a livello di modulo è un semplice JSON le cui chiavi sono i moduli di destinazione nel repository open source e i valori sono l'elenco dei moduli sorgente nei repository di LinkedIn. Qualsiasi modulo di destinazione in un repository open source può essere alimentato da un numero qualsiasi di moduli sorgente. Per indicare i nomi interni dei repository nei moduli sorgente, utilizzare in stile Bash. Utilizzando un file di mappatura a livello di modulo, gli strumenti creano un file di mappatura a livello di file eseguendo la scansione di tutti i file nelle directory associate.
{
"${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,
}La mappatura a livello di file viene creata automaticamente dagli strumenti; tuttavia, può anche essere aggiornato manualmente dall'utente. Si tratta di una mappatura 1:1 di un file sorgente di LinkedIn su un file nel repository open source. Esistono diverse regole associate a questa creazione automatica di associazioni di file:
- In caso di più moduli sorgente per un modulo di destinazione in open source possono verificarsi conflitti, ad esempio uguali , esistente in più di un modulo sorgente. Come strategia di risoluzione dei conflitti, i nostri strumenti utilizzano per impostazione predefinita l’opzione “l’ultimo vince”.
- "null" significa che il file sorgente non fa parte del repository open source.
- Dopo ogni invio o estrazione open source, questa mappatura viene aggiornata automaticamente e viene creata uno snapshot. Ciò è necessario per identificare aggiunte ed eliminazioni dal codice sorgente dall'ultima azione.
Creazione di log di commit
Anche i log di commit per i commit open source vengono generati automaticamente unendo i log di commit dei repository interni. Di seguito è riportato un esempio di registro di commit per mostrare la struttura del registro di commit generato dal nostro strumento. Un commit indica chiaramente quali versioni dei repository di origine sono incluse in quel commit e fornisce un riepilogo del registro del commit. Dai un'occhiata a questo utilizzando un esempio reale di un registro di commit generato dal nostro 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.0Test di dipendenza
LinkedIn ha , che aiuta a garantire che le modifiche a un multiprodotto interno non interrompano l'assemblaggio dei multiprodotti dipendenti. Il repository DataHub open source non è multiprodotto e non può essere una dipendenza diretta di alcun multiprodotto, ma con l'aiuto di un wrapper multiprodotto che recupera il codice sorgente DataHub open source, possiamo comunque utilizzare questo test di dipendenza Pertanto, qualsiasi modifica (che potrebbe essere successivamente esposta) a uno qualsiasi dei multiprodotti che alimentano il repository DataHub open source attiva un evento di build nel multiprodotto della shell. Pertanto, qualsiasi modifica che non consenta la creazione del prodotto wrapper non supera i test prima del commit del prodotto originale e viene annullata.
Si tratta di un meccanismo utile che aiuta a prevenire qualsiasi commit interno che interrompa la build open source e lo rilevi al momento del commit. Senza questo, sarebbe piuttosto difficile determinare quale commit interno ha causato il fallimento della creazione del repository open source, poiché eseguiamo in batch le modifiche interne al repository open source DataHub.
Differenze tra DataHub open source e la nostra versione di produzione
Fino a questo punto, abbiamo discusso la nostra soluzione per sincronizzare due versioni dei repository DataHub, ma non abbiamo ancora delineato i motivi per cui abbiamo bisogno di due flussi di sviluppo diversi. In questa sezione elencheremo le differenze tra la versione pubblica di DataHub e la versione di produzione sui server LinkedIn e spiegheremo le ragioni di queste differenze.
Una fonte di discrepanza deriva dal fatto che la nostra versione di produzione ha dipendenze da codice che non è ancora open source, come Offspring di LinkedIn (il framework di iniezione delle dipendenze interne di LinkedIn). Offspring è ampiamente utilizzato nelle codebase interne perché è il metodo preferito per la gestione della configurazione dinamica. Ma non è open source; quindi dovevamo trovare alternative open source al DataHub open source.
Ci sono anche altri motivi. Poiché creiamo estensioni al modello di metadati per le esigenze di LinkedIn, queste estensioni sono in genere molto specifiche per LinkedIn e potrebbero non applicarsi direttamente ad altri ambienti. Ad esempio, disponiamo di etichette molto specifiche per gli ID dei partecipanti e altri tipi di metadati corrispondenti. Pertanto, ora abbiamo escluso queste estensioni dal modello di metadati open source di DataHub. Man mano che interagiamo con la comunità e comprendiamo le loro esigenze, lavoreremo su versioni open source comuni di queste estensioni, ove necessario.
La facilità d'uso e l'adattamento più semplice per la comunità open source hanno anche ispirato alcune delle differenze tra le due versioni di DataHub. Le differenze nell’infrastruttura di elaborazione dei flussi ne sono un buon esempio. Sebbene la nostra versione interna utilizzi un framework di elaborazione del flusso gestito, abbiamo scelto di utilizzare l'elaborazione del flusso integrata (autonoma) per la versione open source perché evita di creare un'altra dipendenza dell'infrastruttura.
Un altro esempio della differenza è avere un singolo GMS (Generalized Metadata Store) in un'implementazione open source anziché più GMS. GMA (Generalized Metadata Architecture) è il nome dell'architettura back-end per DataHub e GMS è l'archivio di metadati nel contesto di GMA. GMA è un'architettura molto flessibile che consente di distribuire ciascun costrutto di dati (ad esempio set di dati, utenti, ecc.) nel proprio archivio di metadati o di archiviare più costrutti di dati in un unico archivio di metadati purché il registro contenente la mappatura della struttura dei dati in Il GMS è aggiornato. Per facilità d'uso, abbiamo scelto una singola istanza GMS che memorizza tutti i diversi costrutti di dati nel DataHub open source.
Un elenco completo delle differenze tra le due implementazioni è riportato nella tabella seguente.
Caratteristiche
LinkedIn DataHub
DataHub open source
Costrutti di dati supportati
1) Set di dati 2) Utenti 3) Metriche 4) Funzionalità ML 5) Grafici 6) Dashboard
1) Set di dati 2) Utenti
Origini dei metadati supportate per i set di dati
1) 2) Base divano 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vettore 14)
Hive Kafka RDBMS
Pub-sub
Kafka confluente
Streaming Processing
Gestito
Incorporato (autonomo)
Iniezione di dipendenze e configurazione dinamica
Prole di LinkedIn
Costruisci strumenti
Ligradle (wrapper Gradle interno di LinkedIn)
CI / CD
CRT (CI/CD interno di LinkedIn)
ed
Archivi di metadati
GMS multipli distribuiti: 1) GMS set di dati 2) GMS utente 3) GMS metrico 4) GMS funzionalità 5) GMS grafico/cruscotto
GMS unico per: 1) Dataset 2) Utenti
Microservizi nei contenitori Docker
semplifica l'implementazione e la distribuzione delle applicazioni con . Ogni parte del servizio in DataHub è open source, compresi i componenti dell'infrastruttura come Kafka, , и , ha la propria immagine Docker. Per orchestrare i contenitori Docker abbiamo utilizzato .
Figura 2: Architettura Hub dati *fonte aperta**
Puoi vedere l'architettura di alto livello di DataHub nell'immagine sopra. Oltre ai componenti dell'infrastruttura, ha quattro diversi contenitori Docker:
datahub-gms: servizio di archiviazione dei metadati
frontend datahub: applicazione , che serve l'interfaccia DataHub.
datahub-mce-consumatore: applicazione , che utilizza il flusso dell'evento di modifica dei metadati (MCE) e aggiorna l'archivio dei metadati.
datahub-mae-consumatore: applicazione , che utilizza un flusso di eventi di controllo dei metadati (MAE) e crea un indice di ricerca e un database grafico.
Documentazione del repository open source e contenere informazioni più dettagliate sulle funzioni dei vari servizi.
CI/CD su DataHub è open source
Utilizza il repository DataHub open source per l'integrazione continua e per la distribuzione continua. Entrambi hanno una buona integrazione con GitHub e sono facili da configurare. Per la maggior parte delle infrastrutture open source sviluppate dalla comunità o da aziende private (ad es. ), le immagini Docker vengono create e distribuite su Docker Hub per facilitarne l'utilizzo da parte della community. Qualsiasi immagine Docker trovata in Docker Hub può essere facilmente utilizzata con un semplice comando .
Con ogni commit nel repository open source DataHub, tutte le immagini Docker vengono automaticamente create e distribuite su Docker Hub con il tag "latest". Se Docker Hub è configurato con alcuni , tutti i tag nel repository open source vengono rilasciati anche con i nomi dei tag corrispondenti in Docker Hub.
Utilizzo di DataHub
è molto semplice e si compone di tre semplici passaggi:
- Clona il repository open source ed esegui tutti i contenitori Docker con docker-compose utilizzando lo script docker-compose fornito per un avvio rapido.
- Scaricare i dati di esempio forniti nel repository utilizzando lo strumento da riga di comando fornito anch'esso.
- Sfoglia DataHub nel tuo browser.
Monitorato attivamente configurato anche per domande veloci. Gli utenti possono anche creare problemi direttamente nel repository GitHub. Soprattutto, accogliamo con favore e apprezziamo tutti i feedback e i suggerimenti!
Progetti per il futuro
Attualmente, ogni infrastruttura o microservizio per DataHub open source è costruito come contenitore Docker e l'intero sistema è orchestrato utilizzando . Data la popolarità e la diffusione , vorremmo fornire anche una soluzione basata su Kubernetes nel prossimo futuro.
Prevediamo inoltre di fornire una soluzione chiavi in mano per l'implementazione di DataHub su un servizio cloud pubblico come , o . Dato il recente annuncio della migrazione di LinkedIn ad Azure, ciò si allineerà alle priorità interne del team di metadati.
Ultimo ma non meno importante, grazie a tutti i primi utilizzatori di DataHub nella comunità open source che hanno valutato DataHub alfa e ci hanno aiutato a identificare i problemi e a migliorare la documentazione.
Fonte: habr.com