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

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

Агенты сделали эту проблему структурной. Система, которая непрерывно рассуждает и действует на основе актуальных данных, не может терпеть конвейер данных (пайплайн) между собой и информацией, необходимая ей для работы.

На конференции Data + AI Summit во вторник компания Databricks анонсировала два продукта, направленных на упразднение этой инфраструктуры. Lakehouse//RT обеспечивает миллисекундную задержку запросов непосредственно на управляемых таблицах Delta и Iceberg, устраняя выделенный уровень обслуживания в реальном времени, который предприятия поддерживали вместе со своими озерными хранилищами (lakehouses). LTAP, что расшифровывается как Lake Transactional/Analytical Processing (озерная транзакционная/аналитическая обработка), сохраняет нативные транзакционные данные Postgres в формате Delta и Iceberg с момента записи, исключая ETL-конвейеры, которые на протяжении десятилетий связывали операционные и аналитические системы.

Рейнольд Син (Reynold Xin), соучредитель Databricks, в беседе с VentureBeat назвал более простой стек данных «святым Граалем для агентов», утверждая, что по мере того, как пользователи создают все больше приложений с помощью вайб-кодинга (vibe coding), агентам, проводящим аналитические рассуждения поверх этих приложений, требуется, чтобы подлежащая инфраструктура не путалась под ногами и позволяла действовать быстро.

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

LTAP делает ставку на унификацию на уровне хранилища там, где HTAP пытался добиться конвергенции движков

За последние десятилетия многие вендоры опробовали различные подходы к объединению аналитических и транзакционных данных.

Еще в 2014 году аналитическая компания Gartner ввела термин HTAP — аббревиатуру от Hybrid Transactional/Analytical Processing (гибридная транзакционная/аналитическая обработка) — для описания вендоров, пытавшихся объединить эти два типа баз данных. Среди множества вендоров HTAP на рынке оказались такие компании, как MemSQL (ныне известная как SingleStore), SAP HANA и MySQL Heatwave от Oracle.

LTAP — это ответ Databricks на HTAP, использующий архитектуру Lakebase для унификации данных на уровне хранилища, а не на уровне движка. Lakebase — это бессерверный облачный сервис баз данных PostgreSQL от Databricks, который стал общедоступным в феврале.

«HTAP для нас — это скорее провал индустрии, чем успех», — заявил Син.

Подход LTAP затрагивает уровень хранилища, а не уровень запросов. Ранее Lakebase хранила данные Postgres в формате Postgres на объектном хранилище, что требовало конвертации перед тем, как аналитические движки Lakehouse могли эффективно их использовать. С LTAP транзакционные данные попадают непосредственно в формат Delta или Iceberg, разделяя ту же копию, которую читают аналитические рабочие нагрузки. Postgres остается транзакционным движком. Spark и Lakehouse остаются аналитическим движком.

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

Главная инженерная проблема заключается в задержках (латентности). Объектное хранилище обеспечивает время отклика в диапазоне секунд, что слишком медленно для рабочих нагрузок OLTP, требующих субмиллисекундной производительности. Lakebase справляется с этим за счет уровня кэширования между вычислительными инстансами Postgres и объектным хранилищем. Ключевое архитектурное решение заключается в том, где происходит конвертация из строк в столбцы: простаивающая вычислительная мощность процессоров (CPU) на этом уровне кэширования выполняет преобразование до того, как данные попадают в объектное хранилище.

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

Lakehouse//RT обеспечивает миллисекундную задержку запросов к «живым» данным озерного хранилища без отдельного уровня обслуживания

Lakehouse//RT — это ответ Databricks на появление выделенного уровня обслуживания в реальном времени (отдельной системы, которую предприятия поддерживали наряду со своими озерными хранилищами для обработки низколатентных запросов ценой дублирования данных, разделения систем управления и сложности конвейеров, с которыми агенты не могут справиться). Ключевые возможности Lakehouse//RT включают в себя:

Вычислительный движок Reyden: Создан специально для обслуживания с высокой степенью параллелизма и низкими задержками, Reyden запрашивает таблицы Delta и Iceberg напрямую без выгрузки данных из озерного хранилища.

Задержка и пропускная способность: Lakehouse//RT обеспечивает задержку менее 100 мс при 12 000 запросах в секунду, со временем отклика до 10 мс на небольших наборах данных и производительностью до 16 раз выше, чем у существующих выделенных стеков обслуживания.

Управление и доступ к данным: Каждый запрос выполняется в рамках системы управления Unity Catalog без отдельного слоя разрешений, дублирования данных и конвейеров ингестии.

Аналитики видят в агентской концепции и подходе с открытыми форматами главные дифференциаторы

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

«У предприятий годами были HTAP, стриминг, облачные хранилища и операционные базы данных, — рассказала VentureBeat Стефани Вальтер (Stephanie Walter), руководитель практики по стеку ИИ в HyperFRAME Research. — Что изменилось, так это появление концепции агентского ИИ».

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

«Это сильный архитектурный аргумент, однако Lakebase еще предстоит доказать, что она способна обеспечить задержки, надежность и операционную зрелость, ожидаемые директорами по информационной безопасности (CIO)», — добавила она.

Майк Леоне (Mike Leone), аналитик из Moor Insights and Strategy, считает, что путь к подлинной дифференциации более конкретен, чем сама концепция унификации. Он также отметил, что открытая аналитика на базе озера данных в настоящее время является базовым требованием, поскольку многие вендоры предоставляют те или иные подобные сервисы.

«Менее распространенный шаг — позволить транзакционным записям также попадать в открытые форматы, чтобы операционная база данных не находилась в проприетарной «черной коробке», в то время как открытой остается только аналитическая часть», — сказал Леоне в интервью VentureBeat.

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

Техническое утверждение, которое столкнется с наибольшей критикой, является в то же время и самым главным. «Момент, в котором я бы все же хотел, чтобы их инженеры разобрались подробно — это то, как оба движка действительно разделяют одну копию данных без фонового этапа конвертации, выполняющего синхронизацию посередине», — отметил Леоне.

Что это означает для предприятий

Для инженеров по работе с данными, оценивающих свой стек для агентских рабочих нагрузок, вопрос больше не в том, какой лучший в своем классе (best-of-breed) инструмент выбрать для каждой задачи, а в том, оправдан ли вообще запуск раздельных инструментов.

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

Рынок отходит от специализированных слоев обслуживания быстрее, чем предполагало большинство дорожных карт вендоров. Согласно VB Pulse Q1 2026, трехэтапаному продольному опросу организаций с численностью сотрудников более 100 человек, интерес к гибридному поиску вырос за квартал втрое — с 10,3% до 33,3%, в то время как внедрение автономных векторных баз данных снизилось среди всех отслеживаемых вендоров. Та же логика консолидации теперь затрагивает уровень обслуживания в реальном времени.

Традиционный подход — лучшие в своем классе инструменты для каждого типа рабочих нагрузок и конвейеры между ними — был создан для потребления аналитики со скоростью человека. Рабочие нагрузки агентов не терпят такой архитектуры.

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