Arquitectura big data: lagos, lakehouses, formatos y procesamiento

Pocas áreas del software han sufrido tanto el vocabulario de los fabricantes como las plataformas de datos. El término «big data» se acuñó para describir un problema real —conjuntos de datos que ninguna máquina por sí sola podía almacenar ni procesar en un tiempo aceptable— y después se aplicó a casi todo, con el resultado de que muchas organizaciones mantienen clústeres distribuidos sobre datos que cabrían en un portátil.

Esta guía se toma en serio las decisiones de arquitectura y con escepticismo el discurso de marketing. Trata de cómo llegan los datos, dónde se almacenan, en qué formato, quién puede modificarlos y cómo se procesan, además de la sección que casi todas las guías de este tipo omiten: cómo saber que no necesitas nada de esto. El detalle interno de HDFS, YARN y Spark está en la guía del ecosistema Hadoop; aquí lo que interesa es la forma de la plataforma.

Las tres V, a examen

Volumen, velocidad y variedad son una lista de comprobación útil y un mal procedimiento de decisión. Cada una merece una pregunta más exigente.

Volumen. La cifra relevante no es cuántos datos existen, sino cuántos toca una consulta. Un histórico de eventos de cien terabytes que se consulta un día cada vez es un problema de cien gigabytes con un buen particionado. La compresión y el almacenamiento columnar reducen habitualmente en un orden de magnitud los bytes escaneados antes de que intervenga ningún motor distribuido.

Velocidad. Pregúntate cuál es la latencia de decisión, no la de llegada. Que los eventos lleguen de forma continua no exige cálculo en streaming si nadie actúa sobre el resultado antes de la mañana siguiente. Los requisitos reales de streaming —scoring antifraude, precios dinámicos, alertas operativas— son aquellos en los que una respuesta tardía vale menos que una rápida y aproximada.

Variedad. Es la V que mejor ha resistido. Las bases de datos relacionales sufren cuando el esquema cambia de una fuente a otra y se modifica sin previo aviso, y eso sí justifica un lago con schema-on-read.

A menudo se añade una cuarta V, la veracidad, que importa más que las tres primeras. Un pipeline que entrega cien terabytes de cifras sutilmente erróneas es peor que uno que no entrega nada, porque la gente toma decisiones con ellas.

Lago, warehouse, lakehouse

Un data warehouse almacena datos depurados, modelados y tipados, optimizados para SQL analítico. Los datos se transforman al entrar, el esquema se impone y el rendimiento de las consultas es excelente porque la disposición física se diseñó pensando en las preguntas. El precio es la rigidez: una fuente nueva requiere trabajo de modelado antes de que nadie pueda usarla, y los datos que el modelo rechaza simplemente se pierden. El modelado dimensional para warehouses se trata en la guía de business intelligence.

Un data lake guarda ficheros en almacenamiento de objetos —S3, Azure Blob, Google Cloud Storage— tal como llegaron, y aplica el esquema en el momento de la lectura. Es barato, lo acepta todo y conserva los datos brutos para preguntas que nadie ha hecho todavía. Su modo de fallo tiene nombre: el data swamp, un bucket de ficheros sin documentar, sin propietario, sin historial de esquema y sin forma de saber qué copia es la vigente. Los lagos fracasan por motivos de gobierno, no técnicos.

Un lakehouse mantiene los ficheros en formatos abiertos sobre almacenamiento de objetos, pero añade una capa de metadatos que aporta transacciones ACID, evolución de esquema, time travel y una poda de ficheros eficiente. Esa capa es un formato de tabla abierto: Apache Iceberg, Delta Lake o Apache Hudi. El resultado se comporta como una tabla —puedes hacer UPDATE, DELETE y MERGE, y volver atrás— sin dejar de ser legible por cualquier motor que entienda el formato.

Una estructura por capas habitual y sensata, la llames como la llames:

raw / bronze     immutable landing zone, source format, partitioned by ingest date
curated / silver cleaned, deduplicated, typed, conformed to a common schema
serving / gold   aggregated, modelled tables for dashboards, APIs and data science

Cada capa se puede reconstruir a partir de la anterior, y eso es lo que hace posible reprocesar tras un bug.

Formatos de almacenamiento y disposición física

La elección del formato influye más en el coste y la velocidad que el motor de procesamiento.

