Delta Lake vs Apache Iceberg en 2026: Arquitectura Lakehouse y Preguntas de Entrevista

Comparación técnica completa entre Delta Lake y Apache Iceberg para arquitecturas lakehouse modernas. Guía práctica con ejemplos de código y preguntas de entrevista para data engineering.

Delta Lake vs Apache Iceberg en 2026: Arquitectura Lakehouse y Preguntas de Entrevista

Delta Lake y Apache Iceberg representan los dos formatos de tabla abiertos dominantes que impulsan las arquitecturas data lakehouse modernas en 2026. Ambas tecnologías resuelven el mismo problema fundamental—aportar transacciones ACID, evolución de esquemas y viaje en el tiempo al almacenamiento de objetos en la nube—pero adoptan enfoques arquitectónicos diferentes que importan para las cargas de trabajo en producción.

Comparación Rápida

Delta Lake destaca en entornos nativos de Spark con integración estrecha con Databricks, mientras que Iceberg ofrece compatibilidad más amplia con motores (Spark, Trino, Flink, Dremio) y particionamiento más flexible a través de particiones ocultas y evolución de particiones.

Delta Lake vs Iceberg: Diferencias Arquitectónicas Fundamentales

Ambos formatos almacenan datos como archivos Parquet en almacenamiento de objetos, pero sus capas de metadatos difieren significativamente.

Delta Lake utiliza un registro de transacciones (_delta_log/) que contiene archivos JSON que registran cada cambio. Cada commit crea un nuevo archivo JSON, y los checkpoints periódicos consolidan estos archivos en Parquet para lecturas más rápidas. La especificación del protocolo Delta Lake define características de lectura/escritura versionadas para compatibilidad hacia adelante.

Apache Iceberg mantiene una jerarquía de archivos de metadatos: un archivo JSON de metadatos que apunta a listas de manifiestos, que a su vez apuntan a manifiestos que contienen estadísticas a nivel de archivo. Este diseño permite el predicate pushdown en la etapa de planificación—el motor de consultas omite archivos completos antes de leer datos.

| Característica | Delta Lake | Apache Iceberg | |----------------|------------|----------------| | Registro de Transacciones | JSON + checkpoints Parquet | JSON metadatos + archivos de manifiesto | | Evolución de Particiones | Requiere reescritura | En su lugar sin reescritura | | Soporte de Motores | Spark, Trino, Flink | Spark, Trino, Flink, Dremio, Athena | | Viaje en el Tiempo | Basado en versiones | Basado en snapshots con branch/tag | | Evolución de Esquema | Agregar/renombrar columnas | Agregar/renombrar/reordenar/ampliar columnas |

Particiones Ocultas: La Ventaja Clave de Iceberg

El particionamiento tradicional estilo Hive expone las columnas de partición en las consultas (WHERE year=2026 AND month=7), acoplando la disposición física a la sintaxis SQL. Las particiones ocultas de Iceberg desacoplan estas preocupaciones.

python
# iceberg_partition_example.py
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import StringType, TimestampType, LongType, NestedField
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import MonthTransform

# Definición del esquema
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "event_time", TimestampType(), required=True),
    NestedField(3, "user_id", StringType(), required=True),
    NestedField(4, "event_type", StringType(), required=False),
)

# Partición oculta sobre el mes extraído de event_time
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # campo event_time
        field_id=1000,
        transform=MonthTransform(),
        name="event_time_month"
    )
)

# Creación de la tabla con particionamiento oculto
catalog = load_catalog("production")
catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec
)

Los usuarios escriben WHERE event_time > '2026-01-01' e Iceberg elimina automáticamente las particiones irrelevantes. Este enfoque simplifica las consultas y permite la evolución de particiones sin reescribir datos.

Delta Lake: Gestión del Registro de Transacciones

El mecanismo de registro de transacciones de Delta Lake proporciona trazabilidad completa de los cambios. Cada operación genera un archivo JSON atómico en el directorio _delta_log.

