Семантический слой BI: как объединить несколько наборов данных с Topics в Amazon QuickSight (Preview)

Знаете это чувство, когда бизнес-пользователь приходит с вопросом: "Сколько мы заработали на Premium-подписках в Европе в прошлом квартале?", а данные размазаны по трём разным таблицам: одна в Redshift, вторая в S3-паркете, третья — вообще live-соединение с RDS? И каждый раз приходится лепить денормализованные вьюхи, тащить ETL, чтобы связать всё в одну кучу. QuickSight Topics в preview умеет делать это без боли — прямо на уровне семантического слоя.

Почему денормализация — это костыль, а не решение

В классическом 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

Прежде чем лезть в консоль, давайте разберёмся, как это устроено под капотом. Semnatic Layer в QuickSight — это не просто набор полей с типами. Это граф знаний, в котором:

• Наборы данных (Datasets) — физические таблицы или представления (SPICE или direct query).
• Семантические поля (Semantic Fields) — поля с обогащёнными метаданными: синонимы, агрегации, форматы, иерархии.
• Отношения (Relationships) — связи между наборами данных: один-к-одному, один-ко-многим, многие-ко-многим.
• Topics — логическая группировка полей из разных датасетов, которая и является точкой входа для NLQ.

Когда пользователь задаёт вопрос, QuickSight анализирует его, находит подходящие поля в Topic, строит SQL-запрос с нужными JOIN'ами на основе заданных отношений и выполняет его. Всё это происходит в реальном времени, без предварительной денормализации.

Пошаговый план: создаём multi-dataset Topic

Допустим, у нас есть два датасета: orders (заказы с customer_id, total, date, region) и customers (id, name, tier, country). Хотим отвечать на вопросы вроде: "Показать выручку по клиентам из Premium-сегмента за июнь". Никаких ETL, только семантика.

1 Подготовьте наборы данных

Убедитесь, что у вас есть как минимум два датасета в QuickSight. Они могут быть из разных источников: один из Athena, другой из SPICE. Важно, чтобы между ними был общий ключ (например, customer_id).

2 Создайте Topic и добавьте датасеты

В консоли QuickSight перейдите в Topics → Create topic. Назовите его, например, Sales Analysis. На этапе Add datasets выберите оба датасета. Не бойтесь добавить три, четыре — главное, чтобы у них были корректные отношения.

# Пример CLI (если используете AWS CLI v2)
aws quicksight create-topic \
    --aws-account-id 123456789012 \
    --topic-id sales-analysis \
    --topic-name "Sales Analysis" \
    --datasets '[{"DatasetArn": "arn:aws:quicksight:...:dataset/orders", "DatasetName": "orders"},
                {"DatasetArn": "arn:aws:quicksight:...:dataset/customers", "DatasetName": "customers"}]'

3 Настройте отношения (Relationships)

Самый критический шаг. От того, как вы опишете связи, зависит корректность генерации SQL. В редакторе Topic перейдите на вкладку Relationships. Добавьте связь:

• Source dataset: orders
• Target dataset: customers
• Source field: customer_id
• Target field: id
• Type: Many-to-one (так как у каждого заказа один клиент, но у клиента много заказов)

QuickSight поддерживает только один тип JOIN — INNER JOIN на основе заданных полей. Если вам нужен LEFT JOIN — придётся создавать представление на стороне источника. Это ограничение preview, и, надеюсь, к GA добавят больше гибкости. Пока так.

4 Обогатите семантику полей

Теперь, когда датасеты связаны, нужно помочь Natural Language Query Engine понять, что есть что. Для каждого поля задайте:

• Синонимы — например, для поля total добавьте синонимы: ["выручка", "сумма", "revenue"].
• Тип поля — мера (measure) или измерение (dimension). total — мера с агрегацией SUM. region — измерение.
• Формат отображения — для денег: $#,##0.00, дат: YYYY-MM.
• Иерархии — например, для даты: год → квартал → месяц → день.

Чем больше семантики — тем точнее ответы. QuickSight использует эти метаданные для генерации корректного SQL и красивой визуализации.

5 Протестируйте запросы

Вернитесь на вкладку Question (или откройте Q-бар в любом дашборде) и задайте пару вопросов:

"Выручка по клиентам Premium-сегмента по месяцам"
"Топ-10 клиентов по сумме заказов в регионе APAC"
"Средний чек по типам клиентов"

Если QuickSight не может понять запрос — он покажет, какие поля он нашёл, и предложит уточнить. Это отличный способ проверить синонимы и отношения. Исправляйте, пока не заработает.

Нюансы и боли, о которых молчат доки

Я потратил несколько вечеров, чтобы разобраться с multi-dataset Topics, и вот грабли, на которые наступил:

• Ограничение на количество датасетов в одном Topic — в preview не больше 5. Если нужно больше — либо группируйте на уровне источника, либо ждите GA.
• Только INNER JOIN. Если у вас факты без соответствующих записей в измерении — они будут отброшены. Решение: создайте представление в БД с LEFT JOIN и используйте его как один датасет.
• Поля с одинаковыми именами в разных датасетах могут путать NLQ. Используйте разные имена или переименуйте в семантических полях.
• Производительность напрямую зависит от сложности отношений и объёма данных. Для миллионов записей лучше использовать SPICE (in-memory) для обоих датасетов, а не direct query.
• Не работает с расчетными полями в датасетах, если они ссылаются на поля из другого датасета. Все вычисления должны быть внутри одного датасета.

Когда multi-dataset Topics — это выстрел в ногу

Честно: не надо использовать эту фичу для сложных витрин с 10+ таблицами и звездообразной схемой. QuickSight Topics пока не умеет каскадные JOIN'ы через несколько таблиц (только прямые пары). Если у вас схема "факты → измерение1 → измерение2", то вам придётся создать промежуточный датасет-представление. Это всё ещё проще, чем полная денормализация, но не так прозрачно.

Также стоит помнить, что NLQ — это вероятностная штука. Даже с идеальной семантикой модель может интерпретировать вопрос не так, как вы ожидали. Всегда проверяйте сгенерированный SQL (QuickSight показывает его в логах Topic).

А если вы хотите понять, как Amazon использует нейросети для каталогов товаров — читайте статью Catalog AI от Amazon: как нейросети переписывают правила e-commerce изнутри. Там показано, как семантика выходит за рамки BI.

Часто задаваемые вопросы

Что ж, надеюсь, этот гайд сбережёт вам пару бессонных ночей. Multi-dataset Topics — штука сырая, но уже сейчас способна упростить жизнь аналитикам и архитекторам. Главное — не пытайтесь скрестить всё со всем, и помните: семантика — это не магия, а инженерия.

Подписаться на канал