Una malla de datos es un framework de arquitectura y organización que trata los datos como un producto (al que se hace referencia en este documento como "productos de datos"). En este framework, los equipos de información que comprenden mejor esos datos y desarrollan un conjunto de estándares de administración de datos en toda la organización desarrollan los productos de datos. Una vez que los productos de datos se implementan en la malla de datos, los equipos distribuidos en una organización pueden descubrir y acceder a los datos relevantes para sus necesidades de manera más rápida y eficiente. Para lograr una malla de datos que funcione de forma correcta, primero debes establecer los componentes de la arquitectura de alto nivel y los roles organizativos que se describen en este documento.
Este documento forma parte de una serie en la que se describe cómo implementar una malla de datos en Google Cloud. Se supone que leíste y conoces los conceptos descritos en Compila una malla de datos moderna y distribuida con Google Cloud.
La serie tiene las siguientes partes:
- Arquitectura y funciones en una malla de datos (este documento)
- Diseña una plataforma de datos de autoservicio para una malla de datos
- Compila productos de datos en una malla de datos
- Descubre y consume productos de datos en una malla de datos
En esta serie, la malla de datos que se describe es interna de una organización. Aunque es posible extender una arquitectura de malla de datos para proporcionar productos de datos a terceros, este enfoque extendido está fuera del alcance de este documento. La extensión de una malla de datos implica consideraciones adicionales más allá del uso dentro de una organización.
Arquitectura
Los siguientes términos clave se usan para definir los componentes de la arquitectura que se describen en esta serie:
- Producto de datos: un producto de datos es un contenedor lógico o la agrupación de uno o más recursos de datos relacionados.
- Recurso de datos: un recurso de datos es un recurso físico en un sistema de almacenamiento que contiene datos estructurados o almacena una consulta que produce datos estructurados.
- Atributo de datos: un atributo de datos es un campo o elemento de un recurso de datos.
En el siguiente diagrama, se proporciona una descripción general de los componentes clave de la arquitectura en una malla de datos implementada en Google Cloud.
En el diagrama anterior, se muestra lo siguiente:
- Los servicios centrales permiten la creación y la administración de productos de datos, incluidas las políticas de la organización que afectan a los participantes de la malla de datos, los controles de acceso (a través de los grupos de Identity and Access Management) y los artefactos específicos de la infraestructura. En Crea componentes y soluciones de plataforma, se describen ejemplos de tales compromisos y reservas, y una infraestructura que facilita el funcionamiento de la malla de datos.
- Los servicios centrales proporcionan, sobre todo, Data Catalog para todos los productos de datos de la malla de datos y el mecanismo de descubrimiento de clientes potenciales de estos productos. Para obtener información sobre cómo registrar productos de datos en el catálogo de datos, consulta Describe y organiza productos y recursos de datos en una malla de datos.
- Los dominios de datos exponen subconjuntos de sus datos como productos de datos a través de interfaces de consumo de datos bien definidas. Estos productos de datos pueden ser una tabla, una vista, un archivo estructurado, un tema o una transmisión. En BigQuery, sería un conjunto de datos y, en Cloud Storage, sería una carpeta o un bucket. Puede haber diferentes tipos de interfaces que se puedan exponer como un producto de datos. Un ejemplo de una interfaz es una vista de BigQuery en una tabla de BigQuery. Los tipos de interfaces que se usan con mayor frecuencia con fines analíticos se abarcan en Compila productos de datos en una malla de datos.
Implementación de referencia de la malla de datos
Puedes encontrar una implementación de referencia de esta arquitectura en el repositorio de data-mesh-demo.
Las secuencias de comandos de Terraform que se usan en la implementación de referencia demuestran los conceptos de la malla de datos y no están destinados al uso en producción. Mediante la ejecución de estas secuencias de comandos, aprenderás a hacer las siguientes tareas:
- Separar las definiciones de los productos de los datos subyacentes
- Crear plantillas de Data Catalog para describir las interfaces de los productos
- Etiquetar las interfaces de productos con estas plantillas
- Otorgar permisos a los consumidores de productos
Para las interfaces de productos, la implementación de referencia crea y usa los siguientes tipos de interfaces:
- Vistas autorizadas en tablas de BigQuery
- Flujos de datos basados en temas de Pub/Sub
Para obtener más detalles, consulta el archivo README en el repositorio.
Funciones en una malla de datos
A fin de que una malla de datos funcione bien, debes definir roles claros para las personas que realizan tareas dentro de la malla de datos. La propiedad se asigna a los arquetipos de equipo o funciones. Estas funciones contienen los recorridos principales de los usuarios para las personas que trabajan en la malla de datos. Para describir los recorridos de los usuarios con claridad, se les asignaron los roles de los usuarios. Estos roles de usuario se pueden dividir y combinar en función de las circunstancias de cada empresa. No es necesario que asignes los roles directamente a los empleados o equipos de tu organización.
Un dominio de datos está alineado con una unidad de negocios (BU) o una función dentro de una empresa. Los ejemplos comunes de dominios empresariales pueden ser el departamento de Hipotecas de un banco o los departamentos de Clientes, Distribución, Finanzas y RR.HH. de una empresa. Desde una perspectiva conceptual, hay dos funciones relacionadas con los dominios en una malla de datos: los equipos del productor de datos y los equipos del consumidor de datos. Es importante comprender que es probable que un solo dominio de datos entregue ambas funciones a la vez. Un equipo de dominio de datos produce productos de datos a partir de los datos que le pertenecen. El equipo también consume productos de datos para las estadísticas empresariales y a fin de producir productos de datos derivados para el uso de otros dominios.
Además de las funciones basadas en dominios, una malla de datos también tiene un conjunto de funciones que realizan los equipos centralizados dentro de la organización. Estos equipos centrales habilitan la operación de la malla de datos a través de la supervisión, los servicios y la administración entre dominios. Reducen la carga operativa de los dominios de datos en la producción y el consumo de productos de datos, y facilitan las relaciones entre dominios que se requieren para que funcione la malla de datos.
En este documento, solo se describen las funciones que tienen un rol específico de malla de datos. Hay muchas otros roles que se requieren en cualquier empresa, sin importar la arquitectura que se emplee para la plataforma. Sin embargo, estas otros roles están fuera del alcance de este documento.
Las cuatro funciones principales de una malla de datos son las siguientes:
- Equipos de productores basados en dominios de datos: Crean y mantienen productos de datos durante su ciclo de vida. A menudo, estos equipos se denominan productores de datos.
- Equipos de consumidores basados en dominios de datos: Descubren productos de datos y los usan en varias aplicaciones analíticas. Estos equipos pueden consumir productos de datos para crear productos de datos nuevos. A menudo, estos equipos se conocen como los consumidores de datos.
- Equipo de administración de datos central: define y aplica políticas de administración de datos entre los productores de datos, lo que garantiza una alta calidad y confiabilidad de los datos para los consumidores. A menudo, este equipo se conoce como el equipo de administración de datos.
- Equipo de plataforma de infraestructura de datos de autoservicio central: proporciona una plataforma de datos de autoservicio para los productores de datos. Este equipo también proporciona las herramientas para el descubrimiento central de datos y la observabilidad de productos de datos que usan los consumidores y los productores de datos. A menudo, este equipo se conoce como el equipo de la plataforma de datos.
Una función adicional opcional que se debe considerar es la del Centro de excelencia (COE) de la malla de datos. El propósito del COE es proporcionar administración de la malla de datos. El COE también es el equipo de arbitraje designado que resuelve cualquier conflicto generado por cualquiera de las otras funciones. Esta función es útil para ayudar a conectar las otras cuatro funciones.
Equipo del productor basado en dominios de datos
Por lo general, los productos de datos se compilan sobre un repositorio físico de datos (ya sea uno o varios almacenes de datos, data lakes o transmisiones). Una organización necesita roles de plataforma de datos tradicionales para crear y mantener estos repositorios físicos. Sin embargo, estos roles tradicionales de la plataforma de datos no suelen ser las personas que crean el producto de datos.
Para crear productos de datos a partir de estos repositorios físicos, una organización necesita una combinación de profesionales de datos, como ingenieros y arquitectos de datos. En la siguiente tabla, se enumeran todos los roles de usuario específicas del dominio que se necesitan en los equipos del productor de datos.
Rol |
Responsabilidades |
Habilidades requeridas |
Resultados deseados |
|---|---|---|---|
Propietario de productos de datos |
|
Análisis de datos Arquitectura de datos Administración de productos |
|
Líder técnico de productos de datos |
|
Ingeniería de datos Arquitectura de datos Ingeniería de software |
|
Asistencia de productos de datos |
|
Ingeniería de software Ingeniería de confiabilidad de sitios (SRE) |
|
Experto en la materia (SME) para el dominio de datos |
|
Análisis de datos Arquitectura de datos |
|
Propietario de los datos |
|
|
|
Equipos de consumidores basados en dominios de datos
En una malla de datos, las personas que consumen un producto de datos suelen ser usuarios de datos que están fuera del dominio del producto de datos. Estos consumidores de datos usan un catálogo de datos central para encontrar productos de datos que sean relevantes para sus necesidades. Debido a que es posible que más de un producto de datos pueda satisfacer sus necesidades, los consumidores de datos pueden terminar suscribiéndose a varios productos de datos.
Si los consumidores de datos no pueden encontrar el producto de datos requerido para su caso de uso, es su responsabilidad consultar directamente con el COE de la malla de datos. Durante esa consulta, los consumidores de datos pueden aumentar sus necesidades de datos y buscar asesoramiento sobre cómo satisfacer esas necesidades con uno o más dominios.
Cuando buscan un producto de datos, los consumidores de datos buscan datos que los ayuden a lograr varios casos de uso, como informes y paneles de estadísticas persistentes, informes de rendimiento individuales y otras métricas de rendimiento empresarial. Como alternativa, es posible que los consumidores de datos busquen productos de datos que se puedan usar en casos de uso de inteligencia artificial (IA) y aprendizaje automático (AA). Para lograr estos casos de uso, los consumidores de datos requieren una combinación de personas profesionales de datos, que son las siguientes:
Rol |
Responsabilidades |
Habilidades requeridas |
Resultados deseados |
|---|---|---|---|
Analista de datos |
Busca, identifica, evalúa y se suscribe a productos de datos de dominio único o entre dominios para crear una base para que funcionen los frameworks de inteligencia empresarial. |
Ingeniería de estadísticas Estadísticas empresariales |
|
Desarrollador de aplicaciones |
Desarrolla un framework de aplicación para el consumo de datos en uno o más productos de datos, ya sea dentro o fuera del dominio. |
Desarrollo de aplicaciones Ingeniería de datos |
|
Especialista en visualización de datos |
|
Análisis de requisitos Visualización de datos |
|
Científico de datos |
|
Ingeniería de AA Ingeniería de estadísticas |
|
Equipo central de administración de datos
El equipo de administración de datos permite que los productores y consumidores de datos compartan, agreguen y procesen datos de forma segura y segura, sin ingresar riesgos de cumplimiento a la organización.
Para cumplir con los requisitos de cumplimiento de la organización, el equipo de administración de datos es una combinación de profesionales de los datos datos, que son las siguientes:
Rol |
Responsabilidades |
Habilidades requeridas |
Resultados deseados |
|---|---|---|---|
Especialista en administración de datos |
|
Pyme legal Pyme de seguridad Pyme de privacidad de datos |
|
Administrador de datos (se encuentra dentro de cada dominio) |
|
Arquitectura de datos Administración de datos |
|
Ingeniero de administración de datos |
|
Ingeniería de software |
|
Equipo central de la plataforma de infraestructura de datos de autoservicio
El equipo de plataforma de infraestructura de datos de autoservicio, o solo el equipo de plataforma de datos, es responsable de crear un conjunto de componentes de infraestructura de datos. Los equipos de dominios de datos distribuidos usan estos componentes para compilar y, luego, implementar sus productos de datos. El equipo de la plataforma de datos también promueve las prácticas recomendadas y presenta herramientas y metodologías que ayudan a reducir la carga cognitiva para los equipos distribuidos cuando adoptan tecnología nueva.
La infraestructura de la plataforma debe facilitar la integración en herramientas de operaciones para la observabilidad, la instrumentación y la automatización del cumplimiento globales. Como alternativa, la infraestructura debe facilitar esa integración para configurar equipos distribuidos para tener éxito.
El equipo de la plataforma de datos tiene un modelo de responsabilidad compartida que usa con los equipos de dominios distribuidos y el equipo de infraestructura subyacente. El modelo muestra qué responsabilidades se esperan de los consumidores de la plataforma y qué componentes de la plataforma admite el equipo de la plataforma de datos.
Como la plataforma de datos es en sí misma un producto interno, la plataforma no admite todos los casos de uso. En cambio, el equipo de la plataforma de datos lanza de forma continua servicios y funciones nuevos de acuerdo con una hoja de ruta priorizada.
El equipo de la plataforma de datos puede tener un conjunto estándar de componentes implementados y en desarrollo. Sin embargo, los equipos de dominios de datos pueden optar por usar un conjunto de componentes único y diferente si las necesidades de un equipo no se alinean con las que proporciona la plataforma de datos. Si los equipos de los dominios de datos eligen un enfoque diferente, deben asegurarse de que cualquier infraestructura de plataforma que compilen y mantengan cumpla con las políticas y barreras de seguridad de toda la organización para la seguridad y la administración de datos. En el caso de la infraestructura de plataformas de datos que se desarrolla fuera del equipo central de la plataforma de datos, el equipo de la plataforma de datos puede optar por invertir en conjunto o incorporar sus propios ingenieros a los equipos de dominio. Que el equipo de la plataforma de datos opte por invertir en conjunto o incorporar ingenieros puede depender de la importancia estratégica de la infraestructura de la plataforma de dominio de datos para la organización. Gracias a la participación en el desarrollo de la infraestructura por parte de los equipos de dominios de datos, las organizaciones pueden brindar la alineación y la experiencia técnica necesarias para volver a empaquetar cualquier componente nuevo de la infraestructura de la plataforma que esté en desarrollo para volver a utilizarse en el futuro.
Es posible que debas limitar la autonomía en las primeras etapas de la compilación de una malla de datos si tu objetivo inicial es obtener la aprobación de las partes interesadas para escalar verticalmente la malla de datos. Sin embargo, limitar los riesgos de autonomía para crear un cuello de botella en el equipo central de la plataforma de datos Este cuello de botella puede impedir el escalamiento de la malla de datos. Por lo tanto, cualquier decisión de centralización debe tomarse con cuidado. Para los productores de datos, puede ser preferible elegir sus opciones técnicas a partir de un conjunto limitado de opciones disponibles, y evaluarlas y elegirlas entre una lista ilimitada de opciones. Elevar la autonomía de los productores de datos no equivale a crear un panorama tecnológico tecnológica sin éxito. En su lugar, el objetivo es impulsar el cumplimiento y la adopción de la plataforma a través del establecimiento del equilibrio adecuado entre la libertad de elección y la estandarización.
Por último, un buen equipo de plataforma de datos es una fuente central de educación y prácticas recomendadas para el resto de la empresa. Estas son algunas de las actividades más impactantes que recomendamos que realicen los equipos centrales de la plataforma de datos:
- Fomentar las revisiones periódicas del diseño de la arquitectura para nuevos proyectos funcionales y proponer formas comunes de desarrollo en los equipos de desarrollo.
- Compartir el conocimiento y las experiencias, y definir de forma colectiva las prácticas recomendadas y los lineamientos arquitectónicos.
- Garantizar que los ingenieros tengan las herramientas adecuadas para validar y verificar los errores comunes, como los problemas con código, errores y degradaciones de rendimiento.
- Organizar hackatones internos para que los equipos de desarrollo puedan destacar sus requisitos para las necesidades de herramientas internas.
Estos son algunos ejemplos de roles y responsabilidades para el equipo de la plataforma central de datos:
| Rol | Responsabilidades | Habilidades requeridas |
Resultados deseados |
|---|---|---|---|
Propietario de los productos de la plataforma de datos |
|
Estrategia y operaciones de datos Administración de productos Administración de partes interesadas |
|
Ingeniero de plataforma de datos |
|
Ingeniería de datos Ingeniería de software |
|
Ingeniero de plataforma y seguridad (un representante de los equipos centrales de TI, como herramientas de redes y seguridad, que está incorporado en el equipo de la plataforma de datos) |
|
Ingeniería de infraestructura Ingeniería de software |
|
Arquitecto empresarial |
|
Arquitectura de datos Iteración de soluciones y resolución de problemas Creación de consenso |
|
Consideraciones adicionales para una malla de datos
Existen varias opciones de arquitectura para una plataforma de datos de estadísticas, cada una con diferentes requisitos. Para habilitar cada arquitectura de la malla de datos, sugerimos que tu organización siga las prácticas recomendadas que se describen en esta sección.
Adquiere fondos de la plataforma
Como se explicó en la entrada de blog, “Si deseas transformar el inicio con finanzas”, la plataforma nunca se termina, siempre funciona en función de un mapa de ruta priorizado. Por lo tanto, la plataforma debe financiarse como producto, no como un proyecto con un extremo fijo.
El primer usuario de la malla de datos soportará el costo. Por lo general, el costo se comparte entre la empresa que forma el primer dominio de datos para iniciar la malla de datos y el equipo de tecnología central, que suele alojar al equipo central de la plataforma de datos.
Para convencer a los equipos de finanzas para aprobar la financiación de la plataforma central, te recomendamos que generes un caso empresarial sobre el valor de la plataforma centralizada que se realizará con el tiempo. Ese valor proviene de la reimplementación de los mismos componentes en equipos de entrega individuales.
Define la plataforma viable mínima para la malla de datos
Para ayudarte a definir la plataforma mínima viable para la malla de datos, te recomendamos que iteres y pruebes con uno o más casos empresariales. Para tu piloto, busca los casos de uso que se necesiten y en los que un consumidor esté listo para adoptar el producto de datos resultante. Los casos de uso ya deben tener financiación para desarrollar los productos de datos, pero se necesita la participación de los equipos técnicos.
Asegúrate de que el equipo que implementa el piloto comprenda el modelo operativo de la malla de datos de la siguiente manera:
- La empresa (es decir, el equipo del productor de datos) es propietario las tareas pendientes, la asistencia y el mantenimiento.
- El equipo central define los patrones de autoservicio y ayuda a la empresa a compilar el producto de datos, pero pasa el producto de datos a la empresa para que se ejecute y sea propietario cuando se complete.
- El objetivo principal es demostrar el modelo operativo empresarial (los dominios producidos y los dominios consumidos). El objetivo secundario es demostrar el modelo operativo técnico (patrones de autoservicio desarrollados por el equipo central).
- Debido a que los recursos del equipo de la plataforma son limitados, usa el modelo de equipos troncales y de ramas para agrupar el conocimiento, pero permite el desarrollo de productos y servicios de plataforma especializados.
También te recomendamos que hagas lo siguiente:
- Planifica hojas de ruta en lugar de permitir que los servicios y las funciones evolucionen de forma orgánica.
- Define las capacidades mínimas de la plataforma viables que abarquen la transferencia, el almacenamiento, el procesamiento, el análisis y el AA.
- Incorpora la administración de datos en cada paso, no como un flujo de trabajo independiente.
- Implementa las capacidades mínimas de administración, plataforma, flujo de valor y administración de cambios. Las capacidades mínimas son aquellas que cumplen con el 80% de los casos empresariales.
Planifica la coexistencia de la malla de datos con una plataforma de datos existente
Es probable que muchas organizaciones que desean implementar una malla de datos ya tengan una plataforma de datos existente, como un data lake, un almacén de datos o una combinación de ambos. Antes de implementar una malla de datos, estas organizaciones deben planificar la forma en que su plataforma de datos existente puede evolucionar a medida que crece la malla de datos.
Estas organizaciones deben considerar los siguientes factores:
- Los recursos de datos que son más eficaces en la malla de datos.
- Los activos que deben permanecer dentro de la plataforma de datos existente.
- Si los elementos deben moverse o si se pueden mantener en la plataforma existente y aún participar en la malla de datos.
¿Qué sigue?
- Para obtener más información sobre cómo diseñar y operar una topología en la nube, consulta el framework de arquitectura de Google Cloud.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.