Arquitectura de malla de datos: datos descentralizados para empresas

El almacén de datos centralizado ha sido la arquitectura de datos empresarial dominante durante 30 años. En este modelo, un equipo central de ingeniería de datos es propietario de la infraestructura de datos de la empresa: ingiere datos de los sistemas de origen, los limpia y transforma y los entrega a los consumidores a través de un almacén central o lago de datos. Los equipos comerciales solicitan nuevos datos, esperan a que los equipos centrales los entreguen y aceptan las decisiones prioritarias tomadas por un único equipo central para todas las necesidades de datos de la organización.

Este modelo funcionó razonablemente bien cuando los volúmenes de datos eran manejables, las fuentes de datos eran limitadas y el ritmo de cambio empresarial era más lento. Fracasa gravemente en entornos empresariales modernos caracterizados por miles de fuentes de datos, docenas de casos de uso de análisis que compiten por el ancho de banda del equipo central y equipos de negocios que requieren acceso a datos medido en días en lugar de trimestres.

La malla de datos es la respuesta arquitectónica y organizativa a estas limitaciones. En lugar de centralizar la propiedad de los datos en un equipo de plataforma, distribuye la propiedad a los dominios empresariales que mejor conocen los datos: los equipos que los producen. En lugar de tratar los datos como un subproducto de las operaciones, los trata como un producto con consumidores, estándares de calidad y niveles de servicio.

Conclusiones clave

• La malla de datos distribuye la propiedad de los datos a los equipos de dominio en lugar de concentrarla en un equipo de datos central.
• Los cuatro principios: propiedad del dominio, datos como producto, infraestructura de datos de autoservicio y gobernanza computacional federada
• Data mesh resuelve los problemas de escalabilidad, calidad y agilidad de las arquitecturas de datos centralizadas
• La implementación requiere tanto una inversión en plataforma técnica como un cambio organizacional significativo
• La plataforma de infraestructura de datos de autoservicio es la base técnica; sin ella, los equipos de dominio no pueden poseer datos de manera efectiva.
• La gobernanza federada garantiza la coherencia y el cumplimiento sin volver a crear cuellos de botella centrales
• La malla de datos no elimina los equipos de datos centrales: cambia su función de productor a proveedor y facilitador de plataformas.
• La mayoría de las organizaciones deberían implementar la malla de datos de forma incremental, comenzando con los dominios más problemáticos.

---

El problema de las arquitecturas de datos centralizadas

Para comprender por qué la malla de datos ha generado tanto interés empresarial, es necesario comprender los puntos débiles específicos de las arquitecturas centralizadas a escala.

El cuello de botella del equipo central

En un modelo centralizado, el equipo de ingeniería de datos posee todos los canales de datos. Cada nueva fuente de datos requiere el esfuerzo de un equipo central para integrarse. Cada nuevo caso de uso de análisis requiere tiempo de desarrollo del equipo central. Cada problema de calidad de los datos debe ser diagnosticado y solucionado por el equipo central.

A medida que la organización crece y proliferan los casos de uso de datos, el equipo central se convierte en un cuello de botella. Los equipos empresariales esperan entre 2 y 6 meses para las integraciones de datos. Los problemas de calidad de los datos no se solucionan porque los equipos centrales no tienen un contexto de dominio para diagnosticar las causas fundamentales. Las iniciativas de análisis se ven retrasadas por el trabajo de infraestructura de datos que compite con otras prioridades.

La cola crece más rápido de lo que puede crecer el equipo. Agregar más ingenieros de datos centrales no resuelve el problema fundamental: ralentiza el cuello de botella temporalmente mientras persiste el problema arquitectónico subyacente.

Brecha de experiencia en el dominio

El equipo de datos central sabe cómo construir canalizaciones. No conocen la semántica empresarial de los datos que procesan. ¿Qué significa "cliente" en el contexto del dominio de ventas versus el dominio de servicio? ¿Qué constituye un pedido "completado" en el ámbito de cumplimiento? ¿Cuál es la regla correcta de reconocimiento de ingresos para las ventas de productos por suscripción?

Los expertos en el dominio (los equipos empresariales que producen los datos) tienen este conocimiento. El equipo central no. Esta brecha de experiencia produce problemas de calidad de los datos que son difíciles de diagnosticar y solucionar porque quienes los reparan carecen del contexto para comprender los errores.

Inconsistencia y poca confianza

