Десятилетиями дата-инженеры возводили цивилизацию из костылей. Отдельная база для операционных записей (OLTP), отдельное облачное хранилище для аналитики (OLAP), отдельный real-time serving слой, чтобы BI-дашборды не тупили. Между всем этим — ETL-пайплайны, скрипты на Python, горы логов и вечная головная боль со свежестью данных. Архитектура, рождённая в эпоху, когда данные переваривались со скоростью человека.
Затем пришли AI-агенты. Системы, которые не ждут отчёта к пятнице. Им нужна живая, консистентная информация прямо сейчас и возможность писать обратно, не теряя контекст. И тут оказалось, что «десятилетняя проверенная архитектура» — это не надёжность, а хрупкий карточный домик. Потому что агент, который анализирует данные в одной системе, а пишет результат в другую — гарантированно сломается о рассинхронизацию.
И вот на конференции Data + AI Summit компания Databricks делает то, что у неё получается лучше всего — объявляет, что старые правила больше не работают, и предлагает свой молоток. Два анонса под кодовыми именами LTAP и Lakehouse//RT. Звучит как названия космических кораблей. Но на деле — это попытка одним махом разрубить гордиев узел дата-инфраструктуры.
LTAP: Когда HTAP не взлетел
Ещё в 2014 году Gartner придумала аббревиатуру HTAP (Hybrid Transactional/Analytical Processing). Идея была красивой: сделать один движок, который одинаково шустро и записывает транзакции (как база данных магазина), и выполняет сложные аналитические запросы (как Snowflake). Но на практике вышло как с универсальными солдатами — пытались всё, но не преуспели ни в чём. MemSQL (ныне SingleStore), SAP HANA, Oracle HeatWave — все они так или иначе жертвовали производительностью в угоду универсальности.
Databricks идёт с другой стороны и называет подход HTAP «неудачей индустрии». Их ответ — LTAP (Lake Transactional/Analytical Processing). Акцент смещается с универсального движка на унификацию слоя хранения. Раньше Postgres-данные в сервисе Lakebase хранились в родном формате Postgres на объектном хранилище. Когда аналитике надо было их читать — требовалась конвертация. Больно, медленно, дорого.
С LTAP транзакционные данные пишутся сразу в открытый формат — Delta Lake или Apache Iceberg. Физически это одна копия на том же S3-совместимом хранилище. Postgres остаётся движком для операционных запросов (вставка, обновление строк). Spark и Lakehouse — для аналитических (агрегации, JOIN’ы, ML-модели). Но под капотом они работают с одними и теми же файлами. Без ETL-прокладки. Без двойных копий. Без грязных данных, которые разъехались по разным системам.
Главная техническая проблема, которую пришлось решать — латентность. Объектное хранилище (S3, MinIO) выдаёт ответ за секунды. Для OLTP-запросов нужны миллисекунды. Инженеры Databricks добавили кэширующий слой между Postgres-вычислителями и хранилищем. И ключевая фишка: в этом кэше, пока CPU простаивает, строки конвертируются в колоночный формат. Сжатие даёт выигрыш в 10+ раз. Меньше данных — меньше сетевых затрат — быстрее чтение.
Lakehouse//RT: Убить dedicated serving tier
Вторая часть анонса — Lakehouse//RT. Это ответ на вопрос: «Зачем держать отдельную базу данных вроде Redis или ClickHouse, чтобы отдавать данные с низкой задержкой?». Databricks говорит: давайте сделаем так, чтобы живой Lakehouse сам отвечал за 10 миллисекунд.
Для этого они представили новый движок — Reyden. Он спроектирован специально для high-concurrency, low-latency serving. Читает Delta и Iceberg напрямую, без выгрузки. Заявленные характеристики: sub-100ms latency при 12 000 запросов в секунду, а на маленьких датасетах — до 10 мс. И в 16 раз быстрее существующих dedicated-решений.
Самое важное: управление доступом остаётся в Unity Catalog. Никаких дублирующихся permission-слоёв, никаких pipe’ов, которые копируют данные из Lakehouse в отдельный сервис. Одна политика безопасности. Одна копия данных. Никаких задержек на синхронизацию прав. Для AI-агентов, которые должны уметь «видеть» всё и сразу, это принципиально.
А что говорят аналитики?
Стефани Уолтер из HyperFRAME Research замечает: «Боль у дата-команд реальна, но ключевое отличие — это не новая технология, а её framing под AI-агентов». Действительно, HTAP и streaming решения были и десять лет назад. Но именно сейчас, когда агенты требуют живые данные, историю, governance и write-back в одном workflow, аргумент Databricks звучит весомо.
Майк Леоне из Moor Insights добавляет: «Открытые форматы на стороне аналитики уже стали стандартом. Но то, что транзакционные записи ложатся сразу в открытый формат — это реальный шаг вперёд. Потому что операционная база перестаёт быть чёрным ящиком». Он же сомневается в связке: «Я бы хотел увидеть, как инженеры докажут, что два движка действительно работают с одной копией, без скрытого слоя конвертации в середине».
И это главный вопрос: насколько прозрачно и надёжно реализована эта унификация? Ответ мы узнаем, когда продукт выйдет в промышленную эксплуатацию.
Что это значит для вас?
Если вы строите AI-агентов — ваша архитектура данных становится вашим узким местом. Раньше разрыв между OLTP и OLAP можно было зашить ETL-процессами с лагом в час. Теперь, когда агент сам пишет данные и их же анализирует, каждый разрыв — это потеря консистентности.
Databricks предлагает пари: вы выбрасываете dedicated serving tier (Redis, Aerospike) и отдельный real-time слой. Всё ложится на Lakehouse//RT. Вы выбрасываете ETL-пайплайны между Postgres и хранилищем — LTAP унифицирует слой хранения. По данным опроса VB Pulse Q1 2026, тренд уже идёт: standalone векторные базы данных теряют долю, а гибридные retrieval-подходы растут. Та же консолидация происходит и в real-time serving.
Будет ли это работать в продакшене — вопрос инженерной дисциплины. Но вектор движения ясен: меньше специализированных коробок, одна живая копия данных и архитектура, которая не тормозит AI-агента.