Распрацоўка сховішча - справа доўгае і сур'ёзнае.
Многае ў жыцці праекта залежыць ад таго, наколькі добра прадумана аб'ектная мадэль і структура базы на старце.
Агульнапрынятым падыходам былі і застаюцца розныя варыянты спалучэння схемы "зорка" з трэцяй нармальнай формай. Як правіла, па прынцыпе: зыходныя дадзеныя - 3NF, вітрыны - зорка. Гэты падыход, правераны часам і падмацаваны вялікай колькасцю даследаванняў – першае (а часам і адзінае), што прыходзіць у галаву дасведчанаму DWH-шніку пры думцы аб тым, як павінна выглядаць аналітычнае сховішча.
З іншага боку – бізнэсу ў цэлым і патрабаванням заказчыка ў прыватнасці ўласціва хутка мяняцца, а дадзеным – расці як "углыб", так і "ўшыркі". І вось тут выяўляецца асноўны недахоп зоркі - абмежаваная. гнуткасць.
І калі ў вашым ціхім і ўтульным жыцці DWH-распрацоўніка раптам:
- узнікла задача "зрабіць хутка хоць нешта, а потым паглядзім";
- з'явіўся бурна які развіваецца праект, з падлучэннем новых крыніц і пераробкай бізнэс-мадэлі мінімум раз у тыдзень;
- з'явіўся замоўца, які не ўяўляе як сістэма павінна выглядаць і якія функцыі выконваць у канчатковым выніку, але готаў да эксперыментаў і паслядоўнаму ўдакладненню жаданага выніку з паслядоўным жа набліжэннем да яго;
- зазірнуў менеджэр праектаў з радаснай весткай: "А зараз у нас аджайл!".
Або калі вам проста цікава пазнаць як яшчэ можна будаваць сховішчы - вэлкам пад кат!
Што значыць "гнуткасць"
Для пачатку давайце вызначымся, якімі ўласцівасцямі павінна валодаць сістэма, каб яе можна было назваць "гнуткай".
Асобна варта абмовіцца, што апісваныя ўласцівасці павінны ставіцца менавіта да сістэме, а не да працэсу яе распрацоўкі. Таму, калі вы хацелі пачытаць пра Agile як метадалогію распрацоўкі, лепш азнаёміцца з іншымі артыкуламі. Напрыклад, тут жа, на Хабры, ёсць маса цікавых матэрыялаў (як и , так і ).
Гэта не значыць, што працэс распрацоўкі і структура ХД зусім ніяк не злучаны. У цэлым распрацоўваць па Agile сховішча гнуткай архітэктуры павінна быць значна лягчэй. Аднак на практыцы часцей сустракаюцца варыянты і з распрацоўкай па Agile класічнага DWH па Кімбалу і DataVault – па ватэрфоле, чым шчаслівыя супадзенні гнуткасці ў двух яе выявах на адным праекце.
І так, якімі ж магчымасцямі павінна валодаць гнуткае сховішча? Тут можна вылучыць тры пункты:
- Ранняя пастаўка і хуткая дапрацоўка - Гэта значыць, што ў ідэале першы бізнес-вынік (напрыклад, першыя працуючыя справаздачы) павінен быць атрыманы як мага раней, гэта значыць яшчэ да таго, як цалкам спраектавана і ўкаранёна сістэма цалкам. Пры гэтым кожная наступная дапрацоўка таксама павінна займаць як мага менш часу.
- Ітэратыўная дапрацоўка - гэта значыць, што кожная наступная дапрацоўка ў ідэале не павінна закранаць ужо які працуе функцыянал. Менавіта гэты момант часта становіцца самым вялікім кашмарам на буйных праектах - рана ці позна асобныя аб'екты пачынаюць абрастаць такой колькасцю сувязяў, што становіцца прасцей цалкам паўтарыць логіку ў копіі побач, чым дадаць поле ў існуючую табліцу. І калі вас здзіўляе, што аналіз уплыву дапрацоўкі на існуючыя аб'екты можа займаць больш часу, чым сама дапрацоўка - вы хутчэй за ўсё яшчэ не працавалі з буйнымі ХД у банкінгу або тэлекоме.
- Пастаянная адаптацыя да зменлівых патрабаванняў бізнесу - Агульная аб'ектная структура павінна быць спраектавана не проста з улікам магчымага пашырэння а з разлікам на тое, што кірунак гэтага чарговага пашырэння не магло б вам нават прысніцца на этапе праектавання.
І так, адпаведнасць усім гэтым патрабаванням у адной сістэме магчыма (зразумела, у пэўных выпадках і з некаторымі агаворкамі).
Ніжэй я разгледжу дзве самых папулярных для ХД метадалогіі гнуткага праектавання Anchor model и Сховішча даных. За дужкамі застаюцца такія выдатныя прыёмы, як напрыклад EAV, 6NF (у чыстым выглядзе) і ўсё, якое адносіцца да NoSQL рашэнняў – не таму, што яны чымсьці горш, і нават не таму, што ў гэтым выпадку артыкул пагражаў бы набыць аб'ём сярэднестатыстычнага дысера. Проста ўсё гэта ставіцца да рашэнняў некалькі іншага класа – альбо да прыёмаў, якія вы можаце ўжываць у спецыфічных выпадках, незалежна ад агульнай архітэктуры вашага праекта (як EAV), альбо да глабальна іншых парадыгмаў захоўвання інфармацыі (як, напрыклад, графавыя БД і іншыя варыянты NoSQL).
Праблемы "класічнага" падыходу і іх рашэнні ў гнуткіх метадалогіях
Пад "класічным" падыходам маю на ўвазе старую добрую зорку (незалежна ад канкрэтнай рэалізацыі ніжэйлеглых пластоў, ды прабачаць мяне прадстаўнікі Кімбола, Инмона і CDM).
1. Жорсткая кардынальнасьць сувязяў
У аснову такой мадэлі закладваецца выразны падзел дадзеных на вымярэння (Dimension) и факты (Fact). І гэта, чорт пабяры, лагічна - бо аналіз дадзеных у пераважнай большасці выпадкаў зводзіцца менавіта да аналізу пэўных лікавых паказчыкаў (фактаў) у пэўных разрэзах (вымярэннях).
Пры гэтым сувязі паміж аб'ектамі закладваюцца ў выглядзе сувязей паміж табліцамі па вонкавым ключы. Гэта выглядае цалкам натуральна, але адразу ж прыводзіць да першага абмежавання гнуткасці. жорсткаму вызначэнню кардынальнасці сувязей.
Гэта значыць, што на этапе праектавання табліц вы павінны сапраўды вызначыць для кожнай пары злучаных аб'ектаў ці могуць яны ставіцца як шматлікія-да-многім, ці толькі 1-ка-многім, і "ў які бок". Ад гэтага напроста залежыць у якой з табліц будзе першасны ключ а ў які - вонкавы. Змяненне гэтых адносін пры атрыманні новых патрабаванняў з вялікай верагоднасцю прывядзе да перапрацоўкі базы.
Напрыклад, праектуючы аб'ект "касавы чэк" вы, абапіраючыся на клятвенныя запэўненні аддзела продажаў, заклалі магчымасць дзеяння. адной прома-акцыі на некалькі чэкавых пазіцый (але не наадварот):
А праз некаторы час, калегі ўвялі новую маркетынгавую стратэгію, у якой на адну і тую ж пазіцыю могуць дзейнічаць. некалькі прома-акцый адначасова. І зараз вам трэба дапрацаваць табліцы, вылучыўшы сувязь у асобны аб'ект.
(Усе вытворныя аб'екты, у якіх адбываецца джойн чэка на прома, зараз таксама маюць патрэбу ў дапрацоўцы).
Сувязі ў Data Vault і Anchor Model
Пазбегнуць такой сітуацыі аказалася даволі проста: не трэба верыць аддзелу продажаў для гэтага дастаткова усе сувязі першапачаткова захоўваць у асобных табліцах і апрацоўваць як многія-да-многім.
Такі падыход быў прапанаваны Дэнам Лінстэтам (Dan Linstedt) як частка парадыгмы Сховішча даных і цалкам падтрыманы Ларсам Рэнбэкам (Lars Rönnbäck) в Якарнай Мадэлі (Anchor Model).
У выніку атрымліваем першую адметную асаблівасць гнуткіх метадалогій:
Сувязі паміж аб'ектамі не захоўваюцца ў атрыбутах бацькоўскіх сутнасцяў, а ўяўляюць сабой асобны тып аб'ектаў.
В Сховішча даных такія табліцы-звязкі называюцца спасылка, а ў Якарнай Мадэлі - Tie. На першы погляд яны вельмі падобныя, хоць назвай іх адрознення не вычэрпваюцца (пра што пойдзе размова ніжэй). У абедзвюх архітэктурах табліцы-звязкі могуць звязваць любую колькасць сутнасцяў (не абавязкова 2).
Гэтая на першы погляд надмернасць дае істотную гнуткасць пры дапрацоўках. Такая структура становіцца талерантнай не толькі да змены кардынальнасцяў існуючых сувязяў, але і да дадання новых - калі зараз у чэкавай пазіцыі з'явіцца яшчэ і спасылка на касіра, які прабіў яе, з'яўленне такой звязкі стане проста надбудовай над існуючымі табліцамі без уплыву на якія-небудзь існуючыя аб'екты і працэсы.
2. Дубліраванне дадзеных
Другая праблема, развязальная гнуткімі архітэктурамі, меней відавочная і ўласцівая ў першую чаргу вымярэнням тыпу SCD2 (павольна якія змяняюцца вымярэнні другога тыпу), хоць і не толькі ім.
У класічным сховішчы вымярэнне звычайна ўяўляе сабой табліцу, якая змяшчае сурагатны ключ (у якасці PK), а таксама набор бізнес-ключоў і атрыбутаў у асобных калонках.
Калі вымярэнне падтрымлівае версійнасць, да стандартнага набору палёў дадаюцца межы часу дзеяння версіі, а на адзін радок у крыніцы з'яўляецца некалькі версій у сховішча (па адной на кожную змену версійных атрыбутаў).
Калі вымярэнне ўтрымоўвае хоць бы адзін часта змяняецца версійны атрыбут, колькасць версій такога вымярэння будзе вялікім (нават калі астатнія атрыбуты не версійныя, ці ніколі не змяняюцца), а калі такіх атрыбутаў некалькі - колькасць версій можа расці ў геаметрычнай прагрэсіі ад іх колькасці. Такое вымярэнне можа займаць істотны аб'ём дыскавай прасторы, хоць большая частка якія захоўваюцца ў ім дадзеных – проста дублі значэнняў нязменных атрыбутаў з іншых радкоў.
Пры гэтым вельмі часта прымяняецца яшчэ і дэнармалізацыя - частка атрыбутаў наўмысна захоўваюцца ў выглядзе значэння, а не спасылкі на даведнік ці іншае вымярэнне. Такі падыход паскарае доступ да дадзеных, зніжаючы колькасць джойнаў пры звароце да вымярэння.
Як правіла, гэта прыводзіць да таго, што адна і тая ж інфармацыя захоўваецца адначасова ў некалькіх месцах. Напрыклад, інфармацыя аб рэгіёне пражывання і прыналежнасці катэгорыі кліента можа адначасова захоўвацца ў вымярэннях "Кліент", і фактах "Купля", "Дастаўка" і "Звароты ў кол-цэнтр", а таксама ў табліцы-звязку "Кліент - Кліенцкі менеджэр".
У цэлым апісанае вышэй ставяцца і да звычайных (не версійных) вымярэнняў, але ў версійных могуць мець іншы маштаб: з'яўленне новай версіі аб'екта (асабліва заднім лікам), прыводзіць не проста да абнаўлення ўсіх злучаных табліц, а да каскаднага з'яўлення новых версій злучаных аб'ектаў — калі Табліца 1 выкарыстоўваецца пры пабудове Табліцы 2, а Табліца 2 - пры пабудове Табліцы 3 і г.д. Нават калі ніводны атрыбут Табліцы 1 не ўдзельнічае ў пабудове Табліцы 3 (а ўдзельнічаюць іншыя атрыбуты Табліцы 2, атрыманыя з іншых крыніц), версійнае абнаўленне гэтай канструкцыі прынамсі прывядзе да дадатковых накладных выдаткаў, а як максімум - да лішніх версій у Табліцы 3, якая тут наогул "ні пры чым" і далей па ланцужку.
3. Нелінейная складанасць дапрацоўкі
Пры гэтым кожная новая вітрына, якая будуецца на падставе іншай, павялічвае колькасць месцаў, у якіх дадзеныя могуць "разыйсціся" пры занясенні змен у ETL. Гэта, у сваю чаргу, прыводзіць да ўзрастання складанасці (і працягласці) кожнай наступнай дапрацоўкі.
Калі вышэйапісанае тычыцца сістэм з рэдка дапрацоўваем ETL-працэсамі, жыць у такой парадыгме можна - досыць проста сачыць за тым, каб новыя дапрацоўкі карэктна ўносіліся ва ўсе звязаныя аб'екты. Калі ж дапрацоўкі адбываюцца часта, верагоднасць выпадкова "выпусціць" некалькі сувязяў істотна ўзрастае.
Калі ў дадатак улічыць, што "версійны" ETL істотна складаней, чым "не версійны", пазбегнуць памылак пры частай дапрацоўцы ўсёй гэтай гаспадаркі становіцца досыць складана.
Захоўванне аб'ектаў і атрыбутаў у Data Vault і Anchor Model
Падыход, прапанаваны, аўтарамі гнуткіх архітэктур, можна сфармуляваць так:
Неабходна аддзяліць тое, што мяняецца, ад таго, што застаецца нязменным. Гэта значыць захоўваць ключы асобна ад атрыбутаў.
Пры гэтым не варта блытаць не версійны атрыбут з нязменным: першы не захоўвае гісторыю сваёй змены, але можа мяняцца (напрыклад, пры выпраўленні памылкі ўводу або атрыманні новых дадзеных) другі - не мяняецца ніколі.
Пункты гледжання на тое, што менавіта можна лічыць нязменным у Data Vault і якарнай мадэлі разыходзяцца.
З пункту гледжання архітэктуры Сховішча даныхнязменным можна лічыць увесь набор ключоў - натуральныя (ІНАЎ арганізацыі, код тавару ў сістэме-крыніцы і да т.п) і сурагатныя. Пры гэтым астатнія атрыбуты можна падзяліць па групах па крыніцы і/ці частаце змен і для кожнай групы весці асобную табліцу з незалежным наборам версій.
У парадыгме ж Anchor Model нязменным лічыцца толькі сурагатны ключ сутнасці. Усё астатняе (уключаючы натуральныя ключы) - проста прыватны выпадак яго атрыбутаў. Пры гэтым усе атрыбуты па змаўчанні незалежныя сябар ад сябра, таму для кожнага атрыбута павінна быць створана асобная табліца.
В Сховішча даных табліцы, якія змяшчаюць ключы сутнасцяў, называюцца Хабамі (Hub). Хабы заўсёды ўтрымоўваюць фіксаваны набор палёў:
- Натуральныя ключы сутнасці
- Сурагатны ключ
- Спасылку на крыніцу
- Час дадання запісу
Запісы ў Хабах ніколі не змяняюцца і не маюць версій. Вонкава хабы вельмі падобныя на табліцы тыпу ID-map, якія ўжываюцца ў некаторых сістэмах для генерацыі сурагатаў, аднак у якасці сурагатаў у Data Vault рэкамендуецца ўжываць не цэлалікавы сіквенс, а хэш ад набору бізнэс-ключоў. Такі падыход спрашчае загрузку сувязяў і атрыбутаў з крыніц (не трэба джойніцца на хаб для атрымання сурагату, дастаткова проста палічыць хэш ад натуральнага ключа), але можа выклікаць іншыя праблемы (звязаныя, напрыклад, з калізіямі, рэгістрам і недрукаванымі сімваламі ў радковых ключах і т.д. .п.), таму не з'яўляецца агульнапрынятым.
Усе астатнія атрыбуты сутнасцяў захоўваюцца ў спецыяльных табліцах, званых Сатэлітамі (Satellit). Адзін хаб можа мець некалькі сатэлітаў, якія захоўваюць розныя наборы атрыбутаў.
Размеркаванне атрыбутаў па сатэлітах адбываецца па прынцыпе сумеснай змены — у адным сатэліце могуць захоўвацца не версійныя атрыбуты (напрыклад, дата нараджэння і СНІЛС для фіз.асобы), у іншым — версійныя (напрыклад, прозвішча і нумар пашпарта), якія рэдка змяняюцца, у трэцім — часта змяняюцца (напрыклад, адрас дастаўкі, катэгорыя, дата апошняй замовы і.т.п). Версійнасць пры гэтым вядзецца на ўзроўні асобных сатэлітаў, а не сутнасці ў цэлым, таму размеркаванне атрыбутаў мэтазгодна праводзіць так, каб скрыжаванне версій усярэдзіне аднаго сатэліта было мінімальным (што скарачае агульную колькасць захоўваемых версій).
Таксама, для аптымізацыі працэсу загрузкі дадзеных, у асобныя сатэліты часта выносяцца атрыбуты, якія атрымліваюцца з розных крыніц.
Сатэліты звязваюцца з Хабам па знешняму ключу (што адпавядае кардынальнасці 1-ка-многім). Гэта значыць, што множныя значэнне атрыбутаў (напрыклад, некалькі кантактных нумароў тэлефона ў аднаго кліента) падтрымліваецца такой архітэктурай "па змаўчанні".
В Якарнай мадэлі (Anchor Model) табліцы, якія захоўваюць ключы, называюцца Якарамі (Anchor). І захоўваюць яны:
- Толькі сурагатныя ключы
- Спасылку на крыніцу
- Час дадання запісу
Натуральныя ключы з пункту гледжання Якарнай Мадэлі лічацца звычайнымі атрыбутамі. Такі варыянт можа здацца больш складаным для разумення, але ён дае нашмат больш абшару для ідэнтыфікацыі аб'екта.
Напрыклад, калі дадзеныя аб адной і той жа сутнасці могуць паступаць з розных сістэм, у кожнай з якіх выкарыстоўваецца свой натуральны ключ. У Data Vault гэта можа прыводзіць да досыць грувасткім канструкцый з некалькіх хабаў (па адным на крыніцу + якая аб'ядноўвае майстар-версія), у якарнай мадэлі ж натуральны ключ кожнай крыніцы пападае ў свой атрыбут і можа выкарыстоўвацца пры загрузцы незалежна ад усіх астатніх.
Але тут крыецца і адзін падступны момант: калі ў адной сутнасці аб'ядноўваюцца атрыбуты з розных сістэм, хутчэй за ўсё існуюць некаторыя. правілы "склейкі", па якіх сістэма павінна разумець, што запісы з розных крыніц адпавядаюць аднаму асобніку сутнасці.
В Сховішча даных гэтыя правілы хутчэй за ўсё будуць вызначаць фарміраванне "сурагатнага хаба" майстар-сутнасці і ніяк не ўплываць на Хабы, якія захоўваюць натуральныя ключы крыніц і іх зыходныя атрыбуты. Калі ў нейкі момант правілы злепвання памяняюцца (ці прыйдзе абнаўленне атрыбутаў, па якіх яна вырабляецца), дастаткова будзе перафармаваць сурагатныя хабы.
В Якарнай мадэлі ж такая сутнасць хутчэй за ўсё будзе захоўвацца ў адзіным якары. Гэта значыць, што ўсе атрыбуты, незалежна ад таго, з якой крыніцы яны атрыманы, будуць прывязаныя да аднаго і таго ж сурагату. Падзяліць памылкова злітыя запісы і ў цэлым адсочваць актуальнасць злепвання ў такой сістэме можа апынуцца істотна цяжэй, асабліва, калі правілы досыць складаныя і часта змяняюцца, а адзін і той жа атрыбут можа быць атрыманы з розных крыніц (хоць сапраўды магчыма, бо кожная версія атрыбута захоўвае спасылку на сваю крыніцу).
У любым выпадку, калі ў вашай сістэме мяркуецца рэалізацыя функцыяналу дэдэпублікацыі, зліцця запісаў і іншых элементаў MDM, варта асабліва ўважліва азнаёміцца з аспектамі захоўвання натуральных ключоў у гнуткіх метадалогіях. Верагодна, больш грувасткая канструкцыя Data Vault раптам апынецца больш бяспечнай з пункта гледжання памылак зліцця.
Якарная мадэль таксама прадугледжвае дадатковы тып аб'екта, званы Вузлом (Knot) па сутнасці гэта спецыяльны выраджаны выгляд якара, які можа змяшчаць усяго адзін атрыбут. Вузлы мяркуецца выкарыстоўваць для захоўвання плоскіх даведнікаў (напрыклад падлогу, сямейнае становішча, катэгорыя абслугоўвання кліентаў і да т.п). У адрозненні ад Якара, Вузел не мае звязаных табліц атрыбутаў, а яго адзіны атрыбут (назва) заўсёды захоўваецца ў адной табліцы з ключом. Вузлы звязваюцца з Якара табліцамі-сувязямі (Tie) таксама, як якара адзін з адным.
Адназначнага меркавання наконт выкарыстання Вузлоў няма. Напрыклад, , Які актыўна прасоўвае прымяненне Якарнай мадэлі ў Расіі, лічыць (не беспадстаўна), што ні для аднаго даведніка нельга дакладна сцвярджаць, што ён заўсёды будзе статычным і аднаўзроўневым, таму для ўсіх аб'ектаў лепш адразу выкарыстаць паўнавартасны Якар.
Яшчэ адно важнае адрозненне Data Vault і якарнай мадэлі складаецца ў наяўнасці атрыбутаў у сувязяў:
В Сховішча даных Сувязі з'яўляюцца такім жа паўнавартаснымі аб'ектамі, як і Хабы, і могуць мець уласныя атрыбуты. У Якарнай мадэлі Сувязі выкарыстоўваюцца толькі для злучэння Якароў і уласных атрыбутаў мець не могуць. Гэтае адрозненне дае істотна розныя падыходы да мадэлявання. фактаў, пра што пойдзе гаворка далей.
Захоўванне фактаў
Да гэтага мы казалі ў асноўным пра мадэляванне вымярэнняў. З фактамі справа ідзе крыху менш адназначна.
В Сховішча даных тыповы аб'ект для захоўвання фактаў - Сувязь (Link), у Сатэліты якой складаюцца рэчавыя паказчыкі.
Такі падыход выглядае інтуітыўна зразумелым. Ён дае просты доступ да аналізаваных паказчыкаў і ў цэлым падобны на традыцыйную табліцу фактаў (толькі паказчыкі захоўваюцца не ў самой табліцы, а ў "суседняй"). Але ёсць і падводныя камяні: адна з тыпавых дапрацовак мадэлі – пашырэнне ключа факту – выклікае неабходнасць дадання ў Link новага знешняга ключа. А гэта ў сваю чаргу "ламае" модульнасць і патэнцыйна выклікае неабходнасць дапрацовак іншых аб'ектаў.
В Якарнай мадэлі Сувязь не можа мець уласных атрыбутаў, таму такі падыход не пракоціць - абсалютна ўсе атрыбуты і паказчыкі абавязаны мець прывязку да аднаго канкрэтнага якара. Выснова з гэтага простая для кожнага факта таксама патрэбен свой якар. Для часткі таго, што мы абвыклі ўспрымаць як факты, гэта можа выглядаць натуральна - напрыклад, факт пакупкі выдатна зводзіцца да аб'екта "заказ" або "чэк", наведванне сайта - да сесіі і да т.п. Але сустракаюцца і факты, для якіх знайсці такі натуральны "аб'ект-носьбіт" не так проста - напрыклад, рэшткі тавараў на складах на пачатак кожнага дня.
Адпаведна, праблем з модульнасцю пры пашырэнні ключа факту ў якарнай мадэлі не ўзнікае (досыць проста дадаць новую Сувязь да адпаведнага Якару), але праектаванне мадэлі для адлюстравання фактаў менш адназначна, могуць з'яўляцца "штучныя" Якары, якія адлюстроўваюць аб'ектную мадэль бізнэсу не відавочна.
Як дасягаецца гнуткасць
Атрыманая канструкцыя ў абодвух выпадках утрымоўвае істотна больш табліц, чым традыцыйнае вымярэнне. Але можа займаць істотна менш дыскавай прасторы пры тым жа наборы версійных атрыбутаў, што і традыцыйнае вымярэнне. Ніякай магіі тут, натуральна, не - уся справа ў нармалізацыі. Размяркоўваючы атрыбуты па Сатэлітах (у Data Vault) або асобным табліцам (Anchor Model), мы памяншаем (ці зусім выключаем) дубляванне значэнняў адных атрыбутаў пры змене іншых.
Для Сховішча даных выйгрыш будзе залежаць ад размеркавання атрыбутаў па Сатэлітах, а для Якарнай мадэлі - практычна прама прапарцыйны сярэдняй колькасці версій на аб'ект вымярэння.
Аднак выйгрыш па займаемым месцы - важная, але не галоўная перавага асобнага захоўвання атрыбутаў. Разам з асобным захоўваннем сувязей, такі падыход робіць сховішча. модульнай канструкцыяй. Гэта значыць, што даданне як асобных атрыбутаў, так і цэлых новых прадметных абласцей у такой мадэлі выглядае як надбудова над існуючым наборам аб'ектаў без іх змены. І гэта менавіта тое, што робіць апісаныя метадалогіі гнуткімі.
Таксама гэта нагадвае пераход ад адзінкавай вытворчасці да масавай – калі ў традыцыйным падыходзе кожная табліца мадэлі ўнікальная і патрабуе асобнай увагі, то ў гнуткіх метадалогіях – гэта ўжо набор тыпавых "дэталяў". З аднаго боку, табліц становіцца больш, працэсы загрузкі і выбаркі дадзеных павінны выглядаць больш складана. З іншага - яны становяцца тыпавымі. А значыць, могуць быць аўтаматызаваны і кіравацца метададзенымі. Пытанне "як будзем укладваць?", адказ на які мог займаць істотную частку работ па праектаванні дапрацовак, зараз проста не стаіць (як і пытанне аб уплыве змянення мадэлі на працуючыя працэсы).
Гэта не значыць, што аналітыкі ў такой сістэме зусім не патрэбныя - нехта ўсё яшчэ павінен прапрацаваць набор аб'ектаў з атрыбутамі і разабрацца адкуль і як усё гэта загружаць. Але аб'ём прац, а таксама верагоднасць і кошт памылкі істотна змяншаюцца. Як на этапе аналізу, так і пры распрацоўцы ETL, якая ў істотнай частцы можа звесціся да рэдагавання метададзеных.
Цёмны бок
Усё вышэйапісанае робіць абодва падыходы сапраўды гнуткімі, тэхналагічнымі і прыдатнымі для ітэратыўнай дапрацоўкі. Зразумела ёсць і "бочка дзёгцю", аб якой вы, думаю, ужо здагадваецеся.
Дэкампазіцыя дадзеных, якая ляжыць у аснове модульнасці гнуткіх архітэктур, прыводзіць да павелічэння колькасці табліц і, адпаведна, накладных выдаткаў на джойны пры выбарцы. Для таго, каб проста атрымаць усе атрыбуты вымярэння, у класічным сховішчы дастатковага аднаго селекту, а гнуткая архітэктура запатрабуе цэлага шэрагу джойнаў. Прычым калі для справаздач усе гэтыя джойны можна напісаць загадзя, то аналітыкі, якія звыкнуліся пісаць SQL рукамі, будуць пакутаваць удвая.
Ёсць некалькі фактаў, якія палягчаюць такое становішча:
Пры рабоце з вялікімі вымярэннямі амаль ніколі не выкарыстоўваюцца адначасова ўсе яго атрыбуты. Гэта значыць, што джойнаў можа быць менш, чым здаецца пры першым поглядзе на мадэль. У Data Vault можна таксама ўлічыць меркаваную частату сумеснага выкарыстання пры размеркаванні атрыбутаў па сатэлітах. Пры гэтым самі Хабы або Якары патрэбныя ў першую чаргу для генерацыі і мапінга сурагатаў на этапе загрузкі і рэдка выкарыстоўваюцца ў запытах (асабліва гэта датычыцца Якароў).
Усе джойны - па ключы. Акрамя таго, больш "сціснуты" спосаб захоўвання дадзеных зніжае накладныя выдаткі на сканаванне табліц там, дзе яно неабходна (напрыклад пры фільтрацыі па значэнні атрыбуту). Гэта можа прыводзіць да таго, што выбарка з нармалізаванай базы з кучай джойнаў будзе нават хутчэй, чым сканіраванне аднаго цяжкага вымярэння з вялікай колькасцю версій на радок.
Напрыклад, вось у артыкуле ёсць падрабязны параўнальны тэст прадукцыйнасці якарнай мадэлі з выбаркай з адной табліцы.
Многае залежыць ад рухавічка. У шматлікіх сучасных платформаў ёсць унутраныя механізмы аптымізацыі джойнаў. Напрыклад, MS SQL і Oracle умеюць "прапускаць" джойны на табліцы, калі іх дадзеныя не выкарыстоўваюцца нідзе, акрамя іншых джойнаў і не ўплываюць на фінальную выбарку (table/join elimination), а MPP Vertica па , паказала сябе як выдатны рухавічок для якарнай мадэлі з улікам некаторай ручной аптымізацыі плана запыту. З іншага боку, захоўваць якарную мадэль, напрыклад, на Click House, які мае абмежаваную падтрымку join, пакуль выглядае не вельмі добрай ідэяй.
Акрамя таго, для абедзвюх архітэктур існуюць спецыяльныя прыёмы, якія палягчаюць доступ да дадзеных (як з пункту гледжання прадукцыйнасці запытаў, так і для канчатковых карыстальнікаў). Напрыклад, Point-In-Time табліцы у Data Vault або спецыяльныя таблічныя функцыі у якарнай мадэлі.
Разам
Асноўная сутнасць разгледжаных гнуткіх архітэктур складаецца ў модульнасці іх "канструкцыі".
Менавіта гэтая ўласцівасць дазваляе:
- Пасля некаторай пачатковай падрыхтоўкі, злучанай з разгортваннем метададзеных і напісаннем базавых алгарытмаў ETL, хутка даць заказчыку першы вынік у выглядзе парачкі справаздач, якія змяшчаюць дадзеныя ўсяго некалькіх аб'ектаў крыніц. Цалкам прадумваць (нават верхнеўзроўневыя) усю аб'ектную мадэль для гэтага не абавязкова.
- Мадэль дадзеных можа пачаць працаваць (і прыносіць карысць) усяго з 2-3 аб'ектамі, а потым паступова разрастацца (адносна Якарнай мадэлі Мікалай прыгожае параўнанне з грыбніцай).
- Большасць дапрацовак, у тым ліку пашырэнне прадметнай вобласці і даданне новых крыніц не закранае існуючы функцыянал і не выклікае небяспеку зламаць нешта ўжо працуе.
- Дзякуючы дэкампазіцыі на стандартныя элементы, ETL-працэсы ў такіх сістэмах выглядаюць аднатыпна, іх напісанне паддаецца алгарытмізацыі і, у канчатковым рахунку, аўтаматызацыі.
Коштам такой гнуткасці з'яўляецца прадукцыйнасць. Гэта не значыць, што дасягнуць прымальнай прадукцыйнасці на такіх мадэлях немагчыма. Часцей за ўсё, вам проста можа спатрэбіцца больш намаганняў і ўвагі да дэталяў для дасягнення патрэбных метрык.
Прыкладання
Тыпы сутнасці Сховішча даных
Падрабязней пра Data Vault:
Тыпы сутнасцяў Anchor Model
Падрабязней пра Anchor Model:
Зводная табліца з агульнымі рысамі і адрозненнямі разгледжаных падыходаў:
Крыніца: habr.com