Power BI: передовые методы оптимизации 9785937001689, 9781801076449

Table of contents :
Содержание
От издательства
Предисловие
Об авторе
О редакторах
Введение
Для кого эта книга
Структура книги
Как извлечь максимум из книги
Сопроводительные файлы
Цветные изображения
Условные обозначения
Часть I. Архитектура, узкие места и целевые показатели производительности
Глава 1. Постановка целей и определение проблемных областей
Определение уровня производительности
Показатели производительности отчетов
Установка реалистичных целевых показателей производительности
Области с возможными замедлениями
Подключение к источникам данных
Режим Import
Режим DirectQuery
Режим Live connection
Шлюз Power BI
Сетевая задержка
Служба Power BI
Решения, влияющие на производительность
Заключение
Глава 2. Обзор архитектуры и конфигурации Power BI
Средства подключения к источникам и режимы хранения данных
Выбор между режимами Import и DirectQuery
Когда лучше подойдет режим DirectQuery?
Составные модели
Режим LiveConnect
Извлечение локальных данных с помощью шлюза
Как работает шлюз
Предпосылки для оптимальной работы шлюза
Технические характеристики шлюза
Настройка ведения логов в шлюзе
Анализ и моделирование логов шлюза
Анализ логов шлюза
Масштабирование шлюза
Горизонтальное масштабирование с увеличением количества шлюзов
Общая инструкция по архитектуре
Планирование расписания обновлений
Снижение сетевой задержки
Заключение
Глава 3. Оптимизация DirectQuery
Моделирование данных для режима DirectQuery
Оптимизация связей для DirectQuery
Настройки быстродействия режима DirectQuery
Настройки Power BI Desktop
Оптимизация внешних источников данных
Заключение
Часть II. Анализ, улучшение и управление производительностью
Глава 4. Анализ логов и метрик
Метрики использования в Power BI
Доработка отчета о метриках использования
Фильтрация метрик использования
Доступ к сырым данным посредством создания редактируемой копии метрик использования
Доступ к сырым данным посредством создания собственного отчета о метриках использования
Доступ к сырым данным с помощью анализа метрик использования в Excel
Анализ детализированной информации о производительности
Анализ метрик отчета о производительности
Получение показателей производительности из нескольких рабочих областей
Логи Power BI и трассировка
Журнал действий и единый журнал аудита
Трассировка Analysis Services с помощью конечных точек XMLA
Интеграция с Azure Log Analytics
Отслеживание показателей в Azure Analysis Services и Power BI Embedded
Метрики Azure для AAS
Диагностика в Azure для Analysis Services
Метрики Azure и диагностика для PBIE
Заключение
Материалы к прочтению
Глава 5. Анализатор производительности
Технические требования
Обзор Анализатора производительности
Действия и метрики в Анализаторе производительности
Определение действий пользователя
Определение и устранение проблем с производительностью
Единообразие тестов
Возможности и ограничения Анализатора производительности
Интерпретация и выводы о данных от Анализатора производительности
Медленные запросы
Медленные визуальные элементы
Эффект от добавления новых визуальных элементов
Экспорт и анализ данных о производительности
Заключение
Глава 6. Внешние инструменты
Технические требования
Power BI Helper
Поиск столбцов, занимающих много места
Поиск неиспользуемых столбцов
Поиск двунаправленных и неактивных связей
Поиск зависимостей в мерах
Tabular Editor
Использование утилиты Best Practice Analyzer
DAX Studio и VertiPaq Analyzer
Анализ размера модели данных при помощи VertiPaq Analyzer
Настройка производительности модели данных и запросов DAX
Перехват и повторный запуск запросов
Получение информации о времени выполнения запросов
Изменение и настройка запросов
Заключение
Глава 7. Общие принципы управления производительностью
Налаживание воспроизводимого и упреждающего процесса повышения производительности
Цикл управления производительностью
Установка/обновление контрольных целевых показателей
Мониторинг и хранение истории
Обнаружение проблем и расстановка приоритетов
Диагностирование и исправление
Принятие превентивных мер
Обмен опытом и знаниями
Помощь конечным пользователям
Инструкция для разработчиков
Совместный подход к повышению производительности
Применение цикла управления производительностью в разных сценариях
BI-системы самообслуживания
BI-системы на основе отдела или команды
Корпоративные или управляемые ИТ-отделами BI-системы
Заключение
Часть III. Извлечение, преобразование и визуализация данных
Глава 8. Загрузка, преобразование и обновление данных
Технические требования
Основные принципы преобразования данных
Обновление данных, параллелизм и использование ресурсов
Улучшение среды разработки
Свертывание запросов, объединение и агрегация
Использование добавочного обновления
Использование диагностики запросов
Сбор диагностической информации в Power Query
Анализ логов Power Query
Оптимизация потоков данных
Заключение
Глава 9. Разработка отчетов и дашбордов
Технические требования
Оптимизация интерактивных отчетов
Управление визуальными элементами и запросами
Установите выбор по умолчанию в срезах/фильтрах для первой загрузки
Избегайте вывода подробных таблиц со множеством столбцов в базовом отчете
Объединяйте индивидуальные карточки в многострочные или в таблицы
Используйте фильтр Ведущие N для ограничения данных в отчете
Переместите редко используемые срезы на панель фильтров
Исключите ненужные взаимодействия пользователя с отчетом
Используйте всплывающие подсказки для снижения объема и сложности запросов
Проверяйте на производительность пользовательские визуальные элементы и отдавайте предпочтение сертифицированным элементам
Используйте технику сокращения числа запросов для сложных отчетов
Оптимизация дашбордов
Оптимизация отчетов с разбивкой на страницы
Заключение
Часть IV. Модели данных, вычисления и работа с объемными наборами
Глава 10. Моделирование данных и безопасность на уровне строк
Технические требования
Построение эффективных моделей данных
Теория Кимбалла и реализация схемы «звезда»
Разработка схемы «звезда»
Работа со связями типа «многие ко многим»
Уменьшение размера набора данных
Ловушки при использовании безопасности на уровне строк
Заключение
Глава 11. Улучшаем DAX
Технические требования
Ловушки DAX и способы оптимизации
Процесс отладки выражений DAX
Руководство по оптимизации в DAX
Используйте переменные вместо повторения определений мер
Используйте функцию DIVIDE вместо оператора деления
Избегайте преобразования пустых значений в ноль или какого-то текста при вычислении числовых мер
Используйте функцию SELECTEDVALUE вместо VALUES
Используйте функции IFERROR и ISERROR уместно
Используйте функцию SUMMARIZE только с текстовыми столбцами
Избегайте использования функции FILTER при передаче фильтрующих условий
Используйте функцию COUNTROWS вместо COUNT
Используйте функцию ISBLANK вместо BLANK
Оптимизируйте виртуальные связи при помощи функции TREATAS
Заключение
Глава 12. Шаблоны работы с большими данными
Технические требования
Масштабирование при помощи Power BI Premium и Azure Analysis Services
Использование Power BI Premium для масштабирования данных
Использование Azure Analysis Services для масштабирования данных и пользователей
Использование горизонтального масштабирования запросов для увеличения количества пользователей
Использование секционирования с AAS и Premium
Масштабирование с использованием составных моделей и агрегатов
Составные модели данных
Использование агрегатов
Масштабирование с Azure Synapse и Azure Data Lake
Современная архитектура хранилища данных
Azure Data Lake Storage
Azure Synapse Analytics
Заключение
Материалы для чтения
Часть V. Оптимизация емкостей Premium и Embedded
Глава 13. Оптимизация емкостей Premium и Embedded
Возможности Premium, использование ресурсов и автомасштабирование
Поведение емкостей Premium и использование ресурсов
Как оценивается нагрузка на емкость?
Перегрузка емкости и автомасштабирование
Управление пиковыми нагрузками при помощи автомасштабирования
Планирование емкости, мониторинг и оптимизация
Определение исходного размера емкости
Проверка емкости с помощью нагрузочного тестирования
Мониторинг использования ресурсов емкости и перегрузки
Исследование перегрузки
Заключение
Глава 14. Встраивание в приложения
Повышение производительности внедрения
Измерение производительности внедрения
Заключение
Послесловие
Предметный указатель

Citation preview

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 (англ.) ISBN 978-5-93700-168-9 (рус.)

© 2022 Packt Publishing © Перевод, оформление, издание, ДМК Пресс, 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 Шлюз Po­wer BI.........................................................................................................27 Сетевая задержка....................................................................................................28 Служба Po­wer 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 Настройки Po­wer BI Desktop. ................................................................................60 Оптимизация внешних источников данных......................................................62 Заключение..................................................................................................................64

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

8    Содержание Интеграция с Azure Log Analytics.........................................................................81 Отслеживание показателей в Azure Analysis Services и Po­wer 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 Po­wer 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

Содержание    9

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

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

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

10    Содержание Проверяйте на производительность пользовательские визуальные элементы и отдавайте предпочтение сертифицированным элементам. ........................................................................................................175 Используйте технику сокращения числа запросов для сложных отчетов...............................................................................................................176 Оптимизация дашбордов........................................................................................176 Оптимизация отчетов с разбивкой на страницы................................................177 Заключение................................................................................................................179

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

Глава 11. Улучшаем DAX.................................................................................201 Технические требования. ........................................................................................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 Технические требования. ........................................................................................216 Масштабирование при помощи Po­wer BI Premium и Azure Analysis Services. ....216

Содержание    11

Использование Po­wer 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/ или напишите в  издательство по адресу [email protected].

Список опечаток Хотя мы приняли все возможные меры для того, чтобы обеспечить высокое качество наших текстов, ошибки все равно случаются. Если вы найдете ошибку в одной из наших книг, мы будем очень благодарны, если вы сообщите о ней главному редактору по адресу [email protected]. Сделав это, вы избавите других читателей от недопонимания и поможете нам улучшить последующие издания этой книги.

Нарушение авторских прав Пиратство в интернете по-прежнему остается насущной проблемой. Издательство «ДМК Пресс» очень серьезно относится к вопросам защиты авторских прав и лицензирования. Если вы столкнетесь в интернете с незаконной публикацией какой-либо из наших книг, пожалуйста, пришлите нам ссылку на интернет-ресурс, чтобы мы могли применить санкции. Ссылку на подозрительные материалы можно прислать по адресу элект­ ронной почты [email protected]. Мы высоко ценим любую помощь по защите наших авторов, благодаря которой мы можем предоставлять вам качественные материалы.

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

Об авторе Бхавик Мерчант (Bhavik Merchant) обладает 18-летним опытом работы в области бизнес-аналитики и занимает пост руководителя отдела продуктовой аналитики в Salesforce. До этого работал в Microsoft сначала в роли архитектора облачных решений, а затем в статусе продуктового менеджера в проектной группе Po­wer  BI. В  отделе Po­wer  BI Бхавик возглавлял программу клиентских исследований, отвечая за стратегию и  техническую структуру предоставления клиентам информации о производительности системы. До Microsoft много лет работал консультантом BI-систем в отделе корпоративных клиентов. Проводил технические и теоретические тренинги в области повышения эффективности Po­wer BI для партнеров Microsoft по всему миру.

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

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

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

Структура книги    17

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

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

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

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

Как извлечь максимум из книги К некоторым главам этой книги прилагаются файлы с примерами, которые можно открыть с помощью Po­wer BI Desktop. Это поможет вам лучше понять описываемые концепции и  приемы. В  основном в  примерах показаны ситуации до и после внесенных изменений. Вам не обязательно проверять все представленные теории на примерах, но они действительно могут помочь в их освоении. Программное обеспечение, использованное при написании книги: ОС Win­ dows, Po­wer BI Desktop, DAX Studio 2.17.3, Tabular Editor 3, Po­wer BI Helper 12.0. Мы советуем вам всегда работать с самой свежей версией Po­wer BI Desktop, следуя их ежемесячным обновлениям. Если вы читаете электронную версию книги, мы советуем вам вводить код самостоятельно или копировать его из репозитория книги на GitHub (ссылка

20    Введение будет дана в  следующем разделе). Это поможет вам избежать ошибок при копировании скриптов из книги.

Сопроводительные файлы Файлы с  примерами можно загрузить из репозитория книги на GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-BestPractices. Все возможные обновления будут появляться там же. Также вы можете загрузить текущую версию файлов с сайта издательства по адресу 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 «Обзор архитектуры и конфигурации Po­wer BI»;   глава 3 «Оптимизация DirectQuery».

Глава

1 Постановка целей и определение проблемных областей

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

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

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

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

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

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

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

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

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

Целевая метрика P90

Обычный отчет

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

Меньше 10 секунд

Меньше 25 секунд

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

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

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

26    Постановка целей и определение проблемных областей

Облачные источники данных Azure Analysis Services, SQL Azure и т. д. Обновление по расписанию / Динамическое подключение / DirectQuery

Конечные пользователи Дашборды

Power BI Desktop

Отчеты

Analysis Services (на базе Power BI)

Группа OneDrive

Обновление по расписанию / Динамическое подключение / DirectQuery

Шлюз

Локальные источники данных Analysis Services, SQL Server и т. д.

Служба Power BI

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

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

Облачные источники данных Azure Analysis Services, SQL Azure и т. д. Обновление по расписанию / Динамическое подключение / DirectQuery

Конечные пользователи Дашборды

Power BI Desktop

Служба Power BI

Analysis Services (на базе Power BI)

Группа OneDrive

Локальные источники данных Analysis Services, SQL Server и т. д.

Отчеты

Шлюз

Обновление по расписанию / Динамическое подключение / DirectQuery

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

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

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

обновления данных и даже приводить к отказам. В службе Po­wer BI принято ограничение на обновление данных, равное двум часам, тогда как при наличии лицензии Po­wer BI Premium это ограничение увеличивается до пяти часов. При превышении этих лимитов любое обновление будет отменено системой.

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

Режим Live connection Изначально режим Live connection относился исключительно к подключениям к внешним ресурсам Analysis Services, которые могли быть как облачными (Azure Analysis Services), так и  локальными (SQL Server Analysis Services). Позже, с появлением общих наборов данных (shared datasets) и возможности строить отчеты в Po­wer BI Desktop на основании опубликованных наборов данных в службе Po­wer BI, этот режим был расширен. Поскольку исходные наборы данных могут быть как в режиме Import, так и в режиме DirectQuery, опыт работы с ними может отличаться, как описано в предыдущих разделах.

Шлюз Po­wer BI Шлюз (gateway) Po­wer BI – это промежуточный компонент, использующийся для подключения к внешним источникам данных. Обычно он располагается в той же физической или виртуальной сети и обеспечивает безопасное исходящее соединение с Po­wer BI, по которому могут передаваться данные для отчетов и обновлений. Но функции шлюза не ограничиваются передачей данных – это распространенное и очень большое заблуждение. Помимо обеспечения защищенного соединения с  источниками данных, шлюз содержит свой движок обработки (mashup engine), выполняющий преобразование исходных данных и их сжатие перед отправкой в службу Po­wer BI. При отсутствии оптимизации шлюза могут возникать задержки с  обновлением данных вплоть до сбоев, замедление взаимодействий пользователей с  отчетами и  отказы загрузки визуальных элементов из-за превышения времени выполнения запросов.

