Agile DWH დიზაინის მეთოდოლოგიების მიმოხილვა

შენახვის ობიექტის განვითარება ხანგრძლივი და სერიოზული წამოწყებაა.

პროექტის ცხოვრებაში ბევრი რამ არის დამოკიდებული იმაზე, თუ რამდენად კარგად არის გააზრებული ობიექტის მოდელი და ბაზის სტრუქტურა დასაწყისში.

ზოგადად მიღებული მიდგომა იყო და რჩება ვარსკვლავური სქემის მესამე ნორმალურ ფორმასთან შერწყმის სხვადასხვა ვარიანტები. როგორც წესი, პრინციპის მიხედვით: საწყისი მონაცემები - 3NF, ვიტრინები - ვარსკვლავი. ეს მიდგომა, დროში გამოცდილი და დიდი რაოდენობით კვლევებით მხარდაჭერილი, არის პირველი (და ზოგჯერ ერთადერთი) რაც გონზე მოდის გამოცდილ DWH სპეციალისტს, როდესაც ფიქრობს იმაზე, თუ როგორი უნდა იყოს ანალიტიკური საცავი.

მეორეს მხრივ, ზოგადად ბიზნესი და კონკრეტულად მომხმარებელთა მოთხოვნები სწრაფად იცვლება და მონაცემები იზრდება როგორც „სიღრმეში“ და „სიგანეში“. და სწორედ აქ ჩნდება ვარსკვლავის მთავარი მინუსი - შეზღუდული მოქნილობა.

და თუ თქვენს მშვიდ და მყუდრო ცხოვრებაში, როგორც DWH დეველოპერი, მოულოდნელად:

• გაჩნდა დავალება "რაღაცის გაკეთება სწრაფად და მერე ვნახოთ";
• გამოჩნდა სწრაფად განვითარებადი პროექტი, ახალი წყაროების შეერთებით და ბიზნეს მოდელის გადამუშავებით კვირაში ერთხელ მაინც;
• გამოჩნდა მომხმარებელი, რომელსაც წარმოდგენა არ აქვს, როგორი უნდა იყოს სისტემა და რა ფუნქციები უნდა შეასრულოს საბოლოოდ, მაგრამ მზად არის ექსპერიმენტისთვის და თანმიმდევრულად დახვეწოს სასურველი შედეგი და თანმიმდევრულად მიუახლოვდეს მას;
• პროექტის მენეჯერი სასიხარულო ამბით შემოვიდა: „ახლა ჩვენ გვაქვს მოქნილი!“

ან თუ უბრალოდ გაინტერესებთ იმის გარკვევა, თუ როგორ სხვაგვარად შეგიძლიათ ააშენოთ საწყობები - კეთილი იყოს თქვენი მობრძანება!

რას ნიშნავს "მოქნილობა"?

პირველ რიგში, მოდით განვსაზღვროთ რა თვისებები უნდა ჰქონდეს სისტემას, რომ ეწოდოს „მოქნილი“.

ცალკე, აღსანიშნავია, რომ აღწერილი თვისებები კონკრეტულად უნდა ეხებოდეს სისტემა, არა პროცესი მისი განვითარება. ამიტომ, თუ გსურთ წაიკითხოთ Agile, როგორც განვითარების მეთოდოლოგია, უმჯობესია წაიკითხოთ სხვა სტატიები. მაგალითად, იქ, ჰაბრეზე, ბევრი საინტერესო მასალაა (როგორიცაა მიმოხილვა и პრაქტიკულიდა პრობლემური).

ეს არ ნიშნავს იმას, რომ განვითარების პროცესი და მონაცემთა საწყობის სტრუქტურა სრულიად არ არის დაკავშირებული. მთლიანობაში, გაცილებით ადვილი უნდა იყოს სწრაფი არქიტექტურისთვის Agile საცავი. თუმცა, პრაქტიკაში, უფრო ხშირად არსებობს ვარიანტები კლასიკური DWH-ის Agile განვითარებით Kimbal-ისა და DataVault-ის მიხედვით - ჩანჩქერის მიხედვით, ვიდრე მოქნილობის ბედნიერი დამთხვევები მის ორ ფორმაში ერთ პროექტზე.

მაშ, რა შესაძლებლობები უნდა ჰქონდეს მოქნილ საცავს? აქ სამი პუნქტია:

1. ადრეული მიწოდება და სწრაფი შემობრუნება - ეს ნიშნავს, რომ იდეალურ შემთხვევაში, პირველი ბიზნეს შედეგი (მაგალითად, პირველი სამუშაო ანგარიშები) უნდა იქნას მიღებული რაც შეიძლება ადრე, ანუ მანამდეც კი, სანამ მთელი სისტემა სრულად იქნება დაპროექტებული და დანერგილი. უფრო მეტიც, ყოველი მომდევნო გადასინჯვისას ასევე უნდა დასჭირდეს რაც შეიძლება ნაკლები დრო.
2. განმეორებითი დახვეწა - ეს ნიშნავს, რომ ყოველი შემდგომი გაუმჯობესება იდეალურად არ უნდა იმოქმედოს ფუნქციონირებაზე, რომელიც უკვე მუშაობს. ეს არის ის მომენტი, რომელიც ხშირად ხდება ყველაზე დიდი კოშმარი დიდ პროექტებზე - ადრე თუ გვიან, ინდივიდუალური ობიექტები იწყებენ იმდენი კავშირის მოპოვებას, რომ უფრო ადვილი ხდება ლოგიკის სრულად გამეორება ასლთან ახლოს, ვიდრე ველის დამატება არსებულ ცხრილზე. და თუ გაგიკვირდებათ, რომ არსებულ ობიექტებზე გაუმჯობესების გავლენის ანალიზს შეიძლება უფრო მეტი დრო დასჭირდეს, ვიდრე თავად გაუმჯობესებას, სავარაუდოდ, თქვენ ჯერ არ გიმუშავიათ მონაცემთა დიდ საწყობებთან საბანკო ან ტელეკომში.
3. მუდმივად ერგება ბიზნესის ცვალებად მოთხოვნებს - ობიექტის მთლიანი სტრუქტურა უნდა იყოს შემუშავებული არა მხოლოდ შესაძლო გაფართოების გათვალისწინებით, არამედ იმ მოლოდინით, რომ ამ შემდეგი გაფართოების მიმართულებაზე არც კი შეიძლება ვიოცნებოთ დიზაინის ეტაპზე.

