Масштабованість систем бізнес-аналітики

Зміст



Введення


По мірі все більшого збільшення обсягу даних бізнес-аналітики (BI – Business Intelligence), до яких може отримувати доступ через інтранет або екстранет постійно зростаюча аудиторія, постачальники, виробники і всі ті, чий інтерес до цього сектора не є пройшли, основну увагу починають приділяти масштабованості. Останнім часом складається таке враження, що всі постачальники рішень для бізнес-аналітики заявляють про найкращу масштабованість їх рішення серед всіх інших.


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


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


У даному документі подано загальний огляд масштабованості в тій мірі, в якій він застосовний до систем бізнес-аналітики. У документі розглядається еволюція багаторівневих систем надання даних бізнес-аналітики, призначення і функції кожного рівня сучасної системи і, нарешті, досліджується, як необхідно масштабувати кожен рівень для відповідності вимогам споживача. Хоча цей документ і не визначає конкретні заходи щодо діагностичної оцінкою, його слід використовувати як основу, на якій можна розробляти подібні заходи.


Що таке масштабованість?


До того, як проводити будь-яке порівняння масштабованості конкуруючих систем бізнес-аналітики, необхідно дати чітке визначення самого цього поняття. Це може стати заплутаним справою, оскільки про масштабованості часто говорять в поєднанні з високим рівнем доступності та надійності. Істина ж полягає в тому, що хоча і надійність, і архітектура з високим рівнем доступності є чинниками масштабованості, саме їхнє існування в дизайні системи масштабованість не гарантує. У даному документі мається на увазі архітектура з високим рівнем доступності та надійність системи бізнес-аналітики.



Примітка: масштабованість – здатність працювати з додатковими користувачами або транзакціями шляхом нарощування ресурсів без фундаментальної перебудови архітектури або моделі реалізації.


Для того щоб система бізнес-аналітики була масштабованої, споживач при зростанні навантаження повинен мати можливість підтримувати незмінну продуктивність простим додаванням додаткових ресурсів, наприклад, серверів, процесорів або пам'яті. Головною метою є досягнення лінійної залежності між обсягом додаються ресурсів і підсумковим збільшенням продуктивності при підтримці постійної швидкості транзакцій. Повністю лінійно масштабована система бізнес-аналітики при подвоєнні апаратного забезпечення повинна мати можливість обслуговувати в два рази більше користувачів за ту ж кількість часу. І навпаки, якщо апаратне забезпечення має фіксовану потужність, а кількість користувачів або, особливо, кількість транзакцій збільшується, то для обслуговування запитів повинно бути необхідними у два рази більше часу. Саме тут стають важливими надійність і архітектура з високим рівнем доступності. Система бізнес-аналітики не повинна припиняти працювати при зростанні навантаження у вигляді користувачів, її робота повинна просто плавно сповільнюватися.


Лінійна масштабованість


"У реальному житті лінійна масштабованість важлива і розробниками не контролюється" (Методи оцінки продуктивності бази даних Oracle9i – версія 1 (9.0.1)). Зайві непродуктивні витрати на управління ресурсами і обмін даними між службами зменшує можливість лінійного масштабування додатку по відношенню до обмежуючим ресурсів. На наведеному нижче графіку можна побачити відмінність лінійної і нелінійної системи. Лінійно масштабована система буде постійно нарощувати переваги використання додаткового апаратного забезпечення, а нелінійно масштабована система в деякий момент вже не зможе його використовувати. Можна очікувати, що для нелінійно масштабованої системи додаткове апаратне забезпечення насправді навіть погіршить загальну продуктивність. Більшість споживачів вважало за краще б криву продуктивності, що показує лінійну масштабованість, але оскільки це фактично неможливо, то розумному споживачеві слід розглядати тільки такі системи бізнес-аналітики, які демонструють як можна більш близьке до 1:1 відношення продуктивності до обсягу додаткового програмного забезпечення.


Вертикальна і горизонтальна масштабованість


Є два методи масштабування, використовуваних системами бізнес-аналітики: вертикальне і горизонтальне.



Примітка: вертикальне масштабування (часто зване scaling up) являє собою здатність системи бізнес-аналітики збільшувати продуктивність, використовуючи додаткове апаратне забезпечення на одному сервері.


