Amazon Web Services представила в Amazon Quick Sight новую возможность моделирования данных, которая меняет то, как аналитические команды объединяют данные для дашбордов, ad hoc-анализа и запросов на естественном языке. По словам AWS, новая функция Multi-Dataset Relationships позволяет пользователям хранить таблицы как отдельные наборы данных Quick Sight, определять логические связи между ними внутри Topic и позволять Quick Sight собирать соединения во время выполнения вместо того, чтобы заставлять команды заранее создавать широкие денормализованные наборы данных.

Это важно, потому что значительная часть работ по бизнес-аналитике по-прежнему начинается с преобразования данных о продажах, клиентах, продуктах, возвратах, прогнозах и операциях в сценарные выгрузки. AWS позиционирует обновление как способ снизить начальную нагрузку на моделирование, сохранить исходный grain каждого набора данных и повторно использовать семантическую модель в нескольких сценариях использования в Amazon Quick Sight. Для BI-инженеров и корпоративных аналитических команд, уже управляющих громоздкими дашбордами, это изменение — не столько про эффектный ИИ, сколько про сокращение дублирующейся логики данных.

Что именно AWS запустила в Amazon Quick Sight

В основном анонсе AWS заявила, что Multi-Dataset Relationships вводит логический слой моделирования между наборами данных в Topic Quick Sight. Компания чётко разделяет два слоя в Amazon Quick Sight: физический слой внутри набора данных, где пользователи по-прежнему объединяют или трансформируют исходные таблицы, имеющие один и тот же grain, и логический слой между наборами данных, где отдельные наборы данных связаны, но не объединяются до тех пор, пока визуализация, фильтр, вычисляемое поле или вопрос не потребуют данных более чем из одного источника.

На практике AWS предлагает пользователям создавать отдельные наборы данных для таких сущностей, как таблица фактов продаж, измерение клиентов или измерение продуктов, а затем определять, как эти наборы данных связаны внутри Topic. После этого Quick Sight выполняет соединения во время выполнения, когда аналитики создают визуализацию или используют Quick Chat для Q&A. AWS утверждает, что этот подход может сократить разрастание наборов данных, поскольку командам больше не нужно создавать отдельный плоский набор данных для каждого сценария отчётности.

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

В текущем релизе есть важное ограничение. AWS говорит, что функция сейчас использует семантику inner join. В результатах будут отображаться только строки с совпадающими ключами между связанными наборами данных. Это делает запуск полезным для многих распространённых паттернов аналитики в стиле хранилища данных, но также означает, что командам, которые полагаются на left joins, unions или более сложную логику, по-прежнему нужны обходные пути или другой подход к моделированию.

Паттерны данных, которые, по словам AWS, поддерживаются

После запуска AWS опубликовала второй пост, посвящённый шаблонам проектирования для Multi-Dataset Relationships. Самый ясный вывод из этой рекомендации — AWS считает моделирование по схеме «звезда» стандартным вариантом для этой функции.

По словам AWS, наиболее распространённый и рекомендуемый паттерн — это центральный набор данных фактов, соединённый с несколькими измерениями. Это сохраняет соединения в один шаг и соответствует тому, как уже построены многие корпоративные модели отчётности в инструментах за пределами Amazon Quick Sight. Компания также говорит, что схемы «снежинка» возможны, но советует пользователям сворачивать цепочки измерений «снежинка», если только измерение не очень большое, ссылаясь на дополнительную сложность запросов из-за многошаговых соединений.

AWS также описывает поддержку нескольких таблиц фактов, использующих согласованные измерения, что может быть важно для команд, сравнивающих связанные процессы, такие как продажи и возвраты. В этом паттерне общие измерения выступают мостом между фактами. Компания предупреждает, что согласованные измерения должны иметь одинаковый grain и одинаковые ключи во всех таблицах фактов, чтобы результаты были надёжными.

Ещё один поддерживаемый паттерн — роль-игровое измерение, когда одна таблица измерения, например таблица дат, используется в нескольких аналитических ролях. AWS говорит, что правильная реализация в Amazon Quick Sight — не физически дублировать исходную таблицу, а создавать несколько наборов данных на основе одной и той же базовой таблицы дат. Это важно для таких анализов, как сравнение даты заказа и даты отгрузки.

