Malla de datos empresariales

La malla de datos, un tema tendencia en el ámbito del software empresarial, es una nueva forma de pensar en los datos según una arquitectura distribuida para su gestión. La idea es hacer que los datos sean más accesibles y estén más disponibles para los usuarios, conectando directamente a los propietarios, los productores y los consumidores de datos. El objetivo de la malla de datos es mejorar los resultados empresariales de las soluciones centradas en datos e impulsar la adopción de arquitecturas de datos modernas.

Desde el punto de vista empresarial, la malla de datos introduce nuevas ideas acerca de los datos como producto. Es decir, pensar en los datos como un producto que cumple una función, por ejemplo, mejorar la toma de decisiones, ayudar a detectar fraudes o alertar a la empresa de cambios en la cadena de suministro. Para crear productos de datos de alto valor, las organizaciones deben abordar los cambios de cultura y mentalidad, y comprometerse con un enfoque más multifuncional para el modelado de los dominios empresariales.

Desde el punto de vista tecnológico, la visión de Oracle de la malla de datos implica tres nuevas e importantes áreas de enfoque para la arquitectura basada en datos:

1. Herramientas que proporcionen productos de datos como colecciones, eventos y análisis de datos.
2. Arquitecturas de datos distribuidas y descentralizadas para ayudar a las organizaciones que deciden abandonar las arquitecturas monolíticas por la computación multinube y de nube híbrida o que deben operar de forma globalmente descentralizada.
3. Datos en movimiento para las organizaciones que no pueden depender únicamente de datos centralizados, estáticos y orientados a lotes, y que en su lugar están pasando a libros de datos basados en eventos y pipelines centrados en flujos para eventos de datos en tiempo real que proporcionan análisis más actualizados.

Otros aspectos, como las herramientas de autoservicio para los usuarios no técnicos y unos sólidos modelos de gobernanza de datos federada, son tan importantes para la arquitectura de malla de datos como para otras metodologías de gestión de datos más centralizadas y clásicas.

Un enfoque de malla de datos es un cambio de paradigma para pensar en los datos como un producto. La malla de datos introduce cambios organizativos y de procesos que las empresas necesitarán para gestionar los datos como un activo de capital tangible del negocio. La perspectiva de Oracle para la arquitectura de malla de datos requiere la coordinación de los dominios de datos organizativos y analíticos.

Una malla de datos tiene como objetivo enlazar directamente a los productores de datos con los usuarios profesionales y, en la mayor medida posible, eliminar intermediarios de TI de los proyectos y procesos que ingieren, preparan y transforman recursos de datos.

El enfoque de Oracle en cuanto a la malla de datos ha consistido en proporcionar una plataforma para nuestros clientes que pueda abordar estos requisitos tecnológicos emergentes. Esto incluye herramientas para productos de datos, arquitecturas descentralizadas basadas en eventos y patrones de transmisión para datos en movimiento. Para el modelado de dominios de productos de datos y otras preocupaciones sociotécnicas, Oracle se alinea con el trabajo que está llevando a cabo el visionario en el ámbito de las mallas de datos Zhamak Dehghani.

La triste realidad es que las arquitecturas de datos monolíticas del pasado son engorrosas, costosas y poco flexibles. A lo largo de los años, se ha demostrado que la mayoría del tiempo y los costos que implica una plataforma empresarial digital, desde las aplicaciones hasta los análisis, se concentran en los esfuerzos de integración. Por lo tanto, gran parte de las iniciativas de plataforma fracasan.

Aunque la malla de datos no es la panacea frente a las arquitecturas de datos monolíticas y centralizadas, los principios, las prácticas y las tecnologías de la estrategia de malla de datos están pensados para alcanzar algunos de los objetivos de modernización más urgentes y no abordados de las iniciativas empresariales basadas en datos.

Algunas de las tendencias tecnológicas que llevaron a la aparición de la malla de datos como solución incluyen:

