Delta Lake y el ecosistema de table formats

En la lección anterior exploramos Iceberg — el table format que nació en Netflix y se convirtió en estándar abierto. Pero no es el único. Delta Lake, creado por Databricks en 2019, fue el primero en popularizar la idea de "transacciones ACID sobre el data lake". Y aunque Iceberg ha ganado la guerra del ecosistema abierto, Delta Lake sigue siendo dominante en el universo Databricks — que es ENORME. Si trabajas con Databricks (y muchas empresas lo usan), Delta es tu formato nativo.

### Historia: por qué Databricks creó Delta Lake

Databricks tenía el mismo problema que Netflix: sus clientes usaban Spark sobre data lakes y sufrían escrituras parciales, datos corruptos, y falta de ACID. En 2019 lanzaron Delta Lake como proyecto open source. La filosofía de Delta es diferente a Iceberg: mientras Iceberg se diseñó como especificación vendor-neutral, Delta se diseñó como la capa de storage nativa de Databricks. Esto significa que Delta funciona mejor dentro del ecosistema Databricks, pero tiene menos soporte fuera de él.

### Cómo funciona Delta internamente

Delta Lake usa un "transaction log" — un directorio _delta_log/ dentro de la carpeta de la tabla con archivos JSON numerados secuencialmente. Cada archivo JSON es un commit que describe qué archivos se añadieron o eliminaron. Cada 10 commits se crea un "checkpoint" en formato Parquet para no tener que leer todos los JSONs desde el principio.

1# Estructura interna de una tabla Delta
2s3://lake/ventas_delta/
3  _delta_log/
4    00000000000000000000.json    # Commit 0: CREATE TABLE
5    00000000000000000001.json    # Commit 1: INSERT
6    00000000000000000002.json    # Commit 2: UPDATE
7    ...
8    00000000000000000010.checkpoint.parquet  # Checkpoint (resumen)
9  part-00000-xxx.snappy.parquet  # Archivos de datos
10  part-00001-xxx.snappy.parquet
11  part-00002-xxx.snappy.parquet

### MERGE INTO: el arma secreta de Delta

MERGE INTO es la operación más usada en Delta Lake y resuelve uno de los problemas más comunes en ETL: "si el registro existe, actualízalo; si no existe, insértalo" (upsert). En un data lake tradicional sin table format, esto requería leer toda la tabla, hacer un left join con los datos nuevos, y reescribir todo. Con MERGE, Delta lo maneja eficientemente.

1-- MERGE INTO: upsert eficiente en Delta Lake
2MERGE INTO lake.clientes AS target
3USING staging.clientes_nuevos AS source
4ON target.cliente_id = source.cliente_id
5WHEN MATCHED THEN
6    UPDATE SET
7        target.nombre = source.nombre,
8        target.email = source.email,
9        target.actualizado_en = current_timestamp()
10WHEN NOT MATCHED THEN
11    INSERT (cliente_id, nombre, email, creado_en)
12    VALUES (source.cliente_id, source.nombre, source.email, current_timestamp())
13WHEN NOT MATCHED BY SOURCE AND target.activo = true THEN
14    UPDATE SET target.activo = false;  -- Soft delete

Nota importante: Iceberg también soporta MERGE INTO desde Spark 3.x. No es exclusivo de Delta. Pero Delta lo popularizó primero y su implementación está más optimizada en Databricks.

### OPTIMIZE y VACUUM: mantenimiento de tablas

Delta Lake tiene dos comandos de mantenimiento fundamentales:

• ▹OPTIMIZE: compacta archivos pequeños en archivos más grandes. Resuelve el small file problem. Puede incluir Z-ORDER para co-localizar datos que se filtran juntos.
• ▹VACUUM: elimina archivos de datos que ya no son referenciados por ninguna versión activa del log. Libera espacio en disco. Por defecto retiene 7 días para permitir time travel.

1-- OPTIMIZE: compactar small files
2OPTIMIZE lake.ventas;
3
4-- OPTIMIZE con Z-ORDER: co-localizar por columnas frecuentes en filtros
5OPTIMIZE lake.ventas
6  ZORDER BY (fecha, pais);
7
8-- VACUUM: eliminar archivos viejos (no referenciados)
9-- Retiene 168 horas (7 días) por defecto
10VACUUM lake.ventas;
11
12-- VACUUM agresivo (CUIDADO: pierdes time travel)
13VACUUM lake.ventas RETAIN 24 HOURS;
14
15-- Ver historial de la tabla
16DESCRIBE HISTORY lake.ventas;

### Delta vs Iceberg: comparación objetiva

### Apache Hudi: el tercer contendiente

Hay un tercer table format que merece mención: Apache Hudi (Hadoop Upserts Deletes Incrementals), creado por Uber en 2016. Hudi se enfoca en streaming e ingestión incremental — su punto fuerte es absorber CDC (Change Data Capture) de bases operacionales con baja latencia. Si tu caso de uso principal es "replicar una base de datos PostgreSQL al lake en near-real-time", Hudi es una opción sólida. Sin embargo, su ecosistema es más pequeño que Iceberg y Delta.

### El lakehouse: la convergencia final

El paradigma "lakehouse" es la convergencia natural de todo lo que hemos visto: un data lake (storage barato, formatos abiertos) + un table format (ACID, schema, time travel) + un motor de consultas rápido = un sistema que tiene las ventajas del lake Y del warehouse sin los inconvenientes de ninguno. Ya no necesitas un data lake para almacenar y un warehouse separado para consultar. El lakehouse hace ambas cosas.

En la práctica, un lakehouse es: archivos Parquet en S3 + Iceberg/Delta para ACID + Trino/Spark/DuckDB para consultas + un catálogo para descubrimiento. Los datos viven en un solo lugar (el lake), pero se comportan como una base de datos (transacciones, esquema, permisos).