Планирование реализации Power BI: аудит на уровне данных

  • Статья

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется рабочей нагрузке Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

Эта статья аудита на уровне данных ориентирована на несколько аудиторий:

  • Создатели данных и администраторы рабочих областей: пользователи, которые должны понимать использование, внедрение и производительность семантических моделей (ранее известных как наборы данных), потоки данных и метки данных, которые они создают, публикуют и используют.
  • Администраторы Power BI: администраторы, ответственные за надзор за Power BI в организации. Администраторам Power BI может потребоваться совместная работа с ИТ,безопасностью, внутренним аудитом и другими соответствующими командами. Администраторы Power BI также могут сотрудничать с создателями содержимого при устранении неполадок с производительностью.
  • Администраторы емкости Power BI: администраторы, ответственные за надзор за емкостью Premium в организации. Администраторам емкости Power BI может потребоваться совместная работа с создателями содержимого при устранении неполадок с производительностью.
  • Центр превосходства, ИТ-отдела и группы бизнес-аналитики: команды, которые также отвечают за надзор за Power BI. Возможно, им потребуется сотрудничать с администраторами Power BI и другими соответствующими командами.
  • Системные администраторы: команда, которая отвечает за создание и защиту ресурсов Azure Log Analytics , а также администраторов баз данных, которые управляют источниками данных.

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

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

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

Так как семантические модели Power BI основаны на табличном механизме служб Analysis Services, вы можете подключиться к локальной модели данных (в Power BI Desktop) или семантической модели Premium (в служба Power BI), как если бы это база данных Служб Analysis Services. Поэтому для семантических моделей Power BI Premium поддерживаются многие возможности аудита и мониторинга служб Analysis Services.

Примечание.

Дополнительные сведения о моделях, размещенных в службах Analysis Services, см. в обзоре мониторинга.

Остальная часть этой статьи в основном посвящена моделям, опубликованным в служба Power BI.

Журналы событий семантической модели

Со временем создатели данных и владельцы могут столкнуться с ситуациями с семантической моделью. Семантическая модель может:

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

Примечание.

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

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

  • Аудит всех действий, произошедших в семантической модели.
  • Устранение неполадок и оптимизация производительности семантической модели, использования памяти и эффективности запросов.
  • Изучение сведений об обновлении и длительности обновления семантической модели.
  • Отслеживайте язык формул Power Query (запросы M), отправленные Power Query.
  • Отслеживайте формулы и выражения DAX, отправленные в семантику модели (подсистема Служб Analysis Services).
  • Проверьте, был ли выбран правильный режим хранения на основе рабочих нагрузок и необходимо сбалансировать свежие данные и оптимальную производительность.
  • Аудит вызовов ролей безопасности на уровне строк, для которых пользователи и для каких семантических моделей.
  • Общие сведения о количестве одновременных пользователей.
  • Проверьте семантику модели (например, чтобы проверить качество и производительность данных перед одобрением семантической модели или перед публикацией в рабочей рабочей области).

События, созданные семантической моделью Power BI, являются производными от существующих журналов диагностики, доступных для Служб Azure Analysis Services. Существует множество типов событий трассировки, которые можно записывать и анализировать, которые описаны в следующих разделах.

Azure Log Analytics

Azure Log Analytics — это компонент службы Azure Monitor . Интеграция Azure Log Analytics с Power BI позволяет записывать события семантической модели из всех семантических моделей в рабочей области Power BI. Она поддерживается только для рабочих областей Premium. После настройки интеграции и подключения (для рабочей области Power BI Premium) события семантической модели автоматически фиксируются и постоянно отправляются в рабочую область Azure Log Analytics. Журналы семантической модели хранятся в azure Data Обозреватель, которая является базой данных только для добавления, оптимизированной для записи данных телеметрии практически в реальном времени.

Вы назначаете рабочую область Power BI Premium рабочей области Log Analytics в Azure. Чтобы включить этот тип ведения журнала, необходимо создать ресурс Log Analytics в подписке Azure.

