Databricks обещал конец баз данных. Читаем мелкий шрифт

Серия «Новости мира Datalakehouse».

ПРОДОЛЖЕНИЕ анонса

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

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

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

Коротко

• Databricks показал движок реального времени Lakehouse//RT (на новом движке Reyden), архитектуру LTAP — транзакции и аналитика «на одной копии», — и обвязку под ИИ-агентов.

• «Zero-copy, запрос прямо по озеру»: их же сооснователь описывает кэширующий слой, в который данные материализуются. Без отдельной копии для пользователя — да; без внутренней материализации — нет.

• «Одна копия без ETL»: на деле сегодня это две копии и управляемая синхронизация раз в ~15 секунд, которую документация Databricks сама называет reverse ETL. Сама архитектура LTAP ещё не вышла.

• Транзакционная основа Lakebase — это купленный в 2025 году Neon, управляемый serverless-Postgres.

• Цифры громкие (12 000 запросов в секунду, до 16x), но без конфигурации, объёма данных и перцентилей задержки — проверить или сравнить их нельзя.

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

• Сам принцип — метаданные в обычной SQL-базе, открытые форматы, каталог как точка управления — не нов и доступен on-premise, например в DuckLake.

О чём вообще речь

Чтобы дальше было понятно всем, а не только тем, кто живёт внутри этой темы, — быстрый ликбез.

Lakehouse — это подход, при котором вся аналитика компании лежит в одном общем хранилище поверх дешёвых файлов в объектном хранилище (S3 и аналоги), в открытых табличных форматах вроде Delta Lake и Apache Iceberg. Идея в том, чтобы не держать отдельно «озеро» сырых данных и отдельно дорогой аналитический склад, а совместить.

У этой схемы есть давняя слабость. Когда дашборду нужен мгновенный ответ — миллисекунды, а не секунды, — данные обычно копируют из озера в отдельную «быструю» систему: ClickHouse, Apache Pinot, Druid и подобные. Появляется второй контур, который надо кормить, синхронизировать и обслуживать. Вот в эту точку Databricks и бьёт.

Lakehouse//RT: обещание ответа за 10 миллисекунд

Главный технический анонс — движок Reyden и построенный на нём продукт Lakehouse//RT. Обещание простое: быстрые запросы напрямую по таблицам Delta и Iceberg, без отдельной системы под витрины. Заявленные показатели — ответ за 10 мс на небольших данных и до 100 мс на крупных, 12 000 запросов в секунду, до 16 раз быстрее специализированных решений. Статус — бета, пока только на чтение.

Технических деталей самого движка в блоге практически нет: ни архитектуры, ни того, как он работает с форматами, ни сравнения с их прежним движком Photon. Зато есть одна оговорка, которая многое объясняет.

Формулировку «zero-copy» — то есть «запрос идёт прямо по озеру, без копий данных» — стоит читать внимательно. Десять миллисекунд по колоночному Parquet, который лежит в объектном хранилище, физически не получить: один поход в S3 за первым байтом и то занимает дольше. И тут не нужно ничего домысливать: сооснователь Databricks Reynold Xin в интервью прямо описывает кэширующий слой между движком и хранилищем, в который данные перекодируются из строк в колонки со сжатием больше чем в десять раз. То есть данные для быстрого ответа всё же материализуются в промежуточном слое — по их собственным словам.

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

LTAP и Lakebase: «одна копия без ETL»

Второй большой тезис — архитектура LTAP (Lake Transactional/Analytical Processing). По-русски: объединить операционную, транзакционную нагрузку (та, что обслуживает приложения — заказы, профили, состояние) и аналитику на одних и тех же данных, без перекачки между ними. «Конец пайплайнов» — это как раз отсюда.

Здесь важно отделить заявленное от того, что работает сегодня, потому что это разные вещи.

Сама архитектура LTAP, по их же словам, ещё не вышла — помечена «coming soon». А то, что доступно прямо сейчас, устроено так. Транзакции обслуживает Lakebase — управляемый Postgres. Чтобы эти данные стали видны аналитике, работает расширение wal2delta: оно читает журнал транзакций Postgres (тот самый WAL) и пишет изменения в отдельные таблицы Delta, пачками примерно раз в пятнадцать секунд. Обратную синхронизацию — из озера обратно в Postgres — документация Databricks сама называет reverse ETL.

Сложите это вместе. На практике сегодня это две копии данных и управляемая синхронизация между ними с задержкой в секунды. Не мгновенное единство, обещанное со сцены, а аккуратно сделанный конвейер, у которого просто убрали слово «конвейер» из названия. Идея хорошая, реализация рабочая — но «без ETL» здесь пока авансом.

