Транзакции

Это важно

Транзакции, записываемые в управляемые таблицы Iceberg каталога Unity, находятся в закрытой предварительной версии. Чтобы присоединиться к этой предварительной версии, отправьте форму регистрации на предварительный просмотр управляемых таблиц Iceberg.

Транзакции позволяют координировать операции в нескольких инструкциях и таблицах SQL. Все изменения успешно выполняются вместе или откатываются вместе, обеспечивая согласованность данных в операциях и таблицах. Транзакции включают свойства ACID: атомарность, согласованность, изоляцию и устойчивость. См. В чем состоят гарантии ACID на Azure Databricks?.

Транзакции можно использовать с хранимыми процедурами и скриптами SQL для создания критически важных рабочих нагрузок хранения.

В следующем примере показана транзакция:

Неинтерактивный

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;

Interactive

BEGIN TRANSACTION;
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());
COMMIT;

Все три выражения выполняются вместе. Если любая инструкция завершается ошибкой, все изменения отката и Databricks завершает транзакцию без побочных эффектов.

Практические рекомендации по транзакциям см. в руководстве по координации транзакций между таблицами.

Требования

Выполнение транзакций, охватывающих несколько инструкций или несколько таблиц:

  • Все таблицы, в которые выполняется запись, должны:
  • Используйте поддерживаемые вычислительные ресурсы:
    • Для неинтерактивных транзакций используйте любое хранилище SQL, бессерверные вычисления или кластер под управлением Databricks Runtime 18.0 и более поздних версий.
    • Для интерактивных транзакций используйте любое хранилище SQL.
    • Для транзакций в общих ресурсах OpenSharing используйте Databricks Runtime 18.1 и более поздних версий.

Режимы транзакций

Azure Databricks поддерживает два режима транзакций:

Режим Синтаксис Зафиксировать Откат лучше всего подходит для
Неинтерактивный ATOMIC составное выражение Автоматически при успешном выполнении Автоматический при ошибке Фиксированные последовательности, запланированные задания
Interactive BEGIN TRANSACTION; КОММИТ; Руководство Руководство Условная логика, проверка и отладка, JDBC, ODBC, PyODBC

Подробный синтаксис, примеры и шаблоны использования для обоих режимов см. в разделе "Режимы транзакций".

Поддерживаемые операции

В транзакциях можно использовать следующие операции:

Операция Описание
SELECT (подвыборка) Запрос данных и проверка результатов
VALUES оговорка Создание тестовых данных или константных значений
INSERT (включая все варианты) Добавление новых строк
UPDATE Изменение существующих строк
COPY INTO Загрузка данных из файла в таблицу Delta
DELETE FROM Удаление строк
MERGE INTO Шаблоны upsert, объединяющие вставку, обновление и удаление
USE CATALOG и USE SCHEMA. Установка текущего каталога или схемы для инструкций в транзакции
EXECUTE IMMEDIATE Выполнение инструкции SQL, которая создается динамически во время выполнения
DESCRIBE TABLE Возвращать метаданные о таблице, например ее столбцы и свойства
SHOW COLUMNS Выведите список столбцов в таблице
GET Инструкция по диагностике Получение диагностических сведений, таких как состояние активной транзакции или количество строк, затронутых последней инструкцией

Поддерживаемые источники чтения и приемники записи

Транзакции позволяют считывать данные из таблиц Unity Catalog (Delta Lake и Iceberg), потоковых таблиц, представлений и материализованных представлений.

Благодаря гарантиям ACID открытые форматы таблиц, такие как Delta Lake и Iceberg, могут использоваться в транзакциях как в качестве источников чтения, так и в качестве приёмников записи. Используйте allow_nontransactional_read указание для чтения из нетранзакционных источников. См. статью "Чтение" из источников, отличных от транзакций , и пример: чтение без транзакций.

Чтение из источников, не связанных с транзакциями

Предупреждение

Нетранзакционные операции чтения не повторяются. Одновременные изменения исходных данных во время транзакции могут привести к несогласованным считываниям.

Транзакции позволяют читать из нетранзакционных источников. Не транзакционные источники включают внешние таблицы с помощью форматов файлов Parquet, Avro, CSV и JSON, а также федеративных таблиц с помощью JDBC. Чтобы прочитать не транзакционные источники, назовите источник по имени и используйте allow_nontransactional_read указание.

В рамках транзакции можно также запросить information_schema.

Файлы можно считывать напрямую с помощью табличной функции read_files.

Доступ по пути не поддерживается. Если вы ссылаетесь на файл напрямую по пути, например FROM parquet.`/path/to/data`, транзакция завершается ошибкой PATH_BASED_ACCESS .

В следующем примере кода показано, как использовать указание во внешней таблице с помощью JSON:

BEGIN TRANSACTION;
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_json_table
WITH (allow_nontransactional_read = true);

COMMIT;

Пример: чтение без транзакций

В следующем примере показано нетранзакционное чтение из внешней таблицы в формате Parquet. Для этого примера необходимо иметь существующее внешнее расположение данных с правами на чтение и запись.

