Open Source DataHub: plataforma de búsqueda y descubrimiento de metadatos de LinkedIn
Encontrar rápidamente los datos que necesita es esencial para cualquier empresa que dependa de grandes cantidades de datos para tomar decisiones basadas en datos. Esto no solo afecta la productividad de los usuarios de datos (incluidos analistas, desarrolladores de aprendizaje automático, científicos de datos e ingenieros de datos), sino que también tiene un impacto directo en los productos finales que dependen de un proceso de aprendizaje automático (ML) de calidad. Además, la tendencia hacia la implementación o construcción de plataformas de aprendizaje automático plantea naturalmente la pregunta: ¿cuál es su método para descubrir internamente características, modelos, métricas, conjuntos de datos, etc.?
En este artículo hablaremos sobre cómo publicamos una fuente de datos bajo licencia abierta. en nuestra plataforma de búsqueda y descubrimiento de metadatos, desde los primeros días del proyecto . LinkedIn mantiene su propia versión de DataHub separada de la versión de código abierto. Comenzaremos explicando por qué necesitamos dos entornos de desarrollo separados, luego discutiremos los primeros enfoques para usar el código abierto WhereHows y compararemos nuestra versión interna (de producción) de DataHub con la versión en . También compartiremos detalles sobre nuestra nueva solución automatizada para enviar y recibir actualizaciones de código abierto para mantener ambos repositorios sincronizados. Finalmente, brindaremos instrucciones sobre cómo comenzar a usar el DataHub de código abierto y discutiremos brevemente su arquitectura.
¡WhereHows es ahora un DataHub!
El equipo de metadatos de LinkedIn presentado anteriormente (sucesor de WhereHows), la plataforma de búsqueda y descubrimiento de metadatos de LinkedIn, y planes compartidos para abrirla. Poco después de este anuncio, lanzamos una versión alfa de DataHub y la compartimos con la comunidad. Desde entonces, hemos contribuido continuamente al repositorio y trabajado con usuarios interesados para agregar las funciones más solicitadas y resolver problemas. Ahora nos complace anunciar el lanzamiento oficial. .
Enfoques de código abierto
WhereHows, el portal original de LinkedIn para encontrar datos y de dónde provienen, comenzó como un proyecto interno; el equipo de metadatos lo abrió . Desde entonces, el equipo siempre ha mantenido dos bases de código diferentes, una para código abierto y otra para uso interno de LinkedIn, ya que no todas las características del producto desarrolladas para los casos de uso de LinkedIn eran generalmente aplicables a una audiencia más amplia. Además, WhereHows tiene algunas dependencias internas (infraestructura, bibliotecas, etc.) que no son de código abierto. En los años siguientes, WhereHows pasó por muchas iteraciones y ciclos de desarrollo, lo que hizo que mantener sincronizadas las dos bases de código fuera un gran desafío. El equipo de metadatos ha probado diferentes enfoques a lo largo de los años para intentar mantener sincronizado el desarrollo interno y el de código abierto.
Primer intento: "Abrir el código fuente primero"
Inicialmente seguimos un modelo de desarrollo de "código abierto primero", donde la mayor parte del desarrollo ocurre en un repositorio de código abierto y se realizan cambios para la implementación interna. El problema con este enfoque es que el código siempre se envía primero a GitHub antes de que se haya revisado completamente internamente. Hasta que no se realicen cambios desde el repositorio de código abierto y se realice una nueva implementación interna, no encontraremos ningún problema de producción. En caso de una implementación deficiente, también era muy difícil determinar al culpable porque los cambios se realizaban en lotes.
Además, este modelo redujo la productividad del equipo al desarrollar nuevas funciones que requerían iteraciones rápidas, ya que obligaba a que todos los cambios se enviaran primero a un repositorio de código abierto y luego a un repositorio interno. Para reducir el tiempo de procesamiento, la corrección o el cambio requerido se podía realizar primero en el repositorio interno, pero esto se convirtió en un gran problema cuando se trataba de fusionar esos cambios nuevamente en el repositorio de código abierto porque los dos repositorios no estaban sincronizados.
Este modelo es mucho más fácil de implementar para plataformas compartidas, bibliotecas o proyectos de infraestructura que para aplicaciones web personalizadas con todas las funciones. Además, este modelo es ideal para proyectos que comienzan con el código abierto desde el primer día, pero WhereHows se creó como una aplicación web completamente interna. Fue realmente difícil abstraer por completo todas las dependencias internas, por lo que necesitábamos mantener la bifurcación interna, pero mantener la bifurcación interna y desarrollar principalmente código abierto no funcionó del todo.
Segundo intento: “primero el interior”
**Como segundo intento, pasamos a un modelo de desarrollo "primero interno", donde la mayor parte del desarrollo se realiza internamente y se realizan cambios en el código fuente abierto de forma regular. Aunque este modelo es el más adecuado para nuestro caso de uso, tiene problemas inherentes. Enviar directamente todas las diferencias al repositorio de código abierto y luego intentar resolver los conflictos de fusión más tarde es una opción, pero lleva mucho tiempo. En la mayoría de los casos, los desarrolladores intentan no hacer esto cada vez que revisan su código. Como resultado, esto se hará con mucha menos frecuencia, en lotes, y por lo tanto hará más difícil resolver conflictos de fusión más adelante.
¡La tercera vez funcionó!
Los dos intentos fallidos mencionados anteriormente dieron como resultado que el repositorio de WhereHows GitHub permaneciera desactualizado durante mucho tiempo. El equipo continuó mejorando las características y la arquitectura del producto, de modo que la versión interna de WhereHows para LinkedIn llegó a ser más avanzada que la versión de código abierto. Incluso tenía un nuevo nombre: DataHub. Basándose en intentos fallidos anteriores, el equipo decidió desarrollar una solución escalable a largo plazo.
Para cualquier nuevo proyecto de código abierto, el equipo de código abierto de LinkedIn asesora y respalda un modelo de desarrollo en el que los módulos del proyecto se desarrollan íntegramente en código abierto. Los artefactos versionados se implementan en un repositorio público y luego se vuelven a registrar en el artefacto interno de LinkedIn usando . Seguir este modelo de desarrollo no sólo es bueno para quienes usan código abierto, sino que también da como resultado una arquitectura más modular, extensible y conectable.
Sin embargo, una aplicación de back-end madura como DataHub requerirá una cantidad significativa de tiempo para alcanzar este estado. Esto también excluye la posibilidad de abrir una implementación completamente funcional antes de que se hayan abstraído por completo todas las dependencias internas. Es por eso que hemos desarrollado herramientas que nos ayudan a realizar contribuciones de código abierto más rápido y con mucho menos dolor. Esta solución beneficia tanto al equipo de metadatos (desarrollador de DataHub) como a la comunidad de código abierto. Las siguientes secciones discutirán este nuevo enfoque.
Automatización de publicación de código abierto
El último enfoque del equipo de Metadatos para el DataHub de código abierto es desarrollar una herramienta que sincronice automáticamente el código base interno y el repositorio de código abierto. Las características de alto nivel de este kit de herramientas incluyen:
- Sincronizar código de LinkedIn hacia/desde código abierto, similar .
- Generación de encabezado de licencia, similar a .
- Genere automáticamente registros de confirmación de código abierto a partir de registros de confirmación internos.
- Evite cambios internos que rompan las compilaciones de código abierto .
Las siguientes subsecciones profundizarán en las funciones mencionadas anteriormente que tienen problemas interesantes.
Sincronización del código fuente
A diferencia de la versión de código abierto de DataHub, que es un único repositorio de GitHub, la versión de LinkedIn de DataHub es una combinación de múltiples repositorios (llamados internamente ). La interfaz de DataHub, la biblioteca de modelos de metadatos, el servicio backend del almacén de metadatos y los trabajos de transmisión residen en repositorios separados en LinkedIn. Sin embargo, para hacerlo más fácil para los usuarios de código abierto, tenemos un repositorio único para la versión de código abierto de DataHub.
Figura 1: Sincronización entre repositorios Etiqueta LinkedIn DataHub y un único repositorio DataHub fuente abierta
Para admitir flujos de trabajo automatizados de compilación, inserción y extracción, nuestra nueva herramienta crea automáticamente una asignación a nivel de archivo correspondiente a cada archivo fuente. Sin embargo, el kit de herramientas requiere una configuración inicial y los usuarios deben proporcionar una asignación de módulos de alto nivel como se muestra 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"
]
}El mapeo a nivel de módulo es un JSON simple cuyas claves son los módulos de destino en el repositorio de código abierto y los valores son la lista de módulos de origen en los repositorios de LinkedIn. Cualquier módulo de destino en un repositorio de código abierto puede ser alimentado por cualquier número de módulos de origen. Para indicar los nombres internos de los repositorios en los módulos fuente, utilice en estilo Bash. Al utilizar un archivo de mapeo a nivel de módulo, las herramientas crean un archivo de mapeo a nivel de archivo escaneando todos los archivos en los 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,
}Las herramientas crean automáticamente la asignación de nivel de archivo; sin embargo, el usuario también puede actualizarlo manualmente. Esta es una asignación 1:1 de un archivo fuente de LinkedIn a un archivo en el repositorio de código abierto. Existen varias reglas asociadas a esta creación automática de asociaciones de archivos:
- En el caso de varios módulos de origen para un módulo de destino en código abierto, pueden surgir conflictos, por ejemplo, el mismo , existente en más de un módulo fuente. Como estrategia de resolución de conflictos, nuestras herramientas utilizan de forma predeterminada la opción "el último gana".
- "nulo" significa que el archivo fuente no forma parte del repositorio de código abierto.
- Después de cada envío o extracción de código abierto, esta asignación se actualiza automáticamente y se crea una instantánea. Esto es necesario para identificar adiciones y eliminaciones del código fuente desde la última acción.
Crear registros de confirmación
Los registros de confirmación para confirmaciones de código abierto también se generan automáticamente al fusionar los registros de confirmación de los repositorios internos. A continuación se muestra un registro de confirmación de muestra para mostrar la estructura del registro de confirmación generado por nuestra herramienta. Una confirmación indica claramente qué versiones de los repositorios de origen están empaquetadas en esa confirmación y proporciona un resumen del registro de confirmación. Mira este usando un ejemplo real de un registro de confirmación generado por nuestro kit de herramientas.
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.0Pruebas de dependencia
LinkedIn tiene , lo que ayuda a garantizar que los cambios en un multiproducto interno no interrumpan el ensamblaje de los multiproductos dependientes. El repositorio de código abierto de DataHub no es multiproducto y no puede ser una dependencia directa de ningún multiproducto, pero con la ayuda de un contenedor multiproducto que recupera el código fuente de código abierto de DataHub, aún podemos usar esta prueba de dependencia. Por lo tanto, cualquier cambio (que luego puede quedar expuesto) en cualquiera de los multiproductos que alimentan el repositorio de código abierto de DataHub desencadena un evento de compilación en el multiproducto del shell. Por lo tanto, cualquier cambio que no pueda crear un producto contenedor no pasa las pruebas antes de confirmar el producto original y se revierte.
Este es un mecanismo útil que ayuda a prevenir cualquier confirmación interna que rompa la compilación de código abierto y la detecte en el momento de la confirmación. Sin esto, sería bastante difícil determinar qué confirmación interna provocó que fallara la compilación del repositorio de código abierto, porque realizamos cambios internos por lotes en el repositorio de código abierto de DataHub.
Diferencias entre DataHub de código abierto y nuestra versión de producción
Hasta este punto, hemos analizado nuestra solución para sincronizar dos versiones de repositorios de DataHub, pero aún no hemos descrito las razones por las que necesitamos dos flujos de desarrollo diferentes en primer lugar. En esta sección, enumeraremos las diferencias entre la versión pública de DataHub y la versión de producción en los servidores de LinkedIn, y explicaremos los motivos de estas diferencias.
Una fuente de discrepancia surge del hecho de que nuestra versión de producción tiene dependencias de código que aún no es de código abierto, como Offspring de LinkedIn (el marco de inyección de dependencia interna de LinkedIn). Offspring se usa ampliamente en bases de código internas porque es el método preferido para administrar la configuración dinámica. Pero no es de código abierto; por lo que necesitábamos encontrar alternativas de código abierto al DataHub de código abierto.
Hay otras razones también. A medida que creamos extensiones para el modelo de metadatos para las necesidades de LinkedIn, estas extensiones suelen ser muy específicas de LinkedIn y es posible que no se apliquen directamente a otros entornos. Por ejemplo, tenemos etiquetas muy específicas para los ID de los participantes y otros tipos de metadatos coincidentes. Por lo tanto, ahora hemos excluido estas extensiones del modelo de metadatos de código abierto de DataHub. A medida que interactuemos con la comunidad y comprendamos sus necesidades, trabajaremos en versiones comunes de código abierto de estas extensiones cuando sea necesario.
La facilidad de uso y la adaptación más sencilla para la comunidad de código abierto también inspiraron algunas de las diferencias entre las dos versiones de DataHub. Las diferencias en la infraestructura de procesamiento de flujos son un buen ejemplo de esto. Aunque nuestra versión interna utiliza un marco de procesamiento de flujo administrado, elegimos utilizar el procesamiento de flujo integrado (independiente) para la versión de código abierto porque evita crear otra dependencia de infraestructura.
Otro ejemplo de la diferencia es tener un único GMS (almacén de metadatos generalizados) en una implementación de código abierto en lugar de varios GMS. GMA (Arquitectura de metadatos generalizada) es el nombre de la arquitectura de back-end de DataHub y GMS es el almacén de metadatos en el contexto de GMA. GMA es una arquitectura muy flexible que le permite distribuir cada construcción de datos (por ejemplo, conjuntos de datos, usuarios, etc.) en su propio almacén de metadatos, o almacenar múltiples construcciones de datos en un único almacén de metadatos siempre que el registro que contiene el mapeo de la estructura de datos en GMS está actualizado. Para facilitar su uso, elegimos una única instancia de GMS que almacena todas las diferentes construcciones de datos en el DataHub de código abierto.
En la siguiente tabla se proporciona una lista completa de las diferencias entre las dos implementaciones.
Características del producto
Centro de datos de LinkedIn
Centro de datos de código abierto
Construcciones de datos admitidas
1) Conjuntos de datos 2) Usuarios 3) Métricas 4) Funciones de aprendizaje automático 5) Gráficos 6) Paneles
1) Conjuntos de datos 2) Usuarios
Fuentes de metadatos admitidas para conjuntos de datos
1) 2) Base del sofá 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Listo 12) 13) Teradata 13) Vector 14)
Colmena Kafka RDBMS
pub-sub
Kafka confluente
Procesamiento de flujo
Gestionado
Integrado (independiente)
Inyección de dependencia y configuración dinámica
LinkedIn descendientes
Construir herramientas
Ligradle (envoltorio interno de Gradle de LinkedIn)
CI / CD
CRT (CI/CD interno de LinkedIn)
y
Almacenes de metadatos
Múltiples GMS distribuidos: 1) GMS de conjunto de datos 2) GMS de usuario 3) GMS métrico 4) GMS de características 5) GMS de gráfico/panel
GMS único para: 1) Conjuntos de datos 2) Usuarios
Microservicios en contenedores Docker
simplifica la implementación y distribución de aplicaciones con . Cada parte del servicio en DataHub es de código abierto, incluidos componentes de infraestructura como Kafka, , и , tiene su propia imagen de Docker. Para orquestar los contenedores Docker utilizamos .
Figura 2: Arquitectura DataHub *fuente abierta**
Puede ver la arquitectura de alto nivel de DataHub en la imagen de arriba. Además de los componentes de infraestructura, cuenta con cuatro contenedores Docker diferentes:
datahub-gms: servicio de almacenamiento de metadatos
interfaz de centro de datos: aplicación , sirviendo a la interfaz DataHub.
datahub-mce-consumidor: aplicación , que utiliza la secuencia de eventos de cambio de metadatos (MCE) y actualiza el almacén de metadatos.
datahub-mae-consumidor: aplicación , que utiliza un flujo de eventos de auditoría de metadatos (MAE) y crea un índice de búsqueda y una base de datos de gráficos.
Documentación del repositorio de código abierto y contienen información más detallada sobre las funciones de varios servicios.
CI/CD en DataHub es de código abierto
El repositorio de código abierto DataHub utiliza para la integración continua y para un despliegue continuo. Ambos tienen buena integración con GitHub y son fáciles de configurar. Para la mayoría de la infraestructura de código abierto desarrollada por la comunidad o empresas privadas (p. ej. ), las imágenes de Docker se crean y se implementan en Docker Hub para facilitar su uso por parte de la comunidad. Cualquier imagen de Docker que se encuentre en Docker Hub se puede usar fácilmente con un simple comando .
Con cada confirmación al repositorio de código abierto de DataHub, todas las imágenes de Docker se crean e implementan automáticamente en Docker Hub con la etiqueta "última". Si Docker Hub está configurado con algunos , todas las etiquetas en el repositorio de código abierto también se publican con los nombres de etiqueta correspondientes en Docker Hub.
Usando el centro de datos
Es muy sencillo y consta de tres sencillos pasos:
- Clone el repositorio de código abierto y ejecute todos los contenedores Docker con docker-compose utilizando el script docker-compose proporcionado para un inicio rápido.
- Descargue los datos de muestra proporcionados en el repositorio utilizando la herramienta de línea de comandos que también se proporciona.
- Explore DataHub en su navegador.
Seguimiento activo También configurado para preguntas rápidas. Los usuarios también pueden crear incidencias directamente en el repositorio de GitHub. Lo más importante es que damos la bienvenida y apreciamos todos los comentarios y sugerencias.
Planes para el futuro
Actualmente, cada infraestructura o microservicio para DataHub de código abierto se construye como un contenedor Docker y todo el sistema se organiza utilizando . Dada la popularidad y la difusión , también nos gustaría ofrecer una solución basada en Kubernetes en un futuro próximo.
También planeamos proporcionar una solución llave en mano para implementar DataHub en un servicio de nube pública como , o . Dado el reciente anuncio de la migración de LinkedIn a Azure, esto se alineará con las prioridades internas del equipo de metadatos.
Por último, pero no menos importante, gracias a todos los primeros usuarios de DataHub en la comunidad de código abierto que calificaron a DataHub alfa y nos ayudaron a identificar problemas y mejorar la documentación.
Fuente: habr.com