Обзор Service Manager кубов OLAP для расширенной аналитики

Важно!

Поддержка этой версии Service Manager завершена. Мы рекомендуем выполнить обновление до Service Manager 2022.

В Service Manager данные, имеющиеся в хранилище данных, можно консолидировать из различных источников. Она представлена в Service Manager с помощью предопределенных и настроенных кубов данных microsoft Online Analytic Processing (OLAP). Короче говоря, расширенная аналитика в Service Manager состоит из публикации, просмотра и управления данными куба, как правило, в Microsoft Excel или Microsoft SharePoint. Excel в основном используется для просмотра и манипулирования данными. SharePoint в основном используется как средство публикации данных куба и открытия общего доступа к ним.

Service Manager включает в себя хранилище данных system Center. Таким образом, данные из Operations Manager, Configuration Manager и Service Manager можно консолидировать в хранилище данных, где можно легко использовать несколько представлений данных для получения любой необходимой информации. Кроме того, предусмотрен интерфейс, позволяющий поместить в хранилище данные из собственных пользовательских источников, таких как приложения SAP или приложения отдела кадров от сторонних разработчиков. Подобная консолидация создает общую модель данных и дает возможность выполнять обогащенный анализ, что позволяет вашему ИТ-отделу построить хранилище данных, способное обеспечить все его нужды в сфере производства отчетов и бизнес-аналитики.

Помещение данных в общую модель позволяет манипулировать информацией и создавать общие определения и таксономию для всего предприятия. Это достигается путем развертывания кубов OLAP и просмотра имеющейся в них информации с помощью стандартных средств, таких как Excel и SharePoint. Такой подход позволяет пользователям использовать уже имеющиеся у них навыки. Вы контролируете определение своей бизнес-логики в централизованном режиме. К примеру, вы можете определить ключевые показатели эффективности, такие как пороги допустимого времени устранения инцидента и указать, какие значения будут расцениваться как "зеленый", "желтый" и "красный" пороги. Данную настройку можно выполнять в централизованном режиме, позволяя пользователям с легкостью использовать данные и наблюдать общее определение в своих отчетах Excel и панелях мониторинга SharePoint.

Сведения о Service Manager кубах OLAP

Кубы оперативной аналитической обработки (OLAP) — это функция в Service Manager, которая использует существующую инфраструктуру хранилища данных для предоставления пользователям возможностей самостоятельной бизнес-аналитики.

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

Поставщики программного обеспечения или ИТ-разработчики, имеющие опыт работы с кубами OLAP, могут создавать пакеты управления для определения собственных расширяемых и настраиваемых кубов OLAP, созданных на основе инфраструктуры хранилища данных. Такие кубы хранятся в службах SQL Server Analysis Services (SSAS). Средства самостоятельной бизнес-аналитики, такие как Excel и SQL Server Reporting Services (SSRS), позволяют выбирать эти кубы в составе служб SSAS и использовать их для анализа данных с различных перспектив.

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

Кубы OLAP — это звено, завершающее облик решения по созданию и обслуживанию хранилищ данных. Куб OLAP, также известный как многомерный куб или "гиперкуб", представляет из себя структуру данных в составе служб SQL Server Analysis Services (SSAS), которая создается на основе баз данных OLAP и позволяет выполнять почти моментальный анализ данных. Топология данной системы показана на иллюстрации ниже.

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

Цель main Service Manager кубов OLAP заключается в том, чтобы предоставить поставщикам программного обеспечения или ИТ-разработчикам возможность выполнять практически мгновенный анализ данных как для исторического анализа, так и для популярных целей. Service Manager делает это следующим образом:

• Возможность встраивать определения кубов OLAP в пакеты управления. Такие кубы автоматически создаются в службах SSAS при развертывании пакета управления.
• Автоматическое обслуживание куба без вмешательства пользователей, включая ряд задач, в том числе выполнение обработки, секционирования, перевода и локализации, а также изменения схемы.
• Предоставление пользователям средств самостоятельной бизнес-аналитики, таких как Excel, для анализа данных с различных перспектив.
• Сохранение созданных отчетов Excel для дальнейшего использования.

Чтобы увидеть, как кубы хранилища данных представлены в консоли Service Manager, перейдите в рабочую область Data Warehouse и выберите Кубики.

