6  Data Lakehouse

De silos a una base abierta y gobernada

6.0.1 Pregunta rectora

¿En qué momento compartir una base abierta y gobernada para BI, streaming y aprendizaje automático justifica asumir la operación adicional de un Lakehouse?

Un Data Lakehouse no es el destino obligatorio de toda plataforma de datos. En una organización pequeña, un Data Warehouse administrado puede entregar resultados con menos componentes y menos personal. El Lakehouse se vuelve razonable cuando la duplicación, el movimiento de datos, la variedad de cargas y la necesidad de reutilizar contratos comunes superan el costo de operar tablas, metadatos, catálogo, gobierno y mantenimiento.

Esta lectura sigue un caso de una fintech desde sus primeros reportes hasta una plataforma compartida. El propósito no es memorizar productos, sino aprender a separar responsabilidades y argumentar una decisión arquitectónica.

NotaRuta de lectura

Tiempo estimado: 35–45 minutos. Conviene haber leído antes el capítulo de Data Warehouse. Los diagramas usan siempre la misma convención: azul para datos y almacenamiento, morado para metadatos y gobierno, naranja para ingesta, gris para cómputo, verde para consumo confiable y rojo para riesgo o duplicación.

1. Problema
Silos, copias y dos respuestas.
2. Mecanismo
Objetos, tablas, snapshots y catálogo.
3. Integración
BI, ML y streaming sobre contratos comunes.
4. Decisión
Beneficios, operación y criterios de adopción.

Objetivos de aprendizaje.

Al terminar, podrás:

  1. explicar por qué un Data Warehouse fue una elección correcta durante la primera etapa de la fintech;
  2. localizar duplicación, latencia y controles dobles en una arquitectura con silos;
  3. distinguir objeto, bucket, formato de archivo, formato de tabla, catálogo, gobierno y motor de cómputo;
  4. narrar cómo un snapshot evita que una escritura incompleta se vuelva visible;
  5. justificar una transición usando volumen, variedad, velocidad, cargas de trabajo, costo y capacidad operativa;
  6. reconocer que compactación, evolución de esquemas, observabilidad y radio de impacto siguen siendo responsabilidades del equipo.

6.0.2 El problema antes de la definición

A las 10:02, la fintech recibe la transacción tx_8472 por $3,200. Finanzas la incluye en los ingresos del día, pero el sistema de fraude la presenta como bloqueada. Ambos equipos ejecutaron correctamente su propio proceso. La discrepancia está en las rutas y contratos que utilizaron.

La pregunta útil no es todavía «¿qué producto compraremos?», sino «¿qué trabajo se duplica para sostener estas dos rutas?».

6.0.3 Dos caminos que deben representar el mismo negocio

Históricamente, el Data Warehouse y el Data Lake resolvieron problemas legítimos:

  • El Data Warehouse ofreció tablas controladas, SQL, concurrencia y reportes comprensibles para el negocio.
  • El Data Lake permitió conservar grandes volúmenes y tipos diversos en almacenamiento de objetos económico y flexible.

El costo aparece cuando cada uno se convierte en una autoridad separada.

Si Producto agrega device_risk_score, el cambio debe capturarse, aterrizarse, transformarse, incorporarse a la tabla analítica, probarse, publicarse, autorizarse y comunicarse a consumidores. Cuando las rutas están separadas, varias de esas decisiones se repiten. La deuda no está sólo en los bytes duplicados: está en las decisiones duplicadas.

6.0.4 Caso Fintech, fase 1: el Warehouse era suficiente

Durante los años 0–3, la empresa tenía datos relacionales, unas 10,000 transacciones diarias, alrededor de 500 GB al año y reportes por lotes. Su necesidad dominante era conocer ingresos, morosidad y crecimiento con rapidez.

Un servicio administrado, dbt y una persona analista podían entregar valor en una semana y operar por cientos de dólares mensuales dentro del supuesto didáctico. Contratar un equipo especializado para un Lakehouse habría agregado observabilidad, integración y mantenimiento sin un retorno claro.

