LTAP и Lakehouse//RT: как Databricks устранила задержки данных для ИИ-агентов

2026-06-22

Databricks представила LTAP и Lakehouse//RT — архитектуру без ETL-конвейеров для ИИ-агентов реального времени. Разбираем, как это работает и что даёт бизне

Проблема: агенты не могут работать с устаревшими данными

Каждая компания, которая строит ИИ-агентов поверх корпоративных данных, рано или поздно упирается в одно и то же: агент рассуждает на основе информации, которая уже устарела. Причина — классическая архитектура, при которой транзакционная база данных и аналитическое хранилище живут раздельно, а между ними работает ETL-конвейер с задержкой от минут до часов.

Для отчётности это терпимо. Для агента, который принимает операционные решения в реальном времени, это структурная проблема.

Решение: два продукта, одна копия данных

На конференции Data + AI Summit Databricks представила два продукта.

Lakehouse//RT обеспечивает миллисекундные запросы напрямую к таблицам Delta и Iceberg. Раньше для работы в реальном времени компании поддерживали отдельный real-time слой параллельно с основным лейкхаусом — со всеми сопутствующими расходами на синхронизацию и поддержку. Lakehouse//RT устраняет эту необходимость.

LTAP (Lake Transactional/Analytical Processing) идёт глубже. Транзакционные данные Postgres записываются сразу в формате Delta или Iceberg — ETL-конвейер исчезает из архитектуры. Postgres остаётся транзакционным движком, Spark — аналитическим. Но обе системы работают с единственной копией данных в объектном хранилище.

Ключевое отличие от предыдущих попыток (HTAP от SAP HANA, SingleStore, MySQL Heatwave): LTAP объединяет нагрузки на уровне хранения, а не на уровне движка. Каждый движок делает то, что умеет лучше всего — компромисса в производительности нет.

Результат: что меняется для бизнеса

Практический эффект можно описать через изменение цепочки:

Раньше: транзакция → Postgres → ETL (задержка) → хранилище → аналитика → агент принимает решение на устаревших данных.

Теперь: транзакция → Postgres + Delta/Iceberg одновременно → аналитика и агент работают с актуальными данными немедленно.

Сценарии, где это меняет результат:

Дополнительный бонус — сжатие данных. При конвертации из строкового формата в столбцовый степень сжатия превышает 10x, что снижает сетевые издержки между слоем кэширования и объектным хранилищем.

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

Опубликовано на ContentRun, внедрение ИИ в маркетинг и продажи. Что мы делаем.