Устранение неполадок с добавочным обновлением и данными в режиме реального времени

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

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

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

Настройка Power BI Desktop

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

Проблема. Загрузка данных занимает слишком много времени

Загрузка данных после нажатия кнопки "Применить" в Редакторе Power Query занимает слишком много времени и потребляет большое количество ресурсов компьютера. Это может произойти по нескольким возможным причинам.

Причина. Несоответствие типов данных

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

Решение. Проверка типа данных

Убедитесь, что столбец даты и времени для таблицы добавочного обновления имеет тип "дата и время". Если таблица содержит столбец с типом данных "целое число", а не "дата и время", можно создать функцию, преобразующую значение "дата и время" в параметрах RangeStart и RangeEnd в соответствии с целочисленным суррогатным ключом таблицы источника данных. Дополнительные сведения см. в разделе Преобразование значения типа "дата и время" в значение типа "целое число" статьи "Настройка добавочного обновления" .

Причина. Источник данных не поддерживает свертывание запросов

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

Решение. Проверка и тестирование запросов

В большинстве случаев в диалоговом окне "Политика добавочного обновления" отображается предупреждение, указывающее, поддерживает ли запрос, который нужно выполнить в источнике данных, свертывание. Однако в некоторых случаях, возможно, вам понадобится более надежная гарантия того, что свертывание запросов будет поддерживаться. По возможности, отслеживайте запрос, передаваемый источнику данных, с помощью такого средства, как SQL Profiler. Запрос с фильтрами на основе параметров RangeStart и RangeEnd должен выполняться как один запрос.

Также можно указать короткий период для значения "дата и время" параметров RangeStart и RangeEnd, который будет содержать не более нескольких тысяч строк. Если загрузка отфильтрованных данных из источника данных в модель занимает много времени и является очень ресурсоемкой, скорее всего запрос не свертывается.

Если вы определили, что запрос не свертывается, см. руководство по свертыванию запросов в Power BI Desktop и статью Свертывание запросов Power Query, чтобы получить дополнительные сведения о том, что может препятствовать свертыванию запросов и каким образом, и может ли источник данных вообще поддерживать эту функцию.

Обновление набора данных в службе

Устранение неполадок добавочного обновления в службе будет зависеть от типа емкости, в которой был опубликован набор данных. Наборы данных в емкости уровня "Премиум" поддерживают для просмотра и выборочного обновления отдельных секций использование таких средств, как SQL Server Management Studio (SSMS). С другой стороны, наборы данных Power BI Pro не обеспечивают доступ к средствам через конечную точку XMLA, поэтому для устранения неполадок, связанных с добавочным обновлением, вам, возможно, придется опробовать разные методы и столкнуться со многими ошибками.

Проблема. Истекло время ожидания начального обновления

Запланированное обновление для наборов данных Power BI Pro в общей емкости имеет ограничение по времени в два часа. Для наборов данных в емкости уровня "Премиум" это ограничение по времени увеличивается до пяти часов. Системы источников данных также могут накладывать ограничение на размер возвращаемого запроса или время ожидания запроса.

Причина. Запросы к источникам данных не свертываются

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

Решение. Проверка свертывания запросов

Чтобы определить, что запрос, передаваемый для каждой секции, является единым запросом, который содержит фильтр на основе параметров RangeStart и RangeEnd, в источнике данных следует использовать инструмент трассировки. Если нет, убедитесь, что свертывание запросов выполняется в модели Power BI Desktop, загрузив в модель небольшой отфильтрованный объем данных. Если свертывание не выполняется, сначала исправьте ошибки в модели, выполните обновление, которое учитывает только метаданные, для набора данных (через конечную точку XMLA) или, если набор данных Power BI Pro размещен в общей емкости, удалите неполный набор данных в службе, повторно опубликуйте его и повторите начальную операцию обновления.

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

Причина. Данные, загруженные в секции, слишком велики