ImportantePrincipio de decisión

Elegir un Data Warehouse en esta fase no fue falta de visión. Fue ajustar arquitectura, costo y capacidad del equipo al problema real.

Qué hace cada producto en esa fase.

  • PostgreSQL, MySQL o una base operacional administrada registra usuarios, cuentas y pagos de la aplicación. Está optimizada para operar el negocio, no para escanear años de historia.
  • Fivetran o Airbyte extrae o replica datos desde las fuentes hacia un destino analítico.
  • BigQuery, Snowflake, Amazon Redshift o Fabric Warehouse puede cumplir el rol de Data Warehouse. Son alternativas; no es necesario contratar todos.
  • dbt ejecuta transformaciones y pruebas principalmente mediante SQL sobre el Warehouse; no es el lugar principal donde viven los datos.
  • Metabase, Tableau, Power BI o Looker presenta métricas y tableros a usuarios de negocio.

La marca no determina por sí sola la arquitectura. BigQuery puede ser un Warehouse de tablas nativas y también un motor que consulta tablas abiertas. Siempre pregunta: ¿qué almacena, qué cataloga y qué procesa?

Un Data Warehouse moderno también puede ser elástico, admitir datos semiestructurados y consultar almacenamiento externo. La decisión se toma por requisitos, economía y capacidad operativa, no por presentar al Warehouse como una tecnología rígida por definición.

6.0.5 Año 4: el punto de quiebre

La arquitectura inicial no falla por recibir un JSON aislado. El cambio aparece por una combinación de presiones.

Los 4 TB/mes equivalen aproximadamente a 48 TB/año. Llegar a petabytes requeriría crecimiento y retención durante varios años; no debe afirmarse que cuatro terabytes mensuales ya sean un petabyte. Los montos del caso son supuestos docentes, no cotizaciones de proveedores.

Actividad de clasificación.

Síntoma Fuerza principal
Millones de clics móviles Volumen y velocidad
PDFs de contratos Variedad
Modelo de fraude que necesita segundos Velocidad y nuevos consumidores
Científicos que descargan terabytes Movimiento
Dos equipos calculan la misma característica de riesgo Coordinación
La factura de transformaciones se dispara Economía y operación

La pregunta de diseño es: ¿escalamos el Warehouse, añadimos un Lake separado o rediseñamos una base compartida? La respuesta debe empezar por requisitos, no por productos.

6.1 La base técnica del Lakehouse

6.1.1 Vocabulario mínimo

Término Explicación cotidiana Ejemplo en la fintech Qué no significa
Objeto Unidad guardada en la nube: bytes, nombre o key y metadatos. PDF, imagen o archivo Parquet. No es necesariamente una fila ni una tabla.
Bucket Contenedor con nombre donde un proveedor guarda objetos. s3://fintech-datos-prod/. No es motor SQL, base relacional ni todo el Data Lake.
Key Localizador único de un objeto dentro del bucket; puede parecer una ruta. bronze/kafka/2026/08/25/part-0001.json. Los separadores / no siempre representan carpetas tradicionales.
Data Lake Arquitectura para conservar y procesar datos diversos sobre almacenamiento económico, con ingesta, organización, seguridad y gobierno. Objetos, políticas, catálogo y procesos. Un bucket aislado no se vuelve automáticamente un Data Lake.
Data Warehouse Sistema analítico orientado a tablas, SQL y datos preparados para decisiones. Tablas de ingresos y morosidad. No es la base operacional que autoriza cada pago.
Motor de cómputo Software que consulta, transforma, agrega o entrena. BigQuery, Trino, Spark o Databricks SQL. El almacenamiento de objetos no procesa consultas por sí solo.
Formato de archivo Organización de bytes dentro de un archivo. Parquet organiza columnas y compresión. No coordina por sí mismo una tabla de muchos archivos.
Formato de tabla Protocolo que decide qué archivos forman una tabla y conserva cambios, esquema y snapshots. Iceberg, Delta Lake o Hudi. No sustituye almacenamiento, catálogo ni motor.
Catálogo Mapa que relaciona un nombre con ubicación, esquema, propietario y metadatos vigentes. fintech.silver.transactions. Una lista no garantiza calidad sin procesos y responsables.

