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

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

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

Понимание обновлений

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

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

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

  Заметка

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

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

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

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

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

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

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

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

Понимание и оптимизация обновлений

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

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

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

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

Оркестрация

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

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

Контроль

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

Ошибки тайм-аута

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

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

Руководство по тайм-ауту

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

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

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

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

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

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

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

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

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

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

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

Использование добавочного обновления может повысить производительность. Важно, чтобы фильтры секций отправляются в исходную систему при отправке запросов для операций обновления. Чтобы отправить фильтрацию вниз, источник данных должен поддерживать свертку запросов, или вы можете выразить бизнес-логику с помощью функции или других средств, которые могут помочь в устранении и фильтрации файлов или папок 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 обновлений в день.

Связанное содержимое

• Использование инкрементного обновления с потоками данных
• инкрементальное обновление и данные в режиме реального времени для семантических моделей
• рекомендации по потокам данных
• функции потоков данных класса Premium
• Особенности и ограничения потоков данных
• Устранение неполадок в сценариях обновления