DataHub de código aberto: plataforma de busca e descubrimento de metadatos de LinkedIn
Atopar os datos que necesitas rapidamente é esencial para calquera empresa que confíe en grandes cantidades de datos para tomar decisións baseadas en datos. Isto non só afecta a produtividade dos usuarios de datos (incluídos analistas, desenvolvedores de aprendizaxe automática, científicos de datos e enxeñeiros de datos), senón que tamén ten un impacto directo nos produtos finais que dependen dunha canalización de aprendizaxe automática (ML) de calidade. Ademais, a tendencia á implementación ou creación de plataformas de aprendizaxe automática fai que se plantee naturalmente a pregunta: cal é o seu método para descubrir internamente funcións, modelos, métricas, conxuntos de datos, etc.
Neste artigo falaremos de como publicamos unha fonte de datos baixo unha licenza aberta na nosa plataforma de busca e descubrimento de metadatos, a partir dos primeiros días do proxecto . LinkedIn mantén a súa propia versión de DataHub por separado da versión de código aberto. Comezaremos explicando por que necesitamos dous ambientes de desenvolvemento separados, despois comentaremos os primeiros enfoques para usar o código aberto WhereHows e compararemos a nosa versión interna (de produción) de DataHub coa versión de . Tamén compartiremos detalles sobre a nosa nova solución automatizada para impulsar e recibir actualizacións de código aberto para manter ambos repositorios sincronizados. Finalmente, proporcionaremos instrucións sobre como comezar a usar o DataHub de código aberto e comentaremos brevemente a súa arquitectura.
WhereHows agora é un DataHub!
O equipo de metadatos de LinkedIn presentado anteriormente (sucesor de WhereHows), a plataforma de busca e descubrimento de metadatos de LinkedIn e plans compartidos para abrila. Pouco despois deste anuncio, lanzamos unha versión alfa de DataHub e compartimos coa comunidade. Desde entón, contribuímos continuamente ao repositorio e traballamos cos usuarios interesados para engadir as funcións máis solicitadas e resolver problemas. Agora temos o pracer de anunciar o lanzamento oficial .
Enfoques de código aberto
WhereHows, o portal orixinal de LinkedIn para buscar datos e de onde proceden, comezou como un proxecto interno; abriuno o equipo de metadatos . Desde entón, o equipo sempre mantivo dúas bases de código diferentes, unha para código aberto e outra para uso interno de LinkedIn, xa que non todas as funcións do produto desenvolvidas para casos de uso de LinkedIn eran xeralmente aplicables ao público máis amplo. Ademais, WhereHows ten algunhas dependencias internas (infraestrutura, bibliotecas, etc.) que non son de código aberto. Nos anos seguintes, WhereHows pasou por moitas iteracións e ciclos de desenvolvemento, o que fixo que manter as dúas bases de código sincronizadas fose un gran desafío. O equipo de metadatos probou diferentes enfoques ao longo dos anos para tentar manter sincronizado o desenvolvemento interno e de código aberto.
Primeiro intento: "Primeiro código aberto"
Inicialmente seguimos un modelo de desenvolvemento de "código aberto primeiro", onde a maior parte do desenvolvemento ocorre nun repositorio de código aberto e se realizan cambios para o despregamento interno. O problema con este enfoque é que o código sempre se envía primeiro a GitHub antes de ser revisado por completo internamente. Ata que non se fagan cambios desde o repositorio de código aberto e se realice unha nova implantación interna, non atoparemos ningún problema de produción. En caso de mala implantación, tamén era moi difícil determinar o culpable porque os cambios se facían por lotes.
Ademais, este modelo reduciu a produtividade do equipo ao desenvolver novas funcións que requirían iteracións rápidas, xa que obrigaba a que todos os cambios fosen enviados primeiro a un repositorio de código aberto e despois a un repositorio interno. Para reducir o tempo de procesamento, a corrección ou o cambio necesarios podería facerse primeiro no repositorio interno, pero isto converteuse nun gran problema á hora de fusionar eses cambios no repositorio de código aberto porque os dous depósitos estaban fóra de sincronización.
Este modelo é moito máis fácil de implementar para plataformas compartidas, bibliotecas ou proxectos de infraestrutura que para aplicacións web personalizadas con todas as funcións. Ademais, este modelo é ideal para proxectos que inician o código aberto desde o primeiro día, pero WhereHows foi construído como unha aplicación web completamente interna. Era realmente difícil abstraer por completo todas as dependencias internas, polo que necesitabamos manter a bifurcación interna, pero manter a bifurcación interna e desenvolver principalmente o código aberto non funcionou.
Segundo intento: "Inner first"
**Como segundo intento, pasamos a un modelo de desenvolvemento "primeiro interno", onde a maior parte do desenvolvemento prodúcese internamente e se realizan cambios no código fonte aberto de forma regular. Aínda que este modelo é o máis adecuado para o noso caso de uso, ten problemas inherentes. Empurrar directamente todas as diferenzas ao repositorio de código aberto e despois tentar resolver os conflitos de fusión máis tarde é unha opción, pero leva moito tempo. Na maioría dos casos, os desenvolvedores intentan non facelo cada vez que revisan o seu código. Como resultado, isto farase con moita menos frecuencia, por lotes e, polo tanto, dificulta a resolución dos conflitos de fusión máis tarde.
A terceira vez que funcionou!
Os dous intentos fallidos mencionados anteriormente provocaron que o repositorio de WhereHows GitHub permanecese desactualizado durante moito tempo. O equipo continuou mellorando as características e a arquitectura do produto, de xeito que a versión interna de WhereHows para LinkedIn volveuse máis avanzada que a versión de código aberto. Incluso tiña un novo nome: DataHub. Baseándose en intentos fallidos anteriores, o equipo decidiu desenvolver unha solución escalable e a longo prazo.
Para calquera novo proxecto de código aberto, o equipo de código aberto de LinkedIn aconsella e apoia un modelo de desenvolvemento no que os módulos do proxecto se desenvolvan integramente en código aberto. Os artefactos con versións despréganse nun repositorio público e despois revísanse no artefacto interno de LinkedIn usando . Seguir este modelo de desenvolvemento non só é bo para quen usa código aberto, senón que tamén dá como resultado unha arquitectura máis modular, extensible e conectable.
Non obstante, unha aplicación de back-end madura como DataHub requirirá unha cantidade significativa de tempo para chegar a este estado. Isto tamén impide a posibilidade de obter unha implementación que funcione completamente antes de que todas as dependencias internas sexan totalmente abstraídas. É por iso que desenvolvemos ferramentas que nos axudan a facer contribucións de código aberto máis rápido e con moita menos dor. Esta solución beneficia tanto ao equipo de metadatos (desenvolvedor de DataHub) como á comunidade de código aberto. Nas seguintes seccións analizaranse este novo enfoque.
Automatización da publicación de código aberto
O último enfoque do equipo de Metadatos para o DataHub de código aberto é desenvolver unha ferramenta que sincronice automaticamente a base de código interna e o repositorio de código aberto. As características de alto nivel deste conxunto de ferramentas inclúen:
- Sincroniza o código de LinkedIn a/desde código aberto, semellante .
- Xeración de cabeceira de licenza, similar a .
- Xera automaticamente rexistros de commit de código aberto a partir de rexistros de commit internos.
- Evita cambios internos que rompen as compilacións de código aberto .
As seguintes subseccións afondarán nas funcións mencionadas anteriormente que presentan problemas interesantes.
Sincronización do código fonte
A diferenza da versión de código aberto de DataHub, que é un único repositorio de GitHub, a versión de LinkedIn de DataHub é unha combinación de varios repositorios (chamados internamente ). A interface de DataHub, a biblioteca de modelos de metadatos, o servizo de backend do almacén de metadatos e os traballos de streaming residen en repositorios separados en LinkedIn. Non obstante, para facilitalo aos usuarios de código aberto, temos un único repositorio para a versión de código aberto de DataHub.
Figura 1: Sincronización entre repositorios LinkedIn DataHub e un único repositorio DataHub código aberto
Para admitir fluxos de traballo automatizados de creación, inserción e extracción, a nosa nova ferramenta crea automaticamente unha asignación a nivel de ficheiro correspondente a cada ficheiro de orixe. Non obstante, o conxunto de ferramentas require unha configuración inicial e os usuarios deben proporcionar unha asignación de módulos de alto nivel como se mostra a continuación.
{
"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"
]
}A asignación a nivel de módulo é un simple JSON cuxas claves son os módulos de destino no repositorio de código aberto e os valores son a lista de módulos fonte nos repositorios de LinkedIn. Calquera módulo de destino nun repositorio de código aberto pode ser alimentado por calquera número de módulos de orixe. Para indicar os nomes internos dos repositorios nos módulos fonte, use ao estilo Bash. Usando un ficheiro de asignación a nivel de módulo, as ferramentas crean un ficheiro de asignación a nivel de ficheiro escaneando todos os ficheiros dos directorios asociados.
{
"${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,
}As ferramentas crean automaticamente a asignación de nivel de ficheiro; con todo, tamén pode ser actualizado manualmente polo usuario. Esta é unha asignación 1:1 dun ficheiro fonte de LinkedIn a un ficheiro do repositorio de código aberto. Existen varias regras asociadas a esta creación automática de asociacións de ficheiros:
- No caso de varios módulos de orixe para un módulo de destino en código aberto, poden xurdir conflitos, por exemplo, o mesmo , existente en máis dun módulo fonte. Como estratexia de resolución de conflitos, as nosas ferramentas usan por defecto a opción "o último gaña".
- "null" significa que o ficheiro fonte non forma parte do repositorio de código aberto.
- Despois de cada envío ou extracción de código aberto, esta asignación actualízase automaticamente e créase unha instantánea. Isto é necesario para identificar adicións e eliminacións do código fonte desde a última acción.
Creando rexistros de commit
Os rexistros de commit para commits de código aberto tamén se xeran automaticamente fusionando os rexistros de commit dos repositorios internos. A continuación móstrase un exemplo de rexistro de commit para mostrar a estrutura do rexistro de commit xerado pola nosa ferramenta. Un commit indica claramente cales son as versións dos repositorios de orixe que se empaquetan nesa commit e ofrece un resumo do rexistro de commit. Mira este usando un exemplo real dun rexistro de commit xerado polo noso conxunto de ferramentas.
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.0Probas de dependencia
LinkedIn ten , o que axuda a garantir que os cambios nun multiproduto interno non rompan o conxunto de multiprodutos dependentes. O repositorio de DataHub de código aberto non é multiproduto e non pode ser unha dependencia directa de ningún produto múltiple, pero coa axuda dun envoltorio de varios produtos que obtén o código fonte de DataHub de código aberto, aínda podemos usar esta proba de dependencia. Así, calquera cambio (que posteriormente pode ser exposto) en calquera dos multiprodutos que alimentan o repositorio de DataHub de código aberto desencadea un evento de compilación no multiproduto de shell. Polo tanto, calquera cambio que non consiga construír un produto de envoltura non supera as probas antes de comprometer o produto orixinal e revértese.
Este é un mecanismo útil que axuda a evitar calquera commit interno que rompa a compilación de código aberto e que o detecte no momento da confirmación. Sen isto, sería bastante difícil determinar que commit interno provocou que a compilación do repositorio de código aberto fallase, porque agrupamos os cambios internos no repositorio de código aberto de DataHub.
Diferenzas entre DataHub de código aberto e a nosa versión de produción
Ata este punto, discutimos a nosa solución para sincronizar dúas versións de repositorios de DataHub, pero aínda non esbozamos as razóns polas que necesitamos dous fluxos de desenvolvemento diferentes en primeiro lugar. Nesta sección, enumeraremos as diferenzas entre a versión pública de DataHub e a versión de produción nos servidores de LinkedIn e explicaremos as razóns destas diferenzas.
Unha fonte de discrepancia deriva do feito de que a nosa versión de produción ten dependencias de código que aínda non é de código aberto, como Offspring de LinkedIn (o marco de inxección de dependencias interna de LinkedIn). Offspring úsase amplamente nas bases de código internas porque é o método preferido para xestionar a configuración dinámica. Pero non é de código aberto; polo que necesitabamos atopar alternativas de código aberto ao DataHub de código aberto.
Tamén hai outras razóns. A medida que creamos extensións para o modelo de metadatos para as necesidades de LinkedIn, estas extensións adoitan ser moi específicas para LinkedIn e poden non aplicarse directamente a outros ambientes. Por exemplo, temos etiquetas moi específicas para os ID de participantes e outros tipos de metadatos coincidentes. Entón, agora excluímos estas extensións do modelo de metadatos de código aberto de DataHub. A medida que nos relacionamos coa comunidade e entendemos as súas necesidades, traballaremos en versións comúns de código aberto destas extensións cando sexa necesario.
A facilidade de uso e a adaptación máis sinxela para a comunidade de código aberto tamén inspiraron algunhas das diferenzas entre as dúas versións de DataHub. As diferenzas na infraestrutura de procesamento de fluxos son un bo exemplo diso. Aínda que a nosa versión interna utiliza un marco de procesamento de fluxos xestionado, optamos por utilizar o procesamento de fluxos integrado (autónomo) para a versión de código aberto porque evita crear outra dependencia da infraestrutura.
Outro exemplo da diferenza é ter un único GMS (Generalized Metadata Store) nunha implementación de código aberto en lugar de varios GMS. GMA (Arquitectura xeralizada de metadatos) é o nome da arquitectura de fondo para DataHub e GMS é o almacén de metadatos no contexto de GMA. GMA é unha arquitectura moi flexible que permite distribuír cada construción de datos (por exemplo, conxuntos de datos, usuarios, etc.) no seu propio almacén de metadatos, ou almacenar varias construcións de datos nun único almacén de metadatos, sempre que o rexistro que conteña a asignación da estrutura de datos en GMS está actualizado. Para facilitar o seu uso, escollemos unha única instancia de GMS que almacena todas as diferentes construcións de datos no DataHub de código aberto.
Unha lista completa das diferenzas entre as dúas implementacións aparece na táboa seguinte.
Características do produto
LinkedIn DataHub
DataHub de código aberto
Construcións de datos admitidas
1) Conxuntos de datos 2) Usuarios 3) Métricas 4) Funcións de ML 5) Gráficos 6) Paneles
1) Conxuntos de datos 2) Usuarios
Fontes de metadatos admitidas para conxuntos de datos
1) 2) Base de sofá 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
Confluente Kafka
Procesamento de fluxos
Dirixido
Integrado (autónomo)
Inxección de dependencias e configuración dinámica
LinkedIn Offspring
Ferramentas de construción
Ligradle (envoltorio Gradle interno de LinkedIn)
CI / CD
CRT (CI/CD interno de LinkedIn)
Almacéns de metadatos
Distribuído varios GMS: 1) Conjunto de datos GMS 2) Usuario GMS 3) Métrico GMS 4) Función GMS 5) Gráfico/Panel GMS
GMS único para: 1) Conxuntos de datos 2) Usuarios
Microservizos en contedores Docker
simplifica a implantación e distribución de aplicacións con . Cada parte do servizo en DataHub é de código aberto, incluíndo compoñentes de infraestrutura como Kafka, , и , ten a súa propia imaxe de Docker. Para orquestrar os contedores Docker que usamos .
Figura 2: Arquitectura DataHub *código aberto**
Podes ver a arquitectura de alto nivel de DataHub na imaxe superior. Ademais dos compoñentes da infraestrutura, ten catro contedores Docker diferentes:
datahub-gms: servizo de almacenamento de metadatos
datahub-frontend: aplicación , que serve a interface de DataHub.
datahub-mce-consumer: aplicación , que utiliza o fluxo de eventos de cambio de metadatos (MCE) e actualiza o almacén de metadatos.
datahub-mae-consumer: aplicación , que utiliza un fluxo de eventos de auditoría de metadatos (MAE) e crea un índice de busca e unha base de datos de gráficos.
Documentación do repositorio de código aberto e conteñen información máis detallada sobre as funcións de varios servizos.
CI/CD en DataHub é de código aberto
O repositorio de código aberto DataHub utiliza para a integración continua e para un despliegue continuo. Ambos teñen unha boa integración con GitHub e son fáciles de configurar. Para a maioría das infraestruturas de código aberto desenvolvidas pola comunidade ou empresas privadas (p. ex. ), as imaxes de Docker créanse e despregáronse no Docker Hub para que a comunidade sexa máis sinxela. Calquera imaxe de Docker atopada en Docker Hub pódese usar facilmente cun comando sinxelo .
Con cada compromiso co repositorio de código aberto de DataHub, todas as imaxes de Docker constrúense e impléganse automaticamente no Docker Hub coa etiqueta "última". Se Docker Hub está configurado con algúns , todas as etiquetas do repositorio de código aberto tamén se lanzan cos nomes de etiquetas correspondentes en Docker Hub.
Usando DataHub
é moi sinxelo e consta de tres pasos sinxelos:
- Clona o repositorio de código aberto e executa todos os contedores de Docker con docker-compose usando o script docker-compose proporcionado para un inicio rápido.
- Descarga os datos de mostra proporcionados no repositorio mediante a ferramenta de liña de comandos que tamén se proporciona.
- Navega por DataHub no teu navegador.
Seguimento activo tamén está configurado para preguntas rápidas. Os usuarios tamén poden crear problemas directamente no repositorio de GitHub. O máis importante é que agradecemos todos os comentarios e suxestións!
Planos para o futuro
Actualmente, cada infraestrutura ou microservizo para DataHub de código aberto está construído como un contedor Docker e todo o sistema orquestrárase mediante . Dada a popularidade e xeneralización , tamén nos gustaría ofrecer unha solución baseada en Kubernetes nun futuro próximo.
Tamén pensamos ofrecer unha solución chave en man para implementar DataHub nun servizo de nube pública como , ou . Dado o recente anuncio da migración de LinkedIn a Azure, isto aliñarase coas prioridades internas do equipo de metadatos.
Por último, pero non menos importante, grazas a todos os primeiros usuarios de DataHub na comunidade de código aberto que valoraron DataHub alphas e nos axudaron a identificar problemas e mellorar a documentación.
Fonte: www.habr.com