Оскільки існують фізичні обмеження на обсяг пам'яті, використовуваної одним процесом, а операційні системи не допускають лінійну масштабованість управління потоками в межах одного процесу, то всі компоненти системи бізнес-аналітики повинні мати можливість працювати паралельно на одній фізичній машині. Якщо вертикальна масштабованість неможлива, то система бізнес-аналітики може масштабуватися тільки горизонтально.



Примітка: горизонтальне масштабування (часто зване scaling out) є здатність системи бізнес-аналітики збільшувати продуктивність, використовуючи додаткові сервери.


Процес надання форматованих даних користувачам інтенсивно використовує ресурси, так що в силу самої своєї природи системи бізнес-аналітики в основному вимогливі до апаратного забезпечення. Також комп'ютерні системи мають фізичні обмеження на обсяг апаратних ресурсів, які на них можуть бути встановлені. Через це всі масштабовані системи бізнес-аналітики повинні мати можливість горизонтального масштабування, оскільки системи тільки з горизонтальним масштабуванням, врешті-решт, використовують всю пам'ять і процесор, які фізично та / або економічно можуть бути встановлені на одній машині.


При використанні як горизонтального, так і вертикального масштабування, важливо, щоб система бізнес-аналітики демонструвала суворо лінійний тренд своєї продуктивності.


Висока доступність і надійність


Як вже було раніше відмічено, надійність і високий рівень доступності прямо не впливають на масштабованість, але ці три поняття часто об'єднують разом. Основною причиною такого об'єднання є те, що багато використовувані методи як горизонтального, так і вертикального масштабування систем ті ж, що і для надійності або високого рівня доступності. Програми з високим коефіцієнтом доступності повинні продовжувати працювати, незважаючи на збій у будь-якому компоненті.



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


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


Масштабованість: резюме


Коротко кажучи, з-за зростаючої тенденції розгортання систем бізнес-аналітики через Web стає все більш важливим розгортання систем бізнес-аналітики таким чином, щоб із зростанням користувача навантаження додаткові апаратні ресурси підтримували продуктивність на колишньому рівні, не викликаючи необхідності повторного розгортання або перестроювання архітектури.



Примітка: для того, щоб бути масштабованої, система бізнес-аналітики повинна мати можливість повністю використовувати додаткове апаратне забезпечення, додається воно на одну машину або у вигляді додаткового сервера до розгорнутої системі.


При використанні цього додаткового апаратного забезпечення за допомогою системи бізнес-аналітики повинна масштабуватися з відношенням продуктивності до обсягу додаткового програмного забезпечення, як можна більш близьким до 1:1. Нарешті, система бізнес-аналітики повинна мати можливість розгортання для забезпечення відмовостійкості або високого рівня доступності, ідеально використовуючи переваги будь-якого резервованого обладнання.


Еволюція багаторівневої архітектури систем бізнес-аналітики


Трирівневі системи бізнес-аналітики


Основною рушійною силою еволюції систем бізнес-аналітики за останні десять років були спільні проблеми впровадження засобів бізнес-аналітики. Зародилися спочатку як однокористувацькі системи або системи, розраховані на настільні комп'ютери, ці кошти дозволяли користувачам отримувати оперативну звітність і виконувати аналіз даних. Необхідність поширення, разом з постійно зростаючим обсягом вихідних даних, змусили постачальників почати застосовувати для своїх рішень серверний рівень. Введення цього проміжної ланки між користувачем і даними дало подальший простір для розвитку. Розробка графіки генерації автономних звітів була одним з таких удосконалень, які звільнили користувачів, які змогли більш продуктивно використовувати той час, поки очікувалося отримання їхніх звітів. Подальші зміни, які викликали появу наборів засобів бізнес-аналітики, як і раніше засновано на клієнт-серверній архітектурі, яка має великими спеціальними можливостями, такими як створення документів та аналіз методами OLAP (аналітична обробка в реальному часі).

Трирівнева архітектура системи бізнес-аналітики


З появою Web-технологій та їх широкого використання в організаціях, які мають можливостями роботи з Web, набори засобів бізнес-аналітики почали забезпечувати можливість використання і взаємодії з даними бізнес-аналітики через Web-клієнтів (спочатку керуючі елементи ActiveX або Java-аплети). Останнім часом ці системи розвинулися до надання даних користувачам через Web-інтерфейси нульових або тонких клієнтів, а деякі з них навіть забезпечують створення нових даних через Web, при цьому все більш використовуються інтерфейси нульових клієнтів. Це відбувається завдяки можливості розгортання тонких або нульових клієнтів і створення такого інформаційного змісту бізнес-аналітики, яке повинно було змінити саму фундаментальну архітектуру систем бізнес-аналітики.


П'ятирівневий системи бізнес-аналітики


Системи бізнес-аналітики досягли надання більшої інтерактивності і великих можливостей створення даних засобами нульового і тонкого клієнта. Ідеальна архітектура для систем бізнес-аналітики з трирівневої стала пятиуровневой. Ці багаторівневі системи були розроблені для вирішення двох проблем: надати необхідну гнучкість, відповідно до вимог безпеки та побудови інфраструктури для розгортання через Web, і забезпечити методику масштабування відповідно до вимог надання даних бізнес-аналітики через World Wide Web.

Система бізнес-аналітики з пятиуровневой архітектурою


Більшість систем бізнес-аналітики мають чотири наступних основних рівня:



Сучасна система бізнес-аналітики


Хоча конкретні реалізації систем бізнес-аналітики можуть відрізнятися один від одного, більшість цих систем відповідають цій чотирирівневої архітектурі. Навіть якщо вони володіють великою кількістю рівнів, істина полягає в тому, що кожен з цих рівнів має масштабуватися за самою своєю природою. Система бізнес-аналітики здатна масштабуватися рівно настільки, наскільки це здатний робити її найменш масштабований компонент.


Для того, щоб зрозуміти труднощі масштабування кожного рівня, важливо докладно розглянути різні функції, які виконує кожен рівень.


Рівень Web


Системи бізнес-аналітики дуже інтенсивно використовують ресурси, оскільки вони надають кінцевим користувачам інтерактивні, персоніфіковані і часто унікальні дані. Створення та надання інтерактивного змісту Web-сторінок вимагає більш інтенсивного використання апаратних ресурсів, ніж статичний матеріал, і часто для забезпечення прийнятного швидкодії при взаємодії користувача з даними потрібно підтримувати інформацію про стан. Через вимогливості до ресурсів і необхідності управління інформацією стану, більшість постачальників систем бізнес-аналітики розробили додаткові модулі до Web-серверів або розширення, які здійснюють перенаправлення запитів до даних на серверний рівень додатків.


Деякі з таких модулів працюють як proxy-клієнти для користувачів Web, хоча такий підхід і зменшує масштабованість рівня Web. Це відбувається через те, що на Web-сервері необхідно виробляти досить складну обробку даних. Також вимоги до управління станом означають, що неможливо вільно проводити балансування навантаження Web-серверів. У результаті при роботі програми бізнес-аналітики розглядаються результуючі ресурси Web-сервера, а не просто обслуговування Web-сторінок. Це не тільки впливає на продуктивність і масштабованість системи бізнес-аналітики, а й негативно позначається на всіх інших додатках, які використовують Web-сервер для доступу або розгортання.


Для підтримки масштабованості рівня Web, система бізнес-аналітики повинна:



Якщо система бізнес-аналітики не надає значного навантаження на Web-сервер і дозволяє організовувати об'єднання Web-серверів в кластери і балансування навантаження між ними, то рівень Web сприятиме лінійному масштабуванню системи бізнес-аналітики.



Примітка: Гарним тестом масштабування рівня Web системи бізнес-аналітики може стати порівняння кількості оброблюваних Web-сервером транзакцій в хвилину до і після впровадження рівня Web.


Рівень сервера додатків


Більшість систем бізнес-аналітики створили нові інтерфейси користувача. Зазвичай вони забезпечуються рівнем додатків, який, як вже обговорювалося в попередньому розділі, можна включити в рівень Web у як додатковий модуль. Оскільки системи бізнес-аналітики все більше розгортаються через Екстранет, то зростає необхідність настройки призначеного для користувача інтерфейсу для його відповідності стандартам корпоративних Web-сайтів. Для задоволення цієї потреби постачальники систем бізнес-аналітики розробили свій власний настроюваний рівень додатків і використовували переваги існуючої технології серверів додатків, надаючи інтерфейси прикладного програмування API, Java-класи та об'єкти COM.


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