См. раздел Подключение к внешнему расположению Azure Data Lake Storage 2-го поколения (ADLS Gen2).

Чтобы зарегистрировать источник Parquet как именованную внешнюю таблицу, выполните следующее:

CREATE TABLE main.default.external_parquet_table
USING PARQUET
LOCATION 'abfss://my-container@my-storage-account.dfs.core.windows.net/path/to/data'; -- existing external location

Чтобы в рамках транзакции Delta Lake прочитать и нетранзакционный источник данных Parquet, и управляемую таблицу, выполните следующее:

BEGIN ATOMIC
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_parquet_table
WITH (allow_nontransactional_read = true);

-- Managed table source, no hint is required
INSERT INTO another_table
SELECT * FROM managed_delta_table;
END;

Изоляция транзакций

Транзакции разрешают повторяемые операции чтения во всех инструкциях. При доступе к таблице в транзакции Azure Databricks фиксирует согласованный снимок состояния этой таблицы при первом доступе. Все последующие операции чтения этой таблицы используют этот моментальный снимок, поэтому операции чтения остаются согласованными, даже если другие пользователи одновременно изменяют одни и те же таблицы.

В следующем примере первый запрос к products в транзакции фиксирует согласованный снимок состояния:

Неинтерактивный

BEGIN ATOMIC
  SELECT * FROM products WHERE product_id = 1001;
  SELECT * FROM products WHERE product_id = 1001;
END;

Interactive

BEGIN TRANSACTION;
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
COMMIT;

Затем предположим, что другой пользователь одновременно обновляет строку product_id = 1001 до начала второго запроса:

UPDATE products SET price = 29.99 WHERE product_id = 1001;

Так как моментальный снимок был создан при первом обращении, второй запрос к products возвращает исходную строку, а не обновлённую.

Обнаружение конфликтов и параллелизм

Azure Databricks использует управление оптимистической конкуренцией. Транзакции выполняются без блокировки, и конфликты обнаруживаются во время фиксации изменений. При подтверждении транзакции Azure Databricks проверяет, изменили ли другие транзакции те же данные после начала вашей транзакции. Если существуют конфликты, транзакция завершается ошибкой. Для неинтерактивных транзакций откат также происходит автоматически. Для интерактивных транзакций необходимо явно выполнить ROLLBACK очистку состояния транзакции перед началом новой транзакции.

Неинтерактивные транзакции поддерживают параллелизм на уровне строк. Две транзакции могут изменять разные строки в одном файле данных, не конфликтуя при включении параллелизма на уровне строк в целевых таблицах.

Интерактивные транзакции поддерживают параллелизм на уровне таблицы.

Сценарии конфликтов

Сценарий Описание
Конфликты одновременной записи Две транзакции обновляют или удаляют одни и те же строки.
Конфликты записи и чтения Другая транзакция изменила строки, которые были прочитаны вашей транзакцией. Применяется только к уровню изоляции «Serializable».
Фантомные конфликты при чтении Другая транзакция добавила новые строки, которые соответствуют предикату, использованному в операции чтения вашей транзакции. Применяется как к изоляции WriteSerializable, так и к сериализуемой изоляции.
Конфликты метаданных Другая транзакция изменила схему или свойства таблицы.

Дополнительные сведения об уровнях изоляции и разрешении конфликтов для транзакций см. в режимах транзакций. Сведения об уровнях изоляции и поведении конфликтов записи для таблиц Delta Lake в Azure Databricks см. в рекомендациях по оптимизации на Azure Databricks.

Как отображаются транзакции в журнале Delta

Каждая успешная транзакция отображается как одна запись в журнале delta таблицы независимо от количества отдельных операторов, запущенных в транзакции. Это обеспечивает понятный и упорядоченный журнал аудита и упрощает процедуры отката.

Отдельные операции в транзакции доступны в виде метаданных JSON в записи журнала Delta для транзакции.

Обработка ошибок и откат

В следующей таблице описывается, как происходит откат ошибок для обоих типов транзакций:

Сценарий Поведение при неинтерактивных транзакциях Поведение интерактивных транзакций
Сбой инструкции Любое выражение, которое вызывает ошибку, приводит к немедленной автоматической отмене изменений. Необходимо явно запустить ROLLBACK , чтобы отменить изменения, если сеанс по-прежнему активен.
Сбой логики проверки или бизнес-правил Используйте SIGNAL для выброса исключения и активации автоматического отката. Запустите ROLLBACK , чтобы отменить изменения.
Отключение сеанса Транзакция автоматически откатывается. Транзакция автоматически откатывается.
Таймаут Автоматически откатывается после 48 часов общей продолжительности. Автоматически откатывается после 10 минут бездействия или 48 часов общей продолжительности (см. ограничения). Транзакция завершается без побочных эффектов, но необходимо явно запустить ROLLBACK , чтобы очистить состояние транзакции, если сеанс по-прежнему активен.

Для интерактивных транзакций вы можете явно откатить с помощью инструкции ROLLBACK. Это позволяет отменить изменения на основе логики проверки или бизнес-правил, а также после ошибки выполнения инструкции, если сеанс остается активным.

