Data Lakehouse

Definición

Un data lakehouse es una arquitectura de plataforma de datos que unifica las propiedades de dos paradigmas previos: el lago de datos (data lake) y el almacén de datos (data warehouse). Un lago de datos almacena datos crudos en formato nativo — Parquet, JSON, CSV, Avro — sobre object storage de bajo costo como Amazon S3, Google Cloud Storage o Azure Data Lake Storage. Ofrece flexibilidad y bajo costo de almacenamiento, pero carece de garantías transaccionales, aplicación de esquema y el rendimiento de consulta estructurado que requieren los analistas de negocio. Un data warehouse, por el contrario, ofrece transacciones ACID, esquema definido, optimización de consultas y rendimiento analítico predecible, pero a un costo de almacenamiento mayor y con dependencia del proveedor por sus formatos propietarios.

El lakehouse resuelve esa tensión añadiendo una capa de metadatos sobre el object storage que provee las propiedades que le faltaban al lago: transacciones ACID para operaciones de escritura concurrentes, evolución de esquema para adaptar la estructura de los datos sin reescribir tablas enteras, consultas de time-travel para acceder a versiones históricas de los datos en cualquier punto en el tiempo, e indexado y optimización de consultas para rendimiento analítico a la escala del warehouse. Los tres formatos de tabla abierta que implementan este patrón son Delta Lake, Apache Iceberg y Apache Hudi. Juntos, habilitan que motores de consulta como Spark, Trino, Flink, Snowflake y BigQuery lean y escriban los mismos datos almacenados en Parquet sobre S3, sin migrarlos a formatos propietarios.

La consecuencia arquitectónica más importante del lakehouse es que elimina la necesidad de mantener dos copias de los datos: una en el lago para cargas de ML y exploración, y otra en el warehouse para consultas analíticas de negocio. Antes del lakehouse, era común que los equipos de datos mantuvieran esa duplicidad, con pipelines de sincronización entre ambas capas, costos duplicados de almacenamiento y procesamiento, y el riesgo permanente de inconsistencias entre las dos fuentes.

Cómo se implementa

Una implementación de lakehouse típica tiene cuatro capas: almacenamiento, formato de tabla, motor de procesamiento y capa de servicio analítico. El almacenamiento es siempre object storage — S3 en AWS, GCS en Google Cloud, ADLS en Azure. El formato de tabla es uno de los tres formatos abiertos: Delta Lake, Apache Iceberg o Apache Hudi. El motor de procesamiento puede ser Spark (para transformaciones complejas en batch o streaming), Trino o Presto (para consultas SQL interactivas de baja latencia), o Flink (para procesamiento de streams). La capa de servicio analítico puede ser una herramienta de BI como Looker, Metabase o Tableau, o una plataforma de capa semántica como dbt Semantic Layer o Cube.

La elección entre los tres formatos de tabla tiene implicaciones prácticas relevantes. Delta Lake, desarrollado por Databricks y de código abierto desde 2019, tiene la mayor madurez en ecosistemas basados en Spark y es la elección natural para equipos que ya usan Databricks. Apache Hudi, desarrollado por Uber, destaca en casos de uso de upsert de baja latencia donde los registros deben actualizarse frecuentemente — bases de datos de clientes, inventarios en tiempo real. Apache Iceberg, desarrollado originalmente por Netflix y Apple, tiene la adopción más amplia entre motores de consulta heterogéneos y se ha convertido en el estándar de facto para implementaciones que deben ser accesibles desde múltiples herramientas sin dependencia de un motor específico.

Ejemplo práctico

Una empresa de fintech en Ciudad de México con MXN $180 millones en ingresos anuales gestiona datos de transacciones de 120,000 usuarios activos. Antes de adoptar el lakehouse, mantenía dos ambientes separados: un lago de datos en S3 donde los científicos de datos entrenaban modelos de riesgo crediticio y detección de fraude sobre datos crudos en Parquet, y un data warehouse en Snowflake donde el equipo de negocio ejecutaba reportes de ingresos, cohortes de retención y métricas de producto. El equipo de datos mantenía pipelines de ETL para sincronizar datos del lago al warehouse, con 6 a 8 horas de latencia y un costo mensual adicional de aproximadamente MXN $85,000 en procesamiento de transferencia y duplicación.

Al migrar a una arquitectura lakehouse con Apache Iceberg sobre S3, el equipo consolidó ambas capas. Los datos de transacciones se ingieren directamente a tablas Iceberg en S3 mediante Airbyte, son transformados por dbt para generar modelos analíticos, y son accesibles tanto desde Athena para consultas SQL del equipo de negocio como desde SageMaker para los notebooks de los científicos de datos — todo sobre los mismos archivos Parquet en S3. El costo de almacenamiento bajó un 38% al eliminar la duplicación. La latencia de los datos para el equipo de negocio bajó de 6-8 horas a menos de 2 horas. Los científicos de datos ahora entrenan modelos sobre los mismos datos que ve el equipo de negocio, eliminando discrepancias entre los resultados del modelo y las métricas de reporteo. El equipo de datos eliminó el mantenimiento de los pipelines de sincronización — aproximadamente 30 horas de ingeniería mensuales — y las redirigió a proyectos de mayor valor.

Análisis en profundidad

El lakehouse no es la solución correcta para todos los equipos. Para empresas con menos de 500 GB de datos analíticos y necesidades principalmente SQL, un data warehouse moderno como BigQuery, Snowflake o Redshift es más sencillo de operar, más rápido de implementar y no requiere el conocimiento de operaciones de lago que el lakehouse demanda. El argumento a favor del lakehouse se vuelve compelling cuando se dan una o más de estas condiciones: los volúmenes de datos hacen costoso el almacenamiento en warehouse propietario; el equipo necesita combinar cargas de ML sobre datos crudos con consultas analíticas SQL sobre datos modelados sobre los mismos archivos; se requiere acceso multi-motor sin lock-in de proveedor; o se manejan formatos no tabulares — imágenes, logs, texto — junto con datos estructurados.