A medida que diferentes equipos crean sus propias soluciones (extrayendo datos directamente de los sistemas fuente, creando almacenes de datos locales, manteniendo hojas de cálculo a nivel de departamento), la "única fuente de verdad" central se fractura. Múltiples versiones de métricas como "ingresos" y "cliente activo" proliferan entre los equipos, con pequeñas pero importantes diferencias en la definición.

Los líderes empresariales dejan de confiar en los datos, recurren a la intuición y se resisten a la toma de decisiones basada en datos, no porque rechacen el concepto sino porque los datos no son confiables.

---

Los cuatro principios de la malla de datos

Zhamak Dehghani, quien acuñó el término "malla de datos" en 2019 mientras estaba en ThoughtWorks, lo definió a través de cuatro principios.

Principio 1: Propiedad del dominio de los datos

En la malla de datos, los dominios empresariales poseen sus datos: producción, calidad y publicación. El dominio de ventas posee los datos de ventas. El dominio de la cadena de suministro posee datos de inventario y cumplimiento. El dominio del cliente posee el perfil del cliente y los datos de participación.

Propiedad del dominio significa: el equipo del dominio es responsable de la calidad de los datos que publican, la infraestructura de canalización que los produce y los niveles de servicio con los que se comprometen para los consumidores. Cuando los datos son incorrectos, el equipo del dominio los arregla; tienen tanto la responsabilidad como la experiencia en el dominio para hacerlo.

Esto no significa que cada equipo de dominio se convierta en un equipo de ingeniería de datos. La plataforma de infraestructura de datos de autoservicio (Principio 3) proporciona las herramientas que hacen que la propiedad de un dominio sea práctica sin requerir una gran experiencia en ingeniería de datos en cada dominio.

Principio 2: Datos como producto

En la malla de datos, los datos se tratan como un producto: con consumidores, estándares de calidad, documentación y niveles de servicio, como cualquier otro producto.

Un producto de datos es un activo de datos acotado que:

• Tiene una propiedad clara (el equipo del dominio)
• Es detectable (los consumidores pueden encontrarlo a través de un catálogo de datos)
• Está documentado (los consumidores entienden qué contiene y cómo utilizarlo)
• Tiene estándares de calidad (se miden y mantienen la precisión, la integridad y la puntualidad)
• Tiene niveles de servicio definidos (actualidad, disponibilidad, latencia de acceso)
• Tiene una interfaz claramente definida (los consumidores acceden a los datos a través de API definidas o interfaces de consulta, no accediendo a los sistemas fuente)

La mentalidad de "producto" cambia la forma en que los equipos de dominio piensan sobre los datos que publican. Una canalización de datos es un detalle de implementación; un producto de datos es algo que sirve a los consumidores y debe mantenerse. Este cambio en el marco impulsa diferentes comportamientos en torno a la calidad y la confiabilidad.

Principio 3: Infraestructura de datos de autoservicio

La propiedad de los datos por parte de un dominio solo es práctica si los dominios tienen herramientas que hacen que el desarrollo de canales de datos, el monitoreo de la calidad y la publicación de productos de datos sean accesibles sin requerir experiencia especializada en ingeniería de datos.

La plataforma de infraestructura de datos de autoservicio proporciona:

• Herramientas de canalización de datos: desarrollo de canalizaciones de bajo código o basado en configuración que los ingenieros de dominio pueden utilizar sin una gran experiencia en ingeniería de datos.
• Marcos de calidad de datos: pruebas de calidad automatizadas, detección de anomalías y paneles de control de puntuación de calidad que los dominios pueden configurar y monitorear.
• Integración del catálogo de datos: registro automático de nuevos productos de datos en el catálogo de datos empresariales con extracción de metadatos
• Control de acceso: gestión de acceso basada en políticas que los dominios pueden configurar sin la participación de TI
• Interfaces de consumo: interfaces de consulta estandarizadas (SQL, API) que los consumidores pueden usar independientemente del dominio que produjo los datos.
• Monitoreo y observabilidad: monitoreo del estado de la canalización, paneles de actualización de datos y alertas de que los equipos de dominio pueden operar.

La construcción de esta plataforma es la principal inversión técnica en malla de datos. Sin él, la malla de datos descentraliza la responsabilidad sin permitir la capacidad: una receta para el caos en lugar del empoderamiento.

Principio 4: Gobernanza Computacional Federada

Descentralizar la propiedad de los datos no significa abandonar la gobernanza. La malla de datos utiliza una gobernanza federada: estándares definidos centralmente que los dominios aplican localmente.