Una analogía breve ayuda a recordar las responsabilidades:

El bucket es el contenedor; los objetos son los paquetes; la key es la etiqueta. Parquet organiza el contenido de ciertos paquetes. Iceberg, Delta Lake o Hudi mantienen el inventario versionado que dice qué paquetes forman una tabla. El catálogo permite pedir la tabla por nombre y verificar el acceso. El motor abre los paquetes y realiza el cálculo.

Anatomía de un bucket.

La URI s3://fintech-datos-prod/documents/loan-8472.pdf se interpreta así: s3 identifica el servicio, fintech-datos-prod es el bucket y el resto es la key. En Google Cloud se vería gs://...; en ADLS Gen2 se usa un contenedor dentro de una cuenta de almacenamiento.

Tres distinciones deben quedar explícitas:

  1. Bucket ≠ archivo. El bucket contiene objetos; el PDF o Parquet es el objeto.
  2. Bucket ≠ Data Lake. Un Data Lake incluye ingesta, organización, seguridad, catálogo, cómputo y operación.
  3. Bucket ≠ Lakehouse. El Lakehouse añade tablas transaccionales, catálogo, gobierno y motores coordinados.

6.1.2 Una base física compartida todavía no es una tabla

El primer paso del Lakehouse es desacoplar los bytes del motor: guardar datos en objetos y asignar cómputo distinto a SQL, ML o streaming. Esa base ofrece escala, formatos abiertos y economía de capacidad. Sin embargo, una carpeta puede contener:

transactions/
  part-0001.parquet
  part-0002.parquet
  part-0003.parquet
  part-0003-retry.parquet
  _temporary-part-0004.parquet

El nombre de la carpeta no decide de forma confiable cuáles archivos pertenecen a la tabla, cuál fue un reintento y si la escritura terminó.

6.1.3 La idea que debe sobrevivir

Lakehouse = almacenamiento de objetos + formato de tabla transaccional + catálogo y gobierno + motores especializados sobre datos compartidos + operación continua

No es «un lago junto a un almacén» ni «guardar Parquet en S3». Es hacer que conjuntos de archivos se comporten como tablas confiables sin perder apertura y separación entre almacenamiento y cómputo.

6.1.4 Responsabilidades lógicas de la arquitectura

Una implementación puede agrupar varias responsabilidades en un servicio administrado o distribuirlas entre herramientas. Las capas son lógicas, no una lista obligatoria de cinco productos.

1. Ingesta.

Conecta datos estructurados, semiestructurados y no estructurados. Las cargas batch mueven datos acumulados a intervalos; CDC replica cambios de una fuente; streaming procesa eventos a medida que llegan. La modalidad determina frescura, tamaño de archivos, reintentos y costo operativo.

2. Almacenamiento.

S3, Cloud Storage, ADLS Gen2 u OneLake conservan objetos a gran escala. Parquet y ORC son formatos columnares eficientes para datos tabulares; JSON, PDFs e imágenes pueden permanecer como objetos. Usar un formato abierto reduce dependencia, pero no garantiza que todos los motores soporten las mismas operaciones.

3. Formato de tabla, catálogo y gobierno.

Iceberg, Delta Lake y Hudi coordinan archivos como tablas versionadas. El catálogo resuelve nombres, ubicaciones, esquemas y metadatos vigentes. El gobierno añade identidad, clasificación, permisos, auditoría y responsabilidades. Son tareas relacionadas, pero distintas.

4. Interfaces y motores.

