Преглед агилних ДВХ методологија дизајна

Изградња складишта је дуг и озбиљан подухват.

Много тога у животу пројекта зависи од тога колико су модел објекта и основна структура осмишљени на почетку.

Општеприхваћени приступ су биле и остале различите варијанте комбиновања шеме звезда са трећим нормалним обликом. По правилу, по принципу: почетни подаци - 3НФ, витрине - звезда. Овај приступ, временски тестиран и подржан великом количином истраживања, прва је (а понекад и једина) ствар која искусном ДВХ специјалисту пада на памет када размишља о томе како би аналитичко спремиште требало да изгледа.

С друге стране, пословање уопште и захтеви купаца посебно имају тенденцију да се брзо мењају, а подаци имају тенденцију да расту и „у дубину“ и „у ширину“. И ту се појављује главни недостатак звезде - ограничен еластичност.

А ако у вашем мирном и удобном животу као ДВХ програмер изненада:

• настао је задатак „да се бар нешто уради брзо, а онда ћемо видети“;
• појавио се пројекат који се убрзано развија, са повезивањем нових извора и прерадом пословног модела најмање једном недељно;
• појавио се купац који нема појма како систем треба да изгледа и које функције на крају треба да обавља, али је спреман да експериментише и доследно усавршава жељени резултат док му се доследно приближава;
• Менаџер пројекта је свратио са добрим вестима: „А сада имамо агиле!“

Или ако сте само заинтересовани да сазнате како другачије можете да изградите складишта - добродошли у рез!

Шта значи "флексибилност"?

Прво, хајде да дефинишемо која својства систем мора да има да би се могао назвати „флексибилним“.

Одвојено, вреди напоменути да се описана својства треба посебно односити на систем, не да процес његов развој. Стога, ако желите да читате о Агиле-у као развојној методологији, боље је да прочитате друге чланке. На пример, управо тамо, на Хабре, има много занимљивих материјала (нпр преглед и практичноИ проблематично).

То не значи да су процес развоја и структура складишта података потпуно неповезани. Све у свему, требало би да буде знатно лакше развити Агиле спремиште за агилну архитектуру. Међутим, у пракси чешће постоје опције са Агиле развојем класичног ДВХ-а према Кимбал-у и ДатаВаулт-у - према Ватерфалл-у, него срећне случајности флексибилности у своја два облика на једном пројекту.

Дакле, које могућности треба да има флексибилно складиштење? Овде постоје три тачке:

1. Рана испорука и брз обрт - то значи да би идеално требало да се први пословни резултат (на пример, први радни извештаји) добије што је пре могуће, односно чак и пре него што се цео систем у потпуности осмисли и имплементира. Штавише, свака следећа ревизија такође треба да траје што је могуће мање времена.
2. Итеративно усавршавање - то значи да свако наредно побољшање идеално не би требало да утиче на функционалност која већ ради. Управо овај тренутак често постаје највећа ноћна мора на великим пројектима - пре или касније, појединачни објекти почињу да стичу толико веза да постаје лакше потпуно поновити логику у копији у близини него додати поље у постојећу табелу. А ако сте изненађени да анализа утицаја побољшања на постојеће објекте може да потраје више времена од самих побољшања, највероватније још увек нисте радили са великим складиштима података у банкарству или телекомуникацијама.
3. Стално прилагођавање променљивим пословним захтевима - укупну структуру објекта треба пројектовати не само узимајући у обзир могуће проширење, већ са очекивањем да се правац овог следећег проширења не може ни сањати у фази пројектовања.

И да, испуњавање свих ових захтева у једном систему је могуће (наравно, у одређеним случајевима и уз одређене резерве).

У наставку ћу размотрити две најпопуларније методологије агилног дизајна за складишта података - Анцхор модел и Дата Ваулт. Изостављене су изван заграда тако одличне технике као што су, на пример, ЕАВ, 6НФ (у свом чистом облику) и све што се односи на НоСКЛ решења – не зато што су некако лошија, па чак ни зато што би у овом случају чланак претио да добије обим просечног дисера. Само што се све ово односи на решења мало другачије класе – било на технике које можете да користите у одређеним случајевима, без обзира на целокупну архитектуру вашег пројекта (као ЕАВ), или на глобално друге парадигме складиштења информација (као што су базе података графова). и друге опције НоСКЛ).