28    Постановка целей и определение проблемных областей

Облачные источники данных Azure Analysis Services, SQL Azure и т. д. Обновление по расписанию / Динамическое подключение / DirectQuery

Конечные пользователи Дашборды

Power BI Desktop

Служба Power BI

Analysis Services (на базе Power BI)

Группа OneDrive

Обновление по расписанию / Динамическое подключение / DirectQuery

Шлюз

Локальные источники данных Analysis Services, SQL Server и т. д.

Отчеты

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

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

Облачные источники данных Azure Analysis Services, SQL Azure и т. д. Обновление по расписанию / Динамическое подключение / DirectQuery

Конечные пользователи Дашборды

Power BI Desktop

Служба Power BI

Analysis Services (на базе Power BI)

Группа OneDrive

Локальные источники данных Analysis Services, SQL Server и т. д.

Отчеты

Шлюз

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

Обновление по расписанию / Динамическое подключение / DirectQuery

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

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

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

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

Power BI Desktop

Отчеты

Служба Power BI

Analysis Services (на базе Power BI)

Группа OneDrive

Локальные источники данных Analysis Services, SQL Server и т. д.

Конечные пользователи

Шлюз

Обновление по расписанию / Динамическое подключение / DirectQuery

Рис. 1.6    Служба Po­wer BI

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

30    Постановка целей и определение проблемных областей лонов разработки. Выбор, сделанный в этих областях, может оказывать су­ щественное влияние на производительность.

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

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

Заключение    31

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

Глава

2

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

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

Средства подключения к источникам и режимы хранения данных    33

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

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

Рис. 2.1    Опции подключения к SQL Server

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

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

34    Обзор архитектуры и конфигурации Power BI не обязательно должен находиться близко к домашнему региону Po­wer  BI. И если это не так, то данным придется преодолевать определенный путь до отчетов в Po­wer BI. Кроме того, в зависимости от того, как настроена модель данных в DirectQuery, движку Analysis Services может понадобиться выполнять весьма дорогостоящую обработку данных для каждого взаимодействия пользователя с отчетом или аналитического запроса.

Рис. 2.2    При подключении к Excel отсутствует выбор между режимами Import и DirectQuery

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

Средства подключения к источникам и режимы хранения данных    35

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

Рис. 2.3    Сравнение строчного и колоночного хранения информации

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

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

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

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

Давайте перечислим сценарии, в  которых вы могли бы остановить свой выбор на режиме DirectQuery:   огромный объем исходных данных: размер набора данных, публикуемого в  рабочей области в  рамках емкости Po­wer  BI Premium, не

Средства подключения к источникам и режимы хранения данных    37

может превышать 10 Гб. В общей емкости размер ограничен 1 Гб. Эти ограничения относятся к файлу Po­wer BI Desktop (.pbix), публикуемому в службе Po­wer BI, хотя наборы данных Premium зачастую сильно превосходят по объему заявленные лимиты. Если это ваш случай, вы не сможете разместить все свои данные в службе и регулярно их обновлять. У режима DirectQuery тоже есть свое ограничение, выражающееся в 1 млн строк на запрос. Но вам не стоит сильно беспокоиться по этому поводу, поскольку трудно представить, зачем вам мог бы понадобиться столь огромный набор неагрегированных данных в отчете;   доступ к  источнику в  реальном времени: если ваша бизнес-задача предусматривает получение актуальных данных в каждом запросе, единственным вариантом для вас будет DirectQuery;   большие инвестиции в  существующие платформы данных: бывает, что компания осуществляет существенные вложения в  инфраструктуру, например в хранилища данных (data warehouse) или витрины данных (data mart) с  централизованной базой данных. Информация в  таких системах может быть очищена и  идеально оптимизирована для получения аналитических отчетов, а сами системы используются в компании в качестве единственного источника истины (single source of truth). К  таким источникам зачастую обращаются за данными из разных аналитических инструментов, и ожидается, что во всех будет одинаковая актуальная информация. В подобных условиях лучше использовать режим DirectQuery, чтобы не оперировать устаревшей информацией в наборах данных Po­wer BI;   регулирующие и нормативные требования: в отношении географического места хранения информации могут применяться определенные законы и положения в компании. Обычно в этом случае применяется термин суверенность данных (data sovereignty). Если по причине этих требований вы не можете физически переместить данные в Po­ wer BI, остается использовать для доступа к ним режим DirectQuery. Как и в случае с режимом Import, режим DirectQuery также можно определенным образом оптимизировать, о чем мы подробно поговорим в главе 3. Теперь, когда вы узнали все преимущества и недостатки обоих режимов, полезно будет объединить вместе вопросы, ответами на которые необходимо руководствоваться при выборе:   какой у вас объем данных и как он предположительно будет расти?   насколько эффективно можно сжать ваши данные в источнике?   достаточно ли будет перейти на лицензию Premium, чтобы разместить в режиме Import все нужные данные?   можно ли удовлетвориться внедрением смешанной архитектуры? О составных моделях читайте далее.

Составные модели Po­wer BI не ограничивает вас выбором единственного режима (Import или DirectQuery) для одного набора данных или файла .pbix. Вместо этого до-

38    Обзор архитектуры и конфигурации Power BI пустимо сочетать одну или несколько таблиц в режиме Import с одной или несколькими таблицами в режиме DirectQuery. Такой совмещенный подход получил название составная модель (composite model). При выборе составной модели таблицы, хранящиеся в режиме Import и DirectQuery, могут быть оптимизированы так же точно, как и при использовании одного из этих режимов. В то же время при совместном использовании с агрегатами, о которых мы подробно поговорим в  главе 10, составная модель позволит вам найти нужный баланс между быстродействием отчетов, актуальностью информации, размером набора данных и временем его обновления.

Режим LiveConnect В режиме LiveConnect отчет будет отправлять запросы по требованию к внешнему набору данных Analysis Services. В этом отношении он похож на режим DirectQuery, поскольку Po­wer BI не хранит информацию в локальном наборе данных. Отличие состоит в том, что режим LiveConnect можно использовать только при работе с Analysis Services. При этом нельзя производить моделирование данных и добавлять вычисления DAX. Отчет Po­wer BI будет посылать нативные запросы DAX к внешнему источнику данных. Режим LiveConnect можно использовать в приведенных ниже сценариях:   создание отчетов из наборов данных, доступных в  рабочей области Po­wer BI, в Po­wer BI Desktop или Po­wer BI Web;   ваша компания инвестировала средства в Azure Analysis Services или SQL Server Analysis Services и использует этот источник в качестве основного для отчетов Po­wer  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

Локальный SQL Server Analysis Services

Конечные пользователи

Analysis Services (на базе Power BI)

Служба Power BI

Шлюз

Рис. 2.4    Сценарий LiveConnect

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

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

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

Как работает шлюз Зачастую под шлюзом ошибочно понимают исключительно сетевой компонент, используемый для канализирования данных. И хотя он действительно является составной частью конвейера данных, его функции не ограничиваются только передачей информации. Шлюз содержит движок обработки (Mashup Engine) данных и  поддерживает режимы Import, DirectQuery и LiveConnect. Служба шлюза должна быть установлена на физическом или виртуальном сервере. Важно понимать, что шлюз запускает запросы Power Query/M при необходимости, выполняя обработку локально на своей машине. В дополнение шлюз также сжимает, а затем шифрует потоки данных, направляемые службе Po­wer BI. Это позволяет минимизировать объем данных, пересылаемых в  облако, что положительно сказывается на времени обновления и  выполнения запросов. Вместе с  тем такой широкий спектр поддерживаемых подключений и  объем выполняемых задач предполагает выделение приличных ресурсов с возможностью масштабирования для машин, на которых запущен шлюз.

Облачные службы Power BI

Power Apps

Microsoft Flow

Azure Analysis Services

Azure Logic apps

Локальный шлюз (преобразовывает, сжимает и шифрует потоки данных, передаваемые в облако Microsoft) Локальные источники данных

Рис. 2.5    Шлюз выполняет обработку данных локально

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

Извлечение локальных данных с помощью шлюза    41









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

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

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

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

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

Извлечение локальных данных с помощью шлюза    43

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

Настройка ведения логов в шлюзе В локальном шлюзе опция ведения логов включена по умолчанию. При этом в системе ведется два типа логов: по выполнению запросов и по системным счетчикам (system counter). Каждый из этих логов может быть деактивирован при помощи соответствующего свойства value в конфигурационном файле шлюза. Ниже показаны установки для ведения логов по умолчанию:

False

False

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

Извлечение локальных данных с помощью шлюза    45

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

Анализ и моделирование логов шлюза Компания Microsoft предоставляет базовый шаблон отчета Po­wer BI для анализа служебных данных от шлюза. Загрузить этот шаблон можно по адресу https://download.microsoft.com/download/D/A/1/DA1FDDB8-6DA8-4F50-B4D018019591E182/GatewayPerformanceMonitoring.pbit. При открытии файла он сканирует папку с логами шлюза и обрабатывает все файлы с нужными именами. В результате анализа создается модель данных, показанная на рис. 2.6.

Рис. 2.6    Модель данных из шаблона Gateway Performance от Microsoft

46    Обзор архитектуры и конфигурации Power BI На рис.  2.7 показан один из базовых наборов визуальных элементов из этого шаблона.

Рис. 2.7    Пример визуализации в шаблоне Gateway Performance

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

Извлечение локальных данных с помощью шлюза    47

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

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

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

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

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

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

Извлечение локальных данных с помощью шлюза    49

Рис. 2.8    Добавление шлюза к кластеру путем выбора основного экземпляра

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

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

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

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

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

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

Заключение    51

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

Заключение Из этой главы вы узнали, как работают два режима хранения данных в Po­ wer  BI. Наборы данных в  режиме Import полностью кешируются в  памяти, тогда как режим DirectQuery позволяет оставить данные физически на стороне источника и  подключаться к  ним при каждом выполнении запросов. В целом режим Import является более быстрым, поскольку данные фактически извлекаются из локальной колоночной базы данных, в которой к тому же реализовано сжатие. В то же время режим DirectQuery гарантирует получение актуальной информации из источника и  не предусматривает наличия операций обновления данных. К  тому же при использовании этого режима вы можете работать с данными гораздо большего объема по сравнению с ограничениями, имеющимися в лицензии Po­wer BI Premium. Таким образом, у каждого из двух режимов есть свои преимущества и недостатки. В дополнение к режимам Import и DirectQuery в Po­wer BI реализована также составная модель, сочетающая в себе плюсы обоих режимов. Кроме того, в этой главе мы поговорили о шлюзах, позволяющих Po­wer BI безопасно подключаться к локальным источникам данных. При этом шлюз используется не просто как путепровод для информации, а содержит движок обработки, позволяющий локально выполнить необходимые преобразования данных. Эта операция может потребовать больших ресурсов, особенно если с системой одновременно работают сотни или тысячи пользователей, что порождает огромное количество параллельных подключений. Все это ведет к необходимости тщательно мониторить работу шлюза, поддерживать

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

Глава

3 Оптимизация DirectQuery

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

54    Оптимизация DirectQuery

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

Рис. 3.1    Просмотр сгенерированного запроса к источнику

Моделирование данных для режима DirectQuery    55

В открывшемся окне вы можете изучить, как Po­wer BI переводит написанные вами вычисления на родной язык источника и есть ли предпосылки для их оптимизации. На рис. 3.2 показан запрос к таблице с одним добавленным вычислением, вычитающим значение одного числового поля из другого.

Рис. 3.2    Родной для SQL Server запрос на языке T-SQL с пользовательским вычислением Работая в режиме DirectQuery, не усложняйте без необходимости вычисления, чтобы не затруднять жизнь источнику данных. Старайтесь ограничиваться в мерах функция­ ми суммирования, подсчета количества элементов, а  также минимума, максимума и среднего значения. Для начала проанализируйте на предмет производительности машинные запросы, созданные по умолчанию, после чего вносите дополнительные изменения, особенно это касается функции CALCULATE.

Также необходимо помнить, что для создания виртуальной связи между таблицами в модели данных Po­wer BI нет необходимости в том, чтобы эти

56    Оптимизация DirectQuery таблицы были связаны физическим образом в источнике. Физические связи создают инженеры данных с  целью оптимизировать объединения таблиц для общих шаблонов запросов, и  мы в  Po­wer  BI должны по возможности пользоваться этим. На рис. 3.3 показана простая модель данных DirectQuery в Po­wer BI Desktop с  произвольной связью между двумя измерениями (dimension): Person и Product.

Рис. 3.3    Произвольная связь в DirectQuery

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

На показанном примере видно, что Po­wer  BI предлагает определенную гибкость, использование которой может привести к  непредвиденным последствиям, если действовать не вполне осознанно. И таких моментов в следующих главах будет приведено довольно много.

Моделирование данных для режима DirectQuery    57

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

Рис. 3.4    Типичная связь с измерением по числовому идентификатору

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

58    Оптимизация DirectQuery

Рис. 3.5    Установка ссылочной целостности для связи DirectQuery

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

Моделирование данных для режима DirectQuery    59

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

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

В следующем разделе мы рассмотрим некоторые настройки Po­wer BI и оптимизацию источника данных, которые должны пойти вам на пользу при использовании режима DirectQuery.

60    Оптимизация DirectQuery

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

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

Рис. 3.6    Настройка максимального числа подключений на источник данных

Настройки быстродействия режима DirectQuery    61

Если источник данных способен обрабатывать больше подключений параллельно, рекомендуется увеличить значение этого параметра перед пуб­ ликацией набора данных в  службе Po­wer  BI. И  наоборот, при работе с  перегруженными источниками данных вы можете обнаружить, что более комфортная работа будет обеспечиваться при уменьшении этого значения. Причина этого в том, что параллельно запущенные запросы могут излишне нагружать источник, в результате чего общее время обработки запросов может вырасти. Снижение этого параметра будет означать, что некоторые запросы будут вставать в очередь и исполняться позже, когда источник освободится, что снизит нагрузку на него. В Po­wer BI Desktop вы можете ввести большие значения для настройки максимального числа подключений на источник данных. В то же время в службе Po­wer BI есть свои жесткие ограничения в этой области, зависящие от того, используете ли вы емкость Premium и каков ее объем. Эти ограничения могут меняться, при этом публично они не документированы. В связи с этим вы можете обратиться в поддержку Microsoft за дополнительными разъяснениями применительно к вашему конкретному сценарию.

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

Рис. 3.7    Настройка сокращения числа запросов

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

Рис. 3.8    В отчет добавлены кнопки Применить (Apply)

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

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

Настройки быстродействия режима DirectQuery    63

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