SQL, APIs de DataFrame y APIs de metadatos permiten que motores como BigQuery, Trino, Spark o Databricks SQL procesen datos sin convertir el almacenamiento en el motor. La compatibilidad se verifica por operación, versión del formato y configuración.

5. Consumo.

BI necesita métricas certificadas; ciencia de datos necesita entidades reutilizables y datos autorizados; fraude necesita baja latencia; auditoría necesita historia y evidencias. Compartir la base no obliga a compartir un único motor ni a consultar la misma capa de calidad.

6.1.5 Archivo, tabla y catálogo no son sinónimos

Parquet no publica una transacción sobre veinte archivos. El formato de tabla mantiene la lista autorizada, el esquema, las particiones y los snapshots. El catálogo permite que un nombre estable apunte a esos metadatos. Iceberg, Delta Lake y Hudi comparten esa intención general, pero no son idénticos.

6.1.6 Cómo un snapshot oculta una escritura incompleta

El reto no es que S3, Cloud Storage o Azure Blob Storage necesariamente «pierdan consistencia». Una modificación de tabla puede crear muchos objetos; hace falta un commit de tabla atómico que publique el conjunto completo.

La atomicidad se logra porque los lectores consultan una lista autorizada. Si el job falla antes de publicar, el puntero sigue en el snapshot 17. Si termina, un commit mueve el puntero a la versión 18 completa. Un lector que resolvió la versión antes del commit continúa con una vista consistente según el aislamiento y el motor.

Las garantías ACID suelen expresarse por tabla. No debe suponerse automáticamente una transacción atómica entre muchas tablas; hay que verificar el formato y el motor.

6.1.7 Evolución de esquema sin reescribir toda la historia

Los metadatos pueden separar la identidad de una columna de su nombre visible.

Esto habilita evolución de esquema y viaje en el tiempo, pero no vuelve gratuitos todos los cambios. Modificar tipos incompatibles, semántica, particiones o unidades puede exigir migración, backfill, vistas de transición y pruebas.

6.1.8 Catálogo y gobierno: mapa, versión y acceso

El catálogo convierte un nombre de negocio en ubicación, esquema y metadatos vigentes. El gobierno responde otra pregunta: aunque alguien conozca la ruta, ¿tiene derecho a verla y con qué detalle? Un catálogo no mueve datos ni garantiza calidad por existir. Requiere propietarios, políticas, clasificación, auditoría y credenciales con privilegio mínimo.

Comprobación rápida.

Asigna cada responsabilidad:

  1. «Organiza columnas y compresión dentro de part-0007» → formato de archivo.
  2. «Decide que A, B y C forman la versión 17» → formato de tabla.
  3. «Resuelve dónde vive silver.transactions y verifica permisos» → catálogo y gobierno.
  4. «Conserva el PDF original y los bytes de Parquet» → almacenamiento de objetos.

6.2 Integrar calidad, cargas y productos de datos

6.2.1 Medallion: Bronze, Silver y Gold

La arquitectura Medallion es una forma frecuente, no una ley universal, de representar estados de calidad. Los nombres no designan productos ni ubicaciones físicas obligatorias.

Bronze preserva; Silver integra; Gold traduce al lenguaje del negocio. Finanzas no debería calcular ingresos directamente desde JSON Bronze. Una organización puede publicar varias tablas Gold porque cada producto responde a una decisión y granularidad distintas.

PDFs, imágenes y otros binarios permanecen como objetos. Una tabla Silver puede registrar object_uri, hash, propietario, clasificación, estado de OCR y relaciones. No conviene afirmar que una fotografía «se convierte en Iceberg».

6.2.2 Fase 2: una base gobernada y varios motores

La fintech no cambió sólo de contenedor. Cambió el contrato:

  • Finanzas consulta productos Gold certificados.
  • ML utiliza entidades Silver autorizadas y resultados derivados de documentos sin descargar terabytes a almacenamiento local.
  • Fraude procesa eventos en tiempo real y consulta o actualiza señales gobernadas según las garantías del pipeline.