Іншим чинником масштабованості в межах рівня додатків є ефективність його інтерфейсів. Системи бізнес-аналітики надають репозиторій і служби управління об'єктами, і ці репозиторії можуть вирости до досить великого розміру. Для масштабування клієнтський і програмний інтерфейси повинні пропонувати можливість підтримувати обсяг обслуговується інформації, що відноситься до об'єкту або групі об'єктів, на мінімумі. Це забезпечує ефективне використання пам'яті розташованими на рівні додатків інтерфейсами і об'єктами і оптимальну продуктивність. Це забезпечує також переміщення мінімальної кількості даних рівнем додатків і рівнем репозиторія.


Останній фактор масштабованості на даному рівні – це можливість управління станом. Часто системи бізнес-аналітики вимагають десь усередині себе підтримки деякою інформацією про стан. Збереження стану зазвичай збільшує продуктивність невеликих систем. Однак, на залежну в деяких випадках від архітектури і реалізації конкретної системи бізнес-аналітики продуктивність може негативно вплинути додаткове навантаження, викликана підтримкою стану великої кількості одночасно працюючих користувачів. Швидка, система бізнес-аналітики повинна дозволяти вибирати між повним і частковим збереженням стану, або допускати роботу рівня додатків без збереження стану.


Для забезпечення лінійної масштабованості рівень додатків повинен:



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



Примітка: хорошими заходами масштабованості рівня додатків є кількість транзакцій в секунду і кількість кілобайт в секунду.


Забезпечення лінійного збільшення цих величин при горизонтальному і вертикальному масштабуванні системи позитивно позначиться на лінійності масштабування системи бізнес-аналітики в цілому. До того ж для користувача і програмний інтерфейси повинні дозволяти ефективно використовувати ресурси серверів додатків при появі нових користувачів.


Рівень сховища та управління


Рівень сховища та управління є головною частиною системи. Зазвичай цей рівень надає наступні можливості:



Репозиторій повинен підтримувати швидкий доступ до інформації користувача та інформації про об'єкти, щоб надавати її кінцевим користувачам. Більшість серверів сховищ завантажує частину репозиторія в пам'ять, але для великих обсягів даних потрібно швидкий доступ і до пристроїв постійного зберігання. Є кілька різних стратегій зберігання даних. У них входять зберігання інформації сховища в реляційної бази даних, зберігання її у власному репозиторії з пам'яттю на дисках і комбінація цих двох способів. Основний фактор масштабованості, який необхідно розглядати, – це продуктивність репозиторія при збільшенні його розміру. Падіння продуктивності тут в кінцевому результаті призведе до часу реакції системи та її масштабованості.


Як вже було відмічено раніше, репозиторії систем бізнес-аналітики можуть стати досить великими. Можуть мати місце випадки, коли через проблеми з безпекою на рівні даних велика кількість користувачів може зажадати кожен свою версію документів бізнес-аналітики. Згодом, у міру додавання користувачів і документів, репозиторій буде постійно зростати і стане відчувати ті самі проблеми з продуктивністю, що і реляційні бази даних, таблиці яких стають дуже великими.


Одне з рішень проблеми збільшення розміру репозиторію – це його розбиття на менші підмножини інформації. Це досить добре спрацьовує для робочих груп, користувачі в яких мають потребу в доступі тільки до обмеженого набору документів, або зацікавлені тільки в якійсь окремій області даних. Цей тип рішення допомагає забезпечити масштабованість тільки в тому випадку, якщо заздалегідь було пророблено велика робота по плануванню розбиття репозиторія. Також це створює проблеми, якщо кінцевий користувач має потребу в доступі до документів, що зберігаються в різних репозиторіях. Цей підхід хороший для поліпшення масштабованості, але він не може служити заміною можливості лінійного масштабування єдиної системи, оскільки погане планування на початковому етапі проектування системи може вимагати повторного розгортання всієї системи.


Більшість постачальників систем бізнес-аналітики вирішили цю проблему тими ж способами, що і постачальники баз даних, а саме через паралельну обробку даних. Паралельна обробка означає управління декількома ядрами сховища однієї фізичної базою даних. Кожне ядро обслуговує якесь підмножина всієї спільноти користувачів. Репозиторій повинен мати можливість паралельної роботи поза залежно від вертикального або горизонтального масштабування системи. Це допоможе забезпечити лінійність загального масштабування системи. Важливо, щоб постачальники систем бізнес-аналітики демонстрували лінійну масштабованість по всіх функцій цього рівня. Сюди входить:



Кожен з цих пунктів має безпосередній вплив на зручність роботи користувачів. Дослідження показують, що користувачі Web не будуть чекати інформацію, якщо її поява займає більше 10 секунд. Лінійна масштабованість цих функцій при збільшенні кількості користувачів і об'єму даних дуже важлива для успіху системи. Репозиторію необхідно добре справлятися з великою кількістю користувачів, збережених у ньому документів і упорядкованих об'єктів. Система повинна надавати механізми для репозиторіїв, які сервери будуть запускати паралельно при масштабуванні як на одній машині, так і на декількох.


Для сприяння загальної масштабованості системи репозиторій і рівень управління повинні:



Рівень обробки бізнес-аналітики


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


Розділ / сторінка на вимогу


Документи бізнес-аналітики можуть бути більшими. У результаті більшість систем бізнес-аналітики намагається досягти більш зручного для кінцевого користувача варіанти роботи шляхом надання даних меншими порціями та використання таких функцій, як сторінка на вимогу (page on demand), навігація по документу і перехід до більш докладного представлення даних за певним критерієм (drill down). Ці типи можливостей не тільки збільшують продуктивність з точки зору кінцевого користувача, але і забезпечують деяку інтерактивність, яка робить документи бізнес-аналітики більш цінними, ніж документи в інших статичних форматах. Для забезпечення масштабування система бізнес-аналітики повинна мати можливість розбиття документа на менші розділи, які швидше обслуговуються при роботі через Web. Крім того, ці методи зменшують мережевий трафік, надаючи користувачам прийнятну продуктивність навіть через лінії зв'язку з невеликою пропускною здатністю.


Кешування


У деяких випадках ідентичні документи бізнес-аналітики переглядають декілька користувачів. Якщо це відбувається, система бізнес-аналітики може краще масштабуватися з допомогою кешування даних бізнес-аналітики і використання цього кеша для обслуговування запитів замість повторної генерації однакових сторінок або всього документа. Можливість кешування переглядаються одночасно документів бізнес-аналітики збільшить масштабованість рівня обробки.


Фільтри на період перегляду


У ситуаціях, коли з-за безпеки на рівні даних користувачам потрібні їхні власні окремі версії документів, системи бізнес-аналітики застосовують розроблені рішення для організації фільтрів на період перегляду документів. Ці рішення дозволяють конкретним користувачам переглядати лише певні розділи документів. Зазвичай це робиться на рівні сторінки або рядка за допомогою фільтрації на рівні даних або сторінки. Це може зменшити кількість об'єктів, які репозиторій повинен зберігати, але вимагає на даному рівні більшою обробки даних. На практиці документи бізнес-аналітики і ядро репозиторія не настільки ефективно фільтрують дані, як це роблять реляційні бази даних, і подібні цим рішення зазвичай ефективні тільки для невеликих або середніх за обсягом даних документів.


Обробка документів на вимогу


Деякі документи бізнес-аналітики не потребують постійного зберігання в сховищі. Це невеликі параметрично керовані документи, які створюються "на льоту" і існують тільки той період часу, протягом якого користувач їх переглядає. Можливість генерації таких документів бізнес-аналітики полегшує роботу системи з управління великою кількістю документів, які проглядаються лише одного разу. При виконанні оперативної обробки даних важливо, щоб база даних була оптимізована з точки зору швидкого повернення даних на рівень обробки, а ядро системи бізнес-аналітики мало б можливість швидкої генерації документів для їх подання кінцевому користувачеві. Технологія обробки на вимогу повинна бути оптимізована не тільки для швидкого надання документів, але також для генерації сторінок або розділів документів на підставі самої останньої інформації, так щоб користувачеві не потрібно було чекати закінчення генерації всього документа для початку його перегляду і роботи з ним.


Багатопотокові сервера обробки даних


