Архитектура LTAP

Lake Transactional/Analytical Processing (LTAP) — это архитектура данных, которая обслуживает как транзакционные (OLTP), так и аналитические (OLAP) рабочие нагрузки с единого слоя хранения данных в озере под одной моделью управления, так что вам не нужно синхронизировать отдельные транзакционные и аналитические системы. Он убирает конвейеры сбора данных изменений (CDC), репликации и трансформации, которые команды традиционно поддерживают для копирования операционных данных в отдельную аналитическую систему. Azure Databricks строит LTAP на архитектуре хранения Lakebase. Об анонсе см. Databricks представляет LTAP: первую архитектуру Lake Transactional/Analytical Processing.

LTAP — это архитектура, а не единая функция. Azure Databricks реализует это через набор возможностей Lakebase, которые активно разрабатываются и расширяются. Доступные вам возможности зависят от вашего облака. На этой странице объясняется архитектура. Для возможностей, которые вы можете использовать сегодня в облаке, см . раздел «Возможности, реализующие LTAP».

Important

Прежде чем читать эту страницу, прочитайте страницу Архитектура Lakebase, чтобы понять архитектуру Lakebase и её компоненты: не сохраняющие состояние вычислительные узлы Postgres, safekeepers, pageservers и облачное объектное хранилище. LTAP напрямую основывается на том, как Lakebase отделяет вычисления от хранилища, и остальная часть этой страницы предполагает эту основу.

Стоимость поддержания синхронизации двух стеков

Приложения делят работу с данными на два типа нагрузки. Транзакционные (OLTP) рабочие нагрузки работают по нескольким строкам за раз и требуют быстрого полного содержимого этих строк, например, обработки платежа или возврата результата API. Аналитические (OLAP) нагрузки предназначены для получения ценной информации из больших наборов данных, часто с агрегированием данных и объединением множества строк, например при прогнозировании продаж или выявлении мошенничества. Эти паттерны тянут в противоположных направлениях: OLTP требует постоянных чтений и записи с низкой задержкой по отдельным строкам, тогда как OLAP должен сканировать и агрегировать большие объёмы данных. Десятилетиями ответом были две отдельные системы: транзакционная база данных для приложения и хранилище данных или озеро для аналитики.

Связать эти два стека — самая затратная часть. Чтобы поддерживать их синхронизацию, необходимо запускать захват изменений данных (CDC), потоковые конвейеры и реплики для чтения, единственная задача которых — копировать данные из одной системы в другую. Эта инфраструктура хрупка, она создаёт задержку между записью данных и их анализом, а также конкурирует за ресурсы с основной транзакционной базой данных. Поскольку приложения и агенты ИИ всё чаще нуждаются в аналитике по самым свежим транзакционным данным, этот разрыв замедляет работу команд. Копирование данных между двумя системами также создаёт риск управления: родословная может нарушаться при перемещении данных, что усложняет выполнение таких обязательств, как запросы на удаление по GDPR.

Как LTAP объединяет данные на уровне хранения

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

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

Note

О том, как Lakebase разделяет вычисления и хранилище, см. архитектуру Lakebase.

LTAP добавляет ещё один этап в этот слой хранения. Когда хранилище Lakebase материализует данные в объектное хранилище, оно транскодирует строковые данные Postgres в столбцовую структуру Parquet, когда данные попадают в озеро, где их можно читать через открытые таблицы, такие как Delta и Iceberg. Такое транскодирование позволяет одной копии данных обслуживать как OLTP, так и OLAP-нагрузки. Он разработан так, чтобы колоночная копия оставалась точным и эффективным представлением оригинала в Postgres:

• Семантика сохраняется. Хранилище Lakebase транскодирует каждое значение в столбцовую форму, сохраняя исходное представление Postgres, чтобы любой совместимый с Postgres движок мог переинтерпретировать данные без потери информации. Типы, которые не имеют точного соответствия в Parquet, такие как NaN, NUMERIC переполнение или типы расширений, такие как vector, array, geography и JSON, сохраняются в поле переполнения, которое содержит каноническое представление Postgres.
• Версии строк сохраняются. Транскодирование сохраняет промежуточные версии строк, поэтому столбцовая копия содержит ту же информацию о версиях, что и строковые данные.
• Столбцовые данные хорошо поддаются сжатию. Колоночное представление хорошо сжимается, что уменьшает занимаемый объем хранилища и объем данных, передаваемых в объектное хранилище и из него.

Транскодирование полностью происходит на уровне хранения, изолированном от основного экземпляра Postgres, поэтому это не влияет на вашу транзакционную нагрузку по обслуживанию. Это основано на том, что Lakebase уже делает: сбрасывает зафиксированные данные в облачное объектное хранилище. LTAP просто добавляет колоночный формат к той же операции сброса. Вам не нужно выстраивать какой-либо конвейер, и нет никакого внешнего процесса, опрашивающего вашу базу данных.

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

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

Note

Ветка Lakebase — это клон хранилища вашей базы данных, работающий по принципу copy-on-write: она использует существующие данные родительской ветки и сохраняет только изменения, поэтому не требует предварительного дублирования данных. Восстановление на определённый момент времени использует то же версионное хранилище, чтобы вернуть базу данных к более раннему моменту в пределах окна восстановления. Чтобы узнать больше, см. «Ветви базы данных» и «Восстановление на определённый момент времени».

Именно такой подход на уровне хранения отличает LTAP от системы захвата данных изменений (CDC). CDC реплицирует данные из вашего OLTP-хранилища в отдельный аналитический уровень с помощью внешнего процесса, который постоянно опрашивает основную базу данных, и конвейера, преобразующего изменения строк в столбцовые данные. Этот конвейер потребляет ресурсы в вашей основной транзакционной базе данных, заставляет вас самостоятельно разбираться с изменениями схемы и пограничными случаями, а также вынуждает искать компромисс между актуальностью данных и стоимостью конвейера, одновременно добавляя дополнительные точки отказа. LTAP вместо этого использует подход на уровне хранения: система хранения Lakebase преобразует данные и записывает их в озеро в рамках штатной работы, без какого-либо внешнего процесса, конкурирующего с вашей рабочей нагрузкой, и без конвейера обработки, который нужно создавать и поддерживать.

Три столпа LTAP

Объединение данных на уровне хранения придаёт LTAP три определяющих свойства.

• Универсальное управление. Unity Catalog регулирует аналитический доступ к одной логической копии ваших данных в обеих рабочих нагрузках.
• Специально созданные двигатели. Postgres обслуживает транзакции, а Lakehouse — аналитику, и ни один из них не компрометирует другого.
• Одна логическая копия в открытом хранилище. Оба движка читают по одной копии ваших данных в открытых форматах, без реплик или конвейеров для синхронизации.

Универсальное управление

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

Note

Управление Unity Catalog сегодня применяется к аналитическому доступу: внешним вычислителям, таким как Lakehouse//RT и Change Data Feed, которые считывают ваши зарегистрированные данные Lakebase. Пока это не позволяет напрямую управлять отдельными таблицами PostgreSQL. Доступ через транзакционный путь, то есть приложения и клиенты, подключающиеся к Postgres, по-прежнему контролируется стандартными привилегиями Postgres (GRANT и REVOKE), а не Unity Catalog. На практике Unity Catalog управляет аналитическим доступом и доступом к Lakehouse, а роли и привилегии Postgres управляют транзакционным доступом.

Специально созданные двигатели

Postgres обслуживает вашу транзакционную нагрузку, а Lakehouse — аналитику, каждая из которых обладает своими сильными сторонами. Распространённое заблуждение состоит в том, что объединение этих двух означает, будто ваши операционные данные становятся холодными данными и хранятся в Iceberg. Это не так. Lakebase по-прежнему — стандартный Postgres. Индексация, ветвление, восстановление на определённый момент времени, расширения, а также операции точечного чтения и записи с низкой задержкой по-прежнему работают точно так же, как сегодня.

Аналитические чтения не конкурируют с транзакционной нагрузкой, поскольку они изолированы от основного экземпляра PostgreSQL. Когда аналитический движок, такой как Lakehouse//RT, запрашивает живые данные Lakebase, он возвращает свежий, транзакционно согласованный результат без копирования данных:

• Движок считывает основную часть данных из колонковой копии в объектном хранилище, а не из Postgres.
• Чтобы получить согласованное на уровне транзакций представление, у Postgres запрашивается только текущий номер последовательности записи в журнале (LSN) — единственное значение, отмечающее позицию в журнале предзаписи. Это дешёвый поиск метаданных.
• Для небольшого набора совсем недавних изменений, которые ещё не реализованы в озере, он считывает их с сервера страниц и объединяет их сверху.

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

Одна логическая копия в открытом хранилище

Поскольку данные находятся в озере в виде столбного паркета, читаемого через открытые таблицы, такие как Delta и Iceberg, Lakebase (OLTP) и Lakehouse (OLAP) используют одну и ту же основу хранения. Вы поддерживаете одну логическую копию данных в обеих нагрузках, вместо того чтобы сверять транзакционную базу данных с отдельной аналитической копией.

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

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

Нужно ли менять способ использования Lakebase

No. Внедрение возможностей LTAP не требует миграции данных или изменения способа подключения ваших приложений к Lakebase. Lakebase остаётся стандартным Postgres: ваши существующие расширения, индексы, запросы и код приложения продолжают работать без изменений. Каждая из возможностей LTAP независима, поэтому вы можете внедрить любую из них по мере необходимости для конкретной рабочей нагрузки.