Separar almacenamiento y cómputo permite dimensionar y apagar motores por carga, pero no garantiza costos menores. Formato, estadísticas, tamaño de archivos, partición, cachés y consultas siguen determinando desempeño y gasto.

6.2.3 Tecnologías abiertas y servicios administrados

Responsabilidad Ejemplos frecuentes Función en el caso
Fuente operacional PostgreSQL, MySQL, SQL Server, Cloud SQL, RDS, Azure SQL Usuarios, cuentas, cobros y transferencias.
Ingesta batch/CDC Fivetran, Airbyte, AWS DMS, Datastream, Azure Data Factory Replica cambios operacionales.
Eventos Kafka, Confluent, Kinesis, Pub/Sub, Event Hubs Clics, telemetría y fraude.
Almacenamiento de objetos S3, Cloud Storage, ADLS Gen2, OneLake Conserva JSON, Parquet, PDFs e imágenes.
Formato de archivo Parquet, ORC, Avro, JSON Organiza bytes dentro de cada archivo.
Formato de tabla Iceberg, Delta Lake, Hudi Publica snapshots, esquema e inventario de archivos.
Catálogo y gobierno Glue + Lake Formation, Lakehouse runtime catalog + Knowledge Catalog, Unity Catalog, Fabric + Purview Descubrimiento, permisos, linaje y auditoría.
Motores BigQuery, Athena, Redshift, Trino, Spark, Databricks SQL, Fabric SQL Ejecuta la carga analítica o de ingeniería.
Consumo Looker, QuickSight, Power BI, Tableau, notebooks, modelos Convierte datos en decisiones o productos.

Parquet, Iceberg, Delta Lake, Hudi, Spark, Kafka y Trino son estándares o proyectos abiertos. S3, BigQuery, Redshift, Databricks, Fabric y Fivetran son servicios o plataformas administradas. Una plataforma comercial puede administrar tecnologías abiertas.

6.3 Implementaciones en Google Cloud, AWS y Azure

No hay traducción exacta entre servicios. La comparación debe mantener fijas las responsabilidades: almacenamiento, tabla, catálogo, gobierno, cómputo, consumo y operación.

6.3.1 Google Cloud: Cloud Storage, Iceberg y varios motores

La arquitectura actual de Google Cloud combina Cloud Storage, Apache Iceberg, un runtime catalog, gobierno y motores como BigQuery, Spark, Flink y Trino, según su documentación de arquitectura Lakehouse. Las tablas Iceberg administradas por BigQuery permanecen en buckets controlados por la organización y añaden evolución de esquema, time travel y optimización automática, como detalla la guía de tablas Iceberg administradas.

Una ruta de implementación razonable es:

  1. elegir región, proyecto y bucket con políticas de retención y cifrado;
  2. crear un Lakehouse runtime catalog y definir namespaces;
  3. usar Iceberg V2 para nuevas tablas abiertas y decidir quién administra sus metadatos;
  4. configurar IAM y, cuando corresponda, credenciales delegadas con privilegio mínimo;
  5. conectar BigQuery y los motores abiertos que realmente utilizará el equipo;
  6. probar lectura, escritura, evolución, recuperación y costos antes de declarar interoperabilidad.

El quickstart oficial recorre la creación del catálogo Iceberg REST, permisos, tablas y consultas. BigQuery también puede operar como un Data Warehouse moderno sin que la arquitectura deba llamarse Lakehouse.

6.3.2 AWS: S3, Iceberg, Glue y Lake Formation

La arquitectura Lakehouse de SageMaker unifica datos en S3, S3 Tables y Redshift mediante catálogos y acceso gobernado. En una pila modular, S3 conserva objetos, Iceberg coordina tablas, Glue Data Catalog registra metadatos, Lake Formation aplica permisos y Athena, Redshift, EMR o Glue ejecutan las cargas.