64    Оптимизация DirectQuery путем выбора наиболее подходящего плана. Эта статистика должна всегда поддерживаться в актуальном состоянии, чтобы оптимизатор не строил свои догадки на основе устаревших данных о кратности столбцов и количестве строк. Чтобы оптимально настроить работу внешних источников данных, необходимо понимать, какие именно запросы будут посылаться к ним со стороны Po­wer BI. В главе 4 мы научимся перехватывать эти запросы в Po­wer BI. Также с этой целью можно использовать ресурсы внешнего источника, и такая схема часто применяется в готовых рабочих системах, где отчеты публикуются в службе Po­wer BI. Давайте подведем итоги того, что мы узнали о режиме хранения DirectQuery в этой главе, после чего перейдем к знакомству с ключевыми показателями производительности в Po­wer BI.

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

Часть

II

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

Глава

4 Анализ логов и метрик

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

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

Метрики использования в Po­wer BI    67

Рис. 4.1    Просмотр отчета о метриках использования в Po­wer BI

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

Рис. 4.2    Доступ к метрикам использования на странице отчета

После открытия отчета о метриках использования перейдите на страницу Report performance. По умолчанию будет открыта вкладка отчета Daily per-

68    Анализ логов и метрик formance, на которой вы увидите информацию о ежедневных показателях отчета за последние 30 дней. Этот вид отчета показан на рис. 4.3.

Рис. 4.3    Ежедневные показатели отчета

При желании вы можете переключиться на вкладку 7-day performance, чтобы проанализировать скользящие показатели эффективности по неделям. На этом графике представлены сглаженные линии трендов по неделям. В  настоящее время в  Po­wer  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: этот показатель отражает интервал в  секундах, в  который входит

Метрики использования в Po­wer BI    69

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

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

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

70    Анализ логов и метрик

Рис. 4.4    Отчет о суммарной нагрузке на всю рабочую область

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

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

Рис. 4.5    Создание копии отчета о метриках использования

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

Метрики использования в Po­wer BI    71

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

Рис. 4.6    Набор данных для копии отчета о метриках использования

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

72    Анализ логов и метрик   Reports: список всех отчетов в  рабочей области с  именами и  идентификаторами. Используйте столбец IsUsageMetricsReport, чтобы исключить какие-то системные отчеты из вашего анализа. Для этого установите ему значение True;   Report pages: здесь содержится список страниц отчетов с  именами и идентификаторами, а также идентификатор отчета, которому принадлежит страница;   Users: содержит список всех имен участников-пользователей (user principal name – UPN), которые были задействованы в работе с отчетами. Чаще всего под этим атрибутом скрывается электронный адрес. Факты в наборе данных:   Report page views: таблица, содержащая записи для всех просмотров страниц отчетов со стороны клиентов Po­wer BI. Используйте эти данные для анализа на уровне страниц. Здесь важно упомянуть одно ограничение, присутствующее в документации от Microsoft. Данные в этой таблице опираются на сведения, посланные в  Po­wer  BI клиентским устройством (например, браузером на компьютере пользователя). Как сказано в документации, иногда конфигурация устройств или сети может приводить к блокировке исходящих подключений, что может препятствовать поступлению соответствующей информации в Po­wer BI;   Report load times: здесь содержится информация о загрузке всех отчетов в том виде, в котором она поступает от клиента Po­wer BI (например, от powerbi.com в случае использования веб-браузера или от мобильного приложения Po­wer BI при работе с телефона). Поля StartTime и EndTime используются для расчета длительности действий. На данный момент здесь не присутствует информация о странице отчета, так что зафиксированные действия могут относиться к любой странице. Способ обхода данного ограничения приведен далее в этой главе;   Report views: в этой таблице присутствуют действия по открытию отчетов с информацией от службы Po­wer BI. Эти события фиксируются на стороне сервера каждый раз при открытии отчетов. Таким образом, представленная здесь информация не зависит от проблем на стороне клиента и  сетевых задержек, и  каждое открытие отчета происходит в Po­wer BI;   Report rank: статическая таблица со списком всех отчетов в рабочей области и рангами по просмотрам в рамках всего клиента;   Workspace reports: агрегированная информация по дням использования отчетов с  тенденциями. Используйте поле IsUsageMetricsReportWS для исключения системных отчетов из анализа – установите для них значение True. Информация из этой таблицы используется на странице Report performance отчета о  метриках использования в Po­wer BI;   Workspace views: суммарная информация о просмотрах отчетов пользователями в разрезе способов использования и методов доступа. Служит источником данных для страницы с отчетами.

Метрики использования в Po­wer BI    73

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

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

Рис. 4.7    Список датасетов с метриками использования в Po­wer BI Desktop

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

74    Анализ логов и метрик

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

Рис. 4.8    Анализ данных о метриках использования в Microsoft Excel

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

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

Метрики использования в Po­wer BI    75

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

Рис. 4.9    Анализ набора данных с метриками использования в Excel

Рис. 4.10    Детальный отчет о производительности в пользовательском отчете

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

Теперь давайте узнаем, на что именно стоит обращать внимание при анализе данных о производительности и что делать с полученными результатами.

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

Метрики использования в Po­wer BI    77

Таблица 4.1. Инструкция по анализу отчета об агрегированных данных о производительности Вопрос Какие отчеты самые быстрые и самые медленные?

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

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

78    Анализ логов и метрик

Рис. 4.11    Анализ производительности отчета по дням с двумя пиками

Рис. 4.12    Анализ производительности отчета по браузерам

Метрики использования в Po­wer BI    79

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

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

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

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

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

Журнал действий и единый журнал аудита В Po­wer BI присутствуют два источника логов, описывающих действия пользователей. В табл. 4.2 приведены их основные сходства и различия. Таблица 4.2. Сравнение журнала действий и единого журнала аудита Журнал действий Po­wer BI Доступ осуществляется посредством REST API Get Activity Events и командлета Po­wer BI Management Требуются привилегии администратора Po­wer BI или службы Power Platform Содержит только действия из Po­wer BI История хранится на протяжении 30 дней

Единый журнал аудита Доступ осуществляется через интерфейс Compliance Search или командлеты PowerShell Требуются привилегии глобального администратора Office 365 или аудитора Содержит действия из всей линейки продуктов Microsoft, к примеру Office 365 История хранится на протяжении 90 дней

Больше информации будет приведено ниже в разделе «Материалы к прочтению». Для анализа журнала действий (activity log) вам необходимо будет создать отчеты по примеру того, как мы описывали в разделе с метриками использования. В случае с журналом аудита (audit log) вам нет необходимости использовать файлы Excel – вместо этого вы можете сохранять данные в виде файлов CSV. Также логи администрирования легко поддаются автоматизации по причине возможности использования командлетов PowerShell и вызовов REST API.

Логи Po­wer BI и трассировка    81

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

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

82    Анализ логов и метрик

Отслеживание показателей в Azure Analysis Services и Po­wer BI Embedded Azure Analysis Services (AAS) и  Po­wer  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: вычислительные мощности, задействованные всеми процессами в рамках экземпляра. Хорошо оптимизированный экземпляр должен

Логи Po­wer 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 для анализа

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

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

Заключение Поскольку производительность отчетов является довольно важной и обширной темой, мы начали главу с обзора встроенных шаблонов анализа метрик использования в Po­wer BI, которыми могут воспользоваться администраторы рабочей области. Сперва мы научились формировать отчет по метрикам использования. Мы подробно рассмотрели содержимое вкладки с производительностью отчета и узнали, как можно анализировать показатели в разрезе браузеров, местоположения пользователей и методов развертывания отчетов. Мы отметили, что представленная в отчете агрегированная информация является отличной отправной точкой для анализа, но для возможности детального разбора ситуации вам понадобятся данные с  более высоким уровнем грануляции. С целью их получения мы научились сохранять копию исходного отчета и настраивать ее, анализировать сырые данные в Excel и подключаться к набору данных с  метриками использования из Po­wer  BI Desktop. Все эти методы помогут вам получать детальную информацию и выводить ее в нужном вам виде. Попутно мы подробно разобрали назначение всех таблиц в  наборе данных и описали работу с несколькими рабочими областями Po­wer BI одновременно. В завершение первой части главы мы сформулировали и ответили на наиболее типичные вопросы, связанные с производительностью, рассмот­

Материалы к прочтению    85

рели примеры полезных метрик, с  которыми вам предстоит разобраться, и перечислили меры, которые стоит предпринять на основании полученной информации. После этого мы перешли к разговору о логах и трассировке, сразу отметив, что логи уровня всего облачного пространства будут доступны только пользователям с соответствующими правами администратора. В то же время мы узнали, что эти логи изначально не содержат информации о производительности, и  научились извлекать нужные нам сведения напрямую из движка Analysis Services, лежащего в основе любого решения Po­wer BI. Вместе с тем мы узнали, что этот источник содержит очень важные данные относительно производительности запросов и  обновлений. При использовании наборов данных Premium вы имеете возможность осуществлять подключение с помощью конечных точек XMLA, что позволит выполнять трассировку почти в  реальном времени. Также вы располагаете опцией подключения из Po­ wer BI к Azure Log Analytics с целью извлечения гранулярных данных в вашем окружении. Log Analytics – это выделенная служба Azure для масштабного анализа логов с возможностью выполнения произвольных запросов, долговременным хранением, созданием оповещений и поддержкой визуализации средствами Po­wer 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 Po­wer BI Management: https://www.powershellgallery.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-andcompliance?view=o365-worldwide.

Глава

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

В предыдущей главе мы рассмотрели способы извлечения информации об использовании и производительности из службы Po­wer BI посредством отчетов и логов. Эти данные предоставляются компанией Microsoft по вашему требованию, но при этом имеют определенные ограничения в  отношении вопросов, на которые они способны отвечать. В отчетах Po­wer BI нас в первую очередь интересует скорость отрисовки визуальных элементов, выполнения запросов или все это вместе взятое. На момент написания книги далеко не весь спектр детализации был доступен в информации, предоставляемой службой Po­wer BI. В то же время вы можете получить куда более подробные данные при помощи встроенного в  Po­wer  BI Desktop инструмента под названием Анализатор производительности. В процессе чтения этой книги вы видите, как самые разные факторы могут влиять на быстродействие пользовательских отчетов. Для идентификации этих факторов необходимо иметь возможность анализировать поведение отчета на уровне каждого взаимодействия с пользователем и наблюдать за ответами всех визуальных элементов на эти действия. Анализатор производительности (Performance Analyzer) – превосходный инструмент для этих целей. В этой главе мы научимся с ним работать и узнаем, как его использовать для определения проблем с производительностью. Темы, которые будут рассмотрены в этой главе:   обзор Анализатора производительности;   определение и устранение проблем с производительностью;   экспорт и анализ данных о производительности.

Технические требования Некоторые темы из этой главы предполагают наличие примеров. Мы будем упоминать файлы, с  которыми будем работать. Все их вы сможете найти в папке Chapter05 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-Practices.

Обзор Анализатора производительности    87

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

Рис. 5.1    Панель Анализатора производительности с раскрытым визуальным элементом

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

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

Действия и метрики в Анализаторе производительности Анализатор производительности позволяет перехватывать следующие действия пользователей:   Изменил страницу (Changed page): к этому событию относится смена текущей страницы при помощи вкладок в Po­wer BI и пользовательских кнопок навигации, помещенных в отчетах;   Перекрестное выделение (Cross-highlighted): к этой категории относятся типичные действия перекрестной активности, такие как выбор точки данных или столбика на диаграмме. При этом стоит помнить, что большинство щелчков мыши по визуальным элементам в Po­wer BI приводят как минимум к их обновлению. К примеру, при щелчке мышью по пустой области элемента визуализации для отмены перекрестного выделения соответствующие элементы, как и  ожидается, будут обновлены. Если повторно щелкнуть по этой пустой области, вы заметите обновление элемента, и это действие будет перехвачено анализатором;   Изменил срез (Changed a slicer): это событие инициируется при изменении значения среза (slicer) и применяется к другим визуальным элементам. Если у вас включена настройка сокращения числа запросов в  отчете (о которой мы говорили в  предыдущих главах), то вам необходимо будет нажать на кнопку Применить (Apply) для отправки события Изменил срез. Даже при использовании этих кнопок подтверждения выбора взаимодействие со срезами может провоцировать обновления визуальных элементов, которые будут перехвачены анализатором;   Изменил фильтр (Changed a filter): это событие возникает в  случае применения новых значений в фильтре отчета. Настройка сокращения числа запросов в отчете распространяется на фильтры так же, как и на срезы. В Анализаторе производительности фиксируются следующие категории действий для визуальных элементов:   Запрос DAX (DAX query): этот пункт отображается только в случае наличия запроса. Показатель измеряет время, прошедшее с момента отправки запроса визуальным элементом до получения результатов от

Обзор Анализатора производительности    89

движка Analysis Services. Это время должно быть чуть большим, чем в анализе запроса DAX из отчета о производительности от движка Analysis Services, поскольку сюда включаются сетевые задержки и прочие накладные расходы;   Запрос Direct (Direct query): этот пункт появляется только для источников в режиме DirectQuery в присутствии запросов. Показанное время отмеряется с  момента отправки внешнего запроса движком Analysis Services до получения результатов. Это время должно соответствовать метрике для событий класса DirectQuery в движке Analysis Services;   Визуальное отображение (Visual display): здесь демонстрируется время, необходимое для отрисовки визуальным элементом полученных данных. В это время включается загрузка внешнего контента, например изображений, и операции геокодирования. Плохо реализованные или сложные пользовательские элементы визуализации могут требовать значительного времени для отрисовки;   Другое (Other): к этой категории относятся все события визуального элемента, не связанные с отрисовкой, такие как подготовка запросов и прочие операции фоновой обработки данных. Также сюда включается время ожидания других визуальных элементов. Это происходит по причине того, что все элементы визуализации используют один поток (thread) и, если говорить очень упрощенно, каждый из них обрабатывается процессором последовательно. Всякий раз, когда вы добавляете новый визуальный элемент на страницу, этот показатель для всех остальных элементов будет увеличиваться. Это не обязательно плохо, но может негативно сказаться на времени тяжелых в плане визуализации отчетов. Более подробно о проблемах, связанных с визуализацией элементов, мы поговорим в главе 9. Обновление визуального элемента не обязательно приводит к запуску запроса в соответствующем источнике данных. Клиент Po­wer BI хранит локальный кеш результатов вычислений, так что может себе позволить не запускать запрос заново при переключении между недавно отфильтрованными представлениями. Этим объясняется, почему для некоторых визуальных элементов, основывающихся на данных, может отсутствовать пункт с запросом DAX. Чтобы инициировать отправку запроса, необходимо нажать на ссылку Обновить визуальные элементы (Refresh visuals) на панели анализатора производительности.

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

90    Анализатор производительности

Открыт выпадающий список

Рис. 5.2    Пользователь открыл выпадающий список, после чего сделал свой выбор

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

Открыт выпадающий список

Открыт выпадающий список

Рис. 5.3    Выпадающий список открыт во второй раз