python
# delta_transaction_log.py
from delta import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("DeltaTransactionDemo") \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# Creación de una tabla Delta
data = [(1, "2026-07-15", "click"), (2, "2026-07-16", "purchase")]
df = spark.createDataFrame(data, ["id", "date", "event"])
df.write.format("delta").save("/data/events")

# Acceso al historial de transacciones
delta_table = DeltaTable.forPath(spark, "/data/events")
history = delta_table.history()
history.select("version", "timestamp", "operation", "operationMetrics").show()

Los checkpoints de Parquet se crean cada 10 commits por defecto, optimizando el rendimiento de lectura al evitar la reconstrucción del estado a partir de múltiples archivos JSON.

Evolución de Esquema: Comparación Práctica

La evolución de esquema representa un caso de uso crítico para los pipelines de datos en producción. Ambos formatos soportan la adición de columnas, pero Iceberg ofrece capacidades más avanzadas.

sql
-- Evolución de esquema Iceberg
ALTER TABLE analytics.events ADD COLUMN device_type STRING;
ALTER TABLE analytics.events ALTER COLUMN event_type SET NOT NULL;
ALTER TABLE analytics.events RENAME COLUMN event_type TO action_type;

-- Reordenamiento de columnas (específico de Iceberg)
ALTER TABLE analytics.events ALTER COLUMN device_type FIRST;
ALTER TABLE analytics.events ALTER COLUMN user_id AFTER event_id;
sql
-- Evolución de esquema Delta Lake
ALTER TABLE events ADD COLUMNS (device_type STRING);
-- El renombrado requiere habilitar column mapping
ALTER TABLE events SET TBLPROPERTIES ('delta.columnMapping.mode' = 'name');
ALTER TABLE events RENAME COLUMN event_type TO action_type;

Delta Lake requiere la habilitación explícita del column mapping para el renombrado, mientras que Iceberg lo soporta nativamente a través de su sistema de identificadores de campo.

Viaje en el Tiempo y Gestión de Versiones

Ambos formatos permiten consultar estados históricos de los datos, funcionalidad esencial para auditoría, depuración y reproducibilidad de análisis.

python
# time_travel_comparison.py

# Delta Lake - Viaje en el tiempo
df_v1 = spark.read.format("delta").option("versionAsOf", 1).load("/data/events")
df_timestamp = spark.read.format("delta").option("timestampAsOf", "2026-07-15").load("/data/events")

# Restauración a una versión anterior
delta_table = DeltaTable.forPath(spark, "/data/events")
delta_table.restoreToVersion(1)
python
# Iceberg - Viaje en el tiempo con snapshots
from pyiceberg.catalog import load_catalog

catalog = load_catalog("production")
table = catalog.load_table("analytics.events")

# Lista de snapshots disponibles
for snapshot in table.snapshots():
    print(f"Snapshot {snapshot.snapshot_id}: {snapshot.timestamp_ms}")

# Lectura de un snapshot específico
df = spark.read \
    .format("iceberg") \
    .option("snapshot-id", 3821550127947089987) \
    .load("analytics.events")

# Branches y tags de Iceberg (funcionalidad avanzada)
# CREATE TAG production_v1 FOR TABLE analytics.events
# CREATE BRANCH feature_test FOR TABLE analytics.events

Iceberg ofrece funcionalidades adicionales con branches y tags, permitiendo workflows de desarrollo aislados sin duplicar datos.

Optimización y Mantenimiento de Tablas

Las operaciones de mantenimiento son cruciales para mantener el rendimiento de las tablas lakehouse a lo largo del tiempo.

python
# delta_optimization.py
from delta.tables import DeltaTable

delta_table = DeltaTable.forPath(spark, "/data/events")

# Compactación de archivos pequeños
delta_table.optimize().executeCompaction()