AWS также утверждает, что система может работать с фактами разного grain, автоматически агрегируя более детализированный факт до более крупного уровня перед соединением. Если это действительно будет стабильно работать на практике, это может убрать часть ручной предварительной агрегации, которую BI-команды сейчас выносят в ETL-пайплайны.

Где здесь Quick Chat и чем он отличается

Третий пост AWS в этой серии расширяет историю за пределы фиксированных связей в сторону генеративной BI. В руководстве по Quick Chat AWS говорит, что теперь у команд есть два способа поддерживать анализ по нескольким наборам данных в Amazon Quick Sight: заранее определить явные связи или предоставить достаточно семантических метаданных, чтобы система ИИ могла генерировать SQL во время запроса.

Это различие важно. AWS говорит, что Topics на основе связей создают ориентированный ациклический граф, поддерживают до 12 наборов данных и обеспечивают детерминированное поведение, поскольку пути соединений заранее определены. Это подходит для управляемой отчётности, где аналитические команды хотят строгого контроля над тем, как объединяются таблицы.

В отличие от этого, AWS говорит, что Quick Chat может работать на основе семантических подсказок, а не заранее прошитого графа связей. В этом режиме генеративная система использует инструкции Topic, инструкции набора данных, описания и синонимы, чтобы определить, какие наборы данных запрашивать, какие типы соединений использовать и как агрегировать результат. AWS прямо позиционирует этот путь как более гибкий для случаев, связанных с outer joins, union, подзапросами, self joins, рекурсивными иерархиями и сравнениями между разными grain.

Из этого следует, что AWS строит внутри Amazon Quick Sight два перекрывающихся, но разных семантических слоя. Один — это управляемый граф связей для предсказуемой BI. Другой — это семантическая система под управлением ИИ для исследовательских вопросов в Quick Chat. AWS также говорит, что оба варианта можно объединить в гибридный Topic, с фиксированными соединениями для базовых паттернов отчётности и семантическими подсказками для крайних случаев.

Для продуктовых команд, оценивающих корпоративный ИИ, эта гибридная история может быть более важным стратегическим сигналом, чем само обновление BI-модели. Она показывает, что AWS пытается сделать Amazon Quick Sight одновременно и традиционной аналитической платформой, и интерфейсом на естественном языке поверх корпоративных данных, не требуя, чтобы каждый процесс проходил через одну жёсткую систему моделирования.

Доказательства, заявления и текущие ограничения

Доказательства в этой истории полностью взяты из публикаций AWS Machine Learning Blog, поэтому самые сильные утверждения — это заявления самого вендора. AWS предоставляет подробные концептуальные рекомендации и примеры реализации, но в наборе источников нет независимых бенчмарков, данных о внедрениях у клиентов или внешней валидации.

Несколько ограничений прямо указаны в материалах AWS. Во-первых, Multi-Dataset Relationships в текущем релизе использует только inner joins. Во-вторых, граф связей, определённый в Quick Chat, по словам AWS, поддерживает до 12 наборов данных. В-третьих, AWS неоднократно описывает некоторые сценарии как рекомендуемые, а другие — как требующие обходных путей, особенно для более сложных схем.

AWS даёт и конкретные рекомендации по дизайну, которые помогают отделить документацию продукта от маркетинговых формулировок. Совет предварительно соединять цепочки snowflake, если только экономия хранилища явно не оправдывает дополнительную сложность соединений, — это практический компромисс, а не общее обещание производительности. Аналогично, рекомендации по согласованным измерениям и выравниванию grain отражают хорошо известные риски моделирования, которые могут сломать результаты BI, если их игнорировать.

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

В части ИИ AWS говорит, что Quick Chat может использовать семантический контекст для генерации SQL без заранее определённых связей. Это может расширить гибкость, но AWS также прямо признаёт компромисс: скудные метаданные приводят к ненадёжным результатам, потому что у ИИ недостаточно контекста, чтобы выбрать правильные таблицы, ключи и формулы. Иными словами, нагрузка смещается от предварительного соединения данных к созданию сильного семантического слоя.