Un cambio de mentalidad es el primer paso más importante hacia una malla de datos. La disposición a adoptar las prácticas aprendidas de innovación es la guía básica hacia una modernización exitosa de la arquitectura de datos.

Estas áreas de prácticas aprendidas incluyen:

• Diseño: una metodología probada para resolver "problemas perversos", aplicada a dominios de datos empresariales para crear grandes productos de datos
• Teoría de trabajos pendientes: aplicación de una innovación centrada en el cliente y un proceso de innovación basado en resultados para garantizar que los productos de datos empresariales resuelvan problemas empresariales reales

Las metodologías de pensamiento de diseño aportan técnicas probadas que ayudan a romper los silos organizativos que frecuentemente bloquean la innovación multifuncional. La teoría de los trabajos a realizar es la base fundamental para diseñar productos de datos que cumplan objetivos específicos del consumidor final (o trabajos a realizar) que definan el objetivo del producto.

Aunque el enfoque del producto de datos surgió inicialmente de la comunidad de ciencia de datos, ahora se está aplicando a todos los aspectos de la gestión de datos. En lugar de crear arquitecturas de tecnología monolíticas, la malla de datos se centra en los consumidores de datos y los resultados empresariales.

Aunque el pensamiento de productos de datos se puede aplicar a otras arquitecturas de datos, es una parte esencial de una malla de datos. Para ejemplos pragmáticos de cómo aplicar el pensamiento de productos de datos, el equipo de Intuit escribió un análisis detallado de sus experiencias.

Los productos de cualquier tipo, desde materias primas hasta artículos en su tienda local, se producen como activos de valor, destinados a ser consumidos, y tienen un trabajo específico que hacer. Los productos de datos pueden adoptar varias formas, según el dominio de negocio o el problema que se vaya a resolver, y pueden incluir:

• Análisis: informes históricos/en tiempo real y paneles de control
• Juegos de datos: recopilaciones de datos en diferentes formas/formatos
• Modelos: objetos de dominio, modelos de datos y funciones de aprendizaje automático (AA)
• Algoritmos: modelos de aprendizaje automático, puntuación, reglas de negocio
• Servicios de datos y API: tareas, cargas útiles, temas, API de REST y mucho más

Se crea un producto de datos para el consumo, que suele tenerse fuera del departamento de TI y requiere el seguimiento de atributos adicionales, como:

• Mapa de partes interesadas: ¿quién es el propietario que crea y consume este producto?
• Empaquetado y documentación: ¿Cómo se utiliza? ¿Cómo se etiqueta?
• Objetivo y valor: ¿Cuál es el valor implícito/explícito del producto? ¿Hay depreciación con el paso del tiempo?
• Calidad y coherencia: ¿cuáles son los KPI y los SLA de uso? ¿Es verificable?
• Provenencia, ciclo de vida y gobernanza: ¿Existe confianza y capacidad de explicación de los datos?

Los sistemas de TI descentralizados son una realidad moderna, y con el auge de las aplicaciones SaaS y la infraestructura de nube pública (IaaS), la descentralización de las aplicaciones y los datos está aquí para quedarse. Las arquitecturas de software de aplicaciones están cambiando de los monolitos centralizados del pasado a microservicios distribuidos (una malla de servicios). La arquitectura de datos seguirá la misma tendencia hacia la descentralización, con datos cada vez más distribuidos en una variedad más amplia de sitios físicos y en muchas redes. Esto se denomina malla de datos.

Una malla es una topología de red que permite que un grupo grande de nodos no jerárquicos trabajen juntos de forma colaborativa.

Algunos ejemplos técnicos habituales son:

• WiFiMesh: varios nodos trabajan juntos para mejorar la cobertura
• ZWave/Zigbee: redes de dispositivos para el hogar inteligentes de baja energía
• Malla 5G: conexiones de celdas más fiables y resistentes
• Starlink: malla de banda ancha de satélite a escala global
• Malla de servicio: una forma de proporcionar controles unificados sobre microservicios descentralizados (software de aplicaciones)

