Протягом десятиліть фахівці з даних стикаються з проблемою уніфікованого управління як операційними, так і аналітичними базами даних, що не призводить до затримок та зниження продуктивності.
Агенти (штучний інтелект) посилили цю проблему. Система, яка безперервно аналізує дані та діє на основі оперативної інформації, не може терпіти конвеєр затримок між собою та даними, які їй потрібні для роботи.
На конференції Data + AI Summit у вівторок компанія Databricks анонсувала два продукти, спрямовані на спрощення цієї інфраструктури. Lakehouse//RT забезпечує затримку запитів на рівні мілісекунд безпосередньо на керованих таблицях Delta та Iceberg, усуваючи виділений рівень обслуговування в реальному часі, який підприємства підтримували поряд зі своїми Lakehouse. LTAP, що розшифровується як Lake Transactional/Analytical Processing, зберігає транзакційні дані у форматі, сумісному з PostgreSQL, у форматі Delta та Iceberg з моменту запису, усуваючи ETL-конвеєри, які протягом десятиліть з’єднували операційні та аналітичні системи.
Рейнольд Сінь, співзасновник Databricks, описав простіший стек даних як “святий Грааль для агентів” у брифінгу для VentureBeat, стверджуючи, що оскільки користувачі все частіше використовують кодові додатки, агентам, які аналітично обробляють ці додатки, потрібна спрощена інфраструктура, щоб рухатися швидко.
“Агенти дійсно віддають перевагу набагато простішому стеку, тому що вони можуть рухатися набагато швидше”, – сказав він.
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 зберігав дані PostgreSQL у форматі PostgreSQL у сховищі об’єктів, що вимагало конвертації перед тим, як аналітичні двигуни Lakehouse могли б ефективно його використовувати. З LTAP транзакційні дані надходять безпосередньо у форматі Delta або Iceberg, використовуючи ту саму копію даних, яку читають аналітичні навантаження. PostgreSQL залишається транзакційним двигуном. Spark та Lakehouse залишаються аналітичним двигуном.
“Головна мета полягає в тому, щоб використовувати найкращий інструмент для роботи на рівні обробки запитів, а ми просто гарантуємо, що базове сховище містить єдину копію даних”, – сказав Сінь.
Основна інженерна проблема — це затримка. Сховища об’єктів мають час відгуку в кілька секунд, що занадто повільно для OLTP-навантажень, які вимагають продуктивності менше мілісекунди. Lakebase вирішує цю проблему за допомогою рівня кешування між екземплярами обробки PostgreSQL та сховищем об’єктів. Ключовим дизайнерським рішенням є те, де відбувається конвертація стовпців: вільні потужності ЦП на цьому рівні кешування виконують конвертацію рядків у стовпці перед тим, як дані потраплять у сховище об’єктів.
“Коли ви конвертуєте дані з рядкового формату в стовпцевий, вони стискаються більш ніж у 10 разів, зазвичай, тому ви суттєво зменшуєте мережеві витрати базового рівня кешування між цим рівнем кешування та сховищами об’єктів”, – сказав Сінь.
Lakehouse//RT забезпечує мілісекундну затримку запитів на живих даних Lakehouse без окремого рівня обслуговування
Lakehouse//RT — це відповідь Databricks на виділений рівень обслуговування в реальному часі — окрему систему, яку підприємства підтримували поряд зі своїми Lakehouse для обробки запитів з низькою затримкою, але ціною копіювання даних, розділеного управління та складності конвеєрів, які агенти не можуть обійти. Основні можливості Lakehouse//RT включають:
Обчислювальний двигун Reyden: Розроблений спеціально для висококонкурентного обслуговування з низькою затримкою, Reyden запитує таблиці Delta та Iceberg безпосередньо, не переміщуючи дані з Lakehouse.
Затримка та пропускна здатність: Lakehouse//RT забезпечує затримку менше 100 мс при 12 000 запитів на секунду, з часом відгуку до 10 мс на менших наборах даних та до 16 разів вищою продуктивністю порівняно з існуючими виділеними стеками обслуговування.
Управління та доступ до даних: Кожен запит виконується в рамках системи управління Unity Catalog без окремого рівня дозволів, без копіювання даних та без конвеєрів введення даних.
VB Transform · 14–15 липня · Менло-Парк · Агентні контекстні шари
Ваші агенти такі ж хороші, як і дані, до яких вони мають доступ.
Сесії на Transform охоплюють архітектури RAG, що забезпечують роботу агентних систем у масштабі — включно з тим, як підприємства підключають агентів до актуальних геномних, клінічних та корпоративних даних.
Переглянути повний порядок денний →
Аналітики вважають агентне позиціонування та підхід до відкритих форматів справжніми диференціаторами
Проблема, яку вирішують обидва продукти, добре задокументована серед команд даних підприємств, але аналітики проводять відмінність між проблемою та конкретним твердженням Databricks.
“Підприємства вже багато років мають HTAP, потокову передачу даних, хмарні сховища та операційні сховища”, – сказала VentureBeat Стефані Волтер, керівник практики AI Stack у HyperFRAME Research. “Що відрізняється, так це агентне AI-позиціонування”.
Волтер зазначила, що агентам потрібні актуальні операційні дані, історичний контекст, управління, пошук та зворотний запис в одному робочому процесі.
“Це сильний архітектурний аргумент, але Lakebase ще належить довести, що він може забезпечити затримку, надійність та операційну зрілість, яких очікують CIO”, – сказала вона.
Майк Леоне, аналітик Moor Insights and Strategy, вважає, що шлях до справжньої диференціації є більш конкретним, ніж сама концепція уніфікації. Він також зазначив, що відкрита аналітика на озері даних зараз є стандартом, і багато постачальників надають подібні послуги.
“Менш поширеним кроком є дозволити транзакційним записам надходити у відкриті формати, так що операційна база даних не знаходиться в пропрієтарному ящику, тоді як лише аналітична частина є відкритою”, – сказав Леоне VentureBeat.
Він додав, що підхід до відкритих форматів у поєднанні з Lakehouse//RT, що запитує живі дані безпосередньо з озера, надає цій архітектурі правдоподібну причину для виведення з експлуатації цілого ряду спеціалізованих систем.
Технічне твердження, яке зазнає найбільшої перевірки, також є центральним. “Частина, яку я б хотів, щоб їхні інженери детально пояснили, — це те, як обидва двигуни справді спільно використовують одну копію без прихованого кроку конвертації, що синхронізує дані посередині”, – сказав Леоне.
Що це означає для підприємств
Для інженерів даних, які оцінюють свій стек для агентних навантажень, питання полягає вже не в тому, який інструмент найкраще підходить для кожного завдання — а в тому, чи доцільно взагалі використовувати окремі інструменти.
Підприємства, які створили окремі операційні бази даних, рівні обслуговування в реальному часі та аналітичні Lakehouse, раніше могли розглядати прогалини між ними як тягар обслуговування. Агенти виявляють ці прогалини як операційний ризик: система, що працює на межі управління, знайде невідповідності швидше, ніж будь-яка людська команда.
Ринок рухається від спеціалізованих рівнів обслуговування швидше, ніж передбачали більшість дорожніх карт постачальників. Згідно з VB Pulse Q1 2026, трихвильовим поздовжнім опитуванням понад 100 компаній, намір гібридного пошуку (hybrid retrieval intent) потроївся з 10,3% до 33,3% протягом кварталу, тоді як використання окремих векторних баз даних знизилося у всіх відстежуваних постачальників. Та ж логіка консолідації зараз впливає на рівень обслуговування в реальному часі.Традиційний підхід — найкращі інструменти для кожного типу навантаження, конвеєри між ними — був створений для аналітичного споживання на швидкості людини. Агентні навантаження не терплять такої архітектури.
“Проблема, на яку вони вказують, — все копіювання та синхронізація між операційними та аналітичними системами — є реальною та дорогою, і кожен, хто використовує це у великих масштабах, відчуває це”, – сказав Леоне.
Як захиститися (Порада CryptoDom): Ретельно перевіряйте всі запити на доступ до даних, особливо ті, що надходять від автоматизованих систем чи агентів. Упроваджуйте принцип найменших привілеїв, щоб обмежити доступ до конфіденційної інформації лише тими, хто її дійсно потребує.
За даними порталу: venturebeat.com