La función de gobernanza central define: estándares de calidad de datos, políticas de seguridad y privacidad, estándares de interoperabilidad (formatos de datos comunes, estándares de identificadores), requisitos de cumplimiento normativo y el esquema de catálogo de datos al que deben ajustarse todos los productos de datos.

Los dominios implementan estos estándares dentro de sus productos de datos. La función de gobernanza verifica el cumplimiento mediante la aplicación automatizada de políticas en lugar de una revisión manual.

La gobernanza "computacional" significa que las políticas de gobernanza se aplican automáticamente mediante código, no mediante procesos de aprobación manuales. Los controles de acceso los aplica la plataforma; los estándares de calidad de los datos se verifican mediante pruebas automatizadas; Las políticas de seguridad son aplicadas por la infraestructura. Esto hace que la gobernanza sea escalable: no requiere que un equipo central revise manualmente cada producto de datos.

---

Arquitectura de malla de datos en la práctica

Diseño de dominio de datos

Diseñar dominios de datos es el primer desafío práctico. Los límites del dominio deben alinearse con los límites del dominio empresarial: unidades organizativas con una clara responsabilidad de los datos y propiedad del contexto empresarial.

Patrones de diseño de dominio comunes:

Dominios operativos: haga coincidir las unidades de negocio existentes: ventas, marketing, finanzas, operaciones, recursos humanos y cadena de suministro. Cada dominio posee los datos producidos por sus sistemas operativos.

Dominio del cliente: los datos agregados del perfil del cliente, a menudo propiedad de un equipo dedicado de datos del cliente, son un dominio transversal común.

Dominios de análisis: algunas organizaciones crean dominios analíticos dedicados que agregan datos de múltiples dominios operativos para fines analíticos específicos: un dominio de análisis financiero que combina datos de Ventas, Operaciones y Finanzas.

Los límites de los dominios deben trazarse para minimizar las dependencias entre dominios: cuando una parte importante de los datos de un dominio proviene de otro dominio, es posible que sea necesario volver a trazar los límites.

Anatomía del producto de datos

Un producto de datos en una implementación de malla de datos normalmente incluye:

Datos de entrada: datos de origen de sistemas operativos, consumidos a través de flujos de eventos (Kafka), llamadas API o replicación de bases de datos.

Código de transformación: la lógica de canalización que transforma los datos de origen sin procesar en el producto de datos publicado. Normalmente se gestiona como código en control de versiones con implementación de CI/CD.

Interfaz de salida: la forma en que se entregan los datos a los consumidores: tablas en una capa de consulta compartida, puntos finales de API, flujos de eventos o vistas materializadas.

Contratos de calidad: Estándares de calidad definidos y probados: tarifas nulas, requisitos de frescura, verificaciones de integridad referencial, validaciones de reglas comerciales.

Metadatos: definiciones de esquemas, diccionarios de datos, información de linaje y documentación operativa, registrados automáticamente en el catálogo de datos.

Observabilidad: monitoreo del estado de la canalización, paneles de actualización y seguimiento del puntaje de calidad.

Opciones de plataforma técnica

La pila de implementación de la malla de datos varía significativamente según la organización, la plataforma en la nube y las herramientas existentes:

Catálogo de datos: Atlan, Collibra, Alation, DataHub (código abierto), Google Dataplex, AWS Glue Data Catalog. Proporciona la capa de descubrimiento para productos de datos.

Calidad de los datos: Great Expectations (código abierto), Monte Carlo, Soda, Anomalo. Pruebas automatizadas de calidad de datos y detección de anomalías.

Orquestación de canalizaciones: dbt (transformación de datos), Apache Airflow, Prefect, Dagster. Las herramientas de transformación de datos y orquestación de canalizaciones que los dominios utilizan para construir sus canalizaciones.

Capa de consulta: Databricks Unity Catalog, Snowflake, BigQuery, Amazon Redshift. La capa de consulta analítica compartida que los consumidores utilizan para consultar productos de datos de múltiples dominios.

Gestión de acceso: Apache Ranger, AWS Lake Formation, Databricks Unity Catalog. Control de acceso basado en políticas entre dominios.

Transmisión de eventos: Apache Kafka, AWS Kinesis, Google Pub/Sub. Interfaces de productos de datos en tiempo real para consumidores de streaming.

---

Integración con Analytics y Power BI

Las arquitecturas de malla de datos proporcionan la base de datos de propiedad del dominio que consumen los equipos de análisis. La interfaz entre la malla de datos y las herramientas de análisis es fundamental.

Malla de datos + Power BI

