Live Data in Apps - новая функция Amazon Quick: приложение, собранное ИИ-агентом по текстовому описанию, читает управляемые датасеты Quick Sight в реальном времени при каждом открытии. Каждый запрос уходит от имени того, кто смотрит приложение, поэтому row-level и column-level security применяются к нему лично, а не к служебной учётке сервиса. В официальном анонсе это сформулировано коротко: опубликованное приложение запрашивает датасеты живьём, каждый раз, когда его открывают.
До этого запуска любое число, которое показывало приложение Quick Apps, «запекалось» в момент сборки агентом: снимок, замороженный при публикации. Для статичного отчёта подход работал, но ломался, как только требовались метрики, отражающие сегодняшнее состояние данных, и при этом учитывающие, кому какие строки разрешено видеть.
Что такое Live Data in Apps и какую проблему она решает
Amazon Quick - AI-сервис унифицированной аналитики: он связывает корпоративные данные и корпоративный контент под управлением политик, чтобы команды могли искать, анализировать и действовать из одного места. Quick Apps отвечает в этой связке за приложения: вы описываете нужное приложение обычным языком, ИИ-агент пишет и разворачивает рабочее веб-приложение, ручной код и шаги DevOps не нужны.
Живые данные в Quick Apps уже были, но из других источников: action connectors вроде Jira, Slack и Google Drive, документы Spaces, веб-поиск и AI-инференс выполняются в момент просмотра, а не сборки. Управляемых структурированных датасетов это не касалось: числа из них попадали в приложение снимком. Live Data in Apps закрывает этот разрыв и приносит в приложения структурированные датасеты из Quick.
Чем это отличается от статичных снимков
| Аспект | Снимок на момент сборки (раньше) | Live Data in Apps |
|---|---|---|
| Что видит зритель | Числа из датасета, зафиксированные агентом при сборке | Результат запроса к управляемому датасету Quick Sight при каждом открытии |
| Актуальность | На момент публикации приложения | На момент открытия приложения |
| Учёт прав зрителя | Снимок не подстраивался под личность и права читателя, из-за чего подход ломался там, где нужно уважать доступ к строкам | Правила row-level и column-level security применяются к каждому читателю отдельно |
| Реакция на новые данные | Нужна пересборка или ручное обновление снимка | SQL выполняется заново, новые значения появляются сразу |
Дело в природе запроса. Приложение повторно выполняет тот же SQL, который агент написал при сборке, каждый раз, когда кто-то его открывает. Если данные в источнике изменились, приложение покажет новое значение без пересборки и без ручной выгрузки.
Почему это важно для безопасности
Запрос выполняется от имени человека, который смотрит приложение, а не от служебной учётки. Поэтому row-level и column-level security применяются к каждому читателю индивидуально: правила, настроенные в Quick Sight, продолжают работать и в приложении. Отдельную модель прав для приложения строить не нужно, и это главная экономия - вы не поддерживаете вторую схему доступа, которая со временем разъедется с первой.
На практике это выглядит так: если в датасете настроено, что менеджер видит только свой регион, он увидит свой регион и в приложении, а руководитель с более широкими правами - все регионы. Интерфейс один, строки на выходе разные.
Пример сценария: команда поддержки спрашивает «Сколько тикетов мы закрыли на прошлой неделе в разрезе регионов?». Вместо ручного экспорта и вставки в Slack открывается приложение и отдаёт актуальный ответ без SQL.
Как устроены два сценария: сборка приложения и его просмотр
Функция делится на два этапа, и разница между ними снимает большую часть вопросов про актуальность и права.
Этап сборки: как ИИ-агент находит данные и пишет SQL
На этапе сборки агент сам находит подходящие курируемые датасеты и пишет SQL, который отвечает на ваш вопрос. Вы формулируете задачу словами, например «сделай приложение для отслеживания тикетов по регионам», агент ищет датасет с тикетами и строит запрос.
Качество результата зависит от того, насколько хорошо организованы и описаны датасеты. Агент выбирает из того, что лежит в каталоге, и работает с теми именами таблиц и колонок, которые там есть. Чем чище семантический слой, тем меньше шансов, что он возьмёт не ту таблицу или неправильно поймёт метрику. Как этот слой наследуют из AWS Glue Data Catalog и Databricks Unity Catalog, разобрано в материале про Agentic Catalog Experience.
Гарантий, что агент всегда выберет идеальный датасет, нет. Курирование, понятные имена и описания метрик остаются задачей команды данных, а не самой функции.
Этап просмотра: выполнение запросов от имени пользователя
После публикации приложение выполняет тот же SQL каждый раз, когда его открывают, и запрос уходит в Quick Sight от имени конкретного пользователя. Поддерживаются датасеты в режимах SPICE и Direct Query: SPICE хранит данные в памяти Quick, Direct Query обращается к источнику напрямую.
Зритель должен быть аутентифицирован в Quick и дать разовое согласие на доступ к каждому датасету. Публичный анонс не описывает форму и срок действия такого согласия, поэтому перед раскаткой на большую аудиторию стоит проверить текущее поведение в документации и на тестовом окружении.
Согласие выдаётся один раз на датасет, а не на каждый запрос. После этого приложение при каждом открытии обращается к данным живьём: анонс AWS подчёркивает именно повторное выполнение SQL, а не периодическое обновление кэша.
Настройка доступа: что нужно сделать администратору и зрителю
Требования к аутентификации и согласию
Минимальный набор условий: пользователь известен Quick и имеет доступ к нужному датасету, а при первом обращении подтверждает согласие на работу с ним. Если зритель не аутентифицирован, приложение не сможет выполнить запрос от его имени.
Администратору стоит заранее проверить, что датасеты, которые попадут в приложение, доступны нужным группам, а пользователи не потеряют доступ к аналитике после того, как переключатся с дашбордов на приложение.
Как работают RLS и column-level security в этом контексте
Правила row-level и column-level security, настроенные в Quick Sight, применяются к запросам из приложения автоматически, потому что запрос идёт от имени пользователя. Поведение совпадает с тем, как если бы человек сам открыл дашборд в Quick Sight: те же строки, те же доступные колонки.
Дублировать правила для приложения не нужно. Если в датасете настроено, что менеджер видит только свой регион, то и в приложении он увидит только свой регион. Как это выглядит в мультитенантной схеме с изоляцией по идентификатору клиента, подробно разобрано в кейсе Datacor и TrackAbout, где доступ к данным аренды разделён между клиентами через row-level security.
Ограничения и подводные камни Live Data in Apps
Анонс описывает механику функции и не приводит таблицу квот. Конкретные значения по лимитам нужно брать из документации Quick и Quick Sight на момент запуска, а не из новости. Ниже - три вопроса, которые стоит прояснить до того, как приложение уйдёт в прод.
Лимиты на объём запросов и строк
Живые запросы означают нагрузку на источник при каждом открытии приложения. Чем чаще люди открывают приложение и чем больше строк возвращает SQL, тем выше шанс упереться в квоты сервиса. В публичном анонсе конкретные значения не названы, поэтому перед запуском стоит уточнить лимиты по количеству запросов и строк в документации, прикинуть, сколько людей и как часто будет открывать приложение, и подумать о кэшировании или агрегатах на стороне датасета, если поток открытий большой.
Несовместимость Direct Query из разных источников
Отдельный риск связан с архитектурой источников. Датасеты в режиме Direct Query, живущие в разных базах, в одном приложении могут не сработать: анонс не описывает сценарий объединения таких источников, и детали стоит проверять отдельно. Практичный обходной путь - привести данные в SPICE или собрать их в одном источнике до того, как агент начнёт строить приложение. Заодно это снимет часть нагрузки с боевых баз.
Необходимость пересборки при изменении колонок
SQL, сгенерированный на этапе сборки, привязан к структуре датасета. Если колонку переименовали, удалили или поменяли её тип, запрос может перестать выполняться корректно, и приложение начнёт отдавать ошибку или пустые значения. В этом случае понадобится пересборка приложения или ручная правка запроса. Анонс этот момент не раскрывает, поэтому план на изменение схем стоит закладывать заранее.
Кому и когда стоит использовать Live Data in Apps
Администраторам данных: правила RLS и column-level security остаются в Quick Sight, вторую модель прав поддерживать не нужно. Бизнес-пользователям: интерфейс на естественном языке, ответы без SQL и без ожидания выгрузки от аналитика. Разработчикам: не нужно поднимать отдельный бэкенд под каждый внутренний дашборд, если задача закрывается приложением Quick.
Сценарии, где функция раскрывается: операционные приложения, метрики которых меняются в течение дня (закрытые тикеты, статусы заказов, остатки); интерфейсы для команд поддержки и продаж, которым нужен доступ к данным строго под их правами; внутренние инструменты, которые раньше жили в таблице со снимком недельной давности.
Обратная сторона: если данные обновляются раз в месяц и права у всех одинаковые, живые запросы дадут нагрузку без выигрыша. Статичного снимка там достаточно.
Как Live Data in Apps вписывается в экосистему Amazon Quick
Live Data in Apps дополняет картину, в которой Quick Apps собирает приложение из разных живых источников. В момент просмотра уже работают action connectors вроде Jira, Slack и Google Drive, документы Spaces, веб-поиск и AI-инференс. Новый запуск добавляет к этому управляемые структурированные датасеты из Quick Sight.
Практический вывод: одно приложение может одновременно показать актуальные метрики из датасета, подтянуть текст из документа Spaces и сходить во внешний сервис. Что Quick даёт за пределами аналитики - десктопные приложения, аудит и приватное развёртывание на AWS - разбирается в обзоре десктопной версии.
Практические шаги для старта
- Проверьте датасеты. Приложение работает только с курируемыми датасетами Quick Sight: понятные имена таблиц и колонок, описанные метрики, отсутствие дублей.
- Проверьте права. RLS и column-level security должны быть настроены в самих датасетах, а у будущих зрителей - доступ к ним в Quick.
- Опишите приложение словами в Quick Apps и дайте агенту собрать первую версию. Посмотрите, какой SQL он сгенерировал и на какие датасеты опирается.
- Опубликуйте и протестируйте от имени разных пользователей: менеджер региона, руководитель, человек без доступа к части строк. Каждый должен видеть ровно свои данные.
- Заложите план на изменения: что делаете при переименовании колонок, при росте числа открытий, при появлении второго источника в Direct Query.
Если задача шире одного приложения - например, автоматизация обработки входящих документов с диалогом и валидацией, - в Quick есть похожий по подходу сценарий на Quick Automate, где логика тоже описывается промптом.
Отдельный практический момент для команд, работающих из России: подписки на зарубежные облачные сервисы требуют рабочего способа оплаты. Для этого используют виртуальные карты зарубежных банков, выпускаемые дистанционно и пополняемые рублями через СБП, - например, карта для оплаты иностранных сервисов с привязкой к Apple Pay, Google Pay, Alipay и WeChat и управлением через мессенджер.
Итог: стоит ли переходить на живые данные
Live Data in Apps закрывает два пробоя, из-за которых приложения Quick Apps плохо подходили для операционной аналитики: числа, замороженные на момент сборки, и отсутствие учёта прав зрителя на уровне строк. Теперь запрос идёт в Quick Sight в реальном времени от имени конкретного человека, а RLS и column-level security работают так же, как в дашбордах.
Переходить стоит, если вы уже используете Amazon Quick и Quick Sight, датасеты курированы, а правила доступа настроены. Перед продом проверьте три вещи: квоты на количество запросов и строк, совместимость источников для Direct Query и порядок действий при изменении колонок. Если данных мало и права у всех одинаковые, выигрыш от живых запросов будет близок к нулю.