Amazon a présenté une architecture d’analytique agentique basée sur SageMaker, Athena et Quick

AWS показала архитектуру, в которой агентный помощник Amazon Quick превращает аналитику по lakehouse в self-service для бизнес-команд. Схема объединяет S3, SageMaker, AWS Glue и Athena, чтобы пользователь мог задавать вопросы к данным на естественном языке, а не через SQL.

Как устроена схема В демонстрации AWS использует набор TPC-H и строит

поверх него lakehouse из нескольких слоёв. Данные хранятся в Amazon S3, метаданные ведутся через AWS Glue, а Amazon Athena становится единым SQL-слоем для запросов к разным форматам хранения. В примере одновременно используются обычные внешние CSV-таблицы, Iceberg-таблицы в Parquet и управляемые S3 Tables.

Такой подход нужен не ради красоты архитектуры: компания показывает, что один и тот же бизнес-вопрос можно адресовать к разнородным источникам без ручной сборки витрин под каждый сценарий. Поверх этого в Amazon Quick собирается пользовательский слой: датасеты в SPICE для быстрых ответов и дашбордов Topic как семантический слой для бизнес-терминов дашборд с запросами на естественном языке Knowledge Base на основе документации и спецификаций * Quick Space и chat agent как единый интерфейс ## Что делает агент Ключевая часть — не просто чат над таблицами, а связка из Topic, Space и Knowledge Base. Topic выступает как семантический слой: он связывает привычные формулировки вроде выручки, клиентского сегмента или прошлого квартала с конкретными полями, датами и фильтрами в датасете.

Внутри Quick данные сначала загружаются в SPICE, поэтому дашборды и ответы на типовые вопросы должны работать быстро даже при росте исходного lakehouse. Для крупных наборов AWS советует предварительно объединять таблицы в Athena через Custom SQL, а уже затем передавать плоский результат в Quick. Чтобы агент отвечал не только по числам, AWS добавляет к структурированным таблицам неструктурированный контекст.

В Knowledge Base через веб-краулер загружается спецификация TPC-H в PDF, а в Quick Space складываются Topic, база знаний и готовый дашборд. После этого chat agent получает один управляемый контур знаний: он может отвечать на вопросы о выручке и статусах заказов, а заодно вытаскивать определения полей, бизнес-логику запросов и смысл benchmark-запросов из документации. Идея простая: один интерфейс вместо набора разрозненных BI-экранов и wiki-страниц.

Где тут эффект

Для бизнеса главный выигрыш в том, что аналитика перестаёт быть очередью к SQL-специалистам и BI-команде. Пользователь может спросить о выручке по сегментам, динамике заказов, скидках или товарных позициях обычным языком и получить ответ, привязанный к данным и визуализациям. AWS отдельно подчёркивает, что такая модель рассчитана не только на demo-режим: доступ ограничивается ролями, а границы видимости наследуются из IAM и Lake Formation.

То есть сотрудник видит только те таблицы, колонки и источники, к которым у него уже есть разрешения. Но пост одновременно показывает и цену такого удобства. Перед запуском нужно настроить каталог Glue, права в Lake Formation, соединение с Athena, загрузку в SPICE, Topic, Space, дашборд и отдельного агента.

То есть AWS не обещает магию из коробки: агентная аналитика появляется там, где уже выстроены lakehouse, модели доступа и аккуратная семантика данных. Зато в обмен компания получает более короткий путь от вопроса к ответу и меньше ручной работы на стороне аналитиков.

Что это значит AWS фактически продвигает следующую стадию BI: не новый

дашборд, а слой агентного интерфейса поверх существующего lakehouse. Если подход приживётся, бизнес-пользователи будут всё чаще обращаться к данным через диалог, а команды данных сосредоточатся не на разовых выгрузках, а на качестве моделей, прав и контекста.