Databricks ставит $0 на ETL: LTAP объединяет OLAP и OLTP

Databricks вышла на свой саммит Data + AI Summit в Сан-Франциско — мероприятие, которое собрало уже более 30 000 участников очно — и объявила о трёх вещах, которые вместе представляют собой попытку уничтожить целую категорию затрат на инфраструктуру данных: ETL-пайплайны, специализированные стеки для обслуживания в реальном времени и самостоятельные платформы клиентских данных. Ключевая цифра — 16x. Это верхняя граница ускорения, о которой сообщают клиенты при переходе с существующих специализированных стеков на новый движок Lakehouse//RT — по собственным данным Databricks. Ключевое архитектурное заявление — LTAP, который объединяет транзакционную и аналитическую обработку в одной управляемой копии данных.

Что произошло

В рамках одного keynote были представлены три запуска. Первый — LTAP (Lake Transactional/Analytical Processing), новая архитектура, которая помещает Lakebase — описанный как serverless Postgres на открытом объектном хранилище — под ту же систему управления Unity Catalog и тот же слой хранения, что и Lakehouse. Как сообщил Blocks & Files, LTAP хранит данные непосредственно в Unity Catalog в открытых форматах, поэтому он работает с любым приложением, поддерживающим Postgres, на стороне записи, и с любым ридером Iceberg или Delta — на аналитической стороне. LTAP значится как «coming soon» в составе Lakebase.

Второй — Lakehouse//RT, уровень реального времени, работающий на базе нового вычислительного движка Reyden. Databricks заявляет о миллисекундной задержке запросов к управляемым таблицам Delta Lake и Apache Iceberg с поддержкой десятков тысяч одновременных пользователей и агентов. Клиенты сообщают о времени отклика от 10 мс на небольших датасетах, менее 100 мс на больших и менее 100 мс при 12 000 запросов в секунду на стандартных аналитических бенчмарках. Lakehouse//RT находится в стадии Beta.

Третий — CustomerLake, агентная платформа клиентских данных (CDP), созданная нативно на Lakehouse, в настоящее время в Private Preview с HP, Circle K, AB InBev и Getnet by Santander в качестве названных клиентов. Это второй выход Databricks на определённый рынок корпоративного ПО после Lakewatch в сфере безопасности, и ценообразование будет основано на модели потребления, а не на традиционной лицензии на ПО.

Генеральный директор Али Годси представил весь пакет в терминах агентов: «Организации фактически удвоили свою рабочую силу — просто не с помощью людей. Агенты пишут код, совершают звонки и выполняют циклы с темпом, недоступным для человеческих команд». Его аргумент состоит в том, что инфраструктура, созданная для аналитики в человеческом темпе, теперь является узким местом. Lakebase, для справки, был запущен только в прошлом году и уже насчитывает тысячи клиентов, включая Block, Ensemble, Superhuman и Zillow, а также 12 миллионов запусков баз данных в день.

Техническая анатомия

Интересное инженерное заявление в LTAP — не «мы сделали HTAP». Многие вендоры пробовали объединить OLTP+OLAP в одном движке с неоднозначными результатами в части изоляции и конкурентности. Databricks делает нечто более узкое и, пожалуй, более честное: сохраняет два движка исполнения (Postgres для транзакций, стек Lakehouse для аналитики), но обязывает их читать и записывать одну физическую копию данных в Unity Catalog с использованием открытых форматов таблиц. Никакого CDC-пайплайна, никакого ETL-задания, никакой задержки из-за второй копии.

Если это выдержит нагрузку, это изменит модель затрат в двух местах. Первое: счёт за хранение перестаёт удваиваться для каждого датасета, которому нужен как транзакционный, так и аналитический доступ. Второе: SLA по свежести данных для аналитики меняется с «отстаёт от production на несколько минут» на «и есть production». Сравните это с распространённой схемой: Postgres или MySQL, питающий Debezium или Fivetran, ведущий в Delta или Snowflake, с dbt-трансформациями ниже по потоку. Этот стек работает, но это три вендора и вечная проблема согласования.

Reyden, движок за Lakehouse//RT, — более серьёзный технический вопрос. Питч — миллисекундная задержка на открытых форматах при 12 000 QPS, напрямую с таблицами Delta и Iceberg, без проприетарного формата и без отдельного слоя обслуживания. Это ставит его в один ряд с ClickHouse, Pinot и Druid, которые годами оптимизировались именно под такой профиль задержки. Источник не раскрывает размер датасета для бенчмарка, ширину строк, селективность предикатов или состояние кэша — а это важно, потому что «менее 100 мс при 12 000 QPS» может означать всё что угодно: от «тривиальные точечные запросы на тёплом кэше» до «сложные агрегации на холодном хранилище». Пока Databricks не опубликует воспроизводимый прогон TPC-H или аналогичный с этими цифрами, показатель 16x от клиентов носит индикативный, а не бенчмарковый характер.

Дополнения Lakebase — недооценённая часть: кросс-облачное, кросс-региональное восстановление после сбоев, Git-подобное ветвление и снапшоты, а также автономные операции с базами данных, где AI-агенты отслеживают состояние, предлагают индексы и помогают с восстановлением. Git-подобное ветвление для production-данных — это функция, которую инженерные команды будут использовать с первого дня.