# Z-Ordering para mejorar el data skipping
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# Vacuum para eliminar archivos obsoletos
delta_table.vacuum(168)  # Retención de 7 días en horas

# Estadísticas de columnas
spark.sql("ANALYZE TABLE events COMPUTE STATISTICS FOR ALL COLUMNS")
python
# iceberg_maintenance.py

# Compactación Iceberg via Spark
spark.sql("""
    CALL system.rewrite_data_files(
        table => 'analytics.events',
        options => map('target-file-size-bytes', '134217728')
    )
""")

# Expiración de snapshots
spark.sql("""
    CALL system.expire_snapshots(
        table => 'analytics.events',
        older_than => TIMESTAMP '2026-07-01 00:00:00',
        retain_last => 5
    )
""")

# Eliminación de archivos huérfanos
spark.sql("""
    CALL system.remove_orphan_files(
        table => 'analytics.events',
        older_than => TIMESTAMP '2026-07-01 00:00:00'
    )
""")

Preguntas de Entrevista Data Engineering: Arquitectura Lakehouse

Las entrevistas de data engineering en 2026 incluyen frecuentemente preguntas sobre arquitecturas lakehouse. Estos son los temas técnicos esenciales a dominar.

Pregunta 1: Explicar las ventajas de las particiones ocultas de Iceberg

La respuesta esperada debe cubrir: el desacoplamiento entre la disposición física y la sintaxis SQL, la eliminación automática de particiones por el motor de consultas, y la posibilidad de evolucionar el esquema de particionamiento sin reescribir los datos existentes.

Pregunta 2: ¿Cómo garantiza Delta Lake las transacciones ACID?

Delta Lake utiliza bloqueo optimista con un registro de transacciones append-only. Cada commit verifica que la versión base no haya cambiado desde la lectura. En caso de conflicto, la operación falla y puede reintentarse. Los checkpoints Parquet permiten una reconstrucción rápida del estado.

Pregunta 3: ¿Cuándo elegir Iceberg en lugar de Delta Lake?

Iceberg conviene más cuando: múltiples motores de consulta deben acceder a los mismos datos (Spark, Trino, Flink), la evolución de particiones es una necesidad recurrente, o la organización prefiere un formato verdaderamente abierto sin dependencia de un proveedor específico.

python
# interview_code_example.py
# Pregunta: Implementar un upsert con Delta Lake

from delta.tables import DeltaTable

def upsert_events(spark, source_df, target_path):
    """Merge incremental events into Delta table."""
    target_table = DeltaTable.forPath(spark, target_path)
    
    target_table.alias("target").merge(
        source_df.alias("source"),
        "target.event_id = source.event_id"
    ).whenMatchedUpdate(set={
        "event_time": "source.event_time",
        "event_type": "source.event_type",
        "updated_at": "current_timestamp()"
    }).whenNotMatchedInsert(values={
        "event_id": "source.event_id",
        "event_time": "source.event_time",
        "event_type": "source.event_type",
        "created_at": "current_timestamp()",
        "updated_at": "current_timestamp()"
    }).execute()

Pregunta 4: Describir la estrategia de data skipping

Ambos formatos mantienen estadísticas min/max por archivo. Al ejecutar una consulta con predicados, el motor compara los valores de los predicados con las estadísticas y elimina los archivos que no pueden contener coincidencias. El Z-Ordering (Delta) y el sorting (Iceberg) mejoran la eficiencia agrupando valores similares.

¿Listo para aprobar tus entrevistas de Data Engineering?

Practica con nuestros simuladores interactivos, flashcards y tests técnicos.

Explorar Data Engineering

Integración con Catálogos de Metadatos

Los catálogos de metadatos centralizan la gestión de tablas lakehouse y permiten el descubrimiento de datos a escala organizacional.

python
# catalog_integration.py

# Configuración Unity Catalog para Delta Lake
spark = SparkSession.builder \
    .config("spark.sql.catalog.unity", "com.databricks.sql.managedcatalog.UnityCatalogSpark") \
    .config("spark.databricks.unityCatalog.enabled", "true") \
    .getOrCreate()

