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

В 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.

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

Кубы аналитической обработки в Сети (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, куб может почти мгновенно возвращать ответы на широкий спектр вопросов.

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

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

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

Кубы OLAP Service Manager

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

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

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

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

Представление источника данных (DSV) — это коллекция представлений, представляющих измерения, факты и переборы таблиц из источника данных, таких как киоски данных Service Manager. DSV отображает все отношения между таблицами, в том числе первичные и внешние ключи. Другими словами, DSV показывает, как база данных SSAS будет сопоставлена с реляционной схемой, и предоставляет слой абстрагирования поверх реляционной базы данных. Данный слой абстрагирования позволяет определять отношения между таблицами фактов и измерений даже при отсутствии отношений в исходной реляционной базе данных. В DSV также можно определять именованные вычисления, пользовательские меры и новые атрибуты, отсутствующие в схеме измерений хранилища данных. Например, именованное вычисление, определяющее логическое значение для "Устраненные инциденты ", вычисляет значение 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 могут происходить от нескольких таблиц фактов. Меры одинакового уровня детализации объединяются в одну группу мер. Группы мер определяют, какие данные будут загружены в систему, каким образом они будут загружены, а также как данные будут привязаны к многомерному кубу.

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

Показатели

Меры — это числовые значения, которые пользователи хотят срезать, dice, агрегировать и анализировать; это одна из основных причин, по которым вы хотите создать кубы 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. Другими словами, пользователь может извлечь данные на самом низком уровне детализации для определенного значения меры. Например, при получении данных о продажах в течение определенного месяца и категории продуктов можно детализировать эти данные, чтобы просмотреть список каждой строки таблицы, содержащейся в этой ячейке данных.

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

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

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

Пример показателя 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 использует следующие два варианта при сборке и проектировании агрегатов в кубах OLAP Service Manager:

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

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

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

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

Все группы мер в кубе поделены на разделы, каждый из которых определяет часть данных факта, загружаемую в группу мер. Службы SQL Server Analysis Services (SSAS) в SQL Server выпуск Standard позволяют выполнять только одну секцию для каждой группы мер, в то время как в выпуск 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. По умолчанию все группы мер и измерения содержат только один раздел. Поэтому секция не имеет условий границы.
• Границы раздела определяются с помощью привязки запроса, основанной на ключах дат, совпадающих с ключами дат соответствующего раздела факта в таблице 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 главными объектами считаются классы, которые представляют собой завершенный объект в виде завершенной сущности, не являющийся частью другого объекта. Например, основные объекты включают сервер, куб и измерение, которые являются всеми автономными сущностями. Однако DimensionAttribute не является основным объектом, так как он может быть создан только в рамках родительского основного объекта Dimension. DimensionAttribute, таким образом, является дополнительным объектом. Проектировочный этап куба OLAP сфокусирован на создании всех главных объектов, необходимых кубу, вместе с их зависимыми дополнительным объектами. Эти основные объекты — это объекты, которые будут сериализованы и в конечном итоге десериализированы перед созданием объектов в базе данных SSAS.

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

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

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

При развертывании куба интерактивной аналитической обработки (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 минут. Например, если измерение было обработано в 3:05 вечера и другой куб, предназначенный для того же измерения, обрабатывается в 3:45 вечера, измерение не будет повторно обработано. Недостатком данного подхода является повышение вероятности ошибок в ключах измерения. Механизм повторной попытки обрабатывает ошибки ключей измерения, чтобы выполнить повторную обработку измерения с последующей обработкой раздела куба. Дополнительные сведения о сбоях обработки см. в разделе "Распространенные проблемы с отладкой и устранением неполадок".

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

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

Обработка секций должна быть тщательно рассмотрена, так как повторная обработка большого раздела медленна, и она потребляет много ресурсов ЦП на сервере, на котором размещена служба SSAS. Как правило, обработка разделов занимает больше времени, чем обработка измерений. В отличие от обработки измерений, обработка разделов не имеет влияния на другие объекты. Единственными двумя типами обработки, выполняемыми в Кубах OLAP System Center — Service Manager, являются 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, так как секции будут находиться в непроцессованном состоянии. Это приведет к корректному обновлению всех водяных знаков и метаданных, что позволит устранить все возможные проблемы целостности данных.

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

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

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

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

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

Рекомендации по памяти

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

Следующие шаги

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