DataHub con codice sorgente aperto: piattaforma di ricerca e scoperta dei metadati di LinkedIn
Una ricerca rapida dei dati necessari è essenziale per qualsiasi azienda che si basa su un grande volume di dati per prendere decisioni informate. Questo non solo influisce sulla produttività degli utenti dei dati (inclusi analisti, sviluppatori di machine learning, specialisti in data processing e ingegneri dei dati), ma ha anche un impatto diretto sui prodotti finali che dipendono da un pipeline di machine learning (ML) di qualità. Inoltre, la tendenza all'adozione o alla creazione di piattaforme di machine learning solleva naturalmente la questione: qual è il tuo metodo per la scoperta interna delle funzionalità, modelli, metriche, set di dati, ecc.
In questo articolo parleremo di come abbiamo pubblicato un dataset sotto licenza aperta sulla nostra piattaforma di ricerca e scoperta dei metadati, a partire dai primi giorni del progetto . LinkedIn supporta una propria versione di DataHub separatamente dalla versione open source. Inizieremo spiegando perché abbiamo bisogno di due ambienti di sviluppo separati, quindi discuteremo i primi approcci all'utilizzo di WhereHows open source e faremo un confronto tra la nostra versione interna (in produzione) di DataHub e quella su . Condivideremo inoltre i dettagli sulla nostra nuova soluzione automatizzata per l'invio e la ricezione degli aggiornamenti open source, per sincronizzare entrambi i repository. Infine, forniremo istruzioni su come iniziare a utilizzare DataHub open source e discuteremo brevemente della sua architettura.
WhereHows è ora DataHub!
Il team dei metadati di LinkedIn ha precedentemente presentato (successore di WhereHows), la piattaforma di ricerca e scoperta dei metadati di LinkedIn e ha condiviso i piani per renderla open source. Poco dopo questo annuncio, abbiamo rilasciato la versione alpha di DataHub e l'abbiamo condivisa con la comunità. Da allora, abbiamo costantemente contribuito al repository e collaborato con utenti interessati per aggiungere le funzionalità più richieste e risolvere problemi. Siamo ora lieti di annunciare il rilascio ufficiale di .
Approcci open source
WhereHows, il portale originale di LinkedIn per la ricerca dei dati e la loro origine, è stato lanciato come progetto interno; il team dei metadati lo ha reso . Da allora, il team ha sempre mantenuto due diverse basi di codice: una per il codice sorgente aperto e l'altra per l'uso interno di LinkedIn, poiché non tutte le funzionalità del prodotto sviluppate per le applicazioni di LinkedIn erano generalmente applicabili a un pubblico più ampio. Inoltre, WhereHows ha alcune dipendenze interne (infrastruttura, librerie, ecc.) il cui codice sorgente non è aperto. Negli anni successivi, WhereHows ha subito numerose iterazioni e cicli di sviluppo, rendendo difficile la sincronizzazione delle due basi di codice. Il team dei metadati ha cercato per molti anni di utilizzare approcci diversi per tentare di sincronizzare lo sviluppo interno e quello del codice sorgente aperto.
Primo tentativo: "Prima il codice aperto"
Inizialmente seguivamo un modello di sviluppo "prima il codice sorgente aperto", dove lo sviluppo principale avveniva nel repository del codice sorgente aperto e le modifiche venivano apportate per il dispiegamento interno. Il problema con questo approccio è che il codice viene sempre prima inviato su GitHub, prima di essere completamente verificato internamente. Non scopriremo alcun problema di produzione finché non verranno apportate modifiche dal repository del codice sorgente aperto e non verrà effettuato un nuovo dispiegamento interno. In caso di un cattivo dispiegamento, era anche molto difficile determinare il colpevole, poiché le modifiche venivano apportate in lotti.
Inoltre, questo modello ha ridotto la produttività del team nello sviluppo di nuove funzionalità che richiedevano iterazioni rapide, poiché costringeva tutte le modifiche a essere prima inserite nel repository del codice sorgente aperto e poi trasferite nel repository interno. Per ridurre i tempi di elaborazione, era possibile apportare la correzione o la modifica inizialmente nel repository interno, ma questo è diventato un enorme problema quando si è trattato di reintegrare queste modifiche nel repository del codice sorgente aperto, poiché i due repository erano fuori sincronizzazione.
Questo modello è molto più facile da implementare per piattaforme generali, librerie o progetti infrastrutturali rispetto a applicazioni web utente completamente funzionali. Inoltre, questo modello è ideale per i progetti che iniziano con codice sorgente aperto sin dal primo giorno, ma WhereHows è stato creato come un'applicazione web completamente interna. È stato davvero difficile astrarre completamente tutte le dipendenze interne, quindi abbiamo dovuto mantenere un fork interno, ma mantenere un fork interno e sviluppare principalmente con codice sorgente aperto non ha funzionato esattamente.
Secondo tentativo: «Interno prima»
** Come secondo tentativo, siamo passati a un modello di sviluppo «interno prima», in cui lo sviluppo principale avviene all'interno dell'azienda e le modifiche vengono apportate al codice sorgente aperto su base regolare. Anche se questo modello si adatta meglio al nostro caso d'uso, presenta delle sfide. Inviare direttamente tutte le differenze al repository pubblico del codice sorgente e poi cercare di risolvere i conflitti di fusione in seguito è un'opzione, ma richiede molto tempo. Gli sviluppatori in molti casi cercano di evitare di farlo a ogni revisione del codice. Di conseguenza, questo verrà eseguito molto meno frequentemente, a lotti, e quindi rende più difficile la risoluzione successiva dei conflitti di fusione.
Terzo tentativo, è andato tutto bene!
I due tentativi falliti di cui sopra hanno portato a un repository WhereHows GitHub obsoleto per un lungo periodo. Il team ha continuato a perfezionare le funzionalità e l'architettura del prodotto, quindi la versione interna di WhereHows per LinkedIn diventava sempre più avanzata rispetto alla versione open source. Aveva persino un nuovo nome: DataHub. Sulla base dei precedenti tentativi falliti, il team ha deciso di sviluppare una soluzione scalabile a lungo termine.
Per ogni nuovo progetto open source, il team di sviluppatori open source di LinkedIn consiglia e sostiene un modello di sviluppo in cui i moduli del progetto vengono completamente sviluppati con codice sorgente aperto. Gli artefatti con supporto alle versioni vengono distribuiti in un repository pubblico e poi riportati nell'artefatto interno di LinkedIn tramite L'adozione di questo modello di sviluppo non è solo vantaggiosa per chi utilizza codice sorgente aperto, ma porta anche alla creazione di un'architettura più modulare, estensibile e plug-and-play.
Tuttavia, per raggiungere questo stato per un'applicazione interna matura come DataHub, sarà necessario un tempo significativo. Ciò esclude anche la possibilità di un'implementazione completamente funzionante del codice sorgente aperto fino a quando tutte le dipendenze interne non sono completamente astratte. Pertanto, abbiamo sviluppato strumenti che ci aiutano a contribuire al codice sorgente aperto più rapidamente e con molto meno sforzo. Questa soluzione è vantaggiosa sia per il team dei metadati (sviluppatore di DataHub) che per la comunità del codice sorgente aperto. Nelle sezioni successive verrà discusso questo nuovo approccio.
Automazione della pubblicazione con codice sorgente aperto
L'ultimo approccio del gruppo di metadati a DataHub con codice sorgente aperto è lo sviluppo di uno strumento che sincronizza automaticamente la base di codice interna e il repository di codice sorgente aperto. Le funzionalità di alto livello di questo strumento includono:
- Sincronizzazione del codice LinkedIn con / da codice sorgente aperto, in modo simile .
- Generazione dell'intestazione della licenza, simile a .
- Generazione automatica dei log dei commit sorgente aperto a partire dai log dei commit interni.
- Prevenzione delle modifiche interne che rompono la build del codice sorgente aperto, attraverso .
Nei seguenti sotto-paragrafi verranno esaminate in dettaglio le funzioni sopra menzionate che presentano problemi interessanti.
Sincronizzazione del codice sorgente
A differenza della versione di DataHub con codice sorgente aperto, che rappresenta un singolo repository GitHub, la versione di DataHub per LinkedIn è una combinazione di più repository (chiamati all'interno dell'azienda ). L'interfaccia di DataHub, la libreria dei modelli di metadati, il servizio di backend del repository di metadati e i job in streaming si trovano in repository diversi in LinkedIn. Tuttavia, per facilitare l'uso da parte degli utenti del codice sorgente aperto, abbiamo un repository unico per la versione di DataHub con codice sorgente aperto.
Figura 1: Sincronizzazione tra repository LinkedIn DataHub e repository unico DataHub con codice sorgente aperto
Per supportare i processi di lavoro automatici di assemblaggio, invio e recupero, il nostro nuovo strumento crea automaticamente una corrispondenza a livello di file, corrispondente a ciascun file sorgente. Tuttavia, per questo strumento è necessaria una configurazione iniziale, e gli utenti devono fornire una mappatura di alto livello dei moduli, 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 corrispondenza a livello di modulo è un JSON semplice, le cui chiavi sono i moduli di destinazione nel repository open source, e i cui valori sono un elenco di moduli sorgente nei repository LinkedIn. Qualsiasi modulo di destinazione nel repository open source può essere alimentato da un numero qualsiasi di moduli sorgente. Per designare i nomi interni dei repository nei moduli sorgente si utilizza in stile Bash. Utilizzando il file di corrispondenza a livello di modulo, gli strumenti creano un file di corrispondenza a livello di file, scansionando tutti i file nelle directory collegate.
{
"${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 corrispondenza a livello di file è creata automaticamente dagli strumenti; tuttavia, può essere aggiornata anche manualmente dall'utente. Questa corrispondenza è 1:1 tra il file sorgente di LinkedIn e il file nel repository open source. Ci sono alcune regole associate a questa creazione automatica della corrispondenza dei file:
- In caso di più moduli sorgente per un modulo di destinazione nel repository open source, possono sorgere conflitti, ad esempio, lo stesso , presente 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 di codice sorgente aperto o estrazione, questa mappatura viene aggiornata automaticamente e viene creato uno snapshot. Questo è necessario per identificare le aggiunte e le rimozioni di codice sorgente dopo l'ultima azione.
Creazione dei log dei commit
I log dei commit per i commit di codice sorgente aperto vengono creati automaticamente anche unendo i log dei commit dei repository interni. Qui di seguito è riportato un esempio di log di commit per mostrare la struttura del log di commit creato dal nostro strumento. Il commit indica chiaramente quali versioni dei repository sorgente sono incluse in questo commit e fornisce un riepilogo delle informazioni del log di commit. Controlla questo su un esempio reale di log di commit creato dal nostro strumento.
metadata-models 29.0.0 -> 30.0.0
Aggiunto modello di aspetto foo
Risolto problema bar
dataset-gms 2.3.0 -> 2.3.4
Aggiunto API rest.li per servire l'aspetto foo
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Testing delle dipendenze
LinkedIn ha , che aiuta a garantire che le modifiche ai multi-prodotto interni non rompano la build dei multi-prodotto dipendenti. Il repository DataHub di codice sorgente aperto non è un multi-prodotto e non può essere una dipendenza diretta di alcun multi-prodotto, ma tramite un wrapper multi-prodotto che estrae il codice sorgente di DataHub open source, possiamo comunque utilizzare questo sistema di testing delle dipendenze. Pertanto, qualsiasi modifica (che potrebbe, in seguito, essere resa pubblica) in uno qualsiasi dei multi-prodotto che alimentano il repository DataHub sorgente aperto innesca un evento di build nel multi-prodotto wrapper. Di conseguenza, qualsiasi modifica che impedisce la costruzione del multi-prodotto wrapper non passa i test prima del commit del multi-prodotto sorgente e viene restituita.
Questo è un meccanismo utile che aiuta a prevenire qualsiasi commit interno che rompe la build del codice sorgente aperto e lo rileva durante la creazione del commit. Senza di esso, sarebbe piuttosto difficile determinare quale commit interno ha causato il fallimento della build del repository open source, poiché inseriamo cambiamenti interni batch nel repository DataHub di codice sorgente aperto.
Differenze tra DataHub open source e la nostra versione di produzione
Fino a questo momento abbiamo discusso della nostra soluzione per la sincronizzazione di due versioni dei repository DataHub, ma non abbiamo ancora chiarito le ragioni per cui abbiamo effettivamente 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, oltre a spiegare le ragioni di queste differenze.
Una delle fonti di discrepanze deriva dal fatto che la nostra versione di produzione ha dipendenze da codice non open source, come Offspring di LinkedIn (la struttura interna per la gestione delle dipendenze di LinkedIn). Offspring è ampiamente utilizzato nel codice interno, poiché rappresenta il metodo preferito per gestire la configurazione dinamica. Ma non è open source; pertanto, abbiamo dovuto trovare alternative open source per DataHub open source.
Ci sono anche altre ragioni. Mentre creiamo estensioni del modello di metadati per le necessità di LinkedIn, queste estensioni sono generalmente molto specifiche per LinkedIn e potrebbero non essere applicabili direttamente ad altri ambienti. Ad esempio, abbiamo etichette molto specifiche per gli identificatori dei partecipanti e altri tipi di metadati corrispondenti. Quindi, attualmente abbiamo escluso queste estensioni dal modello di metadati di DataHub open source. Man mano che interagiamo con la comunità e comprendiamo le loro esigenze, lavoreremo su versioni comuni di queste estensioni open source, dove necessario.
La facilità d'uso e una più semplice adattabilità per la comunità open source hanno anche ispirato alcune differenze tra le due versioni di DataHub. Le differenze nell'infrastruttura di elaborazione dei flussi ne sono un buon esempio. Anche se la nostra versione interna utilizza un'infrastruttura di elaborazione dei flussi gestita, abbiamo deciso di utilizzare un'elaborazione dei flussi integrata (autonoma) per la versione open source, poiché evita di creare un'altra dipendenza infrastrutturale.
Un altro esempio della differenza è la presenza di un solo GMS (Storage di Metadati Generici) nell'implementazione open source, e non di più GMS. GMA (Architettura Generica dei Metadati) è il nome dell'architettura interna per DataHub, mentre GMS è lo storage dei metadati nel contesto di GMA. GMA è un'architettura molto flessibile, che consente di distribuire ciascuna struttura dati (ad esempio, set di dati, utenti, ecc.) nel proprio storage di metadati o di memorizzare più strutture dati in un unico storage di metadati, finché il registro che contiene la mappatura della struttura dati in GMS viene aggiornato. Per semplificare l'uso, abbiamo scelto un solo esempio di GMS, che memorizza tutte le diverse strutture dati in DataHub open source.
L'elenco completo delle differenze tra le due implementazioni è riportato nella tabella sottostante.
Caratteristiche del Prodotto
LinkedIn DataHub
Open Source DataHub
Strutture Dati Supportate
1) Set di dati 2) Utenti 3) Metriche 4) Caratteristiche ML 5) Grafici 6) Dashboard
1) Set di dati 2) Utenti
Fonti di Metadati Supportate per i Set di Dati
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Elaborazione Stream
Gestito
Integrato (standalone)
Iniezione di Dipendenza & Configurazione Dinamica
LinkedIn Offspring
Strumenti di Build
Ligradle (wrapper Gradle interno di LinkedIn)
CI/CD
CRT (CI/CD interno di LinkedIn)
and
Storage di Metadati
Distribuito più GMS: 1) GMS Set di Dati 2) GMS Utenti 3) GMS Metriche 4) GMS Caratteristiche 5) GMS Grafico/Dashboard
Unico GMS per: 1) Set di Dati 2) Utenti
Microservizi in Contenitori Docker
semplifica il deployment e la distribuzione delle applicazioni tramite . Ogni parte del servizio in DataHub open source, inclusi i componenti dell'infrastruttura, come Kafka, , e , ha la propria immagine Docker. Per l'orchestrazione dei contenitori Docker abbiamo utilizzato .
Figura 2: Architettura DataHub *open source*
Puoi vedere l'architettura ad alto livello di DataHub nell'immagine sopra. Oltre ai componenti dell'infrastruttura, ci sono quattro diversi contenitori Docker:
datahub-gms: servizio di storage dei metadati
datahub-frontend: applicazione , che fornisce l'interfaccia di DataHub.
datahub-mce-consumer: applicazione , che utilizza il flusso di eventi di cambiamento dei metadati (MCE) e aggiorna lo storage dei metadati.
datahub-mae-consumer: applicazione , che utilizza il flusso di eventi di audit dei metadati (MAE) e crea un database di indice di ricerca e grafo.
Documentazione del repository open source e contengono informazioni più dettagliate sulle funzionalità di diversi servizi.
CI / CD in DataHub con codice sorgente aperto
Il repository di DataHub con codice sorgente aperto utilizza per integrazione continua e per distribuzione continua. Entrambi hanno una buona integrazione con GitHub e sono semplici da configurare. Per la maggior parte delle infrastrutture open source, sviluppate dalla comunità o da aziende private (ad esempio, ), sono state create immagini Docker, e vengono distribuite su Docker Hub per semplificarne l'utilizzo da parte della comunità. Qualsiasi immagine Docker trovata in Docker Hub può essere facilmente utilizzata con un semplice comando .
Ad ogni commit nel repository open source di DataHub tutte le immagini Docker vengono create e distribuite automaticamente in Docker Hub con il tag "latest". Se in Docker Hub è configurata una certa , tutti i tag nel repository open source vengono rilasciati anche con i corrispondenti nomi dei tag in Docker Hub.
Utilizzo di DataHub
è molto semplice e consiste in tre passaggi semplici:
- Clona il repository open source e avvia tutti i contenitori Docker utilizzando docker-compose con lo script fornito per il rapido avvio.
- Scarica i campioni di dati presentati nel repository utilizzando lo strumento da riga di comando, anch'esso fornito.
- Visualizza DataHub nel tuo browser.
Un è anche attivo per domande rapide. Gli utenti possono anche aprire issue direttamente nel repository GitHub. Soprattutto, apprezziamo e incoraggiamo tutti i feedback e suggerimenti!
Piani futuri
Attualmente, ogni infrastruttura o microservizio per DataHub con codice sorgente aperto è costruito come container Docker, e l'intero sistema è orchestrato utilizzando . Considerata la popolarità e la diffusione , vorremmo anche fornire una soluzione basata su Kubernetes in un prossimo futuro.
Abbiamo anche in programma di fornire una soluzione pronta per la distribuzione di DataHub su un servizio cloud pubblico, come , o . Considerando l'annuncio recente della migrazione di LinkedIn su Azure, questo sarà in linea con le priorità interne del team dei metadati.
E infine, ma non meno importante: grazie a tutti i primi utenti di DataHub nella comunità open source che hanno apprezzato le versioni alfa di DataHub e ci hanno aiutato a identificare problemi e migliorare la documentazione.
Fonte: habr.com