Una ruta de implementación es:

  1. definir cuentas, regiones, buckets, cifrado, retención y límites de red;
  2. registrar ubicaciones y tablas en Glue Data Catalog;
  3. aplicar Lake Formation e IAM con separación entre administración, escritura y consumo;
  4. crear tablas Iceberg y seleccionar motores compatibles por operación;
  5. probar compaction, snapshots, limpieza y evolución de esquema;
  6. publicar productos de datos y observar frescura, uso y costo.

AWS ofrece un recorrido inicial para crear proyecto, explorar, cargar, consultar y publicar datos. Su guía prescriptiva de Iceberg cubre servicios compatibles y prácticas para costo, rendimiento y operación a escala.

6.3.3 Azure y Microsoft Fabric: OneLake, Delta y Medallion

Microsoft ofrece al menos dos rutas frecuentes. Fabric Lakehouse usa OneLake, tablas Delta, Spark, un endpoint SQL y Power BI. Azure Databricks combina ADLS Gen2, Delta Lake, Unity Catalog, Spark y Databricks SQL. La elección depende de integración, gobierno, habilidades y modelo operativo.

Para Fabric, una ruta de implementación es:

  1. decidir dominios, workspaces y fronteras de seguridad;
  2. crear el Lakehouse y diseñar Bronze, Silver y Gold por calidad y propietario;
  3. ingerir o enlazar datos, conservando el original cuando sea necesario;
  4. publicar Silver y Gold como tablas Delta;
  5. conectar Spark, endpoint SQL y Power BI según la carga;
  6. automatizar pruebas, mantenimiento, OPTIMIZE, retención y observabilidad.

La guía de Medallion en OneLake explica modelos de despliegue, formatos, tamaño de archivos, retención y acceso. El tutorial de extremo a extremo cubre workspace, ingesta, transformación, Delta, endpoint SQL y consumo. Para una ruta empresarial con Data Factory y Azure Databricks, Microsoft organiza el diseño desde una base inicial hasta endurecimiento y misión crítica.

AdvertenciaNo confundas una demostración con una arquitectura de producción

Un tutorial valida el flujo funcional. Producción exige además identidad, red, cifrado, continuidad, RPO/RTO, segregación de entornos, CI/CD, contratos, observabilidad, presupuestos, soporte y responsables.

6.4 El trabajo que no desaparece

6.4.1 El impuesto de los archivos pequeños

El streaming puede crear muchos archivos válidos y pequeños. El motor debe enumerarlos, abrirlos y planificarlos. La compactación reescribe el mismo contenido en menos archivos y publica el reemplazo mediante un nuevo snapshot.

6.4.2 Una fuente compartida comparte el radio de impacto

Responsabilidades operativas.

  • compactación y dimensionamiento de archivos;
  • retención de snapshots y limpieza de archivos huérfanos;
  • calidad, contratos y evolución compatible;
  • permisos, auditoría y prevención de accesos directos no gobernados;
  • observabilidad de latencia, frescura, costo y fallas;
  • pruebas reales de interoperabilidad para cada formato y motor;
  • presupuestos, cuotas y apagado o escalamiento del cómputo;
  • continuidad: time travel es útil, pero no sustituye por sí solo respaldos, aislamiento y recuperación.

6.5 Decidir, no evangelizar

Criterio Warehouse administrado Lake + Warehouse separados Lakehouse
Datos dominantes Relacionales y preparados Crudos diversos con usos separados Diversos y compartidos entre BI, ML y streaming
Prioridad Rapidez de adopción y SQL Aislar economías o equipos Reducir copias con contratos comunes
Cómputo Principalmente SQL/BI Motores y autoridades separadas Motores distintos sobre tablas compartidas
Operación Menor carga para un equipo pequeño Coordinación y sincronización dobles Metadatos, compactación y gobierno rigurosos
Señal económica El servicio administrado sigue alineado La separación tiene fronteras claras Movimiento, copias o almacenamiento propietario dominan el costo
Riesgo principal Rigidez o costo al crecer Dos verdades y latencia Complejidad y radio de impacto compartido