Service Manager кубов OLAP

На рисунке ниже показано изображение из среды SQL Server Business Intelligence Development Studio (BIDS), на котором представлены основные части, необходимые для создания и работы кубов OLAP. Эти части — источник данных, представление источника данных, кубы и измерения. В приведенных ниже разделах описываются части куба OLAP и действия, которые могут выполнять пользователи с их помощью.

Источник данных

Источник данных является источником всех данных, содержащихся в кубе OLAP. Куб OLAP подключается к источнику данных для чтения и обработки необработанных данных путем выполнения агрегирования и вычислений связанных с ними мер. Источником данных для всех Service Manager кубов OLAP являются киоски данных, которые включают киоски данных для Operations Manager и Configuration Manager. Чтобы установить правильный уровень разрешений, сведения аутентификации для источника данных должны быть сохранены в службах SQL Server Analysis Services (SSAS).

Представление источника данных

Представление источника данных (DSV) — это коллекция представлений, представляющих таблицы измерений, фактов и outrigger из источника данных, например Service Manager киоски данных. DSV отображает все отношения между таблицами, в том числе первичные и внешние ключи. Другими словами, DSV показывает, как база данных SSAS будет сопоставлена с реляционной схемой, и предоставляет слой абстрагирования поверх реляционной базы данных. Данный слой абстрагирования позволяет определять отношения между таблицами фактов и измерений даже при отсутствии отношений в исходной реляционной базе данных. В DSV также можно определять именованные вычисления, пользовательские меры и новые атрибуты, отсутствующие в схеме измерений хранилища данных. Например, именованное вычисление, определяющее логическое значение для incidents Resolved , вычисляет значение true, если состояние инцидента разрешено или закрыто. Используя именованное вычисление, Service Manager затем может определить меру для отображения полезной информации, такой как процент разрешенных инцидентов, общее число разрешенных инцидентов и общее число инцидентов, которые не разрешены.

Еще один краткий пример именованного вычисления — ReleasesImplementedOnSchedule. Это именованное вычисление выполняет быструю проверку состояния работоспособности, подсчитывая количество записей о выпусках, в которых фактическая дата реализации прежде или равна запланированной.

Кубы OLAP

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

Измерения

Измерение в SSAS ссылается на измерение из хранилища данных Service Manager. В Service Manager измерение примерно эквивалентно классу пакета управления. Каждый класс пакета управления имеет набор свойств, а каждое измерение — набор атрибутов, при этом каждый атрибут сопоставляется с одним свойством класса. Измерения позволяют выполнять фильтрацию, группирование и маркировку данных. К примеру, можно отфильтровать компьютеры по установленной операционной системе или сгруппировать людей по категориям, используя пол или возраст. Затем данные можно представить в формате, в котором данные естественным образом классифицируются по этим иерархиям и категориям, чтобы обеспечить более глубокий анализ. Измерения также могут иметь естественные иерархии, позволяющие пользователям "детализировать" до более подробных уровней детализации. К примеру, измерение даты обладает иерархией, позволяющей выполнять детализацию до уровня лет, затем — до уровней кварталов, месяцев, недель и отдельных дней.

В следующем рисунке показан куб OLAP, содержащий измерения даты, региона и продукта.

Например, участникам команды Майкрософт может потребоваться быстрая и простая сводка о продажах игровой консоли Xbox One в соответствующей версии. Они могут детализировать данную сводку для получения сведений о продажах за более узкий интервал времени. Бизнес-аналитики могут изучить, как продажи консолей Xbox One повлияли на запуск нового дизайна консоли и Kinect для Xbox One. Такая информация позволяет им выявить происходящие в сфере продаж тренды и разработать потенциальную корректировку бизнес-стратегии компании. Фильтрация по измерению даты позволяет быстро доставлять и использовать данную информацию. Описанное создание объемных и плоскостных срезов данных возможно благодаря наличию в измерениях атрибутов и данных, позволяющих клиенту с легкостью выполнять их фильтрацию и группирование.

В Service Manager все кубы OLAP имеют общий набор измерений. Все измерения используют в качестве источника основной киоск данных хранилища данных, даже при наличии нескольких киосков данных. Таким образом, наличие нескольких киосков данных может привести к ошибкам ключей измерения при обработке куба.

Группа мер

