У папярэднім артыкуле я распавёў аб асновах 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 (point in time) табліцы;
- BRIDGE табліцы;
- PREDEFINED DERIVATIONS.
Давайце больш дэталёва разбяром прызначэнне гэтых элементаў.
PIT табліцы
Як правіла адзін бізнес аб'ект (HUB) можа мець у сваім складзе дадзеныя з рознай частатой абнаўлення, напрыклад, калі мы гаворым аб дадзеных якія характарызуюць чалавека, мы можам сказаць, што інфармацыя аб нумары тэлефона, адрасе або электроннай пошце мае больш высокую частату абнаўлення, чым скажам, Прозвішча, імя пашпарта, сямейнае становішча або падлогу.
Таму, пры вызначэнні сатэлітаў, варта мець на ўвазе частату іх абнаўлення. Чаму гэта важна?
Калі ў адной табліцы захоўваць атрыбуты з рознай частатой абнаўлення, давядзецца дадаваць радок у табліцу пры кожным абнаўленні самага часта змянянага атрыбуту. Як следства - рост аб'ёму дыскавай прасторы, павелічэнне часу выканання запытаў.
Цяпер, калі мы падзялілі сатэліты па частаце абнаўлення, і можам загружаць у іх дадзеныя незалежна, трэба забяспечыць магчымасць атрымання актуальных дадзеных. Лепш без выкарыстання залішніх JOIN'аў.
Растлумачу, напрыклад, патрабуецца атрымаць актуальную (па даце апошняга абнаўлення) інфармацыю з сатэлітаў якія маюць розную частату абнаўлення. Для гэтага запатрабуецца не толькі зрабіць JOIN, але і стварыць некалькі ўкладзеных запытаў (да кожнага сатэліту які змяшчае інфармацыю) з выбарам максімальнай даты абнаўлення MAX(Дата абнаўлення). З кожным новым JOIN'ам такі код разрастаецца, і вельмі хутка становіцца складаным для разумення.
PIT табліца заклікана спрасціць такія запыты, PIT табліцы запаўняюцца адначасова з запісам новых дадзеных у DATA VAULT. PIT табліца:
Такім чынам, у нас ёсць інфармацыя аб актуальнасці дадзеных па ўсіх сатэлітах на кожны момант часу. Выкарыстоўваючы JOIN'ы да PIT табліцы, мы можам поўнасцю выключыць укладзеныя запыты, натуральна з умова, што PIT запаўняецца кожны дзень і без пропускаў. Нават, калі пропускі ў PIT маюць месца, атрымаць актуальныя дадзеныя можна толькі выкарыстоўваючы адзін укладзены запыт да самога PIT'у. Адзін укладзены запыт адпрацуе хутчэй, чым укладзеныя запыты да кожнага сатэліту.
МОСТ
Табліцы BRIDGE таксама выкарыстоўваецца для спрашчэння аналітычных запытаў. Аднак адрозненнем ад PIT з'яўляецца сродкам спрашчэння і паскарэння запытаў паміж рознымі хабамі, лінкамі і іх сатэлітамі.
Табліца змяшчае ўсе неабходныя ключы для ўсіх сатэлітаў, якія часта выкарыстоўваюцца ў запытах. Акрамя таго, пры неабходнасці хэшаваныя бізнес ключы могуць дапаўняцца ключамі ў тэкставым выглядзе, калі найменні ключоў патрэбныя для аналізу.
Справа ў тым, што без выкарыстання BRIDGE, падчас атрыманні дадзеных змешчаных у сатэлітах прыналежным розным хабам, запатрабуецца вырабіць JOIN не толькі саміх сатэлітаў, але і лінкоў якія злучаюць хабы.
Наяўнасць ці адсутнасць BRIDGE вызначаецца канфігурацыяй сховішча, неабходнасцю аптымізацыі хуткасці выканання запытаў. Універсальнага прыклад BRIGE прыдумаць складана.
PREDEFINED DERIVATIONS
Яшчэ адным тыпам аб'ектаў, які набліжае нас да BUSINESS DATA VAULT з'яўляюцца табліцы якія змяшчаюць папярэдне разлічаныя паказчыкі. Такія табліцы сапраўды важныя для бізнэсу, яны ўтрымоўваюць інфармацыю, агрэгаваную па зададзеных правілах і дазваляюць атрымаць да яе доступ адносна проста.
Архітэктурна PREDEFINED DERIVATIONS уяўляюць з сябе, нішто іншае, як яшчэ адзін сатэліт вызначанага хаба. Ён, як і звычайны сатэліт утрымоўвае бізнэс ключ і дату фармавання запісу ў сатэліце. На гэтым, аднак, падабенствы заканчваюцца. Далейшы склад атрыбутаў такога "спецыялізаванага" сатэліта вызначаецца бізнес карыстальнікамі на аснове найбольш запатрабаваных, папярэдне разлічаных паказчыкаў.
Напрыклад, хаб які змяшчае інфармацыю аб супрацоўніку, можа ўключаць у сябе сатэліт з такімі паказчыкамі, як:
- Мінімальны заробак;
- Максімальная зарплата;
- Сярэдні заробак;
- Назапашвальны вынік налічанай зарплаты і т.д.
Лагічна ўключаць PREDEFINED DERIVATIONS у склад PIT табліцы гэтага ж хаба, тады можна без працы атрымаць зрэзы дадзеных па супрацоўніка на пэўна абраную дату.
ВЫСНОВЫ
Як паказвае практыка выкарыстанне DATA VAULT бізнес карыстальнікамі некалькі цяжка па некалькіх прычынах:
- Код запытаў складаны і грувасткі;
- Багацце JOIN'аў уплывае на хуткадзейнасць запытаў;
- Для напісання аналітычных запытаў патрабуецца выбітнае веданне структуры сховішча.
Каб спрасціць доступ да дадзеных, DATA VAULT пашыраецца дадатковымі аб'ектамі:
- PIT (point in time) табліцы;
- BRIDGE табліцы;
- PREDEFINED DERIVATIONS.
У наступнай я планую расказаць, на мой погляд, самае цікавае, для тых, хто працуе з BI. Я прадстаўлю спосабы стварэння табліц - фактаў і табліц - вымярэнняў на базе DATA VAULT.
Матэрыялы артыкула заснаваны:
- На Кента Грацыяна, у якой апроч дэталёвага апісання змяшчаюцца схемы мадэлі;
- Кнізе: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
- Артыкул .
Крыніца: habr.com