Para la fintech:

  • Años 0–3: Warehouse administrado; datos relacionales, objetivo de reporting y equipo pequeño.
  • Año 5: Lakehouse; BI, ML y fraude reutilizan datos diversos a escala, y el movimiento ya domina parte del costo.
  • Otra empresa: puede seguir en Warehouse o usar una arquitectura híbrida. No hay ganador universal.

Usa esta forma de argumento:

Elegimos ___ porque ___ y ; aceptamos el costo o riesgo de .

Ejemplo inicial: «Elegimos un Warehouse administrado porque los datos son relacionales y necesitamos reporting rápido; aceptamos menor flexibilidad futura a cambio de una operación sencilla».

Ejemplo a escala: «Elegimos Lakehouse porque BI, ML y fraude necesitan reutilizar datos diversos y el movimiento de terabytes domina el costo; aceptamos operar compactación, contratos y gobierno con un equipo especializado».

6.5.1 Preguntas frecuentes y errores de recuperación

¿Un bucket es una carpeta gigante?

Es una aproximación inicial útil, pero incompleta. El bucket contiene objetos identificados por keys. Los prefijos pueden mostrarse como carpetas aunque el modelo base no sea un sistema de archivos tradicional.

¿Puedo hacer SQL directamente sobre un bucket?

El bucket no ejecuta SQL. Athena, BigQuery, Trino, Spark u otro motor puede leer archivos. Para tratarlos como tablas confiables necesita esquema, lista vigente de archivos, formato de tabla y catálogo.

¿S3 es un Data Lake?

S3 suele ser su base física. El Data Lake incluye también ingesta, organización, seguridad, catálogo, cómputo y operación.

¿Entonces el Data Warehouse ya no sirve?

No. En la fase inicial fue la opción más eficiente y puede seguir atendiendo productos Gold o cargas de BI. La transición se evalúa cuando el beneficio de compartir datos diversos supera la carga operativa.

¿Guardar Parquet en S3 ya crea un Lakehouse?

No. Resuelve almacenamiento y formato de archivo. Faltan commits consistentes, formato de tabla, catálogo, permisos, calidad, mantenimiento y motores compatibles.

¿Iceberg, Delta Lake y Hudi son bases de datos?

Son formatos o protocolos de tabla. Un catálogo y motores completan la experiencia; una plataforma puede empaquetarlos como servicio.

¿El catálogo guarda todos los datos?

Normalmente guarda o resuelve metadatos: nombres, ubicaciones, esquemas, propietarios, políticas y punteros. Los archivos permanecen en almacenamiento de objetos.

¿La fuente única de verdad es una sola tabla?

No. Significa autoridades y contratos coherentes. Bronze, Silver y Gold pueden coexistir, con productos adecuados a distintas decisiones.

¿Formato abierto significa compatibilidad perfecta?

No. Deben probarse operaciones, versión del formato, extensiones, escrituras concurrentes, evolución de esquema y mantenimiento en cada motor.

¿Separar cómputo siempre abarata?

No. Permite escalar por carga, pero consultas ineficientes, recursos permanentes o falta de límites pueden elevar el gasto.

¿Time travel sustituye los respaldos?

No necesariamente. Depende de retención, eliminación de objetos, aislamiento de cuentas y requisitos de recuperación. Es versionado útil, no una estrategia completa de continuidad.

6.5.2 Exit ticket

Completa sin consultar el capítulo:

  1. Un bucket con Parquet no es todavía una tabla porque…
  2. El catálogo sirve para…, mientras el formato de tabla sirve para…
  3. La migración de la fintech se justifica cuando…, pero obliga a…