Журналы из одной или нескольких рабочих областей Power BI будут отправляться в целевую рабочую область Log Analytics. Ниже приведены некоторые способы упорядочивания данных.

  • Одна целевая рабочая область для всех данных аудита: храните все данные в одной рабочей области Log Analytics. Это полезно, когда один и тот же администратор или пользователи будут получать доступ ко всем данным.
  • Целевые рабочие области, упорядоченные по темам: упорядочивание содержимого по темам. Этот метод особенно полезен, если другим администраторам или пользователям разрешен доступ к данным аудита из Azure Log Analytics. Например, если необходимо разделить данные о продажах от данных операций.
  • Одна целевая рабочая область для каждой рабочей области Power BI: настройка связи между рабочей областью Power BI и рабочей областью Azure Log Analytics. Это полезно, если у вас есть особенно конфиденциальное содержимое, или когда данные подвергаются определенным требованиям соответствия или нормативным требованиям.

Совет

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

Внимание

Хотя имена похожи, данные, захваченные Azure Log Analytics, не совпадают с журналом действий Power BI. Azure Log Analytics фиксирует события трассировки на уровне детализации из подсистемы Служб Analysis Services. Его единственной целью является анализ и устранение неполадок производительности семантической модели. Его область находится на уровне рабочей области. И наоборот, цель журнала действий заключается в том, чтобы понять, как часто происходят определенные действия пользователя (например, изменение отчета, обновление семантической модели или создание приложения). Его область является всем клиентом Power BI.

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

Подключение Azure Log Analytics для параметров клиента администратороврабочей области определяет, какие группы пользователей (которые также имеют необходимую роль администратора рабочей области) могут подключать рабочую область Power BI к существующей рабочей области Azure Log Analytics.

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

Совет

Совместная работа с администратором Azure в начале процесса планирования, особенно при получении утверждения о создании нового ресурса Azure является проблемой в вашей организации. Вам также потребуется планировать предварительные требования безопасности. Определите, следует ли предоставить разрешение администратору рабочей области Power BI в Azure или предоставить разрешение администратору Azure в Power BI.

Журналы семантической модели, захваченные Azure Log Analytics, включают запросы семантической модели, статистику запросов, подробные действия обновления, время ЦП, потребляемые емкостями Premium и многое другое. Так как они — это журналы уровня детализации из подсистемы служб Analysis Services, данные могут быть подробными. Большие объемы данных являются общими для больших рабочих областей, которые испытывают высокую семантику действия модели.

Чтобы оптимизировать затраты при использовании Azure Log Analytics с Power BI:

  • Подключение рабочих областей Power BI в Azure Log Analytics только при активном устранении неполадок, тестировании, оптимизации или изучении действия семантической модели. При подключении трассировка выполняется во всех семантических моделях в рабочей области.
  • Отключите Azure Log Analytics из рабочей области Power BI, если вам больше не нужно активно устранять неполадки, тестировать, оптимизировать или исследовать действия семантической модели. При отключении трассировки выполняется во всех семантических моделях рабочей области.
  • Убедитесь, что вы понимаете модель затрат для выставления счетов Azure Log Analytics для приема данных, хранения и запросов.
  • Не сохраняйте данные в Log Analytics дольше, чем срок хранения 30 дней по умолчанию. Это связано с тем, что анализ семантической модели обычно фокусируется на немедленных действиях по устранению неполадок.

Существует несколько способов доступа к событиям, отправленным в Azure Log Analytics. Вы можете использовать:

  • Предварительно созданное приложение шаблона Log Analytics для семантических моделей Power BI.
  • Соединитель Power BI Desktop для Azure Data Обозреватель (Kusto). Используйте язык запросов Kusto (KQL) для анализа данных, хранящихся в Log Analytics. Если у вас есть опыт SQL-запросов, вы найдете множество сходств с KQL.
  • Веб-запросы в Обозреватель данных Azure.
  • Любое средство запроса, которое может выполнять запросы KQL.

Совет

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

Дополнительные сведения см. в разделе "Управление подключениями Azure".

