Saqlash omborini qurish uzoq va jiddiy ishdir.
Loyihaning hayotida ko'p narsa ob'ekt modeli va asosiy tuzilmaning boshida qanchalik yaxshi o'ylanganiga bog'liq.
Umumiy qabul qilingan yondashuv yulduz sxemasini uchinchi normal shakl bilan birlashtirishning turli xil variantlari bo'lib kelgan va shunday bo'lib qoladi. Qoida tariqasida, printsipga ko'ra: dastlabki ma'lumotlar - 3NF, vitrinalar - yulduz. Vaqt sinovidan o'tgan va katta miqdordagi tadqiqotlar tomonidan qo'llab-quvvatlangan ushbu yondashuv DWH bo'yicha tajribali mutaxassisning analitik ombor qanday bo'lishi kerakligi haqida o'ylayotganda xayoliga keladigan birinchi (va ba'zan yagona) narsadir.
Boshqa tomondan, umuman biznes va ayniqsa mijozlar talablari tez o'zgarib turadi va ma'lumotlar "chuqurlikda" ham, "kenglikda" ham o'sadi. Va bu erda yulduzning asosiy kamchiligi paydo bo'ladi - cheklangan moslashuvchanlik.
Agar DWH ishlab chiqaruvchisi sifatida tinch va qulay hayotingizda to'satdan:
- vazifa paydo bo'ldi "hech bo'lmaganda tezda biror narsa qilish, keyin ko'ramiz";
- haftada kamida bir marta yangi manbalarni ulash va biznes modelini qayta ishlash bilan tez rivojlanayotgan loyiha paydo bo'ldi;
- tizim qanday ko'rinishga ega bo'lishi va u oxir-oqibat qanday funktsiyalarni bajarishi kerakligini bilmaydigan, lekin tajriba o'tkazishga va doimiy ravishda unga yaqinlashib, kerakli natijani doimiy ravishda yaxshilashga tayyor mijoz paydo bo'ldi;
- Loyiha menejeri xushxabar bilan keldi: "Va endi bizda tezkorlik bor!"
Yoki agar siz yana qanday qilib saqlash joylarini qurishingiz mumkinligini bilmoqchi bo'lsangiz - kesishga xush kelibsiz!
"Moslashuvchanlik" nimani anglatadi?
Birinchidan, "moslashuvchan" deb nomlanish uchun tizim qanday xususiyatlarga ega bo'lishi kerakligini aniqlaymiz.
Alohida ta'kidlab o'tish joizki, tavsiflangan xususiyatlar maxsus tegishli bo'lishi kerak tizim, emas jarayon uning rivojlanishi. Shuning uchun, agar siz rivojlanish metodologiyasi sifatida Agile haqida o'qishni istasangiz, boshqa maqolalarni o'qib chiqishingiz yaxshiroqdir. Masalan, Habré-da juda ko'p qiziqarli materiallar mavjud (masalan и , va ).
Bu ishlab chiqish jarayoni va ma'lumotlar omborining tuzilishi mutlaqo bog'liq emas degani emas. Umuman olganda, Agile arxitekturasi uchun Agile omborini ishlab chiqish ancha oson bo'lishi kerak. Biroq, amalda, Kimbal va DataVault-ga ko'ra klassik DWH-ni Agile ishlab chiqish variantlari ko'pincha mavjud - Sharsharaga ko'ra, bitta loyihada uning ikki shaklidagi moslashuvchanlikning baxtli tasodiflaridan ko'ra.
Xo'sh, moslashuvchan saqlash qanday imkoniyatlarga ega bo'lishi kerak? Bu erda uchta nuqta bor:
- Erta yetkazib berish va tez qaytarish - bu ideal holda birinchi biznes natijasi (masalan, birinchi ishchi hisobotlar) imkon qadar tezroq, ya'ni butun tizim to'liq ishlab chiqilishi va amalga oshirilishidan oldin olinishi kerakligini anglatadi. Bundan tashqari, har bir keyingi qayta ko'rib chiqish imkon qadar kamroq vaqt talab qilishi kerak.
- Takroriy takomillashtirish - bu shuni anglatadiki, har bir keyingi yaxshilanish allaqachon ishlayotgan funksionallikka ta'sir qilmasligi kerak. Aynan shu lahza ko'pincha yirik loyihalarda eng katta dahshatga aylanadi - ertami-kechmi, alohida ob'ektlar shu qadar ko'p ulanishlarga ega bo'lishni boshlaydilarki, mavjud jadvalga maydon qo'shishdan ko'ra yaqin atrofdagi nusxada mantiqni to'liq takrorlash osonroq bo'ladi. Va agar siz yaxshilanishlarning mavjud ob'ektlarga ta'sirini tahlil qilish yaxshilanishlardan ko'ra ko'proq vaqt talab qilishi mumkinligiga hayron bo'lsangiz, siz hali bank yoki telekommunikatsiya sohasida katta ma'lumotlar omborlari bilan ishlamagan bo'lishingiz mumkin.
- Doimiy ravishda o'zgaruvchan biznes talablariga moslashish - ob'ektning umumiy tuzilishi nafaqat mumkin bo'lgan kengayishni hisobga olgan holda, balki ushbu keyingi kengayish yo'nalishini dizayn bosqichida hatto orzu ham qila olmasligini kutish bilan ishlab chiqilishi kerak.
Va ha, bu talablarning barchasini bitta tizimda qondirish mumkin (albatta, ba'zi hollarda va ba'zi shartlar bilan).
Quyida men ma'lumotlar omborlari uchun eng mashhur ikkita tezkor dizayn metodologiyasini ko'rib chiqaman - Ankraj modeli и Ma'lumotlar ombori. Qavslar tashqarisida, masalan, EAV, 6NF (sof shaklda) va NoSQL yechimlari bilan bog'liq bo'lgan barcha ajoyib texnikalar qoldirilgan - ular qandaydir yomonroq bo'lgani uchun emas va hatto bu holda maqola sotib olish bilan tahdid qilgani uchun emas. o'rtacha disserning hajmi. Shunchaki, bularning barchasi bir oz boshqacha toifadagi echimlarga tegishli - yoki loyihangizning umumiy arxitekturasidan qat'i nazar (masalan, EAV) yoki boshqa global ma'lumotlarni saqlash paradigmalariga (masalan, grafik ma'lumotlar bazalari) muayyan holatlarda foydalanishingiz mumkin bo'lgan usullarga tegishli. va boshqa NoSQL variantlari).
“Klassik” yondashuv muammolari va ularning moslashuvchan metodologiyalarda yechimlari
"Klassik" yondashuv bilan men yaxshi eski yulduzni nazarda tutyapman (asosiy qatlamlarning o'ziga xos tarzda amalga oshirilishidan qat'i nazar, Kimball, Inmon va CDM izdoshlari meni kechirsin).
1. Bog'lanishlarning qattiq kardinalligi
Ushbu model ma'lumotlarni aniq taqsimlashga asoslangan Hajmi и faktlar. Va bu, la'nat, mantiqiy - axir, aksariyat hollarda ma'lumotlarni tahlil qilish ma'lum bo'limlarda (o'lchovlarda) ma'lum raqamli ko'rsatkichlarni (faktlarni) tahlil qilishdan iborat.
Bunday holda, ob'ektlar orasidagi bog'lanishlar tashqi kalit yordamida jadvallar orasidagi munosabatlar shaklida o'rnatiladi. Bu juda tabiiy ko'rinadi, lekin darhol moslashuvchanlikning birinchi cheklanishiga olib keladi - ulanishlarning kardinalligini qat'iy belgilash.
Bu shuni anglatadiki, jadvalni loyihalash bosqichida siz har bir o'zaro bog'liq ob'ekt juftligi uchun ular ko'pdan ko'pga yoki faqat 1dan ko'pga va "qaysi yo'nalishda" bog'lanishi mumkinligini aniq aniqlashingiz kerak. Bu to'g'ridan-to'g'ri qaysi jadvalda birlamchi kalitga va qaysi chet el kalitiga ega bo'lishini aniqlaydi. Yangi talablar qabul qilinganda bu munosabatni o'zgartirish, ehtimol, bazani qayta ishlashga olib keladi.
Masalan, "naqd pul tushumi" ob'ektini loyihalashda siz savdo bo'limining qasamyodlariga tayanib, harakat qilish imkoniyatini belgilab qo'ydingiz. bir nechta tekshirish lavozimlari uchun bitta ko'tarilish (lekin aksincha emas):
Va bir muncha vaqt o'tgach, hamkasblar bir xil pozitsiyada harakat qilishlari mumkin bo'lgan yangi marketing strategiyasini joriy qilishdi bir vaqtning o'zida bir nechta reklama aktsiyalari. Va endi siz munosabatlarni alohida ob'ektga ajratib, jadvallarni o'zgartirishingiz kerak.
(Endi reklama tekshiruvi qo'shilgan barcha olingan ob'ektlar ham yaxshilanishi kerak).
Ma'lumotlar ombori va anchor modelidagi munosabatlar
Bunday vaziyatdan qochish juda oddiy bo'lib chiqdi: buni amalga oshirish uchun savdo bo'limiga ishonishingiz shart emas. barcha ulanishlar dastlab alohida jadvallarda saqlanadi va uni ko'pdan ko'pga qadar qayta ishlang.
Bunday yondashuv taklif qilindi Dan Linstedt paradigmaning bir qismi sifatida Ma'lumotlar ombori va to'liq qo'llab-quvvatlanadi Lars Rönnbek в Anchor modeli.
Natijada, biz moslashuvchan metodologiyaning birinchi o'ziga xos xususiyatini olamiz:
Ob'ektlar o'rtasidagi munosabatlar asosiy ob'ektlarning atributlarida saqlanmaydi, lekin ob'ektning alohida turidir.
В Ma'lumotlar ombori bunday bog'lovchi jadvallar deyiladi aloqavaqt ichida Anchor modeli - Tie. Bir qarashda, ular juda o'xshash, garchi ularning farqlari nom bilan tugamasa ham (bu haqda quyida muhokama qilinadi). Ikkala arxitekturada ham havola jadvallari bog'lanishi mumkin har qanday miqdordagi ob'ektlar (2 bo'lishi shart emas).
Bu ortiqchalik, birinchi qarashda, o'zgartirishlar uchun sezilarli moslashuvchanlikni ta'minlaydi. Bunday tuzilma nafaqat mavjud bo'g'inlarning tubdan o'zgarishiga, balki yangilarini qo'shishga ham bardoshli bo'ladi - agar hozir chek pozitsiyasi uni buzgan kassir bilan bog'liq bo'lsa, bunday havolaning paydo bo'lishi shunchaki bo'ladi. Mavjud ob'ektlar va jarayonlarga ta'sir qilmasdan, mavjud jadvallar ustiga qo'shimcha bo'ling.
2. Ma'lumotlarni takrorlash
Moslashuvchan arxitekturalar tomonidan hal qilingan ikkinchi muammo unchalik aniq emas va birinchi navbatda o'ziga xosdir. SCD2 tipidagi o'lchovlar (ikkinchi turdagi o'lchamlarni asta-sekin o'zgartirish), garchi ular nafaqat.
Klassik omborda o'lchov odatda surrogat kalit (PK sifatida) va alohida ustunlardagi biznes kalitlari va atributlari to'plamini o'z ichiga olgan jadvaldir.
Agar o'lchov versiyalashni qo'llab-quvvatlasa, versiyaning amal qilish chegaralari standart maydonlar to'plamiga qo'shiladi va manbadagi bir qator uchun omborda bir nechta versiyalar paydo bo'ladi (versiyalangan atributlardagi har bir o'zgarish uchun bittadan).
Agar o'lchov kamida bitta tez-tez o'zgarib turadigan versiyali atributni o'z ichiga olsa, bunday o'lchamning versiyalari soni ta'sirchan bo'ladi (qolgan atributlar versiyalanmagan yoki hech qachon o'zgarmasa ham) va agar bir nechta bunday atributlar mavjud bo'lsa, versiyalar soni ularning sonidan eksponent ravishda o'sadi. Ushbu o'lcham katta hajmdagi disk maydonini egallashi mumkin, garchi u saqlaydigan ma'lumotlarning aksariyati boshqa satrlardagi o'zgarmas atribut qiymatlarining nusxalari bo'lsa ham.
Shu bilan birga, u ham juda tez-tez ishlatiladi denormalizatsiya — baʼzi atributlar ataylab maʼlumotnoma yoki boshqa oʻlchamga havola sifatida emas, balki qiymat sifatida saqlanadi. Ushbu yondashuv ma'lumotlarga kirishni tezlashtiradi, o'lchamga kirishda birlashmalar sonini kamaytiradi.
Odatda bu olib keladi bir xil ma'lumotlar bir vaqtning o'zida bir nechta joyda saqlanadi. Masalan, yashash hududi va mijozning toifasi haqidagi ma'lumotlar bir vaqtning o'zida "Mijoz" o'lchamlari va "Xarid", "Etkazib berish" va "Call-markazga qo'ng'iroqlar" faktlarida, shuningdek, "Mijoz - Mijoz menejeri" da saqlanishi mumkin. ” havola jadvali.
Umuman olganda, yuqorida tavsiflanganlar oddiy (versiyasiz) o'lchamlarga tegishli, ammo versiyalarida ular boshqacha miqyosga ega bo'lishi mumkin: ob'ektning yangi versiyasining paydo bo'lishi (ayniqsa, retrospektsiyada) nafaqat barcha tegishli o'lchamlarning yangilanishiga olib keladi. jadvallar, lekin tegishli ob'ektlarning yangi versiyalarining kaskadli ko'rinishiga - 1-jadvalni qurish uchun 2-jadvaldan foydalanilganda va 2-jadvalni qurish uchun 3-jadvaldan foydalanilganda va hokazo. 1-jadvalni qurishda 3-jadvalning birorta ham atributi ishtirok etmagan bo'lsa ham (va boshqa manbalardan olingan 2-jadvalning boshqa atributlari ishtirok etsa ham), ushbu qurilishni versiyalash kamida qo'shimcha xarajatlarga olib keladi va maksimal darajada qo'shimcha xarajatlarga olib keladi. 3-jadvaldagi versiyalar, bu bilan umuman aloqasi yo'q va undan keyin zanjir.
3. Qayta ishlashning nochiziqli murakkabligi
Shu bilan birga, boshqasi asosida qurilgan har bir yangi vitrina ETLga o'zgartirishlar kiritilganda ma'lumotlar "ajralishi" mumkin bo'lgan joylar sonini oshiradi. Bu, o'z navbatida, har bir keyingi qayta ko'rib chiqishning murakkabligi (va davomiyligi) oshishiga olib keladi.
Agar yuqorida kamdan-kam o'zgartirilgan ETL jarayonlari bo'lgan tizimlar tavsiflangan bo'lsa, siz bunday paradigmada yashashingiz mumkin - faqat barcha tegishli ob'ektlarga yangi o'zgartirishlar to'g'ri kiritilganligiga ishonch hosil qilishingiz kerak. Agar qayta ko'rib chiqishlar tez-tez sodir bo'lsa, tasodifan bir nechta ulanishlarni "yo'qotib qo'yish" ehtimoli sezilarli darajada oshadi.
Bundan tashqari, agar "versiyalangan" ETL "versiyasiz" ga qaraganda ancha murakkab ekanligini hisobga olsak, ushbu qurilmani tez-tez yangilashda xatolarga yo'l qo'ymaslik juda qiyin bo'ladi.
Ob'ektlar va atributlarni Data Vault va Anchor Modelida saqlash
Moslashuvchan arxitektura mualliflari tomonidan taklif qilingan yondashuvni quyidagicha shakllantirish mumkin:
Qaysi o'zgarishlar bir xil bo'lib qolganini ajratish kerak. Ya'ni, kalitlarni atributlardan alohida saqlang.
Biroq, chalkashmaslik kerak versiyalanmagan bilan atribut o'zgarmagan: birinchisi uning o'zgarishlar tarixini saqlamaydi, lekin o'zgarishi mumkin (masalan, kiritish xatosini tuzatishda yoki yangi ma'lumotlarni olishda); ikkinchisi hech qachon o'zgarmaydi.
Ma'lumotlar ombori va Anchor modelida aynan nimani o'zgarmas deb hisoblash mumkinligi borasida nuqtai nazarlar farq qiladi.
Arxitektura nuqtai nazaridan Ma'lumotlar ombori, o'zgarmagan deb hisoblash mumkin kalitlarning butun to'plami - tabiiy (tashkilotning TIN, manba tizimidagi mahsulot kodi va boshqalar) va surrogat. Bunday holda, qolgan atributlarni manba va/yoki o'zgarishlar chastotasiga ko'ra guruhlarga bo'lish mumkin va Har bir guruh uchun alohida jadval tuzing mustaqil versiyalar to'plami bilan.
Paradigmada Anchor modeli o‘zgarmagan deb hisoblanadi faqat surrogat kalit mohiyati. Qolgan hamma narsa (shu jumladan tabiiy kalitlar) uning atributlarining alohida holatidir. Qayerda barcha atributlar sukut bo'yicha bir-biridan mustaqildir, shuning uchun har bir atribut uchun a alohida stol.
В Ma'lumotlar ombori ob'ekt kalitlarini o'z ichiga olgan jadvallar chaqiriladi Hubami. Hublar har doim belgilangan maydonlar to'plamini o'z ichiga oladi:
- Tabiiy ob'ekt kalitlari
- Surrogat kalit
- Manbaga havola
- Qo'shish vaqtini yozib oling
Hublardagi postlar hech qachon o'zgarmaydi va versiyalari yo'q. Tashqi tomondan, hublar ba'zi tizimlarda surrogatlarni yaratish uchun ishlatiladigan ID-map tipidagi jadvallarga juda o'xshaydi, ammo Data Vault'da surrogatlar sifatida biznes kalitlari to'plamidan xeshni ishlatish tavsiya etiladi. Ushbu yondashuv manbalardan aloqalar va atributlarni yuklashni soddalashtiradi (surrogat olish uchun markazga qo'shilishingiz shart emas, shunchaki tabiiy kalitning xeshini hisoblashingiz kerak), lekin boshqa muammolarni keltirib chiqarishi mumkin (masalan, to'qnashuvlar bilan bog'liq). , string kalitlaridagi katta va chop etilmaydigan belgilar va hokazo. .p.), shuning uchun u umuman qabul qilinmaydi.
Boshqa barcha ob'ektlar atributlari deb nomlangan maxsus jadvallarda saqlanadi Sun'iy yo'ldoshlar. Bitta markazda turli xil atributlar to'plamini saqlaydigan bir nechta sun'iy yo'ldoshlar bo'lishi mumkin.
Sun'iy yo'ldoshlar o'rtasida atributlarni taqsimlash printsipga muvofiq amalga oshiriladi qo'shma o'zgarish - bitta sun'iy yo'ldoshda versiyasi bo'lmagan atributlar saqlanishi mumkin (masalan, tug'ilgan sana va jismoniy shaxs uchun SNILS), boshqasida - kamdan-kam o'zgaruvchan versiyalar (masalan, familiya va pasport raqami), uchinchisida - tez-tez o'zgarib turadiganlar (masalan, etkazib berish manzili, toifa, oxirgi buyurtma sanasi va boshqalar). Bunday holda, versiyalashtirish umuman ob'ekt emas, balki alohida sun'iy yo'ldoshlar darajasida amalga oshiriladi, shuning uchun atributlarni bitta sun'iy yo'ldosh ichidagi versiyalarning kesishishi minimal bo'lishi uchun taqsimlash tavsiya etiladi (bu saqlangan versiyalarning umumiy sonini kamaytiradi ).
Shuningdek, ma'lumotlarni yuklash jarayonini optimallashtirish uchun turli manbalardan olingan atributlar ko'pincha alohida sun'iy yo'ldoshlarga kiritiladi.
Sun'iy yo'ldoshlar Hub bilan aloqa qiladi xorijiy kalit (bu 1-dan ko'p kardinallikka mos keladi). Bu shuni anglatadiki, bir nechta atribut qiymatlari (masalan, bitta mijoz uchun bir nechta aloqa telefon raqamlari) ushbu "standart" arxitektura tomonidan qo'llab-quvvatlanadi.
В Anchor modeli kalitlarni saqlaydigan jadvallar deyiladi Ankerlar. Va ular ushlab turadilar:
- Faqat surrogat kalitlar
- Manbaga havola
- Qo'shish vaqtini yozib oling
Anchor modeli nuqtai nazaridan tabiiy kalitlar ko'rib chiqiladi oddiy atributlar. Ushbu variantni tushunish qiyinroqdek tuyulishi mumkin, ammo u ob'ektni aniqlash uchun ko'proq imkoniyatlarni beradi.
Misol uchun, agar bir xil ob'ekt haqidagi ma'lumotlar har xil tizimlardan olinishi mumkin bo'lsa, ularning har biri o'zining tabiiy kalitidan foydalanadi. Data Vault-da bu bir nechta markazlarning ancha noqulay tuzilmalariga olib kelishi mumkin (har bir manba uchun bitta + birlashtiruvchi asosiy versiya), Anchor modelida esa har bir manbaning tabiiy kaliti o'z atributiga to'g'ri keladi va mustaqil ravishda yuklanganda foydalanish mumkin. qolganlarning hammasi.
Ammo bu erda yana bir makkor nuqta bor: agar turli xil tizimlarning atributlari bitta ob'ektda birlashtirilgan bo'lsa, ehtimol ba'zilari mavjud. "yopishtirish" qoidalari, bu orqali tizim turli manbalardan olingan yozuvlar ob'ektning bir nusxasiga mos kelishini tushunishi kerak.
В Ma'lumotlar ombori bu qoidalar, ehtimol, shakllanishini belgilaydi Asosiy ob'ektning "surrogat markazi" va hech qanday tarzda tabiiy manba kalitlari va ularning asl atributlarini saqlaydigan Hublarga ta'sir qilmaydi. Agar biror nuqtada birlashma qoidalari o'zgarsa (yoki uni amalga oshiradigan atributlar yangilansa), bu surrogat markazlarni qayta formatlash uchun etarli bo'ladi.
В Ankraj modeli bunday ob'ekt katta ehtimol bilan saqlanadi yagona langar. Demak, barcha sifatlar, qaysi manbadan bo‘lishidan qat’i nazar, bir xil surrogatga bog‘langan bo‘ladi. Noto'g'ri birlashtirilgan yozuvlarni ajratish va umuman olganda, bunday tizimda birlashishning dolzarbligini kuzatish ancha qiyin bo'lishi mumkin, ayniqsa qoidalar juda murakkab va tez-tez o'zgarib turadigan bo'lsa va bir xil atributni turli manbalardan olish mumkin bo'lsa ham (garchi bu, albatta, mumkin, chunki har bir atribut versiyasi o'z manbasiga havolani saqlab qoladi).
Har qanday holatda, agar sizning tizimingiz funksionallikni amalga oshirishi kerak bo'lsa deuplikatsiya, yozuvlarni birlashtirish va boshqa MDM elementlari, Agile metodologiyalarida tabiiy kalitlarni saqlash jihatlariga alohida e'tibor qaratish lozim. Kattaroq Data Vault dizayni to'satdan birlashma xatolari nuqtai nazaridan xavfsizroq bo'lishi mumkin.
Ankraj modeli deb nomlangan qo'shimcha ob'ekt turini ham taqdim etadi Tugun u mohiyatan maxsus langarning degenerativ turi, unda faqat bitta atribut bo'lishi mumkin. Tugunlar tekis ma'lumotnomalarni saqlash uchun ishlatilishi kerak (masalan, jins, oilaviy ahvol, mijozlarga xizmat ko'rsatish toifasi va boshqalar). Anchordan farqli o'laroq, tugun bog'langan atribut jadvallari mavjud emas, va uning yagona atributi (nomi) har doim kalit bilan bir xil jadvalda saqlanadi. Tugunlar bir-biriga bog'langan holda bog'langan jadvallar (Tie) orqali Anchors bilan bog'langan.
Nodlardan foydalanish bo'yicha aniq fikr yo'q. Masalan, Rossiyada Anchor Modelidan foydalanishni faol ravishda targ'ib qiluvchi , (asossiz emas) birorta ham ma'lumotnoma uchun buni aniq aytish mumkin emas deb hisoblaydi. har doim statik va bir darajali bo'ladi, shuning uchun darhol barcha ob'ektlar uchun to'liq huquqli Anchordan foydalanish yaxshiroqdir.
Data Vault va Anchor modeli o'rtasidagi yana bir muhim farq - bu mavjudlik ulanishlarning atributlari:
В Ma'lumotlar ombori Bog'lanishlar Hublar kabi bir xil to'liq huquqli ob'ektlardir va ular bo'lishi mumkin o'ziga xos xususiyatlar. The Ankraj modeli Havolalar faqat Anchors va ulanish uchun ishlatiladi o‘z atributlariga ega bo‘la olmaydi. Bu farq sezilarli darajada boshqacha modellashtirishga olib keladi faktlar, bu haqda keyinroq muhokama qilinadi.
Faktlarni saqlash
Bundan oldin biz asosan o'lchovlarni modellashtirish haqida gaplashdik. Faktlar biroz aniqroq.
В Ma'lumotlar ombori faktlarni saqlash uchun odatiy ob'ekt hisoblanadi Havola, ularning sun'iy yo'ldoshlarida haqiqiy ko'rsatkichlar qo'shiladi.
Ushbu yondashuv intuitiv ko'rinadi. U tahlil qilingan ko'rsatkichlarga oson kirishni ta'minlaydi va odatda an'anaviy faktlar jadvaliga o'xshaydi (faqat ko'rsatkichlar jadvalning o'zida emas, balki "qo'shni" jadvalda saqlanadi). Ammo tuzoqlar ham mavjud: modelning odatiy modifikatsiyalaridan biri - fakt kalitining kengayishi - talab qiladi. havolaga yangi xorijiy kalit qo'shish. Va bu, o'z navbatida, modullikni "buzadi" va boshqa ob'ektlarni o'zgartirish zaruratini keltirib chiqaradi.
В Ankraj modeli Ulanish o'z atributlariga ega bo'lishi mumkin emas, shuning uchun bu yondashuv ishlamaydi - mutlaqo barcha atributlar va ko'rsatkichlar bitta aniq langarga bog'langan bo'lishi kerak. Bundan xulosa qilish oddiy - Har bir fakt ham o'z langariga muhtoj. Biz fakt sifatida qabul qilishga odatlangan ba'zi narsalar uchun bu tabiiy ko'rinishi mumkin - masalan, sotib olish faktini "buyurtma" yoki "kvitansiya" ob'ektiga mukammal darajada qisqartirish, sessiyaga saytga tashrif buyurish va hokazo. Ammo bunday tabiiy "tashuvchi ob'ekt" ni topish unchalik oson bo'lmagan faktlar ham bor - masalan, har kunning boshida omborlardagi tovarlar qoldiqlari.
Shunga ko'ra, Anchor modelida fakt kalitini kengaytirishda modullik bilan bog'liq muammolar yuzaga kelmaydi (tegishli Anchorga shunchaki yangi aloqa qo'shish kifoya), lekin faktlarni ko'rsatish uchun modelni loyihalash unchalik aniq emas; "sun'iy" langarlar paydo bo'lishi mumkin. biznes ob'ekt modelini noaniq tarzda aks ettiradi.
Moslashuvchanlikka qanday erishiladi
Ikkala holatda ham hosil bo'lgan qurilish o'z ichiga oladi sezilarli darajada ko'proq jadvallaran'anaviy o'lchovlarga qaraganda. Lekin olishi mumkin sezilarli darajada kamroq disk maydoni an'anaviy o'lchov bilan bir xil versiyali atributlar to'plami bilan. Tabiiyki, bu erda sehr yo'q - bularning barchasi normalizatsiya haqida. Atributlarni sun'iy yo'ldoshlar (ma'lumotlar omborida) yoki alohida jadvallar (Anchor modeli) bo'ylab tarqatish orqali biz kamaytiramiz (yoki butunlay yo'q qilamiz) boshqalarni o'zgartirganda ba'zi atributlarning qiymatlarini takrorlash.
uchun Ma'lumotlar ombori yutuqlar Yo'ldoshlar o'rtasida atributlarning taqsimlanishiga bog'liq bo'ladi va uchun Ankraj modeli - har bir o'lchov ob'ekti uchun versiyalarning o'rtacha soniga deyarli to'g'ridan-to'g'ri proportsionaldir.
Biroq, joyni tejash muhim, ammo asosiy emas, atributlarni alohida saqlashning afzalligi. Birgalikda munosabatlar alohida saqlash bilan, bu yondashuv do'kon qiladi modulli dizayn. Bu shuni anglatadiki, bunday modelga individual atributlarni va butunlay yangi mavzu sohalarini qo'shish o'xshaydi ustki tuzilma mavjud ob'ektlar to'plami ustidan ularni o'zgartirmasdan. Va aynan shu narsa tasvirlangan metodologiyalarni moslashuvchan qiladi.
Bu, shuningdek, parcha ishlab chiqarishdan ommaviy ishlab chiqarishga o'tishga o'xshaydi - agar an'anaviy yondashuvda modelning har bir jadvali noyob bo'lsa va alohida e'tibor talab qilsa, moslashuvchan metodologiyalarda u allaqachon standart "qismlar" to'plamidir. Bir tomondan, ko'proq jadvallar mavjud va ma'lumotlarni yuklash va olish jarayonlari murakkabroq ko'rinishi kerak. Boshqa tomondan, ular aylanadi tipik. Bu bo'lishi mumkinligini anglatadi avtomatlashtirilgan va metama'lumotlarga asoslangan. "Biz uni qanday yotqizamiz?" Degan savol, javobi yaxshilanishlarni loyihalash bo'yicha ishlarning muhim qismini egallashi mumkin, endi bunga loyiq emas (shuningdek, modelni o'zgartirishning ish jarayonlariga ta'siri haqidagi savol). ).
Bu analitiklar bunday tizimda umuman kerak emas degani emas - kimdir hali ham atributlarga ega bo'lgan ob'ektlar to'plamida ishlashi va barchasini qaerga va qanday yuklashni aniqlashi kerak. Ammo ish hajmi, shuningdek, xatolik ehtimoli va narxi sezilarli darajada kamayadi. Tahlil bosqichida ham, ETL-ni ishlab chiqishda ham, uning muhim qismi metama'lumotlarni tahrirlashga qisqartirilishi mumkin.
Qorong'u tomoni
Yuqorida aytilganlarning barchasi ikkala yondashuvni ham chinakam moslashuvchan, texnologik jihatdan ilg'or va takroriy takomillashtirish uchun mos qiladi. Albatta, "malhamdagi barrel" ham bor, menimcha, siz allaqachon taxmin qilishingiz mumkin.
Moslashuvchan arxitekturalarning modulliligi asosidagi ma'lumotlarning parchalanishi jadvallar sonining ko'payishiga olib keladi va shunga mos ravishda tepalik namuna olishda qo'shilish uchun. O'lchovning barcha atributlarini oddiygina olish uchun klassik do'konda bitta tanlov kifoya qiladi, ammo moslashuvchan arxitektura butun bir qator birikmalarni talab qiladi. Bundan tashqari, agar hisobotlar uchun bularning barchasini oldindan yozish mumkin bo'lsa, SQLni qo'lda yozishga odatlangan tahlilchilar ikki baravar azoblanadi.
Bu vaziyatni osonlashtiradigan bir nechta faktlar mavjud:
Katta o'lchamlar bilan ishlashda uning barcha atributlari deyarli bir vaqtning o'zida ishlatilmaydi. Bu modelga birinchi qarashda ko'rinadiganidan kamroq qo'shilishlar bo'lishi mumkinligini anglatadi. Ma'lumotlar ombori, shuningdek, sun'iy yo'ldoshlarga atributlarni taqsimlashda kutilgan almashish chastotasini ham hisobga olishi mumkin. Shu bilan birga, Hublar yoki Anchorlarning o'zlari birinchi navbatda yuklash bosqichida surrogatlarni yaratish va xaritalash uchun kerak bo'ladi va so'rovlarda kamdan-kam qo'llaniladi (bu ayniqsa Anchors uchun to'g'ri keladi).
Barcha ulanishlar kalit bilan amalga oshiriladi. Bundan tashqari, ma'lumotlarni saqlashning yanada "siqilgan" usuli, kerak bo'lganda (masalan, atribut qiymati bo'yicha filtrlashda) jadvallarni skanerlash xarajatlarini kamaytiradi. Bu bir qator birikmalar bilan normallashtirilgan ma'lumotlar bazasidan namuna olish har bir satrda ko'plab versiyalar bilan bitta og'ir o'lchamni skanerlashdan ham tezroq bo'lishiga olib kelishi mumkin.
Masalan, bu erda Maqolada bitta jadvaldan namuna bilan Anchor modelining ishlashining batafsil qiyosiy testi mavjud.
Ko'p narsa dvigatelga bog'liq. Ko'pgina zamonaviy platformalarda birlashishni optimallashtirishning ichki mexanizmlari mavjud. Masalan, MS SQL va Oracle jadvallarga qo'shilishlarni "o'tkazib yuborishi" mumkin, agar ularning ma'lumotlari boshqa birlashmalardan tashqari hech qanday joyda ishlatilmasa va yakuniy tanlovga ta'sir qilmasa (jadval/qo'shilishni yo'q qilish) va MPP Vertica , so'rovlar rejasini qo'lda optimallashtirishni hisobga olgan holda, Anchor modeli uchun ajoyib vosita ekanligini isbotladi. Boshqa tomondan, Anchor Modelini, masalan, cheklangan qo'shilish yordamiga ega Click House-da saqlash hali juda yaxshi fikrga o'xshamaydi.
Bundan tashqari, ikkala arxitektura uchun ham mavjud maxsus harakatlar, ma'lumotlarga kirishni osonlashtiradi (ham so'rovlar samaradorligi nuqtai nazaridan, ham oxirgi foydalanuvchilar uchun). Masalan, Vaqtni belgilash jadvallari Ma'lumotlar omborida yoki maxsus jadval funktsiyalari Anchor modelida.
jami
Ko'rib chiqilayotgan moslashuvchan arxitekturalarning asosiy mohiyati ularning "dizayn" ning modulliligidir.
Aynan shu mulk quyidagilarga imkon beradi:
- Metama'lumotlarni joylashtirish va asosiy ETL algoritmlarini yozish bilan bog'liq dastlabki tayyorgarlikdan so'ng, mijozga birinchi natijani tezda taqdim eting bir nechta manba ob'ektlaridan olingan ma'lumotlarni o'z ichiga olgan bir nechta hisobot shaklida. Butun ob'ekt modelini to'liq (hatto eng yuqori darajada) o'ylab ko'rish shart emas.
- Ma'lumotlar modeli atigi 2-3 ta ob'ekt bilan ishlashni boshlashi mumkin (va foydali bo'ladi), keyin esa asta-sekin o'sib boradi (Anchor modeli Nikolay haqida miselyum bilan yaxshi taqqoslash).
- Ko'pgina yaxshilanishlar, jumladan, mavzu maydonini kengaytirish va yangi manbalarni qo'shish mavjud funksionallikka ta'sir qilmaydi va allaqachon ishlayotgan narsani buzish xavfini tug'dirmaydi.
- Standart elementlarga parchalanish tufayli bunday tizimlardagi ETL jarayonlari bir xil ko'rinadi, ularning yozilishi algoritmlashtirishga yordam beradi va oxir-oqibat, avtomatlashtirish.
Ushbu moslashuvchanlikning narxi Hosildorlik. Bu bunday modellarda maqbul ko'rsatkichlarga erishish mumkin emas degani emas. Ko'pincha, kerakli ko'rsatkichlarga erishish uchun sizga ko'proq harakat va tafsilotlarga e'tibor kerak bo'lishi mumkin.
ilovalar
Tashkilot turlari Ma'lumotlar ombori
Data Vault haqida ko'proq ma'lumot:
Tashkilot turlari Anchor modeli
Anchor modeli haqida batafsil ma'lumot:
Ko'rib chiqilayotgan yondashuvlarning umumiy xususiyatlari va farqlari bilan umumiy jadval:
Manba: www.habr.com