En una arquitectura de malla de datos, Power BI se conecta a productos de datos de dominio a través de la capa de consulta compartida, normalmente una casa de lago (Databricks, Azure Synapse, Microsoft Fabric) o un almacén de datos (Snowflake, BigQuery, Redshift).

Los productos de datos de dominio se publican como tablas o vistas en la capa de consulta. Los modelos semánticos (conjuntos de datos) de Power BI se crean sobre estos productos de datos de dominio. Los consumidores de datos (analistas, usuarios comerciales) crean informes sobre los modelos semánticos sin necesidad de comprender qué dominio produjo los datos subyacentes.

OneLake de Microsoft Fabric es particularmente adecuado para arquitecturas de malla de datos: proporciona una capa de almacenamiento unificada donde los equipos de dominio pueden publicar sus productos de datos, con una capa de consulta compartida que consumen Power BI y otras herramientas analíticas. Los espacios de trabajo a nivel de dominio en Microsoft Fabric se alinean naturalmente con los límites del dominio de la malla de datos.

Linaje de datos para análisis

Una de las capacidades más valiosas en una malla de datos madura es el linaje de datos de un extremo a otro: rastrear el origen de cada número en un informe analítico a través de productos de datos, transformaciones y sistemas de origen.

Cuando un informe de Power BI muestra una cifra de ingresos inesperada, el linaje de datos permite un diagnóstico rápido: ¿de qué producto de datos proviene la métrica de ingresos? ¿A qué dominio pertenece? ¿Qué lógica de transformación lo produjo? ¿Qué sistema fuente fue el origen último?

Las herramientas de catálogo de datos con capacidades de linaje (Atlan, Collibra, DataHub) brindan esta visibilidad de linaje, lo que hace que la resolución de problemas de análisis sea mucho más rápida y efectiva.

---

Transformación Organizacional

La malla de datos es tanto una transformación organizacional como técnica. La arquitectura técnica se puede construir con relativa rapidez; la transformación organizacional lleva mucho más tiempo.

Cambios de rol

Ingenieros de datos en equipos centrales: la función cambia de crear canales de datos de producción a crear y mantener la plataforma de infraestructura de datos de autoservicio. De productor a constructor de plataformas. Esta es una transición profesional significativa que requiere una gestión cuidadosa.

Ingenieros de datos en equipos de dominio: nueva función: ingenieros de datos de dominio que están integrados en unidades de negocios, creando y manteniendo productos de datos de dominio. Necesitan tanto habilidades de ingeniería de datos como conocimiento empresarial del dominio.

Analistas de datos: la función se vuelve más poderosa: con productos de datos de dominio detectables y de alta calidad, los analistas dedican menos tiempo a la adquisición y limpieza de datos y más tiempo al análisis. Esto requiere desarrollar habilidades analíticas más sólidas junto con habilidades de datos.

Propietarios de productos de datos: nueva función: miembros del equipo de dominio que son propietarios de la hoja de ruta del producto de datos, gestionan las relaciones con los consumidores y son responsables de los compromisos de calidad de los datos. Similar al rol de gerente de producto, aplicado a los datos.

Equipo central de gobierno de datos: la función cambia de la corrección de la calidad de los datos al establecimiento y aplicación de estándares de gobierno. De solucionador de problemas a formulador de políticas.

Consideraciones sobre la gestión de cambios

La propiedad de los datos del dominio es una responsabilidad que los equipos del dominio no siempre quieren. "Nosotros producimos los datos; ¿por qué deberíamos ser responsables de la ingeniería de datos?" es una reacción común. La respuesta requiere demostrar que la propiedad del dominio brinda a los equipos control sobre el destino de sus propios datos (iteración más rápida, mejor calidad y menor dependencia de las colas centrales) al tiempo que proporciona herramientas de autoservicio que los hacen prácticamente manejables.

La alineación del liderazgo superior es esencial. La malla de datos requiere que los líderes de dominio acepten la responsabilidad por la calidad de los datos junto con sus responsabilidades operativas. Sin este compromiso a nivel de liderazgo, los equipos de dominio se resistirán a la responsabilidad incluso si quieren el control.

---

Preguntas frecuentes

¿La malla de datos es adecuada para pequeñas y medianas empresas, o solo para organizaciones grandes?

La malla de datos es más beneficiosa para las organizaciones donde los cuellos de botella de la arquitectura de datos centrales están causando problemas comerciales reales: generalmente organizaciones con más de 10 dominios importantes de producción de datos, casos de uso de análisis sustanciales y un equipo de datos central que no puede seguir el ritmo de la demanda. Para organizaciones más pequeñas con menos fuentes de datos y necesidades de análisis más simples, un almacén de datos centralizado y bien estructurado puede ser más apropiado. La malla de datos agrega complejidad organizacional y arquitectónica que solo se justifica cuando los problemas que resuelve realmente limitan los resultados comerciales.

