Cuando los datos crecen hasta el punto de que ya no caben ni se procesan en una sola máquina, hablamos de Big Data. No es solo una cuestión de tamaño: el reto se resume clásicamente en las cinco uves —volumen, velocidad, variedad, veracidad y valor— y obliga a repensar cómo se almacena, se procesa y se gobierna la información. Este artículo recorre los paradigmas de procesamiento distribuido (de MapReduce a Spark), las arquitecturas de almacenamiento (data lake, data warehouse y lakehouse), el procesamiento por lotes frente al de flujo, y las obligaciones de gobierno y protección de datos que ningún proyecto serio puede ignorar.
Las cinco uves del Big Data
El volumen es la dimensión obvia: terabytes o petabytes que exceden la capacidad de un servidor convencional. La velocidad se refiere al ritmo de generación e ingesta —sensores de IoT, clics, transacciones— que a menudo exige procesar en tiempo casi real. La variedad abarca datos estructurados (tablas), semiestructurados (JSON, logs) y no estructurados (texto, imágenes, vídeo). La veracidad apunta a la calidad y fiabilidad: datos sucios producen conclusiones falsas con apariencia de rigor. Y el valor es la prueba del algodón: ningún dato vale por sí mismo, solo por la decisión que permite tomar. Diseñar pensando en las cinco uves a la vez evita el error de optimizar el volumen y descuidar la calidad.
Del paradigma MapReduce a Apache Spark
El procesamiento distribuido nació con MapReduce, el modelo popularizado por Hadoop: una fase map que transforma y filtra datos en paralelo a través de muchos nodos, y una fase reduce que agrega los resultados. Su fortaleza es la tolerancia a fallos sobre hardware barato; su debilidad, la lentitud, porque escribe en disco entre cada etapa. El almacenamiento subyacente, HDFS (Hadoop Distributed File System), reparte y replica los bloques de datos para sobrevivir a la caída de nodos individuales.
Apache Spark desplazó a MapReduce al procesar en memoria, lo que lo hace órdenes de magnitud más rápido en cargas iterativas como el entrenamiento de modelos. Spark ofrece una API unificada para SQL (DataFrames), procesamiento de flujo (Structured Streaming), grafos y aprendizaje automático (MLlib), de modo que un mismo motor cubre todo el ciclo analítico. Su modelo de ejecución perezosa (lazy evaluation) construye un grafo de operaciones y lo optimiza antes de ejecutar, evitando trabajo innecesario.
Dónde guardar los datos: lake, warehouse y lakehouse
El data warehouse almacena datos estructurados, limpios y modelados para consultas analíticas rápidas; sigue el esquema en escritura (schema-on-write) y es ideal para informes de negocio. El data lake guarda datos en bruto de cualquier formato a bajo coste, aplicando el esquema en lectura (schema-on-read); ofrece flexibilidad pero, sin gobierno, degenera en un data swamp (pantano de datos) donde nadie encuentra ni confía en nada.
La arquitectura lakehouse, dominante en 2026, combina lo mejor de ambos: la flexibilidad y el bajo coste del lake con las garantías transaccionales y el rendimiento del warehouse, gracias a formatos de tabla abiertos como Delta Lake, Apache Iceberg o Hudi. Estos formatos aportan transacciones ACID, control de versiones (time travel) y evolución de esquema sobre archivos en almacenamiento de objetos, lo que elimina la duplicación de datos entre lake y warehouse.
Tabla comparativa de arquitecturas de almacenamiento
| Criterio | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Tipo de datos | Estructurados | Cualquiera | Cualquiera |
| Esquema | En escritura | En lectura | Flexible + transaccional |
| Coste de almacenamiento | Alto | Bajo | Bajo |
| Transacciones ACID | Sí | No | Sí |
| Idóneo para | Informes de negocio | Datos en bruto, ML | BI y ML unificados |
Procesamiento por lotes y en tiempo real
Existen dos modos fundamentales de procesar. El procesamiento por lotes (batch) opera sobre conjuntos de datos completos en intervalos programados; es eficiente y sencillo para informes diarios o cargas históricas. El procesamiento de flujo (streaming) analiza los eventos según llegan, con latencia de segundos o milisegundos, imprescindible para detección de fraude, alertas o personalización en vivo. Herramientas como Apache Kafka actúan como columna vertebral de ingesta de eventos, y motores como Apache Flink o el propio Structured Streaming de Spark consumen esos flujos.
El gran patrón arquitectónico que conviene conocer es el debate entre la arquitectura Lambda (dos rutas, batch y streaming, que se reconcilian) y la arquitectura Kappa (una sola ruta de streaming que también reprocesa el histórico). La tendencia se inclina hacia Kappa por su menor complejidad operativa, pero la elección depende de los requisitos de latencia y exactitud de cada caso.
Calidad del dato: la veracidad como cimiento
De las cinco uves, la veracidad es la más fácil de descuidar y la más cara de ignorar. Un análisis impecable sobre datos sucios produce conclusiones erróneas con apariencia de rigor científico, lo que es peor que no tener análisis alguno. La calidad del dato se gestiona midiendo varias dimensiones concretas: la exactitud (¿el dato refleja la realidad?), la completitud (¿faltan campos o registros?), la consistencia (¿coinciden los valores entre sistemas?), la puntualidad (¿llega el dato a tiempo para la decisión?) y la unicidad (¿hay duplicados que inflan los recuentos?).
En arquitecturas modernas, estas comprobaciones se automatizan como pruebas de calidad ejecutadas en cada paso del pipeline, de modo que un lote que no cumple los umbrales se bloquea o se marca antes de contaminar las zonas de consumo. Un patrón habitual organiza el lakehouse en capas (bruto, refinado y de consumo), aplicando validaciones crecientes en cada salto, de manera que solo llegan al análisis los datos que han superado el filtro de calidad. Tratar la calidad como una característica del producto de datos, y no como una limpieza puntual, es lo que distingue un programa de datos sostenible de un esfuerzo que se degrada con el tiempo.
Gobierno del dato y cumplimiento normativo
Un proyecto de Big Data sin gobierno es un riesgo legal a la espera de materializarse. El Reglamento General de Protección de Datos (RGPD) impone principios que afectan directamente a la arquitectura: minimización (no acumular datos personales "por si acaso"), limitación de la finalidad, limitación del plazo de conservación y el derecho de supresión, que en un data lake inmutable obliga a diseñar mecanismos de borrado selectivo. La seudonimización y el cifrado en reposo y en tránsito son medidas técnicas exigibles. El gobierno del dato añade catálogos, linaje (saber de dónde viene cada dato y qué se ha hecho con él) y control de accesos basado en roles, todo ello alineable con marcos como la norma ISO/IEC 27001 de seguridad de la información. Cuando los datos alimentan modelos de IA, hay que considerar además las obligaciones de calidad y trazabilidad del Reglamento Europeo de IA.
Implementación por fases
Un programa de datos ordenado avanza así: (1) definir las preguntas de negocio y los casos de uso concretos antes de mover un solo byte; (2) diseñar la ingesta y el catálogo con linaje desde el primer día; (3) establecer las zonas del lakehouse (bruto, refinado, consumo) con reglas de calidad en cada salto; (4) aplicar gobierno y control de accesos antes de abrir el acceso, no después; (5) elegir el modo de procesamiento (batch o streaming) según la latencia que de verdad necesita la decisión; y (6) medir el coste por consulta y el valor entregado, porque el almacenamiento barato anima a acumular datos que nadie usa.
Errores comunes que conviene evitar
El primero es el data swamp: volcar datos sin catálogo ni calidad hasta que el lake se vuelve inutilizable. El segundo es optar por streaming cuando basta un batch nocturno, multiplicando la complejidad operativa sin valor real. El tercero es ignorar el RGPD en la arquitectura, descubriendo demasiado tarde que no se pueden borrar los datos de un usuario que ejerce su derecho de supresión. El cuarto es medir el éxito por terabytes almacenados en lugar de por decisiones mejoradas. Y el quinto es subestimar el coste de la nube: una consulta mal diseñada sobre petabytes puede generar una factura sorprendente.
Preguntas frecuentes
¿Cuándo deja de ser "datos normales" y pasa a ser Big Data?
No hay un umbral fijo en gigabytes. El punto de inflexión llega cuando el volumen, la velocidad o la variedad superan lo que una sola máquina o una base de datos relacional tradicional pueden manejar con eficiencia, obligando a un procesamiento distribuido.
¿Spark sustituye a Hadoop por completo?
Spark sustituye al motor de procesamiento MapReduce por su velocidad en memoria, pero suele convivir con almacenamiento distribuido (HDFS o, más comúnmente hoy, almacenamiento de objetos en la nube). Hadoop como ecosistema ha perdido protagonismo frente al lakehouse.
¿Qué es un lakehouse y por qué se ha impuesto?
Es una arquitectura que aporta transacciones ACID, versionado y rendimiento de warehouse sobre los datos baratos y flexibles de un data lake, mediante formatos de tabla abiertos. Se ha impuesto porque elimina la duplicación entre lake y warehouse y unifica analítica de negocio y machine learning.
¿Cómo afecta el RGPD a un data lake?
Exige poder localizar y borrar datos personales concretos (derecho de supresión), aplicar minimización, seudonimización y cifrado, y mantener trazabilidad. Esto obliga a diseñar el lake con catálogo, linaje y mecanismos de borrado selectivo desde el principio.
Conclusión
El Big Data no consiste en almacenar todo lo posible, sino en convertir grandes volúmenes en decisiones fiables sin perder por el camino la calidad, el coste ni el cumplimiento legal. La arquitectura lakehouse y motores como Spark han resuelto buena parte del problema técnico, pero el factor diferencial sigue siendo el gobierno: un catálogo con linaje, reglas de calidad en cada zona y un diseño compatible con el RGPD desde el primer día separan un activo de datos de un pasivo legal. Acumular petabytes que nadie consulta no es una victoria; es un coste recurrente disfrazado de estrategia. En Summum Marketing partimos siempre de la pregunta de negocio hacia la infraestructura, no al revés, porque el valor de un dato se mide por la decisión que habilita, nunca por su tamaño.