Обзор Анализатора производительности    91

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

Рис. 5.4    Всплывающее окно со срезами с привязкой к иконке

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

92    Анализатор производительности

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

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

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

Определение и устранение проблем с производительностью    93

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

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

94    Анализатор производительности Добавьте пустую страницу в свой отчет при проведении теста производительности в Po­wer BI Desktop. Сохраните файл с открытой в этот момент пустой страницей и закройте Po­wer BI Desktop. Откройте программу снова и убедитесь, что по умолчанию открывается созданная пустая страница. Теперь ни один запрос не подключается к набору данных, а значит, кеширование производиться не будет.

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

Рис. 5.6    Первая загрузка потребовала больше времени

Определение и устранение проблем с производительностью    95

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

Рис. 5.7    Запросы DAX отправляются только при первом открытии отчета

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

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

Определение и устранение проблем с производительностью    97

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

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

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

98    Анализатор производительности Если ваши пользователи работают из разных мест и у вас нет возможности запускать тесты из их локаций, вы можете смоделировать приблизительно похожие сетевые условия при помощи виртуальных машин (virtual machine – VM), поднятых в тех же регионах. Арендовать виртуальные машины сегодня можно почти у любого облачного провайдера, и за несколько часов теста вам придется заплатить совсем немного.

Ограничением Анализатора производительности в  Po­wer  BI Desktop является отсутствие учета общей длительности операции. Это затрудняет возможности анализа общего времени, которое потребовалось на выполнение действия от начала до конца. Частично мы исправим данный недостаток далее в этой главе, когда взглянем на логи. Теперь же давайте рассмотрим примеры проблем, которые можно идентифицировать при помощи Анализатора производительности.

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

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

Определение и устранение проблем с производительностью    99

Рис. 5.9    Таблицы с одинаковыми результатами, но разными мерами

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

Рис. 5.10    Катастрофическая разница в длительности выполнения запросов

Теперь давайте взглянем на выражения DAX для медленной и  быстрой мер: UniqueRedProducts_Slow = CALCULATE( DISTINCTCOUNT('SalesOrderDetail'[ProductID]),

100    Анализатор производительности 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 секунд, что составляет большую часть времени отображения отчета в целом.

Определение и устранение проблем с производительностью    101

Рис. 5.11    Карта со множеством точек данных

Рис. 5.12    Большая часть времени расходуется не на сам запрос

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

102    Анализатор производительности

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

Рис. 5.13    Элементы визуализации, продублированные в отчете

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

Экспорт и анализ данных о производительности    103

Рис. 5.14    Большая часть времени расходуется на категорию событий Другое (Other)

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

104    Анализатор производительности На рис.  5.15 показан фрагмента лог-файла Анализатора производительности.

Рис. 5.15    Первые несколько элементов в лог-файле Анализатора производительности

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

Экспорт и анализ данных о производительности    105

Рис. 5.16    Отчет DirectQuery с четырьмя визуальными элементами

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

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

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

106    Анализатор производительности

Рис. 5.18    Последовательность событий и метрики производительности

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

Рис. 5.19    Дерево событий для пользовательских действий

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

Заключение    107

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

Методы преобразования, которые были использованы в  этом примере, довольно просты и основываются на ручном вводе номеров строк в файле для выделения разных действий пользователя. Мы сделали это намеренно, чтобы проиллюстрировать структуру файла JSON на небольшом примере. Вы можете применить данный прием к своим файлам, при необходимости добавив методику автоматической обработки логов для больших файлов. Теперь, когда мы познакомились с  Анализатором производительности в Po­wer BI, пришло время подвести итоги этой главы и двинуться дальше.

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

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

Глава

6 Внешние инструменты

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

110    Внешние инструменты Темы, которые будут рассмотрены в этой главе:   Po­wer BI Helper;   Tabular Editor;   DAX Studio и VertiPaq Analyzer.

Технические требования Для некоторых примеров из этой главы мы подготовили сопроводительные материалы, на которые будем ссылаться при обсуждении тех или иных приемов. Все нужные файлы располагаются в папке Chapter06 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-Practices.

Po­wer BI Helper Po­wer  BI Helper обладает целым рядом возможностей для исследования, документирования и сравнения локальных файлов Po­wer BI Desktop. Также этот инструмент позволяет просматривать и экспортировать метаданные из службы Po­wer BI, такие как списки рабочих областей и наборов данных с их свойствами. Po­wer BI Helper можно загрузить по адресу https://powerbihelper. org. В предыдущих главах мы не раз указывали на то, как важно стараться сохранять объем наборов данных Po­wer BI максимально небольшим, избавляясь от лишних таблиц и столбцов. В Po­wer BI Helper есть для этого необходимые средства, так что этот инструмент вполне может быть включен в процесс оптимизации решений перед их публикацией.

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

Po­wer BI Helper    111

Рис. 6.1    Вкладка Modeling Advise с колонками по убыванию размера

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

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

112    Внешние инструменты

Рис. 6.2    Удаление неиспользуемых колонок в Po­wer BI Helper

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

Поиск зависимостей в мерах Po­wer BI Helper показывает зависимости в мерах на вкладке Model Analysis. Меры могут быть повторно использованы в других мерах, что бывает очень удобно. В  таких цепочках мер начальное звено часто называется базовой мерой (base measure). Базовые меры могут повторно использоваться во множестве других мер, и  Po­wer  BI Helper позволяет легко идентифицировать все эти обратные зависимости. Эту информацию можно использовать для оптимизации этих базовых мер, поскольку это может привести к ощутимому росту производительности модели данных в целом. Также у вас могут быть сложные меры, ссылающиеся сразу на несколько других мер. В этом случае Po­wer BI Helper поможет вам обнаружить такие меры и оптимизировать их составляющие. Как видите, Po­wer BI Helper оказывает всестороннюю помощь разработчику в  поиске проблем, часто незримо присутствующих в  любой модели данных. Далее мы рассмотрим еще один очень полезный бесплатный инструмент под названием Tabular Editor, который позволит вам еще глубже погрузиться в модель и набор данных.

Tabular Editor    113

Tabular Editor Tabular Editor доступен как в  виде коммерческой версии, так и  с  открытым исходным кодом. Первая предлагает более расширенные возможности и специализированную поддержку, которая может оказаться очень полезной разработчикам Po­wer BI. Но, к счастью, бесплатная версия на момент написания книги содержит весь базовый функционал инструмента и может быть загружена из хранилища GitHub по адресу https://github.com/TabularEditor/ TabularEditor. Tabular Editor представляет собой инструмент для повышения производительности, который может быть эффективно использован в разработке как дополнение Po­wer BI Desktop или Microsoft Visual Studio. Мы не будем подробно останавливаться на всех функциональных возможностях этого инструмента, поскольку это выходит за рамки данной книги. В  то же время Tabular Editor обладает огромной популярностью в  среде разработчиков Po­wer  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-

114    Внешние инструменты 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 видно, как выглядит редактор при открытом правиле.

Tabular Editor    115

Рис. 6.4    Правила BPA, загруженные при помощи Advanced Scripting

Рис. 6.5  Загруженные правила BPA в Tabular Editor

116    Внешние инструменты

Рис. 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.

Tabular Editor    117

Рис. 6.7  Результаты работы BPA с выделенными важными пунктами

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

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

118    Внешние инструменты

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 Analyzer Metrics, как показано на рис. 6.9, чтобы узнать общий объем модели данных и увидеть другую важную статистическую информацию. Зачастую показатель Total Size будет превышать физический объем файла на диске (с расширением .pbix или .abf, если это бэкап Analysis Services). Это происходит из-за того, что при загрузке набора данных в память требуется создание дополнительных структур, – особенно это касается датасетов в режиме Import. В главе 2 мы говорили о том, как в хранилище Po­wer 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

120    Внешние инструменты

Рис. 6.10    Один столбец поработил весь набор данных

На этом рисунке мы также видим, что тип (Data Type) этого столбца указан как String, что подразумевает хранение алфавитно-цифровых символов. Из всего этого можно предположить, что в  этом столбце содержатся длинные текстовые данные, плохо поддающиеся сжатию. На самом деле в  этой колонке находятся тексты запросов DAX и DirectQuery из трассировки движка Analysis Services, загруженной в Po­wer 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 после запуска трассировки.

DAX Studio и VertiPaq Analyzer    121

Рис. 6.11    Трассировка запросов запущена

После запуска отслеживания вы можете взаимодействовать с  набором данных за пределами DAX Studio, а вся информация о ваших действиях продолжит накапливаться. Способ взаимодействия с датасетом зависит от того, где он располагается. Если вы работаете с ним на локальном компьютере при помощи Po­wer  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, но сначала узнаем, как можно перехватывать информацию об их производительности.

122    Внешние инструменты

Рис. 6.12  Запросы, перехваченные DAX Studio

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

Рис. 6.13    На вкладке Server Timings показана детальная статистика выполнения запросов

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

DAX Studio и VertiPaq Analyzer    123

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

Рис. 6.14    Вкладка Server Timings для быстрого запроса

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

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

Изменение и настройка запросов Ранее в этом разделе мы видели, как можно перехватывать запросы, сгенерированные визуальными элементами Po­wer BI, и отображать их текст. Сейчас мы покажем один полезный трюк, связанный с использованием мер области запроса (query-scoped measures), которые будут перекрывать исходные меры в модели. С помощью этого приема можно удобно тестировать быстродействие запросов.

124    Внешние инструменты На рис. 6.15 показано, как можно найти нужную вам меру и, выбрав пункт Define Measure в контекстном меню, перенести определение меры в редактор запросов.

Рис. 6.15    Перенос определения меры в редактор запросов

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

DAX Studio и VertiPaq Analyzer    125

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

Рис. 6.16    После изменения мера дала лучшие результаты

Рис. 6.17    Трассировка Performance Analyzer помогла определить узкое место отчета

  экспортируйте/импортируйте метрики модели: в  DAX Studio вы можете экспортировать и импортировать метаданные модели VertiPaq с помощью файлов с расширением .vpax. В этих файлах не содержатся сами данные. Вместо этого в них находятся имена таблиц и столбцов,

126    Внешние инструменты а также определения мер. Если ничто не запрещает вам делиться метаданными о модели, вы можете передать эти файлы специалисту, чтобы он помог вам их оптимизировать. Итак, мы рассмотрели несколько популярных внешних инструментов, которые способны помочь вам в разработке решений на базе Po­wer BI и обнаружении узких мест в сценариях. Давайте подведем итоги этой главы.

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

Заключение    127

можность использовать меры области запроса в  DAX Studio позволила без вмешательства в модель данных опробовать различные техники языка DAX и оценить их эффективность. На данный момент вы уже довольно много знаете об общих принципах оптимизации работы в Po­wer BI. Также вы познакомились с полезными утилитами, позволяющими измерять быстродействие запросов. В  следующей главе мы рассмотрим общие принципы комбинирования полученных навыков для поддержания высокой эффективности решений на базе Po­wer BI.

Глава

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

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

Налаживание воспроизводимого и упреждающего процесса повышения    129

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

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

130    Общие принципы управления производительностью

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

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

Принятие превентивных мер

Диагностирование и исправление

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

Обнаружение проблем и расстановка приоритетов

Рис. 7.1    Цикл управления производительностью

Давайте рассмотрим каждую фазу отдельно.

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

Налаживание воспроизводимого и упреждающего процесса повышения    131

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

132    Общие принципы управления производительностью

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

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

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

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

Обмен опытом и знаниями    133

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

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

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

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

134    Общие принципы управления производительностью

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

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

Обмен опытом и знаниями    135

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

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

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

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

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

Обмен опытом и знаниями    137

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

BI-системы самообслуживания BI-системы на основе отдела или команды

Роль Бизнеспользователи

138    Общие принципы управления производительностью Таблица 7.1 (окончание) Роль Ответственность Разработчики ETL • Устанавливают и документируют стандарты загрузки и преобразования данных. • Анализируют содержимое на предмет проблем с производитель­ ностью перед публикацией. • Используют логи и внешние инструменты для оптимизирования составляющих системы Архитекторы • Устанавливают и документируют архитектурные стандарты решения решения. • Используют логи и внешние инструменты для информирования о будущих архитектурных решениях. • Узнают о новых разработках, способных повысить производительность системы (то же касается и остальных специалистов) Старшие бизнес- • Определяют процессы, роли и ответственности в управлении аналитики / главы производительностью. отделов • Участвуют в совместной работе по определению объективных аналитики целевых метрик производительности. • Следят за изменениями производительности решения с течением времени и участвуют в обновлении инструкций и процессов

Теперь давайте подытожим все, что мы узнали из этой главы.

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

Заключение    139

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

Часть

III

Извлечение, преобразование и визуализация данных В этой части книги мы познакомимся с движком запросов M и узнаем, как потребляются ресурсы во время загрузки, преобразования и обновления данных. Мы узнаем, как разные аспекты отчетов влияют на производительность, каких приемов стоит избегать и какие есть альтернативы. Содержание этой части:   глава 8 «Загрузка, преобразование и обновление данных»;   глава 9 «Разработка отчетов и дашбордов».

Глава

8

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

142    Загрузка, преобразование и обновление данных

Технические требования Для некоторых примеров из этой главы мы подготовили сопроводительные материалы, на которые будем ссылаться при обсуждении тех или иных приемов. Все нужные файлы располагаются в папке Chapter08 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-Practices.

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

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

Основные принципы преобразования данных    143

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

Рис. 8.1    Настройка одновременной загрузки таблиц в Power Query

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

144    Загрузка, преобразование и обновление данных В увеличении количества контейнеров в Po­wer BI Desktop большого смысла, по сути, нет. При установленном значении по умолчанию на каждое логическое ядро процессора будет выделяться по одному контейнеру, и все они будут обрабатываться параллельно. В зависимости от сложности операций преобразования данных и фоновых процессов, запущенных на компьютере, контейнеры могут очень сильно нагружаться. Наличие слишком большого количества контейнеров может привести к  замедлению обновлений из-за попыток слишком многих операций выполняться одновременно и  порождения ненужной борьбы за процессорное время. В результате каждое ядро процессора начинает выполнять несколько запросов, а  источник данных вынужден поддерживать множество параллельных подключений, хотя здесь могут также существовать свои ограничения на количество подключений. В случае использования Po­wer BI Premium, Po­wer 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.

Основные принципы преобразования данных    145

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

Рис. 8.2    Настройки из раздела Загрузка данных

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

Рис. 8.3    Двоичный параметр с допустимыми значениями

Рис. 8.4    Использование двоичного параметра для ограничения объема данных

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

Основные принципы преобразования данных    147

умолчанию у  вас могут возникать проблемы с  быстродействием. Причина этого в том, что 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 содержится две группы записей,

148    Загрузка, преобразование и обновление данных а именно Student и Course. После выделения этих групп в отдельные таблицы мы просто исключаем исходную таблицу из загрузки.

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

Еще одна техника, помогающая повысить быстродействие запросов со сложными преобразованиями данных, заключается в использовании функций буферизации (buffer functions). В Power Query вы можете воспользоваться такими функциями, как Table.Buffer() и List.Buffer(). Применять их следует, как ясно из названий, к  объектам Table и  List в  Power Query, чтобы принудительно сохранить их в  памяти для дальнейшего использования, а  не передавать небольшими пакетами. Это бывает полезно при обработке определенного вида преобразований, например при извлечении целых таблиц из отдельных колонок (допустим, документов JSON) или динамического сведения/отмены свертывания при наличии большого количества уникальных значений, особенно с  несколькими уровнями вложенности функций. На функции буферизации стоит обратить внимание, если ваши операции обновления завершаются ошибками с указанием на нехватку ресурсов. Последним советом в этом разделе будет пересмотр необходимости присутствия автоматических даты и времени в Po­wer 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, которая отправляется на выполнение в источник. Свертывание запросов представляет собой очень мощную технику, способную критически повысить производительность запросов. В результате выполнения этой операции сокращается объем данных, возвращаемых Po­wer BI, что может существенно снизить время обновления и увеличить эффективность запросов DirectQuery при работе с большими объемами данных на миллионы строк.

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

150    Загрузка, преобразование и обновление данных

Рис. 8.8    Активный пункт говорит о том, что свертывание было проведено успешно

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

Свертывание запросов, объединение и агрегация    151

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

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

152    Загрузка, преобразование и обновление данных

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

Рис. 8.9    Параметры, требуемые для настройки добавочного обновления

Свертывание запросов, объединение и агрегация    153

Рис. 8.10    Настройка фильтра для поддержки в запросе параметризованного диапазона дат

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

Рис. 8.11    Добавочное обновление для таблицы

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

Использование диагностики запросов В Po­wer 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

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

156    Загрузка, преобразование и обновление данных

Сбор диагностической информации в 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) для его запуска с созданием отдельного файла трассировки с именем выполненного шага.

