DataHub con codice sorgente aperto: piattaforma di ricerca e scoperta di metadati di LinkedIn
Una rapida ricerca dei dati necessari è fondamentale per qualsiasi azienda che fa affidamento su un gran numero di dati per prendere decisioni basate su di essi. Questo influisce non solo sulla produttività degli utenti di dati (inclusi analisti, sviluppatori di machine learning, specialisti nella gestione dei dati e ingegneri dei dati), ma ha anche un impatto diretto sui prodotti finali che dipendono da un pipeline di machine learning (ML) di alta qualità. Inoltre, la tendenza a implementare o creare piattaforme di machine learning solleva naturalmente la domanda: qual è il vostro metodo di scoperta interna di funzionalità, modelli, metriche, set di dati, ecc.
In questo articolo parleremo di come abbiamo pubblicato sotto una licenza aperta una fonte di dati sulla nostra piattaforma di ricerca e scoperta di metadati, fin dai primi giorni del progetto . LinkedIn supporta una sua versione di DataHub separata dalla versione open source. Inizieremo spiegando perché abbiamo bisogno di due ambienti di sviluppo distinti, dopodiché discuteremo i primi approcci all'uso di WhereHows con codice sorgente aperto e confronteremo la nostra versione interna (in produzione) di DataHub con la versione su . Condivideremo anche i dettagli del nostro nuovo sistema automatizzato per inviare e ricevere aggiornamenti dal codice sorgente aperto, al fine di sincronizzare entrambi i repository. Infine, forniremo istruzioni su come iniziare a utilizzare DataHub con codice sorgente aperto e discuteremo brevemente la 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 il suo lancio. 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 lavorato con gli utenti interessati per aggiungere le funzionalità più richieste e affrontare i problemi. Ora siamo lieti di annunciare il rilascio ufficiale .
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 aperto . Da allora, il team ha sempre mantenuto due diversi codici sorgente: uno per il software open source e l'altro per l'uso interno di LinkedIn, poiché non tutte le funzionalità del prodotto sviluppate per gli usi di LinkedIn erano generalmente applicabili a un pubblico più ampio. Inoltre, WhereHows ha alcune dipendenze interne (infrastruttura, librerie, ecc.) di cui il codice sorgente non è disponibile. Negli anni successivi, WhereHows ha attraversato molte iterazioni e cicli di sviluppo, rendendo la sincronizzazione dei due codici sorgente una grande sfida. Il team dei metadati ha cercato per anni di adottare diversi approcci per cercare di sincronizzare lo sviluppo interno con quello open source.
Primo tentativo: «Prima il codice aperto»
Inizialmente abbiamo seguito il modello di sviluppo "open source first", in cui lo sviluppo principale avviene in un repository open source e le modifiche vengono apportate per il deployment interno. Il problema con questo approccio è che il codice viene sempre inviato su GitHub prima di essere completamente verificato internamente. Fino a quando le modifiche dal repository open source non vengono integrate e non viene effettuato un nuovo deployment interno, non scopriremo alcun problema di produzione. In caso di un deployment problematico, è stato anche molto difficile identificare il colpevole, poiché le modifiche venivano apportate in batch.
Inoltre, questo modello ha ridotto la produttività del team nello sviluppo di nuove funzionalità che richiedevano iterazioni rapide, poiché costringeva a inserire tutte le modifiche prima nel repository open source e poi trasferirle nel repository interno. Per ridurre il tempo di elaborazione, era possibile effettuare prima la correzione o la modifica nel repository interno, ma questo è diventato un enorme problema quando si trattava di unire queste modifiche di nuovo nel repository open source, perché i due repository si erano disallineati.
Questo modello è molto più facile da implementare per piattaforme generali, librerie o progetti infrastrutturali rispetto a un'applicazione web utente completamente funzionale. Inoltre, questo modello è ideale per progetti che partono con codice sorgente aperto fin dal primo giorno, ma WhereHows è stato sviluppato come un'applicazione web completamente interna. È stato davvero difficile astrarsi completamente da tutte le dipendenze interne, quindi abbiamo dovuto mantenere un fork interno, ma il mantenimento di un fork interno e lo sviluppo principalmente con codice sorgente aperto non hanno funzionato del tutto.
Secondo tentativo: 'Prima l'interno'
** Come seconda possibilità, abbiamo adottato 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. Sebbene questo modello si adatti meglio al nostro caso d'uso, presenta delle problematiche. Inviare direttamente tutte le differenze nel repository del codice open source e poi cercare di risolvere i conflitti di fusione successivamente è un'opzione, ma richiede molto tempo. Gli sviluppatori raramente cercano di farlo ad ogni revisione del codice. Pertanto, questo avverrà molto meno frequentemente, a gruppi, rendendo così più difficile la successiva risoluzione dei conflitti di fusione.
È andata bene la terza volta!
I due tentativi falliti menzionati sopra hanno comportato che il repository WhereHows su GitHub rimanesse obsoleto per molto tempo. Il team ha continuato a migliorare le funzionalità e l'architettura del prodotto, quindi la versione interna di WhereHows per LinkedIn stava diventando sempre più sofisticata rispetto alla versione open source. Aveva persino un nuovo nome: DataHub. Basandosi sui precedenti tentativi non riusciti, 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 supporta un modello di sviluppo in cui i moduli del progetto sono completamente sviluppati come open source. Gli artefatti con supporto versioni vengono distribuiti in un repository pubblico, per poi tornare nell'artefatto interno di LinkedIn tramite . Seguire questo modello di sviluppo non solo è vantaggioso per chi utilizza open source, ma porta anche alla creazione di un'architettura più modulare, estensibile e collegabile.
Tuttavia, per raggiungere questo stato per un'applicazione interna matura come DataHub, sarà necessario un notevole periodo di tempo. Questo esclude anche la possibilità di avere un'implementazione completamente funzionante e a codice aperto prima che tutte le dipendenze interne siano completamente astratte. Ecco perché abbiamo sviluppato strumenti che ci aiutano a contribuire a progetti open source in modo più rapido e meno complicato. Questa soluzione è vantaggiosa sia per il team dei metadati (sviluppatore di DataHub) sia per la comunità open source. Nei prossimi paragrafi verrà discusso questo nuovo approccio.
Automazione della pubblicazione open source
L'ultimo approccio del gruppo metadati per DataHub open source consiste nella creazione di uno strumento che sincronizza automaticamente il codice sorgente interno con il repository open source. Le funzionalità principali di questo strumento includono:
- Sincronizzazione del codice di LinkedIn con / da open source, simile a .
- Generazione dell'intestazione della licenza, simile a .
- Creazione automatica di registri di commit open source a partire dai registri di commit interni.
- Prevenzione delle modifiche interne che compromettono la build open source tramite .
Nei seguenti sotto-sezioni, verranno approfondite le funzionalità sopra menzionate che presentano problemi interessanti.
Sincronizzazione del codice sorgente.
A differenza della versione open source di DataHub, che è un unico repository GitHub, la versione di DataHub per LinkedIn è una combinazione di più repository (internamente chiamati ). L'interfaccia di DataHub, la libreria dei modelli di metadati, il servizio backend di archiviazione dei metadati e i job di streaming si trovano in repository diversi in LinkedIn. Tuttavia, per facilitare la vita degli utenti open source, abbiamo un repository unico per la versione open source di DataHub.
Figura 1: Sincronizzazione tra i repository LinkedIn DataHub e il repository unico DataHub open source.
Per supportare i processi automatizzati di costruzione, invio e estrazione, il nostro nuovo strumento crea automaticamente una mappatura a livello di file corrispondente a ciascun file sorgente. Tuttavia, il toolkit richiede 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 mappatura a livello di modulo è un semplice JSON, dove le chiavi sono i moduli target nel repository open source e i valori sono un elenco di moduli sorgente nei repository di LinkedIn. Qualsiasi modulo target 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 mappatura a livello di modulo, gli strumenti creano un file di mappatura a livello di file, scandendo 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,
}Il mapping a livello di file viene creato automaticamente dagli strumenti; tuttavia, può anche essere aggiornato manualmente dall'utente. Questo mapping rappresenta una corrispondenza 1:1 tra il file sorgente di LinkedIn e il file nel repository open source. Ci sono diverse regole relative a questa creazione automatica del mapping dei file:
- Nel caso di più moduli sorgente per un modulo target nell'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 default l'opzione 'l'ultimo vince'.
- "null" significa che il file sorgente non fa parte del repository open source.
- Dopo ogni invio nel codice sorgente o estrazione da esso, questa corrispondenza viene aggiornata automaticamente e viene creato uno snapshot. Questo è necessario per identificare le aggiunte e le rimozioni del codice sorgente dopo l'ultimo intervento.
Creazione dei log dei commit
I log dei commit per i commit con codice sorgente aperto vengono anch'essi creati automaticamente unendo i log dei commit dei repository interni. Di seguito è riportato un campione di log di commit per mostrare la struttura del log di commit generato dal nostro strumento. Il commit indica chiaramente quali versioni dei repository sorgente sono incluse in questo commit e fornisce un riepilogo 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 aspetto foo
Risolto problema bar
dataset-gms 2.3.0 -> 2.3.4
Aggiunta 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 assicura che le modifiche ai multiprodotti interni non compromettano la costruzione dei multiprodotti dipendenti. Il repository DataHub open source non è un multiprodotto e non può essere una dipendenza diretta di alcun multiprodotto, ma attraverso un contenitore multiprodotto che estrae il codice sorgente di DataHub open source, possiamo comunque utilizzare questo sistema di test delle dipendenze. Pertanto, qualsiasi modifica (che potrebbe essere resa pubblica in seguito) in uno dei multiprodotti che alimentano il repository DataHub open source attiva un evento di costruzione nel contenitore multiprodotto. Pertanto, qualsiasi modifica che impedisca la costruzione del contenitore multiprodotto non supera i test prima del commit del multiprodotto sorgente e viene restituita.
Si tratta di un meccanismo utile che aiuta a prevenire qualsiasi commit interno che possa compromettere la build con codice sorgente aperto, rilevandolo durante la creazione del commit. Senza di esso, sarebbe piuttosto difficile identificare quale commit interno ha causato il fallimento della build del repository open source, poiché inseriamo modifiche interne batch nel repository DataHub open source.
Differenze tra DataHub open source e la nostra versione in produzione
Finora abbiamo discusso della nostra soluzione per sincronizzare le due versioni dei repository DataHub, ma non abbiamo ancora specificato 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 in produzione sui server di LinkedIn, oltre a spiegare le ragioni di queste differenze.
Una delle fonti di discrepanza proviene dal fatto che la nostra versione di produzione ha dipendenze da codice con sorgente non ancora aperto, come l’Offspring di LinkedIn (la struttura interna di gestione delle dipendenze di LinkedIn). Offspring è ampiamente utilizzato nel codice interno, poiché è il metodo preferito per la gestione della configurazione dinamica. Tuttavia, non è open source; pertanto abbiamo dovuto trovare alternative open source per DataHub.
Ci sono anche altre ragioni. Mentre sviluppiamo estensioni del modello di metadati per le necessità di LinkedIn, queste estensioni sono spesso molto specifiche per LinkedIn e potrebbero non essere applicabili direttamente ad altri contesti. Ad esempio, abbiamo etichette molto specifiche per gli identificatori dei partecipanti e altri tipi di metadati di corrispondenza. Pertanto, al momento abbiamo escluso queste estensioni dal modello di metadati DataHub open source. Mentre 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 maggiore adattabilità per la comunità open source hanno ispirato alcune differenze tra le due versioni di DataHub. Le differenze nell'infrastruttura di streaming sono un buon esempio. Mentre la nostra versione interna utilizza un'infrastruttura di streaming gestito, abbiamo deciso di adottare lo streaming incorporato (standalone) per la versione open source, poiché questo evita la creazione di un'ulteriore dipendenza infrastrutturale.
Un altro esempio della differenza è la presenza di un GMS (Generico Magazzino di Metadati) nell'implementazione open source, anziché di più GMS. GMA (Architettura Generica dei Metadati) è il nome dell'architettura interna per DataHub, mentre GMS è il magazzino di metadati nel contesto di GMA. GMA è un'architettura molto flessibile che consente di distribuire ogni costrutto di dati (ad esempio, set di dati, utenti, ecc.) in un proprio magazzino di metadati oppure di memorizzare più costrutti di dati in un unico magazzino di metadati finché il registro contenente la mappatura della struttura dei dati in GMS è aggiornato. Per semplicità d'uso abbiamo scelto un'istanza di GMS che memorizza tutti i vari costrutti di dati in DataHub open source.
L'elenco completo delle differenze tra le due implementazioni è fornito nella tabella sottostante.
Caratteristiche del Prodotto
LinkedIn DataHub
Open Source DataHub
Costrutti di Dati Supportati
1) Set di Dati 2) Utenti 3) Metriche 4) Funzioni ML 5) Grafici 6) Cruscotti
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 dei Flussi
Gestito
Incorporato (standalone)
Iniezione delle Dipendenze e Configurazione Dinamica
Discendenti di LinkedIn
Strumenti di Build
Ligradle (wrapper di Gradle interno di LinkedIn)
CI/CD
CRT (CI/CD interno di LinkedIn)
and
Archivi Metadata
GMS distribuiti multipli: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
GMS singolo per: 1) Dataset 2) Utenti
Microservizi in contenitori Docker
semplifica il dispiegamento e la distribuzione delle applicazioni tramite . Ogni parte del servizio in DataHub con codice sorgente aperto, inclusi componenti infrastrutturali come Kafka, , e , ha la propria immagine Docker. Per l'orchestrazione dei contenitori Docker abbiamo utilizzato .
Figura 2: Architettura DataHub *con codice sorgente aperto*
Puoi vedere l'architettura di alto livello di DataHub nell'immagine sopra. Oltre ai componenti infrastrutturali, dispone di quattro diversi contenitori Docker:
datahub-gms: servizio di archiviazione dei metadati
datahub-frontend: applicazione , che gestisce l'interfaccia di DataHub.
datahub-mce-consumer: applicazione , che utilizza il flusso di eventi di modifica dei metadati (MCE) e aggiorna l'archivio dei metadati.
datahub-mae-consumer: applicazione , che utilizza il flusso di eventi di audit dei metadati (MAE) e crea un database dell'indice di ricerca e del grafo.
Documentazione del repository open source e contengono maggiori dettagli sulle funzionalità dei vari servizi.
CI / CD in DataHub open source
Il repository open source di DataHub utilizza per l'integrazione continua e per il deployment continuo. Entrambi si integrano bene con GitHub e sono facili da configurare. La maggior parte dell'infrastruttura open source sviluppata dalla comunità o da aziende private (ad esempio, ), ha immagini Docker create, che sono distribuite su Docker Hub per semplificare l'uso da parte della comunità. Qualsiasi immagine Docker trovata su Docker Hub può essere facilmente utilizzata con un semplice comando .
Ad ogni commit nel repository open source di DataHub, tutte le immagini Docker vengono automaticamente create e distribuite su Docker Hub con il tag «latest». Se su Docker Hub è configurato un certo , tutti i tag nel repository open source vengono anche rilasciati con i nomi dei tag corrispondenti su Docker Hub.
Utilizzare DataHub
è molto semplice e consiste in tre semplici passaggi:
- Clona il repository open source e avvia tutti i contenitori Docker utilizzando docker-compose con lo script docker-compose fornito per un avvio rapido.
- Scarica i campioni di dati presentati nel repository utilizzando l'utility da riga di comando, che è anch'essa fornita.
- Visualizza DataHub nel tuo browser.
Attivamente monitorato è anche configurato per domande rapide. Gli utenti possono inoltre aprire issue direttamente nel repository GitHub. Soprattutto, apprezziamo e valorizziamo tutti i feedback e i suggerimenti!
Piani per il futuro
Attualmente, ogni infrastruttura o microservizio per DataHub open source è costruito come contenitore Docker, e l'intero sistema è orchestrato tramite . Considerando la popolarità e la diffusione , ci piacerebbe anche fornire una soluzione basata su Kubernetes in un prossimo futuro.
Pianifichiamo anche di fornire una soluzione pronta per il deployment di DataHub in un servizio cloud pubblico come , o . Data la recente notizia della migrazione di LinkedIn su Azure, questo si allineerebbe alle 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 alpha di DataHub e ci hanno aiutato a identificare i problemi e migliorare la documentazione.
Fonte: habr.com
