Databricks продвигает LTAP как основу для агентных приложений

LTAP обещает меньше ETL-пайплайнов, ниже затраты и лучшее управление данными

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

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

На ежегодном мероприятии Data + AI Summit компания представила Lake Transactional and Analytical Processing (LTAP) — новую архитектуру, призванную объединить транзакционные и аналитические данные на одном слое хранения.

По словам Databricks, новый подход отличается от традиционных архитектур online transaction processing (OLTP) и online analytical processing (OLAP), где операционные и аналитические данные обычно хранятся в отдельных системах.

Обычно базы данных OLTP оптимизированы для повседневных бизнес-операций, таких как обработка заказов, платежи и обновление запасов, тогда как системы OLAP предназначены для крупномасштабных аналитических запросов и отчетности.

Из-за этого предприятиям часто приходится опираться на ETL pipelines, репликацию данных и отдельную инфраструктуру, чтобы переносить информацию между двумя средами.

Databricks заявляет, что LTAP стремится убрать зависимость от ETL pipelines, реплицированных баз данных и отдельных копий данных, храня данные один раз в общем слое lakehouse и позволяя отдельным вычислительным движкам независимо обрабатывать транзакционные и аналитические нагрузки.

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

Простота разработки в эпоху agentic

Аналитики тоже согласны с тезисом Databricks о том, что ИИ-агенты предъявляют новые требования к корпоративным архитектурам данных.

«Агенты ведут себя не как люди и даже не как приложения, которые мы строили для людей. Они считывают контекст, повторяют действия, пробуют варианты, затем записывают что-то обратно — тысячи раз и в способах, которые невозможно полностью предсказать. На таком объеме постоянное переключение между production и аналитическими системами начинает становиться узким местом. Давление на сокращение этого разрыва реально, и LTAP — один из способов подойти к этому», — сказал Michael Leone, главный аналитик Moor Insights and Strategy.

Bhupendra Chopra, сооснователь и CRO ИТ-консалтинговой компании Kanerika, отметил, что характер доступа автономного агента к данным делает традиционные архитектуры хрупкими: «Мы видим это напрямую у клиентов, внедряющих multi-agent systems: слой pipeline почти сразу становится потолком, когда агент запускается сотни раз на одну задачу».

Аналитики также указали, что возможность сократить разрыв между OLAP и OLTP, вероятно, поможет разработчикам проектировать более устойчивых ИИ-агентов или приложения, которые предприятия сейчас и пытаются внедрять.

«Самые интересные шаблоны рабочих процессов или приложений — это приложения в реальном времени, учитывающие контекст, которые объединяют транзакции, аналитику и ИИ в одном потоке», — сказала Stephanie Walter, руководитель практики AI stack в HyperFRAME Research.

«Примеры включают ИИ-агентов, которые обновляют customer workflows, одновременно видя исторический контекст аккаунта, а также antifraud-системы, которые реагируют на живые транзакции и долгосрочные поведенческие паттерны», — добавила Walter.

Как отметил Leone, создание таких приложений сегодня потребовало бы от разработчиков собирать данные из транзакционных систем, хранилищ данных, vector databases и других источников через custom integrations, что создает заметную инженерную сложность и нагрузку на поддержку.

Операционная простота и выигрыши в governance для CIO

Для CIO способность LTAP снизить эту инженерную сложность, по словам Ashish Chaturvedi, руководителя executive research в HFS Research, даст и операционную простоту, и экономию затрат.

«Самое заметное преимущество — это меньшее число data pipelines и все, что исчезает вместе с ними. Многие предприятия не осознают, какая часть их бюджета на data engineering уходит просто на обслуживание инфраструктуры», — сказал Chaturvedi.

Chopra из Kanerika отметил, что значительная часть мощности data engineering в средних и крупных компаниях сегодня уходит на поддержание синхронизации между транзакционными и аналитическими системами.

Однако, как подчеркнул Chaturvedi, последствия не ограничиваются продуктивностью разработчиков, архитектурной простотой или экономией затрат: «Стратегический приз — это упрощенное governance. Когда у вас одна копия данных под одной моделью governance вместо того, чтобы те же данные были разбросаны по operational stores, replicas, warehouses и vector databases, вы решаете проблему фрагментации governance».

По словам Chopra, такое упрощение будет операционно важно для предприятий, внедряющих несколько ИИ-агентов, поскольку эти рабочие процессы могут усиливать пробелы в governance со скоростью и масштабом, которых никогда не давали человеческие процессы.

LTAP против HTAP

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

Похожую задачу индустрия пыталась решать с помощью архитектуры Hybrid Transactional and Analytical Processing (HTAP), которая должна была объединить операционные и аналитические нагрузки на тесно связанной инфраструктуре, обслуживая оба типа нагрузки из одной системы.

LTAP, напротив, разделяет storage и compute, позволяя разным движкам обращаться к общему слою данных и при этом масштабироваться независимо, заявила Databricks.

Именно это разделение вычислительных движков, по мнению аналитиков, делает LTAP более перспективным вариантом, чем HTAP.

«HTAP так и не взлетел, потому что попытка заставить одну тесно связанную систему быть одновременно отличной в транзакциях и аналитике обычно делала ее посредственной в обоих случаях, а клиенты в итоге платили премию за этот компромисс», — сказал Leone.

«Я считаю, что разделение storage и compute — правильный инстинкт, и это тот же шаг, который сделал современный облачный мир данных работоспособным. Это важно потому, что HTAP погубило то, что одна нагрузка вытесняла другую, а дать каждой стороне собственный выделенный движок — именно так и предотвращается такая проблема», — добавил он.

Еще одной причиной провала HTAP, по словам David Menninger, исполнительного директора по исследованиям ПО в ISG, было то, что предприятиям приходилось заменять существующие платформы данных новой архитектурой.

LTAP, напротив, опирается на уже привычную практику разделения compute и storage, поэтому добавление операционного слоя требует меньшей архитектурной перестройки и потенциально снижает барьер для внедрения, добавил Menninger.

Пока не архитектура по умолчанию для ИИ-агентов

Однако, несмотря на энтузиазм вокруг LTAP, аналитики предупредили CIO не воспринимать его как неизбежного преемника существующих архитектур данных.

«CIO все равно придется выбирать архитектуру данных с учетом задержки, надежности, совместимости с экосистемой, стоимости, соответствия требованиям и опыта разработчиков», — сказала Walter.

Поддержав ее позицию, Chaturvedi отметил, что для превращения LTAP в де-факто стандарт отрасли Databricks понадобится не только элегантная архитектура: «На бумаге архитектура выглядит убедительно. Проверка будет в цифрах commit-to-query latency под реальной нагрузкой».

Databricks заявила, что LTAP вскоре должен выйти как часть Lakebase, не назвав конкретных сроков.

Материал — перевод статьи с английского.

Оригинал: Databricks pitches LTAP as a new foundation for agentic applications