Контрольный список . При планировании использования Azure Log Analytics ключевые решения и действия включают:

  • Рассмотрим технический POC: спланируйте небольшой проект, чтобы убедиться, что вы полностью понимаете технические требования, требования к безопасности, какие события необходимо записать и как анализировать журналы.
  • Определите, какие рабочие области следует интегрировать с Log Analytics: определите, какие рабочие области класса Premium содержат семантические модели, которые нужно проанализировать.
  • Определите, следует ли включить Log Analytics полный рабочий день для любых рабочих областей: для оптимизации затрат определите, существуют ли ситуации (или определенные рабочие области), где ведение журнала должно быть включено постоянно. Определите, следует ли отключить рабочие области при отсутствии неполадок.
  • Определите, как долго хранить данные Log Analytics: определите, нужно ли задать более длительный период хранения, чем 30-дневный по умолчанию.
  • Уточните процесс запроса новой рабочей области Log Analytics: обратитесь к администратору Azure, чтобы узнать, как запросы к новому ресурсу Log Analytics должны отправляться администраторами рабочей области Power BI.
  • Решите, как будет работать безопасность: совместно с администратором Azure определите, может ли администратор рабочей области Power BI предоставить права на рабочую область Azure Log Analytics или предоставить администратору Azure права на доступ к рабочей области Power BI. При принятии этого решения по обеспечению безопасности рекомендуется регулярно подключать и отключать рабочие области (для оптимизации затрат).
  • Решите, как упорядочить целевые рабочие области Log Analytics. Рассмотрим, сколько рабочих областей Azure Log Analytics будет подходящим для организации данных из одной или нескольких рабочих областей Power BI. Выравнивайте это решение с вашими решениями по безопасности для тех, кто может получить доступ к данным журнала.
  • Определите, какие администраторы рабочих областей могут подключаться: определите, какие группы администраторов рабочих областей могут подключать рабочую область Power BI к рабочей области Log Analytics. Задайте подключение Azure Log Analytics для параметра клиента администраторов рабочих областей, чтобы выровнять это решение.
  • Создайте ресурс Azure Log Analytics: совместная работа с администратором Azure для создания каждой рабочей области Log Analytics. Проверьте и обновите разрешения, назначенные в Azure, чтобы убедиться, что конфигурация Power BI может выполняться без каких-либо проблем. Убедитесь, что данные, хранящиеся в Azure, хранятся в правильном географическом регионе.
  • Задайте подключение Log Analytics для каждой рабочей области Power BI. Совместная работа с администраторами рабочей области Power BI для настройки подключения к Log Analytics для каждой рабочей области Power BI. Убедитесь, что данные журнала будут правильно передаваться в рабочую область Log Analytics.
  • Создайте запросы для анализа данных: настройте запросы KQL для анализа данных в Log Analytics на основе варианта использования и текущих потребностей.
  • Включите рекомендации для администраторов рабочей области Power BI. Предоставьте сведения и предварительные требования администраторам рабочей области Power BI, чтобы запросить новую рабочую область Log Analytics и как подключиться к рабочей области Power BI. Кроме того, объясните, когда необходимо отключить рабочую область Power BI.
  • Предоставьте рекомендации и примеры запросов для анализа данных: создайте запросы KQL для администраторов рабочих областей, чтобы упростить работу с анализом захваченных данных.
  • Мониторинг затрат. Совместная работа с администратором Azure для отслеживания затрат Log Analytics на постоянной основе.

Профилировщик SQL Server

Вы можете использовать SQL Server Profiler (SQL Profiler ) для записи событий семантической модели Power BI. Это компонент SQL Server Management Studio (SSMS). Подключение тивность к семантической модели Power BI поддерживается с помощью SSMS, так как она основана на архитектуре служб Analysis Services, созданной в SQL Server.

Вы можете использовать SQL Profiler на разных этапах жизненного цикла семантической модели.

  • Во время разработки модели данных: SQL Profiler может подключаться к модели данных в Power BI Desktop в качестве внешнего средства. Этот подход полезен для моделей данных, которые хотят проверить свою модель данных или настроить производительность.
  • После публикации семантической модели в служба Power BI: SQL Profiler может подключиться к семантической модели в рабочей области Premium. SSMS — это один из многих поддерживаемых клиентских средств, которые могут использовать конечную точку XMLA для подключения. Этот подход полезен, если вы хотите выполнять аудит, мониторинг, проверку, устранение неполадок или настройку опубликованной семантической модели в служба Power BI.

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

