Общие сведения об обновлении потоков данных и оптимизация

  • Статья

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

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

Общие сведения об обновлениях

Существует два типа обновлений, применимых к потокам данных:

  • Full, который выполняет полный сброс и перезагрузку данных.

  • Добавочный (только премиум), который обрабатывает подмножество данных на основе правил на основе времени, выраженных как фильтр, который вы настраиваете. Фильтр по столбцу даты динамически секционирует данные в диапазоны в служба Power BI. После настройки добавочного обновления поток данных автоматически изменяет запрос, чтобы включить фильтрацию по дате. Вы можете изменить автоматически созданный запрос с помощью Расширенный редактор в Power Query для точной настройки или настройки обновления. Если вы приносите собственные служба хранилища Azure Data Lake, вы можете увидеть срезы времени данных на основе установленной политики обновления.

    Примечание.

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

Добавочное обновление обеспечивает большие потоки данных в Power BI со следующими преимуществами:

  • Обновления выполняются быстрее после первого обновления из-за следующих фактов:

    • Power BI обновляет последние N-секции , указанные пользователем (где секция — день/месяц и т. д.) или
    • Power BI обновляет только данные, которые необходимо обновить. Например, обновление только последних пяти дней семантической модели 10-летней.
    • Power BI обновляет только измененные данные, если вы указываете столбец, который требуется проверка для изменений.

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

  • Сокращение потребления ресурсов — меньше данных для обновления сокращает общее потребление памяти и других ресурсов.

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

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

Общие сведения об обновлениях и оптимизации

Чтобы лучше понять, как выполняется операция обновления потока данных, просмотрите журнал обновления для потока данных, перейдя к одному из потоков данных. Выберите дополнительные параметры (...) для потока данных. Затем выберите журнал обновления Параметры>. Вы также можете выбрать поток данных в рабочей области. Затем выберите дополнительные параметры (...) > Журнал обновления.

Screenshot of dataflows refresh history.

Журнал обновления содержит общие сведения об обновлениях, включая тип по запросу или по расписанию, длительность и состояние выполнения. Чтобы просмотреть сведения в виде CSV-файла, щелкните значок скачивания в правом углу строки описания обновления. Скачанный CSV-файл содержит атрибуты, описанные в следующей таблице. Обновления уровня "Премиум" предоставляют дополнительные сведения на основе дополнительных возможностей вычислений и потоков данных, а также потоков данных на основе Pro, находящихся в общей емкости. Таким образом, некоторые из следующих метрик доступны только в Premium.

Элемент Description Pro Premium
Дата запроса Время обновления было запланировано или обновлено в локальном времени. ✔ ✔
Имя потока данных Имя потока данных. ✔ ✔
Состояние обновления потока данных Завершенные, неудачные или пропущенные (для сущности) являются возможными состояниями. Варианты использования, такие как связанные сущности, являются причинами, по которым может быть пропущено. ✔ ✔
Имя объекта Имя таблицы. ✔ ✔
Имя секции Этот элемент зависит от того, является ли поток данных премиум или нет, и если Pro отображается как NA, так как он не поддерживает добавочное обновление. Premium показывает fullRefreshPolicyPartition или IncrementalRefreshPolicyPartition-[DateRange]. ✔
Состояние обновления Обновление состояния отдельной сущности или секции, которая предоставляет состояние для этого среза данных, обновляемых. ✔ ✔
Время запуска В premium этот элемент — это время, когда поток данных был поставлен в очередь для обработки сущности или секции. Это время может отличаться, если потоки данных имеют зависимости и должны ждать, пока результирующий набор потока данных вышестоящий начнется обработка. ✔ ✔
Время окончания Время окончания — это время завершения сущности потока данных или секции, если применимо. ✔ ✔
Длительность Общее время обновления потока данных, выраженное в HH:MM:SS. ✔ ✔
Обработанные строки Для заданной сущности или секции количество строк, отсканированных или записанных подсистемой потоков данных. Этот элемент может не всегда содержать данные на основе выполняемой операции. Данные могут быть опущены, если подсистема вычислений не используется, или при использовании шлюза в качестве данных, обрабатываемых там. ✔
Обработанные байты Для заданной сущности или секции данные, записанные подсистемой потоков данных, выраженные в байтах.

При использовании шлюза в этом конкретном потоке данных эти сведения не предоставляются.		 ✔
Максимальная фиксация (КБ) Max Commit — это память пиковой фиксации, полезная для диагностики сбоев вне памяти, когда запрос M не оптимизирован.

При использовании шлюза в этом конкретном потоке данных эти сведения не предоставляются.		 ✔
Загруженность процессора Для определенной сущности или секции время, выраженное в HH:MM:SS, которое модуль потоков данных потратил на выполнение преобразований.

При использовании шлюза в этом конкретном потоке данных эти сведения не предоставляются.		 ✔
Время ожидания Для заданной сущности или секции время, затраченное сущностью в состоянии ожидания, на основе рабочей нагрузки емкости Premium. ✔
Ядро вычислений Сведения о том, как операция обновления использует подсистему вычислений для заданной сущности или секции. Значения качества производительности:
-NA
-Сложить
-Кэшированные
— Кэшированные + свернутые

Эти элементы подробно описаны далее в этой статье.		 ✔
Ошибка Если применимо, подробное сообщение об ошибке описывается для каждой сущности или секции. ✔ ✔

Руководство по обновлению потока данных

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

Оркестрация