Проблеми „класичног” приступа и њихова решења у флексибилним методологијама

Под „класичним“ приступом мислим на стару добру звезду (без обзира на специфичну имплементацију основних слојева, нека ми опросте следбеници Кимбалла, Инмона и ЦДМ-а).

1. Крута кардиналност веза

Овај модел се заснива на јасној подели података на Димензија и чињенице. И ово је, дођавола, логично – уосталом, анализа података у огромној већини случајева своди се на анализу одређених бројчаних показатеља (чињеница) у одређеним одељцима (димензијама).

У овом случају, везе између објеката се успостављају у облику релација између табела помоћу страног кључа. Ово изгледа сасвим природно, али одмах доводи до првог ограничења флексибилности - стриктно дефинисање кардиналности веза.

То значи да у фази пројектовања табеле морате тачно да одредите за сваки пар повезаних објеката да ли могу да се односе као више-према-више, или само 1-према-много, и „у ком правцу“. Ово директно одређује која табела ће имати примарни кључ, а која спољни кључ. Промена овог става када се добију нови захтеви ће највероватније довести до прераде базе.

На пример, приликом пројектовања објекта „готовинског рачуна“, ви сте, ослањајући се на заклетве одељења продаје, поставили могућност деловања једно унапређење за неколико позиција за проверу (али не и обрнуто):

И после неког времена, колеге су увеле нову маркетиншку стратегију у којој могу да делују на истој позицији неколико промоција у исто време. А сада треба да измените табеле одвајањем односа у посебан објекат.

(Сви изведени објекти у којима се провјера промоције сада такође треба побољшати).

Односи у трезору података и моделу сидра

Показало се да је избегавање ове ситуације прилично једноставно: не морате веровати одељењу продаје да то уради. све везе се у почетку чувају у посебним табелама и обрадити га као много-према-многима.

Овај приступ је предложен Дан Линстедт као део парадигме Дата Ваулт и у потпуности подржан Ларс Роннбацк в Анцхор Модел.

Као резултат, добијамо прву карактеристичну особину флексибилних методологија:

Релације између објеката се не чувају у атрибутима родитељских ентитета, већ су посебна врста објеката.

В Дата Ваулт такве табеле повезивања се називају линк, и у Анцхор Модел - тие. На први поглед, они су веома слични, иако се њихове разлике не завршавају именом (о чему ће бити речи у наставку). У обе архитектуре, табеле веза могу да се повезују било који број ентитета (не нужно 2).

Ова редундантност, на први поглед, пружа значајну флексибилност за модификације. Таква структура постаје толерантна не само на промене кардиналности постојећих веза, већ и на додавање нових – ако сада чек позиција има и везу са благајником који је пробио кроз њу, појава такве везе ће једноставно постати додатак преко постојећих табела без утицаја на постојеће објекте и процесе.

2. Дуплицирање података

Други проблем који решавају флексибилне архитектуре је мање очигледан и инхерентан је на првом месту. Мерења типа СЦД2 (полако мењају димензије другог типа), мада не само њих.

У класичном складишту, димензија је обично табела која садржи сурогат кључ (као ПК) и скуп пословних кључева и атрибута у одвојеним колонама.

Ако димензија подржава верзионисање, границе ваљаности верзије се додају стандардном скупу поља, а неколико верзија се појављује у спремишту за један ред у извору (једна за сваку промену у верзионисаним атрибутима).

Ако димензија садржи бар један атрибут који се често мења, број верзија такве димензије ће бити импресиван (чак и ако преостали атрибути нису верзионисани или се никада не мењају), а ако постоји неколико таквих атрибута, број верзија може расту експоненцијално од њиховог броја. Ова димензија може заузети значајну количину простора на диску, иако је велики део података које чува једноставно дупликати непроменљивих вредности атрибута из других редова.