# Configuración Iceberg con AWS Glue Catalog
spark = SparkSession.builder \
    .config("spark.sql.catalog.glue_catalog", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.glue_catalog.warehouse", "s3://datalake/warehouse") \
    .config("spark.sql.catalog.glue_catalog.catalog-impl", "org.apache.iceberg.aws.glue.GlueCatalog") \
    .config("spark.sql.catalog.glue_catalog.io-impl", "org.apache.iceberg.aws.s3.S3FileIO") \
    .getOrCreate()

# Configuración Iceberg con REST Catalog (Polaris, Tabular)
spark = SparkSession.builder \
    .config("spark.sql.catalog.rest_catalog", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.rest_catalog.type", "rest") \
    .config("spark.sql.catalog.rest_catalog.uri", "https://catalog.example.com") \
    .getOrCreate()

Rendimiento: Benchmarks y Consideraciones

El rendimiento depende fuertemente del caso de uso específico, el tamaño de los datos y el motor de consultas utilizado.

Para lecturas analíticas intensivas, Iceberg puede ofrecer ventaja gracias a su planificación de consultas más eficiente basada en manifiestos. Para workloads de streaming con micro-batches frecuentes, Delta Lake con su registro de transacciones optimizado puede ser más eficiente.

python
# performance_monitoring.py

# Métricas Delta Lake
spark.sql("DESCRIBE HISTORY events").show()
spark.sql("DESCRIBE DETAIL events").show()

# Métricas Iceberg
spark.sql("SELECT * FROM analytics.events.metadata_log_entries").show()
spark.sql("SELECT * FROM analytics.events.manifests").show()
spark.sql("SELECT * FROM analytics.events.files").show()

Conclusión

Delta Lake y Apache Iceberg representan dos enfoques maduros para la arquitectura lakehouse en 2026. Delta Lake ofrece integración nativa con el ecosistema Databricks y Spark, mientras que Iceberg prioriza la interoperabilidad multi-motor y la flexibilidad del particionamiento.

La elección entre estas tecnologías depende principalmente del ecosistema existente, los requisitos de interoperabilidad y los patrones de acceso a datos. Ambos formatos continúan evolucionando con funcionalidades convergentes, como Delta Lake UniForm que permite la lectura de tablas Delta a través de las APIs de Iceberg.

Para las entrevistas de data engineering, el dominio de los conceptos fundamentales—transacciones ACID sobre almacenamiento de objetos, evolución de esquemas, viaje en el tiempo y optimización del rendimiento—sigue siendo más importante que el conocimiento profundo de un formato específico.

Compartir

Artículos relacionados

Diagrama de la arquitectura de Snowflake que muestra las capas de almacenamiento, cómputo con virtual warehouses y cloud services

Snowflake en 2026: arquitectura, SQL y preguntas de entrevista para ingenieros de datos

Guía 2026 sobre la arquitectura de Snowflake para ingenieros de datos: cómo se separan el almacenamiento y el cómputo, cómo funcionan los virtual warehouses y las micro-partitions, y las preguntas de entrevista que ponen a prueba la experiencia en producción.

Tutorial Apache Airflow orquestación de pipelines DAG 2026

Apache Airflow en 2026: orquestación de pipelines, DAG y preguntas de entrevista

Dominar Apache Airflow 3.2 con este tutorial práctico: escritura de DAG con el Task SDK, patrones de orquestación de pipelines, particiones de assets y preguntas reales de entrevista para puestos de data engineering en 2026.

Tutorial de dbt data build tool transformaciones y pruebas de datos 2026

dbt en 2026: transformaciones de datos, pruebas y preguntas de entrevista

Tutorial práctico de dbt (data build tool): transformaciones SQL, modelado por capas, estrategias de pruebas y preguntas reales de entrevista para roles de data engineering en 2026.