Расширенное инкрементальное обновление и данные в режиме реального времени с конечной точкой XMLA

Семантические модели в емкости Premium с поддержкой конечной точки XMLA для операций чтения и записи позволяют более расширенное обновление, управление разделами и развертывания, содержащие только метаданные, с помощью инструментов, скриптов и API. Кроме того, операции обновления через конечную точку XMLA не ограничиваются 48 обновлениями в день, а ограничение времени запланированного обновления не налагается.

Перегородки

Секции таблицы семантической модели не отображаются и не могут управляться с помощью Power BI Desktop или службы Power BI. Для моделей в рабочей области, назначенной емкости Premium, управление разделами можно осуществлять через XMLA endpoint. Вы можете использовать такие инструменты, как SQL Server Management Studio (SSMS) или табличный редактор с открытым исходным кодом для управления секциями с помощью скриптов с помощью языка скриптов табличной модели (TMSL) и программно с табличной объектной моделью (TOM).

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

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

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

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

Например, если текущая дата — 2 февраля 2021 г. и таблица FactInternetSales в источнике данных содержит строки до сегодняшнего дня, если наша политика указывает на включение изменений в режиме реального времени, обновление строк за последний день обновления и хранение строк за последние три года. Затем с первой операцией обновления создается раздел DirectQuery для изменений в будущем. Создается новый раздел импорта для сегодняшних строк, а исторический раздел создается для вчерашнего целого дня, 1 февраля 2021 года. Исторический раздел создается за предыдущий весь месяц (январь 2021 г.). Исторический раздел создается за весь предыдущий годовой период (2020). Создаются исторические секции за весь 2019 и весь 2018 год. Четвертные разделы не могут быть созданы, потому что 2 февраля первый полный квартал 2021 года еще не завершен.

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

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

Модель всегда сохраняет секции в течение всего периода исторического хранения, а также секции всего периода до текущего периода обновления. В этом примере сохраняются в разделах полные три года исторических данных за 2018, 2019, 2020 годы, а также разделы за период 2021Q101, период 2021Q10201 и текущий ежедневный период обновления. Так как в примере хранятся исторические данные в течение трех лет, секция 2018 г. сохраняется до первого обновления 1 января 2022 г.

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

Общие шаблоны обновления разделов

При работе с операциями конечной точки XMLA следует учитывать эти распространенные шаблоны для управления операциями обновления:

• Частые небольшие обновления: выполнение нескольких небольших целевых операций обновления в рабочие часы с помощью команд секции XMLA или расширенного REST API для сохранения последних данных без обработки всей таблицы.
• Выборочные исторические изменения: выполнение более крупных обновлений исторических партиций или однократных исправлений данных в нерабочее время с помощью TMSL для applyRefreshPolicy: false перестройки конкретных исторических периодов, не влияя на поведение автоматической политики.
• Начальные этапы загрузки: Для больших исторических периодов разбить начальную загрузку на небольшие пакеты путем обработки разделов поэтапно, чтобы избежать превышения времени ожидания и управлять потреблением ресурсов.

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

Обновление управления с помощью SQL Server Management Studio

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

Переопределение поведения добавочного обновления

При использовании SSMS вы также можете управлять вызовом обновлений с помощью языка скриптов табличной модели и табличной объектной модели. Например, в SSMS, в обозревателе объектов щелкните правой кнопкой мыши таблицу и выберите пункт меню "Обработка таблицы", а затем выберите кнопку "Сценарий", чтобы создать команду обновления TMSL.

Эти параметры можно использовать с командой обновления TMSL для переопределения поведения добавочного обновления по умолчанию:

• applyRefreshPolicy. Если для таблицы определена политика добавочного обновления, applyRefreshPolicy определяет, применяется ли эта политика. Если политика не применяется, полная операция процесса оставляет определения разделов без изменений, и все разделы в таблице полностью перезагружаются. Значение по умолчанию — «истина».

• effectiveDate. Если применяется политика добавочного обновления, необходимо знать текущую дату, чтобы определить диапазоны последовательного окна для добавочного обновления и исторических периодов. Параметр effectiveDate позволяет переопределить текущую дату. Этот параметр полезен для тестирования, демонстрации и бизнес-сценариев, когда данные постепенно обновляются до даты в прошлом или будущем, например бюджеты в будущем. Значение по умолчанию — текущая дата.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Дополнительные сведения о переопределении поведения добавочного обновления по умолчанию с помощью TMSL см. в команде "Обновление".

Управление политиками с помощью табличного редактора

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

Обновление оркестрации и автоматизации

