В предишната статия говорих за основите на DATA VAULT, описах основните му елементи и тяхното предназначение. Темата за DATA VAULT обаче не е изчерпана, необходимо е да се поговори за следващите етапи в еволюцията на DATA VAULT.
В тази статия ще се фокусирам върху развитието на DATA VAULT и прехода към BUSINESS DATA VAULT или просто BUSINESS VAULT.
Причините за появата на BUSINESS DATA VAULT
Необходимо е да се отбележи, че макар DATA VAULT да има определени силни страни, той не е без недостатъци. Един от тези недостатъци е сложността при написването на аналитични заявки. Заявките имат значително количество JOIN'ове, а кодът става дълъг и тромав. Също така, данните, постъпващи в DATA VAULT, не подлежат на никакви трансформации, затова от бизнес гледна точка DATA VAULT в чист вид не има безусловна стойност.
Точно за да се преодолеят тези недостатъци, методологията DATA VAULT беше разширена с елементи като:
- PIT (точка във времето) таблици;
- BRIDGE таблици;
- PREDEFINED DERIVATIONS.
Нека да разгледаме по-подробно предназначението на тези елементи.
PIT таблици
Обикновено един бизнес обект (HUB) може да има данни с различна честота на обновление. Например, ако говорим за данни, характеризиращи човек, можем да кажем, че информацията за телефонния номер, адрес или електронна поща има по-висока честота на обновление от например имената, данните за паспорта, семейното положение или пола.
Затова, когато определяме сателитите, трябва да имаме предвид честотата на обновлението им. Защо е важно това?
Ако в една таблица се съхраняват атрибути с различна честота на обновление, ще трябва да добавяме ред в таблицата при всяко обновление на най-често променяния атрибут. В резултат на това - растеж на обема на дисковото пространство, увеличаване на времето за изпълнение на заявките.
Сега, когато разделихме сателитите по честота на обновление и можем да зареждаме в тях данни независимо, трябва да осигурим възможност за получаване на актуални данни. По-добре, без излишни JOIN'ове.
Ще дам пример, когато е необходимо да се получи актуална (според датата на последното обновление) информация от сателити с различна честота на обновление. За целта е нужно не само да се извърши JOIN, но и да се създадат няколко вложени запитвания (при всеки сателит, съдържащ информация) с избиране на максималната дата на обновление MAX(Дата на обновление). С всеки нов JOIN този код нараства и бързо става сложен за разбиране.
Таблицата PIT е създадена, за да опрости такива запитвания. PIT таблиците се запълват едновременно с записването на нови данни в DATA VAULT. PIT таблица:
По този начин разполагаме с информация за актуалността на данните от всички сателити в всеки момент от времето. Използвайки JOIN-ове с PIT таблицата, можем напълно да изключим вложените запитвания, естествено с условие, че PIT се запълва всеки ден и без пропуски. Дори при наличието на пропуски в PIT, актуалните данни могат да бъдат получени само чрез едно вложено запитване към самия PIT. Едно вложено запитване работи по-бързо от вложени запитвания към всеки сателит.
BRIDGE
Таблиците тип BRIDGE се използват също така за опростяване на аналитични запитвания. Обаче, за разлика от PIT, те служат за опростяване и ускоряване на запитвания между различни хъбове, линкове и техните сателити.
Таблицата съдържа всички необходими ключове за всички сателити, които често се използват в запитвания. Освен това, при необходимост хешираните бизнес ключове могат да бъдат допълнени с ключове в текстов вид, ако имената на ключовете са нужни за анализ.
Фактът е, че без използването на BRIDGE, в процеса на получаване на данни намиращи се в сателити, принадлежащи на различни хъбове, ще е необходимо да се извърши JOIN не само на самите сателити, но и на линковете, свързващи хъбовете.
Наличието или отсъствието на BRIDGE се определя от конфигурацията на хранилището и необходимостта от оптимизация на скоростта на изпълнение на запитванията. Универсален пример за BRIDGE е трудно да се измисли.
PREDEFINED DERIVATIONS
Още един тип обекти, който ни приближава до BUSINESS DATA VAULT, са таблиците, съдържащи предварително изчислени показатели. Такива таблици са наистина важни за бизнеса, тъй като съдържат информация, агрегирана по зададени правила, и дават относително лесен достъп до нея.
Архитектурните PREDEFINED DERIVATIONS представляват нищо друго освен още един сателит на определен хъб. Той, подобно на обикновен сателит, съдържа бизнес ключ и дата на създаване на записа в сателита. Обаче, тук схожствата приключват. Допълнителният набор от атрибути на този "специализиран" сателит се определя от бизнес потребителите въз основа на най-търсените, предварително изчислени показатели.
Например, хъбът, съдържащ информация за служител, може да включва сателит с показатели като:
- Минимална заплата;
- Максимална заплата;
- Средна заплата;
- Накопителен итог на начислената заплата и т.н.
Логично е да се включат PREDEFINED DERIVATIONS в PIT таблицата на същия хъб, така че лесно да се получат срезове на данни за служителя на конкретна избрана дата.
ИЗВОДИ
Както показва практиката, използването на DATA VAULT от бизнес потребителите е малко затруднено по няколко причини:
- Кодът на заявките е сложен и обемен;
- Обилието от JOIN'ове влияе на производителността на заявките;
- За написването на аналитични заявки е необходимо отлично познаване на структурата на хранилището.
За да улесни достъпа до данни, DATA VAULT се разширява с допълнителни обекти:
- PIT (точка във времето) таблици;
- BRIDGE таблици;
- PREDEFINED DERIVATIONS.
В следващата Планирам да споделя, на моето мнение, най-интригуващото за тези, които работят с BI. Ще представя начини за създаване на таблици – факти и таблици – измерения на база DATA VAULT.
Материалите в статията се основават на:
- На Кента Грациано, в която освен подробното описание са включени и схеми на модела;
- Книгата: «Building a Scalable Data Warehouse with DATA VAULT 2.0»;
- Статия .
Източник: habr.com
