В предходната статия обсъдих основите на DATA VAULT, описах основните елементи на 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 е трудно да се измисли.
ПРЕДОПРЕДЕЛЕНИ ПРОИЗВЕДЕНИЯ
Още един тип обекти, който ни приближава до BUSINESS DATA VAULT, са таблиците, съдържащи предварително изчислени показатели. Такива таблици наистина са важни за бизнеса, те съдържат информация, агрегирана по зададени правила и позволяват достъп до нея сравнително просто.
Архитектурните ПРЕДОПРЕДЕЛЕНИЯ представляват нищо повече от още един сателит на определен хъб. Той, подобно на обикновения сателит, съдържа бизнес ключ и дата на създаване на записа в сателита. Въпреки това, с това прилики завършват. Допълнителният набор от атрибути на такъв "специализиран" сателит се определя от бизнес потребителите въз основа на най-търсените, предварително изчислени показатели.
Например, хъб, който съдържа информация за служител, може да включва сателит с такива показатели, като:
- Минимална заплата;
- Максимална заплата;
- Средна заплата;
- Натрупан итог на начислената заплата и т.н.
Логично е да се включат ПРЕДОПРЕДЕЛЕНИЯ в 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