Помимо использования SSMS, TMSL и TOM для управления обновлениями через конечную точку XMLA. Вы также можете оркестрировать операции обновления семантической модели с помощью REST API Power BI. Расширенный API обновления предоставляет дополнительные возможности, включая обновление на уровне таблицы и секционирования, логику повторных попыток, отмену и пользовательское управление временем ожидания. Этот подход полезен для интеграции операций обновления в автоматизированные рабочие процессы и конвейеры CI/CD. Подробные инструкции см. в расширенном обновлении с помощью REST API Power BI.

Обеспечение оптимальной производительности

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

• Таблица, настроенная для добавочного обновления, должна получать данные из одного источника данных. Если таблица получает данные из нескольких источников данных, количество запросов, отправляемых службой для каждой операции обновления, умножается на количество источников данных, что потенциально снижает производительность обновления. Убедитесь, что запрос к таблице добавочного обновления предназначен для одного источника данных.
• Для решений с добавочным обновлением секций импорта и данных в режиме реального времени с помощью Direct Query все секции должны запрашивать данные из одного источника данных.
• Если ваши требования к безопасности позволяют, установите для параметра уровня конфиденциальности источника данных значение Организация или Общедоступная. По умолчанию уровень конфиденциальности является частным. Однако этот уровень может препятствовать обмену данными с другими облачными источниками. Чтобы задать уровень конфиденциальности, выберите меню "Дополнительные параметры" и выберите "Параметры> учетныхданных> источника данных", чтобыизменить>параметры уровня конфиденциальности для этого источника данных. Если уровень конфиденциальности установлен в модели Power BI Desktop перед публикацией в службу, он не передается в службу при публикации. Необходимо все равно установить это в параметрах семантической модели на службе. Дополнительные сведения см. в разделе "Уровни конфиденциальности".
• При использовании локального шлюза данных убедитесь, что вы используете версию 3000.77.3 или более поздней.

Предотвращение времени ожидания при первоначальном полном обновлении

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

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

Применение политики обновления

Инструмент с открытым исходным кодом Tabular Editor 2 предоставляет простой способ инициализации начальной операции обновления. После публикации модели с политикой добавочного обновления, определенной для нее из Power BI Desktop в службу, подключитесь к модели с помощью конечной точки XMLA в режиме чтения и записи. Запустите Применить политику обновления для таблицы добавочного обновления. При применении только политики создаются разделы, но данные в них не загружаются. Затем подключитесь к SSMS, чтобы обновить секции последовательно или в пакетах для загрузки и обработки данных. Дополнительные сведения см. в документации по инкрементальному обновлению в Tabular editor.

Фильтр Power Query для пустых секций

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

Выбрав "Закрыть" и "Применить " в редакторе Power Query, определив политику добавочного обновления и сохранив модель, модель будет опубликована в службе. Из службы запускается начальная операция обновления модели. Секции для таблицы FactInternetSales создаются в соответствии с политикой, но данные не загружаются и обрабатываются, так как все данные отфильтровываются.

После завершения начальной операции обновления возвращаемся в редактор Power Query, где другой фильтр столбца ProductKey удаляется. После нажатия кнопки "Закрыть" и "Применить " в редакторе Power Query и сохранения модели модель не публикуется снова. Если модель опубликована снова, она перезаписывает настройки политики инкрементного обновления и принудительно вызывает полное обновление модели при выполнении последующей операции обновления из службы. Вместо этого выполните развертывание только метаданных с помощью набора средств управления жизненным циклом приложений (ALM), удаляющего фильтр из столбца модели . Затем SSMS можно использовать для выборочного обработки секций. Когда все секции полностью обработаны, включая пересчет процесса во всех секциях из SSMS, последующие операции обновления модели из службы обновляют только секции с добавочным обновлением.

Дополнительные сведения об обработке таблиц и секций из SSMS см. в статье "Обработка базы данных, таблицы или секций" (службы Analysis Services). Дополнительные сведения об обработке моделей, таблиц и секций с помощью TMSL см. в статье "Обновить команду ( TMSL)".

Пользовательские запросы для обнаружения изменений данных

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

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

В следующем примере рассматриваются все 120 месяцев за исторический период для изменений с задним числом. Указание 120 месяцев вместо 10 лет означает, что сжатие данных может быть не столь эффективным. Тем не менее он избегает обновления целого исторического года, которое было бы дороже, если бы месяца было достаточно для изменения задним числом.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Развертывание только метаданных

При публикации новой версии файла .pbix из Power BI Desktop в рабочую область. Вы увидите следующий запрос на замену существующей модели, если модель с таким же именем уже существует.

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

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

Для рабочих областей, назначенных емкости "Premium", настроенной для конечной точки XMLA для чтения и записи, совместимые инструменты позволяют развертывание только метаданных. Например, набор средств ALM — это средство диффы схемы для моделей Power BI и может использоваться только для развертывания метаданных.