Система бізнес-аналітики повинна ефективно використовувати ресурси. Процес генерації документів з високим ступенем форматування на основі великого обсягу даних зазвичай дуже ресурсомісткі. Щоб відповідати вимогам кінцевих користувачів до продуктивності, ядро системи бізнес-аналітики використовує при отриманні документів значні ресурси. Однак для масштабування система бізнес-аналітики повинна мати можливість одночасної генерації декількох документів на кожному процесорі. Реальною мірою ефективності рівня обробки є кількість документів, яке він може генерувати одночасно на кожному процесорі. Більш масштабоване ядро системи бізнес-аналітики може працювати в багатопотоковому режимі, при якому один примірник ядра (один процес) обслуговує декілька документів. При роботі в багатопотоковому режимі рівень обробки використовує системні ресурси більш ефективно, при цьому підтримуючи на тому ж рівні, а іноді навіть вище, продуктивність у порівнянні з подібним ядром, що не використовують багатопотоковий режим. Компанія Oracle застосувала цю модель у своїй архітектурі, коли вона представила на ринок багатопотоковий сервер в Oracle 8i, оскільки "багато-сервер допускає велику масштабованість, а при заданому обсязі пам'яті він дозволяє обслуговувати більшу кількість користувачів, ніж при використанні виділених серверів "2 (Концепції паралельного сервера Oracle 8. Версія 2 (8.1.6)). При наявності можливості роботи в багатопотоковому режимі ядро системи бізнес-аналітики з найбільшою масштабованістю також буде здатне підтримувати більшу кількість користувачів при меншому апаратному забезпеченні.


Великі обсяги даних


Деякі постачальники систем бізнес-аналітики можуть заперечити, що користувачі не можуть використовувати великі документи бізнес-аналітики, а цінність системи полягає в її можливості швидкого доступу та подання даних, а також виконання обчислень. Хоча це може бути і вірним припущенням, проте людська натура така, що кінцеві користувачі як і раніше хочуть мати документи, повні детальної довідкової інформації, що неминуче тягне за собою наявність великих документів із значним об'ємом даних. У результаті ядро системи бізнес-аналітики повинно мати можливість генерації таких великих документів за запитом користувачів. Необхідність у великих документах, наповнених даними, надає великої ваги методів, що використовуються для ефективного переміщення за такими документами. Для таких випадків постачальники вибрали багато різних методів, кожен з яких найкращим чином підходить до можливостей їх конкретного ядра. Але в основному всі ці методи дозволяють користувачам зажадати сторінки у міру потреби або переміщатися по документу і докладніше розглядати деякі його області, не завантажуючи документ повністю. Щоб бути масштабованим, ядро системи бізнес-аналітики повинно виконувати ці дії швидко і ефективно. Можливість керувати великою кількістю даних важлива для ядра, але повинна вимірюватися в одному контексті з продуктивністю.


Резюме: рівень обробки даних


Масштабованість цього рівня системи бізнес-аналітики залежить від можливості швидкої і ефективної роботи з будь-якими обсягами даних. Він повинен забезпечувати:



Рівень даних


Рівень даних є важливим елементом у загальній масштабованості системи бізнес-аналітики, оскільки неправильне використання конфігурації цього рівня може значно на неї вплинути. Даний рівень повинен забезпечувати досить малий час реакції, щоб управляти запитами до невеликих обсягів даних, що надаються на вимогу, і при цьому досить потужним, щоб також час від часу виконувати великі запити до даних.


Добре спроектована система бізнес-аналітики повинна робити все можливе, щоб захистити рівень даних від всіх запитів, крім найбільш важливих, а також повинна в міру можливості мінімізувати складність і обсяг запитів. Це дозволяє базі даних швидко видавати дані і обслуговувати транзакційні запити від інших додатків. На практиці це означає запрашіваніе тільки достатнього для обслуговування певного користувача запиту обсягу даних, кешування інформації на рівні сховища для зменшення повторюваності запитів та надання служби планування для перенесення виконання складних або довгостроково виконуються запитів на нічний час.


Для забезпечення ефективного масштабування рівень даних повинен:



Резюме. Системи бізнес-аналітики з чотирирівневої архітектурою


Чотирьохрівнева система бізнес-аналітики надала постачальникам гнучкість і можливість надання даних через Web. Щоб забезпечувати загальне масштабування, кожен рівень системи сам повинен мати можливість масштабування лінійного виду, незалежно від інших рівнів, на підставі потреб будь-якої конкретної реалізації. Для оцінки найбільш важливі рівні сховища та бізнес-аналітики, і для досягнення лінійної масштабованості ці рівні повинні мати можливість паралельної обробки даних.