Примечание.

Использование SQL Profiler — это другой вариант использования для действия данных профилирования. Профилирование данных в Редактор Power Query для более глубокого понимания его характеристик. Хотя профилирование данных является важным действием для моделей данных, это не область для этой статьи.

Рекомендуется использовать SQL Profiler вместо Azure Log Analytics, когда:

  • Ваша организация не позволяет использовать или создавать ресурсы Azure Log Analytics в Azure.
  • Вы хотите записать события для модели данных в Power BI Desktop (которая не была опубликована в рабочей области Premium в служба Power BI).
  • Вы хотите записать события для одной семантической модели в течение короткого периода времени (а не всех семантических моделей в рабочей области Premium).
  • Вы хотите записать определенные события только во время трассировки (например, только событие окончания запроса).
  • Вы хотите часто запускать и останавливать трассировки (например, когда необходимо записывать события семантической модели, которые происходят сейчас).

Как и Azure Log Analytics (описано ранее в этой статье), события семантической модели, собранные профилировщиком SQL, являются производными от существующих журналов диагностики, доступных для служб Azure Analysis Services. Однако существуют некоторые различия в доступных событиях.

Совет

Использование SQL Profiler для мониторинга служб Analysis Services рассматривается во многих книгах, статьях и блогах. Большая часть этих сведений относится к мониторингу семантической модели Power BI.

Внимание

Вы также можете использовать SQL Profiler для мониторинга запросов, отправленных из служба Power BI в базовые источники данных (например, в реляционную базу данных SQL Server). Однако возможность трассировки реляционной базы данных устарела. Подключение в подсистему Служб Analysis Services поддерживается и не рекомендуется. Если вы знакомы с расширенными событиями служб Analysis Services и предпочитаете их использовать, подключение из SSMS возможно для модели данных в Power BI Desktop. Однако она не поддерживается для Power BI Premium. Поэтому в этом разделе основное внимание уделяется только стандартному подключению SQL Profiler.

Разрешить конечные точки XMLA и анализ в Excel с помощью параметров клиента локальных семантических моделей определяет, какие группы пользователей (которые также назначены роли участника, члена или Администратор рабочей области или разрешения сборки для отдельной семантической модели) могут использовать конечную точку XMLA для запроса и /или поддержания семантических моделей в служба Power BI. Дополнительные сведения об использовании конечной точки XMLA см. в сценарии использования расширенной модели данных.

Примечание.

Вы также можете использовать SQL Profiler для отладки и устранения неполадок определенных выражений DAX. Вы можете подключить SQL Profiler к Power BI Desktop как внешнее средство. Найдите класс событий журнала оценки DAX, чтобы просмотреть промежуточные результаты выражения DAX. Это событие создается при использовании функции EVALUATEANDLOG DAX в вычислении модели.

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

Контрольный список . При планировании использования SQL Profiler ключевые решения и действия включают:

  • Решите, кто может установить SSMS или DAX Studio: определите, разрешают ли все создатели содержимого Power BI в организации устанавливать SSMS и (или) DAX Studio, чтобы они могли использовать SQL Profiler. Определите, установлены ли эти вспомогательные средства по запросу или часть стандартного набора программного обеспечения, установленного для утвержденных создателей данных в организации.
  • Добавьте SQL Profiler в меню "Внешние инструменты" в Power BI Desktop: если создатели данных часто будут использовать SQL Profiler, попросите ИТ-специалистов автоматически добавить его в меню "Внешние инструменты" в Power BI Desktop для этих пользователей.
  • Решите, кто может использовать конечную точку XMLA: определите, разрешены ли все пользователи подключаться к опубликованным семантических моделям с помощью конечной точки XMLA или только для утвержденных создателей данных. Задайте конечные точки XMLA и анализируйте в Excel с параметром клиента локальных семантических моделей, чтобы выровнять это решение.
  • Предоставьте рекомендации и примеры запросов для анализа данных: создайте документацию для создателей данных, чтобы они понимали рекомендуемый способ аудита и мониторинга семантических моделей. Предоставьте рекомендации по общим вариантам использования, чтобы упростить их сбор и анализ данных трассировки.

