Publicado el 8 de mayo de 2024
Escrito por Joop van de Ven
Revisa el texto original aquí.
El equipo de la plataforma de datos de Atlassian rediseñó su infraestructura para transformarla en una solución con una visión clara y opiniones definidas. Este rediseño incluyó la incorporación de una nueva capacidad de implementación, inspirada en Kubernetes y Micros (la plataforma interna de Atlassian como servicio), pero especialmente adaptada al dominio de los datos.
Esta nueva capacidad proporciona:
- Un sistema autoservicio de aprovisionamiento de canalizaciones de datos basado en metadatos declarativos.
- Una abstracción extensible para las capacidades de ejecución de las canalizaciones.
- Una experiencia de implementación única y gobernada.
Para desarrollar esta capacidad, aprovechamos la flexibilidad y el poder del marco Kubernetes.
En Atlassian, más de la mitad de la empresa utiliza de manera regular nuestro lago de datos interno, que crece a un ritmo de más de 85 terabytes diarios y potencia tanto las experiencias internas como las de cara al cliente. No está nada mal para un proyecto que comenzó como parte de un ShipIt (un día de innovación habitual en toda la empresa).
El éxito de la primera generación del lago de datos se debe en gran parte a su naturaleza abierta y sin opiniones. Los usuarios de la plataforma tienen la libertad de decidir qué herramientas crear (o instalar) y utilizar, cómo modelar sus datos, qué metadatos capturar y exponer, y cómo ejecutar y respaldar sus canalizaciones de datos. Esta apertura y flexibilidad facilitan la incorporación de los usuarios, siendo la única barrera de entrada aprender sobre las capacidades disponibles. Sin embargo, lo más importante es que coloca a nuestros usuarios en el centro de todo.
Los usuarios de la plataforma son responsables de:
- Conocer qué capacidades están disponibles.
- Asegurarse de que estas capacidades funcionen correctamente y, lo que es más importante, trabajen de manera conjunta.
- Gestionar todo el soporte operativo y el consumo de los datos que generan.
- Capturar y compartir metadatos relevantes sobre sus datos.
La naturaleza abierta e imparcial de la plataforma ha propiciado una transformación acelerada en áreas como la calidad, la observabilidad de los datos y las capacidades de descubrimiento. Algunos equipos crean sus propias herramientas, mientras que otros prefieren usar herramientas estándar que se ajusten mejor a sus métodos de trabajo, e incluso algunos adoptan un enfoque híbrido.
Sin embargo, esta falta de un enfoque estandarizado ha generado desafíos. Los datos ahora se presentan con diferentes niveles de documentación, metadatos, linaje, controles de calidad y observabilidad.
Como resultado, los usuarios de la plataforma:
- Luchan por encontrar datos relevantes.
- A menudo tienen poca confianza en los datos que logran localizar.
- Experimentan una experiencia de usuario fragmentada al implementar y gestionar sus propios datos.
Mientras tanto, los equipos responsables de la plataforma enfrentan dificultades para dar soporte a la plataforma y a los variados ecosistemas de capacidades que existen.
Este no es un problema exclusivo de Atlassian. Las organizaciones que crean sus propios lagos de datos se enfrentan a retos técnicos similares. Aunque optimizan sus lagos para fomentar la adopción, rápidamente se dan cuenta de que, a medida que crece la adopción y las regulaciones de datos se vuelven más estrictas, es necesario cambiar algo: más gobernanza y estandarización.
El camino evolutivo común para las plataformas de datos es estandarizar un conjunto reducido de capacidades (una o dos para cada área clave). Luego, seleccionan aquellas capacidades que puedan integrarse de manera puntual y que, al mismo tiempo, satisfagan las necesidades de gobernanza. A primera vista, este enfoque parece lógico, ya que reduce la carga de soporte de los equipos de plataforma, mientras que los usuarios experimentan cierta unidad o integración. Sin embargo, a medida que evolucionan los requisitos de gobernanza y las herramientas de datos, estas integraciones puntuales resultan difíciles de mantener y, por lo general, pierden valor comercial.
En lugar de centrarse en una experiencia de usuario construida a partir de capacidades aisladas, la experiencia debe modelarse según el flujo de trabajo natural de los usuarios de la plataforma, es decir, debe comenzar con los procesos de los usuarios, no con las capacidades de la plataforma. Este es el punto donde la complejidad aumenta, como se ilustra en el siguiente diagrama.
Los usuarios suelen alternar entre la capacidad de descubrimiento de datos y un entorno de trabajo. La capacidad de descubrimiento de datos debería ofrecer una solución integral en la que los usuarios puedan explorar todos los datos a través de las plataformas de datos de la empresa, para comprender su significado, origen (linaje) y obtener una medida de confianza sobre su calidad y fiabilidad.
De manera similar, el banco de trabajo debe ser un entorno donde los usuarios puedan conectarse a todos los datos disponibles (sujeto a permisos), explotarlos y desarrollar nuevas lógicas de transformación (con herramientas preconfiguradas) que resuelvan el problema en cuestión.
Una vez que los usuarios estén satisfechos con su lógica de transformación, no deberían tener que lidiar con una variedad de capacidades de ejecución (canalización, calidad y observabilidad de los datos). En su lugar, deberían poder implementar toda su lógica de una sola vez, ya sea en SQL, Python, Kotlin, etc., para tareas de ingeniería de datos, aprendizaje automático o análisis. Esto indica que debe existir una capacidad de implementación que proporcione todos los recursos necesarios para la ejecución de canalizaciones, así como la calidad y observabilidad de los datos.
Los metadatos sobre cualquier elemento suministrado deben recopilarse y enviarse a la capacidad de descubrimiento de datos. Asimismo, los resultados de calidad y observabilidad de todos los trabajos de canalización deben ser recopilados y enviados a dicha capacidad.
Lo que ilustra el diagrama anterior es que existen dependencias circulares entre las distintas capacidades. Esto es difícil de resolver mediante soluciones punto a punto de las capacidades disponibles. A continuación, presentaremos la capacidad de implementación que hemos desarrollado, que aborda estos problemas al ofrecer:
- Una puerta de entrada a la producción (para aplicar controles).
- Una única interfaz consistente que permite a los usuarios realizar implementaciones de manera autónoma.
- Un mecanismo extensible para soportar nuevas capacidades de ejecución.
- Un marco de aprovisionamiento declarativo.
La capacidad de implementación oculta la complejidad del aprovisionamiento de canales de datos detrás de una interfaz declarativa. El uso de esta interfaz significa que los usuarios no tienen que aprender a utilizar directamente diferentes capacidades de ejecución, ni saber cómo escribir código para el aprovisionamiento de la plataforma. En cambio, simplemente declaran lo que quieren que sus canales hagan y lo que deben producir, todo a través de metadatos de configuración. De este modo, se desvincula al usuario de las capacidades de ejecución reales del canal. Además, esto facilita que los equipos de plataforma actualicen o migren estas capacidades de ejecución.
El propósito de la capacidad de implementación es aprovisionar canales de datos, por lo que adoptar un enfoque declarativo implica capturar una gran cantidad de metadatos sobre los canales y sus resultados. Por ejemplo, el aprovisionamiento de trabajos de canalización necesita información sobre el tipo de trabajo y sus entradas. Los resultados (como las tablas) deben crearse previamente para garantizar la configuración de permisos adecuados, entre otros aspectos. La ventaja es que todos estos metadatos tienen un inmenso valor para los fines de descubrimiento de datos.
Declarar los metadatos por adelantado, junto con una capacidad que proporcione lo que se declara, tiene un beneficio adicional: elimina la necesidad de inspeccionar (o rastrear) la plataforma para comprender su estado. Aunque la inspección posterior a la implementación podría parecer útil para recopilar metadatos sobre una plataforma, implica riesgos. Por ejemplo, no es posible detectar cambios importantes hasta que se hayan implementado.
Ahora que entendemos que los metadatos enriquecidos deben capturarse por adelantado, el siguiente paso es reconocer que los metadatos conforman un gráfico grande y complejo de relaciones. Por ejemplo:
- Las canalizaciones consisten en uno o más pasos, y cada paso normalmente equivale a un trabajo ejecutado.
- Las canalizaciones pueden depender de otras canalizaciones (de aguas arriba).
- Las canalizaciones generan resultados (por ejemplo, tablas).
- Las tablas pertenecen a una base de datos y constan de columnas.
- Las columnas pueden depender de otras columnas (linaje).
- Las políticas se aplican a las tablas.
- Las relaciones de versiones deben mantenerse.
Además de todas estas relaciones, introducimos una más: los productos de datos. Los productos de datos consisten en las tablas (y, por extensión, su base de datos) y los canales, que en conjunto forman los datos como producto. Los productos de datos proporcionan un fuerte sentido de propiedad sobre los datos y establecen un contrato claro sobre los mismos dentro del producto.
Al integrar todo esto, empieza a surgir el siguiente modelo:
Cada entidad del modelo anterior tiene su propio esquema, a excepción de <Column>, que es un tipo anidado dentro de <Table>. Cada esquema incluye todos los metadatos necesarios para aprovisionar la entidad correspondiente, así como cualquier metadato adicional que pueda ser útil en un contexto de descubrimiento.
En su repositorio de código fuente, junto con la lógica de transformación, los usuarios crean archivos de configuración que contienen metadatos sobre las entidades necesarias para ejecutar dicha lógica en el lago de datos. El repositorio actúa como un registro de auditoría para todos los cambios en los archivos de configuración, y permite un proceso de aprobación mediante solicitudes de incorporación de cambios (PR). Una vez que una PR es aprobada, como parte del flujo CI/CD, los archivos de configuración se envían a la capacidad de implementación, que luego toma la lógica de transformación y aprovisiona las entidades correspondientes.
El modelo anterior abarca solo tablas y bases de datos. Sin embargo, se puede extender fácilmente más allá de los lagos de datos hacia plataformas de streaming (aunque lo hemos omitido para simplificar y clarificar).
El <Steps> mapa de pasos de la canalización corresponde a los trabajos que se ejecutan en el lago. Aquí adoptamos una abstracción deliberada. Los usuarios tienen control sobre la capacidad de ejecución de la canalización que desean utilizar, pero sin necesidad de aprender todos los detalles de implementación de esas capacidades, mientras que los ingenieros encargados de crear y mantener la plataforma no tienen que desarrollar un lenguaje de configuración de canalización universal. Tomemos como ejemplo una canalización con una transformación dbt; su archivo de configuración sería similar al siguiente.
id: pipeline/91b21ee3-57be-4380-ac95-a809d216bd49
name: example_pipeline
product: product/30c151b9-d841-4bff-b27a-06ac980fcbe6
version: 1
schedule:
cron: 0 0 * * *
dependencies:
- pipeline/73a7ba9d-f0f5-40e4-93d6-cc62014902de
- pipeline/c464915c-ee5f-4118-b1ec-c5db4f63da71
steps:
- name: simple_transformation
transformation:
dbt:
project: mySimpleDbtProject
outputs:
- table/1c698484-4988-49b7-8f2c-83ac4f93350dTenga en cuenta el uso de la dbt palabra clave (línea 13). Las distintas capacidades de ejecución (o distintas versiones de una determinada capacidad) tienen distintas palabras clave. Esto proporciona un mecanismo extensible para añadir capacidades de ejecución adicionales simplemente introduciendo nuevas palabras clave. También facilita la identificación de los procesos afectados por un cambio en una determinada capacidad de ejecución.
Ahora profundizaremos un poco más en la implementación de la capacidad de implementación. Lo primero que debemos tener en cuenta es que esta capacidad es la única vía mediante la cual los usuarios pueden realizar cambios en los procesos de producción. Por lo tanto, es crucial que valide todos los metadatos que recibe. La validación es la primera acción que realiza la capacidad al recibir cualquier entrada.
La validación no solo asegura la integridad de la plataforma y la calidad de los datos en el lago, sino que también actúa como un filtro para cumplir con requisitos adicionales, como convenciones de nomenclatura, información de propiedad y estándares de calidad, entre otros.
Si los metadatos superan la validación, el siguiente paso es que la capacidad de implementación proporcione lo que se ha declarado en los metadatos. Para lograr esto, la lógica de aprovisionamiento interactúa con las aplicaciones que conforman el lago de datos. Estas aplicaciones incluyen productos listos para usar como AWS, dbt, Databricks, Anomalo, Airflow, Fivetran, Immuta, entre otros, así como aplicaciones desarrolladas internamente. Una vez que las entidades han sido aprovisionadas, los metadatos correspondientes se agregan al almacén de metadatos para su posterior descubrimiento.
La capacidad está construida sobre Kubernetes. El punto de entrada a la capacidad es una puerta de enlace que valida el conjunto de archivos de configuración (todos los archivos que componen el producto de datos) enviados a través del flujo CI/CD. A continuación, cada archivo de configuración se envuelve en un manifiesto de Kubernetes anotado antes de ser entregado a Kubernetes para su implementación.
Kubernetes está configurado con controladores y operadores de admisión personalizados para cada entidad en el modelo descrito anteriormente. Al recibir el manifiesto de una entidad, los controladores de admisión realizan validaciones adicionales, lo que puede incluir la interacción con las aplicaciones asociadas al controlador.
Si todos los pasos de validación son satisfactorios, el operador correspondiente proporcionará los recursos necesarios para la entidad, basándose en los archivos de configuración y utilizando las aplicaciones asociadas. Esto se logra gracias a que los operadores de Kubernetes están fundamentados en un bucle de control. Cada vez que los archivos de configuración se modifican mediante una solicitud de incorporación de cambios o según un cronograma determinado, los operadores comparan el estado actual de los recursos con el estado deseado declarado en los archivos. Si los estados no coinciden, los operadores sincronizan los recursos de la entidad con el estado deseado según lo especificado en los archivos de configuración.
Cabe destacar que Kubernetes ofrece mucho más que solo el marco de conciliación utilizado en el servicio de implementación. En esencia, es un sistema diseñado para automatizar la implementación, el escalado y la gestión de aplicaciones en contenedores. Sin embargo, nuestra capacidad de implementación se apoya exclusivamente en el marco de conciliación de Kubernetes, ya que los controladores y operadores proporcionan un mecanismo extensible para aprovisionar y gestionar los recursos asociados a cada entidad. Estos controladores y operadores personalizados, junto con el marco de conciliación de Kubernetes, nos permiten implementar eficazmente canalizaciones de datos.
En este artículo, se presentó una nueva capacidad para implementar canalizaciones de datos. Esta capacidad:
- Resume las capacidades de la plataforma para los usuarios, permitiéndoles concentrarse en sus fortalezas (como definir la lógica de transformación), y les proporciona una forma simple y consistente de autogestionar la implementación de su lógica de transformación.
- Ofrece a los equipos de la plataforma un mayor control sobre la evolución de la plataforma.
- Proporciona un mecanismo para aplicar la gobernanza en las implementaciones de canalizaciones de datos.
La nueva capacidad logra todo esto porque su diseño parte del proceso de los usuarios. Como resultado, la capacidad integra de manera eficiente áreas separadas pero interrelacionadas, como el descubrimiento de datos, la gobernanza de datos y la implementación y gestión de canalizaciones de datos.
Publicado el 8 de mayo de 2024
Escrito por Joop van de Ven
Revisa el texto original aquí.
Somos S4E Solutions for Eveyone, Platinium Solution Partner de Atlassian en Latinoamérica visítanos y otras soluciones digitales para tu compañía. ¡Conversemos!
Nos puedes encontrar en redes sociales, ¡Síguenos para tener actualizaciones diarias!
LinkedIn , YouTube, Facebook y Twitter.
S4E cuenta con un equipo de soporte certificado en herramientas Atlassian y AWS.
