Что такое гарантии ACID на Azure Databricks?

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

• Атомарность означает, что все транзакции либо завершаются успешно, либо завершаются сбоем полностью.
• Гарантии согласованности связаны с тем, как данное состояние данных наблюдается одновременными операциями.
• Изоляция означает, как одновременные операции потенциально конфликтуют друг с другом.
• Устойчивость означает, что зафиксированные изменения являются постоянными.

Хотя многие технологии обработки и хранения данных описывают транзакции ACID, определенные гарантии зависят от системы, а транзакции на Azure Databricks могут отличаться от других систем, с которыми вы работали.

Как определяются границы транзакций в Azure Databricks?

По умолчанию каждая инструкция SQL выполняется как собственная атомарная транзакция для одной таблицы. Можно также сгруппировать несколько инструкций между несколькими таблицами в одну атомарную транзакцию с помощью BEGIN ATOMIC ... END; синтаксиса. Все изменения либо успешно применяются одновременно, либо откатываются вместе. Транзакции, охватывающие несколько таблиц, требуют, чтобы фиксации каталога были включены на участвующих таблицах. См. транзакции.

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

По умолчанию Azure Databricks обеспечивает изоляцию моментальных снимков для операций чтения и изоляцию write-serializable при записи. Хотя сериализуемая изоляция для операций записи обеспечивает более серьёзные гарантии, чем изоляция моментальных снимков, эти меры защиты применяются только к операциям записи.

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

Как Azure Databricks реализует атомарность?

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

Файлы данных не отслеживаются, если журнал транзакций не записывает новую версию. Если транзакция завершается ошибкой после записи файлов данных в таблицу, эти файлы данных не повреждают состояние таблицы, но файлы не станут частью таблицы. Операция VACUUM удаляет все неотслеживаемые файлы данных в каталоге таблицы, включая оставшиеся незафиксированные файлы из неудачных транзакций.

Как Azure Databricks реализует устойчивость данных?

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

Как Azure Databricks реализует консистентность?

В Delta Lake используется оптимистическое управление параллелизмом для предоставления гарантий транзакций при записи. В этом механизме операции записи выполняются в три этапа:

1. Чтение: считывает (при необходимости) последнюю доступную версию таблицы для определения, какие файлы необходимо изменить (то есть перезаписать).
   • Записи, которые доступны только для добавления, не считывают текущее состояние таблицы перед записью. Проверка схемы использует метаданные из журнала транзакций.
2. Запись: записывает файлы данных в каталог, используемый для определения таблицы.
3. Проверка и фиксация:
   • Проверяет, конфликтуют ли предложенные изменения с любыми другими изменениями, которые могут быть одновременно зафиксированы после считываемого моментального снимка.
   • При отсутствии конфликтов все промежуточные изменения фиксируются в виде новой версии моментального снимка, и операция записи успешно выполняется.
   • При возникновении конфликтов операция записи завершается сбоем с исключением параллельного изменения. Этот сбой предотвращает повреждение данных.

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

Как Azure Databricks реализует изоляцию?

Azure Databricks использует сериализуемую изоляцию по умолчанию для всех операций записи и обновлений таблицы. Изоляция моментальных снимков используется для всех операций чтения таблиц.

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

См. уровни изоляции и конфликты записи.

Поддерживает ли Delta Lake транзакции с несколькими таблицами?

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

Отношения первичного и внешнего ключей в Azure Databricks являются информационными и не подлежат применению. См. раздел "Объявление первичного ключа", внешнего ключа и уникальных ограничений.

Что означает поддержка операций записи в несколько кластеров для Delta Lake?

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

Можно ли изменить таблицу Delta из других рабочих областей?

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