Compartir a través de

Transactions

Importante

Las transacciones que escriben en tablas delta administradas por el catálogo de Unity se encuentran en versión preliminar pública.

Las transacciones que escriben en las tablas Iceberg gestionadas por Unity Catalog se encuentran en versión preliminar privada. Para unirse a esta versión preliminar, envíe el formulario de inscripción de las tablas Iceberg administradas.

Las transacciones permiten coordinar las operaciones entre varias instrucciones SQL y tablas. Todos los cambios se realizan correctamente juntos o se revierten, lo que garantiza la coherencia de los datos en las operaciones y tablas. Las transacciones proporcionan garantías ACID: atomicidad, coherencia, aislamiento y durabilidad. Consulte ¿Cuáles son las garantías ACID en Azure Databricks?. Las transacciones se pueden usar con procedimientos almacenados y scripting de SQL para crear cargas de trabajo de almacenamiento críticas.

En el ejemplo siguiente se muestra una transacción:

BEGIN ATOMIC
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  INSERT INTO audit_log VALUES (1, 2, 100, current_timestamp());
END;

Las tres instrucciones se realizan juntas. Si se produce un error en alguna instrucción, todos los cambios revierten y Databricks finaliza la transacción sin efectos secundarios.

Para la práctica práctica con transacciones, consulte Tutorial: Coordinar transacciones entre tablas.

Requisitos

Para ejecutar transacciones que abarcan varias instrucciones o varias tablas:

  • Todas las tablas escritas en deben:
  • Usa la computación admitida.
    • Para transacciones no interactivas, use cualquier almacenamiento de SQL, proceso sin servidor o clúster que ejecute Databricks Runtime 18.0 y versiones posteriores.
    • En el caso de las transacciones interactivas, use cualquier almacenamiento de SQL.
    • Para las transacciones en activos compartidos de Delta Sharing, use Databricks Runtime 18.1 y versiones posteriores.

Modos de transacción

Azure Databricks admite dos modos de transacción:

Modo Sintaxis Confirmar Reversión Más adecuado para
No interactivo Instrucción compuesta ATOMIC Automático en caso de éxito Automático en caso de error Secuencias fijas, trabajos programados
Interactivo BEGIN TRANSACTION; COMMIT; Manual Manual Lógica condicional, validación y depuración, JDBC, ODBC, PyDBC

Para obtener una sintaxis detallada, ejemplos y patrones de uso para ambos modos, consulte Modos de transacción.

Operaciones soportadas

Puede usar las siguientes operaciones dentro de las transacciones:

Operación Descripción
SELECT Consulta de datos y validación de resultados
VALUES cláusula Generación de datos de prueba o valores constantes
INSERT (incluidas todas las variantes) Agregar nuevas filas
UPDATE Modificar filas existentes
COPY INTO Carga de datos de un archivo en una tabla Delta
DELETE FROM Eliminar filas
MERGE INTO Patrones de inserción, actualización y eliminación que combinan acciones de insert, update y delete

Leer fuentes en transacciones

Las transacciones pueden leer desde tablas de catálogo de Unity (Delta y Iceberg), tablas de streaming, vistas y vistas materializadas. Para leer desde orígenes no transaccionales, use la indicación allow_nontransactional_reads.

Lectura de orígenes no transaccionales

Para leer desde orígenes no transaccionales, como archivos Parquet, archivos Avro y tablas federadas mediante JDBC, use la allow_nontransactional_reads sugerencia, tal como se muestra en el siguiente ejemplo:

BEGIN TRANSACTION;

-- Read from a non-transactional Parquet source
INSERT INTO transactional_table
SELECT col1, col2
FROM parquet.`/path/to/data`
WITH (allow_nontransactional_reads = true);

-- Read from a managed Delta table (no hint needed)
INSERT INTO another_table
SELECT * FROM managed_delta_table;

COMMIT;

Advertencia

Las lecturas no transaccionales no son repetibles. Los cambios simultáneos en los datos de origen durante la transacción pueden dar lugar a lecturas incoherentes.

Aislamiento de transacciones

Las transacciones proporcionan lecturas consistentes en todas las declaraciones. Al acceder a una tabla en una transacción, Azure Databricks captura una instantánea coherente de esa tabla al principio de acceso. Todas las lecturas posteriores de esa tabla usan esta instantánea, por lo que las lecturas siguen siendo coherentes aunque otros usuarios modifiquen simultáneamente las mismas tablas.