Концепция группы мер совпадает с термином "факт" в контексте хранилища данных. Подобно тому, как факты содержат числовые меры в хранилище данных, группа мер содержит меры для куба OLAP. Все меры в кубе OLAP, происходящие от одной таблицы фактов в представлении источника данных, также могут считаться группой мер. Однако в определенных случаях меры в кубе OLAP могут происходить от нескольких таблиц фактов. Меры одинакового уровня детализации объединяются в одну группу мер. Группы мер определяют, какие данные будут загружены в систему, каким образом они будут загружены, а также как данные будут привязаны к многомерному кубу.

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

Меры

Меры — это числовые значения, которые пользователи хотят срезать, нарезать кости, агрегировать и анализировать; они являются одной из основных причин, по которым требуется создавать кубы OLAP с помощью инфраструктуры хранилища данных. При помощи служб SSAS можно создавать кубы OLAP, использующие бизнес-правила и вычисления для форматирования и отображения мер в настраиваемом формате. Большой объем времени разработки куба OLAP тратится на определение того, какие меры будут отображены, и каким образом они будут вычисляться.

Меры — это значения, обычно сопоставляемые с числовыми столбцами в таблице фактов хранилища данных, но их также можно создать из атрибутов измерения или вырожденного измерения. Эти меры являются самыми важными анализируемыми значениями куба OLAP и представляют основной интерес для пользователей, просматривающих куб OLAP. Пример меры, существующей в хранилище данных — ActivityTotalTimeMeasure. ActivityTotalTimeMeasure — это мера из факта ActivityStatusDurationFact, обозначающая время, которое каждое действие проводит в определенном состоянии. Уровень детализации меры состоит из всех охваченных ей измерений. К примеру, уровень детализации факта отношений ComputerHostsOperatingSystem состоит из измерений Computer и Operating System.

Функции агрегирования осуществляют вычисление на основе мер для возможности дальнейшего анализа данных. Наиболее распространенные функцией агрегирования является Sum ("Сумма"). Один из распространенных запросов к кубу OLAP, к примеру, суммирует продолжительность всех действий, имеющих состояние In Progress. Другие распространенные функции агрегирования — Min, Max и Count.

После завершения обработки необработанных данных в кубе OLAP пользователи могут выполнять более сложные вычисления и запросы, используя многомерные выражения (MDX) для определения собственных выражений мер и их вычисляемых элементов. MDX — это отраслевой стандарт для операций запроса и доступа к данным, сохраненным в системах OLAP. SQL Server не предназначен для работы с моделью данных, поддерживаемой многомерными базами данных.

Детализация

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

• Детализация данных для просмотра демографической информации о населении США, затем штата Вашингтон, затем — муниципального района Сиэтл, города Редмонд и, в заключение, штаб-квартиры Майкрософт.
• Детализация данных о продажах консолей Xbox One за 2015 календарный год, затем за четвертый квартал года, затем за декабрь, за неделю до Рождества и, наконец, канун Рождества.

Детализация

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

Часто путают термины детализации и детализации друг с другом. Разница между main заключается в том, что детализация работает с предопределенной иерархией данных, например, США, затем в Вашингтоне, затем в Сиэтле в кубе OLAP. Детализация "drill-through" позволяет перейти на самый низший уровень детализации и извлечь из источника данных набор строк, составляющих одну ячейку агрегата.

Ключевой показатель эффективности

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

Пример показателя KPI: выполнить все запросы на изменение в течение 48 часов. Показатель KPI можно использовать для определения процентной доли выполненных в течение этого интервала времени запросов на изменение. Для визуального представления показателей KPI предусмотрена возможность создания панелей мониторинга. Например, можно определить целевое значение KPI как "выполнить все запросы на изменение в течение 48 часов на 75 процентов".

Секции

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

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

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

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

Статистические схемы

Агрегаты в кубе OLAP — это предварительно просуммированные наборы данных. Они аналогичны инструкции SQL SELECT с предложением GROUP BY. Службы SSAS могут использовать эти агрегаты при ответе на запросы, чтобы сократить количество необходимых вычислений и быстро возвращать ответы пользователю. Агрегаты, встроенные в куб OLAP, сокращают количество операций агрегирования, выполняемых службами SSAS во время запроса. Построение правильных агрегатов может существенно улучшить производительность запросов. Зачастую это процесс, развивающийся в течение времени существования куба OLAP по мере изменения его запросов и использования.

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