У исто време, такође се веома често користи денормализација — неки атрибути се намерно чувају као вредност, а не као веза ка референтној књизи или некој другој димензији. Овај приступ убрзава приступ подацима, смањујући број спајања приликом приступа димензији.

Обично ово доводи до исте информације се чувају истовремено на више места. На пример, информације о региону пребивалишта и категорији клијента могу истовремено да се чувају у димензијама „Клијент” и чињеницама „Куповина”, „Достава” и „Позиви у позивном центру”, као и у „Клијент – менаџер за клијенте”. ” табела веза.

Уопштено говорећи, горе описано важи за регуларне (неверзионисане) димензије, али у верзијама оне могу имати другачију скалу: појава нове верзије објекта (нарочито у ретроспективи) доводи не само до ажурирања свих повезаних табеле, већ на каскадно појављивање нових верзија сродних објеката – када се табела 1 користи за прављење табеле 2, а табела 2 за изградњу табеле 3 итд. Чак и ако ниједан атрибут табеле 1 није укључен у конструкцију табеле 3 (а укључени су и други атрибути табеле 2 добијени из других извора), верзија ове конструкције ће на минимуму довести до додатних трошкова, а максимално до додатних верзије у табели 3. која са тим уопште нема везе и даље низ ланац.

3. Нелинеарна сложеност прераде

Истовремено, сваки нови излог изграђен на основу другог повећава број места на којима подаци могу да се „разиђу” када се промене ЕТЛ. Ово, заузврат, доводи до повећања сложености (и трајања) сваке наредне ревизије.

Ако горе описани системи са ретко модификованим ЕТЛ процесима, можете живети у таквој парадигми - само треба да се уверите да су нове модификације исправно направљене на свим повезаним објектима. Ако се ревизије дешавају често, вероватноћа да ћете случајно „пропустити“ неколико веза значајно се повећава.

Ако, поред тога, узмемо у обзир да је „верзионисани“ ЕТЛ знатно компликованији од „неверзионисаног“, постаје прилично тешко избећи грешке приликом честог ажурирања читавог овог објекта.

Чување објеката и атрибута у трезору података и моделу сидра

Приступ који су предложили аутори флексибилних архитектура може се формулисати на следећи начин:

Неопходно је одвојити шта се мења од онога што остаје исто. То јест, чувајте кључеве одвојено од атрибута.

Међутим, не треба збунити није верзионисано атрибут са непромењена: први не чува историју својих промена, али може да се мења (на пример, приликом исправљања грешке у уносу или пријема нових података); други се никада не мења.

Тачке гледишта се разликују о томе шта се тачно може сматрати непроменљивим у трезору података и моделу сидра.

Са архитектонске тачке гледишта Дата Ваулт, може се сматрати непромењеним цео сет кључева - природни (ТИН организације, шифра производа у изворном систему итд.) и сурогат. У овом случају, преостали атрибути се могу поделити у групе према извору и/или учесталости промена и Одржавајте посебну табелу за сваку групу са независним скупом верзија.

У парадигми Анцхор Модел сматра непромењеним само сурогат кључ Душа. Све остало (укључујући природне кључеве) је само посебан случај његових атрибута. У чему сви атрибути су подразумевано независни један од другог, тако да за сваки атрибут а засебна табела.

В Дата Ваулт позивају се табеле које садрже кључеве ентитета Хубами. Чворишта увек садрже фиксни скуп поља:

• Кључеви природних ентитета
• Сурогат кључ
• Линк до извора
• Забележите време додавања

Објаве у чвориштима никада се не мењају и немају верзије. Споља, чворишта су веома слична табелама типа ИД-мапе које се користе у неким системима за генерисање сурогата, међутим, препоручује се коришћење хеш из скупа пословних кључева као сурогата у Трезору података. Овај приступ поједностављује учитавање односа и атрибута из извора (нема потребе да се придружите чворишту да бисте добили сурогат, само израчунајте хеш природног кључа), али може да изазове друге проблеме (везане, на пример, са колизијама, великим словима и неисписним знакова у стринг кључевима итд. .п.), стога није опште прихваћено.

