Сақтау орнын дамыту ұзақ және маңызды міндет.
Жобаның өмірінде көп нәрсе бастапқыда нысан үлгісі мен базалық құрылымның қаншалықты жақсы ойластырылғанына байланысты.
Жалпы қабылданған тәсіл жұлдызды схеманы үшінші қалыпты формамен біріктірудің әртүрлі нұсқалары болды және болып қала береді. Әдетте, принцип бойынша: бастапқы деректер - 3NF, витриналар - жұлдыз. Уақытпен тексерілген және үлкен көлемдегі зерттеулермен расталған бұл тәсіл тәжірибелі DWH маманының аналитикалық репозиторийдің қандай болуы керектігі туралы ойлайтын бірінші (кейде жалғыз) нәрсе.
Екінші жағынан, жалпы бизнес және әсіресе тұтынушылардың талаптары тез өзгереді, ал деректер «тереңдікте» де, «кеңдікте» де өседі. Міне, жұлдыздың негізгі кемшілігі - шектеулі икемділік.
Егер сіздің тыныш және жайлы өміріңізде DWH әзірлеушісі ретінде кенеттен:
- тапсырма «кем дегенде бірдеңені тез істеу керек, содан кейін көреміз» деген тапсырма пайда болды;
- аптасына кемінде бір рет жаңа көздерді қосу және бизнес үлгісін қайта өңдеу арқылы қарқынды дамып келе жатқан жоба пайда болды;
- появился заказчик, который не представляет как система должна выглядеть и какие функции выполнять в конечном итоге, но готов к экспериментам и последовательному уточнению желаемого результата с последовательным же приближением к нему;
- Жоба менеджері жақсы жаңалықпен келді: «Ал енді бізде ептілік бар!»
Немесе сақтау қоймаларын тағы қалай салуға болатынын білгіңіз келсе - кесуге қош келдіңіз!
«Икемділік» нені білдіреді?
Алдымен «икемді» деп аталу үшін жүйенің қандай қасиеттері болуы керек екенін анықтайық.
Отдельно стоит оговориться, что описываемые свойства должны относиться именно к жүйе, емес процесс оның дамуы. Сондықтан, егер сіз даму әдістемесі ретінде Agile туралы оқығыңыз келсе, басқа мақалаларды оқығаныңыз жөн. Мысалы, дәл сол жерде, Хабреде көптеген қызықты материалдар бар (мысалы и , Сонымен ).
Бұл өңдеу процесі мен деректер қоймасының құрылымы бір-бірімен мүлдем байланысты емес дегенді білдірмейді. Тұтастай алғанда, Agile архитектурасы үшін Agile репозиторийін жасау оңайырақ болуы керек. Дегенмен, іс жүзінде Kimbal және DataVault бойынша классикалық DWH Agile әзірлеу нұсқалары жиі кездеседі - Сарқырама бойынша, оның бір жобадағы екі нысанындағы икемділіктің бақытты сәйкестігі.
Сонымен, икемді сақтаудың қандай мүмкіндіктері болуы керек? Мұнда үш нүкте бар:
- Ерте жеткізу және жылдам қайтару - бұл ең дұрысы бірінші іскерлік нәтижені (мысалы, бірінші жұмыс есептері) мүмкіндігінше ертерек, яғни бүкіл жүйе толығымен жобаланып, енгізілмей тұрып алу керек дегенді білдіреді. Сонымен қатар, әрбір келесі қайта қарау мүмкіндігінше аз уақыт алуы керек.
- Итеративті нақтылау — это значит, что каждая следующая доработка в идеале не должна затрагивать уже работающий функционал. Именно этот момент часто становится самым большим кошмаром на крупных проектах — рано или поздно отдельные объекты начинают обрастать таким количеством связей, что становится проще полностью повторить логику в копии рядом, чем добавить поле в существующую таблицу. И если вас удивляет, что анализ влияния доработки на существующие объекты может занимать больше времени, чем сама доработка — вы скорее всего ещё не работали с крупными ХД в банкинге или телекоме.
- Өзгеретін бизнес талаптарына үнемі бейімделу - объектінің жалпы құрылымы ықтимал кеңеюді ескере отырып емес, сонымен қатар келесі кеңейтудің бағытын жобалау кезеңінде тіпті армандауға болмайтынын күтумен жобалануы керек.
Иә, осы талаптардың барлығын бір жүйеде орындау мүмкін (әрине, белгілі бір жағдайларда және кейбір ескертпелермен).
Төменде мен деректер қоймалары үшін ең танымал екі икемді дизайн әдістемесін қарастырамын - Анкерлік модель и Деректер қоймасы. Жақшаның сыртында, мысалы, EAV, 6NF (таза түрінде) және NoSQL шешімдеріне қатысты барлық тамаша әдістер қалды - олар қандай да бір түрде нашар болғандықтан емес, тіпті бұл жағдайда мақала сатып алуға қауіп төндіретіндіктен де емес. орташа диссердің көлемі. Мұның бәрі сәл басқа сыныптың шешімдеріне қатысты - жобаңыздың жалпы архитектурасына қарамастан (мысалы, EAV) немесе басқа ақпаратты сақтау парадигмаларына (мысалы, графиктік дерекқорлар сияқты) нақты жағдайларда қолдануға болатын әдістерге қатысты. және басқа опциялар NoSQL).
Проблемы “классического” подхода и их решения в гибких методологиях
«Классикалық» тәсіл арқылы мен жақсы ескі жұлдызды айтамын (негізгі қабаттардың нақты орындалуына қарамастан, Кимбалл, Инмон және CDM ізбасарлары мені кешірсін).
1. Байланыстардың қатаң кардиналдығы
Бұл модель деректерді нақты бөлуге негізделген Өлшем и фактілер. Және бұл, қарғыс атқыр, қисынды - ақыр соңында, деректерді талдау жағдайлардың басым көпшілігінде белгілі бір бөлімдердегі (өлшемдердегі) белгілі бір сандық көрсеткіштерді (фактілерді) талдауға келеді.
Бұл жағдайда объектілер арасындағы байланыс сыртқы кілттің көмегімен кестелер арасындағы қатынастар түрінде орнатылады. Бұл өте табиғи көрінеді, бірақ бірден икемділіктің бірінші шектеуіне әкеледі - байланыстардың кардиналдығын қатаң анықтау.
Бұл кестені құрастыру сатысында байланысты нысандардың әрбір жұбы үшін олардың көпке-көпке немесе тек 1-көпке қатысты болуы мүмкін бе және «қай бағытта» дәл анықтау керек дегенді білдіреді. Бұл қай кестеде бастапқы кілт, қайсысында сыртқы кілт болатынын тікелей анықтайды. Жаңа талаптар қабылданған кезде бұл көзқарасты өзгерту, ең алдымен, базаны қайта өңдеуге әкеледі.
Мысалы, сату бөлімінің антына сүйене отырып, «кассалық чек» нысанын жобалау кезінде сіз әрекет ету мүмкіндігін белгіледіңіз. бірнеше тексеру орындарына бір көтерілу (бірақ керісінше емес):
Біраз уақыттан кейін әріптестер бір ұстанымда әрекет ете алатын жаңа маркетингтік стратегияны енгізді бір уақытта бірнеше жарнамалық акциялар. Ал енді қарым-қатынасты бөлек нысанға бөлу арқылы кестелерді өзгерту керек.
(Енді жылжыту тексеруі қосылған барлық туынды нысандарды да жақсарту қажет).
Деректер қоймасы мен якорь үлгісіндегі қатынастар
Бұл жағдайдан құтылу өте қарапайым болды: мұны істеу үшін сату бөліміне сенудің қажеті жоқ. барлық қосылымдар бастапқыда бөлек кестелерде сақталады и обрабатывать как многие-ко-многим.
Бұл тәсіл ұсынылды Дэн Линстедт парадигманың бөлігі ретінде Деректер қоймасы и полностью поддержан Ларс Рённбек в Анкерлік үлгі.
Нәтижесінде икемді әдістемелердің бірінші ерекшелігін аламыз:
Объектілер арасындағы қарым-қатынастар негізгі нысандардың атрибуттарында сақталмайды, бірақ объектінің жеке түрі болып табылады.
В Деректер қоймасы мұндай байланыстырушы кестелер деп аталады байланыс, ал Анкерлік үлгі - галстук. Бір қарағанда, олар өте ұқсас, бірақ олардың айырмашылықтары атаумен аяқталмайды (бұл туралы төменде талқыланады). Екі архитектурада да сілтеме кестелері байланыстыра алады нысандардың кез келген саны (міндетті түрде 2 емес).
Бұл артықшылық, бір қарағанда, өзгертулер үшін айтарлықтай икемділікті қамтамасыз етеді. Мұндай құрылым бар сілтемелердің түбегейлі өзгеруіне ғана емес, сонымен қатар жаңаларын қосуға төзімді болады - егер қазір чек позициясында оны ашқан кассирге сілтеме болса, мұндай сілтеменің пайда болуы жай болады. кез келген бар нысандар мен процестерге әсер етпей, бар кестелердің үстінен қосымша.
2. Мәліметтердің қайталануы
Икемді архитектуралармен шешілетін екінші мәселе онша айқын емес және бірінші кезекте тән. SCD2 типті өлшемдер (екінші типті өлшемдердің баяу өзгеретіні), бірақ олар ғана емес.
Классикалық қоймада өлшем әдетте суррогат кілтті (PK ретінде) және жеке бағандардағы іскери кілттер мен төлсипаттардың жиынын қамтитын кесте болып табылады.
Өлшем нұсқаларды қолдайтын болса, нұсқа жарамдылық шекаралары өрістердің стандартты жинағына қосылады және көздегі бір жол үшін репозиторийде бірнеше нұсқа пайда болады (нұсқалы төлсипаттардың әрбір өзгерісі үшін бір).
Өлшемде кем дегенде бір жиі өзгеретін нұсқа атрибуттары болса, мұндай өлшемнің нұсқаларының саны әсерлі болады (тіпті қалған төлсипаттар нұсқаланбаған болса немесе ешқашан өзгермейді) және осындай бірнеше төлсипат болса, нұсқалар саны олардың санынан экспоненциалды түрде өседі. Бұл өлшем дискілік кеңістіктің айтарлықтай көлемін алуы мүмкін, бірақ ол сақтайтын деректердің көп бөлігі басқа жолдардағы өзгермейтін төлсипат мәндерінің көшірмелері болып табылады.
Сонымен қатар, ол өте жиі қолданылады денормальизация — кейбір атрибуттар анықтамалық кітапқа немесе басқа өлшемге сілтеме ретінде емес, әдейі мән ретінде сақталады. Бұл тәсіл деректерге қол жеткізуді жылдамдатады, өлшемге қатынасу кезінде біріктірулер санын азайтады.
Әдетте бұл әкеледі бірдей ақпарат бір уақытта бірнеше жерде сақталады. Мысалы, тұрғылықты жері мен клиент санаты туралы ақпаратты бір уақытта «Клиент» өлшемдерінде және «Сатып алу», «Жеткізу» және «Байланыс орталығына қоңырау шалу» фактілерінде, сондай-ақ «Клиент – Клиент менеджері» бөлімінде сақтауға болады. ” сілтеме кестесі.
Тұтастай алғанда, жоғарыда сипатталған қалыпты (нұсқасыз) өлшемдерге қатысты, бірақ нұсқада олар басқа масштабта болуы мүмкін: объектінің жаңа нұсқасының пайда болуы (әсіресе ретроспективада) барлық байланысты жаңартуға ғана емес әкеледі. кестелер, бірақ байланысты объектілердің жаңа нұсқаларының каскадты көрінісіне - 1-кесте 2-кестені құру үшін, ал 2-кесте 3-кестені құру үшін пайдаланылғанда және т.б. 1-кестенің құрылысына 3-кестенің бірде-бір атрибуты қатыспаса да (және басқа көздерден алынған 2-кестенің басқа атрибуттары қатыстырылады), бұл құрылысты нұсқалау ең аз дегенде қосымша үстеме шығындарға, ал ең көбі қосымшаға әкеледі. 3-кестедегі нұсқалар. оның оған мүлдем қатысы жоқ және одан әрі тізбекте.
3. Қайта өңдеудің сызықты емес күрделілігі
Сонымен қатар, басқасының негізінде жасалған әрбір жаңа көрме стенді ETL-ге өзгертулер енгізілгенде деректердің «айырылуы» мүмкін орындардың санын көбейтеді. Бұл, өз кезегінде, әрбір келесі қайта қараудың күрделілігінің (және ұзақтығының) ұлғаюына әкеледі.
Егер жоғарыда сирек өзгертілген ETL процестері бар жүйелер сипатталса, сіз осындай парадигмада өмір сүре аласыз - барлық қатысты нысандарға жаңа модификациялардың дұрыс жасалғанына көз жеткізіңіз. Егер қайта қараулар жиі орын алса, бірнеше қосылымдардың кездейсоқ «жоғалу» ықтималдығы айтарлықтай артады.
Сонымен қатар, егер «нұсқаланған» ETL «нұсқасы жоққа» қарағанда айтарлықтай күрделірек екенін ескерсек, бұл бүкіл құралды жиі жаңарту кезінде қателерді болдырмау өте қиын болады.
Нысандар мен атрибуттарды Data Vault және Anchor үлгісінде сақтау
Икемді архитектураның авторлары ұсынған тәсілді келесідей тұжырымдауға болады:
Өзгерістер мен өзгеріссіз қалғандарын ажырату керек. Яғни, кілттерді атрибуттардан бөлек сақтаңыз.
Дегенмен, шатастырмау керек нұсқасы жоқ атрибутымен өзгеріссіз: біріншісі оның өзгерістерінің тарихын сақтамайды, бірақ өзгеруі мүмкін (мысалы, енгізу қатесін түзету немесе жаңа деректерді алу кезінде); екіншісі ешқашан өзгермейді.
Точки зрения на то, что именно можно считать неизменным в Data Vault и Якорной модели расходятся.
С точки зрения архитектуры Деректер қоймасы, өзгеріссіз деп санауға болады кілттердің бүкіл жиынтығы - табиғи (ұйымның СТН, бастапқы жүйедегі өнім коды және т.б.) және суррогат. Бұл жағдайда қалған атрибуттарды өзгерістердің қайнар көзіне және/немесе жиілігіне қарай топтарға бөлуге болады және Әр топқа жеке кесте жасаңыз нұсқалардың тәуелсіз жиынтығымен.
Парадигмада Anchor Model өзгеріссіз деп есептеледі тек суррогат кілт мәні. Барлық қалғандары (соның ішінде табиғи кілттер) оның атрибуттарының ерекше жағдайы ғана. Бола тұра барлық атрибуттар әдепкі бойынша бір-бірінен тәуелсіз, сондықтан әрбір атрибут үшін a бөлек үстел.
В Деректер қоймасы нысан кілттері бар кестелер шақырылады Хубами. Концентраторлар әрқашан өрістердің тұрақты жиынын қамтиды:
- Табиғи нысан кілттері
- Суррогат кілт
- Дереккөзге сілтеме
- Қосу уақытын жазу
Хабтардағы жазбалар ешқашан өзгермейді және нұсқалары болмайды. Сырттай хабтар суррогаттарды жасау үшін кейбір жүйелерде пайдаланылатын ID-карта түріндегі кестелерге өте ұқсас, дегенмен, Data Vault ішінде суррогат ретінде бизнес кілттер жинағынан хэшті пайдалану ұсынылады. Бұл тәсіл көздерден жүктеу қатынастары мен атрибуттарын жеңілдетеді (суррогат алу үшін хабқа қосылудың қажеті жоқ, жай ғана табиғи кілттің хэшін есептеңіз), бірақ басқа проблемаларды тудыруы мүмкін (мысалы, соқтығысуға, регистрге және басып шығаруға болмайтынға қатысты) жол пернелеріндегі таңбалар және т.б. .p.), сондықтан ол жалпы қабылданбайды.
Барлық басқа нысан атрибуттары деп аталатын арнайы кестелерде сақталады Спутниктер. Бір хабта әртүрлі атрибуттар жиынын сақтайтын бірнеше жерсерік болуы мүмкін.
Жерсеріктер арасында атрибуттарды бөлу принцип бойынша жүреді бірлескен өзгеріс — бір спутникте нұсқасы жоқ атрибуттарды сақтауға болады (мысалы, жеке тұлғаның туған күні және SNILS), екіншісінде - сирек өзгеретін нұсқалар (мысалы, тегі мен төлқұжат нөмірі), үшіншісінде - жиі өзгеретіндер (мысалы, жеткізу мекенжайы, санат, соңғы тапсырыс күні және т.б.). Бұл жағдайда нұсқалау тұтастай нысан емес, жеке жерсеріктер деңгейінде жүзеге асырылады, сондықтан атрибуттарды бір жерсерік ішіндегі нұсқалардың қиылысуы минималды болатындай етіп таратқан жөн (бұл сақталған нұсқалардың жалпы санын азайтады) ).
Сондай-ақ, деректерді жүктеу процесін оңтайландыру үшін әртүрлі көздерден алынған атрибуттар жиі жеке жерсеріктерге енгізіледі.
Жерсеріктер хаб арқылы байланысады шетелдік кілт (бұл 1-ден көпке дейінгі кардиналдыққа сәйкес келеді). Бұл бірнеше атрибут мәндеріне (мысалы, бір клиентке арналған бірнеше байланыс телефон нөмірлері) осы «әдепкі» архитектура қолдау көрсететінін білдіреді.
В Анкерлік үлгі кілттерді сақтайтын кестелер деп аталады Якорями (Anchor). Және олар сақтайды:
- Тек суррогат кілттер
- Дереккөзге сілтеме
- Қосу уақытын жазу
Анкерлік модель тұрғысынан табиғи кілттер қарастырылады кәдімгі атрибуттар. Такой вариант может показаться более сложным для понимания, но он дает намного больше простора для идентификации объекта.
Мысалы, егер бір нысан туралы деректер әрқайсысы өзінің табиғи кілтін пайдаланатын әртүрлі жүйелерден алынса. Деректер қоймасында бұл бірнеше хабтардың (әр көзге біреу + біріктіретін негізгі нұсқа) айтарлықтай қиын құрылымдарына әкелуі мүмкін, ал Anchor үлгісінде әрбір көздің табиғи кілті өз төлсипатына түседі және оны тәуелсіз жүктеген кезде пайдалануға болады. басқалардың барлығы.
Бірақ бұл жерде бір жасырын мәселе бар: егер әртүрлі жүйелердің атрибуттары бір нысанда біріктірілсе, олардың кейбіреулері болуы мүмкін. «жабыстыру» ережелері, ол арқылы жүйе әртүрлі көздерден алынған жазбалар нысанның бір данасына сәйкес келетінін түсінуі керек.
В Деректер қоймасы бұл ережелер, ең алдымен, қалыптастыруды анықтайды басты нысанның "суррогат хабы" и никак не влиять на Хабы, хранящие натуральные ключи источников и их исходные атрибуты. Если в какой-то момент правила склейки поменяются (или придет обновление атрибутов, по которым она производится), достаточно будет переформировать суррогатные хабы.
В Анкерлік модель мұндай нысан сақталады жалғыз якорь. Бұл дегеніміз, барлық атрибуттар қай көзден алынса да, бір суррогатқа байланысты болады. Қате біріктірілген жазбаларды бөлу және тұтастай алғанда, мұндай жүйеде біріктірудің өзектілігін бақылау әлдеқайда қиын болуы мүмкін, әсіресе ережелер өте күрделі және жиі өзгеретін болса және бірдей атрибутты әртүрлі көздерден алуға болатын болса (бірақ ол әрине мүмкін, себебі әрбір төлсипат нұсқасы өз көзіне сілтемені сақтайды).
Кез келген жағдайда, егер сіздің жүйеңіз функционалдылықты жүзеге асыруы керек болса қайталау, жазбаларды біріктіру және басқа MDM элементтері, Agile әдістемелерінде табиғи кілттерді сақтау аспектілеріне ерекше назар аударған жөн. Көлемді Data Vault дизайны біріктіру қателері тұрғысынан кенеттен қауіпсіз болуы мүмкін.
Анкерлік модель деп аталатын қосымша нысан түрін де қамтамасыз етеді Түйін бұл негізінен ерекше зәкірдің бұзылған түрі, онда тек бір атрибут болуы мүмкін. Түйіндер жалпақ анықтамалықтарды (мысалы, жынысы, отбасылық жағдайы, тұтынушыларға қызмет көрсету санаты және т.б.) сақтау үшін пайдаланылуы керек. Зәкірден айырмашылығы, түйін байланысты атрибут кестелері жоқ, және оның жалғыз атрибуты (аты) әрқашан кілтпен бір кестеде сақталады. Түйіндер якорьге бір-бірімен байланыстырылғандай, байлау кестелері (Галстук) арқылы қосылады.
Түйіндерді пайдалану туралы нақты пікір жоқ. Мысалы, Ресейде якорь үлгісін қолдануды белсенді түрде насихаттайтын , (негізсіз емес) бірде-бір анықтамалық үшін оны сенімді түрде айтуға болады деп санайды. әрқашан будет статическим и одноуровневым, поэтому для всех объектов лучше сразу использовать полноценный Якорь.
Data Vault және Anchor үлгісі арасындағы тағы бір маңызды айырмашылық қол жетімділік болып табылады байланыстардың атрибуттары:
В Деректер қоймасы Сілтемелер хабтар сияқты толыққанды нысандар болып табылады және болуы мүмкін өзіндік атрибуттары. The Анкерлік модель Сілтемелер тек якорьді қосу үшін пайдаланылады және өз атрибуттары бола алмайды. Бұл айырмашылық айтарлықтай әртүрлі модельдеу тәсілдеріне әкеледі фактілер, ол әрі қарай талқыланады.
Факті сақтау
Бұған дейін біз негізінен өлшемді модельдеу туралы айттық. Фактілер біршама анық емес.
В Деректер қоймасы фактілерді сақтауға арналған типтік объект болып табылады Сілтеме, олардың спутниктеріне нақты көрсеткіштер қосылады.
Бұл тәсіл интуитивті болып көрінеді. Ол талданатын көрсеткіштерге оңай қол жеткізуді қамтамасыз етеді және әдетте дәстүрлі фактілер кестесіне ұқсас (тек көрсеткіштер кестенің өзінде емес, «көршілес» кестеде сақталады). Бірақ қателіктер де бар: модельдің типтік модификацияларының бірі - факт кілтін кеңейту - қажет етеді добавления в Link нового внешнего ключа. Және бұл, өз кезегінде, модульді «бұзады» және басқа нысандарға өзгертулер енгізу қажеттілігін тудыруы мүмкін.
В Анкерлік модель Қосылымның өз атрибуттары болуы мүмкін емес, сондықтан бұл тәсіл жұмыс істемейді - мүлдем барлық атрибуттар мен көрсеткіштер бір нақты якорьмен байланыстырылуы керек. Бұдан шығатын қорытынды қарапайым - для каждого факта тоже нужен свой якорь. Біз фактілер ретінде қабылдауға үйренген кейбір нәрселер үшін бұл табиғи болып көрінуі мүмкін - мысалы, сатып алу фактісін «тапсырыс» немесе «түбіртек» нысанына толығымен азайтуға болады, сайтқа сеансқа бару және т.б. Бірақ мұндай табиғи «тасымалдаушы нысанды» табу оңай емес фактілер де бар - мысалы, әр күннің басында қоймалардағы тауарлардың қалдықтары.
Тиісінше, Anchor үлгісіндегі факті кілтін кеңейту кезінде модульдік проблемалар туындамайды (тиісті якорьге жай ғана жаңа қатынасты қосу жеткілікті), бірақ фактілерді көрсету үшін модельді жобалау бір мәнді емес; «жасанды» якорьдер пайда болуы мүмкін. бизнес нысан үлгісін түсініксіз түрде көрсетеді.
Икемділікке қалай қол жеткізіледі
Алынған құрылыс екі жағдайда да қамтиды кестелер айтарлықтай көпдәстүрлі өлшеуге қарағанда. Бірақ алуы мүмкін существенно меньше дискового пространства дәстүрлі өлшем сияқты нұсқаланған төлсипаттардың бірдей жинағымен. Әрине, мұнда ешқандай сиқыр жоқ - бәрі қалыпқа келтіру туралы. Атрибуттарды жерсеріктерге (деректер қоймасында) немесе жеке кестелерге (зәкір үлгісі) тарату арқылы біз азайтамыз (немесе толығымен жоямыз) басқаларын өзгерту кезінде кейбір атрибуттардың мәндерінің қайталануы.
үшін Деректер қоймасы ұтыстар Жерсеріктер арасындағы атрибуттардың таралуына байланысты болады және Анкерлік модель — өлшем объектісіне шаққандағы нұсқалардың орташа санына дерлік тура пропорционал.
Дегенмен, кеңістікті үнемдеу атрибуттарды бөлек сақтаудың маңызды, бірақ басты артықшылығы болып табылады. Қатынастарды бөлек сақтаумен бірге бұл тәсіл дүкенді жасайды модульдік дизайн. Бұл мұндай модельге жеке атрибуттарды да, толық жаңа тақырыптық аймақтарды қосу сияқты көрінетінін білдіреді жоғарғы құрылысы нысандардың бар жиыны бойынша оларды өзгертпей. Міне, дәл осы сипатталған әдістемелерді икемді етеді.
Бұл сонымен қатар бөлшектік өндірістен жаппай өндіріске көшуді еске салады - егер дәстүрлі тәсілде модельдің әрбір кестесі бірегей болса және ерекше назар аударуды қажет етсе, икемді әдістемелерде бұл стандартты «бөлшектердің» жиынтығы болып табылады. Бір жағынан, кестелер көбірек, ал деректерді жүктеу және алу процестері күрделірек көрінуі керек. Екінші жағынан, олар айналады тән. А значит, могут быть автоматизированы и управляться метаданными. Жақсартуларды жобалау бойынша жұмыстың едәуір бөлігін алатын «біз оны қалай саламыз?» Деген сұраққа жауап беруге тұрарлық емес (сонымен қатар модельді өзгертудің жұмыс процестеріне әсері туралы сұрақ). ).
Это не значит, что аналитики в такой системе совсем не нужны — кто-то все еще должен проработать набор объектов с атрибутами и разобраться откуда и как всё это загружать. Но объем работ, а также вероятность и цена ошибки существенно снижаются. Как на этапе анализа, так и при разработке ETL, которая в существенной части может свестись к редактированию метаданных.
Қараңғы жағы
Жоғарыда айтылғандардың барлығы екі тәсілді де шын мәнінде икемді, технологиялық жағынан жетілдірілген және қайталанатын жақсартуға қолайлы етеді. Әрине, «жақпадағы бөшке» де бар, оны сіз қазірдің өзінде болжауға болады деп ойлаймын.
Икемді архитектуралардың модульділігі негізінде жатқан мәліметтердің декомпозициясы кестелер санының ұлғаюына әкеледі және сәйкесінше, үстеме сынама алу кезінде біріктіру. Өлшемнің барлық атрибуттарын жай ғана алу үшін классикалық дүкенде бір таңдау жеткілікті, бірақ икемді архитектура біріктірулердің тұтас сериясын қажет етеді. Оның үстіне есептер үшін осы біріктірулердің барлығын алдын ала жазуға болатын болса, SQL-ді қолмен жазуға дағдыланған аналитиктер екі есе зардап шегеді.
Бұл жағдайды жеңілдететін бірнеше фактілер бар:
Үлкен өлшемдермен жұмыс істегенде оның барлық атрибуттары бір уақытта дерлік пайдаланылмайды. Бұл модельге бірінші көзқараспен қарағанда, біріктірулер аз болуы мүмкін дегенді білдіреді. Деректер қоймасы атрибуттарды жерсеріктерге бөлу кезінде ортақ пайдаланудың күтілетін жиілігін де ескеруі мүмкін. Сонымен қатар, хабтардың немесе якорлардың өздері, ең алдымен, жүктеу сатысында суррогаттарды жасау және салыстыру үшін қажет және сұрауларда сирек қолданылады (бұл әсіресе Анкерлерге қатысты).
Барлық қосылыстар кілт арқылы жүзеге асырылады. Бұған қоса, деректерді сақтаудың анағұрлым «қысылған» тәсілі қажет жерде (мысалы, төлсипат мәні бойынша сүзгілеу кезінде) сканерлеу кестелерінің үстеме шығынын азайтады. Бұл бір жолға көптеген нұсқалары бар бір ауыр өлшемді сканерлеуге қарағанда, біріктірулер тобымен қалыпқа келтірілген дерекқордан іріктеу жылдамырақ болатынына әкелуі мүмкін.
Мысалы, мұнда Мақалада бір кестеден алынған үлгімен Anchor моделінің өнімділігінің егжей-тегжейлі салыстырмалы сынағы бар.
Көп нәрсе қозғалтқышқа байланысты. Көптеген заманауи платформаларда біріктіруді оңтайландырудың ішкі механизмдері бар. Мысалы, MS SQL және Oracle кестелерге қосылуларды «өткізіп» алады, егер олардың деректері басқа біріктірулерден басқа еш жерде пайдаланылмаса және соңғы таңдауға әсер етпесе (кесте/біріктіруді жою) және MPP Vertica , сұрау жоспарын қолмен оңтайландыруды ескере отырып, якорь үлгісі үшін тамаша қозғалтқыш екенін дәлелдеді. Екінші жағынан, Anchor үлгісін, мысалы, шектеулі қосылу қолдауы бар Click House жүйесінде сақтау әлі өте жақсы идея болып көрінбейді.
Сонымен қатар, екі сәулет үшін де бар ерекше қимылдар, деректерге қол жеткізуді жеңілдету (сұрау өнімділігі тұрғысынан да, соңғы пайдаланушылар үшін де). Мысалы, Уақыт бойынша кестелер Деректер қоймасында немесе арнайы кесте функциялары Anchor үлгісінде.
Барлығы
Қарастырылып отырған икемді архитектуралардың негізгі мәні олардың «дизайнының» модульділігі болып табылады.
Бұл мүмкіндік береді:
- Метадеректерді орналастыруға және негізгі ETL алгоритмдерін жазуға байланысты бастапқы дайындықтан кейін, Тұтынушыға бірінші нәтижені жылдам қамтамасыз ету бірнеше бастапқы нысандардан алынған деректерді қамтитын бірнеше есеп түрінде. Бүкіл нысан моделін толығымен (тіпті жоғарғы деңгейде) ойластыру қажет емес.
- Деректер үлгісі бар болғаны 2-3 нысанмен жұмыс істей бастайды (және пайдалы болуы мүмкін), содан кейін біртіндеп өседі (Николайдың якорь үлгісіне қатысты мицелиямен жақсы салыстыру).
- Көптеген жақсартулар, соның ішінде тақырып аймағын кеңейту және жаңа көздерді қосу бар функционалдылыққа әсер етпейді және қазірдің өзінде жұмыс істеп тұрған нәрсені бұзу қаупін тудырмайды.
- Стандартты элементтерге ыдырау арқасында мұндай жүйелердегі ETL процестері бірдей көрінеді, олардың жазылуы алгоритмдеуге мүмкіндік береді және, сайып келгенде, автоматтандыру.
Бұл икемділіктің бағасы Өнімділік. Бұл мұндай үлгілерде қолайлы өнімділікке қол жеткізу мүмкін емес дегенді білдірмейді. Көбінесе қалаған көрсеткіштерге қол жеткізу үшін сізге көбірек күш пен егжей-тегжейлі назар аудару қажет болуы мүмкін.
бағдарламалар
Нысан түрлері Деректер қоймасы
Data Vault туралы қосымша ақпарат:
Нысан түрлері Anchor Model
Подробнее про Anchor Model:
Қарастырылған тәсілдердің ортақ белгілері мен айырмашылықтары бар жиынтық кесте:
Ақпарат көзі: www.habr.com