¿Cuánto tiempo lleva la implementación de una malla de datos?

Un cronograma realista de implementación de malla de datos para una gran empresa: de 6 a 12 meses para la construcción de la plataforma de infraestructura de datos de autoservicio, de 12 a 18 meses para que los primeros 3 a 5 productos de datos de dominio estén operativos, de 24 a 36 meses para que el programa cubra la mayoría de los dominios principales. La organización debe evaluar de manera realista cuánto tiempo lleva desarrollar las capacidades del equipo de dominio: incorporar ingenieros de datos en los equipos de dominio, capacitar a los propietarios de productos de dominio y cambiar la cultura del equipo de dominio en torno a la propiedad de los datos. La transformación organizacional completa a prácticas de malla de datos suele tardar entre 3 y 5 años, y se genera un valor significativo en el primer año desde las primeras implementaciones del dominio.

¿Cuál es la diferencia entre un lago de datos, un almacén de datos, una casa de lago de datos y una malla de datos?

Un lago de datos es un repositorio de almacenamiento que almacena datos sin procesar en su formato nativo. Un almacén de datos es un almacén de datos estructurado e integrado optimizado para consultas analíticas. Un data lakehouse combina la economía de almacenamiento de un data lake con el rendimiento de las consultas y la gobernanza de un data warehouse. La malla de datos es un enfoque arquitectónico y organizativo, no una tecnología de almacenamiento: describe cómo se poseen, se producen y se gobiernan los datos. La malla de datos se puede implementar sobre una base tecnológica de lago de datos, almacén o lago. La mayoría de las implementaciones de malla de datos modernas utilizan un lago de datos (Databricks, Microsoft Fabric, Snowflake) como capa de consulta compartida.

¿Cómo se relaciona la malla de datos con la arquitectura de microservicios?

Data mesh aplica principios arquitectónicos de microservicios a la gestión de datos, específicamente las ideas de propiedad de dominio, contexto limitado y capacidad de implementación independiente. Así como los microservicios descomponen una aplicación monolítica en servicios de dominio, la malla de datos descompone una plataforma de datos central en productos de datos de dominio. La analogía se extiende a la estructura organizacional: así como los microservicios son propiedad de equipos multifuncionales que incluyen desarrolladores, operaciones y gestión de productos, los productos de datos deben ser propiedad de equipos de dominios multifuncionales que incluyan ingenieros de datos, expertos en el dominio y propietarios de productos de datos.

¿Cuáles son los errores más comunes en la implementación de la malla de datos?

Los patrones de falla más comunes: construir la plataforma de autoservicio sin inversión suficiente (se asignan responsabilidades a los dominios sin herramientas, lo que genera caos); no lograr la aceptación del liderazgo del dominio antes de continuar (los equipos del dominio se resisten a la propiedad sin el compromiso organizacional del liderazgo); tratar la malla de datos como una iniciativa puramente tecnológica (descuidando la gestión del cambio organizacional que hace que la propiedad del dominio sea sostenible); e intentar implementar una malla de datos en todos los dominios simultáneamente (la complejidad del cambio simultáneo en toda la organización generalmente resulta en implementaciones fallidas, comenzando con 2 o 3 dominios difíciles y demostrando que el modelo antes de escalarlo es consistentemente más exitoso).

---

Próximos pasos

La malla de datos representa un replanteamiento fundamental de la arquitectura de datos empresariales que aborda las limitaciones de escalamiento, calidad y agilidad de los modelos centralizados. Para las organizaciones que experimentan cuellos de botella en los datos, ofrece un camino hacia la propiedad de datos escalable y apropiada para el dominio.

Los servicios de análisis y Power BI de ECOSIRE ayudan a las organizaciones a diseñar e implementar la capa de análisis que se encuentra en la parte superior de las arquitecturas de malla de datos, conectando productos de datos de dominio con herramientas de inteligencia empresarial que brindan información a los tomadores de decisiones. Nuestro equipo puede asesorar tanto sobre la estrategia de arquitectura de datos como sobre la implementación de análisis que hace que la inversión en malla de datos se traduzca en valor comercial.

Comuníquese con nuestro equipo de arquitectura de datos y análisis para analizar si la malla de datos es el enfoque adecuado para los desafíos de datos de su organización.