Использование потоков данных в той же рабочей области позволяет выполнять простую оркестрацию. Например, у вас могут быть потоки данных A, B и C в одной рабочей области и цепочка, например A > B > C. При обновлении источника (A) подчиненные сущности также обновляются. Однако при обновлении C вам придется обновлять другие независимо друг от друга. Кроме того, если добавить новый источник данных в поток данных B (который не включен в A), данные не обновляются как часть оркестрации.

Может потребоваться объединить элементы, которые не соответствуют управляемой оркестрации Power BI. В этих сценариях можно использовать API и (или) использовать Power Automate. Вы можете ознакомиться с документацией по API и скриптом PowerShell для программного обновления. Существует соединитель Power Automate, который позволяет выполнять эту процедуру без написания кода. Подробные примеры см. в конкретных пошаговом руководстве по последовательному обновлению.

Наблюдение

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

Ошибки, связанные с истечением времени ожидания

Оптимизация времени выполнения сценариев извлечения, преобразования и загрузки (ETL) идеально подходит. В Power BI применяются следующие случаи:

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

Руководство по истечении времени ожидания

Пороговые значения времени ожидания для потоков данных Power BI Pro:

  • Два часа на уровне отдельных сущностей.
  • Три часа на всем уровне потока данных.

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

Если вы испытываете время ожидания, рассмотрите возможность оптимизации запросов потока данных и рассмотрите возможность свертывания запросов в исходных системах.

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

Длительные сроки

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

Руководство по длительным периодам обновления

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

Затем он может помочь оценить, можно ли использовать добавочное обновление.

Использование добавочного обновления может повысить производительность. Важно, чтобы фильтры секций отправляются в исходную систему при отправке запросов для операций обновления. Чтобы отправить фильтрацию вниз, источник данных должен поддерживать свертку запросов, или вы можете выразить бизнес-логику с помощью функции или других средств, которые могут помочь в устранении и фильтрации файлов или папок Power Query. Большинство источников данных, поддерживающих запросы SQL, поддерживают свертку запросов, а некоторые веб-каналы OData также могут поддерживать фильтрацию.

Однако такие источники данных, как неструктурированные файлы, большие двоичные объекты и API, обычно не поддерживают фильтрацию. В случаях, когда серверная часть источника данных не поддерживает фильтр, его нельзя отправить вниз. В таких случаях подсистема mash-up компенсирует и применяет фильтр локально, что может потребовать получения полной семантической модели из источника данных. Эта операция может привести к медленному добавочному обновлению, и процесс может выйти из ресурсов либо в служба Power BI, либо в локальном шлюзе данных, если используется.

Учитывая различные уровни поддержки свертывания запросов для каждого источника данных, необходимо выполнить проверку, чтобы убедиться, что логика фильтра включена в исходные запросы. Чтобы упростить эту проверку, Power BI пытается выполнить эту проверку с помощью свертывания индикаторов для Power Query Online. Многие из этих оптимизаций — это опыт разработки, но после обновления у вас есть возможность анализировать и оптимизировать производительность обновления.

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

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

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

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

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

    • Такие средства, как Azure Speed Test , предоставляют сведения о задержке сети между клиентом и регионом Azure. Как правило, чтобы свести к минимуму влияние задержки в сети, старайтесь как можно ближе хранить источники данных, шлюзы и кластер Power BI. Расположение в одном регионе предпочтительнее. Если задержка в сети является проблемой, попробуйте найти шлюзы и источники данных ближе к кластеру Power BI, разместив их в облачных виртуальных машинах.

Высокий уровень времени процессора

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

Руководство по высокой нагрузке на процессор

Существует два варианта оптимизации высокого времени процессора.

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

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

Использование подсистемы вычислений для повышения производительности

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

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

Предупреждение

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

Руководство по состояниям подсистемы вычислений

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

NA — это состояние означает, что подсистема вычислений не использовалась, так как:

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

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

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

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

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

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

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

Кэшированные + сложенные — при отображении кэшированных и сложенных данных, скорее всего, оптимизировано обновление данных, так как у вас есть сущность, которая ссылается на другую сущность и ссылается на другую сущность вышестоящий. Эта операция также выполняется поверх SQL и, как это, также имеет потенциал для улучшения с помощью вычислений SQL. Чтобы убедиться, что вы получаете лучшую производительность, используйте преобразования, поддерживающие свертывание SQL, например слияние (присоединение), группирование (агрегирование) и добавление (объединение) действий в Редактор запросов.

Руководство по оптимизации производительности подсистемы вычислений

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

Вычисляемых и связанных сущностей в одной рабочей области:

Для приема сосредоточьтесь на получении данных в хранилище как можно быстрее, используйте фильтры только в том случае, если они снижают общий размер семантической модели. Оставить логику преобразования отдельной от этого шага. Затем отделите преобразование и бизнес-логику в отдельном потоке данных в той же рабочей области. Используйте связанные или вычисляемые сущности. Это позволяет подсистеме активировать и ускорить вычисления. Для простой аналогии, это как приготовление пищи на кухне: подготовка пищи, как правило, отдельный и отличный шаг от сбора сырых ингредиентов, и предварительные требования для размещения пищи в духовке. Аналогичным образом необходимо подготовить логику отдельно, прежде чем воспользоваться преимуществами вычислительной подсистемы.

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

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

Если подсистема вычислений включена, но производительность выполняется медленно:

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

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

Рекомендации и ограничения

Лицензия Power BI Pro имеет ограничение на обновление потоков данных в 8 обновлений в день.

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