Метаданные модели данных

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

Динамические административные представления

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

В частности, можно:

  • Аудит источников данных, используемых моделью.
  • Узнайте, какие объекты используют большую память в модели.
  • Определите, насколько эффективно можно сжимать данные столбцов.
  • Поиск столбцов в модели, которая не используется.
  • Аудит активных сеансов и подключений пользователей.
  • Проверьте структуру модели.
  • Просмотрите выражения DAX, используемые вычисляемыми таблицами, вычисляемыми столбцами, мерами и правилами безопасности на уровне строк (RLS).
  • Определение зависимостей между объектами и мерами.

Совет

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

SSMS — это средство, обычно используемое для выполнения запросов dmV. Можно также использовать командлет Invoke-ASCmd PowerShell для создания и выполнения скриптов XMLA , запрашивающих динамические административные представления.

Сторонние средства и внешние инструменты также популярны в сообществе Power BI. Эти средства используют общедоступные динамические административные административные представления для упрощения доступа и работы с данными, возвращаемыми динамическими административными представлениями. Одним из примеров является DAX Studio, которая включает явные функции для доступа к динамическим административным представлениям. DAX Studio также включает встроенную функцию "Метрики представления", которая обычно называется Vertipaq Analyzer. Анализатор Vertipaq имеет пользовательский интерфейс для анализа структуры и размера таблиц, столбцов, связей и секций в модели данных. Вы также можете экспортировать (или импортировать) метаданные модели данных в VPAX-файл. Экспортируемый файл содержит только метаданные о структуре и размере модели данных, не сохраняя данные модели.

Совет

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

Запросы dmV можно использовать на разных этапах жизненного цикла семантической модели.

  • Во время разработки модели данных: выбранное средство может подключаться к модели данных в Power BI Desktop в качестве внешнего средства. Этот подход полезен для моделей данных, которые хотят проверить свою модель данных или настроить производительность.
  • После публикации семантической модели в служба Power BI: выбранное средство может подключиться к семантической модели в рабочей области Premium. SSMS является одним из многих поддерживаемых клиентских средств, использующих конечную точку XMLA для подключения. Этот подход полезен при аудите или проверке опубликованной семантической модели в служба Power BI.

Совет

Если вы решите написать собственные запросы dmV (например, в SSMS), помните, что динамические административные представления не поддерживают все операции SQL. Кроме того, некоторые динамические административные представления не поддерживаются в Power BI (так как им требуются разрешения администратора сервера Analysis Services, которые не поддерживаются Power BI).

Разрешить конечные точки XMLA и анализ в Excel с помощью параметров клиента локальных семантических моделей определяет, какие группы пользователей (которые также назначены роли участника, члена или Администратор рабочей области или разрешения сборки для отдельной семантической модели) могут использовать конечную точку XMLA для запроса и /или поддержания семантических моделей в служба Power BI.

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

Анализатор соответствия рекомендациям

Анализатор рекомендаций (BPA) — это функция табличного редактора, которая является сторонним инструментом, который достигает широкого внедрения сообществом Power BI. BPA включает набор настраиваемых правил, которые помогут вам проверить качество, согласованность и производительность модели данных.

Совет

Чтобы настроить BPA, скачайте набор правил рекомендаций, предоставляемых корпорацией Майкрософт на GitHub.

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

BPA также может помочь вам в аудите и управлении моделями данных. Например, можно проверить, включает ли модель данных все роли безопасности на уровне строк (RLS). Кроме того, можно проверить, имеют ли все объекты модели описание. Это полезно, если, например, ваша цель — убедиться, что модель данных содержит словарь данных.

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