La malla de datos está alineada con estos conceptos de malla y proporciona una forma descentralizada de distribuir datos a través de redes virtuales/físicas y a grandes distancias. Las arquitecturas monolíticas de integración de datos heredadas, como ETL y las herramientas de federación de datos, y más recientemente, los servicios en la nube pública, como AWS Glue, requieren una infraestructura altamente centralizada.

Una solución de malla de datos completa debe poder funcionar en un marco multinube, que podría abarcar desde sistemas locales, varias nubes públicas e incluso redes perimetrales.

En un mundo en el que los datos están muy distribuidos y descentralizados, la función de la seguridad de la información es primordial. A diferencia de los monolitos altamente centralizados, los sistemas distribuidos deben delegar las actividades necesarias para autenticar y autorizar a varios usuarios a diferentes niveles de acceso. La delegación segura de confianza entre redes es difícil de lograr.

Algunas consideraciones incluyen:

• Cifrado estático: como datos/eventos que se escriben en el almacenamiento
• Autenticación distribuida: para servicios y almacenes de datos, como mTLS, certificados, SSO, almacenes secretos y almacenes de datos
• Cifrado en movimiento: como datos/eventos que fluyen en la memoria
• Gestión de identidades: servicios de tipo LDAP/IAM, multiplataforma
• Autorizaciones distribuidas: para puntos finales de servicio para redactar datos
  Por ejemplo: Open Policy Agent (OPA), un sidecar para colocar el punto de decisión de política (PDP) en el clúster contenedor/K8S, donde se está procesando el punto final del microservicio. LDAP/IAM puede ser cualquier servicio compatible con JWT.
• Enmascaramiento determinista: para ocultar de forma fiable y consistente los datos de PII

La seguridad dentro de cualquier sistema de TI puede ser difícil, y es aún más difícil proporcionar una alta seguridad dentro de los sistemas distribuidos. Sin embargo, estos problemas se pueden resolver.

Un principio fundamental de la malla de datos es la noción de distribución de la propiedad y la responsabilidad. La mejor práctica es federar la propiedad de los productos de datos y los dominios de datos a las personas de una organización más cercanas a los datos. En la práctica, esto puede alinearse con los datos de origen (por ejemplo, fuentes de datos no procesados, como los sistemas operativos de registro/aplicaciones) o con los datos analíticos (por ejemplo, datos generalmente compuestos o agregados formateados para que los consumidores de datos los utilicen fácilmente). En ambos casos, los productores y consumidores de los datos suelen estar alineados con las unidades de negocio en lugar de con las organizaciones de TI.

Las antiguas formas de organizar dominios de datos suelen caer en la trampa de alinearse con las soluciones tecnológicas, como las herramientas ETL, los almacenes de datos, los lagos de datos o la organización estructural de una empresa (recursos humanos, marketing y otras líneas de negocio). Sin embargo, para un problema de negocio determinado, los dominios de datos suelen estar mejor alineados con el alcance del problema que se está resolviendo, el contexto de un proceso de negocio concreto o la familia de aplicaciones en un área de problema específica. En las grandes empresas, estos dominios de datos suelen encontrarse entre las organizaciones internas y las huellas tecnológicas.

La descomposición funcional de los dominios de datos adquiere una prioridad elevada de primera clase en la malla de datos. Diversas metodologías de descomposición de datos para el modelado de dominios pueden adaptarse a la arquitectura de malla de datos, incluido el modelado clásico de almacenes de datos (como Kimball e Inmon) o el modelado de almacenes de datos, pero la metodología más común que se está probando actualmente en la arquitectura de malla de datos es el diseño controlado por dominios (DDD). El enfoque DDD surgió de la descomposición funcional de microservicios y se está aplicando en un contexto de malla de datos.

Un área importante donde Oracle se ha sumado a la discusión sobre la malla de datos es elevar la importancia de los datos en movimiento como ingrediente clave de una malla de datos moderna. Los datos en movimiento son fundamentalmente esenciales para sacar los datos del mundo heredado del procesamiento por lotes monolítico y centralizado. Las capacidades de los datos en movimiento responden a varias preguntas principales de la malla de datos, tales como:

• ¿Cómo podemos acceder a los productos de datos alineados con el origen en tiempo real?
• ¿Qué herramientas pueden proporcionar los medios para distribuir transacciones de datos de confianza en una malla de datos físicamente descentralizada?
• Cuando necesite hacer que los eventos de datos estén disponibles como API de productos de datos, ¿qué puedo utilizar?
• Para productos de datos analíticos que deben estar continuamente actualizados, ¿cómo me alinearía con los dominios de datos y garantizaría confianza y validez?

Estas preguntas no son solo una cuestión de "detalles de implementación", sino que son de importancia central para la propia arquitectura de datos. Un diseño controlado por dominio para datos estáticos utilizará diferentes técnicas y herramientas que un proceso dinámico de datos en movimiento del mismo diseño. Por ejemplo, en las arquitecturas de datos dinámicas, el libro mayor de datos es la fuente central de datos para los eventos de datos.

Los libros mayores son un componente fundamental para hacer que funcione una arquitectura de datos distribuidos. Al igual que con un libro mayor de contabilidad, un libro mayor de datos registra las transacciones a medida que se producen.

Cuando distribuimos el libro mayor, los eventos de datos se vuelven "reproducibles" en cualquier ubicación. Algunos libros mayores son un poco como un registrador de vuelo de avión que se utiliza para la alta disponibilidad y la recuperación ante desastres.

A diferencia de los almacenes de datos centralizados y monolíticos, los libros mayores distribuidos están diseñados específicamente para realizar un seguimiento de los eventos atómicos y/o las transacciones que se producen en otros sistemas (externos).

Una malla de datos no es solo un tipo único de libro mayor. Según los casos de uso y los requisitos, una malla de datos puede utilizar diferentes tipos de libros mayores de datos basados en eventos, incluidos los siguientes:

• Libro mayor de eventos de uso general, como Kafka o Pulsar
• Libro mayor de eventos de datos: herramientas de replicación/CDC distribuidas
• Software intermedio de mensajería: incluye ESB, MQ, JMS y AQ
• Libro mayor de cadenas de bloques: para transacciones seguras, inmutables y de varias partes

Juntos, estos libros mayores pueden actuar como una especie de registro de eventos duraderos para toda la empresa, proporcionando una lista en ejecución de eventos de datos que se producen en sistemas de registro y sistemas de análisis.

Los flujos de datos políglota tienen una prevalencia mayor que nunca. Varían según los tipos de eventos, las cargas útiles y la semántica de las distintas transacciones. Una malla de datos debe soportar los tipos de flujo necesarios para una variedad de cargas de trabajo de datos empresariales.

Por supuesto, hay más de tres atributos de una malla de datos. Nos hemos centrado en los tres aspectos anteriores como una forma de centrar la atención en los atributos que Oracle considera que son algunos de los aspectos nuevos y únicos del enfoque de malla de datos moderno emergente.

Otros atributos importantes de la malla de datos incluyen:

• Herramientas de autoservicio: la malla de datos adopta la tendencia general de gestión de datos hacia el autoservicio. Los desarrolladores ciudadanos deben proceder cada vez más de las clasificaciones de los propietarios de datos.
• Gobernanza de datos: la malla de datos también ha abrazado la tendencia de larga data hacia un modelo de gobernanza federada más formalizado, apoyado por directores de datos, administradores de datos y proveedores de catálogos de datos durante muchos años.
• Uso de datos: al profundizar en los principios de la malla de datos, hay una gran cantidad de trabajo básico para garantizar que los productos de datos sean altamente utilizables. Los principios para los productos de datos se referirán a datos que son valiosos, utilizables y factibles de compartir.