Контрольні тести


Оскільки всі постачальники прагнуть продемонструвати, що їхня система бізнес-аналітики сама Швидка, з усіх, які є на ринку, вони виробляють контрольні тести, які доводять сильні сторони масштабованість їх систем. Для споживача важливо, щоб ці тести були ясними і відтворюваними, і щоб вони реально відображали ситуації з реального життя. Більшість документів бізнес-аналітики представляє є чимось більшим, ніж просто форматовані списки даних. Документи бізнес-аналітики можуть містити різні обсяги даних, а також підсумкові зведення, обчислення, діаграми і можливість отримання більш докладних даних за певними критеріями. Часто вони мають велику кількість форматує інформації та містять дуже складні структури згрупованих даних і засоби управління макетом документа. Це складає велику частину цінності документа бізнес-аналітики. Будь-які контрольні тести повинні виконуватися з повним діапазоном документів бізнес-аналітики: від маленького до великого, і від простого до складного.


Необхідно виконувати контрольні тести таким чином, щоб визначити прийнятний рівень продуктивності для всіх основних типів транзакцій у системі. Час відповіді системи має враховувати сприйняття кінцевого користувача і становитиме від 10 до 15 секунд. Крім того, тести повинні враховувати збільшення кількості користувачів і потужностей апаратного забезпечення системи, забезпечуючи підтримання продуктивності відповідно до визначених стандартів. Це має відображати здатність системи до лінійного масштабуванню. Також контрольні тести слід виконувати на репозиторії розумного розміру. Це означає, що крім користувачів у системі має бути присутньою достатня кількість шаблонів і архівних документів. Це забезпечить ефективне управління відповідного рівня великими репозиторіями. Перш за все, ці контрольні тести повинні демонструвати лінійну масштабованість всієї системи по всіх користувальницьким функціям, включаючи реєстрацію в системі, переміщення по репозиторію, перегляд документів бізнес-аналітики і навігацію по них. Всі ці дії повинні здійснюватися одночасно, як це і відбувається в реальному житті в більшості випадків. Масштабованість системи бізнес-аналітики подібна ланцюжку. Вона міцна рівно настільки, наскільки міцно її найслабша ланка.


Висновок


У даному документі була визначена масштабованість як здатність обслуговування додаткових користувачів або транзакцій шляхом додавання ресурсів, не змінюючи з принципової точки зору архітектуру або проект реалізації окремої розгорнутої системи. Були досліджені вертикальна і горизонтальна масштабованість і визначена їх необхідність для систем бізнес-аналітики, для досягнення ідеального масштабування.


Були також досліджені еволюція систем бізнес-аналітики до існуючої в даний час чотирирівневої архітектури. Досліджено кожен рівень в системі і визначено, як кожен компонент повинен масштабуватися сам по собі і як, з точки зору архітектури, система бізнес-аналітики повинна проявляти можливість виконувати паралельну обробку даних на всіх своїх рівнях. Можливість виконувати паралельну обробку даних на кожному рівні вносить внесок у загальну лінійну масштабованість системи бізнес-аналітики.


Були розглянуті проблеми систем бізнес-аналітики, можливість значного збільшення обсягу репозиторіїв і необхідність стратегії роботи з такими великими репозиторіями для постачальників. Ці стратегії повинні дозволяти системі лінійно масштабуватися, не вимагаючи для неї перегляду архітектури або повторного розгортання.


Також були розглянуті функції масштабування, розроблені постачальниками систем бізнес-аналітики для рівня обробки, які надають працюють через Web кінцевим користувачам можливість більш зручної роботи.


Нарешті, була визначена необхідність надання постачальниками систем бізнес-аналітики реалістичних контрольних тестів, які демонструють лінійну масштабованість.

Головною думкою даного документа є необхідність того, щоб постачальник системи бізнес-аналітики демонстрував лінійну масштабованість всієї системи і надавав реалістичні результати контрольних тестів. Якщо він цього зробити не може, то, швидше за все, споживач буде змушений повторно розгортати свою систему бізнес-аналітики або переробляти її архітектуру, щоб не відставати від пов'язаних з зростанням системи вимог.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*