Использование диагностики запросов    157 Логи запросов могут оказываться очень объемными, что затрудняет работу с ними. Редактор 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-powerquery-diagnostics-data-in-a-power-bi-decomposition-tree. Мы также привели примеры визуализации разобранных диагностических сведений. На рис. 8.15 показан фрагмент файла Query Diagnostics.pbix, в котором при помощи дерева декомпозиции определяются наиболее дорогостоящая в плане ресурсов группа операций и ее потомки. Во всплывающем окне вы видите, что шаг Level 2 выполняется около 29 секунд и загружает более 220 000 строк. Также мы видим выражение на языке SQL, отправленное в источник данных, что является подтверждением того, что свертывание запроса было выполнено успешно. Теперь взглянем на пример, в котором та же логика запроса будет реализована двумя разными способами, т. е. с обращением к разным источникам данных. Мы посмотрим, как это повлияет на свертывание запросов и  их производительность. В рассматриваемом сценарии у нас есть хранилище данных, и мы хотим создать широкую денормализованную таблицу в качестве временного решения. Мы возьмем таблицу фактов с продажами и обогатим ее за счет номинативных данных из четырех таблиц-измерений с сотрудниками, покупате-

158    Загрузка, преобразование и обновление данных лями и т. д. Все данные хранятся в SQL Server. Для этого примера мы все эти таблицы по отдельности загрузили в Po­wer BI Desktop, что видно на рис. 8.16. Затем мы сохранили данные из таблицы фактов, находящейся в базе данных, в файле CSV с именем Fact Sale_disk, чтобы использовать его в качестве альтернативного источника данных для сравнения.

Рис. 8.15    Иерархический вид лога запроса после сглаживания

Рис. 8.16    Исходные таблицы, загруженные в набор данных

Использование диагностики запросов    159

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

Рис. 8.17    Сравнение запросов с одной логикой, но разными источниками

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

Рис. 8.18    У запроса со свертыванием меньше время выполнения и меньше действий

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

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

Оптимизация потоков данных    161

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

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

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

Оптимизация потоков данных    163

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

Рис. 8.19    Визуальное отображение связанной сущности

Рис. 8.20    Включение расширенной подсистемы вычислений в настройках потоков данных

164    Загрузка, преобразование и обновление данных Настройка расширенной подсистемы вычислений доступна только при использовании других потоков данных в  качестве источника. Вы можете говорить о  наличии вычисляемой сущности (computed entity), если поверх ее иконки нарисована молния, как показано на рис. 8.21. Также на рисунке видно, что Po­wer BI отображает всплывающую подсказку при наведении мышью на шаг Источник (Source), в которой указано, что он будет выполнен во внешнем окружении.

Рис. 8.21    Вычисляемая сущность, обозначенная визуально

  DirectQuery для потоков данных: при использовании вычисляемых сущностей в  качестве источников для наборов данных Po­wer  BI допустимо обращаться к ним в режиме DirectQuery. Это бывает полезно при наличии большого количества наборов данных, имеющих в своей основе поток данных. Даже если поток данных один раз загружается в  Po­wer  BI из внешнего источника, применение режима DirectQuery способно снизить нагрузку как на Po­wer  BI, так и  на источник. Согласно принципам размерного моделирования (dimensional modeling) Ральфа Кимбалла, это может быть полезно, когда у вас объемные измерения, но вы часто обращаетесь к небольшой их части и вам не нужно большинство их атрибутов. В главе 10 мы будем говорить о размерном моделировании более подробно. Режим DirectQuery устанавливается при доступе к потокам данных как источнику в Po­wer BI Desktop с помощью коннектора Потоки данных Po­wer  BI (Po­wer  BI Dataflows). В  процессе настройки доступа вам будет предложено сделать выбор между режимами Import и DirectQuery – так же, как и при подключении к  любому другому источнику, поддерживающему оба режима хранения. В  настоящее время существуют определенные ограничения для потоков данных DirectQuery, такие как невозможность использовать их с составными моделями. Обратитесь к официальной документации от Microsoft для проверки допустимости вашего сценария. В этой главе мы получили полное представление о  принципах преобразования данных в  Po­wer  BI и  способах сокращения времени обновлений. Давайте подведем итоги и двинемся дальше.

Заключение    165

Заключение В этой главе мы начали погружение в  недра решений Po­wer  BI и  первым делом рассмотрели процессы загрузки и преобразования данных. Мы увидели, что основная роль на этих этапах отводится Power Query и его движку обработки с языком запросов M. Мы также узнали, насколько требовательными к ресурсам являются операции обновления данных и насколько важно уделять внимание оптимизации в слое Power Query. Далее мы поговорили про параллельные вычисления и научились выполнять соответствующие настройки в  Po­wer  BI Desktop. Заодно рассмотрели опции, позволяющие ускорить процесс разработки решения и  обновление данных в целом. Также мы узнали, как настроить параллельные вычисления применительно к Po­wer BI Premium, Embedded и Azure Analysis Services. После этого переключились на процесс преобразования данных, особо выделив типичные операции вроде фильтрации, объединения и агрегации, способные замедлять работу системы. Мы изучили особенности очень важной возможности свертывания запросов, позволяющей существенно ускорить процесс за счет переноса вычислений на сторону источника данных, где они обычно выполняются гораздо быстрее и эффективнее. Мы узнали, как определить в Po­wer BI Desktop, выполняется ли свертывание запроса, а заодно научились настраивать добавочное обновление, призванное снизить количество загружаемых данных. Далее мы рассмотрели такую важную тему, как содержимое логов диаг­ ностики Power Query. Мы увидели, что анализировать структуру этих логов бывает не всегда удобно, но при этом в них содержится очень полезная информация для оптимизации запросов и источников данных. В завершение главы мы узнали, что из себя представляют потоки данных и как они могут быть использованы для снижения интенсивности во время загрузки и преобразования информации путем централизации общей логики и данных. Мы отметили, что в плане оптимизации производительности потоки данных мало отличаются от Power Query. Однако при работе с ними мы можем воспользоваться дополнительными возможностями, такими как расширенная подсистема вычислений. Теперь, когда вы узнали, как наиболее эффективно доставлять данные в Po­wer BI, давайте рассмотрим принципы оптимизации отчетов и дашбордов, чтобы пользователю было комфортнее работать, а данных загружалось меньше.

Глава

9 Разработка отчетов и дашбордов

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

Технические требования Для некоторых примеров из этой главы мы подготовили сопроводительные материалы, на которые будем ссылаться при обсуждении тех или иных приемов. Все нужные файлы располагаются в папке Chapter09 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-Practices.

Оптимизация интерактивных отчетов    167

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

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

Управление визуальными элементами и запросами Важно сразу отметить, что визуальные элементы (visuals) в Po­wer BI призваны работать параллельно. Это оказывает своеобразное влияние на производительность. Открывая интерактивный отчет в Po­wer BI, вы как бы запускаете все визуальные элементы разом. В результате элементы на основе данных тут же собирают и отправляют минимум по одному запросу к набору данных, причем эти запросы отправляются пакетами, которые выполняются по

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

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

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

Оптимизация интерактивных отчетов    169

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

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

Рис. 9.1  Агрегированный отчет по пяти пользователям

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

170    Разработка отчетов и дашбордов

Рис. 9.2  Детализированный отчет по конкретному пользователю

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

Рис. 9.3    Пять отдельных карточек – пять запросов DAX

Оптимизация интерактивных отчетов    171

что при размещении метрик в отдельных карточках будут отсылаться отдельные запросы для каждого элемента. Этот пример взят из файла Many cards. pbix, который вы можете загрузить из папки с сопроводительными материа­ лами. Для проведения анализа в Po­wer BI Desktop мы воспользовались инструментом Performance Analyzer, о котором подробно говорили ранее в этой книге. Как видите, каждый из пяти визуальных элементов отправляет свой запрос DAX, и на их выполнение требуется примерно по 2 с.

Рис. 9.3    Пять отдельных карточек – пять запросов DAX

На рис. 9.4 показано, как изменится ситуация, если объединить наши мет­ рики в одну многострочную карточку. Вы видите, что мы пришли всего к одному запросу.

Рис. 9.4  Одна многострочная карточка – один запрос DAX

Также мы можем собрать наши меры в таблицу. Результат этого показан на рис. 9.5. Здесь мы еще видим, что нам удалось обойтись лишь одним запросом.

172    Разработка отчетов и дашбордов

Рис. 9.5  Одна таблица с пятью мерами – один запрос DAX

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

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

Рис. 9.6    Левый элемент выводит все записи, а правый – только первые пять

Оптимизация интерактивных отчетов    173

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

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

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

174    Разработка отчетов и дашбордов тами. Для этого необходимо выделить нужный элемент или срез и  нажать на кнопку Изменить взаимодействия (Edit interactions) в  меню Формат (Format). Элемент останется выделенным, и вы сможете включить или выключить взаимодействия. В  данном случае в  левом визуальном элементе взаимодействие осталось включенным, а  в  правом мы его выключили. За взаимодействия отвечают иконки в правом верхнем углу элементов.

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

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

Оптимизация интерактивных отчетов    175

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

Рис. 9.8    С помощью подсказок выводится информация, не обязательная к просмотру в исходном виде отчета

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

176    Разработка отчетов и дашбордов

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

Рис. 9.9    Настройка сокращения числа запросов в Po­wer BI Desktop

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

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

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

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

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

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

Заключение    179

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

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

180    Разработка отчетов и дашбордов случаев. Отчеты с  разбивкой на страницы базируются на технологии SSRS и иначе называются отчетами с точностью до пикселя, поскольку проектируются для дальнейшей печати. Интерактивные отчеты включают в себя визуальные элементы, каждый из которых отправляет запросы для отображения нужных ему данных. Po­wer BI по своей сути является современным приложением JavaScript, и визуальные элементы в  отчете можно рассматривать как блоки кода, выполняющиеся параллельно. Это означает, что чем больше элементов у  вас на странице отчета, тем больше работы предстоит выполнить источнику данных. На самом же деле браузеры не выполняют код JavaScript в параллельном режиме, вмес­то этого вся работа возлагается на один поток центрального процессора. Это приводит к тому, что с увеличением количества визуальных элементов на странице растет и  время ожидания ими своей очереди обработки процессора. Из всего этого следует, что не стоит без необходимости размещать в отчете чрезмерно большое количество элементов. Так вы сможете снизить конкуренцию за процессорное время и повысить быстродействие отчета. Также мы узнали, что действия пользователя в  интерактивном отчете могут приводить к  отправке множества запросов. Как следствие это может приводить к серьезным проблемам с производительностью при работе с объемными наборами данных и наличием большого количества визуальных элементов и сложных мер, поскольку каждый щелчок мышью способен инициировать отправку множества запросов, с  которыми источнику будет справиться нелегко. Вы должны принимать все меры, позволяющие снизить плотность общения отчета с набором данных посредством запросов, включая использование отчетов с  детализацией по требованию и  объединение посылаемых запросов при помощи кнопок Применить. Далее мы узнали, как при помощи дашбордов в Po­wer BI можно агрегировать данные из различных отчетов и использовать кеширование для повышения быстродействия. Попутно отметили, что обновление плиток после запланированного обновления может негативно сказаться на общем времени обновления и комфорте для пользователей, особенно при наличии емкости Premium. В завершение главы мы познакомились с отчетами с разбивкой на страницы и узнали, как можно извлечь преимущество из использования реляционного источника данных. В следующей главе мы подробно поговорим о  процессе моделирования данных, и это будет одна из важнейших тем в книге. Просчеты при моделировании могут обойтись разработчику очень дорого и свести на нет все усилия по оптимизации отчетов.

Часть

IV

Модели данных, вычисления и работа с объемными наборами В этой части книги мы научимся проектировать эффективные и интуитивно понятные модели данных, избегая использования неоптимальных связей и вычислений DAX. Мы также узнаем, как можно использовать агрегаты и составные модели для работы с большими наборами данных. Содержание этой части:   глава 10 «Моделирование данных и безопас­ность на уровне строк»;   глава 11 «Улучшаем DAX»;   глава 12 «Шаблоны работы с большими данными».

Глава

10

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

Построение эффективных моделей данных    183

Технические требования Для некоторых примеров из этой главы мы подготовили сопроводительные материалы, на которые будем ссылаться при обсуждении тех или иных приемов. Все нужные файлы располагаются в папке Chapter10 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BI-Performance-Best-Practices.

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

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

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

Таблица измерения

Таблица измерения

Таблица измерения Таблица фактов

Таблица измерения

Таблица измерения

Рис. 10.1    Схема «звезда»

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

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

Построение эффективных моделей данных    185

личество часов отпуска по сотрудникам, но при этом иметь возможность посмотреть детализацию бронирований вплоть до даты начала отпуска. Сейчас нам нужно определиться с таблицами фактов и измерениями и разработать схему данных. 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) могут содержать избыточные повторяющиеся значения. Группировка значений, в сущности, осуществляется для упрощения бизнес-аналитики, а повторяющиеся значения не представляют большой проб­