Совет

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

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

  • Решите, кто может установить SSMS: определите, разрешено ли всем создателям содержимого Power BI в организации устанавливать SSMS, чтобы они могли подключаться к опубликованным семантических моделям. Определите, установлено ли оно по запросу или в составе стандартного набора программного обеспечения, установленного для утвержденных создателей данных в организации.
  • Решите, кто может установить сторонние инструменты: определите, разрешено ли всем создателям содержимого Power BI в организации устанавливать сторонние средства (например, DAX Studio и табличный редактор), чтобы они могли отслеживать локальные модели данных и /или опубликованные семантические модели. Определите, установлены ли они по запросу или как часть стандартного набора программного обеспечения, установленного для утвержденных создателей данных в организации.
  • Настройте правила рекомендаций. Определите, какие правила анализатора рекомендаций могут сканировать модели данных в вашей организации.
  • Решите, кто может использовать конечную точку XMLA: определите, разрешены ли все пользователи подключаться к семантической модели с помощью конечной точки XMLA или только утвержденные создатели данных. Задайте конечные точки XMLA и анализируйте в Excel с параметром клиента локальных семантических моделей, чтобы выровнять это решение.
  • Предоставьте рекомендации создателям содержимого: создайте документацию для создателей данных, чтобы они понимали рекомендуемые способы анализа семантических моделей. Предоставьте рекомендации по общим вариантам использования, чтобы упростить их сбор и анализ результатов dmV и (или) использование анализатора рекомендаций.

Производительность модели данных и запросов

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

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

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

Совет

Для импорта и анализа файлов журналов, созданных Анализатор производительности, можно использовать DAX Studio.

Дополнительные сведения о Анализатор производительности см. в статье "Аудит на уровне отчета".

Диагностика запросов

Используйте диагностику запросов, доступную в Power BI Desktop, для изучения производительности Power Query. Они полезны для устранения неполадок и для того, чтобы понять, что делает подсистема Power Query.

Сведения, полученные от диагностики запросов, включают:

  • Дополнительные сведения, связанные с сообщениями об ошибках (при возникновении исключения).
  • Запросы, отправляемые в источник данных.
  • Происходит ли свертывание запросов или не происходит.
  • Количество строк, возвращаемых запросом.
  • Потенциальные замедления во время операции обновления данных.
  • Фоновые события и системные запросы.

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

Вы можете запустить сеанс диагностика в Редактор Power Query. После включения операции запроса и обновления собираются, пока не будет остановлена трассировка диагностики. Данные заполняются непосредственно в редакторе запросов после остановки диагностика. Power Query создает группу диагностики (папку) и добавляет в нее несколько запросов. Затем можно использовать стандартные функции Power Query для просмотра и анализа данных диагностика.

Кроме того, можно включить трассировку в Power BI Desktop в разделе "Диагностика" окна "Параметры". Файлы журналов сохраняются в папке на локальном компьютере. Эти файлы журнала заполняются данными после закрытия Power BI Desktop, в то время как трассировка остановлена. После закрытия Power BI Desktop вы можете открыть файлы журналов с предпочитаемой программой (например, текстовым редактором), чтобы просмотреть их.

Оценка запросов и свертывание

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

Приложение метрик уровня "Премиум"

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

Совет

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

Приложение метрик уровня "Премиум" состоит из внутренней семантической модели и начального набора отчетов. Это помогает выполнять мониторинг емкости Power BI Premium (SKU) или емкости Power BI Embedded (A SKU). Он включает данные за последние две до четырех недель (в зависимости от метрики).

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

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

  • Определите целевые показатели производительности запросов семантической модели. Убедитесь, что у вас есть хорошее представление о производительности семантической модели. Определите, когда вам потребуются определенные целевые показатели производительности запросов (например, запросы для поддержки отчетов должны отображаться в течение пяти секунд). В этом случае убедитесь, что целевые объекты передаются создателям данных в вашей организации.
  • Определение целевых показателей производительности обновления семантической модели. Определите, когда требуется определенный целевой объект обновления данных (например, завершение операции обновления данных в течение 15 минут и до 5 утра). В этом случае убедитесь, что целевые объекты передаются создателям данных в вашей организации.
  • Обучите свою службу поддержки. Убедитесь, что ваша внутренняя группа поддержки пользователей знакома с возможностями диагностики, чтобы они могли поддерживать пользователей Power BI, когда им нужна помощь.
  • Подключение группу поддержки и администраторов баз данных: Убедитесь, что ваша группа поддержки знает, как связаться с правильными администраторами для каждого источника данных (например, при устранении неполадок сворачиванием запросов).
  • Совместная работа с администратором емкости Premium. Обратитесь к администратору емкости для устранения неполадок семантических моделей, находящихся в рабочей области, которая назначена емкости Premium или емкости Power BI Embedded. При необходимости запросите доступ к приложению метрик Premium.
  • Предоставьте рекомендации создателям содержимого: создайте документацию для создателей данных, чтобы они понимали, какие действия следует предпринять при устранении неполадок.
  • Включите в учебные материалы: предоставьте своим создателям данных рекомендации по созданию моделей данных с правильной производительности. Помогите им принять хорошие привычки дизайна рано. Сосредоточьтесь на обучении создателей данных, как принимать хорошие решения по проектированию.

