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

Параллелизм на уровне строк

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

Требования к параллелизму на уровне строк

Таблицы не поддерживают параллелизм на уровне строк, если у них определены секции или если не включены векторы удаления. Параллелизм на уровне строк требует Databricks Runtime 14.2 и более поздних версий.

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

Сведения о версиях среды выполнения Databricks до 14.2 см. в разделе "Поведение предварительного просмотра одновременного доступа на уровне строк" (устаревшая версия).

Замечание

MERGE INTO для поддержки параллелизма на уровне строк требуется Photon в Databricks Runtime 14.2. В Databricks Runtime 14.3 LTS и более поздних версиях Фотон не требуется.

Матрица конфликтов с параллелизмом на уровне строк

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

INSERT (1) UPDATE, УДАЛИТЬ, MERGE INTO OPTIMIZE
INSERT Не может конфликтовать
UPDATE, УДАЛИТЬ, MERGE INTO Не удается разрешить конфликт в WriteSerializable. Может конфликтовать в режиме сериализуемости при изменении той же строки. Может возникать конфликт при изменении одной и той же строки.
OPTIMIZE Не может конфликтовать Может возникать конфликт, когда используется ZORDER BY. Нельзя подвергаться конфликту иначе. Может возникать конфликт, когда используется ZORDER BY. Нельзя подвергаться конфликту иначе.

(1) Все INSERT операции в этой таблице описываются как операции добавления и не считывают данные из этой же таблицы до фиксации. INSERT операции, содержащие подзапросы, выполняющие считывание из той же таблицы, поддерживают такой же параллелизм, как и MERGE.

Замечание

  • Таблицы с столбцами удостоверений не поддерживают одновременные транзакции. См. «Использование идентификационных столбцов в Delta Lake».
  • REORG операции имеют семантику изоляции, идентичную OPTIMIZE при перезаписи файлов данных. При применении обновления REORG протоколы таблиц изменяются, что приводит к конфликту со всеми выполняющимися операциями.

Запись конфликтов без параллелизма на уровне строк

Таблицы не поддерживают параллелизм на уровне строк, если в них определены секции или не включены векторы удаления. Databricks Runtime 14.2 или более поздней версии требуется для параллелизма на уровне строк.

Матрица конфликтов без параллелизма на уровне строк

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

INSERT (1) UPDATE, УДАЛИТЬ, MERGE INTO OPTIMIZE
INSERT Не может конфликтовать
UPDATE, УДАЛИТЬ, MERGE INTO Не удается разрешить конфликт в WriteSerializable. Может конфликтуться в Сериализуемом режиме. См. раздел "Избегайте конфликтов" с помощью секционирования. Может возникать конфликт в Serializable и WriteSerializable. См. раздел "Избегайте конфликтов" с помощью секционирования.
OPTIMIZE Не может конфликтовать Невозможно обнаружить конфликт в таблицах с активированными векторами удаления, если ZORDER BY не используется. Может возникнуть конфликт в противном случае. Невозможно возникновение конфликтов в таблицах с включенными векторами удаления, если не используется ZORDER BY. Может возникнуть конфликт в противном случае.

(1) Все INSERT операции в этой таблице описывают операции добавления, которые не считывают данные из этой таблицы перед фиксацией. INSERT операции, содержащие подзапросы, выполняющие считывание из той же таблицы, поддерживают такой же параллелизм, как и MERGE.

Замечание

  • Таблицы с столбцами удостоверений не поддерживают одновременные транзакции. См. «Использование идентификационных столбцов в Delta Lake».
  • REORG операции имеют семантику изоляции, идентичную OPTIMIZE перезаписи файлов данных. При применении обновления REORG протоколы таблиц изменяются, что приводит к конфликту со всеми выполняющимися операциями.

Ограничения параллелизма на уровне строк

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

Ограничение Описание
Сложные условные предложения Условия сложных типов данных (структуры, массивы, карты), недетерминированные выражения, вложенные запросы и коррелированные вложенные запросы
MERGE предикатное требование В Databricks Runtime 14.2 MERGE команды должны использовать явный предикат в целевой таблице для фильтрации строк, соответствующих исходной таблице.
Компромисс производительности Обнаружение конфликтов на уровне строк может увеличить общее время выполнения. При большом количестве параллельных транзакций модуль записи отдает предпочтение задержке вместо разрешения конфликтов.

