Los Deletion Vectors (DV) son una de las funcionalidades más relevantes en Delta Lake para acelerar las operaciones de modificación de datos.

¿Cómo funcionan los Deletion Vectors?

Tradicionalmente, Delta Lake utiliza un enfoque Copy-on-Write: cuando se elimina, actualiza o mergea una fila dentro de un archivo Parquet, el archivo completo debe reescribirse, excluyendo las filas afectadas. Esto es costoso en E/S, especialmente para archivos grandes o modificaciones puntuales.

Con los Deletion Vectors, Delta introduce un modelo Merge-on-Read:

• Los archivos Parquet originales no se reescriben.

• Las filas eliminadas se registran en un archivo auxiliar comprimido (un .bin).

• Durante la lectura, el motor aplica el vector de eliminación y descarta esas posiciones lógicamente.

• El coste de reescritura total se pospone a operaciones posteriores como OPTIMIZE o REORG TABLE ... APPLY (PURGE).

Este enfoque reduce de manera drástica la E/S asociada a las operaciones de DELETE/UPDATE/MERGE.

Ejemplo Práctico en Microsoft Fabric

Preparación y creación de tablas

data = [
    (1, "Ana", "Ventas"), 
    (2, "Luis", "IT"), 
    (3, "Marta", "Marketing"), 
    (4, "Carlos", "Ventas"), 
    (5, "Elena", "IT")
]
columns = ["id", "nombre", "departamento"]
df = spark.createDataFrame(data, columns)

# Tabla SIN Deletion Vectors (Comportamiento Predeterminado)
df.coalesce(1).write.format("delta").mode("overwrite").saveAsTable("tabla_sin_dv")

# Tabla CON Deletion Vectors
df.coalesce(1).write.format("delta").mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("delta.enableDeletionVectors", "true") \
  .saveAsTable("tabla_con_dv")

Comportamiento SIN Deletion Vectors (Copy-on-Write)

Tras ejecutar DELETE FROM tabla_sin_dv WHERE id = 3, Delta:

1. Marca el archivo original como remove en _delta_log.

2. Genera un archivo Parquet nuevo con 4 filas.

3. Registra el add correspondiente.

{
    "operationMetrics": {
        "numRemovedFiles": "1",
        "numCopiedRows": "4",
        "numDeletionVectorsAdded": "0",
        "numDeletedRows": "1",
        "numAddedFiles": "1"
    }
}

Comportamiento CON Deletion Vectors (Merge-on-Read)

Tras el mismo DELETE en la tabla con DV habilitado, Delta:

1. Mantiene el archivo Parquet original.

2. Añade un archivo deletion_vector_....bin con la posición invalidada.

3. Actualiza el commit indicando el DeletionVector aplicado.

{
    "operationMetrics": {
        "numRemovedFiles": "0",
        "numCopiedRows": "0",
        "numDeletionVectorsAdded": "1",
        "numDeletedRows": "1",
        "numAddedFiles": "0"
    }
}

Resumen comparativo

Análisis del impacto en rendimiento

Para medir el impacto real, utilicé un dataset idéntico de 100 millones de filas en dos tablas Delta. Los resultados:

Resultados principales

• DELETE (1 fila): DV realiza el borrado 6.2x más rápido

• DELETE (25M): DV realiza el borrado 3.2x más rápido

• UPDATE (5M): DV es 3.5x más lento

• MERGE (2M): rendimiento similar, ligera penalización con DV

• OPTIMIZE: DV es 208x más rápido

• VACUUM: DV es 1.6x más rápido

• SELECT COUNT(1): DV es 5.9x más lento

• SELECT SUM(price): DV es 1.8x más lento

El beneficio de DV es enorme en escritura, pero las lecturas pueden penalizarse seriamente.

¿Por qué las lecturas son más lentas con Deletion Vectors?

La causa es el modelo Merge-on-Read, donde el lector debe:

1. Leer los archivos Parquet originales.

2. Leer los vectores de eliminación asociados.

3. Combinar ambas fuentes y filtrar las filas inválidas.

Cuantos más deletes/updates acumula una tabla, más trabajo deben hacer los lectores.

El remedio: compactación

Después de ejecutar:

OPTIMIZE <tabla>

o

REORG TABLE <tabla> APPLY (PURGE)

la tabla queda físicamente limpia y las lecturas vuelven a ser rápidas.

¿Cuándo habilitar Deletion Vectors?

Casos recomendados

• Capas Bronze y Silver con ingestas frecuentes, deletes/updates parciales o merges incrementales.

• Workloads donde la E/S es el cuello de botella.

• Cuando hay una estrategia de optimización establecida con OPTIMIZE + VACUUM periódicos.

Casos NO recomendados

• Tablas Gold, modelos de agregación, capas analíticas puras, dashboards con baja latencia o Power BI Direct Lake. Aquí Copy-on-Write suele ser más eficiente.

• Fabric Copy Data Activity: ignora Deletion Vectors y pueden reaparecer filas “borradas”.

Conclusión

Los Deletion Vectors mejoran la eficiencia de las operaciones de escritura de forma drástica. Sin embargo, su adopción implica entender las implicaciones del modelo Merge-on-Read en términos de rendimiento de lectura:

• DV aceleran la escritura

• Penalizan las lecturas si no hay mantenimiento

• Ofrecen el mejor rendimiento total cuando se combinan con OPTIMIZE