Los formatos columnares ganan en analítica por tres motivos que se suman. Una consulta que lee tres de ochenta columnas solo lee esas tres. Los valores de una misma columna se parecen, así que la compresión es muchísimo mejor que por filas. Y las estadísticas por row group permiten al lector saltarse bloques enteros cuyo rango min/max no puede cumplir el predicado. En conjunto, convierten un escaneo completo en una fracción de la E/S.

El particionado es una poda a nivel de directorio: escribir dt=2026-09-07/region=eu permite que una consulta que filtra por esas columnas se salte todo lo demás. Dos reglas lo mantienen útil. Particiona por columnas que aparezcan en casi todos los filtros, normalmente una fecha. Y mantén una cardinalidad baja: particionar por id de cliente genera millones de directorios y un problema de metadatos mucho peor que el escaneo que te has ahorrado.

El tamaño de los ficheros es la otra mitad. Apunta a ficheros de unos cientos de megabytes. Los procesos de escritura en streaming producen de forma natural muchísimos ficheros diminutos, así que programa una compactación; todos los formatos de tabla ofrecen una operación de mantenimiento para ello. Dentro de un fichero, ordenar por una columna que se filtre a menudo hace que las estadísticas de los row groups sean mucho más selectivas, con el mismo razonamiento que el clustering en un motor relacional, tratado en la guía de índices y planes de ejecución.

Los formatos de tabla abiertos aportan lo que los simples directorios no pueden: commits atómicos, para que un lector nunca vea una actualización a medio escribir; aislamiento por snapshot y time travel, para consultar la tabla tal como estaba ayer o deshacer una carga fallida; particionado oculto, para que las consultas no tengan que mencionar la columna de partición; y evolución de esquema por id de columna en lugar de por posición, para que renombrar una columna no corrompa los ficheros antiguos.

Ingesta

Las fuentes se reducen a unas pocas formas recurrentes.

Extracciones batch: volcados nocturnos, ficheros de proveedores, llamadas a APIs. Son simples, se entienden bien y son la respuesta correcta mucho más a menudo de lo que se admite. Prefiere la extracción incremental sobre una columna de watermark a releerlo todo.

La captura de cambios de datos (CDC) lee el log de transacciones de una base de datos y emite un flujo de inserciones, actualizaciones y borrados. Es la forma menos intrusiva de replicar una base operativa en la plataforma: sin consultas contra el origen, sin ventana batch y con el orden que proporciona el log. También es donde aparecen la mayoría de los problemas de corrección, sobre todo en torno a los cambios de esquema y los borrados.

Flujos de eventos. Un broker basado en log ofrece un búfer duradero, ordenado y con capacidad de replay entre productores y consumidores, y desacopla su disponibilidad y su velocidad. Esa capacidad de replay es lo que hace posible el reprocesamiento; consulta la arquitectura de Kafka para ver cómo funcionan las particiones, los offsets y la retención.

Sea cual sea la fuente, deposita el payload bruto sin modificarlo antes de transformarlo. El almacenamiento es barato; un bug de transformación irrecuperable, no.

La distinción ETL frente a ELT también tiene su sitio aquí. El ETL tradicional transforma antes de cargar, de modo que el warehouse solo contiene datos modelados. El ELT carga en bruto y transforma con la capacidad de cómputo del propio motor de destino, lo que sale más barato, conserva la copia bruta y convierte las transformaciones en SQL bajo control de versiones. El ELT es la opción moderna por defecto allí donde la capa de almacenamiento es barata y el motor es elástico.

Procesamiento

El procesamiento batch recalcula sobre un conjunto de datos acotado. Apache Spark domina este terreno; Trino y Presto cubren el SQL federado interactivo, y los motores de warehouse en la nube, el resto. El batch es más fácil de entender, sencillo de relanzar y correcto por construcción, porque la entrada no se mueve mientras trabajas.

El procesamiento en streaming calcula de forma continua sobre una entrada no acotada e introduce tres conceptos que el batch nunca necesita:

• Tiempo de evento frente a tiempo de procesamiento. Los eventos llegan tarde y desordenados. Los resultados por ventanas deben basarse en cuándo ocurrió algo, no en cuándo se recibió.
• Watermarks. Un watermark es la afirmación del motor de que ya no se espera ningún evento anterior a una marca de tiempo dada, y es lo que permite que una ventana se cierre y emita su resultado.
• Estado y exactly-once. Las agregaciones mantienen un estado que debe sobrevivir a los fallos, y los sinks deben ser idempotentes o transaccionales para que los resultados no se dupliquen en los reintentos.