Service Manager использует следующие два варианта при сборке и проектировании агрегатов в Service Manager кубах OLAP:

• Рост производительности достиг
• Оптимизация с учетом использования

Параметр "Рост производительности достиг" определяет процент создаваемых агрегатов. Например, если для этого параметра установить используемое по умолчанию рекомендуемое значение в 30 процентов, построение агрегатов будет продолжаться до тех пор, пока предполагаемый рост производительности куба OLAP не составит 30 процентов. Однако это не означает, что будет построено 30 процентов возможных агрегатов.

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

секционирование кубов Service Manager

Все группы мер в кубе поделены на разделы, каждый из которых определяет часть данных факта, загружаемую в группу мер. SQL Server Analysis Services (SSAS) в SQL Server Standard Edition допускает только одну секцию для каждой группы мер, в то время как в выпуск Enterprise допускается несколько секций. Разделы полностью прозрачны для пользователя, однако они имеют большое влияние на производительность и масштабируемость. Например, разделы могут быть обработаны по отдельности и параллельно. Они могут иметь разные схемы агрегирования. Можно выполнить повторную обработку раздела, не затрагивая другие разделы группы мер. Кроме того, система SSAS автоматически сканирует только те разделы, которые содержат необходимые для запроса данные, что позволяет значительно повысить производительность запросов.

Секционирование кубов выполняется при каждом запуске задания по обслуживанию хранилища данных — по умолчанию ежечасно. Выполняемый модуль данного процесса называется ManageCubePartitions. Его выполнение происходит всегда после этапа CreateMartPartitions. Данные зависимостей хранятся в таблице infra.moduletriggercondition.

Главная библиотека DLL, ответственная на секционирование, находится в служебной библиотеке DLL хранилища, Microsoft.EnterpriseManagement.Warehouse.Utility, в классе PartitionUtil. В частности, в классе есть метод ManagePartitions(), который обрабатывает все обслуживание секций. Используемые для обслуживания и оперативной аналитической обработки хранилища данных библиотеки DLL Microsoft.EnterpriseManagement.Warehouse.Maintenance и Microsoft.EnterpriseManagement.Warehouse.Olap, вызывают библиотеку Microsoft.EnterpriseManagement.Warehouse.Utility для обработки разделов во время обслуживания хранилища и развертывания куба. Таким образом фактическое управление разделами осуществляется в общей служебной библиотеке DLL во избежание дублирования логики и кода.

Функция обслуживания секционирования куба выполняет следующие задачи:

• Создание секций
• Удаление разделов
• Обновление границ разделов

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

1. Запуск обработки куба для каждой группы мер в кубе
2. Получение всех разделов из таблицы etl.TablePartition для группы мер
3. Удаление всех разделов, имеющихся в группе мер, но отсутствующих в таблице etl.TablePartition
4. Добавление всех новых разделов, существующих только в таблице etl.TablePartition
5. Обновление разделов, которые могли измениться, путем сопоставления каждого раздела с параметрами RangeStartDate и RangeEndDate в таблице etl.TablePartition

Помните о следующих нюансах обработки куба:

• Только группы мер, предназначенные для фактов, содержат несколько секций в SQL Server Standard Edition. По умолчанию все группы мер и измерения содержат только один раздел. Таким образом, у секции нет граничных условий.
• Границы раздела определяются с помощью привязки запроса, основанной на ключах дат, совпадающих с ключами дат соответствующего раздела факта в таблице etl.TablePartition.

развертывание куба OLAP Service Manager

Развертывание куба оперативной аналитической обработки (OLAP) использует инфраструктуру развертывания Service Manager для создания кубов OLAP в базе данных SQL Server Analysis Services (SSAS).

Развертываемый элемент возвращает развертывающий объект с коллекцией ресурсов, которые сериализуются и используются для создания куба OLAP в базе данных SSAS. В кубах OLAP развертываемый объект называется CubeDeployable (для элемента SystemCenterCubе) или CubeExtensionDeployable (для элемента CubeExtension). Развертывающим объектом для обоих элементов является CubeDeployer.