Мониторинг источников данных

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

Вы можете отслеживать источник данных следующими способами:

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

Существует множество действий, которые может предпринять создатель содержимого Power BI после анализа результатов мониторинга. Они могут:

  • Настройте и уточните запросы, отправляемые в источник данных, чтобы они были максимально эффективными.
  • Проверьте и настройте собственные запросы , отправляемые в источник данных.
  • Уменьшите количество столбцов, импортированных в модель данных.
  • Удалите столбцы высокой точности и высокой карта inality, импортируемые в модель данных.
  • Уменьшите объем исторических данных, импортированных в модель данных.
  • Настройте время обновления данных Power BI, чтобы помочь распределить спрос на источник данных.
  • Используйте добавочное обновление данных, чтобы уменьшить нагрузку на источник данных.
  • Уменьшите количество обновлений данных Power BI путем консолидации нескольких семантических моделей в общую семантику.
  • Настройте параметры автоматического обновления страницы, чтобы увеличить частоту обновления и, следовательно, уменьшить нагрузку на источник данных.
  • Упрощение вычислений для уменьшения сложности запросов, отправленных в источник данных.
  • Измените режим хранения данных (например, на режим импорта вместо DirectQuery), чтобы уменьшить согласованную нагрузку запросов на источник данных.
  • Используйте методы сокращения запросов, чтобы уменьшить количество запросов, отправляемых в источник данных.

Системные администраторы могут выполнять другие действия. Они могут:

  • Введите промежуточный уровень данных, например потоки данных Power BI (если хранилище данных не является жизнеспособным вариантом). Создатели содержимого Power BI могут использовать потоки данных в качестве источника данных вместо подключения непосредственно к источникам данных. Промежуточный уровень данных может снизить нагрузку на исходную систему. Кроме того, он имеет дополнительное преимущество централизованной логики подготовки данных. Дополнительные сведения см. в сценарии самостоятельной подготовки данных.
  • Измените расположение источника данных, чтобы уменьшить влияние задержки в сети (например, используйте тот же регион данных для служба Power BI, источников данных и шлюзов).
  • Оптимизируйте источник данных, чтобы он более эффективно извлекает данные для Power BI. К нескольким общим методам относятся создание индексов таблиц, создание индексированных представлений, создание сохраненных вычисляемых столбцов, поддержание статистики, использование таблиц в памяти или таблицы columnstore и создание материализованных представлений.
  • Прямые пользователи используют только для чтения реплика источника данных, а не исходную рабочую базу данных. Реплика может быть доступен в рамках стратегии обеспечения высокого уровня доступности (HA). Одним из преимуществ реплика только для чтения является сокращение состязаний в исходной системе.

Средства и методы, которые можно использовать для мониторинга источников данных, зависят от платформы технологий. Например, администратор базы данных может использовать расширенные события или хранилище запросов для мониторинга База данных SQL Azure и баз данных SQL Server.