Apache Flink es la implementación de referencia para streaming con estado y baja latencia; Spark Structured Streaming ofrece el mismo modelo de programación que su API batch, con ejecución en micro-batch o continua, algo que a menudo resulta decisivo para los equipos que ya usan Spark. Kafka Streams encaja con transformaciones que viven dentro de un servicio y no en un clúster.

La arquitectura lambda ejecutaba una capa batch para la corrección junto a una capa rápida para la frescura, y las fusionaba en el momento de la consulta. Funciona, pero a costa de duplicar la lógica de negocio en dos bases de código con dos conjuntos de bugs. La arquitectura kappa mantiene un único camino de streaming y reprocesa el histórico reproduciendo el log retenido, algo viable precisamente porque los brokers y los formatos de tabla modernos admiten replay y escrituras idempotentes. Empieza con kappa si de verdad necesitas streaming; empieza con batch a secas si no.

Gobierno, calidad y coste

El trabajo de plataforma que decide si alguien se fía de los datos es poco vistoso e imprescindible.

• Un catálogo —Apache Hive Metastore, catálogos REST de Iceberg o un equivalente en la nube— registra qué tablas existen, sus esquemas y sus ubicaciones. Sin él, el descubrimiento consiste en preguntar a los compañeros.
• El linaje registra qué job produjo qué tabla a partir de qué entradas. Cuando una cifra parece incorrecta, el linaje marca la diferencia entre una hora y una semana.
• Los contratos de datos convierten el esquema que publica un productor en un acuerdo explícito, versionado y con tests, de modo que un cambio aguas arriba rompa un build y no un dashboard.
• Los controles de calidad se ejecutan como parte del pipeline: recuentos de filas dentro de los límites esperados, tasas de nulos, comprobaciones referenciales, umbrales de frescura. Haz que el job falle de forma ruidosa antes que publicar datos erróneos en silencio.
• Privacidad y retención. Los datos personales en un lago siguen siendo datos personales. Debes saber dónde están, cifrarlos, restringir el acceso y poder borrarlos, un requisito que los simples ficheros no pueden cumplir y los formatos de tabla sí.
• Coste. En el almacenamiento de objetos en la nube, la factura depende de los bytes escaneados y de las peticiones realizadas, así que la poda de particiones, el tamaño de los ficheros y la proyección de columnas son palancas de coste tanto como de rendimiento. Define reglas de ciclo de vida que muevan las particiones frías a niveles de almacenamiento más baratos.

Cuándo no necesitas nada de esto

Debes estar dispuesto a concluir que una plataforma distribuida es la respuesta equivocada.

• Una sola instancia de PostgreSQL maneja cientos de gigabytes de datos analíticos con particionado y una buena indexación, como describe la guía de buenas prácticas SQL.
• Un motor columnar de un solo nodo lee directamente ficheros Parquet y supera a un clúster Spark pequeño con conjuntos de datos de hasta cientos de gigabytes, sin ningún clúster que operar.
• Los logs y los datos de observabilidad tienen su sitio en una plataforma específica, no en un lago genérico; consulta la gestión centralizada de logs.
• Si el requisito es «el negocio quiere dashboards», la respuesta puede ser un warehouse y una herramienta de BI, sin ningún lago.

Las razones de más peso para construir una plataforma de datos de verdad son que los datos provengan de muchos sistemas con modelos incompatibles, que los consumidores sean numerosos y variados, o que los volúmenes superen realmente a una sola máquina. Sin ellas, la complejidad no aporta nada y cuesta un equipo.

Conclusiones clave

• Mide el volumen por los bytes escaneados por consulta, la velocidad por la latencia de decisión, y añade la veracidad a la lista: datos erróneos a gran escala son peores que no tener datos.
• Los warehouses ofrecen esquema y velocidad sobre datos depurados, los lagos almacenamiento barato y flexible, y los lakehouses usan formatos de tabla abiertos para combinar transacciones y control de esquema con la economía del almacenamiento de objetos.
• Los formatos columnares con poda de particiones, tamaños de fichero razonables y row groups ordenados aportan más rendimiento que cualquier cambio de motor de procesamiento.
• Deposita los datos brutos sin modificarlos, organiza las transformaciones en capas para que cada etapa sea reproducible y prefiere ELT con transformaciones bajo control de versiones.
• Elige streaming solo cuando una decisión dependa de ello, y prefiere un único camino con replay a mantener copias batch y streaming de la misma lógica.
• Catálogo, linaje, contratos de datos, controles de calidad y reglas de retención son lo que hace fiable una plataforma; sin ellos, un lago se convierte en una ciénaga.