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

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

Десятилетиями компании поддерживали две параллельные системы: операционную базу данных для транзакций и аналитическое хранилище для отчётов и ML. Между ними жил ETL-конвейер — источник задержек, ошибок и инженерной боли. Для ИИ-агентов, которые принимают решения на основе актуальных данных, такая архитектура стала структурным барьером.

На конференции Data + AI Summit компания Databricks представила два продукта, призванных закрыть эту проблему.

Что такое Lakehouse//RT и зачем он нужен агентам

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

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

LTAP: унификация на уровне хранения, а не движка

LTAP (Lake Transactional/Analytical Processing) — ответ Databricks на концепцию HTAP, которую Gartner ввёл ещё в 2014 году. Разница принципиальная:

• HTAP пытался объединить два типа нагрузок на уровне движка запросов (примеры: SingleStore, SAP HANA, MySQL Heatwave). Результат — компромиссная производительность для обоих сценариев.
• LTAP решает проблему на уровне хранения. Транзакционные данные Postgres записываются сразу в формате Delta или Iceberg — в момент записи, без дополнительного ETL.

Архитектура при этом остаётся специализированной: Postgres продолжает быть транзакционным движком, Spark — аналитическим. Меняется только то, что обе системы работают с одной копией данных в объектном хранилище.

Как решается проблема задержки объектного хранилища

Объектное хранилище (S3, GCS, ADLS) имеет время отклика в секундах — неприемлемо для OLTP-нагрузок, где нужны субмиллисекунды. Lakebase (сервис PostgreSQL от Databricks) решает это через слой кэширования между вычислительными экземплярами Postgres и объектным хранилищем.

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

Практическая ценность для бизнеса с ИИ-агентами

Если вы строите или планируете строить агентные системы поверх корпоративных данных, вот что меняется:

До LTAP:

1. Транзакция записывается в Postgres
2. ETL-конвейер (с задержкой от минут до часов) переносит данные в хранилище
3. Аналитический движок обрабатывает устаревшие данные
4. Агент принимает решение на основе неактуальной картины

После LTAP:

1. Транзакция записывается в Postgres
2. Данные в формате Delta/Iceberg доступны аналитике немедленно
3. Агент работает с текущим состоянием системы

Конкретные сценарии, где это критично:

• Fraud detection: агент должен реагировать на транзакцию в момент её проведения, а не через 15 минут после ETL
• Персонализация в реальном времени: поведение пользователя на сайте влияет на рекомендации прямо сейчас
• Операционные агенты: управление складом, динамическое ценообразование, мониторинг SLA

Что это означает для стека данных

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

LTAP и Lakehouse//RT не революция в смысле «всё изменилось за ночь». Это закрытие инфраструктурного долга, который накапливался с тех пор, как аналитические и транзакционные системы разошлись в разные стороны. Для команд, которые строят production-агентов, эта архитектура убирает один из главных практических барьеров.

---

*Разбираем ИИ-инструменты и автоматизацию в ContentRun Club.*