186    Моделирование данных и безопасность на уровне строк лемы для колоночного хранилища вроде Analysis Services, поскольку они хорошо сжимаются. Концепция группировки данных показана на рис. 10.3, где продемонстрированы нормализованная и денормализованная версии измерения сотрудников. Таблица: Employee

Таблица: Role

Таблица: Employee_Role

Измерение: Employee

Рис. 10.3    Денормализация трех таблиц в единое измерение сотрудников

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

Рис. 10.4    Таблица фактов Leave Booking

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

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

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

Budgets

Рис. 10.5    Дубликаты в ключевых столбцах в таблицах Calendar и Budgets

Это вполне допустимый сценарий, который может присутствовать в моделях в самых разных вариациях. При попытке создать в Po­wer BI связь между столбцами с  дублирующимися значениями вы обнаружите, что тип связи можно указать только «многие ко многим», как показано на рис. 10.6.

188    Моделирование данных и безопасность на уровне строк

Рис. 10.6    Настройка связи «многие ко многим»

После указания корректного типа связи Po­wer BI начнет отображать правильные результаты в визуальных элементах. К примеру, если вывести суммарные значения по полю Budget с использованием среза по полю MonthName из таблицы Calendar, вы получите правильные числа, что видно по рис. 10.7.

Построение эффективных моделей данных    189

Рис. 10.7    Правильные расчеты с использованием связи типа «многие ко многим»

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

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

190    Моделирование данных и безопасность на уровне строк

Рис. 10.8    После добавления таблицы-моста связи обрели тип «один ко многим»

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

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

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

Построение эффективных моделей данных    191

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

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

Построение эффективных моделей данных    193









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

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

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

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

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

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

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

Рис. 10.10    Типичное измерение с иерархией в Po­wer BI

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

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

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

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

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

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

Измерение: Geography

Таблица фактов: Sales

Таблица безопасности: SEC_ProductGroup

Измерение: ProductGroup

Рис. 10.11    Фильтрация одной таблицы фактов несколькими измерениями с применением правил безопас­но­сти

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

198    Моделирование данных и безопасность на уровне строк Таблица безопасности: 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 RLS.pbix Роль Super Man 4 RLS Combined.pbix Без RLS 2 RLS Combined.pbix Роль Super Man 2

Движок хранилища (мс) 1 8 1 1

Запросы движка хранилища 1 16 1 1

Общее время (мс) 4 12 3 3

Заключение    199

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

Измерение: Users

Измерение: Geography

Таблица фактов: Sales M2M

Двунаправленная. Направление = Оба

Рис. 10.13    Объединение пользователей и разрешений

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

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

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

Глава

11 Улучшаем DAX

В предыдущей главе мы сконцентрировали внимание на наборах данных в режиме Import применительно к визуальному слою Po­wer BI, и ключевым выводом стала необходимость снижения нагрузки на источники данных путем минимизации сложности и количества запросов, поступающих в датасет Po­wer 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-PowerBI-Performance-Best-Practices.

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

Процесс отладки выражений DAX В главах 5 и 6 мы говорили о том, как можно использовать вспомогательные инструменты для отслеживания производительности решений. Некоторые из этих инструментов применимы для отладки выражений DAX. Ниже мы приводим список шагов по настройке и проверке формул DAX. 1. Редактировать выражения DAX можно непосредственно при работе с набором данных. В идеале при этом нужно пользоваться инструментом Best Practice Analyzer (BPA) для поиска возможных улучшений. В следующем разделе мы рассмотрим оптимальную методику работы с этим инструментом, но в идеале вы должны проверять все правила вручную. 2. Ранжируйте предположения об изменениях по степени прилагаемых усилий от низшего к  высшему. Рассмотрите вариант переноса некоторых вычислений и даже промежуточных результатов в Power Query. Обычно это лучшее место для произведения построчных вычислений. 3. В окружении разработки вы можете вносить простые изменения, но всегда необходимо проверять, что в результате меры возвращают корректные результаты. 4. Тестируйте быстродействие страниц отчетов и визуальных элементов при помощи инструмента Po­wer 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 ему удастся не всегда. Лучше для выполнения подобных вычислений пользоваться переменными. Заметьте, что мы здесь не перехватываем ошибки и не выполняем прочую оптимизацию:

204    Улучшаем DAX 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 тыс. строк в таблице фактов эта разница вряд ли будет ощутимой. Но при больших объемах данных и более сложных мерах, особенно если их результаты будут использоваться в других мерах, отображаемых одновременно, снижение производительности утаить не удастся.

Ловушки DAX и способы оптимизации    205

В мере YoY% не используется переменная

В мере YoY% используется переменная

Рис. 11.2    С использованием переменной длительность и объем вычислений уменьшились Использование переменных – это, вероятно, самый важный совет при оптимизации выражений DAX, поскольку повторные вычисления в формулах встречаются достаточно часто. Кроме того, вы заметите, что при написании кода за вас – например, при создании быстрых мер – Po­wer  BI также активно использует этот и  многие другие приемы по оптимизации запросов.

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

Но вместо этого вы можете использовать функцию DIVIDE(), как показано ниже: Profit DIVIDE = DIVIDE([Profit], [Sales])

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

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

Эта версия использует / и условную логику

Эта версия использует функцию DIVIDE()

Рис. 11.3    DAX Studio доказывает эффективность использования функции DIVIDE

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

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

Ловушки DAX и способы оптимизации    207

'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.

208    Улучшаем DAX

Обычная мера Sales

Измененная мера с заменой пустых значений нулями

Рис. 11.5    Снижение производительности при замене пустых значений нулями

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

Рис. 11.6    Отображение элементов без данных

Ловушки DAX и способы оптимизации    209

Еще одним преимуществом этого подхода является то, что вам не придется беспокоиться о производительности каждый раз, когда используется эта мера. В результате вы сможете сбалансировать быстродействие системы в зависимости от потребностей пользователей. Если вам все же необходимо реализовать замену пустых значений в мерах, вы можете сделать это для определенного диапазона данных. Мы рекомендуем вам ознакомиться со статьей на сайте 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.

210    Улучшаем DAX

Используйте функции 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") )

Ловушки DAX и способы оптимизации    211

С целью повышения эффективности рекомендуется заменить в качестве параметра функции табличное выражение на булево, как показано ниже: 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 из новой таблицы. При этом мы не можем создать связь между таблицами на основании более чем одного ключевого столбца.

212    Улучшаем DAX

Рис. 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]),

Заключение    213 'Dimension Customer'[Buying Group], 'Dimension Customer'[Postal Code] ) )

Мы не продемонстрировали версию меры с использованием функции INTERSECT  – можем лишь сказать, что она будет чуть короче, чем с  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 можно применять обновления к  набору данных и тестировать отчеты на рабочих сценариях для сравнения показателей.

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

Глава

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

В предыдущей главе мы говорили о важности проведения оптимизации выражений DAX. Таким образом, к  этому моменту мы обсудили аспекты повышения производительности практически для всех слоев решений на базе Po­wer BI: от наборов данных до отчетов. В этой главе мы сделаем шаг назад и снова поговорим об архитектурных концепциях и связанных с ними возможностях, которые помогут в работе с действительно большими объемами данных. Количество информации, собираемое и обрабатываемое в организациях, постоянно растет. С  появлением концепции интернета вещей (Internet of Things – IoT) в некоторых областях промышленности, таких как энергетика и управление ресурсами, объемы накапливаемых данных стали превышать все мыслимые пределы. Для любой современной угледобывающей компании или газоперерабатывающего завода наличие десятков тысяч датчиков, собирающих информацию с высокой степенью гранулярности (гораздо чаще, чем раз в секунду), – обычная практика. Даже с учетом самых мощных технологий сжатия данных, применяющихся в Po­wer BI, не всегда можно загрузить и сохранить такие объемы информации в  режиме Import за приемлемое время. И  масштабы проблем возрастают, когда вам необходимо поддерживать одновременную работу сотен или тысяч пользователей. В данной главе мы поговорим о способах борьбы с этими трудностями, включая использование емкостей Po­wer  BI Premium, технологий Azure, а также составных моделей и  агрегатов. Концепции, которые мы будем обсуждать, являются взаимодополняемыми и при необходимости могут быть использованы совместно в одном решении. В этой главе мы обсудим следующие темы:   масштабирование при помощи Po­wer BI Premium и Azure Analysis Services;   масштабирование с использованием составных моделей и агрегатов;   масштабирование с Azure Synapse и Data Lake.

216    Шаблоны работы с большими данными

Технические требования Для этой главы мы подготовили один составной файл с примерами, который называется Composite and Aggs.pbix. Его можно найти в папке Chapter12 в хранилище GitHub по адресу https://github.com/PacktPublishing/Microsoft-Power-BIPerformance-Best-Practices. Поскольку в этом файле используется режим DirectQuery для доступа к базе данных SQL Server, мы включили в список файлов бэкап базы с именем AdventureWorksLT2016.bak. Вы можете восстановить базу данных из этого бэкапа в  SQL Server и  обновить подключение в  Po­wer  BI Desktop для успешного запуска примеров.

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

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

Масштабирование при помощи Po­wer BI Premium и Azure Analysis Services    217

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

На рис. 12.1 показана опция настройки Формат хранения крупных наборов данных (Large dataset storage format) применительно к опубликованному датасету. Этот переключатель можно найти на вкладке наборов данных в рабочей области Po­wer BI. Для отключения ограничения на размер набора данных установите переключатель в положение Вкл (On).

Рис. 12.1    Настройка формата хранения крупных наборов данных

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

218    Шаблоны работы с большими данными Но ничто не вечно и не бесконечно, и при наличии емкости 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 производится только по факту использования услуги, кроме того, вы можете приостановить действие службы и  масштабировать свой пакет по необходимости. Также вы сможете пользоваться полноценной поддержкой инструментов разработчика Po­wer BI Pro, таких как Microsoft Visual Studio с системой контроля версий и возможностью интеграции с CI/CD (непрерывная интеграция и непрерывная поставка). Как и SQL Server Analysis Services, AAS включает в себя только движок обработки данных, так что его функции ограничены хранением наборов данных и  их обработкой. Таким образом, для размещения отчетов вам по-прежнему придется пользоваться клиентским инструментом, таким как Po­wer BI Desktop или портал PowerBI. com. Службу AAS можно рассматривать как подкласс емкости Premium, но на сегодняшний день это не совсем так. Причина – в таких серьезных отличиях, как динамическое управление памятью, присутствующее только в емкости Premium, и  технология горизонтального масштабирования запросов (Query Scale Out – QSO), доступная лишь в  AAS. Эта технология позволяет увеличить количество одновременно работающих с системой пользователей с минимальными накладными расходами, и  на сегодняшний день ее очень не хватает в емкости Premium. В то же время не может не радовать заявленное стремление компании Microsoft сделать емкость Premium своеобразной расширенной версией AAS.

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

Масштабирование при помощи Po­wer BI Premium и Azure Analysis Services    219

распределения нагрузки чтения запросов между несколькими репликами данных. Вы просто настраиваете службу на создание дополнительных копий данных (максимальное количество копий ограничено семью). В  результате поступающие подключения от клиентов распределяются по созданным репликам. Обратите внимание, что не все регионы использования и планы 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 и  ограничением

220    Шаблоны работы с большими данными в 40 единиц. Как видите, в данный момент никаких критических всплесков в этой области не наблюдается.

Рис. 12.3    Отслеживание метрики QPU на портале Azure

Теперь посмотрим, как использование секционирования может повысить эффективность обновлений.

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

Масштабирование при помощи Po­wer BI Premium и Azure Analysis Services    221

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

Таблицы, определенные в наборе данных Po­wer BI, по умолчанию состоят из одной секции. У  вас нет возможности напрямую управлять процессом секционирования в  Po­wer  BI Desktop. Однако при настройке добавочного обновления секции создаются автоматически, а за основу берутся настройки гранулярности времени и актуальности данных. Таким образом, при использовании AAS или Po­wer BI Premium вам понадобится обратиться к  внешним инструментам для управления секциями. Например, в процессе разработки секции могут быть созданы в Visual Studio – для этого нужно воспользоваться инструментом 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, и мы рекомендуем придерживаться этого подхода.

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

Рис. 12.4    Свойство ReplicaSyncMode было изменено

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

В следующем разделе мы посмотрим, как в Po­wer BI можно эффективно использовать составные модели для решения проблем с большими данными и медленными запросами DirectQuery.

Масштабирование с использованием составных моделей и агрегатов    223

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

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

224    Шаблоны работы с большими данными менить тип модели вручную на вкладке Модель (Model) в Po­wer BI Desktop, как показано на рис. 12.6.

Рис. 12.5    Информация о режиме хранения модели в Po­wer BI Desktop

Рис. 12.6    Изменение режима хранения модели в Po­wer BI Desktop

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

Масштабирование с использованием составных моделей и агрегатов    225

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

226    Шаблоны работы с большими данными 3. Связи типа «многие ко многим». 4. Связи между разными источниками данных (самые медленные). Далее мы перейдем к теме агрегатов и их связи с составными моделями данных.

Использование агрегатов В подавляющем большинстве аналитических сценариев в  том или ином виде используются агрегированные данные. Обычно принято анализировать исторические тренды, отклонения и выбросы в обобщенном виде, после чего при необходимости углубляться в детализацию. Давайте в качестве примера рассмотрим работу логистической компании по отслеживанию тысяч отправок. Вряд ли вы можете себе представить, что базовый анализ компании может начинаться с детализации до конкретной посылки. Скорее всего, изначально аналитика строится с группировкой по типу транспортировки или региону. В случае появления цифр, не отвечающих определенным критериям, можно углубиться в данные в поисках причин отклонений. В главе 9 мы подробно говорили о таком методе анализа как одном из наиболее эффективных и удобных. При всем этом вы можете следовать всем рекомендациям при проектировании модели, но все равно столкнуться с  проблемами быстродействия отчетов при использовании объемных наборов данных в режиме DirectQuery. Даже с учетом проведения всех оптимизаций существует физический предел в отношении обработки данных с использованием ограниченных ресурсов компьютера. В таких ситуациях на помощь приходят агрегаты (aggregations), реализованные в Po­wer 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

После создания таблицы необходимо сообщить Po­wer BI о том, как ее нужно использовать. Щелкните правой кнопкой мыши по таблице OrderDetail

Масштабирование с использованием составных моделей и агрегатов    227

и выберите пункт Управление агрегированием (Manage aggregations). В открывшемся диалоговом окне выполните настройки, показанные на рис. 12.7.

Рис. 12.7    Настройка агрегата для таблицы OrderDetail

Здесь необходимо сделать несколько пояснений. Во-первых, нам необходимо дать понять Po­wer BI, какую именно таблицу мы хотим использовать в качестве агрегата для таблицы OrderDetail. Во-вторых, нужно установить соответствие между столбцами и задать тип используемой агрегации. Также мы можем установить определенное значение в  поле Приоритет (Precedence) на случай, если у нас будет несколько агрегатов для разных гранулярностей. Таким образом, мы устанавливаем порядок использования агрегатов в  том случае, если значение может быть получено из разных агрегатных таблиц. После создания агрегата остается только установить связь между агрегатной таблицей и измерением Product, как показано на рис. 12.8.

