Добавочное обновление и данные в режиме реального времени для наборов данных

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

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

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

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

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

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

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

Преимущество добавочного обновления заключается в том, что служба обрабатывает все это на основе политик добавочного обновления, которые вы определяете. На самом деле процесс и секции, созданные на его основе, не видны в службе. В большинстве случаев четко определенная политика добавочного обновления — это все, что необходимо для значительного повышения производительности обновления набора данных. Однако секция DirectQuery в режиме реального времени поддерживается только для наборов данных в емкостях Premium. Power BI Premium также обеспечивает более сложные сценарии секционирования и обновления через конечную точку XML для анализа (XMLA).

Требования

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

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

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

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

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

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

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

Для других источников данных параметры RangeStart и RangeEnd должны передаваться источнику данных каким-то образом, который обеспечивает фильтрацию. Для файловых источников данных, где файлы и папки упорядочены по дате, параметры RangeStart и RangeEnd можно использовать для фильтрации файлов и папок, чтобы выбрать файлы для загрузки. Для веб-источников данных параметры RangeStart и RangeEnd можно интегрировать в HTTP-запрос. Например, следующий запрос можно использовать для добавочного обновления трассировок из экземпляра AppInsights:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Нет требования, чтобы окончательный запрос поддерживал свертывание. Например, в следующем выражении мы используем невертый NativeQuery, но интегрируем параметры RangeStart и RangeEnd непосредственно в SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

При настройке добавочного обновления выражение Power Query, включающее в себя фильтр даты и времени на основе параметров RangeStart и RangeEnd, выполняется для источника данных. Если фильтр указан на шаге запроса после исходного запроса, важно, чтобы при свертывание запроса сочеталось начальное действие запроса с действиями, ссылающимися на параметры RangeStart и RangeEnd. Например, в следующем выражении запроса будет свертываться, Table.SelectRows так как он сразу после Sql.Database шага, и SQL Server поддерживает свертывание:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Нет требования, чтобы окончательный запрос поддерживал свертывание. Например, в следующем выражении мы используем невертый NativeQuery, но интегрируем параметры RangeStart и RangeEnd непосредственно в SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

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

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

Снимок экрана: предупреждение о свертке запроса

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

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

Один источник данных

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

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

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

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

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

Примечание

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

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

В отношении запросов также может действовать лимит времени по умолчанию, настроенный для источника данных. Большинство реляционных источников данных позволяют переопределять ограничения времени в выражении Power Query M. Например, в приведенном ниже выражении с помощью функции доступа к данным 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"

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

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

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

Снимок экрана: диалоговое окно запланированного обновления с полем ввода часового пояса

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

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

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

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

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

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

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

Снимок экрана: диалоговое окно

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

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

Снимок экрана: контекстное меню столбца с выбранным пользовательским фильтром

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

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

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

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

Таблица

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

Обязательные параметры

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

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

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

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

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

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

Необязательные параметры

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

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

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

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

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

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

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

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

Публикация

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

Примечание

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

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

Важно!

После того как Power BI Desktop опубликует модель в службе, вы не сможете скачать этот PBIX-файл обратно.

Обновить

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

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

Автоматическое обновление отчета

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

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

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

Сообщество

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

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