Analítica, streaming, almacenes de datos, lagos de datos y data mesh

Dos cargas de trabajo distintas: OLTP y OLAP

Todo lo visto hasta ahora en este capítulo ha tratado del procesamiento de transacciones en línea (OLTP): muchas lecturas y escrituras pequeñas y rápidas de registros individuales, como hacer un pedido, registrar un pago o actualizar la posición de un repartidor. La analítica hace otro tipo de preguntas. ¿Cuáles fueron los ingresos por tipo de cocina y región, semana a semana, durante los dos últimos años? afecta a millones de filas, lee solo unas pocas columnas de cada una y no cambia nada. Esto es el procesamiento analítico en línea (OLAP), y es tan distinto del OLTP que ejecutar ambos en la misma base de datos no suele servir bien a ninguno: una sola consulta analítica grande puede saturar los discos y la caché de búfer de los que depende el proceso de pago, y el esquema normalizado que mantiene correctas las transacciones obliga a los analistas a unir una docena de tablas.

La respuesta arquitectónica estándar es separar las cargas de trabajo. Los sistemas operacionales mantienen sus propias bases de datos, de las que son propietarios sus servicios, como se describió en la Sección 7.1. Los datos se copian, de forma continua o periódica, a una plataforma analítica diseñada para recorridos completos: almacenamiento columnar que lee solo las columnas necesarias, compresión intensa, motores de consulta masivamente paralelos y esquemas con la forma adecuada para el análisis. El resto de esta sección trata de cómo se diseña esa plataforma, cómo llegan a ella los datos, cómo cambia el panorama el streaming y quién es el propietario del resultado.

Almacenes de datos y modelado dimensional

Un almacén de datos (data warehouse) es una base de datos construida para el análisis que integra datos depurados de muchos sistemas operacionales y conserva su historial. Dos escuelas han marcado cómo se diseñan los almacenes de datos, y los profesionales aún discuten sobre ellas. Bill Inmon, a menudo llamado el padre del almacén de datos (Building the Data Warehouse, 1992), defiende un diseño descendente: primero se construye un almacén de datos normalizado, integrado y de alcance empresarial como fuente única de verdad, y después se derivan de él los data marts departamentales. Ralph Kimball (The Data Warehouse Toolkit, publicado por primera vez en 1996, tercera edición con Margy Ross en 2013) defiende un diseño ascendente: construir modelos dimensionales de un proceso de negocio cada vez e integrarlos mediante dimensiones conformadas compartidas (una única definición acordada de cliente, fecha o restaurante que usan todos los modelos). El enfoque de Inmon ofrece una integración más sólida con un costo inicial mayor; el de Kimball da resultados utilizables antes, pero exige disciplina para mantener las dimensiones conformadas. Muchas plataformas modernas combinan ambos: una capa depurada e integrada que alimenta modelos dimensionales para su consumo.

El esquema en estrella de Kimball sigue siendo el modelo analítico que más se enseña. Una tabla de hechos central registra eventos de negocio con un grano (grain) declarado (una fila por línea de pedido, por pago, por ping del repartidor), con medidas numéricas como la cantidad, el importe y los minutos, y claves foráneas a tablas de dimensiones. Cada dimensión contiene atributos descriptivos que se usan para filtrar y agrupar: fechas (con indicadores precalculados de día de la semana, mes y día festivo), restaurantes (nombre, tipo de cocina, ciudad), clientes y platos. Las consultas pasan a ser una tabla de hechos unida a unas pocas dimensiones pequeñas, algo que los motores columnares ejecutan con mucha eficiencia. Los atributos que cambian con el tiempo, como un restaurante que se traslada de ciudad, se gestionan con técnicas de dimensión de cambio lento (slowly changing dimension); la más común, el tipo 2, añade una fila de dimensión nueva con fechas de validez, de modo que los hechos históricos siguen apuntando a los atributos que eran ciertos en su momento.

-- Revenue and average delivery time by cuisine and weekday for last quarter.
-- One join per dimension; the fact table is scanned, never updated.
SELECT r.cuisine,
       d.weekday,
       SUM(f.line_total_pence) / 100.0 AS revenue_gbp,
       AVG(f.delivery_minutes)          AS avg_delivery_min
