Глава 10. Складове с данни (Data Warehouses)
Развитието на теорията, софтуера и използването на бази данни, а също и на технологиите за съхранение и осигуряване на достъп до големи масиви от данни, породи възможност за взимане на решения основани на анализ на данните в цялото им многообразие и пълнота. Това породи необходимост от развитие на инструменти, ориентирани към подпомагане на такива анализи. Тази и следващите три глави са посветени на такива инструменти, станали популярни през последните десетина години – Data Warehouses и Data Mining. Въпреки, че тези категории продукти са съвсем нови, терминолгията не е докрай изчистена и разнообразието в интерпретациите твърде голямо, тяхното значение за практиката на съвременното управление е безспорно. Тук ще разгледаме един от подходите за изграждане на тези продукти, а именно като качествено развитие на базите данни, които са в основата на изграждане на тези инструменти. До голяма степен спорно, но тук ще приемем твърдението че бази данни, data warehouses и data mining осигуряват аналитични инструмнети с различна, повишаваща се степен на сложност и могат да се разглеждат като етапи за достигане на зрялост на управлението на информацията в дадена социална система (виж фигура 10.1.).
Основната задача на базите данни е да осигурят събиране, съхраняване и достъп до големи масиви от данни. На практика, базите данни са основния инструмент на тъй наречените транзакционни информационни системи (Transaction Processing Systems – TPS), про които всяка транзакция осъществена в социалната система се регистрира (записва) в базата данни, като се осигурява проследимост на взаимн-свързаните аспекти при осъществяване на конкретната транзакция. Говорим за OLTP (on-line transaction processing) системи. За разлика от тях, при складовете с данни търсим обобщение (агрегиране), оценка на тенденции, характеризиране на процесите при различно ниво на агрегираност. Целта при тези системи е да се разберат по-цялостно процесите и явленията, както и да се оцени ролята и на най-дребните детайли, имащи реално отражение върху представянето на социалната система. Говорим за OLAP (on-line analytical processing) системи. Data Mining системите позволяват използване на по-сложни аналитични техники за откриване на неизвестни взаимовръзки, модели, асоциации, правила и други подобни “патерни” – откриване на нови знания, скрити в морето от фактологическа информация, натрупвана чрез OLTP системите. Ако при базите данни и OLTP системите акцента е върху актуалността на информацията, то при втората – актуалността не е най-важното условие, предвид инерциоността на социалните системи е важно да се проследи развитието на процесите и моментното състояние на социалната система не е толкова важно. На практика използването на тези приложения за управление на дадена социална система представлява еволюционен процес – първо трябва да се решат проблемите със събиране, съхраняване и достъп до фактологическата информация генерирана в системата (база данни и OLTP система), след това да се потърсят средствата за пълноценно използване на тази информация за решаване на средносрочните управленски проблеми, и чак след това да се търсят инструменти за изучаване процесите и явленията и откриване на ново знание. Социални системи, които не са решили удачно първата задача не разполагат с информационен ресурс за решаване на следващите проблеми.
Техниките, които се използват при структуриране е анализиране на данните в Data Warehouses и Data Mining имат значение за информационните брокери и извън обхвата на самите системи. Голямата част от тези техники са добре познати статистически и математически аналитични методи, чието познаване и използване е полезно и извън рамките на конкретните системи. Разбира се, вграждането на такива средства в информационните системи за управление на дадена социална система позволява оперативното им използване и ефекта е по-голям и пълноценен от прилагането им ad-hoc.
Тази глава е посветена на Data Warehouses. На български ще ги наричаме “складове с данни”, въпреки че този термин не е получил гражанственост и може би ще бъде заменен от по-подходящ в бъдеще.
Настоящата глава е структурирана по следния начин: в първия раздел е дадено определение на “склад с данни”и са описани и коментирани двата основни подхода за изграждане на такива системи. Вторият раздел разглежда и коментира структурата от данни, известна като многомерен куб от данна (data cube), като основна структура за използвана от програмните продукти за изграждане на складове с данни. Тук по-задълбочено сме се спряли на построяването на йерархия на концепциите, които играят важна роля в практиката на информационния брокер и самостоятелно, извън обхвата на складовете с данни. Третият раздел е посветен на обработката на данните с помощта на складовете с данни – подготовката на данните и зареждането им в склада с данни и OLAP функциите, характерни за “складовете с данни”.
10.1. Какво е “склад от данни”?
В литературата има множество опредления на Data Warehouses, макар и не съвсем точни и прецизни, тук ще цитираме две от тях, защто те показват важни, в съдържателно отношение, аспекти на тези приложения:
• Подпомагаща решенията база данни, която се поддържа отделно от операционната база данни на организацията;
• Поддържаща обработка на информацията чрез осигуряване на солидна платформа от консолидирани, исторически данни за анализиране.
Тук ние ще следваме дефиницията на W. H. Inmon [] “Складовете от данни са предметно-ориентирани, интегрирани, зависещи от времето (time-variant) и статични (non-volatile) колекции от данни за подпомагане процеса на вземане на управленски решения”.
Предметно-ориентирани. Организирани според основните субекти на социалната организация като клиенти, продукти, продажби и т.н.; фокусирани върху моделиране и анализ, а не върху ежедневните операции; осигуряващи прост и разумен поглед към даден въпрос чрез изключване на данните, които не са полезни за процеса на взимане на решения.
Интегрирани. Конструирани чрез интеграция на множество, хетерогенни източници на данни, като релационни бази данни, обикновени (плоски) файлове и др. Прилагат се техники за почистване и интегриране на данните за осигуряване на съответствие на имената, кодировките, дименсиите на атрибутите и така нататък (виж раздел 7.2.) от различните източници.
Зависима от времето. Осигурява анализ на данните в историческа перспектива, осигурявайки данни за последните 5, 10 години. Времевия хоризонт; в сравнение с този на операционните бази данни, които работят само с актуални, днешните данни; е значително по-голям. Всяка ключова структура, съдържа времето, зададено експлицитно или имплицитно.
Статични. Данните, съхранявани отделно, се трансформират и зареждат от оперативните бази данни, така че непрекъснатото обновяване на транзакционните бази данни, не е характерно за “складовете с данни”, което свежда броя на операциите над данните само до две: начално зареждане и достъп.
При конструиране на приложения изпълняващи ролята на “склад от данни” се използват два подхода:
• Над хетерогенните бази данни се изгражда покривала (wrappers) или посредници (mediators), които представляват софтуер, служещ за трансформация на клиентската заявка на заявки към различните бази данни и към другите източници, и интегриране на получените резултати. Тези продукти използват мета-каталог за трансформация на заявките и интегрирането на резултатите. Основно предимство на този подход е, че данните които се използват за формиране на резулта са актуални, от последната минута. Недостатците са породени от необходимостта, сложни, ресурсоемкио филтрирания и трансформации на данните да се осъществяват от компютърните системи, осигуряващи оперативната работа на организацията.
• При този подход, “склада с данни” се зарежда еднократно (например нощем, когато оперативните системи не работят с максимално натоварване и имат свободен ресурс за изпълнение на заявките за зареждане на “склада с данни”). Това осигурява висока производителност, защото значителната част от обработката, поискана в потребителската заявка е извършена предварително – при зареждане на “склада с данни”, като в същото време не натоварва транзакционните системи. Тук трябва да се реашават следните проблеми:
o Проблеми на проектирането – предварително определяне на обхвата на данните, които ще бъдат използвани при анализите;
o Проблеми на зареждането – тъй като предварително не се знае какви точно анализи ще бъдат необходими, при зареждането трябва да се филтрират, трансформират и интегрират всички данни, които потенциално биха били нужни на следващия ден на аналитиците;
o Необходим е допълнителен хардуер специално за “склада с данни”.
Независимо от цитираните проблеми, вторият подход за построяване на “складове с данни” се налага все повече – цената на хардуера вече е твърде ниска и продължава да пада; използването на системите в ненатовареното време за зареждане не създава проблеми за функционирането на оперативните системи; социалните организации, достигнали в своето развитие до необходимостта от ‘складове с данни”, имат достатъчен опит за да могат да определят от какви аналитични инструменти се нуждаят.
10.2. Многомерен модел на данните – куб от данни
За разлика от проблемите, решавани с помощта на транзакционните системи, при вземането на решения със средно и дългосрпчен времеви хоризонт трябва да се вземат под внимание и анализират данни показващи различните страни на функционирането на системата, при това тези данни трябва да се интегрират така, чеда показват системата като едно цяло и по правило имат агрегиран, обобщен характер. Т.е. нужно е единно представяне на многоаспектната информация за дейността на социалната организация – нужен е многомерен информационен модел, който е целево ориентиран към извършване на конкретен клас анализи. При това, този модел трябва да позволява удобно представяне в компютърните системи и да позволява лесно агрегиране по данните с различно ниво на обобщаване или детайлизация.
Кубовете от данни се наложиха като модел, който отговаря на тези изисквания. Преди да опишем характеристиките на този модел, трябва да изясним понятието “йерахия на концепциите”, което е ключово за построяване на куб данни за даден клас аналитични задачи.
10.2.1. Йерархия на концепциите
Нека разгледаме дейността на компания за продажба на електроника, оперираща на глобално – в Европа, Северна Америка и т.н. Разглеждаме характеристиката “място” на данните за представяне на компанията. За ръководството на комапнията са важни параметрити на представяне на компанията като цяло, по региони, за отделните региони – по страни, за отделните страни – по градове, за отделните градове – по офиси. Агрегирането (обобщаването, обединяването) на данните за отделните офиси в даден град, формира данните за града, агрегирането на данните за отделните градове в дадена държава – формира данните за държавата и т.н. (виж фиг. 10.2).
За характеристиката (концепцията) място трябва да се изгради йерархия – {всичко, регион, страна, град, офис}, която да отразява структурата на събираната информация от една страна, и аналитичните потребности от друга. За всеки вид анализ е необходимо данните да бъдат характеризирани чрез множество “концепции”. Например за анализ на динамиката на продажбите на горната фирма, трябва да се отчитат освен място, още продукт и време, но може да се включат и други (тук ще се ограничим до тримерен модел заради графичното илюстриране на куба данни). Йерархията по продукт може да бъде: всички, тип на продукта (персонални компютри, телевизори, аудио-визуални системи), категория продукт (17, 21, ..., 60 инчов телевизор), производител, марка. По време: за цялата година, по тримесечия, по месеци, по дни; или за цялата година, по седмици, по дни (тъй като седмицата може да бъде разделена от прехода между два месеца, а в същото време динамиката на продажбите е зависима от деня от седмицата – е възможно да се използват и двете йерархии). Така достигаме до модела покзан на фигура 10.3. Във всяка клетка на показания къб данни се съхраняват данните за продажбите на електроника за съответното ниво на агрегираност по трите дименсии. В клетката, посочена с {всички всички всички} се записват общите данни за продажбите в цялата компания, в слоя клетки показан в челото на куба – данните за продажбите по всички продукти по страни и по тримесечия, в долния хоризонтален ръб на този слой са данните за продажбите на всички продукти за всички страни по тримесечия, а в десния вертикален ръб – данни за продажбите на всички продукти, по страни, за целия период. Тук е показана, разбира се, само малка част от куба данни, който описахме, съответстваща само на първото ниво в трите йерархии.
Куб данни може удобно да се представи в релационен модел на база данни и за реализацията му да се използват елементи или цяла СУБД. Например в SQL Sever 2005 на Microsoft е реализирана функционалност съответстваща на Data Warehouses и подпомагаща Data Mining. Тук ще коментираме накратко само модела “звезда” (виж фиг. 10.4.) за представяне на куб данни като релационен модел. Този модел се състои от два типа таблица:
- Факт-таблица, съдържаща конкретните мерки за наблюдаваните обекти – параметрите, които са предмет на анализите. Това са числовите стойности на различните измерения на дейността. За случая на продажби, такива мерки могат да бъдат брой продажби (units_sold), приход от продажби (dollars_sold), средно продажби (avg_sales) и т. н. Тези три мерки се определят за всяка комбинация от нива по йерархията на концепциите, като връзката с тях става чрез външни ключове към таблиците – номенклатури;
- Таблици-номенклатури. За всяка от размерностите на многомерния модел на данните, представен в куба, се изгражда таблица, съдържащи данни за конкретна стойност на дадения поазател в йерархията.
Например, нека разгледаме йерархията ка времето {година, месец, ден}. За всеки ден от годината (365 на брой) ще пазим запис в номенклатурата, отделно за всеки месец от годината (12 на брой) ще пазим по един такъв запис и за годината като цяло – още един. Така тази номенклатура ще съдържа 365+12+1 = 378 записа.
Във факт-таблицата ще пазим записи на трите мерки, описващи продажбите (брой, сума, средно) за всяка комбинация от възможни стойности на номенклатурите за четирите размерностости.
Разбира се, зареждането на куба е свързано с изпълнение на огромно множество заявки към оперативните бази данни за извличане и агрегиране на информацията. За да преценим порядъка на обема на тази обработка, нека да продължим горния пример, така ще добием представа и за обема на информацията в куба. За целта нека упростим малко модела от фигура 10.3. като определим приблизително номенклатурата на продуктите на 5000 записа, номенклатурата на местата – 2000, клоновете – 200, като в тези числа влизат и записите за по-горните нива на четирите йерархии. Така факт-таблицата би трябвало да съдържа: 5000 (продукта) х 2000 (магазина) х 200 (клона) х 378 (времеви единици), което прави приблизително 756 000 000 000 записа. Зареждането на такъв склад с данни изисква изпълнението на 756 милярда заявки. Разбира се, тази обработка може да бъде оптимизирана и на практика е много по-ефективна, но независимо от това, огромен обем записи трябва да се генерират.
Допълнително, зареждането на “склада с данни” изисква почистване на данните от грешни записи, обработка на липсващи данни, анализ на силно отличаващи се стойност (outliers) и други опреации ориентирани към подобряване качеството на информацията. В следващия раздел ще разгледаме накратко операциите, които почти задължително участват в тъй наречената предварителна обработка.
10.3. Типична функционалност на “складовете с данни”
На фигура 10.5. е показана схема на четири степенна архитектура на “склад от данни”:
- Първата степен включва източниците на информация. Без изградена и добре работеща система за събиране, съхраняване и осигуряване на достъп до първичната информация, изграждането и функционирането на следващите елементи, ориентирани към структуриране на данните и анализирането им, са безсмислени.
- Втората степен може да се определи като предварителна обработка. На този етап трябва да се извършат следните основни дейности:
o извличане на информацията – като правило се използват данни от разннообразни източници. При това трябва да се решават следните проблеми: проблеми с имената (една същност може да бъде наречена с различни имена в различните бази данни), проблеми с размерностите (един и същ тип данни може да бъде представян в различни размерности – американския клон на компанията използва “миля”, българския – километър); проблеми с релевантността (изключването на детайлите, съдържащи се в оперативните бази данни, които не носят информация или не са полезни за откриване на общото състояние, тенденциите и т.н.) и дтуги подобни;
o трансформиране на данните – тук се включват по-сложни преобразувания насочени към премахване на грешните данни (откриване и премахване), обработка на липсващи данни, откриване и анализиране на силно отличаващите се стойности (outliers), привеждане към единна скала за измерване и т.н. Глава 11 коментира подробно този кръг проблеми;
o зареждане на данните в “куб данни” – при зареждането на данните, важна роля играе определянето на йерархията на концепциите, което като правило има субективен характер. Може да възникне ситуация, при която за различните анализатори се изграждат различни “складове данни” с една и съща информация. Гледната точка на потребителите трябва да бъде отразена;
o периодично обновяване.
- Третата степен включва начините за съхраняване на данните, които бяха разгледани в предишния раздел.
- В четвъртото ниво са групиране операциите, които от една страна са стандартизирани до степен универсалност, а от друга позволяват специфични анализи, ориентирани към конкретната ситуация. (на аналитичните техники, които не са стандартни в този смисъл, са посветени следващите три глави):
o Roll up (drill-up): сумира данните чрез преминаване в по-горно ниво на йерахията на концепциите или чрез съкращаване на размерността;Drill down (roll down): обратно на roll-up преминаване от по-високо към по-ниско ниво – или от по агрегирано представяне към по-детайлизирано представяне на данните;
o Slice and dice: проектиране и селектиране (извличане на отделна равнина от куба или на под-куб);
o Pivot (rotate): реорганизация и преориентиране на куба, визуализация – от 3D към серия от 2D планове;
This entry was posted
at 12:15
and is filed under
Компютърни системи и технологии
. You can follow any responses to this entry through the
.