Возможности, реализующие LTAP

Вы применяете архитектуру LTAP на практике через набор возможностей Lakebase. Каждый из них опирается на общую основу хранилища, описанную выше, и вместе они охватывают пути, по которым данные проходят через LTAP:

• Управляйте и регистрируйте: помещайте данные Lakebase в Unity Catalog.
• Отображать данные Lakehouse в Lakebase: синхронизированные таблицы, ускоренные с помощью LTAP Direct Writes.
• Запрос в реальном времени по данным Lakebase: Lakehouse//RT для аналитики, Lakebase Change Data Feed для потоков изменений.

Следующая диаграмма показывает, как эти возможности записывают данные в единую копию ваших данных и считывают их из неё, при этом эта копия управляется Unity Catalog.

Lakehouse//RT и Lakebase Change Data Feed читают одни и те же базовые данные, но представляют их по-разному. Lakehouse//RT читает текущее состояние актуальных данных Postgres для аналитики. Change Data Feed предоставляет поток изменений на уровне строк для последующих конвейеров обработки и аудита. То же самое относится и к внешнему CDC-процессу, который устраняет LTAP: оба работают с единственной копией данных.

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

Capability	Статус	Description
Зарегистрировать Lakebase в каталоге Unity	Генеральная Ассамблея	Управление аналитическим доступом к данным Lakebase и выполнение кросс-исходных запросов из Lakehouse.
Обслуживание данных с синхронизированными таблицами	Генеральная Ассамблея	Используйте данные таблиц Unity Catalog в Lakebase для OLTP-чтения с низкой задержкой. LTAP Direct Writes (Beta) ускоряет начальную загрузку в каждом режиме синхронизации, а также полные обновления.
Lakehouse//RT отправляет запрос к Lakebase	Бета-версия	Запускайте транзакционно согласованные OLAP-запросы на живых данных Postgres, не влияя на производительность Lakebase OLTP.
Поток данных об изменениях Lakebase	Public Preview	Сохраняйте построчные изменения из таблиц Lakebase Postgres в таблицах Delta каталога Unity Catalog для последующих конвейеров обработки и аудита.

Как подходить к реализации

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

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

• Lakebase управляет записью. Ваше приложение пишет в Postgres, и вы хотите, чтобы операционные данные были доступны для аналитики без их копирования. Например, приложение для продаж записывает заказы и платежи в Lakebase по мере их происходящего. Используйте Lakehouse//RT, чтобы запустить панель мониторинга выручки в реальном времени по этим заказам, или Lakebase Change Data Feed, чтобы передавать каждое изменение заказа в последующий конвейер обработки данных или журнал аудита.
• Дом на озере принадлежит этому сценарию. Ваши данные создаются или поддерживаются в архитектуре Lakehouse, и вы хотите обеспечить для своего приложения низколатентное OLTP-чтение этих данных. Например, ночная работа в доме на озере включает вычисление рекомендаций по продуктам или таблицу цен. Используйте синхронизированные таблицы для передачи этих данных в Lakebase, чтобы ваше приложение могло читать их с низкой задержкой, и включите LTAP Direct Writes для ускорения начальной загрузки большой таблицы.

Сопоставьте каждый набор данных с одним из этих направлений, зарегистрируйте базу данных в Unity Catalog для управления данными, затем следуйте документации по соответствующим возможностям, чтобы реализовать каждый вариант. Одно приложение часто использует оба направления: отправляет эталонные данные из Lakehouse в Postgres, одновременно открывая собственные транзакционные записи обратно аналитике. Доступность зависит от облака, поэтому проверьте таблицу возможностей выше, чтобы убедиться, что предлагается в вашем облаке.

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

• Архитектура Lakebase: Поймите, как Lakebase отделяет вычисления без состояния от долговечного хранения. См. архитектуру Lakebase.
• Зарегистрируйте базу данных в Unity Catalog: управляйте данными Lakebase и задавайте запросы из lakehouse. См. раздел "Регистрация базы данных Lakebase" в каталоге Unity.
• Отображайте данные с помощью синхронизированных таблиц: синхронизируйте данные таблицы Unity Catalog с Lakebase для чтения с низкой задержкой и ускоряйте большие загрузки с помощью LTAP Direct Writes. См. Публикация данных Lakehouse с использованием синхронизированных таблиц.

• Поток данных об изменениях Lakebase: Передавайте изменения на уровне строк в Lakehouse для конвейеров и аудита. См. поток данных об изменениях Lakebase.

Узнать больше

• Объявление: Databricks запускает LTAP — первую архитектуру транзакционной/аналитической обработки Lake
• Инженерный блог: От монолита к Lakebase и LTAP: переосмысление базы данных от хранилища и вверх
• Демонстрация: LTAP: первая транзакционная/аналитическая архитектура Lake