Сви остали атрибути ентитета се чувају у посебним табелама тзв Сателити. Једно чвориште може имати неколико сателита који чувају различите скупове атрибута.

Расподела атрибута међу сателитима одвија се по принципу заједничка промена — у једном сателиту могу да се чувају неверзионисани атрибути (на пример, датум рођења и СНИЛС за појединца), у другом - они који се ретко мењају (на пример, презиме и број пасоша), у трећем - они који се често мењају (на пример, адреса испоруке, категорија, датум последње поруџбине итд.). У овом случају, верзија се врши на нивоу појединачних сателита, а не ентитета у целини, па је препоручљиво дистрибуирати атрибуте тако да укрштање верзија унутар једног сателита буде минимално (што смањује укупан број сачуваних верзија). ).

Такође, да би се оптимизовао процес учитавања података, атрибути добијени из различитих извора често се укључују у појединачне сателите.

Сателити комуницирају са чвориштем преко страни кључ (што одговара кардиналности 1 према много). То значи да вишеструке вредности атрибута (на пример, више бројева телефона за контакт за једног клијента) подржава ова „подразумевана“ архитектура.

В Анцхор Модел табеле које чувају кључеве се зову Анцхорс. И чувају:

• Само сурогат кључеви
• Линк до извора
• Забележите време додавања

Разматрају се природни кључеви са становишта Анцхор модела обични атрибути. Ова опција може изгледати теже за разумевање, али даје много више простора за идентификацију објекта.

На пример, ако подаци о истом ентитету могу доћи из различитих система, од којих сваки користи свој природни кључ. У трезору података, ово може довести до прилично гломазних структура неколико чворишта (један по извору + обједињујућа главна верзија), док у Анцхор моделу природни кључ сваког извора спада у сопствени атрибут и може се користити приликом учитавања независно од сви остали.

Али овде постоји и једна подмукла тачка: ако се атрибути из различитих система комбинују у један ентитет, највероватније постоје неки правила "лепљења", чиме систем мора да разуме да записи из различитих извора одговарају једној инстанци ентитета.

В Дата Ваулт ова правила ће највероватније одредити формацију „сурогат чвориште“ главног ентитета и ни на који начин не утиче на чворишта која чувају природне изворне кључеве и њихове оригиналне атрибуте. Ако се у неком тренутку промене правила спајања (или се ажурирају атрибути помоћу којих се оно обавља), биће довољно да се сурогат чворишта поново форматирају.

В Анцхор модел такав ентитет ће највероватније бити ускладиштен у једино сидро. То значи да ће сви атрибути, без обзира из ког извора потичу, бити везани за исти сурогат. Раздвајање погрешно спојених записа и, уопште, праћење релевантности спајања у таквом систему може бити много теже, посебно ако су правила прилично сложена и често се мењају, а исти атрибут се може добити из различитих извора (иако је свакако могуће, пошто свака верзија атрибута задржава везу до свог извора).

У сваком случају, ако ваш систем треба да имплементира функционалност дедупликација, спајање записа и других МДМ елемената, вреди обратити посебну пажњу на аспекте чувања природних кључева у агилним методологијама. Вероватно је да ће гломазнији дизајн трезора података одједном бити сигурнији у смислу грешака при спајању.

Анцхор модел такође пружа додатни тип објекта тзв Чвор у суштини је посебан дегенерисани тип сидра, који може да садржи само један атрибут. Чворови би требало да се користе за чување равних именика (на пример, пол, брачни статус, категорија корисничке услуге, итд.). За разлику од Сидра, Чвора нема придружене табеле атрибута, а његов једини атрибут (име) увек се чува у истој табели са кључем. Чворови су повезани са сидрима помоћу табела веза (Тие) на исти начин као што су сидра међусобно повезана.

Не постоји јасно мишљење о употреби чворова. На пример, Николај Голов, који активно промовише употребу сидро модела у Русији, сматра (не безразложно) да се ни за један приручник може са сигурношћу тврдити да увек ће бити статична и на једном нивоу, па је боље одмах користити пуноправни Сидро за све објекте.

