Construir una malla de datos basada en eventos

Capítulo 1. Comunicación de datos basada en sucesos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

La forma en que las empresas se relacionan con sus datos está cambiando rápidamente. Atrás quedaron los días en que todos los datos de una empresa encajaban perfectamente en una única base de datos relacional. La revolución de los grandes datos, iniciada hace más de dos décadas, ha evolucionado desde entonces, y ya no basta con almacenar tus conjuntos masivos de datos en un gran lago de datos para analizarlos por lotes. La velocidad y la interconectividad han surgido como los próximos grandes requisitos empresariales competitivos, transformando de nuevo la forma en que las empresas crean, almacenan, acceden y comparten sus datos importantes.

Los datos son el alma de una empresa. Pero muchas de las formas en que las empresas crean, comparten y utilizan los datos son desordenadas e inconexas. La malla de datos proporciona un marco completo para revisar estas relaciones, a menudo disfuncionales, y ofrece una nueva forma de pensar, crear y compartir datos en toda una organización, de modo que podamos hacer cosas útiles y provechosas: prestar un mejor servicio a nuestros clientes, elaborar informes sin errores, obtener información procesable y permitir procesos verdaderamente basados en datos.

Para comprender lo que intentamos solucionar, primero necesitamos tener una idea de los principales problemas de datos a los que se enfrenta una empresa moderna.

En primer lugar, los sistemas de big data, que sustentan el motor de análisis empresarial de una empresa, se han disparado en tamaño y complejidad. Ha habido muchos intentos de abordar y reducir esta complejidad, pero todos se han quedado cortos.

En segundo lugar, las operaciones empresariales de las grandes empresas hace tiempo que superaron el punto de ser atendidas por una única implementación monolítica. Las Implementaciones multiservicio son la norma, incluidas las arquitecturas de microservicios y orientadas a servicios. Los límites de estos sistemas modulares rara vez se definen con facilidad, sobre todo cuando muchos sistemas operativos y analíticos separados dependen del acceso de sólo lectura a los mismos conjuntos de datos. Aquí hay una tensión opuesta: por un lado, colocar las funciones empresariales en una única aplicación proporciona un acceso coherente a todos los datos producidos y almacenados en ese sistema. Por otro, estas funciones empresariales pueden no tener absolutamente ninguna relación entre sí, aparte de necesitar un acceso común de sólo lectura a datos empresariales importantes.

Y tercero, un problema común a los ámbitos operativo y analítico: la incapacidad de acceder a datos de alta calidad, bien documentados, autoactualizables y fiables. El volumen de datos que maneja una organización aumenta sustancialmente año tras año, alimentando la necesidad de mejores formas de ordenarlos, almacenarlos y utilizarlos. Esta presión asesta el golpe definitivo al ideal de mantenerlo todo en una única base de datos y obliga a los desarrolladores a dividir las aplicaciones monolíticas en implementaciones separadas con sus propias bases de datos. Mientras tanto, los equipos de big data luchan por seguir el ritmo de la fragmentación y refactorización de estos sistemas operativos, ya que siguen siendo los únicos responsables de obtener sus propios datos.

Los datos han sido tratados históricamente como ciudadanos de segunda clase, como una forma de escape o subproducto emitido por las aplicaciones empresariales. Esta forma de pensar, que da prioridad a las aplicaciones, sigue siendo la principal fuente de problemas en los entornos informáticos actuales, lo que conduce a canalizaciones de datos ad hoc, mecanismos de acceso a los datos improvisados y fuentes incoherentes de verdades similares pero diferentes. La malla de datos aborda estas deficiencias de frente, alterando fundamentalmente las relaciones que mantenemos con nuestros datos. En lugar de un subproducto secundario, los datos, y el acceso a ellos, pasan a ser ciudadanos de primera clase, al mismo nivel que cualquier otro servicio empresarial.

Los datos empresariales importantes deben estar disponibles de forma fácil y fiable como bloques de construcción primitivos para tus aplicaciones, independientemente del tiempo de ejecución, el entorno o la base de código de tu aplicación. Tratamos nuestros datos como ciudadanos de primera clase, con propiedad exclusiva, garantías mínimas de calidad, acuerdos de nivel de servicio (SLA) y mecanismos escalables para un acceso limpio y fiable. Los flujos de eventos son el mecanismo ideal para servir estos datos, proporcionando una forma sencilla pero potente de comunicar de forma fiable datos empresariales importantes a través de una organización, permitiendo a cada consumidor acceder y utilizar las primitivas de datos que necesita.

En este capítulo, echaremos un vistazo a las fuerzas que han dado forma a las herramientas y sistemas operativos y analíticos que utilizamos habitualmente hoy en día, y a los problemas que conllevan. Las enormes ineficiencias de las arquitecturas de datos contemporáneas nos proporcionan ricos aprendizajes que aplicaremos a nuestras soluciones basadas en eventos. Esto sentará las bases para el próximo capítulo, cuando hablemos de la malla de datos en su conjunto.

¿Qué es la malla de datos?

La malla de datos fue inventada por Zhamak Dehghani. Es un cambio social y tecnológico de en la forma en que se crean los datos, se accede a ellos y se comparten en las organizaciones. La malla de datos proporciona una lingua franca para debatir las necesidades y responsabilidades de los distintos equipos, dominios y servicios, y cómo pueden trabajar juntos para hacer de los datos un ciudadano de primera clase. Este capítulo explora los principios que forman la base de la malla de datos.