FROM   fact_order_line f
JOIN   dim_date       d ON d.date_key       = f.date_key
JOIN   dim_restaurant r ON r.restaurant_key = f.restaurant_key
WHERE  d.quarter = '2026-Q2'
  AND  r.region  = 'North West'
GROUP  BY r.cuisine, d.weekday
ORDER  BY revenue_gbp DESC;
-- Caveat: delivery_minutes is per order, so averaging it over order LINES
-- weights big orders more. Grain decisions matter (see the worked example).

Cómo entran los datos: ETL, ELT y captura de datos de cambios

Los datos llegan al almacén de datos mediante pipelines. En el ETL clásico (extraer, transformar, cargar), una herramienta independiente extrae los datos de los sistemas de origen, los depura y les da forma en sus propios servidores, y carga solo el resultado. Desde que los almacenes de datos en la nube abarataron el almacenamiento y volvieron elástico el cómputo, el ELT se ha vuelto habitual: extraer y cargar primero los datos en bruto y después transformarlos dentro del almacén con SQL, a menudo gestionados como modelos versionados y probados con una herramienta como dbt. El ELT conserva los datos en bruto, así que las transformaciones pueden corregirse y volver a ejecutarse; su riesgo es que los datos personales en bruto se extiendan más de lo necesario.

Cómo se extraen los datos importa igual. Las copias completas nocturnas son sencillas, pero lentas y desactualizadas. La captura de datos de cambios (CDC) lee el propio log de replicación de la base de datos (el registro de escritura anticipada de PostgreSQL, el binlog de MySQL) con una herramienta como Debezium y transmite cada inserción, actualización y borrado como un evento, con baja latencia y poca carga en el origen. Sea cual sea el mecanismo, leer directamente las tablas de otro servicio acopla la plataforma de analítica al esquema privado de ese servicio, exactamente el problema que describió la Sección 7.1. El patrón más robusto es que cada servicio publique los datos deliberadamente, mediante eventos o una exportación acordada, bajo un contrato de datos.

Data lakes, lakehouses y formatos de tabla abiertos

Un data lake (lago de datos) (el término se atribuye a James Dixon, 2010) almacena datos en bruto de muchas fuentes en su forma original, normalmente como archivos en un almacenamiento de objetos barato como Amazon S3, a menudo en formatos columnares como Apache Parquet. Aplaza el esquema hasta que se leen los datos, lo que conviene a los científicos de datos que quieren el detalle en bruto y a los datos cuyo uso aún no se conoce. Los lagos se ganaron la fama de convertirse en pantanos de datos (data swamps): sin propietarios, documentación ni comprobaciones de calidad, nadie se fía de lo que contienen. Los archivos en almacenamiento de objetos también carecen de lo que ofrece un almacén de datos: transacciones, actualizaciones y borrados, imposición del esquema y lecturas consistentes mientras se escriben los datos.

El lakehouse (Armbrust, Ghodsi, Xin y Zaharia, CIDR 2021) añade esas funciones de almacén de datos sobre archivos abiertos en el lago. La tecnología que lo hace posible es el formato de tabla abierto: Delta Lake (creado en Databricks), Apache Iceberg (creado en Netflix) y Apache Hudi (creado en Uber). Cada uno mantiene una capa de metadatos (un log de transacciones o un árbol de archivos de manifiesto) que registra qué archivos de datos forman cada versión de una tabla. Eso aporta confirmaciones atómicas, escritores concurrentes con concurrencia optimista, evolución de esquemas, actualizaciones y borrados a nivel de fila (necesarios para las solicitudes de supresión) y viaje en el tiempo (time travel): consultar una tabla tal como era en una versión anterior. Como el formato es abierto, varios motores (Spark, Trino, Flink y, cada vez más, los propios almacenes de datos en la nube) pueden leer y escribir las mismas tablas, lo que reduce la dependencia del proveedor (lock-in). Muchos lakehouses organizan los datos en capas, lo que Databricks popularizó como arquitectura medallón (medallion): bronce para los datos en bruto ingeridos, plata para los datos depurados y conformados, y oro para los modelos a nivel de negocio, como los esquemas en estrella.