Рис. 12.8    Таблица Agg_SalesByProduct в режиме импорта связана с таблицей Product в смешанном режиме

228    Шаблоны работы с большими данными Заметьте, что сама агрегатная таблица и  все ее столбцы в  наборе данных Po­wer BI являются скрытыми. Это происходит по умолчанию, чтобы не вводить пользователей в заблуждение. Агрегатные таблицы действительно можно не показывать и  полагаться на движок, который в  нужный момент будет выбирать данные из нужной таблицы. В этом примере мы продемонстрировали работу агрегатов на основании связей. Мы полагаемся на связь, благодаря которой значения из таблицы Product могут фильт­ ровать таблицу OrderDetail. При добавлении агрегатной таблицы нам нужно было создать эту связь. В то же время в системах обработки больших данных, основанных на Hadoop, данные зачастую хранятся в широких денормализованных таблицах во избежание создания ресурсоемких объединений таблиц во время выполнения запросов. Для таких сценариев в Po­wer BI мы также можем использовать агрегатные таблицы, но без необходимости создания связей.

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

Рис. 12.9    Разные группировки с продажами для проверки агрегатов

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

Масштабирование с использованием составных моделей и агрегатов    229

Рис. 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

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

Без агрегатов 80 мс 155 мс 340 мс

С агрегатами 3 мс 5 мс 500 мс

Комментарии С агрегатом намного быстрее С агрегатом намного быстрее С агрегатом вышло медленнее из-за накладных расходов на обращение к разным источникам с небольшим объемом данных

В нашем примере создать и  воспользоваться агрегатом было довольно просто. На практике же бывает весьма сложно предсказать заранее сложность, объем и частоту запросов, которые будут сгенерированы в результате выполнения операции. Это значительно затрудняет задачу заблаговременного планирования создания агрегатов. Зная эту проблему, компания Microsoft выпустила автоматические агрегаты (automatic aggregations) в помощь пользовательским. При создании этих агрегатов используются методы машинного обучения, базирующиеся на поведении пользователей. Это может значительно облегчить процесс управления агрегатами при правильном подходе. В  настоящее время автоматические агрегаты доступны в  Po­wer  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.

232    Шаблоны работы с большими данными

Современная архитектура хранилища данных Комбинировать концепции ETL, ELT и  аналитики больших данных можно с  использованием гибридной архитектуры хранилища данных (hybrid data warehouse architecture) на основе озера данных. Озеро данных (data lake) можно себе представить как место дислокации сырых данных. К данным в озере конечные пользователи обычно не имеют прямого доступа. Данные, помещенные в озеро, могут использоваться по-разному в зависимости от конечной цели. К примеру, специалисту по обработке данных может понадобиться провести анализ сырых данных и  создать на их основании наборы данных для моделей машинного обучения. С другой стороны, участники команды бизнес-аналитиков могут с  определенной периодичностью выгружать данные, преобразовывать их по собственным алгоритмам и хранить, к примеру, в базе данных SQL Server. На рис. 12.13 в очень упрощенном виде показана коллекция компонентов Azure, из которых может состоять современное хранилище данных. Модель и обслуживание PolyBase

Логи, файлы и медиа (неструктурированные) Бизнес/пользовательские приложения (структурированные)

Azure Synapse Analytics (Synapse SQL)

Загрузка

Хранение

Подготовка и обучение

Azure Synapse Analytics (конвейеры)

Azure Data Lake Storage

Azure Synapse Analytics (Apache Spark)

Azure Analysis Services

Power BI

Рис. 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 с помощью Po­wer BI. Представленные выше шаги выполняются по порядку, а на рис. 12.13 показаны лишь некоторые связи между компонентами. Это сделано в  целях обучения, для демонстрации схемы движения данных в рабочем окружении. В реальных условиях некоторые шаги допустимо пропускать или связывать компоненты иначе – в зависимости от сценария и навыков пользователя. К примеру, инженер данных вполне может под-

Масштабирование с Azure Synapse и Azure Data Lake    233 ключиться из Po­wer 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: веб-окружение, способное обслуживать большое количество пользователей. С помощью этой службы пользователи могут загружать, преобразовывать и визуализировать данные;   интеграция с  Po­wer  BI: вы можете связывать рабочие области Po­ wer BI с вашей рабочей областью Synapse в Synapse Studio. После этого можно анализировать данные из служб Synapse с  помощью Po­wer  BI внутри Synapse Studio;   интеграция с  ноутбуками: Synapse Studio поддерживает ноутбуки Python в отношении интерактивного анализа и документации данных;   бессерверный и  выделенный пулы SQL: эти службы предоставляют доступ к структурированному хранилищу SQL Server в облаке. Бессерверному пулу (serverless pool) требуется незначительная настройка и управление – вам нет необходимости предоставлять сервер, службу

234    Шаблоны работы с большими данными автомасштабирования, и вы платите за каждый запрос. Выделенный пул (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 и способами их использования для масштабирования данных, пришло время подвести итоги этой главы.

Заключение В этой главе мы узнали, как справляться с действительно огромными объемами данных. Сперва мы рассмотрели случаи, когда ваш набор данных в Po­wer BI превышает 1 Гб, допустимый при использовании общей емкости, и порекомендовали переход на емкости Po­wer BI Premium, ограничение в которых установлено на отметке 10 Гб. Мы также отметили, что с использованием формата хранения крупных наборов данных объем ваших датасетов может легко превышать и эти лимиты. Чисто технически вы можете задействовать всю доступную для вашей емкости память, а  для плана Premium P5 она составляет 400 Гб. Кроме того, емкости Premium предлагают расширенные возможности по использованию параллелизма, что положительно сказывается на производительности обновлений и запросов.

Заключение    235

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

236    Шаблоны работы с большими данными

Материалы для чтения Заметьте, что в Synapse, как и в Po­wer BI, предусмотрено большое количест­ во опций и настроек, связанных с производительностью. Ниже приведены материалы для самостоятельного изучения этих настроек (все инструкции переведены на русский):   рекомендации по использованию бессерверного пула SQL в Azure Synapse Analytics: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/ sql/best-practices-serverless-sql-pool;   рекомендации по использованию выделенных пулов SQL в Azure Synapse 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-analytics/sql-data-warehouse/sql-data-warehouse-concept-recommendations;   оптимизация производительности с  помощью материализованных представлений на основе выделенного пула SQL в Azure Synapse Analytics: https://learn.microsoft.com/ru-ru/azure/synapse-analytics/sql/develop-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-datawarehouse/performance-tuning-result-set-caching;   оптимизация производительности запросов к  хранилищу данных в Azure Synapse Analytics: https://learn.microsoft.com/ru-ru/training/modules/optimize-data-warehouse-query-performance-azure-synapse-analytics;   руководство по настройке производительности потоков данных в  Synapse: https://learn.microsoft.com/ru-ru/azure/data-factory/concepts-data-flow-performance?context=%2Fazure%2Fsynapseanalytics%2Fcontext%2Fcontext.

Часть

V

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

Глава

13

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

Возможности Premium, использование ресурсов и автомасштабирование    239

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

Возможности Premium, использование ресурсов и автомасштабирование Лицензия Po­wer 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 Services, оптимизированных для печати;   конечные точки XMLA: доступ к API для автоматизации и пользовательской настройки развертывания/обновления;   приложение Life Cycle Management (ALM): использование кон­вейе­ ров развертывания, управление разработкой и оценка версий в виде приложения;   улучшенные возможности применения искусственного интеллекта: анализ текста и изображений, а также автоматизированные методы машинного обучения;   межрегиональное развертывание: вы можете развертывать емкости Premium в разных регионах с целью удовлетворения требований в отношении суверенности данных (data sovereignty);   применение модели Bring Your Own Key (BYOK): вы можете использовать собственный ключ шифрования для обеспечения безопас­но­сти данных. Теперь давайте посмотрим, как емкости Premium используют ресурсы и что происходит при увеличении требований и нагрузок.

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

Возможности Premium, использование ресурсов и автомасштабирование    241

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

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

242    Оптимизация емкостей Premium и Embedded

Рис. 13.1    Настройки емкости Premium, влияющие на производительность

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

Возможности Premium, использование ресурсов и автомасштабирование    243

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

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

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

Порог емкости = 120 процессорных секунд

Процессорные секунды (не в масштабе)

120

Доступная емкость Пользовательский запрос Пользовательский запрос Пользовательский запрос Обновление B = 2 процессорные секунды на цикл вычисления

7 5

Обновление A = 5 процессорных секунд на цикл вычисления

0 1:00 А

4:00 B

9:00 C

Время (не в масштабе)

D

Рис. 13.2    Оценка нагрузки на емкость P1 в разные временные промежутки (от A до D) Поскольку нагрузка от фонового обновления равномерно распределяется по 2880 цик­ лам вычисления, на рис. 13.2 и 13.5 корректно будет отобразить ее в виде константы после завершения операции. Что касается пользовательских запросов, нагрузка от них будет переменной для каждой операции. Однако для простоты картины мы решили отображать эти нагрузки как постоянные.

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

Возможности Premium, использование ресурсов и автомасштабирование    245

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 поведение емкости изменилось во избежание таких эксцессов. На первый взгляд может показаться, что переход в режим отсрочки может быть еще более губительным для системы, но на самом деле это не так. Пользователь, работающий в таком режиме, заметит задержку при обработке интерактивных запросов по сравнению с ненагруженной системой. Зато вероятность успешного завершения запросов в  таком случае существенно

246    Оптимизация емкостей Premium и Embedded повышается. Причина в том, что режим отсрочки дает емкости возможность завершить все активные процессы, не нагружая ее излишне запросами, которые в результате могут привести к отказу. На рис. 13.3 показано, как работает режим отсрочки. Обратите внимание, что в цикле A нам понадобилось больше ресурсов, чем было выделено, – это видно по интерактивным запросам, расположенным выше порогового уровня в 120 процессорных секунд. В связи с этим в цикле B все новые запросы будут временно поставлены на паузу, что позволит сохранить работоспособность системы и ощущение относительного комфорта для пользователя. Перегрузка Интерактив

120

Интерактив Интерактив ОТСРОЧКА Интерактив

Интерактив Интерактив

Процессорные секунды

Интерактив Интерактив Фоновые операции 0 А

B

Рис. 13.3    Интерактивные операции в цикле B получили отсрочку из-за перегрузки в цикле A

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

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

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

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

Рис. 13.4    Настройки автомасштабирования для связывания подписки Azure и выделения виртуальных ядер

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

Перегрузка

Новый порог емкости Интерактив

Интерактив

120

Интерактив Интерактив Интерактив

Процессорные секунды

Интерактив Интерактив Интерактив Фоновые операции 0 А

B

Рис. 13.5    Выделение дополнительного виртуального ядра при настройке автомасштабирования

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

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

Планирование емкости, мониторинг и оптимизация    249

Определение исходного размера емкости Ранее в  этой главе мы упоминали, что емкости Po­wer  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

Общее кол-во вирт. ядер EM1/A1 1 EM2/A2 2 EM3/A3 4 P1/A4 8 P2/A5 16 P3/A6 32 P4/A7 64 P5/A8 128

Серверные Интер­ фейсные ядра ядра 0,5 0,5 1 1 2 2 4 4 8 8 16 16 32 32 64 64

Память (Гб) 3 5 10 25 50 100 200 400

Подключения DirectQuery/ Live в секунду 3,75 7,5 15 30 60 120 240 480

Макс. память на запрос (Гб) 1 2 2 6 6 10 10 10

Параллелизм обновлений 5 10 20 40 80 160 320 640

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

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

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

Планирование емкости, мониторинг и оптимизация    251

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

252    Оптимизация емкостей Premium и Embedded "filterTable":"DimDate", "filterColumn":"Quarter", "isSlicer":false, "filtersList":["Q1","Q2","Q3","Q4"] } ], &"thinkTimeSeconds":1 };

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

Планирование емкости, мониторинг и оптимизация    253

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

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

254    Оптимизация емкостей Premium и Embedded

Рис. 13.6    Настройки оповещений емкости

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

Планирование емкости, мониторинг и оптимизация    255

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

256    Оптимизация емкостей Premium и Embedded

Рис. 13.7    Общий вид приложения для отслеживания метрик емкости

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

Планирование емкости, мониторинг и оптимизация    257

Рис. 13.8    Пример всплывающей подсказки

4. В отчете в удобном виде представлена информация о том, какие объекты больше всего нагружают систему. В данном случае мы видим, что большая часть нагрузки на процессор пришлась на датасет с названием Customer360 TEST. Для получения детальной информации вы можете опуститься на уровень операций. 5. Вы должны регулярно отслеживать значения метрик Artifact Size и Overloaded Minutes. Это даст вам понять, какие объекты занимают больше всего места и  генерируют наибольшую нагрузку. Для нашей емкости EM1 предельный объем набора данных равен 3 Гб, так что наш датасет может спокойно уместиться в памяти. При приближении размера набора данных к означенному пределу нам необходимо будет предпринять определенные действия. Помните, что память, выделяемая для набора данных, учитывает операции обновления и запускае­ мые запросы. Если объем датасета приближается к пороговому значению, возможно, вы не оставляете достаточно памяти для избежания перегрузок. 6. На этом визуальном элементе отображаются пиковые значения памяти, которую занимали объекты набора данных в рамках 3-часовых интервалов. Здесь мы видим, что в двух временных периодах мы превышали лимит на параллельные обновления. В таких случаях следует дополнительно исследовать, какие обновления выполнялись и возникали ли пересечения, приведшие к отсрочке обновлений, повлиявшей на общую производительность.

258    Оптимизация емкостей Premium и Embedded 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 показан развернутый вид диаграммы по объектам для двух самых ресурсоемких элементов.

Планирование емкости, мониторинг и оптимизация    259

Рис. 13.9    Подробные диаграммы по нагрузке

Рис. 13.10    Детализированный вид отчета по объектам и операциям

260    Оптимизация емкостей Premium и Embedded Исходя из путей объектов, выделенных жирным шрифтом, понятно, что оба объекта представляют собой наборы данных в  рабочей области LoadTest. Как мы видим, в первом наборе данных присутствуют только запросы (Query), и мы зафиксировали перегрузку. Во втором наборе производились и другие операции, и при этом нагрузка на центральный процессор оказалась намного меньше. Пойдем дальше и щелкнем правой кнопкой мыши по объекту Customer360 TEST, чтобы открылась страница с детализацией, показанная на рис. 13.11. Здесь вы можете обнаружить неожиданные всплески активности и наблюдать за тенденциями. Всплески при этом можно проанализировать более детально на других страницах, о которых мы скажем позже. На рис. 13.11 мы видим почасовую расшифровку для указанного набора данных по разным метрикам и  операциям. С  помощью этих графиков вы можете выяснить, были ли всплески активности связаны с резким увеличением количества пользователей, запуском других активностей в емкости или иными факторами.