Решение. Уменьшите размер набора данных

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

Решение. Включение формата хранения большого набора данных

Если набор данных, опубликованный в емкости "Премиум", превысит 1 ГБ или более, можно повысить производительность операций обновления и убедиться, что набор данных не превышает ограничения по размеру, включив формат хранения большого набора данных перед выполнением первой операции обновления в службе. Дополнительные сведения см. в статье Большие наборы данных в Power BI Premium.

Решение. Выполнение загрузки начального обновления

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

Причина. Истечение времени ожидания запроса к источнику данных

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

Решение. Переопределение ограничения по времени в выражении запроса

Многие источники данных позволяют переопределить ограничения по времени в выражении запроса. Дополнительные сведения см. в разделе "Ограничения по времени" статьи "Добавочное обновление для наборов данных".

Проблема. Обновление не выполняется из-за повторяющихся значений

Причина. Изменились даты публикации

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

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

Решение. Обновление определенных секций

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

Проблема. Данные усечены

Причина. Превышено ограничение на количество запросов к источнику данных

Некоторые источники данных, такие как Azure Data Explorer, Log Analytics и Application Insights, имеют ограничение в 64 МБ (в сжатом состоянии) для данных, которые могут быть возвращены для внешнего запроса. Azure Data Explorer может возвращать явную ошибку, но для других источников данных, таких как Log Analytics и Application Insights, возвращаемые данные усекаются.

Решение. Указание меньших периодов обновления и хранения

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

Проблема. Сбой при обновлении из-за конфликтов ключей секции

Причина. Дата в столбце даты в источнике данных обновлена

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

Гибридный режим в службе (предварительная версия)

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

Screenshot of hybrid table.

Проблема: производительность запросов неудовлетворительна

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

При настройке политики добавочного обновления Power BI Desktop напоминает вам переключить все связанные таблицы в двойной режим при выборе пункта "Получить последние данные в режиме реального времени" с помощью DirectQuery (только premium). Кроме того, убедитесь, что вы просматриваете все существующие связи между таблицами в представлении модели.

Screen showing converting related tables to dual mode.

Таблицы, работающие в режиме DirectQuery, легко переключаются в двойной режим. В свойствах таблицы в разделе "Дополнительно" выберите "Двойной" в списке "Режим хранения". Однако таблицы, работающие в режиме импорта, требуют ручной работы. К двойным таблицам применяются те же функциональные ограничения, что и к таблицам DirectQuery. Поэтому Power BI Desktop не может преобразовывать таблицы импорта, так как они могут полагаться на дополнительные функции, недоступные в двойном режиме. Эти таблицы необходимо вручную воссоздать в режиме DirectQuery, а затем преобразовать их в двойной режим. Дополнительные сведения см. в статье "Управление режимом хранения" в Power BI Desktop.

Проблема. Визуальные элементы отчета не отображают последние данные

Причина. Результаты запросов кэшируются в Power BI, повышая производительность и уменьшая нагрузку на серверную часть

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

Решение. Настройка автоматического обновления страницы

Чтобы сохранить последние изменения данных из источника, настройте автоматическое обновление страницы для отчетов в службе Power BI. Автоматическое обновление страницы может выполняться в фиксированных интервалах, таких как пять секунд или десять минут. При достижении указанного интервала все визуальные элементы на этой странице отправляют запрос на обновление в источник данных и соответствующим образом обновляются. Кроме того, можно обновить визуальные элементы на странице на основе обнаружения изменений в данных. Для этого требуется мера обнаружения изменений, которую Power BI затем использует для опроса источника данных для внесения изменений. Обнаружение изменений поддерживается только в рабочих областях, которые являются частью емкости Premium. Дополнительные сведения см. в статье "Автоматическое обновление страницы" в Power BI.

См. также раздел

Обновление данных в Power BI
Расширенное добавочное обновление с использованием конечной точки XMLA
Добавочное обновление для потоков данных