Добавочное обновление и данные в режиме реального времени для семантических моделей
Добавочное обновление и данные в режиме реального времени для семантических моделей в 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 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, чтобы соответствовать целым числным суррогатным ключам столбца дат. Дополнительные сведения см. в статье "Настройка добавочного обновления и данных в режиме реального времени— преобразование 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 ограничение времени составляет пять часов. Операции обновления — это операции с большим объемом памяти и процессами. Полная операция обновления может использовать столько же, сколько в два раза больше памяти, необходимых только для модели, так как служба сохраняет моментальный снимок модели в памяти до завершения операции обновления. Операции обновления также могут быть процессоемкими, потребляя значительное количество доступных ресурсов ЦП. Операции обновления также должны полагаться на переменные подключения к источникам данных, а также возможность этих систем источников данных быстро возвращать выходные данные запроса. Ограничение времени — это защита для ограничения чрезмерного потребления доступных ресурсов.
Примечание.
При использовании емкостей Premium операции обновления, выполняемые через конечную точку 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 можно задать секции, которые будут обрабатываться по отдельности, последовательно или параллельно, чтобы уменьшить объем данных, возвращаемых в одном запросе, а также обойти пятичасовое ограничение времени. Дополнительные сведения см. в статье "Дополнительное добавочное обновление" — предотвращение времени ожидания при первоначальном полном обновлении.
Текущие дата и время
По умолчанию текущая дата и время определяются на основе универсального времени (UTC) во время обновления. Для обновлений по запросу и запланированных обновлений можно настроить другой часовой пояс в разделе "Обновить", который будет учитываться при определении текущей даты и времени. Например, обновление, которое происходит в 8:00 по тихоокеанскому времени (США и Канаде) с настроенным часовой поясом определяет текущую дату и время на основе тихоокеанского времени, а не времени UTC, который возвращается на следующий день.
Операции обновления, не вызываемые через служба Power BI, такие как команда обновления XMLA TMSL или расширенный API обновления, не учитывают настроенный часовой пояс запланированного обновления и по умолчанию в формате 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 вы применяете настраиваемые фильтры дат в столбце дат таблицы. Примененные фильтры выбирают подмножество данных, загруженных в модель при нажатии кнопки "Применить".
В нашем примере FactInternetSales после создания фильтров на основе параметров и применения шагов данные (примерно 20 000 строк) загружаются в модель.
Определение политики
После применения фильтров и загрузки подмножества данных в модель необходимо определить политику добавочного обновления для таблицы. После публикации модели в службе политика используется службой для создания секций таблиц и управления ими и выполнения операций обновления. Чтобы определить политику, используйте диалоговое окно добавочного обновления и данных в режиме реального времени для указания обязательных и необязательных параметров.
Таблица
Поле "Выбор таблицы " по умолчанию используется для таблицы, выбранной в представлении данных. Включите добавочное обновление для таблицы ползунок. Если выражение Power Query для таблицы не включает фильтр на RangeStart основе параметров, RangeEnd переключатель недоступен.
Обязательные параметры
Архивные данные, начиная с параметра даты обновления, определяют исторический период, в котором строки с датой и временем в этом периоде включены в модель, а также строки для текущего неполного исторического периода, а также строки в период обновления до текущей даты и времени.
Например, если указать пять лет, таблица сохраняет последние пять целых лет исторических данных в разделах года. Таблица также будет включать строки для текущего года в квартале, месяце или днях секций до и в том числе периода обновления.
Для моделей в емкостях Premium резервные исторические секции можно выборочно обновлять при детализации, определенной этим параметром. Дополнительные сведения см. в разделе "Дополнительное добавочное обновление" — секции.
Добавочное обновление данных, начиная с параметра даты обновления, определяет период добавочного обновления, в котором все строки с датой и временем этого периода включаются в разделы обновления и обновляются с каждой операцией обновления.
Например, если указать период обновления в течение трех дней с каждой операцией обновления, служба переопределяет RangeStart запросы RangeEnd на строки с датой и временем в течение трехдневного периода с началом и окончанием, зависящим от текущей даты и времени. Строки с датой и временем за последние три дня до текущего времени операции обновления обновляются. С помощью этой политики можно ожидать, что таблица моделей FactInternetSales в службе, которая в среднем составляет 10 000 новых строк в день, чтобы обновить примерно 30 000 строк с каждой операцией обновления.
Укажите период, содержащий только минимальное количество строк, необходимых для обеспечения точной отчетности. При определении политик для нескольких таблиц одни и RangeEnd те же RangeStart параметры должны использоваться, даже если для каждой таблицы определены разные периоды хранения и обновления.
Необязательные параметры
Параметр Получения последних данных в режиме реального времени с параметром 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 для переопределения поведения обнаружения изменений данных. Дополнительные сведения см. в статье "Дополнительное добавочное обновление" — пользовательские запросы для обнаружения изменений данных.
Публикация
После настройки политики добавочного обновления вы опубликуете модель в службе. После завершения публикации можно выполнить начальную операцию обновления модели.
Примечание.
Семантические модели с политикой добавочного обновления для получения последних данных в режиме реального времени с помощью DirectQuery можно опубликовать только в рабочей области Premium.
Для моделей, опубликованных в рабочих областях, назначенных емкостям Premium, если модель будет увеличиваться до 1 ГБ, вы можете повысить производительность операции обновления и убедиться, что модель не превышает пределы размера, включив параметр формата хранилища больших семантических моделей перед выполнением первой операции обновления в службе. Дополнительные сведения см. в статье "Большие модели" в Power BI Premium.
Внимание
После публикации модели в службе Power BI Desktop вы не сможете скачать этот PBIX-файл обратно.
Refresh
После публикации в службе выполняется начальная операция обновления модели. Это обновление должно быть отдельным (вручную), чтобы отслеживать ход выполнения. Начальная операция обновления может занять довольно некоторое время. Секции должны создаваться, загружаться исторические данные, объекты, такие как связи и иерархии, созданные или перестроенные, и вычисляемые объекты пересчитываются.
Последующие операции обновления ( отдельные или запланированные) гораздо быстрее, так как обновляются только секции добавочного обновления. Другие операции обработки по-прежнему должны выполняться, такие как объединение секций и пересчет, но обычно занимает гораздо меньше времени, чем начальное обновление.
Автоматическое обновление отчета
Для отчетов, использующих модель с политикой добавочного обновления, чтобы получить последние данные в режиме реального времени с помощью DirectQuery, рекомендуется включить автоматическое обновление страницы с фиксированным интервалом или на основе обнаружения изменений, чтобы отчеты включали последние данные без задержки. Дополнительные сведения см. в статье "Автоматическое обновление страницы" в Power BI.
Расширенное добавочное обновление
Если модель включена в емкости Premium с включенной конечной точкой XMLA, добавочное обновление можно расширить для расширенных сценариев. Например, с помощью SQL Server Management Studio можно просматривать секции и управлять ими, загружать начальную операцию обновления или обновлять резервные исторические секции. Дополнительные сведения см. в статье "Дополнительное добавочное обновление" с конечной точкой XMLA.
Сообщество
Power BI имеет активное сообщество, где MVPs, бизнес-специалисты и одноранговые специалисты делятся опытом в группах обсуждений, видео, блогах и многое другое. При изучении добавочного обновления обратитесь к следующим ресурсам:
- Сообщество Power BI
- Поиск "Добавочное обновление Power BI" в Bing
- Выполните поиск по запросу "Добавочное обновление файлов" в Bing
- Поиск "Сохранить существующие данные с помощью добавочного обновления" в Bing