Más allá de las migraciones "lift and shift" de arquitecturas de datos monolíticas a la nube, muchas organizaciones también buscan retirar sus aplicaciones centralizadas del pasado y avanzar hacia una arquitectura de aplicaciones de microservicios más moderna.

Sin embargo, los monolitos de las aplicaciones heredadas suelen depender de bases de datos enormes, lo que plantea la cuestión de cómo dividir en fases el plan de migración para reducir las interrupciones, los riesgos y los costos. Una malla de datos puede proporcionar una importante capacidad operativa de TI para los clientes que realizan transiciones por fases de monolitos a arquitectura de malla. Por ejemplo:

• Descarga de subdominios de transacciones de base de datos, como el filtrado de datos por "contexto enlazado"
• Replicación de transacciones bidireccional para migraciones en fases
• Sincronización entre plataformas, como mainframe en DBaaS

En el lenguaje de los arquitectos de microservicios, este enfoque utiliza un buzón de salida de transacciones bidireccional para activar el patrón de migración fig de Strrangler, un contexto enlazado a la vez.

Las aplicaciones clave para el negocio requieren KPI y SLA muy altos en lo que a resiliencia y continuidad se refiere. Independientemente de si estas aplicaciones son monolíticas, microservicios o intermedios, no pueden caer.

En los sistemas de misión crítica, un modelo de datos distribuido de coherencia eventual no suele ser aceptable. Sin embargo, estas aplicaciones deben funcionar en muchos centros de datos. Esto plantea la cuestión de la continuidad del negocio, "¿Cómo puedo ejecutar mis aplicaciones en más de un centro de datos sin dejar de garantizar datos correctos y consistentes".

Independientemente de si las arquitecturas monolíticas utilizan "conjuntos de datos fragmentados" o si los microservicios se configuran para una alta disponibilidad entre sitios, la malla de datos ofrece datos correctos y de alta velocidad a cualquier distancia.

Una malla de datos puede proporcionar la base para una información descentralizada y 100 % correcta en todos los sitios. Por ejemplo:

• Transacciones lógicas de latencia muy baja (entre plataformas)
• Garantías con capacidad ACID para datos correctos
• Resolución de conflictos, bidireccional y multiactiva

Una plataforma moderna de estilo de malla de servicios utiliza eventos para el intercambio de datos. En lugar de depender del procesamiento por lotes en el nivel de datos, las cargas útiles de datos fluyen continuamente cuando se producen eventos en la aplicación o el almacén de datos.

Para algunas arquitecturas, los microservicios deben intercambiar cargas útiles de datos entre sí. Otros patrones requieren el intercambio entre aplicaciones monolíticas o almacenes de datos. Esto plantea la pregunta: "¿Cómo puedo intercambiar de forma fiable cargas útiles de datos de microservicios entre mis aplicaciones y almacenes de datos?"

Una malla de datos puede suministrar la tecnología básica para el intercambio de datos centrado en los microservicios. Por ejemplo:

• De los microservicios a los microservicios en contexto
• De los microservicios a los microservicios en todos los contextos
• Monolitos hacia/desde microservicios

Los patrones de microservicios, como el abastecimiento de eventos, CQRS y la bandeja de salida de transacciones, son soluciones comúnmente conocidas. Una malla de datos proporciona las herramientas y los marcos para hacer que estos patrones sean repetibles y fiables a escala.

Más allá de los patrones de diseño de microservicios, la necesidad de integración empresarial se extiende a otros sistemas de TI, como bases de datos, procesos de negocio, aplicaciones y dispositivos físicos de todo tipo. Una malla de datos proporciona la base para integrar datos en movimiento.

Los datos en movimiento normalmente se basan en eventos. Una acción de usuario, un evento de dispositivo, un paso de proceso o una confirmación de almacén de datos pueden iniciar un evento con una carga útil de datos. Estas cargas útiles de datos son cruciales para integrar sistemas de Internet de las cosas (IoT), procesos y bases de datos empresariales, almacenes de datos y lagos de datos.