Таблица dbo.Selector в базе данных DWStagingAndConfig содержит данные по обоим элементам пакета управления (SystemCenterCube и CubeExtension). Подсистема развертывания использует эти метаданные в том случае, если при импорте пакета управления в хранилище данных с применением задания MPSync требуется дополнительная обработка элемента пакета управления.

В ходе развертывания для создания и модификации всех компонентов куба в базе данных SSAS используется программный интерфейс объектов AMO. В частности, объект AMO в отключенном режиме используется, так как элемент CubeDeployable не будет иметь подключения к базе данных SSAS. Работа с объектами AMO в разъединенном режиме позволяет создавать полное дерево объектов AMO без подключения к серверу. Service Manager затем сериализует иерархию объектов в виде потоковых ресурсов и присоединяет их к объекту средства развертывания, который передается обратно в инфраструктуру развертывания. Затем выполняется десериализация развертывающего объекта, устанавливается подключение к базе данных SSAD и создаются объекты с помощью отправки соответствующих запросов в базу данных.

Возможна сериализация только главных объектов. В контексте объектов AMO главными объектами считаются классы, которые представляют собой завершенный объект в виде завершенной сущности, не являющийся частью другого объекта. Например, к основным объектам относятся Server, Cube и Dimension, которые являются автономными сущностями. DimensionAttribute, однако, не является основным объектом, так как его можно создать только как часть родительского основного объекта Dimension. DimensionAttribute, таким образом, является дополнительным объектом. Проектировочный этап куба OLAP сфокусирован на создании всех главных объектов, необходимых кубу, вместе с их зависимыми дополнительным объектами. Эти основные объекты являются объектами, которые будут сериализованы и, в конечном итоге, десериализуются до создания объектов в базе данных SSAS.

Для успешного завершения развертывания и удовлетворения зависимостей, предъявляемых элементами куба OLAP, ресурсы, обертывающие главные объекты, должны быть созданы в определенном порядке. В двух представленных ниже списках показана последовательность развертывания элементов SystemCenterCube и CubeExtension, соответственно.

1. элементы DataSourceView
2. элементы измерения
3. элемент измерения даты
4. элемент куба
5. элементы DataSourceView
6. элемент куба

Service Manager обработки куба OLAP

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

1. Извлечение: извлечение данных из исходной системы.
2. Преобразование: применение функций для приведения данных в соответствие со стандартной схемой измерений.
3. Загрузка: загрузка данных в киоск данных для потребления.
4. Процесс: загрузка данных из киоска данных в куб OLAP для просмотра.

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

Обработка куба OLAP состоит из двух отдельных задач:

1. Обработка измерений.
2. Обработка разделов.

Каждый куб OLAP имеет соответствующее задание обработки в консоли Service Manager и выполняется по настраиваемому пользователем расписанию. Эти задания описаны в разделах, приведенных ниже.

Обработка измерений.

Каждое добавляемое в базу данных SSAS измерение должно подвергнуться полной обработке, чтобы получить состояние "обработано". Однако после обработки измерения нет никакой гарантии, что оно будет обработано снова при обработке другого куба, предназначенного для того же измерения. Если не выполнять автоматическую повторную обработку измерения, Service Manager не может повторно обрабатывать каждое измерение для каждого куба. Это особенно верно, если измерение было недавно обработано, так как маловероятно, что существуют новые данные, которые еще не были обработаны. Для оптимизации эффективности обработки существует одноэлементный класс, определенный в пакете управления Microsoft.SystemCenter.Datawarehouse.OLAP.Base с именем Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. Образец данного класса приведен ниже.

<!-- This singleton class defines the minimum interval of time in minutes that must elapse before a shared dimension is reprocessed. -->   
<ClassType ID="Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval" Accessibility="Public" Abstract="false" Base="AdminItem!System.AdminItem" Singleton="true">  
<Property ID="IntervalInMinutes" Type="int" Required="true" DefaultValue="60"/>  
</ClassType>  

Данный Singleton-класс содержит свойство IntervalInMinutes, определяющее частоту обработки измерения. По умолчанию это свойство имеет значение 60 минут. Например, если измерение было обработано в 15:05, а другой куб, предназначенный для этого же измерения, обрабатывается в 15:45, измерение не будет повторно обработано. Недостатком данного подхода является повышение вероятности ошибок в ключах измерения. Механизм повторной попытки обрабатывает ошибки ключей измерения, чтобы выполнить повторную обработку измерения с последующей обработкой раздела куба. Дополнительные сведения о сбоях обработки см. в разделе "Распространенные проблемы с отладкой и устранением неполадок".

