Databricks ставить $0 на ETL: LTAP об'єднує OLAP і OLTP

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

Що відбулося

В одному keynote були представлені три продукти. Перший — LTAP (Lake Transactional/Analytical Processing), нова архітектура, яка розміщує Lakebase — описаний як серверний Postgres на відкритому об'єктному сховищі — під тим самим управлінням Unity Catalog і шаром зберігання, що й Lakehouse. Як повідомляє Blocks & Files, LTAP зберігає дані безпосередньо в Unity Catalog у відкритих форматах, тому він сумісний із будь-яким застосунком, що підтримує Postgres, на стороні запису, та з будь-яким читачем Iceberg або Delta на аналітичній стороні. LTAP перебуває в статусі «незабаром» у складі Lakebase.

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

Третій — CustomerLake, агентна платформа клієнтських даних (CDP), побудована нативно на Lakehouse, наразі в Private Preview з такими клієнтами, як HP, Circle K, AB InBev і Getnet by Santander. Це другий вихід Databricks на визначений ринок корпоративного програмного забезпечення після Lakewatch у сфері безпеки, і ціноутворення буде базуватися на споживанні, а не на традиційній ліцензії.

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

Технічна анатомія

Цікава інженерна заява в LTAP — не «ми зробили HTAP». Чимало постачальників пробували єдиний рушій OLTP+OLAP, з неоднозначними результатами щодо ізоляції та конкурентності. Databricks робить дещо вужче й, мабуть, чесніше: зберігає два рушії виконання (Postgres для транзакцій, стек Lakehouse для аналітики), але змушує їх читати та писати одну фізичну копію даних в Unity Catalog у відкритих табличних форматах. Жодного CDC-пайплайну, жодного ETL-завдання, жодного відставання другої копії.

Якщо це витримає навантаження, модель витрат зміниться у двох місцях. По-перше, рахунок за зберігання перестане подвоюватися для кожного датасету, якому потрібен і транзакційний, і аналітичний доступ. По-друге, SLA актуальності аналітики зміниться з «відставання на кілька хвилин від продакшну» на «і є продакшн». Порівняйте це з поширеним патерном: 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 для продакшн-даних — це функція, яку інженерні команди реально використовуватимуть із першого дня.

Хто постраждає

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

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

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

План дій для дата-команд

На цьому тижні — три конкретні кроки. По-перше, проведіть аудит того, скільки копій ваших найгарячіших клієнтських або транзакційних таблиць існує у вашому стеку. Порахуйте OLTP-первинний, кожну репліку, кожен CDC-приймач, кожну копію у сховищі та кожну кінцеву точку зворотного ETL. Ця цифра — ваш бізнес-кейс для LTAP. Якщо вона чотири або вище, економія на зберіганні та узгодженні сама по собі виправдовує пілот.

По-друге, не мігруйте продакшн на Lakehouse//RT Beta або LTAP «незабаром». Натомість побудуйте паралельну вимірювальну обв'язку. Виберіть один дашборд реального часу або один сервіс прапорів функцій для клієнтів, продублюйте навантаження та виміряйте затримку p50, p95 і p99 на Reyden порівняно з вашим поточним шаром обслуговування — з вашими даними, а не з бенчмарк-даними Databricks. Показник 16x — це максимум, повідомлений клієнтами. Ваше число буде іншим і є єдиним, що має значення.

По-третє, якщо ви сьогодні використовуєте CDP, запитайте у свого аккаунт-менеджера, як виглядає шлях міграції, до того як CustomerLake вийде з Private Preview. Ціноутворення базується на споживанні, а не на ліцензіях на місця, що робить моделювання 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 або скидання цін від щонайменше одного спеціалізованого постачальника аналітики реального часу протягом двох кварталів.