El viaje a la malla de datos - Parte 3 - Creación de los primeros productos de datos
Summary
- En Data Mesh, considerar los datos como un producto implica gestionar los datos compartidos con el mismo cuidado, los mismos estándares y el mismo enfoque del ciclo de vida que se aplican a los productos de software o a las API.
- Un producto de datos se define menos por su forma técnica y más por cómo se diseña, se gestiona, se documenta y se hace utilizable a gran escala.
- Los productos de datos de calidad deben ser fáciles de encontrar, accesibles, fiables, autodescriptivos, interoperables y seguros.
- Entre las buenas prácticas de diseño se incluyen asignar a cada producto de datos una función clara, interfaces estables y la posibilidad de reutilización en múltiples contextos.
- La creación de productos de datos también requiere una sólida experiencia en desarrollo, en la que se utilicen de forma pragmática la automatización, los flujos de trabajo basados en código, los metadatos, los contratos y la infraestructura existente.
While the literature on data mesh is extensive, it often describes a final state, rarely how to achieve it in practice. The question then arises:
What approach should be adopted to transform data management and implement a data mesh?
In this series of articles, get an excerpt from our Practical Guide to Data Mesh where we propose an approach to kick off a data mesh journey in your organization, structured around the four principles of data mesh (domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance) and leveraging existing human and technological resources.
- Part 1: Scoping Your Pilot Project
- Part 2: Assembling a Development Team & Data Platform for the Pilot Project
- Part 3: Creating Your First Data Products
- Part 4: Implementing Federated Computational Governance
Throughout this series of articles, and in order to illustrate this approach for building the foundations of a successful data mesh, we will rely on an example: that of the fictional company Premium Offices – a commercial real estate company whose business involves acquiring properties to lease to businesses.
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.
Premium Offices Example:
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.
The Practical Guide to Data Mesh: Setting up and Supervising an Enterprise-Wide Data Mesh
Written by Guillaume Bodet, our guide was designed to arm you with practical strategies for implementing data mesh in your organization, helping you:
- Start your data mesh journey with a focused pilot project.
- Discover efficient methods for scaling up your data mesh.
- Acknowledge the pivotal role an internal marketplace plays in facilitating the effective consumption of data products.
- Learn how the Actian Data Intelligence Platform emerges as a robust supervision system, orchestrating an enterprise-wide data mesh.
Stay connected
Data insights delivered to you.
(i.e. sales@..., support@...)
