El viaje a la malla de datos - Parte 3 - Creación de los primeros productos de datos
Corporación Actian
22 de abril de 2024
Aunque la bibliografía sobre el mallado de datos es extensa, a menudo describe un estado final, rara vez cómo conseguirlo en la práctica. Surge entonces la pregunta:
¿Qué enfoque adoptar para transformar la gestión de datos e implantar una malla de datos?
En esta serie de artículos, encontrará un extracto de nuestra Guía práctica de la malla de datos, en la que proponemos un enfoque para poner en marcha un viaje de malla de datos en su organización, estructurado en torno a los cuatro principios de la malla de datos (propiedad y arquitectura de datos descentralizada y orientada al dominio, datos como producto, infraestructura de datos de autoservicio como plataforma y gobernanza computacional federada) y aprovechando los recursos humanos y tecnológicos existentes.
- Parte 1: Determinación del alcance del proyecto piloto
- Parte 2: Reunir un equipo de desarrollo y una plataforma de datos para el proyecto piloto
- Parte 3: Creación de los primeros productos de datos
- Parte 4: Implantación de la gobernanza informática federada
A lo largo de esta serie de artículos, y con el fin de ilustrar este enfoque para construir los cimientos de una malla de datos de éxito, nos basaremos en un ejemplo: el de la empresa ficticia Premium Offices, una inmobiliaria comercial cuya actividad consiste en adquirir propiedades para arrendarlas a empresas.
En los primeros artículos de la serie, hemos identificado los dominios, definido un caso de uso inicial y reunido al equipo responsable de su desarrollo. Ahora es el momento de pasar al segundo principio de la malla de datos, "los datos como producto", desarrollando los primeros productos de datos.
El enfoque de pensamiento de producto de la malla
En la última década, los dominios han desarrollado a menudo una cultura de producto en torno a sus capacidades operativas. Ofrecen sus productos al resto de la organización como API que pueden consumirse y componerse para desarrollar nuevos servicios y aplicaciones. En algunas organizaciones, los equipos se esfuerzan por ofrecer la mejor experiencia posible a los desarrolladores que utilizan sus API de dominio: búsqueda en un catálogo global, documentación completa, ejemplos de código, entornos sandbox, niveles de servicio garantizados y supervisados, etc.
Estas API se gestionan como productos que nacen, evolucionan con el tiempo (sin rupturas de compatibilidad), se enriquecen y acaban siendo obsoletas, normalmente sustituidas por una versión más nueva, más moderna y con más prestaciones.
La malla de datos propone aplicar este mismo enfoque de pensamiento de producto a los datos compartidos por los dominios.
Características de los productos de datos
En algunas organizaciones, esta cultura orientada al producto ya está bien establecida. En otras, habrá que desarrollarla o introducirla. Pero no nos equivoquemos:
Un producto de datos no es un nuevo artefacto digital que requiera nuevas capacidades técnicas (como un producto API). Es simplemente el resultado de un enfoque particular de gestión de datos expuesto por un dominio al resto de la organización.
Gestionar las API como un producto no requería un gran avance tecnológico: el middleware existente hacía el trabajo perfectamente. Del mismo modo, los productos de datos pueden desplegarse en las infraestructuras de datos existentes, sean cuales sean. Técnicamente, un producto de datos puede ser un simple archivo en un lago de datos con una interfaz SQL; un pequeño esquema en estrella, complementado con algunas vistas que faciliten la consulta, instanciado en una base de datos relacional; o incluso una API, un flujo Kafka, un archivo Excel, etc.
Un producto de datos no se define por cómo se materializa, sino por cómo se diseña, gestiona y gobierna; y por un conjunto de características que permiten su explotación a gran escala dentro de la organización.
Estas características suelen condensarse en el acrónimo DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure).
Además, la obtención de un producto de datos DATSIS no requiere inversiones significativas. Se trata de definir un conjunto de convenciones globales que deben seguir los dominios (nomenclatura, protocolos admitidos, gestión de accesos y permisos, controles de calidad, metadatos, etc.). La aplicación operativa de estas convenciones no suele requerir nuevas capacidades tecnológicas: las soluciones existentes suelen bastar para empezar.
Sin embargo, el catálogo constituye una excepción. Desempeña un papel central en el despliegue de la malla de datos al permitir a los dominios publicar información sobre sus productos de datos, y a los consumidores explorar, buscar, comprender y explotar estos productos de datos.
Buenas prácticas para el diseño de productos de datos
Diseñar un producto de datos no es, desde luego, una ciencia exacta: puede haber un solo producto, o tres o cuatro. Para orientar esta elección, una vez más es útil aprovechar algunas de las mejores prácticas de las arquitecturas distribuidas: un producto de datos debe:
- Tener una responsabilidad única y bien definida.
- Disponer de interfaces estables y garantizar la compatibilidad con versiones anteriores.
- Ser utilizable en varios contextos diferentes y, por tanto, favorecer el poliglotismo.
Experiencia como desarrollador de productos de datos
La experiencia del desarrollador es también un aspecto fundamental de la malla de datos, con la ambición de hacer converger el desarrollo de productos de datos y el desarrollo de servicios o componentes de software. No se trata solo de ser amable con los ingenieros, sino también de responder a una cierta racionalidad económica:
La descentralización de la gestión de datos implica que los dominios dispongan de sus propios recursos para desarrollar productos de datos. En muchas organizaciones, el equipo de datos centralizado no es lo suficientemente grande como para apoyar a los equipos distribuidos. Para garantizar el éxito de la malla de datos, es esencial poder recurrir a la reserva de ingenieros de software, que suele ser mayor.
El estado del arte en el desarrollo de software se basa en un alto nivel de automatización: asignación declarativa de recursos de infraestructura, pruebas unitarias y de integración automatizadas, creación y despliegue orquestados mediante herramientas CI/CD, flujos de trabajo Git para la gestión de fuentes y versiones, publicación automática de documentación, etc.
El desarrollo de productos de datos debe converger hacia este estado del arte - y dependiendo de la madurez de la organización, sus equipos y su pila tecnológica, esta convergencia llevará más o menos tiempo. El enfoque correcto es automatizar todo lo posible utilizando las herramientas existentes y dominadas, y luego identificar las operaciones que no están automatizadas para integrar gradualmente herramientas adicionales.
En la práctica, esto es lo que constituye un producto de datos:
- Primero el código - Para canalizaciones que alimentan el producto de datos con datos procedentes de distintas fuentes u otros productos de datos; para cualquier API de consumo del producto de datos; para probar canalizaciones y controlar la calidad de los datos; etc.
- Datos, por supuesto - Pero la mayoría de las veces, los datos existen en los sistemas y son simplemente extraídos y transformados por pipelines. Por lo tanto, no están presentes en el código fuente (salvo excepciones).
- Metadatos - Algunos de los cuales documentan el producto de datos: esquema, semántica, sintaxis, calidad, linaje, etc. Otros tienen por objeto garantizar la gobernanza del producto a escala de malla: contratos, responsabilidades, políticas de acceso, restricciones de uso, etc.
- Infraestructura - O más exactamente, la declaración de los recursos físicos necesarios para instanciar el producto de datos: despliegue y ejecución de código, despliegue de metadatos, asignación de recursos para el almacenamiento, etc.
En cuanto a la infraestructura, la malla de datos no requiere nuevas capacidades: la gran mayoría de las organizaciones ya disponen de una plataforma de datos. La implantación de la malla de datos tampoco requiere una plataforma centralizada. Algunas empresas ya han invertido en una plataforma común, y parece lógico aprovechar las capacidades de esta plataforma para desarrollar la malla; pero otras tienen varias plataformas, algunas entidades o ciertos dominios que cuentan con su infraestructura. Es totalmente posible desplegar la malla de datos en estas infraestructuras híbridas: mientras los productos de datos respeten unas normas comunes de direccionabilidad, interoperabilidad y control de acceso, las modalidades técnicas de su ejecución tienen poca importancia.
Oficinas Premium Ejemplo:
Para establecer un marco inicial de gobernanza de su malla de datos, Premium Offices ha fijado las siguientes normas:
- Un producto de datos se materializa como un proyecto dedicado en BigQuery - esto permite establecer reglas de acceso a nivel de proyecto, o más finamente si es necesario. Estos proyectos se colocarán en un directorio "productos de datos" y en un subdirectorio con el nombre del dominio al que pertenecen (en nuestro ejemplo, "Brokerage").
- Los productos de datos deben ofrecer vistas para acceder a los datos: estas vistas proporcionan una interfaz de consumo estable y permiten potencialmente evolucionar el modelo interno del producto sin afectar a sus consumidores.
- Todos los productos de datos deben identificar los datos utilizando referencias comunes para datos comunes (Clientes, Productos, Proveedores, Empleados, etc.) - esto simplifica la referencia cruzada de datos de diferentes productos de datos (LEI, código de producto, UPC, EAN, dirección de correo electrónico, etc.).
- El acceso a los productos de datos requiere una autenticación sólida basada en las capacidades de IAM de GCP: es posible utilizar una cuenta de servicio, pero cada usuario de un producto de datos debe tener entonces una cuenta de servicio dedicada. Cuando las políticas de acceso dependen de los usuarios, debe utilizarse la identidad del usuario final mediante autenticación OAuth2.
- La norma es conceder acceso sólo a las vistas, y no al modelo interno.
- El propietario del producto de datos procesa las solicitudes de acceso mediante flujos de trabajo establecidos en ServiceNow.
- DBT es el ETL preferido para implementar pipelines - cada producto de datos tiene un repositorio dedicado para su pipeline.
- Un producto de datos puede consumirse a través del protocolo JDBC o a través de las API de BigQuery (sólo lectura).
- Un producto de datos debe definir su contrato: frecuencia de actualización de los datos, niveles de calidad, clasificación de la información, políticas de acceso y restricciones de uso.
- El producto de datos debe publicar sus metadatos y documentación en un mercado - a falta de un sistema existente, Premium Offices decide documentar sus primeros productos de datos en un espacio dedicado en la wiki de su empresa.
Este conjunto inicial de normas evolucionará, por supuesto, pero establece un marco pragmático para garantizar las características DATSIS de los productos de datos aprovechando exclusivamente las tecnologías y competencias existentes. Para su proyecto piloto, Premium Offices ha optado por descomponer la arquitectura en dos productos de datos:
- Análisis de contratos de arrendamiento - Este primer producto de datos ofrece capacidades analíticas sobre los contratos de arrendamiento: entidad, empresa matriz, ubicación del inmueble, fecha de inicio del arrendamiento, fecha de finalización del arrendamiento, tipo de arrendamiento, importe del alquiler, etc. Se modela en forma de un pequeño esquema en estrella que permite el análisis a lo largo de 2 dimensiones: tiempo e inquilino - éstas son las dimensiones de análisis necesarias para construir la primera versión del cuadro de mando. También incluye una o dos vistas que aprovechan el esquema en estrella para proporcionar datos pre-agregados - estas vistas constituyen la interfaz pública del producto de datos. Por último, incluye una vista para obtener la lista más reciente de inquilinos.
- Calificaciones de entidades - Este segundo producto de datos proporciona calificaciones históricas de entidades en forma de un conjunto de datos simple y una vista en espejo que sirve de interfaz, de acuerdo con normas comunes. La calificación se obtiene de un proveedor especializado, que las distribuye en forma de API. Para invocar esta API, debe proporcionarse una lista de entidades, obtenida mediante el consumo de la interfaz apropiada del producto analítico Tenancy.
En conclusión, adoptar la mentalidad de tratar los datos como un producto es esencial para las organizaciones en proceso de descentralización de la gestión de datos. Este enfoque cultiva una cultura de responsabilidad, estandarización y eficiencia en la gestión de datos en distintos ámbitos. Al considerar los datos como un activo valioso y aplicar marcos de gestión estructurados, las organizaciones pueden garantizar la coherencia, fiabilidad y perfecta integración de los datos en todas sus operaciones.
En nuestro último artículo, repasaremos el cuarto y último principio de la malla de datos: la gobernanza informática federada.
Guía práctica de Data Mesh: Configuración y supervisión de una malla de datos para toda la empresa
Redactada por Guillaume Bodet, nuestra guía ha sido diseñada para dotarle de estrategias prácticas para implantar la malla de datos en su organización, ayudándole:
- Comience su viaje por la malla de datos con un proyecto piloto específico.
- Descubra métodos eficaces para ampliar su malla de datos.
- Reconocer el papel fundamental que desempeña un mercado interno para facilitar el consumo efectivo de productos de datos.
- Descubra cómo la Plataforma de Inteligencia de Datos Actian emerge como un sistema de supervisión robusto, orquestando una malla de datos en toda la empresa.
Suscríbase al blog de Actian
Suscríbase al blog de Actian para recibir información sobre datos directamente en su correo electrónico.
- Manténgase informado: reciba lo último en análisis de datos directamente en su bandeja de entrada.
- No se pierda ni una publicación: recibirá actualizaciones automáticas por correo electrónico que le avisarán cuando se publiquen nuevas publicaciones.
- Todo depende de usted: cambie sus preferencias de entrega para adaptarlas a sus necesidades.