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

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

Секции

Секции таблицы семантической модели не отображаются и не могут управляться с помощью Power BI Desktop или служба Power BI. Для моделей в рабочей области, назначенной емкости Premium, секции можно управлять с помощью конечной точки XMLA с помощью таких средств, как 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 год создаются в течение всего года. Не создаются целые кварталы секций, так как мы еще не завершили первый полный квартал 2021 года.

Diagram shows the partition naming granularity described in the text.

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

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

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

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

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

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

Screenshot shows the Partitions window in SSMS.

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

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

Screenshot shows the Script button in Process Table dialog.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screenshot show the Tabular Editor with Apply Refresh Policy selected.

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

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

Screenshot shows the Power Query Editor with code that filters out the product key.

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

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

Совет

Не забудьте проверка видео, блоги и многое другое, предоставляемое сообществом экспертов Power BI.

Дополнительные сведения об обработке таблиц и секций из 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 ..."
    ]
}

Совет

Не забудьте проверка видео, блоги и многое другое, предоставляемое сообществом экспертов Power BI.

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

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

Screenshot shows the Replace model dialog.

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

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

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

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

Screenshot shows the ALM Toolkit window.

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

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

Примечание.

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

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

  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 модели отсутствуют параметры и RangeEndDateKey параметры. Просто импортируйте таблицу 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();
        }
    }
}