Знаете это чувство, когда бизнес-пользователь приходит с вопросом: «Сколько мы заработали на Premium-подписках в Европе в прошлом квартале?», а данные размазаны по трём разным таблицам: одна в Redshift, вторая в S3-паркете, третья — вообще live-соединение с RDS? И каждый раз приходится лепить денормализованные вьюхи, тащить ETL, чтобы связать всё в одну кучу. QuickSight Topics в preview умеет делать это без боли — прямо на уровне семантического слоя.
Важно: Функция multi-dataset Topics находится в публичном предварительном обозрении (preview). Все описанные шаги актуальны на 12.07.2026. Возможны изменения в GA-релизе.
Почему денормализация — это костыль, а не решение?
В классическом BI-мире, если вы хотите, чтобы пользователь мог задать вопрос на естественном языке (NLQ) через Amazon QuickSight Topics, вам нужно было создать один плоский датасет, который содержит все поля из всех источников. Это значит — JOIN'ы, дедупликации, перекосы, дублирование данных. А если завтра добавится ещё один источник? Снова ETL, снова переписывать модель. К тому же такой подход убивает производительность: при каждом запросе QuickSight сканирует гигантскую таблицу.
Multi-dataset Topics решает эту проблему принципиально иначе. Вместо того чтобы склеивать данные физически, вы описываете отношения между наборами данных на уровне семантического слоя. QuickSight сам понимает, как соединить таблицы в момент выполнения запроса — оптимизатор NLQ (Natural Language Query) преобразует ваш вопрос в SQL с правильными JOIN'ами. И да, это работает не только с QuickSight SPICE, но и с прямыми запросами к Athena, Redshift или Aurora.
Анатомия семантического слоя в QuickSight Topics
Прежде чем лезть в консоль, давайте разберёмся, как это устроено под капотом. Semantic Layer в QuickSight — это не просто набор полей с типами. Это граф знаний, который включает:
- Датасеты — фактические данные (SPICE или прямой запрос).
- Топики (Topics) — логические группировки полей, которые пользователь видит в NLQ.
- Отношения (Relationships) — связи между датасетами, определённые на уровне семантики.
- Семантические поля — поля с бизнес-смыслом (например, «Выручка» = SUM(amount) WHERE status = 'paid').
Когда пользователь задаёт вопрос, NLQ-движок разбирает его, сопоставляет с семантическими полями из разных датасетов, и на основе заданных отношений строит SQL-запрос. Этот SQL выполняется на источнике данных или в SPICE, а результат отдаётся пользователю. Вся магия — в runtime joins, которые не требуют физического материализованного представления.
Более подробно о концепциях семантического слоя я уже писал в предыдущей статье. Там раскрыта архитектура построения графа знаний. Сейчас же сосредоточимся на практическом руководстве.
Пошаговый план: объединяем датасеты через Multi-Dataset Topics
Я буду использовать реальный пример: у нас есть датасет Sales (продажи) в Athena, датасет Customers (клиенты) в SPICE, и датасет Products (товары) как live-запрос к RDS PostgreSQL. Наша цель — создать единый Topic, который позволяет спрашивать: «Покажи топ-5 товаров по выручке в регионе EMEA».
1 Подготовка датасетов
Убедитесь, что каждый датасет уже опубликован в QuickSight. Важно: датасеты могут быть из разных источников (SPICE, Athena, Redshift, Aurora), но они должны быть доступны в одном аккаунте QuickSight. Если датасеты в разных аккаунтах — используйте кросс-аккаунтный доступ.
- Для датасета Sales: создайте поле
customer_idиproduct_id(ключи для связи). - Для датасета Customers: поле
idиregion. - Для датасета Products: поле
idиname.
Уже на этом этапе многие допускают ошибку: не синхронизируют типы данных. Если в одном датасете customer_id — строка, а в другом — число, QuickSight не сможет сделать JOIN. Приведите типы к одному формату.
2 Создание Topic с несколькими датасетами
В консоли QuickSight перейдите в Topics → Create Topic. На шаге выбора источников укажите все три датасета. QuickSight автоматически попытается определить возможные отношения, но лучше задать их вручную.
Важно: Не добавляйте все поля из каждого датасета. Выбирайте только те, которые нужны для бизнес-вопросов. Чем меньше полей, тем точнее работает NLQ.
3 Определение семантических отношений
В разделе Relationships укажите связи между датасетами:
-- Пример логики отношений:
Sales.customer_id → Customers.id (LEFT JOIN)
Sales.product_id → Products.id (LEFT JOIN)Выберите тип JOIN (INNER, LEFT, RIGHT, FULL). Для большинства случаев LEFT — оптимален. QuickSight также поддерживает сложные отношения — составные ключи, условия с AND/OR.
Типичная ошибка: пытаться объединить датасеты с разными гранулярностями без указания агрегации. Например, если Sales — на уровне строк заказа, а Customers — на уровне клиента, то при прямом JOIN вы получите дубли. QuickSight автоматически применяет агрегацию, если правильно настроить семантические поля. Но лучше заранее убедиться, что датасеты согласованы.
4 Создание семантических полей
Теперь самое интересное. Вместо того чтобы пользователь разбирался с сырыми полями, вы создаёте бизнес-поля с формулами. Например:
- Выручка = SUM(Sales.amount) WHERE Sales.status = 'paid'.
- Регион = Customers.region.
- Товар = Products.name.
Эти поля будут видны пользователю в NLQ. QuickSight сам поймёт, что для расчёта выручки нужно соединить три датасета.
5 Тестирование и публикация
Используйте встроенную консоль NLQ-тестирования в QuickSight. Попробуйте вопросы:
- «Покажи выручку по регионам за последний квартал»
- «Топ-3 товара по количеству продаж в EMEA»
QuickSight сгенерирует SQL-запрос, объединяющий все три датасета через LEFT JOIN. Вы можете увидеть его в логах. Если запрос кажется неоптимальным (например, полный скан таблицы), проверьте, все ли отношения заданы корректно, и не слишком ли широкая селекция полей.
После успешного тестирования опубликуйте Topic для пользователей.
Нюансы и частые ошибки
| Проблема | Причина | Решение |
|---|---|---|
| Дублирование строк в результатах | Неправильный тип JOIN или отсутствие агрегации | Используйте семантические поля с SUM/COUNT; проверьте гранулярность |
| NLQ не понимает вопрос с полями из разных датасетов | Не заданы отношения между датасетами | Проверьте Relationships в Topic |
| Медленные запросы (особенно на live-источниках) | Runtime join на больших таблицах | Рассмотрите перемещение данных в SPICE; используйте ограничение по времени (например, только последний год) |
| Ошибка «Data source not supported for multi-dataset Topics» | Один из источников не поддерживает runtime joins (например, Excel-файл) | Перенесите данные в SPICE или используйте только поддерживаемые источники (Athena, Redshift, Aurora, S3, SPICE) |
FAQ: Коротко о главном
Поддерживает ли QuickSight Multi-Dataset Topics для live-запросов к RDS?
Да, поддерживает Aurora и RDS MySQL/PostgreSQL через прямой запрос. Однако учтите, что runtime join может создать дополнительную нагрузку на базу. Рекомендуется предварительно протестировать.
Могу ли я использовать семантические поля из разных датасетов в одной формуле?
Да, например, создать поле «Маржа» = (Sales.revenue - Products.cost) / Sales.revenue. QuickSight автоматически подставит правильные JOIN'ы.
Как долго сохраняются runtime-отношения?
Отношения хранятся в метаданных Topic. При каждом NLQ-запросе они пересчитываются заново — никакого кэширования SQL-генерации не происходит.
Работает ли это с кросс-региональными датасетами?
Да, QuickSight поддерживает датасеты из разных регионов, но учтите задержки при прямых запросах. Лучше переместить данные в SPICE, который находится в том же регионе, что и QuickSight.
Что дальше: от Preview к Production
Multi-Dataset Topics — мощный инструмент, но не панацея. Если в вашей организации десятки датасетов и сложные трансформации, возможно, стоит посмотреть в сторону полноценного semantic layer типа AWS Lake Formation или сторонних решений (например, QuickSight с Q — ещё один шаг к самообслуживанию).
Мой неочевидный совет: не старайтесь объединить всё в один Topic. Создайте несколько тематических Topics (например, «Продажи», «Маркетинг», «Финансы»). Так NLQ будет точнее, а пользователи не утонут в сотне полей. И помните: семантический слой живёт, пока вы его поддерживаете. Добавили новый источник данных — обновили отношения. Забыли — получили жалобы на «битые» отчёты.