Ejemplo:

BEGIN TRANSACTION;

-- First access to products table captures snapshot
SELECT * FROM products WHERE product_id = 1001;

-- Another user updates product 1001

-- Still reads the same snapshot (repeatable read)
SELECT * FROM products WHERE product_id = 1001;

COMMIT;

Detección y simultaneidad de conflictos

Azure Databricks usa el control de la simultaneidad optimista. Las transacciones continúan sin bloqueo, y los conflictos se detectan en el momento de confirmación. Cuando se confirma, Azure Databricks comprueba si otras transacciones modificaron los mismos datos una vez iniciada la transacción. Si existen conflictos, se produce un error en la transacción. En el caso de las transacciones no interactivas, la reversión también se produce automáticamente. Para las transacciones interactivas, debe ejecutarse ROLLBACK explícitamente para borrar el estado de la transacción antes de comenzar una nueva transacción.

Las transacciones no interactivas admiten la concurrencia a nivel de fila. Dos transacciones pueden modificar filas diferentes en el mismo archivo de datos sin entrar en conflicto cuando la simultaneidad de nivel de fila está habilitada en las tablas de destino.

Las transacciones que son interactivas admiten la simultaneidad a nivel de tabla.

Escenarios de conflicto

Escenario Descripción
Conflictos de escritura y escritura Dos transacciones actualizan o eliminan las mismas filas.
Conflictos de lectura y escritura Otra transacción modificó las filas que su transacción leyó. Solo se aplica al aislamiento serializable.
Conflictos de lectura fantasma Otra transacción añadió nuevas filas que coincidían con un predicado que tu transacción leyó. Se aplica a los niveles de aislamiento WriteSerializable y Serializable.
Conflictos de metadatos Otra transacción cambió el esquema o las propiedades de la tabla.

Para obtener más información sobre los niveles de aislamiento y la resolución de conflictos para las transacciones, consulte Modos de transacción. Para obtener información sobre los niveles de aislamiento y el comportamiento de los conflictos de escritura en las tablas Delta Lake en Azure Databricks, consulte Recomendaciones de optimización en Azure Databricks.

Cómo aparecen las transacciones en el registro delta

Cada transacción correcta aparece como una sola entrada en el registro delta de la tabla, independientemente de cuántas instrucciones individuales se ejecutaron dentro de la transacción. Esto proporciona una pista de auditoría limpia y simplifica las operaciones de reversión.

Las operaciones individuales dentro de una transacción están disponibles como metadatos JSON en la entrada de registro Delta para la transacción.

Manejo de errores y restauración

En la tabla siguiente se describe cómo se producen las reversiones de errores para ambos tipos de transacción:

Escenario Comportamiento de transacciones no interactivas Comportamiento de transacciones interactivas
Fallo de declaración Cualquier instrucción que provoque un error provoca una reversión automática inmediata. Debe explícitamente ejecutar ROLLBACK para descartar los cambios si la sesión sigue activa.
Lógica de validación errónea o reglas de negocios Use SIGNAL para iniciar una excepción y desencadenar la reversión automática. Ejecute ROLLBACK para descartar los cambios.
Desconexión de sesión La transacción se revierte automáticamente. La transacción se revierte automáticamente.
Tiempo de espera La reversión ocurre de manera automática tras un total de 48 horas. Revierte automáticamente después de 10 minutos de inactividad o 48 horas de duración total (consulte Limitaciones). La transacción finaliza sin efectos secundarios, pero debe ejecutar explícitamente ROLLBACK para borrar el estado de la transacción si la sesión sigue activa.

En el caso de las transacciones interactivas, puede revertir explícitamente mediante la instrucción ROLLBACK . Esto resulta útil cuando desea descartar los cambios en función de la lógica de validación o las reglas de negocios, o después de un error de instrucción cuando la sesión permanece activa.

procedimientos recomendados

Siga estos procedimientos para reducir los conflictos y optimizar el rendimiento de las transacciones.

