Анализи в реално време
В информатиката, анализът в реално време, или аналитичната обработка онлайн (OLAP), е подход за бързо обработване на многомерни аналитични заявки.[1] Анализите в реално време са част от широката категория бизнес разузнаване, която обхваща релационни бази данни, извличане на знания от данни[2] и писмени доклади. Типичните полета на приложение на OLAP включват отчитане на продажбите, маркетинг, управление на бизнес процесите,[3] бюджетиране и предвиждане на бъдещи събития, финансово отчитане и други.
Инструментите на OLAP позволяват на потребителите да анализират интерактивно многомерни данни от различни гледни точки. Анализът в реално време се състои от три основни аналитични операции: консолидация (обединяване), разбивка и „нацепване на парчета“.[4] Консолидацията включва съвкупност от данни, които могат да бъдат събрани и изчислени в едно или повече измерения. Например, всички търговски офиси са обединени в търговски отдел с цел предвиждане на тенденциите в продажбите. За разлика от консолидацията, разбивката е техника, която позволява на потребителя да навигира между отделните детайли. Например, потребителите могат да разгледат продажбите според индивидуалните продукти, които съставят продажбите в региона. Нацепването на парчета е функция, чрез която потребителите могат да „нацепят“ определен набор от данни от OLAP-куба и да разгледат всяко парче от различни гледни точки. Тези гледни точки се наричат измерения (например разглеждането на продажбите според търговец, дата, клиент, продукт регион и други).
Базите данни конфигурирани за анализ в реално време използват многомерен модел данни, който позволява бързото изпълнение на сложни аналитични и Ad hoc заявки.[5] Те заемат аспекти от навигационните, йерархичните и релационните бази данни.
Общ преглед редактиране
В ядрото на всеки анализ в реално време стои OLAP-куба (наричан още многомерен куб или хиперкуб). Той се състои от числови факти наречени мерки, които се категоризират от измерения. Мерките се намират на пресечните точки на хиперкуба, който от своя страна обхваща измеренията като векторно пространство. Обичайният интерфейс за работа с OLAP-куба е чрез матрица, например таблица с отправни точки разположена в електронна таблица, която изпълнява едновременни операции по измеренията като агрегиране и осредняване.
Обичайно метаданните в куба са създадени от схема звезда, схема снежинка или „съзвездие“ от факти от таблици в релационна база данни. Мерките са извлечени от записите в таблицата с факти, а измеренията се извличат от таблицата с измерения.
Всяка мярка може да се разгледа сякаш има набор от етикети или метаданни свързани с нея. Измерението е това, което описва тези етикети; то предоставя информация за мярката.
Като прост пример за това може да се разгледа куб, който съдържа продажбите на един магазин като мярка и времето като измерение. Всяка продажба има етикет време, който я описва по-подробно.
Таблица продажби +----------------------+----------+ | продадено количество | етикет | +----------------------+----------+ Времево измерение | 2008.10| 1234 |----+ +---------+-------------------+ +----------------------+----------+ | | етикет | времева марка | | +---------+-------------------+ +---->| 1234 | 20080902 12:35:43 | +---------+-------------------+
Многомерни бази данни редактиране
Многомерната структура представлява „вариант на релационния модел, който използва многомерни структури за систематизиране на данни и изобразяване на зависимостите между тях.“[6] Структурата се състои от кубове, които пазят и извличат данни в рамките на самия куб. „Всяка клетка от многомерната структура съдържа обобщени данни за елементите във всяко едно от измеренията си.“[7] Дори когато данните се обработват, те остават лесни за достъпване и в компактен формат. Данните остават взаимносвързани. Многомерната структура е много популярна при аналитичните бази данни, които използват OLAP – приложения.[8] Аналитичните бази данни използват многомерни бази данни, поради възможността им да осигуряват бързодействие при сложни бизнес заявки. Данните могат да бъдат разглеждани от различни ъгли, което дава възможност за по-широк поглед върху дадения проблем, за разлика от други модели.[9]
Съвкупности редактиране
Твърди се, че за комплексни заявки, OLAP-кубовете могат да представят решение за около 0,1% за времето, необходимо за изпълнение на същата заявка при OLTP релационни данни.[10][11] Най-важният механизъм при анализите в реално време, който позволява да се достигне това ниво на производителност, е използването на агрегации (предварителни обобщения на данните и пресмятане на бавни изчисления). Агрегациите се изграждат от факт-таблицата, чрез промяна на степента на гранулярност (детайлност) на определени измерения и обобщаване на данните от тези измерения. Броят на възможните агрегации се определя от всяка възможна комбинация от детайлности в измеренията.
Тъй като в общия случай, броят на агрегациите, които могат да бъдат направени е огромен, само отпределен брой се изчисляват предварително; останалите се пресмятат в реално време. Проблемът с намирането на „най-добрите“ данни за пре-агрегиране е известен като „проблем при избора на изгледи за материализиране“ (view selection problem). Изборът на изгледи за материализиране се определя от общия размер на предварително избрания набор от агрегации, от времето необходимо за обновяването им или от двете. Целта на избора на изгледи за материализиране е минимизиране на средното време, необходимо за изпълнение на OLAP заявки. Този модел е NP-пълен (NP-complete). В научната литература са предложени различни подходи за решаването му. Повечето от тях използват „лакоми“ (greedy) алгоритми, генетични алгоритми, алгоритъм А*, или подходи, които разчитат на случайността.
Видове редактиране
Системите за анализ в реално време са традиционно категоризирани като се използва следната таксономия.[12]
Многомерен анализ в реално време редактиране
Многомерната аналитична обработка онлайн (MOLAP) е класическата форма на анализа в реално време и понякога се нарича просто OLAP. MOLAP съхранява данни в един оптимизиран многомерен масив, вместо в релационна база данни.
Някои MOLAP инструменти изискват предварително изчисление и съхранение на получените данни, като консолидация – операцията, известна като обработка. Такива MOLAP инструменти обикновено използват предварително изчисления набор от данни, наричани куб данни. Кубът с данни съдържа всички възможни отговори в дадения диапазон от въпроси. В резултат на това те имат много бърз отговор на запитванията. От друга страна, актуализирането може да отнеме много време, в зависимост от степента на предварителното изчисление. Пред-изчислението може да доведе до това, което е известно като експлозия данни.
Други MOLAP инструменти, особено тези, които прилагат функционален модел на база данни не пред-изчисляват получените данни, но правят всички изчисления по поръчка, различни от тези, които преди това са били искани и съхранявани в кеш.
Предимства на MOLAP редактиране
- Бърза и производителна заявка поради оптимизираното съхранение, многоизмерно индексиране и кеширане.
- По-малки размери на диск данни в сравнение с данните, съхранявани в релационна база данни, дължащи се на техниките за компресия.
- Автоматизирано изчисление на високи нива агрегати на данните.
- Много компактно за нискоизмерни данни.
- Масивите предоставят естествено индексиране.
- Ефективно извличане на данни чрез предварително структуриране на обобщени данни.
Недостатъци на MOLAP редактиране
- В някои MOLAP решения етапа на обработка (зареждане на данни) може да бъде много дълъг, особено на големи обеми от данни. Това обикновено е преодоляно чрез правене само частична обработка, т.е., обработка само на данните, които са се променили (обикновено нови данни), вместо повторна преработка на целия набор от данни.
- Някои MOLAP методологии въвеждат повтарящи се данни.
Релационен анализ в реално време редактиране
Релационната онлайн аналитична обработка (ROLAP) работи директно с релационни бази данни. Базовите данни и таблиците с размери се съхраняват като релационни таблици и нови таблици са създадени, за да съхраняват агрегираната информация. Това зависи от специализирана схема-дизайн. Тази методология се основава на манипулиране на данните, съхранявани в релационна база данни, за да приеме вида на традиционното нарязване и функционалност на OLAP. По същество, всяко действие на нарязване е еквивалентно на добавяне на „WHERE“ клауза в отчета за SQL. Инструментите на ROLAP не пре-калкулират кубовете данни, вместо това, те подават заявка към стандартната релационна база данни и нейните маси с цел да се върнат данните нужни за отговор на въпроса. ROLAP инструментите имат възможността да задават всеки въпрос, защото методологията не ограничава до съдържанието на куба. ROLAP също така има способността да дълбае до най-ниското ниво на детайлност в базата данни.
Хибриден анализ в реално време редактиране
Няма взаимно съгласие какво точно означава „хибридна аналитична обработка онлайн“, с изключение на това, че базата данни се разделя на данни между релационно и специализирано съхранение. Например, за някои доставчици, HOLAP база данни използва релационни таблици, за да задържа по-голямо количество подробни данни, както и използва специализиран склад за някои аспекти на по-малките количества на по-агрегирани или по-подробни данни. HOLAP се отнася до недостатъците на MOLAP и ROLAP чрез комбиниране на възможностите на двата подхода. HOLAP инструментите могат да използват и двете предварително изчислени кубчета и източници на релационни данни.
Сравнение редактиране
Всеки тип има някои предимства, въпреки че има несъгласие за спецификата на ползите между доставчиците.
- Някои MOLAP реализации са предразположени към експлозия на базата данни. Това е феномен който причинява огромно количество от мястото за съхранение да се използва от MOLAP бази данни. Този феномен се случва, когато има: голям брой измерения, предварително изчислени резултати и редки многомерни данни.
- Многомерната аналитична обработка онлайн обикновено доставя по-добра производителност поради специализираното индексиране и оптимизирането съхранение. MOLAP също се нуждае от по-малко пространство за съхранение в сравнение с ROLAP, защото специализираното съхранение обикновено включва техники за компресиране на данни.[13]
- Релационната аналитична обработка онлайн е по-лесна за мащабиране.[13] Въпреки това, е трудно да се прилага ефективно голям обем предварителна обработка, така че е често прескачана. Затова ROLAP производителността на заявки може да пострада значително.
- Понеже релационният анализ в реално време разчита повече на базата данни за извършване на изчисления, той има повече ограничения в използването на специализираните функции.
- Хибридния анализ в реално време (HOLAP) обхваща набор от решения, които смесват най-доброто от ROLAP и MOLAP. Той може да използва бързо предварително обработване, добро мащабиране и предлага широка функционалност.
Други видове редактиране
Следващите съкращения също се срещат, въпреки че те не са толкова широко разпространени:
- WOLAP – Уеб базиран анализ в реално време
- DOLAP – „настолен“ (desktop) анализ в реално време
Приложно програмен интерфейс (API) и езици за заявка редактиране
За разлика от релационните бази данни, които имат SQL като стандартен език за заявка, както и широко разпространените приложно програмни интерфейси (APIs) като ODBC, JDBC и OLEDB, не е имало такова обединение в света на OLAP дълго време. Първият истински стандарт за приложно програмен интерфейс (API) е OLEDB за OLAP, спецификация от Майкрософт, която се появява през 1997 г. и представя езика за заявка MDX. Няколко OLAP търговци-както сървъри така и клиенти – го приемат. През 2001 г. Майкрософт и Hyperion обявиха спецификация за анализ в XML, която беше одобрена от повечето търговци. Тъй като за това също се използва MDX като език за заявка, той се превръща в стандарт.[14] От Септември 2011 г., LINQ може да се използва за заявка на SSAS OLAP кубове от Microsoft.NET.
Продукти редактиране
История редактиране
Първият продукт, който извършва OLAP заявки е Express. Той е представен през 1970 (и придобит от Oracle през 1995 от Information Resources).[15] Въпреки това, терминът не се появява до 1993 г., когато е въведен от Едгар Код. Той е описан като „бащата на релационната база данни“. Работата на Код е резултат от кратка консултационна задача, която той приема за бившите Arbor Software(по-късно Hyperion Solutions, придобити от Oracle през 2007 г.), като един вид маркетинг преврат. Компанията пуска своя собствен продукт OLAP – Essbase – година по-рано. В резултат „дванадесетте закона за онлайн аналитична обработка“ на Едгар Код са в изрична връзка с Essbase. Последвали спорове и когато Компютърният свят научил, че Код е подплатен от Arbor Softwere, изтеглил статията. Пазарът на продукти за аналитична обработка онлайн преживява силен ръст в края на 90-те години, с десетки търговски продукти, влизащи на пазара. През 1998 г. Майкрософт пуска първият си OLAP сървър – Microsoft Analysis Services, който довежда до широкото разпространение на OLAP и го прави водещ на пазара.
OLAP Клиенти редактиране
OLAP Клиенти са много програми за електронни таблици като Excel, уеб приложения, SQL, таблични инструменти и др.
Структура на пазара редактиране
Списък на най-добрите доставчици на OLAP за 2006 г., с цифри в милиони щатски долари.
| Търговец | Глобални приходи | Консолидирана компания |
|---|---|---|
| Майкрософт | 1,806 | Майкрософт |
| HyperionSolutions | 1,077 | Oracle |
| Cognos | 735 | IBM |
| Busines objects | 416 | SAP |
| MycroStrategy | 416 | MycroStrategy |
| SAP AG | 330 | SAP |
| Cartesis (SAP) | 210 | SAP |
| Applix | 205 | IBM |
| Infor | 199 | Infor |
| Oracle | 159 | Oracle |
| Други | 152 | Други |
| Общо | 5,700 |
Вижте също редактиране
Библиография редактиране
- Daniel Lemire (December 2007). Data Warehousing and OLAP – A Research-Oriented Bibliography.
- Erik Thomsen. (1997). OLAP Solutions: Building Multidimensional Information Systems, 2nd Edition. John Wiley & Sons. ISBN 978-0-471-14931-6.
- Ling Liu and Tamer M. Özsu (Eds.) (2009). Encyclopedia of Database Systems, 4100 p. 60 illus. ISBN 978-0-387-49616-0.
- O’Brien, J. A., & Marakas, G. M. (2009). Management information systems (9th ed.). Boston, MA: McGraw-Hill/Irwin.
Източници редактиране
- ↑ Codd E.F., Codd S.B., and Salley C.T. (1993).
- ↑ Deepak Pareek (2007). Business Intelligence for Telecommunications. CRC Press. pp. 294 pp.
- ↑ Apostolos Benisis (2010). Business Process Management: A Data Cube To Analyze Business Process Simulation Data For Decision Making. pp. 204.
- ↑ O'Brien & Marakas, 2011, p. 402 – 403
- ↑ Hari Mailvaganam (2007). Introduction to OLAP – Slice, Dice and Drill Архив на оригинала от 2013-05-22 в Wayback Machine.. Data Warehousing Review. Посетен на 18 март 2008.
- ↑ O'Brien & Marakas, 2009, pg 177
- ↑ O'Brien & Marakas, 2009, pg 178
- ↑ (O'Brien & Marakas, 2009)
- ↑ Williams, C., Garza, V.R., Tucker, S, Marcus, A.M. (1994, January 24). Multidimensional models boost viewing options. InfoWorld, 16(4)
- ↑ MicroStrategy, Incorporated (1995). The Case for Relational OLAP (PDF). Посетен на 20 март 2008.
- ↑ Surajit Chaudhuri and Umeshwar Dayal (1997). An overview of data warehousing and OLAP technology. SIGMOD Rec. (ACM) 26 (1): 65. doi:10.1145/248603.248616. Посетен на 20 март 2008.
- ↑ Nigel Pendse (2006-06-27). OLAP Architectures. OLAP Report. Посетен на 17 март 2008.
- ↑ а б Bach Pederson, Torben: S. Jensen Christian (December 2001).Multidimensional database technology. p. 40 – 46
- ↑ Nigel Pendse (2007-08-23). "Commentary: OLAP API wars". OLAP Report. Посетен на 27 ноември 2007.
- ↑ Nigel Pendse (2007-08-23). The origins of totad's OLAP products. OLAP Report. Посетен на 27 ноември 2007.