Иногда Power BI обращается к источнику данных через шлюз данных. Шлюзы обрабатывают подключение из служба Power BI к определенным типам источников данных. Однако они делают больше, чем просто подключаться к данным. Шлюз включает подсистему mashup, которая выполняет обработку и преобразование данных на компьютере. Он также сжимает и шифрует данные, чтобы их можно было эффективно и безопасно передавать в служба Power BI. Поэтому неуправляемый или неоптимизованный шлюз может способствовать узким местам производительности. Мы рекомендуем обратиться к администратору шлюза, чтобы помочь в мониторинге шлюзов.

Совет

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

Дополнительные сведения о инвентаризации клиентов и журнале действий см. в разделе аудита на уровне клиента.

Контрольный список . При планировании мониторинга источника данных ключевые решения и действия включают:

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

Мониторинг обновления данных

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

Соглашение об уровне обслуживания

ИТ-служба обычно использует соглашения об уровне обслуживания для документирования ожиданий для ресурсов данных. Для Power BI рекомендуется использовать соглашение об уровне обслуживания для критического содержимого или содержимого корпоративного уровня. Обычно он включает в себя, когда пользователи могут ожидать, что обновленные данные в семантической модели будут доступны. Например, вы можете иметь соглашение об уровне обслуживания, которое все обновления данных должны выполняться каждые 7 утра каждый день.

Журналы семантической модели

Журналы событий семантической модели из Azure Log Analytics или SQL Profiler (описанные ранее в этой статье) содержат подробные сведения о том, что происходит в семантической модели. Захваченные события включают действие обновления семантической модели. Журналы событий особенно полезны, если необходимо устранить неполадки и исследовать обновления семантической модели.

Семантические модели емкости premium

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

Усовершенствованная семантическая модель обновляется

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

Мониторинг расписания обновления данных

Администраторы Power BI могут отслеживать расписания обновления данных в клиенте, чтобы определить, есть ли много операций обновления, запланированных одновременно в течение определенного периода времени (например, от 5 утра до 7 утра, что может быть особенно занято время обновления данных). Администратор istrator имеют разрешение на доступ к метаданным расписания обновления семантической модели из API сканирования метаданных, которые называются API сканера.

REST API в Power BI

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

Журнал обновления данных можно получить с помощью:

Совет

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

Контрольный список . При планировании мониторинга обновления данных ключевые решения и действия включают:

  • Определение конкретных целей. При обновлении данных мониторинга получите ясность о том, что нужно выполнить, и о том, что должно быть область мониторинга (например, производственные семантические модели, сертифицированные семантические модели и другие).
  • Попробуйте настроить соглашение об уровне обслуживания. Определите, будет ли соглашение об уровне обслуживания полезно задавать ожидания для доступности данных и при выполнении расписаний обновления данных.
  • Совместная работа с администраторами базы данных и шлюза: работа с базой данных или системными администраторами, а также администраторами шлюзов для мониторинга или устранения неполадок с обновлением данных.
  • Передача знаний для группы поддержки. Убедитесь, что ваша группа поддержки знает, как помочь создателям контента при возникновении проблем с обновлением данных.
  • Обновление обучения и рекомендаций. Включите ключевые сведения и советы для создателей данных о том, как обновить данные из источников данных организации и общих источников данных. Включите рекомендации и организационные предпочтения по управлению обновлением данных.
  • Используйте адрес электронной почты поддержки для уведомлений: для критического содержимого настройте уведомления об обновлении для использования адреса электронной почты поддержки.
  • Настройка централизованного мониторинга обновления. Используйте REST API Power BI для компиляции журнала обновления данных.

Мониторинг потока данных

Вы создаете поток данных Power BI с помощью Power Query Online. Многие функции производительности запросов и диагностика Power Query, которые были описаны ранее, применимы.

При необходимости можно задать рабочие области для использования Azure Data Lake Storage 2-го поколения для хранилища потоков данных (известного как перенос собственного хранилища), а не внутреннего хранилища. При использовании собственного хранилища рекомендуется включить телеметрию , чтобы отслеживать метрики для учетной записи хранения. Дополнительные сведения см. в сценарии самостоятельной подготовки данных и расширенном сценарии подготовки данных.

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

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

Совет

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

Мониторинг Datamart

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

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

Связанный контент

В следующей статье этой серии вы узнаете об аудите на уровне клиента.