En mi último libro, Building Event-Driven Microservices (O'Reilly), introduje el término capa de comunicación de datos, tocando en muchos de los mismos principios que la malla de datos: tratar los datos como ciudadanos de primera clase, formalizar la estructura para la comunicación entre dominios, publicar los datos en flujos de eventos para uso general, y facilitar su uso tanto a los productores como a los consumidores de datos. Y aunque me gusta la terminología de la capa de comunicación de datos, la realidad es que creo que el lenguaje y los principios formalizados de la malla de datos proporcionan todo lo que necesitamos para hablar de este problema sin introducir otro paradigma de "datos algo algo".

El libro de Dehghani, Data Mesh (O'Reilly), expone la teoría y el pensamiento de la malla de datos con gran profundidad y detalle, pero sigue siendo necesariamente agnóstico de las implementaciones específicas.

En este libro, veremos una implementación práctica de la malla de datos que utiliza el flujo de eventos como modo principal de producto de datos para las comunicaciones de datos entre dominios. Podemos ser un poco más pragmáticos y menos intensos en la teoría y más concretos y específicos en la implementación de un diseño basado en eventos. Aunque creo que los flujos de eventos son fundamentalmente la mejor opción para la comunicación entre dominios, tienen sus contrapartidas y, por supuesto, también las cubriré, mencionando las posibilidades no basadas en flujos cuando sean más adecuadas.

La malla de datos se basa en cuatro principios fundamentales: propiedad del dominio, datos como producto, gobierno federado y plataforma de autoservicio. Juntos, estos principios nos ayudan a estructurar una forma de comunicar los datos empresariales importantes en toda la organización. Evaluaremos estos principios con más detalle en el próximo capítulo, pero antes de llegar allí, veamos por qué la malla de datos es importante hoy en día.

Una malla de datos basada en sucesos

Los modernos requisitos competitivos de los grandes datos en movimiento, combinados con la moderna computación en nube, exigen un replanteamiento de la forma en que las empresas crean, almacenan, mueven y utilizan los datos. La base de esta nueva arquitectura de datos es el evento, el quantum de datos que representa las actividades empresariales reales, proporcionado a través de una multitud de flujos de eventos creados al efecto. Los flujos de eventos proporcionan los medios para que un sistema nervioso central permita a las unidades de negocio acceder y utilizar bloques de construcción de datos fundamentales y autoactualizables. Estos bloques de construcción de datos se unen a las filas de la contenedorización, la infraestructura como servicio (IaaS),los conductos de integración continua (CI) y de implementación continua (CD), y las soluciones de monitoreo, los componentes sobre los que se construyen las modernas aplicaciones en la nube.

Los flujos de eventos no son nuevos. Pero muchas de las limitaciones tecnológicas que sustentaban las anteriores arquitecturas basadas en eventos, como la escala, la retención y el rendimiento limitados, se han aliviado en gran medida. Los modernos corredores de eventos multiinquilino con almacenamiento por niveles pueden almacenar una cantidad ilimitada de datos, eliminando las estrictas restricciones de capacidad que limitaban las arquitecturas anteriores. Los productores escriben sus datos importantes del dominio empresarial en un flujo de eventos, lo que permite a otros acoplarse a ese flujo y utilizar los bloques de construcción de datos para sus propias aplicaciones. Por último, las aplicaciones consumidoras pueden crear a su vez sus propios flujos de eventos para compartir sus propios datos empresariales con los demás, lo que da lugar a una malla de comunicaciones estandarizada para uso de todos.

La malla de datos nos proporciona conceptos y un lenguaje muy útiles para construir este sistema nervioso central interconectado. La Figura 1-1 muestra un ejemplo básico del aspecto que podría tener una malla de datos.

Figura 1-1. Una implementación muy básica de Hello Data Mesh

El equipo propietario del sistema operativo Alfa selecciona algunos datos de su límite de servicio, los remodela y los escribe en un producto de datos alineado con la fuente, que también es de su propiedad (trataremos más sobre la alineación de productos de datos en "Los tres tipos de alineación de productos de datos"). El equipo que posee el sistema operativo Beta lee los datos de este producto de datos en su propio límite de servicio, remodelándolos de nuevo, transformándolos y almacenando sólo lo que necesitan.

Mientras tanto, un tercer equipo se conecta al producto de datos del equipo Alfa y lo utiliza para componer su propio producto de datos alineados agregados. A continuación, este mismo equipo utiliza su producto de datos alineados agregados tanto para alimentar un caso de uso de análisis de flujo como para escribir un lote de archivos en el almacenamiento en la nube, donde los analistas de datos lo utilizarán para componer informes y alimentar trabajos de análisis por lotes existentes.

Este diagrama representa sólo la punta del iceberg de la malla de datos, y quedan muchas áreas por cubrir. Pero lo esencial de la malla de datos basada en eventos es hacer que los datos estén disponibles en tiempo real para cualquier consumidor que los necesite.

Muchos de los problemas que resuelve la malla de datos existen desde hace mucho tiempo. Ahora vamos a hacer un breve recorrido histórico para comprender mejor qué es lo que resolvemos y por qué la malla de datos es una solución muy relevante y potente.

Utilización de datos en el plano operativo

Los datos tienden a ser creados por un sistema operativo que hace cosas de negocios. Con el tiempo, esos datos tienden a ser arrastrados al plano analítico con fines de análisis y elaboración de informes. En esta sección, nos centraremos en parte del plano operativo y en los retos habituales de compartir datos empresariales con otros servicios operativos (y analíticos).

El monolito de datos

Las bases de datos de procesamiento de transacciones en línea (OLTP) constituyen la base de gran parte de los servicios informáticos operativos actuales (llamémoslos "monolitos" para simplificar). Los sistemas monolíticos tienden a desempeñar un gran papel en el plano operativo, ya que la comunicación síncrona consistente tiende a ser más sencilla de razonar y desarrollar que la comunicación asíncrona. Las bases de datos relacionales, como PostgreSQL y MySQL, tienen un gran protagonismo en las aplicaciones monolíticas, ya que proporcionan transacciones de atomicidad, consistencia, aislamiento y durabilidad (ACID) y un estado consistente para la aplicación.

Juntos, la aplicación y la base de datos demuestran los siguientesprincipios de monolito de datos:

La base de datos es la fuente de la verdad

El monolito confía en la base de datos subyacente como almacén duradero de información para la aplicación. Cualquier registro nuevo o actualizado se registra primero en la base de datos, convirtiéndola en la fuente definitiva de verdad para esas entidades.

Los datos son muy coherentes

Los datos del monolito, cuando se almacenan en una base de datos relacional típica de , son fuertemente consistentes. Esto proporciona a la lógica empresarial una fuerte coherencia de lectura y escritura y, gracias a las transacciones, no accederá inadvertidamente a registros parcialmente actualizados.

Los datos de sólo lectura están fácilmente disponibles

Cualquier parte del monolito puede acceder fácilmente a los datos almacenados en la base de datos del monolito . Los permisos de acceso de sólo lectura garantizan que no se produzcan alteraciones inadvertidas en los datos.

Ten en cuenta que a la base de datos sólo debe acceder directamente el servicio que la posee, y no debe utilizarse como punto de integración.

Estos tres principios forman una fuerza vinculante que hacepoderosas a las arquitecturas monolíticas. El código de tu aplicación tiene acceso de sólo lectura a toda la gama de datos almacenados en la base de datos del monolito como un conjunto deprimitivas de datos autorizadas, coherentes y accesibles. Esta base facilita la construcción de nuevas funcionalidades de la aplicación, siempre que sea en la misma aplicación. Pero, ¿y si necesitas crear una nueva aplicación?

Las dificultades de comunicar datos para cuestiones operativas

Una nueva aplicación no puede confiar en el mismo fácil acceso a las primitivas de datos que tendría si se construyera como parte del monolito. Esto no sería un problema si la nueva aplicación no necesitara ninguno de los datos empresariales del monolito. Sin embargo, rara vez es así, ya que las empresas son efectivamente un conjunto de dominios superpuestos, en particular el núcleo común, con los mismos datos al servicio de múltiples requisitos empresariales. Por ejemplo, un minorista de comercio electrónico puede confiar en su monolito para gestionar sus pedidos, ventas e inventario, pero necesita una nueva aplicación alimentada por una base de datos basada en documentos (u otro tipo de base de datos) para la funcionalidad de búsqueda en texto plano. La Figura 1-2 destaca el quid de la cuestión: ¿cómo introducimos los datos de Ol' Reliable en la nueva base de datos de documentos para potenciar la búsqueda?

Figura 1-2. El nuevo equipo del servicio de búsqueda debe averiguar cómo obtener los datos que necesita del monolito y mantenerlos actualizados

Esto pone al nuevo equipo del servicio de búsqueda en un pequeño aprieto. El servicio necesita acceder a los datos del artículo, la tienda y el inventario en el monolito, pero también necesita modelarlo todo como un conjunto de documentos para el motor de búsqueda. Hay dos formas habituales en que los equipos intentan resolver esto. Una es replicar y transformar los datos para el motor de búsqueda, en un intento de preservar los tres principios de datos del monolito. La segunda es utilizar API para reestructurar los límites de servicio del sistema de origen, de forma que no se copien simplemente los mismos datos, sino que se sirvan completamente desde un único sistema. Ambas pueden lograr cierto éxito, pero en última instancia son insuficientes como solución general. Veámoslas con más detalle para ver por qué.

Estrategia 1: Replicar datos entre servicios

Hay varios mecanismos que entran dentro de esta estrategia. El primero y más sencillo es simplemente acceder a la base de datos y coger los datos que necesites, cuando los necesites. Un enfoque algo más estructurado consiste en consultar periódicamente la base de datos de origen y volcar el conjunto de resultados en tu nueva estructura. Aunque esto te da la ventaja de seleccionar una tecnología de almacenamiento de datos diferente para tu nuevo servicio, tiene algunos inconvenientes importantes:

Acoplamiento estrecho con la fuente

Sigues acoplado al modelo interno de la base de datos fuente y confías exclusivamente en él para gestionar tus necesidades de consulta.

Carga de rendimiento en la fuente

Los grandes conjuntos de datos y las consultas complejas pueden paralizar la base de datos . Esto es especialmente cierto en el caso de la desnormalización de datos para casos de uso analítico, en los que son habituales las tablas múltiples y las uniones complejas.

El segundo mecanismo más común para la estrategia de replicación de datos es una réplica de sólo lectura de la base de datos fuente . Aunque esto puede ayudar a aliviar los problemas de rendimiento de las consultas, los consumidores siguen estando acoplados en el modelo interno. Y, por desgracia, cada acoplamiento externo adicional sobre el modelo de datos interno hace que el cambio sea más caro, arriesgado y difícil para todos los miembros implicados.

Advertencia

El acoplamiento sobre el modelo de datos interno de un sistema fuente causa muchos problemas. El modelo fuente cambiará en el curso de la evolución normal del negocio, lo que a menudo provoca rupturas tanto en las consultas periódicas como en las operaciones internas de todos los consumidores externos. Cada servicio acoplado tendrá que refactorizar su copia del modelo para que coincida con lo disponible en el origen, migrar los datos del modelo antiguo al nuevo y actualizar su código empresarial en consecuencia. Hay una cantidad sustancial de riesgo en cada uno de estos pasos, ya que un fallo al realizar cada uno correctamente puede llevar a malentendidos en el significado de los modelos, copias divergentes de los datos y, en última instancia, resultados empresariales incorrectos.

Las estrategias de replicación de datos se vuelven más difíciles de mantener con cada nueva fuente independiente y cada nueva réplica necesaria. Esto introduce algunos problemas nuevos:

El conjunto de datos original puede ser difícil de descubrir

No es infrecuente que un equipo acople accidentalmente su servicio a una copia de los datos originales, en lugar de a los propios datos originales de . Puede ser difícil descubrir cuál es la fuente original de los datos sin recurrir aredes informalesde conocimiento.

Aumento de las conexiones punto a punto

Además, cada nuevo servicio independiente puede convertirse en su propia fuente autorizada de datos, aumentando el número de conexiones punto a punto para la replicación de datos entre servicios.

La replicación punto a punto de datos entre servicios introduce una complejidad adicional, al tiempo que introduce un acoplamiento estrecho en el modelo de datos interno de la fuente. Es insuficiente para construir la capa moderna de comunicación de datos.

Estrategia 2: Utilizar API para evitar la necesidad de replicar datos

Los microservicios de solicitud-respuesta directamente acoplados , también conocidos a veces como microservicios síncronos, son otro enfoque común para tratar el acceso a datos remotos. Los microservicios pueden llamar directamente a la API de otro servicio para intercambiar pequeñas cantidades de información y realizar trabajo en nombre del otro.

Por ejemplo, puedes tener un microservicio que gestione las operaciones relacionadas con el inventario, mientras tienes otros microservicios dedicados a los envíos y las cuentas. Cada una de las peticiones de estos servicios se origina en los microservicios frontend móvil y frontend web dedicados, que cosen las operaciones y devuelven una vista sin fisuras a los usuarios, como se muestra en la Figura 1-3.

Figura 1-3. Ejemplo de una arquitectura sencilla de microservicios de comercio electrónico

Los microservicios síncronos tienen muchas ventajas:

• Los servicios creados específicamente sirven a las necesidades del ámbito empresarial.

• Los propietarios tienen un alto nivel de independencia para utilizar las herramientas, tecnologías y modelos que mejor se adapten a sus necesidades.

• Los equipos también tienen más control sobre los límites de sus dominios, incluido el control y la toma de decisiones sobre cómo ampliarlos para ayudar a atender las necesidades de otros clientes.

Hay numerosos libros escritos sobre microservicios síncronos, como Building Microservices de Sam Newman (O'Reilly) y Microservices Patterns de Chris Richardson (Manning), que entran en muchos más detalles de los que me caben, así que no profundizaré mucho en ellos aquí.

Los principales inconvenientes de esta estrategia son los mismos que con un servicio único:

• No hay ningún mecanismo fácil y fiable para acceder a los datos más allá de los mecanismos proporcionados en la API de los microservicios.

• Los microservicios síncronos suelen estar estructurados para ofrecer una API de operaciones empresariales, no para servir un acceso masivo fiable a los datos del dominio subyacente.

• La mayoría de los equipos recurren a los mismos contratiempos que un monolito: buscar en la base de datos y sacar los datos que necesites, cuando los necesites, (véase la Figura 1-4).
  

  
  

  

  Figura 1-4. Los límites del microservicio pueden no coincidir con las necesidades del problema empresarial

En esta figura, el nuevo servicio depende de losservicios de inventario, cuentas y envíos sólo para acceder a los datos empresariales subyacentes, pero no para ejecutarninguna lógica empresarial. Aunque esta forma de acceso a los datos puede servirse a través de una API síncrona, puede no ser adecuada para todos los casos de uso. Por ejemplo, los grandes conjuntos de datos, los datos sensibles al tiempo y los modelos complejos pueden impedir que este tipo de acceso se haga realidad. Además, existe la carga operativa de proporcionar la API de acceso a los datos y el rendimiento del servicio de datos además del de la funcionalidad del microservicio base.

Los sistemas operativos carecen de una solución generalizada para comunicar datos empresariales importantes entre servicios. Esto no es algo aislado de las operaciones. El dominio de los macrodatos, que sustenta y potencia los análisis, los informes, el aprendizaje automático, la IA y otros servicios empresariales, es un consumidor voraz de conjuntos de datos completos de toda la empresa.

Mientras que las violaciones de los límites de dominio en la forma de acceso a los datos "smash and grab" sonla base sobre la que se ha construido la ingeniería de big data (he formado parte de tales asaltos durante la década que he pasado en este espacio), afortunadamente para nosotros, nos ha proporcionado ricos conocimientos que podemos aplicar para hacer una solución mejor para todos los usuarios de datos. Pero antes de llegar a eso, echemos un vistazo a los requisitos del dominio de los grandes datos para acceder a y utilizar los datos, y cómo ha evolucionado este espacio hasta donde está hoy.

El Plano Analítico: Almacenes y lagos de datos

Mientras que las preocupaciones operativas se centran principalmente en el OLTP y la comunicación de servidor a servidor, las preocupaciones analíticas se centran históricamente en responder preguntas sobre el rendimiento general de la empresa. Los sistemas de procesamiento analítico en línea (OLAP) almacenan los datos en un formato más adecuado para las consultas analíticas, lo que permite alos analistas de datos evaluar los datos en diferentes dimensiones. Los almacenes de datos ayudan a responder a preguntas como "¿Cuántos artículos vendimos el año pasado?" y "¿Cuál fue nuestro artículo más popular?". Responder a estas preguntas requiere remodelar los datos operativos en un modelo adecuado para la analítica, y también tener en cuenta las grandes cantidades de datos donde se encuentran finalmente las respuestas.

La introducción de datos en un almacén de datos se ha basado históricamente en un proceso conocido como Extraer, Transformar y Cargar (ETL), como se muestra en la Figura 1-5.

Un trabajo programado periódicamente extrae los datos de una o varias bases de datos fuente y los transforma en el modelo de datos requerido por el almacén de datos. A continuación, los datos se cargan en el almacén de datos, donde los analistas de datos pueden realizar más consultas y análisis. Los almacenes de datos suelen imponer esquemas bien definidos en el momento de la escritura, incluidos los tipos, nombres y anulabilidad de las columnas.

Figura 1-5. Flujo de trabajo ETL típico de un almacén de datos

Históricamente, los almacenes de datos han demostrado su eficacia a la hora de proporcionar un medio para obtener resultados analíticos. Pero las cargas de datos y cálculo, cada vez mayores, requerían unidades de disco más grandes y chips de cálculo más potentes, y acabaron por chocar con los límites físicos del hardware informático. Así que, en lugar de seguir ampliando, llegó el momento de reducir.

La necesidad de una escala masiva era evidente para Google, que publicó The Google File System en octubre de 2003. Esta es la época que vio nacer los grandes datos y provocó un replanteamiento global masivo de cómo creamos, almacenamos, procesamos y, en última instancia, utilizamos los datos.

Nota

Muchos almacenes de datos modernos también ofrecen una gran escalabilidad, pero esto no se hizo realidad hasta la llegada de la revolución de los grandes datos. Históricamente, los almacenes de datos estaban limitados por los mismos factores que cualquier otro sistema que funcionara en un único servidor.

Apache Hadoop se impuso rápidamente como la forma definitiva de resolver los problemas de escalado a los que se enfrentaban los sistemas OLAP tradicionales. Al ser gratuito y de código abierto, cualquier empresa podía utilizarlo en cualquier lugar, siempre que supiera cómo gestionar los requisitos de infraestructura. También proporcionó una nueva forma de calcular los análisis, en la que ya no estabas constreñido a un sistema propietario limitado por los recursos de un único ordenador.

Hadoop introdujo en el Sistema de Archivos Distribuidos Hadoop (HDFS), un sistema de archivos duradero y tolerante a fallos que permitía crear, almacenar y procesar conjuntos de datos realmente masivos en múltiples nodos de hardware. Aunque HDFS ya ha sido suplantado en gran medida por opciones como Amazon S3 y Google Cloud Storage, allanó el camino para una nueva y audaz idea: copiar todos los datos que necesites en una única ubicación lógica, independientemente de su tamaño, y aplicar procesamiento para limpiar, ordenar y remodelar los datos en el formato necesario para derivar importantes análisis empresariales.

La arquitectura de big data introdujo un cambio significativo en la mentalidad hacia los datos. No sólo abordó los problemas de capacidad de los sistemas OLAP existentes, sino que introdujo un nuevo concepto en el mundo de los datos: no sólo era aceptable, sino preferible, utilizar datos no estructurados o semiestructurados, en lugar de imponer un esquema en la escritura como en unalmacén de datos. En este nuevo mundo de big data, eras libre de escribir datos con o sin ningún esquema o estructura y resolverlo todo más tarde en el momento de la consulta aplicando un esquema en la lectura. Muchos ingenieros de datos se alegraron de librarse del requisito del esquema en escritura, ya que facilitaba la simple introducción de datos en el ecosistema.

Considera la Tabla 1-1, en la que se comparan las estructuras de datos y los casos de uso entre la base de datos relacional y MapReduce. MapReduce es uno de los primeros marcos de procesamiento de Hadoop y es lo que utilizarías para leer datos, aplicar un esquema (en la lectura), realizar transformaciones y agregaciones, y producir el resultado final.

Tabla 1-1. Comparación entre un sistema de gestión de bases de datos relacionales y Hadoop, alrededor de 2009

	RDBMS tradicional	MapReduce
Tamaño de los datos	Gigabytes	Petabytes
Accede a	Interactivo y por lotes	Lote
Actualizaciones	Leer y escribir muchas veces	Escribe una vez, lee muchas veces
Estructura	Esquema estático	Esquema dinámico
Integridad	Alta	Baja
Escalado	No lineal	Lineal

Observa que esta guía definitiva de 2009 promueve MapReduce como una solución para manejar datos de baja integridad con un esquema dinámico, haciendo hincapié en la noción de que HDFS debe almacenar datos no estructurados de baja integridad, con esquemas variables y posiblemente conflictivos que deben resolverse en tiempo de ejecución. También señala que estos datos se escriben una vez, se leen muchas veces, que es precisamente el escenario en el que quieres un esquema fuerte, consistente y reforzado, proporcionando una amplia oportunidad para que los usuarios de los datos, bien intencionados pero sin restricciones, apliquen un esquema en tiempo de lectura que malinterprete o invalide los datos.

Un esquema en escritura, que incluya columnas bien definidas con tipos, valores por defecto, anulabilidad y nombres, no restringe necesariamente de ningún modo las transformaciones posteriores. Tampoco te obliga a desnormalizar o unir datos antes de escribir.

Un esquema te proporciona una comprobación de sanidad, asegurando que los datos que estás ingiriendo se ajustan al menos a las expectativas más básicas de los procesadores posteriores. Abandonar esa comprobación de sanidad empuja la detección de errores aguas abajo, causando dificultades significativas a quienes intentan utilizar los datos.

En los primeros días de Hadoop, no creo que yo -o muchos otros- apreciáramos cómo la noción de esquema en lectura acabaría cambiando la forma en que se recopilan, almacenan y analizan los datos. Creíamos y apoyábamos la idea de que estaba bien coger los datos cuando los necesitabas y resolverlos a posteriori, reestructurando, limpiando y aplicando esquemas más adelante. Esto también lo hizo muy apetecible para quienes se planteaban migrar a Hadoop para aliviar sus limitaciones analíticas, porque este movimiento no restringía tus procesos de escritura ni te molestaba con reglas estrictas de ingestión de datos: después de todo, ¡puedes arreglar los datos una vez copiados!

Por desgracia, el principio fundamental de almacenar datos no estructurados para utilizarlos con esquema en lectura resultó ser uno de los principios más costosos y perjudiciales introducidos por la revolución de los grandes datos. Veamos precisamente cómo afecta negativamente al acceso distribuido a los datos y por qué los datos esquematizados bien definidos son un principio tan importante de la malla de datos .

El impacto organizativo del esquema en la lectura

Imponer un esquema en tiempo de lectura, en lugar de en tiempo de escritura, conduce a una proliferación de lo que llamamos "datos malos". La falta de comprobaciones en tiempo de escritura significa que los datos escritos en HDFS pueden no adherirse a los esquemas que los lectores están utilizando en su trabajo actual, como se muestra en la Figura 1-6. Algunos datos erróneos harán que los consumidores detengan el procesamiento, mientras que otros datos erróneos pueden pasar silenciosamente desapercibidos. Aunque ambos son problemáticos, los fallos silenciosos pueden ser mortales y difíciles de detectar.

Figura 1-6. Ejemplos de datos erróneos en un conjunto de datos, descubiertos sólo en el momento de la lectura

Para comprender mejor la influencia perjudicial del esquema en la lectura, echemos un vistazo a tres roles y su relación entre sí. Aunque me limito a mis propias experiencias personales, he tenido la suerte de hablar con muchas otras personas de datos en mi carrera, de diferentes empresas y líneas de negocio. Puedo afirmar con seguridad que, aunque las responsabilidades varían un poco de una organización a otra, este resumen de funciones es, en general, universal para la mayoría de las organizaciones contemporáneas que utilizan big data:

El analista de datos

Encargados de responder a las preguntas empresariales de , generar perspectivas y crear informes basados en datos. Los analistas de datos consultan los conjuntos de datos que les proporcionan los ingenieros de datos.

El ingeniero de datos

Encargado de obtener los datos empresariales importantes de los sistemas de toda la organización y ponerlos en un formato utilizable para los analistas de datos.

El desarrollador de la aplicación

Encargados de desarrollar una aplicación para resolver problemas empresariales. La base de datos de esa aplicación es también la fuente de datos que necesitan los analistas de datos para hacer su trabajo.

Históricamente, la forma más común de adoptar Hadoop en era establecer un equipo de datos dedicado como subconjunto del equipo de ingeniería habitual, o totalmente separado de él. El ingeniero de datos accedía a la base de datos del desarrollador de la aplicación, obtenía los datos necesarios y los extraía para introducirlos en HDFS. Los científicos de datos los limpiarían y reestructurarían (y posiblemente construirían modelos de aprendizaje automático a partir de ellos), antes de pasarlos para su uso en análisis.

Por último, los analistas de datos consultaban y procesaban los conjuntos de datos capturados paraobtener respuestas a sus preguntas analíticas. Sin embargo, este modelo dio lugar a muchos problemas. Las conversaciones entre el equipo de datos y los desarrolladores de aplicaciones eran poco frecuentes y solían girar en torno a garantizar que la carga de consultas del equipo de datos no afectara a las capacidades de servicio de producción.

Hay tres problemas principales con esta separación de preocupaciones y responsabilidades. Veámoslos.

Problema 1: Violación de los límites del modelo de datos

Los datos ingeridos en el dominio analítico están acoplados en el modelo de datos interno de la fuente y dan lugar a un acoplamiento directo por parte de todos los usuarios posteriores de esos datos. En el caso de fuentes sencillas y poco cambiantes, esto puede no suponer un gran problema. Pero muchos modelos abarcan varias tablas, están diseñados para operaciones OLTP y pueden ser objeto de una refactorización sustancial a medida que cambian los casos de uso empresarial. El acoplamiento directo a este modelo interno expone a todos los usuarios posteriores a estos cambios.

Advertencia

Un ejemplo que he visto de modificación de una tabla que rompía silenciosamente los trabajos posteriores consistía en cambiar un campo de booleano a long. La versión original representaba una respuesta a la pregunta "¿Pagó el cliente por promocionar esto?". La versión actualizada representaba el ID del presupuesto del dominio recién ampliado, vinculando esta parte del modelo al presupuesto y su tipo asociado (incluido el nuevo tipo de prueba). La empresa había adoptado un modelo de "prueba antes de comprar" en el que reservaba, por ejemplo, varios cientos de dólares en créditos publicitarios para mostrar la eficacia de la promoción, sin contabilizarlo en los ingresos brutos totales.

Los trabajos que ingerían estos datos en HDFS no perdían el ritmo (ningún esquema en escritura), pero algunos de los trabajos posteriores empezaron a informar de valores extraños. La mayoría de ellos eran trabajos de Python, que evaluaban fácilmente los nuevos valores de long como booleanos, y daban lugar a una atribución excesiva de varios análisis de usuario. Desgraciadamente, como en realidad no se rompió ningún trabajo, este problema no se detectó hasta que un cliente empezó a hacer preguntas sobre resultados anormales en sus informes. Éste es sólo un ejemplo de los muchos que me he encontrado, en los que cambios razonables y bienintencionados en el modelo de datos de un sistema tienen consecuencias no deseadas en todos los que se han acoplado a él.

Problema 2: Falta de propiedad única

Los desarrolladores de aplicaciones son los expertos del dominio y los maestros del modelo de datos de origen, pero su responsabilidad de comunicar esos datos a otros equipos (como el equipo de big data) suele ser inexistente. En cambio, sus responsabilidades suelen terminar en los límites de su aplicación y su base de datos.

Mientras tanto, el ingeniero de datos tiene la tarea de encontrar la forma de sacar esos datos de la base de datos del desarrollador de la aplicación, a tiempo, sin afectar negativamente al sistema de producción. El ingeniero de datos depende de las fuentes de datos, pero a menudo tiene poca o ninguna influencia en lo que ocurre con las fuentes de datos, lo que hace que su papel sea muy reactivo. Esta división producción/datos es una barrera muy real en muchas organizaciones, y a pesar de los mejores esfuerzos, acuerdos, comprobaciones de integración y herramientas preventivas, las roturas en los conductos de ingestión de datos siguen siendo un tema común.

Por último, el analista de datos, responsable de utilizar realmente los datos para obtener valor empresarial, sigue estando a dos grados de separación del experto en el dominio (desarrollador de aplicaciones), y a tres grados si tienes una capa de científicos de datos ahí dentro que siguen manipulando los datos. Tanto los analistas como los científicos de datos tienen que lidiar con los datos que hayan podido extraer los ingenieros de datos, incluida la resolución de datos incoherentes que no coincidan con sus esquemas de lectura existentes.

Como los analistas de datos suelen compartir sus esquemas con otros analistas de datos, también necesitan asegurarse de que sus esquemas resueltos no rompen el trabajo de los demás. Esto es cada vez más difícil de hacer a medida que una organización y sus datos crecen y, por desgracia, sus esfuerzos de resolución se limitan a beneficiar sólo a otros analistas. Los casos de uso operativo tienen que encontrar su propia forma de obtener datos.

Problema 3: Conexiones de datos punto a punto y personalizadas

Mientras que un equipo de datos en una organización pequeña puede constar sólo de un puñado de miembros, las organizaciones más grandes tienen equipos de datos formados por cientos o miles de miembros. En las grandes organizaciones de datos, es habitual extraer las mismas fuentes de datos en varios subdominios diferentes de la plataforma de datos, en función de los casos de uso, los límites del equipo y los límites tecnológicos.

Por ejemplo, los datos de ventas pueden extraerse en el departamento de análisis, el departamento de información al consumidor y el departamento de cuentas por cobrar. Cada subgrupo suele crear, programar y ejecutar de forma independiente trabajos ETL para extraer los datos a su propio subdominio, lo que da lugar a múltiples copias de los datos de origen gestionadas de forma independiente, como se muestra en la Figura 1-7.

Figura 1-7. Tres dominios analíticos, cada uno cogiendo datos de donde puede para hacer su trabajo

Aunque las conexiones de datos punto a punto, creadas a propósito, permiten a los usuarios acceder a los datos que necesitan donde los necesitan, acaban provocando una maraña desordenada. Puede ser difícil saber a quién pertenece el trabajo ETL, especialmente cuando los usuarios y los equipos comparten credenciales de acceso. Rastrear el linaje, la frescura y determinar la propiedad de un conjunto de datos puede ser igualmente difícil, lo que a menudo conduce a una mayor proliferación de nuevos trabajos ETL. Al fin y al cabo, si no estás seguro de que los datos sean exactamente los que necesitas, más vale que hagas tu propio trabajo y tu propia copia, por seguridad.

Imponer controles de acceso en la fuente puede ayudar a aclarar quién puede acceder a qué datos, pero sólo desde la fuente primaria. Pero restringir el acceso a los datos puede ser contraproducente. Un proceso largo o engorroso para obtener acceso puede dar lugar a que la gente simplemente haga copias de otras fuentes menos protegidas. En la Figura 1-7, observa que el dominio Predicciones simplemente circunnavega los controles de acceso a la fuente copiando los datos de ventas del dominio Perspectivas del usuario.

Pero, ¿son estas copias realmente los mismos datos? La frecuencia de sincronización, las transformaciones, las zonas horarias, los fallos intermitentes y un entorno incorrecto (por ejemplo, de ensayo, no de producción) son sólo algunos de los problemas que pueden afectar a la integridad de tu fuente copiada. Es posible que creas que estás recibiendo los datos correctos, pero no es así y no lo sabes. Por ejemplo, copias un conjunto de datos pensando que está sincronizado con la hora UTC-0, pero en realidad está sincronizado con la UTC-6. El formato, la partición y el orden de los datos pueden parecer idénticos, pero siguen existiendo estas diferencias difíciles de detectar y no documentadas.

Las conexiones punto a punto personalizadas pueden ser difíciles de mantener, provocar una acumulación de datos y dar lugar a muchas tareas de sincronización duplicadas que producen datos similares pero diferentes.

Este modelo desarticulado y las responsabilidades de propiedad y distribución de los datos conducen a datos erróneos, lo que resulta costoso en términos de tiempo, dinero y oportunidades perdidas. Echemos un vistazo a los costes, antes de terminar diciendo por qué la malla de datos pretende resolver estos problemas.

Malos datos: Los costes de la inacción

Los datos erróneos suelen pasar desapercibidos hasta que se aplican a un esquema. Por ejemplo, no puedes insertar TEXT en una columna Int32 de una base de datos. Sin embargo, al utilizar el esquema en lectura, aplazamos efectivamente la validación de nuestros datos hasta el final del proceso de canalización de datos. Y aunque nuestras fuentes utilicen un esquema, no hay garantía de que nuestras innumerables canalizaciones punto a punto hayan capturado correctamente el esquema junto con los datos. Ha habido muchos Int32 capturados como String, o, en el peor de los casos, como Object.

Los datos defectuosos son costosos de solucionar, y son más costosos cuanto más extendidos están. Todos los que han accedido, utilizado, copiado o procesado los datos pueden verse afectados y requerir medidas paliativas por su parte. La complejidad aumenta aún más por el hecho de que no todos los consumidores lo "arreglarán" de la misma manera. Esto puede dar lugar a resultados divergentes con otros y puede ser una pesadilla detectarlos, rastrearlos yrectificarlos.

Los datos erróneos suelen ser creados inadvertidamente por personas bienintencionadas, simplemente debido a la naturaleza punto a punto, "mete la mano y cógela", de muchas herramientas de transferencia de datos. Esto se ha visto agravado por la escala masiva, en la que un equipo descubre que no sólo su copia del conjunto de datos es errónea, sino que lo ha sido durante varios meses, y que los resultados de cada trabajo posterior calculado utilizando ese conjunto de datos también son erróneos. Estos trabajos pueden utilizar cientos o miles de nodos de procesamiento, con 32x a 128x más en GB de RAM, procesando cientos de TB de datos cada noche. Esto puede suponer fácilmente cientos de miles o millones de dólares sólo en costes de procesamiento para volver a ejecutar todos los trabajos afectados.

Las decisiones empresariales también pueden haberse visto afectadas. He tenido conocimiento de los detalles de un caso en el que una empresa había facturado incorrectamente a sus clientes varios millones de dólares en conjunto, en algunos casos demasiado y en otros demasiado poco. En realidad, la causa era bastante inocente: un cambio de esquema combinado con una compleja cadena de ETL de datos de "mete la mano y cógela" provocó algunos problemas de interpretación de los datos cuando se aplicó el esquema en el momento de la lectura. Sólo cuando un cliente observó que sus costes de facturación superaban con creces sus costes de contratación, se inició una investigación y se descubrió el problema de fondo.

El creciente protagonismo de los datos en la informática moderna ha llevado a otros a investigar los costes asociados, especialmente en lo que respecta a cuánto cuestan a las empresas los datos erróneos. Los resultados son asombrosamente elevados.

En 2016, un informe de IBM, destacado por la Harvard Business Review (HBR), estimaba el impacto financiero de los datos erróneos en 3,1 billones de dólares estadounidenses, sólo en EEUU. Aunque el informe original (frustrantemente) ya no está disponible, HBR ha conservado algunas de las cifras más relevantes:

• 50%: la cantidad de tiempo que los trabajadores del conocimiento pierden buscando datos, encontrando y corrigiendo errores, y buscando fuentes de confirmación para datos en los que no confían.

• 60%: la fracción estimada de tiempo que los científicos de datos dedican a limpiar y organizar los datos.

El problema de los datos erróneos existe desde hace mucho tiempo. Las copias de datos divergen a medida que cambia su fuente original. Las copias se vuelven obsoletas. Los errores detectados en un conjunto de datos no se corrigen en los duplicados. El conocimiento del dominio relacionado con la interpretación y comprensión de los datos sigue siendo incompleto, al igual que el apoyo de los propietarios de los datos originales.

La malla de datos propone solucionar este problema convirtiendo los datos en ciudadanos de primera clase, un producto como cualquier otro. Un producto de datos con un esquema bien definido, documentación de dominio, mecanismos de acceso estandarizados y acuerdos de nivel de servicio puede reducir sustancialmente el impacto de los datos defectuosos justo en la fuente. Los consumidores, una vez acoplados al producto de datos, pueden cometer sus propios errores de lógica empresarial, lo cual es inevitable. Sin embargo, rara vez cometerán errores involuntarios por el mero hecho de intentar adquirir, comprender e interpretar los datos que necesitan para resolver sus problemas empresariales. La inacción no es una solución.

¿Podemos unificar los flujos de trabajo analíticos y operativos?

Hay un problema más que se sitúa en el corazón de la ingeniería: no es sólo el equipo de datos el que tiene estos problemas de acceso y calidad de los datos. Todas y cada una de las aplicaciones OLTP que necesitan datos almacenados en otra base de datos tienen los mismos problemas de acceso a los datos que el equipo de datos. ¿Cómo se accede a datos empresariales importantes, encerrados en otro servicio, por cuestiones operativas?

Ha habido varios intentos de permitir una mejor comunicación operativa entre servicios, como la arquitectura orientada a servicios, los buses de servicios empresariales y, por supuesto, los microservicios de petición-respuesta punto a punto. Pero en cada una de estas arquitecturas, los datos del servicio están encapsulados en su propia base de datos y fuera del alcance de otros servicios. En cierto modo, esto es bueno: el modelo interno está protegido y tienes una única fuente de verdad. Las aplicaciones proporcionan API operativas a las que otras aplicaciones pueden llamar para que hagan el trabajo en su nombre. Sin embargo, estas soluciones no resuelven la cuestión fundamental del acceso mayorista de sólo lectura a los conjuntos de datos definitivos para utilizarlos según sea necesario para sus propios casos de uso operativo.

Otra complicación es que hoy en día muchos casos de uso operativo dependen de resultados analíticos. Piensa en aprendizaje automático, motores de recomendación, IA, etc. Algunos casos de uso, como elaborar un informe mensual de los productos más vendidos, pueden etiquetarse claramente como "analíticos", que se derivan de un trabajo calculado periódicamente.

Otros casos de uso no son tan claros. Piensa en un minorista de comercio electrónico que quiere anunciar zapatos basándose en el inventario actual (operativo), las compras anteriores del usuario (analítico) y las intenciones estimadas en tiempo real de la sesión de compra del usuario (analítico y operativo). En la práctica, la frontera entre lo operativo y lo analítico rara vez está bien definida, y el mismo conjunto de datos puede ser necesario para multitud de fines: analíticos, operativos o intermedios.

Tanto la analítica de datos como los sistemas operativos convencionales tienen dificultades sustanciales para acceder a los datos contenidos en otras bases de datos. Estas dificultades se agravan aún más por el creciente volumen, velocidad y escala de los datos, mientras que los sistemas se ven obligados simultáneamente a escalar hacia fuera en lugar de hacia arriba, a medida que se alcanzan las limitaciones de computación de los servicios individuales. Las estrategias de comunicación de datos de la mayoría de las organizaciones se basan en la tecnología de ayer y no tienen en cuenta las ofertas de almacenamiento, computación y software como servicio (SaaS) modernos en la nube. Estas herramientas y tecnologías han cambiado la forma en que los datos pueden modelarse, almacenarse y comunicarse en toda una organización, lo que examinaremos con más detalle a lo largo del resto de este libro.

Repensar los datos con la Malla de Datos

La premisa de la solución de malla de datos es sencilla. Publica conjuntos de datos empresariales importantes en estructuras de datos dedicadas, duraderas y fácilmente accesibles, conocidas como productos de datos. Los creadores originales de los datos son responsables del modelado, la evolución, la calidad y el soporte de los datos, tratándolos con el mismo cuidado de primera clase que se da a cualquier otro producto de la organización.

Los posibles consumidores pueden explorar, descubrir y suscribirse a los productos de datos que necesitan para sus casos de uso empresarial. Los productos de datos deben estar bien descritos, ser fáciles de interpretar y constituir la base de un conjunto de primitivas de datos autoactualizables para potenciar tanto los servicios empresariales como la analítica.

Los flujos de eventos desempeñan el papel óptimo para la base de los productos de datos, porque ofrecen el sustrato inmutable, anexable, duradero y reproducible para todos los consumidores. Estos flujos se convierten en una fuente fundamental de verdad para las cargas de trabajo operativas, analíticas y de todo tipo en toda la organización.

Esta arquitectura se construye aprovechando la moderna computación en nube y el SaaS, como se explica con más detalle en el Capítulo 5. Una buena pila de ingeniería facilita la creación y gestión de las aplicaciones a lo largo de su ciclo de vida, incluyendo la adquisición de recursos informáticos, proporcionando escalabilidad, registro y capacidades de monitoreo. Los flujos de eventos proporcionan a la pila de ingeniería moderna el acceso formalizado y estandarizado a los datos que necesita para hacer las cosas.

Volvamos a los principios del monolito de datos de la anterior en este capítulo a través de la lente de esta propuesta. Estos tres principios esbozan las principales influencias para colocar nuevas funciones empresariales dentro de un monolito. ¿Cómo se relacionaría con estos principios un conjunto de flujos de eventos autoactualizables?

La base de datos es la fuente de la verdad → El flujo de eventos es la fuente de la verdad

El propietario del dominio de datos es ahora responsable de componer un modelo de cara al exterior y escribirlo como un conjunto de eventos en uno (o más) flujos de eventos. A cambio, otros servicios ya no pueden acceder directamente al modelo de datos interno ni acoplarse a él, y el productor ya no es responsable de servir tareas empresariales a medida en nombre del servicio que realiza la consulta, como suele ocurrir en una arquitectura de microservicios. El flujo de eventos se convierte en el principal punto de acoplamiento entre sistemas. Los servicios descendentes consumen eventos del flujo de eventos, los modelan para sus fines y los almacenan en sus propios almacenes de datos dedicados.

Los datos son fuertemente coherentes → Los datos son finalmente coherentes

El productor del flujo de eventos puede conservar una fuerte coherencia de lectura-después-escritura para su propio estado interno, junto con otras ventajas de la base de datos, como las transacciones ACID locales. Los consumidores del flujo de eventos, sin embargo, son independientes en su procesamiento de eventos y modelado de estado y, por tanto, dependen de su propia visión eventualmente consistente de los datos procesados. Un consumidor no tiene acceso de escritura al flujo de eventos, por lo que no puede modificar la fuente de datos. Los diseños de sistemas consumidores deben tener en cuenta la consistencia eventual, y exploraremos este tema con más detalle más adelante en este libro.

Los datos de sólo lectura están disponibles (¡no se modifican!)

Los flujos de eventos proporcionan el mecanismo formalizado para comunicar datos en un formato de sólo lectura y autoactualización, y los consumidores ya no necesitan crear, gestionar y mantener su propio mecanismo de extracción. Si una aplicación consumidora necesita conservar el estado, lo hace utilizando su propio almacén de datos dedicado, completamente independiente de la base de datos del productor.

La malla de datos formaliza los límites de propiedad de los datos dentro de una organizacióny normaliza los mecanismos de almacenamiento y comunicación. También proporciona un marco reutilizable para producir, consumir, modelar y utilizar datos, no sólo para los sistemas actuales, sino también para los que están por construir.

Objeciones comunes a una malla de datos basada en sucesos

Hay varias objeciones comunes que me he encontrado con frecuencia al hablar de una malla de datos basada en eventos . Aunque trataremos estas situaciones con más detalle a lo largo del libro, quiero sacarlas a colación ahora para reconocer que estas objeciones existen, pero que cada una de ellas es manejable.

Los productores no pueden modelar datos para los casos de uso de todo el mundo

En realidad, este argumento es cierto, aunque se equivoca de cabo a rabo. El principal deber del productor es proporcionar un modelo público externo preciso y fiable de los datos de su dominio para uso del consumidor. Estos modelos de datos sólo deben exponer las partes del dominio que otros equipos pueden acoplar; el resto de su modelo interno permanece fuera de los límites. Por ejemplo, un dominio de comercio electrónico tendría modelos de ventas, artículos e inventario y flujos de eventos independientes, que simplemente detallarían las propiedades y valores actuales de cada venta, artículo y nivel de inventario, mientras que una empresa de transporte puede tener flujos de eventos para cada envío, camión y conductor.

Estos modelos son deliberadamente sencillos y se centran en una única definición de dominio, lo que da lugar a bloques de construcción de datos ajustados y modulares que otros sistemas pueden utilizar para construir sus propios modelos de datos. Los consumidores que ingieren estos eventos pueden reestructurarlos según sea necesario, incluso unirlos con eventos de otros flujos o fusionarlos con estados existentes, para derivar un modelo que funcione para resolver sus casos de uso empresarial. Los consumidores también pueden dirigirse a los equipos de productores para solicitar que se añada información adicional al modelo público o aclaraciones sobre determinados campos y valores.

Dado que el equipo productor es el propietario del modelo de datos original, es el más cualificado para decidir qué aspectos del modelo deben exponerse y permitir que otros se acoplen a él. De hecho, no hay otro equipo más cualificado que el que realmente crea la fuente original de datos para definir lo que significa y cómo deben interpretar los demás lo que significan sus campos, relaciones y valores. Este enfoque permite a los propietarios de la fuente de datos abstraerse de sus complejidades internas, como su modelo relacional altamente normalizado o su almacén de documentos. Los cambios en el modelo interno de la fuente pueden ocultarse a los consumidores que, de otro modo, se habrían acoplado directamente a él, reduciendo así las roturas y los errores.

Hacer varias copias de los datos es malo

Esta objeción, irónicamente, se opone implícitamente al primer argumento. Aunque, al igual que el argumento anterior, tiene algo de verdad. Múltiples copias del mismo conjunto de datos pueden desincronizarse inadvertidamente, volverse obsoletas o proporcionar una fuente de datos que discrepe de la fuente original, y de hecho lo hacen. Sin embargo, nuestra propuesta no consiste en hacer que la copia de datos sea una batalla campal, sino en establecer un proceso formalizado y bien respaldado que establezca normas y responsabilidades claras, abrazando esta realidad en lugar de ocultarse de ella.

Hay tres subtipos principales de este argumento.

Sólo debe haber una única copia maestra de los datos, y todos los sistemas debenreferenciarla directamente

Esta creencia no tiene en cuenta el hecho de que los equipos de análisis de big data de todo el mundo ya han estado violando este principio desde los albores del movimiento big data (y en realidad, OLAP en general) porque sus necesidades no pueden satisfacerse con una única copia maestra, almacenada en una única base de datos en algún lugar. Tampoco tiene en cuenta las diversas necesidades de otros sistemas operativos, que siguen las mismas estrategias de adquisición de datos que traspasan los límites. Es sencillamente insostenible.

La insuficiencia del sistema fuente para modelar sus datos para todos los casos de uso empresarial es una de las principales razones por las que acabarán existiendo varias copias del mismo conjunto de datos. Un sistema puede necesitar soportar transacciones ACID en un modelo relacional, mientras que un segundo sistema debe soportar un almacén de documentos para geolocalización y búsqueda en texto plano. Un tercer consumidor puede necesitar escribir estos conjuntos de datos en HDFS, para aplicar un procesamiento al estilo MapReduce y obtener resultados de las 364 copias anteriores de esos datos que hizo, con referencias cruzadas a otros conjuntos de datos anuales. Todos ellos no pueden servirse desde una única base de datos central, si no sólo por el modelado, sí por la imposibilidad de un rendimiento satisfactorio para todos los casos de uso.

Es demasiado costoso computacionalmente crear, almacenar y actualizar variascopias de los mismos datos

Este argumento está hipercentrado en el hecho de que trasladar y almacenar datos cuesta dinero, y por tanto almacenar una copia de los mismos datos es un despilfarro (sin tener en cuenta factores como la remodelación y el rendimiento, por supuesto). Este argumento no tiene en cuenta la inexpensabilidad de la computación en nube, en particular los costes de almacenamiento y de red excepcionalmente baratos de los principales proveedores de nube actuales. Tampoco tiene en cuenta las horas de trabajo de los desarrolladores necesarias para construir y mantener canalizaciones ETL personalizadas, parte de las ineficiencias multimillonarias en la creación, búsqueda y uso de datos.

Optimizar para minimizar la transferencia de datos, el tamaño de la aplicación y el uso del disco ya no es tan importante como antes para la mayoría de las aplicaciones empresariales. En su lugar, la prioridad debe ser minimizar los esfuerzos de los desarrolladores para acceder a los bloques de construcción de datos, centrándose en la flexibilidad operativa.

Gestionar las políticas de seguridad de la información en todos los sistemas y conjuntos de datos distribuidos es demasiado difícil

Formalizar el acceso a los datos mediante productos de datos te permite aplicar controles de acceso a usuarios y servicios. La encriptación te permite proteger todos tus datos sensibles frente a consumidores no autorizados, de modo que sólo puedan leerlos quienes tengan permiso para ello.

La plataforma de autoservicio desempeña un papel importante en una arquitectura de malla de datos, ya que aplica todas las políticas de seguridad, controles de acceso y requisitos de encriptación. La adhesión a la infoseguridad se integra en los flujos de trabajo normales de los productores y consumidores de productos de datos, lo que facilita enormemente la imposición y auditoría del cumplimiento.

La coherencia final es demasiado difícil de gestionar

Los datos comunicados a través de flujos de eventos requieren que se tenga en cuenta y se planifique la coherencia final. Sin embargo, la queja de que la coherencia eventual es demasiado difícil de gestionar suele basarse en un malentendido del impacto que puede tener en los procesos empresariales en su conjunto. Podemos definir adecuadamente los límites de nuestro sistema para tener en cuenta la coherencia eventual entre sistemas, al tiempo que tenemos acceso a una coherencia sólida dentro de un sistema. No hay vuelta de hoja: si un determinado proceso empresarial necesita una coherencia perfecta, la creación y el uso de los datos deben estar dentro del mismo límite de servicio. Pero la mayoría de los procesos empresariales no la necesitan, y para los que sí, nada de lo que proponemos en este libro te impide obtenerla. En el Capítulo 10 trataremos con más detalle cómo gestionar la coherencia eventual de .

Resumen

Las estrategias existentes de comunicación de datos se quedan cortas ante los requisitos empresariales reales. Romper los límites de un servicio metiendo la mano para hacerse con sus datos no es una prácticasostenible, pero es extremadamente común y a menudo soporta múltiples sistemas críticos y flujos de trabajo analíticos. Reestructurar tus sistemas en pulcros microservicios modulares no resuelve el problema del acceso a los datos; otras partes de tu empresa, como los equipos de análisis de big data y aprendizaje automático, seguirán necesitando acceso mayoritario a los datos actuales e históricos de dominios de toda la organización. De un modo u otro , se crearán copias de datos, y podemos luchar contra ello o aceptar este hecho y trabajar para mejorarlo. Si optamos por esto último, podemos utilizar flujos de eventos para estandarizar y simplificar la comunicación de datos en toda la organización como fuentes de verdad únicas y autoactualizables.

Los eventos constituyen la base de la comunicación en las arquitecturas basadas en eventos y conforman fundamentalmente el espacio en el que resolvemos nuestros problemas. Los eventos, suministrados a través de flujos de eventos, forman los bloques de construcción para construir sistemas asíncronos y reactivos. Estos bloques de construcción son primitivas similares a las API síncronas: otras aplicaciones pueden descubrirlas, acoplarse a ellas y utilizarlas para construir sus propios servicios. La consistencia eventual, los modelos específicos del consumidor, las réplicas de sólo lectura y las materializaciones de flujos son sólo algunos de los conceptos que exploraremos en este libro, junto con las funciones que tienen los modernos recursos de computación, almacenamiento y redes en la nube en esta nueva arquitectura de datos.

Los capítulos siguientes profundizarán en la construcción y el uso de una malla de datos basada en eventos. Exploraremos cómo diseñar eventos, incluidos eventos de estado, acción y notificación, así como patrones para producirlos y consumirlos. Este libro cubre el manejo de eventos a escala, incluyendo multiclúster y multirregión, buenas prácticas para la privacidad y el cumplimiento normativo, así como principios para manejar la coherencia eventual y la comunicación asíncrona. Exploraremos los cambios sociales y culturales necesarios para dar cabida a una malla de datos basada en eventos y veremos algunos casos prácticos del mundo real que destacan los éxitos y las lecciones aprendidas por otros.

Por último, también veremos los pasos prácticos que puedes dar para empezar a construir hacia esto en tu propia organización. Una de las mejores cosas de esta arquitectura es que es modular e incremental, y puedes empezar a aprovechar las ventajas en un sector de tu empresa cada vez. Aunque hay algunas inversiones iniciales, la computación en nube moderna y las soluciones SaaS han eliminado prácticamente las barreras de entrada, lo que facilita mucho empezar y probar si es la solución adecuada para ti.