Databricks 3 июля представила архитектуру Databricks LTAP и заявила, что объединила транзакционные и аналитические нагрузки без дублирования данных. Для команд, которые строят AI-сервисы, внутренние платформы данных и продуктовую аналитику, здесь важна не рекламная формула про «zero copies», а более приземленный вопрос: можно ли действительно читать свежие транзакции аналитическим движком без привычного ETL-зазора и без нового слоя боли в эксплуатации.
Как пишет The Register, Databricks описывает LTAP как lake transactional/analytical processing. Схема опирается на два новых для этой истории компонента: Reyden, новый compute engine для lakehouse, и Lakebase, собственный serverless PostgreSQL на объектном хранилище. Заявка амбициозная: не пытаться запихнуть OLTP и OLAP в один движок, а объединить их на уровне хранения, чтобы транзакции, аналитика, стриминг и операционные данные жили в одном lakehouse.
На бумаге это выглядит как ответ на старую головную боль индустрии. OLTP-системы оптимизированы под мелкие чтения и частые записи по строкам. OLAP-системы, наоборот, любят большие сканы, колонночное хранение и пакетные обновления. Свести эти два мира в одну физическую модель сложно уже на уровне страниц, форматов и компромиссов по производительности. Сейчас задача снова в моде, потому что рынок данных ищет архитектуры под AI-агентов: им нужно не только обучаться на исторических массивах, но и быстро читать и писать в боевых системах без долгой синхронизации между базой, витриной и очередным аналитическим контуром.
Но именно на этом месте и начинается спор о формулировках. Транзакционная часть LTAP построена вокруг Lakebase, а та, в свою очередь, базируется на технологиях Neon, который Databricks купила в прошлом году. Инженеры и конкуренты быстро разобрали схему: актуальные данные PostgreSQL остаются в формате pageserver как локальное представление, затем отправляются в объектное хранилище для долговечности и аналитики уже в формате Parquet, а при обращении к «холодным» данным могут снова восстанавливаться в вид, пригодный для PostgreSQL. Иными словами, Databricks действительно сближает транзакционное и аналитическое хранение, но физически это не похоже на магию с одной-единственной формой данных. На конференции по PostgreSQL в мае инженеры Databricks Христа Стоянов и Джонатан Кац прямо показывали, что pageserver дает хранение для Postgres, а Spark-исполнитель для аналитики читает layer files с полными образами страниц из объектного хранилища.
Внутри самой компании формулировки тоже оказались менее категоричными, чем в маркетинговых слайдах и интервью. По данным The Register, один из инженеров Databricks в закрытом сообществе признал: технически копий две, потому что pageserver в архитектуре Neon работает как кэш или слой материализации. Позиция компании при этом такая: у пользователя остается одна «авторитетная» копия данных, один source of truth в Iceberg, а все остальное относится к обычной и неизбежной иерархии хранения, где между кэшами процессора, оперативной памятью и blob storage всегда есть промежуточные представления. Формально это аккуратнее, чем лозунг «zero copies». Практически же спор упирается в то, что считать копией: второе независимое хранилище, которое надо синхронизировать, или любой отдельный физический формат тех же данных.
Конкуренты, разумеется, не промолчали. SingleStore напомнила, что рынок уже много лет пытается решить ту же задачу под вывеской HTAP. Компания еще в 2014 году начала развивать схему с row store в памяти и column store на диске, а в 2020-м вывела облачный сервис с трехуровневой архитектурой хранения на AWS, Azure и GCP. CTO SingleStore Надим Асгар довольно едко заметил: нельзя объявить HTAP неудачей, а потом двадцать минут объяснять, почему миру нужен именно HTAP. Его главный аргумент бьет ровно в боль инженеров: даже если считать, что authoritative copy одна, над ней все равно сидят несколько движков со своими кэшами, своей моделью свежести и своими режимами отказа. Если запись ложится в строчное представление Postgres, а аналитика читает колонночное, значит кто-то все равно должен поддерживать эти формы в согласованном состоянии.
Впрочем, если отрезать маркетинговый слой, под капотом у Databricks есть действительно сильная инженерная работа. Профессор Карнеги-Меллона Энди Павло отметил, что Reyden умеет читать записи практически сразу после того, как их принимает фронтенд Neon/PostgreSQL, и это нетривиальная задача. Проблема не в том, чтобы распарсить одну страницу Postgres: это как раз сравнительно просто. Сложность в том, чтобы корректно понять, какие версии строк видимы для конкретного запроса, какие метаданные нужно подтянуть из каталога и как соблюсти транзакционную безопасность. По сути, Reyden научили интерпретировать содержимое PostgreSQL-страниц и разруливать видимость данных без ожидания, пока все окончательно «вытолкнется» в S3-подобное хранилище. Для near-real-time аналитики это уже не игра в слова, а вполне осязаемый выигрыш.
Для разработчиков и продуктовых команд здесь важны два вывода. Первый: Databricks LTAP не отменяет физику систем хранения, поэтому обещание «ноль копий» лучше читать как «без двух независимых мастер-копий, которые нужно синхронизировать». Второй: если архитектура действительно дает аналитике быстрый и безопасный доступ к свежим транзакциям, это может сократить лаг между боевой базой и аналитическим контуром в сценариях с AI-агентами, персонализацией, fraud detection и операционной отчетностью. Но вместе с этим вырастает цена ошибок в семантике согласованности, кэшировании и деградациях под нагрузкой. Для CIO и дата-платформенных команд вопрос будет не в красоте слогана, а в том, как именно эта схема ведет себя на сбоях, при всплесках записи и на смешанных workload'ах.
На рынке данных давно пытаются стереть границу между OLTP и OLAP: от SAP HANA и Oracle HeatWave до MongoDB с column-store index. Databricks, похоже, подошла к задаче ближе с точки зрения интеграции lakehouse и PostgreSQL. Но главный тест для LTAP будет не в конференционных демо, а в том, согласятся ли инженеры считать одну «авторитетную» копию достаточным определением единства данных, когда под ней уже живут несколько физических представлений и довольно хитрая машинерия синхронизации.