დიახ, ყველა ამ მოთხოვნის დაკმაყოფილება ერთ სისტემაში შესაძლებელია (რა თქმა უნდა, გარკვეულ შემთხვევებში და გარკვეული დათქმებით).

ქვემოთ განვიხილავ მონაცემთა საწყობების ორი ყველაზე პოპულარული სწრაფი დიზაინის მეთოდოლოგიას - წამყვანი მოდელი и მონაცემთა საცავი. ფრჩხილებს მიღმა დარჩა ისეთი შესანიშნავი ტექნიკა, როგორიცაა, მაგალითად, EAV, 6NF (თავის სუფთა სახით) და ყველაფერი, რაც დაკავშირებულია NoSQL გადაწყვეტილებებთან - არა იმიტომ, რომ ისინი გარკვეულწილად უარესია და არც იმიტომ, რომ ამ შემთხვევაში სტატია ემუქრება შეძენას. საშუალო დისერის მოცულობა. უბრალოდ, ეს ყველაფერი ეხება ოდნავ განსხვავებული კლასის გადაწყვეტილებებს - ან ტექნიკას, რომელიც შეგიძლიათ გამოიყენოთ კონკრეტულ შემთხვევებში, თქვენი პროექტის მთლიანი არქიტექტურის მიუხედავად (როგორიცაა EAV), ან გლობალურად ინფორმაციის შენახვის სხვა პარადიგმებს (როგორიცაა გრაფიკის მონაცემთა ბაზები). და სხვა ვარიანტები NoSQL).

„კლასიკური“ მიდგომის პრობლემები და მათი გადაწყვეტა მოქნილ მეთოდოლოგიაში

"კლასიკურ" მიდგომაში ვგულისხმობ ძველ კარგ ვარსკვლავს (მიუხედავად ქვემდებარე ფენების კონკრეტული იმპლემენტაციისა, შეიძლება მაპატიონ კიმბოლის, ინმონის და CDM-ის მიმდევრებმა).

1. კავშირების ხისტი კარდინალურობა

ეს მოდელი ეფუძნება მონაცემთა მკაფიო დაყოფას განზომილება и ფაქტები. და ეს, ჯანდაბა, ლოგიკურია - ბოლოს და ბოლოს, მონაცემთა ანალიზი შემთხვევების აბსოლუტურ უმრავლესობაში მიდის გარკვეული რიცხვითი ინდიკატორების (ფაქტების) ანალიზამდე გარკვეულ მონაკვეთებში (განზომილებაში).

ამ შემთხვევაში, ობიექტებს შორის კავშირები მყარდება უცხოური გასაღების გამოყენებით ცხრილებს შორის ურთიერთობების სახით. ეს საკმაოდ ბუნებრივად გამოიყურება, მაგრამ მაშინვე იწვევს მოქნილობის პირველ შეზღუდვას - კავშირების კარდინალურობის მკაცრი განსაზღვრა.

ეს ნიშნავს, რომ ცხრილის დიზაინის ეტაპზე, თქვენ ზუსტად უნდა განსაზღვროთ დაკავშირებული ობიექტების თითოეული წყვილი, შეუძლიათ თუ არა მათ დაკავშირება მრავალი-მრავალთან, ან მხოლოდ 1-მრავალთან და „რომელი მიმართულებით“. ეს პირდაპირ განსაზღვრავს, თუ რომელ ცხრილს ექნება პირველადი გასაღები და რომელს ექნება უცხო გასაღები. ამ დამოკიდებულების შეცვლა ახალი მოთხოვნების მიღებისას, სავარაუდოდ, გამოიწვევს ბაზის გადამუშავებას.

მაგალითად, "ნაღდი ფულის ქვითრის" ობიექტის დაპროექტებისას, თქვენ, გაყიდვების განყოფილების ფიცებზე დაყრდნობით, განისაზღვრეთ მოქმედების შესაძლებლობა. ერთი დაწინაურება რამდენიმე საკონტროლო პოზიციისთვის (მაგრამ არა პირიქით):

და გარკვეული პერიოდის შემდეგ, კოლეგებმა შემოიღეს ახალი მარკეტინგული სტრატეგია, რომელშიც მათ შეუძლიათ იმოქმედონ იმავე პოზიციაზე რამდენიმე აქცია ერთდროულად. და ახლა თქვენ უნდა შეცვალოთ ცხრილები ურთიერთობის ცალკეულ ობიექტად გამოყოფით.

(ყველა მიღებული ობიექტი, რომლებშიც ახლა არის შეერთებული სარეკლამო ჩეკი, ასევე საჭიროებს გაუმჯობესებას).

ურთიერთობები მონაცემთა სარდაფში და წამყვან მოდელში

ამ სიტუაციის თავიდან აცილება საკმაოდ მარტივი აღმოჩნდა: თქვენ არ უნდა ენდოთ გაყიდვების განყოფილებას ამის გასაკეთებლად. ყველა კავშირი თავდაპირველად ინახება ცალკეულ ცხრილებში და დაამუშავეთ როგორც ბევრი-მრავალზე.