Скачайте и установите последнюю версию инструментария ALM из репозитория Git Служб анализа. Пошаговые инструкции по использованию набора средств ALM не включены в документацию Майкрософт. Ссылки и сведения о поддержке набора средств ALM доступны на ленте справки . Чтобы выполнить развертывание только метаданных, сравните и выберите запущенный экземпляр Power BI Desktop как источник, а существующую модель в службе Power BI как целевой объект. Учитывайте отображаемые различия и пропустите обновление таблицы с сегментами инкрементного обновления или используйте диалоговое окно "Параметры", чтобы сохранить разделы для обновления таблицы. Проверьте выбор, чтобы обеспечить целостность целевой модели, а затем обновить.

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

Вы также можете использовать TMSL и TOM для добавления политики добавочного обновления в существующую модель через конечную точку XMLA.

Процесс включает следующие шаги:

1. Убедитесь, что целевая модель имеет необходимый минимальный уровень совместимости. В SSMS щелкните правой кнопкой мыши по [имя модели]>, выберите Свойства>, затем Уровень совместимости. Чтобы повысить уровень совместимости, используйте скрипт createOrReplace TMSL или проверьте следующий пример кода TOM.

   a. Import policy - 1550
   b. Hybrid policy - 1565
   

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

3. Определите RefreshPolicy объект с требуемым архивированием (скользящим окном) и периодами добавочного обновления, а также исходным выражением, которое фильтрует целевую таблицу на основе параметров RangeStart и RangeEnd. Задайте режим политики обновления для импорта или гибридного использования в зависимости от требований к данным в режиме реального времени. Гибридная функция заставляет Power BI добавить в таблицу раздел DirectQuery, чтобы извлечь последние изменения из источника данных, произошедшие после последнего обновления.

4. Добавьте политику обновления в таблицу и выполните полное обновление, чтобы Power BI секционирует таблицу в соответствии с вашими требованиями.

В следующем примере кода показано, как выполнить предыдущие шаги с помощью TOM. Если вы хотите использовать этот пример как есть, необходимо иметь копию базы данных AdventureWorksDW и импортировать таблицу FactInternetSales в модель. В примере кода предполагается, что в модели отсутствуют параметры RangeStart и RangeEnd, а также функция DateKey. Просто импортируйте таблицу FactInternetSales и опубликуйте модель в рабочую область в Power BI Premium. Затем обновите workspaceUrl, чтобы пример кода смог подключиться к вашей модели. При необходимости обновите любые дополнительные строки кода.

using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
    class Program
    {
        static string workspaceUrl = "<Enter your Workspace URL here>";
        static string databaseName = "AdventureWorks";
        static string tableName = "FactInternetSales";
        static void Main(string[] args)
        {
            using (var server = new TOM.Server())
            {
                // Connect to the dataset.
                server.Connect(workspaceUrl);
                TOM.Database database = server.Databases.FindByName(databaseName);
                if (database == null)
                {
                    throw new ApplicationException("Database cannot be found!");
                }
                if(database.CompatibilityLevel < 1565)
                {
                    database.CompatibilityLevel = 1565;
                    database.Update();
                }
                TOM.Model model = database.Model;
                // Add RangeStart, RangeEnd, and DateKey function.
                model.Expressions.Add(new TOM.NamedExpression {
                    Name = "RangeStart",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "RangeEnd",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "DateKey",
                    Kind = TOM.ExpressionKind.M,
                    Expression =
                        "let\n" +
                        "    Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
                        "in\n" +
                        "    Source"
                });
                // Apply a RefreshPolicy with Real-Time to the target table.
                TOM.Table salesTable = model.Tables[tableName];
                TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
                {
                    Mode = TOM.RefreshPolicyMode.Hybrid,
                    IncrementalPeriodsOffset = -1,
                    RollingWindowPeriods = 1,
                    RollingWindowGranularity = TOM.RefreshGranularityType.Year,
                    IncrementalPeriods = 1,
                    IncrementalGranularity = TOM.RefreshGranularityType.Day,
                    SourceExpression =
                        "let\n" +
                        "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
                        "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
                        "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
                        "in\n" +
                        "    #\"Filtered Rows\""
                };
                salesTable.RefreshPolicy = hybridPolicy;
                model.RequestRefresh(TOM.RefreshType.Full);
                model.SaveChanges();
            }
            Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
            Console.ReadLine();
        }
    }
}

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

• Настройка добавочного обновления и данных в режиме реального времени
• Устранение неполадок с инкрементным обновлением и данными реального времени
• Расширенное обновление с помощью REST API Power BI
• Секции в табличных моделях
• Внешние инструменты в Power BI Desktop
• Настройка запланированного обновления