Evitación de conflictos

  • Mantener las transacciones cortas: las transacciones que se prolongan aumentan la probabilidad de conflicto y mantienen los recursos ocupados por más tiempo.
  • Validar temprano: comprobar las condiciones previas al principio de una transacción para detectar fallos rápidamente.
  • Databricks recomienda transacciones no interactivas para la mayoría de los casos de uso: las transacciones no interactivas usan simultaneidad de nivel de fila. Consulte Transacciones no interactivas.
  • Reintento en conflictos: cuando se producen conflictos, vuelva a intentar la transacción con datos nuevos.

Uso de transacciones de diferentes clientes

Las transacciones funcionan en varias interfaces de cliente:

Limitaciones

Las siguientes limitaciones se aplican a las transacciones que abarcan varias tablas:

Limitación Descripción
Conflictos de transacciones interactivas Transacciones interactivas (BEGIN TRANSACTION; ... COMMIT;) usan una detección de conflictos más conservadora que las transacciones no interactivas y pueden entrar en conflicto a nivel de tabla, excepto en las INSERT operaciones que no leen de la tabla de destino. Use transacciones no interactivas (instrucción compuesta ATOMIC) cuando es importante la detección de conflictos a nivel de fila. Consulte Transacciones no interactivas.
Objetivos de escritura Se puede escribir solo en tablas Delta, administradas por el catálogo de Unity, o en tablas Iceberg que tengan habilitada la característica de tabla catalogManaged. Consulte Confirmaciones administradas por catálogo.
Solo operaciones DML Las transacciones admiten SELECT, INSERT, UPDATEDELETE, , COPY INTOy MERGE. Ejecute operaciones DDL, como CREATE TABLE, ALTER TABLEo DROP TABLE, fuera de las transacciones.
No se admiten las operaciones de metadatos Las operaciones de metadatos no funcionan dentro de transacciones independientemente del protocolo. Esto incluye llamadas a metadatos basadas en RPC de Thrift (como métodos JDBC DatabaseMetaData y funciones de catálogo ODBC), comandos basados en SQL (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) y consultas SELECT en tablas information_schema o tablas del sistema. Ejecute operaciones de metadatos fuera de las transacciones.
COPY INTO simultaneidad Una transacción que ejecuta un comando COPY INTO falla si otro comando COPY INTO se ejecuta concurrentemente para escribir en la misma tabla y se confirma primero.
Las operaciones de escritura en streaming no son compatibles No se admiten escrituras transaccionales en tablas de streaming.
No se admiten tablas RLS y CLM Las tablas con filtros de fila y máscaras de columna no pueden participar en transacciones.
Límites de tabla y vista Una transacción puede leer o escribir hasta 100 tablas y puede leer hasta 100 vistas. Cada tabla puede tener hasta 100 confirmaciones intermedias dentro de una transacción.
No se admite el viaje en el tiempo No se puede usar viaje en el tiempo dentro de una transacción.
Tiempo de espera de inactividad Las transacciones interactivas se deshacen después de 10 minutos de inactividad. La transacción finaliza sin efectos secundarios, pero debe ejecutar explícitamente ROLLBACK para borrar el estado de la transacción si la sesión sigue activa.
Duración máxima Todas las transacciones se revierten automáticamente después de 48 horas de duración total. En el caso de las transacciones interactivas, la transacción finaliza sin efectos secundarios, pero debe ejecutar explícitamente ROLLBACK para borrar el estado de la transacción si la sesión sigue activa.
Requisito de tablas compartidas de Delta Sharing Los proveedores de delta Sharing deben compartir una tabla WITH HISTORY para permitir que los destinatarios ejecuten transacciones en ella. Los destinatarios pueden ejecutar transacciones mediante cualquier tipo de capacidad de cálculo.
Restricciones de cómputo para destinatarios de Delta Sharing Los destinatarios de Azure Databricks solo pueden ejecutar transacciones en vistas compartidas, vistas materializadas, tablas de streaming y tablas externas que no son de Iceberg. Los destinatarios de la misma cuenta de Azure Databricks que su proveedor deben usar la computación compartida o sin servidor. Los destinatarios en otra cuenta deben usar cómputo sin servidor.
Conflicto de tabla de origen de uso compartido delta Los destinatarios de delta Sharing no pueden hacer referencia a una vista compartida ni a una tabla compartida que haga referencia a la misma tabla de origen dentro de una sola transacción.

Pasos siguientes

  • Last updated on