После полной обработки измерения выполняется добавочная обработка с помощью операции ProcessUpdate . Операция ProcessFull выполняется лишь в еще одном случае — при изменении схемы измерения, поскольку это действие приводит к возврату измерения в необработанное состояние. Помните, что если ProcessFull выполняется в измерении, все затронутые кубы и их секции будут находиться в необработанном состоянии, и они должны быть полностью обработаны при следующем запланированном запуске.

Обработка разделов.

Обработка секций должна быть тщательно рассмотрена, так как повторная обработка большой секции выполняется медленно и потребляет много ресурсов ЦП на сервере, на котором размещаются службы SSAS. Как правило, обработка разделов занимает больше времени, чем обработка измерений. В отличие от обработки измерений, обработка разделов не имеет влияния на другие объекты. Единственными двумя типами обработки, выполняемыми в System Center Service Manager кубами OLAP, являются ProcessFull и ProcessAdd.

Подобно измерениям, создание новых разделов в кубе OLAP требует, чтобы относящаяся к разделу задача ProcessFull находилась в состоянии, реагирующем на запросы. Поскольку задача ProcesFull — ресурсоемкая операция, ее следует выполнять только при необходимости, например, при создании раздела или при обновлении строки. В сценариях, в которых строки были добавлены и строки не были обновлены, Service Manager может выполнять задачу ProcessAdd. Для этого Service Manager использует подложки и другие метаданные. При этом опрашиваются таблицы etl.cubepartition и etl.tablepartition для определения режима необходимой обработки.

На следующей схеме показано, как Service Manager определяет тип обработки на основе данных водяного знака.

При выполнении задачи ProcessAdd Service Manager ограничивает область запроса с помощью подложек. Например, если значение InsertedBatchId равно 100, а значение WatermarkBatchId — 50, запрос загружает данные только из того киоска данных, где InsertedBatchId имеет значение больше 50 и меньше 100.

Наконец, важно отметить, что Service Manager не поддерживает обработку кубов OLAP вручную с помощью служб SSAS или Business Intelligence Development Studio. Обработка кубов за пределами методов, предоставляемых в System Center— Service Manager, включая консоль Service Manager и командлеты Service Manager, не обновляет таблицы подложек. Поэтому могут возникнуть проблемы с целостностью данных. Если вы случайно повторно обработали куб вручную, одним из возможных обходных путей является отмена обработки куба OLAP вручную таким же образом. В следующий раз, когда Service Manager обработает куб, он автоматически выполнит задачу ProcessFull, так как секции будут находиться в необработанном состоянии. Это приведет к корректному обновлению всех водяных знаков и метаданных, что позволит устранить все возможные проблемы целостности данных.

Обслуживание Service Manager кубов OLAP

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

Периодическая повторная обработка измерений служб Analysis Services

При работе со службами SQL Server Analysis Services рекомендуется регулярно выполнять полную обработку измерений SSAS. При полной обработке измерений происходит перестройка индексов и оптимизация хранения многомерных данных, что повышает производительность запросов (а также производительность куба), которая может снижаться с течением времени. Это процесс подобен регулярной дефрагментации жесткого диска на компьютере.

Негативным последствием полной обработки измерения SSAS является то, что все соответствующие кубы OLAP становятся необработанными и должны тоже быть полностью обработаны для возврата в состояние, позволяющее им отвечать на запросы. Service Manager явно не обрабатывается в измерениях SSAS. Время выполнения этой задачи обслуживания необходимо выбрать самостоятельно.

Рекомендации по использованию памяти

Если все операции хранилища данных по извлечению, преобразованию и загрузке (ETL), а также функции куба OLAP выполняются на одном сервере, будьте внимательны при подсчете памяти, необходимой для работы операционной системы, хранилища данных и служб SSAS. Убедитесь, что сервер способен обеспечить одновременное выполнение множества операций обработки данных. Этот момент особенно важен, поскольку операция обработки кубов OLAP требовательна к памяти.

Дальнейшие действия

• Моделирование кубов OLAP в пакетах управления.