Поделиться через

Уровни изоляции (WriteSerializable и Serializable)

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

Уровень изоляции Описание
Сериализуемый Самый сильный уровень изоляции. Гарантирует, что зафиксированные операции записи и все операции чтения являются сериализуемыми. Операции разрешены, если существует последовательная последовательность, которая при выполнении по одному за раз создает тот же результат, что и в таблице. Для операций записи эта последовательная цепочка совпадает с порядком, наблюдаемым в истории таблицы.
WriteSerializable (по умолчанию) Более слабый уровень изоляции, чем Serializable. Гарантирует, что сериализуются только операции записи (не операции чтения). Это по-прежнему сильнее изоляции моментальных снимков . Обеспечивает хороший баланс согласованности и доступности данных для большинства распространенных операций.

Влияние уровней изоляции на чтение

Операции чтения всегда используют изоляцию снимка. Уровень изоляции операций записи определяет, позволяет ли читателю видеть снимок состояния таблицы, которая, по историческим данным, как бы никогда не существовала.

  • Сериализуемая: средство чтения всегда видит только таблицы, соответствующие истории.
  • WriteSerializable: средство чтения может увидеть состояние таблицы, которое не существует в журнале Delta

Пример: параллельное удаление и вставка

Рассмотрим сценарий, когда долго выполняющаяся транзакция удаления и транзакция вставки запускаются одновременно и считывают версию v0. Транзакция вставки сначала подтверждается и создает версию v1. После этого транзакция удаления пытается зафиксировать v2:

t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)

В этом сценарии deleteTxn не увидел данных, вставленных insertTxn, и не удалил их.

  • Serializable: deleteTxn не разрешено завершить транзакцию, и возникает конфликт
  • WriteSerializable: deleteTxn допускается фиксация, так как транзакции можно упорядочить. Полученное состояние таблицы таково, как если бы insertTxn произошло после deleteTxn, поэтому все вставленные строки являются частью таблицы. Однако история Delta показывает порядок физической фиксации (insertTxn в версии 1 перед deleteTxn в версии 2).

Выбор уровня изоляции

Задайте уровень изоляции с помощью ALTER TABLE команды:

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

Где <level-name> это Serializable или WriteSerializable.

Example:

-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

Когда Delta Lake фиксирует без чтения таблицы?

Операции Delta Lake INSERT или добавления не читают состояние таблицы перед коммитом, если выполнены следующие условия:

  1. Логика выражается с помощью INSERT логики SQL или режима добавления
  2. Логика не содержит вложенных запросов или условных условий, ссылающихся на таблицу, предназначенную операцией записи

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

Замечание

Многие распространенные шаблоны используют MERGE операции, чтобы вставлять данные, основываясь на условиях таблицы. Хотя эту логику можно переписать с помощью инструкций INSERT, если какое-либо условное выражение ссылается на столбец в целевой таблице, эти инструкции имеют те же ограничения параллелизма, что и MERGE.

Дальнейшие действия

  • Last updated on