Respuestas mínimas esperadas
  1. Falta una lista versionada y transaccional que determine qué archivos forman la tabla.
  2. El catálogo permite encontrar y gobernar; el formato coordina snapshots, esquema y commits.
  3. Varias cargas comparten datos diversos a escala y las copias o costos se vuelven dominantes; a cambio se operan mantenimiento, gobierno y contratos.

Criterio de logro.

El objetivo se alcanza si puedes reconstruir la cadena silos → objetos → snapshots → catálogo/gobierno → motores especializados → operación → decisión y, además, explicar por qué el Warehouse fue correcto en la fase inicial y por qué el Lakehouse sólo se volvió razonable al cambiar los requisitos.

6.6 Cheatsheet

6.6.1 Modelo mental en una página

Si ves o escuchas… Piensa en… Pregunta de verificación
s3://, gs://, ADLS, OneLake Almacenamiento de objetos ¿Dónde viven los bytes y quién controla la ubicación?
Parquet u ORC Formato de archivo ¿Cómo se organizan columnas dentro de cada archivo?
Iceberg, Delta o Hudi Formato de tabla ¿Cómo se publican commits, snapshots y evolución de esquema?
Glue, Lakehouse runtime catalog, Unity Catalog, Fabric/Purview Catálogo y gobierno ¿Quién resuelve nombres, metadatos, permisos, linaje y propietario?
BigQuery, Athena, Trino, Spark, Redshift, Databricks SQL Motor de cómputo ¿Qué procesa y qué operaciones soporta sobre el formato?
Bronze Evidencia recibida ¿Puede reconstruirse el proceso y respetarse la retención?
Silver Entidades validadas ¿Existe contrato, calidad, deduplicación y responsable?
Gold Producto de datos ¿Qué decisión, granularidad y definición de negocio sirve?
Muchos archivos pequeños Deuda operativa ¿Quién compacta, actualiza estadísticas y limpia huérfanos?
«Una copia para cada equipo» Impuesto de coordinación ¿Pueden compartir tabla, catálogo y política sin compartir motor?

6.6.2 Diagnóstico rápido

Todavía es un Data Lake consultable si hay objetos, Parquet, catálogo básico y motor, pero no existe un protocolo transaccional que publique versiones confiables de tabla.

Hay un Lakehouse funcional si los datos tabulares comparten formato de tabla, catálogo, gobierno y motores compatibles, con operación de calidad, mantenimiento y costo.

Conviene un Warehouse administrado cuando domina SQL sobre datos preparados, el equipo es pequeño y la simplicidad ofrece más retorno que la flexibilidad adicional.

Conviene evaluar Lakehouse cuando BI, ML y streaming necesitan reutilizar datos diversos; las copias, el movimiento o el almacenamiento propietario son el cuello de botella; y existe capacidad para operarlo.

6.6.3 Lista mínima de implementación

  1. Definir decisiones y SLO de frescura, calidad, costo y recuperación.
  2. Elegir almacenamiento, regiones, cifrado, retención y fronteras de red.
  3. Elegir formato de tabla y probar compatibilidad real con cada motor.
  4. Establecer catálogo, identidad, clasificación, permisos, linaje y propietarios.
  5. Diseñar contratos y estados de calidad; Medallion es una opción.
  6. Automatizar pruebas, compactación, estadísticas, retención y limpieza.
  7. Observar frescura, fallas, uso, rendimiento y costo por producto de datos.
  8. Preparar evolución compatible, rollback y continuidad.

La síntesis final es:

silos y copias
→ base común en objetos
→ archivos coordinados por snapshots
→ catálogo y permisos
→ motores distintos sobre contratos compartidos
→ mantenimiento y control del radio de impacto
→ elección condicionada por el caso

6.7 Bibliografía y guías oficiales de implementación

Las referencias siguientes son documentación primaria de los proveedores. Fueron consultadas el 30 de agosto de 2026.

6.7.1 Google Cloud

6.7.2 Amazon Web Services

6.7.3 Microsoft Azure y Fabric