Procesamiento de flujos: tiempo del evento, ventanas y marcas de agua

Los pipelines por lotes responden a preguntas sobre ayer. Algunas preguntas no pueden esperar: ¿se está usando esta tarjeta de forma fraudulenta ahora mismo?, ¿llegan tarde esta noche los repartidores de Manchester?, ¿qué restaurantes deberían pausarse porque sus cocinas están desbordadas? Los procesadores de flujos como Apache Flink, Kafka Streams y Spark Structured Streaming calculan de forma continua sobre flujos de eventos no acotados. Los conceptos esenciales proceden del modelo Dataflow de Google (Akidau y colegas, VLDB 2015).

El primero es la diferencia entre el tiempo del evento, cuando algo ocurrió realmente, y el tiempo de procesamiento, cuando el sistema lo observa. Difieren por los retrasos de red, los reintentos, el procesamiento por lotes y los dispositivos que se quedan sin conexión: el teléfono de un repartidor dentro de un ascensor registra una entrega a las 19:03, pero envía el evento a las 19:13. Cualquier resultado que deba reflejar la realidad (pedidos cada cinco minutos, tiempo medio de entrega por hora) debe calcularse por tiempo del evento, o se desplazará cada vez que el pipeline vaya lento y será incorrecto cuando se reproduzca.

El segundo son las ventanas, que cortan un flujo no acotado en trozos finitos para agregarlos: las ventanas fijas (tumbling) tienen un tamaño fijo y no se solapan (cada cinco minutos), las ventanas deslizantes (sliding) se solapan (los últimos diez minutos, actualizados cada minuto) y las ventanas de sesión agrupan ráfagas de actividad por clave separadas por un intervalo de inactividad (la sesión de navegación de un cliente).

El tercero es la marca de agua (watermark): la estimación móvil del procesador de que probablemente ya han llegado todos los eventos hasta un tiempo del evento dado. Cuando la marca de agua pasa el final de una ventana, puede emitirse el resultado de esa ventana. Las marcas de agua son heurísticas, así que algunos eventos llegan aun así después de que su ventana se haya cerrado. El pipeline necesita una política explícita para esos datos tardíos: descartarlos, enviarlos a una salida lateral (side output) para corregirlos más tarde, o mantener las ventanas abiertas durante un retraso permitido (allowed lateness) y emitir resultados actualizados. Esperar más da respuestas más completas; emitir antes da respuestas más frescas. Ese compromiso entre latencia y completitud es la versión del procesamiento de flujos de un compromiso entre atributos de calidad y debe decidirse con el negocio.

Las arquitecturas Lambda y Kappa

¿Cómo deben combinarse los resultados por lotes y los de streaming? El ensayo de Nathan Marz de 2011 How to beat the CAP theorem describió lo que pasó a conocerse como la arquitectura Lambda: un conjunto de datos maestro inmutable alimenta una capa de lotes (batch layer), que recalcula periódicamente vistas exactas a partir de todos los datos, y una capa rápida (speed layer), que calcula en tiempo real vistas aproximadas de los datos recientes; las consultas combinan ambas, y cada ejecución por lotes sustituye las aproximaciones de la capa rápida. Lambda ofrece exactitud y baja latencia, y la capa de lotes actúa como red de seguridad ante los bugs del streaming. Su costo es que la misma lógica debe escribirse, y mantenerse idéntica, en dos frameworks distintos.

En 2014, Jay Kreps, uno de los creadores de Apache Kafka, cuestionó este diseño y propuso la arquitectura Kappa, un nombre que ofreció medio en broma. Usar solo un procesador de flujos y conservar la entrada en un log durante el tiempo suficiente para reproducirla. Para cambiar la lógica, se inicia una segunda instancia del trabajo nuevo que lee desde el principio del log y escribe en una tabla de salida nueva, y se pasan los lectores a ella cuando se ha puesto al día. Una sola base de código, y reprocesar es simplemente reproducir. Kappa depende de una retención larga del log y de procesadores de flujos lo bastante buenos como para gestionar correctamente el tiempo del evento y el estado, algo que ofrecen los motores modernos. Hoy, la mayoría de los diseños nuevos se inclinan por un streaming al estilo Kappa con un lakehouse para el historial, mientras que los diseños al estilo Lambda persisten donde recalcular por lotes historiales muy largos es más barato o donde se confía en pipelines por lotes existentes.

