power bi фильтр ведущие n
Типы аналитики, поддерживаемые в Power BI
ПРИМЕНЯЕТСЯ К: 
Служба Power BI для бизнес-пользователей Служба Power BI для дизайнеров и разработчиков 
Power BI Desktop Требуется лицензия Pro или Premium
Power BI может находить интересные тенденции и закономерности в данных. Эти тенденции и закономерности представляются в виде визуальных элементов, которые называются аналитикой. Аналитические сведения доступны для визуальных элементов на панелях мониторинга, визуальных элементов в отчетах и на всех страницах отчета.
Сведения об использовании аналитики см. в статье Аналитика Power BI.
Как выполняется аналитика?
Power BI обеспечивает быстрый поиск различных подмножеств в вашем наборе данных. При поиске Power BI применяет набор оптимизированных алгоритмов для выявления потенциально полезных аналитических сведений. Аналитические сведения можно запускать на плитках панелей мониторинга, в визуальных элементах отчетов и на страницах отчетов.
Терминология
Для получения аналитических сведений в Power BI используются статистические алгоритмы. Эти алгоритмы перечислены и описаны в следующем разделе данной статьи. Но прежде чем переходить к ним, следует ознакомиться с определениями ряда терминов, которые могут незнакомы вам.
Какие аналитические сведения можно получить?
Power BI предоставляет десять типов аналитических сведений для плиток панели мониторинга. Они описаны ниже. Для отчетов Power BI заблаговременно выполняет анализ аномалий, тенденций и ключевых показателей эффективности.
Провалы или всплески значений
Выделяет случаи, когда значения одной или двух категорий намного превышают значения остальных.
Точки изменений во временных рядах
Выделяет существенные изменения в тенденциях, наблюдаемых во временном ряде данных.
Correlation
Выявляет случаи, когда несколько мер проявляют схожие закономерности или тенденции при нанесении на график в зависимости от какой-либо категории или значения в наборе данных.
Низкая вариативность
Выявляет случаи, когда точки данных для измерения близки к среднему значению, то есть дисперсия невелика. Предположим, что у вас есть мера «Sales» и измерение «Region» (Регион). Просматривая этот регион, вы замечаете очень малые различия между значениями точек данных и средним значением (по всем точкам данных). Триггер по этим аналитическим сведениям срабатывает, когда дисперсия продаж по всем регионам не превышает порогового значения. Иными словами, когда продажи во всех регионах примерно на одном уровне.
Большинство (основные факторы)
Находит случаи, когда большую часть общего значения можно свести к одному фактору, выполнив детализацию по другому параметру.
Выбросы
Этот тип аналитики использует модель кластеризации для поиска выбросов в данных, отличных от временных рядов. Выбросы указывают наличие определенных категорий со значениями, значительно отличающимися от других категорий.
Общие тенденции во временных рядах
Определяет восходящие и нисходящие тенденция в данных временных рядов.
Сезонность во временных рядах
Находит повторяющийся рисунок в данных временных рядов, такие как недельная, месячная или годовая сезонность.
Постоянная доля
Выделяет случаи иерархической корреляции между долей дочернего значения и суммарным значением родительского элемента в непрерывной переменной. Аналитические сведения об устойчивой доле относятся к контексту меры, измерения и другого измерения даты и времени. Триггер по этим аналитическим сведениям срабатывает, когда для определенного значения измерения, например «восточный регион», регистрируется стабильная доля от общих продаж по соответствующему измерению даты и времени.
Аналитические сведения об устойчивой доле аналогичны сведениям о низкой дисперсии, так как оба отражают недостаточно различающиеся во времени значения. Но при этом аналитические сведения об устойчивой доле оценивают отсутствие дисперсии в процентах от общего количества по времени, а аналитические сведения о низкой дисперсии оценивают низкую вариативность абсолютных значений меры по измерению.
Выбросы временных рядов
Определяет, есть ли во временном ряде значения даты или времени, которые существенно отличаются от остальных значений даты и времени.
Перекрестная фильтрация визуальных элементов в отчете Power BI
ПРИМЕНЯЕТСЯ К: Служба Power BI для бизнес-пользователей Служба Power BI для дизайнеров и разработчиков Power BI Desktop Требуется лицензия Pro или Premium
Одно из главных преимуществ Power BI заключается во взаимосвязи всех визуальных элементов на странице отчета. Когда вы выбираете точку данных на любом из визуальных элементов, с учетом этого изменяется содержимое всех остальных визуальных элементов на странице.
Взаимодействие визуальных элементов друг с другом
По умолчанию выбор точки данных в одном визуальном элементе на странице отчета позволяет осуществлять перекрестную фильтрацию или перекрестное выделение других визуальных элементов на странице. Конкретные правила взаимодействия визуальных элементов на странице определяются конструктором отчета. Конструкторы могут включать и выключать средства взаимодействия, а также изменять настроенные по умолчанию параметры поведения перекрестной фильтрации, перекрестного выделения и детализации.
Если вы еще не знакомы с возможностями иерархий и детализации в Power BI, изучите эту статью.
Перекрестная фильтрация и перекрестное выделение
Перекрестную фильтрацию и перекрестное выделение можно использовать для того, чтобы определить, как одно значение в данных влияет на другое. Термины перекрестная фильтрация и перекрестное выделение используются для отделения поведения, описанного здесь, от того, что происходит при использовании области Фильтры для фильтрации и выделения визуальных элементов.
Давайте рассмотрим значения этих терминов на примере страниц отчетов, приведенных ниже. Кольцевая диаграмма «Общий объем категории по сегменту» имеет два значения: «Умеренность» и «Удобство».
Давайте посмотрим, что происходит при выборе значения Умеренность.
При перекрестной фильтрации удаляются неприменимые данные. При выборе значения Умеренность на кольцевой диаграмме выполняется перекрестная фильтрация графика. Теперь на графике будут отображаться только точки данных для сегмента «Умеренность».
При перекрестном выделении сохраняются все исходные точки данных, но та часть, которая не относится к выбранным элементам, затемняется. При выборе значения Умеренность на кольцевой диаграмме выполняется перекрестное выделение гистограммы. На гистограмме затемняются все данные, которые относятся к сегменту «Удобство», и выделяются все данные, которые относятся к сегменту «Умеренность».
Рекомендации и устранение неполадок
Если отчет содержит визуальный элемент, который поддерживает детализацию, детализация одного визуального элемента по умолчанию не оказывает влияния на другие визуальные элементы на странице отчета. Но конструктор отчетов может изменить это поведение, поэтому проверьте детализированные визуализации и узнайте, включены ли детализирующие фильтры для других визуализаций в конструкторе отчетов.
Фильтры на уровне визуального элемента сохраняются при перекрестной фильтрации и перекрестном выделении других визуальных элементов на странице отчета. Таким образом, если вы или разработчик отчета применили фильтры уровня визуального элемента к элементу VisualA и вы используете элемент visualA для взаимодействия с элементом visualB, фильтры уровня визуального элемента, примененные к элементу visualA, будут применяться к элементу visualB.
Руководство по использованию модели DirectQuery в Power BI Desktop
Эта статья ориентирована на разработчиков моделей данных DirectQuery для Power BI, использующих Power BI Desktop или службу Power BI. В ней описываются варианты использования DirectQuery, а также существующие ограничения и рекомендации по применению этого режима. В частности, это руководство поможет вам определить, подходит ли режим DirectQuery для вашей модели, а также повысить производительность отчетов, основанных на моделях DirectQuery. Эта статья посвящена моделям DirectQuery, размещаемым в службе Power BI или на сервере отчетов Power BI.
Исчерпывающее описание проектирования с использованием схемы модели DirectQuery выходит за рамки данной статьи. Общую информацию см. в статье Модели DirectQuery в Power BI Desktop. Более подробное обсуждение приводится в документе DirectQuery в службах SQL Server 2016 Analysis Services. Обратите внимание, что в этом документе описывается применение DirectQuery в SQL Server Analysis Services. Тем не менее по большей части это содержимое применимо и к моделям DirectQuery в Power BI.
В этой статье составные модели не рассматриваются напрямую. Такие модели могут содержать один или более источников DirectQuery. Таким образом, приведенные в этой статье рекомендации как минимум частично применимы к схеме составной модели. Тем не менее проблемы, связанные с объединением таблиц импорта и таблиц DirectQuery, выходят за рамки этой статьи. Дополнительные сведения см. в статье Использование составных моделей в Power BI Desktop.
Важно понимать, что применением моделей DirectQuery сопряжено с особой рабочей нагрузкой на среду Power BI (служба Power BI или Сервер отчетов Power BI) и базовые источники данных. Если вы выбрали схему DirectQuery, рекомендуется привлечь к участию в проекте специалистов в этой предметной области. Успешное развертывание модели DirectQuery зачастую требует сплоченной совместной работы целой группы ИТ-профессионалов. Как правило, в состав такой группы входят разработчики моделей и администраторы баз данных-источников. Помимо них, к участию в проекте могут привлекаться разработчики архитектуры и хранилища данных, а также разработчики функций извлечения, преобразования и загрузки. Кроме того, для достижения высокой производительности часто требуется провести оптимизацию непосредственно в самом источнике данных.
Проектирование в Power BI Desktop
Подключения к источникам данных Azure Synapse Analytics (ранее хранилище данных SQL) и Azure HDInsight Spark могут устанавливаться напрямую без применения Power BI Desktop. Такая схема реализуется в службе Power BI путем получения данных и выбора плитки «Базы данных». Дополнительные сведения см. в статье Azure Synapse Analytics (в прошлом — Хранилище данных SQL) и DirectQuery.
Тем не менее, несмотря на удобство, применять такой подход не рекомендуется. Основная причина заключается в том, что в таком случае будет невозможно обновить структуру модели в соответствии с изменением схемы базового источника данных.
Таким образом, для создания всех моделей DirectQuery и управления ими мы рекомендуем использовать Power BI Desktop. Такой подход обеспечивает полный контроль над определением необходимой модели, включая применение таких поддерживаемых функций, как иерархии, вычисляемые столбцы, меры и другие. Кроме того, в этом случае вы сможете при необходимости пересматривать модель в соответствии с изменением схемы базового источника данных.
Оптимизация производительности источника данных
Реляционную базу данных-источник можно оптимизировать разными способами, которые описываются в приведенном ниже списке.
Мы понимаем, что не у всех разработчиков моделей есть разрешения и навыки, необходимые для оптимизации реляционной базы данных. Несмотря на то, что подготовку данных для модели DirectQuery рекомендуется осуществлять именно на этом уровне, в определенной части оптимизировать модель можно и не изменяя базу данных-источник. Тем не менее наиболее эффективными будут результаты оптимизации, проводимой на уровне базы данных-источника.
Проверьте целостность данных. Особенно важно, чтобы таблицы измерений включали столбец уникальных значений (ключ измерения), который сопоставляется с таблицей или таблицами фактов. Кроме того, столбцы измерений фактов должны содержать допустимые значения ключа измерений. Такой подход позволяет реализовать более эффективные связи в рамках модели, которые предполагают наличие сопоставленных значений по обе стороны связи. При проблемах с целостностью источника данных рекомендуется добавить запись «неизвестного» измерения, что позволит эффективно исправить данные. Например, в таблицу Продукт можно добавить строку, представляющую неизвестный продукт, и назначить ей выходящий за рамки диапазона ключ, к примеру –1. В таком случае, если в строках таблицы Продажи будет отсутствовать ключ продукта, вместо него можно будет использовать значение –1. Благодаря этому каждому значению ключа продукта в таблице Продажи будет соответствовать строка в таблице Продукт.
Добавьте индексы. Определите для таблиц или представлений соответствующие индексы, что позволит обеспечить эффективное извлечение данных для последующих операций фильтрации или группирования данных в визуальном элементе отчета. Полезные сведения и рекомендации по проектированию индекса для источников SQL Server, баз данных SQL Azure и Azure Synapse Analytics (в прошлом — хранилище данных SQL Azure) см. в статье Руководство по проектированию и архитектуре индекса SQL Server. Дополнительные сведения о работе с непостоянными источниками данных SQL Server или базы данных SQL Azure см. в статье Начало работы с Columnstore для операционной аналитики в реальном времени.
Проектируйте распределенные таблицы. Для источников Azure Synapse Analytics (в прошлом — хранилище данных SQL), которые используют архитектуру вычислений с массовым параллелизмом, рекомендуется настраивать распределение хэша для крупных таблиц фактов, а также реплицировать таблицы измерений на всех вычислительных узлах. Дополнительные сведения см. в статье Руководство по проектированию распределенных таблиц в Azure Synapse Analytics (в прошлом — хранилище данных SQL).
Обеспечьте материализацию преобразований требуемых данных. Реляционные базы данных-источники SQL Server (и другие реляционные базы данных-источники) поддерживают добавление вычисляемых столбцов в таблицы. Значения этих столбцов рассчитываются с помощью выражений, например путем умножения количества на цену за единицу товара. Вычисляемые столбцы могут быть сохранены (материализованы) и, как и обычные столбцы, в некоторых случаях поддерживают индексацию. Дополнительные сведения см. в статье Индексация вычисляемых столбцов.
Также можно рассмотреть применение индексированных представлений, с помощью которых реализуется предварительное агрегирование данных на более высоком уровне. Например, если в таблице Продажи содержатся данные на уровне строки заказа, можно создать представление, в котором эти данные будут суммированы. Для этого можно использовать инструкцию SELECT, которая сгруппирует данные в таблице Продажи по датам (на уровне месяцев), клиентам, продуктам и суммирует значения мер, таких как продажи, количество и т. д. После этого такое представление можно индексировать. Дополнительные сведения, относящиеся к источникам SQL Server и базы данных SQL Azure, см. в статье Создание индексированных представлений.
Обеспечьте материализацию таблицы дат. При разработке моделей достаточно часто добавляется таблица дат, благодаря которой обеспечивается фильтрация на основе времени. Чтобы обеспечить поддержку временных фильтров, применяемых в вашей организации, создайте в базе данных-источнике таблицу и загрузите в нее диапазон дат, включающий в себя все даты в таблице фактов. Такая таблица должна включать практически применимые периоды времени, такие как год, квартал, месяц, неделя и т. д.
Оптимизация схемы модели
Модель DirectQuery можно оптимизировать самыми разными способами, представленными в следующем списке.
Исключите сложные запросы Power Query. Чтобы повысить эффективность схемы модели, можно исключить из нее запросы Power Query, применяющие какие-либо преобразования. Это означает, что каждый запрос будет сопоставляться с одной таблицей или одним представлением реляционной базы данных-источника. Если вы хотите просмотреть представление фактического SQL-запроса для примененного шага Power Query, выберите параметр Просмотреть машинный запрос.
Изучите случаи использования вычисляемых столбцов и изменения типов данных. Модели DirectQuery поддерживают добавление вычислений и шагов Power Query для преобразования типов данных. Тем не менее, если это возможно, во многих случаях добиться более высокой производительности позволяет материализация результатов преобразования в реляционной базе данных-источнике.
Не используйте фильтрацию относительных дат Power Query. В запросе Power Query можно определить фильтрацию относительных дат. Например, это может потребоваться для извлечения заказов на продажу, созданных за предыдущий (относительно текущей даты) год. Фильтр такого типа преобразуется в неэффективный машинный запрос следующим образом.
В таких ситуациях рекомендуется включать в таблицу дат столбцы относительного времени. В таких столбцах хранятся значения смещения относительно текущей даты. Например, в столбце Относительный год нулевое значение соответствует текущему году, значение –1 — предшествующему и т. д. Таким образом, предпочтительный подход заключается в материализации столбца Относительный год в таблице дат. Менее эффективный, но все же практичный, способ заключается в добавлении вычисляемого столбца модели, основанного на выражении, использующем функции DAX TODAY и DATE.
Используйте простые меры. По крайней мере поначалу мы рекомендуем ограничить меры, чтобы упростить агрегаты. К агрегатным функциям относятся SUM, COUNT, MIN, MAX и AVERAGE. Затем, если эти меры демонстрируют достаточную эффективность, вы можете поэкспериментировать с более сложными мерами, в каждом случае уделяя особое внимание их производительности. Хотя функцию DAX CALCULATE можно использовать для построения сложных выражений мер, управляющих контекстом фильтра, делать это не рекомендуется, так как они приводят к созданию ресурсоемких машинных запросов, которые имеют невысокую производительность.
Избегайте связей в вычисляемых столбцах. Связи в модели могут определять отношение только между одним столбцом одной таблицы и одним столбцом из другой таблицы. Тем не менее в некоторых случаях требуется связать таблицы по нескольким столбцам. Например, таблицы Продажи и География связаны по двум столбцам: Страна и Город. Для создания связи между таблицами требуется один столбец, а в таблице География столбец должен содержать уникальные значения. Достичь этого можно путем объединения названий страны и города с использованием дефиса в качестве разделителя.
Для создания объединенного столбца можно применить как пользовательский столбец Power Query, так и вычисляемый столбец модели. Тем не менее такое решение не рекомендуется, поскольку в этом случае выражение вычисления будет встраиваться в исходные запросы. Это не только неэффективно, но и, как правило, препятствует использованию индексов. Вместо этого рекомендуется добавить в реляционную базу данных-источник материализованные столбцы и выполнить их индексацию. Также можно попробовать добавить столбцы суррогатного ключа в таблицы измерений, что часто применяется в схемах реляционных хранилищ данных.
Единственное исключение из этого правила связано с функцией DAX COMBINEVALUES. Эта функция предназначена для поддержки связей модели по нескольким столбцам. Вместо создания выражения, которое будет использоваться в связи, эта функция создает предикат соединения SQL с несколькими столбцами.
Избегайте связей в столбцах с данными типа «Уникальный идентификатор». Power BI изначально не поддерживает тип данных уникального идентификатора (GUID). При определении связи между столбцами такого типа Power BI создаст исходный запрос с соединением, который требует приведения типов. Как правило, подобные преобразования данных во время выполнения запроса приводят к снижению производительности. Пока для этого случая не найдется оптимальное решение, единственным выходом остается материализовать столбцы альтернативного типа данных в базовой базе данных.
Скройте столбец, находящийся на стороне связи «один». Столбец, находящийся на стороне связи «один», должен быть скрыт. (Как правило, это столбец первичного ключа в таблицах измерений.) Если вы скроете такой столбец, он не будет представлен в области Поля и, соответственно, не может использоваться для настройки визуального элемента. Столбец, находящийся на стороне связи «многие», может оставаться видимым, если это необходимо для группирования или фильтрации отчетов по значениям столбцов. В качестве примера рассмотрим модель, в которой существует связь между таблицами Продажи и Продукт. Столбец связи содержит номера SKU продукта. Если требуется добавлять номер SKU продукта в визуальные элементы, он должен быть видимым только в таблице Продажи. Если этот столбец используется для фильтрации или группирования в визуальном элементе, Power BI создаст запрос, в котором не потребуется объединять таблицы Продажи и Продукт.
Задайте связи для обеспечения целостности. Свойство Предполагать целостность данных связей DirectQuery определяет, будет ли Power BI создавать исходный запрос с использованием внутреннего соединения вместо внешнего. Это улучшит производительность запроса, хотя она и зависит в большей степени от конкретных параметров реляционной базы данных источника. Дополнительные сведения см. в статье Функция «Предполагать целостность данных» в Power BI Desktop.
Старайтесь избегать двусторонней фильтрации связей. Использование двусторонней фильтрации связей может привести к неправильному выполнению инструкций запросов. Эту функцию связи следует использовать только при необходимости. Как правило, это требуется при реализации связи «многие ко многим» для сопоставительной таблицы. Дополнительные сведения см. в статье Связи с кратностью «многие ко многим» в Power BI Desktop.
Ограничьте использование параллельных запросов. Вы можете задать максимально допустимое количество подключений, которые DirectQuery открывает для каждого базового источника данных. Это ограничение регулирует количество запросов, отправляемых в источник данных одновременно.
Этот параметр будет доступен только в том случае, если в модели присутствует хотя бы один источник DirectQuery. Его значение применяется ко всем источникам DirectQuery, включая любые новые источники DirectQuery, добавляемые в эту модель.
При увеличении значения параметра Максимальное число подключений на источник данных увеличивается число запросов (до максимального указанного количества), отправляемых в базовый источник данных, что удобно при наличии нескольких визуальных элементов на одной странице или при одновременном подключении к отчету большого числа пользователей. Как только будет достигнуто максимальное число подключений, дополнительные запросы помещаются в очередь до освобождения подключения. Увеличение этого предела приводит к росту нагрузки на базовый источник данных, соответственно, параметр не гарантирует общего повышения производительности.
При публикации модели в Power BI максимально допустимое число параллельных запросов к базовому источнику данных также зависит от среды. Разные среды (например, Power BI, Power BI Premium или сервер отчетов Power BI) могут налагать разные ограничения на пропускную способность. Дополнительные сведения об ограничениях ресурсов емкости для Power BI Premium см. в статье Развертывание емкостей Power BI Premium и управление ими.
Оптимизация схем отчетов
Основанные на наборе данных DirectQuery отчеты можно оптимизировать самыми разными способами, представленными в следующем списке.
Используйте методы сокращения числа запросов. В разделе Параметры и настройки Power BI Desktop представлена страница «Сокращение числа запросов». Она содержит три полезных параметра. Вы можете по умолчанию отключить перекрестное выделение и перекрестную фильтрацию, однако эта настройка может быть переопределена при редактировании взаимодействий. Также можно отображать на срезах и фильтрах кнопку «Применить». В результате параметры среза или фильтра будут применяться только после того, как пользователь нажмет эту кнопку. Если вы хотите включить эти параметры, мы рекомендуем сделать это на этапе создания запроса.
Сначала примените фильтры: На начальной стадии проектирования отчетов мы рекомендуем применять любые необходимые фильтры на уровне отчета, страницы или визуального элемента, прежде чем сопоставлять поля с полями визуального элемента. Например, вместо того, чтобы перетаскивать меры Страна и Продажи, а затем выполнять фильтрацию по году, следует сначала применить фильтр к полю Год. Это можно объяснить следующим образом: так как на каждом шаге создания визуального элемента отправляется запрос, а также учитывая при этом возможность выполнения других действий (до непосредственного завершения выполнения первого запроса), на базовый источник данных создается ненужная нагрузка. Изначальное применение фильтров делает менее затратными промежуточные запросы и увеличивает скорость их выполнения. Кроме того, в случае применения фильтров только на поздних этапах вполне вероятно превышение ограничения в один миллион строк, как описывается выше в разделе Сведения о DirectQuery.
Ограничьте число визуальных элементов на странице: При открытии страницы отчета, к которой применяются фильтры, обновляются все представленные на ней визуальные элементы. Тем не менее в среде Power BI предусмотрено ограничение на число параллельно отправляемых запросов, которое также может устанавливаться параметром модели Максимальное число подключений на источник данных, как описывается выше. Таким образом, с увеличением числа визуальных элементов на странице возрастает вероятность того, что они будут обновляться последовательно. Это, в свою очередь, влечет за собой замедление процесса обновления страницы в целом, а также повышение шансов на то, что визуальные элементы будут отображать несогласованные результаты (для непостоянных источников данных). По этим причинам рекомендуется ограничить количество визуальных элементов на одной странице и вместо этого использовать несколько более простых страниц. Вы можете получить схожие макеты страницы, заменив несколько визуальных элементов карточки одним визуальным элементом многострочной карточки.
Отключите взаимодействие между визуальными элементами. Для выполнения перекрестного выделения и перекрестной фильтрации в базовый источник отправляются запросы. В тех случаях, когда такие взаимодействия не требуются, рекомендуется отключить их, если время реакции на выбор пользователем элементов выходит за рамки приемлемого. Это можно сделать для всего отчета (как описано выше для сокращения числа запросов) или для отдельных случаев. Дополнительные сведения: Перекрестная фильтрация визуальных элементов в отчете Power BI.
Кроме того, каждая из приведенных ниже функций может вызвать проблемы производительности.
Фильтры мер: Визуальные элементы, содержащие меры (или агрегаты столбцов), могут содержать фильтры, примененные к этим мерам. Например, представленный ниже визуальный элемент отображает столбец Продажи в параметре Категория, но при этом включает категории с объемом продаж, превышающим 15 млн.
Это может привести к отправке двух запросов в базовый источник данных.
Это оптимальное решение для сотен и тысяч категорий, как показано в этом примере. Тем не менее в случае чрезмерно большого числа категорий производительность снизится. (Хотя, по сути, запрос завершится ошибкой, если число категорий, соответствующих условию, превысит один миллион, т. е. установленное ограничение, рассмотренное в этой статье выше.)
Фильтры «Ведущие N»: Можно определить дополнительные фильтры для фильтрации по первым (или последним) N значениям с ранжированием по мере. Например, чтобы отобразить только первые пять категорий для приведенного выше визуального элемента, сделайте следующее. Как и в случае с фильтрами мер, это приведет к отправке двух запросов в базовый источник данных. Тем не менее первый запрос вернет из базового источника все категории, после чего из них будут отобраны первые N результатов. В зависимости от количества включенных столбцов это может привести к проблемам с производительностью (или сбоям запросов из-за ограничения строк в один миллион).
Медиана: В общем случае любой агрегат (Sum, Count Distinct и т. д.) передается в базовый источник. Но к медиане это не относится, так как это статистическое выражение не поддерживается базовым источником. В таких случаях подробные данные извлекаются из базового источника, а Power BI вычисляет медиану на основе возвращенных результатов. Это подходит, если медиана будет рассчитываться для относительно небольшого количества результатов, в противном случае производительность будет снижена (или же запросы завершатся сбоем из-за ограничения в один миллион строк). Например, оптимально использовать медиану населения страны, а не цены продажи.
Срезы с поддержкой множественного выбора. Поддержка множественного выбора в срезах и фильтрах может привести к снижению производительности. Это связано с тем, что по мере выбора дополнительных элементов среза пользователем (например, при комплектовании набора из 10 интересующих пользователя продуктов) каждая новая операция выбора приводит к отправке запроса в базовый источник. Хотя пользователь и может выбрать следующий элемент до завершения первого запроса, это вызовет дополнительную нагрузку на базовый источник. Чтобы избежать этого, можно использовать кнопку «Применить», как описывается выше в разделе, посвященном сокращению числа запросов.
Визуальные итоги. по умолчанию в таблицах и матрицах отображаются итоги и промежуточные итоги. Часто для получения таких итогов нужно отправлять дополнительные запросы к базовому источнику. Это верно при работе с агрегатами Count Distinct и Median, а также во всех случаях при использовании DirectQuery через SAP HANA или SAP Business Warehouse. Если такие итоги не требуются, отключите их на панели «Формат».
Преобразование в составную модель
Преимущества моделей импорта и DirectQuery можно сочетать в рамках одной модели, настроив режим хранения для таблиц модели. В качестве режима хранения таблиц можно задать «Импорт», DirectQuery или «Двойной». Модель, содержащая таблицы с разными режимами хранения, называется составной. Дополнительные сведения см. в статье Использование составных моделей в Power BI Desktop.
Преобразование модели DirectQuery в составную может дать целый ряд улучшений с точки зрения функциональности и производительности. Составная модель поддерживает интеграцию с несколькими источниками DirectQuery и также может включать агрегаты. Вы можете добавить таблицы агрегирования в таблицы DirectQuery для импорта обобщенного представления таблицы. Это позволяет значительно повысить производительность в тех случаях, когда визуальные элементы запрашивают высокоуровневые агрегаты. Дополнительные сведения см. в статье Агрегаты в Power BI Desktop.
Обучение пользователей
Важно научить пользователей эффективно работать с отчетами, основанными на наборах данных DirectQuery. Авторам отчетов следует внимательно ознакомиться с разделом Оптимизация схем отчетов.
Также рекомендуется ознакомить пользователей отчетов с принципами работы с отчетами, построенными на основе наборов данных DirectQuery. Им может потребоваться знание общей архитектуры данных, в том числе и соответствующих ограничений, описываемых в этой статье. Они должны понимать, что операции обновления и интерактивной фильтрации в некоторых случаях могут значительно замедляться. Зная причины такого снижения производительности, пользователи будут уверены в том, что даже в случае снижения скорости ответа отчеты и данные по-прежнему обрабатываются с необходимой эффективностью.
Если ваш отчет основывается на непостоянном источнике данных, проинформируйте его пользователей о принципах использования кнопки «Обновить». Также сообщите им о вероятности появления несогласованности результатов на странице отчетов, которая может быть устранена посредством обновления.
Дальнейшие действия
Дополнительные сведения о DirectQuery см. в следующих статьях: