DataHub de codi obert: plataforma de cerca i descobriment de metadades de LinkedIn
Trobar ràpidament les dades que necessiteu és essencial per a qualsevol empresa que depengui de grans quantitats de dades per prendre decisions basades en dades. Això no només afecta la productivitat dels usuaris de dades (inclosos analistes, desenvolupadors d'aprenentatge automàtic, científics de dades i enginyers de dades), sinó que també té un impacte directe en els productes finals que depenen d'un pipeline d'aprenentatge automàtic (ML) de qualitat. A més, la tendència a implementar o construir plataformes d'aprenentatge automàtic planteja naturalment la pregunta: quin és el vostre mètode per descobrir internament característiques, models, mètriques, conjunts de dades, etc.
En aquest article parlarem de com vam publicar una font de dades sota una llicència oberta a la nostra plataforma de recerca i descobriment de metadades, des dels primers dies del projecte . LinkedIn manté la seva pròpia versió de DataHub per separat de la versió de codi obert. Començarem explicant per què necessitem dos entorns de desenvolupament separats, després parlarem dels primers enfocaments per utilitzar el codi obert WhereHows i comparem la nostra versió interna (de producció) de DataHub amb la versió de . També compartirem detalls sobre la nostra nova solució automatitzada per impulsar i rebre actualitzacions de codi obert per mantenir els dos dipòsits sincronitzats. Finalment, proporcionarem instruccions sobre com començar a utilitzar el DataHub de codi obert i parlarem breument de la seva arquitectura.
WhereHows és ara un DataHub!
L'equip de metadades de LinkedIn es va presentar anteriorment (successor de WhereHows), la plataforma de cerca i descobriment de metadades de LinkedIn i plans compartits per obrir-lo. Poc després d'aquest anunci, vam llançar una versió alfa de DataHub i la vam compartir amb la comunitat. Des de llavors, hem contribuït contínuament al repositori i hem treballat amb usuaris interessats per afegir les funcions més sol·licitades i resoldre problemes. Ara ens complau anunciar el llançament oficial .
Enfocaments de codi obert
WhereHows, el portal original de LinkedIn per trobar dades i d'on prové, va començar com un projecte intern; l'equip de metadades la va obrir . Des d'aleshores, l'equip sempre ha mantingut dues bases de codi diferents, una per a codi obert i una altra per a ús intern de LinkedIn, ja que no totes les funcions del producte desenvolupades per als casos d'ús de LinkedIn eren generalment aplicables a un públic més ampli. A més, WhereHows té algunes dependències internes (infraestructura, biblioteques, etc.) que no són de codi obert. En els anys següents, WhereHows va passar per moltes iteracions i cicles de desenvolupament, fent que mantenir les dues bases de codi sincronitzades fos un gran repte. L'equip de metadades ha provat diferents enfocaments al llarg dels anys per intentar mantenir sincronitzat el desenvolupament intern i de codi obert.
Primer intent: "Primer codi obert"
Al principi vam seguir un model de desenvolupament "de codi obert primer", on la majoria del desenvolupament es produeix en un dipòsit de codi obert i es fan canvis per al desplegament intern. El problema d'aquest enfocament és que el codi sempre s'envia a GitHub abans que s'hagi revisat completament internament. Fins que no es facin canvis des del dipòsit de codi obert i es faci un nou desplegament intern, no trobarem cap problema de producció. En cas de mal desplegament, també era molt difícil determinar el culpable perquè els canvis es feien per lots.
A més, aquest model va reduir la productivitat de l'equip a l'hora de desenvolupar noves funcions que requerien iteracions ràpides, ja que obligava a introduir tots els canvis primer a un dipòsit de codi obert i després a un dipòsit intern. Per reduir el temps de processament, primer es podria fer la correcció o el canvi necessari al dipòsit intern, però això es va convertir en un gran problema a l'hora de tornar a fusionar aquests canvis al dipòsit de codi obert perquè els dos dipòsits estaven fora de sincronització.
Aquest model és molt més fàcil d'implementar per a plataformes compartides, biblioteques o projectes d'infraestructura que per a aplicacions web personalitzades amb totes les funcions. A més, aquest model és ideal per a projectes que comencen de codi obert des del primer dia, però WhereHows es va crear com una aplicació web completament interna. Va ser realment difícil abstraure completament totes les dependències internes, així que vam haver de mantenir la bifurcació interna, però mantenir la bifurcació interna i desenvolupar majoritàriament el codi obert no va funcionar del tot.
Segon intent: "Primer interior"
**Com a segon intent, vam passar a un model de desenvolupament "primer intern", on la majoria del desenvolupament es produeix a l'interior i es fan canvis al codi font obert de manera regular. Tot i que aquest model és el més adequat per al nostre cas d'ús, té problemes inherents. Empènyer directament totes les diferències al dipòsit de codi obert i després intentar resoldre els conflictes de combinació més tard és una opció, però requereix molt de temps. En la majoria dels casos, els desenvolupadors intenten no fer-ho cada vegada que revisen el seu codi. Com a resultat, això es farà amb molta menys freqüència, per lots, i per tant dificulta la resolució de conflictes de fusió més endavant.
La tercera vegada va funcionar!
Els dos intents fallits esmentats anteriorment van fer que el dipòsit de GitHub de WhereHows quedés desactualitzat durant molt de temps. L'equip va continuar millorant les característiques i l'arquitectura del producte, de manera que la versió interna de WhereHows per a LinkedIn es va fer més avançada que la versió de codi obert. Fins i tot tenia un nou nom: DataHub. A partir d'intents fallits anteriors, l'equip va decidir desenvolupar una solució escalable i a llarg termini.
Per a qualsevol projecte de codi obert nou, l'equip de codi obert de LinkedIn assessora i dóna suport a un model de desenvolupament en el qual els mòduls del projecte es desenvolupen completament en codi obert. Els artefactes amb versions es despleguen a un dipòsit públic i després es tornen a comprovar en un artefacte intern de LinkedIn mitjançant . Seguir aquest model de desenvolupament no només és bo per a aquells que utilitzen codi obert, sinó que també resulta en una arquitectura més modular, extensible i connectable.
Tanmateix, una aplicació de fons madura com DataHub requerirà una quantitat de temps important per arribar a aquest estat. Això també exclou la possibilitat d'open source una implementació que funcioni completament abans que totes les dependències internes s'hagin abstret completament. És per això que hem desenvolupat eines que ens ajuden a fer contribucions de codi obert més ràpidament i amb molt menys dolor. Aquesta solució beneficia tant a l'equip de metadades (desenvolupador de DataHub) com a la comunitat de codi obert. Les seccions següents tractaran aquest nou enfocament.
Automatització de la publicació de codi obert
L'últim enfocament de l'equip de Metadades al DataHub de codi obert és desenvolupar una eina que sincronitzi automàticament la base de codi interna i el dipòsit de codi obert. Les característiques d'alt nivell d'aquest conjunt d'eines inclouen:
- Sincronitza el codi de LinkedIn amb/des de codi obert, similar .
- Generació de capçalera de llicència, similar a .
- Genereu automàticament registres de confirmació de codi obert a partir dels registres de confirmació interns.
- Eviteu els canvis interns que trenquin les compilacions de codi obert .
Els següents subapartats aprofundiran en les funcions esmentades anteriorment que tenen problemes interessants.
Sincronització del codi font
A diferència de la versió de codi obert de DataHub, que és un únic dipòsit de GitHub, la versió de LinkedIn de DataHub és una combinació de diversos dipòsits (anomenats internament). ). La interfície de DataHub, la biblioteca de models de metadades, el servei de backend del magatzem de metadades i els treballs de transmissió en temps real resideixen en repositoris separats a LinkedIn. Tanmateix, per facilitar-ho als usuaris de codi obert, tenim un únic repositori per a la versió de codi obert de DataHub.
Figura 1: Sincronització entre repositoris LinkedIn DataHub i un únic repositori DataHub codi obert
Per donar suport a fluxos de treball automatitzats de creació, inserció i extracció, la nostra nova eina crea automàticament un mapa a nivell de fitxer corresponent a cada fitxer font. No obstant això, el conjunt d'eines requereix una configuració inicial i els usuaris han de proporcionar un mapa de mòduls d'alt nivell tal com es mostra a continuació.
{
"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"
]
}El mapeig a nivell de mòdul és un JSON simple les claus del qual són els mòduls de destinació al repositori de codi obert i els valors són la llista de mòduls font als repositoris de LinkedIn. Qualsevol mòdul de destinació d'un dipòsit de codi obert pot ser alimentat per qualsevol nombre de mòduls font. Per indicar els noms interns dels dipòsits als mòduls font, utilitzeu a l'estil Bash. Utilitzant un fitxer de mapatge a nivell de mòdul, les eines creen un fitxer de mapatge a nivell de fitxer escanejant tots els fitxers dels directoris associats.
{
"${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,
}Les eines creen automàticament l'assignació de nivell de fitxer; tanmateix, també pot ser actualitzat manualment per l'usuari. Aquesta és una assignació 1:1 d'un fitxer font de LinkedIn a un fitxer del dipòsit de codi obert. Hi ha diverses regles associades amb aquesta creació automàtica d'associacions de fitxers:
- En el cas de diversos mòduls d'origen per a un mòdul de destinació en codi obert, poden sorgir conflictes, per exemple, el mateix , existent en més d'un mòdul font. Com a estratègia de resolució de conflictes, les nostres eines utilitzen per defecte l'opció "L'últim guanya".
- "nul" significa que el fitxer font no forma part del dipòsit de codi obert.
- Després de cada enviament o extracció de codi obert, aquest mapatge s'actualitza automàticament i es crea una instantània. Això és necessari per identificar les addicions i les supressions del codi font des de l'última acció.
Creació de registres de commit
Els registres de commit per a commits de codi obert també es generen automàticament fusionant els registres de commit dels dipòsits interns. A continuació es mostra un registre de commit d'exemple per mostrar l'estructura del registre de commit generat per la nostra eina. Una confirmació indica clarament quines versions dels dipòsits font estan empaquetades en aquesta confirmació i proporciona un resum del registre de confirmació. Fes una ullada a aquest utilitzant un exemple real d'un registre de confirmació generat pel nostre conjunt d'eines.
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.0Prova de dependència
LinkedIn té , que ajuda a garantir que els canvis a un multiproducte intern no trenquin el conjunt de multiproductes dependents. El repositori DataHub de codi obert no és multiproducte i no pot ser una dependència directa de cap multiproducte, però amb l'ajuda d'un embolcall multiproducte que obté el codi font de DataHub de codi obert, encara podem utilitzar aquesta prova de dependència. Per tant, qualsevol canvi (que després es pugui exposar) a qualsevol dels multiproductes que alimenten el repositori de codi obert DataHub activa un esdeveniment de compilació al multiproducte de l'intèrpret d'ordres. Per tant, qualsevol canvi que no aconsegueix construir un producte d'embolcall falla les proves abans de comprometre el producte original i es reverteix.
Aquest és un mecanisme útil que ajuda a prevenir qualsevol confirmació interna que trenqui la compilació de codi obert i la detecti en el moment de la confirmació. Sense això, seria bastant difícil determinar quina confirmació interna va provocar que la compilació del dipòsit de codi obert fallés, perquè agrupem els canvis interns al dipòsit de codi obert de DataHub.
Diferències entre DataHub de codi obert i la nostra versió de producció
Fins a aquest punt, hem parlat de la nostra solució per sincronitzar dues versions de repositoris de DataHub, però encara no hem descrit els motius pels quals necessitem dos fluxos de desenvolupament diferents en primer lloc. En aquesta secció, enumerarem les diferències entre la versió pública de DataHub i la versió de producció als servidors de LinkedIn i explicarem els motius d'aquestes diferències.
Una font de discrepància prové del fet que la nostra versió de producció té dependències del codi que encara no és de codi obert, com ara Offspring de LinkedIn (el marc d'injecció de dependències interna de LinkedIn). La descendència s'utilitza àmpliament a les bases de codi internes perquè és el mètode preferit per gestionar la configuració dinàmica. Però no és de codi obert; per tant, havíem de trobar alternatives de codi obert al DataHub de codi obert.
També hi ha altres motius. A mesura que creem extensions al model de metadades per a les necessitats de LinkedIn, aquestes extensions solen ser molt específiques de LinkedIn i poden no aplicar-se directament a altres entorns. Per exemple, tenim etiquetes molt específiques per als identificadors de participants i altres tipus de metadades coincidents. Per tant, ara hem exclòs aquestes extensions del model de metadades de codi obert de DataHub. A mesura que ens relacionem amb la comunitat i entenem les seves necessitats, treballarem en versions comunes de codi obert d'aquestes extensions quan sigui necessari.
La facilitat d'ús i l'adaptació més fàcil per a la comunitat de codi obert també van inspirar algunes de les diferències entre les dues versions de DataHub. Les diferències en la infraestructura de processament de flux en són un bon exemple. Tot i que la nostra versió interna utilitza un marc de processament de flux gestionat, vam optar per utilitzar el processament de flux integrat (autònom) per a la versió de codi obert perquè evita crear una altra dependència de la infraestructura.
Un altre exemple de la diferència és tenir un sol GMS (Magatzem de metadades generalitzats) en una implementació de codi obert en lloc de diversos GMS. GMA (Generalized Metadata Architecture) és el nom de l'arquitectura de fons de DataHub i GMS és el magatzem de metadades en el context de GMA. GMA és una arquitectura molt flexible que us permet distribuir cada construcció de dades (per exemple, conjunts de dades, usuaris, etc.) al seu propi magatzem de metadades, o emmagatzemar múltiples construccions de dades en un únic magatzem de metadades sempre que el registre que contingui el mapeig de l'estructura de dades en El GMS està actualitzat. Per facilitar-ne l'ús, vam triar una única instància de GMS que emmagatzema totes les diferents construccions de dades al DataHub de codi obert.
A la taula següent es mostra una llista completa de les diferències entre les dues implementacions.
Característiques del producte
LinkedIn DataHub
DataHub de codi obert
Construccions de dades compatibles
1) Conjunts de dades 2) Usuaris 3) Mètriques 4) Funcions ML 5) Gràfics 6) Taulers de control
1) Conjunts de dades 2) Usuaris
Fonts de metadades admeses per a conjunts de dades
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Prest 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Processament de fluxos
Gestionat
Incrustat (autònom)
Injecció de dependències i configuració dinàmica
Fill de LinkedIn
Construir eines
Ligradle (embolcall intern de Gradle de LinkedIn)
CI / CD
CRT (CI/CD intern de LinkedIn)
i
Magatzems de metadades
GMS múltiple distribuït: 1) Conjunt de dades GMS 2) GMS d'usuari 3) GMS mètric 4) Funció GMS 5) GMS Gràfic/Tauler de control
GMS únic per a: 1) Conjunts de dades 2) Usuaris
Microserveis en contenidors Docker
simplifica el desplegament i la distribució d'aplicacions amb . Cada part del servei a DataHub és de codi obert, inclosos components d'infraestructura com Kafka, , и , té la seva pròpia imatge de Docker. Per orquestrar els contenidors Docker que hem utilitzat .
Figura 2: Arquitectura DataHub *codi obert**
Podeu veure l'arquitectura d'alt nivell de DataHub a la imatge de dalt. A més dels components d'infraestructura, té quatre contenidors Docker diferents:
datahub-gms: servei d'emmagatzematge de metadades
datahub-frontend: aplicació , que serveix la interfície de DataHub.
datahub-mce-consumer: aplicació , que utilitza el flux d'esdeveniments de canvi de metadades (MCE) i actualitza el magatzem de metadades.
datahub-mae-consumer: aplicació , que utilitza un flux d'esdeveniments d'auditoria de metadades (MAE) i crea un índex de cerca i una base de dades de gràfics.
Documentació del repositori de codi obert i conté informació més detallada sobre les funcions de diversos serveis.
CI/CD a DataHub és de codi obert
El repositori de codi obert DataHub utilitza per a la integració contínua i per a un desplegament continu. Tots dos tenen una bona integració de GitHub i són fàcils de configurar. Per a la majoria de les infraestructures de codi obert desenvolupades per la comunitat o empreses privades (p. ), les imatges de Docker es creen i es despleguen a Docker Hub per facilitar-ne l'ús per part de la comunitat. Qualsevol imatge de Docker que es trobi a Docker Hub es pot utilitzar fàcilment amb una ordre senzilla .
Amb cada compromís amb el dipòsit de codi obert de DataHub, totes les imatges de Docker es creen i es despleguen automàticament a Docker Hub amb l'etiqueta "última". Si Docker Hub està configurat amb alguns , totes les etiquetes del dipòsit de codi obert també es publiquen amb els noms d'etiquetes corresponents a Docker Hub.
Utilitzant DataHub
és molt senzill i consta de tres senzills passos:
- Cloneu el dipòsit de codi obert i executeu tots els contenidors de Docker amb docker-compose mitjançant l'script docker-compose proporcionat per a un inici ràpid.
- Baixeu les dades de mostra proporcionades al dipòsit mitjançant l'eina de línia d'ordres que també es proporciona.
- Navegueu per DataHub al vostre navegador.
Seguiment actiu també configurat per a preguntes ràpides. Els usuaris també poden crear problemes directament al repositori de GitHub. El més important és que donem la benvinguda i agraïm tots els comentaris i suggeriments!
Plans per al futur
Actualment, cada infraestructura o microservei per a DataHub de codi obert es construeix com a contenidor Docker i tot el sistema s'orquestra mitjançant . Donada la popularitat i la difusió , també ens agradaria oferir una solució basada en Kubernetes en un futur proper.
També tenim previst oferir una solució clau en mà per desplegar DataHub en un servei de núvol públic com ara , o . Tenint en compte el recent anunci de la migració de LinkedIn a Azure, això s'alinearà amb les prioritats internes de l'equip de metadades.
Finalment, però no menys important, gràcies a tots els primers usuaris de DataHub a la comunitat de codi obert que han valorat DataHub alfa i ens han ajudat a identificar problemes i millorar la documentació.
Font: www.habr.com