Добавочное обновление для наборов данных

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

Использование добавочного обновления обеспечивает следующие преимущества:

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

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

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

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

Преимущество добавочного обновления заключается в том, что служба обрабатывает все это на основе политик добавочного обновления, которые определяет пользователь. Фактически, процесс и секции, созданные во время выполнения процессы, даже не видны в службе. В большинстве случаев все, что необходимо для значительного повышения производительности обновления набора данных, — это четко определенная политика добавочного обновления. Однако для наборов данных в емкости уровня "Премиум" поддерживаются более сложные сценарии секционирования и обновления через конечную точку XMLA.

Требования

Поддерживаемые планы

Добавочное обновление поддерживается для наборов данных уровней Power BI Premium, "Premium на пользователя", Power BI Pro и Power BI Embedded.

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

Добавочное обновление является лучшим решением для структурированных реляционных источников данных, таких как База данных SQL и Azure Synapse, но его также можно использовать и для других источников данных. В любом случае источник данных должен поддерживать следующее:

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

Свертывание запросов — добавочное обновление предназначено для источников данных, поддерживающих свертывание запросов, то есть способность Power Query создавать единичные выражения запросов для получения и преобразования исходных данных. Большинство источников данных, которые поддерживают запросы SQL, также поддерживают свертывание запроса. При этом такие источники данных, как неструктурированные файлы, BLOB-объекты и веб-каналы, обычно не поддерживают свертывание.

При настройке добавочного обновления выражение Power Query, включающее в себя фильтр даты и времени на основе параметров RangeStart и RangeEnd, выполняется для источника данных. Фильтр, по сути, является преобразованием, включенным в запрос, который определяет предложение WHERE на основе параметров. Однако фильтр невозможно добавить в выражение запроса, если он не поддерживается источником данных. Подсистема гибридных веб-приложений для запросов возмещает это и применяет фильтр локально, для чего может потребоваться извлечь все строки для таблицы из источника данных. Это может привести к замедлению добавочного обновления, и в следствии процессу будет недостаточно ресурсов либо в службе Power BI, либо в локальном шлюзе данных, что в сумме может обречь на неудачу достижение цели добавочного обновления.

Кроме того, поскольку разные типы источников данных не равным образом поддерживают свертывание запросов, необходимо выполнить проверку, чтобы убедиться в том, что логика фильтра включена в запросы, выполняемые к источнику данных. В большинстве случаев Power BI Desktop будет пытаться выполнить эту проверку при определении политики добавочного обновления. Для источников данных на основе SQL, таких как База данных SQL, Azure Synapse, Oracle и Teradata, эта проверка является надежной. Когда же другим источникам данных, возможно, не удастся выполнить проверку без трассировки запросов. Если Power BI Desktop не удастся подтвердить возможность свертывания, в диалоговом окне настройки политики добавочного обновления отобразится предупреждение.

Экран "Предупреждение о свертывании запроса"

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

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

Другие типы источников данных

Если применить дополнительные пользовательские функции и логики запросов, добавочное обновление можно использовать с другими типами источников данных, при условии, что фильтры, которые работают на основе RangeStart, и RangeEnd, можно передавать в одном запросе. Например, файлы книг Excel, хранящиеся в папке, файлах в SharePoint или RSS-каналах. Не забывайте, что это более сложные сценарии, для которых необходимы дополнительные настройка и тестирование, выходящие за рамки сведений, описанных в этой статье. Обязательно ознакомьтесь с разделом Сообщество этой статьи, чтобы узнать, как найти дополнительные сведения об использовании добавочного обновления для таких уникальных сценариев.

Ограничения по времени

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

Примечание

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

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

В отношении запросов также может действовать лимит времени по умолчанию, настроенный для источника данных. Большинство реляционных источников данных позволяют переопределить ограничения по времени в выражении M запроса Power Query. Например, в приведенном ниже выражении с помощью функции доступа к данным SQL Server CommandTimeout задается равным двум часам. Для каждого периода, определенного в диапазонах политики, запрос выполняется с учетом времени ожидания команды.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

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

Текущие дата и время

Текущие дата и время зависят от системной даты на момент обновления. Если для набора данных в службе включено запланированное обновление, то при определении текущих даты и времени учитывается указанный часовой пояс. Как индивидуальные, так и запланированные обновления через службу учитывают часовой пояс (если он доступен). Например, обновление, которое выполняется в 20 часов по тихоокеанскому времени (США и Канада) с заданным часовым поясом, определяет текущие дату и время по тихоокеанскому времени, а не по Гринвичу (в противном случае это будет следующий день). Операции обновления, которые не были вызваны через службу, например команда обновления TMSL, не учитывают часовой пояс запланированного обновления.

Часовой пояс

Настройка добавочного обновления

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