ეს მიდგომა იყო შემოთავაზებული დენ ლინსტედტი როგორც პარადიგმის ნაწილი მონაცემთა საცავი და სრული მხარდაჭერა ლარს რონბეკი в წამყვანი მოდელი.

შედეგად, ჩვენ ვიღებთ მოქნილი მეთოდოლოგიების პირველ განმასხვავებელ მახასიათებელს:

ობიექტებს შორის ურთიერთობები არ ინახება მშობელი ერთეულების ატრიბუტებში, მაგრამ არის ცალკეული ტიპის ობიექტი.

В მონაცემთა საცავი ასეთ დამაკავშირებელ ცხრილებს ე.წ ბმულიდა წამყვანი მოდელი - Tie. ერთი შეხედვით ძალიან ჰგვანან ერთმანეთს, თუმცა მათი განსხვავებები სახელით არ მთავრდება (რაზეც ქვემოთ იქნება განხილული). ორივე არქიტექტურაში ბმულის ცხრილებს შეუძლიათ დაკავშირება ნებისმიერი რაოდენობის სუბიექტები (არ არის აუცილებელი 2).

ეს სიჭარბე, ერთი შეხედვით, იძლევა მნიშვნელოვან მოქნილობას ცვლილებებისთვის. ასეთი სტრუქტურა ხდება ტოლერანტული არა მხოლოდ არსებული ბმულების კარდინალურობის ცვლილებებთან, არამედ ახლის დამატებით - თუ ახლა საკონტროლო პოზიციას ასევე აქვს ბმული მოლარესთან, რომელმაც გახსნა იგი, ასეთი ბმულის გამოჩენა უბრალოდ გახდება. დანამატი არსებულ ცხრილებზე ზემოქმედების გარეშე არსებულ ობიექტებსა და პროცესებზე.

2. მონაცემთა დუბლირება

მოქნილი არქიტექტურებით გადაჭრილი მეორე პრობლემა ნაკლებად აშკარაა და პირველ რიგში თანდაყოლილია. SCD2 ტიპის გაზომვები (ნელა იცვლება მეორე ტიპის ზომები), თუმცა არა მხოლოდ ისინი.

კლასიკურ საწყობში, განზომილება, როგორც წესი, არის ცხრილი, რომელიც შეიცავს სუროგატ გასაღებს (როგორც PK) და ბიზნეს გასაღებებისა და ატრიბუტების ერთობლიობას ცალკეულ სვეტებში.

თუ განზომილება მხარს უჭერს ვერსიებს, ვერსიის მოქმედების საზღვრები ემატება ველების სტანდარტულ კომპლექტს და რამდენიმე ვერსია გამოჩნდება საცავში წყაროს ერთი რიგისთვის (თითო ვერსიული ატრიბუტების თითოეული ცვლილებისთვის).

თუ განზომილება შეიცავს მინიმუმ ერთ ხშირად ცვალებად ვერსიულ ატრიბუტს, ასეთი განზომილების ვერსიების რაოდენობა შთამბეჭდავი იქნება (მაშინაც კი, თუ დარჩენილი ატრიბუტები არ არის ვერსიირებული ან არასდროს იცვლება), და თუ არსებობს რამდენიმე ასეთი ატრიბუტი, ვერსიების რაოდენობა შეიძლება იზრდება ექსპონენტურად მათი რიცხვიდან. ამ განზომილებას შეუძლია დაიკავოს მნიშვნელოვანი ადგილი დისკზე, თუმცა მისი შენახული მონაცემების უმეტესობა უბრალოდ სხვა რიგებიდან უცვლელი ატრიბუტების მნიშვნელობების დუბლიკატია.

ამავე დროს, ის ასევე ძალიან ხშირად გამოიყენება დენორმალიზაცია — ზოგიერთი ატრიბუტი განზრახ ინახება როგორც მნიშვნელობა და არა როგორც საცნობარო წიგნის ან სხვა განზომილების ბმული. ეს მიდგომა აჩქარებს მონაცემთა წვდომას, ამცირებს შეერთების რაოდენობას განზომილებაში წვდომისას.

როგორც წესი, ეს იწვევს ერთი და იგივე ინფორმაცია ინახება რამდენიმე ადგილას ერთდროულად. მაგალითად, ინფორმაცია საცხოვრებელი რეგიონისა და კლიენტის კატეგორიის შესახებ შეიძლება ერთდროულად ინახებოდეს "კლიენტის" ზომებში და "შეძენის", "მიწოდების" და "ზარების ცენტრის" ფაქტებში, ასევე "კლიენტი - კლიენტის მენეჯერი". ” ბმული ცხრილი.

ზოგადად, ზემოთ აღწერილი ეხება რეგულარულ (არავერსიულ) ზომებს, მაგრამ ვერსიებში მათ შეიძლება ჰქონდეთ განსხვავებული მასშტაბი: ობიექტის ახალი ვერსიის გაჩენა (განსაკუთრებით რეტროსპექტივაში) იწვევს არა მხოლოდ ყველა დაკავშირებულის განახლებას. ცხრილები, მაგრამ დაკავშირებული ობიექტების ახალი ვერსიების კასკადური გარეგნობისთვის - როდესაც ცხრილი 1 გამოიყენება ცხრილი 2-ის ასაგებად, ხოლო ცხრილი 2 გამოიყენება ცხრილი 3-ის შესაქმნელად და ა.შ. მაშინაც კი, თუ ცხრილის 1-ის არც ერთი ატრიბუტი არ არის ჩართული ცხრილის 3-ის მშენებლობაში (და ჩართულია მე-2 ცხრილის სხვა ატრიბუტები, რომლებიც მიღებულია სხვა წყაროებიდან), ამ კონსტრუქციის ვერსიების შეცვლა მინიმუმამდე გამოიწვევს დამატებით ზედნადებს, ხოლო მაქსიმუმ დამატებით დამატებით ხარჯებს. ვერსიები ცხრილში 3. რომელსაც საერთოდ არაფერი აქვს საერთო და უფრო ქვევით ჯაჭვში.