Још једна важна разлика између Дата Ваулт-а и Анцхор модела је доступност атрибути веза:

В Дата Ваулт Линкови су исти пуноправни објекти као и чворишта и могу их имати сопствених атрибута. У Анцхор модел Везе се користе само за повезивање Сидра и не могу имати своје атрибуте. Ова разлика резултира значајно различитим приступима моделирању чињенице, о чему ће даље бити речи.

Складиштење чињеница

Пре овога смо углавном говорили о моделирању мерења. Чињенице су мало мање јасне.

В Дата Ваулт типичан објекат за чување чињеница је Линк, у чијим сателитима се додају реални индикатори.

Овај приступ изгледа интуитиван. Омогућава лак приступ анализираним индикаторима и генерално је сличан традиционалној табели чињеница (само индикатори се не чувају у самој табели, већ у „суседној“). Али постоје и замке: једна од типичних модификација модела - проширење кључа чињеница - захтева додавање новог страног кључа у Линк. А ово, заузврат, „разбија“ модуларност и потенцијално узрокује потребу за модификацијама других објеката.

В Анцхор модел Веза не може имати своје атрибуте, тако да овај приступ неће радити - апсолутно сви атрибути и индикатори морају бити повезани са једним специфичним сидром. Закључак из овога је једноставан - Свака чињеница такође треба своје сидро. За нешто од онога што смо навикли да доживљавамо као чињенице, ово може изгледати природно – на пример, чињеница куповине може се савршено свести на објекат „поруџбина“ или „признаница“, посета сајту на сесију итд. Али постоје и чињенице за које није тако лако пронаћи такав природни „предмет носиоца“ - на пример, остаци робе у складиштима на почетку сваког дана.

Сходно томе, проблеми са модуларношћу приликом проширења кључа чињеница у моделу сидра не настају (довољно је једноставно додати нову везу одговарајућем сидру), али је дизајнирање модела за приказ чињеница мање недвосмислено; могу се појавити „вештачка“ сидра који приказују модел пословног објекта на нејасан начин.

Како се постиже флексибилност

Добијена конструкција у оба случаја садржи знатно више столованего традиционално мерење. Али може потрајати знатно мање простора на диску са истим скупом верзионисаних атрибута као и традиционална димензија. Наравно, овде нема магије - све је у нормализацији. Дистрибуцијом атрибута преко сателита (у трезору података) или појединачних табела (сидрени модел), смањујемо (или потпуно елиминишемо) дуплирање вредности неких атрибута при промени других.

За Дата Ваулт добици ће зависити од расподеле атрибута међу Сателитима, и за Анцхор модел — је скоро директно пропорционална просечном броју верзија по објекту мерења.

Међутим, уштеда простора је важна, али не и главна предност одвојеног чувања атрибута. Заједно са одвојеним складиштењем односа, овај приступ чини продавницу модуларни дизајн. То значи да у таквом моделу изгледа додавање како појединачних атрибута тако и читавих нових предметних области надградња преко постојећег скупа објеката без њиховог мењања. И управо то чини описане методологије флексибилним.

Ово такође подсећа на прелазак са производње у комаду на масовну производњу - ако је у традиционалном приступу свака табела модела јединствена и захтева посебну пажњу, онда је у флексибилним методологијама то већ скуп стандардних „делова“. С једне стране, има више табела, а процеси учитавања и преузимања података би требало да изгледају компликованије. С друге стране, постају типично. Што значи да може бити аутоматизовани и вођени метаподацима. Питање "како ћемо то поставити?", чији одговор би могао да заузме значајан део посла на пројектовању побољшања, сада једноставно није вредно тога (као ни питање о утицају промене модела на радне процесе ).

То не значи да у таквом систему аналитичари уопште нису потребни – неко ипак мора да проради скуп објеката са атрибутима и смисли где и како све то учитати. Али количина посла, као и вероватноћа и цена грешке, значајно су смањени. Како у фази анализе, тако и током развоја ЕТЛ-а, који се у значајном делу може свести на уређивање метаподатака.

Тамна страна

