Saxlama inkişafı uzun və ciddi bir işdir.
Layihənin həyatında çox şey başlanğıcda obyekt modelinin və baza strukturunun nə qədər yaxşı düşünülməsindən asılıdır.
Ümumi qəbul edilmiş yanaşma ulduz sxeminin üçüncü normal forma ilə müxtəlif kombinasiyaları olmuşdur və qalır. Bir qayda olaraq, prinsipə görə: ilkin məlumatlar - 3NF, vitrinlər - ulduz. Zamanla sınaqdan keçirilmiş və çoxlu araşdırmalarla dəstəklənən bu yanaşma təcrübəli DWH mütəxəssisinin analitik anbarın necə olması barədə düşündüyü zaman ağlına gələn ilk (və bəzən yeganə) şeydir.
Digər tərəfdən, ümumilikdə biznes və xüsusən də müştəri tələbləri sürətlə dəyişməyə meyllidir, halbuki məlumatlar həm “dərinlikdə”, həm də “genişlikdə” böyüyür. Və burada ulduzun əsas çatışmazlığı görünür - məhduddur rahatlıq.
DWH tərtibatçısı kimi sakit və rahat həyatınızda birdən-birə:
- vəzifə "heç olmasa tez bir şey etmək, sonra görəcəyik" ortaya çıxdı;
- həftədə ən azı bir dəfə yeni mənbələrin qoşulması və biznes modelinin dəyişdirilməsi ilə sürətlə inkişaf edən bir layihə ortaya çıxdı;
- sistemin necə görünməsi və sonda hansı funksiyaları yerinə yetirməsi barədə heç bir fikri olmayan, lakin təcrübələrə və ona ardıcıl yanaşma ilə istənilən nəticənin ardıcıl dəqiqləşdirilməsinə hazır olan bir müştəri meydana çıxdı;
- layihə meneceri xoş xəbərlə içəri baxdı: “İndi çevikliyimiz var!”.
Və ya sadəcə olaraq başqa necə saxlama qura biləcəyinizi öyrənmək istəyirsinizsə - pişiyə xoş gəlmisiniz!
"Elastiklik" nə deməkdir?
Başlamaq üçün, sistemin “çevik” adlandırılması üçün hansı xüsusiyyətlərə malik olması lazım olduğunu müəyyən edək.
Ayrı-ayrılıqda qeyd etmək lazımdır ki, təsvir olunan xüsusiyyətlərə xüsusi istinad edilməlidir sistem, yox proses onun inkişafı. Buna görə də, Agile haqqında bir inkişaf metodologiyası kimi oxumaq istəyirsinizsə, digər məqalələri oxumaq daha yaxşıdır. Məsələn, elə orada, Habré-də çoxlu maraqlı materiallar var (kimi и Və ).
Bu o demək deyil ki, inkişaf prosesi və məlumat anbarının strukturu tamamilə əlaqəsizdir. Ümumiyyətlə, çevik yaddaşın çevik inkişafı daha asan olmalıdır. Bununla belə, praktikada Kimbal və DataVault-a görə klassik DWH-nin Çevik inkişafı ilə bir layihədə iki formada çevikliyin xoşbəxt təsadüflərindən daha çox variant var - şəlaləyə görə.
Beləliklə, çevik saxlama hansı imkanlara malik olmalıdır? Burada üç məqam var:
- Erkən çatdırılma və sürətli tamamlama - bu o deməkdir ki, ideal olaraq ilk iş nəticəsi (məsələn, ilk iş hesabatları) mümkün qədər tez, yəni bütün sistem tərtib olunmadan və tətbiq edilməmişdən əvvəl əldə edilməlidir. Eyni zamanda, hər bir sonrakı təftiş də mümkün qədər az vaxt aparmalıdır.
- İterativ dəqiqləşdirmə - bu o deməkdir ki, hər bir sonrakı düzəliş, ideal olaraq, artıq işləyən funksionallığa təsir etməməlidir. Məhz bu məqam tez-tez böyük layihələrdə ən böyük kabusa çevrilir - gec-tez ayrı-ayrı obyektlər o qədər çox əlaqələr əldə etməyə başlayır ki, mövcud cədvələ sahə əlavə etməkdənsə yan-yana surətdə məntiqi tamamilə təkrarlamaq daha asan olur. Mövcud obyektlərə təkmilləşdirmələrin təsirinin təhlilinin təftişin özündən daha uzun çəkə biləcəyinə təəccüblənirsinizsə, çox güman ki, bank və ya telekommunikasiya sahəsində böyük məlumat anbarları ilə işləməmisiniz.
- Dəyişən biznes tələblərinə daimi uyğunlaşma - ümumi obyekt strukturu yalnız mümkün genişlənmə nəzərə alınmaqla deyil, bu növbəti genişlənmənin istiqamətinin dizayn mərhələsində xəyal belə edilə bilməyəcəyi gözləntiləri ilə tərtib edilməlidir.
Və bəli, bütün bu tələblərə bir sistemdə riayət etmək mümkündür (əlbəttə ki, müəyyən hallarda və bəzi qeyd-şərtlərlə).
Aşağıda HD üçün ən məşhur çevik dizayn metodologiyalarından ikisini nəzərdən keçirəcəyəm anker modeli и Məlumat Anbarı. Mötərizənin xaricində, məsələn, EAV, 6NF (saf formada) və NoSQL həlləri ilə əlaqəli hər şey kimi əla fəndlər var - onlar nədənsə daha pis olduğuna görə deyil, hətta bu halda məqalənin həcmi əldə etməklə təhdid edəcəyinə görə deyil. orta disser. Sadəcə olaraq, bütün bunlar bir qədər fərqli sinif həllərinə aiddir - ya layihənizin ümumi arxitekturasından (məsələn, EAV) asılı olmayaraq, konkret hallarda tətbiq edə biləcəyiniz üsullara və ya qlobal miqyasda fərqli məlumat saxlama paradiqmalarına (məsələn, qrafik verilənlər bazası kimi) aiddir. və digər variantlar).NoSQL).
“Klassik” yanaşmanın problemləri və onların çevik metodologiyalarda həlli yolları
“Klassik” yanaşma dedikdə mən köhnə yaxşı ulduzu nəzərdə tuturam (əsas təbəqələrin konkret həyata keçirilməsindən asılı olmayaraq, məni Kimball, Inmon və CDM tərəfdarlarını bağışlayın).
1. Əlaqələrin sərt kardinallığı
Bu model məlumatların aydın şəkildə bölünməsinə əsaslanır ölçülər (Ölçü) и faktlar (Fakt). Və bu, lənətə gəlsin, məntiqlidir - axırda, əksər hallarda məlumatların təhlili müəyyən bölmələrdə (ölçülərdə) müəyyən ədədi göstəricilərin (faktların) təhlilinə gəlir.
Eyni zamanda, obyektlər arasında əlaqələr xarici açarla cədvəllər arasında keçidlər şəklində qoyulur. Bu olduqca təbii görünür, lakin dərhal çevikliyin ilk məhdudiyyətinə gətirib çıxarır - əlaqələrin kardinallığının ciddi tərifi.
Bu o deməkdir ki, cədvəllərin dizayn mərhələsində siz hər bir əlaqəli obyekt cütü üçün onların çox-çox, yoxsa yalnız 1-dən çox ilə əlaqəli ola biləcəyini və "hansı istiqamətdə" bağlı ola biləcəyini müəyyən etməlisiniz. Cədvəllərdən hansının əsas açarın, hansının isə xarici açarın olacağı birbaşa asılıdır. Yeni tələblər alındıqda bu nisbətin dəyişdirilməsi çox güman ki, bazanın yenidən işlənməsinə gətirib çıxaracaq.
Məsələn, "nağd pul qəbzi" obyektini tərtib edərkən, siz satış şöbəsinin andlı təminatlarına güvənərək, hərəkət etmək imkanını qoyursunuz. bir neçə yoxlama vəzifəsi üçün bir yüksəliş (lakin əksinə deyil):
Və bir müddət sonra həmkarlar yeni marketinq strategiyasını təqdim etdilər eyni zamanda bir neçə promosyon. İndi ayrı bir obyektdə əlaqəni vurğulayaraq cədvəlləri yekunlaşdırmalısınız.
(Promo çekin qoşulduğu bütün törəmə obyektlər indi də təkmilləşdirilməlidir).
Data Vault və Anchor Modelindəki bağlantılar
Belə bir vəziyyətdən qaçmaq olduqca sadə oldu: satış şöbəsinə etibar etmək lazım deyil, kifayətdir bütün əlaqələr əvvəlcə ayrı-ayrı cədvəllərdə saxlanılır və çoxdan çoxa qədər emal edin.
Bu yanaşma təklif edildi Dan Linstedt paradiqmanın bir hissəsi kimi Məlumat Anbarı və tam dəstəklənir Lars Rönnbek в Çapa modeli.
Nəticədə, çevik metodologiyaların ilk fərqləndirici xüsusiyyətini əldə edirik:
Obyektlər arasındakı əlaqələr əsas obyektlərin atributlarında saxlanılmır, lakin obyektlərin ayrıca növüdür.
В Məlumat Anbarı belə cədvəllər adlanır əlaqə, içində isə Çapa modeli - Qalustuk. İlk baxışdan onlar çox oxşardırlar, baxmayaraq ki, onların fərqləri adla tükənmir (bunlar aşağıda müzakirə olunacaq). Hər iki arxitekturada keçid cədvəlləri əlaqələndirilə bilər istənilən sayda qurum (mütləq 2 deyil).
Bu ilk baxışdan artıqlıq tamamlamalarda əsas rahatlıq verir. Belə bir quruluş təkcə mövcud əlaqələrin əsas xüsusiyyətlərini dəyişdirməyə deyil, həm də yenilərini əlavə etməyə dözümlü olur - əgər indi bir çek mövqeyində onu pozan kassirlə əlaqə varsa, belə bir əlaqənin görünüşü sadəcə bir üst quruluş olacaqdır. heç bir mövcud obyekt və proseslərə təsir etmədən mövcud cədvəllər üzərində.
2. Məlumatların təkrarlanması
Çevik arxitekturaların həll etdiyi ikinci problem, ilk növbədə, daha az aydındır və xasdır. ölçmələr növü SCD2 (ikinci növün yavaş-yavaş dəyişən ölçmələri), baxmayaraq ki, təkcə onlar deyil.
Klassik yaddaşda ölçü adətən surroqat açarı (PK kimi) və ayrı-ayrı sütunlarda biznes açarları və atributları dəsti olan cədvəldir.
Ölçü versiyalaşdırmanı dəstəkləyirsə, versiya vaxt məhdudiyyətləri standart sahələr dəstinə əlavə edilir və mənbədəki hər sətirdə repozitoriyada birdən çox versiya görünür (versiyalaşdırılmış atributlara hər dəyişiklik üçün bir).
Ölçü tez-tez dəyişən ən azı bir versiyalı atributdan ibarətdirsə, belə ölçüsün versiyalarının sayı təsir edici olacaq (digər atributlar versiyalaşdırılmasa və ya heç vaxt dəyişməsə belə) və bir neçə belə atribut varsa, versiyaların sayı onların sayından eksponent olaraq arta bilər. Belə bir ölçü əhəmiyyətli miqdarda disk sahəsi tuta bilər, baxmayaraq ki, orada saxlanılan məlumatların əksəriyyəti digər cərgələrin dəyişməz atribut dəyərlərinin sadəcə dublikatlarıdır.
Eyni zamanda, tez-tez istifadə olunur denormalizasiya - bəzi atributlar məlumat kitabçasına və ya başqa ölçüyə istinad kimi deyil, qəsdən dəyər kimi saxlanılır. Bu yanaşma bir ölçüyə daxil olan zaman birləşmələrin sayını azaltmaqla məlumatlara çıxışı sürətləndirir.
Bir qayda olaraq, bu nəticə verir eyni məlumat eyni vaxtda bir neçə yerdə saxlanılır. Məsələn, yaşayış bölgəsi və müştəri kateqoriyasına üzvlük haqqında məlumat eyni vaxtda “Müştəri” ölçülərində, “Satınalma”, “Çatdırılma” və “Çağrı mərkəzi ilə əlaqə” faktlarında, həmçinin link cədvəli "Müştəri - Müştəri meneceri".
Ümumiyyətlə, yuxarıda göstərilənlər adi (versiyalaşdırılmamış) ölçmələrə aiddir, lakin versiyalarda onlar fərqli miqyasda ola bilər: obyektin yeni versiyasının görünüşü (xüsusilə arxa planda) yalnız bütün əlaqəli cədvəllərin yenilənməsinə deyil, həm də əlaqəli obyektlərin yeni versiyalarının kaskad görünüşünə - Cədvəl 1-nin qurulması üçün Cədvəl 2-dən və Cədvəl 2-ün qurulması üçün Cədvəl 3-dən istifadə edildikdə və s. Cədvəl 1-in heç bir atributu Cədvəl 3-ün qurulmasında iştirak etməsə belə (və digər mənbələrdən əldə edilmiş Cədvəl 2-nin digər atributları iştirak edir), bu konstruksiyanın versiyalaşdırılması ən azı əlavə məsrəflərə, ən çox isə əlavə xərclərə səbəb olacaqdır. Cədvəl 3-dəki versiyalar, ümumiyyətlə “buna heç bir aidiyyəti yoxdur” və zəncirdən aşağı.
3. Təkmilləşdirmənin qeyri-xətti mürəkkəbliyi
Eyni zamanda, digərinin əsasında qurulan hər bir yeni vitrin, ETL-də dəyişikliklər edildikdə məlumatların “ayrıla biləcəyi” yerlərin sayını artırır. Bu, öz növbəsində, hər bir sonrakı təftişin mürəkkəbliyinin (və müddətinin) artmasına səbəb olur.
Yuxarıdakılar nadir hallarda dəyişdirilmiş ETL prosesləri olan sistemlərə aiddirsə, siz belə bir paradiqmada yaşaya bilərsiniz - sadəcə olaraq bütün əlaqəli obyektlərdə yeni təkmilləşdirmələrin düzgün aparıldığına əmin olun. Əgər düzəlişlər tez-tez baş verirsə, bir neçə keçidin təsadüfən “itkin düşməsi” ehtimalı əhəmiyyətli dərəcədə artır.
Bundan əlavə, nəzərə alsaq ki, "versiyalaşdırılmış" ETL "versiyalaşdırılmamış" ilə müqayisədə daha mürəkkəbdir, bütün bu iqtisadiyyatın tez-tez təkmilləşdirilməsi zamanı səhvlərdən qaçınmaq olduqca çətin olur.
Data Vault və Anchor Modelində obyektlərin və atributların saxlanması
Çevik arxitekturaların müəllifləri tərəfindən təklif olunan yanaşma aşağıdakı kimi formalaşdırıla bilər:
Dəyişənlərdən dəyişməz qalanı ayırmaq lazımdır. Bu, açarları atributlardan ayrı saxlamaqdır.
Bununla belə, çaşdırmayın versiya deyil ilə atribut dəyişməz: birincisi onun dəyişmə tarixini saxlamır, lakin dəyişə bilər (məsələn, giriş xətasını düzəldərkən və ya yeni məlumatlar qəbul edərkən), ikincisi heç vaxt dəyişmir.
Data Vault və Anchor modelində tam olaraq nəyin dəyişməz sayıla biləcəyinə dair fikirlər fərqlidir.
Memarlıq baxımından Məlumat Anbarı, dəyişməmiş hesab edilə bilər bütün açarlar dəsti — təbii (təşkilatın VÖEN, mənbə sistemindəki məhsul kodu və s.) və surroqat. Eyni zamanda, qalan atributları dəyişikliklərin mənbəyinə və/və ya tezliyinə görə qruplara bölmək olar. hər bir qrup üçün ayrıca masa saxlayın müstəqil versiyalar dəsti ilə.
Eyni paradiqmada Çapa modeli dəyişməz hesab edilir yalnız surroqat açar qurumlar. Qalan hər şey (o cümlədən təbii açarlar) onun atributlarının xüsusi halıdır. Harada bütün atributlar standart olaraq bir-birindən müstəqildir, buna görə də hər bir atribut üçün yaradılmalıdır ayrı masa.
В Məlumat Anbarı obyekt açarlarını ehtiva edən cədvəllər çağırılır Hubami (Hub). Qovşaqlarda həmişə sabit sahələr dəsti var:
- Təbii varlıq açarları
- Surroqat açar
- Mənbəyə keçid
- Qeydiyyat vaxtı
Hub-da girişlər heç vaxt dəyişməz və versiyaları yoxdur. Xarici olaraq, hublar bəzi sistemlərdə surroqatlar yaratmaq üçün istifadə edilən ID-xəritə cədvəllərinə çox bənzəyir, lakin Data Vault-da surroqatlar kimi tam ədəd ardıcıllığından deyil, bir sıra biznes açarlarından hash istifadə etmək tövsiyə olunur. Bu yanaşma mənbələrdən keçidlərin və atributların yüklənməsini asanlaşdırır (surroqat əldə etmək üçün mərkəzə qoşulmağa ehtiyac yoxdur, sadəcə təbii açardan hash hesablayın), lakin bu, digər problemlərə səbəb ola bilər (məsələn, toqquşmalar, vəziyyət və qeyri-sabitlik ilə). simli düymələrdə simvolların çapı və s. .p.), buna görə də ümumiyyətlə qəbul edilmir.
Bütün digər obyekt atributları adlı xüsusi cədvəllərdə saxlanılır Peyklər (peyk). Bir mərkəzdə müxtəlif atributlar dəstini saxlayan bir neçə peyk ola bilər.
Peyklər arasında atributların paylanması prinsipə uyğun olaraq baş verir birgə dəyişiklik - bir peykdə versiyası olmayan atributlar saxlanıla bilər (məsələn, fərdi şəxs üçün doğum tarixi və SNILS), digərində - nadir hallarda dəyişən versiya (məsələn, soyadı və pasport nömrəsi), üçüncüsü - tez-tez dəyişən (məsələn, çatdırılma ünvanı, kateqoriya, son sifarişin tarixi və s.). Bu vəziyyətdə versiya bütövlükdə qurum deyil, ayrı-ayrı peyklər səviyyəsində həyata keçirilir, buna görə də atributların bir peyk daxilində versiyaların kəsişməsi minimal olacağı şəkildə paylanması məsləhət görülür (bu, ümumi sayını azaldır). saxlanılan versiyalar).
Həmçinin, məlumatların yüklənməsi prosesini optimallaşdırmaq üçün müxtəlif mənbələrdən alınan atributlar çox vaxt ayrı-ayrı peyklərdə yerləşdirilir.
Peyklər Hub ilə əlaqə qurur xarici Açar (1-dən çox kardinallığa uyğundur). Bu o deməkdir ki, birdən çox atribut dəyərləri (məsələn, eyni müştəri üçün birdən çox əlaqə telefonu nömrəsi) bu "standart" arxitektura tərəfindən dəstəklənir.
В Çapa modeli açarları saxlayan cədvəllər adlanır Çapalar. Və saxlayırlar:
- Yalnız surroqat açarlar
- Mənbəyə keçid
- Qeydiyyat vaxtı
Anchor Modeli baxımından təbii açarlar nəzərdən keçirilir adi atributlar. Bu seçimi başa düşmək daha çətin görünə bilər, lakin o, obyekti müəyyən etmək üçün daha çox imkan verir.
Məsələn, əgər eyni obyekt haqqında məlumatlar hər biri öz təbii açarından istifadə edən müxtəlif sistemlərdən gələ bilərsə. Data Vault-da bu, bir neçə qovşağın (hər mənbəyə bir + birləşən əsas versiya) kifayət qədər çətin konstruksiyalarına səbəb ola bilər, Anchor modelində isə hər bir mənbənin təbii açarı öz atributuna düşür və müstəqil olaraq yüklənərkən istifadə edilə bilər. bütün digərləri.
Ancaq burada bir məkrli məqam var: müxtəlif sistemlərin atributları bir varlıqda birləşdirilirsə, çox güman ki, bəziləri var. yapışqan qaydaları, bunun vasitəsilə sistem müxtəlif mənbələrdən olan qeydlərin müəssisənin bir nümunəsinə uyğun olduğunu başa düşməlidir.
В Məlumat Anbarı bu qaydaların formalaşmasını müəyyən etmək ehtimalı var əsas müəssisənin “surroqat mərkəzi” və heç bir şəkildə mənbələrin təbii açarlarını və onların orijinal atributlarını saxlayan Hublara təsir etmir. Əgər müəyyən bir anda birləşmə qaydaları dəyişdirilərsə (və ya birləşmə üçün istifadə olunan atributlar yenilənərsə), bu, surroqat mərkəzləri yenidən formalaşdırmaq üçün kifayət edəcəkdir.
В anker modeli belə bir obyektin saxlanması ehtimalı var tək lövbər. Bu o deməkdir ki, bütün atributlar, hansı mənbədən alınmasından asılı olmayaraq, eyni surroqata bağlanacaq. Səhv birləşdirilmiş qeydləri ayırmaq və ümumiyyətlə, belə bir sistemdə birləşmənin aktuallığını izləmək, xüsusən də qaydalar kifayət qədər mürəkkəbdirsə və tez-tez dəyişirsə və eyni atribut müxtəlif mənbələrdən əldə edilə bilərsə, daha çətin ola bilər (baxmayaraq ki, bu, mütləqdir. mümkündür, çünki hər bir atribut versiyası mənşəyinə istinad saxlayır).
İstənilən halda, sisteminizin funksionallığı həyata keçirməsi nəzərdə tutulursa təkmilləşdirmə, qeydlərin birləşdirilməsi və digər MDM elementləri, çevik metodologiyalarda təbii açarların saxlanması aspektlərini xüsusilə diqqətlə oxumalısınız. Bəlkə də Data Vault-un daha çətin dizaynı birləşmə xətaları baxımından birdən daha təhlükəsizdir.
anker modeli adlı əlavə obyekt tipini də təmin edir Düyün əslində xüsusidir degenerativ lövbər növü, yalnız bir atribut ehtiva edə bilər. Qovşaqların düz kataloqların saxlanması üçün istifadə edilməsi nəzərdə tutulur (məsələn, cins, ailə vəziyyəti, müştəri xidməti kateqoriyası və s.). Anchor-dan fərqli olaraq Düyün əlaqəli atribut cədvəlləri yoxdur, və onun yeganə atributu (ad) həmişə açarla eyni cədvəldə saxlanılır. Düyünlər lövbərlər bir-birinə bağlandığı kimi bağlama masaları (Qalstuk) ilə Çapalarla əlaqələndirilir.
Düyünlərin istifadəsi ilə bağlı birmənalı fikir yoxdur. Misal üçün, Rusiyada Anchor Modelinin istifadəsini fəal şəkildə təbliğ edən , hesab edir ki, (əsassız deyil) bir məlumat kitabı üçün onun həmişə statik və tək səviyyəli olacaq, buna görə də bütün obyektlər üçün bir anda tam hüquqlu Anchor istifadə etmək daha yaxşıdır.
Data Vault və Anchor Model arasındakı digər mühüm fərq mövcudluğudur bağlantılar üçün atributlar:
В Məlumat Anbarı Bağlantılar Hublarla eyni tam hüquqlu obyektlərdir və ola bilər öz atributları. Ilə anker modeli Linklər yalnız Çapaları birləşdirmək üçün istifadə olunur və öz atributlarına malik ola bilməz. Bu fərq əhəmiyyətli dərəcədə fərqli modelləşdirmə yanaşmalarına səbəb olur. faktlar, bundan sonra müzakirə olunacaq.
Faktların saxlanması
İndiyə qədər biz əsasən modelləşdirmə ölçüləri haqqında danışdıq. Faktlar bir az daha aydındır.
В Məlumat Anbarı faktların saxlanması üçün tipik obyekt - Link, kimin peyklərində real göstəricilər əlavə olunur.
Bu yanaşma intuitiv görünür. O, təhlil edilən göstəricilərə asan girişi təmin edir və ümumiyyətlə ənənəvi fakt cədvəlinə bənzəyir (yalnız göstəricilər cədvəlin özündə deyil, “bitişik cədvəldə” saxlanılır). Ancaq tələlər də var: modelin tipik təkmilləşdirmələrindən biri - fakt açarının genişləndirilməsi - bunu zəruri edir. Linkə yeni xarici açarın əlavə edilməsi. Və bu, öz növbəsində, modulluğu "sındırır" və potensial olaraq digər obyektlərin təkmilləşdirilməsinə ehtiyac yaradır.
В anker modeli Bağlantının öz atributları ola bilməz, buna görə də bu yanaşma işləməyəcək - tamamilə bütün atributlar və göstəricilər bir xüsusi lövbərlə əlaqələndirilməlidir. Buradan nəticə sadədir - hər bir faktın da öz lövbəri lazımdır. Fakt kimi qəbul etməyə adət etdiyimiz bəzi şeylər üçün bu təbii görünə bilər - məsələn, satınalma faktı "sifariş" və ya "qəbz" obyektinə mükəmməl şəkildə endirilir, sayta baş çəkmək sessiyaya endirilir və s. Ancaq belə bir təbii "daşıyıcı obyekt" tapmaq o qədər də asan olmadığı faktlar var - məsələn, hər günün əvvəlində anbarlarda malların balansı.
Müvafiq olaraq, Anchor Modelində fakt açarını genişləndirərkən modulluqla bağlı heç bir problem yoxdur (sadəcə müvafiq Anchor-a yeni Əlaqə əlavə etmək kifayətdir), lakin faktları göstərmək üçün modeli dizayn etmək daha az sadədir, "süni" Çapalar görünə bilər. biznesin obyekt modelini əks etdirən aydın deyil.
Çeviklik necə əldə edilir
Hər iki halda meydana gələn tikinti ehtiva edir əhəmiyyətli dərəcədə daha çox masalarənənəvi ölçmə ilə müqayisədə. Amma götürə bilər əhəmiyyətli dərəcədə az disk sahəsi ənənəvi ölçü ilə eyni versiyalı atributlar dəsti ilə. Təbii ki, burada heç bir sehr yoxdur - hər şey normallaşma ilə bağlıdır. Atributları Peyklər (Məlumat Anbarında) və ya fərdi cədvəllər (Anchor Model) arasında paylamaqla biz azaldırıq (və ya tamamilə aradan qaldırırıq) digərlərini dəyişdirərkən bəzi atributların dəyərlərinin təkrarlanması.
Uğrunda Məlumat Anbarı qazanc, atributların Peyklər arasında paylanmasından asılı olacaq və üçün anker modeli — ölçmə obyekti üzrə versiyaların orta sayı ilə demək olar ki, düz mütənasibdir.
Bununla belə, yer tutmaq atributları ayrıca saxlamağın vacib, lakin əsas üstünlüyü deyil. Bağlantıların ayrı saxlanması ilə birlikdə bu yanaşma saxlanmasını təmin edir modul dizayn. Bu o deməkdir ki, belə bir modelə həm fərdi atributlar, həm də tamamilə yeni mövzu sahələri əlavə etmək kimi görünür üst quruluş onları dəyişdirmədən mövcud obyektlər dəsti üzərində. Təsvir edilən metodologiyaları çevik edən məhz budur.
Bu, həm də parça istehsalından kütləvi istehsala keçidə bənzəyir - əgər ənənəvi yanaşmada hər bir model cədvəli unikaldırsa və ayrıca diqqət tələb edirsə, çevik metodologiyalarda bu, artıq tipik "detallar" toplusudur. Bir tərəfdən daha çox cədvəl var, məlumatların yüklənməsi və götürülməsi prosesləri daha mürəkkəb görünməlidir. Digər tərəfdən, onlar olurlar tipik. Bu o deməkdir ki, ola bilər avtomatlaşdırılmış və metadata tərəfindən idarə olunur. Cavabı təkmilləşdirmələrin dizaynı üzərində işin əhəmiyyətli hissəsini tuta bilən "necə qoyacağıq?" Sualı indi sadəcə buna dəyməz (modelin dəyişdirilməsinin işə təsiri sualı kimi) proseslər).
Bu, o demək deyil ki, belə bir sistemdə analitiklərə ümumiyyətlə ehtiyac yoxdur - kimsə hələ də atributları olan bir sıra obyektlər hazırlamalı və hamısını harada və necə yükləməli olduğunu başa düşməlidir. Ancaq işin həcmi, həmçinin səhv ehtimalı və dəyəri əhəmiyyətli dərəcədə azalır. Həm təhlil mərhələsində, həm də əhəmiyyətli bir hissəsində metadataların redaktə edilməsinə endirilə bilən ETL-nin inkişafı zamanı.
Qaranlıq tərəf
Yuxarıda göstərilənlərin hamısı hər iki yanaşmanı həqiqətən çevik, istehsal oluna bilən və təkrarlanan təkmilləşdirmə üçün uyğun edir. Əlbəttə ki, siz artıq bildiyiniz bir “tar çəlləsi” də var.
Çevik arxitekturaların modulluğunun əsasını təşkil edən məlumatların parçalanması cədvəllərin sayının artmasına səbəb olur və müvafiq olaraq, baş üstü gətirərkən birləşmələr üçün. Sadəcə olaraq ölçünün bütün atributlarını əldə etmək üçün klassik yaddaşda tək seçim kifayətdir və çevik arxitektura bir sıra birləşmələr tələb edir. Üstəlik, hesabatlar üçün bütün bu birləşmələri əvvəlcədən yazmaq olarsa, SQL-i əl ilə yazmağa öyrəşmiş analitiklər ikiqat əziyyət çəkəcəklər.
Bu vəziyyəti asanlaşdıran bir neçə fakt var:
Böyük ölçülərlə işləyərkən, demək olar ki, bütün atributları eyni vaxtda istifadə edilmir. Bu o deməkdir ki, modelə ilk baxışdan göründüyündən daha az birləşmə ola bilər. Data Vault-da siz həmçinin peyklərə atributlar ayırarkən gözlənilən paylaşma tezliyini nəzərə ala bilərsiniz. Eyni zamanda, Hub və ya Çapaların özləri ilk növbədə yükləmə mərhələsində surroqatların yaradılması və xəritələşdirilməsi üçün lazımdır və sorğularda nadir hallarda istifadə olunur (bu, xüsusilə Anchors üçün doğrudur).
Bütün birləşmələr açarla edilir. Bundan əlavə, məlumatların saxlanmasının daha "sıxılmış" üsulu, lazım olan yerlərdə (məsələn, bir atribut dəyərinə görə süzgəcdən keçirərkən) cədvəlin skan edilməsinə əlavə xərcləri azaldır. Bu ona gətirib çıxara bilər ki, bir dəstə birləşmə ilə normallaşdırılmış verilənlər bazasından əldə etmək, hər sətirdə çoxlu versiya ilə ağır ölçüləri skan etməkdən daha sürətli olacaq.
Məsələn, burada məqalədə bir cədvəldən seçimlə Anchor modelinin ətraflı müqayisəli performans testi var.
Çox şey mühərrikdən asılıdır. Bir çox müasir platformalarda birləşmələrin optimallaşdırılması üçün daxili mexanizmlər var. Məsələn, MS SQL və Oracle, verilənləri digər birləşmələr istisna olmaqla, heç bir yerdə istifadə edilmədikdə və yekun seçimə təsir etmədikdə (cədvəl/qoşulmanın aradan qaldırılması), MPP Vertica isə cədvəllərə qoşulmaları “atlaya” bilər. , sorğu planının bəzi əl ilə optimallaşdırılması ilə Anchor Model üçün əla mühərrik olduğunu sübut etdi. Digər tərəfdən, Anchor Modelini, məsələn, qoşulmaq üçün məhdud dəstəyi olan Click House-da saxlamaq hələ yaxşı fikir kimi görünmür.
Bundan əlavə, hər iki memarlıq üçün var xüsusi fəndlər, bu da verilənlərə daxil olmağı asanlaşdırır (həm sorğu performansı baxımından, həm də son istifadəçilər üçün). Misal üçün, Zamanla bağlı cədvəllər Data Vault-da və ya xüsusi masa funksiyaları anker modelində.
Ümumi
Nəzərdən keçirilən çevik arxitekturaların əsas mahiyyəti onların “dizaynının” modulluğudur.
Bu əmlak imkan verir:
- Metaməlumatların yerləşdirilməsi və əsas ETL alqoritmlərinin yazılması ilə bağlı bəzi ilkin hazırlıqdan sonra, tez müştəriyə ilk nəticəni təqdim etmək yalnız bir neçə mənbə obyektindən məlumatları ehtiva edən bir neçə hesabat şəklində. Bunun üçün bütün obyekt modelini tam (hətta ən yüksək səviyyədə) düşünmək lazım deyil.
- Məlumat modeli yalnız 2-3 obyektlə işləməyə (və faydalı) başlaya bilər və sonra tədricən böyümək (Anchor modeli Nikolay ilə əlaqədar miselyumla gözəl müqayisə).
- Mövzu sahəsinin genişləndirilməsi və yeni mənbələrin əlavə edilməsi daxil olmaqla, əksər təkmilləşdirmələr mövcud funksionallığa təsir göstərmir və artıq işləyən bir şeyi pozmaq təhlükəsi yaratmır.
- Standart elementlərə parçalanma sayəsində bu cür sistemlərdə ETL prosesləri eyni görünür, onların yazısı alqoritmləşdirməyə imkan verir və nəticədə, avtomatlaşdırma.
Bu çevikliyin qiyməti performans. Bu o demək deyil ki, belə modellərdə məqbul performansa nail olmaq mümkün deyil. İstədiyiniz ölçülərə çatmaq üçün daha çox səy və təfərrüata diqqət yetirməyə ehtiyacınız ola bilər.
Proqram
Müəssisə növləri Məlumat Anbarı
Data Vault haqqında ətraflı:
Müəssisə növləri Çapa modeli
Anchor Model haqqında daha çox məlumat:
Baxılan yanaşmalar arasında ümumi xüsusiyyətlər və fərqlər olan xülasə cədvəli:
Mənbə: www.habr.com