Una malla de datos proporciona la tecnología base para la integración en tiempo real en toda la empresa. Por ejemplo:

• Conexión de eventos de dispositivos reales a sistemas de TI
• Integración de los procesos de negocio en los sistemas de ERP
• Alineación de bases de datos operativas con almacenes de datos analíticos

Las grandes organizaciones tendrán naturalmente una combinación de sistemas antiguos y nuevos, monolitos y microservicios, almacenes de datos operativos y analíticos; una malla de datos puede ayudar a unificar estos recursos en diferentes dominios de negocio y de datos.

Los almacenes de datos analíticos pueden incluir data marts, almacenes de datos, cubos OLAP, lagos de datos y tecnologías de data lakehouse.

En general, solo hay dos formas de traer datos a estos almacenes de datos analíticos:

• Carga por lotes/microlotes en un programador de tiempo
• Ingesta de flujo: carga continua de eventos de datos

Una malla de datos proporciona la base para una capacidad de ingestión de datos de transmisión. Por ejemplo:

• Eventos de datos de bases de datos o almacenes de datos
• Eventos de dispositivo de telemetría de dispositivo físico
• Registro de eventos de aplicación o transacciones de negocio

La ingesta de eventos por flujo puede reducir el impacto en los sistemas de origen, mejorar la fidelidad de los datos (importante para la ciencia de datos) y permitir el análisis en tiempo real.

Una vez ingeridos en los almacenes de datos analíticos, suele ser necesario que los pipelines de datos preparen y transformen los datos en diferentes niveles o zonas de datos. Este proceso de acotación de datos suele ser necesario para los productos de datos analíticos descendentes.

Una malla de datos puede proporcionar una capa de pipeline de datos gestionada de forma independiente que funcione con los almacenes de datos analíticos y que proporcione los siguientes servicios principales:

• Descubrimiento y preparación de datos de autoservicio
• Gobernanza de recursos de datos entre dominios
• Preparación y transformación de datos en los formatos de productos de datos que se requieren
• Verificación de datos mediante una política que garantice la coherencia

Estos pipelines de datos deben ser capaces de funcionar en diferentes almacenes de datos físicos (como marts, almacenes o lagos) o como un "flujo de datos de pushdown" dentro de plataformas de datos analíticos que soportan datos de flujo, como Apache Spark y otras tecnologías de data lakehouse.

Los eventos ocurren continuamente. El análisis de los eventos en un flujo puede ser crucial para comprender lo que está sucediendo de momento a momento.

Este tipo de análisis basados en series temporales de flujos de eventos en tiempo real puede ser importante para datos de dispositivos IoT del mundo real y para comprender lo que ocurre en sus centros de datos de TI, o para transacciones financieras, como la supervisión del fraude.

Una malla de datos completa incluirá las capacidades fundamentales para analizar eventos de todo tipo, en muchos tipos diferentes de ventanas de tiempo de eventos. Por ejemplo:

• Análisis de flujo de eventos simple (eventos web)
• Supervisión de actividad empresarial (eventos SOAP/REST)
• Procesamiento de eventos complejos (correlación de varios flujos)
• Análisis de eventos de datos (en transacciones de DB/ACID)

Al igual que los pipelines de datos, los análisis de transmisión pueden ejecutarse dentro de una infraestructura de data lakehouse establecida o por separado, como servicios nativos en la nube.

Los responsables de la integración de datos están buscando una integración de datos analítica y operativa en tiempo real a partir de una recopilación diversa de almacenes de datos resilientes. Las innovaciones han sido constantes y rápidas a medida que la arquitectura de datos evoluciona hacia la analítica de transmisión. La alta disponibilidad operativa ha dado lugar a análisis en tiempo real, y la automatización de la ingeniería de datos está simplificando la preparación de los datos, lo que permite a los científicos y analistas de datos contar con herramientas de autoservicio.