Мерчант - Power BI. Передовые Методы Оптимизации - 2023

Бхавик Мерчант
Power BI:
передовые методы оптимизации
Bhavik Merchant
Microsoft Power BI
Performance
Best Practices
A comprehensive guide
to building consistently fast
Power BI solutions
BIRMINGHAM—MUMBAI
Power BI:
передовые
методы оптимизации
Полное руководство
по построению стабильно
быстрых решений
в Microsoft Power BI
Москва, 2023
УДК 004.424
ББК 32.372
М52
Мерчант Б.
М52 Power BI: передовые методы оптимизации / пер. с англ. А. Ю. Гинько. – М.:
ДМК Пресс, 2023. – 282 с.: ил.
ISBN 978-5-93700-168-9
Эта книга научит вас поддерживать решения Power BI любой степени слож-
ности с минимальными усилиями. Вы узнаете, как проводить оптимизацию на
всех слоях Power BI – начиная с рабочей области отчета и заканчивая модели-
рованием данных, их преобразованием, хранением и архитектурой. Выясните,
что необходимо сделать, чтобы при масштабировании проекта не страдало его
быстродействие. Научитесь определять распространенные ошибки на этапе про-
ектирования данных, приводящие к снижению эффективности решения и рас-
ходованию лишней памяти.
Издание предназначено для аналитиков данных, разработчиков в области биз-
нес-аналитики и специалистов по работе с Power BI. Оно пригодится тем, кто хочет
создавать решения на базе Power BI, способные масштабироваться в отношении
объема данных и количества пользователей без потери эффективности. Для из-
учения материала потребуется базовое знание Power BI и всех его компонентов.
УДК 004.424
ББК 32.372
First published in the English language under the title ‘Microsoft Power BI Performance Best
Practices – (9781801076449).
Все права защищены. Любая часть этой книги не может быть воспроизведена в ка-
кой бы то ни было форме и какими бы то ни было средствами без письменного разрешения
владельцев авторских прав.
ISBN 978-1-80107-644-9 (англ.) © 2022 Packt Publishing

ISBN 978-5-93700-168-9 (рус.) © Перевод, оформление, издание,
ДМК Пресс, 2023
Как и многие другие авторы, я посвящаю эту книгу первым делом
моей жене и пятилетнему сыну. Особенно сыну, который оказался
большим молодцом, позволив мне сосредоточиться на сверхурочной
работе по выходным вместо совместного отдыха и игр. До за-
ключительных глав книги я не осознавал в полной мере, насколько
важной будет для меня поддержка семьи, а долгие месяцы с COVID
заставили нас преодолевать новые личные и профессиональные
преграды. Несмотря на изоляцию и привыкание к новой стране,
они продолжали поддерживать меня и отмечать окончание каждой
главы как маленький праздник. И за это я выражаю им свою самую
глубокую благодарность.
Также я хотел бы сказать спасибо всем коллегам во времена рабо-

ты в Microsoft в отделе Power BI. Я многому научился у парней из ко-
манды Power BI CAT, архитектурных проектировщиков, менедже-
ров по разработке ПО и экспертов в области отчетности. Список
тех, кому я благодарен, слишком велик, чтобы его здесь приводить.
К тому же есть риск кого-то забыть, чего мне не хотелось бы. На-
деюсь, их глубокие знания в совокупности с моим богатым опытом
помогут вам вывести свои решения Power BI на новый уровень.
Содержание
От издательства. ...................................................................................................12
Предисловие...........................................................................................................13
Об авторе. ................................................................................................................14
О редакторах..........................................................................................................15
Введение. .................................................................................................................16
Часть I. АРХИТЕКТ УРА, УЗКИЕ МЕСТА И ЦЕЛЕВЫЕ

ПОКАЗАТЕЛИ ПРОИЗВОДИТЕЛЬНОСТИ ........................................21
Глава 1. Постановка целей и определение проблемных
областей....................................................................................................................22
Определение уровня производительности. ...........................................................23
Показатели производительности отчетов..........................................................23
Установка реалистичных целевых показателей производительности..........24
Области с возможными замедлениями. .................................................................25
Подключение к источникам данных...................................................................26
Режим Import. .....................................................................................................26
Режим DirectQuery. ............................................................................................27
Режим Live connection. ......................................................................................27
Шлюз Power BI.........................................................................................................27
Сетевая задержка....................................................................................................28
Служба Power BI. .....................................................................................................29
Решения, влияющие на производительность. .......................................................30
Заключение..................................................................................................................30
Глава 2. Обзор архитектуры и конфигурации Power BI....................32

Средства подключения к источникам и режимы хранения данных. .................32
Выбор между режимами Import и DirectQuery. .................................................33
Содержание  7
Когда лучше подойдет режим DirectQuery?........................................................36

Составные модели..............................................................................................37
Режим LiveConnect. ................................................................................................38
Извлечение локальных данных с помощью шлюза. .............................................39
Как работает шлюз.................................................................................................40
Предпосылки для оптимальной работы шлюза. ...............................................40
Технические характеристики шлюза..............................................................42
Настройка ведения логов в шлюзе..................................................................43
Анализ и моделирование логов шлюза. .........................................................45
Анализ логов шлюза. .........................................................................................47
Масштабирование шлюза.................................................................................48
Горизонтальное масштабирование с увеличением количества шлюзов.....48
Общая инструкция по архитектуре..........................................................................50
Планирование расписания обновлений.............................................................50
Снижение сетевой задержки............................................................................50
Заключение..................................................................................................................51
Глава 3. Оптимизация DirectQuery. .............................................................53

Моделирование данных для режима DirectQuery..................................................54
Оптимизация связей для DirectQuery.................................................................57
Настройки быстродействия режима DirectQuery. .................................................60
Настройки Power BI Desktop. ................................................................................60
Оптимизация внешних источников данных......................................................62
Заключение..................................................................................................................64
Часть II. АНАЛИЗ, УЛУЧШЕНИЕ И УПРАВЛЕНИЕ

ПРОИЗВОДИТЕЛЬНОСТЬЮ ......................................................................65
Глава 4. Анализ логов и метрик. ...................................................................66
Метрики использования в Power BI.........................................................................66
Доработка отчета о метриках использования. ..................................................69
Фильтрация метрик использования. ..............................................................69
Доступ к сырым данным посредством создания редактируемой
копии метрик использования..........................................................................70
Доступ к сырым данным посредством создания собственного отчета
о метриках использования...............................................................................73
Доступ к сырым данным с помощью анализа метрик использования
в Excel...................................................................................................................74
Анализ детализированной информации о производительности. .............74
Анализ метрик отчета о производительности. .............................................76
Получение показателей производительности из нескольких рабочих
областей...............................................................................................................79
Логи Power BI и трассировка.....................................................................................80
Журнал действий и единый журнал аудита.......................................................80
Трассировка Analysis Services с помощью конечных точек XMLA..................81
8  Содержание
Интеграция с Azure Log Analytics.........................................................................81

Отслеживание показателей в Azure Analysis Services и Power BI
Embedded. ................................................................................................................82
Метрики Azure для AAS.....................................................................................82
Диагностика в Azure для Analysis Services......................................................83
Метрики Azure и диагностика для PBIE..........................................................84
Заключение..................................................................................................................84
Материалы к прочтению. ..........................................................................................85
Глава 5. Анализатор производительности...............................................86

Технические требования. ..........................................................................................86
Обзор Анализатора производительности...............................................................87
Действия и метрики в Анализаторе производительности. .............................88
Определение действий пользователя. ................................................................89
Определение и устранение проблем с производительностью............................92
Единообразие тестов..............................................................................................93
Возможности и ограничения Анализатора производительности..................97
Интерпретация и выводы о данных от Анализатора
производительности..............................................................................................98
Медленные запросы. .........................................................................................98
Медленные визуальные элементы................................................................100
Эффект от добавления новых визуальных элементов. ..............................102
Экспорт и анализ данных о производительности...............................................103
Заключение................................................................................................................107
Глава 6. Внешние инструменты...................................................................109

Технические требования. ........................................................................................110
Power BI Helper. .........................................................................................................110
Поиск столбцов, занимающих много места.....................................................110
Поиск неиспользуемых столбцов.......................................................................111
Поиск двунаправленных и неактивных связей...............................................112
Поиск зависимостей в мерах..............................................................................112
Tabular Editor.............................................................................................................113
Использование утилиты Best Practice Analyzer................................................113
DAX Studio и VertiPaq Analyzer................................................................................118
Анализ размера модели данных при помощи VertiPaq Analyzer..................118
Настройка производительности модели данных и запросов DAX. ..............120
Перехват и повторный запуск запросов.......................................................120
Получение информации о времени выполнения запросов. .....................122
Изменение и настройка запросов. ................................................................123
Заключение................................................................................................................126
Глава 7. Общие принципы управления производительностью.....128

Налаживание воспроизводимого и упреждающего процесса повышения
производительности................................................................................................129
Цикл управления производительностью..........................................................130
Установка/обновление контрольных целевых показателей......................130
Мониторинг и хранение истории..................................................................132

Обнаружение проблем и расстановка приоритетов...................................132
Диагностирование и исправление. ...............................................................132
Принятие превентивных мер.........................................................................132
Обмен опытом и знаниями.....................................................................................133
Помощь конечным пользователям....................................................................133
Инструкция для разработчиков. ........................................................................134
Совместный подход к повышению производительности..............................134
Применение цикла управления производительностью в разных
сценариях. .............................................................................................................135
BI-системы самообслуживания......................................................................135
BI-системы на основе отдела или команды.................................................136
Корпоративные или управляемые ИТ-отделами BI-системы...................136
Заключение................................................................................................................138
Часть III. ИЗВЛЕЧЕНИЕ, ПРЕОБРАЗОВАНИЕ

И ВИЗУАЛИЗАЦИЯ ДАННЫХ .................................................................140
Глава 8. Загрузка, преобразование и обновление данных. .........141
Основные принципы преобразования данных. ..................................................142
Обновление данных, параллелизм и использование ресурсов.....................142
Улучшение среды разработки.............................................................................145
Свертывание запросов, объединение и агрегация..............................................149
Использование добавочного обновления.........................................................152
Использование диагностики запросов..................................................................154
Сбор диагностической информации в Power Query........................................156
Анализ логов Power Query...................................................................................157
Оптимизация потоков данных...............................................................................160
Заключение................................................................................................................165
Глава 9. Разработка отчетов и дашбордов. ..........................................166

Оптимизация интерактивных отчетов.................................................................167
Управление визуальными элементами и запросами. ....................................167
Установите выбор по умолчанию в срезах/фильтрах для первой
загрузки.............................................................................................................168
Избегайте вывода подробных таблиц со множеством столбцов
в базовом отчете...............................................................................................169
Объединяйте индивидуальные карточки в многострочные
или в таблицы...................................................................................................170
Используйте фильтр Ведущие N для ограничения данных в отчете. ......172
Переместите редко используемые срезы на панель фильтров.................173
Исключите ненужные взаимодействия пользователя с отчетом.............173
Используйте всплывающие подсказки для снижения объема
и сложности запросов......................................................................................174
10  Содержание
Проверяйте на производительность пользовательские визуальные

элементы и отдавайте предпочтение сертифицированным
элементам. ........................................................................................................175
Используйте технику сокращения числа запросов для сложных
отчетов...............................................................................................................176
Оптимизация дашбордов........................................................................................176
Оптимизация отчетов с разбивкой на страницы................................................177
Заключение................................................................................................................179
Часть IV. МОДЕЛИ ДАННЫХ, ВЫЧИСЛЕНИЯ И РАБОТА

С ОБЪЕМНЫМИ НАБОРАМИ . .................................................................181
Глава 10. Моделирование данных и безопасность
на уровне строк...................................................................................................182
Построение эффективных моделей данных.........................................................183
Теория Кимбалла и реализация схемы «звезда». ............................................183
Разработка схемы «звезда».............................................................................184
Работа со связями типа «многие ко многим»..............................................187
Уменьшение размера набора данных...............................................................190
Ловушки при использовании безопасности на уровне строк............................194
Заключение................................................................................................................199
Глава 11. Улучшаем DAX.................................................................................201

Ловушки DAX и способы оптимизации.................................................................202
Процесс отладки выражений DAX......................................................................202
Руководство по оптимизации в DAX.................................................................203
Используйте переменные вместо повторения определений мер............203
Используйте функцию DIVIDE вместо оператора деления.......................205
Избегайте преобразования пустых значений в ноль или какого-то
текста при вычислении числовых мер..........................................................206
Используйте функцию SELECTEDVALUE вместо VALUES...........................209
Используйте функции IFERROR и ISERROR уместно..................................210
Используйте функцию SUMMARIZE только с текстовыми столбцами. ...210
Избегайте использования функции FILTER при передаче
фильтрующих условий. ...................................................................................210
Используйте функцию COUNTROWS вместо COUNT..................................211
Используйте функцию ISBLANK вместо BLANK..........................................211
Оптимизируйте виртуальные связи при помощи функции TREATAS.....211
Заключение................................................................................................................213
Глава 12. Шаблоны работы с большими данными...........................215

Масштабирование при помощи Power BI Premium и Azure Analysis Services. ....216
Использование Power BI Premium для масштабирования данных...............216

Использование Azure Analysis Services для масштабирования данных
и пользователей....................................................................................................218
Использование горизонтального масштабирования запросов
для увеличения количества пользователей.................................................218
Использование секционирования с AAS и Premium.......................................220
Масштабирование с использованием составных моделей и агрегатов...........223
Составные модели данных..................................................................................223
Использование агрегатов....................................................................................226
Масштабирование с Azure Synapse и Azure Data Lake.........................................230
Современная архитектура хранилища данных. ..............................................232
Azure Data Lake Storage........................................................................................233
Azure Synapse Analytics........................................................................................233
Заключение................................................................................................................234
Материалы для чтения.............................................................................................236
Часть V. ОПТИМИЗАЦИЯ ЕМКОСТЕЙ PREMIUM

И EMBEDDED .....................................................................................................237
Глава 13. Оптимизация емкостей Premium и Embedded. ..............238
Возможности Premium, использование ресурсов и автомасштабирование....239
Поведение емкостей Premium и использование ресурсов.............................240
Как оценивается нагрузка на емкость?.............................................................243
Перегрузка емкости и автомасштабирование.................................................245
Управление пиковыми нагрузками при помощи
автомасштабирования. ...................................................................................246
Планирование емкости, мониторинг и оптимизация........................................248
Определение исходного размера емкости. ......................................................249
Проверка емкости с помощью нагрузочного тестирования..........................250
Мониторинг использования ресурсов емкости и перегрузки.......................253
Исследование перегрузки...............................................................................258
Заключение................................................................................................................266
Глава 14. Встраивание в приложения......................................................268

Повышение производительности внедрения. .....................................................269
Измерение производительности внедрения........................................................273
Заключение................................................................................................................275
Послесловие...........................................................................................................276
Предметный указатель. ..................................................................................277

От издательства
Отзывы и пожелания
Мы всегда рады отзывам наших читателей. Расскажите нам, что вы думаете
об этой книге – что понравилось или, может быть, не понравилось. Отзывы
важны для нас, чтобы выпускать книги, которые будут для вас максимально
полезны.
Вы можете написать отзыв на нашем сайте www.dmkpress.com, зайдя на
страницу книги и оставив комментарий в разделе «Отзывы и рецензии».
Также можно послать письмо главному редактору по адресу dmkpress@gmail.
com; при этом укажите название книги в теме письма.
Если вы являетесь экспертом в какой-либо области и заинтересованы в на-
писании новой книги, заполните форму на нашем сайте по адресу http://
dmkpress.com/authors/publish_book/ или напишите в издательство по адресу
dmkpress@gmail.com.
Список опечаток
Хотя мы приняли все возможные меры для того, чтобы обеспечить высо-
кое качество наших текстов, ошибки все равно случаются. Если вы найдете
ошибку в одной из наших книг, мы будем очень благодарны, если вы сооб-
щите о ней главному редактору по адресу dmkpress@gmail.com. Сделав это,
вы избавите других читателей от недопонимания и поможете нам улучшить
последующие издания этой книги.
Нарушение авторских прав

Пиратство в интернете по-прежнему остается насущной проблемой. Издатель-
ство «ДМК Пресс» очень серьезно относится к вопросам защиты авторских прав
и лицензирования. Если вы столкнетесь в интернете с незаконной публикацией
какой-либо из наших книг, пожалуйста, пришлите нам ссылку на интернет-ре-
сурс, чтобы мы могли применить санкции.
Ссылку на подозрительные материалы можно прислать по адресу элект
ронной почты dmkpress@gmail.com.
Мы высоко ценим любую помощь по защите наших авторов, благодаря
которой мы можем предоставлять вам качественные материалы.
Предисловие
Спросите любого, кто когда-либо присутствовал на конференции, посвящен-

ной базам данных, писал посты или вел блоги по этой теме, какой вопрос
является наиболее актуальным во все времена, и вы наверняка получите один
и тот же ответ – повышение эффективности. И если лекции по проектиро-
ванию баз данных традиционно набирают достаточное количество посети-
телей, то на семинары, посвященные оптимизации БД, бывает, просто не
пробиться. В чем здесь дело? Мне кажется, все очень просто – так же просто,
как и основная цель оптимизации, состоящая в том, чтобы медленное сделать
быстрым. Этому главным образом посвящена ежедневная профессиональная
деятельность администраторов баз данных, разработчиков отчетов и бизнес-
аналитиков. Скорость естественным образом преобразуется в удобство ис-
пользования инструмента и быстроту принятия решений, что положительно
сказывается на моральном духе коллектива и критически важных показате-
лях организации. Да и сами разработчики, способные повысить скорость вы-
полнения запросов и формирования отчетов, обычно не остаются в стороне
и получают повышения и прибавку в зарплате.
Power BI в этом отношении ничем не отличается от любого другого инстру-
мента бизнес-аналитики или базы данных. Одной из самых популярных причин
недовольства пользователей является скорость формирования отчетов. В обыч-
ных условиях Power BI славится своей высокой производительностью даже при
работе с довольно большими объемами данных. Но достаточно допустить не-
большую ошибку при написании сложного вычисления или проектировании
модели данных, и вы не оберетесь проблем. Будучи специалистом в области
Power BI, вы должны уметь оптимально с точки зрения производительности
проектировать модели данных и решать возникающие проблемы с отчетами.
Все это значительно повышает значимость книги, которую написал Бхавик.
Несмотря на большую популярность темы оптимизации, я лично не видел до
этого ни одной книги из этой области в Power BI. В этой книге собраны вместе
советы, подсказки и приемы, которые раньше были беспорядочно разброса-
ны по официальной документации, блогам, курсам и статьям, и положены
на огромный опыт автора в составе отдела разработки Power BI во взаимо-
действии с крупнейшими заказчиками. Вместо того чтобы сосредоточиться
на одном аспекте оптимизации, например выражениях DAX, автор рассмот
рел тему повышения эффективности Power BI действительно многогранно
и всесторонне. В результате мы получили бесценный ресурс, способный стать
краеугольным камнем на пути совершенствования навыков в деле оптимиза-
ции проектов на базе Power BI. Строго следуйте всем советам из этой книги
и воплощайте их в жизнь!
Кристофер Уэбб,
главный администратор команды Power BI CAT,
13-кратный обладатель статуса MVP
и автор множества книг в области SSAS и Power BI
Об авторе
Бхавик Мерчант (Bhavik Merchant) обладает 18-летним опытом работы в об-

ласти бизнес-аналитики и занимает пост руководителя отдела продуктовой
аналитики в Salesforce. До этого работал в Microsoft сначала в роли архитек-
тора облачных решений, а затем в статусе продуктового менеджера в про-
ектной группе Power BI. В отделе Power BI Бхавик возглавлял программу
клиентских исследований, отвечая за стратегию и техническую структуру
предоставления клиентам информации о производительности системы. До
Microsoft много лет работал консультантом BI-систем в отделе корпоратив-
ных клиентов. Проводил технические и теоретические тренинги в области
повышения эффективности Power BI для партнеров Microsoft по всему миру.
О редакторах
Суреш Датла (Suresh Datla) работает в IT-индустрии более 20 лет и обладает

большим опытом в области бизнеса и технологий. Он является разработчи-
ком, консультантом, популяризатором и тренером по Power BI. С момента
появления на рынке Azure и Power Platform тесно работает с этими система-
ми, а также является частью проекта Microsoft по разработке и внедрению
вертикальных решений. Суреш неоднократно выступал на мероприятиях от
Microsoft по темам Power Platform, Power BI, Power BI Premium, безопасности
и эффективности. Каждый месяц организовывает форум по Power Platform
в Южной Калифорнии и свято верит в то, что своим успехом эта платформа
всецело обязана квалифицированному сообществу. Суреш является директо-
ром компании Synergis Consulting, возглавляя группы архитектуры данных,
разработчиков и инженеров.
Вишванат Музумдар (Vishwanath Muzumdar) имеет более чем 8-летний

опыт работы в сфере информационных технологий и бизнес-аналитики.
Специализируется на создании визуальных отчетов для клиентов. Своей
целью видит применение управленческих и аналитических навыков в сфере
инструментов отчетности Microsoft Power BI для помощи компании в дости-
жении финансовых успехов.
Введение
Начать выстраивать аналитические решения с помощью Power BI очень не-

сложно. После этого проект может жить собственной жизнью, набирая попу-
лярность и повышая объем используемых данных. Однако если не заплани-
ровать такой рост изначально, вы наверняка в какой-то момент столкнетесь
с проблемами. Эта книга поможет вам провести мероприятия по оптими-
зации всех без исключения слоев Power BI, начиная с рабочей области отче-
та и заканчивая моделированием данных, их преобразованием, хранением
и архитектурой.
Разработчики и архитекторы, работающие с Power BI, смогут применить
полученные из этой книги знания на практике на всех стадиях жизненного
цикла своих решений. Книга, которую вы держите в руках, – это не просто
сборник советов и приемов по оптимизации своих проектов, но и полное
структурированное руководство для обнаружения узких мест и их устра-
нения.
Изучив все приведенные практики и примеры, вы научитесь определять
распространенные ошибки на этапе проектирования данных, приводящие
к снижению эффективности решения и расходованию лишней памяти. Мы
рассмотрим все настройки, которые могут негативно сказываться на про-
изводительности. Вместе мы пройдем по всем слоям типичного решения
Power BI и узнаем, что необходимо сделать, чтобы при масштабировании
проекта не страдало его быстродействие. Начнем мы со слоя данных и по-
степенно поднимемся до уровня дизайна отчетов. Попутно мы рассмотрим
варианты лицензирования Power BI Premium, включая процесс планиро-
вания загрузки и нагрузочное тестирование, и поговорим о службах Azure,
позволяющих обеспечить дополнительное масштабирование.
Прочитав книгу, вы сможете поддерживать решения Power BI любой сте-
пени сложности с минимальными усилиями. Вдобавок вы научитесь исполь-
зовать сторонние программные продукты для обнаружения проблем с про-
изводительностью.
Для кого эта книга

Книга, которую вы начинаете читать, предназначена для аналитиков дан-
ных, разработчиков в области бизнес-аналитики и специалистов по рабо-
те с Power BI. Она будет полезна тем, кто хочет создавать решения на базе
Power BI, способные масштабироваться в отношении объема данных и ко-
личества пользователей без потери эффективности. Также книга поможет
идентифицировать и устранить узкие места, влияющие на производитель-
ность решения. Для понимания всех концепций, описанных в этой книге, вам
потребуется базовое знание Power BI и всех его компонентов.
Структура книги  17
Структура книги
Глава 1 «Постановка целей и определение проблемных областей». В этой
главе мы рассмотрим решение на базе Power BI в виде потока данных от
различных источников к потребителям в обобщенном виде. Мы посмотрим,
как могут храниться и перемещаться данные в Power BI на пути к конечным
потребителям. В большинстве случаев решения относительно архитектуры
проекта, принятые на ранней стадии, бывает трудно и дорого отменить или
изменить. Именно поэтому необходимо на самом старте проекта правильно
оценивать нагрузку и планировать разработку, исходя из нее.
Глава 2 «Обзор архитектуры и конфигурации Power BI». Из этой гла-
вы вы узнаете, как можно улучшить производительность и снизить время
ожидания получения информации. Здесь мы также расскажем о режимах
хранения данных в Power BI и их перемещении в модель данных, поскольку
решения, принятые на этом этапе, могут влиять на объемы и актуальность
исходных данных. Кроме того, мы рассмотрим разные варианты разверты-
вания шлюзов Power BI, обычно используемых для подключения к внешним
источникам данных. Важность этой темы обусловлена тем, что пользовате-
лям зачастую требуется оперировать одновременно актуальными и истори-
ческими данными, объем которых ничем не ограничен.
Глава 3 «Оптимизация DirectQuery». В третьей главе книги мы позна-
комимся с режимом хранения DirectQuery, полагающимся на внешние ис-
точники данных. Этот режим, как правило, используется в организациях
при наличии больших объемов данных. Источники DirectQuery зачастую
не предназначены для аналитических запросов, что негативно сказывается
на быстродействии отчетов и операций обновления данных. Мы рассмот
рим методы оптимизации как в отношении Power BI, так и применительно
к внешним источникам, что позволит повысить эффективность запросов.
Глава 4 «Анализ логов и метрик». В этой главе мы поговорим о том, что
быстродействие отчетов может быть улучшено только в случае ее объектив-
ной оценки. Таким образом, здесь мы узнаем, где можно взять данные о про-
изводительности и как по ним определить наличие узких мест в системе.
Будут рассмотрены встроенные и внешние инструменты для мониторинга
показателей эффективности, а также даны полезные рекомендации по про-
ведению такого анализа.
Глава 5 «Анализатор производительности». Здесь мы поговорим об
одном из самых простых способов отслеживания временных задержек при
формировании отчетов. Мы воспользуемся инструментом Анализатор про-
изводительности, служащим для проведения подробного анализа действий
пользователей с детализацией до визуальных элементов. Мы выполним рас-
ширенный обзор всех возможностей, опишем все метрики и продемонстри-
руем процесс анализа на примере.
Глава 6 «Внешние инструменты». Данная глава будет посвящена сто-
ронним инструментам, способным помочь при анализе производительности
решений. Мы рассмотрим типичные сценарии использования таких инстру-
ментов с подключением к Power BI, сбором ключевых показателей эффектив-
ности и их подробным анализом.
18  Введение
Глава 7 «Общие принципы управления производительностью». В этой

главе мы расскажем о том, что метрики и инструменты, описанные в пред-
шествующих главах, по сути, являются строительными блоками общей си-
стемы управления показателями эффективности. При этом успех более ве-
роятен при внедрении структурированного и воспроизводимого подхода
к построению образа мышления на основе показателей эффективности на
всех стадиях жизненного цикла решения в Power BI. Здесь мы приведем со-
веты по процессу управления данными, которые помогут избежать проблем
с масштабированием для новой информации и предотвратить ухудшение
качества данных для имеющейся. Мы также обсудим типичные роли в рам-
ках аналитического проекта любого уровня – от самостоятельного до управ-
ляемого из единого центра – и расскажем об их функциях в деле повышения
эффективности решения.
Глава 8 «Загрузка, преобразование и обновление данных». Здесь мы
поговорим о важнейшей роли периодического обновления данных для лю-
бой аналитической системы, и в Power BI это применимо к наборам данных
в режиме Import. Операции по обновлению данных в этом режиме являются
одними из наиболее затратных в отношении нагрузки на центральный про-
цессор и память, и они могут повлечь серьезные задержки и даже отказы,
особенно при работе с объемными наборами данных. В результате поль-
зователи могут остаться без обновлений, процесс разработки замедлится,
а ресурсы будут постоянно подвергаться огромным нагрузкам. Чтобы из-
бежать этих проблем, требуется при преобразовании данных уделить особое
внимание вопросам производительности.
Глава 9 «Разработка отчетов и дашбордов». В этой главе мы поговорим
о вершине айсберга любого решения Power BI, представляющей собой отчеты
и дашборды, с которыми по большей части взаимодействует пользователь.
Независимо от своего визуального представления, этот слой Power BI по
своей сути является приложением JavaScript, запущенным в браузере. Здесь
мы коснемся ключевых приемов, позволяющих оптимизировать вывод визу-
ального слоя, включая срезы и фильтрацию. Также мы поговорим о постра-
ничных отчетах, которые ведут себя отлично от интерактивных и обладают
своими особенностями в отношении оптимизации.
Глава 10 «Моделирование данных и безопасность на уровне строк».
Здесь мы подробно поговорим о наборах данных Power BI, в которых хра-
нится исходная информация после преобразования и откуда извлекается для
анализа. Таким образом, это наиболее критичная область любого решения на
базе Power BI, лежащая в его основе. В то же время Power BI обладает доста-
точным арсеналом возможностей, которые можно применить в процессе мо-
делирования данных. Некоторые решения способны облегчить процесс раз-
работки ценой снижения производительности запросов и/или увеличения
объема обрабатываемых данных. В этой главе мы дадим полезные советы
по моделированию данных, снижению объемов задействованной информа-
ции и ускорению работы связей. В заключение коснемся темы оптимизации
безопасности на уровне строк.
Глава 11 «Улучшаем DAX». В данной главе мы посмотрим, как формулы
DAX позволяют разработчику расширить функционал модели данных. При
Как извлечь максимум из книги  19
этом одного и того же результата можно добиться с применением разных

формул, и не все они будут одинаково эффективными в конкретных усло-
виях. Мы перечислим основные проблемы, связанные с формулами DAX,
и научимся писать код более эффективно.
Глава 12 «Шаблоны работы с большими данными». Здесь мы узнаем,
как постоянный рост объема данных в компании способен привести к серьез-
ным проблемам. Даже с применением инновационных технологий сжатия
данных, используемых в Power BI, бывает затруднительно за приемлемое вре-
мя выполнять загрузку нужных нам наборов данных в режиме Import. И эта
проблема усугубляется необходимостью параллельно поддерживать работу
в системе сотен и тысяч пользователей. В этой главе мы рассмотрим способы
борьбы с подобными проблемами, включая использование лицензирования
Power BI Premium, технологий Azure, а также составных моделей и агрегатов.
Глава 13 «Оптимизация емкостей Premium и Embedded». В этой главе
мы обсудим предоставляемые в рамках лицензии Power BI Premium выделен-
ные емкости с менее строгими ограничениями, а также другие возможности,
включая постраничные отчеты и службы искусственного интеллекта. Кроме
того, мы поговорим о втором поколении Premium (Gen2) и узнаем, как при
наличии такой подписки система справляется с повышенной нагрузкой и как
работает автоматическое масштабирование. Попутно мы коснемся настроек,
которые могут позволить повысить производительность системы. Мы на-
учимся правильно планировать объемы данных и проводить нагрузочные
тесты. Также мы посмотрим, как можно использовать приложение Capacity
Metrics для поиска и решения проблем с нагрузкой на емкость.
Глава 14 «Встраивание в приложения». В заключительной главе книги мы
посмотрим, как можно встраивать содержимое Power BI в пользовательские
веб-приложения для интегрирования информации с данными из других ис-
точников. В этом случае приложение размещается на стороннем сервере при
помощи вызовов API, что накладывает дополнительные ограничения. Мы по-
говорим о том, как можно организовать этот процесс наиболее эффективно.
Как извлечь максимум из книги

К некоторым главам этой книги прилагаются файлы с примерами, которые
можно открыть с помощью Power BI Desktop. Это поможет вам лучше понять
описываемые концепции и приемы. В основном в примерах показаны си-
туации до и после внесенных изменений. Вам не обязательно проверять все
представленные теории на примерах, но они действительно могут помочь
в их освоении.
Программное обеспечение, использованное при написании книги: ОС Win
dows, Power BI Desktop, DAX Studio 2.17.3, Tabular Editor 3, Power BI Helper 12.0.
Мы советуем вам всегда работать с самой свежей версией Power BI Desktop,
следуя их ежемесячным обновлениям.
Если вы читаете электронную версию книги, мы советуем вам вводить код
самостоятельно или копировать его из репозитория книги на GitHub (ссылка
20  Введение
будет дана в следующем разделе). Это поможет вам избежать ошибок при
копировании скриптов из книги.
Сопроводительные файлы
Файлы с примерами можно загрузить из репозитория книги на GitHub по
адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-
Practices. Все возможные обновления будут появляться там же.
Также вы можете загрузить текущую версию файлов с сайта издательства
по адресу www.dmkpress.com на странице с описанием данной книги.
Цветные изображения
По следующей ссылке вы можете скачать в виде PDF все рисунки и диа-
граммы, использованные в книге: https://static.packt-cdn.com/downloads/
9781801076449_ColorImages.pdf.
Условные обозначения
На протяжении книги мы будем использовать следующие условные обозна-
чения и шрифты.
Код в тексте: так в тексте книги мы будем обозначать код, имена таблиц
баз данных, имена папок, файлов, расширения файлов, пути, ссылки, поль-
зовательский ввод. Пример: «Просто скопируйте приведенный ниже код,
выполните его, после чего перезапустите TabularEditor, чтобы применились
новые правила».
Блоки кода будут выделены следующим образом:
System.Net.WebClient w = new System.Net.WebClient();
string path = System.Environment.GetFolderPath(System.Environment.SpecialFolder.
LocalApplicationData);
string url = "https://raw.githubusercontent.com/microsoft/Analysis-Services/master/
BestPracticeRules/BPARules.json";
string downloadLoc = path+@"\TabularEditor\BPARules.json";
w.DownloadFile(url, downloadLoc);
Новые термины, важные слова и текст, который вы видите на экране, будут

выделены жирным шрифтом, например: «Раздел Workloads содержит на-
стройки, связанные с производительностью».
Важные примечания будут выводиться так.
Советы будут выводиться так.
Примечания будут выводиться так.

Часть I
Архитектура, узкие места
и целевые показатели
производительности
В этой вводной части мы дадим высокоуровневый обзор архитектуры Po

wer BI и определим области, в которых на производительность можно влиять
посредством проектных решений. После прочтения данной части вы будете
понимать, как устанавливать реалистичные целевые показатели произво-
дительности.
Содержание этой части:
глава 1 «Постановка целей и определение проблемных областей»;
глава 2 «Обзор архитектуры и конфигурации Power BI»;
глава 3 «Оптимизация DirectQuery».
Глава 1
Постановка целей
и определение
проблемных областей
При анализе производительности аналитических решений многие считают

важнейшим показателем быстродействие системы формирования отчетно-
сти. По большей части это так и есть, поскольку практически все пользовате-
ли – от операторов до управляющих – взаимодействуют с системой именно
посредством отчетов как главной визуальной составляющей. Однако скоро
вы узнаете, что существуют и другие не менее важные области для примене-
ния оптимизации, если смотреть на ситуацию в целом. К примеру, ускорение
подсистемы формирования отчетов может не дать ожидаемых результатов,
если исходный набор данных, лежащий в основе отчета, долго обновляется
или выдает ошибки из-за достигнутых ограничений выделенных ресурсов.
В итоге актуальные свежие данные могут просто не поспевать за великолеп-
ными и быстро формирующимися отчетами.
Автор книги, которую вы держите в руках, испытал на себе последствия
снижения быстродействия системы отчетов. Как-то раз в одной крупной
коммунальной компании предприняли попытку миграции с одной системы
формирования отчетности на другую, от стороннего поставщика. Несмотря
на превосходство новой системы в техническом и функциональном планах,
разработчики попытались напрямую перенести в нее функционал старых от-
четов. В результате это решение привело к существенному снижению быст
родействия отчетов. Были потрачены миллионы на лицензирование и кон-
сультации с новым поставщиком, но большинство пользователей просто
отказывались переходить на новую систему из-за ее медлительности. Этот
случай мы привели в качестве демонстрации возможных последствий того,
что может произойти, если изначально правильно не заложить фактор про-
изводительности в аналитическое решение.
В этой главе вы начнете свое путешествие в мир оптимизации решений
на базе Microsoft Power BI. В качестве введения в полный спектр управления
производительностью мы рассмотрим решения Power BI в образе потока
данных от различных источников в консолидированном виде и их представ-
ления аналитикам данных и прочим пользователям, работающим с инфор-
Определение уровня производительности  23
мацией. Мы посмотрим, как данные могут храниться в Power BI и какой путь

преодолевать по дороге к конечному пользователю. Многие архитектурные
и проектные решения, принятые на ранней стадии становления проекта,
бывает очень проблематично и дорого отменять или изменять впоследствии.
В связи с этим возрастает важность всесторонней предварительной оценки
возможных последствий принимаемых решений и использования подхода
на основе данных к выбираемой стратегии на самом старте.
При оценке эффективности системы разработчики зачастую недооцени-
вают или вовсе упускают из виду процесс установки целевых показателей
производительности (performance targets). А как без этого определить, како-
го результата вы в итоге добились? Давайте начнем с теоретической части
описания целей, после чего перейдем к техническим аспектам реализации.
Темы, которые будут рассмотрены в этой главе:
определение уровня производительности;
области с возможными замедлениями;
решения, влияющие на производительность.
Определение уровня производительности

С появлением сверхбыстрых компьютеров и средств распределенного вычис-
ления пользователи и заказчики аналитических решений вполне обоснованно
стали ожидать от них впечатляющего быстродействия, что бывает критически
важно для принятия серьезных бизнес-решений. Поставщики инструментов
бизнес-аналитики откликнулись на эти ожидания упоминаниями во всех сво-
их рекламных проспектах потрясающей скорости работы предлагаемых ими
решений. В результате сегодня с трудом можно найти пользователя, который
воспринял бы действительно быстро формирующиеся отчеты или вовремя
обновляющиеся данные как нечто необычное и поражающее воображение –
скорее, как само собой разумеющееся. И наоборот, любая задержка в процессе
формирования отчетов приводит к резкой негативной реакции с его стороны
и жалобам во все возможные инстанции. Если такие проблемы начинают но-
сить масштабный характер, критике начинает подвергаться как сама платфор-
ма, такая как Power BI, так и техническая команда, занимающаяся разработкой
конкретного решения. В худшем случае пользователи могут отказаться рабо-
тать в предлагаемом программном комплексе, в результате чего руководство
может принять решение о смене платформы. Решение состоит в том, чтобы
на самых ранних стадиях проекта задуматься о быстродействии строящегося
проекта, поскольку исправить возникшие проблемы с производительностью
при выходе на рабочие мощности с привлечением тысяч пользователей может
оказаться очень сложно, если не невозможно.
Показатели производительности отчетов

Сегодня большинство решений в области бизнес-аналитики существуют
в виде веб-интерфейса. При этом работа с отчетами обычно не ограни-
24  Постановка целей и определение проблемных областей
чивается одним лишь их формированием – пользователи с ними активно

взаимодействуют. Применительно к Power BI это означает открытие отчета
и дальнейшую интерактивную работу с фильтрами, срезами и визуальными
элементами, детализацию до нужных уровней и переключение между стра-
ницами как непосредственно, так и с помощью закладок. Каждое взаимо-
действие пользователя с отчетом имеет определенное намерение, и нельзя
разрывать эту связь. В нашей отрасли бытует высказывание о том, что ана-
литика должна производиться со скоростью мысли. Этот опыт и связанные
с ним ожидания очень напоминают навигацию по обычному веб-сайту или
взаимодействие с программным обеспечением в интернете.
Таким образом, при определении показателей производительности для
аналитической системы можно воспользоваться многими наработками, при-
нятыми в веб-студиях и используемыми на протяжении последних двух-трех
десятилетий, – это не так сложно. В своей статье от 2004 года профессор
Фиона На (Nah, F.) определила показатель приемлемого времени ожидания
(tolerable wait time – TWT) для веб-пользователей. Этот показатель описы-
вает время, которое пользователь сайта готов ждать, перед тем как закрыть
веб-страницу. В своей статье профессор привела многочисленные исследова-
ния прошлых лет, ориентированные на определение пороговых временных
отметок, по достижении которых у пользователя истекает терпение и по-
является негатив. Из этих исследований можно сделать вывод о том, что
в хорошем отчете Power BI должна полностью загружаться страница или
появляться результат интерактивного взаимодействия в идеале в течение
четырех секунд, а в большинстве случаев – не позже, чем через 12 секунд. При
этом измерение всегда стоит производить с точки зрения пользователя, т. е.
с момента вызова им отчета (например, нажатия на ссылку на веб-портале
Power BI) и до завершения полной отрисовки отчета на экране.
Установка реалистичных целевых показателей

Теперь, когда у нас есть руководство по установке целевых показателей на
основе исследований, нам нужно применить его на практике. Распростра-
ненной ошибкой является установка единого целевого показателя для всех
отчетов и ожидание, что он будет выполняться при каждом взаимодействии
пользователя с любым из них. Недостаток такого подхода заключается в том,
что даже хорошо спроектированная и оптимизированная система может
оказаться слишком сложной для удовлетворения оптимистично установлен-
ной цели. К примеру, при наличии очень большого набора данных (десятки
гигабайт) и сложного вложенного выражения DAX, результат которого ото-
бражается в табличном визуальном элементе (Table) с несколькими уровня-
ми гранулярности, вам будет никак не уложиться в рамки, приемлемые для
небольшого датасета с простыми агрегациями в виде суммирования и ото-
бражением в виде карточек (Card).
Таким образом, по причине изменчивости сложности решений и других
факторов, не зависящих от разработчика (к примеру, мощности компьютера
Области с возможными замедлениями  25
пользователя или используемого им браузера), стоит рассматривать целе-

вые показатели производительности в терминах типичного опыта исполь-
зования (typical user experience) и предполагать, что есть как ожидания, так
и выбросы. В результате целевые метрики должны вычисляться с расчетом
на большинство пользователей. Мы рекомендуем устанавливать целевые
показатели с использованием 90-го процентиля для загрузки отчета или
интерактивного взаимодействия с ним пользователя. Часто такая метрика
называется P90. С учетом приведенных выше исследований целевая метрика
P90 по загрузке отчета должна составлять 10 секунд или меньше. Это озна-
чает, что 90 % загрузок отчета должны укладываться в интервал до 10 секунд
включительно.
В то же время одного только показателя P90 будет недостаточно, и мы
подробно будет говорить об этом в главе 7. На данный момент мы должны
учитывать, что решения могут быть разной степени сложности, в связи с чем
рекомендуется устанавливать набор метрик в зависимости от характера от-
чета и его допусков по ожиданию. На рис. 1.1 показан пример таблицы с це-
левыми показателями, которую можно адаптировать под конкретные нужды
организации.
Обычный отчет Сложный отчет
Целевая метрика P90 Меньше 10 секунд Меньше 25 секунд
Рис. 1.1  Пример целевых метрик для отчетов в Power BI
Теперь взглянем на Power BI в целом, чтобы лучше понимать, в каких

именно областях необходимо внедрять оптимизацию.
Области с возможными замедлениями

На следующем шаге нашего процесса улучшения производительности мы
должны понять, на что именно расходуется время. По своей сути любое
решение Power BI призвано в конечном счете представлять информацию
пользователю в удобном для него виде. Таким образом, само решение
можно воспринимать как поток данных, берущих свое начало в опреде-
ленных источниках, преодолевающих различные системные компоненты
Power BI и достигающих компьютера или мобильного телефона конечного
пользователя. Упрощенная схема типичного решения Power BI показана
на рис. 1.2.
Теперь давайте поговорим о различных составных частях типичного ре-
шения на базе Power BI, чтобы лучше разобраться, какую роль каждая из
них играет в отношении возможных проблем с производительностью. Под-
робное рассмотрение некоторых из этих частей мы оставим на вторую главу
книги.
Облачные источники данных

Azure Analysis Services, SQL Azure и т. д.
Обновление по расписанию /
Динамическое подключение / DirectQuery Конечные пользователи
Дашборды Отчеты Служба

Power BI Power BI
Desktop
Analysis Services
Группа (на базе Power BI)
OneDrive
Шлюз Динамическое подключение /
DirectQuery
Локальные источники данных
Analysis Services, SQL Server и т. д.
Рис. 1.2  Решение на базе Power BI в упрощенном виде
Подключение к источникам данных

На рис. 1.3 выделены области решения, на которых сказываются проблемы
с источниками данных и методами подключения к ним.


Power BI Power BI
Desktop
Группа Analysis Services

OneDrive (на базе Power BI)
Локальные источники данных DirectQuery
Рис. 1.3  Области, чувствительные к проблемам

с подключениями и источниками данных
Режим Import
При использовании наборов данных в режиме Import разработчики могут
испытывать проблемы с задержками от пользовательского интерфейса при
работе с Power Query или языком запросов M в Power BI Desktop. В исклю-
чительных случаях это может привести к увеличению сроков разработки
операций преобразования данных с часов до дней. После развертывания
решения проблемы в этой области могут негативно сказываться на времени
обновления данных и даже приводить к отказам. В службе Power BI принято

ограничение на обновление данных, равное двум часам, тогда как при на-
личии лицензии Power BI Premium это ограничение увеличивается до пяти
часов. При превышении этих лимитов любое обновление будет отменено
системой.
Режим DirectQuery
При использовании режима DirectQuery данные физически остаются в ис-
точнике, что предполагает необходимость их извлечения и обработки в Po
wer BI практически при каждом взаимодействии пользователя с системой.
При применении этого режима проблемы обычно возникают в отношении
скорости формирования отчетов пользователем. Визуальные элементы будут
загружаться дольше, пользователи будут нервничать, прерывать загрузку
и пытаться взаимодействовать с другими элементами или менять фильтры.
Это само по себе может привести к увеличению количества отправляемых
запросов, что еще больше замедлит процесс формирования отчетов за счет
дополнительных операций загрузки из внешних источников.
Режим Live connection

Изначально режим Live connection относился исключительно к подключени-
ям к внешним ресурсам Analysis Services, которые могли быть как облачными
(Azure Analysis Services), так и локальными (SQL Server Analysis Services).
Позже, с появлением общих наборов данных (shared datasets) и возможности
строить отчеты в Power BI Desktop на основании опубликованных наборов
данных в службе Power BI, этот режим был расширен. Поскольку исходные
наборы данных могут быть как в режиме Import, так и в режиме DirectQuery,
опыт работы с ними может отличаться, как описано в предыдущих разделах.
Шлюз Power BI
Шлюз (gateway) Power BI – это промежуточный компонент, использующийся
для подключения к внешним источникам данных. Обычно он располагается
в той же физической или виртуальной сети и обеспечивает безопасное ис-
ходящее соединение с Power BI, по которому могут передаваться данные для
отчетов и обновлений.
Но функции шлюза не ограничиваются передачей данных – это распро-
страненное и очень большое заблуждение. Помимо обеспечения защищен-
ного соединения с источниками данных, шлюз содержит свой движок об-
работки (mashup engine), выполняющий преобразование исходных данных
и их сжатие перед отправкой в службу Power BI. При отсутствии оптимизации
шлюза могут возникать задержки с обновлением данных вплоть до сбоев,
замедление взаимодействий пользователей с отчетами и отказы загрузки
визуальных элементов из-за превышения времени выполнения запросов.


Power BI Power BI
Desktop

Локальные источники данных DirectQuery
Рис. 1.4  Шлюз Power BI
Сетевая задержка
Сетевая задержка (network latency) выражается во времени, необходимом для
передачи порции данных из одной точки сети в другую. Этот показатель из-
меряется в миллисекундах, и обычно для этого используется утилита ping.
При помощи нее фиксируется время, затраченное на отправку небольшого
пакета информации в место назначения и получения ответа о его успешной
доставке адресату. Если это время исчисляется секундами, вас могут ждать
серьезные проблемы. Основными факторами, влияющими на сетевую за-
держку, являются географическое расстояние между точками, количество
транзитных участков, или так называемых прыжков (hops), на пути и загру-
женность сети в целом.
На рис. 1.5 показаны пути, по которым данные могут перемещаться в Po
wer BI. Стоит отметить, что для каждой стрелки может быть характерна своя
сетевая задержка, а значит, разные пользователи могут ощущать разную
скорость передачи данных при работе с системой.


Power BI Power BI
Desktop

DirectQuery
Рис. 1.5  Перемещение данных по сети

Наибольшую задержку пользователи могут испытывать при интерактив-

ном взаимодействии с отчетами. В первую очередь это будет заметно тем,
кто работает с отчетами, состоящими из множества визуальных элементов,
а значит, посылающих большое количество запросов, каждый из которых
должен быть обработан, а данные должны быть возвращены по сети.
Служба Power BI
Служба Power BI (Power BI service), выделенная на рис. 1.6, является важней-
шей составляющей любого решения на базе Power BI. Системные компо-
ненты службы в большинстве своем не поддаются управлению со стороны
разработчиков и пользователей. Вместо этого их стабильность и быстро-
действие контролируются компанией Microsoft. Исключениями являются
емкости Power BI Premium и Power BI Embedded, инфраструктура которых
по-прежнему контролируется Microsoft, но администраторы организации
имеют доступ к управлению выделенными им емкостями. Подробно об этом
мы будем говорить в главе 13.


Power BI Power BI
Desktop

DirectQuery
Рис. 1.6  Служба Power BI
Основным компонентом службы Power BI, которым вы можете управлять,

является движок Analysis Services, лежащий в основе решения на базе Po
wer BI. Даже при должном контроле за работой службы Power BI со стороны
Microsoft неправильные решения, принятые в области моделирования дан-
ных в Analysis Services, или неоптимальные вычисления DAX могут приво-
дить к значительному увеличению объема наборов данных, используемой
памяти и, как следствие, замедлению выполняемых запросов. В результате
обычно страдает быстродействие отчетов. При применении емкостей Pre-
mium/Embedded проблемы с Analysis Services могут оказывать экспонен-
циальное воздействие на производительность системы из-за влияния на
множество наборов данных в емкости.
В заключительном разделе этой главы мы перечислим области Power BI,
в которых можно добиться улучшений за счет использования разных шаб
лонов разработки. Выбор, сделанный в этих областях, может оказывать су

щественное влияние на производительность.
Решения, влияющие на производительность

Каждый компонент Power BI в отдельности может быть оптимизирован для
достижения лучшей производительности общего решения, и ниже мы пере-
числим области, с которых стоит начинать свой путь оптимизатора:
неправильное использование режимов DirectQuery/Import: реше-
ния, принимаемые в отношении режимов хранения данных, оказы-
вают влияние на соотношение между размером модели / временем
ее обновления и актуальностью данных / интерактивными возмож-
ностями отчетов;
разработка в Power Query: решения, принимаемые на этом слое, мо-
гут помешать использованию нативных возможностей, которыми на-
делен источник данных, в результате чего дополнительная нагрузка
будет ложиться на внутренний движок обработки Power Query;
моделирование данных: решения в этой области могут негативно
сказываться на объеме модели данных и используемой памяти, а также
приводить к задействованию дополнительных вычислительных ресур-
сов, что не может не отразиться на удобстве использования решения;
неэффективные вычисления DAX: ошибки в этой области могут не
позволить использовать высокоэффективный движок хранилища (Stor-
age Engine) VertiPaq, вместо которого нагрузка ляжет на движок формул
(Formula Engine);
сложные или неэффективные настройки безопасности на уровне
строк: промахи здесь могут приводить к необходимости производить
достаточно интенсивные вычисления для определения того, какие
строки должны быть доступны пользователю;
плохо спроектированные отчеты: неверные решения в этой обла-
сти могут приводить к повышенной нагрузке на устройства конечного
пользователя;
задержка сети или доступа к данным: неправильно выбранная стра-
тегия в этой части может разнести данные и пользователей дальше
друг от друга, чем это возможно.
Теперь, когда вы познакомились со всеми высокоуровневыми областями
решения на базе Power BI, доступными для оптимизации, пришло время
подвести итоги этой главы.
Заключение
Как вы узнали из этой главы, интерактивное взаимодействие с аналитиче-
скими отчетами очень напоминает работу с обычными веб-приложениями,
в связи с чем при определении степени удовлетворенности пользователей
Заключение  31
быстродействием и удобством системы можно опираться на уже известные

принципы, разработанные для интернет-серфинга. Исследования в этой об-
ласти показали, что в идеале процесс формирования отчетов должен уклады-
ваться в 4 с, тогда как превышение отметки в 10–12 с может привести к плохо
скрываемому пользователями недовольству быстродействием отчетов.
В процессе оптимизации системы необходимо устанавливать целевые
показатели производительности и быть готовыми к присутствию выбро-
сов в рамках 90-го процентиля. При наличии очень сложных отчетов нужно
предусмотреть набор метрик производительности, который будет учитывать
характер отчета.
Важно помнить, что каждый компонент Power BI и даже сети, по кото-
рой бегают данные, вносит свой вклад в быстродействие системы в целом.
В связи с этим проблемы с производительностью не стоит пытаться решать
изолированно – например, путем оптимизации только отчетов. Вместо это-
го данный процесс может потребовать координации усилий всей команды
и сторонних поставщиков, особенно это касается крупных организаций.
В следующей главе мы подробнее расскажем о работе внутреннего движ-
ка хранилища VertiPaq в Power BI и посмотрим, как можно оптимизировать
хранение информации. Также мы коснемся вопросов оптимизации шлюза
и дадим важные советы, которые помогут убедиться в том, что эта область
не является узким местом в отношении производительности системы.
Глава 2
Обзор архитектуры
и конфигурации Power BI
В предыдущей главе мы говорили о важности установки метрик производи-

тельности и отдельно рассмотрели области решения на базе Power BI, способ-
ные при их должной оптимизации существенно повлиять на быстродействие
сценария в целом.
В этой главе мы более подробно поговорим о важности архитектурных
решений и их влиянии на производительность системы. Вы узнаете, какие
требования существуют в этой области, и научитесь принимать обоснован-
ные решения в отношении архитектуры проекта, удовлетворяющей всем
сторонам. В конечном итоге эта глава поможет вам определиться с выбором
компонентов для хранения данных в Power BI. Все решения в этой области
должны приниматься с учетом максимально возможной эффективности сле-
дования данных от источника к потребителю путем увеличения скорости
обработки информации и снижения задержек.
Начнем мы с подробного рассмотрения режимов хранения данных в Po
wer BI и способов достижения ими соответствующих наборов данных. Мы
узнаем, как лучше разворачивать шлюз Power BI, который традиционно ис-
пользуется для подключения к внешним источникам. Эти аспекты имеют
важнейшее значение, поскольку пользователям зачастую требуется извле-
кать как актуальные, так и исторические данные, а таких пользователей мо-
гут быть тысячи, и работать они хотят все одновременно.
средства подключения к источникам и режимы хранения данных;
извлечение локальных данных с помощью шлюза;
общая инструкция по архитектуре.
Средства подключения к источникам

и режимы хранения данных
Выбор способа подключения и режима хранения (storage mode) – это, пожалуй,
первое решение, которое необходимо принять при проектировании нового
Средства подключения к источникам и режимы хранения данных  33
решения на базе Power BI. Здесь присутствуют варианты, которые мы обсуж-

дали в предыдущей главе, – Import и DirectQuery. В Power BI Desktop это
решение принимается на этапе подключения к источнику данных перед вы-
водом предварительного просмотра с дальнейшим моделированием данных.
Не все коннекторы в Power BI поддерживают режим DirectQuery. Некоторые из них

способны работать только в режиме Import. Вы должны знать об этом заранее, чтобы
при необходимости выбрать правильную технику поддержки актуальности данных,
если датасет строится на основании разных источников.
На рис. 2.1 показано окно подключения к SQL Server с предложением вы-

брать между режимами Import и DirectQuery.
Рис. 2.1  Опции подключения к SQL Server
К рабочей книге Excel, напротив, можно подключиться только в режиме

Import. На рис. 2.2 видно, что нам доступна лишь кнопка загрузки данных,
без вариантов для выбора. Это предполагает наличие единственного режима
Import.
Выбор между режимами Import и DirectQuery

Режимом подключения по умолчанию в Power BI является Import, поскольку
он более быстрый – иногда на порядок. В режиме Import данные хранятся
в наборах данных Power BI – по сути, в памяти. Первым делом при выборе
этого режима данные копируются в службу Power BI, обычно располагаю-
щуюся в одном географическом регионе с местом обработки отчетов. Этот
регион называется домашним (home region). Источник DirectQuery совсем
34  Обзор архитектуры и конфигурации Power BI
не обязательно должен находиться близко к домашнему региону Power BI.

И если это не так, то данным придется преодолевать определенный путь до
отчетов в Power BI. Кроме того, в зависимости от того, как настроена модель
данных в DirectQuery, движку Analysis Services может понадобиться выпол-
нять весьма дорогостоящую обработку данных для каждого взаимодействия
пользователя с отчетом или аналитического запроса.
Рис. 2.2  При подключении к Excel

отсутствует выбор между режимами Import и DirectQuery
Таким образом, чисто с точки зрения производительности мы обычно

рекомендуем режим Import в сравнении с DirectQuery, поскольку он предпо-
лагает более эффективное интерактивное взаимодействие. Однако из этого
правила есть и исключения, о которых мы поговорим позже.
Еще одной причиной быстродействия режима Import является то, что
он задействует xVelocity – собственное хранилище Power BI, также имену-
емое VertiPaq. xVelocity представляет собой движок колоночного хранилища
(column-based storage), в отличие от строчных хранилищ, использующихся
в большинстве баз данных. Хранилище на основе колонок призвано ниве-
лировать недостатки транзакционных баз данных со строчным хранением
информации в отношении обработки запросов от типичных инструмен-
тов отчетности. Оно способно обрабатывать множество агрегаций даже на
огромных объемах данных, в то же время предоставляя и детализированную
информацию.
В движках с построчным хранилищем информация физически размещает-
ся в виде групп строк. Это прекрасно работает в случае с транзакционными
таблицами, поскольку в них часто выполняются чтение и запись отдельных
строк или их небольших групп. В таких хранилищах в основном используют-
ся в запросах все или большинство колонок в таблицах, и они оптимизирова-
ны для извлечения и записи целых строк. Представьте себе транзакционную

базу данных с продажами, в которую необходимо внести новый заказ. Эта
операция потребует вставки нескольких строк в базу данных. А для просмот
ра заказа нужно будет прочитать несколько строк из различных таблиц, при
этом мы будем использовать почти все колонки.
А теперь представьте типичный аналитический запрос для отчета на осно-
ве той же базы данных с продажами. В этом случае нам, скорее всего, понадо-
бятся агрегированные данные, например продажи или прибыль по месяцам
с разбивкой или фильтрацией по категориям товаров. Подобные запросы
должны обрабатывать большие массивы данных для вычисления агрегатов,
и зачастую в них используются далеко не все столбцы, присутствующие в ис-
ходных таблицах. Такие шаблоны запросов привели к появлению концепции
колоночного хранения данных, при котором информация физически хра-
нится по столбцам, а не по строкам. Хранилища, следующие этой концепции,
оптимизированы для расчета агрегированных величин и фильтрации по
столбцам без необходимости извлекать при этом строки целиком, в которых
присутствует множество не нужных нам данных. Кроме того, такие хранили-
ща спроектированы с расчетом на присутствие в столбцах большого коли-
чества повторений. В этом случае дублирующиеся данные могут физически
не храниться вовсе, что позволяет сэкономить немало места. Такое сжатие
данных в Power BI выполняет движок xVelocity – фактически он применяет
разные алгоритмы компрессии к разным столбцам в зависимости от пред-
ставленных в них типов данных. Эта концепция сжатия данных отнюдь не
нова – примерно то же самое происходит с вашими файлами на компьютере,
когда вы используете архиваторы.
На рис. 2.3 в упрощенном виде показана схема хранения данных в виде
строк и столбцов. Обведенные секции демонстрируют, как физически распо-
лагаются данные в памяти в том и другом случае. В колоночном хранилище
повторяющиеся значения в столбцах (как, например, CustomerID = 16) могут
быть сжаты с целью экономии места на диске.
Рис. 2.3  Сравнение строчного и колоночного хранения информации
В целом можно сказать, что движок xVelocity позволяет значительно по-

высить скорость извлечения данных благодаря их хранению в виде, наиболее
подходящем для аналитических отчетов, и сжатию с использованием самых
продвинутых алгоритмов. В главе 10 вы узнаете подробности оптимиза-

ции моделей данных. Удержание размера модели с использованием режима
Import на минимально возможном уровне позволит вам не выйти за име-
ющиеся ограничения, такие как 10 Гб в расчете на одну рабочую область
(workspace) в общей емкости.
В общем виде принято считать, что использование режима Import совместно с движ-
ком xVelocity позволяет снизить занимаемое моделью место в 5–10 раз. Например,
датасет в Power BI на основе исходных данных объемом 1 Гб может занимать порядка
100–200 Мб. Зачастую можно добиться и большей степени сжатия в зависимости от
кратности (cardinality) данных в столбцах.
Теперь рассмотрим объективные причины отказа от режима Import в поль-

зу DirectQuery.
Когда лучше подойдет режим DirectQuery?

Хотя режим Import имеет неоспоримые преимущества в виде снижения раз-
мера набора данных и повышения скорости выполнения запросов, быва-
ют ситуации, когда лучше будет остановить выбор на режиме DirectQuery.
А иногда у вас просто не будет вариантов, и единственным выбором будет
DirectQuery.
Основным отличием режима DirectQuery от Import, как ясно из названия,
является то, что запросы к набору данных Power BI в этом случае отправ-
ляются напрямую в источник. Очевидный плюс такого способа извлечения
данных состоит в поддержке актуальности информации, поступающей из
источника в ответ на каждый запрос. Сами исходные данные не копируются
в набор данных Power BI. Вместо этого в нем содержатся только метаданные,
такие как названия столбцов и связей. Это исключает необходимость на-
страивать механизм обновления данных или ждать момента актуализации,
чтобы извлечь свежую порцию информации. В результате наборы данных
в режиме DirectQuery занимают крошечное место на диске – от нескольких
килобайт до 2 Мб.
Выбор между режимами Import и DirectQuery – это, конечно, компромисс. Режим Im-
port дает вам максимальную скорость выполнения запросов, но с необходимостью
настраивать механизм обновления данных и мириться с тем, что иногда придется
довольствоваться информацией не первой свежести. В то же время режим Direct-
Query обеспечивает полную гарантию актуальности извлекаемых данных и позво-
ляет оперировать объемами информации, превышающими ограничения, принятые
в Power BI. Но взамен вам придется пожертвовать скоростью выполнения запросов,
да и хранилище в источнике, вероятно, придется подвергнуть оптимизации.
Давайте перечислим сценарии, в которых вы могли бы остановить свой

выбор на режиме DirectQuery:
огромный объем исходных данных: размер набора данных, публи-
куемого в рабочей области в рамках емкости Power BI Premium, не
может превышать 10 Гб. В общей емкости размер ограничен 1 Гб. Эти

ограничения относятся к файлу Power BI Desktop (.pbix), публикуемому
в службе Power BI, хотя наборы данных Premium зачастую сильно пре-
восходят по объему заявленные лимиты. Если это ваш случай, вы не
сможете разместить все свои данные в службе и регулярно их обнов-
лять. У режима DirectQuery тоже есть свое ограничение, выражающееся
в 1 млн строк на запрос. Но вам не стоит сильно беспокоиться по этому
поводу, поскольку трудно представить, зачем вам мог бы понадобиться
столь огромный набор неагрегированных данных в отчете;
доступ к источнику в реальном времени: если ваша бизнес-зада-
ча предусматривает получение актуальных данных в каждом запросе,
единственным вариантом для вас будет DirectQuery;
большие инвестиции в существующие платформы данных: бы-
вает, что компания осуществляет существенные вложения в инфра-
структуру, например в хранилища данных (data warehouse) или витрины
данных (data mart) с централизованной базой данных. Информация
в таких системах может быть очищена и идеально оптимизирована
для получения аналитических отчетов, а сами системы используются
в компании в качестве единственного источника истины (single source
of truth). К таким источникам зачастую обращаются за данными из
разных аналитических инструментов, и ожидается, что во всех будет
одинаковая актуальная информация. В подобных условиях лучше ис-
пользовать режим DirectQuery, чтобы не оперировать устаревшей ин-
формацией в наборах данных Power BI;
регулирующие и нормативные требования: в отношении географи-
ческого места хранения информации могут применяться определен-
ные законы и положения в компании. Обычно в этом случае применя-
ется термин суверенность данных (data sovereignty). Если по причине
этих требований вы не можете физически переместить данные в Po
wer BI, остается использовать для доступа к ним режим DirectQuery.
Как и в случае с режимом Import, режим DirectQuery также можно опреде-
ленным образом оптимизировать, о чем мы подробно поговорим в главе 3.
Теперь, когда вы узнали все преимущества и недостатки обоих режимов,
полезно будет объединить вместе вопросы, ответами на которые необходимо
руководствоваться при выборе:
какой у вас объем данных и как он предположительно будет расти?
насколько эффективно можно сжать ваши данные в источнике?
достаточно ли будет перейти на лицензию Premium, чтобы разместить
в режиме Import все нужные данные?
можно ли удовлетвориться внедрением смешанной архитектуры?
О составных моделях читайте далее.
Составные модели
Power BI не ограничивает вас выбором единственного режима (Import или
DirectQuery) для одного набора данных или файла .pbix. Вместо этого до-
пустимо сочетать одну или несколько таблиц в режиме Import с одной или
несколькими таблицами в режиме DirectQuery. Такой совмещенный подход
получил название составная модель (composite model). При выборе составной
модели таблицы, хранящиеся в режиме Import и DirectQuery, могут быть оп-
тимизированы так же точно, как и при использовании одного из этих режи-
мов. В то же время при совместном использовании с агрегатами, о которых
мы подробно поговорим в главе 10, составная модель позволит вам найти
нужный баланс между быстродействием отчетов, актуальностью информа-
ции, размером набора данных и временем его обновления.
Режим LiveConnect
В режиме LiveConnect отчет будет отправлять запросы по требованию к внеш-
нему набору данных Analysis Services. В этом отношении он похож на режим
DirectQuery, поскольку Power BI не хранит информацию в локальном наборе
данных. Отличие состоит в том, что режим LiveConnect можно использовать
только при работе с Analysis Services. При этом нельзя производить модели-
рование данных и добавлять вычисления DAX. Отчет Power BI будет посылать
нативные запросы DAX к внешнему источнику данных. Режим LiveConnect
можно использовать в приведенных ниже сценариях:
создание отчетов из наборов данных, доступных в рабочей области
Power BI, в Power BI Desktop или Power BI Web;
ваша компания инвестировала средства в Azure Analysis Services или
SQL Server Analysis Services и использует этот источник в качестве ос-
новного для отчетов Power BI. Основные причины для выбора здесь
режима LiveConnect следующие:
a) вам нужен полный контроль за секциями, временем обновления
данных, масштабированием и разделением нагрузки по запросам
и обновлениям;
b) интеграция с CI/CD (непрерывная интеграция и непрерывная по-
ставка) и другими конвейерами автоматизации;
c) требования детализированного контроля и диагностики Analysis
Services;
d) размер изначального набора данных не укладывается в ограниче-
ния емкости Premium.
На рис. 2.4 показан сценарий с использованием режима LiveConnect.
Подключения к Analysis Services также поддерживают режим Import, при котором

данные физически копируются и актуализируются в процессе запуска обновления.
Внешний набор данных Analysis Services может находиться в режиме Import, так что
вам следует подумать, является ли режим LiveConnect действительно оптимальным
для получения актуальных данных. Режим Import может быть правильным выбором,
если вы просто строите таблицы поиска для небольшой витрины данных или времен-
ного анализа (например, это может быть список товаров или клиентов).
Извлечение локальных данных с помощью шлюза  39
Azure
Analysis Services
Конечные пользователи
Отчеты
Power BI
Desktop Analysis Services
(на базе Служба Power BI
Power BI)
Шлюз
Локальный
SQL Server Analysis Services
Рис. 2.4  Сценарий LiveConnect
Способ подключения отчета к источнику данных зависит от того, где за-

пущен отчет. Допустим, подключение из Power BI Desktop в офисе может
выполняться совсем по другому маршруту в сравнении со службой Power BI,
когда пользователь использует портал Power BI Web или мобильное прило-
жение. Если организации необходимо обезопасить и получить контроль за
подключениями из Power BI к локальным источникам данных (находящимся
не в облаке), то производят развертывание шлюза. В следующем разделе мы
подробно поговорим о назначении шлюза, его роли в оптимизации архитек-
туры данных и способах извлечения из него максимума возможного.
Извлечение локальных данных с помощью

шлюза
Локальный шлюз данных (on-premises data gateway) обеспечивает безопасное
соединение между локальными источниками данных и различными служба-
ми Microsoft, включая Power BI. Также в список этих продуктов входят Power
Apps, Power Automate, Azure Analysis Services и Azure Logic Apps. Шлюзы
позволяют организациям сохранять конфиденциальные источники данных
внутри сети и управлять доступом к ним со стороны Power BI и пользова-
телей. Шлюз доступен как в версии для организаций, так и в персональном
варианте. В этом разделе мы сосредоточимся на шлюзе для организаций.
При повышенной нагрузке на шлюз или недостатке выделенных ресурсов
обычно страдает быстродействие формирования и интерактивного взаимо-
действия пользователей с отчетами. Нагруженный шлюз может быть не в со-
стоянии создавать новые подключения, что способно приводить к отказам
запросов и возвращению пустых визуальных элементов в отчетах. Хуже того,
естественной реакцией пользователей в таких ситуациях является попытка

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

Зачастую под шлюзом ошибочно понимают исключительно сетевой компо-
нент, используемый для канализирования данных. И хотя он действительно
является составной частью конвейера данных, его функции не ограничи-
ваются только передачей информации. Шлюз содержит движок обработ-
ки (Mashup Engine) данных и поддерживает режимы Import, DirectQuery
и LiveConnect. Служба шлюза должна быть установлена на физическом или
виртуальном сервере. Важно понимать, что шлюз запускает запросы Power
Query/M при необходимости, выполняя обработку локально на своей ма-
шине. В дополнение шлюз также сжимает, а затем шифрует потоки данных,
направляемые службе Power BI. Это позволяет минимизировать объем дан-
ных, пересылаемых в облако, что положительно сказывается на времени
обновления и выполнения запросов. Вместе с тем такой широкий спектр
поддерживаемых подключений и объем выполняемых задач предполагает
выделение приличных ресурсов с возможностью масштабирования для ма-
шин, на которых запущен шлюз.
Облачные службы
Power BI Power Apps Microsoft Flow Azure Analysis Services Azure Logic apps
Локальный шлюз (преобразовывает,

сжимает и шифрует потоки данных,
передаваемые в облако Microsoft)
Рис. 2.5  Шлюз выполняет обработку данных локально
Предпосылки для оптимальной работы шлюза

При развертывании шлюза необходимо следовать определенным правилам.
Мы перечислим их все и объясним, почему так важно их выполнять:
размещайте шлюз как можно ближе к источникам данных: вы
должны всегда пытаться устанавливать шлюз на сервер, располага-
ющийся близко к вашим источникам данных. Физическая дистанция
увеличивает сетевую задержку, поскольку данным приходится пре-

одолевать большее расстояние и в процессе проходить через большее
количество промежуточных узлов. Каждый прыжок (hop) между узлами
увеличивает общее время передачи информации, особенно в условиях
нагруженной сети. Таким образом, мы должны делать все возможное
для минимизации физического расстояния между серверами и коли-
чества прыжков. Это также означает, что по возможности лучше разме-
щать шлюз в той же сети, где находятся источники, и тщательно прове-
рить быстродействие самой сети. Если ваши источники располагаются
на виртуальных машинах (virtual machines), старайтесь размещать их
в домашнем регионе Power BI;
откажитесь от регулирования количества запросов в сети: некото-
рые брандмауэры (firewalls) или прокси-серверы могут быть настроены
на регулирование сетевых подключений с целью оптимизации про-
пускной способности сети. Это может приводить к замедлению пере-
дачи данных через шлюз, так что лучше сразу разобраться с этим со-
вместно с администраторами сети;
избегайте запуска сторонних приложений и служб на сервере со
шлюзом: это поможет гарантировать, что нагрузка от других прило-
жений не будет негативно сказываться на запросах и пользователях.
В процессе разработки проекта на это можно не обращать внимания;
разделяйте шлюзы с подключениями DirectQuery и запланиро-
ванными обновлениями: подключения в режиме Import будут задей-
ствоваться только во время операций обновления данных, и зачастую
это происходит в нерабочее время, на которое и планируется выполне-
ние актуализации данных. Поскольку эти операции обычно содержат
действия по преобразованию данных в Power Query/M, они требуют не-
мало ресурсов центрального процессора и памяти, особенно если рабо-
та производится с объемным набором данных. В главе 8 мы подробно
поговорим об оптимизации преобразований с использованием Power
Query/M. Что касается подключений в режиме DirectQuery, здесь шлюз
по большей части выступает как проводник результатов запросов из
источников данных. В связи с этим подключения DirectQuery обычно
отнимают меньше ресурсов по сравнению с Import. Однако, поскольку
владельцы наборов данных могут выполнять операции преобразова-
ния и различные вычисления применительно к данным в режиме Di-
rectQuery, ресурсы процессора временами могут использоваться доста-
точно интенсивно. Развертывание нескольких шлюзов, некоторые из
которых отводятся под подключения DirectQuery, а другие – для работы
с обновлениями, позволит вам более предсказуемо распределить на-
грузку между ними. Это, в свою очередь, снизит вероятность появления
задержек у пользователей во время формирования отчетов;
используйте достаточно объемное и быстрое локальное храни-
лище: сервер со шлюзом буферизирует данные на диске перед их от-
правкой в облако. Они сохраняются в папке %LOCALAPPDATA%\Microsoft\
On-premises data gateway\Spooler. Если вы параллельно обновляете боль-
шие наборы данных, вы должны убедиться, что у вас на сервере есть
достаточно свободного места для их размещения. Мы настоятельно

рекомендуем использовать высокоскоростные конфигурации серверов
с твердотельными накопителями, чтобы хранилище не стало узким
местом системы;
используйте настройки параллелизма для шлюза: шлюз автома-
тически установит оптимальные значения по умолчанию для парал-
лельных операций, исходя из количества доступных ядер процессора.
Мы рекомендуем следить за настройками шлюза и использовать ре-
комендации из следующего раздела относительно характеристик сер-
веров для определения оптимальной конфигурации. Для изменения
настроек параллелизма вам необходимо внести правки в конфигура-
ционный файл по адресу \Program Files\On-premises data gateway\Micro-
soft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config. Произведите
следующее изменение:
MashupDisableContainerAutoConfig = true
Теперь вы сможете менять показанные в табл. 2.1 свойства в конфигу-

рационном файле по своему усмотрению.
Таблица 2.1. Доступные настройки конфигурации шлюза

Настройка Описание
MashupDefaultPoolContainer- Максимальное количество одновременно запущенных контейнеров
MaxCount обработки, выполняющих обновления параллельно. Большинство
запросов используют для выполнения контейнеры обработки.
Рекомендуемая верхняя граница параметра вдвое превышает
количество ядер процессора на шлюзе. Если установить параметр
в единицу, запросы будут выполняться последовательно.
Это может быть полезно при работе с источниками данных, не
поддерживающими корректно параллельное выполнение запросов
MashupDQPoolContainerMaxCount Максимальное количество одновременно запущенных контейнеров
обработки запросов DirectQuery
MashupDQPoolContainerMax Максимальный «рабочий набор» памяти, выделяемый для каждого
WorkingSetInMB контейнера обработки запросов DirectQuery
MashupTestConnectionPool Максимальное количество контейнеров обработки для тестовых
ContainerMaxInstanceCount подключений
MashupAzureConnectorsCaching- Максимальное количество контейнеров обработки для LogicApps,
PoolContainerMaxCount Power Apps и Power Automate
MashupAzureConnectorsCaching- Максимальный «рабочий набор» памяти, выделяемый для каждого
PoolContainerMaxWorkingSetInMB контейнера обработки LogicApps, Power Apps и Power Automate
Технические характеристики шлюза

В большинстве случаев компании начинают с одного сервера с установлен-
ным шлюзом, после чего по мере необходимости проводят вертикальное
и/или горизонтальное масштабирование выделенных ресурсов. В этом от-
ношении очень важно следовать минимальной спецификации от Microsoft
для шлюзов в готовых решениях. На момент написания книги Microsoft ре-
комендовала выделить под шлюз сервер с минимальным количеством ядер
процессора, равным восьми, 8 Гб оперативной памяти и сетевыми адапте-

рами на несколько гигабит. При этом мы настоятельно советуем проводить
постоянный и тщательный мониторинг для понимания того, какие аспекты
сервера подвергаются наибольшей нагрузке. Процесс отслеживания важных
показателей мы опишем далее в этой главе.
К сожалению, не существует единой формулы, применимой к любому
шлюзу в отношении выделяемых ресурсов. Однако при должном монито-
ринге и использовании соответствующих инструментов вы сможете понять
текущие требования в плане технических характеристик серверов и перспек-
тивы для их масштабирования.
Вы уже знаете, что шлюз поддерживает различные типы подключений,
которые вкупе с их количеством определяют необходимый объем ресурсов,
выделяемых для комфортной работы. При планировании развертывания
шлюза вы должны задать себе следующие вопросы, ответы на которые по-
могут правильно распределить ресурсы:
обновление какого количества наборов данных одновременно должен
поддерживать ваш шлюз?
какой объем данных будет перемещаться в процессе обновления?
будут ли во время обновлений выполняться сложные преобразования
данных?
какое количество пользователей будет параллельно обращаться к ис-
точникам DirectQuery и LiveConnect?
какое количество визуальных элементов будет располагаться в наи-
более часто используемых отчетах DirectQuery/LiveConnect? Каждый
визуальный элемент на основе данных будет генерировать как мини-
мум один запрос к источнику;
в каком количестве отчетов будет использоваться опция автомати-
ческого обновления страниц (Automatic Page Refresh) и какую частоту
обновлений планируется использовать?
В следующем разделе вы узнаете, как проводить мониторинг работы шлю-
за и собирать данные о нем для потенциального использования при масшта-
бировании.
Настройка ведения логов в шлюзе

В локальном шлюзе опция ведения логов включена по умолчанию. При этом
в системе ведется два типа логов: по выполнению запросов и по системным
счетчикам (system counter). Каждый из этих логов может быть деактивирован
при помощи соответствующего свойства value в конфигурационном файле
шлюза. Ниже показаны установки для ведения логов по умолчанию:
<setting name="DisableQueryExecutionReport" serializeAs="String">
<value>False</value>
</setting>
<setting name="DisableSystemCounterReport" serializeAs="String">
<value>False</value>
</setting>
Далее приведем перечень других параметров, которые можно настраивать

в этом файле:
ReportFilePath: путь хранения файлов с логами. По умолчанию этот
путь ведет либо к папке \Users\PBIEgwService\AppData\Local\Microsoft\
On-premises data gateway\Report, либо к \Windows\ServiceProfiles\PBIEg-
wService\AppData\Local\Microsoft\On-premises data gateway\Report. Путь
зависит от операционной системы. Если вы используете другой акка-
унт для шлюза, соответствующим образом измените путь;
ReportFileCount: шлюз разделяет файлы логов при достижении ими
предопределенного размера. Это облегчает анализ и разбор нужных
временных отрезков. Параметр ReportFileCount определяет количество
файлов с логами каждого типа, которые должны сохраняться. Значение
параметра по умолчанию – 10. При превышении этого порога более
старые файлы будут удалены;
ReportFileSizeInBytes: этим параметром определяется максималь-
ный объем файлов с логами. Значение параметра по умолчанию –
104 857 600 (100 Мб). Временные отрезки, охватываемые в каждом
файле, могут отличаться в зависимости от активности в эти периоды;
QueryExecutionAggregationTimeInMinutes: метрики выполнения за-
просов хранятся в агрегированном виде. Этот параметр определяет
количество минут, за которое выполняется агрегация. Значение по
умолчанию – 5;
SystemCounterAggregationTimeInMinutes: метрики системных счет-
чиков также агрегируются перед сохранением. И этот параметр, как
и предыдущий, отвечает за интервал агрегации в минутах. Значение
по умолчанию – 5.
Включив логирование, вы будете получать собранную информацию о рабо-
те системы в виде четырех наборов файлов с расширением .log и числовыми
окончаниями в именах. Ниже приведены названия всех четырех групп логов:
QueryExecutionReport: в этих файлах хранится детальная информа-
ция по каждому выполненному запросу. Здесь вы можете узнать, за-
вершился ли запрос успешно, получить информацию об источнике
данных, типе запроса, времени его выполнения и обработки данных,
времени записи на диск, объеме записанных данных и средней ско-
рости операций по работе с диском. Эти сведения могут помочь при
поиске узких мест в системе;
QueryStartReport: в этих упрощенных логах содержится информация
о тексте запросов, источниках данных и времени запуска запроса.
Здесь вы можете увидеть запрос, который на самом деле был послан
источнику. Это может быть полезно при решении проблем с быстро-
действием и особенно касается источников данных в режиме Direc-
tQuery. В главе 3 мы подробно поговорим о способах оптимизации
систем с использованием режима DirectQuery;
QueryExecutionAggregationReport: файлы из этой группы содержат
агрегированную информацию о запросах с интервалом, по умолчанию
установленным в пять минут. В них представлены такие важные данные,
как количество запросов за временной период, среднее, максимальное

и минимальное время выполнения запросов и обработки данных;
SystemCounterAggregationReport: здесь хранится агрегированная ин-
формация о системных ресурсах сервера, на котором установлен шлюз.
Среди прочего в этих файлах представлены данные о среднем, макси-
мальном и минимальном расходе ресурсов центрального процессора
и памяти для сервера, службы шлюза и движка обработки.
После внесения изменений в конфигурационный файл требуется перезапустить

шлюз. Новые записи в логах появятся в течение 10 минут плюс время из параметра
QueryAggregationTimeInMinutes.
Анализ и моделирование логов шлюза

Компания Microsoft предоставляет базовый шаблон отчета Power BI для ана-
лиза служебных данных от шлюза. Загрузить этот шаблон можно по адресу
https://download.microsoft.com/download/D/A/1/DA1FDDB8-6DA8-4F50-B4D0-
18019591E182/GatewayPerformanceMonitoring.pbit.
При открытии файла он сканирует папку с логами шлюза и обрабатывает
все файлы с нужными именами. В результате анализа создается модель дан-
ных, показанная на рис. 2.6.
Рис. 2.6  Модель данных из шаблона Gateway Performance от Microsoft

На рис. 2.7 показан один из базовых наборов визуальных элементов из

этого шаблона.
Рис. 2.7  Пример визуализации в шаблоне Gateway Performance
Шаблон от Microsoft дает вам возможность наглядно увидеть разнообраз-

ную информацию по агрегированным и детализированным показателям
работы шлюза. Но чтобы воспользоваться им по максимуму, вам придется
внести некоторые изменения в преобразования, модель данных и сопут-
ствующие вычисления. Это может занять довольно много времени, так что
здесь вам, возможно, стоит рассмотреть готовые варианты. Если у вашей
компании есть подписка на поддержку от Microsoft (Premier Support или Uni-
fied Support), то вы можете воспользоваться услугой оценки эффективности
вашего решения. Она проводится силами опытных инженеров при помощи
продвинутых шаблонов для анализа логов шлюза. Также вы можете нанять
сторонних консультантов с соответствующим опытом. Поиск таких предло-
жений в интернете позволит вам оценить все за и против.
Если же вы решили построить свой собственный шаблон на базе имеюще-
гося решения от Microsoft, вот несколько советов:
автоматизируйте процесс извлечения и хранения логов с сервера шлю-
за, например при помощи PowerShell;
создайте отдельные измерения для даты и времени и свяжите их со
всеми таблицами логов, чтобы можно было строить отчеты по всем
событиям с учетом временной корреляции;
создайте общие измерения для статуса запроса (Query Status), типа
запроса (Query Type) и источника данных (Data Source) и свяжите их
с остальными таблицами в модели. Это позволит вам использовать

одинаковые фильтры и срезы во всех отчетах;
добавьте измерение с детализированной информацией обо всех ва-
ших шлюзах, включая окружение, идентификатор, имя, объем памяти
и количество ядер процессора. Используйте идентификатор шлюза для
связи с таблицами фактов и логами;
создайте отчеты и элементы визуализации с отражением трендов
и агрегатов для анализа пиков загруженности памяти и процессора
в разрезе запросов DirectQuery и обновлений. Больше информации мы
дадим в следующем разделе.
Теперь посмотрим, на какие вопросы могут ответить сохраненные логи.
Анализ логов шлюза

Мы полагаем, что даже имеющиеся шаблоны визуализации данных из логов
шлюза позволят вам ответить на общие вопросы и быстро идентифициро-
вать проблемные области. Ниже перечислены основные вопросы, на которые
вам необходимо получить ответы:
есть ли в загрузке шлюза какие-то явно выраженные пики и с какой
периодичностью они появляются?
как выглядит шаблон нагрузки при достижении максимального уровня
использования ресурсов?
какие наборы данных, потоки данных или отчеты потребляют большую
часть ресурсов шлюза?
какова пропускная способностью шлюза в пересчете на запросы в се-
кунду и обработанные байты в секунду?
какие операции были запущены в моменты обнаружения критических
падений пропускной способности шлюза и какие из них потребляли
больше всего ресурсов?
много ли операций DirectQuery и обновлений выполняется на шлюзе
одновременно? Если да, это может приводить к серьезным нагрузкам
на центральный процессор и память, и в этом случае стоит рассмотреть
варианты с разнесением шлюзов DirectQuery и обновлений по разным
серверам, другим распределением операций обновлений или проведе-
нием масштабирования;
какова средняя продолжительность выполнения запросов и что глав-
ным образом влияет на ее рост: ограничения ресурсов или увеличение
объемов данных/сложности запросов?
какие запросы выполняются дольше всего? Они каждый раз выполня-
ются медленно или скорость меняется с течением времени? В первом
случае вам необходимо обратить внимание на сам запрос и модель
данных – если здесь все в порядке, то стоит выполнить оптимизацию
источника данных или сетевого соединения. Во втором случае при-
дется разбираться с непредсказуемыми пиками нагрузки шлюза или
источника данных.
Вернитесь к разделу «Технические характеристики шлюза» и повторите вопросы, ко-
торыми стоит задаваться при выборе мощностей. Проверьте, как ваши ответы соот-
носятся с вопросами, перечисленными выше. Это поможет вам составить технический
план и лучше понять, на какие характеристики шлюза необходимо ориентироваться
в ваших условиях.
Далее мы узнаем, когда стоит задумываться о проведении масштабирова-

ния шлюза и каких видов оно бывает.
Масштабирование шлюза
Иногда бывает, что даже при должном мониторинге и управлении шлюзом
вы упираетесь в его естественные ограничения по причине роста объема
данных или интенсивности их использования. В таких ситуациях стоит за-
думаться о проведении масштабирования (scaling) шлюза, заключающегося
в выделении дополнительных ресурсов или замене старых на более быстрые.
О необходимости масштабирования ресурсов могут говорить цифры, полу-
ченные в результате анализа производительности системы, а именно об
использовании процессора, памяти и дискового пространства. Оптимиза-
цию невозможно проводить до бесконечности, и иногда вы все же будете
упираться в физические ограничения, что должно стать для вас сигналом
к рассмотрению вариантов, связанных с масштабированием.
Предположим, с оптимизацией решения у вас полный порядок, но вы все
равно замечаете проблемы с быстродействием, вызванные повышением на-
грузки. Вашим первым выбором должно стать вертикальное масштабирова-
ние (scale up) ресурсов. Вы можете увеличить количество ядер центрального
процессора и объем памяти независимо друг от друга, если результаты ваше-
го анализа показывают, что проблема только в одном аспекте, а в остальных
все в порядке. Хотя процессор и память – это первое, о чем стоит задуматься
при вертикальном масштабировании, не стоит забывать также о доступном
месте на диске и пропускной способности сети. Эти компоненты также могут
быть масштабированы вертикально, но может потребоваться и горизонталь-
ное масштабирование.
Горизонтальное масштабирование с увеличением

количества шлюзов
При достижении предела вертикального масштабирования сервера, на ко-
тором развернут шлюз, вы можете задуматься о создании кластера шлюзов
(gateway cluster). Это позволит распределить нагрузку между несколькими
физическими серверами. Кроме того, кластер способен справляться с ра-
бочими задачами в одиночку в случае отказа соседнего сервера по той или
иной причине.
Для создания кластера вам необходимо просто запустить установщик
шлюза на другом сервере. В процессе установки вам будет предложено под-
ключить шлюз к уже существующему шлюзу, который будет выступать в ка-
честве основного экземпляра кластера. Окно с соответствующим выбором
показано на рис. 2.8.
Рис. 2.8  Добавление шлюза к кластеру путем выбора основного экземпляра
Все запросы изначально поступают на основной экземпляр шлюза в клас

тере. На другие шлюзы запросы могут перенаправляться только в случае
перехода основного в режим офлайн.
Если один из серверов вышел из строя, вы можете удалить его из кластера при по
мощи команды PowerShell Remove-OnPremisesDataGateway. Если этого не сделать, за-
просы продолжат поступать на этот шлюз, что может негативно сказываться на про-
изводительности всего кластера.
По умолчанию распределение нагрузки по шлюзам в кластере производит-

ся случайным образом. Но вы всегда можете повлиять на это распределение,
чтобы оно выполнялось исходя из пороговых значений нагрузки на память
и процессор. Таким образом, если один шлюз достигнет своих пороговых
значений нагрузки, ему на помощь будет выделен соседний сервер из клас
тера. В результате запрос получит отказ только в случае, если все шлюзы из
кластера работают на пределе нагрузки.
При необходимости администратор шлюза должен внести соответству-
ющие изменения в конфигурационный файл, располагающийся по адресу
\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipe-
line.GatewayCore.dll.config.
Для регулирования распределения нагрузки между шлюзами в указанном
файле предусмотрены следующие параметры:
CPUUtilizationPercentageThreshold: значение в интервале от 0 до 100,

устанавливающее ограничение нагрузки на центральный процессор.
Ноль означает отсутствие ограничения;
MemoryUtilizationPercentageThreshold: аналогичный параметр для па-
мяти;
ResourceUtilizationAggregationPeriodInMinutes: временной отрезок
в минутах, за который будет выполняться агрегирование системных
счетчиков по процессору и памяти на данном сервере. Именно эти
агрегаты сравниваются с пороговыми значениями, описанными выше.
Значение по умолчанию – 5.
Теперь, когда вы достаточно узнали о режимах хранения данных и возмож-
ных вариантах оптимизации шлюза, пришло время обсудить более общие
факторы, которые способны негативно влиять на быстродействие системы.
Общая инструкция по архитектуре

В этом разделе мы дадим несколько важных советов, которые помогут вам
оптимизировать производительность вашего решения на базе Power BI.
Планирование расписания обновлений

Зачастую вопросу актуальности источника данных в режиме Import уделя-
ется недостаточно внимания. Нет никакого смысла обновлять набор данных
несколько раз в день, если он основывается на информации из стороннего
хранилища, данные в котором обновляются один раз ночью. Это накладыва-
ет дополнительную нагрузку на источник данных и службу Power BI.
Проанализируйте свое рабочее окружение и понаблюдайте за тем, ког-
да у вас выполняются операции обновления и как долго они длятся. Если
несколько таких операций запускаются параллельно, это может негативно
сказываться на других конкурентных вычислениях из-за разделения ресур-
сов памяти и процессора. И этот эффект может усугубляться при наличии
лицензии Power BI Premium. Переговорите с владельцами датасетов на пред-
мет частоты обновления наборов данных и разнесения этих операций во
времени, чтобы они не выполнялись одновременно. Процесс обновления
набора данных может требовать столько же памяти, сколько и сам датасет,
а в случае наличия сложных или неэффективных преобразований – еще боль-
ше. В общем смысле принято считать, что на обновление может выделяться
вдвое больше памяти по сравнению с объемом данных.
Снижение сетевой задержки

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

и других служб, по крайней мере в рабочем окружении. К примеру,
если вы используете Azure, рекомендуется устанавливать в качестве
региона ваш домашний регион из Power BI;
рассмотрите вариант создания облачной реплики (cloud replica) своих
локальных источников данных. Это может привести к некоторым об-
лачным накладным расходам, но позволит значительно снизить за-
держку для Power BI, если облако располагается далеко от локального
дата-центра;
если ваши данные располагаются в облаке, рассмотрите вариант ве-
дения разработки посредством удаленного рабочего стола на вирту-
альных машинах в облаке. В идеале эти виртуальные машины должны
располагаться в одном регионе с источниками данных;
используйте Azure ExpressRoute для осуществления безопасного вы-
деленного высокоскоростного подключения из локальной сети к Azure
Cloud.
Теперь, когда вы понимаете, какие архитектурные решения, оказываю-
щие влияние на быстродействие, вы можете принимать, давайте подведем
некоторые итоги, после чего перейдем к следующей области оптимизации
Power BI.
Из этой главы вы узнали, как работают два режима хранения данных в Po
wer BI. Наборы данных в режиме Import полностью кешируются в памяти,
тогда как режим DirectQuery позволяет оставить данные физически на сто-
роне источника и подключаться к ним при каждом выполнении запросов.
В целом режим Import является более быстрым, поскольку данные фактиче-
ски извлекаются из локальной колоночной базы данных, в которой к тому
же реализовано сжатие. В то же время режим DirectQuery гарантирует по-
лучение актуальной информации из источника и не предусматривает на-
личия операций обновления данных. К тому же при использовании этого
режима вы можете работать с данными гораздо большего объема по срав-
нению с ограничениями, имеющимися в лицензии Power BI Premium. Таким
образом, у каждого из двух режимов есть свои преимущества и недостатки.
В дополнение к режимам Import и DirectQuery в Power BI реализована также
составная модель, сочетающая в себе плюсы обоих режимов.
Кроме того, в этой главе мы поговорили о шлюзах, позволяющих Power BI
безопасно подключаться к локальным источникам данных. При этом шлюз
используется не просто как путепровод для информации, а содержит движок
обработки, позволяющий локально выполнить необходимые преобразова-
ния данных. Эта операция может потребовать больших ресурсов, особенно
если с системой одновременно работают сотни или тысячи пользователей,
что порождает огромное количество параллельных подключений. Все это
ведет к необходимости тщательно мониторить работу шлюза, поддерживать
его ресурсы на должном уровне и своевременно проводить масштабирова-

ние. Мы в этой главе сформулировали важнейшие вопросы, ответы на кото-
рые помогут вам определиться со стратегией управления шлюзами. При этом
ответы могут быть получены на основе логов, процесс анализа которых мы
также описали. Был продемонстрирован шаблон анализа, подготовленный
для этих целей компанией Microsoft, и рассмотрены способы его улучшения.
Попутно мы рассказали, на какие шаблоны стоит обращать внимание при
разборе логов и какие вопросы рассматривать для улучшения корреляции
данных. Это поможет определиться со стратегией масштабирования шлю-
зов – когда проводить вертикальное масштабирование путем увеличения
ресурсов шлюза, а когда – горизонтальное, расширяя количество шлюзов
с образованием кластеров и балансируя нагрузку между ними.
После этого мы поговорили о важности планирования обновлений для
предотвращения слишком большой параллельной активности. Наконец, мы
обсудили дополнительные варианты снижения объема данных и сетевой за-
держки для тестовых и рабочих окружений.
В следующей главе мы продолжим говорить о режимах хранения данных
и сконцентрируемся на оптимизации моделей DirectQuery. Инструкции бу-
дут даны как для наборов данных Power BI, так и для внешних источников
данных.
Глава 3
Оптимизация
DirectQuery
До этого момента мы рассуждали о производительности Power BI довольно

укрупненно. Мы узнали, какие аспекты Power BI могут быть затронуты в ре-
зультате принятия нами каких-то решений и какие факторы необходимо
учитывать при их принятии. Эти решения носили скорее архитектурный
характер и касались в основном выбора правильных компонентов для обес
печения наиболее эффективного потока данных в соответствии с вашими
объемами и требованиями к актуальности информации.
Однако одного этого знания недостаточно для гарантии высокой произво-
дительности системы. В предыдущей главе на примере шлюза мы увидели,
как можно сконфигурировать и оптимизировать один компонент решения.
Это же применимо и ко всем остальным компонентам Power BI, и сейчас мы
начнем разбираться в том, как те или иные решения в разных областях могут
повлиять на быстродействие системы и каких действий стоит избегать.
В главе 2 мы познакомились с режимами наборов данных, применяемы-
ми в Power BI: Import и DirectQuery. Сейчас мы подробнее рассмотрим вто-
рой из них – DirectQuery. Отчеты Power BI генерируют запросы, которые
выполняются параллельно. При этом каждое взаимодействие пользователя
с отчетом способно инициировать выполнение сразу нескольких запросов,
а с отчетами DirectQuery, использующими одни и те же источники данных,
могут работать сразу несколько пользователей. И при построении моделей
с режимом хранения DirectQuery критически важно учитывать возможность
отправки многочисленных запросов к внешним источникам.
Мы рассмотрим особенности моделирования данных в режиме Direct-
Query, которые помогут снизить нагрузку на внешние источники. Также мы
реализуем меры по снижению объемов обработки данных. Узнаем, какие
настройки существуют для реализации параллелизма в DirectQuery. Кроме
того, обсудим варианты оптимизации внешних источников данных с целью
снижения объема передаваемой по сети информации.
моделирование данных для режима DirectQuery;
настройки быстродействия режима DirectQuery.
54  Оптимизация DirectQuery
Моделирование данных для режима

DirectQuery
Моделирование данных (data modeling) в общем виде сводится к определению
того, какие атрибуты данных будут объединены в таблицы и как эти таблицы
должны быть связаны друг с другом. Построение модели данных (data model)
DirectQuery в Power BI позволяет загрузить метаданные таблиц и связи из ис-
точника данных. При необходимости вы можете определить свои собствен-
ные связи и вычисления для нужных вам таблиц и столбцов.
Вычисления, сделанные в модели DirectQuery, преобразуются во внешние
запросы, которые должен обрабатывать источник. Вы можете посмотреть
созданные запросы в редакторе Power Query (Power Query Editor), щелкнув
правой кнопкой мыши на нужном шаге и выбрав пункт Просмотреть ма-
шинный запрос (View Native Query), как показано на рис. 3.1.
Рис. 3.1  Просмотр сгенерированного запроса к источнику

Моделирование данных для режима DirectQuery  55
В открывшемся окне вы можете изучить, как Power BI переводит написан-

ные вами вычисления на родной язык источника и есть ли предпосылки для
их оптимизации. На рис. 3.2 показан запрос к таблице с одним добавленным
вычислением, вычитающим значение одного числового поля из другого.
Рис. 3.2  Родной для SQL Server запрос на языке T-SQL

с пользовательским вычислением
Работая в режиме DirectQuery, не усложняйте без необходимости вычисления, чтобы

не затруднять жизнь источнику данных. Старайтесь ограничиваться в мерах функция
ми суммирования, подсчета количества элементов, а также минимума, максимума
и среднего значения. Для начала проанализируйте на предмет производительности
машинные запросы, созданные по умолчанию, после чего вносите дополнительные
изменения, особенно это касается функции CALCULATE.
Также необходимо помнить, что для создания виртуальной связи между

таблицами в модели данных Power BI нет необходимости в том, чтобы эти
таблицы были связаны физическим образом в источнике. Физические связи

создают инженеры данных с целью оптимизировать объединения таблиц
для общих шаблонов запросов, и мы в Power BI должны по возможности
пользоваться этим.
На рис. 3.3 показана простая модель данных DirectQuery в Power BI Desk-
top с произвольной связью между двумя измерениями (dimension): Person
и Product.
Рис. 3.3  Произвольная связь в DirectQuery
Мы создали такую тривиальную модель с единственной связью исключи-

тельно с целью демонстрации. Суть же в том, что в базе данных такие табли-
цы вряд ли будут объединены связью, и уж точно не по текстовым столбцам,
представляющим названия товаров и имена людей. Однако, создавая подоб-
ную связь в Power BI, мы просим источник данных или Power BI выполнить
это объединение. Очевидно, что подобная связь будет малоэффективной
из-за невозможности воспользоваться средствами оптимизации, реализо-
ванными в источнике.
Избегайте создания в режиме DirectQuery связей между таблицами и столбцами, по
которым в источнике данных не созданы физические связи и индексы. Если это неиз-
бежно, старайтесь, чтобы в таблицах – как минимум в одной из них – было не очень
много строк.
На показанном примере видно, что Power BI предлагает определенную

гибкость, использование которой может привести к непредвиденным по-
следствиям, если действовать не вполне осознанно. И таких моментов в сле-
дующих главах будет приведено довольно много.
Оптимизация связей для DirectQuery

Давайте продолжим говорить о физических связях в источнике данных.
С большой долей вероятности в вашем источнике есть колонки в таблицах,
представляющие первичные (Primary Key) и внешние ключи (Foreign Key),
а также есть ограничения (constraints) и индексы (indexes). На рис. 3.4 по-
казан простой пример из области розничной торговли, в котором таблица
с территориями торговли связана с таблицей заказов по полю TerritoryID.
Рис. 3.4  Типичная связь с измерением по числовому идентификатору
При наличии такой связи в источнике может быть налажена ссылочная

целостность (referential integrity) данных. Это означает, что таблица Sales-
Territory может быть объявлена основным списком торговых территорий,
и в каждой строке в таблице SalesOrderHeader должно быть заполнено со-
ответствующее поле TerritoryID. Таким образом, мы предполагаем, что ни
в одной из этих двух таблиц в поле TerritoryID не могут находиться пустые
значения. Это обычная практика для большинства СУБД, и для Power BI это
имеет огромное значение, поскольку при наличии ссылочной целостности
набор данных DirectQuery может генерировать гораздо более оптимальные
запросы.
В терминах баз данных наличие ссылочной целостности означает, что Po
wer BI может использовать оператор INNER JOIN вместо OUTER JOIN при из-
влечении данных из нескольких таблиц. Это допустимо при полной уверен-
ности в том, что применение более эффективного оператора INNER JOIN не
приведет к потере строк в одной из таблиц из-за отсутствия совпадений. Если
такая уверенность есть, вы можете дать Power BI соответствующее указание
в окне редактирования связи. На рис. 3.5 показано, где в Power BI Desktop не-
обходимо установить флажок, означающий наличие в источнике ссылочной
целостности для этой связи.
Рис. 3.5  Установка ссылочной целостности для связи DirectQuery
Еще одним удобством в Power BI является возможность создавать вычис-

ляемые столбцы (calculated columns), что работает и применительно к табли-
цам DirectQuery. Power BI поддерживает создание связей на основе одного
столбца из каждой таблицы. Но иногда нам требуется при моделировании
данных для уникальной идентификации сущности использовать комбина-
цию столбцов. Простейшая техника, используемая в подобных случаях, за-
ключается в создании вычисляемого столбца с конкатенацией значений из
нужных вам составных колонок. Далее этот столбец, представляющий собой
уникальный ключ, используется для построения связей с другими таблицами
в Power BI. При этом связи на основе вычисляемых столбцов значительно
уступают в эффективности связям на базе физических столбцов. И в случае
с режимом DirectQuery это вдвойне важно.
Избегайте использования связей на основе вычисляемых столбцов в режиме Direct
Query. Такое объединение нельзя будет напрямую передать в источник, и для него
потребуется выполнить дополнительные вычисления в Power BI. По возможности ис-
пользуйте функцию COMBINEVALUES() для создания связей по объединенным колонкам,
поскольку она отлично оптимизирована под режим DirectQuery.
Еще одним способом передачи этого вычисления в источник данных явля-

ется добавление пользовательского рассчитываемого столбца или материа
лизованного представления.
Также важными концепциями при обсуждении связей являются крат-
ность (Cardinality) и направление кросс-фильтрации (Cross filter direction),
выпадающие списки для которых видны на рис. 3.5. Выбор в качестве крат-
ности варианта многие ко многим (Many-to-many) сделает невозможным
установку флажка для ссылочной целостности и может привести к созданию
менее эффективных запросов, если в данных на самом деле поддержива-
ется кратность один ко многим. Также выбор варианта Оба (Both), кото-
рый иногда именуется двунаправленной связью (bidirectional relationship),
в выпадающем списке Направление кросс-фильтрации может привести
к созданию дополнительных запросов к источнику данных. Это происходит
из-за задействования большего количества таблиц в результате небольших
интерактивных взаимодействий с отчетами, таких как изменение значе-
ний в срезах, поскольку фильтрация должна распространяться по связям на
множество таблиц. Задумайтесь, нужны ли в вашем бизнес-сценарии двуна-
правленные связи.
Двунаправленные связи зачастую используют в отчетах с целью синхронизации зна-
чений в фильтре и срезе. Для достижения того же эффекта можно применить в срезе
фильтр по мере. Применительно к нашему сценарию с продажами мы могли бы ис-
пользовать эту технику для отображения в срезе только тех товаров, по которым были
продажи.
Последний совет, связанный с оптимизацией связей для режима Direct-

Query, будет относиться к использованию глобального уникального идентифи-
катора (Globally Unique Identifier – GUID) или немного измененного универ-
сального уникального идентификатора (Universally Unique Identifier – UUID).
Эти широко используемые идентификаторы состоят из 32 шестнадцатерич-
ных чисел и дефисов. Пример: 123e4567-e89b-12d3-a456-426614174000. Обычно
такие последовательности используются для уникальной идентификации
записей в хранилище данных и часто встречаются в продуктах и службах от
Microsoft.
Избегайте создания столбцов с уникальными идентификаторами в таком формате
при использовании режима DirectQuery. Power BI не поддерживает такой тип дан-
ных по умолчанию, что приводит к необходимости преобразовывать значения при
объединении таблиц. Рассмотрите вариант создания материализованного текстового
столбца или суррогатного целочисленного ключа в хранилище данных и используйте
эти поля при определении связей.
В следующем разделе мы рассмотрим некоторые настройки Power BI и оп-

тимизацию источника данных, которые должны пойти вам на пользу при
использовании режима DirectQuery.
Настройки быстродействия режима

DirectQuery
В Power BI предусмотрено несколько настроек, способных ускорить работу
наборов данных в режиме DirectQuery. И в этом разделе мы о них подробно
поговорим.
Настройки Power BI Desktop

В окне параметров и настроек Power BI Desktop есть секция с названием Па-
раметры опубликованного набора данных (Published dataset settings), по-
казанная на рис. 3.6. Пункт Максимальное число подключений на источ-
ник данных (Maximum connections per data source) в этой секции отвечает за
предельное количество параллельно открытых подключений в расчете на один
источник. Значение по умолчанию – 10. Это означает, что вне зависимости от
количества визуальных элементов в отчете и числа пользователей, работающих
с ним, больше десяти подключений одновременно открыто к нему не будет.
Рис. 3.6  Настройка максимального числа подключений на источник данных

Настройки быстродействия режима DirectQuery  61
Если источник данных способен обрабатывать больше подключений па-

раллельно, рекомендуется увеличить значение этого параметра перед пуб
ликацией набора данных в службе Power BI. И наоборот, при работе с пе-
регруженными источниками данных вы можете обнаружить, что более
комфортная работа будет обеспечиваться при уменьшении этого значения.
Причина этого в том, что параллельно запущенные запросы могут излиш-
не нагружать источник, в результате чего общее время обработки запросов
может вырасти. Снижение этого параметра будет означать, что некоторые
запросы будут вставать в очередь и исполняться позже, когда источник ос-
вободится, что снизит нагрузку на него.
В Power BI Desktop вы можете ввести большие значения для настройки максимально-

го числа подключений на источник данных. В то же время в службе Power BI есть свои
жесткие ограничения в этой области, зависящие от того, используете ли вы емкость
Premium и каков ее объем. Эти ограничения могут меняться, при этом публично они
не документированы. В связи с этим вы можете обратиться в поддержку Microsoft за
дополнительными разъяснениями применительно к вашему конкретному сценарию.
Также полезной секцией настроек в Power BI Desktop, помогающей оптими-

зировать работу в режиме DirectQuery, является секция Сокращение числа
запросов (Query reduction), показанная на рис. 3.7. С настройками по умолча-
нию Power BI будет посылать запросы к источнику всякий раз, когда пользова-
Рис. 3.7  Настройка сокращения числа запросов

тель меняет значение фильтра или среза в отчете. Это значительно повышает
эффект интерактивности, но может существенно снизить эффективность при
работе с загруженными или не оптимально настроенными источниками Direc-
tQuery, а также в случае большой сложности посылаемых на сервер запросов.
Это происходит из-за того, что источник может не успеть обработать одно
изменение визуального элемента пользователем к моменту, когда он уже из-
менил свой выбор. В результате количество запросов увеличивается.
Настройка снижения количества отправляемых на сервер запросов по-
зволяет добавить в секции фильтров и срезов кнопку Применить (Apply).
Таким образом, пользователь сможет выполнить сразу несколько изменений
настроек и отправить их на сервер вручную по готовности. На рис. 3.8 по-
казан фрагмент отчета со срезом и фильтром после применения настроек из
секции уменьшения числа отправляемых запросов.
Рис. 3.8  В отчет добавлены кнопки Применить (Apply)
Теперь посмотрим, как можно оптимизировать внешние источники дан-

ных для лучшей работы со сценариями DirectQuery.
Оптимизация внешних источников данных

Мы уже знаем, что наборы данных в режиме DirectQuery могут работать
медленнее по сравнению с режимом Import по причине того, что внешние
источники могут быть не оптимизированы для обработки запросов от систем
бизнес-аналитики.
Настройки быстродействия режима DirectQuery  63
Вне зависимости от того, какая СУБД установлена на внешнем источни-

ке, существуют общие требования и рекомендации, применимые к самым
разным хранилищам, которые могут помочь существенно ускорить процесс
обработки запросов от Power BI. Перечислим их ниже:
индексы: индексы позволяют движку баз данных быстро находить
нужные записи при использовании операций фильтрации и объеди-
нения. Рассмотрите возможность создания индексов по столбцам, ис-
пользующимся для связей в Power BI или задействованным в отчете
в качестве фильтров или срезов;
технология колоночного хранилища: использование современ-
ных хранилищ данных позволит вам создать специфические индексы
с применением колонок, а не привычных строк. Это поможет сущест
венно повысить эффективность запросов с агрегациями в Power BI.
Старайтесь определять индексы с использованием колонок, часто из-
влекаемых совместно в отчетах с агрегациями;
материализованные представления: материализованное представ-
ление (materialized view) – это по своей сути запрос, результаты которо-
го предварительно рассчитаны и сохранены как обычная таблица. При
изменении исходных данных материализованное представление тоже
обновляется для отражения актуальной информации. Вы можете пере-
нести операции преобразования в такое представление в источнике
данных вместо определения их в Power BI. Таким образом, в хранилище
уже будут присутствовать подготовленные данные для нужд Power BI.
Конечно, это больше применимо к информации, которая изменяется
не очень часто. При этом не забывайте, что хранение слишком боль-
шого количества материализованных представлений на сервере также
может привести к снижению его быстродействия по причине того, что
все эти данные необходимо поддерживать в актуальном состоянии, на
что расходуются ресурсы. Излишняя индексация также может иметь
обратный эффект и привести к замедлению работы источника;
базы данных в памяти: одной из причин высокой скорости работы на-
боров данных в режиме Import является то, что все данные для них хра-
нятся в быстрой оперативной памяти, а не на медленном диске. Режим
DirectQuery также имеет встроенные возможности для хранения дан-
ных в памяти, чем вы можете воспользоваться при работе с Power BI;
реплики для чтения: рассмотрите возможность создания реплики для
чтения (read-only replica) вашего источника для нужд Power BI. Она
может быть оптимизирована для доступа из Power BI независимо от
остального трафика сервера. Более того, эту реплику можно синхрони-
зировать с определенной периодичностью, если вам не нужны актуаль-
ные данные постоянно. Это позволит еще повысить быстродействие;
горизонтальное и вертикальное масштабирование: положительно
повлиять на быстродействие системы можно путем увеличения до-
ступных ресурсов сервера или расширения парка серверов в кластере,
которые смогут обрабатывать запросы параллельно. Последний вари-
ант применим при работе с большими данными;
поддержка статистики базы данных: некоторые СУБД используют
внутреннюю статистику с целью оптимизации выполнения запросов
путем выбора наиболее подходящего плана. Эта статистика должна

всегда поддерживаться в актуальном состоянии, чтобы оптимизатор не
строил свои догадки на основе устаревших данных о кратности столб-
цов и количестве строк.
Чтобы оптимально настроить работу внешних источников данных, необ-
ходимо понимать, какие именно запросы будут посылаться к ним со стороны
Power BI. В главе 4 мы научимся перехватывать эти запросы в Power BI. Также
с этой целью можно использовать ресурсы внешнего источника, и такая схе-
ма часто применяется в готовых рабочих системах, где отчеты публикуются
в службе Power BI.
Давайте подведем итоги того, что мы узнали о режиме хранения Direct-
Query в этой главе, после чего перейдем к знакомству с ключевыми показа-
телями производительности в Power BI.
В этой главе мы определили моделирование данных как процесс выбора
столбцов для группировки в таблицы и настройку связей между таблицами.
Мы узнали, что для оптимальной работы режима DirectQuery необходимо
стараться по максимуму упрощать вычисления на этапе преобразования
данных в Power Query, чтобы гарантировать их бесшовную трансформацию
в запросы на родном для источника данных языке. Попутно мы научились
просматривать эти итоговые запросы к источнику в редакторе Power Query
и увидели, как именно вычисления в Power BI преобразуются в запросы SQL.
После этого мы рассмотрели возможность объединения таблиц в режиме
DirectQuery непосредственно в Power BI даже в отсутствие соответствующих
связей в источнике данных. Эта опция должна использоваться с большой
осторожностью. В любом случае с точки зрения оптимизации всегда луч-
ше воспользоваться связями и ссылочной целостностью, определенными во
внешнем источнике, а не в Power BI, поскольку это обеспечит более эффек-
тивную фильтрацию и объединение исходных данных. Мы также упомянули
про дополнительные настройки для связей и рассказали об их влиянии на
наборы данных в режиме DirectQuery.
Затем мы обратились к параметрам и настройкам Power BI Desktop, с по-
мощью которых можно оказывать влияние на процесс осуществления па-
раллельных запросов к источнику данных. Также мы перечислили наиболее
распространенные приемы оптимизации, которые подойдут практически
ко всем источникам данных и помогут повысить эффективность моделей
DirectQuery. Эти приемы могут потребовать объединения усилий с админи-
страторами баз данных в источнике в процессе выбора наиболее оптималь-
ных решений для взаимодействия с Power BI.
В следующей главе мы погрузимся в мир показателей производитель-
ности, доступных в Power BI, и узнаем, к каким данным они обеспечивают
доступ и как могут влиять на быстродействие решений.
Часть II
Анализ, улучшение
и управление
производительностью
В этой части книги мы научимся определять источники показателей про-

изводительности в Power BI и получать к ним полный доступ. Мы также
узнаем, какие инструменты лучше подходят для разных слоев, научимся
производить отладку и применять структурированный подход к улучшению
производительности.
глава 4 «Анализ логов и метрик»;
глава 5 «Анализатор производительности»;
глава 6 «Внешние инструменты»;
глава 7 «Общие принципы управления производительностью».
Глава 4
Анализ логов и метрик
В первой части книги мы заложили устойчивый фундамент для управления

производительностью в Power BI, определив важнейшие архитектурные ком-
поненты, влияющие на быстродействие и удобство работы пользователей.
Мы определили, как ваш выбор в этих областях может оказывать воздействие
на производительность, и перечислили советы и рекомендации, следование
которым поможет выжать максимум из имеющихся ресурсов.
При переходе от теоретических концепций к практике вам необходимо
будет узнать о способах измерения производительности и анализа данных.
Это позволит вам принимать взвешенные решения по поводу дальнейшего
углубленного исследования показателей и внесения изменений для повыше-
ния эффективности системы. Итак, пришло время перейти ко второй части
книги, в которой мы научимся извлекать данные о производительности Po
wer BI и правильно их анализировать.
В этой главе мы сосредоточимся на поиске и извлечении информации
о производительности. Вы узнаете, какие данные вам доступны, как их полу-
чить и как понять, что именно они указывают на узкие места.
метрики использования в Power BI;
логи Power BI и трассировка.
Метрики использования в Power BI

В главе 1 мы уже говорили, что наиболее заметным показателем быстродей-
ствия системы бизнес-аналитики является скорость формирования отчетов.
В Power BI администратор рабочей области может получать информацию
о производительности при помощи встроенного отчета о метриках исполь-
зования (usage metrics). Но учтите, что эта опция недоступна при исполь-
зовании классических рабочих областей (classic workspaces), она есть только
в новых рабочих областях второй версии (Workspace v2). Подробнее о рабочих
областях в Power BI можно почитать по адресу https://learn.microsoft.com/en-
us/power-bi/collaborate-share/service-new-workspaces.
Доступ к метрикам использования вы можете получить из выпадающего
меню отчета в рабочей области Power BI, как показано на рис. 4.1. Нужный
вам пункт называется Просмотреть отчет о метриках использования
(View usage metrics report).
Метрики использования в Power BI  67
Рис. 4.1  Просмотр отчета о метриках использования в Power BI
Также вы можете запустить этот отчет из верхней панели инструментов

на странице отчета. Там этот пункт меню именуется Открыть метрики ис-
пользования (Open usage metrics), что видно на рис. 4.2.
Рис. 4.2  Доступ к метрикам использования на странице отчета
После открытия отчета о метриках использования перейдите на страницу

Report performance. По умолчанию будет открыта вкладка отчета Daily per-
68  Анализ логов и метрик
formance, на которой вы увидите информацию о ежедневных показателях

отчета за последние 30 дней. Этот вид отчета показан на рис. 4.3.
Рис. 4.3  Ежедневные показатели отчета
При желании вы можете переключиться на вкладку 7-day performance,

чтобы проанализировать скользящие показатели эффективности по неде-
лям. На этом графике представлены сглаженные линии трендов по неделям.
В настоящее время в Power BI поддерживаются две версии отчета о метриках ис-
пользования. Если ваш отчет выглядит не так, как показано на рисунках, проверьте,
что у вас активирован переключатель Новый отчет об использовании включен (New
usage report on), который видно на рис. 4.3. При желании вы можете переключаться
между этими режимами.
На странице Report performance отчета о метриках использования пред-

ставлены следующие показатели, на которых стоит остановиться подробнее:
Typical opening time: представляет собой 50-й процентиль или ме-
диану длительности загрузки отчета за выбранный период. Если вы
выстроите в один ряд все времена загрузки отчета за период и отсор
тируете их, то медиана будет точно посередине. Медиана в данном
случае лучше отражает типичное время загрузки отчета, поскольку не
так подвержена влиянию выбросов;
Opening time trend: этот показатель демонстрирует процентное изме-
нение типичного времени загрузки отчета, сравнивая первую и вторую
половины выбранного периода. В нашем случае (на рис. 4.3) мы видим,
что во второй половине указанного месяца отчет стал формироваться
на 20 % быстрее;
For most of the users your report opens between [X] and [Y] seconds:
этот показатель отражает интервал в секундах, в который входит
большинство вызовов отчета. Нижняя граница (X) представляет собой

10-й процентиль по времени загрузки отчета, а верхняя (Y) – 90-й про-
центиль. Таким образом, под большинством здесь подразумевается
80 % вызовов. Это очень подходящий индикатор быстродействия от-
чета, поскольку он охватывает действительно большую часть загрузок,
и на него не оказывают влияния статистические выбросы. В идеале
нижняя и верхняя границы показателя не должны сильно отличаться,
но это вовсе не обязательное правило. Главное, чтобы верхняя граница
находилась в пределах допустимого быстродействия вашего отчета,
о котором мы говорили в главе 1;
25 % of open report actions: эта линия на графике отражает динамику
25-го процентиля длительности загрузки отчета за выбранный период;
50 % of open report actions: эта линия показывает динамику 50-го про-
центиля (медианы) длительности загрузки отчета;
75 % of open report actions: эта линия отражает динамику 75-го про-
центиля длительности загрузки отчета.
Обратите внимание на диаграмму в правой нижней части отчета. На ней
отражено типичное время загрузки отчета с разбивкой по странам (Coun-
try), методу доступа (Consumption Method) и браузерам (Browser). Мы
рекомендуем регулярно отслеживать показатели отчета в представленных
разрезах, чтобы вовремя выявлять выбивающиеся из общего ряда цифры.
В датасете, лежащем в основе отчета о метриках использования, присутству-
ют и дополнительные точки данных, информация о которых не выводится
в отчете по умолчанию. В следующем разделе мы узнаем, как их извлечь
и использовать.
Доработка отчета о метриках использования

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

Отчет о метриках использования по умолчанию строится на основании дан-
ных об одном выбранном отчете. Но вам может понадобиться проанализиро-
вать быстродействие целой рабочей области в агрегированном виде или до-
бавить информацию по другим отчетам. Это можно сделать, раскрыв правую
панель с фильтрами, сняв текущее выделение отчетов и выбрав нужный вам
отчет по имени или идентификатору. На рис. 4.4 показана раскрытая панель
фильтров с очищенным по умолчанию фильтром ReportGuid и развернутым
списком отчетов с их именами. Обратите внимание, что при указании не-
скольких элементов для анализа к заголовку отчета добавляется приставка
Multiple reports selected, говорящая о множественном выборе.
Рис. 4.4  Отчет о суммарной нагрузке на всю рабочую область
Теперь посмотрим, как можно получить доступ к модели данных, лежащей

в основе отчета о метриках использования, и внести в отчет необходимые
изменения.
Доступ к сырым данным посредством создания

редактируемой копии метрик использования
Отчет о метриках использования в Power BI управляется самой системой.
У вас нет доступа к его изменению, и соответствующие пункты на панели
инструментов будут для вас неактивны. Однако вы можете обойти это огра-
ничение при помощи создания копии отчета о метриках использования.
Для этого при работе с ним выберите в меню Файл (File) пункт Сохранить
копию (Save a copy), как показано на рис. 4.5.
Рис. 4.5  Создание копии отчета

о метриках использования
По умолчанию при создании копии отчета его новая версия будет поме-
щена в ту же рабочую область, где располагается оригинал. Вам нет необхо-
димости настраивать расписание обновлений для этого отчета, поскольку он

использует в качестве источника данных скрытый системный набор данных
о метриках использования.
Для изменения созданной копии отчета вы можете открыть его так же точ-
но, как любой другой отчет. После открытия нажмите на кнопку Изменить
(Edit) на панели инструментов и произведите необходимые действия. На
рис. 4.6 показаны элементы, служащие источником данных для копии отчета
о метриках использования.
Рис. 4.6  Набор данных для копии отчета

о метриках использования
Давайте кратко пройдемся по всем основным элементам представленного

набора данных, чтобы вы могли использовать их при построении собствен-
ных отчетов и искать ответы на интересующие вас вопросы.
Меры в наборе данных:
Model measures: логический контейнер для мер в наборе данных.
В нем содержатся папки с мерами для лучшего восприятия.
Измерения в наборе данных:
Dates: общий календарь. Мы рекомендуем пользоваться этой таблицей
для создания фильтров и визуальных элементов с указанием хроноло-
гии, поскольку она связана со всеми соответствующими таблицами ло-
гов. Это позволит вам размещать в отчете различные метрики в одном
и том же контексте дат;
Reports: список всех отчетов в рабочей области с именами и иден-

тификаторами. Используйте столбец IsUsageMetricsReport, чтобы
исключить какие-то системные отчеты из вашего анализа. Для этого
установите ему значение True;
Report pages: здесь содержится список страниц отчетов с именами
и идентификаторами, а также идентификатор отчета, которому при-
надлежит страница;
Users: содержит список всех имен участников-пользователей (user prin-
cipal name – UPN), которые были задействованы в работе с отчетами.
Чаще всего под этим атрибутом скрывается электронный адрес.
Факты в наборе данных:
Report page views: таблица, содержащая записи для всех просмотров
страниц отчетов со стороны клиентов Power BI. Используйте эти дан-
ные для анализа на уровне страниц. Здесь важно упомянуть одно огра-
ничение, присутствующее в документации от Microsoft. Данные в этой
таблице опираются на сведения, посланные в Power BI клиентским
устройством (например, браузером на компьютере пользователя). Как
сказано в документации, иногда конфигурация устройств или сети мо-
жет приводить к блокировке исходящих подключений, что может пре-
пятствовать поступлению соответствующей информации в Power BI;
Report load times: здесь содержится информация о загрузке всех отче-
тов в том виде, в котором она поступает от клиента Power BI (например,
от powerbi.com в случае использования веб-браузера или от мобильного
приложения Power BI при работе с телефона). Поля StartTime и End-
Time используются для расчета длительности действий. На данный
момент здесь не присутствует информация о странице отчета, так что
зафиксированные действия могут относиться к любой странице. Спо-
соб обхода данного ограничения приведен далее в этой главе;
Report views: в этой таблице присутствуют действия по открытию от-
четов с информацией от службы Power BI. Эти события фиксируются
на стороне сервера каждый раз при открытии отчетов. Таким образом,
представленная здесь информация не зависит от проблем на стороне
клиента и сетевых задержек, и каждое открытие отчета происходит
в Power BI;
Report rank: статическая таблица со списком всех отчетов в рабочей
области и рангами по просмотрам в рамках всего клиента;
Workspace reports: агрегированная информация по дням использо-
вания отчетов с тенденциями. Используйте поле IsUsageMetricsRe-
portWS для исключения системных отчетов из анализа – установите
для них значение True. Информация из этой таблицы используется
на странице Report performance отчета о метриках использования
в Power BI;
Workspace views: суммарная информация о просмотрах отчетов поль-
зователями в разрезе способов использования и методов доступа. Слу-
жит источником данных для страницы с отчетами.
Практические способы использования этого набора данных для анализа

различных сценариев описаны в документации от Microsoft. Мы рекомен-
дуем вам ознакомиться с решением по адресу https://docs.microsoft.com/pow-
er-bi/collaborate-share/service-modern-usage-metrics#worked-example-of-view-
and-viewer-metrics. Это поможет вам лучше понимать и интерпретировать
метрики использования.
Доступ к сырым данным посредством создания

собственного отчета о метриках использования
Вам может потребоваться использовать Power BI Desktop для создания свое
го собственного отчета о производительности системы или вы не хотите
строить свой отчет на базе уже существующего по умолчанию. В этом случае
вы можете подключиться из Power BI Desktop к набору данных с метриками
использования в нужной вам рабочей области. Вы обнаружите этот датасет
в любой рабочей области, в которой хотя бы раз обращались к метрикам ис-
пользования.
Для создания отчета на основе этого набора данных в Power BI Desktop
выберите при подключении вариант Наборы данных Power BI (Power BI
datasets), после чего воспользуйтесь поиском и введите шаблон usage metrics
report. В результате останутся все системные наборы данных с метриками
использования, и вы сможете подключиться к одному из них – в нужной вам
рабочей области. На рис. 4.7 показан результат поиска со всеми наборами
данных, отвечающими введенному шаблону.
Рис. 4.7  Список датасетов с метриками использования в Power BI Desktop
Подключившись к набору данных, вы увидите модель, которую мы подроб-

но описали в предыдущем разделе, и сможете строить собственные отчеты.
Доступ к сырым данным с помощью анализа метрик

использования в Excel
Еще одним способом доступа к данным о производительности является их
анализ в Excel. Для этого вы можете воспользоваться стандартным функцио
налом отчета с метриками использования в Power BI, выбрав в меню Экс-
портировать (Export) пункт Анализировать в Excel (Analyze in Excel), как
показано на рис. 4.8. После этого Power BI предупредит вас о загрузке файла
Excel со всей необходимой информацией для подключения.
Рис. 4.8  Анализ данных о метриках использования в Microsoft Excel
Теперь вы можете открыть загруженный файл Excel и строить нужные вам

визуализации на основе данных из набора Power BI, который появится в Ex-
cel в виде набора полей для сводной таблицы. На рис. 4.9 показана сводная
таблица, созданная после подключения к данным о метриках использования.
Здесь мы сравнили показатели 25-го, 50-го и 90-го процентилей в разрезе
браузеров по одному отчету.
Теперь посмотрим, как можно добраться до детальной информации, пре-
доставляемой уже знакомым нам набором данных в Power BI.
Анализ детализированной информации

о производительности
До сих пор мы говорили об анализе агрегированных данных из набора с мет
риками использования, по примеру отчета по умолчанию. С этого вполне
можно начать, но суммарные показатели вряд ли позволят вам выделить
конкретные проблемы и добраться до их истинных причин. К счастью, в опи-
санном ранее наборе данных о метриках использования содержится и бо-
лее детальная информация. Давайте воспользуемся ей и на основе таблицы
Report load times построим отчет о производительности с более высокой
степенью гранулярности.
Хотя мы при построении отчета воспользуемся лишь одной опцией, вам
будет доступен полный спектр анализа. На рис. 4.10 показан отчет с таблицей
и графиком, построенный на основе неагрегированных данных. Цель заклю-

чалась в сравнении двух отчетов на предмет динамики их быстродействия
с течением времени. Похожим образом можно анализировать любые другие
доступные в наборе данных измерения.
Рис. 4.9  Анализ набора данных с метриками использования в Excel
Рис. 4.10  Детальный отчет о производительности в пользовательском отчете

В наборе данных с метриками использования отсутствует информация о страницах

отчетов, так что вы не сможете узнать, какая именно страница породила то или иное
действие. Нельзя строить предположения о том, что была задействована страница
отчета по умолчанию, на основании закладок или прямых общих ссылок. Единствен-
ным способом извлечь информацию о странице в веб-службе является разделение
отчета на несколько копий с одной страницей в каждом. Это позволит смоделировать
работу со страницами и быть уверенными, что конкретная метрика точно относится
к определенной странице отчета. Компания Microsoft анонсировала выпуск обновле-
ний, которые должны решить эту проблему. На момент написания книги соответству-
ющее обновление запланировано на 2022 год. Подробно об этом можно узнать по
адресу https://docs.microsoft.com/power-platform-release-plan/2022wave1/power-bi/
administrative-insights-long-term-historical-tenant-activity-retention-central-metada-
ta-built-in-reports.
Теперь давайте узнаем, на что именно стоит обращать внимание при ана-
лизе данных о производительности и что делать с полученными результа-
тами.
Анализ метрик отчета о производительности

Мы рассмотрели разные способы получения доступа к данным о произво-
дительности в Power BI и настройке отчетов на их основании. Теперь узна-
ем, как использовать полученные данные для идентификации узких мест
в системе.
Если вас интересует конкретная проблема с производительностью и вы
хотите разобраться в ней подробно, вам необходимо детально анализировать
поступающие запросы. В главах 5 и 6 мы представим подходящие для этого
инструменты. Сейчас же мы сосредоточимся на верхнеуровневом анализе
отчетов и поиске трендов и аномалий, а также поговорим о том, как интер-
претировать полученную информацию.
Вам нет необходимости особым образом настраивать отчеты о произво-
дительности, для того чтобы делать правильные выводы. На странице Re-
port performance, присутствующей в отчете по умолчанию, есть нужная
информация. Приведенную ниже таблицу можно использовать в качестве
руководства (табл. 4.1).
На рис. 4.11 показаны данные о производительности отчета за месяц
с суммарным количеством просмотров более 60 тыс. Здесь мы видим, что
в целом быстродействие отчета сохраняется на стабильном уровне, за исклю-
чением двух дней, когда показатель 75-го процентиля подпрыгнул на пять
и более секунд по сравнению с нормой. Это должно вас побудить проверить
быстродействие других отчетов в эти дни. Если с ними было все в порядке,
необходимо узнать, наблюдались ли пики в эти дни в плане обращений к от-
чету со стороны пользователей, и если да, значит, отчет испытывает явные
проблемы с масштабированием. Кроме того, вполне возможно, что труд-
ности возникли только у тех, кто использует в работе лишь этот конкретный
отчет. В этом случае вы можете воспользоваться данными по странам и ин-
формацией о пользователях для проведения нового анализа.
Таблица 4.1. Инструкция по анализу отчета об агрегированных данных

Вопрос Обоснование и дальнейшие действия
Какие отчеты самые быстрые Выделите общие характеристики для быстрых и медленных отчетов.
и самые медленные? При этом необходимо сосредоточиться на медленных и часто
используемых отчетах. Проведите экспертизу модели данных, DAX
и выполните анализ визуальных элементов в проблемных отчетах
Остается ли скорость форми- Главная цель – определить, всегда ли анализируемый отчет
рования отчетов стабильной формируется медленно или на его скорость оказывает влияние
с течением времени? нагрузка от пользователей либо системы (больше относится
к лицензии Premium). Если вы обнаружите спад быстродействия
отчета в конкретный период, проверьте, как в этот же период вели
себя другие отчеты. Если тоже замедлялись, ищите проблему во
внешних факторах, а не в самом отчете
Наблюдается ли для какого-то Как и в случае с предыдущим вопросом, здесь полезно выяснить,
отчета ощутимая разница между зависят ли замедления в работе отчета от конкретного
нижним и верхним процентилями пользователя, его местоположения, браузера и т. д. Это поможет
по времени загрузки? отвести подозрения от самого отчета
Какие браузеры используются Официально сообщается, что использование старых версий
для формирования отчетов браузеров может вести к замедлению работы отчетов в Power BI.
и зависит ли от этого фактора При этом разница в скорости может быть значительной, и данные
быстродействие отчетов? об этом могут использоваться как побуждение к обновлению
технической базы, на которое в крупных корпорациях всегда идут
очень неохотно
Испытывают ли пользователи Конфигурация сети, скорость соединения и физическое расстояние
из определенных стран или пользователей от домашнего региона Power BI могут оказывать
регионов проблемы негативное воздействие на быстродействие отчетов. Этим фактором
с быстродействием отчетов? можно оправдать низкую скорость формирования отчетов,
при условии что большинство пользователей находятся далеко
или имеют проблемы с подключениями по сети
Было ли замечено снижение Отчеты Power BI могут быть развернуты самыми разными
быстродействия отчетов в зави- способами. Каждый из них имеет свои особенности и предполагает
симости от платформы и метода особые меры по оптимизации. Полученная информация поможет
распространения содержимого вам выстроить наиболее приемлемую структуру развертывания
(например, мобильная версия отчетов для вашей организации
против веб-версии или встроен-
ные отчеты против powerbi.com)?
На рис. 4.12 показан анализ быстродействия того же отчета в разрезе брау

зеров с использованием вкладки из базового набора метрик использования.
Как видите, устаревшие браузеры дают меньшую производительность по
сравнению с их более современными конкурентами.
Также рекомендуется настраивать собственные пользовательские отчеты
на основе данных о производительности. На рис. 4.13 показан один из таких
отчетов. В левой части точечной диаграммы выделены три отчета, значи-
тельно уступающие остальным в быстродействии, и при этом они довольно
часто используются. В правой части диаграммы отмечен еще один отчет,
к которому обращаются очень часто. И хотя его нельзя однозначно причис-
лить к самым медленным отчетам в системе, типичное время открытия для
него составляет 50 секунд, что далеко от идеала и требует дополнительного
исследования.
Рис. 4.11  Анализ производительности отчета по дням с двумя пиками
Рис. 4.12  Анализ производительности отчета по браузерам

Рис. 4.13  Анализ времени открытия отчетов и количества их пользователей
Теперь научимся извлекать метрики производительности из нескольких

рабочих областей.
Получение показателей производительности из нескольких

рабочих областей
На момент написания книги Power BI не предоставлял единого места для
сбора информации о метриках производительности из нескольких рабочих
областей. Если вам все же необходимо объединить данные об использовании
и производительности для разных областей, придется выполнить некоторые
ручные действия. Один из вариантов приведен ниже.
1. Воспользуйтесь уже знакомым вам пунктом меню Анализировать
в Excel (Analyze in Excel) для построения плоской таблицы с нужными
вам данными о производительности. Выберите диапазон дат в соот-
ветствии с тем, как часто вы хотите выполнять этот процесс и получать
свежие данные. К примеру, вы можете выбрать 7-дневный диапазон,
если хотите обновлять данные каждую неделю.
2. Повторите шаг 1 для всех рабочих областей Power BI и сохраните ин-
формацию в отдельных файлах Excel.
3. В Power BI Desktop выполните импорт и объединение файлов Excel.
Постройте запрос таким образом, чтобы выполнялась загрузка всех
файлов из папки. Таким образом, каждую неделю, когда вы будете по-
лучать обновленные данные, вы будете просто добавлять недельные
файлы в папку и обновлять данные в Power BI.
4. Каждую неделю вы сможете использовать файлы Excel предыдущей
недели и обновлять фильтр дат.
Вы можете выстроить и свой алгоритм действий. Например, можно загру-

жать данные об использовании в центральное хранилище и в дальнейшем
использовать его в качестве источника для анализа. Данный подход больше
подойдет администраторам баз данных и разработчикам, и в следующем
разделе мы коснемся этой темы.
Логи Power BI и трассировка

Способ анализа производительности системы при помощи отчетов с метри-
ками использования, описанный в предыдущем разделе, подходит админист
раторам рабочих областей. Администраторам служб Power BI предоставляет
файлы с логами, но на сегодня они не содержат метрик производительности
отчетов. В то же время в компании Microsoft заявили о намерении улучшить
систему ведения логов, так что мы уделим некоторое внимание этой теме,
поскольку в будущем вы сможете полноценно использовать логи для анализа
Журнал действий и единый журнал аудита

В Power BI присутствуют два источника логов, описывающих действия поль-
зователей. В табл. 4.2 приведены их основные сходства и различия.
Таблица 4.2. Сравнение журнала действий и единого журнала аудита

Журнал действий Power BI Единый журнал аудита
Доступ осуществляется посредством REST API Get Доступ осуществляется через интерфейс
Activity Events и командлета Power BI Management Compliance Search или командлеты PowerShell
Требуются привилегии администратора Power BI Требуются привилегии глобального администратора
или службы Power Platform Office 365 или аудитора
Содержит только действия из Power BI Содержит действия из всей линейки продуктов
Microsoft, к примеру Office 365
История хранится на протяжении 30 дней История хранится на протяжении 90 дней
Больше информации будет приведено ниже в разделе «Материалы к про-

чтению».
Для анализа журнала действий (activity log) вам необходимо будет создать
отчеты по примеру того, как мы описывали в разделе с метриками исполь-
зования. В случае с журналом аудита (audit log) вам нет необходимости ис-
пользовать файлы Excel – вместо этого вы можете сохранять данные в виде
файлов CSV. Также логи администрирования легко поддаются автоматиза-
ции по причине возможности использования командлетов PowerShell и вы-
зовов REST API.
Логи Power BI и трассировка  81
Трассировка Analysis Services

с помощью конечных точек XMLA
Если вы располагаете лицензией Power BI Premium, вам будет доступно ис-
пользование конечных точек XMLA (XMLA endpoint) при установке соот-
ветствующей настройки в параметрах. С помощью этой технологии можно
получать доступ к наборам данных Power BI, отправляя команды напрямую
движку Analysis Services. Таким образом, вы сможете осуществлять трасси-
ровку из SQL Server Profiler на рабочей станции и извлекать детализирован-
ную информацию о наборах данных почти в реальном времени. Данные из
Analysis Services представляют большой интерес тем, что содержат информа-
цию о нагрузке на движок, производительности запросов и эффективности
обновлений. Подробнее о трассировке движка мы будем говорить в следую-
щих главах. Сейчас же вам достаточно знать, что SQL Profiler предоставляет
универсальный интерфейс извлечения и просмотра логов, но он не рекомен-
дуется к использованию. В главе 6 мы поговорим о сторонних инструментах,
которые можно применять для этих целей. Тем же, кто хочет использовать
SQL Profiler или не имеет возможности запускать стороннее программное
обеспечение, мы рекомендуем прочитать пост от Кристофера Уэбба (Chris-
topher Webb), написавшего не одну книгу по Analysis Services. Пост можно
найти по адресу https://blog.crossjoin.co.uk/2020/03/02/connecting-sql-server-
profiler-to-power-bi-premium.
Интеграция с Azure Log Analytics

Не так давно компания Microsoft предоставила возможность подключаться
из Power BI к рабочим областям Azure Log Analytics. Azure Log Analytics – это
платформа, в которой вы можете загружать и хранить логи в течение двух
лет, выполнять произвольные запросы в режиме почти реального времени,
создавать оповещения и извлекать данные для отчетности и аналитики.
В Microsoft сообщают, что в скором времени появится много дополнитель-
ных метрик, связанных с производительностью. Это очень многообеща-
ющее направление, поскольку дает потребителям полный контроль над
своими логами с детализированными и гранулярными метриками, пусть
и небесплатно. Также Microsoft предоставляет удобные шаблоны отчетов,
доступные для загрузки. Поскольку этот функционал на момент написа-
ния книги находился на этапе публичного предпросмотра, мы не будем
подробно на нем останавливаться, ведь здесь еще все может поменяться.
Больше информации по этой теме можно получить по адресу https://powerbi.
microsoft.com/ru-ru/blog/announcing-long-term-usage-and-performance-insights-
public-preview.
Отслеживание показателей в Azure Analysis

Services и Power BI Embedded
Azure Analysis Services (AAS) и Power BI Embedded (PBIE) представляют со-
бой службы, входящие в состав Azure. Это означает, что они поддерживаются,
управляются и оплачиваются в рамках облачной платформы Azure. Вы можете
применять эти службы по отдельности, напрямую интегрируя их в свои при-
ложения или используя в качестве независимых слоев данных, которые при
необходимости могут быть масштабированы. Мы в основном будем использо-
вать инструментальные средства Azure для просмотра данных из этих служб.
Метрики Azure для AAS

После установки и подготовки к работе экземпляра AAS вы можете использо-
вать встроенные метрики для визуализации нагрузки и различных операций.
Просто перейдите на портале Azure в раздел с экземпляром AAS и выберите
пункт с метриками в навигационной панели слева. После этого вы може-
те выбирать разные показатели для вывода на графиках в веб-интерфейсе,
как описано в документации по адресу https://learn.microsoft.com/en-us/azure/
analysis-services/analysis-services-monitor. Давайте рассмотрим наиболее важ-
ные показатели и приведем их описание:
Current User Sessions: количество одновременных активных сессий
пользователей. Вы можете сопоставить эти данные с временными ин-
тервалами с пиковой нагрузкой, чтобы понять, является ли количество
сессий решающим фактором снижения производительности;
M Engine Memory: память, задействованная процессами движка об-
работки во время обновления данных. Обратите внимание на этот по-
казатель при поиске пиковых значений и попытайтесь определить,
совпадают ли они с отказами отчетов или проблемами с их быстро-
действием;
M Engine QPU: вычислительные мощности, задействованные в про-
цессе обработки данных и выраженные в единицах обработки запро-
сов (Query Processing Units – QPU). К примеру, если вы располагаете
экземпляром уровня S1, то в вашем распоряжении будет 100 QPU, и вы
должны убедиться, что этого вам достаточно при достижении нагруз-
ками своих пиковых показателей. Конкретный показатель зависит от
анализируемого сценария и определяется путем выполнения нагру-
зочного тестирования в отсутствие обновлений. Об этом процессе мы
подробно будем говорить в главе 13;
Memory: показатель использования памяти. Демонстрирует, какой
общий объем памяти используется всеми серверными процессами
в экземпляре. Если это значение близко к максимально допустимому
в рамках вашего SKU, быстродействие запросов и обновлений может
страдать, и могут возникать сбои и отказы;
QPU: вычислительные мощности, задействованные всеми процессами
в рамках экземпляра. Хорошо оптимизированный экземпляр должен
Логи Power BI и трассировка  83
функционировать на пределе нагрузки без продолжительного удержа-

ния показателя QPU на максимальном уровне, хотя наличие пиковых
всплесков не обязательно является проблемой;
Query Pool Busy Threads: количество потоков процессора, используе-
мое для запросов. Максимальное значение прописано в конкретном
плане SKU. Если вы заметили, что этот показатель достигает максиму-
ма и долгое время удерживается на этом значении, это означает, что
параллельно запускается слишком много запросов/отчетов. Некоторые
запросы в таких условиях будут вынуждены ожидать свободного окна
для начала выполнения.
На рис. 4.14 показан график по метрике AAS QPU, сформированный на
портале Azure.
Рис. 4.14  Метрика Azure Analysis Services QPU на портале Azure
Для службы AAS также доступны и некоторые другие детализированные

трассировки. Но чтобы ими воспользоваться, необходимо выполнить опре-
деленные настройки. Об этом мы поговорим далее.
Диагностика в Azure для Analysis Services

Ранее в этой главе мы говорили о том, как можно использовать конечные
точки XMLA для подключения к рабочим областям Premium с целью извлече-
ния трассировок движка. Эта же концепция применима и к AAS, хотя можно
использовать журнал диагностики Azure и Azure Log Analytics для анализа
полученной информации. В то же время перед подключением AAS к службе

журналирования необходимо выполнить определенные требования, в числе
которых – предоставление места назначения для логов. Это требует наличия
прав администратора в Azure. Тонкости настройки этого процесса выходят
за рамки данной книги, так что вы можете ознакомиться с ними в официаль-
ной документации по адресу https://learn.microsoft.com/en-us/azure/analysis-
services/analysis-services-logging.
Метрики Azure и диагностика для PBIE

Power BI Embedded (PBIE) поддерживает встроенные метрики Azure, доступ-
ные на портале Azure, по тому же принципу, что и в AAS. Разница лишь в том,
что в этом случае доступных метрик будет меньше. В процессе перевода
компанией Microsoft инфраструктуры Premium/Embedded с поколения Gen1
на Gen2 доступные метрики меняются. С текущим списком метрик можно
ознакомиться в онлайн-документации. По этой ссылке еще описываются
процессы диагностики и журналирования в PBIE, которые работают так же,
как в AAS: https://learn.microsoft.com/en-us/power-bi/developer/embedded/mon-
itor-power-bi-embedded-reference#metrics.
В следующих главах мы подробнее поговорим о логах движка AS. Советы,
которые мы дадим, будут одинаково применимы к движку AS в Power BI, AAS
и PBIE.
Теперь, когда вы освоили базовые методики работы с производитель
ностью в Power BI, пришло время подвести итоги этой главы.
Поскольку производительность отчетов является довольно важной и обшир-
ной темой, мы начали главу с обзора встроенных шаблонов анализа метрик
использования в Power BI, которыми могут воспользоваться администраторы
рабочей области.
Сперва мы научились формировать отчет по метрикам использования. Мы
подробно рассмотрели содержимое вкладки с производительностью отчета
и узнали, как можно анализировать показатели в разрезе браузеров, место-
положения пользователей и методов развертывания отчетов. Мы отметили,
что представленная в отчете агрегированная информация является отлич-
ной отправной точкой для анализа, но для возможности детального разбора
ситуации вам понадобятся данные с более высоким уровнем грануляции.
С целью их получения мы научились сохранять копию исходного отчета и на-
страивать ее, анализировать сырые данные в Excel и подключаться к набору
данных с метриками использования из Power BI Desktop. Все эти методы
помогут вам получать детальную информацию и выводить ее в нужном вам
виде. Попутно мы подробно разобрали назначение всех таблиц в наборе
данных и описали работу с несколькими рабочими областями Power BI одно-
временно. В завершение первой части главы мы сформулировали и ответили
на наиболее типичные вопросы, связанные с производительностью, рассмот
Материалы к прочтению  85
рели примеры полезных метрик, с которыми вам предстоит разобраться,

и перечислили меры, которые стоит предпринять на основании полученной
информации.
После этого мы перешли к разговору о логах и трассировке, сразу отметив,
что логи уровня всего облачного пространства будут доступны только поль-
зователям с соответствующими правами администратора. В то же время мы
узнали, что эти логи изначально не содержат информации о производитель-
ности, и научились извлекать нужные нам сведения напрямую из движка
Analysis Services, лежащего в основе любого решения Power BI. Вместе с тем
мы узнали, что этот источник содержит очень важные данные относительно
производительности запросов и обновлений. При использовании наборов
данных Premium вы имеете возможность осуществлять подключение с по-
мощью конечных точек XMLA, что позволит выполнять трассировку почти
в реальном времени. Также вы располагаете опцией подключения из Po
wer BI к Azure Log Analytics с целью извлечения гранулярных данных в вашем
окружении. Log Analytics – это выделенная служба Azure для масштабного
анализа логов с возможностью выполнения произвольных запросов, долго-
временным хранением, созданием оповещений и поддержкой визуализации
средствами Power BI.
Кроме того, для использующих в работе Azure Analysis Services или Po
wer BI Embedded мы рассказали о необходимости воспользоваться журналом
диагностики, поскольку они представляют собой отдельные службы Azure.
Важное замечание здесь состоит в том, что все логи движка AS берут свое
начало в одних и тех же трассировках, хотя и представляются в разных фор-
матах.
В следующей главе мы еще глубже погрузимся в тему анализа произво-
дительности и рассмотрим очень полезный инструмент под названием Ана-
лизатор производительности. К этому инструменту мы будем обращаться
и в последующих главах книги при рассмотрении влияния тех или иных
действий на производительность решения.
Материалы к прочтению
Чтобы лучше усвоить темы, которые мы затрагивали в этой главе, советуем
вам ознакомиться с материалами, ссылки на которые приведены ниже:
Rest API Get Activity Events: https://learn.microsoft.com/ru-ru/rest/api/
power-bi/admin/get-activity-events;
командлет PowerShell Power BI Management: https://www.powershell-
gallery.com/packages/MicrosoftPowerBIMgmt/1.2.1104;
Microsoft 365 Compliance Search: https://compliance.microsoft.com;
командлеты Microsoft 365 PowerShell: https://learn.microsoft.com/
ru-ru/microsoft-365/compliance/search-the-audit-log-in-security-and-
compliance?view=o365-worldwide.
Глава 5
Анализатор
В предыдущей главе мы рассмотрели способы извлечения информации об

использовании и производительности из службы Power BI посредством от-
четов и логов. Эти данные предоставляются компанией Microsoft по вашему
требованию, но при этом имеют определенные ограничения в отношении
вопросов, на которые они способны отвечать. В отчетах Power BI нас в первую
очередь интересует скорость отрисовки визуальных элементов, выполнения
запросов или все это вместе взятое. На момент написания книги далеко
не весь спектр детализации был доступен в информации, предоставляемой
службой Power BI. В то же время вы можете получить куда более подробные
данные при помощи встроенного в Power BI Desktop инструмента под на-
званием Анализатор производительности.
В процессе чтения этой книги вы видите, как самые разные факторы могут
влиять на быстродействие пользовательских отчетов. Для идентификации
этих факторов необходимо иметь возможность анализировать поведение
отчета на уровне каждого взаимодействия с пользователем и наблюдать за
ответами всех визуальных элементов на эти действия.
Анализатор производительности (Performance Analyzer) – превосходный
инструмент для этих целей. В этой главе мы научимся с ним работать и узна-
ем, как его использовать для определения проблем с производительностью.
обзор Анализатора производительности;
определение и устранение проблем с производительностью;
экспорт и анализ данных о производительности.
Технические требования
Некоторые темы из этой главы предполагают наличие примеров. Мы будем
упоминать файлы, с которыми будем работать. Все их вы сможете найти
в папке Chapter05 в хранилище GitHub по адресу https://github.com/PacktPub-
lishing/Microsoft-Power-BI-Performance-Best-Practices.
Обзор Анализатора производительности  87
Обзор Анализатора производительности

Анализатор производительности (Performance Analyzer) позволяет вам за-
писывать действия пользователя и разбивать поведение отчетов по визу-
альным элементам, включая запросы DAX и DQ. Вместе с тем вам предостав-
ляется информация о длительности всех внутренних операций элементов
визуализации в миллисекундах. На рис. 5.1 показано, как на панели Анали-
затор производительности отображается статистика по одностраничной
операции обновления, инициированной из самого инструмента.
Обратите внимание на то, какие действия были перехвачены и сколько
времени они потребовали. Ссылка Копировать запрос (Copy query) бывает
крайне полезна при анализе производительности запросов DAX или модели
данных. Она позволяет вам извлечь запрос DAX или внешнюю команду Di-
rectQuery, генерируемую визуальным элементом. Эти запросы впоследствии
могут быть проанализированы при помощи сторонних инструментов, о ко-
торых мы поговорим в главе 6.
Рис. 5.1  Панель Анализатора производительности

с раскрытым визуальным элементом
В этой главе мы сконцентрируемся на практических примерах использо-

вания этого инструмента и нюансах поведения Power BI, на которые следует
обращать внимание при анализе производительности. Если вам нужно прос
то познакомиться с Анализатором производительности, вы можете прочи-
тать вводную инструкцию по адресу https://learn.microsoft.com/ru-ru/power-bi/
create-reports/desktop-performance-analyzer.
88  Анализатор производительности
Анализатор производительности измеряет длительность операций с точки зрения

клиента Power BI Desktop. Стоит учитывать, что условия, в которых ведется разработка
в Power BI Desktop, могут значительно отличаться от реальной рабочей среды. Объем
данных, нагрузка на источник, количество одновременно работающих пользовате-
лей, требования к безопасности, местоположение и задействование локальных шлю-
зов – все эти факторы могут сыграть свою роль. Всегда имейте это в виду, выполняя
измерение показателей в Анализаторе производительности. При разработке в Po
wer BI Desktop условия зачастую бывают идеальными, но на практике пользователи
могут видеть совсем иную картину.
Действия и метрики в Анализаторе

Анализатор производительности позволяет перехватывать следующие дей-
ствия пользователей:
Изменил страницу (Changed page): к этому событию относится смена
текущей страницы при помощи вкладок в Power BI и пользовательских
кнопок навигации, помещенных в отчетах;
Перекрестное выделение (Cross-highlighted): к этой категории отно-
сятся типичные действия перекрестной активности, такие как выбор
точки данных или столбика на диаграмме. При этом стоит помнить,
что большинство щелчков мыши по визуальным элементам в Power BI
приводят как минимум к их обновлению. К примеру, при щелчке мы-
шью по пустой области элемента визуализации для отмены пере-
крестного выделения соответствующие элементы, как и ожидается,
будут обновлены. Если повторно щелкнуть по этой пустой области,
вы заметите обновление элемента, и это действие будет перехвачено
анализатором;
Изменил срез (Changed a slicer): это событие инициируется при из-
менении значения среза (slicer) и применяется к другим визуальным
элементам. Если у вас включена настройка сокращения числа запро-
сов в отчете (о которой мы говорили в предыдущих главах), то вам
необходимо будет нажать на кнопку Применить (Apply) для отправки
события Изменил срез. Даже при использовании этих кнопок под-
тверждения выбора взаимодействие со срезами может провоцировать
обновления визуальных элементов, которые будут перехвачены ана-
лизатором;
Изменил фильтр (Changed a filter): это событие возникает в случае
применения новых значений в фильтре отчета. Настройка сокращения
числа запросов в отчете распространяется на фильтры так же, как и на
срезы.
В Анализаторе производительности фиксируются следующие категории
действий для визуальных элементов:
Запрос DAX (DAX query): этот пункт отображается только в случае на-
личия запроса. Показатель измеряет время, прошедшее с момента от-
правки запроса визуальным элементом до получения результатов от
движка Analysis Services. Это время должно быть чуть большим, чем
в анализе запроса DAX из отчета о производительности от движка Anal-
ysis Services, поскольку сюда включаются сетевые задержки и прочие
накладные расходы;
Запрос Direct (Direct query): этот пункт появляется только для источ-
ников в режиме DirectQuery в присутствии запросов. Показанное время
отмеряется с момента отправки внешнего запроса движком Analysis
Services до получения результатов. Это время должно соответствовать
метрике для событий класса DirectQuery в движке Analysis Services;
Визуальное отображение (Visual display): здесь демонстрируется вре-
мя, необходимое для отрисовки визуальным элементом полученных
данных. В это время включается загрузка внешнего контента, напри-
мер изображений, и операции геокодирования. Плохо реализованные
или сложные пользовательские элементы визуализации могут требо-
вать значительного времени для отрисовки;
Другое (Other): к этой категории относятся все события визуального
элемента, не связанные с отрисовкой, такие как подготовка запросов
и прочие операции фоновой обработки данных. Также сюда включает-
ся время ожидания других визуальных элементов. Это происходит по
причине того, что все элементы визуализации используют один поток
(thread) и, если говорить очень упрощенно, каждый из них обрабаты-
вается процессором последовательно. Всякий раз, когда вы добавляе-
те новый визуальный элемент на страницу, этот показатель для всех
остальных элементов будет увеличиваться. Это не обязательно плохо,
но может негативно сказаться на времени тяжелых в плане визуализа-
ции отчетов. Более подробно о проблемах, связанных с визуализацией
элементов, мы поговорим в главе 9.
Обновление визуального элемента не обязательно приводит к запуску запроса в со-
ответствующем источнике данных. Клиент Power BI хранит локальный кеш результа-
тов вычислений, так что может себе позволить не запускать запрос заново при пере-
ключении между недавно отфильтрованными представлениями. Этим объясняется,
почему для некоторых визуальных элементов, основывающихся на данных, может
отсутствовать пункт с запросом DAX. Чтобы инициировать отправку запроса, необхо-
димо нажать на ссылку Обновить визуальные элементы (Refresh visuals) на панели
анализатора производительности.
Определение действий пользователя

На момент написания книги в поведении Анализатора производительности
присутствуют определенные странности в отображении действий пользо-
вателя, связанные с тем, что некоторые действия просто не выводятся на
соответствующем уровне. К примеру, если настроить срез как выпадающий
список, не все ваши действия с ним будут отображаться на одном и том же
уровне гранулярности. Это может усложнить процесс понимания того, какие
действия с отчетом производил пользователь. На рис. 5.2 показан простой
пример.
Открыт выпадающий список
Рис. 5.2  Пользователь открыл выпадающий список,

после чего сделал свой выбор
Здесь мы видим, что выпадающий список сначала был открыт, после чего
было выбрано значение, о чем свидетельствует действие Изменил срез
(Changed a slicer). При этом не вполне очевидно, что первый пункт описывает
именно действие пользователя, поскольку внешне он выглядит как общее
обновление визуального элемента. Если продолжить этот пример и снова
открыть выпадающий список, все станет еще более запутано. На рис. 5.3 вид-
но, что в нашей панели добавилось событие открытия выпадающего списка
к предыдущему действию Изменил срез (Changed a slicer).
Рис. 5.3  Выпадающий список открыт во второй раз

Кроме того, некоторые продвинутые техники взаимодействия с отчетами

вовсе не регистрируются в анализаторе в виде обычных действий пользова-
теля. Например, если вы используете иконку с привязкой в качестве действия
к закладке (например, для открытия панели со срезами), взаимодействие
с таким элементом будет фиксироваться как последовательность обновлений
визуальных элементов. На рис. 5.4 показан пример отчета, в котором панель
со срезами используется в качестве всплывающего окна, тогда как остальное
содержимое отчета тускнеет на фоне.
Рис. 5.4  Всплывающее окно со срезами с привязкой к иконке
На рис. 5.5 отображена панель анализатора производительности с собы

тиями, зарегистрированными в результате взаимодействия со всплывающим
окном. Выделенная область показывает действия, связанные с открытием
этого окна. Как видите, они располагаются непосредственно под событием
с предыдущим действием пользователя (обновлением визуального элемен-
та, инициированным из анализатора).
Рис. 5.5  Выделенная область

с активацией всплывающего окна со срезами
Теперь дадим несколько полезных советов по работе с Анализатором про-

изводительности и рассмотрим примеры проблем, которые можно иденти-
фицировать при помощи этого инструмента.
Определение и устранение проблем

с производительностью
Начнем с нескольких советов по работе с Анализатором производитель-
ности, чтобы вы могли быть уверены в том, что каждый раз вы сравниваете
сопоставимые данные и события. Это очень важно, так что вы должны ста-
Определение и устранение проблем с производительностью  93
раться исключить как можно больше переменных и моделировать одни и те

же условия, которые можете контролировать.
Единообразие тестов
Как вы знаете, при открытии файла с расширением .pbix в Power BI Desktop
набор данных автоматически загружается в память. При этом для моделей
с режимом хранения Import файл в памяти может занимать довольно много
места – до нескольких гигабайт. Наверняка вы замечали, что Power BI Desk-
top дольше открывается при работе с объемными файлами. Большая часть
времени при этом требуется для переноса набора данных с диска в память.
Эта концепция применима и к службе Power BI после развертывания в ней
своего набора данных.
При этом служба Power BI не удерживает все наборы данных в памяти по-
стоянно. Вместо этого она использует сложные эвристические алгоритмы
в попытках очистить память, насколько это возможно. Если вы на протяже-
нии какого-то времени не используете набор данных, то можете заметить
некоторую задержку при первом открытии отчета. Несмотря на использова-
ние компанией Microsoft очень эффективных методов хранения и передачи
данных, эта задержка при работе с большими файлами может быть довольно
значительной и превышать комфортные 8–10 секунд из рекомендации о вре-
мени загрузки отчетов, которую мы упоминали в главе 1. Учитывайте этот
аспект при сравнении быстродействия отчетов в Power BI Desktop и служ-
бе и старайтесь сделать все, чтобы исключить подобные выбросы из своих
метрик производительности при их оценке. Кроме того, до пользователей
также стоит донести эту особенность работы с системой при первом запуске
отчетов, особенно если отчеты несут критически важную информацию или
используются большой группой людей.
Любые дискуссии о производительности отчетов должны включать в себя
поправки на кеширование данных. Кеширование – это давно и отлично за-
рекомендовавший себя механизм повышения быстродействия часто исполь-
зуемых сценариев при помощи локального хранения результатов расчетов
для их быстрого повторного использования. В Power BI довольно активно
используется методика кеширования данных. В то же время это может нега-
тивно сказываться на репрезентативности проводимых вами исследований
в области производительности, поскольку первые запуски будут серьезно
уступать всем последующим.
При открытии существующего файла в Power BI Desktop будет открыта
страница, которая была активной в момент сохранения файла. На этой стра-
нице могут располагаться различные визуальные элементы, которые долж-
ны будут загрузиться, отправить запросы и отрисоваться, прежде чем вы
сможете продолжить работу с Power BI Desktop. Даже если вы сразу откроете
Анализатор производительности и запустите тестирование, кеширование
на клиенте и в Analysis Services неизбежно повлияет на быстродействие.
Лучшим решением этой проблемы при выполнении анализа производитель-
ности в Power BI Desktop является создание пустой страницы.
Добавьте пустую страницу в свой отчет при проведении теста производительности
в Power BI Desktop. Сохраните файл с открытой в этот момент пустой страницей и за-
кройте Power BI Desktop. Откройте программу снова и убедитесь, что по умолчанию
открывается созданная пустая страница. Теперь ни один запрос не подключается
к набору данных, а значит, кеширование производиться не будет.
На рис. 5.6 показано сравнение открытия файла с пустой страницей и по-

следующего переключения на отчет с проверкой производительности с на-
жатием на кнопку обновления визуальных элементов на панели Анализатора
производительности. При первом «холодном» запуске отчету потребовалось
больше секунды (выделенные области в секциях Другое (Other)) на загрузку
данных, тогда как при обновлении эти операции заняли минимальное вре-
мя, которым можно пренебречь. Время выполнения запросов DAX оказалось
очень низким и не оказывает влияния на общую картину. Это время уходит
на начальную инициализацию визуальных элементов, которая происходит
при первом их отображении. Вы можете влиять на этот показатель путем
снижения количества визуальных элементов в отчете. Какого-то рекомен-
Рис. 5.6  Первая загрузка потребовала больше времени

дованного ограничения в этом отношении нет, но заметные задержки при

отображении отчета появляются при наличии 30–50 элементов, особенно
если они отправляют запросы. В главе 9 мы рассмотрим приемы уменьшения
количества элементов визуализации в отчете.
Клиент Power BI Desktop кеширует данные в памяти. Если же вы обращае-
тесь к отчетам посредством веб-портала Power BI, это происходит в браузере.
При переключении со страницы отчета и обратно Power BI не будет посылать
новые запросы, а перерисует визуальные элементы отчета на основе ло-
кального кеша. Это видно по рис. 5.7. Здесь мы переключились со страницы
отчета на пустую страницу и обратно. Раскрыв действия для одних и тех же
визуальных элементов, мы обнаружили, что во втором случае пункты с за-
просами DAX отсутствуют.
Рис. 5.7  Запросы DAX

отправляются только при первом открытии отчета
Последний фактор, который стоит учитывать при проведении тестов, со-

стоит в том, какие процессы запущены на сервере параллельно с работой
Power BI Desktop и анализатора производительности. Объемный набор дан-
ных вкупе со сложными запросами способен изрядно нагрузить ресурсы
центрального процессора и памяти одномоментно. В случае запуска на ком-
пьютере других ресурсоемких приложений результаты тестирования могут
быть скомпрометированы.
Вы можете наблюдать эффект снижения скорости обработки процессором
визуальных элементов, сделав соответствующие настройки на своем ком-
пьютере. В Microsoft Windows это делается в окне Настройки электропи-
тания (Power Options) на вкладке Дополнительные параметры (Advanced
settings), как показано на рис. 5.8. В зависимости от вашего процессора вы
можете наблюдать значительное увеличение времени обработки данных, из-
менив параметр Максимальное состояние процессора (Maximum processor
state). Это довольно грубый, хотя и действенный механизм проверки быстро-
действия системы на более старых и медленных компьютерах.
Рис. 5.8  Изменение настроек процессора в Windows
В веб-браузерах присутствуют встроенные инструменты разработчика, с помощью

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

ствие отчетов, которые трудно или невозможно отследить при помощи Ана-
лизатора производительности.
Возможности и ограничения Анализатора

Анализатор производительности может помочь вам оптимизировать внеш-
ний вид отчетов, структуру модели данных и выражения DAX на пути до-
стижения идеального баланса между функционалом и быстродействием.
Если исключить внешние факторы, такие как работу в режиме DirectQuery,
нагрузку на емкости Premium или сетевые задержки, вы вполне можете за-
кладываться на то, что получение прироста производительности в Desktop
будет автоматически означать улучшение быстродействия и в службе Po
wer BI. В подавляющем большинстве случаев это будет именно так, а значит,
анализ производительности в Desktop можно рассматривать в качестве под-
ходящего первого шага на пути проверки быстродействия системы.
Но существуют и проблемы, связанные с масштабированием, которые
непосредственно влияют на производительность после развертывания ра-
бочего решения. Если вам приходится иметь дело с большими объемами
данных, обычно принято ограничивать их некоторым образом в тестовом
окружении с целью более быстрой и комфортной разработки. При публи-
кации отчетов используется уже полный рабочий набор данных. Очевидно,
что запросы к ограниченному набору данных будут выполняться быстрее,
и если разница будет существенной, результаты тестирования в Desktop
окажутся нерепрезентативными. Некоторые выражения DAX и визуальные
элементы начинают «тормозить» только при работе с большими данными,
так что вы не можете объективно сравнивать быстродействие даже в рамках
одного отчета или страницы. Это необходимо учитывать при проведении
тестов и оценок.
Если при выполнении тестов производительности вы не имеете возможности напря-
мую подключаться к рабочим наборам данных, озаботьтесь тем, чтобы в вашем рас-
поряжении была копия данных, приближенная по объему к рабочей базе.
Еще одним важным фактором при работе с Анализатором производи-

тельности является ваше географическое положение. Если все пользователи
вашей системы обращаются к ней, физически находясь в одном офисе, вы
можете проводить свои тесты также из этого офиса. Однако в случае, когда
ваши пользователи работают из разных мест, используют VPN или доступ че-
рез интернет, вы должны также проводить тесты для разных локаций, чтобы
учесть фактор сетевых задержек. Области применения методов оптимизации
при этом будут зависеть от ролей пользователей и влияния низкой произ-
водительности.
Если ваши пользователи работают из разных мест и у вас нет возможности запускать
тесты из их локаций, вы можете смоделировать приблизительно похожие сетевые
условия при помощи виртуальных машин (virtual machine – VM), поднятых в тех же
регионах. Арендовать виртуальные машины сегодня можно почти у любого облачно-
го провайдера, и за несколько часов теста вам придется заплатить совсем немного.
Ограничением Анализатора производительности в Power BI Desktop яв-

ляется отсутствие учета общей длительности операции. Это затрудняет воз-
можности анализа общего времени, которое потребовалось на выполнение
действия от начала до конца. Частично мы исправим данный недостаток
далее в этой главе, когда взглянем на логи.
Теперь же давайте рассмотрим примеры проблем, которые можно иден-
тифицировать при помощи Анализатора производительности.
Интерпретация и выводы о данных

от Анализатора производительности
Анализатор производительности прекрасно справляется с поиском медлен-
ных запросов и визуальных элементов. Сейчас мы рассмотрим несколько
таких примеров и подумаем, какие можно предпринять действия по опти-
мизации процессов.
Медленные запросы
Существует масса причин, по которым может страдать скорость выполне-
ния запросов. При тестировании в Power BI Desktop вы будете главным об-
разом обращать внимание на эффективность модели данных и выражений
DAX, особенно если работаете с локальным набором данных, содержащимся
в файле .pbix. Если исключить внешние факторы, обычно вмешивающиеся
после развертывания реального проекта, причины замедления запросов мо-
гут сводиться к следующим:
запрос возвращает объемный набор данных в виде результата;
запрос содержит обращение к сложным и неэффективным мерам;
запрос оперирует слишком большим набором данных, возможно с объ-
единениями с высокой кратностью;
модель данных не отвечает рекомендованным требованиям;
комбинация перечисленных факторов.
На рис. 5.9 продемонстрированы два табличных визуальных элемента из
отчета, показывающих суммы продаж и количество товаров с группировкой
по номеру счета (account number). Здесь используется простая мера с сум-
мированием по полю LineTotal и подсчет уникального количества товаров
красного цвета. Медленная (слева) и быстрая (справа) меры дают одинаковые
результаты, хотя выражения DAX используются немного разные.
Рис. 5.9  Таблицы с одинаковыми результатами, но разными мерами
На рис. 5.10 представлен фрагмент панели Анализатора производитель-

ности для наших таблиц. Обратите внимание, что на отображение таблицы
в первом случае потребовалось больше 26 секунд, а во втором – всего пол-
торы.
Рис. 5.10  Катастрофическая разница

в длительности выполнения запросов
Теперь давайте взглянем на выражения DAX для медленной и быстрой

мер:
UniqueRedProducts_Slow =
CALCULATE(
DISTINCTCOUNT('SalesOrderDetail'[ProductID]),
FILTER(
'SalesOrderDetail',
RELATED('Product'[Color]) = "Red"))
UniqueRedProducts_Fast =
CALCULATE(
DISTINCTCOUNT('SalesOrderDetail'[ProductID]), 'Product'[Color]
= "Red")
Меры выглядят похоже, и можно предположить, что между таблицами

SalesOrderDetail и Product есть связь в модели данных. Тогда почему одна из
мер настолько медленнее другой? Причина в том, что в первой версии меры
инициируется обращение к контексту строки (row context) из-за вызова
функции RELATED(). Мы еще вернемся к этому примеру в следующей главе,
когда будем перехватывать трассировки запросов. Если вы написали запрос,
подобный первому, и обнаружили, что он выполняется более 26 секунд, вос-
пользуйтесь трассировкой движка Analysis Services для обнаружения при-
чин. При анализе быстродействия отчетов всегда рекомендуется обращать
внимание на структуру модели данных и выражения DAX. Этому будут по-
священы отдельные главы книги, а с примером можно ознакомиться в файле
Slow vs Fast Measures.pbix.
Медленные визуальные элементы

Часто бывает, что время выполнения запроса DAX составляет лишь малую
часть от общей продолжительности формирования отчета. Визуальные эле-
менты могут медленно отрисовываться по следующим причинам:
использование внешнего содержимого, такого как изображения;
извлечение данных из API, например с целью получения географиче-
ских координат для карты;
сложные вычисления со множеством точек данных;
отсутствие оптимизации, что зачастую бывает при использовании
пользовательских несертифицированных визуальных элементов.
На рис. 5.11 показан визуальный элемент Карта с большим количеством
точек данных – всего на географической карте выведено более 27 тысяч
координат с широтой и долготой. В элементе визуализации применяется
алгоритм уменьшения количества точек и геокодируются данные.
На рис. 5.12 продемонстрирован фрагмент панели Анализатора произво-
дительности с трассировкой того же визуального элемента. При этом элемент
был единственным на странице отчета, и для чистоты эксперимента мы
переключились на него с пустой страницы. Обратите внимание, что катего-
рии Визуальное отображение (Visual display) и Другое (Other) в сумме за-
нимают более 4 секунд, что составляет большую часть времени отображения
отчета в целом.
Рис. 5.11  Карта со множеством точек данных
Рис. 5.12  Большая часть времени расходуется не на сам запрос
В этом конкретном случае вы могли бы изменить настройки визуального

элемента или применить фильтры для ускорения отрисовки визуализации.
Этот совет применим и к другим медленным элементам визуализации. При-
мер с географической картой вы можете посмотреть в файле Map with Many
Points.pbix.
Если проблемный визуальный элемент не удается оптимизировать, вы
всегда можете заменить его другим элементом, несмотря на определенные
компромиссы. Кроме того, вы можете рассказать свою историю о данных со-
всем иначе, с использованием совершенно других визуализаций.
Эффект от добавления новых визуальных элементов

Ранее в этой главе мы уже говорили о том, что при добавлении новых ви-
зуальных элементов в отчет будет увеличиваться время в категории Другое
(Other). Это можно заметить на панели Анализатора производительности.
Для реализации экстремального примера мы создали отчет с шестью прос
тыми визуальными элементами, после чего 19 раз продублировали этот на-
бор, получив в результате отчет со 120 элементами. После этого мы изменили
фильтрацию для каждого элемента, чтобы они генерировали свои собствен-
ные запросы. Шесть базовых визуальных элементов показаны на рис. 5.13.
Рис. 5.13  Элементы визуализации, продублированные в отчете
На рис. 5.14 отображен фрагмент панели Анализатора производительно-

сти при тестировании отчета со 120 визуальными элементами. Заметьте, что
запросы DAX отрабатывают практически мгновенно, тогда как львиная доля
времени содержится в категории Другое (Other).
Если вы знаете, что производительность ваших отчетов страдает от из-
бытка на них визуальных элементов, первое, что можно посоветовать, – это
избавиться от лишних из них. В большинстве случаев удобство отчетов не
ухудшится, а зачастую даже улучшится. Более конкретные советы по улуч-
шению дизайна отчетов мы дадим в главе 9.
В завершение этой главы рассмотрим возможности Анализатора произво-
дительности в отношении экспорта логов.
Экспорт и анализ данных о производительности  103
Рис. 5.14  Большая часть времени

расходуется на категорию событий Другое (Other)
Экспорт и анализ данных

Ранее в этой главе мы говорили о некоторых ограничениях Анализатора про-
изводительности в плане полноты предоставляемой информации. Лучший
способ погрузиться в детальный анализ логов – это импортировать их непо-
средственно в Power BI для дальнейшего разбора. В этом разделе вы научи-
тесь выгружать и преобразовывать логи, что даст вам возможность извлечь
из них больше ценной информации.
Анализатор производительности в Power BI хранит логи в формате JSON
со следующими характеристиками:
все действия пользователей и события, сгенерированные визуальными
элементами, располагаются на верхнем уровне документа JSON, в эле-
менте с именем events;
некоторые события содержат элемент с именем metrics, в котором мо-
гут находиться такие свойства, как длительность запроса, текст запроса
и метаданные визуального элемента, например его идентификатор
и тип;
также у событий есть дочерние элементы id и parentid, которые могут
быть использованы для определения иерархии событий типа родитель/
потомок. Это позволяет построить дерево событий.
На рис. 5.15 показан фрагмента лог-файла Анализатора производитель-

ности.
Рис. 5.15  Первые несколько элементов

в лог-файле Анализатора производительности
Прежде чем извлечь максимум пользы из сохраненных файлов, необхо-

димо выполнить с ними определенные действия. Мы уже упоминали ранее,
что действия пользователей и события визуальных элементов располага-
ются в файле на одном уровне. Сами события при этом не ассоциируются
с действиями пользователей, поскольку действия не содержат дочерних эле-
ментов. Первое, что мы должны предположить, – это то, что после действия
пользователя следующие несколько событий по хронологии будут отражать
визуальные изменения, порожденные этим действием. С целью отображе-
ния событий в виде дерева нам необходимо вывести новые столбцы для
группировки событий каждого действия и их связывания. Также мы можем
вычислить длительность событий путем вычитания времени начала из вре-
мени окончания.
На рис. 5.16 показан простой отчет DirectQuery, который мы будем исполь-
зовать для анализа файлов с логами.
Экспорт и анализ данных о производительности  105
Рис. 5.16  Отчет DirectQuery с четырьмя визуальными элементами
Лог-файл был создан при переключении на этот отчет с пустой страницы,

после чего было произведено обновление визуальных элементов на панели
анализатора. В итоге всего было зарегистрировано два действия пользова-
телей, что видно на рис. 5.17.
Рис. 5.17  Трассировка Анализатора производительности

для двух действий пользователя
Мы экспортировали эти данные и поработали с ними в файле Analyzing

Desktop Performance Logs.pbix. После преобразования данных в нужный нам
вид мы можем построить простое хронологическое представление с возмож-
ностью фильтрации по типам событий и визуальным элементам. Это пред-
ставление, показанное на рис. 5.18, можно использовать для исследования
последовательности и длительности событий.
Рис. 5.18  Последовательность событий и метрики производительности
На рис. 5.19 показан пример построения деревьев для каждого действия

пользователя. В этом примере мы использовали для выбора действий срез.
В результате получили полную информацию о событиях с визуальным под-
креплением.
Рис. 5.19  Дерево событий для пользовательских действий
Это представление содержит вычисление с именем FirstToLastSeconds,

отражающее количество секунд от самого раннего до самого позднего со-
бытия в нашей области применения. Таким образом, вы будете иметь при-
мерное представление о длительности действия пользователя до завершения

последнего события.
Вычисление длительности пользовательского действия с применением такого метода

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

довольно просты и основываются на ручном вводе номеров строк в файле
для выделения разных действий пользователя. Мы сделали это намеренно,
чтобы проиллюстрировать структуру файла JSON на небольшом примере.
Вы можете применить данный прием к своим файлам, при необходимости
добавив методику автоматической обработки логов для больших файлов.
Теперь, когда мы познакомились с Анализатором производительности
в Power BI, пришло время подвести итоги этой главы и двинуться дальше.
В этой главе мы познакомились со встроенным инструментом Power BI под
названием Анализатор производительности (Performance Analyzer), помога-
ющим оценивать быстродействие и эффективность действий пользователей
на основе визуальных элементов. На панели инструмента события отобража-
ются с разделением на категории обработки запроса, отрисовки визуальных
элементов и выполнения прочих действий. Это позволяет понять, где именно
возникли проблемы. Кроме того, с помощью Анализатора производительно-
сти можно оценить различные метрики, а также скопировать запросы DAX
и DirectQuery для дальнейшего разбора в сторонних инструментах. Вместе
с тем вы можете выгрузить целый лог-файл для будущего анализа.
Мы рассмотрели различные типы действий пользователей, перехватыва-
емые анализатором, и узнали, какие метрики производительности для них
используются. Также мы отметили случаи, когда действия трудно отличить
друг от друга.
После этого мы дали несколько полезных советов по проведению тестов на
производительность в Power BI Desktop, включая создание пустой страницы
в отчете, обеспечение единообразия условий и создание максимально со-
вместимой копии реальной базы для теста. Мы акцентировали ваше внима-
ние на том, что даже при успешной оптимизации в Desktop проблемы могут
появиться вновь при увеличении количества пользователей и повышении
объема данных в рабочей системе. Вы должны помнить, что всегда могут
вмешаться внешние факторы, влияющие на скорость работы опубликован-
ных в службе Power BI отчетов.
Далее мы посмотрели, как Анализатор производительности справляется
с идентификацией медленных запросов и визуальных элементов, и разо-
брали практические примеры для обоих случаев. Мы перечислили возмож-
ные причины замедления запросов и элементов визуализации и узнали, как
можно этому противостоять. Помимо этого, наглядно убедились в том, что

кратное увеличение количества визуальных элементов в отчете может при-
вести к существенному замедлению работы вне зависимости от скорости
выполнения запросов и быстроты отрисовки каждого конкретного элемента
визуализации.
В завершение главы мы узнали, какую дополнительную информацию мож-
но почерпнуть из лог-файлов при их экспорте. Мы смогли извлечь данные
о длительности пользовательских действий, хотя и использовали при этом
недокументированные методы. Также нам удалось визуализировать дей-
ствия пользователей с разбивкой на события в виде дерева. Все это способно
значительно повысить потенциал ваших действий по анализу производи-
тельности отчетов.
В следующей главе мы рассмотрим некоторые свободно распространяе-
мые внешние инструменты, которые вы сможете использовать в дополнение
к Анализатору производительности при проведении оптимизации ваших
отчетов, модели данных и запросов DAX.
Глава 6
Внешние инструменты
В предыдущих двух главах мы использовали инструменты и данные, предо-

ставляемые компанией Microsoft, для получения и анализа информации,
связанной с производительностью наших решений на базе Power BI. Сейчас
мы рассмотрим некоторые внешние инструменты, поставляемые бесплатно,
которые способны дополнить встроенные средства анализа производитель-
ности и вывести поиск узких мест на новый качественный уровень.
Инструменты, которые мы будем рассматривать, обладают богатым функ-
ционалом по документированию решений, их анализу и составлению реко-
мендаций, исправлению неудобств, связанных с работой Power BI, трасси-
ровке метрик производительности и выполнению запросов. Полный список
возможностей этих средств выходит за рамки данной книги, так что мы
сосредоточимся только на аспектах, способных помочь нам в анализе быст
родействия наших решений.
Рассматриваемые инструменты по большей части поставляются с откры-
тым исходным кодом и активно поддерживаются сообществом. Кроме того,
все они очень широко используются и признаны самой компанией Micro-
soft. Таким образом, Power BI Desktop сам проверяет установленные вами
инструменты и предоставляет вам доступ к ним непосредственно в своем
интерфейсе – на вкладке Внешние инструменты (External Tools). Более того,
некоторые из них будут автоматически подключаться к открытому в данный
момент файлу .pbix. На момент написания книги все эти инструменты хоро-
шо поддерживаются, и для них регулярно выпускаются обновления.
Однако, несмотря на то что обсуждаемые здесь инструменты были соз-
даны и поддерживаются экспертами, владеющими собственными консал-
тинговыми компаниями в области Power BI, не все они обладают полной
официальной поддержкой, и об этом стоит помнить. К примеру, в вашей
организации может действовать запрет на использование какого-то из этих
программных обеспечений. Будьте готовы к тому, что при необходимости
вы можете не получить быструю специализированную поддержку по работе
с тем или иным инструментом, как в случае с коммерческим лицензирован-
ным ПО.
Все инструменты, обсуждаемые в этой главе, могут подключаться к на-
борам данных Analysis Services в рамках Power BI Desktop, Azure Analysis
Services или службы Power BI. Таким образом, в этой главе мы будем под-
разумевать, что используемый вами инструмент уже подключен к набору
данных Analysis Services.
110  Внешние инструменты

Power BI Helper;
Tabular Editor;
DAX Studio и VertiPaq Analyzer.
Для некоторых примеров из этой главы мы подготовили сопроводитель-
ные материалы, на которые будем ссылаться при обсуждении тех или иных
приемов. Все нужные файлы располагаются в папке Chapter06 в хранилище
GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Perfor-
mance-Best-Practices.
Power BI Helper
Power BI Helper обладает целым рядом возможностей для исследования,
документирования и сравнения локальных файлов Power BI Desktop. Также
этот инструмент позволяет просматривать и экспортировать метаданные из
службы Power BI, такие как списки рабочих областей и наборов данных с их
свойствами. Power BI Helper можно загрузить по адресу https://powerbihelper.
org.
В предыдущих главах мы не раз указывали на то, как важно стараться со-
хранять объем наборов данных Power BI максимально небольшим, избавля-
ясь от лишних таблиц и столбцов. В Power BI Helper есть для этого необходи-
мые средства, так что этот инструмент вполне может быть включен в процесс
оптимизации решений перед их публикацией.
Поиск столбцов, занимающих много места

Обычно чем меньше размер модели данных, тем быстрее формируются от-
четы и выполняются обновления. Именно поэтому очень важно искать и ис-
ключать из датасетов столбцы, занимающие много места. Сейчас мы просто
познакомимся с подобной техникой, а в главе 10 будем подробно говорить
о способах снижения размеров наборов данных. Выполните следующие дей-
ствия для исследования характеристик набора.
1. Откройте ваш файл с расширением .pbix в Power BI Desktop, после чего
подключите утилиту Power BI Helper к своему набору данных.
2. Переключитесь на вкладку Modeling Advise.
3. Обратите внимание, что в открывшемся списке столбцы отсортирова-
ны по размеру (колонка dictionary size) от наибольшего к наименьше-
му. Здесь указан объем сжатых данных из этой колонки в мегабайтах.
На рис. 6.1 показан пример отображения данной вкладки.
Power BI Helper  111
Рис. 6.1  Вкладка Modeling Advise с колонками по убыванию размера
В приведенном примере мы видим, что данные в столбце UserSession

(колонка Attribute name) занимают порядка 45 Мб. Весь файл с расширени-
ем .pbix весит 172 Мб. Таким образом, один только этот столбец занимает
приблизительно четверть размера файла, что очень много. Вы должны при-
ложить все усилия, чтобы избавиться от подобных столбцов в модели данных.
Если же они необходимы вам для отчета, связей или расчетов, предпримите
все возможные меры для уменьшения их размера. Об этом мы будем под-
робно говорить в главе 10.
Файл Power BI Desktop в режиме Import содержит полную копию исходных данных.
Информация хранится в файле с расширением .pbix в виде файла бэкапа Analysis
Services (.abf). Даже если размер файла .pbix не соответствует в точности объему
набора данных, загруженного в память, для приблизительной оценки занимаемого
места таблицами и колонками он вполне годится.
Поиск неиспользуемых столбцов

Power BI Helper может помочь с поиском колонок в модели данных, которые
не используются. Переключитесь на вкладку Visualization и найдите соот-
ветствующий список. Удалить неиспользуемое поле можно, щелкнув по нему
правой кнопкой мыши и выбрав пункт Delete, как показано на рис. 6.2.
Учтите, что все изменения, которые вы сделаете в Power BI Helper, отра
зятся и в файле .pbix, открытом в данный момент. По умолчанию Power BI
Helper сохранит перед этим исходный файл в папке, указанной в верхней
левой области окна. Мы рекомендуем всегда создавать бэкапы подобным
образом, чтобы не удалить из модели что-нибудь нужное.
Рис. 6.2  Удаление неиспользуемых колонок в Power BI Helper
Поиск двунаправленных и неактивных связей

На вкладке Modeling Advise, которая была показана на рис. 6.1, справа при-
сутствует также секция со связями в модели данных. Ее можно использовать
для обнаружения двунаправленных связей в вашей модели. Такие связи могут
существенно замедлять выполнение запросов и тянуть за собой нежелатель-
ную фильтрацию, так что вам необходимо отдельно проверить все их на
предмет необходимости существования.
Поиск зависимостей в мерах

Power BI Helper показывает зависимости в мерах на вкладке Model Analysis.
Меры могут быть повторно использованы в других мерах, что бывает очень
удобно. В таких цепочках мер начальное звено часто называется базовой
мерой (base measure). Базовые меры могут повторно использоваться во мно-
жестве других мер, и Power BI Helper позволяет легко идентифицировать
все эти обратные зависимости. Эту информацию можно использовать для
оптимизации этих базовых мер, поскольку это может привести к ощутимому
росту производительности модели данных в целом. Также у вас могут быть
сложные меры, ссылающиеся сразу на несколько других мер. В этом случае
Power BI Helper поможет вам обнаружить такие меры и оптимизировать их
составляющие.
Как видите, Power BI Helper оказывает всестороннюю помощь разработ-
чику в поиске проблем, часто незримо присутствующих в любой модели
данных. Далее мы рассмотрим еще один очень полезный бесплатный ин-
струмент под названием Tabular Editor, который позволит вам еще глубже
погрузиться в модель и набор данных.
Tabular Editor  113
Tabular Editor
Tabular Editor доступен как в виде коммерческой версии, так и с откры-
тым исходным кодом. Первая предлагает более расширенные возможности
и специализированную поддержку, которая может оказаться очень полезной
разработчикам Power BI. Но, к счастью, бесплатная версия на момент напи-
сания книги содержит весь базовый функционал инструмента и может быть
загружена из хранилища GitHub по адресу https://github.com/TabularEditor/
TabularEditor.
Tabular Editor представляет собой инструмент для повышения произво-
дительности, который может быть эффективно использован в разработке как
дополнение Power BI Desktop или Microsoft Visual Studio. Мы не будем под-
робно останавливаться на всех функциональных возможностях этого инстру-
мента, поскольку это выходит за рамки данной книги. В то же время Tabular
Editor обладает огромной популярностью в среде разработчиков Power BI,
и мы настоятельно рекомендуем вам самостоятельно изучить этот инстру-
мент, если вы планируете проектировать модели данных производственно-
го масштаба. Вы можете начать с документации к Tabular Editor, в которой
описан весь основной функционал этого инструмента. Мы же подробно оста-
новимся на утилите, входящей в состав Tabular Editor, под названием Best
Practice Analyzer.
Использование утилиты Best Practice Analyzer

Tabular Editor имеет в своем составе очень мощное и эффективное расшире-
ние под названием Best Practice Analyzer (BPA). Этот инструмент позволяет
вам определять правила моделирования данных, которые могут быть сохра-
нены в виде коллекций. Примером такого правила может быть избегание ис-
пользования типов данных с плавающей запятой в числовых колонках. После
определения набора правил вы можете использовать инструмент BPA для
сканирования набора данных Analysis Services. При этом будет произведена
проверка всех объектов модели на соответствие определенным правилам
и составлен отчет.
После установки Tabular Editor откройте пункт меню Tools. Здесь вы мо-
жете запустить Best Practice Analyzer, а также настроить нужные вам правила,
что видно на рис. 6.3.
Если вы только что установили Tabular Editor, то обнаружите, что никаких
правил по умолчанию для Best Practice Analyzer не существует. Вы можете
начать с базового набора правил, подготовленного при поддержке Microsoft,
но для их установки вам придется выполнить некоторые действия вруч-
ную. В качестве ориентира вы можете использовать правила, определенные
в проекте Tabular Editor на GitHub по адресу https://github.com/TabularEditor/
BestPracticeRules.
Чтобы установить нужные вам правила, необходимо скопировать файл
BPARules.json, находящийся по ссылке выше, в папку %localappdata%\Tabular-
Editor. Вы можете ввести этот путь в Проводнике Windows (Windows File

Explorer) и получить доступ к нужной директории.
Рис. 6.3  Управление правилами BPA в Tabular Editor
Также вы можете воспользоваться инструментом Advanced Scripting, вхо-

дящим в состав Tabular Editor, для загрузки и копирования правил в нужную
папку. Просто вставьте приведенный ниже скрипт в этот инструмент, выпол-
ните его, после чего перезапустите Tabular Editor, чтобы правила вступили
в силу:
System.Net.WebClient w = new System.Net.WebClient();
string path = System.Environment.GetFolderPath(System.Environment.SpecialFolder.
LocalApplicationData);
string url = "https://raw.githubusercontent.com/microsoft/Analysis-Services/master/
BestPracticeRules/BPARules.json";
string downloadLoc = path+@"\TabularEditor\BPARules.json";
w.DownloadFile(url, downloadLoc);
Вам необходимо подключиться к набору данных Analysis Services в Tabular Editor,

прежде чем вы сможете запускать скрипты. В противном случае соответствующая
опция на панели инструментов будет неактивна.
На рис. 6.4 показан результат выполнения скрипта BPA в Tabular Editor.

Выделенными областями отмечены кнопка запуска скрипта и сообщение
в строке состояния об успешности его выполнения.
После загрузки правил вы можете просматривать их, изменять и добавлять
новые по вашему усмотрению. На рис. 6.5 показан интерфейс инструмента
после установки правил.
На рис. 6.6 видно, как выглядит редактор при открытом правиле.
Рис. 6.4  Правила BPA, загруженные при помощи Advanced Scripting
Рис. 6.5 Загруженные правила BPA в Tabular Editor

Рис. 6.6  Редактирование правила в BPA
Чтобы применить созданные правила к вашему набору данных, для начала

подключитесь к нему с помощью встроенных средств Tabular Editor. После
этого запустите BPA, нажав на клавишу F10 или выбрав соответствующий
пункт в меню Tools, как было показано на рис. 6.3.
Пример результатов, полученных из набора данных после запуска правил,
показан на рис. 6.7. Здесь можно особо отметить три важные опции на панели
инструментов, выделенные на рисунке:
Go to object: приводит к открытию скрипта модели для объекта;
Generate fix script: генерирует скрипт, который вы сможете впослед-
ствии применить к объекту, и копирует его в буфер обмена;
Apply fix: немедленно применяет скрипт к вашей модели. Будьте осто-
рожны с этой опцией и убедитесь, что у вас есть бэкап модели.
Получив результаты работы BPA, вы должны определиться с тем, какие из-
менения применять. Казалось бы, можно просто применить все предложен-
ные изменения и все. Однако мы настоятельно советуем вам внимательно
просмотреть список изменений и решить, какие из них стоит утверждать
и в каком порядке.
Правила BPA по умолчанию делятся на шесть категорий:
DAX Expressions;
Error Prevention;
Formatting;
Maintenance;
Naming Conventions;
Performance.
Рис. 6.7 Результаты работы BPA с выделенными важными пунктами
С целью оптимизации производительности мы советуем обратить при-

стальное внимание на пункты из категорий Performance и DAX Expressions.
Эти категории напрямую влияют на быстродействие запросов и операций
обновления данных. Остальные категории в основном нацелены на удобство
и обслуживание модели данных.
Лучшим способом для проверки результатов оптимизации является проведение
тестов на типовых сценариях. К примеру, если вы планируете оптимизировать три
независимые меры DAX, вносите изменения по одному и проверяйте эффект от
них отдельно. После этого выполните тестирование со всеми тремя изменениями.
Это позволит вам определить наиболее эффективные изменения и узнать, как ваши
действия влияют на производительность совместно. Также это поможет вам оценить
влияние на быстродействие системы разных шаблонов в отношении модели данных,
так что в следующий раз вы уже будете знать, на что обращать внимание в первую
очередь при оптимизации решения.
Итак, мы рассмотрели инструменты, способные помочь вам в выявлении

проблем с моделью и наборами данных. В завершение главы мы разберем
DAX Studio и VertiPaq Analyzer. Эти инструменты работают совместно и по-
зволяют получить больше полезной информации о наборах данных, а также
решать возникающие проблемы с моделями данных и выражениями DAX.
Кроме того, они способны облегчить написание запросов DAX и произвести
замер скорости их выполнения.
DAX Studio и VertiPaq Analyzer

DAX Studio, как ясно из названия, представляет собой инструмент для рабо-
ты с запросами на языке DAX. Он обладает очень интуитивно понятным ин-
терфейсом и предоставляет богатые возможности по исследованию и анали-
зу наборов данных Analysis Services. О запросах мы поговорим далее в этом
разделе, а сейчас обратимся к работе с наборами данных.
Движок Analysis Services уже много лет поддерживает работу с динамиче-
скими административными представлениями (Dynamic Management View –
DMV). К этим представлениям можно обращаться из Analysis Services для по-
лучения подробной информации об объектах наборов данных и операциях.
VertiPaq Analyzer использует публично документированные представле-
ния DMV для отображения того, какие структуры присутствуют в наборах
данных и как много места они занимают. Этот инструмент начинал свое су-
ществование в качестве отдельной утилиты для моделей данных Power Pivot
в Excel и до сих пор присутствует в таком виде. Но в этой главе мы обратимся
к его новой инкарнации в качестве встроенного механизма DAX Studio.
Важно отметить, что имя VertiPaq было изначально дано движку хранили-
ща столбцов в сжатом виде в рамках Analysis Services (Verti означает колонки,
а Paq – сжатие).
Анализ размера модели данных при помощи

VertiPaq Analyzer
В настоящее время VertiPaq Analyzer встроен в DAX Studio в виде инструмента
View Metrics, располагающегося на вкладке Advanced. Вы просто нажимае
те на кнопку, и DAX Studio запускает для вас DMV и отображает статистику
в табличном виде. Это показано на рис. 6.8.
Вы можете переключиться на вкладку Summary в секции Vertipaq Ana-
lyzer Metrics, как показано на рис. 6.9, чтобы узнать общий объем модели
данных и увидеть другую важную статистическую информацию.
Зачастую показатель Total Size будет превышать физический объем файла
на диске (с расширением .pbix или .abf, если это бэкап Analysis Services). Это
происходит из-за того, что при загрузке набора данных в память требуется
создание дополнительных структур, – особенно это касается датасетов в ре-
жиме Import.
В главе 2 мы говорили о том, как в хранилище Power BI происходит процесс
сжатия столбцов. Статистика в VertiPaq Analyzer позволяет судить о том, как
сильно может быть сжат каждый столбец и сколько места занимают данные.
Также этот инструмент может применяться для исследования других объ-
ектов модели данных, таких как связи.
На вкладке Columns можно узнать, есть ли в модели данных столбцы, за-
нимающие намного больше места по сравнению с остальными. На рис. 6.10
DAX Studio и VertiPaq Analyzer  119
показаны колонки, присутствующие в том же наборе данных, который

мы рассматривали на предыдущем рисунке. Как видите, из 238 колонок
одна (с именем Operation-EventText) занимает аж 39 % места! Любопыт-
но отметить при этом, что кратность или мощность (столбец Cardinality),
выражающаяся в количестве уникальных значений, этой колонки при-
мерно вчетверо ниже, чем у следующих по размеру столбцов, что видно
на рис. 6.10.
Рис. 6.8 Кнопка View Metrics запускает VertiPaq Analyzer
Рис. 6.9 Вкладка Summary инструмента VertiPaq Analyzer Metrics

Рис. 6.10  Один столбец поработил весь набор данных
На этом рисунке мы также видим, что тип (Data Type) этого столбца указан
как String, что подразумевает хранение алфавитно-цифровых символов. Из
всего этого можно предположить, что в этом столбце содержатся длинные
текстовые данные, плохо поддающиеся сжатию. На самом деле в этой ко-
лонке находятся тексты запросов DAX и DirectQuery из трассировки движка
Analysis Services, загруженной в Power BI. Это знание может позволить вам
принять решение о нецелесообразности хранения информации в модели
данных с таким уровнем детализации. В качестве альтернативы вы можете
осуществлять хранение подобных данных как-то иначе или просто ограни-
чить данные в этой таблице несколькими днями либо неделями.
Теперь давайте узнаем, как DAX Studio способен помочь нам проанализи-
ровать и повысить производительность решения.
Настройка производительности модели данных

и запросов DAX
Основным средством перехвата трассировок от Analysis Services является
SQL Server Profiler. При запуске трассировки вы должны четко понимать,
какие именно события вы хотите перехватывать, что требует определенных
знаний о том, какие события бывают и что они содержат. Но даже с этим
знанием работать с Profiler бывает не всегда комфортно, поскольку этот
инструмент изначально предусматривался для анализа трассировок от баз
данных SQL Server. Хорошие новости состоят в том, что DAX Studio может
запустить трассировку на сервере Analysis Services, после чего собрать, об-
работать, отформатировать и отобразить полученную информацию в своем
интерфейсе. Это позволяет выполнять и анализировать запросы, никуда не
переключаясь, используя при этом особый функционал, нацеленный именно
на работу с Analysis Services, что делает эту связку гораздо более удобной по
сравнению с применением SQL Profiler.
Перехват и повторный запуск запросов

Кнопка All Queries в разделе Traces на панели инструментов DAX Studio
позволит запустить трассировку набора данных, к которому в данный мо-
мент выполнено подключение. На рис. 6.11 показан экран DAX Studio после
запуска трассировки.
Рис. 6.11  Трассировка запросов запущена
После запуска отслеживания вы можете взаимодействовать с набором

данных за пределами DAX Studio, а вся информация о ваших действиях про-
должит накапливаться. Способ взаимодействия с датасетом зависит от того,
где он располагается. Если вы работаете с ним на локальном компьютере при
помощи Power BI Desktop, то можете просто открывать отчеты. В процес-
се будут генерироваться запросы, которые будет перехватывать DAX Studio
и выводить на вкладке All Queries в хронологическом порядке с указанием
длительности в миллисекундах. На рис. 6.12 показаны два запроса, перехва-
ченных в момент открытия страницы Unique by Account No из файла Slow
vs Fast Measures.pbix.
В главе 5 был представлен рис. 5.9, на котором были выведены два таблич-
ных визуальных элемента с одинаковыми данными, но с использованием
двух разных мер. На рис. 6.12 мы видим, что на выполнение быстрой вер-
сии запроса потребовалось всего 17 мс, тогда как медленная выполнялась
более 11,3 с. Мы щелкнули мышью по быстрому запросу, в результате чего
в основном окне открылся текст запроса. Теперь вы можете редактировать
запрос в процессе его оптимизации и проверять результаты. В предыдущей
главе мы выяснили, что запрос для меры UniqueRedProducts_Slow был написан
неэффективно. Вскоре мы познакомимся с техниками оптимизации запро-
сов DAX, но сначала узнаем, как можно перехватывать информацию об их
Рис. 6.12 Запросы, перехваченные DAX Studio
Получение информации о времени выполнения запросов

Чтобы получить детальную информацию о быстродействии запросов, необ-
ходимо воспользоваться кнопкой Server Timings, которая видна на рис. 6.11.
После запуска трассировки вы можете запускать запросы и использовать
вкладку Server Timings для просмотра процесса их выполнения движком,
как показано на рис. 6.13.
Рис. 6.13  На вкладке Server Timings

показана детальная статистика выполнения запросов
Как видите, здесь представлена вся нужная информация. Сокращения FE

и SE в левой части окна обозначают движок формул (Formula engine – FE)
и движок хранилища (Storage engine – SE). Движок хранилища отличается вы-
сокой скоростью выполнения запросов и многопоточностью, и в его обязан-
ности входит извлечение данных. В процессе извлечения движок хранилища
может применять простую вычислительную логику вроде фильтрации для
ограничения получаемого набора данных. Движок формул, наоборот, одно-
поточный, и он генерирует план выполнения запроса – физическую последо-

вательность действий, необходимых для достижения итогового результата.
Также в его зону ответственности входит выполнение основных вычислений,
включая использование объединений таблиц, сложных фильтров, агрегаций
и операций поиска. Наша задача – избежать того, чтобы запросы большую
часть времени выполнялись движком формул или запускали на выполнение
большое количество запросов в движке хранилища. Внизу слева на рис. 6.13
видно, что было запущено порядка 5 тыс. запросов в движке хранилища. При
этом в списке запросов справа видно, что многие из них возвращают всего
по одной строке, что довольно подозрительно.
Для сравнения взгляните на рис. 6.14, где показан процесс выполнения
быстрой версии запроса DAX.
Рис. 6.14  Вкладка Server Timings для быстрого запроса
Как видите, количество запросов в движке хранилища снизилось до трех,

а результат, как и ожидалось, был получен гораздо быстрее.
Движок Analysis Services использует технику кеширования данных для ускорения вы-
полнения запросов. В этих кешах содержатся несжатые результаты запросов, которые
могут быть использованы повторно для экономии времени на извлечении и распа-
ковке информации. Для получения объективных результатов тестирования быстро-
действия запросов необходимо предварительно нажимать на кнопку Clear Cache на
панели инструментов DAX Studio, которая показана на рис. 6.11.
Мы еще продолжим разговор об этих концепциях в следующих главах,

когда будем подробно обсуждать оптимизацию DAX и модели данных. Сей-
час же давайте попробуем поэкспериментировать с запросами в DAX Studio
и посмотрим, как это скажется на их производительности.
Изменение и настройка запросов

Ранее в этом разделе мы видели, как можно перехватывать запросы, сгенери-
рованные визуальными элементами Power BI, и отображать их текст. Сейчас
мы покажем один полезный трюк, связанный с использованием мер области
запроса (query-scoped measures), которые будут перекрывать исходные меры
в модели. С помощью этого приема можно удобно тестировать быстродей-
ствие запросов.
На рис. 6.15 показано, как можно найти нужную вам меру и, выбрав пункт
Define Measure в контекстном меню, перенести определение меры в редак-
тор запросов.
Рис. 6.15  Перенос определения меры в редактор запросов
Теперь мы можем модифицировать меру в редакторе запросов, и движок

будет использовать в расчетах именно ее, а не меру, содержащуюся в моде-
ли данных! Этот прием позволяет вам опробовать разные методы расчетов
в мерах без необходимости менять модель данных и запускать обновления
многочисленных визуальных элементов.
Помните, что этот способ не оказывает воздействия на набор данных,
к которому вы подключены. Вы можете оптимизировать выражения в DAX
Studio, а затем, по готовности, переносить изменения в Power BI Desktop/
Visual Studio. На рис. 6.16 показан пример изменения меры UniqueRedProd-
uct_Slow в области запроса с целью получения прироста производительности.
Описанная техника может быть применена и к изменениям в модели дан-
ных. К примеру, если вам необходимо исследовать влияние на производи-
тельность изменения типа связи между таблицами, вы можете запустить
запрос в DAX Studio до и после внесения изменения и провести сравнение
результатов.
Ниже мы приведем дополнительные советы по работе с DAX Studio:
изолируйте меры: выполняя оптимизацию быстродействия запро-
са, сгенерированного визуальным элементом отчета, комментируйте
в коде сложные меры и фиксируйте контрольную оценку производи-
тельности. После этого добавляйте меры в запрос по одной и замеряй-
те скорость. Это позволит обнаружить самые медленные меры в запро-
се и визуальном контексте;
работайте с трассировками Desktop Performance Analyzer: DAX Stu-
dio умеет импортировать файлы трассировки, сгенерированные ин-
струментом Desktop Performance Analyzer. Вы можете загружать файлы
с помощью кнопки Load Perf Data, располагающейся рядом с кнопкой
All Queries. Эти файлы можно перехватить, после чего поделиться ими
со специалистом по DAX или моделированию данных, который сможет

проанализировать их в DAX Studio, воспроизведя их поведение. На
рис. 6.17 показано, как DAX Studio форматирует данные, чтобы было
понятно, какой визуальный элемент или компонент отнимает больше
всего времени. Этот лог был сгенерирован после просмотра каждой из
трех страниц в файле Slow vs Fast Measures.pbix;
Рис. 6.16  После изменения мера дала лучшие результаты
Рис. 6.17  Трассировка Performance Analyzer

помогла определить узкое место отчета
экспортируйте/импортируйте метрики модели: в DAX Studio вы

можете экспортировать и импортировать метаданные модели VertiPaq
с помощью файлов с расширением .vpax. В этих файлах не содержатся
сами данные. Вместо этого в них находятся имена таблиц и столбцов,
а также определения мер. Если ничто не запрещает вам делиться мета-

данными о модели, вы можете передать эти файлы специалисту, чтобы
он помог вам их оптимизировать.
Итак, мы рассмотрели несколько популярных внешних инструментов, ко-
торые способны помочь вам в разработке решений на базе Power BI и обна-
ружении узких мест в сценариях. Давайте подведем итоги этой главы.
В этой главе мы представили и обсудили несколько полезных утилит, ис-
пользующих разные методы и подходы в работе с Power BI и помогающих
в обнаружении областей для улучшения производительности. Все их можно
применять в качестве дополнений к официальным инструментам от Micro-
soft в процессе оптимизации решений.
Мы узнали, что рассмотренные инструменты обладают достаточно бога-
тым функционалом, помимо управления производительностью, так что мы
настоятельно рекомендуем вам самостоятельно изучить их во всех подроб-
ностях и начинать применять в процессе работы. Единственной преградой
может быть то, что в бесплатных версиях приложений зачастую отсутствует
официальная поддержка производителя.
Первым инструментом, с которым мы познакомились, был Power BI Helper.
В его возможности входит идентификация столбцов, занимающих неоправ-
данно много места, неиспользуемых колонок, двунаправленных связей и за-
висимостей между мерами. Все эти аспекты тесно переплетаются с вопро-
сами повышения производительности.
После этого мы узнали об очень полезном инструменте Tabular Editor со
встроенным в него расширением Best Practice Analyzer (BPA). Эта связка по-
зволяет импортировать разработанные специалистами правила для моделей
данных и сканировать наборы данных на соответствие рекомендациям, свя-
занным с производительностью. Кроме того, с помощью BPA мы можете при
необходимости применить рекомендованные изменения к модели данных
после первого же открытия.
Далее мы познакомились с DAX Studio и VertiPaq Analyzer. DAX Studio яв-
ляется полноценным и развитым инструментом для написания и отладки
запросов на языке DAX, который ко всему прочему умеет перехватывать
запросы к наборам данных Power BI в реальном времени и анализировать
их быстродействие. Мы также научились создавать метрики, дающие пол-
ную информацию об объектах в наборе данных и занимаемом ими месте.
После этого мы поговорили о составляющих времени выполнения запро-
сов, вскользь упомянув о движке формул и движке хранилища и их роли
в процессе обработки данных запросов. Также мы научились получать до-
ступ к внутренним запросам VertiPaq, отправленным на исполнение. А воз-
можность использовать меры области запроса в DAX Studio позволила без

вмешательства в модель данных опробовать различные техники языка DAX
и оценить их эффективность.
На данный момент вы уже довольно много знаете об общих принципах
оптимизации работы в Power BI. Также вы познакомились с полезными ути-
литами, позволяющими измерять быстродействие запросов. В следующей
главе мы рассмотрим общие принципы комбинирования полученных на-
выков для поддержания высокой эффективности решений на базе Power BI.
Глава 7
Общие принципы
управления
производительностью
Мы начали эту книгу с описания основ управления производительностью

и важности определения адекватных целевых показателей на основе иссле-
дований пользовательского поведения. Мы выделили области, оптимизация
в которых способна положительно сказаться на производительности отчетов
и скорости обновления данных, после чего сосредоточились на архитектур-
ных концепциях и методах оптимизации. В главах 4–6 мы подробно погово-
рили об источниках данных и инструментах, способных помочь в процессе
мониторинга отчетов и повышения производительности запросов.
Показатели и инструменты, которые мы обсуждали до этого, фактически
являются строительными блоками процесса управления производительно-
стью (performance management). Однако успеха в этой области можно до-
биться только при использовании структурированного и легко воспроизво-
димого подхода к встраиванию постулатов повышения производительности
в жизненный цикл решений на основе Power BI. В этой главе мы изложим
основные принципы наладки процессов, следование которым поможет из-
бежать проблем с масштабированием для новых данных и предотвратить
снижение качества существующих.
Процесс управления производительностью можно условно разбить на
две фазы. Первая включает в себя мониторинг и обнаружение узких мест
решения на базе Power BI. Вторая ставит целью анализ первопричин сниже-
ния производительности и их устранение. Технические темы, изложенные
в предыдущих главах, должны лечь в основу процесса управления произво-
дительностью в Power BI, особенно это касается быстродействия отчетов.
Поскольку формирование отчетов является наиболее распространенной
областью использования систем бизнес-аналитики, мы намеренно реши-
ли сначала познакомить вас с общими принципами управления произво-
дительностью, после чего углубиться в конкретные приемы, применимые
в каждой области.
Налаживание воспроизводимого и упреждающего процесса повышения  129
По прочтении этой и шести предыдущих глав у вас будет достаточно ин-

формации для внедрения в жизнь первой фазы процесса управления про-
изводительностью. Получив все необходимые сведения об источниках воз-
никновения проблем, вы сможете переходить ко второй фазе. Именно на
ней будет сконцентрировано внимание в следующих главах книги, где мы
будем подробно говорить о способах оптимизации конкретных слоев, вклю-
чая структуру отчетов, модель данных и запросы на языке M.
налаживание воспроизводимого и упреждающего процесса повыше-
ния производительности;
обмен опытом и знаниями.
Налаживание воспроизводимого
и упреждающего процесса повышения
В главе 1 мы говорили о потенциальных негативных последствиях в работе
неоптимально настроенной системы бизнес-аналитики. Прекрасно, когда
есть инструменты и метрики для отслеживания подобных проблем. Но на
практике я чаще всего сталкиваюсь с тем, что такие инструменты начинают
использовать только после того, как возникшие проблемы с производитель-
ностью нанесут значительный урон предприятию – достаточный для того,
чтобы информация об этом дошла до руководства, разработчиков и адми-
нистраторов. Это не лучший сценарий для бизнеса по приведенным ниже
причинам:
производить структурные изменения в рабочем окружении бывает
очень проблематично, для этого недостаточно просто выкатить тех-
нические обновления. Кроме того, при таких обширных изменениях
на уровне отчетов или набора данных нередко требуется провести до-
полнительное обучение персонала и обновить всю инструкцию и до-
кументацию;
руководство может ставить сильно ограниченные сроки для решения
возникших проблем. В то же время поиск первопричин, разработка
обновлений и развертывание системы зачастую требуют достаточно
большого времени, и в условиях строгих ограничений разработчики
способны допускать еще более серьезные ошибки, которые могут при-
вести к новым проблемам;
организация может попросту не располагать техническим отделом,
способным решать масштабные проблемы, по причине недостатка ква-
лификации или численного состава. Это может приводить к большим
задержкам и росту недовольства пользователей системы.
Теперь давайте посмотрим, что из себя представляет цикл управления
производительностью.
130  Общие принципы управления производительностью
Цикл управления производительностью

Для приложения минимальных усилий по поддержанию эффективности
системы необходимо использовать упреждающий проактивный подход
к управлению производительностью. Этого можно добиться, представляя
управление производительностью в виде непрерывного цикла, показанного
на рис. 7.1.
Установка/обновление
контрольных целевых
показателей
Принятие Мониторинг
превентивных мер и хранение истории
Обнаружение проблем
Диагностирование и расстановка
и исправление приоритетов
Рис. 7.1  Цикл управления производительностью
Давайте рассмотрим каждую фазу отдельно.
Установка/обновление контрольных целевых показателей

Невозможно повышать производительность системы без возможности срав-
нивать результаты проверок и итераций. Для начала необходимо определить
контрольные ожидаемые показатели (baseline metric) для разных сценариев –
в идеале в известных воспроизводимых условиях. Именно эти показатели мы
называем контрольными, или базовыми, и именно с ними должны сравни-
ваться метрики, которые вы будете измерять в процессе функционирования
системы.
Давайте переведем разговор в практическое русло. Представьте, что вы
получили жалобы на низкую скорость формирования отчета от двух пользо-
вателей. При этом один из них ждал вывода около 15 с, а второй – около 45 с.
Если бы у нас не было никакой дополнительной информации, мы вынужде-
ны были бы спрашивать об обстоятельствах проблем самих пользователей.
15 секунд – далеко не лучшее время для загрузки отчета, но в отсутствие
прочей информации мы не знаем, укладывается ли этот показатель в норму
для этого конкретного сценария. О 45 секундах можно сказать то же самое.
Налаживание воспроизводимого и упреждающего процесса повышения  131
Самым очевидным советом в данном случае было бы заранее запастись конт

рольным показателем для этого отчета, чтобы потом было с чем сравнивать.
Ниже приведены сопутствующие рекомендации по установке контрольных
целевых показателей:
контрольный целевой показатель целесообразно устанавливать в сред-
нее значение за несколько измерений по схожему сценарию. Мини-
мально допустимое количество измерений – три, но чем их будет боль-
ше, тем лучше;
создавайте целевые показатели для каждой комбинации из набора
данных и страницы отчета. Здесь очень важно хранить данные на уров-
не страницы, поскольку структура отчетов может меняться и одна стра-
ница может открываться намного дольше остальных;
производите замеры контрольных показателей для отчетов как в Po
wer BI Desktop, так и после публикации в службе. Сравнение значений
этих двух метрик до и после изменений способно выявить архитектур-
ные и структурные проблемы;
для каждого отчета отдельно сохраняйте контрольную метрику для
полностью холодного запуска, когда Power BI не открыт и набор данных
не сохранен в памяти. Значения этой метрики будут существенно от-
личаться от показателей горячего запуска, когда пользователь работает
с системой, а датасет уже находится в памяти;
рассмотрите возможность хранения разных контрольных показателей
для разных вариантов настроек безопасности. Правила безопасности
на уровне строк (row-level security) могут оказывать влияние на произ-
водительность, и вам может понадобиться иметь разные метрики для
разных групп пользователей;
также разные контрольные показатели можно хранить для разных
времен суток и географических регионов, чтобы учесть все варианты
сетевой нагрузки;
используйте одно и то же аппаратное обеспечение при установке конт
рольных метрик. Это позволит исключить из числа факторов техниче-
скую составляющую;
сохраняйте историю обновлений системы с полным описанием про-
изведенных изменений. Это позволит объяснить перепады в произво-
дительности отчетов при анализе, а также поможет сравнивать быст
родействие отчетов после внесения изменений.
Некоторые из перечисленных рекомендаций относятся исключительно
к отчетам Power BI. Однако вы можете применять эти принципы и к другим
областям Power BI. Например, вы можете установить целевые метрики для
операции обновления набора данных для Power BI Desktop и службы Po
wer BI.
Установка контрольных целевых показателей является одновременно пер-
вым и последним шагом в цикле, поскольку любые действия по повышению
производительности должны изменять поведение системы для всех пользо-
вателей, а не только для избранных. Так что вы должны соответствующим
образом обновить все нужные метрики.
Мониторинг и хранение истории

На момент написания книги история показателей производительности от-
четов хранится в Power BI за последние 30 дней. Для наборов данных из ра-
бочей области Premium вы можете обратиться к 60 последним обновлениям
датасета на портале администрирования. Этого может оказаться недостаточ-
но для построения полноценного графика с трендами и обнаружения спада
производительности, так что мы рекомендуем извлекать данные о метриках
производительности и хранить отдельно для построения полноценных диа-
грамм, как было показано в главе 4. Это также поможет выявить сезонные
изменения или, к примеру, повышение нагрузки в конце отчетных месяцев.
Вы должны регулярно сравнивать текущие значения показателей произво-
дительности с их контрольными отметками. Мы рекомендуем делать это как
минимум еженедельно, а для сглаживания выбросов вы можете применять
скользящие показатели.
Обнаружение проблем и расстановка приоритетов

Здесь все довольно понятно. При обнаружении расхождений между текущи-
ми показателями и целевыми вы должны проставить им соответствующие
приоритеты по степени влияния на удобство работы пользователей и ком-
пании в целом. Попытайтесь выделить метрики, критически важные для
скорейшего исправления. Иногда приоритеты будут зависеть не от вас, а от
мнения руководства.
Диагностирование и исправление
Обнаруженные проблемы нужно описывать и решать, как мы показывали
в двух предыдущих главах. Первое, что необходимо сделать, – это опреде-
лить источник проблемы. Используя отчет в качестве примера, вы можете
сделать вывод о том, что один из визуальных элементов долго прорисо-
вывается или мера долго считается. А может быть, проблема в фильтре
безопасности. В следующих главах мы детально рассмотрим методы реше-
ния проблем.
При решении проблем с производительностью отчета лучше всего начать с визуаль-
ных элементов. Даже если вам удастся устранить недостаток при помощи модифика-
ции запроса DAX или оптимизации модели данных, на безопасное внедрение этих
изменений может потребоваться немало времени, поскольку при этом могут быть
затронуты разные зависимости в наборе данных. Что касается слоя визуальных эле-
ментов, то в него можно вносить изменения независимо и даже в процессе работы
системы.
Принятие превентивных мер

Главное правило проактивных мер по повышению производительности со-
стоит в том, чтобы учиться на своих ошибках и никогда их не повторять. На
этом шаге вы должны обновлять стандарты, списки контрольных проверок
Обмен опытом и знаниями  133
и другие материалы, которыми пользуются ваши разработчики, с целью по-

вышения их квалификации и учета специфики системы.
Мы рекомендуем также внести в свой цикл разработки регулярные работы по про-
верке производительности системы. На начальных стадиях разработки достаточно
будет следовать приведенным выше рекомендациям, а перед развертыванием ре-
шений необходимо использовать средства оптимизации Power BI Desktop и внеш-
них инструментов, чтобы убедиться в отсутствии проблем с эффективностью. Также
желательно выполнять проверку на предмет масштабирования решения перед его
публикацией. Мы поговорим об этом в последней главе книги.
Теперь коснемся вопросов распространения знаний о методах повышения

производительности в рамках вашей организации.
Обмен опытом и знаниями

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

Одно из главных преимуществ Power BI состоит в доступности и простоте
использования для пользователей, не обладающих техническими знаниями
и не являющихся профессиональными разработчиками в области бизнес-
аналитики. Мы рекомендуем вам создать для таких пользователей следую-
щие руководства:
инструкция по созданию отчетов – здесь должны быть перечислены
стили, темы и приемы при построении отчетов, которых следует из-
бегать. Эта инструкция может быть представлена даже в виде файлов
шаблона Power BI (.pbit);
инструкция по моделированию/обновлению данных – сюда не-
обходимо включить основы моделирования данных на основе измере-
ний, указать на возможные ловушки при создании связей, рассказать
о способах избавления от ненужных данных и дать рекомендации по
работе в Power Query;
пользовательские ссылки на инструкции – Power BI позволяет на-
страивать по своему усмотрению ссылки на вспомогательные ресурсы,
так что вы можете обеспечить пользователям прямой доступ к своим
руководствам.
Теперь перейдем к профессиональным разработчикам.
Инструкция для разработчиков

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

К текущему моменту вы уже знаете, что для построения и оптимизации мас-
штабного решения на базе Power BI необходимо обладать очень разносто-
ронними знаниями. В результате зачастую для полноценного управления
производительностью требуется объединение усилий сразу нескольких спе-
циалистов или подразделений. К сожалению, нередко случается так, что вся
вина падает на одного из участников процесса тестирования. Разработчики
отчетов не могут должным образом проверять отчеты без понимания того,
что сами меры выполняются долго. Инженерам данных не удается оптими-
зировать датасет из-за чрезмерных нагрузок на источник данных. И это лишь
два из множества возможных сценариев.
Мы рекомендуем вам наладить процесс взаимопомощи в вопросах управ-
ления производительностью. Назначьте специалистов из разных отделов,
обладающих необходимыми для этого знаниями, для совместной работы
над эффективностью решения. Это могут быть как технические эксперты
в области моделирования данных, построения отчетов или DAX, так и, к при-
меру, узкопрофильные специалисты в предметной области: финансисты,
складские работники или инспекторы.
Также необходимо тщательно отслеживать все изменения используе-
мых продуктов при помощи технической документации и блогов. Хороший
пример – производительность мер, написанных на языке DAX. Компания
Microsoft зачастую влияет на эффективность своих решений, выпуская но-
вые функции под новыми именами с целью соблюдения обратной совмес
тимости.
Теперь, когда вы имеете представление обо всех фазах цикла управления
производительностью и необходимых навыках для его реализации, мы рас-
смотрим различные сценарии и ответственность групп пользователей.
Применение цикла управления

производительностью в разных сценариях
Инструменты бизнес-аналитики используются повсеместно, причем как
обычными людьми, так и глобальными корпорациями. Естественно, спо-
собы развития и поддержки аналитики будут меняться с ростом компании.
Чем больше организация, тем больше и необходимость централизованного
управления этими процессами. Но, по нашему мнению, даже в очень круп-
ных компаниях сильная среда бизнес-аналитики сохраняет баланс между
удовлетворением требований отдельных сотрудников и небольших групп
на основе принципов централизованного управления корпоративными дан-
ными. Эти сотрудники и группы часто сталкиваются с необходимостью по-
строения новой аналитики и выполнения различных преобразований дан-
ных, и они предпочли бы, чтобы технические требования и стандарты для
осуществления их работы были минимальными. Это может идти вразрез
с корпоративными принципами стандартизации, следования инструкциям
и использования оптимальных методов в области моделирования данных
и влиять на производительность.
Эти противоречивые потребности часто упоминают в свете баланса меж-
ду BI-системами самообслуживания (self-service BI) и корпоративными или
управляемыми ИТ-отделами BI-системами. Способы балансирования между
этими потребностями выходят за рамки данной книги, к тому же организа-
ции аналогичного размера могут использовать совершенно разные подходы
со своими компромиссами. Мы же опишем лишь общие сценарии работы
компаний, выделим типичные роли в них и распишем рекомендованные
обязанности для них с целью участия в общем процессе повышения произ-
BI-системы самообслуживания
К BI-системам самообслуживания (self-service BI) относятся системы, к ко-
торым обращаются пользователи с целью проведения анализа данных, не
обладая при этом большими знаниями и достаточными навыками в обла-
сти статистики и аналитики данных. Использование таких систем зачастую
является наиболее быстрым способом получения необходимых сведений
и построения выводов. Пользователи могут сами загружать, преобразовы-
вать и манипулировать данными наиболее подходящим для них способом.
Более того, в процессе работы они вольны использовать как официальные,
так и неофициальные источники данных, включая информацию из внешних
источников, например о численности населения или погоде. Эти системы
работают в основном по принципу модели с пассивным источником данных
(pull model), когда пользователи сами ищут нужную им информацию и строят
на ее основании отчеты.
В качестве примера можно привести сотрудника компании облачного про-

вайдера, которому необходимо проверить гипотезу о том, что одна из услуг
компании начинает пользоваться повышенным спросом в период после го-
сударственных праздников. Для этого ему требуется быстро объединить име-
ющиеся у него внутренние данные с информацией о праздниках с публично-
го сайта. В зависимости от модели управления результатами анализа смогут
пользоваться отдельные сотрудники компании, целые отделы или даже весь
штат компании, что может сказаться на производительности решения.
BI-системы на основе отдела или команды

Эта модель предполагает, что группа людей, наделенная общими функция
ми или целями, производит аналитические изыскания на основе набора
известных тем или инициатив. К примеру, в отделе закупок могут решить
проанализировать эффективность поставок, или команда, специализирую-
щаяся на маркетинге, – задаться идеей определить рентабельность каждого
канала продаж. В команде могут присутствовать как специалисты в пред-
метной области, так и эксперты по работе с данными, что может положитель-
но сказаться на производительности реализуемых решений. Как и в случае
с BI-системами самообслуживания, в BI-системах на основе отдела или ко-
манды также могут использоваться разные источники данных, а в рамках
командных систем некоторые сотрудники нередко применяют и BI-системы
самообслуживания. Обычно полученная в результате групповая аналитика
используется для нужд отдела или отчетов менеджмента.
Корпоративные или управляемые ИТ-отделами BI-системы

В этой модели централизованная команда занимается построением общих
сущностей, которыми впоследствии пользуются все сотрудники компании.
Речь идет о наборах данных, концептуальных моделях, отчетах, дашбордах
и т. д. Работа в этом случае ведется по принципу модели с активным источником
данных (push model), поскольку созданием и распределением данных занима-
ется централизованная команда, а все остальные являются пассивными потре-
бителями. Такие модели подразумевают высочайший контроль за качеством
данных и стандартизацией, начиная от именования объектов и принципов
моделирования данных и заканчивая инструкциями по построению отчетов
и использованию корпоративных тем. Централизованная BI-команда обычно
определяет инфраструктуру, архитектуру и все процессы, а также контроли-
рует применение командных BI-систем и систем самообслуживания.
Исходя из описания приведенных выше сценариев, можно сделать вывод о том, что
путь аналитики в плане зрелости решений начинается с BI-систем самообслуживания
и заканчивается корпоративными системами. И это верно, поскольку определенные
бизнесом аналитические потребности с ростом компании нуждаются в подкрепле-
нии и управлении со стороны технического отдела. Поэтому мы еще раз подчеркива-
ем важность применения соответствующих принципов управления производитель-
ностью для каждого из перечисленных сценариев – это поможет минимизировать
усилия по восстановлению общей эффективности системы.
Теперь перечислим типовые роли проекта бизнес-аналитики, участвую-

щие в процессе оптимизации производительности. Мы также предположим,
какие действия они могут предпринимать для создания высокоэффективных
решений вне зависимости от сценария и навыков пользователей. Поскольку
управление производительностью касается в первую очередь реализации
решения в Power BI, мы не стали включать такие роли, как распорядитель
данных (data steward). Обратите внимание, что в табл. 7.1 нет упоминания
о том, что только какие-то конкретные роли участвуют в сценарии. Любая
роль может принимать участие в любом сценарии, мы просто сконцентри-
руем внимание на основных ролях и их участии в решениях. Причина в том,
что BI-системы самообслуживания оказывают влияние на корпоративные
системы, и наоборот.
Таблица 7.1. Роли и ответственности в сценариях

Роль Ответственность
BI-системы Бизнес- • Используют Performance Analyzer для избавления от проблем.
самообслу- пользователи • Проверяют производительность системы после публикации на
живания рабочих данных
BI-системы Бизнес- • Как и в случае с BI-системами самообслуживания.
на основе пользователи • Пользователи, принимающие решения, устанавливают критерии
отдела или производительности.
команды • Используют инструкции от прочих специалистов и участвуют
в совместном анализе перед публикацией
Технические • Поддерживают централизованное управление бизнес-логикой,
специалисты например определяют вычисления.
и эксперты в пред- • Устанавливают рекомендованные правила для извлечения данных
метной области из источников и их преобразования
Аналитики данных / • Документируют возможные ловушки и рекомендуют обходные пути
разработчики для загрузки, моделирования и визуализации данных.
отчетов • Используют логи и внешние инструменты для оптимизирования
составляющих системы
Корпора Бизнес- • Как и в случае с BI-системами на основе отдела или команды
тивные пользователи
или управ- Технические • Как и в случае с BI-системами на основе отдела или команды,
ляемые специалисты но во взаимодействии с разработчиками
ИТ-отделами и эксперты в пред-
BI-системы метной области
Аналитики данных / • Как и в случае с BI-системами на основе отдела или команды,
разработчики но с большим уклоном в визуализацию данных.
отчетов • Анализируют содержимое на предмет проблем с производитель
ностью перед публикацией
Специалисты по • Устанавливают и документируют стандарты моделирования
моделированию данных с учетом особых требований отделов, не отвечающих
данных общим принципам.
• Анализируют содержимое на предмет проблем с производитель
ностью перед публикацией.
• Используют логи и внешние инструменты для оптимизирования
Таблица 7.1 (окончание)

Роль Ответственность
Разработчики ETL • Устанавливают и документируют стандарты загрузки
и преобразования данных.
• Анализируют содержимое на предмет проблем с производитель
ностью перед публикацией.
• Используют логи и внешние инструменты для оптимизирования
Архитекторы • Устанавливают и документируют архитектурные стандарты
решения решения.
• Используют логи и внешние инструменты для информирования
о будущих архитектурных решениях.
• Узнают о новых разработках, способных повысить производитель-
ность системы (то же касается и остальных специалистов)
Старшие бизнес- • Определяют процессы, роли и ответственности в управлении
аналитики / главы производительностью.
отделов • Участвуют в совместной работе по определению объективных
аналитики целевых метрик производительности.
• Следят за изменениями производительности решения с течением
времени и участвуют в обновлении инструкций и процессов
Теперь давайте подытожим все, что мы узнали из этой главы.
В этой главе мы описали суть воспроизводимых процессов, которые могут
помочь вам управлять производительностью в проактивной упреждающей
манере. Это очень важно для общей стабильности и комфортной работы
пользователей. Если вы сможете выявить и решить проблемы до момента
их повсеместного распространения, то сэкономите себе и компании много
времени и денег.
Мы узнали, как определять контрольные ожидаемые показатели в качестве
отправной точки для анализа производительности и как важно соблюдать все
необходимые условия в отношении модели данных, страниц отчетов, полно-
мочий пользователей и прочих факторов для установки этих показателей.
Также мы упомянули о важности хранения истории метрик производитель-
ности, чтобы в дальнейшем можно было отследить зависимости наподобие
сезонности. Кроме прочего, мы отметили, что при обнаружении проблем
необходимо правильно расставить приоритеты для предпринимаемых мер,
исходя из их ценности для компании и комфорта пользователей, а опыт
возникновения неполадок внести в стандарты и инструкции во избежание
повторения подобных ситуаций в будущем.
В завершение главы мы поговорили о важности совместной работы разных
отделов компании над вопросами производительности системы и написа-
ния инструкций, помогающих избежать распространенных ловушек. Мы
рассмотрели наиболее популярные сценарии и роли – от BI-систем само-
обслуживания до корпоративных или управляемых ИТ-отделами систем.
Поскольку небольшие системы самообслуживания всегда могут перерасти

в решения, которыми будут пользоваться отделы или целые организации,
мы особо подчеркнули важность следования инструкциям по поддержанию
производительности для каждой роли. Мы также прописали ответственности
для всех ролей применительно к участию в цикле управления производи-
тельностью.
В следующей главе мы начнем погружение во все области Power BI. Лю-
бое решение на базе Power BI начинается с данных, так что мы научимся
оптимизировать их загрузку и узнаем, как можно повысить эффективность
запросов на языке M.
Часть III
Извлечение,
преобразование
и визуализация данных
В этой части книги мы познакомимся с движком запросов M и узнаем, как

потребляются ресурсы во время загрузки, преобразования и обновления дан-
ных. Мы узнаем, как разные аспекты отчетов влияют на производительность,
каких приемов стоит избегать и какие есть альтернативы.
глава 8 «Загрузка, преобразование и обновление данных»;
глава 9 «Разработка отчетов и дашбордов».
Глава 8
Загрузка, преобразование
и обновление данных
До сих пор мы концентрировали свое внимание в основном на мониторинге

показателей производительности и изучении причин возникающих проблем.
Сейчас мы достигли следующей фазы нашего погружения в процесс управ-
ления производительностью в Power BI. Мы начнем говорить о том, какие
действия можно предпринять для решения возникших проблем с производи-
тельностью, обнаруженных при помощи инструментов, которые мы подробно
обсуждали в предыдущих главах. В каждой последующей главе мы будем
погружаться в разные аспекты Power BI и давать рекомендации в отношении
производительности. И начнем с процесса загрузки данных в Power BI.
Периодическая загрузка данных – это критически важная составляющая
любой аналитической системы, и в Power BI она применима к наборам дан-
ных в режиме Import. При этом обновление данных и связанные с ним опера-
ции преобразования данных могут быть одними из самых затратных в плане
задействования ресурсов центрального процессора и памяти. Выполнение
этих операций может негативно сказываться на комфорте работы пользо-
вателей и приводить к отказу обновлений. Объемные наборы данных, зани-
мающие большую часть памяти, да еще и со сложными преобразованиями,
будут стремиться задействовать все имеющиеся в их распоряжении ресурсы.
А неоптимально выполняющиеся преобразования данных могут оказаться
настолько требовательными, что приведут к отказу операций обновления.
Более того, они могут очень серьезно замедлять работу системы, а в крайних
случаях вести к сбою Power BI Desktop.
В этой главе мы рассмотрим принципы работы движка преобразования
данных Power Query и методику написания высокоэффективных запросов.
Вдобавок научимся применять сильные стороны источников данных и из-
бегать ловушек при составлении запросов с целью минимизации использо-
вания ресурсов. Это принесет свои плоды как на этапе разработки набора
данных, так и после его публикации.
основные принципы преобразования данных;
свертывание запросов, объединение и агрегация;
использование диагностики запросов;
оптимизация потоков данных.
142  Загрузка, преобразование и обновление данных
Основные принципы преобразования данных

Главным достоинством Power Query является, безусловно, то, что этот ин-
струмент позволяет пользователю строить целые конвейеры из достаточно
сложных операций по преобразованию данных при помощи одного лишь
графического интерфейса. Каждое действие пользователя в результате ав-
томатически преобразуется в строку кода на языке M. Как итог мы получаем
очень простой способ доступа сразу к нескольким источникам данных и воз-
можность выполнять действия по преобразованию в нужном нам порядке.
При этом неоптимальный порядок выполнения шагов и их неправильная
конфигурация могут приводить к повышенному потреблению ресурсов и су-
щественному замедлению процесса обновления. Эти проблемы иногда могут
быть незаметны в Power BI Desktop, особенно при использовании небольших
наборов данных для тестирования, что является распространенной практи-
кой. Несмотря на это, нужно стараться всегда писать запросы в Power Query
максимально эффективно, чтобы впоследствии не возникали сюрпризы. Да-
вайте посмотрим, как Power Query расходует ресурсы.
Обновление данных, параллелизм

и использование ресурсов
При обновлении датасета в режиме Import в службе Power BI сам набор дан-
ных остается доступным онлайн. К нему по-прежнему могут обращаться
опубликованные отчеты, могут подключаться клиенты из Power BI Desktop
или Excel. Это возможно благодаря тому, что исходный набор данных остает-
ся на месте и обслуживает потребителей, тогда как в обновлении в фоновом
режиме участвует его созданная копия. Но за такое удобство приходится
платить, поскольку в момент обновления обе копии набора данных зани-
мают место в памяти. Более того, память расходуется и при выполнении
сопутствующих обновлению преобразований.
Вы должны учитывать, что для успешного выполнения полного обновления вам пона-
добится как минимум вдвое больше памяти в сравнении с хранением набора данных.
Также не забывайте, что чем сложнее будут заложенные в набор данных преобразо-
вания, тем больше памяти потребуется на вычисления. На практике это означает, что
для обновления набора данных размером 2 Гб вам может понадобиться минимум
4 Гб памяти.
Основные принципы преобразования данных  143
Вся работа по загрузке и преобразованию данных в Power BI выполняет-

ся движком обработки Power Query (Power Query mashup engine). При этом
в качестве хоста, как уже упоминалось в начале этой главы, используется
машина, на которой запущен движок обработки. Это может быть хост с Po
wer BI Desktop, службой Power BI, емкостью Premium или шлюзом. Каждая
таблица, участвующая в обновлении, обрабатывается в отдельном контейне-
ре вычисления (evaluation container). В Power BI Desktop каждому контейнеру
вычисления по умолчанию выделяется 432 Мб физической памяти. Если
контейнеру потребуется дополнительная память, будет использована вир-
туальная память, и контейнер будет буферизован на диске, что негативно
скажется на производительности.
Что касается количества одновременно обрабатываемых контейнеров, тут
все зависит от хоста. В Power BI Desktop число параллельно запускаемых кон-
тейнеров по умолчанию соответствует количеству логических ядер процес-
сора на компьютере. Но этот параметр может быть изменен вручную в раз-
деле Загрузка данных (Data Load) в панели настроек Power Query. Здесь же
вы можете изменить объем памяти, который будет выделяться для каждого
контейнера вычислений, что показано на рис. 8.1.
Рис. 8.1  Настройка одновременной загрузки таблиц в Power Query
Некоторые операции преобразования данных требуют дополнительной

памяти для временного хранения информации. Если лимит контейнера уже
исчерпан, такие данные будут сохраняться на диске, что повлияет на быстро-
действие операции.
Вы можете использовать встроенный в Windows Монитор ресурсов (Resource Monitor)
для отслеживания памяти, потребляемой Power Query. На вкладке Память (Memory)
найдите процесс с названием Microsoft.Mashup.Container. Если в колонке Завершено
(Commit) вы увидите гораздо большее значение, чем в столбце Рабочий набор (Work-
ing Set), значит, производится буферизация или подкачка данных. Чтобы избежать
этого в Power BI Desktop, вы можете увеличить в настройках объем памяти для каж-
дого контейнера вычислений. Но помните, что установка слишком большого значения
может привести к использованию всей доступной памяти и негативно сказаться на
времени отклика системы. Перед тем как менять этот параметр, убедитесь, что вы ис-
черпали все возможности по оптимизации запросов, о чем мы будем говорить далее.
В увеличении количества контейнеров в Power BI Desktop большого смыс-

ла, по сути, нет. При установленном значении по умолчанию на каждое ло-
гическое ядро процессора будет выделяться по одному контейнеру, и все они
будут обрабатываться параллельно. В зависимости от сложности операций
преобразования данных и фоновых процессов, запущенных на компьютере,
контейнеры могут очень сильно нагружаться. Наличие слишком большого
количества контейнеров может привести к замедлению обновлений из-за
попыток слишком многих операций выполняться одновременно и порож-
дения ненужной борьбы за процессорное время. В результате каждое ядро
процессора начинает выполнять несколько запросов, а источник данных
вынужден поддерживать множество параллельных подключений, хотя здесь
могут также существовать свои ограничения на количество подключений.
В случае использования Power BI Premium, Power BI Embedded или Azure
Analysis Services у вас не будет возможности изменить количество контей-
неров или объем памяти при помощи интерфейса, а лимиты будут зависеть
от плана SKU, и они устанавливаются компанией Microsoft. Однако с исполь-
зованием конечных точек XMLA (XMLA endpoint) вы можете вручную пере-
определить количество одновременно обрабатываемых таблиц и партиций.
Это можно сделать при помощи команды sequence в скрипте TMSL. Вы можете
использовать, например, SQL Server Management Studio для подключения
к вашему набору данных и выполнения скрипта. В приведенном ниже при-
мере мы использовали команду sequence для возможности запуска десяти
параллельных контейнеров. Обратите внимание, что здесь мы указали лишь
одну таблицу. Вы можете изменить скрипт по своему усмотрению, указав
нужные вам таблицы и партиции:
{
"sequence":{
"maxParallelism":10,
"operations":[
{
"refresh":{
"type":"full",
"objects":[
{
"database":"ExampleDataset",
"table":"ExampleLogs",
"partition":"ExampleLogs202112"
}
// здесь можно указать другие таблицы и партиции

]
}
}
]
}
}
Теперь давайте посмотрим, как можно ускорить обработку запросов в Po

wer BI Desktop.
Улучшение среды разработки

Работая с большими объемами данных, сложными преобразованиями и мед-
ленными источниками данных, Power BI Desktop зачастую не справляется
с нагрузкой, начинает медленно работать, а иногда и вовсе перестает от-
вечать на запросы. Одной из причин является то, что программа локально
хранит кеши данных для отображения предварительного просмотра для каж-
дого шага преобразования, и они обновляются в фоновом режиме. Другой
причиной может быть присутствие множества динамических запросов на ос-
нове параметра. При правильном использовании параметры запросов пред-
ставляют собой очень мощную технику в Power Query. При этом изменение
всего одного параметра может приводить к обновлению сразу нескольких
предварительных просмотров, что способно существенно замедлить работу
системы и негативно отразиться на нагрузке на источники данных.
Если вы испытываете подобные неудобства, вы всегда можете отключить
загрузку фоновых данных (Background Data) в настройках Power Query. Это
приведет к тому, что предварительные просмотры будут обновляться только
при выборе соответствующего шага запроса. Флажок Разрешить скачива-
ние в фоновом режиме для предварительного просмотра данных (Allow
data previews to download in the background) показан на рис. 8.2. Также вы
Рис. 8.2  Настройки из раздела Загрузка данных

здесь видите флажок Включить параллельную загрузку таблиц (Enable

parallel loading of tables). Его отключение может быть очень полезно при за-
пуске большого количества сложных запросов, когда вы уверены, что источ-
ник лучше справится с последовательно поступающими запросами. Обычно
это бывает при написании вручную машинных запросов для источника со
множеством объединений, преобразований и агрегаций.
Еще одним способом снижения нагрузки на источник в процессе разработ-
ки является использование простого бинарного параметра для ограничения
возвращаемых данных. На рис. 8.3 показан такой флаг с именем Develop-
mentFlag и возможными значениями 0 и 1.
После создания такого параметра вы можете применять его в своих за-
просах. На рис. 8.4 показано, как можно использовать условное выражение
в Расширенном редакторе (Advanced Editor) для учета этого параметра. Если
значение параметра установлено в единицу, то Power Query берет только
данные до 1 июня 2013 года с шага #"Filtered Rows". В противном случае
берутся результаты предшествующего ему шага Fact_Transaction. Это хо-
роший практический пример того, как в Power Query можно ссылаться на
предыдущие состояния запросов.
Рис. 8.3  Двоичный параметр с допустимыми значениями
Рис. 8.4  Использование двоичного параметра для ограничения объема данных
Если вы используете несколько источников данных и значения из одного

источника влияют на запросы к другому, с настройками безопасности по
умолчанию у вас могут возникать проблемы с быстродействием. Причина

этого в том, что Power Query делает все, чтобы предотвратить утечку дан-
ных из одного источника в другой из соображений безопасности. К примеру,
если вы используете значения из одной базы данных для фильтрации ин-
формации из другой, передаваемые вами данные могут быть перехвачены
нежелательными потребителями. Power Query предотвращает такие утеч-
ки, извлекая все данные локально и только затем применяя фильтр. На это
требуется больше времени, поскольку Power Query необходимо дождаться
окончания чтения данных. Кроме того, в этом случае Power Query не может
воспользоваться никакими приемами оптимизации в источнике данных,
включая индексирование.
Если вас не волнуют вопросы, связанные с безопасностью данных, вы мо-
жете установить в разделе настроек Конфиденциальность (Privacy) пере-
ключатель Уровни конфиденциальности (Privacy Levels) в положение Всегда
игнорировать параметры уровней конфиденциальности (Always ignore
Privacy Level settings), как показано на рис. 8.5. Здесь мы выполнили эту на-
стройку в глобальной секции, но вы также можете устанавливать ее и для
конкретного файла .pbix в соответствующей секции ниже.
Рис. 8.5  Настройка игнорирования параметров уровней конфиденциальности

может повысить производительность
Еще одной полезной техникой в Power Query является использование

ссылок для создания одного запроса на основе другого. Это бывает полез-
но, когда вам необходимо разделить поток данных на несколько форматов
или по отдельности фильтровать и преобразовывать подмножества данных.
Распространенной ошибкой является то, что таблицу, на которую произво-
дится ссылка, оставляют в наборе данных, хотя она напрямую не исполь-
зуется в отчетах. Даже если вы скроете ее от пользователей, данные из нее
все равно продолжат загружаться и занимать драгоценную память. В таких
случаях бывает уместно снять флажок Включить загрузку (Enable Load)
в контекстном меню запроса. Это позволит временно сохранить таблицу во
время обновления и уменьшит объем занимаемой набором данных памяти.
На рис. 8.6 показано, что в источнике CSV содержится две группы записей,
а именно Student и Course. После выделения этих групп в отдельные табли-

цы мы просто исключаем исходную таблицу из загрузки.
Рис. 8.6  Отмена загрузки

для промежуточных таблиц
Еще одна техника, помогающая повысить быстродействие запросов со

сложными преобразованиями данных, заключается в использовании функ-
ций буферизации (buffer functions). В Power Query вы можете воспользоваться
такими функциями, как Table.Buffer() и List.Buffer(). Применять их следует,
как ясно из названий, к объектам Table и List в Power Query, чтобы при-
нудительно сохранить их в памяти для дальнейшего использования, а не
передавать небольшими пакетами. Это бывает полезно при обработке опре-
деленного вида преобразований, например при извлечении целых таблиц
из отдельных колонок (допустим, документов JSON) или динамического
сведения/отмены свертывания при наличии большого количества уникаль-
ных значений, особенно с несколькими уровнями вложенности функций.
На функции буферизации стоит обратить внимание, если ваши операции
обновления завершаются ошибками с указанием на нехватку ресурсов.
Последним советом в этом разделе будет пересмотр необходимости при-
сутствия автоматических даты и времени в Power BI. При активации флажка
Автоматические дата и время для новых файлов (Auto date/time for new
files) из раздела Логика операций со временем (Time intelligence), пока-
занного на рис. 8.7, будет создана скрытая внутренняя таблица-календарь,
связанная со всеми полями календарного типа в наборе данных. Эта таблица
может занимать достаточно много места, если в вашем наборе данных боль-
шой интервал дат или присутствует много полей с датами и временем. Всегда
лучше использовать собственные календарные измерения, связанные только
с нужными вам датами в наборе данных, для которых необходимо будет вы-
полнять агрегацию по месяцам и годам.
Свертывание запросов, объединение и агрегация  149
Рис. 8.7  Настройки логики операций со временем в Power Query
Теперь рассмотрим способы снятия нагрузки с Power Query при работе

с объемными данными и снижения времени обновления.
Свертывание запросов, объединение

и агрегация
Хотя Power Query обладает собственным мощным движком преобразования
данных, он имеет возможность делегировать некоторые сложные операции
источнику данных, которые будут выполняться на языке, родном для кон-
кретного источника. Эта техника известна как свертывание запросов (query
folding), и фактически она означает перевод шагов преобразования данных
в Power Query в SQL-инструкцию SELECT, которая отправляется на выполнение
в источник.
Свертывание запросов представляет собой очень мощную технику, способную кри-
тически повысить производительность запросов. В результате выполнения этой опе-
рации сокращается объем данных, возвращаемых Power BI, что может существенно
снизить время обновления и увеличить эффективность запросов DirectQuery при ра-
боте с большими объемами данных на миллионы строк.
Для успешного выполнения свертывания запросов необходимо обладать

определенными знаниями и опытом. Чтобы проверить, было ли для опре-
деленного шага запроса выполнено свертывание, нужно щелкнуть по нему
правой кнопкой мыши и обратить внимание на пункт Просмотреть машин-
ный запрос (View Native Query), показанный на рис. 8.8.
Рис. 8.8  Активный пункт говорит о том,

что свертывание было проведено успешно
В идеале вы должны стремиться к тому, чтобы для последнего шага в ва-

шем запросе был активен пункт просмотра машинного кода, поскольку это
будет автоматически означать, что весь запрос был успешно свернут. На
первый взгляд здесь все просто, но необходимо четко понимать, какие опе-
рации могут быть свернуты, а какие непременно прервут цепочку свертыва-
ния запроса. Это зависит в первую очередь от источника данных, при этом
подробной и полной документации по этому поводу не существует. К тому
же не все источники данных поддерживают возможность просмотра машин-
ного запроса. Примером источника, в котором не реализована эта функция,
является Odata – протокол для построения и обращения к интерфейсу REST
API. При работе с такими источниками можно воспользоваться инструмен-
том диагностики запросов, о котором мы подробно поговорим в следующем
разделе.
Приведенные ниже операции обычно успешно свертываются в машинные
запросы:
фильтрация строк со статическими значениями или с использованием
параметров Power Query;
группировка и агрегация;
сведение столбцов и отмена свертывания;
простые математические и строковые вычисления, такие как конкате-

нация, которые могут быть легко преобразованы в запросы источника
данных;
удаление столбцов;
переименование столбцов;
объединение таблиц на основе общего атрибута;
слияние запросов (без использования нечетких соответствий) из од-
ного источника;
добавление запросов на основе одного источника.
Следующие операции обычно не свертываются:
изменение типа данных столбца;
добавление столбца с индексом;
слияние запросов из разных источников;
добавление запросов на основе разных источников;
добавление настраиваемых столбцов со сложной логикой расчетов, не
имеющей строгого эквивалента в языке источника.
Выполняйте все шаги, которые будут гарантированно свернуты, в начале запроса,
чтобы их выполнение точно производилось на стороне источника данных. Помните,
что первый же шаг, который не сможет быть успешно свернут, тут же прервет всю
цепочку свертывания запроса, и все дальнейшие операции будут выполняться исклю-
чительно локально – в движке Power Query, – даже если сами по себе они могли бы
быть свернуты. Поэкспериментируйте со своим запросом и по возможности устано-
вите такой порядок выполнения операций, который позволит максимально продлить
цепочку свертывания запроса.
Особое внимание обращайте на операции группировки, сортировки и слия

ния, которые не были успешно свернуты в Power Query. Эти операции для
своего выполнения требуют полной загрузки таблиц в Power Query, что при
работе с объемными наборами данных может занимать довольно продолжи-
тельное время и приводить к излишней нагрузке на ресурсы. Если операция
группировки не может быть передана на выполнение в источник, но при
этом вы уверены, что данные в базе уже отсортированы по столбцу груп-
пировки, вы можете повысить быстродействие запроса, передав функции
Table.Group() дополнительный параметр, GroupKind.Local. В этом случае Power
Query сможет выполнить операцию гораздо более эффективно, зная, что при
смене значения в столбце гарантированно меняется и группа. Такой допуск
делается исходя из предположения о том, что данные уже упорядочены по
этому столбцу и значения непрерывны.
Если вы хорошо владеете языком, родным для источника данных, то можете писать
пользовательские запросы вручную, а не полагаться на Power Query. Это гаран-
тирует вам, что ваши запросы будут переданы на выполнение источнику данных,
и может быть особенно важно и полезно, если вы хорошо знаете структуру базы
в источнике и можете использовать ее особенности, такие как подсказки или хинты
(query hints), для ускорения выполнения запросов. Сложные объединения и агрега-
ции также могут не отправляться на исполнение в источник данных, и в этом случае
лучше будет реализовывать эти операции при помощи пользовательских ручных
запросов.
Использование добавочного обновления

Для источников данных, поддерживающих свертывание запросов, в Power
Query реализован функционал добавочного обновления (incremental refresh).
Это крайне полезный прием, нацеленный на оптимизацию операций об-
новления данных. По умолчанию при обновлении набора данных в режиме
Import Power BI требует полной загрузки всех таблиц. Это означает, что все
данные, присутствующие в таблицах на момент обновления, просто выбра-
сываются. Таким образом обеспечивается гарантия того, что в Power BI загру-
жаются наиболее актуальные данные. Однако зачастую это приводит к тому,
что повторной загрузке подвергаются исторические данные, которые между
операциями обновления не менялись. Если вы уверены в том, что за время,
прошедшее с момента последнего обновления, ваш источник пополнился
новыми данными, а старые не подвергались изменениям, и так происходит
всегда, вы можете настроить отдельные таблицы в наборе данных Power BI
для использования добавочного, а не полного обновления. Для этого необ-
ходимо выполнить следующие действия.
1. Перед использованием добавочного обновления вы должны создать
два параметра с типом Дата и время и именами RangeStart и Ran-
geEnd для управления периодом обновления. Настройка этих парамет
ров показана на рис. 8.9.
2. Далее необходимо использовать созданные параметры в качестве ди-
намических фильтров для ограничения количества строк, возвращае-
мых запросом. Пример такой фильтрации показан на рис. 8.10. Здесь
в качестве поля для фильтрации используется колонка Invoice Date
Key.
Рис. 8.9  Параметры, требуемые для настройки добавочного обновления

Рис. 8.10  Настройка фильтра

для поддержки в запросе параметризованного диапазона дат
3. После настройки запроса для использования параметризованного диа-

пазона вы можете активировать добавочное обновление. Для этого мож-
но щелкнуть правой кнопкой мыши по таблице в Power BI Desktop и вы-
брать пункт Добавочное обновление (Incremental refresh). На рис. 8.11
показано, как можно для таблицы Fact Sale установить период, на протя-
жении которого будут храниться исторические данные (в нашем случае
шесть месяцев), и период для обновления (у нас это один день).
Рис. 8.11  Добавочное обновление для таблицы

Также в диалоговом окне добавочного обновления присутствуют две оп-

ции, позволяющие вам расширить контроль за ситуацией:
Обнаруживать изменения данных (Detect data changes): эта опция
позволяет вам выбрать колонку календарного типа в источнике дан-
ных, в которой хранится дата последнего изменения записи. Если тако-
вая имеется в источнике, вы сможете еще больше сократить количество
возвращаемых строк за счет выбора только тех из них, которые были
изменены в заданный период;
Обновлять только завершенные дни (Only refresh complete day): эта
опция дает возможность обрабатывать только полные завершенные
дни, что крайне критично при расчете некоторых метрик. Представь-
те, что вы считаете среднее дневное количество пользователей в веб-
приложении. Этот показатель не будет отражать реальную ситуацию,
если в расчет будут браться неполные дни. Допустим, вы настроили
ежедневное обновление данных на 2 часа ночи, чтобы сильно не на-
гружать сервер в активные часы. Установка этой опции позволит вам
обновлять данные только для записей, внесенных до полуночи.
Далее мы посмотрим, как встроенный в Power BI инструмент диагности-
ки может помочь в обнаружении и исправлении проблем с производитель
ностью.
Использование диагностики запросов

В Power BI Desktop вы можете воспользоваться встроенным инструментом
под названием Диагностика запроса (Query diagnostics) для детального по-
нимания того, что происходит на каждом шаге вашего запроса. Даже при
работе с достаточно простыми запросами с небольшим количеством преоб-
разований вам необходимо четко понимать, где именно располагается узкое
место, чтобы точечно направить усилия по оптимизации. Для активации
диагностики перейдите на одноименную вкладку в параметрах Power Query
и установите опции, показанные на рис. 8.12. Вам могут понадобиться не
все показанные установки, главное – активируйте флажки Агрегирован-
ный уровень (Aggregated) и Счетчики производительности (Performance
counters).
На этом этапе вам доступны четыре следующих вида логов, соответству-
ющих флажкам в настройках:
Агрегированный уровень (Aggregated): итоговое представление
с агрегированными операциями в виде единого лога. Все длительности
операций суммируются;
Подробный уровень (Detailed): детализированное представление без
агрегаций, которое может быть полезным при рассмотрении сложных
Использование диагностики запросов  155
проблем или случаев, когда агрегированное представление не дает

нужной степени гранулярности для поиска первопричин неполадок;
Счетчики производительности (Performance counters): каждые пол-
секунды Power Query делает снимок текущего использования памяти,
процессора и прочих показателей. Этими показателями можно пре-
небречь, если запросы выполняются быстро или все действия отправ-
ляются в источник данных;
Разделы конфиденциальности данных (Data privacy partitions):
помогает идентифицировать разделы, используемые внутри движка
с цельюсоблюдения конфиденциальности данных.
Рис. 8.12  Настройки диагностики в Power Query
Теперь давайте научимся осуществлять сбор информации и ее анализ.

Сбор диагностической информации в Power Query

Сбор диагностических сведений в Power Query не начинается сразу после
установки нужных настроек. Чтобы результаты трассировки были сохране-
ны на диск, вам необходимо вручную запустить процесс сбора информации
из меню Инструменты (Tools) в Редакторе Query Editor, как показано на
рис. 8.13.
Рис. 8.13  Средства диагностики в Power Query
Нажмите на кнопку Начать диагностику (Start Diagnostics), чтобы за-

пустить процесс сбора информации. С этого момента все выполняемые за-
просы и операции обновления будут автоматически сохраняться на диске
в виде лог-файлов. Вы можете запустить сколько угодно операций, но вы не
увидите результаты, пока не нажмете на кнопку Остановить диагностику
(Stop Diagnostics). После этого логи автоматически появятся в редакторе за-
просов, как показано на рис. 8.14.
Рис. 8.14  Загруженные логи запросов
Выполнять диагностику можно только из интерфейса редактора Power

Query. При этом будут фиксироваться все события, включая загрузку пред-
варительного просмотра и запуск отдельных шагов запроса. В дополнение
вы можете перехватывать события на вкладке Отчет (Report), что бывает
удобно при трассировке полного обновления таблицы или набора данных.
Ваш выбор будет зависеть от сценария, который вы отлаживаете. Вы можете
выбрать конкретный шаг запроса и использовать кнопку Шаг диагностики
(Diagnose Step) для его запуска с созданием отдельного файла трассировки
с именем выполненного шага.
Логи запросов могут оказываться очень объемными, что затрудняет работу с ними.
Редактор Power Query выполняет различные фоновые операции и кеширование для
ускорения выполнения запросов, так что в диагностике могут быть отображены не все
шаги. Мы рекомендуем запускать диагностику только для тех операций или таблиц,
которые вам необходимо проанализировать. Это позволит сократить размер логов.
Запускайте диагностику, выполняйте действие, затем сразу останавливайте трасси-
ровку и переходите к анализу логов.
Анализ логов Power Query

Структура лог-файлов Power Query разнообразна и может меняться с течени-
ем времени. Мы рекомендуем вам обратиться к официальной документации
по адресу https://learn.microsoft.com/ru-ru/power-query/querydiagnostics за разъ-
яснениями по поводу того, что скрывается за каждым полем.
В большинстве случаев нас будет интересовать поле Эксклюзивная дли-
тельность (Exclusive Duration) в агрегированном и подробном логах. В нем
указана продолжительность операции в секундах, что позволяет быстро най-
ти самые медленные действия. В документации от Microsoft описывается,
как можно отфильтровать лог-файл по имени шага или идентификатору.
Это позволяет легко обнаружить самое слабое звено цепи, но не дает пред-
ставления о зависимостях между операциями. Структура логов построена
с использованием иерархии типа родитель–потомок произвольной глубины,
которая зависит от сложности выполняемых операций.
Для облегчения анализа логов мы приводим пример функции, которая
может быть использована с целью приведения структуры файла к плоской
явной иерархии, которую проще визуализировать при помощи дерева деком-
позиции (decomposition tree). Функция находится в файле ParsePQLog.txt, ко-
торый можно загрузить из папки этой главы в репозитории GitHub. Она была
написана на основе функции, впервые появившейся в блоге Криса Уэбба
(Chris Webb) по адресу https://blog.crossjoin.co.uk/2020/02/03/visualising-power-
query-diagnostics-data-in-a-power-bi-decomposition-tree.
Мы также привели примеры визуализации разобранных диагностических
сведений. На рис. 8.15 показан фрагмент файла Query Diagnostics.pbix, в кото-
ром при помощи дерева декомпозиции определяются наиболее дорогостоя-
щая в плане ресурсов группа операций и ее потомки. Во всплывающем окне
вы видите, что шаг Level 2 выполняется около 29 секунд и загружает более
220 000 строк. Также мы видим выражение на языке SQL, отправленное в ис-
точник данных, что является подтверждением того, что свертывание запроса
было выполнено успешно.
Теперь взглянем на пример, в котором та же логика запроса будет реали-
зована двумя разными способами, т. е. с обращением к разным источникам
данных. Мы посмотрим, как это повлияет на свертывание запросов и их
производительность.
В рассматриваемом сценарии у нас есть хранилище данных, и мы хотим
создать широкую денормализованную таблицу в качестве временного реше-
ния. Мы возьмем таблицу фактов с продажами и обогатим ее за счет номи-
нативных данных из четырех таблиц-измерений с сотрудниками, покупате-
лями и т. д. Все данные хранятся в SQL Server. Для этого примера мы все эти
таблицы по отдельности загрузили в Power BI Desktop, что видно на рис. 8.16.
Затем мы сохранили данные из таблицы фактов, находящейся в базе данных,
в файле CSV с именем Fact Sale_disk, чтобы использовать его в качестве аль-
тернативного источника данных для сравнения.
Рис. 8.15  Иерархический вид лога запроса после сглаживания
Рис. 8.16  Исходные таблицы,

загруженные в набор данных
Будем выполнять объединение таблицы фактов с измерениями и после

каждого объединения разворачивать нужные нам столбцы. Мы можем пред-
положить, что при работе с этой версией запроса свертывание будет выпол-
няться успешно. Также создадим вторую версию запроса, в которой в ка
честве источника будет использоваться файл. Можно догадаться, что в этом
случае свертывание запроса выполняться не будет, поскольку операции объ-
единения и фильтрации будут применяться напрямую к файлу CSV на диске.
Разница между получившимися запросами показана на рис. 8.17. Как видите,
для запроса с именем FlattenedForAnalyst_NotFolded пункт контекстного меню
Просмотреть машинный запрос (View Native Query) не активен.
Рис. 8.17  Сравнение запросов с одной логикой,

но разными источниками
На рис. 8.18 показан результат сравнения обновлений двух запросов в пла-

не продолжительности выполнения и количества действий. Легко заметить,
что запрос, обращающийся к базе данных, выполнился намного быстрее – за
10 с против 34 с – по сравнению с запросом, у которого в качестве источника
стоит файл. Это не должно вас удивлять, особенно если задуматься о том, как
работает движок обработки Power Query. Для запроса, обращающегося к базе
данных, вся логика была объединена и послана в источник данных в виде од-
ного запроса. Что касается второго случая с использованием таблицы фактов
из файла и измерений из базы данных, то здесь Power Query приходится вы-
полнять запросы для извлечения данных из измерений с целью локального
объединения. Именно этим объясняется наличие такого большого количест
ва действий для второго запроса.
Рис. 8.18  У запроса со свертыванием

меньше время выполнения и меньше действий
Теперь, когда вы получили базовые знания и навыки в области поиска

узких мест средствами Power Query, пришло время поговорить о повышении
производительности применительно к потокам данных.
Оптимизация потоков данных

Поток данных (dataflow) Power BI представляет собой особый тип объекта
в рабочей области Power BI. Поток данных содержит такую же логику преоб-
разования данных, как и запросы на языке M в Power Query, о которых мы
говорили ранее. В нем располагаются определения одной или нескольких
таблиц, полученных в результате этих преобразований. А после успешного
обновления поток данных также включает в себя копию преобразованных
данных, сохраненных в Azure Data Lake.
Оптимизация потоков данных  161
Потоки данных очень похожи на объекты запросов, которые вы опреде-

ляете в Power BI Desktop, и это действительно так. Однако между ними есть
и серьезные отличия, которые мы привели ниже:
поток данных может быть создан только в веб-приложении Power BI
с помощью службы Power Query Online;
поток данных является обособленным объектом, который существует
независимо. Он не связан и не публикуется вместе с набором данных,
вместо этого наборы данных могут использовать потоки данных в ка-
честве источников;
существуют определенные интерфейсные и функциональные различия
между Power Query в Power BI Desktop и Power Query Online;
поток данных может быть использован в наборе данных или даже
в других потоках с целью организации централизованной логики пре-
образований.
Последнее отличие в приведенном выше списке чрезвычайно важно, по-
скольку оно, по сути, определяет смысл существования потоков данных. Они
призваны облегчить повторное использование данных без необходимости
дублировать операции преобразования данных и выполнять лишнюю обра-
ботку. Давайте рассмотрим применение потока данных на практике. Пред-
положим, в компании поощряется самостоятельная разработка отчетов, что
позволяет пользователям быстро делать выводы о данных. В результате было
выяснено, что многие пользователи обращаются к списку покупателей с их
свойствами, расположенными в двух различных источниках: финансовой
системе и системе управления информацией о клиентах. Вместо того чтобы
каждый пользователь ломал голову над тем, как правильно преобразовать
и консолидировать информацию о покупателях из двух источников, было
решено создать единый поток данных, к которому каждый пользователь
сможет обращаться.
Использование потоков данных – это отличный способ централизации обобщенной
логики преобразования данных и предоставления результирующих таблиц пользо-
вателям в удобном виде. В итоге пропадает необходимость выполнять одну и ту же
обработку для каждого набора данных. Как результат наблюдается падение общего
количества операций обновления данных и ускорение процесса разработки отчетов
за счет предоставления пользователям предварительно обработанных данных. Кро-
ме того, вы можете обновлять поток данных с целью повышения производительности
зависимых объектов без необходимости вносить изменения в сами эти объекты (при
условии что структура выходной таблицы не изменится).
В процессе разработки потоков данных используются все те же методы оп-

тимизации, которые применяются в Power Query и о которых мы уже упоми-
нали. В то же время потоки данных обладают некоторыми архитектурными
особенностями, позволяющими использовать дополнительные возможности
для оптимизации, которые приведены в списке ниже:
разные потоки данных для приема данных и их преобразования:
это позволяет загрузить непреобразованные данные в отдельный по-
ток, который обычно называется staging. В результате повышается

скорость преобразования данных, источник которых доступен локаль-
но и может быть использован повторно разными операциями измене-
ния данных;
отдельные потоки данных для сложной логики или разных ис-
точников данных: стоит задуматься о выделении сложных ресурсоем-
ких операций в отдельные потоки данных. Это позволит обрабатывать
и оптимизировать разные сущности независимо друг от друга. В ре-
зультате какие-то из них могут оказаться доступны раньше остальных,
поскольку не должны будут ждать окончания обработки всего потока
данных;
разделение потоков с разной периодичностью обновления: вы
не можете выбрать отдельные сущности в потоке данных и обновить
их, все они будут обновляться по расписанию. Таким образом, вам не-
обходимо разделять сущности с разными периодами обновления во
избежание ненужных операций загрузки и обработки;
рассмотрите возможность использования рабочих областей Pre-
mium: потоки данных, созданные в емкости Premium, обладают до-
полнительными возможностями, позволяющими повысить их про-
изводительность и повторное использование. Эти возможности мы
перечислим в следующем списке.
Ниже приведены функциональные возможности, нацеленные на повыше-
ние эффективности потоков данных, которые мы настоятельно рекомендуем
использовать. Обратите внимание, что эти возможности доступны только
при применении емкости Premium:
добавочное обновление: применительно к потокам данных этот
функционал действует так же, как в Power Query. Установка соответ-
ствующей настройки позволит существенно снизить время операций
обновления потока данных после его первой загрузки;
связанные сущности: вы можете использовать один поток данных
в качестве источника для других потоков. Это позволит разбить общую
логику на отдельные группы преобразований, на разные фазы и по-
вторно использовать данные с каждого этапа. В результате вы смо-
жете снизить затраты на разработку и минимизировать количество
дублирующихся преобразований и обновлений. На рис. 8.19 показано
использование специальной иконки при применении потока данных
в качестве источника. В этом примере объект Audit Log Files содержит
записи лога в формате JSON из журнала действий Power BI, о котором
мы говорили в главе 4. Пользователю нужно разложить этот лог на груп-
пы с разными колонками в зависимости от типа действия. Связанные
сущности – прекрасный способ повторно использовать данные из лога
без необходимости импортировать их в Power BI для каждой группы;
расширенная подсистема вычислений и вычисляемые сущности:
потоки данных, созданные в емкости Premium, могут воспользоваться
преимуществами расширенного ядра вычислений (Enhanced Compute
Оптимизация потоков данных  163
Engine), которое по умолчанию активно для лицензии Premium. Это по-

зволит существенно снизить время обновления для ресурсоемких пре-
образований, таких как объединение, фильтрация и группировка. До-
стигается такой прогресс за счет использования SQL-подобного кеша
с поддержкой свертывания запросов. На рис. 8.20 показана страница
параметров потоков данных с возможностью активировать улучшен-
ную подсистему вычислений;
Рис. 8.19  Визуальное отображение связанной сущности
Рис. 8.20  Включение расширенной подсистемы вычислений

в настройках потоков данных
Настройка расширенной подсистемы вычислений доступна только при использова-

нии других потоков данных в качестве источника. Вы можете говорить о наличии
вычисляемой сущности (computed entity), если поверх ее иконки нарисована молния,
как показано на рис. 8.21. Также на рисунке видно, что Power BI отображает всплыва-
ющую подсказку при наведении мышью на шаг Источник (Source), в которой указано,
что он будет выполнен во внешнем окружении.
Рис. 8.21  Вычисляемая сущность, обозначенная визуально
DirectQuery для потоков данных: при использовании вычисляемых

сущностей в качестве источников для наборов данных Power BI до-
пустимо обращаться к ним в режиме DirectQuery. Это бывает полезно
при наличии большого количества наборов данных, имеющих в своей
основе поток данных. Даже если поток данных один раз загружается
в Power BI из внешнего источника, применение режима DirectQuery
способно снизить нагрузку как на Power BI, так и на источник. Со-
гласно принципам размерного моделирования (dimensional modeling)
Ральфа Кимбалла, это может быть полезно, когда у вас объемные изме-
рения, но вы часто обращаетесь к небольшой их части и вам не нужно
большинство их атрибутов. В главе 10 мы будем говорить о размерном
моделировании более подробно. Режим DirectQuery устанавливается
при доступе к потокам данных как источнику в Power BI Desktop с по-
мощью коннектора Потоки данных Power BI (Power BI Dataflows).
В процессе настройки доступа вам будет предложено сделать выбор
между режимами Import и DirectQuery – так же, как и при подключении
к любому другому источнику, поддерживающему оба режима хране-
ния. В настоящее время существуют определенные ограничения для
потоков данных DirectQuery, такие как невозможность использовать
их с составными моделями. Обратитесь к официальной документации
от Microsoft для проверки допустимости вашего сценария.
В этой главе мы получили полное представление о принципах преобра-
зования данных в Power BI и способах сокращения времени обновлений.
Давайте подведем итоги и двинемся дальше.
В этой главе мы начали погружение в недра решений Power BI и первым
делом рассмотрели процессы загрузки и преобразования данных. Мы уви-
дели, что основная роль на этих этапах отводится Power Query и его движку
обработки с языком запросов M. Мы также узнали, насколько требователь-
ными к ресурсам являются операции обновления данных и насколько важно
уделять внимание оптимизации в слое Power Query.
Далее мы поговорили про параллельные вычисления и научились выпол-
нять соответствующие настройки в Power BI Desktop. Заодно рассмотрели
опции, позволяющие ускорить процесс разработки решения и обновление
данных в целом. Также мы узнали, как настроить параллельные вычисления
применительно к Power BI Premium, Embedded и Azure Analysis Services.
После этого переключились на процесс преобразования данных, особо
выделив типичные операции вроде фильтрации, объединения и агрегации,
способные замедлять работу системы. Мы изучили особенности очень важ-
ной возможности свертывания запросов, позволяющей существенно уско-
рить процесс за счет переноса вычислений на сторону источника данных, где
они обычно выполняются гораздо быстрее и эффективнее. Мы узнали, как
определить в Power BI Desktop, выполняется ли свертывание запроса, а за-
одно научились настраивать добавочное обновление, призванное снизить
количество загружаемых данных.
Далее мы рассмотрели такую важную тему, как содержимое логов диаг
ностики Power Query. Мы увидели, что анализировать структуру этих логов
бывает не всегда удобно, но при этом в них содержится очень полезная ин-
формация для оптимизации запросов и источников данных.
В завершение главы мы узнали, что из себя представляют потоки данных
и как они могут быть использованы для снижения интенсивности во время
загрузки и преобразования информации путем централизации общей логи-
ки и данных. Мы отметили, что в плане оптимизации производительности
потоки данных мало отличаются от Power Query. Однако при работе с ними
мы можем воспользоваться дополнительными возможностями, такими как
расширенная подсистема вычислений.
Теперь, когда вы узнали, как наиболее эффективно доставлять данные
в Power BI, давайте рассмотрим принципы оптимизации отчетов и дашбор-
дов, чтобы пользователю было комфортнее работать, а данных загружалось
меньше.
Глава 9
Разработка отчетов
и дашбордов
В предыдущей главе мы рассмотрели способы оптимальной загрузки данных

в Power BI с минимальной нагрузкой на ресурсы и затрачиваемым временем.
Медленные операции обновления данных не сказываются на комфорте ра-
боты пользователей с отчетами, поскольку обычно они выполняются в фо-
новом режиме в часы без пиковых нагрузок.
Теперь давайте переключим свое внимание на визуальную часть Power BI.
Выборы, которые вы делаете в этой области, напрямую влияют на работу
пользователей с точки зрения удобства и быстродействия. Мы в основном
будем акцентировать внимание на моментах, связанных с производительно-
стью, но отдельно будем упоминать и решения, которые могут положительно
повлиять на комфорт пользователя.
В этой главе мы узнаем, как работает визуальная составляющая Power BI
в отчетах и как она влияет на отправляемые запросы и нагрузку на дви-
жок. Это даст нам фундаментальные знания о поведении отчетов и поможет
определиться с методами оптимизации. Также мы отдельно остановимся
на распространенных ловушках при проектировании отчетов и посоветуем
альтернативные варианты реализации, которые позволят повысить произ-
водительность.
оптимизация интерактивных отчетов;
оптимизация дашбордов;
оптимизация отчетов с разбивкой на страницы.
Оптимизация интерактивных отчетов  167
Оптимизация интерактивных отчетов

Используя термин интерактивные отчеты (interactive report), мы подразуме
ваем стандартные отчеты в Power BI, которые были созданы в среде Power BI
Desktop. Эти отчеты состоят из динамических визуальных элементов, пред-
назначенных в первую очередь для просмотра на экранах компьютеров. При
этом элементы отчета могут менять размеры и реагировать на изменение
размера и разрешения экрана, следуя известному принципу What You See is
What You Get (WYSIWYG).
Сам термин интерактивный отчет является неофициальным и исполь-
зуется в этой книге для удобства и ясности изложения. Компания Microsoft
намеренно разделяет термины интерактивный отчет и отчет с разбивкой
на страницы (paginated report), при этом официально признан только второй
из них. Отчеты с разбивкой на страницы базируются на SQL Server Report-
ing Services (SSRS) и используют другую парадигму, о которой мы будем
говорить в конце этой главы.
С этого момента мы будем явно использовать только термин отчет с разбивкой на
страницы. Во всех остальных случаях, когда не будет специального уточнения, будут
подразумеваться именно интерактивные отчеты.
Отчеты строятся путем размещения отдельных визуальных элементов

на одной или нескольких страницах. Большинство визуальных элементов
управляются данными, а это означает, что им требуется вводная информация
для отображения своего содержимого. Визуальное представление Power BI
являет собой современное приложение на базе JavaScript, выполняющееся
в клиентском браузере. Таким образом, чем мощнее устройство, тем быст
рее выполняются скрипты на языке JavaScript и тем выше производитель-
ность отчетов. Учитывайте это при оценке производительности отчетов на
устаревшем оборудовании. Но в то же время не забывайте и о том, что даже
самый быстрый компьютер не способен обеспечить отчетам такого прироста,
как продуманный и четко реализованный процесс оптимизации самих от-
четов и наборов данных, на основании которых они построены.
Давайте посмотрим, как связаны между собой визуальные элементы и за-
просы, чтобы понимать, куда двигаться в плане оптимизации.
Управление визуальными элементами

и запросами
Важно сразу отметить, что визуальные элементы (visuals) в Power BI призваны
работать параллельно. Это оказывает своеобразное влияние на производи-
тельность. Открывая интерактивный отчет в Power BI, вы как бы запускаете
все визуальные элементы разом. В результате элементы на основе данных
тут же собирают и отправляют минимум по одному запросу к набору дан-
ных, причем эти запросы отправляются пакетами, которые выполняются по
168  Разработка отчетов и дашбордов
возможности параллельно. При этом даже тем визуальным элементам, ко-

торые не отправляют запросы, требуется определенное время центрального
процессора. Негативным побочным эффектом того, что Power BI по своей
сути является приложением JavaScript, является специфика работы браузера
со скриптами на языке JavaScript. Несмотря на природу параллельных вы-
числений, заложенную в визуальные элементы, по сути, они выполняются
последовательно в рамках одного потока центрального процессора, а это
означает, что общее процессорное время делится между ними. Таким об-
разом, фактически в любой момент времени обрабатывается только один
визуальный элемент. Это ограничение распространяется на все приложе-
ния JavaScript. В случае с Power BI это значит, что увеличение количества
элементов на странице приводит к повышению общего времени ожидания
процессора по причине конкурентной борьбы между ними.
Существует прямая связь между количеством визуальных элементов в отчете и соз-
даваемой им нагрузкой. А чем выше нагрузка, тем зачастую ниже производитель-
ность отчета. Создаваемая нагрузка разделяется между двумя областями: клиентским
устройством, обрабатывающим визуальные элементы, и набором данных, отвечаю-
щим на запросы. Сюда также включаются запросы, отправляемые во внешние источ-
ники данных в режиме DirectQuery. Таким образом, вы должны стремиться к макси-
мальному сокращению количества элементов на странице всегда, когда это возможно,
осознавая, что каждый новый элемент будет увеличивать нагрузку на единственный
поток центрального процессора. Также вы должны стараться настраивать элементы
так, чтобы они не посылали избыточно сложных запросов, а возвращали только ту
информацию, которая необходима для отображения пользователю.
Строгого количества визуальных элементов, превышение которого одно-

значно приведет к замедлению работы отчета, не существует. В некоторых
инструкциях пишут о критическом числе 20, но мы бы не хотели идти по этой
скользкой дорожке. Дело в том, что гораздо большее влияние на производи-
тельность отчета оказывает не количество элементов, а выбор их типов, на-
стройка набора данных, оптимизация DAX-выражений и пр. В результате два
отчета с одинаковым количеством визуальных элементов могут показывать
совершенно разную производительность. Вместо определения лимитов мы
рекомендуем вплотную заняться оптимизацией на основе установленных
целевых показателей и метрик, о которых мы подробно говорили в первой
части главы 7.
Давайте перечислим и детально рассмотрим рекомендации, касающиеся
визуальной части отчетов Power BI и нацеленные на повышение их произ-
Установите выбор по умолчанию в срезах/фильтрах

для первой загрузки
Если у вас довольно объемный набор данных, для извлечения данных из него
может потребоваться немало времени даже после проведения оптимизации.
По умолчанию Power BI не устанавливает никакого выбора в срезах и отчетах.

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

столбцов в базовом отчете
Пользователям зачастую нужно видеть в отчете детальную информацию
в табличном виде. Но обычно такая необходимость возникает не на началь-
ном этапе анализа. Лучше начать с вывода агрегированных данных и предо-
ставить пользователю возможность выполнять детализацию данных в узких
рамках заданного контекста. Эту концепцию иногда так и называют – отчет
с детализацией. Вы можете создать отдельную страницу для подробного
анализа, чтобы отчет не возвращал огромное количество строк без надоб-
ности. Давайте рассмотрим конкретный пример. Предположим, вам необ-
ходимо построить отчет о действиях пользователей на основе лог-файла.
Вместо того чтобы выводить в табличном виде все события, лучше будет раз-
бить аналитику на два этапа. На рис. 9.1 показан возможный вид страницы
с агрегированными данными по наиболее интересующим нас пользователям
с применением двух визуальных элементов.
Рис. 9.1 Агрегированный отчет по пяти пользователям
На рис. 9.2 продемонстрирована страница с подробным отчетом, кото-

рый может быть вызван из любого визуального элемента агрегированного
отчета.
Рис. 9.2 Детализированный отчет по конкретному пользователю
Объединяйте индивидуальные карточки в многострочные

или в таблицы
Очень распространенной практикой при построении отчетов является раз-
мещение базовых метрик в строку в верхней части отчета с использованием
отдельных визуальных элементов Карточка (Card). Но мы знаем, что каж-
дый элемент посылает свой отдельный запрос. Если меры находятся в одной
области видимости, движок хранилища данных (включая Analysis Services
в Power BI) зачастую способен извлекать данные и вычислять меры в одном
пакете. Однако в случае, если эти вычисления запрашиваются разными ви-
зуальными элементами, запросы будут выполняться отдельно и независимо
друг от друга и не смогут воспользоваться оптимизацией на стороне источ-
ника. Во избежание этого вы можете объединить метрики в Многострочную
карточку (Multi-row Card) или Таблицу (Table). В результате можно получить
все необходимые сведения при помощи одного запроса. На рис. 9.3 видно,
Рис. 9.3  Пять отдельных карточек – пять запросов DAX

что при размещении метрик в отдельных карточках будут отсылаться отдель-

ные запросы для каждого элемента. Этот пример взят из файла Many cards.
pbix, который вы можете загрузить из папки с сопроводительными материа
лами. Для проведения анализа в Power BI Desktop мы воспользовались ин-
струментом Performance Analyzer, о котором подробно говорили ранее в этой
книге. Как видите, каждый из пяти визуальных элементов отправляет свой
запрос DAX, и на их выполнение требуется примерно по 2 с.
Рис. 9.3  Пять отдельных карточек – пять запросов DAX
На рис. 9.4 показано, как изменится ситуация, если объединить наши мет

рики в одну многострочную карточку. Вы видите, что мы пришли всего к од-
ному запросу.
Рис. 9.4 Одна многострочная карточка – один запрос DAX
Также мы можем собрать наши меры в таблицу. Результат этого показан

на рис. 9.5. Здесь мы еще видим, что нам удалось обойтись лишь одним за-
просом.
Рис. 9.5 Одна таблица с пятью мерами – один запрос DAX
В данном примере мы использовали небольшой набор данных, так что раз-

ница для конечного пользователя здесь будет не так заметна. Но при работе
с большими данными и сложными вычислениями этот простой прием может
позволить пользователям сэкономить немало времени и нервов.
Используйте фильтр Ведущие N для ограничения данных

в отчете
При просмотре итоговой информации всегда лучше выводить несколько
элементов с наибольшими или наименьшими значениями показателей,
а не весь список. К примеру, в визуальном элементе по качеству обслужи-
вания клиентов могут быть показаны только десять покупателей с мини-
мальным уровнем удовлетворенности. Это позволит значительно снизить
объем передаваемой информации и повысить скорость формирования от-
чета. Существует два способа осуществить подобную фильтрацию. Первый
состоит в применении фильтра Ведущие N (Top N), доступного в визуальных
элементах Power BI на панели Фильтры (Filters). На рис. 9.6 показаны два
элемента визуализации: левый находится в своем исходном состоянии, тогда
Рис. 9.6  Левый элемент выводит все записи, а правый – только первые пять
как правый настроен на вывод первых пяти имен производителей с упоря-

дочиванием по SalesAmount.
Второй способ ограничить количество отображаемых записей заключается
в написании меры с использованием ранжирующих функций (ranking func-
tions). Хотя этот метод требует чуть большего количества усилий от разра-
ботчика, он позволяет выполнять динамическое ранжирование при помощи
значений в срезе или фильтре. А значит, пользователь получит возможность
сам выбирать количество элементов из предопределенного списка значе-
ний (5, 10, 20 и т. д.). Какой бы способ вы ни выбрали, мы рекомендуем вам
всегда тестировать решение с фильтром на ведущие записи и без него. В не-
которых случаях применение ранжирующего вычисления может, наоборот,
замедлить работу визуального элемента. И тогда от этого приема лучше будет
отказаться.
Переместите редко используемые срезы на панель

фильтров
Всегда хочется вместить как можно больше срезов в отчет, чтобы дать поль-
зователю возможность максимально настроить его под свои требования. Но
любой срез сам по себе является визуальным элементом и посылает запро-
сы для заполнения значениями. А когда пользователь делает выбор в одном
срезе, по умолчанию выполняется обновление всех остальных срезов с целью
актуализации своих элементов с учетом предпочтений пользователя. В ре-
зультате все срезы отправляют новые запросы в набор данных. И хотя такой
замкнутый функционал бывает очень полезен при работе с отчетами, иног
да он способен замедлить их работу, особенно если речь идет про большое
количество срезов и объемные наборы данных. В этих случаях имеет смысл
рассмотреть вариант переноса наиболее редко используемых срезов на па-
нель Фильтры (Filters). Это позволит уменьшить количество отправляемых
запросов во время интерактивного взаимодействия с отчетом, поскольку
фильтры посылают запросы к источнику только после непосредственного
вмешательства пользователя и не зависят от выбора в срезах.
Исключите ненужные взаимодействия пользователя

с отчетом
При выборе точки данных в Power BI по умолчанию производится пере-
крестная фильтрация всех остальных визуальных элементов. И зачастую
некоторые из этих действий не добавляют анализу ровным счетом ничего.
Мы рекомендуем всегда просматривать отчеты на предмет выполняемых
взаимодействий между элементами и избавляться от тех из них, которые не
приносят пользы. Это позволит снизить количество отправляемых отчетом
запросов, поскольку не все действия по выбору элементов в визуальных эле-
ментах будут приводить к обновлению других элементов отчета. Эта техника
применима и к взаимодействию срезов друг с другом. На рис. 9.7 показано,
как можно осуществить ручную настройку взаимодействий между элемен-
тами. Для этого необходимо выделить нужный элемент или срез и нажать
на кнопку Изменить взаимодействия (Edit interactions) в меню Формат
(Format). Элемент останется выделенным, и вы сможете включить или вы-
ключить взаимодействия. В данном случае в левом визуальном элементе
взаимодействие осталось включенным, а в правом мы его выключили. За
взаимодействия отвечают иконки в правом верхнем углу элементов.
Рис. 9.7  Выбор в срезе будет влиять

только на правый визуальный элемент, что видно по иконкам
Используйте всплывающие подсказки для снижения объема

и сложности запросов
Иногда при анализе вам требуется работать с большим количеством мер.
В таких случаях разработчики прибегают к помощи таблиц или матриц,
в которых выводят сразу все нужные показатели. Но если ваши меры требу-
ют серьезных вычислений, а наборы данных достаточно велики, подобный
подход может привести к существенному замедлению работы. В качестве
альтернативы вы можете вывести в отчете только критически важные меры,
а остальные перенести во всплывающую подсказку (Tooltip). Большинство
визуальных элементов в Power BI поддерживают работу с подсказками, ко-
торые отображаются при наведении пользователем мыши на точку данных
и фактически заполняются информацией по требованию. Подсказка уста-
навливается в свойствах визуального элемента и может представлять собой
либо список атрибутов, либо страницу отчета. Мы рекомендуем прививать
пользователям культуру использования всплывающих подсказок в рамках
содержательной части собраний и тренингов.
На рис. 9.8 показан табличный визуальный элемент, для которого отобра-

жается всплывающая подсказка в результате наведения мышью на вторую
строку. Справа видны настройки подсказки с указанием названия страницы
(TT-Visual count), используемой в этом качестве.
Рис. 9.8  С помощью подсказок выводится информация,

не обязательная к просмотру в исходном виде отчета
Проверяйте на производительность пользовательские

визуальные элементы и отдавайте предпочтение
сертифицированным элементам
Одним из преимуществ Power BI является его открытость к использованию
сторонних пользовательских элементов визуализации. Увы, некоторые из
них работают не совсем оптимально и не могут воспользоваться всеми улуч-
шениями, которые со временем вносят разработчики в визуальный фрейм-
ворк. Такие элементы могут работать медленно даже при взаимодействии
с быстрым оптимизированным набором данных. Мы советуем всегда про-
верять сторонние визуальные элементы на производительность при помощи
описанного в предыдущих главах инструмента Power BI Desktop Performance
Analyzer для поиска утечек. Используйте во время тестирования реальный
набор данных и сравните эти элементы со встроенными визуальными эле-
ментами Power BI на предмет перекрестного выделения и фильтрации. Так-
же мы рекомендуем вам отдавать предпочтение официально сертифици-
рованным элементам, проверенным специалистами компании Microsoft.
Если пользовательский элемент оказывается слишком медленным, лучше
отобразить нужную вам информацию при помощи других типов визуали-
зации – возможно, посредством нескольких взаимосвязанных элементов,
которые можно будет анализировать совместно. При этом стоит признать,
что есть пользовательские визуальные компоненты, которые очень сложно
или даже невозможно чем-то заменить.
Используйте технику сокращения числа запросов

для сложных отчетов
Еще один способ уменьшения количества запросов и повышения эффектив-
ности отчетов состоит в изменении поведения по умолчанию для взаимо-
действий элементов, срезов и фильтров. Вы можете сделать это в настрой-
ках Power BI Desktop в соответствующей секции. Это позволит отключить
взаимодействие между визуальными элементами по умолчанию и добавить
кнопку Применить (Apply) в срезы и фильтры. В результате пользователи
смогут менять значения сразу в нескольких срезах и фильтрах без отправки
сопутствующих запросов, а итоговый запрос сразу со всеми изменениями
будет отправляться по нажатии на кнопку Применить. Эти опции в настрой-
ках показаны на рис. 9.9.
Рис. 9.9  Настройка сокращения числа запросов в Power BI Desktop
Визуальные элементы отчета можно закреплять, что приводит к созданию

дашбордов, к теме оптимизирования которых мы и переходим.
Оптимизация дашбордов
При помощи дашбордов (dashboard) в Power BI пользователи имеют возмож-
ность собрать на одной странице отчеты и визуальные элементы. Для этого
необходимо воспользоваться техникой закрепления (pinning). Это самый прос
той способ создать единое пользовательское представление, состоящее из
самых важных элементов, на основе разных – даже не связанных друг с дру-
гом – отчетов. Дашборды в Power BI работают быстро и ведут себя иначе, чем
отчеты, поскольку всегда, когда это возможно, кешируют результаты запросов
и визуальные элементы. Это позволяет значительно снизить время загрузки
дашборда за счет отсутствия необходимости выполнять множество действий
по обработке данных по требованию. Power BI отправляет запросы и подго-
тавливает плитки (tiles) дашборда после обновления исходных данных.
Оптимизация отчетов с разбивкой на страницы  177
Визуальные элементы кешируются в момент закрепления на дашборде, а отчеты, на-

зываемые живыми плитками (live tiles), – нет. В связи с этим мы рекомендуем закреп
лять на дашбордах отдельные визуальные элементы вместо целых отчетов, чтобы
воспользоваться всеми преимуществами кеширования.
Существует также риск серьезного повышения фоновой нагрузки на си-

стему при использовании дашбордов. Это происходит из-за того, что плитки
дашборда должны учитывать контекст безопасности. Если вы используете
безопасность на уровне строк, значит, у вас будут возникать разные роли
и контексты, и Power BI придется генерировать уникальные кеши плиток
для каждого контекста безопасности. Для наборов данных в режиме Import
это происходит автоматически после обновления датасета, а для DirectQuery
плитки обновляются раз в час.
Таким образом, при наличии большого количества контекстов и объемно-
го набора данных есть риск отправки в короткий промежуток времени сотен
или тысяч фоновых запросов. Если вы не используете емкость Premium, са-
мым вероятным последствием этого станет увеличенное время обновлений,
поскольку для плиток обновление происходит в последнюю очередь. Но если
у вас есть емкость Premium, вам будет выделен фиксированный объем ресур-
сов, а это означает, что эти фоновые операции с большой долей вероятности
скажутся на работе пользователей.
В связи с тем, что обновление плиток выполняется автоматически и у вас
нет никаких способов повлиять на это при помощи настроек, мы рекоменду-
ем проводить тестирование с отключенной безопасностью на уровне строк,
чтобы определить, является ли обновление плиток причиной проблем с про-
изводительностью.
В заключительном разделе этой главы мы поговорим об отчетах с раз-
бивкой на страницы.
Оптимизация отчетов с разбивкой

на страницы
Отчеты с разбивкой на страницы (paginated reports) в Power BI используют
в своей основе технологию Службы отчетности SQL Server (SQL Server
Reporting Services – SSRS). Для определения отчетов при этом используется
XML-подобный язык Report Definition Language (RDL). Такие отчеты также
часто называют отчетами с точностью до пикселя (pixel-perfect), апеллируя
к тому факту, что они разрабатываются с оглядкой на возможность печати.
За основу берется предустановленный размер страницы (обычно это стан-
дартный лист размером A4), и разработчик размещает на макете элементы,
точно задавая их размеры и местоположение. Подобное представление от-
лично подходит для оперативных отчетов с большим количеством строк
и страниц, таких как счета-фактуры, поскольку в них можно задавать верх-
ние и нижние колонтитулы и отступы. Разработчик обычно не имеет пред-
ставления о том, сколько страниц будет в итоговом отчете. Для создания
отчетов с разбивкой на страницы существует отдельный инструмент под

названием Power BI Report Builder.
Многостраничные отчеты могут использовать как реляционные, так и ана-
литические источники данных, расположенные локально или в облаке. К по-
следним могут относиться многомерные источники по типу наборов данных
Power BI, об оптимизации которых мы будем подробно говорить в следую-
щей главе. Здесь же мы сосредоточимся на реляционных источниках, обыч-
но представленных в виде транзакционных баз данных вроде SQL Server
и Oracle Database.
Ниже приведены советы, которых мы рекомендуем придерживаться при
работе с отчетами с разбивкой на страницы:
используйте облачные источники данных: локальные источники
данных могут располагаться достаточно далеко с географической точ-
ки зрения, и доступ к ним должен осуществляться посредством шлю-
зов. Эта схема может оказаться гораздо более медленной по сравнению
с облачным хранилищем, особенно если оно располагается в домаш-
нем регионе Power BI;
используйте для доступа к аналитическим источникам средства
разработки запросов DAX: в состав Power BI Report Builder входят
построители запросов DAX и MDX для Analysis Services. DAX и MDX
представляют собой разные языки запросов, поддерживаемые служ-
бой Analysis Services. Указанные средства разработки запросов могут
быть использованы применительно к источникам с наборами данных
Power BI или к любой модели Analysis Services. Мы рекомендуем поль-
зоваться построителем запросов DAX для большей эффективности,
особенно при работе с табличными моделями;
используйте хранимые процедуры в источнике данных: хранимые
процедуры (stored procedures) представляют собой пример эффектив-
ной инкапсуляции бизнес-логики. Они могут быть повторно вызваны
в различных отчетах и использовать параметры для обработки разных
входных данных. При этом процедуры могут включать в себя сложную
логику, такую как циклы и работа с временными таблицами. Обычно
они выполняются очень эффективно за счет оптимизации на уровне
источника данных, включая кеширование планов выполнения;
извлекайте только нужные вам данные: отчеты с разбивкой на стра-
ницы позволяют выполнять агрегацию и фильтрацию данных прямо
в настройках визуализации. Однако это может замедлить выполне-
ние запросов и привести к увеличению загружаемых в отчет объемов
данных. Кроме того, использование этой техники может потребовать
дополнительных накладных расходов для отображения результатов.
В связи с этим мы советуем выполнять агрегацию и фильтрацию дан-
ных непосредственно в источнике при помощи хранимых процедур
или изменения реляционного запроса. Зачастую это будет быстрее по
сравнению с делегированием работы движку отчетов;
фильтрация набора данных против параметризации: отчеты с раз-
бивкой на страницы позволяют применять фильтр поверх уже извле-
ченных данных (фильтрация) или передавать его напрямую в источник
данных (параметризация). Давайте проиллюстрируем это на приме-

ре. Предположим, у нас есть отчет о продажах, который может быть
отфильтрован по странам. При использовании фильтрации (filtering)
заранее будут извлекаться данные обо всех странах, а когда пользова-
тель выберет страну, никакие дополнительные запросы отправляться
в источник не будут, а отбор будет произведен локально. Параметри-
зация (parameterization) предполагает отправку нового запроса после
выбора пользователем нужной ему страны и получение ограниченного
набора данных. Фильтрацию рекомендуется использовать в случаях,
когда пользователь с большой долей вероятности будет многократно
менять свой выбор – в нашем примере он может несколько раз менять
выбранную страну и сравнивать результаты. Здесь затраты на извле-
чение большего набора данных по сравнению с отображаемым могут
быть оправданы. При этом кеширование больших наборов данных для
каждого пользователя может негативно сказаться на быстродействии
вашей емкости;
избегайте использования вычисляемых полей: многостраничные
отчеты позволяют вам определить собственные пользовательские
поля в рамках результата запроса. К примеру, вы могли бы объеди-
нить какие-то строки или выполнить определенные арифметические
действия. Мы рекомендуем делать это на стороне источника данных,
чтобы вычисления производились заранее и были готовы для отправки
в отчет. Это может существенно повысить производительность при не-
обходимости возвращать большое количество строк;
оптимизируйте изображения: старайтесь использовать изображе-
ния как можно меньшего размера без серьезного влияния на их раз-
решение и качество. Использование сжатых форматов вроде JPG мо-
жет позволить снизить размер файлов, при этом специализированные
программы способны применять алгоритмы, позволяющие добиться
идеального баланса между размером и качеством. Старайтесь избегать
использования встроенных изображений, поскольку они могут уве-
личить размер отчета и негативно сказаться на процессе его отобра
жения. Лучше воспользоваться изображениями, сохраненными на веб-
серверах или в базах данных, – это повысит удобство сопровождения
системы за счет применения централизованного хранилища. Но при
этом не забывайте, что изображения, сохраненные на веб-сервере, мо-
гут загружаться дольше, если используется внешняя сеть.
Теперь давайте подведем итоги главы и пойдем дальше.
В этой главе мы сконцентрировали свое внимание на визуальном слое Po
wer BI, в котором проектируем наши отчеты. Мы узнали, что в Power BI сущест
вует два типа отчетов. Интерактивные отчеты содержат набор визуальных
элементов, таких как диаграммы и срезы, и они используются в большинстве
случаев. Отчеты с разбивкой на страницы базируются на технологии SSRS

и иначе называются отчетами с точностью до пикселя, поскольку проекти-
руются для дальнейшей печати.
Интерактивные отчеты включают в себя визуальные элементы, каждый из
которых отправляет запросы для отображения нужных ему данных. Power BI
по своей сути является современным приложением JavaScript, и визуальные
элементы в отчете можно рассматривать как блоки кода, выполняющиеся
параллельно. Это означает, что чем больше элементов у вас на странице
отчета, тем больше работы предстоит выполнить источнику данных. На са-
мом же деле браузеры не выполняют код JavaScript в параллельном режиме,
вместо этого вся работа возлагается на один поток центрального процессора.
Это приводит к тому, что с увеличением количества визуальных элементов
на странице растет и время ожидания ими своей очереди обработки про-
цессора. Из всего этого следует, что не стоит без необходимости размещать
в отчете чрезмерно большое количество элементов. Так вы сможете снизить
конкуренцию за процессорное время и повысить быстродействие отчета.
Также мы узнали, что действия пользователя в интерактивном отчете
могут приводить к отправке множества запросов. Как следствие это мо-
жет приводить к серьезным проблемам с производительностью при работе
с объемными наборами данных и наличием большого количества визуаль-
ных элементов и сложных мер, поскольку каждый щелчок мышью способен
инициировать отправку множества запросов, с которыми источнику будет
справиться нелегко. Вы должны принимать все меры, позволяющие снизить
плотность общения отчета с набором данных посредством запросов, вклю-
чая использование отчетов с детализацией по требованию и объединение
посылаемых запросов при помощи кнопок Применить.
Далее мы узнали, как при помощи дашбордов в Power BI можно агрегиро-
вать данные из различных отчетов и использовать кеширование для повы-
шения быстродействия. Попутно отметили, что обновление плиток после за-
планированного обновления может негативно сказаться на общем времени
обновления и комфорте для пользователей, особенно при наличии емкости
Premium.
В завершение главы мы познакомились с отчетами с разбивкой на стра-
ницы и узнали, как можно извлечь преимущество из использования реляци-
онного источника данных.
В следующей главе мы подробно поговорим о процессе моделирования
данных, и это будет одна из важнейших тем в книге. Просчеты при моделиро-
вании могут обойтись разработчику очень дорого и свести на нет все усилия
по оптимизации отчетов.
Часть IV
Модели данных,
вычисления и работа
с объемными наборами
В этой части книги мы научимся проектировать эффективные и интуитивно

понятные модели данных, избегая использования неоптимальных связей
и вычислений DAX. Мы также узнаем, как можно использовать агрегаты и со-
ставные модели для работы с большими наборами данных.
глава 10 «Моделирование данных и безопасность на уровне строк»;
глава 11 «Улучшаем DAX»;
глава 12 «Шаблоны работы с большими данными».
Глава 10
Моделирование
данных и безопасность
на уровне строк
В предыдущей главе мы познакомились с визуальным слоем Power BI и основ-

ной упор сделали на стремлении уменьшить нагрузку на источники данных за
счет снижения сложности и количества отправляемых запросов. Мы узнали, что
в этой области можно довольно легко добиться повышения производительно-
сти. Однако по опыту работы с большим количеством проектов на базе Power BI
мы можем сказать, что зачастую корень проблем лежит отнюдь не в визуаль-
ном слое, а на уровне набора данных, и негативный эффект по этой части может
быть гораздо большим. Кроме того, этот эффект может усиливаться, если проб
лемный набор данных используется более чем одним отчетом. А ведь повтор-
ное использование датасетов – это рекомендованная практика, направленная
на снижение дублирования данных и усилий по разработке решений.
В этой главе мы погрузимся еще на один уровень ниже – в моделирование
наборов данных в Power BI с акцентом на режим хранения Import. Структура
датасета – это критически важный аспект любого проекта, поскольку каса-
ется самого сердца Power BI и вследствие этого существенно влияет на про-
изводительность и быстродействие решения. Power BI предоставляет очень
богатые возможности по моделированию данных и обладает достаточной
гибкостью, что дает разработчикам большую свободу действий в выборе
стратегии. В то же время неправильно выбранное направление в отношении
модели данных способно свести на нет все усилия по оптимизации отчетов
и снизить их быстродействие даже при работе с наборами данных объемом
гораздо меньше 1 Гб.
Мы будем много говорить о дизайне модели данных, способах снижения
размера набора данных, создании эффективных связей и возможных ловуш-
ках при использовании безопасности на уровне строк. Мы также воспользу-
емся некоторыми инструментами и техниками, описанными в предыдущих
главах, для определения влияния структуры модели на ее производительность.
построение эффективных моделей данных;
ловушки при использовании безопасности на уровне строк.
Построение эффективных моделей данных  183
Построение эффективных моделей данных

Начнем с теоретических основ построения эффективных моделей данных.
Техники, которые мы будем обсуждать, разрабатывались с учетом удобства
использования, но в конечном счете предстали в виде идеальной концеп-
ции моделирования данных для движка Analysis Services в Power BI. Первым
делом познакомимся со схемой «звезда», являющейся родной для Analysis
Services и для работы с которой оптимизирован движок этой службы.
Теория Кимбалла и реализация схемы «звезда»

Моделирование данных можно представить как способ группирования и свя-
зывания атрибутов в наборе данных. Существуют разные взгляды на идеаль-
ный метод создания модели данных, и не все из них взаимоисключающие.
Но глубокое погружение в это идеологическое противостояние выходит за
рамки данной книги.
Мы же сосредоточимся на описании размерного моделирования (dimen-
sional modeling) – очень популярной техники, введенной компанией Kimball
Group более 30 лет назад. Многие считают этот вид моделирования идеаль-
ным для представления данных пользователям, и движку Analysis Services,
лежащему в основе Power BI, он отлично подходит. Размерное моделирова-
ние является отличной альтернативой включению всех полей в одну широ-
кую таблицу, представленную пользователю. Мы рекомендуем вам поближе
познакомиться с техниками Кимбалла, поскольку они описывают весь про-
цесс разработки BI-решения, включая сбор требований. Компания Kimball
Group опубликовала довольно много книг по этой теме, которые можно без
труда найти на их сайте по адресу https://www.kimballgroup.com.
Транзакционные базы данных оптимизированы для эффективного хране-
ния и извлечения данных и нацелены на исключение дублирования данных
за счет применения техники, получившей название нормализация (normal-
ization). Эта техника предполагает разделение связанных данных на разные
таблицы с объединением их по ключевым полям для извлечения нужных
атрибутов. К примеру, данные в информационной системе предприятия мо-
гут быть разбиты на тысячи таблиц с интуитивно понятными именами самих
таблиц и содержащихся в них столбцов.
Центральной концепцией размерного моделирования является схема, по-
лучившая название «звезда». Моделирование данных с применением схемы
184  Моделирование данных и безопасность на уровне строк
«звезда» (star schema) оптимально для нужд быстрого извлечения и анализа

информации при помощи отчетов, при этом эффективность хранения дан-
ных отходит на второй план. Простейшая размерная модель данных состоит
из таблиц двух типов:
таблица фактов (fact): в этих таблицах содержится количественная
информация в виде записей о происходящих событиях. Например, это
могут быть строки заказов клиентов или ответы респондентов в ис-
следовании;
измерение (dimension): здесь хранится описательная информация о тех
или иных атрибутах, которая используется для группировки и фильт
рации данных. В качестве примера можно привести календарные пе-
риоды, такие как кварталы и месяцы.
После определения таблиц фактов и измерений в нашей модели стано-
вится понятно, почему схема получила имя «звезда». В простейшем виде
такая модель содержит одну таблицу фактов, которая соединяется со всеми
измерениями подобно лучам звезды, что видно на рис. 10.1.
Таблица
измерения
Таблица Таблица
измерения измерения
Таблица
фактов
Таблица Таблица
измерения измерения
Рис. 10.1  Схема «звезда»
На представленной выше диаграмме показана таблица фактов с пятью

измерениями, просто чтобы поддержать сходство со звездой. При этом чис
то технически нет никаких ограничений на количество измерений, хотя их
избыток может привести к трудностям понимания модели. В следующем
разделе мы приведем практический пример схемы «звезда».
Разработка схемы «звезда»

Допустим, нам нужно спроектировать размерную модель (dimensional model)
для системы бронирования отпусков сотрудников. Мы хотим знать общее ко-
личество часов отпуска по сотрудникам, но при этом иметь возможность по-

смотреть детализацию бронирований вплоть до даты начала отпуска. Сейчас
нам нужно определиться с таблицами фактов и измерениями и разработать
схему данных. Kimball Group рекомендует разбивать процесс создания раз-
мерной модели на четыре этапа. Ниже мы перечислим их, а также укажем,
как именно эти шаги соотносятся с нашим конкретным примером.
1. Идентификация бизнес-процесса (бронирование отпусков).
2. Определение предельной гранулярности (одна запись на каждое бро-
нирование).
3. Определение измерений (Employee, Date).
4. Определение фактов (забронированные часы).
Теперь давайте взглянем на предполагаемую схему «звезда» для нашего
примера, показанную на рис. 10.2. Она содержит таблицу фактов и измере-
ния, которые мы определили в процессе размерного моделирования. Однако
вместо двух определенных выше измерений мы видим, что у нас присутству-
ют три измерения. Фактически измерение Date появляется на диаграмме
дважды, поскольку нам необходимо будет анализировать как даты выпол-
нения бронирования, так и даты начала отпусков. В этом случае мы имеем
дело с еще одной концепцией Кимбалла, называемой ролевым измерением
(role-playing dimension).
Date Booked
Employee Start Date
Live
Booking
Рис. 10.2  Схема «звезда» для системы бронирования отпусков сотрудников
На первых двух этапах происходит определение нашей цели и области

применения. Настоящая работа начинается на третьем этапе, когда мы опре-
деляем измерения. При проектировании схемы «звезда» мы обычно прово-
дим процесс денормализации (de-normalization) для предварительного объ-
единения связанных атрибутов в единое измерение там, где это возможно.
Денормализованные таблицы (de-normalized tables) могут содержать избы-
точные повторяющиеся значения.
Группировка значений, в сущности, осуществляется для упрощения биз-
нес-аналитики, а повторяющиеся значения не представляют большой проб
лемы для колоночного хранилища вроде Analysis Services, поскольку они

хорошо сжимаются.
Концепция группировки данных показана на рис. 10.3, где продемонстри-
рованы нормализованная и денормализованная версии измерения сотруд-
ников.
Таблица: Employee Таблица: Role Таблица: Employee_Role
Измерение: Employee
Рис. 10.3  Денормализация трех таблиц в единое измерение сотрудников
Здесь мы видим, что значение Analyst атрибута RoleName у нас дважды

повторяется в готовом измерении, поскольку у нас в штате есть два анали-
тика.
Измерение Date будет содержать все даты, а также их составляющие, ко-
торые могут понадобиться нам для анализа, такие как день недели, название
месяца, квартал, год и т. д. Обычно такая таблица генерируется при помощи
запроса в базе данных или скрипта на языке M или DAX. Мы не будем углуб
ляться в эту тему, поскольку она не имеет отношения к нашему примеру.
На заключительном шаге мы должны создать таблицу фактов. Поскольку
мы определились заранее с тем, что у нас должны храниться данные на уров-
не бронирования, мы можем включить в таблицу фактов поля, показанные
на рис. 10.4.
Таблица фактов: Leave Booking
Рис. 10.4  Таблица фактов Leave Booking

Мы представили простейший пример размерного моделирования, чтобы не услож-

нять демонстрацию. В целом же это отдельная наука, требующая тщательного изуче-
ния, и в реальных сценариях все может быть намного сложнее. Скажем лишь, что
существуют разные типы измерений и таблиц фактов, а также дополнительные таб
лицы, помогающие решать проблемы с гранулярностью. Мы лишь вкратце коснемся
этих тем, а если вам понадобится изучить теорию подробнее, вы сможете сделать это
самостоятельно.
Теперь рассмотрим еще одну важную концепцию из области моделирова-

ния данных, напрямую касающуюся Power BI.
Работа со связями типа «многие ко многим»

Одной из важнейших концепций Кимбалла, активно применяющихся в Po
wer BI, является связь типа «многие ко многим» (many-to-many relationships).
Этот тип связи применяется при моделировании сценария, в котором на обе-
их сторонах связи могут присутствовать дублирующиеся значения в ключе-
вом столбце. К примеру, у вас может быть таблица с плановыми значениями,
которые устанавливаются для каждого отдела ежемесячно, тогда как другие
транзакции анализируются на ежедневной основе. Последнее требование го-
ворит о том, что гранулярность в таблице с датами должна быть установлена
на уровне дня. На рис. 10.5 показаны несколько строк из таблиц в подобном
сценарии. Здесь мы выделили столбец YearMonth, который необходимо ис-
пользовать для связи таблиц на нужном нам уровне гранулярности. При этом
в обеих таблицах в этом столбце присутствуют повторы.
Calendar (с фильтром на первые два дня из каждого месяца) Budgets
Рис. 10.5  Дубликаты в ключевых столбцах в таблицах Calendar и Budgets
Это вполне допустимый сценарий, который может присутствовать в моде-

лях в самых разных вариациях. При попытке создать в Power BI связь между
столбцами с дублирующимися значениями вы обнаружите, что тип связи
можно указать только «многие ко многим», как показано на рис. 10.6.
Рис. 10.6  Настройка связи «многие ко многим»
После указания корректного типа связи Power BI начнет отображать пра-

вильные результаты в визуальных элементах. К примеру, если вывести сум-
марные значения по полю Budget с использованием среза по полю Month-
Name из таблицы Calendar, вы получите правильные числа, что видно по
рис. 10.7.
Рис. 10.7  Правильные расчеты

с использованием связи типа «многие ко многим»
Итак, мы увидели, где и как можно использовать связи типа «многие ко

многим», но рекомендуем вам применять их с большой осторожностью и же-
лательно на небольших наборах данных.
Вы должны избегать использования связей типа «многие ко многим» при работе

с объемными наборами данных, особенно если на обеих сторонах связи будет много
строк. Быстродействие таких связей всегда будет ниже по сравнению со стандартны-
ми связями типа «один ко многим», а в условиях объемного набора данных и с при-
менением сложных выражений DAX разница может оказаться колоссальной. Мы ре-
комендуем использовать вместо связей типа «многие ко многим» таблицы-мосты
(bridge tables), позволяющие прийти к двум связям типа «один ко многим». Также вам
придется немного переписать меры.
Во избежание использования связей типа «многие ко многим» с сопут-

ствующим им неминуемым снижением производительности вы можете при-
бегнуть к альтернативному подходу с созданием в модели данных новых
таблиц, именуемых мостами. На рис. 10.8 показан этот подход. Заметьте,
что обе связи имеют тип «один ко многим». В таблице-мосте содержатся
пары значений ключевых столбцов из двух связываемых таблиц, образуя
тем самым уникальные строки. Для этого нам пришлось добавить ключевой
столбец BudgetKey в таблицу Budgets.
Рис. 10.8  После добавления таблицы-моста связи обрели тип «один ко многим»
Также вам придется внести небольшие изменения в расчеты, чтобы они

учитывали наличие таблицы-моста. А именно вам нужно будет обернуть
каждую меру в функцию CALCULATE() с явным указанием фильтра по табли-
це-мосту. В нашем случае мы можем скрыть поле Budget и заменить его
следующим вычислением:
BudgetMeasure = CALCULATE(SUM(Budgets[Budget]), Budget_Bridge)
Применение обеих техник вы можете рассмотреть внимательнее в файле

Many to many.pbix, входящем в состав сопроводительных материалов.
В нашем примере с небольшим количеством строк в таблицах создание
таблицы-моста не является оправданным. Более того, мы даже увеличили
размер нашей модели данных без особой на то необходимости. Таким обра-
зом, здесь вы не заметите никакого прироста производительности, а в плане
поддержки использование связи типа «многие ко многим» будет даже проще.
Но при работе с объемными наборами данных мы настоятельно рекоменду-
ем переходить к использованию таблиц-мостов с целью повышения произ-
Теперь рассмотрим способы сокращения размера набора данных. Это
в перспективе также должно привести к снижению времени обновления
и формирования отчетов.
Уменьшение размера набора данных

В главе 2 мы уже говорили о том, что таблицы в режиме Import в наборах дан-
ных Power BI хранятся в сжатом формате. Нам необходимо стараться удержи-
вать размер этих таблиц на минимально возможном уровне для уменьшения
времени, затрачиваемого на обновление данных и выполнение запросов.
Также нужно помнить о необходимости начальной загрузки набора данных.
Power BI не хранит все датасеты в памяти, это было бы чрезмерно расточи-
тельно. Набор данных, не использовавшийся какое-то время, должен быть
при следующем обращении загружен в память с диска. И время загрузки
набора данных увеличивается с ростом размера самого датасета.
Но польза от небольшого объема данных не ограничивается одним только
снижением времени загрузки. Чем меньше данных необходимо обрабаты-
вать, тем меньше потребуется процессорного времени и памяти, что позво-
лит освободить ресурсы для других важных операций.
Давайте перечислим основные рекомендации по снижению размера на-

бора данных:
избавьтесь от неиспользуемых таблиц и столбцов: если какая-то
таблица или колонка не используется ни в наборе данных, ни в отчетах,
от нее лучше избавиться. Бывает, что таблицы или атрибуты применя-
ются в процессе внутренних вычислений, но непосредственно пользо-
вателю не выводятся. Такие объекты удалять нет необходимости;
избегайте использования столбцов с большой точностью и крат-
ностью: зачастую данные в источнике хранятся с большей точностью,
чем необходимо для проведения анализа и вычислений. К примеру,
даты могут храниться в базе с точностью до секунды, но если мы даже
на предельной гранулярности выполняем анализ только по дням, нам
нет необходимости знать о минутах и секундах. Также нам не нужно
иметь доступ к знакам после запятой в поле с весом человека, если
при анализе мы оперируем исключительно округленными значения-
ми. Мы рекомендуем проводить очистку данных с уменьшением точ-
ности либо в Power Query, либо при вычислениях или даже хранении
данных в источнике, если это допустимо. Давайте рассмотрим пример
со сравнением десятичных значений с целочисленными. Power BI оба
типа данных хранит с использованием 64-битных значений, занима-
ющих 8 байт. Кажется, что никакой разницы нет. Но размер набора
данных все равно уменьшится, поскольку при урезании точности мы
уменьшаем количество уникальных значений в столбце (например, все
значения между 99,0 и 99,49 будут сведены при округлении к 99). В ре-
зультате мы серьезно выиграем на сжатии повторяющихся значений.
То же самое касается и столбцов с высокой кратностью или мощностью
(cardinality). Под этими терминами подразумевается количество уни-
кальных элементов в группе. В столбце с высокой кратностью будет
мало дублирующихся значений, а значит, и сжиматься он будет очень
слабо. Некоторые столбцы заведомо будут содержать только уникаль-
ные значения. Это характерно для идентификаторов или первичных
ключей вроде Employee ID, которые уникальны по своей природе. От
таких столбцов в наборах данных нужно избавляться с большой осто-
рожностью, поскольку они могут понадобиться для создания связей
между таблицами или вывода в отчетах;
отключите опцию автоматической даты и времени: если в вашем
наборе данных присутствует много столбцов календарного типа, до-
статочно много места могут занимать скрытые таблицы с календаря-
ми, которые Power BI по умолчанию создает автоматически. Убедитесь,
что вы отключили эту опцию, как было описано в главе 2;
разбивайте календарные столбцы на дату и время: если вам необ-
ходимо проводить аналитику с учетом даты и времени, рассмотрите
возможность разделения исходного столбца, хранящего обе составляю-
щие, на два – отдельно с датой и временем. Это позволит существенно
сократить количество уникальных значений в столбцах. Судите сами:
если данные у нас хранятся за 10 лет с точностью до секунды, мы полу-
чим порядка 315 млн уникальных записей в календаре (10 лет умножить
на 365 дней, 24 часа и 60 минут и секунд). А после разделения на дату

и время мы получим максимум 90 050 записей (10 × 365 + 24 × 60 × 60),
что характеризует уменьшение количества строк более чем на 99 %;
замените GUID на суррогатные ключи для связей: GUID, или гло-
бальный уникальный идентификатор (Globally Unique Identifier – GUID),
состоит из 32 шестнадцатеричных чисел и дефисов. Пример такого
идентификатора – 123e4567-e89b-12d3-a456-426614174000. В Analysis Ser-
vices подобные значения хранятся в виде текста. Связи, созданные на
основе текстовых полей, гораздо менее эффективны по сравнению со
связями на базе числовых значений. Вы можете использовать Power
Query для генерирования суррогатного ключа (surrogate key), которым
сможете подменить GUID как в измерении, так и в таблицах фактов.
Для объемных наборов данных эта операция может серьезно ударить
по ресурсам, и в конечном итоге вы жертвуете скоростью обновления
в пользу быстродействия запросов. В качестве альтернативы вы мо-
жете обсудить с администраторами базы данных вариант с созданием
суррогатного ключа прямо в источнике. Эта техника может не дать
результатов, если в системе нужны GUID. Например, кому-то из поль-
зователей может понадобиться скопировать идентификатор и выпол-
нить поиск по нему во внешней системе. Вы можете избежать предва-
рительной загрузки GUID в набор данных, используя составную модель
и отчеты с динамической загрузкой одного или нескольких GUID при
запросе детализации в режиме DirectQuery. Более подробно составные
модели мы рассмотрим в главе 12;
рассмотрите возможность использования составных моделей или
подмножеств для очень объемных моделей: при работе с моделями
данных, состоящими из многих десятков и даже сотен таблиц, вы може-
те создавать поднаборы данных для улучшения производительности.
Старайтесь включать в поднаборы только факты, имеющие непосред-
ственное отношение к конкретной бизнес-задаче и требующиеся для
анализа одними и теми же группами пользователей в рамках визуаль-
ного элемента, страницы отчета или аналитической сессии. Избегайте
загрузки в один поднабор фактов, имеющих очень мало смежных из-
мерений. К примеру, факты по бронированию отпусков и отпускным
деньгам могут находиться в одном наборе, а эти же факты с информа-
цией о запросах к сайту – нет. Вы также можете решить эти проблемы
при помощи использования составных моделей и агрегатов, о чем мы
будем подробно говорить в главе 12. Кроме того, данная рекомендация
также применима к медленным моделям DirectQuery. В этом случае
переход на составные модели с агрегатами может дать ощутимую при-
бавку в производительности;
используйте наиболее эффективные типы данных и меняйте
текст на целочисленные значения: Power BI будет пытаться вы-
брать правильные с его точки зрения типы данных для столбцов за вас.
Если данные приходят из строго типизированных источников вроде
баз данных, Power BI будет по максимуму воспроизводить типы из ис-
точника. Но для многих источников типы данных могут выбираться
не совсем подходящим образом, и необходимо всегда проверять их

самостоятельно. Это особенно важно при загрузке информации из
плоских файлов, где целочисленные значения могут преобразовы-
ваться в текст. В этом случае нужно вручную исправить тип данных для
столбцов на целое число, чтобы могло быть применено кодирование на
основе значений (value encoding). Этот метод выполняет сжатие данных
гораздо более эффективно по сравнению с кодированием со словарем
(dictionary encoding) и кодированием на основе длин серий (run-length
encoding), которые традиционно используются для текстовых данных.
Кроме того, связи, построенные на базе целочисленных полей, рабо-
тают быстрее;
выполняйте предварительную сортировку целочисленных клю-
чей: Power BI сканирует значения в столбцах во время чтения строка
за строкой. При этом решается, какой тип компрессии лучше будет
применить. Эта компрессия в итоге применяется к группам строк,
называемым сегментами (segments). В настоящее время SQL Server
и Azure Analysis Services работают с сегментами из 8 млн строк, тогда
как Power BI Desktop и служба Power BI оперируют лишь сегментами,
состоящими из 1 млн строк. Для таблиц большего размера имеет смысл
загружать данные в Power BI с уже отсортированными ключами. Это
позволит уменьшить диапазон значений внутри сегмента, что положи-
тельно скажется на эффективности кодирования на основе длин серий;
используйте двунаправленные связи с осторожностью: этот тип
связей позволяет контексту срезов и фильтров распространяться в обе
стороны. Если в модели присутствует большое количество двунаправ-
ленных связей (bi-directional relationships), применение фильтрации
к одной части набора данных может приводить к запуску длинных
цепочек влияний объектов друг на друга, поскольку все такие связи
должны будут отработать. Это может существенно замедлить выпол-
нение запросов. Мы рекомендуем создавать двунаправленные связи
между таблицами только в случае острой необходимости;
разгрузите вычисляемые столбцы DAX: вычисляемые столбцы
сжимаются не так эффективно, как физические. Если в вашей модели
присутствуют вычисляемые столбцы, особенно с большой кратностью,
рассмотрите вариант переноса вычислений на более низкий слой. На-
пример, вы можете выполнить их в Power Query. Используйте инструк-
цию по переносу вычислений, которую мы приводили в главе 8;
пересмотрите типы агрегации столбцов по умолчанию: обычно
в числовых столбцах в Power BI используется агрегация по умолчанию
в виде суммирования и реже – в виде подсчета количества строк. Это
свойство может быть установлено на вкладке Данные (Data) в Power BI
Desktop. Но в вашей модели могут присутствовать и числовые столб-
цы, к которым суммирование не применимо, например уникальные
идентификаторы, такие как номера заказов. Если в качестве агрега-
ции по умолчанию используется сумма, Power BI будет суммировать
атрибут в визуальных элементах. Это может смутить пользователей,
а с точки зрения производительности вас может обеспокоить то, что
здесь выполняется бессмысленное суммирование. Таким образом, мы

советуем вам пересмотреть типы агрегации для полей по умолчанию,
Рис. 10.9  Агрегация по умолчанию для столбца с идентификаторами

установлена в подсчет количества, а не суммы
Теперь рассмотрим способы оптимизации при использовании безопасно

сти на уровне строк.
Ловушки при использовании безопасности

на уровне строк
Безопасность на уровне строк (RLS) – это одна из ключевых особенностей Po
wer BI. Этот механизм позволяет разграничивать доступ к информации для
пользователей. Функционирует он посредством ограничения строк, которые
пользователь может видеть, при помощи фильтрующего выражения DAX.
Существует два подхода к настройке RLS в Power BI. Простейшая конфи-
гурация подразумевает создание ролей в наборе данных и добавление в них
членов, в качестве которых могут быть как отдельные пользователи, так
и целые группы безопасности. После этого для роли задается фильтрую-
щее табличное выражение DAX, определяющее область видимости для ее
членов. Второй подход, часто именуемый динамическим RLS (dynamic RLS),
предполагает создание таблиц безопасности (security tables) в наборе дан-
ных, содержащих информацию о пользователях и разрешениях. Этот способ
обычно используется, когда разрешения могут часто меняться, поскольку он
позволяет поддерживать созданные таблицы безопасности автоматически,
без необходимости подвергать изменениям набор данных Power BI. Мы пред-
полагаем, что вы знакомы с обеими техниками.
Что касается производительности, то проблемы в этой области могут
возникать, когда применение фильтров становится относительно дорогим
в сравнении с выполнением тех же запросов без использования механизма
RLS. Это происходит, если фильтрующие выражения оказываются достаточ-
но сложными и приводят к задействованию однопоточного движка формул,
о котором мы подробно говорили в главе 6. Фильтр также может порождать
большое количество запросов для движка хранилища.
Давайте по сложившейся традиции перечислим рекомендации в отноше-
нии оптимального использования механизма RLS:
Ловушки при использовании безопасности на уровне строк  195
выполняйте фильтрацию RLS применительно к измерениям, а не

к таблицам фактов: измерения обычно содержат намного меньше
строк, чем таблицы фактов. В результате в фильтрации будет прини-
мать участие меньше строк и связей, что положительно скажется на
быстродействии механизма;
избегайте выполнения вычислений DAX внутри фильтрующих
выражений, особенно это касается манипулирования строками:
такие операции, как условные выражения и манипулирование строка-
ми, выполняются исключительно в движке формул, и применительно
к большим наборам данных они могут потребовать достаточно много
времени. Старайтесь по возможности не усложнять фильтрующие вы-
ражения DAX без особой необходимости, а все вычисления с созданием
промежуточных значений, которые могут потребоваться, выполняйте
заранее. Рассмотрим пример с иерархией типа родитель–потомок (par-
ent-child hierarchies), в котором в таблице располагается вся нужная
информация о предках элемента в каждой строке. Взгляните на иерар
хию с организационной структурой, представленную на рис. 10.10. Мы
предварительно сгладили иерархию при помощи функции Path, что-
бы иметь возможность применять выражения DAX непосредственно
к уровням иерархии. Это довольно типичный пример обращения с ие-
рархиями в Power BI.
Измерение: Organization Structure
Рис. 10.10  Типичное измерение с иерархией в Power BI
Представьте, что вам необходимо создать роль с доступом для всех

сотрудников финансового отдела (Finance). Вероятно, вы могли бы
написать следующее фильтрующее выражение для этого:
PATHCONTAINS('Organization Structure'[Path], 2)
Это сработает, но мы включили сюда функцию для манипуляции стро-

ками, которая осуществляет поиск в столбце Path. Таким образом,
с точки зрения производительности лучше будет использовать следую
щее выражение, в котором выполняется целочисленное сравнение:
'Organization Structure'['Level 2 ID'] = 2
оптимизируйте связи: фильтры безопасности распространяются от

измерений к таблицам фактов по соответствующим связям подобно
любым другим фильтрам, использующимся в отчете или запросе. Так

что применительно к ним вы должны следовать всем рекомендациям,
озвученным в предыдущем разделе и главе 3;
тестируйте механизм RLS на реалистичных сценариях: Power BI
Desktop позволяет воспроизводить созданные роли для проверки
механизма RLS. Вам необходимо использовать инструменты вроде
Desktop Performance Analyzer и DAX Studio для отслеживания быстро-
действия операций и активности движка с применением механиз-
ма RLS и без него. Обращайте внимание на разницу в длительности
операций, выполняемых движком формул, и количестве запросов,
отправляемых движку хранилища, чтобы понять, как влияет на про-
изводительность вашей системы механизм RLS. Также настоятельно
рекомендуется произвести тестирование опубликованной в службе
Power BI версии на реальных объемах данных. Это поможет обна-
ружить проблемы, которые невозможно было выявить на тестовых
данных в процессе разработки. Помните о важности установки це-
левых показателей и замера производительности после каждого
произведенного изменения, о чем мы много говорили в главе 7. Мы
рекомендуем вам ознакомиться с видео от Guy in a Cube, в котором
показан процесс тестирования механизма RLS с применением ин-
струментов, описанных нами в главе 3, по адресу https://www.youtube.
com/watch?v=nRm-yQrh-ZA.
Теперь перечислим советы по оптимизации динамического RLS:
избегайте использования несвязанных таблиц безопасн ос ти
и функции LOOKUPVALUE(): эта техника имитирует присутствие
связи между таблицами за счет использования функции поиска со-
впадений в столбцах двух таблиц. Сама эта операция связана со ска-
нированием данных и выполняется намного дольше по сравнению
с наличием физической связи между таблицами. Вам может понадо-
биться изменить вашу таблицу безопасности и модель данных в целом,
чтобы организовать нужные физические связи, но эти усилия окупятся
в дальнейшем;
сохраняйте минимальный размер таблиц безопасности: при ис-
пользовании динамического RLS фильтр изначально применяется
к таблицам безопасности, после чего распространяется на остальные
таблицы по связям. Мы должны проектировать таблицы безопасно
сти так, чтобы в них содержалось минимально возможное количество
строк. Это приведет к уменьшению количества совпадений и снизит
объем работы движка во время фильтрации. Помните, что Power BI не
ограничивает вас наличием лишь одной таблицы безопасности, так
что вы отнюдь не обязаны сваливать все разрешения в одну большую
таблицу. Наличие нескольких небольших нормализованных таблиц
безопасности может привести к гораздо лучшим результатам в плане
производительности;
избегайте использования двунаправленных фильтров безопасно
сти: операции фильтрации не кешируются при использовании двуна-
Ловушки при использовании безопасности на уровне строк  197
правленных связей, что ведет к снижению производительности. Если

вам приходится использовать двунаправленную фильтрацию, старай-
тесь, чтобы количество строк в таблицах безопасности не превышало
128 тыс.;
сводите несколько контекстов безопасности в одну таблицу: если
у вас есть несколько фильтров RLS от измерений, которые применяют-
ся к одной таблице фактов, вы можете создать единую таблицу безопас
ности, применяя принципы так называемого мусорного измерения (junk
dimension) Кимбалла. Это может быть полный набор всех возможных
комбинаций разрешений (также известный как перекрестное произве-
дение (cross-product)) или актуальные уникальные наборы разрешений,
которые нужны пользователям. Перекрестное произведение создать
очень просто, но в результате могут появиться комбинации, которые
не имеют смысла или никогда не могут встретиться. Чтобы рассмотреть
эту технику на практике, давайте представим себе модель данных, по-
казанную на рис. 10.11, в которой одна таблица фактов фильтруется
несколькими измерениями, к которым, в свою очередь, применяются
правила безопасности. Стрелки символизируют связи, а их направле-
ния – распространение фильтра.
Таблица безопасности:
SEC_Gepgraphy Измерение: Geography
Таблица фактов: Sales
SEC_ProductGroup Измерение: ProductGroup
Рис. 10.11  Фильтрация одной таблицы фактов

несколькими измерениями с применением правил безопасности
Мы можем уменьшить количество работы, требующееся для выполне-

ния фильтрации, собрав разрешения в единую таблицу безопасности,
Таблица безопасности: SEC_Combined
Измерение: Geography
Таблица фактов:
Sales
Измерение: ProductGroup
Рис. 10.12  Более эффективный способ фильтрации единой таблицы фактов
Обратите внимание, что новая таблица безопасности SEC_Combined

не содержит перекрестное произведение двух прежних таблиц. Вместо
этого в ней находятся только комбинации, присутствующие в источни-
ке данных, что позволило сократить ее размер. Такой способ предпо-
чтителен при наличии большого количества измерений и допустимых
значений. В нашем примере наша итоговая таблица безопасности со-
держит 20 строк вместо 30, как было бы в случае заполнения ее при
помощи перекрестного произведения (5 строк в таблице Geography
умножить на 6 строк в таблице ProductGroup).
Увидеть эффект от этого изменения можно, открыв несколько страниц
отчетов или запустив несколько запросов с применением механизма
RLS и без. Проверьте это на файлах RLS.pbix и RLS Combined.pbix, вхо-
дящих в состав сопроводительных материалов к книге. В них содер-
жатся конфигурации, показанные на рисунках, представленных выше,
и единственная роль для имитации пользователя Super Man.
Мы запустили несколько тестов в DAX Studio с использованием роли,
созданной для пользователя Super Man, и получили результаты, по-
казанные в табл. 10.1. Несмотря на небольшой объем данных разме-
ром порядка 25 000 строк и приемлемые задержки, вы можете видеть
300%-ный рост производительности при применении механизма RLS
Таблица 10.1. Сравнение производительности различных конфигураций RLS

Файл примера Конфигурация
Движок Движок Запросы движка Общее
формул (мс) хранилища (мс) хранилища время (мс)
RLS.pbix Без RLS 3 1 1 4
RLS.pbix Роль Super Man 4 8 16 12
RLS Combined.pbix Без RLS 2 1 1 3
RLS Combined.pbix Роль Super Man 2 1 1 3
в подходе с комбинированной таблицей безопасности. А с увеличе-

нием количества пользователей, измерений и строк в таблице фактов
разница станет ощутимой;
объединяйте пользователей с одним контекстом безопасности: на
рис. 10.11 видно, что в наших таблицах безопасности присутствуют не-
сколько строк для каждого пользователя и есть дублирующиеся наборы
правил безопасности. К примеру, пользователи Spider Man и Black
Widow имеют доступ ко всем строкам в регионе Asia и товарной груп-
пе Outdoor Furniture. При наличии сотен или тысяч пользователей
таблицы безопасности могут вырасти до неприличных размеров. Но
если у нас есть пользователи с одинаковыми наборами прав, мы можем
существенно сократить размер таблиц, применив прием моделирова-
ния, показанный на рис. 10.13. Обратите внимание, что таблицы стали
меньше. Также заметьте, что здесь мы по делу использовали связь типа
«многие ко многим» и двунаправленную фильтрацию – именно в такой
конфигурации производительность может улучшиться.
Измерение: Users SEC_Gepgraphy Измерение: Geography
Таблица фактов: Sales

M2M Двунаправленная.
Направление = Оба
Рис. 10.13  Объединение пользователей и разрешений
Построить таблицы безопасности, показанные в этом примере, можно

разными способами. Можно создавать таблицы извне в рамках обычных
действий по загрузке данных в хранилище или воспользоваться Power Query.
Теперь пришло время подытожить все сказанное в этой главе.
В этой главе мы рассмотрели различные способы повышения производи-
тельности наборов данных Power BI в режиме Import. Начали мы с неболь-
шого теоретического введения в размерное моделирование Кимбалла, из
которого узнали о схеме «звезда», строящейся на основании измерений
и таблиц фактов. Моделирование данных мы определили как метод группи-
ровки и объединения атрибутов в таблицах, а схема «звезда» представляет
собой один из способов моделирования. Создание моделей позволяет людям
без специальных знаний анализировать свои данные, интуитивно связы-
вая номинативные атрибуты из таблицы фактов с измерениями, а движок
Analysis Services, лежащий в основе Power BI, очень эффективно работает со
схемой «звезда», которая является предпочтительным выбором. В процессе
освоения моделирования данных мы перечислили четыре этапа размерно-
го моделирования и привели несколько примеров, включая использование

связи типа «многие ко многим».
После этого сосредоточились на способах уменьшения размера набора дан-
ных. Это очень важный аспект моделирования данных, поскольку меньшие
объемы данных требуют меньшей длительности их обработки, что позволяет
освободить ресурсы для других процессов. Мы знали о том, что необходимо
избавляться от таблиц и столбцов, которые не нужны при формировании от-
четов и выполнении расчетов. Мы также рассмотрели техники, позволяющие
движку Analysis Services гораздо эффективнее сжимать данные. Среди них
можно выделить правильный подбор типов данных для столбцов, снижение
их кратности и, по возможности, перевод в числовые форматы.
В заключение мы поговорили о приемах оптимизации механизма безопас
ности на уровне строк (RLS). Мы узнали, что RLS работает точно так же, как
обычные фильтры, а значит, данные ранее рекомендации об оптимизации
связей в полной мере можно применить и к безопасности. Здесь очень важно
усвоить, что выражения DAX, отвечающие за фильтры безопасности, должны
быть максимально простыми, насколько это возможно, и не использовать
операции манипуляции строками. Техника динамического RLS предусмат
ривает использование таблиц безопасности, которые, как мы узнали из этой
главы, также должны быть минимально возможного размера. Мы также по-
смотрели, как можно использовать инструменты Desktop Performance Ana-
lyzer и DAX Studio для перехвата и анализа производительности запросов
с применением механизма RLS и без.
В следующей главе мы пристально посмотрим на формулы DAX, обсудим
распространенные ловушки и способы их обхода.
Глава 11
Улучшаем DAX
В предыдущей главе мы сконцентрировали внимание на наборах данных в ре-

жиме Import применительно к визуальному слою Power BI, и ключевым выво-
дом стала необходимость снижения нагрузки на источники данных путем ми-
нимизации сложности и количества запросов, поступающих в датасет Power BI.
В теории хорошо спроектированная модель данных не должна испыты-
вать проблем с производительностью, если она не оперирует экстремаль-
но огромными наборами данных от нескольких десятков миллионов строк
и выше. Однако на практике модели, работающие с небольшими объемами
информации, нередко страдают от низкого быстродействия по причине не-
оптимально написанных мер на DAX.
Изучить основы DAX для неподготовленного человека не представляет
большой сложности. Здесь вам не потребуется даже специфического техни-
ческого опыта – это не более, чем написание формул в Microsoft Excel. Но
стать настоящим экспертом в DAX очень и очень непросто. Причина этого,
как ни удивительно, кроется в богатстве средств языка DAX и возможности
добиться одного и того же результата совершенно разными способами. Для
экспертного знания этого языка вам потребуется погрузиться в изучение кон-
текста строки и контекста фильтра, определяющих, какие данные находятся
в области видимости в конкретной точке вычисления. В главе 6 мы говори-
ли об особенностях движка формул и движка хранилища в Analysis Services.
В этой главе мы пойдем дальше и на примерах покажем, как применение
определенных шаблонов в языке DAX, связанных с контекстом фильтра и кон-
текстом строки, способно повлиять на поведение движка. Мы внимательно
посмотрим, на что именно тратится время в медленных шаблонах запросов.
Попутно мы выделим шаблоны DAX, приводящие к снижению произво-
дительности, и расскажем о том, как их правильно переписать.
В этой главе мы обсудим только одну тему, включающую в себя множество
советов и рекомендаций:
ловушки DAX и способы оптимизации.
Для этой главы мы подготовили один файл с примерами, который называ-
ется DAX Optimization.pbix и который можно найти в папке Chapter11 в хра-
202  Улучшаем DAX
нилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-

BI-Performance-Best-Practices.
Ловушки DAX и способы оптимизации

Перед тем как углубиться в оптимизацию запросов DAX, мы кратко опишем
процесс настройки и проверки формул.
Процесс отладки выражений DAX

В главах 5 и 6 мы говорили о том, как можно использовать вспомогательные
инструменты для отслеживания производительности решений. Некоторые
из этих инструментов применимы для отладки выражений DAX. Ниже мы
приводим список шагов по настройке и проверке формул DAX.
1. Редактировать выражения DAX можно непосредственно при работе
с набором данных. В идеале при этом нужно пользоваться инструмен-
том Best Practice Analyzer (BPA) для поиска возможных улучшений.
В следующем разделе мы рассмотрим оптимальную методику работы
с этим инструментом, но в идеале вы должны проверять все правила
вручную.
2. Ранжируйте предположения об изменениях по степени прилагаемых
усилий от низшего к высшему. Рассмотрите вариант переноса неко-
торых вычислений и даже промежуточных результатов в Power Query.
Обычно это лучшее место для произведения построчных вычислений.
3. В окружении разработки вы можете вносить простые изменения, но
всегда необходимо проверять, что в результате меры возвращают кор-
ректные результаты.
4. Тестируйте быстродействие страниц отчетов и визуальных элементов
при помощи инструмента Power BI Desktop Performance Analyzer. Пере-
носите перехваченные анализатором запросы в DAX Studio и восполь-
зуйтесь вкладкой Server Timings для сравнения нагрузки на движок
формул и движок хранилища.
5. Модифицируйте формулы DAX и проверяйте производительность
в DAX Studio. Помните о том, что этот инструмент позволяет вам пере-
записывать меры локально, не внося изменения в актуальный набор
данных.
6. Вносите изменения в формулы DAX в наборе данных, параллельно
проверяя результаты при помощи Performance Analyzer на произво-
дительность и корректность.
7. Проверяйте изменения в рабочей системе на реальных сценариях
и объемах данных. Если все в порядке, вносите изменения в список
обновлений. В противном случае повторите процесс с учетом допу-
щенных ошибок.
Теперь давайте перейдем к руководству по оптимизации в DAX.
Ловушки DAX и способы оптимизации  203
Руководство по оптимизации в DAX

Наша цель будет прежней – движок Analysis Services должен выполнять как
можно меньше работы с как можно меньшим количеством данных. Даже
в хорошо оптимизированных наборах данных, в которых соблюдены все
рекомендации относительно моделирования, плохо написанные выражения
DAX могут привести к сканированию избыточного количества строк при вы-
числении или излишне нагружать движок формул ненужными расчетами.
Таким образом, нашу основную цель можно разбить на три более мелкие:
уменьшить объем работы, выполняемой однопоточным движком
формул;
снизить общее количество внутренних запросов, генерируемых в ре-
зультате выполнения запроса DAX;
избегать сканирования объемных таблиц.
В данном разделе мы будем анализировать производительность первых нескольких
запросов только при помощи DAX Studio. Но помните, что вы можете также использо-
вать Desktop Performance Analyzer и другие инструменты для анализа и оптимизации
выражений DAX, которые будут приведены в этой главе.
Ниже мы перечислим распространенные шаблонные решения, которые

обычно приводят к существенному повышению производительности. При
этом мы будем отдельно отмечать, какие проблемы могут возникать с ис-
пользованием этих шаблонов и как их решать.
Используйте переменные вместо повторения

определений мер
Время от времени в процессе вычисления нам требуется повторно использо-
вать вычисленное ранее значение. Давайте рассмотрим пример, в котором
нам необходимо рассчитать долю продаж по сравнению с аналогичным пе-
риодом в прошлом году. Простейший способ такого расчета приведен ниже:
YoY% =
(
SUM('Fact Sale'[Total Sales])
- CALCULATE(SUM('Fact Sale'[Total Sales]),
DATEADD('Dimension Date'[Date], -1, YEAR))
),
/
CALCULATE(SUM('Fact Sale'[Total Sales]),
DATEADD('Dimension Date'[Date], -1, YEAR)
Обратите внимание, что мы дважды рассчитываем прошлогодние прода-

жи – сначала для числителя, а затем для знаменателя. В результате движок
вынужден будет два раза выполнить расчет, и воспользоваться преимущест
вами кеширования в Analysis Services ему удастся не всегда. Лучше для вы-
полнения подобных вычислений пользоваться переменными. Заметьте, что
мы здесь не перехватываем ошибки и не выполняем прочую оптимизацию:
YoY% VAR =
VAR __PREV_YEAR =
CALCULATE(
SUM('Fact Sale'[Total Sales]),
DATEADD('Dimension Date'[Date], -1, YEAR))
RETURN
(SUM('Fact Sale'[Total Sales]) - __PREV_YEAR) /__PREV_
YEAR
Как видите, мы воспользовались ключевым словом VAR для определения

переменной с именем __PREV_YEAR, в которой будет храниться сумма продаж
за предыдущий год. Это значение может быть использовано в любом месте
запроса при обращении по имени переменной, и повторное вычисление
происходить не будет.
Вы можете найти обе меры – с использованием переменной и без – в со-
проводительном файле. Страницы отчета Without Variable и With Variable
содержат табличный визуальный элемент, показанный на рис. 11.1.
Рис. 11.1  Табличный визуальный элемент с долями продаж

относительно предыдущего года
Мы перехватили трассировку запроса при помощи DAX Studio. Давайте

посмотрим, что получилось. Результат проверки производительности по-
казан на рис. 11.2.
Как видите, первый запрос, в котором переменная не использовалась, ока-
зался немного более медленным. Это заметно по одному лишнему запросу
для движка хранилища. К счастью, в нашем простом примере оптимизатору
удалось воспользоваться результатами кеширования. Также мы видим, что
движок формул в первом случае выполнял свои операции дольше. В нашем
примере с 220 тыс. строк в таблице фактов эта разница вряд ли будет ощути-
мой. Но при больших объемах данных и более сложных мерах, особенно если
их результаты будут использоваться в других мерах, отображаемых одновре-
менно, снижение производительности утаить не удастся.
В мере YoY% не используется переменная
В мере YoY% используется переменная
Рис. 11.2  С использованием переменной длительность

и объем вычислений уменьшились
Использование переменных – это, вероятно, самый важный совет при оптимизации

выражений DAX, поскольку повторные вычисления в формулах встречаются доста-
точно часто. Кроме того, вы заметите, что при написании кода за вас – например, при
создании быстрых мер – Power BI также активно использует этот и многие другие
приемы по оптимизации запросов.
Используйте функцию DIVIDE вместо оператора деления

При выполнении операции деления нам часто нужно заботиться о том, чтобы
не возникало ошибок, если в знаменателе окажется ноль или пустое зна-
чение. Этого можно добиться при помощи условной логики, которая будет
лишний раз нагружать движок формул. Давайте вновь обратимся к рис. 11.1.
Теперь вместо годового роста продаж мы будем рассчитывать рентабель-
ность. При этом будем перехватывать ошибки деления на ноль и пустые
значения в знаменателе:
Profit IF =
IF(
OR(
ISBLANK([Sales]),[Sales] == 0
),
BLANK(),
[Profit]/[Sales]
)
Но вместо этого вы можете использовать функцию DIVIDE(), как показано

ниже:
Profit DIVIDE =
DIVIDE([Profit], [Sales])
У этой функции есть сразу несколько преимуществ по сравнению с ус-

ловной логикой. Во-первых, она позволяет перехватить нулевые и пустые
значения еще в движке хранилища, который, как мы знаем, функционирует

в многопоточном режиме. К тому же у этой функции есть необязательный
третий параметр, позволяющий указать альтернативное значение, которое
будет использоваться в случае, если в знаменателе окажется нулевое или
пустое значение. Ну и сама формула получается более лаконичной, и ее легче
будет поддерживать.
Если взглянуть на производительность при помощи DAX Studio, мы также
увидим очень существенную прибавку. Первая версия формулы выполнялась
втрое дольше, что видно на рис. 11.3.
Эта версия использует / и условную логику
Эта версия использует функцию DIVIDE()
Рис. 11.3  DAX Studio доказывает эффективность использования функции DIVIDE
На рис. 11.3 также показано, что медленная версия формулы порождает

больше внутренних запросов, а вычисления в движке хранилища длятся в че-
тыре раза дольше. В движке формул также заметно двукратное увеличение
длительности. А ведь речь идет всего об одной формуле для одного визу-
ального элемента. И чем больше будет таких запросов на странице отчета,
тем медленнее он будет формироваться. Вы можете поэкспериментировать
с мерами на страницах Profit IF и Profit DIVIDE в файле с примерами.
Избегайте преобразования пустых значений в ноль

или какого-то текста при вычислении числовых мер
Иногда с целью повышения удобства разработчики пишут меры, которые
вместо пустых значений возвращают ноль. Такой подход часто используют
в финансовых отчетах, в которых пользователю нужно видеть все элементы
измерения (будь то коды затрат или товаров) вне зависимости от того, были
движения по этой позиции или нет. Давайте рассмотрим пример. В нашем
файле с примерами есть простая мера Sales, суммирующая значения в поле
'Fact Sale'[Total Including Tax]. Мы адаптировали ее таким образом, чтобы

вместо пустых значений она возвращала ноль:
SalesNoBlank =
VAR SumSales =
SUM('Fact Sale'[Total Including Tax])
RETURN
IF(ISBLANK(SumSales), 0, SumSales)
Затем мы воспользовались визуальным элементом Матрица для отобра-

жения продаж в разрезе штрих-кодов товаров для обеих версий мер. Резуль-
таты показаны на рис. 11.4. Вверху мы видим значения продаж только за
2016 год, что означает отсутствие движений по указанным товарам за другие
годы. В нижней части продажи показываются начиная с 2013 года, а справа
появилась вертикальная полоса прокрутки.
ОБЫЧНАЯ МЕРА С СУММОЙ:
ИЗМЕНЕННАЯ МЕРА С ЗАМЕНОЙ ПУСТЫХ ЗНАЧЕНИЙ НУЛЯМИ:
Рис. 11.4  Те же суммы,

но с выводом строк для месяцев с отсутствующими продажами
Оба вывода технически корректны. Но за замену пустых значений нулями

нам пришлось прилично заплатить. Если размышлять о размерном модели-
ровании в теории, у нас могли бы присутствовать значения для всех без ис-
ключения комбинаций измерений. На практике это бы означало, что каждый
наш продавец должен был бы продавать каждый товар каждый день во всех
без исключения магазинах и т. д. Однако в реальности всегда будут комбина-
ции измерений с отсутствующими значениями. В Analysis Services для таких
случаев предусмотрена оптимизация, позволяющая скрывать пустые пере-
сечения измерений и не возвращать строки, если все меры в них возвращают
пустые значения. Мы измерили производительность двух рассмотренных
в этом примере решений с помощью DAX Studio, и с результатами вы можете
ознакомиться на рис. 11.5.
Обычная мера Sales
Измененная мера с заменой пустых значений нулями
Рис. 11.5  Снижение производительности при замене пустых значений нулями
На рис. 11.5 видно, что в случае с модифицированной мерой возросла

общая длительность ее вычисления, продолжительность обработки в движ-
ке формул и количество генерируемых запросов. Вы можете проверить эти
меры на страницах MeasureWithBlank и MeasureNoBlank в файле с примерами.
Можно рассмотреть вариант замены пустых значений не непосредственно
в мерах, а в настройках визуальных элементов. Для этого необходимо выде-
лить элемент в Power BI Desktop и на панели Поля (Fields) для конкретного
атрибута измерения активировать пункт меню Показывать элементы без
данных (Show items with no data), как показано на рис. 11.6. Это также при-
ведет к снижению производительности отчета, но не так критично по срав-
нению с изменениями в мерах.
Рис. 11.6  Отображение элементов без данных

Еще одним преимуществом этого подхода является то, что вам не при-
дется беспокоиться о производительности каждый раз, когда используется
эта мера. В результате вы сможете сбалансировать быстродействие системы
в зависимости от потребностей пользователей.
Если вам все же необходимо реализовать замену пустых значений в мерах,
вы можете сделать это для определенного диапазона данных. Мы рекомен-
дуем вам ознакомиться со статьей на сайте SQLBI, в которой подробно рас-
смотрены нюансы этой задачи с использованием комбинации выражений
DAX и приемов моделирования данных в зависимости от вашего сценария:
https://www.sqlbi.com/articles/how-to-return-0-instead-of-blank-in-dax.
Также отметим, что не стоит менять пустые числовые значения на текс
товые шаблоны наподобие «Данные отсутствуют». Хотя эта информация
может оказаться полезной для пользователя, решение окажется еще более
медленным по сравнению с заменой пустых значений нулями, поскольку
мера станет текстовой. Кроме того, это может привести к проблемам в даль-
нейшем, если эта мера будет использована в других вычислениях.
Используйте функцию SELECTEDVALUE вместо VALUES

Бывает, что вычисление необходимо производить только при наличии в об-
ласти видимости единственного элемента измерения. Например, вы можете
использовать срез в качестве параметрической таблицы, чтобы позволить
пользователям динамически менять значения мер, – допустим, масштабируя
их определенным образом. Для доступа к единственному значению в об-
ласти видимости можно использовать функцию HASONEVALUE(), которая воз-
вращает TRUE в случае присутствия одного элемента, после чего применить
функцию VALUES(). Применительно к параметрической таблице с названием
Scale мера могла бы выглядеть так:
Sales by Scale =
DIVIDE (
[Sales Amount],
IF( HASONEVALUE ( Scale[Scale] ), VALUES ( Scale[Scale] ), 1 )
)
Но вместо этого вы могли бы воспользоваться функцией SELECTEDVALUE(),

которая выполняет оба шага. Эта функция возвращает пустое значение, если
в области видимости нет элементов или их больше одного, и позволяет за-
дать альтернативное значение, которое будет возвращено в обратном случае.
Таким образом, меру, показанную выше, можно переписать так:
Sales by Scale =
DIVIDE (
[Sales],
SELECTEDVALUE ( 'Scale'[Scale], 1 )
)
Вы можете увидеть эту технику в действии в файле с примерами на стра-

нице SELECTEDVALUE.
Используйте функции IFERROR и ISERROR уместно

В языке DAX присутствуют так называемые функции-помощники, которые
разработчик может использовать для перехвата ошибок в вычислениях. В эти
функции можно заключать целые меры, чтобы управлять возвращаемыми
ими значениями. В то же время к использованию таких функций нужно при-
бегать с большой осторожностью, поскольку они увеличивают количество
операций сканирования в движке хранилища и могут приводить к запуску
медленных построчных вычислений. Мы рекомендуем выполнять проверку
на ошибки на стороне источника или средствами ETL, чтобы этим не при-
ходилось заниматься в DAX. К сожалению, это не всегда осуществимо, так
что вы должны уметь при необходимости пользоваться приведенными ниже
техниками:
использовать функции FIND() или SEARCH() для поиска и замены значе-
ний для безуспешных соответствий;
применять функции DIVIDE или SELECTEDVALUE для управления пустыми
и нулевыми значениями.
Используйте функцию SUMMARIZE только с текстовыми

столбцами
Функция SUMMARIZE() используется в языке DAX для осуществления группи-
ровок. Тогда как она позволяет работать со столбцами любых типов, мы не
рекомендуем применять ее к числовым колонкам по соображениям произ-
водительности. Вместо этого лучше воспользоваться новой оптимизирован-
ной функцией SUMMARIZECOLUMNS(). На эту тему существует немало полезных
примеров, и мы советуем вам обратить внимание на статью на сайте SQLBI,
в которой производится углубленный разбор, по адресу https://www.sqlbi.com/
articles/introducing-summarizecolumns.
Избегайте использования функции FILTER при передаче

фильтрующих условий
Такие функции, как CALCULATE() и CALCULATETABLE(), принимают на вход пара-
метр с фильтром, позволяющий настраивать контекст вычисления. Функция
FILTER() возвращает таблицу, но ее использование для установки фильтру-
ющих условий в других функциях является неэффективным. Вместо этого
лучше преобразовать вызов функции FILTER в булево выражение. Рассмотрим
для примера следующую меру:
Wingtip Sales FILTER =
CALCULATE(
[Sales],
FILTER('Dimension Customer', 'Dimension Customer'[Buying Group] == "Wingtip Toys")
)
С целью повышения эффективности рекомендуется заменить в качестве

параметра функции табличное выражение на булево, как показано ниже:
Wingtip Sales =
CALCULATE(
[Sales],
'Dimension Customer'[Buying Group] == "Wingtip Toys")
)
Функция FILTER может приводить к запуску построчных операций в движ-

ке, тогда как передача булева выражения позволит использовать более эф-
фективную фильтрацию колоночного хранилища.
Используйте функцию COUNTROWS вместо COUNT

Часто разработчикам приходится писать меры с подсчетом количества строк
в таблице в рамках заданного контекста. В отсутствие пустых значений мож-
но использовать два вида вычислений, которые будут возвращать одина-
ковые результаты. Функция COUNT() принимает на вход ссылку на столбец,
а COUNTROWS() – на таблицу. Когда вам необходимо просто посчитать коли-
чество строк, не заботясь о пустых значениях, второй вариант будет значи-
тельно эффективнее.
Используйте функцию ISBLANK вместо BLANK

Эти функции возвращают одинаковый результат, но ISBLANK() работает быст
рее, чем BLANK().
Оптимизируйте виртуальные связи при помощи функции

TREATAS
Иногда нам необходимо отфильтровать таблицу на основании значений
столбца из другой таблицы в условиях невозможности создания между эти-
ми таблицами физической связи. Бывает, что для создания уникального
ключа нужно использовать сразу несколько столбцов, или связь между таб
лицами установлена с типом «многие ко многим». Эту задачу можно решить,
используя функции FILTER() и CONTAINS() или же INTERSECT(). В то же время
функция TREATAS() будет работать быстрее, и рекомендуется использовать
именно ее.
Откройте страницу с названием TREATAS в файле с примерами. На рис. 11.7
показан пример, в котором мы добавили таблицу с группами вознагражде-
ний для клиентов на основании столбцов Buying Group и Postal Code. Нам
необходимо отфильтровать данные о продажах по столбцу Reward Group из
новой таблицы. При этом мы не можем создать связь между таблицами на
основании более чем одного ключевого столбца.
Рис. 11.7  Новая таблица Reward Group

не может быть связана с таблицей Customer
Можно написать следующую меру с использованием функции CONTAINS:

RG Sales CONTAINS =
CALCULATE(
[Sales],
FILTER(
ALL('Dimension Customer'[Buying Group]),
CONTAINS(
VALUES(RewardsGroup[Buying Group]),
RewardsGroup[Buying Group],
'Dimension Customer'[Buying Group]
)
),
FILTER(
ALL('Dimension Customer'[Postal Code]),
CONTAINS(
VALUES(RewardsGroup[Postal Code]),
RewardsGroup[Postal Code],
'Dimension Customer'[Postal Code]
)
)
)
Получилась довольно длинная мера для весьма простой логики, да и с про-

изводительностью у нее будут проблемы. Гораздо лучше для этого восполь-
зоваться функцией TREATAS, как показано ниже:
RG Sales TREATAS =
CALCULATE(
[Sales],
TREATAS(
SUMMARIZE(RewardsGroup, RewardsGroup[Buying Group],
RewardsGroup[Postal Code]),
'Dimension Customer'[Buying Group],

'Dimension Customer'[Postal Code]
)
)
Мы не продемонстрировали версию меры с использованием функции IN-

TERSECT – можем лишь сказать, что она будет чуть короче, чем с CONTAINS,
и чуть быстрее. Но чемпионом по всем показателям все равно остается вер-
сия с функцией TREATAS. На рис. 11.8 мы показали небольшую таблицу, при
формировании которой при использовании функции TREATAS нам удалось
добиться 25%-го улучшения производительности. Также мы сократили ко-
личество внутренних запросов в движке хранилища с 11 до 8.
Рис. 11.8  Визуальный элемент

для тестирования функций CONTAINS и TREATAS
Теперь, когда вы узнали о методах оптимизации в языке DAX, мы можем

подвести итоги этой главы.
В этой главе мы узнали о важности улучшения выражений DAX, посколь-
ку неоптимально написанные формулы способны свести на нет все усилия
в области моделирования данных. Причина этого в том, что шаблоны DAX
непосредственно влияют на то, как именно Analysis Services будет извлекать
данные и проводить вычисления.
Проверку своих оптимизаций выражений, написанных на языке DAX, мы
выполняли при помощи уже знакомых вам инструментов, описанных в пре-
дыдущих главах. Сначала мы привели пример использования Best Practice
Analyzer и визуального анализа для поиска и исправления узких мест в фор-
мулах. После этого мы воспользовались Desktop Performance Analyzer для
перехвата запросов, сгенерированных визуальными элементами, после чего
запускали их при помощи DAX Studio для лучшего понимания их поведения.
В процессе анализа очень важно обращать внимание на общую длительность
выполнения запроса, количество внутренних запросов, а также время, потре-
бовавшееся движку формул и движку хранилища. После проверки внесенных
изменений в DAX Studio можно применять обновления к набору данных
и тестировать отчеты на рабочих сценариях для сравнения показателей.
В завершение главы мы рассмотрели распространенные ловушки в языке

DAX и указали способы их обхода. Нашей главной целью является снижение
степени задействования движка формул в общем процессе и уменьшение ко-
личества запросов, обрабатываемых движком хранилища. Для большинства
оптимизаций мы привели визуальные элементы и подтверждения повыше-
ния производительности на примере DAX Studio, чтобы вы могли в дальней-
шем сами улучшать свои запросы и знали, на что именно нужно обращать
внимание.
Вы уже достаточно узнали об оптимизации решений на базе Power BI, но
при работе с действительно большими объемами данных у вас по-прежнему
могут возникать проблемы с производительностью, для устранения которых
может потребоваться дополнительное моделирование и применение аль-
тернативного архитектурного подхода. Таким образом, в следующей главе
книги мы рассмотрим техники, которые помогут вам управлять данными,
исчисляемыми терабайтами.
Глава 12
Шаблоны работы
с большими данными
В предыдущей главе мы говорили о важности проведения оптимизации вы-

ражений DAX. Таким образом, к этому моменту мы обсудили аспекты по-
вышения производительности практически для всех слоев решений на базе
Power BI: от наборов данных до отчетов. В этой главе мы сделаем шаг назад
и снова поговорим об архитектурных концепциях и связанных с ними воз-
можностях, которые помогут в работе с действительно большими объемами
данных.
Количество информации, собираемое и обрабатываемое в организациях,
постоянно растет. С появлением концепции интернета вещей (Internet of
Things – IoT) в некоторых областях промышленности, таких как энергетика
и управление ресурсами, объемы накапливаемых данных стали превышать
все мыслимые пределы. Для любой современной угледобывающей компании
или газоперерабатывающего завода наличие десятков тысяч датчиков, со-
бирающих информацию с высокой степенью гранулярности (гораздо чаще,
чем раз в секунду), – обычная практика.
Даже с учетом самых мощных технологий сжатия данных, применяющихся
в Power BI, не всегда можно загрузить и сохранить такие объемы информации
в режиме Import за приемлемое время. И масштабы проблем возрастают,
когда вам необходимо поддерживать одновременную работу сотен или ты-
сяч пользователей. В данной главе мы поговорим о способах борьбы с этими
трудностями, включая использование емкостей Power BI Premium, техно-
логий Azure, а также составных моделей и агрегатов. Концепции, которые
мы будем обсуждать, являются взаимодополняемыми и при необходимости
могут быть использованы совместно в одном решении.
В этой главе мы обсудим следующие темы:
масштабирование при помощи Power BI Premium и Azure Analysis Ser-
vices;
масштабирование с использованием составных моделей и агрегатов;
масштабирование с Azure Synapse и Data Lake.
216  Шаблоны работы с большими данными
Для этой главы мы подготовили один составной файл с примерами, который
называется Composite and Aggs.pbix. Его можно найти в папке Chapter12 в хра-
нилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-
Performance-Best-Practices. Поскольку в этом файле используется режим Direc-
tQuery для доступа к базе данных SQL Server, мы включили в список файлов
бэкап базы с именем AdventureWorksLT2016.bak. Вы можете восстановить базу
данных из этого бэкапа в SQL Server и обновить подключение в Power BI
Desktop для успешного запуска примеров.
Масштабирование при помощи Power BI

Premium и Azure Analysis Services
Пользователи Power BI с лицензией Pro могут создавать рабочие области
в общих емкостях или емкостях Premium. Общая емкость (shared capacity)
доступна по умолчанию для всех организаций, использующих Power BI. Эта
емкость полностью управляется со стороны Microsoft, которая распределяет
нагрузку между разными клиентскими окружениями (тенантами) на тысячах
физических серверов по всему миру. Для обеспечения стабильной работы
пользователей в общей емкости используются определенные ограничения.
Первое из них касается объема сжатого набора данных и составляет 1 Гб.
Power BI Desktop позволяет вам создавать наборы данных, объем которых
ограничен только физической памятью на вашем компьютере, но в общую
емкость вы не сможете загрузить датасет размером больше 1 Гб. Также если
набор данных, размещенный в общей емкости, разрастется и станет зани-
мать больше 1 Гб, начнут возникать ошибки с обновлением. Обратите вни-
мание, что это ограничение касается именно сжатых данных, так что объем
реальных данных может быть в несколько раз больше.
Использование Power BI Premium

для масштабирования данных
Одним из способов обойти ограничение общей емкости на предельный раз-
мер набора данных является использование выделенной емкости Power BI
Premium. Емкость Premium приобретается отдельно, и в ней предусмотрено
выделение вычислительных ресурсов на организацию. При этом емкости
Premium ранжируются по выделяемому объему ресурсов от P1 (8 ядер про-
цессора и 25 Гб памяти) до P5 (128 ядер процессора и 400 Гб памяти). Также
здесь стоит упомянуть о предлагаемых компанией Microsoft емкостях Po
wer BI Embedded. Несмотря на то что их необходимо приобретать и оплачи-
вать отдельно, технологии в данном случае используются точно такие же,
Масштабирование при помощи Power BI Premium и Azure Analysis Services  217
и все советы, применимые к емкостям Premium, могут быть успешно при-

менены и к емкостям Embedded.
Емкость Premium предлагает некоторые уникальные возможности, мень-
шие ограничения и дополнительные опции, помогающие повысить произво-
дительность и масштабировать систему. Подробно об оптимизации емкости
Premium мы будем говорить в главе 13. Сейчас вам достаточно будет знать,
что в емкости Premium лимит на размер набора данных увеличен до 10 Гб.
Это касается исходного датасета, загружаемого в емкость Premium.
Если объем вашего набора данных превышает 1 Гб, вы должны рассмотреть вари-
ант использования емкости Power BI Premium. Это позволит вам загружать наборы
объемом до 10 Гб с допустимым увеличением до 12 Гб после обновления. При этом
если в настройках датасета установить формат хранения крупных наборов данных,
ограничение на его размер будет снято. В этом случае единственным сдерживающим
фактором останется объем доступной памяти в емкости. Вы даже можете выделить
две емкости Premium разных размеров и соответствующим образом распределять
нагрузку между ними. Всегда старайтесь иметь свободную память в емкости для хра-
нения временных таблиц для запросов, в которых могут присутствовать несжатые
данные. Кроме того, использование формата хранения крупных наборов данных мо-
жет положительно сказаться на скорости операций записи, производимых посред-
ством конечных точек XMLA.
На рис. 12.1 показана опция настройки Формат хранения крупных набо-

ров данных (Large dataset storage format) применительно к опубликованно-
му датасету. Этот переключатель можно найти на вкладке наборов данных
в рабочей области Power BI. Для отключения ограничения на размер набора
данных установите переключатель в положение Вкл (On).
Рис. 12.1  Настройка формата хранения крупных наборов данных
Стоит отметить, что режим формата хранения крупных наборов данных

может быть установлен в емкости Premium по умолчанию. При этом адми-
нистраторы имеют возможность устанавливать максимальный размер для
наборов данных, чтобы пользователи не израсходовали всю память, доступ-
ную в емкости.
С активированной опцией хранения крупных наборов данных емкость
Premium идеально подходит для выполнения масштабирования данных. Она
также допускает расширение количества пользователей благодаря наличию
достаточных вычислительных ресурсов для поддержки большого количества
параллельных запросов и сессий. Этому способствует и возможность выде-
ления нескольких емкостей – так вы сможете разнести наиболее популярные
наборы данных по разным емкостям.
Но ничто не вечно и не бесконечно, и при наличии емкости Premium вы

также можете достигнуть ее пределов в отношении объема данных и коли-
чества одновременно работающих пользователей. Посмотрим, как с этим
позволит справиться платформа Azure Analysis Services.
Использование Azure Analysis Services

для масштабирования данных и пользователей
Azure Analysis Services (AAS) представляет собой предложение от Microsoft
в формате платформа как услуга (Platform-as-a-Service – PaaS). AAS входит
в состав обширного набора служб от Microsoft в облаке Azure. При этом в ва-
шем распоряжении будет выбор из линейки планов SKU – каждый со своей
вычислительной мощностью, выраженной в единицах обработки запросов
(Query Processing Units – QPU).
AAS можно рассматривать в качестве облачной альтернативы SQL Server
Analysis Services. Для компаний, работающих с SSAS и желающих мигриро-
вать в облако, AAS является самым простым и надежным вариантом.
Оплата AAS производится только по факту использования услуги, кроме
того, вы можете приостановить действие службы и масштабировать свой
пакет по необходимости. Также вы сможете пользоваться полноценной под-
держкой инструментов разработчика Power BI Pro, таких как Microsoft Visual
Studio с системой контроля версий и возможностью интеграции с CI/CD (не-
прерывная интеграция и непрерывная поставка). Как и SQL Server Analysis
Services, AAS включает в себя только движок обработки данных, так что его
функции ограничены хранением наборов данных и их обработкой. Таким
образом, для размещения отчетов вам по-прежнему придется пользоваться
клиентским инструментом, таким как Power BI Desktop или портал PowerBI.
com. Службу AAS можно рассматривать как подкласс емкости Premium, но на
сегодняшний день это не совсем так. Причина – в таких серьезных отличиях,
как динамическое управление памятью, присутствующее только в емкости
Premium, и технология горизонтального масштабирования запросов (Query
Scale Out – QSO), доступная лишь в AAS. Эта технология позволяет увели-
чить количество одновременно работающих с системой пользователей с ми-
нимальными накладными расходами, и на сегодняшний день ее очень не
хватает в емкости Premium. В то же время не может не радовать заявленное
стремление компании Microsoft сделать емкость Premium своеобразной рас-
ширенной версией AAS.
Использование горизонтального масштабирования

запросов для увеличения количества пользователей
В Power BI Premium и AAS используются одинаковые ограничения в отно-
шении размера набора данных. При этом в AAS реализована технология го-
ризонтального масштабирования запросов (QSO), позволяющая значитель-
но расширить количество одновременно работающих пользователей путем
распределения нагрузки чтения запросов между несколькими репликами

данных. Вы просто настраиваете службу на создание дополнительных копий
данных (максимальное количество копий ограничено семью). В результа-
те поступающие подключения от клиентов распределяются по созданным
репликам. Обратите внимание, что не все регионы использования и планы
SKU поддерживают создание семи реплик. Дополнительную информацию
по этому поводу можно узнать на странице https://learn.microsoft.com/en-us/
azure/analysis-services/analysis-services-overview. Также стоит упомянуть, что
создание реплик – удовольствие не бесплатное, что необходимо учитывать
при планировании производительности.
Еще одной полезной возможностью AAS при использовании горизонталь-
ного масштабирования запросов является разделение серверов запросов
и серверов обработки. Это позволяет повысить производительность обе-
их операций. Например, в случае выполнения обновления одна из реплик
целиком будет выделена под эту операцию, и никакие другие подключения
не будут обрабатываться этой репликой. Таким образом, можно физически
разделить реплики, выполняющие операции чтения и записи.
Настройку реплик можно выполнить на портале Azure или с помощью
скрипта PowerShell. На рис. 12.2 показан пример создания дополнительной
реплики запроса.
Рис. 12.2  Сервер AAS с одной репликой

и подсветкой возможности разделения нагрузки
Обратите внимание, что создание реплик не дает вам возможность хра-

нить наборы данных большего размера, чем без использования механизма
горизонтального масштабирования запросов. Вместо этого создаются иден-
тичные копии данных с тем же планом SKU.
В завершение давайте поговорим о том, как определить, что настало время
прибегать к помощи масштабирования. У вас есть возможность наблюдать
за метриками AAS на портале Azure и, в частности, следить за поведением
метрики QPU (Query Processing Units) с течением времени. Если вы видите,
что эта метрика часто достигает верхней допустимой границы и на эти пики
приходятся интервалы падения производительности, значит, самое время
задуматься о горизонтальном масштабировании запросов. На рис. 12.3 по-
казан график метрики QPU для сервера AAS с планом S0 и ограничением
в 40 единиц. Как видите, в данный момент никаких критических всплесков

в этой области не наблюдается.
Рис. 12.3  Отслеживание метрики QPU на портале Azure
Теперь посмотрим, как использование секционирования может повысить

эффективность обновлений.
Использование секционирования с AAS

и Premium
В AAS секционированные таблицы (partitioned tables) поддерживаются уже
много лет. Секционирование (partitioning) просто делит таблицу на более мел-
кие составляющие, которыми можно управлять по отдельности. Обычно сек-
ционирование применяется к таблицам фактов и выполняется на основе дат.
К примеру, у вас в распоряжении могут быть данные за пять лет, разбитые
на 60 секций по месяцам. В этом случае вы сможете обрабатывать каждую
секцию отдельно и даже выполнять над ними различные операции, напри-
мер очищать данные в одной секции в момент загрузки данных в другую.
С точки зрения производительности секционирование может положитель-
но влиять на обновление данных по двум причинам:
во-первых, это дает вам возможность обрабатывать только новые и об-
новленные данные, не затрагивая при этом секции с исторической
информацией;
во-вторых, эффективность обновления может повыситься благодаря
параллельной обработке секций.
Максимального параллелизма при этом можно добиться при наличии ре-
сурсов центрального процессора и памяти в AAS и поддержке нагрузки ис-
точником данных. AAS автоматически применяет параллельные вычисления

для двух и более секций, и это поведение нельзя отменить при помощи на-
строек.
В Power BI Premium (с форматом хранения крупных наборов данных) и AAS раз-
мер сегмента составляет 8 млн строк. Сегменты (segments) представляют собой внут
ренние структуры, используемые для разбиения столбцов на блоки, к которым при-
меняется операция сжатия. Таким образом, рекомендуется использовать стратегию
с минимальным количеством строк в секции, равным 8 млн, при полной загрузке. Это
позволит добиться наиболее эффективного сжатия данных и избежать дополнитель-
ной работы с данными в мелких секциях. Избыточная степень секционирования мо-
жет привести к замедлению операций обновления и увеличению размера датасета.
Таблицы, определенные в наборе данных Power BI, по умолчанию состоят

из одной секции. У вас нет возможности напрямую управлять процессом
секционирования в Power BI Desktop. Однако при настройке добавочного
обновления секции создаются автоматически, а за основу берутся настройки
гранулярности времени и актуальности данных.
Таким образом, при использовании AAS или Power BI Premium вам пона-
добится обратиться к внешним инструментам для управления секциями.
Например, в процессе разработки секции могут быть созданы в Visual Stu-
dio – для этого нужно воспользоваться инструментом Partition Manager. По
окончании разработки секциями можно управлять в SQL Server Management
Studio посредством языка Tabular Model Scripting Language (TMSL). Также
можно обращаться к секциям программно при помощи табличной объектной
модели (Tabular Object Model – TOM).
Управлять параллелизмом в момент обновления можно при помощи па-
раметра MaxParallelism в языке TMSL, который отвечает за ограничение
общего количества параллельных операций вне зависимости от источника
данных. В главе 8 мы уже приводили скрипт TMSL с использованием этого
параметра.
Ранее в этой главе мы описали простейший пример с секционировани-
ем по месяцам. Более продвинутый подход может предполагать хранение
годовых или месячных исторических секций одновременно с дневными ак-
тивными секциями. Это придает больше гибкости процессу обновления не-
давних фактов и минимизирует затраты на повторную обработку в случае
возникновения ошибок обновления, поскольку вы можете запустить обра-
ботку всего за один день. Однако такая стратегия требует дополнительных
усилий, ведь секции необходимо объединять. Например, в конце каждого
месяца вам может понадобиться объединять все дневные секции в месячную.
Делать это все вручную может быть очень утомительно. Разумеется, луч-
ше автоматизировать данный процесс с помощью так называемых таблиц
отслеживания (tracking tables) для управления диапазонами дат и секция-
ми. Подробный пример автоматизации процесса управления секциями был
опубликован разработчиками компании Microsoft по адресу https://github.
com/microsoft/Analysis-Services/blob/master/AsPartitionProcessing/Automated%20
Partition%20Management%20for%20Analysis%20Services%20Tabular%20Models.
pdf, и мы рекомендуем придерживаться этого подхода.
Последнее, о чем хотелось бы упомянуть в данном разделе, – это режимы

синхронизации (synchronization mode) реплик запроса. При обновлении на-
боров данных реплики, задействованные в горизонтальном масштабирова-
нии запросов, также должны быть обновлены, чтобы все пользователи могли
оперировать актуальными данными. По умолчанию реплики восстанавли-
ваются полностью (без добавочного обновления) и поэтапно. При наличии
как минимум трех реплик они будут отсоединяться и присоединяться по
две за раз, что может привести к отключению некоторых клиентов. Такое
поведение регламентируется при помощи серверного свойства ReplicaSync-
Mode, которое может быть установлено в SQL Server Management Studio, как
показано на рис. 12.4. Эта настройка может быть изменена, чтобы синхро-
низация выполнялась в параллельном режиме. В этом случае обновление
кешей в памяти будет происходить постепенно, что положительно скажется
на общем времени синхронизации. Также мы выиграем от того, что подклю-
чения не будут прерываться, поскольку все реплики всегда будут находиться
в доступе.
Рис. 12.4  Свойство ReplicaSyncMode было изменено
Для свойства ReplicaSyncMode допустимы следующие значения:

1 – полное поэтапное восстановление. Установка по умолчанию;
2 – параллельная синхронизация.
При использовании параллельной синхронизации может понадобиться дополни-
тельная память для размещения реплик, которые всегда остаются в доступе для за-
просов. Операция синхронизации ведет себя в целом как обычное обновление дан-
ных, которое может потребовать вдвое больше памяти, чем занимает набор данных,
как мы уже знаем из главы 2.
В следующем разделе мы посмотрим, как в Power BI можно эффективно

использовать составные модели для решения проблем с большими данными
и медленными запросами DirectQuery.
Масштабирование с использованием составных моделей и агрегатов  223
Масштабирование с использованием
составных моделей и агрегатов
До сих пор мы говорили, что максимальную производительность наборам
данных в Power BI обеспечивает режим хранения Import. Но иногда большие
объемы данных и связанные с этим ограничения на обновление приводят
вас к решению использовать режим DirectQuery. Здесь у вас может возник-
нуть желание перечитать главу 2, в которой мы говорили о выборе режимов
хранения и их преимуществах и недостатках.
Также мы рассказывали о способности Analysis Services очень эффективно
агрегировать данные, а в решениях из области бизнес-аналитики агрега-
ция используется большую часть времени. Применение режима DirectQuery
позволяет делегировать обязанности по агрегированию данных источнику,
чтобы избавить от этих ресурсоемких операций Power BI. Если вы работае-
те с десятками миллионов или миллиардами строк, агрегация может стать
узким местом в плане производительности системы, даже если источник
данных хорошо оптимизирован. И здесь вам могут прийти на помощь со-
ставные модели данных и агрегаты.
Составные модели данных

В предыдущих главах книги мы вели речь отдельно либо о режиме хранения
Import, либо о DirectQuery. Это могло создать у вас впечатление, что эти
режимы взаимоисключающие, хотя на самом деле это не так. В Analysis Ser-
vices у вас есть возможность создавать составные модели данных (composite
model), также называемые моделями со смешанным режимом (mixed mode),
что позволяет комбинировать в одном наборе данных режимы DirectQuery
и Import. Это открывает перед вами интересные возможности. Например, вы
можете обогащать источники DirectQuery за счет редко изменяемых данных
в режиме Import, хранящихся в другом месте. Также вы можете сочетать не-
сколько источников в режиме DirectQuery. При этом вы можете следовать
всем рекомендациям относительно режимов хранения Import и DirectQuery,
о которых мы писали ранее. Здесь же мы обсудим нюансы построения и под-
держки составных моделей данных.
В Analysis Services режим хранения устанавливается на уровне таблицы.
Именно это позволяет нам сочетать таблицы с разными режимами в одном
наборе данных. В правом нижнем углу Power BI Desktop выводится информа-
ция о типе открытой модели. Если модели соответствует тип Import, никаких
специальных статусов вы здесь не увидите. Если же вы имеете дело со сме-
шанной моделью или моделью в режиме DirectQuery, то в строке состояния
будет выводиться соответствующая пометка, показанная на рис. 12.5.
Существуют разные способы установки для модели смешанного типа
(Mixed) в Power BI Desktop. Вы можете добавить таблицу с режимом Import
к существующей модели с типом DirectQuery или наоборот. Также можно из-
менить тип модели вручную на вкладке Модель (Model) в Power BI Desktop,

Рис. 12.5  Информация о режиме хранения модели в Power BI Desktop
Рис. 12.6  Изменение режима хранения модели в Power BI Desktop
На представленном рисунке можно заметить сразу несколько любопытных

особенностей. В выпадающем списке Режим хранения (Storage mode) пред-
ставлены следующие варианты: Импорт (Import), DirectQuery и Двойной
(Dual). Что касается самой диаграммы, то здесь о режиме хранения таблиц го-
ворит внешний вид их заголовков. При установке двойного режима Analysis
Services будет решать в зависимости от области видимости и гранулярности
запроса, использовать ли внутренний кеш или актуальные данные из источ-
ника. Давайте подробнее рассмотрим режимы хранения таблиц и подумаем,
когда стоит их использовать:
DirectQuery: об этом режиме свидетельствует синяя полоса в заголов-
ке с иконкой DirectQuery (на нашем рисунке это таблица OrderDetail).
Этот режим стоит выбирать для таблиц очень большого объема или при
необходимости извлекать только актуальные данные из источника. Po
wer BI никогда не будет импортировать данные из таких таблиц при об-
новлении. Обычно режим DirectQuery применяется для таблиц фактов;
Импорт (Import): для таблиц с этим режимом заголовки остаются бе-
лыми – без дополнительного цветового оформления (в нашей модели
такой таблицей является ProductCategory). Выбирайте режим импорта
для таблиц небольшого размера или хорошо сжимаемых, которым тре-

буется высокая скорость извлечения данных и информация в которых
меняется не так часто, как в источниках DirectQuery. При выборе этого
режима вы не должны планировать использование этих таблиц для
фильтрации или группировки таблиц фактов;
Двойной (Dual): таблицы с этим смешанным режимом хранения по-
мечены на диаграмме пунктирным сине-белым заголовком с иконкой
DirectQuery (в нашем примере это таблица Product). Этот режим реко-
мендуется выбирать для таблиц, выступающих в качестве измерений
и использующихся для фильтрации или группировки таблиц фактов, т. е.
для таблиц, хранящихся в режиме DirectQuery. Это означает, что в не-
которых сценариях информация из этой таблицы будет запрашиваться
вместе с данными из таблиц фактов, располагающихся в источнике.
Теперь давайте узнаем, как перечисленные режимы хранения использу-
ются движком в различных сценариях. Это поможет вам правильно опреде-
литься с режимами для ваших таблиц, что очень важно для настройки связей
между таблицами и в конечном счете критически влияет на производитель-
ность. Ниже перечислены возможные сценарии запросов:
в запросе используются только таблицы с режимами Импорт или
Двойной: такие запросы применяются для наполнения срезов или
фильтров, обычно с измерениями. При их выполнении достигается
максимальная производительность за счет использования кеша;
в запросе используются таблицы с режимами Двойной или Di-
rectQuery из одного источника: эта ситуация возникает при необ-
ходимости связать измерения в режиме Двойной с таблицами фактов
в режиме DirectQuery. В результате будут генерироваться один или
несколько машинных запросов к источнику DirectQuery, за счет чего
может достигаться относительно хорошая производительность, при ус-
ловии что источник оптимизирован согласно советам из главы 3. Связи
типа «один к одному» или «один ко многим» в рамках одного источни-
ка расцениваются как обычные связи, которые функционируют очень
эффективно. Под обычной связью мы подразумеваем связь, в которой
на стороне «один» располагается таблица с уникальными значениями;
все остальные запросы: в эту категорию попадают все запросы, в ко-
торых устанавливаются связи между разными источниками. Это про-
исходит, когда таблице с режимом хранения Двойной или Импорт из
источника А необходимо объединиться с таблицей в режиме DirectQue-
ry из источника Б. В этом случае используются ограниченные связи (limi
ted relationships), что негативно сказывается на производительности.
Связи типа «многие ко многим» и связи между разными источниками
данных причисляются к ограниченным.
Теперь давайте расставим связи от наиболее приоритетных к использова-
нию к наименее приоритетным.
1. Связи типа «один ко многим» в рамках одного источника данных (са-
мые быстрые).
2. Связи типа «многие ко многим» с использованием таблиц-мостов и как
минимум одной двунаправленной связи.
3. Связи типа «многие ко многим».

4. Связи между разными источниками данных (самые медленные).
Далее мы перейдем к теме агрегатов и их связи с составными моделями
данных.
Использование агрегатов
В подавляющем большинстве аналитических сценариев в том или ином
виде используются агрегированные данные. Обычно принято анализировать
исторические тренды, отклонения и выбросы в обобщенном виде, после чего
при необходимости углубляться в детализацию. Давайте в качестве примера
рассмотрим работу логистической компании по отслеживанию тысяч от-
правок. Вряд ли вы можете себе представить, что базовый анализ компании
может начинаться с детализации до конкретной посылки. Скорее всего, из-
начально аналитика строится с группировкой по типу транспортировки или
региону. В случае появления цифр, не отвечающих определенным критери-
ям, можно углубиться в данные в поисках причин отклонений. В главе 9 мы
подробно говорили о таком методе анализа как одном из наиболее эффек-
тивных и удобных.
При всем этом вы можете следовать всем рекомендациям при проекти-
ровании модели, но все равно столкнуться с проблемами быстродействия
отчетов при использовании объемных наборов данных в режиме DirectQuery.
Даже с учетом проведения всех оптимизаций существует физический предел
в отношении обработки данных с использованием ограниченных ресурсов
компьютера. В таких ситуациях на помощь приходят агрегаты (aggregations),
реализованные в Power BI. Агрегатная таблица (aggregation table) представ-
ляет собой слепок сгруппированных данных из таблицы фактов, хранящийся
в памяти в режиме Import. Таким образом, содержимое этих таблиц следует
актуализировать во время обновления данных.
Давайте продолжим работать с примером, показанным на рис. 12.6, и соз-
дадим агрегат для таблицы OrderDetail во избежание выполнения внешних
запросов DirectQuery. Допустим, мы выяснили, что очень часто в наших от-
четах используются агрегированные данные о продажах на уровне товаров.
Таким образом, мы сможем значительно повысить быстродействие запросов,
если создадим соответствующую агрегатную таблицу с промежуточными
данными. Добавим таблицу с именем Agg_SalesByProduct в режиме Import
с использованием следующего запроса SQL:
SELECT
ProductID,
sum(sod.LineTotal) as TotalSales,
sum(sod.OrderQty) as TotalQuantity
FROM
[SalesLT].[SalesOrderDetail] sod
GROUP BY ProductID
После создания таблицы необходимо сообщить Power BI о том, как ее нуж-

но использовать. Щелкните правой кнопкой мыши по таблице OrderDetail
и выберите пункт Управление агрегированием (Manage aggregations). В от-

крывшемся диалоговом окне выполните настройки, показанные на рис. 12.7.
Рис. 12.7  Настройка агрегата для таблицы OrderDetail
Здесь необходимо сделать несколько пояснений. Во-первых, нам необхо-

димо дать понять Power BI, какую именно таблицу мы хотим использовать
в качестве агрегата для таблицы OrderDetail. Во-вторых, нужно установить
соответствие между столбцами и задать тип используемой агрегации. Также
мы можем установить определенное значение в поле Приоритет (Prece-
dence) на случай, если у нас будет несколько агрегатов для разных грануляр-
ностей. Таким образом, мы устанавливаем порядок использования агрегатов
в том случае, если значение может быть получено из разных агрегатных
таблиц. После создания агрегата остается только установить связь между
агрегатной таблицей и измерением Product, как показано на рис. 12.8.
Рис. 12.8  Таблица Agg_SalesByProduct

в режиме импорта связана с таблицей Product в смешанном режиме
Заметьте, что сама агрегатная таблица и все ее столбцы в наборе дан-

ных Power BI являются скрытыми. Это происходит по умолчанию, чтобы не
вводить пользователей в заблуждение. Агрегатные таблицы действительно
можно не показывать и полагаться на движок, который в нужный момент
будет выбирать данные из нужной таблицы.
В этом примере мы продемонстрировали работу агрегатов на основании связей. Мы
полагаемся на связь, благодаря которой значения из таблицы Product могут фильт
ровать таблицу OrderDetail. При добавлении агрегатной таблицы нам нужно было
создать эту связь. В то же время в системах обработки больших данных, основанных
на Hadoop, данные зачастую хранятся в широких денормализованных таблицах во
избежание создания ресурсоемких объединений таблиц во время выполнения за-
просов. Для таких сценариев в Power BI мы также можем использовать агрегатные
таблицы, но без необходимости создания связей.
Теперь давайте посмотрим в DAX Studio, когда и какие агрегаты исполь-

зуются во время выполнения запросов. Начнем с создания трех табличных
визуальных элементов по продажам с разными уровнями группировки, по-
казанных на рис. 12.9. В файле с примерами этот отчет можно найти на
странице Aggs Comparison.
Рис. 12.9  Разные группировки с продажами для проверки агрегатов
Как видите, мы продолжили работать с таблицами, модель данных для

которых была показана на рис. 12.8. Далее воспользуемся инструментом DAX
Studio для перехвата запросов и выясним, что происходит «под капотом»:
A: Grouping by Product table (визуальный элемент с группировкой
по товарам): запрос для этого элемента визуализации обошелся об-
ращением только к таблицам с режимом хранения Import. При этом
ему понадобилось сгенерировать всего один внутренний запрос для
движка хранилища. Обратите внимание на рис. 12.10, что DAX Studio
предоставил информацию для подкласса события RewriteAttempted,
а это означает, что движок обнаружил подходящий агрегат и пытается
его использовать в расчетах. Вы можете щелкнуть на этом событии,
чтобы получить более подробную информацию в правой части окна.
Как видите, здесь указано, какая именно агрегатная таблица была ис-
пользована в запросе;
Рис. 12.10  Информация о запросе для визуального элемента A
B: Grouping by ProductCategory table (визуальный элемент с группи-

ровкой по категориям товаров): и снова нашему запросу хватило ин-
формации из таблиц с режимом хранения Import. Обратите внимание:
несмотря то что таблица ProductCategory напрямую не связана с агре-
гатной таблицей, движок смог воспользоваться информацией из нее,
используя в качестве моста таблицу Product, что видно на рис. 12.11.
Это позволило нам избежать выполнения внешнего запроса для дан-
ного сценария;
Рис. 12.11  Информация о запросе для визуального элемента B
C: Grouping by Product and Customer table (визуальный элемент

с группировкой по товарам и клиентам): на этот раз движок попытал-
ся воспользоваться агрегатом для таблицы с клиентами, но ожидаемо
не смог этого сделать, поскольку мы не создавали агрегации на уровне
грануляции клиентов. В результате был использован внешний запрос,
что подтверждается наличием в таблице подкласса события SQL. Это
показано на рис. 12.12. К счастью, агрегатной таблицей движку удалось
воспользоваться позже по ходу выполнения запроса.
Рис. 12.12  Информация о запросе для визуального элемента C

На этом примере мы увидели, как могут использоваться агрегаты по вре-

мя выполнения запросов, однако пока что не сравнивали быстродействие
запросов с агрегатами и без них. Чтобы это сделать, достаточно удалить
созданную ранее агрегатную таблицу и снова перехватить запросы с помо-
щью DAX Studio, измерив общую длительность их выполнения. В табл. 12.1
представлена сводная информация.
Таблица 12.1. Сравнение производительности запросов с агрегатами и без них

Без агрегатов С агрегатами Комментарии
Визуальный элемент A 80 мс 3 мс С агрегатом намного быстрее
Визуальный элемент B 155 мс 5 мс С агрегатом намного быстрее
Визуальный элемент C 340 мс 500 мс С агрегатом вышло медленнее
из-за накладных расходов на обращение
к разным источникам с небольшим
объемом данных
В нашем примере создать и воспользоваться агрегатом было довольно

просто. На практике же бывает весьма сложно предсказать заранее слож-
ность, объем и частоту запросов, которые будут сгенерированы в результате
выполнения операции. Это значительно затрудняет задачу заблаговремен-
ного планирования создания агрегатов. Зная эту проблему, компания Micro-
soft выпустила автоматические агрегаты (automatic aggregations) в помощь
пользовательским. При создании этих агрегатов используются методы ма-
шинного обучения, базирующиеся на поведении пользователей. Это может
значительно облегчить процесс управления агрегатами при правильном
подходе.
В настоящее время автоматические агрегаты доступны в Power BI только в емко-
стях Premium и Embedded. Эта возможность находится в стадии предварительного
просмотра и будет дополняться и обновляться, в связи с чем пока не имеет смысла
вдаваться во все подробности ее реализации. За всеми изменениями можно следить
в официальной документации по адресу https://learn.microsoft.com/en-us/power-bi/
enterprise/aggregations-auto.
В завершение главы поговорим об аналитических службах Azure Synapse

и Data Lake. Этими технологиями от Microsoft можно воспользоваться для
внешнего хранения больших данных с доступом в режиме DirectQuery.
Масштабирование с Azure Synapse

и Azure Data Lake
Многие аналитические платформы базируются на концепции симметричной
многопроцессорной обработки (symmetric multi-processing – SMP). Этот под-
ход предполагает наличие одного компьютера с одним экземпляром опе-
рационной системы и несколькими процессорами, совместно работающи-
Масштабирование с Azure Synapse и Azure Data Lake  231
ми с общей памятью, устройствами ввода/вывода и т. д. Это похоже на ваш

обычный компьютер или ноутбук, но с использованием новых серверных
технологий. Альтернативная парадигма, именующаяся массово-параллель-
ной обработкой данных (massively parallel processing – MPP), включает в себя
идею использования кластера, состоящего из множества компьютеров, каж-
дый со своими процессорами, операционной системой и памятью. В такой
структуре каждый компьютер именуется узлом (node).
Что это означает на практике? Представьте, что вам необходимо рассчитать
сумму на основе 100 млрд строк. Применяя методику симметричной много-
процессорной обработки, вы обречете один компьютер выполнять все эти вы-
числения. Концепция массово-параллельной обработки данных позволит вам
логически выделить десять групп по 10 млрд строк в каждой и назначить их
разным физическим компьютерам. В результате все десять вычислений будут
производиться параллельно, а вам останется лишь сложить итоговые значе-
ния. Если вы хотите получить результат еще быстрее, то можете делегировать
вычисления не десяти, а 50 компьютерам – по 2 млрд строк каждому. Даже
с учетом накладных расходов на коммуникацию и синхронизацию данных вы
получите очень серьезный прирост производительности.
В системах для работы с большими данными (big data), таких как Hadoop,
Apache Spark и Azure Synapse, применяется архитектура массово-параллель-
ной обработки данных по причине ее высокого быстродействия. Кроме того,
эта концепция позволяет производить как вертикальное масштабирование,
используя более мощные компьютеры, так и горизонтальное, увеличивая
их численность. Применяя подход с симметричной многопроцессорной об-
работкой, вам будет доступно только вертикальное масштабирование, пока
вы не достигнете предельного насыщения ресурсами вашего единственного
компьютера.
Постоянно увеличивающийся поток данных из современных глобальных
приложений, включая приложения, реализующие концепцию интернета
вещей (Internet of Things – IoT), создает проблемы в области анализа данных.
Обычно приложения бизнес-аналитики используют очищенные данные,
представленные в виде модели, что требует предварительного проведения
их моделирования и преобразования. Это концепция прекрасно работает для
традиционных приложений. Однако при работе с большими данными, по-
ступающими, например, от многочисленных датчиков или веб-приложений
с трекингом, хранить их в обычном формате базы данных в виде строк ста-
новится нерационально из-за их огромных объемов. В связи с этим многие
системы для работы с такими данными прибегают к использованию особым
образом оптимизированных файлов (например, в формате Parquet), в ко-
торых информация хранится в денормализованном виде. В этих системах
применяется альтернативный подход под названием Извлечение–загруз-
ка–преобразование (Extract-Load-Transform – ELT) вместо традиционного
Извлечение–преобразование–загрузка (Extract-Transform-Load – ETL), ис-
пользуемого в Power Query. При применении методологии ELT преобразова-
ние сырых данных выполняется «на лету» в параллельном режиме.
Теперь давайте соотнесем все перечисленные концепции с архитектурой
хранилища данных и предложениями от Azure.
Современная архитектура хранилища данных

Комбинировать концепции ETL, ELT и аналитики больших данных можно
с использованием гибридной архитектуры хранилища данных (hybrid data
warehouse architecture) на основе озера данных. Озеро данных (data lake) мож-
но себе представить как место дислокации сырых данных. К данным в озере
конечные пользователи обычно не имеют прямого доступа.
Данные, помещенные в озеро, могут использоваться по-разному в зависи-
мости от конечной цели. К примеру, специалисту по обработке данных может
понадобиться провести анализ сырых данных и создать на их основании
наборы данных для моделей машинного обучения. С другой стороны, участ-
ники команды бизнес-аналитиков могут с определенной периодичностью
выгружать данные, преобразовывать их по собственным алгоритмам и хра-
нить, к примеру, в базе данных SQL Server. На рис. 12.13 в очень упрощенном
виде показана коллекция компонентов Azure, из которых может состоять
современное хранилище данных.
Модель и обслуживание
PolyBase
Azure Synapse Azure Analysis
Analytics Services
(Synapse SQL)
Подготовка
Загрузка Хранение и обучение
Логи, файлы и медиа
(неструктурированные)
Бизнес/пользовательские Azure Synapse Azure Data Azure Synapse Power BI

приложения Analytics Lake Storage Analytics
(структурированные) (конвейеры) (Apache Spark)
Рис. 12.13  Архитектура современного хранилища данных

(изображение принадлежит Microsoft)
На рис. 12.13 цифрами отмечены следующие типичные действия.

1. Хранение любых типов данных в Azure Data Lake Storage с использова-
нием конвейеров (pipelines) Azure Synapse Analytics.
2. Использование Synapse Analytics для очистки данных.
3. Хранение очищенных структурированных данных в Synapse SQL и обо-
гащение в Azure Analysis Services.
4. Построение отчетности на основе Synapse и Azure Analysis Services
с помощью Power BI.
Представленные выше шаги выполняются по порядку, а на рис. 12.13 показаны лишь
некоторые связи между компонентами. Это сделано в целях обучения, для демон-
страции схемы движения данных в рабочем окружении. В реальных условиях неко-
торые шаги допустимо пропускать или связывать компоненты иначе – в зависимости
от сценария и навыков пользователя. К примеру, инженер данных вполне может под-
Масштабирование с Azure Synapse и Azure Data Lake  233
ключиться из Power BI напрямую к Azure Data Lake Storage для исследования форма-
та и качества данных. Также есть и другие компоненты Azure, дополняющие эту схему,
которые не были здесь показаны.
Теперь давайте внимательнее присмотримся к технологиям, позволяю-

щим выполнять масштабирование.
Azure Data Lake Storage

Azure Data Lake Storage (ADLS) представляет собой современное хранилище,
предназначенное для больших данных. Оно не предполагает ограничений на
хранение данных и совместимо с такими незапатентованными технология
ми, как Hadoop Distributed File System (HDFS), что является обязательным
требованием для многих систем на основе Hadoop. Обратите внимание, что
текущую версию ADLS в Microsoft именуют ADLS Gen2, подчеркивая тем са-
мым, что речь идет об использовании технологии второго поколения. И хотя
изначальная версия озера данных по-прежнему доступна, мы рекомендуем
работать именно с Gen2, поскольку это поколение предлагает лучшую про-
изводительность и функциональность. Кроме того, такие платформы, как
Synapse, будут работать только со вторым поколением хранилища. Службы
Synapse оптимизированы для работы с данными в параллельном режиме
с использованием ADLS.
Azure Synapse Analytics

Azure Synapse – это аналитическая платформа, содержащая различные служ-
бы, предназначенные для аналитики данных. Ранее эта платформа имено-
валась SQL Server Data Warehouse, и тогда основной упор делался на пре-
доставлении распределенной версии SQL Server для работы с огромными
объемами данных, исчисляющимися терабайтами. С тех пор был произведен
ребрендинг, а платформа стала включать в себя следующие компоненты
и возможности:
Synapse Studio: веб-окружение, способное обслуживать большое ко-
личество пользователей. С помощью этой службы пользователи могут
загружать, преобразовывать и визуализировать данные;
интеграция с Power BI: вы можете связывать рабочие области Po
wer BI с вашей рабочей областью Synapse в Synapse Studio. После этого
можно анализировать данные из служб Synapse с помощью Power BI
внутри Synapse Studio;
интеграция с ноутбуками: Synapse Studio поддерживает ноутбуки
Python в отношении интерактивного анализа и документации данных;
бессерверный и выделенный пулы SQL: эти службы предоставля-
ют доступ к структурированному хранилищу SQL Server в облаке. Бес-
серверному пулу (serverless pool) требуется незначительная настройка
и управление – вам нет необходимости предоставлять сервер, службу
автомасштабирования, и вы платите за каждый запрос. Выделенный пул

(dedicated pool) должен быть заранее полностью настроен, и при его
использовании вы платите на постоянной основе с течением време-
ни. Выделенные пулы могут быть приостановлены и масштабированы
при необходимости в сторону расширения или сужения. Эти опции
позволяют достичь нужного баланса между затратами и накладными
расходами на управление;
бессерверный и выделенный пулы Spark: Apache Spark представля-
ет собой очень популярную платформу с открытым исходным кодом
для работы с большими данными. Эта технология предлагает интер-
фейс SQL для работы с данными и встроенные возможности для ин-
теллектуальной обработки информации. Synapse полностью интегри-
рован с пулами Spark, что позволяет аналитикам использовать Spark
Jobs напрямую из Synapse Studio;
потоки данных: представляют собой визуальную логику преобразо-
вания данных для очистки и манипуляции информацией с помощью
пулов обработки;
конвейеры данных: позволяют пользователям оркестрировать и мо-
ниторить операции преобразования данных.
Современная архитектура хранилища данных включает огромное коли
чество опций и вариаций. К сожалению, ближайшее ее рассмотрение выхо-
дит за рамки этой книги. Microsoft предлагает несколько базовых архитектур
для решения аналитических задач, начиная от хранилища бизнес-данных
и заканчивая прогнозной аналитикой на основе потоковых данных прак-
тически в реальном времени. Мы рекомендуем вам посетить сайт, посвя-
щенный Microsoft Azure Architecture, чтобы узнать, какие службы Azure вы
можете использовать для решения своих аналитических задач: https://learn.
microsoft.com/ru-ru/azure/architecture/browse/?azure_categories=analytics.
Теперь, когда вы познакомились с основами технологий Azure и способами
их использования для масштабирования данных, пришло время подвести
итоги этой главы.
В этой главе мы узнали, как справляться с действительно огромными объ-
емами данных. Сперва мы рассмотрели случаи, когда ваш набор данных
в Power BI превышает 1 Гб, допустимый при использовании общей емкости,
и порекомендовали переход на емкости Power BI Premium, ограничение в ко-
торых установлено на отметке 10 Гб. Мы также отметили, что с использова-
нием формата хранения крупных наборов данных объем ваших датасетов
может легко превышать и эти лимиты. Чисто технически вы можете задей-
ствовать всю доступную для вашей емкости память, а для плана Premium
P5 она составляет 400 Гб. Кроме того, емкости Premium предлагают расши-
ренные возможности по использованию параллелизма, что положительно
сказывается на производительности обновлений и запросов.
После этого мы обратились к примерам, в которых проблемы масштаби-

рования тесно связаны с большим количеством одновременно работающих
пользователей, и узнали, почему это может оказывать дополнительную на-
грузку на память и центральный процессор. В качестве решения мы предло-
жили использовать технологию горизонтального масштабирования запросов
(QSO), реализованную в AAS. Мы также рекомендовали применять секциони-
рование в Premium и AAS для ускорения процесса обновления больших таб
лиц. Попутно рассмотрели существующие различия между Premium и AAS.
Далее мы поговорили о повышении производительности DirectQuery при
помощи составных моделей данных, позволяющих комбинировать разные
режимы хранения в одном наборе данных Power BI. Мы увидели, что в Po
wer BI можно устанавливать режимы хранения на уровне таблиц, задавая для
них отдельно режимы Импорт, DirectQuery или Двойной. Последний режим
позволяет импортировать данные и хранить их в памяти, одновременно
используя режим DirectQuery при необходимости. Мы узнали, когда нужно
применять каждый из этих режимов хранения и как Analysis Services будет
выбирать лучший вариант в зависимости от конкретного сценария.
После этого мы перешли к разговору о применении в своих решениях
агрегатов как дополнения к составным моделям. В основе создания агрегатов
лежит идея о том, что в процессе анализа мы часто пользуемся агрегирован-
ными данными из таблиц фактов. Но даже в очень хорошо оптимизирован-
ных источниках данных DirectQuery агрегация значений на основании десят-
ков миллионов или миллиардов строк будет занимать значительное время.
И проблема может усугубиться при наличии большого количества парал-
лельных обращений. Наличие агрегатных таблиц в Power BI позволяет вам
определять сгруппированные поднаборы данных на основе таблиц фактов,
данные из которых Analysis Services может использовать вместо обращения
к медленным источникам DirectQuery. Вы можете добиться огромного при-
роста производительности, размещая агрегатные таблицы в режиме Import.
В заключение мы рассмотрели прочие технологии от Microsoft, позволяю-
щие справиться с проблемой хранения и анализа больших данных. Мы узна-
ли, что с практической точки зрения может быть нецелесообразно загружать
и преобразовывать определенные типы данных по причине их больших объ-
емов и низкой скорости. Таким образом, системы обработки больших данных
в основном используют принципы массово-параллельной обработки данных
(MPP) и полагаются на методологию ELT в сравнении с традиционной ETL,
предполагающую преобразование данных «на лету» при необходимости.
В современных хранилищах все сырые данные предварительно переносят-
ся в централизованное озеро данных, в котором реализованы различные
технологии доступа к информации с применением методик ETL или ELT
в зависимости от нужд решения. Мы рассмотрели Azure Data Lake Storage
и Azure Synapse Analytics в качестве технологий, на основе которых вы мо-
жете строить свои хранилища данных.
В следующей главе мы подробно поговорим об оптимизации емкостей Po
wer BI Premium и Embedded. Применительно к ним Microsoft предоставляет
богатые возможности по настройке, нацеленные на повышение произво-
дительности.
Материалы для чтения

Заметьте, что в Synapse, как и в Power BI, предусмотрено большое количест
во опций и настроек, связанных с производительностью. Ниже приведены
материалы для самостоятельного изучения этих настроек (все инструкции
переведены на русский):
рекомендации по использованию бессерверного пула SQL в Azure Syn-
apse Analytics: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/
sql/best-practices-serverless-sql-pool;
рекомендации по использованию выделенных пулов SQL в Azure Syn-
apse Analytics: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/
sql/best-practices-dedicated-sql-pool;
рекомендации Помощника по Azure для выделенного пула SQL в Azure
Synapse Analytics: https://learn.microsoft.com/ru-ru/azure/synapse-analyt-
ics/sql-data-warehouse/sql-data-warehouse-concept-recommendations;
оптимизация производительности с помощью материализованных
представлений на основе выделенного пула SQL в Azure Synapse Ana-
lytics: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/sql/devel-
op-materialized-view-performance-tuning;
настройка производительности с помощью упорядоченного кластери-
зованного индекса columnstore: https://learn.microsoft.com/ru-ru/azure/
synapse-analytics/sql-data-warehouse/performance-tuning-ordered-cci;
настройка производительности путем кеширования результирующего
набора: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/sql-data-
warehouse/performance-tuning-result-set-caching;
оптимизация производительности запросов к хранилищу данных
в Azure Synapse Analytics: https://learn.microsoft.com/ru-ru/training/mod-
ules/optimize-data-warehouse-query-performance-azure-synapse-analytics;
руководство по настройке производительности потоков дан-
ных в Synapse: https://learn.microsoft.com/ru-ru/azure/data-facto-
ry/concepts-data-flow-performance?context=%2Fazure%2Fsynapse-
analytics%2Fcontext%2Fcontext.
Часть V
Оптимизация емкостей
Premium и Embedded
В этой части книги мы познакомимся с настройками и ограничениями в от-

ношении ресурсов емкости Power BI Premium и рассмотрим варианты рас-
становки приоритетов в плане рабочей нагрузки и управления памятью при
использовании емкостей Power BI Premium/Embedded. Также мы научимся
эффективно встраивать объекты Power BI в приложения и измерять сопут-
ствующую нагрузку.
глава 13 «Оптимизация емкостей Premium и Embedded»;
глава 14 «Встраивание в приложения».
Глава 13
Оптимизация емкостей
Premium и Embedded
В предыдущей главе мы рассматривали различные варианты масштабиро-

вания данных и пользователей. И первым делом мы посоветовали переход
на емкости Power BI Premium, предлагающие более щадящие ограничения на
размер наборов данных по сравнению с общими емкостями.
В этой главе мы обратим более пристальный взгляд на емкости Premium
(P и EM) и Embedded (A). Несмотря на то что эти емкости приобретаются
и оплачиваются отдельно, за небольшими исключениями, они предостав-
ляют одинаковые наборы услуг и оптимизируются очень похоже. Таким об-
разом, в этой главе мы будем говорить по большей части о емкости Premium,
а емкость Embedded будем упоминать лишь тогда, когда для нее будут при-
менимы иные способы оптимизации. С моделью лицензирования Power BI
Premium на пользователя (Premium Per User – PPU) мы поступим точно так же.
В процессе чтения главы вы узнаете, что емкость Premium отличается не
только увеличенными лимитами на размер датасета. Помимо этого послаб
ления, емкость Premium также предлагает дополнительные богатые возмож-
ности в сравнении с общими емкостями. Но здесь стоит отметить, что все эти
улучшения связаны с дополнительной ответственностью, которая ложится
на плечи администратора емкости. В связи с этим мы подробно обсудим все
новые опции и настройки, такие как автомасштабирование, и поговорим
о том, как они могут сказаться на производительности.
После этого мы узнаем о том, как можно объективно определить размер
емкости и спланировать его рост на будущее. Одной из важнейших техник
в этой области является проведение нагрузочных тестов для определения
лимитов и узких мест вашего решения на основе данных. Также мы познако-
мимся с приложением Premium Capacity Metrics App от Microsoft, с помощью
которого можно отслеживать текущее состояние емкости и вносить важные
корректировки.
В октябре 2021 года компания Microsoft выпустила в общий доступ Premi-
um Gen2 (второе поколение Premium). В этом релизе были улучшены многие
аспекты емкости Premium, и мы в этой главе рассмотрим некоторые из этих
улучшений, включая возможность автоматического масштабирования ем-
кости с помощью дополнительных ядер процессора, имеющихся в резерве.
Хотя первое поколение Premium все еще используется некоторыми организа-
Возможности Premium, использование ресурсов и автомасштабирование  239
циями, в Microsoft объявили о предстоящей миграции клиентов на Premium

Gen2. В связи с этим мы не будем подробно останавливаться в этой главе на
первом поколении Premium.
возможности Premium, использование ресурсов и автомасштабиро
вание;
планирование емкости, мониторинг и оптимизация.
Возможности Premium, использование

ресурсов и автомасштабирование
Лицензия Power BI Premium предоставляет организации право на использо-
вание собственной выделенной емкости, что позволяет избавиться от проб
лем с «шумными соседями», присущих общей емкости. Давайте для начала
перечислим возможности емкости Premium, создающие предпосылки для
повышения производительности и масштабируемости решения:
возможность автомасштабирования: эта новая возможность появи-
лась в Gen2 и позволила администраторам выделять ядра централь-
ного процессора для использования в периоды повышенной нагрузки
(недоступно в виде лицензирования Premium на пользователя);
повышенные лимиты на хранилище и размер наборов данных:
100 Тб для общего хранилища и 400 Гб для набора данных (100 Гб в ли-
цензии Premium на пользователя);
повышенная частота обновлений набора данных: 48 раз в день из
интерфейса пользователя с возможностью повышения частоты при
использовании конечных точек XMLA;
повышенный параллелизм при обновлениях: вы можете проводить
больше операций обновления одновременно – от пяти (Embedded A1)
до 640 (Premium P5/Embedded A8);
улучшения при работе с потоками данных: потоки данных, соз-
данные в емкости Premium, могут воспользоваться преимуществами
расширенного ядра вычислений (Enhanced Compute Engine);
нагрузка по требованию с использованием формата хранения
крупных наборов данных: емкости Premium не хранят в памяти все
наборы данных. Вместо этого датасеты, не используемые на протя-
жении определенного времени, выгружаются с целью освобождения
места в памяти. Как мы уже говорили в главе 10, в емкости Premium
может быть увеличена скорость начальной загрузки в память за счет
использования формата хранения крупных наборов данных. Такой
способ загрузки по требованию может ускорить общий процесс по-
средством загрузки только тех страниц данных, которые требуются
для удовлетворения нужд запроса. В противном случае пришлось бы
держать весь набор данных в памяти, на что потребовалось бы немало
времени. Тем самым вы можете сэкономить порядка 35 % времени за-
240  Оптимизация емкостей Premium и Embedded
грузки отчета для датасетов объемом более 5 Гб. И чем больше данных,
тем больше будет прирост.
Далее перечислим некоторые возможности Premium, не относящиеся на-
прямую к производительности. Заметим, что последние три пункта недо-
ступны для варианта лицензирования Premium на пользователя (Premium
Per User – PPU):
возможность создавать отчеты с разбивкой на страницы: речь
о строго форматированных отчетах на базе SQL Server Reporting Ser-
vices, оптимизированных для печати;
конечные точки XMLA: доступ к API для автоматизации и пользова-
тельской настройки развертывания/обновления;
приложение Life Cycle Management (ALM): использование конвейе
ров развертывания, управление разработкой и оценка версий в виде
приложения;
улучшенные возможности применения искусственного интеллек-
та: анализ текста и изображений, а также автоматизированные методы
машинного обучения;
межрегиональное развертывание: вы можете развертывать емкости
Premium в разных регионах с целью удовлетворения требований в от-
ношении суверенности данных (data sovereignty);
применение модели Bring Your Own Key (BYOK): вы можете исполь-
зовать собственный ключ шифрования для обеспечения безопасности
данных.
Теперь давайте посмотрим, как емкости Premium используют ресурсы
и что происходит при увеличении требований и нагрузок.
Поведение емкостей Premium и использование

ресурсов
При покупке организацией емкости Premium ей выделяются виртуальные
ядра (virtual cores – v-cores) и определенный объем памяти, и все рабочие
нагрузки ложатся на эти выделенные ресурсы. К примеру, отчет с разбивкой
на страницы может посылать запросы и выполнять обработку данных одно-
временно с обновлением датасета.
В первой версии Premium клиенты должны были строго следить за выде-
ленной памятью и количеством одновременных обновлений. Им нужно было
четко понимать, как именно расставляются приоритеты между операциями
разных типов, а именно:
интерактивные операции (быстрое выполнение):
– нагрузка на датасет: запросы, отчеты и операции чтения XMLA;
– нагрузка на поток данных: все операции;
– нагрузка на постраничные отчеты: отрисовка отчетов;
фоновые операции (более долгое выполнение):
– нагрузка на датасет: запланированные обновления, обновления по
требованию и фоновые запросы после обновления;
– нагрузка на поток данных: запланированные обновления;

– нагрузка на постраничные отчеты: подписки на основе данных;
– нагрузка на AI: вычисление функций;
– вызовы API для экспорта отчетов в файл.
Все это относится и к Premium Gen2. В то же время в Microsoft изменили
способы применения ограничений во втором поколении емкости, и далее
мы поговорим об этом.
В исходной версии Premium весь объем памяти, выделенный для емкости, делил-
ся между всеми рабочими нагрузками и не мог быть превышен. К примеру, в плане
P1 все параллельные процессы в емкости не могли использовать суммарно больше
25 Гб памяти.
При переходе на Gen2 модель использования ресурсов была изменена таким образом,
чтобы тяжелые фоновые операции не мешали пользователям, отнимая все имеющие-
ся ресурсы. Теперь ограничение на память для емкости применяется с учетом набора
данных, а не ко всем нагрузкам разом. Это означает, что с планом P1 у вас может быть
несколько активных датасетов, потребляющих до 25 Гб памяти. Обратите внимание,
что доступные ядра процессора по-прежнему могут являться сдерживающим факто-
ром из-за недоступности ограниченных потоков, а это означает, что они не могут быть
назначены для обновления контейнеров обработки. Здесь на помощь может прийти
механизм автомасштабирования, о котором мы будем говорить далее в этой главе.
С введением Gen2 компании Microsoft удалось добиться улучшений в обла-

сти масштабирования и параллелизма за счет выдачи клиентам больших ре-
сурсов по сравнению с тем, что они приобретают. Например, емкость в плане
P1 может быть запущена на физическом компьютере с ресурсами P3. Micro-
soft запускает группы таких мощных узлов, выделенные для особых нагрузок
Premium. Это позволяет максимально равномерно распределить нагрузку
между процессами. В официальной документации Microsoft указывает, что
нагрузка выполняется на узле с достаточным объемом памяти.
Давайте посмотрим, какие настройки, относящиеся к производительно-
сти и масштабированию, мы можем менять. На рис. 13.1 показан раздел
Параметры емкости (Capacity Settings) на Портале администрирования
Power BI (Power BI Admin Portal) для емкости Gen2. В секции Workloads как
раз содержатся настройки, влияющие на производительность.
Ниже мы подробно расскажем обо всех важных настройках, оказываю-
щих влияние на масштабирование и производительность. Здесь вы можете
установить свои ограничения, чтобы обезопасить себя от проблем с набором
данных или отчетов, генерирующих сложные ресурсоемкие запросы:
Предельный объем памяти для запросов (%) (Query Memory Limit
(%)): максимальный процент памяти, который может быть задейство-
ван при выполнении запроса. Значение по умолчанию – 0, что соот-
ветствует базовому ограничению текущей емкости;
Время ожидания запроса (в секундах) (Query Timeout (seconds)):
количество секунд, на протяжении которых может выполняться за-
прос, перед тем как возникнет превышение лимита времени. Значение
по умолчанию соответствует одному часу, а для отключения лимита
введите в поле 0;
Рис. 13.1  Настройки емкости Premium,

влияющие на производительность
Максимальное число промежуточных наборов строк (Max Inter-

mediate Row Count): в случае с подключением в режиме DirectQuery
ограничивает количество строк, возвращаемых запросом. Это может
помочь снизить нагрузку на источники;
Максимальное число наборов результирующих строк (Max Result
Row Count): максимальное количество строк, которое может быть воз-
вращено запросом DAX;
Максимальный размер автономного набора данных (Гб) (Max Of-
fline Dataset Size (GB)): определяет максимальный размер набора дан-
ных, хранящегося на диске;
Минимальный интервал обновления (Minimum refresh interval) (для
опции Automatic Page Refresh с фиксированным интервалом): опреде-
ляет, как часто отчет с автоматическим обновлением страницы может

посылать запросы на извлечение новых данных. Помогает удержать раз-
работчиков от установки более частых обновлений, чем это необходимо;
Минимальный интервал выполнения (Minimum execution interval)
(для опции Automatic Page Refresh с отслеживанием изменений):
подобно предыдущей настройке, но применяется к частоте проверки
меры отслеживания изменений.
Теперь давайте узнаем, как емкости оценивают нагрузку и что происходит,
когда емкость оказывается перегружена.
Как оценивается нагрузка на емкость?

Емкости Premium Gen2 производят оценку нагрузки каждые 30 секунд, при
этом каждый интервал называется циклом вычисления (evaluation cycle). Мы
рассмотрим на практических примерах процесс вычисления нагрузки на
каждом цикле и поведение емкости в момент достижения ее лимита.
В Power BI использование емкости оценивается при помощи показателя,
называющегося процессорным временем (CPU time), который обычно исчис-
ляется процессорными секундами (CPU seconds). Одна процессорная секунда
эквивалентна занятости одного ядра процессора на полную мощность в те-
чение одной секунды. При этом общая длительность операции от начала до
конца может быть иной. Другими словами, если мы знаем, что длительность
операции составляет одну процессорную секунду, это не обязательно означа-
ет, что от начала до конца она заняла ровно секунду. Это просто говорит о том,
что одно ядро процессора работало на полную мощность на протяжении од-
ной секунды, или о том, что в процессе выполнения операции центральный
процессор был нагружен менее чем на 100 % в течение более одной секунды.
Мы в наших примерах будем использовать емкость с планом P1. Эта ем-
кость ограничена четырьмя серверными ядрами (backend cores) и четырьмя
интерфейсными (frontend cores). Серверные ядра используются для ключе-
вых функций Power BI, таких как обработка запросов и обновление набо-
ров данных, тогда как интерфейсные ответственны за комфортную работу
пользователя, включая обслуживание веб-службы, управление содержимым
страницы, правами доступа и расписаниями. Нагрузка на емкость измеря-
ется только применительно к серверным ядрам.
Зная о том, что Power BI производит оценку нагрузки каждые 30 секунд, мы
можем рассчитать максимальное процессорное время, доступное нам во вре-
мя цикла вычисления в плане P1. 30 секунд умножаем на четыре ядра и полу-
чаем 120 процессорных секунд. Таким образом, для емкости P1 система будет
каждые полминуты определять, превышает ли нагрузка 120 процессорных
секунд. Напомним, что в Gen2 емкость P1 может временно испытывать на-
грузку более 120 процессорных секунд из-за наличия резервных мощностей.
Что при этом происходит с интенсивностью нагрузки центрального процес-
сора, зависит от конфигурации емкости.
Перед более глубоким погружением в материал стоит заметить, как счи-
тается нагрузка на центральный процессор, ведь интерактивные и фоновые
операции воспринимаются системой по-разному. Интерактивные операции

учитываются в рамках циклов вычисления, в которых они запускаются. В то же
время нагрузка процессора по причине фоновой активности рассчитывается
как скользящее значение за 24 часа на основании тех же 30-секундных интерва-
лов. Просто показатели сглаживаются и ровно распределяются по всем циклам
вычисления. Всего в сутках, как несложно посчитать, 2880 циклов вычисления.
Давайте проиллюстрируем все сказанное на простом, но реалистичном
примере. Предположим, у нас есть свежая емкость с планом P1. Мы заплани-
ровали две операции обновления (назовем их A и B), которые должны завер-
шиться к часу и к четырем часам ночи соответственно. Предположим, первое
обновление займет 14 400 процессорных секунд (по пять на каждый цикл
вычисления), а второе – 5760 секунд (по две на цикл). Пользователи начина-
ют формировать отчеты, размещенные в емкости, около 9 утра, не нагружая
емкость до пороговых значений. На рис. 13.2 показано, как будет распреде-
ляться нагрузка в этом сценарии и как будут меняться со временем доступные
ресурсы. Мы отметили на рисунке четыре разных цикла вычисления, чтобы
было понятно, как различные операции вносят свой вклад в оценку нагрузки.
Сценарий, который мы описали, занимает меньше 24 часов времени.
Порог емкости = 120 процессорных секунд

120
Доступная
Процессорные секунды
емкость
(не в масштабе)
Пользовательский запрос
7
Обновление B = 2 процессорные секунды на цикл вычисления
5
Обновление A = 5 процессорных секунд на цикл вычисления
0
1:00 4:00 9:00
А B C D
Время (не в масштабе)
Рис. 13.2  Оценка нагрузки на емкость P1

в разные временные промежутки (от A до D)
Поскольку нагрузка от фонового обновления равномерно распределяется по 2880 цик

лам вычисления, на рис. 13.2 и 13.5 корректно будет отобразить ее в виде константы
после завершения операции. Что касается пользовательских запросов, нагрузка от
них будет переменной для каждой операции. Однако для простоты картины мы ре-
шили отображать эти нагрузки как постоянные.
Давайте пройдемся по всем четырем циклам вычисления и посмотрим,

как рассчитывается нагрузка на каждом из временных отрезков.
1. Цикл вычисления A: в этот момент времени емкость еще не была
использована. И никаких предшествующих фоновых активностей для
учета нагрузки пока не было.
2. Цикл вычисления B: здесь обновление A уже завершилось, а обновле-

ние B еще не начиналось. Фоновая нагрузка для обновления A состав-
ляет 14 440 процессорных секунд, разбитых на 30-секундные интерва-
лы (по пять процессорных секунд на один цикл). Поскольку никаких
других активностей в этот момент не происходит, суммарная нагрузка
составляет 5 процессорных секунд.
3. Цикл вычисления C: в этот момент уже завершилось обновление B.
Фоновая нагрузка для этого обновления составляет 5760 процессорных
секунд, распределенных по две секунды на цикл вычисления. Одна-
ко здесь учитываются нагрузки уже от обоих обновлений, поскольку
они происходили в один 24-часовой интервал. Несмотря на то что обе
операции обновления к этому моменту уже завершились, скользящая
нагрузка от них продолжает учитываться, так что общая нагрузка будет
составлять 7 процессорных секунд.
4. Цикл вычисления D: здесь у нас одновременно активны и фоновые
процессы, и интерактивные пользовательские запросы. Общая нагруз-
ка в этом случае складывается из нагрузки от фоновых обновлений
(7 процессорных секунд) и нагрузки от запросов. Конкретная оценка
в нашем примере не так важна. Более важно то, что в этом цикле вы-
числения нагрузка не превышает 120 процессорных секунд.
Теперь посмотрим, что происходит, когда достигается перегрузка, т. е. пре-
вышается предельная нагрузка для емкости. Этот термин используется для
описания ситуации, когда емкости требуются дополнительные ресурсы, по-
мимо выделенных по умолчанию.
Перегрузка емкости и автомасштабирование

Для емкости P1 перегрузка (overload) означает, что общая нагрузка (включая
сглаженную фоновую активность) превышает 120 процессорных секунд во
время цикла вычисления. При достижении этого лимита (если опция ав-
томасштабирования выключена) система переходит в режим ограничения
количества запросов (throttling), также называемый режимом отсрочки ин-
терактивных запросов (interactive request delay). При этом система будет
находиться в этом режиме, пока на каждом очередном цикле вычисления
будет сохраняться превышение доступной емкости. В режиме отсрочки (delay
mode) система будет искусственно задерживать отправку интерактивных
запросов. Длительность отсрочки – величина динамическая и зависит от
нагрузки на емкость.
Режим отсрочки впервые появился в Gen2. До этого емкость можно было
перегружать до тех пор, пока она не перестанет отвечать на запросы. С по-
явлением Gen2 поведение емкости изменилось во избежание таких экс-
цессов. На первый взгляд может показаться, что переход в режим отсрочки
может быть еще более губительным для системы, но на самом деле это не так.
Пользователь, работающий в таком режиме, заметит задержку при обработ-
ке интерактивных запросов по сравнению с ненагруженной системой. Зато
вероятность успешного завершения запросов в таком случае существенно
повышается. Причина в том, что режим отсрочки дает емкости возможность

завершить все активные процессы, не нагружая ее излишне запросами, ко-
торые в результате могут привести к отказу.
На рис. 13.3 показано, как работает режим отсрочки. Обратите внимание,
что в цикле A нам понадобилось больше ресурсов, чем было выделено, – это
видно по интерактивным запросам, расположенным выше порогового уров-
ня в 120 процессорных секунд. В связи с этим в цикле B все новые запросы
будут временно поставлены на паузу, что позволит сохранить работоспособ-
ность системы и ощущение относительного комфорта для пользователя.
Перегрузка
Интерактив
120
Процессорные Интерактив ОТСРОЧКА Интерактив
секунды Интерактив
Фоновые операции
0
А B
Рис. 13.3  Интерактивные операции в цикле B

получили отсрочку из-за перегрузки в цикле A
Если вы часто сталкиваетесь с перегрузкой емкости, первым делом вам

стоит рассмотреть вариант масштабирования с помощью расширенного пла-
на. Но расширенные планы стоят денег, и эти расходы может быть трудно
оправдать, если перегрузка появляется лишь временами – спорадически
и непредсказуемо. Вы также можете провести горизонтальное масштабиро-
вание, распределив рабочие области по нескольким емкостям, чтобы одна
из емкостей не испытывала непропорционально высокие нагрузки. Если
же в вашем распоряжении имеется только одна емкость, распределение на-
грузки вам не поможет.
Подробнее о перегрузке мы поговорим при обсуждении мониторинга
и оптимизации в следующем разделе. А сейчас рассмотрим альтернативный
способ смягчения пиковых нагрузок.
Управление пиковыми нагрузками при помощи

автомасштабирования
Эффективным способом управления излишними нагрузками в емкостях Pre-
mium без дополнительных расходов является использование опции автомас-
штабирования (Autoscale), появившейся в Gen2.
Автомасштабирование в том виде, как оно реализовано в Premium, недоступно в ем-

костях Power BI Embedded (A SKU). В данном случае вам необходимо использовать
комбинацию метрик, а также API или PowerShell для ручного контроля за показателями
и запуска команд для выполнения масштабирования. Больше информации по этому
способу можно почерпнуть по адресу https://learn.microsoft.com/en-us/power-bi/devel-
oper/embedded/power-bi-embedded-generation-2#autoscaling-in-embedded-gen2.
Автомасштабирование в Premium осуществляется путем связывания

подписки Azure с емкостью Premium с разрешением использовать дополни-
тельные виртуальные ядра (v-cores) при возникновении перегрузки. Power BI
будет выделять по одному виртуальному ядру за раз до достижения максиму-
ма, определенного администратором. Виртуальные ядра выделяются сроком
на 24 часа и тарифицируются только при выделении на эти сутки в состоянии
перегрузки. На рис. 13.4 показана панель настройки автомасштабирования,
находящаяся в разделе Параметры емкости (Capacity Settings) на портале
администрирования Power BI.
Рис. 13.4  Настройки автомасштабирования

для связывания подписки Azure и выделения виртуальных ядер
На рис. 13.5 видно, как изменится сценарий, который мы рассматривали

на рис. 13.3, при включении опции автомасштабирования. Как видите, новое
виртуальное ядро было выделено на следующем после возникновения пере-
грузки цикле вычисления, и одновременно с этим увеличилось пороговое
значение емкости. Важно также отметить, что интерактивная операция, за-
пущенная после обнаружения перегрузки, не была отложена.
+1 ядро Новый порог емкости

Перегрузка
Интерактив Интерактив
120
Процессорные
секунды Интерактив
Фоновые операции
А B
Рис. 13.5  Выделение дополнительного виртуального ядра

при настройке автомасштабирования
Теперь, когда мы узнали, что емкости могут оценивать нагрузку и при

необходимости быть масштабированы, поговорим о планировании размера
емкости и эффективном ее использовании.
Планирование емкости, мониторинг

и оптимизация
Самый частый вопрос, который задают компании перед покупкой емко-
сти Premium или Embedded, касается объема доступных ресурсов. В рамках
подписки Premium предоставляется много разных услуг, и разумно пред-
положить, что рабочая нагрузка и ее распределение будут варьироваться от
организации к организации. Это серьезно затрудняет процесс предваритель-
ной оценки требуемых ресурсов для емкости по простым метрикам вроде
количества пользователей. Кроме того, использование емкости со временем
расширяется, так что даже если вы правильно оценили исходный размер
емкости, вам, скорее всего, в какой-то момент придется задуматься о мас-
штабировании. В следующих двух разделах мы как раз поговорим об опреде-
лении начального объема ресурсов для емкости и дальнейшем мониторинге
с целью масштабирования в будущем.
Планирование емкости, мониторинг и оптимизация  249
Определение исходного размера емкости

Ранее в этой главе мы упоминали, что емкости Power BI доступны в раз-
личных размерах в зависимости от модели лицензирования (licensing model).
Вам необходимо выбрать подходящую единицу хранения (Stock-Keeping Unit –
SKU) на основании требований вашей организации. На ваш выбор может вли-
ять также необходимость использовать ту или иную возможность, поскольку
далеко не каждая возможность присутствует во всех SKU плана A из Azure и P
из EM, доступных в Office. Например, отчеты с разбивкой на страницы недо-
ступны в емкостях A1-A3 и EM1-EM3, а службы искусственного интеллекта
не присутствуют в планах EM1 и A1.
Очень полезно иметь перед глазами полные характеристики планов. На
момент написания книги действуют ограничения, показанные в табл. 13.1.
Таблица 13.1. Доступные SKU и их ограничения на емкость

SKU Общее Серверные Интер Память Подключения Макс. Параллелизм
кол-во ядра фейсные (Гб) DirectQuery/ память на обновлений
вирт. ядер ядра Live в секунду запрос (Гб)
EM1/A1 1 0,5 0,5 3 3,75 1 5
EM2/A2 2 1 1 5 7,5 2 10
EM3/A3 4 2 2 10 15 2 20
P1/A4 8 4 4 25 30 6 40
P2/A5 16 8 8 50 60 6 80
P3/A6 32 16 16 100 120 10 160
P4/A7 64 32 32 200 240 10 320
P5/A8 128 64 64 400 480 10 640
Теперь давайте подумаем, какие факторы необходимо учитывать при при-

нятии решения о размере емкости. В следующем разделе мы еще раз прой-
демся по этим факторам в контексте проведения нагрузочных тестов:
объем отдельных наборов данных: принимайте во внимание са-
мые большие и сложные датасеты, которые будут использоваться чаще
всего. Вы можете прототипировать наборы данных в Power BI Desk-
top и использовать DAX Studio и VertiPaq Analyzer для оценки степени
сжатия данных для прогнозирования размеров итоговых датасетов.
Убедитесь, что выбранный вами план способен комфортно вместить
самый крупный ваш набор данных;
количество и сложность запросов: подумайте о том, какое количест
во пользователей может просматривать различные отчеты одновре-
менно. При этом необходимо учитывать как централизованные отче-
ты организации, так и собственные отчеты пользователей. Вы можете
оценить этот процент по тому, насколько охотно в вашей компании
поддерживают создание пользователями собственного контента. При
анализе количества и сложности запросов можно воспользоваться ин-
струментами Desktop Performance Analyzer и DAX Studio;
количество и сложность обновлений данных: оцените предельное

количество наборов данных, которые может потребоваться обновлять
одновременно на различных стадиях рабочего процесса. Выберите
емкость с подходящим показателем параллелизма. Также стоит пом-
нить, что в общий объем набора данных входит не только память, за-
нимаемая таблицами и прочими структурами данных, но и память,
требующаяся для выполнения запросов и фоновых обновлений. И если
этот общий объем превышает ограничение приобретаемой емкости,
обновления будут завершаться ошибками;
нагрузка от других служб: учитывайте, что потоки данных, службы
искусственного интеллекта, постраничные отчеты и другие возможно-
сти, которые вы захотите использовать в будущем, требуют определен-
ных ресурсов. Если вы планируете расширяться в эту область, заранее
спланируйте это при выборе емкости;
периодическое распределение нагрузки: нагрузка на емкость будет
меняться в течение суток в зависимости от рабочих часов компании.
Также у каждой компании есть собственные «горячие» часы, когда
объем работы возрастает. Это может быть закрытие месяца или такие
акции, как «черная пятница». Вы должны закладывать в план перспек-
тиву подобных всплесков активности. Если эти всплески предполагают
использование гораздо большего количества ресурсов по сравнению
с обычными днями, можно выбрать подход с автомасштабированием
вместо использования емкости большего объема.
Потратив немного времени и воспользовавшись этим перечнем, можно
дать вполне объективную оценку в отношении требуемых ресурсов емкости.
Но свои догадки нужно еще и проверить – для этого используются нагру-
зочные тесты, позволяющие оценить поведение емкости и ее способность
к масштабированию. Давайте этим и займемся.
Проверка емкости с помощью нагрузочного

тестирования
После выбора размера емкости необходимо проверить, отвечает ли сделан-
ный выбор вашим требованиям в различных ситуациях. Компания Microsoft
предлагает два набора скриптов PowerShell для помощи в имитации рабо-
чих нагрузок с учетом разных сценариев. Эти инструменты используют все
преимущества REST API, доступного только в лицензии Premium. Вы можете
настроить инструменты на запуск отчетов в емкости в разных условиях.
При этом нужно пытаться максимально приблизиться к реалистичным об-
стоятельствам в отношении использования наборов данных – только в та-
ких условиях инструменты тестирования смогут сгенерировать адекватные
и объективные выходные данные. Эта активность может быть перехвачена
и отображена в инструменте Capacity Metrics App, о котором мы поговорим
далее. Мы будем использовать его с целью отслеживания использования
ресурсов, возникновения перегрузки и выполнения автомасштабирования.
Для начала давайте рассмотрим внимательнее эти инструменты от Mi-

crosoft. Оба они доступны в соответствующих папках в одном репозитории
GitHub по адресу https://github.com/microsoft/PowerBI-Tools-For-Capacities. Что
же они из себя представляют?
LoadTestingPowerShellTool: это очень простой инструмент. Он ими-
тирует большое количество пользователей, открывающих один и тот
же отчет одновременно. Это худший сценарий, который в реальной
жизни возникнет вряд ли, но он позволяет понять, какую нагрузку
способна выдержать емкость применительно к конкретному отчету
за короткое время. Скрипт узнает у вас, какое количество отчетов вы
хотите открыть, после чего запросит ввести учетные данные пользова-
теля, который будет открывать отчеты, и значения фильтра. По оконча-
нии настройки для каждого отчета будет открыто свое окно браузера,
и начнется запуск отчетов с указанными фильтрами.
RealisticLoadTestTool: этот скрипт уже не так прост, как первый, и он
требует дополнительных настроек. Он разработан для имитации реа
листичных действий пользователей, таких как изменение значений
в срезах и фильтрах. Кроме того, здесь вы можете задать временные
интервалы между действиями пользователя, имитирующие принятие
им решений. Для начала этот скрипт также спросит вас, сколько отче-
тов вы хотите протестировать и учетные записи каких пользователей
использовать при этом. На этом этапе будет создан конфигурацион-
ный файл PBIReport.json в папке с именем, соответствующим текущим
дате и времени. После этого вы можете настроить этот файл, чтобы он
соответствовал вашим требованиям. Здесь вы имеете возможность за-
гружать определенные страницы или закладки, управлять количеством
повторных стартов сессии, определять значения в срезах и фильтрах
с множественным выбором и добавлять своим пользователям «время
на подумать между действиями» в секундах. Ниже приведен один из
вариантов настройки конфигурационного файла:
reportParameters={
"reportUrl":"https://app.powerbi.com/
reportEmbed?reportId=36621bde-4614-40df-8e08-
79481d767bcb",
"pageName": "ReportSectiond1b63329887eb2e20791",
"bookmarkList": [""],
"sessionRestart":100,
"filters": [
{
"filterTable":"DimSalesTerritory",
"filterColumn":"SalesTerritoryCountry",
"isSlicer":true,
"filtersList":[
"United States",
["France","Germany"]
]
},
{
"filterTable":"DimDate",
"filterColumn":"Quarter",
"isSlicer":false,
"filtersList":["Q1","Q2","Q3","Q4"]
}
],
&"thinkTimeSeconds":1
};
Обратите внимание, что для запуска скрипта есть определенные требо-

вания:
PowerShell должен быть запущен с повышенными привилегиями (от
имени администратора);
вы должны разрешить запускать неподписанные скрипты, запустив
команду Set-ExecutionPolicy Unrestricted;
должен быть установлен модуль commandlet в Power BI при помощи
команды Install-Module MicrosoftPowerBIMgmt.
Также стоит помнить о следующих ограничениях этих скриптов:
скрипты работают путем запуска основной веб-страницы HTML в брау-
зере Google Chrome, содержащей код для встраивания отчетов Power BI,
которые нам нужны для тестирования. Если вы хотите использовать
другой браузер, то вам придется изменить скрипт PowerShell для об-
ращения к этому браузеру при помощи аргументов командной строки;
если в вашем пути к скрипту содержатся пробелы или длинные имена
папок, браузер может запуститься с неправильными параметрами и не
загрузить требуемые отчеты;
версия LoadTestingPowerShellTool работает только с числовыми началь-
ным и конечным значениями числовых фильтров. Если указать тек-
стовый фильтр, скрипт запустится, а вот отчеты могут не открыться;
скрипт сохраняет токен из Azure Active Directory, который использует
для имитации действий пользователей. Время доступа к токену ис-
текает через 60 минут. Таким образом, отчеты могут выполняться на
протяжении часа и затем, по истечении срока доступа токена, завер-
шиться ошибкой;
поскольку экземпляры браузера запускаются на той же машине, на
которой был выполнен скрипт, все клиентские нагрузки ложатся имен-
но на нее. В связи с этим стоит осторожно подходить к выбору коли-
чества отчетов, запускаемых параллельно. Рекомендуется запускать
столько отчетов, сколько ядер содержит ваш центральный процессор.
Таким образом, на компьютере с 8-ядерным процессором вы можете
безопасно тестировать восемь параллельно открывающихся отчетов.
Больше запускать можно, но при этом нужно внимательно следить за
нагрузкой центрального процессора, чтобы не перегрузить его. Это
серьезное ограничение, накладываемое на обсуждаемые здесь скрип-
ты, и преодолеть его не так просто. Необходимо запускать тестовую на-
грузку на компьютере с большим количеством ядер и с компьютерами,
работающими в параллели. В Microsoft Visual Studio и Azure DevOps
встроены свои автономные веб-тестировщики, способные автомати-

зировать нагрузочные тесты, хотя в данный момент они считаются
устаревшими в пользу Azure Load Testing. Больше информации об этом
можно получить по адресу https://learn.microsoft.com/en-us/azure/load-
testing/overview-what-is-azure-load-testing.
Теперь мы дадим некоторые рекомендации по самой процедуре проведе-
ния тестов:
проведите тестирование с наборами данных, размер которых близок
к максимально допустимому для вашей емкости;
тестируйте отчеты разной степени сложности. Условно вы можете их
разделить на три категории, основываясь на количестве визуальных
элементов и продолжительности выполнения запросов. Никаких стро-
гих критериев здесь нет, а все индивидуально для каждой организации.
Также ваши тесты должны включать в себя сочетания их последова-
тельных и параллельных запусков отчетов;
создайте разных пользователей с разными разрешениями RLS и вы-
полняйте тесты от их имени;
запускайте вручную или по расписанию обновления во время тестиро-
вания. Инструмент не поддерживает этого, так что вы должны делать
это как обычно, из портала администрирования. Это позволит создать
фоновую активность, которую позже можно будет проанализировать
в приложении метрик. Будет неплохо, если вы будете запускать об-
новления и во время отсутствия нагрузок на емкости, и затем – парал-
лельно с другими обновлениями и отчетами. В результате вы получите
возможность сравнить полученные показатели и выяснить, способна
ли емкость под нагрузкой выполнять операции обновления за при-
емлемое время;
не забывайте учитывать нагрузку от других служб, таких как потоки
данных и постраничные отчеты. Несмотря на то что инструмент не
поддерживает такие возможности, вы можете запускать обновления
потоков данных или отчеты с разбивкой на страницы в Power BI при
помощи веб-портала или вызовов API прямо во время тестирования.
Теперь давайте познакомимся с приложением для отслеживания метрик
и научимся пользоваться им с целью обнаружения проблем емкости, связан-
ных с нагрузкой.
Мониторинг использования ресурсов емкости

и перегрузки
Power BI позволяет администратору емкости конфигурировать пользователь-
ские оповещения (customized notifications) для каждой емкости. Эти настрой-
ки доступны в параметрах емкости, и в них можно установить пороговое зна-
чение используемой емкости, при котором будет производиться оповещение
по электронной почте. Мы рекомендуем настроить показанные на рис. 13.6
параметры, чтобы заранее предупредить возможные проблемы.
Рис. 13.6  Настройки оповещений емкости
Пороговое значение используемой емкости для оповещений можно выста-

вить в районе 85 %. Это позволит вам обнаружить пики нагрузки еще до того,
как они станут проблемой, и отреагировать соответствующим образом – мас-
штабировать емкость или оптимизировать потенциально проблемные узлы.
Второй флажок, показанный на рис. 13.6, стоит установить, если вы хотите
включить оповещения при превышении допустимой емкости. Третий фла-
жок отвечает за оповещения при выделении дополнительного ядра в рамках
процедуры автоматического масштабирования, а четвертый – за предупреж-
дение о достижении порога автомасштабирования.
Но все ваше планирование будет абсолютно бесполезным, если вы не
сможете контролировать эффект от принятых решений. Вам нужен способ
верхнеуровневой детекции проблем, связанных с нагрузкой на емкость,
и возможность глубже проанализировать происходящее. И в этом вам мо-
жет помочь шаблонное приложение Premium Capacity Utilization and Met-
rics от Microsoft. Оно не встроено в службу, а должно быть установлено от-
дельно с портала AppSource. Вы можете загрузить его по следующей ссылке,
но для установки вам потребуются права администратора емкости: https://
appsource.microsoft.com/en-us/product/power-bi/pbi_pcmm.pbipremiumcapacity-
monitoringreport.
В настоящее время приложение позволяет анализировать 14 дней почти
в реальном времени и опускаться на уровень объектов и операций. Одним
из примеров объектов является набор данных, а операции, которые могут
выполняться применительно к нему, – это обновления и запросы.
В официальной документации к приложению детально и последовательно
описаны все присутствующие в нем элементы управления. Мы не будем все
это повторять, а лучше опишем процесс анализа пары сценариев при по-
мощи приложения. Будем проводить тестирование на емкости EM1 с одним
виртуальным ядром. Мы специально выбрали такой тип емкости, поскольку

его легко перегрузить при работе с одной 8-ядерной клиентской машины.
После загрузки нескольких наборов данных мы провели следующие тесты
за несколько часов:
с 5:00 до 5:30 утра мы вручную открыли отчеты и поработали с ними;
с 7:00 до 7:45 мы запускали нагрузочные тесты на емкости без авто-
масштабирования. При этом настроили механизм тестирования на
одновременную загрузку 12 браузеров. В двух из них были запущены
отчеты со сложными запросами, на выполнение которых в идеальных
условиях требуется порядка 15 секунд. Одновременно с этим в фоно-
вом режиме мы производили операции обновления в ручном режиме.
При этом отметили, что с течением времени отчеты начинают работать
все дольше;
примерно в 10 часов утра мы добавили еще одно ядро в рамках про-
цесса автомасштабирования и создали дополнительную нагрузку на
емкость;
в районе 10:30 мы подняли ограничение автомасштабирования до че-
тырех и еще повысили нагрузку, запустив в параллели 16 браузеров
с четырьмя сложными отчетами. На фоне продолжили выполнять об-
новление наборов данных в ручном режиме;
примерно в 11:00 мы снизили нагрузку на емкость, закрыв браузеры,
в которых выполнялись сложные отчеты.
По прошествии этой работы посмотрим на отчет с метриками. Наша цель –
определить точки повышенной нагрузки, взглянуть на режим отсрочки и уз-
нать, как работает автомасштабирование.
На рис. 13.7 показан общий вид приложения с метриками. Мы выделили
и пронумеровали интересующие нас области.
Перед тем как подробно описать пронумерованные области, нам бы хоте-
лось дать ряд важных комментариев по поводу представленного примера:
наша емкость была приобретена специально для тестирования. Таким
образом, данные у нас были собраны лишь за один день, чем объясня-
ется то, что диаграмма по загрузке процессора вверху слева по большей
части пустая. При этом столбик диаграммы разбит на объекты, и мы
видим, что один из них использует процессор больше остальных. Этот
график может быть преобразован для просмотра других метрик при
помощи кнопок вверху;
график со спарклайнами по неделям в правой части отчета остался
пустым по той же причине, которую мы указали выше;
из-за отсутствия исторических данных столбец с изменением про-
изводительности (Performance Delta) остался незаполненным. Здесь
обычно указываются относительные оценки, и отрицательные числа
говорят о снижении производительности по объектам. Подробности
можно увидеть на странице отчета Artifact Detail, с которой мы позна-
комимся позже. Строки с отрицательными значениями в этом столбце
будут подсвечены оранжевым для лучшей заметности;
Рис. 13.7  Общий вид приложения для отслеживания метрик емкости
в верхней части отчета присутствует ссылка Help, по которой откроет-

ся полная инструкция по работе с отчетом. Такие страницы включены
во все страницы отчета;
в отчете также реализованы всплывающие подсказки, открывающиеся
при наведении на иконку со знаком вопроса в верхней правой части
визуальных элементов. На рис. 13.8 показана всплывающая подсказка
для визуального элемента Artifacts (14 days), находящегося в нижней
левой части отчета.
Теперь давайте пройдемся по нумерованным пунктам с рис. 13.7. Мы де-
тально опишем каждый выделенный фрагмент на рисунке.
1. На графике нагрузки на процессор мы видим превышение нашего по-
рогового значения (пунктирная линия) после 7 утра, что соотносится
с созданной нами дополнительной нагрузкой. Этим можно объяснить
замеченное нами постепенное снижение быстродействия отчета.
2. Эти два всплеска активности характеризуют повышение нагрузки пос
ле спада, когда мы масштабировали емкость сначала на одно дополни-
тельное ядро, а затем на четыре.
3. Здесь видно, что на протяжении двух часов мы сталкивались с пере-
грузкой емкости. Вы можете щелкнуть мышью по этим столбикам, что-
бы увидеть на графике слева, какие объекты активно использовались
в это время.
Рис. 13.8  Пример всплывающей подсказки
4. В отчете в удобном виде представлена информация о том, какие объ-

екты больше всего нагружают систему. В данном случае мы видим, что
большая часть нагрузки на процессор пришлась на датасет с названием
Customer360 TEST. Для получения детальной информации вы можете
опуститься на уровень операций.
5. Вы должны регулярно отслеживать значения метрик Artifact Size
и Overloaded Minutes. Это даст вам понять, какие объекты занимают
больше всего места и генерируют наибольшую нагрузку. Для нашей
емкости EM1 предельный объем набора данных равен 3 Гб, так что
наш датасет может спокойно уместиться в памяти. При приближении
размера набора данных к означенному пределу нам необходимо будет
предпринять определенные действия. Помните, что память, выделяе-
мая для набора данных, учитывает операции обновления и запускае
мые запросы. Если объем датасета приближается к пороговому значе-
нию, возможно, вы не оставляете достаточно памяти для избежания
перегрузок.
6. На этом визуальном элементе отображаются пиковые значения па-
мяти, которую занимали объекты набора данных в рамках 3-часовых
интервалов. Здесь мы видим, что в двух временных периодах мы пре-
вышали лимит на параллельные обновления. В таких случаях следует
дополнительно исследовать, какие обновления выполнялись и возни-
кали ли пересечения, приведшие к отсрочке обновлений, повлиявшей
на общую производительность.
7. На этой диаграмме операции делятся на быстрые (Fast: < 100 мс),
приемлемые (Moderate: от 100 мс до 2 с) и медленные (Slow: > 2 с).
В идеале мы бы хотели видеть здесь как можно меньше медленных
операций, и тенденция их присутствия должна быть равномерной или
нисходящей. Если она восходящая, вам необходимо дополнительно ис-
следовать данные на предмет поиска объектов, наибольшим образом
влияющих на производительность.
Теперь, когда мы произвели обобщенный анализ производительности
системы, пришло время более детально рассмотреть объекты и операции,
ставшие причиной выделенных на рис. 13.7 областей.
Исследование перегрузки
Первое, что мы можем сделать, – это повысить гранулярность двух верхних
визуальных элементов с обзорной страницы приложения. Мы открыли от-
чет за 24 февраля из верхнего левого графика, в результате получив рас-
шифровку по часам. Одновременно с этим открывается детализированный
вид правого верхнего графика до 30-секундных интервалов, которые совпа-
дают с продолжительностью циклов вычисления, о которых мы говорили
ранее.
Детализированные диаграммы показаны на рис. 13.9. Мы изменили их
положение для большей наглядности. Также мы навели мышь на один из
высоких столбиков между 7:00 и 8:00 утра, когда в нашем распоряжении
было лишь одно виртуальное ядро. Значение этого столбика выходит за до-
пустимую границу, и мы отчетливо видим, как сильно в этот момент емкость
нуждается в дополнительных ресурсах. Также на графике хорошо видны
моменты, когда нам было выделено сначала одно дополнительное ядро, а за-
тем четыре. Заметно и то, что в результате оказания повышенных нагрузок
на емкость ближе к концу тестирования ресурсы центрального процессора
в течение короткого времени использовались более чем на 150 %.
Вы могли ожидать, что добавление одного виртуального ядра к емкости EM1 подни-
мет предельную планку использования центрального процессора до отметки 200 %.
Однако на деле одно дополнительное ядро увеличило порог до 150 %, а четыре
ядра – до 300 %. Причина в том, что ресурсы выделяемых в рамках автомасшта-
бирования ядер поровну поделены между серверными и интерфейсными опера-
циями. Таким образом, при добавлении одного ядра мы получаем прирост в 50 %
к серверной обработке, которую, как мы уже писали, и отслеживают метрики про-
изводительности.
Теперь давайте щелкнем мышью по столбику, выделенному на предыду-

щем рисунке, чтобы посмотреть, какие объекты внесли наибольший вклад
в этом временном интервале с перегрузкой. На рис. 13.10 показан разверну-
тый вид диаграммы по объектам для двух самых ресурсоемких элементов.
Рис. 13.9  Подробные диаграммы по нагрузке
Рис. 13.10  Детализированный вид отчета по объектам и операциям

Исходя из путей объектов, выделенных жирным шрифтом, понятно, что

оба объекта представляют собой наборы данных в рабочей области Load-
Test. Как мы видим, в первом наборе данных присутствуют только запросы
(Query), и мы зафиксировали перегрузку. Во втором наборе производились
и другие операции, и при этом нагрузка на центральный процессор оказалась
намного меньше.
Пойдем дальше и щелкнем правой кнопкой мыши по объекту Customer360
TEST, чтобы открылась страница с детализацией, показанная на рис. 13.11.
Здесь вы можете обнаружить неожиданные всплески активности и наблю-
дать за тенденциями. Всплески при этом можно проанализировать более
детально на других страницах, о которых мы скажем позже.
На рис. 13.11 мы видим почасовую расшифровку для указанного набора
данных по разным метрикам и операциям. С помощью этих графиков вы
можете выяснить, были ли всплески активности связаны с резким увеличе-
нием количества пользователей, запуском других активностей в емкости или
иными факторами.
Рис. 13.11  Детализация до объекта с тенденциями по часам
Теперь попробуем исследовать период с повышенной нагрузкой более

подробно. Для этого вернемся на уровень выше – к странице отчета, по-
казанной на рис. 13.9, щелкнем правой кнопкой мыши на пике активности,
соответствующем времени 7:43 на диаграмме Capacity CPU %, и выберем
пункт меню TimePoint Detail, как показано на рис. 13.12.
Рис. 13.12  Детализация до конкретной точки во времени
На открывшейся странице TimePoint Detail, показанной на рис. 13.13,

отображается информация с высокой степенью детализации. Интервал от-
чета содержит примерно час времени с выбранной нами временной точкой
посередине, которая показана в виде вертикальной красной линии. Обратите
внимание, что данные об интерактивных операциях (Interactive Operations)
и фоновых операциях (Background Operations) разнесены по разным табли-
цам. При этом интерактивные операции собраны за отчетный час, тогда как
фоновые – за прошедшие сутки, поскольку все они вносят вклад в расчетную
нагрузку. В столбце (метрике) % of Capacity указано, какой процент общей
емкости был задействован для выполнения операции. Мы также можем от-
слеживать продолжительность операции и использование режима отсрочки
интерактивных запросов (в столбце Throttling (s)).
На этом этапе анализа бывает полезно объединить усилия администрато-
ров емкости и владельцев ее содержимого для определения того, влияют ли
отсрочки запросов на работу пользователей, и если да, то насколько сильно.
Если влияние ощутимое и мы видим, что большой вклад в это вносят фоно-
вые операции, можно попробовать перенести запланированные обновления
на другое время, чтобы снизить фоновую активность и вероятность появле-
ния перегрузок. В нашем случае влияние фоновых операций можно считать
минимальным, так что необходимо направить взгляд в сторону оптимизации
отчетов и/или масштабирования.
Рис. 13.13  Детализация до операций
Теперь обратим внимание на вкладку Evidence, содержимое которой по-

казано на рис. 13.14. Здесь собраны только перегруженные объекты – дан-
ные на этой странице появляются лишь в случае возникновения перегрузки.
При этом для каждого объекта в таблице представлена метрика Overloading
score. В нашем примере мы можем заметить, что для всех трех первых объ-
ектов присутствуют минуты с перегрузкой (столбец Overloaded minutes)
в одинаковом интервале от 15 до 23 минут. При этом обратите внимание,
что для объекта Customer360 TEST показатель Overloading score превышает
200 000, тогда как для двух остальных он составляет всего несколько сотен.
Абсолютная оценка здесь не имеет смысла. Она вычисляется с учетом того,
как часто объект влиял на перегрузку и насколько сильным было это влия-
ние. Первым делом вы должны обращать внимание на объекты с наивысшей
оценкой. В нашем случае, поскольку мы видели такую большую активность
запросов к этому набору данных и не можем изменить фоновую нагрузку,
стоит задуматься о переносе датасета в другую емкость или проведении
масштабирования.
И последняя страница в отчете, о которой мы еще не сказали, – это Refresh,
показанная на рис. 13.15. Она может быть открыта как со страницы с объек-
тами, так и при помощи верхней вкладки. В последнем случае на странице
будут учитываться все объекты, и именно это нужно нам в нашем примере.
Страница Refresh предназначена для анализа нагрузки вследствие обновле-
ний по дням и часам с привязкой к объектам.
Мы рекомендуем использовать метрики (столбцы) Duration (s) и Ratio
в нижней таблице для определения главных кандидатов для дальнейшего
исследования. И действительно, первым делом необходимо проверить про-
должительные обновления с высоким показателем Ratio, вычисляемым как

отношение времени использования процессора (показатель CPU (s)) к дли-
тельности (Duration (s)). Оптимизация здесь может подразумевать повы-
шение производительности запросов на языке M и/или смену расписания
обновлений или емкости.
Рис. 13.14  Страница Evidence с объектами, влияющими на перегрузку
В заключение взглянем на временной отрезок после 10:00, когда нам

в рамках автоматического масштабирования было выделено сначала одно
дополнительное виртуальное ядро, а затем четыре. Даже с учетом проведен-
ного масштабирования поначалу мы испытывали проблемы с перегрузкой.
Это видно на рис. 13.16 по второму столбику на визуальном элементе с по-
часовой нагрузкой. Мы воспользуемся страницей Timepoint Detail, чтобы
проанализировать некоторые детали поведения емкости и связать это с тес
тированием, которое мы провели.
На рис. 13.16 показана всплывающая подсказка, на которой видно, что в цик
ле, соответствующем времени 10:44:00, нагрузка составляла 153 %. Также мы
видим, что некоторые запросы были переведены в режим отсрочки, но время
отсрочки составляет в основном 8–9 секунд. Сравните это с рис. 13.13, где вре-
мя отсрочки запросов достигало 20 секунд для того же набора данных. Давайте
посмотрим, что здесь происходит. До 10:44 мы видим повышение активно-
сти. При достижении нагрузки в 150 %, допустимой с одним дополнительным

ядром, система ввела отсрочку для некоторых запросов на время выделения
дополнительных ресурсов. Причина в том, что дополнительные ядра не ис-
пользуются до тех пор, пока не понадобится помощь в борьбе с перегрузкой.
Рис. 13.15  Страница Refresh с информацией об обновлениях
Рис. 13.16  Страница Timepoint Detail

на момент выделения одного дополнительного ядра
Теперь переместимся во времени чуть вперед, на 10:56:30, как показано на

рис. 13.17. Обратите внимание, что те же запросы не были отсрочены.
Рис. 13.17  Страница Timepoint Detail

на момент выделения четырех дополнительных ядер
Итак, мы готовы подвести итоги нашего анализа и привести действия, ко-

торые следует выполнять при использовании приложения для диагностики
метрик емкости.
Действия, которые мы будем описывать, предполагают, что архитектура, наборы дан-

ных, механизм RLS, операции преобразования данных и отчеты уже были оптими-
зированы. Зачастую в организациях слишком рано прибегают к масштабированию
своих емкостей. Это ведет к повышению затрат и не оправдывает себя в условиях,
когда все остальные составляющие решения не оптимизированы. Да, вы можете вре-
менно увеличить ресурсы, чтобы облегчить работу пользователям, пока параллельно
работаете над улучшением структуры решения. Еще одним аргументом против мас-
штабирования в качестве первой меры является то, что такой подход идет вразрез
с рекомендованной практикой оптимизации и управления производительностью.
Если вы полагаете, что ваше решение нуждается в оптимизации, мы советуем первым
делом обратить внимание на самые часто используемые наборы данных и отчеты,
страдающие от низкой производительности по сравнению с другими объектами в ем-
кости. Их оптимизация позволит снизить нагрузку на процессор и память и освободит
дополнительные ресурсы в емкости. Кроме того, стоит особо выделять самые про-
должительные обновления с повышенным использованием процессора в фоновом
режиме. В этом вам помогут подходы и методы, которые мы обсуждали в предыду-
щих главах.
Давайте подведем итог этого раздела, обозначив шаги, которые вам сле-
дует предпринимать при возникновении перегрузок при работе с отчетами.
1. Первым делом выделите самые объемные объекты, вносящие вклад
в перегрузку, особенно обращая внимание на те из них, которые ис-
пользуются большим количеством пользователей.
2. Проанализируйте тенденции поведения этих объектов, выяснив, какой
характер носят перегрузки – постоянный или периодический. Также
обратите внимание на то, как с течением времени меняется актив-
ность системы, количество пользователей и минут с перегрузкой. Если
вы наблюдаете постепенный рост этих показателей, скорее всего, это
говорит о естественных увеличениях потребности в ресурсах вашей
системы, и без вертикального или горизонтального масштабирования

здесь не обойтись.
3. Исследуйте периоды с высокой нагрузкой на предмет возникновения
других активностей. Вы можете обнаружить, что в разных наборах
данных интерактивные пики приходятся на одно и то же время. В ре-
зультате вы можете перенести наиболее активные объекты в емкости
с наличием свободных ресурсов или прибегнуть к масштабированию.
Емкости Embedded A представляют собой предложения от Microsoft в формате плат-
форма как услуга (Platform-as-a-Service – PaaS) и приобретаются и оплачиваются
в Azure. Они располагают полной интеграцией с Azure Log Analytics, что позволяет
выполнять трассировку почти в реальном времени и собирать метрики, доступные
в Log Analytics для Azure Analysis Services. Версия Embedded Gen2 была улучше-
на и расширена за счет дополнительных точек данных, но она не содержит готовых
отчетов. Кроме того, вы будете вынуждены нести расходы на Azure и осуществлять
поддержку работоспособности системы. Подробнее о соответствующих настройках
можно почитать по адресу https://learn.microsoft.com/ru-ru/power-bi/developer/em-
bedded/monitor-power-bi-embedded-reference.
Теперь подведем итоги этой главы и перейдем к заключительной главе

книги.
В этой главе мы вплотную подошли к окончанию нашего увлекательного
путешествия в мир оптимизации решений на основе Power BI. Мы подробно
поговорили о возможностях, предоставляемых емкостями Power BI Premium
и Embedded. Мы узнали, что, несмотря на необходимость приобретать эти
лицензии отдельно, их планы содержат очень много общего в отношении
функционала. Это означает, что рекомендации по оптимизации этих емко-
стей по большей мере совпадают.
Также мы ближе познакомились с типом лицензирования Power BI Premi-
um и узнали о некоторых уникальных возможностях, позволяющих повысить
производительность и реализовать масштабирование проекта. После этого
мы поговорили о втором поколении Premium (Gen2), которое в настоящее
время входит в базовое предложение Microsoft. В связи с общей доступно-
стью Gen2 мы не стали тратить время на описание предыдущего поколения
Premium и его особенностей. Затем быстро пробежались по настройкам ем-
кости, таким как тайм-ауты запросов и интервалы обновлений, с помощью
которых вы можете уменьшить влияние ресурсоемких операций на емкость.
Далее в этой главе мы обсудили разные модели оценки нагрузки на ем-
кость в Gen2 и изменения в ограничениях на использование памяти, которые
помогли повысить масштабируемость решений, особенно в отношении об-
новления данных. В частности, мы поговорили о возможности осуществлять
отсрочку запросов во время перегрузки емкости.
После этого мы продолжили разговор о перегрузках и в качестве основной
меры борьбы с истощением ресурсов посоветовали применять автомати-
ческое масштабирование, которое позволяет также сэкономить на покупке

дополнительных емкостей. Мы узнали, что измерение нагрузки на мощ-
ность производится циклически с интервалами в 30 секунд. В этих циклах
вычисления собирается информация обо всех активностях за период для
определения того, могут ли ресурсы системы быть перегружены. Перегрузка
фиксируется тогда, когда суммарное процессорное время, требуемое для вы-
полнения операций в рамках 30-секундного окна, превышает выделенные
в виде виртуальных ядер ресурсы.
Далее мы поговорили о планировании емкости и показали способ опре-
деления начального размера емкости, воспользовавшись оценками размера
набора данных, частоты обновлений и другими показателями. Мы вместе
выполнили нагрузочные тесты с помощью скриптов PowerShell, предостав-
ленных компанией Microsoft, а также обсудили их ограничения и условия
применения. Мы узнали, как использовать эти инструменты для имитации
продолжительной предельной нагрузки с одновременным открытием мно-
жества отчетов. Кроме того, мы посмотрели, как можно проводить и более
реалистичные проверки, включающие имитацию изменения пользователя-
ми значений срезов и фильтров, перехода по страницам и использования
закладок.
Также в этой главе мы подробно поговорили о возможностях мониторинга
емкостей. Сначала мы узнали о том, как использовать систему оповещения
администраторов о достижении емкостью своего порога ресурсов и выделе-
нии дополнительных ядер в рамках автомасштабирования. Затем посмот
рели на практике, как применительно к емкости EM1 провести нагрузочные
тесты с продолжительным использованием ресурсов на пределе возможного.
Мы познакомились с приложением Premium Capacity Metrics and Utiliza-
tion и научились с его помощью следить за высокоуровневыми показателями
нагрузки и при необходимости опускаться до нужного уровня детализации.
В завершение главы мы акцентировали ваше внимание на важности вы-
веренного подхода к масштабированию и оптимизации емкости, лишний
раз подчеркнув, что не стоит всегда полагаться на возможности расширения
ресурсов, а вместо этого лучше уделить время разносторонней оптимизации
своего решения. Эта мысль является основой данной книги, к тому же опти-
мизация при правильном подходе способна сэкономить компании немало
денег, которые могли быть бездумно потрачены на расширение физических
ресурсов. Необходимо очень тщательно мониторить появляющиеся шабло-
ны и тенденции в работе системы и следить за тем, что именно происходит
в пиковые моменты, чтобы обнаружить проблемные объекты, требующие
большого объема ресурсов.
В следующей и заключительной главе книги мы рассмотрим процесс
оптимизации встраивания содержимого Power BI в пользовательские веб-
приложения.
Глава 14
Встраивание
в приложения
В предыдущей главе мы подробно рассказали о емкостях, предоставляемых

в рамках лицензий Power BI Premium и Embedded. Мы узнали, какие до-
полнительные возможности предлагают эти планы, особенно в отношении
масштабируемости и производительности. Мы также поговорили о том, как
емкости управляют доступными ресурсами в обычном режиме и в режиме
перегрузки, и научились мониторить, оптимизировать и масштабировать
емкости.
В этой главе мы взглянем на оптимизацию с точки зрения встраивания
(embedding) содержимого Power BI в приложения. Это позволяет разработчи-
кам использовать API Power BI для внедрения отчетов, дашбордов и плиток
в пользовательские приложения. Данную возможность можно использовать
по-разному, и чаще всего в компаниях прибегают к ней для предоставления
аналитического контента в рамках внутренней сети, на общедоступных сай-
тах и даже в коммерческих приложениях.
Чисто технически встраивание в Power BI доступно при использовании лю-
бой емкости, так что вам нет необходимости обязательно приобретать паке-
ты Premium или Embedded, чтобы опробовать эту возможность на практике.
Однако для полноценного использования механизма встраивания вам при-
дется воспользоваться выделенной емкостью, чтобы обойти ограничения,
характерные для общих емкостей, например на количество токенов внед
рения (embed tokens). Таким образом, материал в этой главе будет посвящен
емкостям Premium и Embedded. Мы не будем касаться опции публикации
в интернете (Publish to Web), предназначенной для массового распростра-
нения содержимого Power BI, поскольку она работает совсем по-другому.
Мы сосредоточимся именно на встраивании, обсудим нюансы этой техно-
логии, ее ограничения и расскажем о том, как добиться максимально эффек-
тивного внедрения содержимого Power BI во внешние приложения. Также
коснемся темы мониторинга внедрения, помогающего определить узкие
места в процессе встраивания контента в приложения.
повышение производительности внедрения;
измерение производительности внедрения.
Повышение производительности внедрения  269
Повышение производительности внедрения

Встраивание содержимого во внешние приложения дает организации опре-
деленную гибкость в отношении развертывания и распространения кон-
тента Power BI. При принятии решения о типе приобретаемой лицензии
необходимо рассмотреть вопросы стоимости, возможности развертывания
и прочие нюансы. В линейке компании Microsoft есть емкости, больше ори-
ентированные на внешнее распространение контента, а не на внутреннее.
В то же время функционал и механизмы оптимизации у всех емкостей при-
мерно одинаковые. Таким образом, все советы и рекомендации, которые вы
почерпнете из этой главы, вы сможете с легкостью применять при работе
с другими типами емкостей. Если вы хотите подробнее узнать о лицензии
Embedded и моделях распространения, то можете обратиться к официальной
документации по адресу https://learn.microsoft.com/ru-ru/power-bi/developer/
embedded/embedded-faq.
Встраивание содержимого в приложения при помощи API – это еще один
способ распространения контента без использования веб-интерфейса Po
wer BI. На рис. 14.1 показана эта схема.
Пользовательское приложение
(например, портал или веб-сайт)
Вызовы API Веб-страница или форма

и содержимое Power BI
Служба Power BI
Встроенное содержимое
Power BI
Рис. 14.1  Встраивание содержимого Power BI во внешние приложения
В этой схеме пользователи взаимодействуют с внешним приложением,

а не напрямую с powerbi.com. После инициализации содержимого приложе-
ние не влияет на производительность встроенного контента, если не считать
конкуренцию за процессорное время на клиенте.
При встраивании содержимого вы должны придерживаться тех же рекомендаций
в отношении оптимизации, которые относятся к любому другому контенту в Power BI.
Следуйте советам, приведенным в предыдущих главах, которые касаются модели-
рования данных, загрузки, структуры отчетов и т. д. Также очень важно выполнять
планирование и масштабирование емкости, как было описано в прошлой главе.
В то же время существуют и особые требования в отношении настройки приложений
со встроенным содержимым и их взаимодействия со службой Power BI. Далее вы
узнаете, чем отличается технология встраивания от традиционного использования
Power BI и как можно ее ускорить.
270  Встраивание в приложения
В процессе встраивания содержимого Power BI в приложение мы добав-

ляем новый слой обработки и связанных с ней задержек. Когда мы смотрим
отчет на сайте Power BI, в большинстве случаев в этот момент приложение
Power BI уже предварительно загружено и инициализировано. Это означает,
что загружен весь ключевой код приложения и зависимости. В то же время
при загрузке Power BI по требованию в нашем приложении это может быть
не так. На этом этапе всегда могут присутствовать накладные расходы и со-
путствующие им задержки в результате взаимодействия приложения со
службой Power BI. Сюда включается время, затрачиваемое приложением
еще до обращения к Power BI, когда пользователи видят другое содержи-
мое. Это увеличивает время загрузки содержимого Power BI. Таким образом,
мы советуем любыми способами минимизировать накладные расходы на
встраивание.
Давайте приведем рекомендации, связанные с оптимизацией сценариев
встраивания контента.
Обращайте внимание на размещение приложения и его архитек-
туру: двунаправленная стрелка на рис. 14.1 характеризует коммуни-
кацию и перемещение данных между Power BI и пользовательским
приложением. Вы должны стремиться минимизировать задержки, свя-
занные с этой коммуникацией, путем размещения вашего приложения
максимально близко к домашнему региону Power BI, насколько это
только возможно. Основными факторами быстродействия здесь яв-
ляются количество прыжков (hops) между транзитными узлами и про-
пускная способность канала связи между Power BI и приложением. Не
забывайте, что визуальные элементы выполняются на стороне кли-
ента, так что если у вас есть пользователи в разных географических
зонах, скорость работы приложения с одинаковым содержимым у них
может отличаться.
Предварительно загружайте зависимости: в API службы Power BI
Embedded присутствует метод с именем powerbi.preload, позволяющий
по требованию загружать ключевые зависимости Power BI. Это бывает
полезно, когда приложение не показывает пользователю контент из
Power BI немедленно после открытия. Если вы знаете, что пользова-
тель должен произвести определенные действия перед открытием со-
держимого Power BI, то можете ускорить процесс его первой загрузки.
Это можно сделать, вызвав метод powerbi.preload при инициализации
приложения, но перед тем как пользователь доберется до открытия
контента Power BI. В результате будут загружены и локально кеши-
рованы нужные файлы JavaScript, CSS и другие объекты, что при не-
обходимости отобразить содержимое Power BI позволит обойтись без
предварительного извлечения всех зависимостей. Дополнительную
информацию по этому методу можно почитать по адресу https://learn.
microsoft.com/ru-ru/javascript/api/overview/powerbi/preload.
Используйте механизм предварительной загрузки только в случае, если содержимое
Power BI располагается не на основной странице приложения. Лучше всего инициа-
лизировать iFrame заранее, если это возможно, как объясняется в следующем пункте.
Повышение производительности внедрения  271
Предварительно инициализируйте iFrame: встраивание контен-

та Power BI реализуется с помощью конструкции HTML, именуемой
iFrame. iFrame используется для внедрения одного документа HTML
в другой и обычно применяется с целью отображения внешнего кон-
тента, управляемого с другой веб-страницы или сервера. Например,
вы можете использовать iFrame для встраивания поисковой страницы
Google в один из разделов вашего сайта. При внедрении содержимого
при помощи метода powerbi.embed вам необходимо передать идентифи-
катор отчета, ссылку URL и токен доступа. В зависимости от структуры
приложения не все эти составляющие могут быть доступны немедлен-
но. При вызове метода powerbi.embed сначала подготавливается и ини-
циализируется объект iFrame – еще до загрузки содержимого. Одна-
ко можно выполнить эту инициализацию еще раньше, вызвав метод
powerbi.bootstrap(element, config). В качестве параметров нужно пере-
дать элемент HTML и объект конфигурирования. По готовности всех не-
обходимых параметров вы можете вызвать метод powerbi.embed, пере-
дав ему тот же элемент HTML, который уже был инициализирован. Это
отличный способ заранее подготовить контент Power BI к отображению
в фоновом режиме, пока пользователь занят в приложении чем-то дру-
гим. В зависимости от архитектуры и конфигурации приложения этот
подход может сэкономить несколько драгоценных секунд пользовате-
лю, что положительно скажется на его мнении о работе приложения.
Эффективно используйте параметры метода embed: второй па-
раметр метода powerbi.embed(element, config) позволяет задать на-
стройки внедряемого содержимого. Ниже перечислены свойства объ-
екта конфигурирования, напрямую влияющие на производительность
решения:
– EmbedURL: это свойство представляет собой ссылку на встраивае-
мый контент. Оно присваивается атрибуту src объекта iFrame. Из-
бегайте самостоятельного создания этой ссылки. Лучше извлечь
ее из API Get Reports, Get Dashboards или Get Tiles;
– Permissions: это свойство отвечает за права, которыми вы хотите
наделить пользователя отчета. Используйте значение Read, если
пользователю не нужно будет создавать контент и копировать или
редактировать отчеты. Это позволит избежать инициализации не-
нужных компонентов интерфейса. В случае если пользователю
необходимо будет редактировать содержимое, выдавайте ему ми-
нимально возможные для этого права доступа;
– Slicers, filters и bookmarks: это отдельные свойства объекта кон-
фигурирования, позволяющие задать контекст для содержимого.
По умолчанию Power BI старается кешировать визуальные эле-
менты для ускорения работы отчетов, пока запросы выполняются
в фоновом режиме. Эти кешированные результаты строятся на
основании контекста отчета, включающего в себя слайдеры и т. д.
Однако если передать этот контекст прямо в коде, кеш исполь-
зоваться не будет. Таким образом, если вам известен начальный
контекст для встраиваемого отчета, вы должны публиковать отчет
уже с установленным контекстом. После этого вы сможете вызы-

вать метод embed без контекста и воспользоваться всеми преиму-
ществами механизма кеширования.
Реализуйте эффективную смену отчетов: пользовательские прило-
жения позволяют создавать самый разнообразный функционал, вклю-
чая панель навигации для отчетов Power BI. Пользователь может просто
нажимать на соответствующие кнопки и переключаться между отче-
тами без необходимости обновлять содержимое страницы. Если вы
захотите реализовать подобный функционал, убедитесь, что повторно
используете объект iFrame. При вызове метода powerbi.embed исполь-
зуйте другую конфигурацию, но элемент HTML передавайте тот же.
Измените интерфейс, чтобы снять нагрузку со срезов: вы можете
снизить сложность отчетов, убрав из них срезы и настроив их напря-
мую в объекте конфигурирования, который мы упоминали ранее. Это
позволит вам собрать весь пользовательский выбор и передать его
одним объектом, пока загружается встроенный отчет.
Регулируйте время реакции приложения для более комфортной
работы: пользователь может дважды щелкать на ссылках в отчетах
или при смене отчетов слишком часто нажимать на кнопку мыши, что
может приводить к отправке на сервер лишних запросов. Вы можете
предупредить такое поведение приложения, установив в его парамет
рах небольшую длительность времени, в течение которого будут игно-
рироваться последующие действия пользователя. Обычно эта длитель-
ность устанавливается в районе 100 мс.
Продумывайте вывод нескольких визуальных элементов: интер
активные отчеты могут состоять не только из визуальных элементов.
Помимо обычных отчетов, вам может понадобиться скомбинировать
несколько отчетов или даже отдельные плитки в вашем приложении
вместе с другим содержимым. Если встраивать каждый объект отдель-
но, для них понадобятся свои элементы iFrame. В то же время инициа-
лизация iFrame – процесс довольно ресурсоемкий, так что вы должны
стремиться к минимизации их количества. Вот несколько способов:
– консолидируйте отчеты: если это возможно, объединяйте вместе
данные и визуальные элементы из разных датасетов и отчетов. Это
позволит вам внедрять содержимое в виде одного элемента iFrame;
– используйте дашборды для объединения разнородного контен-
та: дашборды в Power BI могут содержать плитки из разных отчетов
и наборов данных, которые невозможно объединить технически.
Если вам необходимо встроить в приложение плитки из разных от-
четов, попробуйте объединить их на одном дашборде и внедрить
в приложение его, а не отдельные элементы. Это позволит вам обой-
тись одним элементом iFrame. Вы также можете встраивать в при-
ложение отдельные плитки с дашборда, а не из отчетов. Это позволит
сделать процесс загрузки более быстрым. Вы можете рассмотреть
данный вариант, если вам не нужно, чтобы в вашем приложении
отображались все плитки, и вы хотите обойтись одним элементом
iFrame;
Измерение производительности внедрения  273
– используйте пользовательский макет: объект конфигурирования

содержит свойство layoutType, которому может быть присвоено зна-
чение customLayout. Здесь вы можете вручную задать размер страни-
цы и макет визуального элемента, переписав тем самым значения по
умолчанию. Более того, с помощью этого свойства вы можете скрыть
нежелательные визуальные элементы. Также допустимо использо-
вать этот подход для изменения положения элементов на странице,
чтобы отчет комфортно было просматривать с мобильных устройств.
Больше информации о настройке пользовательского макета можно
получить на странице https://learn.microsoft.com/ru-ru/javascript/api/
overview/powerbi/custom-layout.
Теперь, когда вы знаете, как оптимизировать сценарии внедрения содер-
жимого Power BI в приложения, давайте посмотрим, как можно измерить
производительность встроенных отчетов.
Измерение производительности внедрения

При встраивании содержимого Power BI в приложения рекомендуется не
упускать из виду вопросы производительности и ее измерения. Методы мо-
ниторинга, описанные ранее в этой книге, идеально подходят для измерения
производительности отдельных объектов, но они бессильны, когда речь идет
о том, что происходит внутри приложения и есть ли проблемы, связанные
с загрузкой контента из Power BI. К примеру, некий встроенный отчет тео-
ретически может посылать запросы и прорисовывать визуальные элементы
в течение двух секунд, но пользователь при этом вынужден ждать дольше
из-за накладных расходов, связанных с внедрением контента. Перед тем как
углубиться в измерение этих накладных расходов, дадим некоторые практи-
ческие рекомендации.
При настройке производительности встраиваемых объектов необходимо заранее из-

мерить значения метрик в базовом виде – без встраивания. Это позволит вам полу-
чить эталонные показатели для сравнения и попутно даст возможность обнаружить
проблемы, не связанные с внедрением содержимого в приложение. Вы можете про-
должать оптимизировать датасеты, выражения DAX и прочее параллельно с опти-
мизацией механизма внедрения контента. При этом очень важно убедиться, что для
проверки производительности встраивания в приложение вы каждый раз использу-
ете одно и то же содержимое. Так вы сможете гарантировать, что все произведенные
улучшения достигаются за счет оптимизации механизма встраивания, а не по при-
чине разницы контента.
При внедрении содержимого Power BI в приложение система генерирует

определенные события, помогающие отследить происходящее и оптимизи-
ровать процесс встраивания. Полная информация обо всех событиях собра-
на в официальной документации по адресу https://learn.microsoft.com/ru-ru/
javascript/api/overview/powerbi/handle-events.
Здесь мы приведем три основных события, которые могут помочь в про-
цессе оптимизации:
Loaded: это событие возникает в момент окончания инициализации

отчета или дашборда Power BI. Загрузка считается завершенной, когда
исчезает логотип, показанный на рис. 14.2;
Рис. 14.2  Логотип Power BI и индикатор прогресса,

отображаемые в процессе загрузки отчета
Rendered: это событие свидетельствует об окончании обработки всех

визуальных элементов и выводе их на экран;
VisualRendered: это событие вызывается для каждого визуального эле-
мента отдельно. Однако по умолчанию оно не генерируется – для этого
необходимо в конфигурации встраивания установить свойству visual-
RenderedEvents значение true. Это позволит отследить скорость загрузки
каждого элемента по отдельности, ранжировать их и выделить наи-
более медленные. Эту информацию также можно получить из Desktop
Performance Analyzer, и всегда полезно сравнивать производительность
развернутого решения в процессе разработки и в рабочем окружении.
Теперь давайте посмотрим, как можно использовать события для понима-
ния того, где именно возникают задержки. При этом мы будем использовать
как перечисленные выше события, так и события, инициируемые в прило-
жении посредством действий пользователя. Это даст нам полную картину
происходящего. На рис. 14.3 показана временная шкала пользовательской
активности в приложении. Предположим, что пользователь нажал на кнопку
в веб-приложении (не в отчете Power BI), что привело к загрузке отчета Po
wer BI с двумя визуальными элементами.
На рис. 14.3 показаны Пользовательское событие старта и Пользова-
тельское событие финиша. Этими событиями ограничено полное время
с момента нажатия пользователем на кнопку открытия отчета и до заверше-
ния работы по их загрузке и отрисовке. В приложении может выполняться
и другая работа в фоновом режиме, и именно поэтому мы сделали опреде-
ленный временной зазор между событиями Rendered и Пользовательское
событие финиша.
Перехватив эти события, вы можете путем несложных математических
действий вычислить продолжительность каждого из них. После этого вы
можете сравнить свои данные с результатами, полученными из службы и из
Performance Analyzer, на предмет существенных различий.
Теперь пришло время подвести итоги заключительной главы книги.
Нажатие на кнопку для загрузки встроенного отчета
Загрузка отчета Power BI
Инициализация
Загрузка визуального элемента A

Загрузка визуального
элемента В
Время
Пользовательское Loaded VisualRendered

событие старта (A) Пользовательское
событие финиша
VisualRendered
(В)
Rendered
Рис. 14.3  Хронология событий в пользовательском приложении
В этой главе мы поговорили об оптимизации процесса встраивания содер-
жимого Power BI в сторонние приложения. Мы узнали, что емкости Premium
и Embedded позволяют разработчикам без каких-либо серьезных усилий
внедрять свои отчеты в пользовательские приложения. Это дает возмож-
ность расширить спектр контента приложения за счет аналитических от-
четов Power BI. При этом пользователям не нужно взаимодействовать непо-
средственно с Power BI, доступ к необходимым отчетам у них будет прямо
из приложения. Мы на протяжении всей книги говорили о том, как важно
планировать и оптимизировать емкости, в том числе Embedded, и находя-
щееся в них содержимое.
Также в этой главе мы узнали о том, что процесс встраивания контента
включает в себя коммуникацию между службой Power BI и приложением
посредством вызовов API. Инструментарий емкости Embedded позволяет
разработчикам осуществлять аутентификацию в Power BI, загружать базовый
код приложения и размещать в нем отчеты, дашборды и плитки. Это ведет
к появлению накладных расходов на внедрение, которые могут быть очень
большими в случае существенных задержек в коммуникации между прило-
жением и Power BI. В то же время вы можете и должны проводить оптимиза-
цию содержимого Power BI отдельно от механизмов встраивания. В идеале
вы уже должны были это сделать, чтобы полностью сконцентрироваться на
настройке производительности.
Кроме того, мы поговорили о важности использования последних версий
инструментов при выполнении встраивания контента в приложение с целью
достижения наилучших результатов с точки зрения эффективности. Мы так-

же упомянули о методах API, предоставленных компанией Microsoft, с по-
мощью которых можно осуществить предварительную загрузку необходи-
мых компонентов, включая файлы JavaScript и CSS, для ускорения процесса
внедрения. Сказали мы и о возможности конфигурирования процесса встра-
ивания, что позволяет, например, указать минимальные разрешения для
пользователя и, следовательно, загружать только необходимые компоненты.
После этого мы узнали о том, что встраиваемый контент в приложени-
ях выводится посредством стандартных элементов iFrame. Мы рассказали
о важности использования как можно меньшего количества таких контей-
неров по причине того, что каждый из них использует драгоценные ресур-
сы. В свете этого порекомендовали консолидировать информацию в мень-
шее количество отчетов, а также использовать для встраивания дашборды
и плитки, что позволит снизить время загрузки контента.
Наконец, мы научились измерять производительность механизма встраи-
вания. В процессе были представлены события, возникающие в приложении,
и сказано о необходимости их использования с целью получения полной
картины происходящего. Это позволит определить длительность каждой
конкретной операции и полноценно проанализировать процессы инициа-
лизации отчета, а также отрисовки всех визуальных элементов и каждого из
них по отдельности.
Послесловие
Поздравляем! Наше путешествие в мир оптимизации Power BI подошло к ло-
гическому завершению, и теперь вы должны быть готовы применить все по-
лученные знания и навыки на практике. А завершить хочется напоминанием
о том, что управление производительностью должно стать неотъемлемой
частью каждого процесса в жизненном цикле ваших решений. И наилуч-
ших результатов вы сможете добиться только при планировании и тесном
сотрудничестве со всеми специалистами, способными внести свой вклад
в оптимизацию ваших проектов!
Предметный указатель
A customLayout, 273
AAS, 82, 218
ADLS, 233 D
ADLS Gen2, 233 Data mart, 37
Advanced Scripting, 114 Data warehouse, 37
Apache Spark, 234 DAX, 178
Azure Analysis Services, 82, 218 DAX Studio, 118
Azure Data Lake, 160 DIVIDE(), 205
Azure Data Lake Storage, 233
Azure ExpressRoute, 51
Azure Log Analytics, 81 E
Azure Synapse, 233 ELT, 231
EmbedURL, 271
B ETL, 231
Extract-Load-Transform, 231
Best Practice Analyzer, 113 Extract-Transform-Load, 231
BI-система самообслуживания, 135
BLANK(), 211
bookmarks, 271 F
Bring Your Own Key, 240 FILTER(), 210, 211
filters, 271
C FIND(), 210
CALCULATE(), 190, 210
CALCULATETABLE(), 210 G
Cardinality, 36 GroupKind.Local, 151
CI/CD, 38 GUID, 192
COMBINEVALUES(), 58
Composite model, 38
CONTAINS(), 211
H
COUNT(), 211 Hadoop Distributed File System, 233
COUNTROWS(), 211 HASONEVALUE(), 209
CPUUtilizationPercentageThreshold, 50 Home region, 33
Current User Sessions, 82 Hop, 28, 41
278  Предметный указатель
I Premier Support, 46
Premium на пользователя, 240
iFrame, 271 Premium Capacity Utilization and
INNER JOIN, 57 Metrics, 254
INTERSECT(), 211
ISBLANK(), 211
Q
L QPU, 82
QSO, 218
layoutType, 273
QueryAggregationTimeInMinutes, 45
List, 148
QueryExecutionAggregationReport, 44
List.Buffer(), 148
QueryExecutionAggregationTimeIn
Loaded, 274
Minutes, 44
LoadTestingPowerShellTool, 251
QueryExecutionReport, 44
LOOKUPVALUE(), 196
Query Pool Busy Threads, 83
Query Processing Units, 82
M Query Scale Out, 218
Mashup engine, 27, 40 QueryStartReport, 44
MaxParallelism, 221
MDX, 178 R
Memory, 82
RangeEnd, 152
MemoryUtilizationPercentageThreshold, 50
RangeStart, 152
M Engine Memory, 82
RDL, 177
M Engine QPU, 82
RealisticLoadTestTool, 251
MPP, 231
RELATED(), 100
Remove-OnPremisesDataGateway, 49
N Rendered, 274
Network latency, 28 ReplicaSyncMode, 222
Report Definition Language, 177
ReportFileCount, 44
O ReportFilePath, 44
OUTER JOIN, 57 ReportFileSizeInBytes, 44
ResourceUtilizationAggregationPeriodIn
Minutes, 50
P RLS, 194
P90, 25
Parquet, 231
Partition Manager, 221
S
Path, 195 SEARCH(), 210
PBIE, 82, 84 SELECTEDVALUE(), 209
Performance Analyzer, 86 sequence, 144
Permissions, 271 SKU, 249
ping, 28 Slicers, 271
powerbi.bootstrap, 271 SMP, 230
powerbi.embed, 271 Spark Jobs, 234
Power BI Embedded, 82, 84 SQL Server Management Studio, 221
Power BI Helper, 110 SQL Server Profiler, 120
powerbi.preload, 270 SQL Server Reporting Services, 177
Power BI Report Builder, 178 Storage mode, 32
Power BI service, 29 SUMMARIZE(), 210
Power Query, 142 SUMMARIZECOLUMNS(), 210
Power Query Online, 161 Synapse Studio, 233
Предметный указатель  279
SystemCounterAggregationReport, 45 Вертикальное масштабирование, 48

SystemCounterAggregationTimeIn Визуальные элементы, 167
Minutes, 44 Виртуальная машина, 41, 98
Виртуальное ядро, 240, 247
T Витрина данных, 37
Внешние инструменты, 109
Table, 148 Внешний ключ, 57
Table.Buffer(), 148 Всплывающая подсказка, 174
Table.Group(), 151 Встраивание, 268
Tabular Editor, 113 Выделенный пул, 234
Tabular Model Scripting Language, 221 Вычисляемая сущность, 164
Throttling, 245 Вычисляемый столбец, 58
TREATAS(), 211
Г
U
Гибридная архитектура хранилища
Unified Support, 46 данных, 232
Глобальный уникальный
V идентификатор, 59, 192
Горизонтальное масштабирование
VALUES(), 209
запросов, 218
VAR, 204
V-core, 240
VertiPaq, 34, 118 Д
VertiPaq Analyzer, 118 Дашборд, 176
View Metrics, 118 Движок обработки, 27, 40
VisualRendered, 274 Движок обработки Power Query, 143
visualRenderedEvents, 274
Движок формул, 30, 122
Visual Studio, 221
Движок хранилища, 30, 122
Двунаправленная связь, 59, 112, 193
X Денормализация, 185
xVelocity, 34 Денормализованная таблица, 185
Дерево декомпозиции, 157
Диагностика запроса, 154
А Динамические административные
Автомасштабирование, 246 представления, 118
Автоматические агрегаты, 230 Динамический RLS, 194
Автоматическое обновление страниц, 43 Добавочное обновление, 152
Агрегат, 226 Домашний регион, 33
Агрегатная таблица, 226
Анализатор производительности, 86 Е
Единица
Б обработки запросов, 82
Базовая мера, 112 хранения, 249
Безопасность на уровне строк, 194 Единственный источник истины, 37
Бессерверный пул, 233 Емкость Premium, 217
Большие данные, 231
Брандмауэр, 41 Ж
Журнал
В аудита, 80
Ведение логов, 43 действий, 80
280  Предметный указатель
З Н
Зависимости в мерах, 112 Направление кросс-фильтрации, 59
Загрузка фоновых данных, 145 Неиспользуемое поле, 111
Закрепление, 176 Нормализация, 183
И О
Иерархия типа родитель–потомок, 195 Облачная реплика, 51
Измерение, 56, 184 Общая емкость, 216
Имя участника-пользователя, 72 Общие наборы данных, 27
Индекс, 57 Ограничение, 57
Интерактивный отчет, 167 Ограниченные связи, 225
Интернет вещей, 215, 231 Озеро данных, 232
Интерфейсные ядра, 243 Оптимизация запросов DAX, 202
Отчет с разбивкой на страницы, 167, 177
К
Карточка, 170
П
Классическая рабочая область, 66 Параметризация, 179
Кодирование Параметры запросов, 145
на основе длин серий, 193 Первичный ключ, 57
на основе значений, 193 Перегрузка, 245
со словарем, 193 Перекрестное произведение, 197
Колоночное хранилище, 34 Платформа как услуга, 218, 266
Конвейер, 232 Подсказки, 151
Конечная точка XMLA, 81, 144 Пользовательские оповещения, 253
Контейнер вычисления, 143 Портал AppSource, 254
Контекст строки, 100 Поток данных, 160
Контрольные ожидаемые Приемлемое время ожидания, 24
показатели, 130 Процентиль, 25
Кратность, 36, 59, 191 Процессорное время, 243
Процессорные секунды, 243
Прыжки, 28
Л Прыжок, 41
Локальный шлюз данных, 39 Пул Spark, 234
М Р
Максимальное состояние процессора, 96 Рабочая область второй версии, 66
Массово-параллельная обработка, 231 Размерная модель, 184
Масштабирование, 48 Размерное моделирование, 164, 183
Материализованное представление, 63 Ранжирующие функции, 173
Мера области запроса, 123 Распорядитель данных, 137
Метрики использования, 66 Распределение ресурсов, 43
Многострочная карточка, 170 Расширенное ядро вычислений, 162, 239
Моделирование данных, 54 Расширенный редактор, 146
Модель Редактор Power Query, 54
данных, 54 Режим
лицензирования, 249 ограничения количества запросов, 245
с активным источником данных, 136 отсрочки, 245
с пассивным источником данных, 135 отсрочки интерактивных запросов, 245
Мощность, 191 синхронизации, 222
Мусорное измерение, 197 хранения, 32
Предметный указатель  281
DirectQuery, 27, 36 Транзитные участки, 28

Import, 26, 33
LiveConnect, 38
Live connection, 27
У
Реплика Узел, 231
данных, 219 Универсальный уникальный
для чтения, 63 идентификатор, 59
Ролевое измерение, 185 Управление производительностью, 128
Уровень конфиденциальности, 147
С
Свертывание запросов, 149 Ф
Связь «один ко многим», 59 Фильтрация, 179
Сегмент, 193, 221 Фильтр Ведущие N, 172
Секционирование, 220 Формат хранения крупных наборов
Секционированные таблицы, 220 данных, 217
Серверные ядра, 243 Функции буферизации, 148
Сетевая задержка, 28
Симметричная многопроцессорная
обработка, 230 Х
Системный счетчик, 43 Хинты запросов, 151
Скрипт TMSL, 144 Хранилище данных, 37
Служба Хранимая процедура, 178
отчетности SQL Server, 177
Power BI, 29
Смешанный режим, 223 Ц
Составная модель, 38, 223 Целевые метрики, 25
Срез, 88 Целевые показатели
Ссылочная целостность, 57 производительности, 23
Суверенность данных, 37, 240 Цикл вычисления, 243
Суррогатный ключ, 192
Схема «звезда», 184
Ш
Т Шлюз, 27
Таблица, 170
безопасности, 194 Э
отслеживания, 221 Эксклюзивная длительность, 157
фактов, 184
Таблица-мост, 189
Табличная объектная модель, 221
Я
Токены внедрения, 268 Язык M, 142
Книги издательства «ДМК ПРЕСС»
можно купить оптом и в розницу
в книготорговой компании «Галактика»
(представляет интересы издательств
«ДМК ПРЕСС», «СОЛОН ПРЕСС», «КТК Галактика»).
Адрес: г. Москва, пр. Андропова, 38, оф. 10;
тел.: (499) 782-38-89, электронная почта: books@alians-kniga.ru.
При оформлении заказа следует указать адрес (полностью),
по которому должны быть высланы книги;
фамилию, имя и отчество получателя.
Желательно также указать свой телефон и электронный адрес.
Эти книги вы можете заказать и в интернет-магазине: http://www.galaktika-dmk.com/.
Power BI: передовые методы оптимизации
Главный редактор Мовчан Д. А.

dmkpress@gmail.com
Зам. главного редактора Сенченкова Е. А.
Перевод Гинько А. Ю.
Корректор Синяева Г. И.
Верстка Чаннова А. А.
Дизайн обложки Мовчан А. Г.
Гарнитура PT Serif. Печать цифровая.

Усл. печ. л. 22,91. Тираж 200 экз.
Веб-сайт издательства: www.dmkpress.com

Мерчант - Power BI. Передовые Методы Оптимизации - 2023

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Мерчант - Power BI. Передовые Методы Оптимизации - 2023

Загружено:

Авторское право:

Доступные форматы

Бхавик Мерчант

ISBN 978-1-80107-644-9 (англ.) © 2022 Packt Publishing

Также я хотел бы сказать спасибо всем коллегам во времена рабо-

Часть I. АРХИТЕКТ УРА, УЗКИЕ МЕСТА И ЦЕЛЕВЫЕ

Глава 2. Обзор архитектуры и конфигурации Power BI....................32

Когда лучше подойдет режим DirectQuery?........................................................36

Глава 3. Оптимизация DirectQuery. .............................................................53

Часть II. АНАЛИЗ, УЛУЧШЕНИЕ И УПРАВЛЕНИЕ

Интеграция с Azure Log Analytics.........................................................................81

Глава 5. Анализатор производительности...............................................86

Глава 6. Внешние инструменты...................................................................109

Глава 7. Общие принципы управления производительностью.....128

Мониторинг и хранение истории..................................................................132

Часть III. ИЗВЛЕЧЕНИЕ, ПРЕОБРАЗОВАНИЕ

Глава 9. Разработка отчетов и дашбордов. ..........................................166

Проверяйте на производительность пользовательские визуальные

Часть IV. МОДЕЛИ ДАННЫХ, ВЫЧИСЛЕНИЯ И РАБОТА

Глава 11. Улучшаем DAX.................................................................................201

Глава 12. Шаблоны работы с большими данными...........................215

Использование Po­wer BI Premium для масштабирования данных...............216

Часть V. ОПТИМИЗАЦИЯ ЕМКОСТЕЙ PREMIUM

Глава 14. Встраивание в приложения......................................................268

Предметный указатель. ..................................................................................277

Нарушение авторских прав

Спросите любого, кто когда-либо присутствовал на конференции, посвящен-

Бхавик Мерчант (Bhavik Merchant) обладает 18-летним опытом работы в об-

Суреш Датла (Suresh Datla) работает в IT-индустрии более 20 лет и обладает

Вишванат Музумдар (Vishwanath Muzumdar) имеет более чем 8-летний

Начать выстраивать аналитические решения с помощью Po­wer BI очень не-

Для кого эта книга

Глава 7 «Общие принципы управления производительностью». В этой

этом одного и того же результата можно добиться с применением разных

Как извлечь максимум из книги

Новые термины, важные слова и текст, который вы видите на экране, будут

Важные примечания будут выводиться так.

Советы будут выводиться так.

Примечания будут выводиться так.

В этой вводной части мы дадим высокоуровневый обзор архитектуры Po­

При анализе производительности аналитических решений многие считают

мацией. Мы посмотрим, как данные могут храниться в Po­wer BI и какой путь

Определение уровня производительности

Показатели производительности отчетов

чивается одним лишь их формированием – пользователи с ними активно

Установка реалистичных целевых показателей

пользователя или используемого им браузера), стоит рассматривать целе-

Обычный отчет Сложный отчет

Целевая метрика P90 Меньше 10 секунд Меньше 25 секунд

Рис. 1.1  Пример целевых метрик для отчетов в Po­wer BI

Теперь взглянем на Po­wer BI в целом, чтобы лучше понимать, в каких

Области с возможными замедлениями

Облачные источники данных

Дашборды Отчеты Служба

Рис. 1.2  Решение на базе Po­wer BI в упрощенном виде

Подключение к источникам данных

Облачные источники данных

Дашборды Отчеты Служба

Группа Analysis Services

Рис. 1.3  Области, чувствительные к проблемам

обновления данных и даже приводить к отказам. В службе Po­wer BI принято

Режим Live connection

Облачные источники данных

Дашборды Отчеты Служба

Группа Analysis Services

Рис. 1.4  Шлюз Po­wer BI

ISBN 978-1-80107-644-9 (англ.) © 2022 Packt Publishing

Использование Power BI Premium для масштабирования данных...............216

Начать выстраивать аналитические решения с помощью Power BI очень не-

В этой вводной части мы дадим высокоуровневый обзор архитектуры Po

мацией. Мы посмотрим, как данные могут храниться в Power BI и какой путь

Рис. 1.1  Пример целевых метрик для отчетов в Power BI

Теперь взглянем на Power BI в целом, чтобы лучше понимать, в каких

Рис. 1.2  Решение на базе Power BI в упрощенном виде

обновления данных и даже приводить к отказам. В службе Power BI принято

Рис. 1.4  Шлюз Power BI

Рис. 1.6  Служба Power BI

Основным компонентом службы Power BI, которым вы можете управлять,

лонов разработки. Выбор, сделанный в этих областях, может оказывать су

решения на базе Power BI. Здесь присутствуют варианты, которые мы обсуж-

Не все коннекторы в Power BI поддерживают режим DirectQuery. Некоторые из них

не обязательно должен находиться близко к домашнему региону Power BI.

Все запросы изначально поступают на основной экземпляр шлюза в клас

CPUUtilizationPercentageThreshold: значение в интервале от 0 до 100,

по возможности совмещайте размещение источников данных, шлюзов