Настройка добавочного обновления выполняется в Power BI Desktop. Для большинства моделей потребуются только несколько задач. Однако помните следующее.

  • Опубликовав модель в службе, вы не сможете повторно опубликовать ее в Power BI Desktop. При повторной публикации будут удалены все существующие секции и данные, уже имеющиеся в наборе данных. При публикации в емкости уровня "Премиум" последующие изменения схемы метаданных можно выполнить с помощью набора средств ALM с открытым исходным кодом или с использованием языка TMSL. Дополнительные сведения см. в разделе "Выполнение развертывания только для метаданных" статьи "Расширенное добавочное обновление".
  • После публикации в службе вы не сможете снова загрузить в Power BI Desktop набор данных в виде PBIX-файла. Поскольку наборы данных в службе могут значительно увеличиваться, загружать их обратно и открывать на обычном настольном компьютере нецелесообразно.

Создание параметров

При настройке добавочного обновления в Power BI Desktop вам сначала понадобится создать два параметра даты и времени Power Query с зарезервированными именами RangeStart и RangeEnd, учитывая регистр. Эти параметры, определенные в диалоговом окне "Управление параметрами" в Редакторе Power Query, изначально используются для фильтрации данных, загружаемых в таблицу модели Power BI Desktop, чтобы включить только строки, даты и время которых соответствуют указанному периоду. Опубликовав модель, служба автоматически переопределит параметры RangeStart и RangeEnd для запроса данных, определенных периодом обновления, указанным в параметрах политики добавочного обновления.

Например, в таблице источника данных FactInternetSales в среднем в день создаются 10000 новых строк. Чтобы ограничить количество строк, первоначально загружаемых в модель в Power BI Desktop, мы указываем двухдневный период между RangeStart и RangeEnd.

Экран &quot;Диалоговое окно &quot;Управление параметрами&quot;

Фильтрация данных

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

Пользовательский фильтр

В нашем примере FactInternetSales после создания фильтров, основанных на параметрах, и применения шагов, в модель загружаются данные за два дня, примерно 20 000 строк.

Определение политики

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

Чтобы определить политику, необходимо задать три обязательных параметра и два необязательных параметра:

Экран &quot;Диалоговое окно &quot;Определение политики&quot;

1. Таблица

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

2. Сохранение строк за последние

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

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

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

3. Обновление строк за последние

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

Например, если указать период обновления 10 дней, то при каждой операции обновления служба будет переопределять параметры RangeStart и RangeEnd, чтобы создать запрос для строк с датой и временем, соответствующими десятидневному периоду, начиная с текущих даты и времени. При этом будут обновлены строки с датой и временем в диапазоне последних 10 дней до текущей операции обновления. С помощью этого типа политики мы можем принимать таблицу набора данных FactInternetSales в службе, которая усредняет 10 000 новых строк в день, чтобы обновлять при каждой операции обновления примерно 100 000 строк.

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

4. Обнаружение изменения данных

Это необязательный параметр. Добавочное обновление данных за 10 дней гораздо эффективнее полного обновления за пять лет. Однако обновление можно сделать еще более выборочным. Используя вариант "Обнаруживать изменения данных", можно выбрать столбец типа "дата и время", с помощью которого будут определяться дни, в которые данные изменились; тогда обновляться будут данные только за эти дни. Предполагается, что в источнике данных есть такой столбец. Обычно он предназначен для аудита. Этот столбец не должен быть столбцом, который использовался для секционирования данных с помощью параметров RangeStart и RangeEnd. Для каждого из периодов в диапазоне добавочного обновления вычисляется максимальное значение этого столбца. Если такое значение не изменилось с момента последнего обновления, обновлять данные за этот период не нужно. Благодаря этому в примере число дней, за которые нужно обновить данные, потенциально может уменьшиться, например с 10 до двух.

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

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

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

5. Обновление только завершенных дней

Это необязательный параметр. Допустим, запланировано ежедневное обновление в 04:00. Если в течение этих четырех часов с полуночи до 4:00 в таблице источника данных появляются новые строки данных, возможно, вы не захотите учитывать их при расчете. Например, учитывать некоторые бизнес-метрики, такие как баррели в сутки в нефтегазовой отрасли, за неполные дни просто нецелесообразно. Другим примером является обновление данных в финансовой системе, в которой данные за предыдущий месяц утверждаются в 12-й календарный день месяца. В этом случае можно задать период обновления длительностью в месяц и настроить запуск обновления в 12-й день месяца. Например, если выбрать этот вариант, данные за январь будут обновляться 12 февраля.

Помните, что если запланированное обновление не настроено для часового пояса, отличного от UTC, операции обновления в службе выполняются, учитывая время в формате UTC, что может определять дату вступления в силу и влиять на полные периоды.

Публикация

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

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

Важно!

Опубликовав PBIX-файл в службе, вы не сможете его снова загрузить.

Обновить

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

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

Расширенное добавочное обновление

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

Сообщество

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

Дальнейшие действия

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