Секции в табличных моделях

Применимо к: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

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

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

Степень детализации данных

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

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

Секция Данные из
Продажи2020 Текущий финансовый год
Продажи2019–2010 Финансовые годы 2010, 2011, 2012, 2013, 2014, 2015. 2016, 2017, 2018, 2019
SalesOld Все финансовые годы перед последними десятью финансовыми годами.

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

Нет необходимости обрабатывать данные в секции Sales2019–2010 в ночное время. Тем не менее, поскольку данные о продажах за предыдущие десять финансовых лет по-прежнему могут изменяться из-за возврата продуктов и других корректировок, их по-прежнему необходимо обрабатывать регулярно, поэтому данные в разделе Sales2019–2010 обрабатываются ежемесячно. Данные в разделе SalesOld редко изменяются, поэтому обрабатываются только ежегодно.

При вводе 2021 финансового года в таблицу Sales модели добавляется новый раздел Sales2021. Затем раздел Sales2020 можно объединить с разделом Sales2019-2010 и переименовать в Sales2020-2011. Данные за 2010 финансовый год исключаются из раздела Sales2020–2011 и перемещаются в раздел SalesOld. Затем все секции обрабатываются для отражения изменений. Это обычно называется шаблоном последовательного окна : данные в каждой секции хранятся в пределах предопределенного диапазона дат и при необходимости увеличиваются, сохраняя использование памяти и ресурсов обработки в пределах прогнозируемого диапазона с течением времени.

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

Секционирование также эффективно для таблиц, содержащих данные из нескольких источников данных. Разные источники данных могут обновлять данные в разное время, что может определять разные требования к детализации и обработке данных таблицы модели. Например, таблица Orders в модели содержит транзакции заказов из двух разных таблиц фактов: factInternetOrders и factRetailOrders. В источнике данных factInternetOrders обновляется каждый час. FactRetailOrders, с другой стороны, обновляется только один раз в день после закрытия всех розничных магазинов. Создавая отдельные секции с разными детализациями в таблице "Заказы" модели для данных, импортированных из factInternetOrders и factRetailOrders, операции обработки в таблице Orders можно разделять и выполнять в большей степени с данными порядка в источниках данных.

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

Ограничения секций

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

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

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

Создание секций и управление ими

При создании моделей с помощью конструктора табличных моделей в Visual Studio вы создаете новые секции, редактируете, объединяете или удаляете секции в базе данных рабочей области модели с помощью диспетчера секций. В зависимости от уровня совместимости модели, которую вы создаете, диспетчер секций предоставляет два режима выбора данных для включения в секцию: для табличных моделей 1400 и более поздних версий со структурированными источниками данных секции определяются с помощью выражения Power Query M. Например, следующий запрос определяет секцию для 2019 календарного года:

let
    Source = #"SQL/sqlserver database windows net;Contoso",
    dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
    #"Filtered Rows"

Для источников данных поставщика секции определяются с помощью SQL-запроса. Например,

SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))

Обратите внимание, что аргумент Filtered Rows в выражении Power Query M и предложение WHERE в инструкции SQL определяют ровно один календарный год с помощью операторов больше (>), меньше (<) и равно (=). При определении секций важно, чтобы запрос каждой секции определял уникальный диапазон данных, который не может привести к дублированию данных с другими секциями.

SQL Server Management Studio (SSMS)

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

Язык TMSL

Секции для модели определяются в объекте Partitions. В следующем примере секция Sales2019 определяется как:

"partition": {
      "name": "Sales2019",
      "mode": "import",
      "source": {
        "type": "m",
        "expression": [
          "let",
          "    Source = #\"SQL/sqlserver database windows net;Contoso\",",
          "    dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
          "in",
          "    #\"Filtered Rows\""
        ]
      },

Действия с объектом Partitions можно указать в следующих командах TMSL:

Скрипты TMSL можно выполнять в SQL Server Management Studio, с помощью PowerShell, выполнив команду Invoke-ASCmd или задачу скрипта служб SQLServer Integration Services (SSIS).

Для моделей с уровнями совместимости 1100 и 1103 вместо TMSL используется язык сценариев служб Analysis Services (ASSL ).

Табличная объектная модель (TOM)

В табличной объектной модели секции определяются классом Partition в пространстве имен Microsoft.AnalysisServices.Tabular. Дополнительные сведения о программных решениях, использующих TOM в качестве API, см. в разделах Создание таблиц, секций и столбцов (TOM) и Дополнительные стратегии секционирования далее в этой статье.

Для моделей с уровнями совместимости 1100 и 1103 используйте объекты AMO.

Обработка секций

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

При разработке моделей в Visual Studio можно вручную выполнять операции обработки в разделах базы данных рабочей области из меню или панели инструментов. Для развернутых моделей операции обработки вызываются вручную с помощью диалогового окна «Таблицы обработки» в SSMS путем выполнения скрипта, содержащего команду Refresh (TMSL), или программно с помощью табличной объектной модели (TOM).

Параллельная обработка

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

MaxConnections

По умолчанию каждая операция обработки подключается к источнику данных для каждой секции и запрашивает его. Максимальное число подключений по умолчанию, указанное в качестве свойства MaxConnections к одному источнику данных, равно 10. Службы Analysis Services определяют количество параллельных операций обработки на основе количества ядер и доступных потоков. Эти потоки являются общими для экземпляра сервера. Одна команда, например процесс, может не принимать все доступные потоки. Потоки, запускаемые для обработки , по одному для каждой параллельной операции обработки, могут быть отложены, чтобы оставаться в пределах MaxConnections.

MaxParallelism

По умолчанию операции обработки выполняются параллельно, насколько это возможно. Однако можно выбрать обработку секций последовательно или параллельно, указав параметр свойства maxParallism с помощью команды Sequence (TMSL). Установка значения 1 означает, что для обработки используется не параллельный поток. Если задать значение 2 или более, то для параллельных операций обработки можно использовать фиксированное количество потоков.

Azure Monitor

Чтобы определить эффективное использование доступных потоков во время операций процесса, для Azure Analysis Services используйте Метрики Azure Обозреватель для мониторинга CommandPoolIdleThreads и CommandPoolBusyThreads. Чтобы узнать больше, ознакомьтесь с отслеживанием метрик сервера. Для SQL Server Analysis Services используйте Монитор производительности для отслеживания бездействующих потоков пула обработки, не являющихся потоками ввода-вывода, и пулом обработки занятых потоков, не являющихся потоками ввода-вывода. Дополнительные сведения см. в статье Счетчики производительности (SSAS).

Примечание

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

Расширенные стратегии секционирования

В статье Автоматизированное управление секциями для табличных моделей служб Analysis Services .pdf, а также сопутствующий пример кода AsPartitionProcessing в GitHub содержатся подробные сведения и пример решения для вымышленной компании Advenure Works с помощью табличной объектной модели (TOM) для создания секций и управления ими. Основные понятия, описанные в этой статье и проекте, применимы ко всем платформам служб Analysis Services.

См. также раздел

Создание секций табличных моделей и управление ими
Объект Partitions (TMSL)
Создание таблиц, секций и столбцов с помощью табличной объектной модели (TOM)
Создание секций (урок учебника)