3. გადამუშავების არაწრფივი სირთულე

ამავდროულად, მეორის ბაზაზე აგებული ყოველი ახალი ვიტრინა ზრდის იმ ადგილების რაოდენობას, სადაც მონაცემები შეიძლება „განსხვავდებოდეს“ ETL-ში ცვლილებების შეტანისას. ეს, თავის მხრივ, იწვევს ყოველი შემდგომი გადასინჯვის სირთულის (და ხანგრძლივობის) ზრდას.

თუ ზემოაღნიშნული აღწერს სისტემებს იშვიათად შეცვლილი ETL პროცესებით, თქვენ შეგიძლიათ იცხოვროთ ასეთ პარადიგმაში - თქვენ უბრალოდ უნდა დარწმუნდეთ, რომ ახალი ცვლილებები სწორად არის შეტანილი ყველა დაკავშირებულ ობიექტზე. თუ გადასინჯვები ხშირად ხდება, რამდენიმე კავშირის შემთხვევით „გამოტოვების“ ალბათობა მნიშვნელოვნად იზრდება.

გარდა ამისა, თუ გავითვალისწინებთ, რომ „ვერსიული“ ETL მნიშვნელოვნად უფრო რთულია, ვიდრე „არავერსიული“, საკმაოდ რთული ხდება შეცდომების თავიდან აცილება მთელი ამ ობიექტის ხშირი განახლებისას.

ობიექტებისა და ატრიბუტების შენახვა Data Vault-სა და Anchor Model-ში

მოქნილი არქიტექტურის ავტორების მიერ შემოთავაზებული მიდგომა შეიძლება ჩამოყალიბდეს შემდეგნაირად:

აუცილებელია განვასხვავოთ ის, რაც იცვლება, რაც იგივე რჩება. ანუ შეინახეთ გასაღებები ატრიბუტებისაგან განცალკევებით.

თუმცა, არ უნდა აგვერიოს არ არის ვერსია ატრიბუტით უცვლელი: პირველი არ ინახავს მისი ცვლილებების ისტორიას, მაგრამ შეიძლება შეიცვალოს (მაგალითად, შეყვანის შეცდომის გამოსწორებისას ან ახალი მონაცემების მიღებისას); მეორე არასოდეს იცვლება.

თვალსაზრისები განსხვავდება იმის შესახებ, თუ რა შეიძლება ჩაითვალოს უცვლელად მონაცემთა საცავში და წამყვან მოდელში.

არქიტექტურული თვალსაზრისით მონაცემთა საცავი, შეიძლება ჩაითვალოს უცვლელად გასაღებების მთელი ნაკრები - ბუნებრივი (ორგანიზაციის TIN, პროდუქტის კოდი წყაროს სისტემაში და ა.შ.) და სუროგატი. ამ შემთხვევაში, დარჩენილი ატრიბუტები შეიძლება დაიყოს ჯგუფებად ცვლილებების წყაროს და/ან სიხშირის მიხედვით და შეინახეთ ცალკე ცხრილი თითოეული ჯგუფისთვის ვერსიების დამოუკიდებელი ნაკრებით.

პარადიგმაში წამყვანი მოდელი ითვლება უცვლელად მხოლოდ სუროგატი გასაღები არსი. ყველაფერი დანარჩენი (მათ შორის ბუნებრივი გასაღებები) მისი ატრიბუტების მხოლოდ განსაკუთრებული შემთხვევაა. სადაც ყველა ატრიბუტი ნაგულისხმევად ერთმანეთისგან დამოუკიდებელია, ასე რომ თითოეული ატრიბუტისთვის ა ცალკე მაგიდა.

В მონაცემთა საცავი ერთეულის გასაღებების შემცველი ცხრილები ეწოდება ჰუბამი. ჰაბები ყოველთვის შეიცავს ველების ფიქსირებულ კომპლექტს:

• ბუნებრივი პირის გასაღებები
• სუროგატი გასაღები
• ბმული წყაროსთან
• ჩაწერეთ დამატების დრო