Лучшие практики

Следуйте этим рекомендациям, чтобы сократить конфликты и оптимизировать производительность транзакций.

Устранение конфликтов

  • Сохранение коротких транзакций: длительные транзакции повышают вероятность конфликтов и удерживают ресурсы дольше.
  • Проверка на ранней стадии: Убедитесь в выполнении предварительных условий в начале транзакции, чтобы быстро выявить ошибки.
  • Используется BEGIN ATOMIC для параллелизма на уровне строк: неинтерактивные транзакции (BEGIN ATOMIC ... END;) обнаруживают конфликты на уровне строк, что уменьшает конфликты по сравнению с обнаружением на уровне таблицы, используемым интерактивными транзакциями. См. неинтерактивные транзакции.
  • Реализуйте логику повторных попыток: транзакция может завершиться ошибкой в любой момент из-за конфликта. Создайте логику повторных попыток в приложение и повторите неудачные транзакции с свежими данными.
  • Запустите каждый интерактивный сеанс с откатом: запуститеROLLBACK в начале интерактивного сеанса, чтобы очистить любое предварительное состояние транзакции.

Использование транзакций из разных клиентов

Транзакции работают в различных клиентских интерфейсах:

Ограничения

Следующие ограничения применяются к транзакциям:

Ограничение Описание
Конфликты интерактивных транзакций Интерактивные транзакции (BEGIN TRANSACTION; ... COMMIT;), используют более консервативное обнаружение конфликтов, чем неинтерактивные транзакции, и могут конфликтовать на уровне таблицы, за исключением INSERT операций, которые не читают из целевой таблицы. Используйте неинтерактивные транзакции (сложный оператор ATOMIC), когда важно обнаружение конфликтов на уровне строк. См. неинтерактивные транзакции.
Целевые объекты для записи Вы можете записывать только в управляемые каталогом Unity таблицы Delta или Iceberg с включенной функцией catalogManaged таблицы. См. коммиты каталога.
Операции DDL не поддерживаются Выполнение операций DDL, таких как CREATE TABLE, ALTER TABLEили DROP TABLEвне транзакций. Сведения об операциях, поддерживаемых транзакциями, см. в разделе "Поддерживаемые операции".
Некоторые операции метаданных не поддерживаются Некоторые операции метаданных не работают внутри транзакций независимо от протокола. К ним относятся вызовы метаданных на основе RPC на основе Thrift (например, методы JDBC DatabaseMetaData и функции каталога ODBC), команды на основе SQL, перечисляющие объекты (например SHOW TABLES , и SHOW DATABASES), а SELECT также запросы к системным таблицам. Выполните эти операции метаданных за пределами транзакций.
COPY INTO Конкурентность Транзакция, выполняющая команду COPY INTO, завершается ошибкой, если другая команда COPY INTO выполняется параллельно для записи в ту же таблицу и фиксирует сначала.
Параллелизм на уровне строк для MERGE Конкурентное выполнение операций MERGE на уровне строк не поддерживается в AWS GovCloud, а также в однопользовательских (выделенных) кластерах. На этих платформах для операций MERGE используется параллелизм на уровне таблиц. См. параллелизм на уровне строк.
Ограничения таблицы и представления Транзакция может считывать или записывать до 100 таблиц в сочетании и может считывать до 100 представлений. Каждая таблица может содержать до 100 промежуточных коммитов в транзакции.
Перемещение по времени не поддерживается Нельзя использовать перемещение по времени в рамках транзакции.
Время ожидания перед переходом в режим простоя Интерактивные транзакции откатываются через 10 минут бездействия. Транзакция завершается без побочных эффектов, но необходимо явно запустить ROLLBACK , чтобы очистить состояние транзакции, если сеанс по-прежнему активен.
Происхождение Транзакции выдают след при каждом чтении и записи. События родословной сохраняются, даже если транзакция откатывается.
Максимальная длительность Все транзакции автоматически откатываются через 48 часов с момента их начала. Для интерактивных транзакций транзакция завершается без побочных эффектов, но необходимо явно запустить ROLLBACK , чтобы очистить состояние транзакции, если сеанс по-прежнему активен.
Требование к общим таблицам OpenSharing Поставщики OpenSharing должны совместно использовать таблицу WITH HISTORY , чтобы разрешить получателям выполнять транзакции на нем. Получатели могут выполнять транзакции с помощью любого типа вычислений.
Ограничения вычислительных ресурсов для получателей OpenSharing Получателям Azure Databricks разрешено выполнять транзакции только в общих представлениях, материализованных представлениях, потоковых таблицах и внешних таблицах, которые не являются таблицами Айсберг. Получатели в той же учетной записи Azure Databricks, что и их поставщик, должны использовать общие или бессерверные вычисления. Получатели в другой учетной записи должны использовать бессерверные вычисления.
Конфликт исходной таблицы OpenSharing Получатели OpenSharing не могут ссылаться на общее представление и общую таблицу, ссылающуюся на ту же исходную таблицу в рамках одной транзакции.

Дополнительные ресурсы

  • Last updated on