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

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

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

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

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

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

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

В Редактор Power Query после нажатия кнопки "Применить" загрузка данных занимает слишком много времени и ресурсов компьютера. Существует несколько потенциальных причин.

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

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

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

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

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

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

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

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

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

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

Обновление семантической модели в службе

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

Проблема: время ожидания начального обновления

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

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

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

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

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

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

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

Решение. Уменьшение размера модели

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

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

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

Решение: начальное обновление начального обновления

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

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

Запросы могут быть ограничены по умолчанию по умолчанию для источника данных.

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

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

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

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

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

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

Решение. Обновление определенных разделов

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

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

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

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

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

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

Проблема. Обновление завершается сбоем из-за конфликтов ключа секции

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

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

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

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

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

Причина. Связанные таблицы не в двойном режиме

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

Решение. Преобразование связанных таблиц в двойной режим

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

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

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

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

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

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

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

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

• Data refresh in Power BI (Обновление данных в Power BI)
• Расширенное добавочное обновление с помощью конечной точки XMLA
• Добавочное обновление для потоков данных