Control de concurrencia para las tablas Delta

Cuando varios cuadernos de Fabric, canalizaciones o trabajos de Spark escriben en la misma tabla Delta al mismo tiempo, Delta Lake usa el control de concurrencia optimista (OCC) para mantener la tabla coherente. Cada transacción lee una instantánea, escribe nuevos archivos y, a continuación, valida que no se produjo ninguna confirmación en conflicto entre sí. Si se detecta un conflicto, la transacción falla y genera una excepción en lugar de corromper los datos.

Este artículo aborda patrones prácticos para gestionar escrituras simultáneas en Fabric. Para obtener una especificación completa del protocolo OCC, consulte Control de simultaneidad de Delta Lake (documentación de código abierto).

Niveles de aislamiento

Todas las tablas Delta usan el nivel de aislamiento Serializable. Serializable es el nivel más estricto y el único admitido. Garantiza que el resultado de las transacciones simultáneas sea idéntico a algún orden de ejecución secuencial.

Delta Lake también usa un nivel de SnapshotIsolation interno para las operaciones que no cambian los datos lógicos (como OPTIMIZE). SnapshotIsolation omite la comprobación de adición concurrente, lo que permite que la compactación se lleve a cabo sin entrar en conflicto con inserciones concurrentes. No se configura SnapshotIsolation directamente: Delta Lake la aplica automáticamente cuando corresponda.

Con el aislamiento Serializable, un anexado ciego simultáneo (INSERT INTO) puede entrar en conflicto con un MERGE o UPDATE que lee la misma partición.

Qué operaciones entran en conflicto

No todas las escrituras simultáneas entran en conflicto. El factor clave es si dos operaciones tocan los mismos archivos subyacentes.

Aislamiento de escritores con particiones

La manera más común de ejecutar DML simultáneo en la misma tabla sin conflictos es particionar la tabla por la columna que separa los escritores y, a continuación, incluir esa columna en cada condición de operación. Cuando cada escritor tiene como destino una partición diferente, las operaciones tocan conjuntos de archivos separados y no entran en conflicto.

Un escenario típico: varias canalizaciones, cada una de las cuales procesa datos de una unidad de negocio o inquilino diferente. Divida por esa dimensión y ancle el MERGE de cada canal a su partición.

-- Each pipeline targets its own partition, so concurrent runs don't conflict
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

# Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

// Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Para obtener más información sobre las estrategias de creación de particiones, consulte Creación de particiones para tablas Delta.

Reintento de confirmación integrado

Delta Lake reintenta automáticamente una confirmación cuando detecta que otra transacción se ha confirmado primero. En cada reintento, lee la confirmación ganadora, ejecuta el comprobador de conflictos y, si no existe ningún conflicto lógico, vuelve a intentar la confirmación en la siguiente versión disponible. Este proceso se repite de forma transparente sin ninguna acción del código.

Un conflicto lógico (por ejemplo, dos operaciones que vuelven a escribir el mismo archivo) no se pueden resolver automáticamente. El reintento genera una de las excepciones enumeradas en Excepciones de conflictos comunes. Sin embargo, muchas colisiones de versiones transitorias (como dos anexiones ciegas para la misma ranura de versión) se resuelven automáticamente y nunca se exponen a la aplicación.

Excepciones de conflictos comunes

Cuando se detecta un conflicto, Delta Lake genera una excepción específica. Comprender qué excepción ve ayuda a identificar la causa principal.

Estrategias comunes para evitar conflictos de escritura

Habilitación de la compactación automática

La compactación automática se ejecuta sincrónicamente como parte de las operaciones de escritura. La compactación sincrónica impide que los trabajos de compactación programados de forma independiente se superpongan con las operaciones de modificación de datos y, por lo tanto, provoquen excepciones de escritor concurrente.

Programar el mantenimiento fuera de las ventanas de escritura

OPTIMIZE y VACUUM pueden entrar en conflicto con las operaciones simultáneas de modificación de datos. En Fabric, programe trabajos de notebook o actividades de canalización para la compactación de tablas y VACUUM en periodos de baja actividad; por ejemplo, una vez finalizada la ingesta nocturna, en lugar de hacerlo durante esta.

Uso de patrones de anexión y combinación

Para la ingesta de alta concurrencia, cargue los datos sin procesar con escrituras de solo anexado en una tabla de preparación (sin posibilidad de conflictos) y, a continuación, ejecute una única tarea MERGE para consolidarlos en la tabla de destino. El patrón serializa la operación propensa a conflictos mientras mantiene el proceso de ingestión completamente en paralelo.

Adición de lógica de reintento para conflictos lógicos

El reintento de confirmación integrado controla las colisiones de versiones transitorias automáticamente, pero los conflictos lógicos, donde dos operaciones se superponen realmente, generan una excepción. Dado que Delta Lake nunca genera escrituras parciales, una transacción fallida puede reintentarse de forma segura a nivel de aplicación. Para las canalizaciones en las que se esperan conflictos lógicos ocasionales, envuelve la operación de escritura en una lógica de reintento:

from delta.exceptions import ConcurrentAppendException
import time

# Retry with backoff on transient concurrent write conflicts
max_retries = 3
for attempt in range(max_retries):
    try:
        spark.sql("MERGE INTO target USING source ON ...")
        break
    except ConcurrentAppendException:
        if attempt < max_retries - 1:
            time.sleep(2 ** attempt)
        else:
            raise

Elección de la estrategia de diseño correcta

La agrupación en clústeres líquidos y la creación de particiones resuelven diferentes problemas. La agrupación en clústeres líquidos optimiza el diseño de archivos para el rendimiento de lectura. La partición crea límites físicos que evitan conflictos entre escritores concurrentes. Si la carga de trabajo necesita ambos, particiónela por la columna de aislamiento del escritor y use Z-Order dentro de cada partición para mejorar el rendimiento de lectura.

Contenido relacionado

• Partición
• Agrupación en clústeres líquidos
• Combinación Low-Shuffle
• Compactación de tabla
• Z-Order
• Mantenimiento de tablas delta
• Interoperabilidad de Delta Lake
• Control de simultaneidad de Delta Lake (documentación de código abierto)