Кто пострадает

Наиболее уязвимая категория — специализированные вендоры аналитики в реальном времени. Если Lakehouse//RT обеспечивает хотя бы что-то близкое к показателю 16x по сравнению с существующими стеками обслуживания, вопрос закупок для Databricks-магазина становится неудобным: зачем платить за второй движок, вторую модель разрешений и CDC-пайплайн для его питания? ClickHouse, Pinot, Rockset-подобные слои обслуживания и различные стартапы в области «real-time OLAP» должны сформулировать, что они делают, чего не делает Reyden. Мы пока не знаем, как Reyden ведёт себя при соединениях с высокой кардинальностью или на рабочих нагрузках с интенсивными мутациями, и граница там имеет значение: если производительность деградирует на нагрузке с множеством точечных запросов, типичной для дашбордов продуктовой аналитики, заявление 16x сужается до узкого сегмента.

Следующая категория — самостоятельные CDP-вендоры. CustomerLake — это прямой удар по Segment, mParticle, Treasure Data и слою активации Adobe и Salesforce. Формулировка «бесконечные кампании» — непрерывные агентные циклы, персонализирующие 1:1 миллиард раз в день — это маркетинговый язык, но архитектурный аргумент под ним весомый: если клиентские данные уже хранятся в Lakehouse, прикручивать CDP, который копирует их обратно, — нелепо. То, что HP и AB InBev названы клиентами, сигнализирует: Databricks идёт за CDP-бюджетами компаний Global 2000, а не среднего рынка.

Команды в сфере iGaming и финтех должны внимательно следить за этим. Оба вертикальных рынка работают с горячим OLTP (ставки, транзакции, KYC-события), питающим интенсивную аналитику (модели фрода, риск-дашборды, персонализация). Нынешняя схема — Postgres или Aurora плюс стриминговый пайп в хранилище. LTAP, если он выполнит обещание по изоляции, убирает стриминговый пайп. Неизвестное — конкурентность при ограничениях аудита регулируемых рабочих нагрузок: источник не сообщает, как масштабируются журналы аудита Unity Catalog при устойчивых скоростях транзакционной записи, а это первый вопрос, который задаст CISO финтех-компании.

Руководство для команд данных

На этой неделе — три конкретных шага. Первый: проведите аудит того, сколько копий ваших самых горячих таблиц клиентов или транзакций существует в вашем стеке. Подсчитайте OLTP-primary, каждую реплику, каждый CDC-сток, каждую копию в хранилище и каждый reverse-ETL-эндпоинт. Это число — ваш бизнес-кейс для LTAP. Если оно четыре или выше, экономия на хранении и согласовании уже оправдывает пилот.

Второй: не мигрируйте production на Lakehouse//RT Beta или LTAP «coming soon». Вместо этого создайте параллельный стенд для измерений. Выберите один дашборд реального времени или один сервис feature flag для пользователей, зеркалируйте нагрузку и измеряйте задержку p50, p95 и p99 на Reyden по сравнению с вашим текущим слоем обслуживания — с вашими данными, а не с бенчмарковыми данными Databricks. Показатель 16x — это потолок, заявленный клиентами. Ваш показатель будет другим и является единственным, который имеет значение.

Третий: если вы сегодня используете CDP, спросите у вашего аккаунт-менеджера, как выглядит путь миграции, прежде чем CustomerLake выйдет из Private Preview. Ценообразование основано на потреблении, а не на лицензии per seat, что делает моделирование TCO нетривиальным. Получите оценку использования на основе вашего фактического объёма событий до того, как зафиксируется прайс-лист GA.

Если LTAP и Reyden выдержат заявленную производительность, в течение следующих двух кварталов мы должны увидеть, как минимум, одного крупного специализированного вендора аналитики в реальном времени, объявляющего о нативной интеграции с Databricks или о пересмотре конкурентного ценообразования. Если к концу 2026 года этого не произойдёт — это сигнал, что технические заявления уже, чем предполагал keynote.

Ключевые выводы

• Настоящая инновация LTAP — одна физическая копия данных в Unity Catalog, с которой работают движки Postgres и Lakehouse. Никакого CDC, никакого ETL, никакой второй копии.
• Lakehouse//RT заявляет о задержке менее 100 мс при 12 000 QPS и ускорении до 16x по сравнению с существующими стеками реального времени, однако датасет для бенчмарка, состав запросов и состояние кэша не раскрываются.
• Lakebase вырос от запуска до тысяч клиентов и 12 миллионов запусков баз данных в день за один год, включая Block, Superhuman и Zillow.
• CustomerLake (Private Preview, HP, Circle K, AB InBev, Getnet) — второй выход Databricks в вертикальное ПО после Lakewatch, с ценообразованием на основе потребления, а не мест.
• Проверяемый прогноз: если заявления Reyden подтвердятся, ожидайте нативной интеграции с Databricks или пересмотра ценообразования минимум от одного специализированного вендора аналитики в реальном времени в течение двух кварталов.