Data mesh: la propiedad de los datos analíticos

A medida que las organizaciones crecían, los equipos de datos centrales se convirtieron en cuellos de botella: cada fuente nueva y cada pregunta nueva hacían cola detrás de un equipo que no entendía muy bien ni los sistemas de origen ni las preguntas del negocio. En 2019, Zhamak Dehghani, entonces en Thoughtworks, propuso el data mesh (ampliado después en su libro de 2022 Data Mesh). Aplica a los datos analíticos la misma descentralización que los microservicios aplicaron a los sistemas operacionales, y se basa en cuatro principios.

Propiedad por dominio: los equipos más cercanos a los datos, como los de pedidos, pagos o repartidores, son propietarios de sus datos analíticos y los sirven, igual que son propietarios de sus servicios. Los datos como producto: cada equipo publica productos de datos que se pueden descubrir y direccionar, y que están documentados, son fiables y son seguros, con un propietario y objetivos de calidad, y trata a los demás equipos como clientes. Plataforma de datos de autoservicio: un equipo de plataforma proporciona el almacenamiento, los pipelines, el catálogo y el control de acceso que abaratan la publicación de un producto de datos, para que cada dominio no tenga que reinventarlos. Gobernanza computacional federada: las reglas globales (identificadores, clasificaciones de privacidad, estándares de interoperabilidad) se acuerdan conjuntamente y la plataforma las aplica automáticamente, en lugar de un comité de revisión central.

El data mesh es tanto un diseño organizativo como una arquitectura, y las opiniones difieren sobre cuándo compensa. Sus defensores señalan la escala: elimina el cuello de botella central y pone la calidad de los datos donde está el conocimiento. Sus críticos señalan que necesita equipos de dominio maduros, una plataforma sólida y una inversión real, y que a las organizaciones más pequeñas suele servirles mejor una plataforma central bien gestionada con una propiedad clara de cada conjunto de datos. La ley de Conway (Sección 3.7) se aplica directamente: la arquitectura de datos reflejará la estructura que la organización adopte realmente.

Calidad, linaje, catálogos y privacidad

Los datos analíticos solo son útiles si la gente confía en ellos. Las comprobaciones de calidad de los datos se ejecutan dentro de los pipelines y prueban la frescura (¿llegó la carga de hoy?), el volumen (¿se redujo a la mitad el número de filas?), el esquema (¿cambió de tipo una columna?), la validez (¿son positivos los importes y están bien formados los códigos postales?) y la unicidad. Las comprobaciones que fallan deben detener un pipeline o poner los datos en cuarentena, en lugar de publicarlos sin avisar. El linaje de datos registra de dónde procede cada conjunto de datos y qué transformaciones lo produjeron, de modo que, cuando una cifra parece errónea o cambia un esquema de origen, puedes rastrear el impacto aguas arriba y aguas abajo; la especificación OpenLineage estandariza cómo lo comunican los pipelines. Un catálogo de datos hace que los conjuntos de datos se puedan descubrir, con descripciones, propietarios, clasificaciones y linaje en un solo lugar.

Las plataformas de analítica concentran datos, lo que las hace atractivas para los atacantes y arriesgadas según la legislación de protección de datos. Aplica la minimización de datos (no copies campos personales que ningún análisis necesite), seudonimiza los identificadores siempre que sea posible, clasifica las columnas para que las políticas de acceso sigan a los datos, impón los periodos de conservación con borrado automatizado y asegúrate de que las solicitudes de supresión lleguen al lago y al almacén de datos además de a los sistemas operacionales; los formatos de tabla abiertos ayudan porque admiten borrados a nivel de fila. La Sección 8.7 trata las obligaciones en detalle.