Агрегирование Power BI, шаг 3. Настройка функций агрегации и тестирование агрегаций в действии
Агрегация может значительно повысить производительность таблиц, полученных из DirectQuery. Чтобы использовать его, во-первых, вам нужно создать таблицу агрегации, во-вторых, вам нужно настроить надлежащие режимы хранения для таблиц в модели. Наконец, вы должны настроить функции агрегирования, что мы и собираемся объяснить в этом посте. Вы можете узнать об агрегации в других статьях этой серии и продолжить этот пример.
Что такое агрегация в Power BI?
Шаг 1: Создать агрегированную таблицу
Образец модели
У нас есть образец модели данных, который включает в себя таблицу агрегирования (Sales Agg) и таблицу фактов из DirectQuery (FactInternetSales), а также связь с некоторыми другими таблицами с режимами хранения Dual или DirectQuery, как показано ниже:
Управление агрегациями
Агрегированная таблица создана и имеет правильные связи и режим хранения. Однако Power BI все еще не знает о такой агрегации (помните об этом, потому что вы можете даже создать агрегацию вне Power BI с помощью оператора group by в T-SQL). Вы должны сообщить Power BI о такой агрегации. Вот почему мы должны установить и настроить его.
Щелкните правой кнопкой мыши таблицу Agg Sales и выберите Manage Aggregations.
В окне Manage Aggregations у вас будет возможность выбрать функции агрегирования и поля, к которым эта функция применяется.
В этом посте мы не будем рассказывать о конфигурации Precedence. Это для сценариев, когда у вас есть несколько уровней агрегации и приоритет использования агрегации. В этом примере сценария у нас есть только одна агрегированная таблица.
Конфигурация агрегации здесь должна точно соответствовать конфигурации агрегации в агрегированной таблице. Что это значит? На шаге создания агрегированной таблицы мы создали сгруппированный результат со следующей настройкой:
Как видите, у нас есть три поля типа Group by: OrderDateKey, CustomerKey и ProductSubcategoryKey. Эти поля должны быть помечены как Group By в соответствующих полях в таблице FactInternetSales (исходная таблица фактов);
Затем вы должны настроить функции агрегирования в соответствии с исходной конфигурацией группировки. Для SalesAmount_Sum и UnitPrice_Sum агрегация должна быть установлена как Sum для их соответствующих полей в таблице FactInternetSales.
Правило № 1: Подробный столбец должен иметь одинаковый тип данных сгруппированного столбца, чтобы использовать функцию Sum
Если вы читали предыдущие статьи на тему агрегации, во время создания агрегированной таблицы мы упоминали, что если вы используете SUM в качестве агрегации, то тип данных столбца после агрегации (SalesAmount_Sum) должен быть точно таким же типом данных в качестве исходного столбца (SalesAmount).
Если вы не будете следовать этому правилу, то в списке столбцов столбец будет выделен серым цветом, и вы не сможете его выбрать. Сначала измените тип данных, а затем вернитесь, чтобы установить его снова.
Для двух других столбцов UnitPrice_Count и FactInternetSales_Count агрегирование равно Count, а таблица - FactInternetSales.
Правило № 2: Тип данных столбца должен быть целым числом (Integer), если используется функция Count
Снова вернемся к более раннему сообщению. Если вы создали какой-либо агрегированный результат, который использует Count, тип данных этого столбца должен быть целым числом. В противном случае функция Count в управляющих агрегатах будет недоступна.
После настройки всего, окно управления агрегациями должно выглядеть как на этом скриншоте:
Скройте агрегированную таблицу
Последний шаг - скрыть агрегированную таблицу! Вы можете подумать, зачем?! Итак, мы создали агрегированную таблицу только для Power BI, чтобы автоматически переключаться с большой таблицы фактов DirectQuery на небольшую агрегированную таблицу импорта данных. Однако это только за кулисами. Пользователь не должен ничего знать об этом. Чтобы сделать этот процесс понятным с точки зрения пользователя, просто скройте таблицу Sales Agg.
Пользователь ничего не увидит в этой таблице. Список таблиц в разделе полей содержит только одну таблицу фактов; FactInternetSales.
Тестирование результата
После всей тяжелой работы, описанной ранее, сейчас самое время проверить, как работает агрегация в действии. В приведенном ниже отчете представлены все виды визуализаций: FactInternetSales, SalesAmount, со срезами по Education, и Occupation (из DimCustomer), CalendarYear (из DimDate), ProductSubcategory и ProductCategory:
У нас все время работает SQL Profiler, и вот результат;
Вот как агрегированная таблица работает за сценой. Поскольку все эти визуальные элементы нарезают данные по полям, которые мы имеем в агрегированной таблице (CustomerKey, OrderDateKey и ProductSubcategoryKey), результат всегда будет автоматически выбираться из агрегированной таблицы. Хотя таблица Sales Agg фактически не используется в этих визуализациях.
Если, однако, у нас есть визуализация, использующая другое поле, которого нет в агрегированной таблице, то пришло время сделать запрос из источника данных. Ниже приведен обзор каждой рекламной акции:
И SQL Profiler отслеживает запрос здесь:
Итак, поехали; у нас есть агрегация, которая ускоряет производительность таблицы DirectQuery. Ничто не мешает вам создать несколько уровней агрегации. На самом деле, это рекомендуется делать, особенно в тех случаях, когда разные пользователи или визуальные объекты будут использовать разные комбинации полей. Мы напишем еще один пост в блоге о добавлении большего количества слоев агрегации.
Вот наша диаграмма модели для справки:
Резюме
В серии статей «Агрегации» вы узнали, что такое агрегации и как она может сделать вашу составную модель быстрой, а затем вы узнали, как создать агрегированную таблицу в Power BI. Режим двойного хранения был следующей важной настройкой, которую вы узнали об агрегации, и, наконец, на этом шаге вы сконфигурировали функции агрегации и увидели агрегацию в действии. В реальных сценариях использования агрегирования у вас будет более одной агрегированной таблицы; называемой слоями скоплений. Следите за нашей следующей статьей о слоях агрегации.