Властивості показників

Залежно від того, який показник ви вибрали, доступний певний перелік доступних властивостей.

Агрегація

Для показника значення

Для показника формули

Для показників формул агрегація змінює метод розрахунку формули для зведеного результату у звіті.

Наприклад, є показник-формула, який вважається як
С = АxВ:

якщо агрегація включена, то зведений підсумок показника З вважається як ∑Сi , де i – рядки звіту.
Це означає, що спочатку система вважатиме значення рядка, а потім – суму всіх значень. Тому такий варіант обчислення не підходить для подальших операцій з показниками-лічильниками (індикаторами) – замість їх кількості буде підставлятися константа 1.

якщо агрегацію вимкнено, то зведений підсумок для показника С вважається як ∑Аi x ∑Вi , де i – рядки звіту.
Система спочатку порахує суму по всьому показнику, а тільки після виконання операцій між показниками. Це працюватиме лише для тих показників, які раніше вже були агреговані.

Прихований

Використовується для допоміжних показників для проміжних розрахунків. Якщо увімкнено, при побудові звіту цей показник за замовчуванням буде прихований.

Наслідувати на підпроекти

Наслідує значення показника на дочірні об'єкти дерева ієрархічної структури.

Приклад для довідника "Обчислення премії учасників проекту"

Реалізація:

Приклад для об'єкта – «Обчислення середньої вартості будівництва»

довідник Бюджет – заповнюється у задачі проекту, з розрахунку на 1 кв.метр площі об'єкта (реквізит проекту «Площа об'єкта»);

Використовувати проміжний розрахунок

Починаючи з версії системи 3.29 при активації якості «успадковувати на підпроекти», з'являється нове властивість «Використовувати проміжний розрахунок».

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

При активації властивість відображається в списку показників куба в колонці «Властивості».

Сума як останнє значення у групі

Дозволяє відображати підсумки за показником не як суму всіх значень, а як значення з останнього періоду часу, що відображається у звіті.

Дозволити NULL

Дозволяє у незаповнених значеннях показника OLAP-куба залишити порожнє значення – null. За замовчуванням (якщо опція не активована) порожні значення показника замінюються на 0.

Огляд кубів 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 вести журнал запитів даних, щоб при виконанні запиту відомості передавалися в процес розробки агрегатів.

Секціонування кубів Service Manager

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

Секціонування кубів виконується при кожному запуску завдання обслуговування сховища даних — за замовчуванням щогодини.Його виконання відбувається завжди після етапу 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) та створенні всіх його секцій він готовий до обробки, щоб він був доступний для перегляду.

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

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

Обробка куба OLAP складається із двох окремих завдань:

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

Обробка вимірів.

Кожне вимірювання, що додається в базу даних SSAS, має піддатися повній обробці, щоб отримати стан "оброблено".Однак після обробки виміру немає жодних гарантій, що він буде оброблений знову, коли інший куб, призначений для того ж виміру, обробляється. Не виконуючи автоматичної обробки вимірювання, service Manager не повторно оброблятиме кожен вимір для кожного куба. Це особливо вірно, якщо вимір нещодавно оброблений, тому що навряд чи існують нові дані, які ще не оброблені. Для оптимізації ефективності обробки існує одинтонний клас, визначений у пакеті керування Microsoft.SystemCenter.Datawarehouse.OLAP.Base, який називається Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. Зразок цього класу наведено нижче.

Цей 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 вимоглива до пам'яті.

Наступні кроки