Ещё одна деталь, о которой стоит знать. Сам Lakebase — это не написанный с нуля прорыв, а технология Neon, которую Databricks купил в 2025 году: serverless-Postgres с отделённым хранилищем и копированием-при-записи. Хорошая покупка, зрелая вещь. Но «прорыв со сцены» и «купленный год назад стартап» — немного разные истории.

А кому это вообще нужно

И вот тут — самое важное, потому что за громкими словами теряется простой вопрос: какие транзакции вы реально доверите такой системе.

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

И это видно по их собственным примерам внедрения. easyJet перенесла на Lakebase внутренний операционный портал и старую среду SQL Server. Ensemble гоняет через него обработку медицинских потоковых данных под ИИ. Block, Zillow, Superhuman — бэкенды своих приложений и телеметрия. Ни одного примера про систему, где недопустима потеря даже одной записи.

То есть реальный класс, очерченный самими кейсами, — это быстрые витрины и операционные приложения на данных, значимых чисто статистически: телеметрия, события и возможно их справочники в которых можно “прямо по месту” работать с данными. Там, где потеря отдельной строки переживается и не превращается в финансовую дыру. Сценарий нормальный и полезный. Просто это не «единое хранилище для всего», а вполне конкретная и понятная ниша.

Цифры есть, методологии под ними нет

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

Под красивыми показателями производительности не раскрыто почти ничего: ни конфигурация кластера, ни объём данных (для теста TPC-H назван только потолок «до 1 ТБ»), ни имена конкурентов, которых обошли в сравнении. Перцентили задержки под нагрузкой — P95 и P99, по которым и судят, годится ли движок для боевой выдачи под тысячами одновременных запросов, — не опубликованы вовсе. А именно хвост задержек, а не средняя цифра, решает, развалится сервис под нагрузкой или нет.

Конкуренты этим, разумеется, воспользовались. StarTree, которая делает движок на базе Apache Pinot, приводит встречную цифру: их движок в продакшене LinkedIn держит 200 000 запросов в секунду, тогда как у Databricks речь о 12 000 на лабораторном стенде. Цифра конкурента — тоже маркетинг, но разрыв показателен.

А единственный независимый замер, у партнёра Databricks — компании Perficient, дал отрезвляющую картину. Четырёхкратное увеличение кластера ускорило запросы с 86 до 93 миллисекунд — то есть в пределах погрешности, больше железа почти не помогло. А один из типов запросов на новом движке оказался даже медленнее обычного Databricks SQL. Это не значит, что движок плохой. Это значит, что реальная картина сложнее одной героической цифры со слайда.

Сам принцип, кстати, не новый

Если отвлечься от масштабов и ценников, базовые идеи здесь известны давно: метаданные в обычной SQL-базе, данные в открытых форматах, инлайн мелких изменений прямо в каталог, каталог как единая точка управления. Всё это встречается и в открытых инструментах — например, в DuckLake, который работает on-premise и без лицензионной платы.

Сразу важная оговорка, чтобы меня правильно поняли: внутренней реализации Databricks никто со стороны не видел, на код-ревью меня не звали, и я не утверждаю, что кто-то у кого-то списал. Речь о сходстве подхода на уровне идей. Но когда крупный вендор продаёт со сцены как откровение принцип, который в открытом виде давно крутится у тебя на собственном железе, — стоит хотя бы спросить себя, за масштаб ты платишь или за вывеску.

Где это оправдано, а где нет

Чтобы не свалиться в огульное «всё плохо», расставлю границы по делу.

Где Lakehouse//RT и LTAP уместны. Быстрые операционные дашборды и встроенная в приложения аналитика поверх данных, которые и так живут в экосистеме Databricks. Свежие данные для ИИ-агентов, где лаг в секунды терпим. Сценарии, где «всё в одной платформе» экономит реальную возню с отдельным serving-контуром. Если вы уже на Databricks и ваши данные — это потоки и события, инструмент закроет боль.

Где я бы не спешил. Системы, где запись — это деньги и потеря недопустима. Требования к данным внутри собственного контура — санкционные, регуляторные, по безопасности. Случаи, где вам реально нужны сотни тысяч запросов в секунду с предсказуемым хвостом задержек — пока нет опубликованных P99, это покупка кота в мешке. И ситуации, где те же принципы закрываются скромным open-source стеком on-premise без облачного ценника.

Что в сухом остатке

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

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

В следующей части серии разберу, что на том же саммите происходило вокруг ИИ-агентов и почему «семантический слой» — это во многом переоткрытая работа администратора баз данных. Продолжение следует.