Све наведено чини оба приступа заиста флексибилним, технолошки напредним и погодним за итеративно побољшање. Наравно, ту је и „буре у масти“, о чему мислим да већ можете да претпоставите.

Декомпозиција података, која лежи у основи модуларности флексибилних архитектура, доводи до повећања броја табела и, сходно томе, надземне да се споји приликом узорковања. Да би се једноставно добили сви атрибути димензије, у класичној продавници довољан је један избор, али флексибилна архитектура ће захтевати читав низ спојева. Штавише, ако се сви ови спојеви за извештаје могу написати унапред, онда ће аналитичари који су навикли да ручно пишу СКЛ двоструко патити.

Постоји неколико чињеница које олакшавају ову ситуацију:

Када се ради са великим димензијама, сви његови атрибути се скоро никада не користе истовремено. То значи да може бити мање спојева него што се чини на први поглед на модел. Трезор података такође може узети у обзир очекивану учесталост дељења када додељује атрибуте сателитима. У исто време, сами чворишта или сидри су потребни првенствено за генерисање и мапирање сурогата у фази учитавања и ретко се користе у упитима (ово посебно важи за сидра).

Сви спојеви су по кључу. Поред тога, „компримовани“ начин складиштења података смањује трошкове скенирања табела тамо где је то потребно (на пример, када се филтрира по вредности атрибута). Ово може довести до чињенице да ће узорковање из нормализоване базе података са гомилом спојева бити чак и брже од скенирања једне тешке димензије са много верзија по реду.

На пример, овде у ово Чланак садржи детаљан упоредни тест перформанси Анцхор модела са узорком из једне табеле.

Много зависи од мотора. Многе модерне платформе имају интерне механизме за оптимизацију придруживања. На пример, МС СКЛ и Орацле могу да „прескачу“ спајања на табеле ако се њихови подаци не користе нигде осим за друга спајања и не утичу на коначни избор (елиминација табеле/придруживања), а МПП Вертица искуство колега из Авита, се показао као одличан мотор за Анцхор модел, с обзиром на неку ручну оптимизацију плана упита. С друге стране, складиштење Анцхор модела, на пример, на Цлицк Хоусе, који има ограничену подршку за придруживање, још увек не изгледа као добра идеја.

Поред тога, за обе архитектуре постоје специјални потези, што олакшава приступ подацима (како са становишта перформанси упита тако и за крајње кориснике). На пример, Табела у времену у Трезору података или посебне функције табеле у моделу Сидро.

Укупно

Главна суштина разматраних флексибилних архитектура је модуларност њиховог „дизајна“.

Управо ово својство омогућава:

• Након неких почетних припрема везаних за примену метаподатака и писање основних ЕТЛ алгоритама, брзо обезбедити купцу први резултат у облику неколико извештаја који садрже податке из само неколико изворних објеката. Није потребно у потпуности промислити (чак и на највишем нивоу) цео модел објекта.
• Модел података може почети да ради (и бити користан) са само 2-3 објекта, а затим расте постепено (у вези са моделом Анцхор Николаи примењен лепо поређење са мицелијумом).
• Већина побољшања, укључујући проширење предметне области и додавање нових извора не утиче на постојећу функционалност и не представља ризик од квара нечега што већ ради.
• Захваљујући декомпозицији на стандардне елементе, ЕТЛ процеси у таквим системима изгледају исто, њихово писање је подложно алгоритмизацији и, на крају, аутоматизација.

Цена ове флексибилности је перформансе. То не значи да је немогуће постићи прихватљиве перформансе на таквим моделима. Чешће него не, можда ће вам једноставно требати више труда и пажње на детаље да бисте постигли жељене метрике.

Аппс

Типови ентитета Дата Ваулт

Више информација о трезору података:
Сајт Дана Листадта
Све о трезору података на руском
О трезору података на Хабреу

Типови ентитета Анцхор Модел

Више детаља о моделу сидра:

Сајт креатора модела Анцхор
Чланак о искуству имплементације Анцхор модела у Авиту

Збирна табела са заједничким карактеристикама и разликама разматраних приступа:

Извор: ввв.хабр.цом