Репортаж от Wedoany，Компания Databricks объявила о запуске технологии под названием LTAP (lake transactional/analytical processing) с маркетинговым слоганом «одни данные, ноль компромиссов, ноль копий», направленной на решение проблемы сосуществования OLTP и OLAP в одной системе. Технология основана на открытом унифицированном аналитическом движке Apache Spark и опирается на два новых продукта: Reyden (новый вычислительный движок) и Lakebase (бессерверная PostgreSQL на основе открытого объектного хранилища). Databricks пытается объединить транзакционные, аналитические, потоковые и операционные данные на единой копии хранилища в рамках data lakehouse (сочетание озера данных и хранилища данных), решая фундаментальную проблему: OLTP выполняет небольшие построчные чтения и частые записи, тогда как OLAP — крупные поколоночные чтения и пакетные записи. Эта проблема становится особенно актуальной на фоне стремления рынка баз данных к рабочим нагрузкам, связанным с развертыванием AI-агентов.
Однако вокруг заявления о «нулевом копировании» возникли споры. Некоторые инженеры по данным отмечают, что в LTAP текущие данные PostgreSQL хранятся локально в формате pageserver, а затем распространяются в объектное хранилище в формате Parquet для долгосрочного хранения. PostgreSQL/Lakebase может извлекать данные из объектного хранилища и преобразовывать данные Parquet обратно в pageserver. Один из комментаторов, представляющий конкурента Databricks, указал, что на самом деле это «две копии данных, а не одна». На конференции по PostgreSQL в мае этого года слайды инженеров Databricks Христо Стоянова и Джонатана Каца также подтвердили это: pageserver обеспечивает хранение, а исполнители аналитики Spark извлекают слоистые файлы с полными образами страниц из зеркального слоя в объектном хранилище. В закрытом сообществе, с которым ознакомилось издание The Register, один из инженеров Databricks ответил, что технически это две копии, поскольку pageserver выступает в роли кэша или материализованного слоя в архитектуре Neon. Lakebase основан на технологии Neon, приобретённой Databricks в прошлом году, и поддерживает ветвление с копированием при записи (copy-on-write) и автоматически масштабируемые бессерверные вычисления.
Объединение OLTP и OLAP — не первая попытка Databricks. В 2014 году компания SingleStore начала исследования по использованию оперативной памяти для строчного хранения и дискового колоночного хранения, применив технологию многоуровневого хранения, позволяющую выполнять аналитику и транзакции в одной системе. В 2020 году компания запустила облачный сервис баз данных, который, по заявлению, автоматически управляет данными в трёхуровневой архитектуре: оперативная память, локальный кэш и объектное хранилище. В ответ на заявление Databricks о том, что гибридная транзакционная/аналитическая обработка (HTAP) потерпела неудачу, технический директор SingleStore Надим Асгар отметил, что объединение OLTP и OLAP как раз и является целью HTAP, и «переименование в LTAP меняет только маркетинг, но не физическую реальность». Он указал, что в системе Databricks работают три движка, каждый со своим кэшем и представлением о свежести данных, а физическая форма «двух копий» требует механизма синхронизации. Кроме того, MongoDB предлагает колоночные индексы, Oracle HeatWave for MySQL позволяет выполнять аналитику на транзакционных приложениях, а SAP с 2011 года продвигает аналитику в реальном времени на основе in-memory базы данных HANA.
Databricks настаивает на достоверности заявления о «нулевом копировании», утверждая, что это позволяет избежать двух авторитетных копий данных, требующих синхронизации. В заявлении для The Register представитель Databricks сообщил, что в LTAP пользователи работают с единственной авторитетной копией данных, которая имеет единый источник истины в Iceberg, а другие промежуточные внутренние копии относятся к «иерархии хранения базы данных». На недавней конференции Databricks уточнила, что данные имеют только одну «авторитетную» копию или только одну копию «в хранилище», что аналогично описанию SingleStore своего уровня хранения как «прозрачного для пользователя».
Энди Павло, доцент кафедры баз данных Университета Карнеги-Меллона (Carnegie Mellon University), отметил, что независимо от маркетинговых споров, Databricks проделала впечатляющую инженерную работу, позволив новому движку Reyden читать страницы PostgreSQL. Он пояснил, что интерпретация содержимого страниц PostgreSQL движком Reyden — непростая задача, поскольку страницы не являются полностью самодостаточными и требуют обращения к Neon/PostgreSQL для получения метаданных из каталога. Эта технология позволяет проводить более своевременный анализ, причём с транзакционной безопасностью, без необходимости ожидания выгрузки данных в S3. Кроме того, Reyden не имеет состояния и может масштабироваться горизонтально за счёт увеличения вычислительных ресурсов. Павло также признал, что «в конечном итоге они всё равно копируют данные».