Все ограничения для векторов удаления также применяются. См. Ограничения.

Избегайте конфликтов с помощью секционирования

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

Example:

Команды UPDATE table WHERE date > '2010-01-01' ... и DELETE table WHERE date < '2010-01-01' конфликтуют, если таблица не секционирована по дате, потому что оба они могут попытаться изменить одни и те же файлы. Разделение таблицы по date избегает конфликта.

Замечание

Секционирование таблицы по столбцу с высоким кратностью может привести к проблемам с производительностью из-за большого количества подкаталогов.

Пример: Предотвращение конфликтов с явными фильтрами разделов

Это исключение часто возникает во время параллельных операций DELETE, UPDATE или MERGE, которые могут считывать один и тот же раздел даже при обновлении разных разделов. Сделайте разделение явным в условии операции:

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Конфликтные исключения

При возникновении конфликта транзакций наблюдается одно из следующих исключений:

ConcurrentAppendException

Это исключение возникает, когда параллельная операция добавляет файлы в ту же секцию (или в любое место несекционированной таблицы), которую считывает операция. Добавление файлов может быть вызвано операциями INSERT, DELETE, UPDATE или MERGE.

По умолчанию, если уровень изоляции установлен на WriteSerializable, файлы, добавленные слепыми INSERT операциями (операциями, добавляющими данные без чтения данных), не конфликтуют ни с одной операцией. Если уровень изоляции сериализуемый, неявные добавления могут конфликтовать.

Это важно

Слепые добавления могут конфликтовать в режиме WriteSerializable, если несколько одновременных операций DELETE, UPDATE или MERGE могут ссылаться на значения, вставленные с помощью слепых добавлений. Чтобы избежать этого, следуйте правилам ниже.

  • Убедитесь, что параллельные операции DELETE, UPDATE или MERGE не считывают дополненные данные
  • Есть не более одной DELETE, UPDATE или MERGE операции, которая может читать добавленные данные.

ConcurrentDeleteReadException

Это исключение возникает, когда параллельная операция удаляет файл, который был считан вашей операцией. Распространенными причинами являются DELETE, UPDATE или MERGE операции, которые перезаписывают файлы.

ConcurrentDeleteDeleteException

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

MetadataChangedException

Это исключение возникает, когда параллельная транзакция обновляет метаданные таблицы Delta. Распространенными причинами являются ALTER TABLE операции или записи, которые обновляют схему таблицы.

Исключение параллельной транзакции

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

ИсключениеИзмененияПротокола

Это исключение может возникать, когда:

  • Таблица Delta обновляется до новой версии протокола (возможно, потребуется обновить среду выполнения Databricks).
  • Одновременно несколько авторов создают или заменяют таблицу.
  • Несколько авторов пишут в пустой путь одновременно

См. сведения о совместимости функций Delta Lake и протоколах.

Поведение в режиме предварительного просмотра параллелизма на уровне строк (устаревший режим)

В этом разделе описано поведение предварительной версии для параллелизма на уровне строк в Databricks Runtime 14.1 и ниже.

Версия среды выполнения Databricks Поведение
Databricks Runtime 13.3 LTS и более поздние версии Таблицы с жидким кластеризацией автоматически обеспечивают конкурентность на уровне строк
Databricks Runtime 14.0 и 14.1 Включение параллелизма на уровне строк для таблиц с векторами удаления с помощью приведенной ниже конфигурации
Databricks Runtime 14.1 и ниже Технология вычислений, не связанная с Фотоном, поддерживает только параллельность на уровне строк для операций DELETE.

Чтобы включить параллелизм на уровне строк в Databricks Runtime 14.0 и 14.1, выполните следующие действия.

spark.databricks.delta.rowLevelConcurrencyPreview = true

Согласованность на уровне строк всегда требует векторов удаления.

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

  • Last updated on