Что это значит для разработчиков и корпоративных команд

Для BI-разработчиков релиз меняет то, где происходит моделирование. Вместо того чтобы снова и снова создавать плоские наборы данных в ETL или представлениях базы данных, команды могут хранить больше исходно-ориентированных наборов данных в Amazon Quick Sight и централизовать часть логики в Topic. Это должно быть привлекательно для организаций с несколькими дашбордами по одним и тем же доменам продаж, возвратов, клиентов и продуктов.

Для корпоративных команд ИИ более привлекательной может быть повторная используемость. Если один Topic может обслуживать дашборды, вычисляемые поля и вопросы Quick Chat, то работа по семантическому моделированию потенциально поддерживает и управляемую отчётность, и разговорную аналитику. Это ценно, если организация хочет предоставлять доверенные данные через интерфейсы на естественном языке, не создавая отдельный семантический стек с нуля.

Тем не менее остаются причины, почему некоторые команды будут придерживаться предварительно соединённых моделей. Поддержка только inner joins ограничивает полноту для наборов данных с отсутствующими ключами или необязательными связями. Соединения во время выполнения также могут создавать вопросы отладки и производительности, которых избегают предварительно вычисленные таблицы. А организации со строгими требованиями к финансовой или регуляторной отчётности могут предпочесть полностью материализованную модель, которую проще проверять и версионировать.

Запуск также чётче обозначает позицию AWS в корпоративном ИИ и аналитике. Amazon Quick Sight больше не конкурирует только за дашборды с другими BI-инструментами; с Quick Chat он конкурирует и по тому, насколько хорошо могут сосуществовать управляемая семантическая модель и генеративный интерфейс. Это оказывает на AWS давление, требуя доказать не только широту функций, но и надёжность, когда пользователи смешивают традиционную BI и ИИ-управляемые запросы.

На что смотреть дальше

Следующие сигналы очевидны. Во-первых, AWS нужно расширить поддержку соединений за пределы inner joins, если она хочет, чтобы Multi-Dataset Relationships охватывали более широкую долю корпоративных аналитических нагрузок. Во-вторых, покупателям стоит искать более чёткие рекомендации или телеметрию по производительности во время выполнения, особенно для cross-fact и cross-grain запросов в Amazon Quick Sight.

В-третьих, будет важно, опубликует ли AWS примеры клиентов, показывающие, как команды используют Multi-Dataset Relationships и Quick Chat вместе в продакшене. Сейчас история сильна в архитектуре и паттернах моделирования, но слаба в части внешнего подтверждения.

Наконец, стоит следить за тем, как AWS будет развивать границу между определёнными связями и SQL, сгенерированным ИИ. Если Quick Chat сможет надёжно обрабатывать сложные паттерны, сохраняя управление, это сочетание может сделать Amazon Quick Sight более значимым для организаций, пытающихся внедрить корпоративный ИИ в существующие BI-процессы.

Мнение Creati.ai

Этот запуск AWS лучше всего понимать как инфраструктуру для аналитических команд, а не как эффектную функцию для конечного пользователя. Multi-Dataset Relationships в Amazon Quick Sight решает упрямую операционную проблему: слишком много BI-логики слишком рано застывает в предварительно соединённых выгрузках, что приводит к хрупким моделям, дублирующимся метрикам и постоянным перестройкам. AWS предлагает более модульную альтернативу, но она всё равно зависит от дисциплинированного измерительного моделирования.

Стратегический момент — в связке с Quick Chat. AWS фактически разделяет детерминированную семантическую структуру и генерацию запросов под управлением ИИ, а затем позволяет клиентам выбрать одно или оба решения. Для разработчиков и корпоративных команд это правильная рамка. Надёжный аналитический ИИ редко зависит только от модели; он зависит от качества семантического слоя под ней. Вместе Amazon Quick Sight, Quick Chat и Multi-Dataset Relationships показывают, что AWS пытается сделать этот слой более повторно используемым, более управляемым и более совместимым с доступом на естественном языке.