პოსტები ჰაბებში არასოდეს შეიცვალოს და არ ჰქონდეს ვერსიები. გარეგნულად, ჰაბები ძალიან ჰგავს ID-რუქის ტიპის ცხრილებს, რომლებიც გამოიყენება ზოგიერთ სისტემაში სუროგატების გენერირებისთვის, თუმცა რეკომენდებულია ჰაშის გამოყენება ბიზნეს კლავიშების ნაკრებიდან, როგორც სუროგატები Data Vault-ში. ეს მიდგომა ამარტივებს ურთიერთობებისა და ატრიბუტების ჩატვირთვას წყაროებიდან (არ არის საჭირო ჰაბთან შეერთება სუროგატის მისაღებად, უბრალოდ გამოთვალეთ ბუნებრივი გასაღების ჰეში), მაგრამ შეიძლება გამოიწვიოს სხვა პრობლემები (დაკავშირებული, მაგალითად, შეჯახებასთან, ქეისთან და დაუბეჭდავად სიმბოლოები სიმებიანი კლავიშებში და ა.შ.

ყველა სხვა ერთეული ატრიბუტი ინახება სპეციალურ ცხრილებში, სახელწოდებით თანამგზავრები. ერთ კერას შეიძლება ჰქონდეს რამდენიმე თანამგზავრი, რომლებიც ინახავს ატრიბუტების სხვადასხვა კომპლექტს.

ატრიბუტების განაწილება თანამგზავრებს შორის ხდება პრინციპის მიხედვით ერთობლივი ცვლილება - ერთ თანამგზავრში შეიძლება ინახებოდეს არავერსიული ატრიბუტები (მაგალითად, დაბადების თარიღი და SNILS ინდივიდისთვის), მეორეში - იშვიათად ცვალებადი ვერსიები (მაგალითად, გვარი და პასპორტის ნომერი), მესამეში - ხშირად ცვალებადი. (მაგალითად, მიწოდების მისამართი, კატეგორია, ბოლო შეკვეთის თარიღი და ა.შ.). ამ შემთხვევაში, ვერსიირება ხორციელდება ცალკეული თანამგზავრების დონეზე და არა მთლიანი ერთეულის დონეზე, ამიტომ მიზანშეწონილია ატრიბუტების განაწილება ისე, რომ ვერსიების გადაკვეთა ერთ თანამგზავრში მინიმალური იყოს (რაც ამცირებს შენახული ვერსიების საერთო რაოდენობას. ).

ასევე, მონაცემთა ჩატვირთვის პროცესის ოპტიმიზაციის მიზნით, სხვადასხვა წყაროდან მიღებული ატრიბუტები ხშირად შედის ცალკეულ თანამგზავრებში.

სატელიტები დაუკავშირდებიან ჰაბს მეშვეობით უცხოური გასაღები (რაც შეესაბამება 1-დან ბევრ კარდინალობას). ეს ნიშნავს, რომ მრავალი ატრიბუტის მნიშვნელობა (მაგალითად, მრავალი საკონტაქტო ტელეფონის ნომერი ერთი კლიენტისთვის) მხარდაჭერილია ამ „ნაგულისხმევი“ არქიტექტურით.

В წამყვანი მოდელი მაგიდები, რომლებიც ინახავს გასაღებებს, ეწოდება წამყვანები. და ინახავენ:

• მხოლოდ სუროგატული გასაღებები
• ბმული წყაროსთან
• ჩაწერეთ დამატების დრო

განიხილება ბუნებრივი გასაღებები წამყვანი მოდელის თვალსაზრისით ჩვეულებრივი ატრიბუტები. ეს ვარიანტი შეიძლება უფრო რთულად გასაგები ჩანდეს, მაგრამ ის გაცილებით მეტ შესაძლებლობებს აძლევს ობიექტის იდენტიფიკაციას.

მაგალითად, თუ ერთი და იგივე ერთეულის შესახებ მონაცემები შეიძლება მოდიოდეს სხვადასხვა სისტემებიდან, რომელთაგან თითოეული იყენებს საკუთარ ბუნებრივ გასაღებს. Data Vault-ში ამან შეიძლება გამოიწვიოს რამდენიმე ჰაბის საკმაოდ შრომატევადი სტრუქტურა (ერთი თითო წყაროზე + გამაერთიანებელი სამაგისტრო ვერსია), ხოლო Anchor მოდელში თითოეული წყაროს ბუნებრივი გასაღები ხვდება საკუთარ ატრიბუტში და შეიძლება გამოყენებულ იქნას დამოუკიდებლად ჩატვირთვისას. ყველა დანარჩენი.

მაგრამ აქ არის ერთი მზაკვრული მომენტიც: თუ სხვადასხვა სისტემის ატრიბუტები გაერთიანებულია ერთ ერთეულში, სავარაუდოდ, არსებობს რამდენიმე "წებოვნების" წესები, რომლითაც სისტემამ უნდა გააცნობიეროს, რომ სხვადასხვა წყაროდან ჩანაწერები შეესაბამება ერთეულის ერთ ინსტანციას.

В მონაცემთა საცავი ეს წესები, სავარაუდოდ, განსაზღვრავს ფორმირებას სამაგისტრო ერთეულის „სუროგატული კერა“. და არანაირად არ მოახდინოს გავლენა ჰაბებზე, რომლებიც ინახავს ბუნებრივი წყაროს გასაღებებს და მათ ორიგინალურ ატრიბუტებს. თუ რაღაც მომენტში შეიცვლება შერწყმის წესები (ან განახლდება ის ატრიბუტები, რომლითაც იგი შესრულდება), საკმარისი იქნება სუროგატული ჰაბების რეფორმირება.

В წამყვანი მოდელი ასეთი ერთეული, სავარაუდოდ, შეინახება ერთადერთი წამყვანი. ეს ნიშნავს, რომ ყველა ატრიბუტი, არ აქვს მნიშვნელობა რა წყაროდან მოდის, ერთსა და იმავე სუროგატთან იქნება დაკავშირებული. შეცდომით შერწყმული ჩანაწერების გამიჯვნა და, ზოგადად, ასეთ სისტემაში გაერთიანების შესაბამისობის მონიტორინგი შეიძლება ბევრად უფრო რთული იყოს, განსაკუთრებით იმ შემთხვევაში, თუ წესები საკმაოდ რთულია და ხშირად იცვლება და იგივე ატრიბუტის მიღება შესაძლებელია სხვადასხვა წყაროდან (თუმცა, რა თქმა უნდა, შესაძლებელია, რადგან თითოეული ატრიბუტის ვერსია ინარჩუნებს ბმულს მის წყაროსთან).

ნებისმიერ შემთხვევაში, თუ თქვენმა სისტემამ უნდა განახორციელოს ფუნქციონირება დედუპლიკაცია, ჩანაწერების შერწყმა და სხვა MDM ელემენტები, ღირს განსაკუთრებული ყურადღების მიქცევა სწრაფი მეთოდოლოგიებში ბუნებრივი გასაღებების შენახვის ასპექტებზე. სავარაუდოა, რომ Data Vault-ის უფრო დიდი დიზაინი უცებ უფრო უსაფრთხო იქნება შერწყმის შეცდომების თვალსაზრისით.

წამყვანი მოდელი ასევე უზრუნველყოფს დამატებით ობიექტის ტიპს ე.წ კვანძი ის არსებითად განსაკუთრებულია დეგენერაციული ტიპის წამყვანი, რომელიც შეიძლება შეიცავდეს მხოლოდ ერთ ატრიბუტს. კვანძები უნდა იქნას გამოყენებული ბრტყელი დირექტორიების შესანახად (მაგალითად, სქესი, ოჯახური მდგომარეობა, მომხმარებელთა მომსახურების კატეგორია და ა.შ.). წამყვანისგან განსხვავებით, კვანძი არ აქვს დაკავშირებული ატრიბუტების ცხრილები, და მისი ერთადერთი ატრიბუტი (სახელი) ყოველთვის ინახება იმავე ცხრილში გასაღებით. კვანძები უკავშირდებიან წამყვანებს ჰალსტუხი ცხრილებით (Tie) ისევე, როგორც ანკორები ერთმანეთთან.

არ არსებობს მკაფიო მოსაზრება კვანძების გამოყენებასთან დაკავშირებით. Მაგალითად, ნიკოლაი გოლოვი, რომელიც აქტიურად უჭერს მხარს წამყვანი მოდელის გამოყენებას რუსეთში, თვლის (არა უსაფუძვლოდ), რომ არც ერთი საცნობარო წიგნისთვის არ შეიძლება დარწმუნებით ითქვას, რომ ყოველთვის იქნება სტატიკური და ერთ დონის, ამიტომ უმჯობესია დაუყოვნებლივ გამოიყენოთ სრულფასოვანი წამყვანი ყველა ობიექტისთვის.

კიდევ ერთი მნიშვნელოვანი განსხვავება Data Vault-სა და Anchor მოდელს შორის არის ხელმისაწვდომობა კავშირების ატრიბუტები:

В მონაცემთა საცავი ბმულები არის იგივე სრულფასოვანი ობიექტები, როგორც ჰაბები და შეიძლება ჰქონდეს საკუთარი ატრიბუტები. In წამყვანი მოდელი ბმულები გამოიყენება მხოლოდ წამყვანების დასაკავშირებლად და არ შეიძლება ჰქონდეს საკუთარი ატრიბუტები. ეს განსხვავება იწვევს მნიშვნელოვნად განსხვავებულ მოდელირების მიდგომებს ფაქტები, რომელიც შემდგომში იქნება განხილული.

ფაქტების შენახვა

მანამდე ძირითადად ვსაუბრობდით გაზომვის მოდელირებაზე. ფაქტები ცოტა ნაკლებად ნათელია.

В მონაცემთა საცავი ფაქტების შესანახი ტიპიური ობიექტია Ბმული, რომლის თანამგზავრებშიც ემატება რეალური მაჩვენებლები.

ეს მიდგომა ინტუიციური ჩანს. ის უზრუნველყოფს მარტივ წვდომას გაანალიზებულ ინდიკატორებზე და ზოგადად ჰგავს ტრადიციულ ფაქტების ცხრილს (მხოლოდ ინდიკატორები ინახება არა თავად ცხრილში, არამედ "მეზობელ"). მაგრამ არის ხარვეზებიც: მოდელის ერთ-ერთი ტიპიური მოდიფიკაცია - ფაქტის გასაღების გაფართოება - საჭიროებს ლინკზე ახალი უცხო გასაღების დამატება. და ეს, თავის მხრივ, "არღვევს" მოდულარობას და პოტენციურად იწვევს სხვა ობიექტების მოდიფიკაციის საჭიროებას.

В წამყვანი მოდელი კავშირს არ შეიძლება ჰქონდეს საკუთარი ატრიბუტები, ამიტომ ეს მიდგომა არ იმუშავებს - აბსოლუტურად ყველა ატრიბუტი და ინდიკატორი უნდა იყოს დაკავშირებული ერთ კონკრეტულ წამყვანთან. აქედან დასკვნა მარტივია - თითოეულ ფაქტს ასევე სჭირდება საკუთარი წამყვანი. ზოგიერთისთვის, რასაც ჩვენ მიჩვეული ვართ ფაქტებად აღქმას, ეს შეიძლება ბუნებრივად გამოიყურებოდეს - მაგალითად, შეძენის ფაქტი შეიძლება შესანიშნავად შემცირდეს ობიექტზე „შეკვეთა“ ან „მიღება“, საიტის მონახულება სესიაზე და ა.შ. მაგრამ ასევე არის ფაქტები, რომლებისთვისაც არც ისე ადვილია ასეთი ბუნებრივი "გადამზიდავი ობიექტის" პოვნა - მაგალითად, საქონლის ნაშთები საწყობებში ყოველი დღის დასაწყისში.

შესაბამისად, Anchor-ის მოდელში ფაქტების გასაღების გაფართოებისას მოდულარობის პრობლემები არ წარმოიქმნება (საკმარისია უბრალოდ დაამატოთ ახალი ურთიერთობა შესაბამის წამყვანს), მაგრამ ფაქტების საჩვენებლად მოდელის დაპროექტება ნაკლებად ცალსახაა; შეიძლება გამოჩნდეს „ხელოვნური“ წამყვანები. რომლებიც აჩვენებენ ბიზნეს ობიექტის მოდელს გაურკვეველად.

როგორ მიიღწევა მოქნილობა

შედეგად მიღებული კონსტრუქცია ორივე შემთხვევაში შეიცავს მნიშვნელოვნად მეტი ცხრილივიდრე ტრადიციული გაზომვა. მაგრამ შეიძლება დასჭირდეს მნიშვნელოვნად ნაკლები ადგილი დისკზე ვერსიირებული ატრიბუტების იგივე ნაკრებით, როგორც ტრადიციული განზომილება. ბუნებრივია, აქ ჯადოქრობა არ არის - ეს ყველაფერი ნორმალიზებაა. ატრიბუტების განაწილებით თანამგზავრებზე (მონაცემთა საცავში) ან ცალკეულ ცხრილებზე (ანკორის მოდელი), ჩვენ ვამცირებთ (ან მთლიანად აღმოვფხვრით) ზოგიერთი ატრიბუტის მნიშვნელობების დუბლირება სხვების შეცვლისას.

იყიდება მონაცემთა საცავი მოგება დამოკიდებული იქნება ატრიბუტების განაწილებაზე თანამგზავრებს შორის და ამისთვის წამყვანი მოდელი - თითქმის პირდაპირპროპორციულია ვერსიების საშუალო რაოდენობის საზომ ობიექტზე.

თუმცა, სივრცის დაზოგვა ატრიბუტების ცალკე შენახვის მნიშვნელოვანი, მაგრამ არა მთავარი უპირატესობაა. ურთიერთობების ცალკე შენახვასთან ერთად, ეს მიდგომა ქმნის მაღაზიას მოდულური დიზაინი. ეს ნიშნავს, რომ ამ მოდელში ინდივიდუალური ატრიბუტებისა და მთელი ახალი საგნის არეების დამატება ჰგავს ზედატრუქტურა ობიექტების არსებულ კომპლექტზე მათი შეცვლის გარეშე. და ეს არის ზუსტად ის, რაც აღწერილ მეთოდოლოგიებს მოქნილს ხდის.

ეს ასევე წააგავს ცალი წარმოებიდან მასობრივ წარმოებაზე გადასვლას - თუ ტრადიციული მიდგომით მოდელის თითოეული ცხრილი უნიკალურია და განსაკუთრებულ ყურადღებას მოითხოვს, მაშინ მოქნილ მეთოდოლოგიაში ეს უკვე არის სტანდარტული "ნაწილების" ნაკრები. ერთის მხრივ, მეტი ცხრილია და მონაცემების ჩატვირთვისა და მოპოვების პროცესები უფრო რთული უნდა გამოიყურებოდეს. მეორეს მხრივ, ისინი ხდებიან ტიპიური. რაც ნიშნავს რომ შეიძლება იყოს ავტომატიზირებული და მეტამონაცემებზე ორიენტირებული. კითხვა „როგორ დავდებთ მას?“, რომლის პასუხმა შეიძლება დაიკავოს სამუშაოს მნიშვნელოვანი ნაწილი გაუმჯობესების დიზაინზე, ახლა უბრალოდ არ ღირს (ასევე კითხვა სამუშაო პროცესებზე მოდელის შეცვლის გავლენის შესახებ. ).

ეს არ ნიშნავს, რომ ანალიტიკოსები საერთოდ არ არის საჭირო ასეთ სისტემაში - ვიღაცას მაინც უნდა იმუშაოს ატრიბუტების მქონე ობიექტების ნაკრებში და გაარკვიოს, სად და როგორ ჩატვირთოს ეს ყველაფერი. მაგრამ სამუშაოს მოცულობა, ისევე როგორც შეცდომის ალბათობა და ღირებულება, მნიშვნელოვნად მცირდება. როგორც ანალიზის ეტაპზე, ასევე ETL-ის შემუშავების დროს, რაც მნიშვნელოვან ნაწილს შეიძლება შემცირდეს მეტამონაცემების რედაქტირებამდე.

ბნელი მხარე

ყოველივე ზემოაღნიშნული ხდის ორივე მიდგომას მართლაც მოქნილ, ტექნოლოგიურად მოწინავე და შესაფერისს განმეორებითი გაუმჯობესებისთვის. რა თქმა უნდა, არის "კასრი მალამოში", რომლის შესახებაც ვფიქრობ უკვე შეგიძლიათ გამოიცნოთ.

მონაცემთა დაშლა, რომელიც საფუძვლად უდევს მოქნილი არქიტექტურის მოდულარობას, იწვევს ცხრილების რაოდენობის ზრდას და, შესაბამისად, ზედნადები შეერთება ნიმუშის აღებისას. იმისათვის, რომ უბრალოდ მიიღოთ განზომილების ყველა ატრიბუტი, კლასიკურ მაღაზიაში საკმარისია ერთი არჩევანი, მაგრამ მოქნილი არქიტექტურა მოითხოვს შეერთების მთელ სერიას. უფრო მეტიც, თუ ანგარიშებისთვის ყველა ეს შეერთება შეიძლება წინასწარ დაიწეროს, მაშინ ანალიტიკოსები, რომლებიც მიჩვეულნი არიან SQL-ის ხელით წერას, ორმაგად დაზარალდებიან.

არსებობს რამდენიმე ფაქტი, რომელიც ამარტივებს სიტუაციას:

დიდი ზომებით მუშაობისას, მისი ყველა ატრიბუტი თითქმის არასოდეს გამოიყენება ერთდროულად. ეს ნიშნავს, რომ შეიძლება იყოს ნაკლები შეერთება, ვიდრე ერთი შეხედვით ჩანს მოდელზე. Data Vault-ს ასევე შეუძლია გაითვალისწინოს გაზიარების მოსალოდნელი სიხშირე თანამგზავრებზე ატრიბუტების განაწილებისას. ამავდროულად, თავად Hubs ან Anchors საჭიროა ძირითადად ჩატვირთვის ეტაპზე სუროგატების გენერირებისთვის და რუკების შესაქმნელად და იშვიათად გამოიყენება შეკითხვებში (ეს განსაკუთრებით ეხება Anchors-ს).

ყველა შეერთება ხდება გასაღებით. გარდა ამისა, მონაცემთა შენახვის უფრო „შეკუმშული“ გზა ამცირებს ცხრილების სკანირების ხარჯს, სადაც ეს საჭიროა (მაგალითად, ატრიბუტის მნიშვნელობის მიხედვით ფილტრაციისას). ამან შეიძლება გამოიწვიოს ის ფაქტი, რომ ნიმუშების აღება ნორმალიზებული მონაცემთა ბაზიდან რამდენიმე შეერთებით კიდევ უფრო სწრაფი იქნება, ვიდრე ერთი მძიმე განზომილების სკანირება მწკრივში მრავალი ვერსიით.

მაგალითად, აქ ამ სტატიაში მოცემულია Anchor მოდელის მუშაობის დეტალური შედარებითი ტესტი ერთი ცხრილის ნიმუშით.

ბევრი რამ არის დამოკიდებული ძრავაზე. ბევრ თანამედროვე პლატფორმას აქვს შიდა შეერთების ოპტიმიზაციის მექანიზმები. მაგალითად, MS SQL-ს და Oracle-ს შეუძლიათ "გამოტოვონ" შეერთებები ცხრილებთან, თუ მათი მონაცემები არ გამოიყენება სადმე, გარდა სხვა შეერთებისა და არ იმოქმედებს საბოლოო შერჩევაზე (ცხრილი/შეერთების აღმოფხვრა) და MPP Vertica. Avito-ს კოლეგების გამოცდილება, დაამტკიცა, რომ არის შესანიშნავი ძრავა Anchor Model-ისთვის, შეკითხვის გეგმის გარკვეული ხელით ოპტიმიზაციის გათვალისწინებით. მეორეს მხრივ, Anchor Model-ის შენახვა, მაგალითად, Click House-ზე, რომელსაც აქვს შეზღუდული შეერთების მხარდაჭერა, ჯერ კიდევ არ გამოიყურება ძალიან კარგი იდეა.

გარდა ამისა, ორივე არქიტექტურისთვის არსებობს სპეციალური მოძრაობებიაადვილებს მონაცემებზე წვდომას (როგორც შეკითხვის შესრულების თვალსაზრისით, ასევე საბოლოო მომხმარებლებისთვის). Მაგალითად, წერტილოვანი ცხრილები მონაცემთა სარდაფში ან მაგიდის სპეციალური ფუნქციები Anchor-ის მოდელში.

საერთო ჯამში

განხილული მოქნილი არქიტექტურების მთავარი არსი არის მათი „დიზაინის“ მოდულურობა.

სწორედ ეს თვისება იძლევა საშუალებას:

• მეტამონაცემების გავრცელებასთან და ძირითადი ETL ალგორითმების დაწერის გარკვეული საწყისი მომზადების შემდეგ, სწრაფად მიაწოდოს მომხმარებელს პირველი შედეგი რამდენიმე მოხსენების სახით, რომელიც შეიცავს მონაცემებს მხოლოდ რამდენიმე წყაროს ობიექტიდან. არ არის აუცილებელი მთლიანად დაფიქრდეს (თუნდაც უმაღლეს დონეზე) მთელი ობიექტის მოდელი.
• მონაცემთა მოდელმა შეიძლება დაიწყოს მუშაობა (და სასარგებლო იყოს) მხოლოდ 2-3 ობიექტით და შემდეგ იზრდება თანდათან (რაც შეეხება წამყვანის მოდელ ნიკოლაის გამოყენებითი კარგი შედარება მიცელიუმთან).
• გაუმჯობესების უმეტესობა, მათ შორის საგნის არეალის გაფართოება და ახალი წყაროების დამატება არ ახდენს გავლენას არსებულ ფუნქციონირებაზე და არ წარმოადგენს რისკს, დაარღვიოს ის, რაც უკვე მუშაობს.
• სტანდარტულ ელემენტებად დაშლის წყალობით, ETL პროცესები ასეთ სისტემებში ერთნაირად გამოიყურება, მათი ჩაწერა ექვემდებარება ალგორითმიზაციას და, საბოლოო ჯამში, ავტომატიზაცია.

ამ მოქნილობის ფასია შესრულება. ეს არ ნიშნავს, რომ შეუძლებელია ასეთ მოდელებზე მისაღები შესრულების მიღწევა. უფრო ხშირად, ვიდრე არა, შეიძლება უბრალოდ დაგჭირდეთ მეტი ძალისხმევა და ყურადღება დეტალებზე, რათა მიაღწიოთ სასურველ მეტრებს.

პროგრამები

ერთეულის ტიპები მონაცემთა საცავი

დამატებითი ინფორმაცია Data Vault-ის შესახებ:
დენ ლისტადტის ვებსაიტზე
ყველაფერი მონაცემთა სარდაფის შესახებ რუსულ ენაზე
შესახებ მონაცემთა Vault on Habré

ერთეულის ტიპები წამყვანი მოდელი

დამატებითი ინფორმაცია წამყვანი მოდელის შესახებ:

Anchor Model-ის შემქმნელების საიტი
სტატია Anchor Model-ის დანერგვის გამოცდილების შესახებ Avito-ში

შემაჯამებელი ცხრილი განხილული მიდგომების საერთო მახასიათებლებით და განსხვავებებით:

წყარო: www.habr.com