La evolución del panorama de formatos de tabla en 2024-2026 favorece claramente a Apache Iceberg. Los principales proveedores cloud han añadido soporte nativo: Snowflake puede leer y escribir tablas Iceberg directamente; BigQuery Omni hace lo mismo; AWS Athena, EMR y Glue son todos compatibles con Iceberg. Databricks, históricamente el principal impulsor de Delta Lake, anunció soporte de primera clase para Iceberg a través de UniForm — una capa de compatibilidad que permite que las tablas Delta sean leídas como Iceberg por otros motores. Ese convergencia hacia Iceberg como capa de interoperabilidad reduce el riesgo de apostar por este formato, porque incluso los ecosistemas construidos sobre Delta pueden exponer datos como Iceberg.

En el contexto LATAM, la adopción del lakehouse sigue con un rezago de 18 a 24 meses respecto a los mercados norteamericano y europeo, pero la curva de adopción se está acelerando. Las razones son estructurales: los costos de almacenamiento en object storage son significativamente menores que los costos de warehouse propietario en pesos mexicanos, pesos colombianos o reales brasileños, lo que hace que el argumento de costo sea más poderoso que en mercados donde el dólar tiene mayor poder adquisitivo relativo. Adicionalmente, la disponibilidad de regiones cloud de AWS, GCP y Azure en Brasil, México y recientemente Colombia reduce la latencia y los costos de egreso de datos que eran una barrera para arquitecturas cloud-native en la región.

Una consideración operativa importante para equipos en LATAM que evalúan el lakehouse es la disponibilidad de talento. Las habilidades necesarias para implementar y mantener un lakehouse — Spark, Iceberg, infraestructura cloud, orquestación con Airflow o Dagster — son escasas en el mercado latinoamericano. En 2025-2026, el perfil de ingeniería de datos con dominio de estas herramientas tiene una prima salarial de entre el 30% y el 60% sobre el perfil de SQL warehouse tradicional en mercados como México y Colombia. Este factor de costo de talento debe incluirse en el análisis de costo total de propiedad (TCO) cuando se evalúa si el lakehouse es la arquitectura correcta para el tamaño y stage del negocio.

La relación entre el lakehouse y las plataformas de business intelligence es de complementariedad, no de competencia. El lakehouse es infraestructura — donde viven los datos y cómo se organizan para ser consultados. Una plataforma de BI o de inteligencia operativa opera sobre el lakehouse para responder preguntas de negocio, generar alertas y recomendar acciones. La calidad de los datos en el lakehouse — consistencia, latencia, gobernanza de esquema — determina directamente la calidad de las respuestas que puede generar la capa de inteligencia que se construye sobre él. Un lakehouse mal gobernado produce lo mismo que el lago de datos de la era anterior: un "pantano de datos" donde los analistas no confían en los números que ven.

Errores frecuentes

• ✗

  Adoptar el lakehouse sin el talento de ingeniería necesario para operarlo. Un lakehouse mal implementado puede ser más difícil de mantener que un data warehouse moderno y más caro de operar si el equipo no tiene las habilidades de Spark, Iceberg y orquestación. La decisión de arquitectura debe considerar el costo total de propiedad incluyendo el talento — no solo el costo de almacenamiento — especialmente en mercados LATAM donde las habilidades de ingeniería de datos avanzada son escasas y tienen prima salarial.

• ✗

  Ignorar la gobernanza de esquema y convertir el lakehouse en un nuevo pantano de datos. El principal riesgo del lakehouse es heredar el problema que tenían los lagos de datos puros: sin disciplina en el esquema, la documentación de tablas y el control de calidad de datos, el lakehouse se convierte en un repositorio de archivos Parquet sin contexto. La capa de tabla abierta (Iceberg, Delta, Hudi) provee las herramientas técnicas para la gobernanza de esquema, pero el proceso de usarlas requiere disciplina del equipo. El contrato de esquema para cada tabla debe documentarse, versionarse y comunicarse a los consumidores.

• ✗

  Construir el lakehouse antes de tener claridad sobre las preguntas que debe responder. La arquitectura de datos no es un fin en sí mismo; es infraestructura para responder preguntas de negocio. Equipos que invierten 6 a 9 meses en construir un lakehouse sin tener definidas las métricas de negocio clave, los flujos de transformación necesarios y los consumidores de los datos terminan con infraestructura técnica sofisticada que no está conectada a decisiones operativas. La arquitectura correcta de datos parte de las preguntas de negocio, no de la tecnología.

Cómo lo rastrea Fairview

Fairview se conecta a datos almacenados en arquitecturas de data lakehouse — ya sea sobre Iceberg, Delta Lake o Hudi — a través de conectores nativos con Trino, Athena, BigQuery Omni y Spark SQL. Para equipos que ya tienen un lakehouse implementado, Fairview funciona como la capa de inteligencia operativa sobre la infraestructura existente: lee las tablas modeladas, aplica la capa semántica de métricas de negocio, y genera alertas y recomendaciones de acción cuando las métricas se desvían de los umbrales definidos. Para equipos que están evaluando si adoptar un lakehouse, Fairview puede conectarse también directamente a los warehouses existentes (Snowflake, BigQuery, Redshift) o a fuentes de datos operativas sin necesidad de infraestructura de lago como prerequisito. La decisión de arquitectura de datos no debe ser un prerequisito para acceder a inteligencia operativa.

Preguntas frecuentes