Многооперационные транзакции стали общедоступными (Generally Available), позволяя организациям запускать сложные многоэтапные рабочие процессы с гарантиями атомарности без использования отдельный систем хранилищ данных.
Хранилища данных обеспечивают работу важнейших для предприятий нагрузок, включая загрузку и трансформацию данных, бизнес-аналитику, приложения и операционную аналитику. Многие из этих нагрузок требуют, чтобы изменения в нескольких таблицах либо успешно завершались, либо отменялись одновременно. Исторически сложилось так, что для получения таких гарантий транзакционности организации полагались на отдельные системы хранилищ данных, что приводило к дорогостоящему перемещению данных, дублированию копий, фрагментированному управлению и операционной сложности.
Databricks — первая архитектура lakehouse, которая нативно поддерживает многооперационные транзакции как для таблиц Delta Lake, так и для Apache Iceberg. Наряду с хранимыми процедурами, временными таблицами и SQL-скриптами, многооперационные транзакции переносят традиционные рабочие нагрузки хранилищ данных в открытые и управляемые данные в lakehouse.
Проблемы с транзакциями в традиционных и облачных хранилищах данных
Традиционные и облачные хранилища предоставляют гарантии транзакционности, но часто за счет фрагментированной архитектуры данных:
- Дополнительные копии и перемещение данных: Перемещение данных в отдельное хранилище и из него увеличивает задержки, затраты и риски возникновения несогласованности.
- Фрагментированное управление: Командам приходится дублировать и синхронизировать политики доступа, аудит и операционный контроль в разных системах.
- Сложные обходные пути для обеспечения согласованности: Разработчикам требуется пользовательская оркестрация, сверка данных и логика повторных попыток для поддержания согласованности связанных изменений.
Многооперационные транзакции переносят эти гарантии непосредственно в открытый и управляемый lakehouse, сокращая количество дублирующих систем и объем операционной работы, необходимой для поддержания их согласованности.
Транзакции в lakehouse создают единую основу для работы с хранилищами данных
Транзакции в lakehouse служат основой для выполнения требовательных рабочих нагрузок хранилищ на открытых корпоративных данных. Они объединяют поддержку открытых форматов таблиц с единым управлением и высокой производительностью при высокой параллельности. Они также интегрируются со знакомыми инструментами разработки хранилищ, конвейерами данных и возможностями наблюдаемости в production.
Открытость для Delta Lake и Apache Iceberg
Многооперационные транзакции поддерживают как таблицы Delta Lake, так и Apache Iceberg. Команды могут сохранять открытые форматы таблиц, получая при этом гарантии атомарности для нескольких операторов и таблиц. Им не нужно переносить управляемые данные в проприетарный формат или поддерживать транзакционную копию в другой системе.
Высокая скорость при высокой параллельности
Архитектура lakehouse поддерживает параллелизм на уровне строк, позволяя параллельным транзакциям выполнять запись в одну и ту же таблицу, если они не обновляют одну и ту же строку. В отличие от традиционных хранилищ данных, которые используют блокировки для сериализации операций записи, параллелизм на уровне строк позволяет запускать больше транзакций параллельно. В результате Databricks обеспечивает значительно более высокую производительность по сравнению с традиционными облачными и устаревшими хранилищами, позволяя организациям запускать требовательные рабочие нагрузки хранилищ непосредственно в lakehouse.
Интеграция с разработкой хранилищ и конвейерами данных
Транзакции совместимы с другими возможностями хранилищ данных, позволяя командам создавать традиционные рабочие нагрузки хранилищ в lakehouse. Например, разработчики могут размещать промежуточные результаты во временной таблице, упаковывать многошаговую бизнес-логику в хранимую процедуру и фиксировать весь рабочий процесс атомарно.
Транзакции также могут выполнять запись в потоковые таблицы, привнося гарантии атомарности в рабочие процессы, которые непрерывно загружают, преобразуют и публикуют данные. Теперь конвейеры нижнего уровня могут получать согласованные обновления, что предотвращает обработку ими неполных данных.
Управляемые транзакции для конфиденциальных данных
Транзакции учитывают элементы управления доступом на основе атрибутов Unity Catalog, включая безопасность на уровне строк и маскирование столбцов, как при чтении, так и при записи. Это особенно важно для рабочих процессов, которые подготавливают, проверяют и публикуют конфиденциальные данные.
Наблюдаемость в production
Транзакции в production должны быть как понятными, так и корректными. Разработчики могут использовать такие команды, как DESCRIBE TABLE, SHOW COLUMNS и GET DIAGNOSTICS, чтобы проверять таблицы, участвующие в транзакции, и собирать информацию о выполнении транзакций. Эти возможности делают транзакционные рабочие процессы более простыми в разработке, эксплуатации и устранении неполадок.
Этот полностью интегрированный опыт позволяет Fivetran создавать свои коннекторы поверх транзакций lakehouse.
"Fivetran History Mode сохраняет каждую версию записи с использованием медленно меняющихся измерений (SCD) типа 2. Каждое изменение источника представляет собой две записи в пункт назначения: закрытие предыдущей версии и вставка новой активной — обе операции должны завершиться успешно. Раньше, когда гарантии транзакционности ограничивались отдельным оператором, мы выполняли их как раздельные операции и защищались от частичных сбоев с помощью логики сверки и проверок согласованности при последующих синхронизациях. С многооперационными и многотабличными транзакциями мы теперь фиксируем закрытие и вставку как единое атомарное целое, поэтому либо применяется все изменение целиком, либо не применяется ничего. Это позволило Fivetran удалить целый класс кода для исправления согласованности и предоставило нашим клиентам более надежную гарантию корректности исторических данных", — Эджидио Терра (Egidio Terra), ведущий продакт-менеджер, Fivetran.
Аналогичным образом Accolade использует транзакции для обработки тысяч записей о претензиях и обязательствах каждый день.
"В Accolade мы обрабатываем примерно 1700 транзакций в production каждый день для работы с входящими претензиями и обязательствами. Каждое из этих обновлений должно выполняться надежно и согласованно. Многооперационные и многотабличные транзакции позволяют нам запускать эти многошаговые операции с полными гарантиями транзакционности непосредственно в нашем управляемом lakehouse. Эта надежность имеет решающее значение для нашего масштабного переноса критически важных рабочих нагрузок в открытый lakehouse без создания отдельного хранилища", — Акшай Айгаонкар (Akshay Ajgaonkar), инженерный менеджер, Accolade.
В совокупности открытые форматы, централизованное управление, параллелизм на уровне строк, привычные функции SQL, интеграция конвейеров и наблюдаемость создают полноценную среду транзакций в lakehouse.
Основные сценарии использования многооперационных транзакций
Многооперационные и многотабличные транзакции поддерживают несколько распространенных шаблонов для модернизации ETL, миграции рабочих нагрузок хранилищ и публикации проверенных данных.
Обеспечение многотабличных гарантий транзакционности для ETL
Задание ETL может обновлять связанные таблицы как единое целое. В этом примере статус заказа и баланс запасов не могут рассинхронизироваться.
Если какое-либо из обновлений завершается с ошибкой, рабочий процесс может откатить оба изменения вместо публикации выполненного заказа без соответствующей корректировки запасов.
Миграция процедур хранилища в lakehouse
Хранимые процедуры и временные таблицы позволяют разработчикам сохранять привычные шаблоны разработки хранилищ при работе с управляемыми данными lakehouse.
Политики безопасности на уровне строк и маскирования столбцов Unity Catalog продолжают применяться к управляемым операциям чтения и записи. Эта процедура также использует команду DESCRIBE TABLE для проверки схемы и метаданных целевого объекта перед следующим набором операций записи, помогая разработчикам проверять конфигурацию и устранять неполадки, не покидая транзакционный рабочий процесс.
Реализация шаблона Write-Audit-Publish
Шаблон Write-Audit-Publish предотвращает появление данных в видимой зоне до тех пор, пока они не пройдут необходимые проверки качества.
Рабочий процесс подготавливает новые данные, записывает результаты проверки их качества и публикует проверенные записи в ходе одной атомарной операции. Если проверка или запись завершаются с ошибкой, транзакция может выполнить откат вместо того, чтобы предоставлять частичный результат. Тот же шаблон может включать транзакционные записи в потоковые таблицы, когда нисходящим конвейерам необходимы опубликованные данные непрерывно.
Начните работу с транзакциями уже сегодня
Многооператорные транзакции (Multi-Statement Transactions) стали общедоступными (GA) для управляемых Unity Catalog таблиц Delta Lake и Apache Iceberg на Databricks. Начните работу с транзакциями уже сегодня, используя документацию Databricks или обратившись к встроенному ассистенту продукта.
Используя транзакции в Lakehouse, вы можете перенести критически важные рабочие нагрузки хранилищ данных на открытые, управляемые данные, одновременно сокращая количество дублирующих систем, перемещение данных и операционную сложность.
