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

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

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

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

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

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

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

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

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

Требования

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

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

Добавочное обновление поддерживается для моделей 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, чтобы соответствовать целым числным суррогатным ключам столбца дат. Дополнительные сведения см. в статье "Настройка добавочного обновления и данных в режиме реального времени— преобразование DateTime в целое число".

Для других источников данных параметры 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

При настройке добавочного обновления выражение 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, неуправляемые преобразования нельзя использовать. Если это чистая политика режима импорта без данных в режиме реального времени, подсистема mashup запроса может компенсировать и применить фильтр локально, что требует получения всех строк таблицы из источника данных. Это может привести к замедлению добавочного обновления, и процесс может исчерпать ресурсы как в службе 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. Для моделей в емкости Premium ограничение времени составляет пять часов. Операции обновления требуют значительных затрат процессорных и памятьных ресурсов. Полная операция обновления может использовать до двух раз больше памяти, чем требуется только для модели, поскольку служба сохраняет снимок состояния модели в памяти до завершения операции обновления. Операции обновления также могут быть процессоемкими, потребляя значительное количество доступных ресурсов ЦП. Операции обновления также должны полагаться на переменные подключения к источникам данных, а также возможность этих систем источников данных быстро возвращать выходные данные запроса. Ограничение времени — это защита для ограничения чрезмерного потребления доступных ресурсов.

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

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

По умолчанию текущая дата и время определяются на основе универсального времени (UTC) во время обновления. Для запланированных обновлений и обновлений REST API можно настроить другой часовой пояс в разделе "Обновить", который будет учитываться при определении текущей даты и времени. Например, обновление, которое происходит в 8:00 по тихоокеанскому времени (США и Канаде) с настроенным часовой поясом определяет текущую дату и время на основе тихоокеанского времени, а не времени UTC, который возвращается на следующий день.

Операции обновления, не вызываемые через службу Power BI, такие как команда обновления XMLA TMSL, не учитывают конфигурацию часового пояса и по умолчанию в временной зоне UTC.

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

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

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

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

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

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

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

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

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

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

В редакторе Power Query добавьте действия фильтрации:

1. Выберите "Добавить шаг" или измените запрос непосредственно в строке формул.
2. Используйте функцию Table.SelectRows для создания фильтров, ссылающихся на параметры.
3. Примените отдельные шаги фильтра как для условий начальной, так и конечной даты.

Например, чтобы фильтровать по OrderDateKey:

#"Filtered Rows" = Table.SelectRows(Source, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
#"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))

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

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

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

Таблица

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

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

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

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

Для моделей в емкостях Premium резервные исторические секции можно выборочно обновлять при детализации, определенной этим параметром. Дополнительные сведения см. в разделе «Расширенное инкрементное обновление — разделы».

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

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

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

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

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

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

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

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

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

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

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

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

Публикация

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

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

Обновить

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

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

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

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

Расширенное инкрементное обновление

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

Сообщество

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

• Сообщество Power BI
• Поиск "Добавочное обновление Power BI" в Bing
• Выполните поиск по запросу "Добавочное обновление файлов" в Bing
• Искать "Удержание существующих данных с помощью добавочного обновления" в Bing

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

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