Рис. 13.11    Детализация до объекта с тенденциями по часам

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

Планирование емкости, мониторинг и оптимизация    261

Рис. 13.12    Детализация до конкретной точки во времени

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

262    Оптимизация емкостей Premium и Embedded

Рис. 13.13    Детализация до операций

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

Планирование емкости, мониторинг и оптимизация    263

должительные обновления с высоким показателем 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 мы видим повышение активно-

264    Оптимизация емкостей Premium и Embedded сти. При достижении нагрузки в 150 %, допустимой с одним дополнительным ядром, система ввела отсрочку для некоторых запросов на время выделения дополнительных ресурсов. Причина в том, что дополнительные ядра не используются до тех пор, пока не понадобится помощь в борьбе с перегрузкой.

Рис. 13.15    Страница Refresh с информацией об обновлениях

Рис. 13.16    Страница Timepoint Detail на момент выделения одного дополнительного ядра

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

Планирование емкости, мониторинг и оптимизация    265

Рис. 13.17    Страница Timepoint Detail на момент выделения четырех дополнительных ядер

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

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

266    Оптимизация емкостей Premium и Embedded системы, и без вертикального или горизонтального масштабирования здесь не обойтись. 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/embedded/monitor-power-bi-embedded-reference.

Теперь подведем итоги этой главы и  перейдем к  заключительной главе книги.

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

Заключение    267

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

Глава

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

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

Повышение производительности внедрения    269

Повышение производительности внедрения Встраивание содержимого во внешние приложения дает организации определенную гибкость в  отношении развертывания и  распространения контента Po­wer  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    Встраивание содержимого Po­wer BI во внешние приложения

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

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

Повышение производительности внедрения    271

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

272    Встраивание в приложения









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

Измерение производительности внедрения    273

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

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

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

274    Встраивание в приложения   Loaded: это событие возникает в  момент окончания инициализации отчета или дашборда Po­wer BI. Загрузка считается завершенной, когда исчезает логотип, показанный на рис. 14.2;

Рис. 14.2    Логотип Po­wer BI и индикатор прогресса, отображаемые в процессе загрузки отчета

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

Заключение    275 Нажатие на кнопку для загрузки встроенного отчета Загрузка отчета Power BI Инициализация Загрузка визуального элемента A Загрузка визуального элемента В Время Пользовательское событие старта

Loaded

VisualRendered (A)

Пользовательское событие финиша

VisualRendered (В) Rendered

Рис. 14.3    Хронология событий в пользовательском приложении

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

276    Встраивание в приложения достижения наилучших результатов с точки зрения эффективности. Мы также упомянули о методах API, предоставленных компанией Microsoft, с помощью которых можно осуществить предварительную загрузку необходимых компонентов, включая файлы JavaScript и CSS, для ускорения процесса внед­рения. Сказали мы и о возможности конфигурирования процесса встраивания, что позволяет, например, указать минимальные разрешения для пользователя и, следовательно, загружать только необходимые компоненты. После этого мы узнали о  том, что встраиваемый контент в  приложениях выводится посредством стандартных элементов iFrame. Мы рассказали о важности использования как можно меньшего количества таких контейнеров по причине того, что каждый из них использует драгоценные ресурсы. В свете этого порекомендовали консолидировать информацию в меньшее количество отчетов, а также использовать для встраивания дашборды и плитки, что позволит снизить время загрузки контента. Наконец, мы научились измерять производительность механизма встраивания. В процессе были представлены события, возникающие в приложении, и  сказано о  необходимости их использования с  целью получения полной картины происходящего. Это позволит определить длительность каждой конкретной операции и  полноценно проанализировать процессы инициализации отчета, а также отрисовки всех визуальных элементов и каждого из них по отдельности.

Послесловие Поздравляем! Наше путешествие в мир оптимизации Po­wer BI подошло к логическому завершению, и теперь вы должны быть готовы применить все полученные знания и навыки на практике. А завершить хочется напоминанием о  том, что управление производительностью должно стать неотъемлемой частью каждого процесса в  жизненном цикле ваших решений. И  наилучших результатов вы сможете добиться только при планировании и тесном сотрудничестве со всеми специалистами, способными внести свой вклад в оптимизацию ваших проектов!

Предметный указатель A AAS, 82, 218 ADLS, 233 ADLS Gen2, 233 Advanced Scripting, 114 Apache Spark, 234 Azure Analysis Services, 82, 218 Azure Data Lake, 160 Azure Data Lake Storage, 233 Azure ExpressRoute, 51 Azure Log Analytics, 81 Azure Synapse, 233

B Best Practice Analyzer, 113 BI-система самообслуживания, 135 BLANK(), 211 bookmarks, 271 Bring Your Own Key, 240

C CALCULATE(), 190, 210 CALCULATETABLE(), 210 Cardinality, 36 CI/CD, 38 COMBINEVALUES(), 58 Composite model, 38 CONTAINS(), 211 COUNT(), 211 COUNTROWS(), 211 CPUUtilizationPercentageThreshold, 50 Current User Sessions, 82

customLayout, 273

D Data mart, 37 Data warehouse, 37 DAX, 178 DAX Studio, 118 DIVIDE(), 205

E ELT, 231 EmbedURL, 271 ETL, 231 Extract-Load-Transform, 231 Extract-Transform-Load, 231

F FILTER(), 210, 211 filters, 271 FIND(), 210

G GroupKind.Local, 151 GUID, 192

H Hadoop Distributed File System, 233 HASONEVALUE(), 209 Home region, 33 Hop, 28, 41

278    Предметный указатель

I iFrame, 271 INNER JOIN, 57 INTERSECT(), 211 ISBLANK(), 211

L layoutType, 273 List, 148 List.Buffer(), 148 Loaded, 274 LoadTestingPowerShellTool, 251 LOOKUPVALUE(), 196

M Mashup engine, 27, 40 MaxParallelism, 221 MDX, 178 Memory, 82 MemoryUtilizationPercentageThreshold, 50 M Engine Memory, 82 M Engine QPU, 82 MPP, 231

N Network latency, 28

O OUTER JOIN, 57

P P90, 25 Parquet, 231 Partition Manager, 221 Path, 195 PBIE, 82, 84 Performance Analyzer, 86 Permissions, 271 ping, 28 powerbi.bootstrap, 271 powerbi.embed, 271 Power BI Embedded, 82, 84 Power BI Helper, 110 powerbi.preload, 270 Power BI Report Builder, 178 Power BI service, 29 Power Query, 142 Power Query Online, 161

Premier Support, 46 Premium на пользователя, 240 Premium Capacity Utilization and Metrics, 254

Q QPU, 82 QSO, 218 QueryAggregationTimeInMinutes, 45 QueryExecutionAggregationReport, 44 QueryExecutionAggregationTimeIn­ Minutes, 44 QueryExecutionReport, 44 Query Pool Busy Threads, 83 Query Processing Units, 82 Query Scale Out, 218 QueryStartReport, 44

R RangeEnd, 152 RangeStart, 152 RDL, 177 RealisticLoadTestTool, 251 RELATED(), 100 Remove-OnPremisesDataGateway, 49 Rendered, 274 ReplicaSyncMode, 222 Report Definition Language, 177 ReportFileCount, 44 ReportFilePath, 44 ReportFileSizeInBytes, 44 ResourceUtilizationAggregationPeriodIn­ Minutes, 50 RLS, 194

S SEARCH(), 210 SELECTEDVALUE(), 209 sequence, 144 SKU, 249 Slicers, 271 SMP, 230 Spark Jobs, 234 SQL Server Management Studio, 221 SQL Server Profiler, 120 SQL Server Reporting Services, 177 Storage mode, 32 SUMMARIZE(), 210 SUMMARIZECOLUMNS(), 210 Synapse Studio, 233

Предметный указатель    279 SystemCounterAggregationReport, 45 SystemCounterAggregationTimeIn­ Minutes, 44

T Table, 148 Table.Buffer(), 148 Table.Group(), 151 Tabular Editor, 113 Tabular Model Scripting Language, 221 Throttling, 245 TREATAS(), 211

U Unified Support, 46

V VALUES(), 209 VAR, 204 V-core, 240 VertiPaq, 34, 118 VertiPaq Analyzer, 118 View Metrics, 118 VisualRendered, 274 visualRenderedEvents, 274 Visual Studio, 221

X xVelocity, 34

А Автомасштабирование, 246 Автоматические агрегаты, 230 Автоматическое обновление страниц, 43 Агрегат, 226 Агрегатная таблица, 226 Анализатор производительности, 86

Б Базовая мера, 112 Безопасность на уровне строк, 194 Бессерверный пул, 233 Большие данные, 231 Брандмауэр, 41

В Ведение логов, 43

Вертикальное масштабирование, 48 Визуальные элементы, 167 Виртуальная машина, 41, 98 Виртуальное ядро, 240, 247 Витрина данных, 37 Внешние инструменты, 109 Внешний ключ, 57 Всплывающая подсказка, 174 Встраивание, 268 Выделенный пул, 234 Вычисляемая сущность, 164 Вычисляемый столбец, 58

Г Гибридная архитектура хранилища данных, 232 Глобальный уникальный идентификатор, 59, 192 Горизонтальное масштабирование запросов, 218

Д Дашборд, 176 Движок обработки, 27, 40 Движок обработки Power Query, 143 Движок формул, 30, 122 Движок хранилища, 30, 122 Двунаправленная связь, 59, 112, 193 Денормализация, 185 Денормализованная таблица, 185 Дерево декомпозиции, 157 Диагностика запроса, 154 Динамические административные представления, 118 Динамический RLS, 194 Добавочное обновление, 152 Домашний регион, 33

Е Единица обработки запросов, 82 хранения, 249 Единственный источник истины, 37 Емкость Premium, 217

Ж Журнал аудита, 80 действий, 80

280    Предметный указатель

З

Н

Зависимости в мерах, 112 Загрузка фоновых данных, 145 Закрепление, 176

Направление кросс-фильтрации, 59 Неиспользуемое поле, 111 Нормализация, 183

И

О

Иерархия типа родитель–потомок, 195 Измерение, 56, 184 Имя участника-пользователя, 72 Индекс, 57 Интерактивный отчет, 167 Интернет вещей, 215, 231 Интерфейсные ядра, 243

Облачная реплика, 51 Общая емкость, 216 Общие наборы данных, 27 Ограничение, 57 Ограниченные связи, 225 Озеро данных, 232 Оптимизация запросов DAX, 202 Отчет с разбивкой на страницы, 167, 177

К Карточка, 170 Классическая рабочая область, 66 Кодирование на основе длин серий, 193 на основе значений, 193 со словарем, 193 Колоночное хранилище, 34 Конвейер, 232 Конечная точка XMLA, 81, 144 Контейнер вычисления, 143 Контекст строки, 100 Контрольные ожидаемые показатели, 130 Кратность, 36, 59, 191

П

Локальный шлюз данных, 39

Параметризация, 179 Параметры запросов, 145 Первичный ключ, 57 Перегрузка, 245 Перекрестное произведение, 197 Платформа как услуга, 218, 266 Подсказки, 151 Пользовательские оповещения, 253 Портал AppSource, 254 Поток данных, 160 Приемлемое время ожидания, 24 Процентиль, 25 Процессорное время, 243 Процессорные секунды, 243 Прыжки, 28 Прыжок, 41 Пул Spark, 234

М

Р

Максимальное состояние процессора, 96 Массово-параллельная обработка, 231 Масштабирование, 48 Материализованное представление, 63 Мера области запроса, 123 Метрики использования, 66 Многострочная карточка, 170 Моделирование данных, 54 Модель данных, 54 лицензирования, 249 с активным источником данных, 136 с пассивным источником данных, 135 Мощность, 191 Мусорное измерение, 197

Рабочая область второй версии, 66 Размерная модель, 184 Размерное моделирование, 164, 183 Ранжирующие функции, 173 Распорядитель данных, 137 Распределение ресурсов, 43 Расширенное ядро вычислений, 162, 239 Расширенный редактор, 146 Редактор Power Query, 54 Режим ограничения количества запросов, 245 отсрочки, 245 отсрочки интерактивных запросов, 245 синхронизации, 222 хранения, 32

Л

Предметный указатель    281 DirectQuery, 27, 36 Import, 26, 33 LiveConnect, 38 Live connection, 27 Реплика данных, 219 для чтения, 63 Ролевое измерение, 185

С Свертывание запросов, 149 Связь «один ко многим», 59 Сегмент, 193, 221 Секционирование, 220 Секционированные таблицы, 220 Серверные ядра, 243 Сетевая задержка, 28 Симметричная многопроцессорная обработка, 230 Системный счетчик, 43 Скрипт TMSL, 144 Служба отчетности SQL Server, 177 Power BI, 29 Смешанный режим, 223 Составная модель, 38, 223 Срез, 88 Ссылочная целостность, 57 Суверенность данных, 37, 240 Суррогатный ключ, 192 Схема «звезда», 184

Транзитные участки, 28

У Узел, 231 Универсальный уникальный идентификатор, 59 Управление производительностью, 128 Уровень конфиденциальности, 147

Ф Фильтрация, 179 Фильтр Ведущие N, 172 Формат хранения крупных наборов данных, 217 Функции буферизации, 148

Х Хинты запросов, 151 Хранилище данных, 37 Хранимая процедура, 178

Ц Целевые метрики, 25 Целевые показатели производительности, 23 Цикл вычисления, 243

Ш

Т

Шлюз, 27

Таблица, 170 безопасности, 194 отслеживания, 221 фактов, 184 Таблица-мост, 189 Табличная объектная модель, 221 Токены внедрения, 268

Э Эксклюзивная длительность, 157

Я Язык M, 142

Книги издательства «ДМК ПРЕСС» можно купить оптом и в розницу в книготорговой компании «Галактика» (представляет интересы издательств «ДМК ПРЕСС», «СОЛОН ПРЕСС», «КТК Галактика»). Адрес: г. Москва, пр. Андропова, 38, оф. 10; тел.: (499) 782-38-89, электронная почта: [email protected]. При оформлении заказа следует указать адрес (полностью), по которому должны быть высланы книги; фамилию, имя и отчество получателя. Желательно также указать свой телефон и электронный адрес. Эти книги вы можете заказать и в интернет-магазине: http://www.galaktika-dmk.com/.

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

Power BI: передовые методы оптимизации

Главный редактор



Зам. главного редактора Перевод Корректор Верстка Дизайн обложки

Мовчан Д. А.

[email protected]

Сенченкова Е. А. Гинько А. Ю. Синяева Г. И. Чаннова А. А. Мовчан А. Г.

Гарнитура PT Serif. Печать цифровая. Усл. печ. л. 22,91. Тираж 200 экз. Веб-сайт издательства: www.dmkpress.com