Agile DWH डिजाइन विधिहरूको सिंहावलोकन

भण्डारण सुविधाको विकास गर्नु लामो र गम्भीर कार्य हो।

परियोजनाको जीवनमा धेरै कुरा निर्भर गर्दछ कि वस्तुको मोडेल र आधार संरचना सुरुमा कति राम्रोसँग सोचिएको छ।

तारा योजनालाई तेस्रो सामान्य रूपको साथ संयोजन गर्ने विभिन्न प्रकारहरू सामान्य रूपमा स्वीकृत गरिएको छ र रहन्छ। एक नियमको रूपमा, सिद्धान्त अनुसार: प्रारम्भिक डाटा - 3NF, शोकेस - तारा। यो दृष्टिकोण, समय-परीक्षण र अनुसन्धान को एक ठूलो मात्रा द्वारा समर्थित, पहिलो (र कहिले काँही एक मात्र) कुरा हो जुन एक अनुभवी DWH विशेषज्ञ को दिमागमा आउँछ जब एक विश्लेषणात्मक भण्डार कस्तो हुनुपर्छ भन्ने बारे सोच्दै।

अर्कोतर्फ, सामान्य रूपमा व्यापार र विशेष रूपमा ग्राहक आवश्यकताहरू चाँडै परिवर्तन हुन्छन्, र डेटा दुवै "गहिराइमा" र "चौडाइमा" बढ्छ। र यो जहाँ तारा को मुख्य हानि देखिन्छ - सीमित लचकता.

र यदि तपाईको शान्त र आरामदायी जीवनमा DWH विकासकर्ताको रूपमा अचानक:

• कार्य उठ्यो "कम से कम केहि छिटो गर्न को लागी, र त्यसपछि हामी देख्नेछौं";
• नयाँ स्रोतहरूको जडान र कम्तिमा हप्तामा एक पटक व्यापार मोडेलको पुन: कार्यको साथ, द्रुत रूपमा विकास भइरहेको परियोजना देखा पर्‍यो;
• एउटा ग्राहक देखा परेको छ जसलाई प्रणाली कस्तो देखिनु पर्छ र यसले अन्ततः कस्तो प्रकार्यहरू प्रदर्शन गर्नुपर्छ भन्ने कुरा थाहा छैन, तर प्रयोग गर्न तयार छ र लगातार यसको नजिक पुग्दा इच्छित परिणामलाई परिष्कृत गर्न तयार छ;
• परियोजना प्रबन्धकले सुसमाचारको साथ छोडे: "र अब हामीसँग फुर्तिलो छ!"

वा यदि तपाईं अरू कसरी भण्डारण सुविधाहरू निर्माण गर्न सक्नुहुन्छ भनेर पत्ता लगाउन चाहानुहुन्छ भने - कटमा स्वागत छ!

"लचकता" को अर्थ के हो?

पहिले, "लचिलो" भनिने प्रणालीमा कुन गुणहरू हुनुपर्छ भनेर परिभाषित गरौं।

अलग रूपमा, यो उल्लेख गर्न लायक छ कि वर्णित गुणहरू विशेष रूपमा सम्बन्धित हुनुपर्छ प्रणाली, होइन प्रक्रिया यसको विकास। तसर्थ, यदि तपाइँ विकास पद्धतिको रूपमा Agile को बारेमा पढ्न चाहानुहुन्छ भने, यो अन्य लेखहरू पढ्न राम्रो छ। उदाहरणका लागि, त्यहाँ, Habré मा, त्यहाँ धेरै रोचक सामग्रीहरू छन् (जस्तै समीक्षा и व्यावहारिक, र समस्याग्रस्त).

यसको मतलब यो होइन कि विकास प्रक्रिया र डाटा गोदामको संरचना पूर्ण रूपमा असंबद्ध छ। समग्रमा, फुर्तिलो वास्तुकलाको लागि एजाइल रिपोजिटरी विकास गर्न यो महत्त्वपूर्ण रूपमा सजिलो हुनुपर्छ। जे होस्, अभ्यासमा, किम्बल र डाटाभल्ट अनुसार क्लासिक DWH को फुर्तिलो विकासको साथ विकल्पहरू छन् - झरना अनुसार, एक परियोजनामा ​​यसको दुई रूपहरूमा लचिलोपनको सुखद संयोगहरू भन्दा।

त्यसोभए, लचिलो भण्डारणमा के क्षमताहरू हुनुपर्छ? यहाँ तीनवटा बिन्दुहरू छन्:

1. प्रारम्भिक डेलिभरी र छिटो टर्नअराउंड - यसको मतलब यो हो कि आदर्श रूपमा पहिलो व्यापार परिणाम (उदाहरणका लागि, पहिलो कार्य रिपोर्टहरू) सकेसम्म चाँडो प्राप्त गरिनुपर्छ, अर्थात्, सम्पूर्ण प्रणाली पूर्ण रूपमा डिजाइन र कार्यान्वयन हुनु अघि नै। यसबाहेक, प्रत्येक पछिको संशोधनले पनि सकेसम्म थोरै समय लिनुपर्छ।
2. पुनरावृत्ति परिष्करण - यसको मतलब यो हो कि प्रत्येक पछिको सुधारले पहिले नै काम गरिरहेको कार्यक्षमतालाई प्रभाव पार्नु हुँदैन। यो क्षण हो जुन प्राय: ठूला परियोजनाहरूमा सबैभन्दा ठूलो दुःस्वप्न हुन्छ - चाँडै वा पछि, व्यक्तिगत वस्तुहरूले यति धेरै जडानहरू प्राप्त गर्न थाल्छन् कि अवस्थित तालिकामा फिल्ड थप्नु भन्दा नजिकैको प्रतिलिपिमा तर्कलाई पूर्ण रूपमा दोहोर्याउन सजिलो हुन्छ। र यदि तपाईं छक्क पर्नु भएको छ कि अवस्थित वस्तुहरूमा सुधारहरूको प्रभावको विश्लेषण गर्न आफैंमा सुधारहरू भन्दा बढी समय लाग्न सक्छ, तपाईंले सम्भवतः अझैसम्म बैंकिङ वा टेलिकमहरूमा ठूला डाटा गोदामहरूसँग काम गर्नुभएको छैन।
3. व्यापार आवश्यकताहरू परिवर्तन गर्न निरन्तर अनुकूलन गर्दै - समग्र वस्तु संरचना सम्भावित विस्तारलाई ध्यानमा राखेर मात्र होइन, तर यो अर्को विस्तारको दिशा डिजाइन चरणमा सपनामा पनि कल्पना गर्न सकिँदैन भन्ने अपेक्षाको साथ डिजाइन गर्नुपर्छ।

र हो, यी सबै आवश्यकताहरू एउटै प्रणालीमा पूरा गर्न सम्भव छ (अवश्य पनि, केही अवस्थाहरूमा र केही आरक्षणहरूको साथ)।

तल म डाटा गोदामहरूका लागि दुई सबैभन्दा लोकप्रिय चुस्त डिजाइन विधिहरू विचार गर्नेछु - एंकर मोडेल и डाटा भल्ट। कोष्ठकहरू बाहिर छोडिएका उत्कृष्ट प्रविधिहरू छन्, उदाहरणका लागि, EAV, 6NF (यसको शुद्ध रूपमा) र NoSQL समाधानहरूसँग सम्बन्धित सबै कुरा - तिनीहरू कुनै न कुनै रूपमा नराम्रो भएकाले होइन, र यस अवस्थामा लेखले प्राप्त गर्ने धम्की दिने भएकोले पनि होइन। औसत डिसर को मात्रा। यो केवल यो हो कि यो सबै थोरै फरक वर्गको समाधानसँग सम्बन्धित छ - या त तपाइँको परियोजनाको समग्र वास्तुकला (जस्तै EAV), वा विश्वव्यापी रूपमा अन्य जानकारी भण्डारण प्रतिमानहरू (जस्तै ग्राफ डाटाबेसहरू) को लागी तपाइँले विशेष केसहरूमा प्रयोग गर्न सक्ने प्रविधिहरूमा। र अन्य विकल्पहरू NoSQL)।

"शास्त्रीय" दृष्टिकोणका समस्याहरू र लचिलो विधिहरूमा तिनीहरूको समाधान

"शास्त्रीय" दृष्टिकोणबाट मेरो मतलब राम्रो पुरानो तारा हो (अन्तर्निहित तहहरूको विशिष्ट कार्यान्वयनको बाबजुद, किमबल, इनमोन र सीडीएमका अनुयायीहरूले मलाई माफ गर्नुहोस्)।

1. जडानहरूको कठोर कार्डिनलिटी

यो मोडेल डाटा को स्पष्ट विभाजन मा आधारित छ आयाम и तथ्यहरू। र यो, धिक्कार छ, तार्किक छ - आखिर, धेरै जसो केसहरूमा डाटा विश्लेषण निश्चित खण्डहरू (आयामहरू) मा निश्चित संख्यात्मक संकेतकहरू (तथ्यहरू) को विश्लेषणमा आउँछ।

यस अवस्थामा, वस्तुहरू बीचको जडानहरू विदेशी कुञ्जी प्रयोग गरेर तालिकाहरू बीचको सम्बन्धको रूपमा स्थापित हुन्छन्। यो एकदम स्वाभाविक देखिन्छ, तर तुरुन्तै लचिलोपनको पहिलो सीमामा जान्छ - जडान को कार्डिनलिटी को सख्त परिभाषा.

यसको मतलब यो हो कि तालिका डिजाइन चरणमा, तपाइँले सम्बन्धित वस्तुहरूको प्रत्येक जोडीको लागि सही रूपमा निर्धारण गर्नुपर्छ कि तिनीहरू धेरै-देखि-धेरै, वा केवल 1-देखि-धेरै, र "कुन दिशामा" सम्बन्धित हुन सक्छन्। यसले सीधै निर्धारण गर्छ कि कुन तालिकामा प्राथमिक कुञ्जी हुनेछ र कुनमा विदेशी कुञ्जी हुनेछ। नयाँ आवश्यकताहरू प्राप्त हुँदा यो मनोवृत्ति परिवर्तन गर्नाले सम्भवतः आधारको पुन: कार्यको नेतृत्व गर्नेछ।

उदाहरण को लागी, "नगद रसिद" वस्तु डिजाइन गर्दा, बिक्री विभाग को शपथ मा भर पर्दै, तपाईंले कार्य को संभावना राख्नुभयो। धेरै चेक पदहरूको लागि एक पदोन्नति (तर उल्टो होइन):

र केहि समय पछि, सहकर्मीहरूले नयाँ मार्केटिङ रणनीति प्रस्तुत गरे जसमा उनीहरूले एउटै स्थितिमा कार्य गर्न सक्छन् एकै समयमा धेरै पदोन्नतिहरू। र अब तपाईंले सम्बन्धलाई छुट्टै वस्तुमा विभाजन गरेर तालिकाहरू परिमार्जन गर्न आवश्यक छ।

(सबै व्युत्पन्न वस्तुहरू जसमा पदोन्नति जाँच जोडिएको छ अब पनि सुधार गर्न आवश्यक छ)।

डाटा भल्ट र एंकर मोडेलमा सम्बन्धहरू

यस अवस्थाबाट बच्न एकदम सरल भयो: तपाईंले यो गर्न बिक्री विभागलाई विश्वास गर्नुपर्दैन। सबै जडानहरू सुरुमा छुट्टै तालिकाहरूमा भण्डारण गरिन्छ र यसलाई धेरै-देखि-धेरै प्रशोधन गर्नुहोस्।

यो दृष्टिकोण प्रस्ताव गरिएको थियो डेन लिन्स्टेड प्रतिमानको भागको रूपमा डाटा भल्ट र पूर्ण समर्थन Lars Rönnbäck в एंकर मोडेल.

नतिजाको रूपमा, हामीले लचिलो विधिहरूको पहिलो विशिष्ट विशेषता पाउँछौं:

वस्तुहरू बीचको सम्बन्ध अभिभावक संस्थाहरूको विशेषताहरूमा भण्डार गरिएको छैन, तर वस्तुको एक अलग प्रकार हो।

В डाटा भल्ट त्यस्ता लिङ्किङ तालिकाहरू भनिन्छ लिङ्क, र in एंकर मोडेल - टाई। पहिलो नजरमा, तिनीहरू धेरै समान छन्, यद्यपि तिनीहरूको भिन्नता नामको साथ समाप्त हुँदैन (जुन तल छलफल गरिनेछ)। दुबै आर्किटेक्चरहरूमा, लिङ्क तालिकाहरू लिङ्क गर्न सक्छन् संस्थाहरूको कुनै पनि संख्या (आवश्यक छैन 2)।

यो अनावश्यकता, पहिलो नजर मा, परिमार्जन को लागी महत्वपूर्ण लचिलोपन प्रदान गर्दछ। यस्तो संरचना अवस्थित लिङ्कहरूको मुख्यतामा परिवर्तनहरू मात्र होइन, तर नयाँहरू थप्नको लागि पनि सहिष्णु हुन्छ - यदि अब चेक पोजिसनमा क्यासियरसँग लिङ्क छ जसले यसलाई खोल्यो, यस्तो लिङ्कको उपस्थिति मात्र हुनेछ। कुनै पनि अवस्थित वस्तु र प्रक्रियाहरूलाई असर नगरी अवस्थित तालिकाहरूमा एड-अन।

2. डाटा नक्कल

लचिलो वास्तुकलाहरू द्वारा हल गरिएको दोस्रो समस्या कम स्पष्ट छ र पहिलो स्थानमा निहित छ। SCD2 प्रकार मापन (बिस्तारै दोस्रो प्रकारको आयामहरू परिवर्तन गर्दै), यद्यपि तिनीहरू मात्र होइन।

एक क्लासिक वेयरहाउसमा, एक आयाम सामान्यतया एउटा तालिका हो जसमा एक सरोगेट कुञ्जी (PK को रूपमा) र व्यापार कुञ्जीहरूको सेट र छुट्टै स्तम्भहरूमा विशेषताहरू हुन्छन्।

यदि कुनै आयामले संस्करणलाई समर्थन गर्दछ भने, संस्करणको वैधता सीमाहरू फिल्डहरूको मानक सेटमा थपिन्छन्, र स्रोतको एउटा पङ्क्तिको लागि भण्डारमा धेरै संस्करणहरू देखा पर्दछन् (संस्करण विशेषताहरूमा प्रत्येक परिवर्तनको लागि एउटा)।

यदि एक आयाममा कम्तिमा एक बारम्बार परिवर्तन गरिएको संस्करण विशेषता समावेश छ भने, त्यस्ता आयामको संस्करणहरूको संख्या प्रभावशाली हुनेछ (बाँकी विशेषताहरू संस्करण नभएको वा कहिल्यै परिवर्तन नगरे पनि), र यदि त्यहाँ धेरै त्यस्ता विशेषताहरू छन् भने, संस्करणहरूको संख्या हुन सक्छ। तिनीहरूको संख्याबाट तीव्र रूपमा वृद्धि। यो आयामले डिस्क स्पेसको महत्त्वपूर्ण मात्रा लिन सक्छ, यद्यपि यसले भण्डारण गरेको धेरै डेटा अन्य पङ्क्तिहरूबाट अपरिवर्तनीय विशेषता मानहरूको नक्कल मात्र हो।

एकै समयमा, यो पनि धेरै पटक प्रयोग गरिन्छ विकृतिकरण - केही विशेषताहरू जानाजानी मानको रूपमा भण्डारण गरिएका छन्, र सन्दर्भ पुस्तक वा अर्को आयामको लिङ्कको रूपमा होइन। यो दृष्टिकोणले डेटा पहुँचलाई गति दिन्छ, आयाम पहुँच गर्दा जोडिने संख्या घटाउँछ।

सामान्यतया यो निम्त्याउँछ एउटै जानकारी धेरै ठाउँमा एकैसाथ भण्डार गरिएको छ। उदाहरण को लागी, निवास को क्षेत्र र ग्राहक को वर्ग को बारे मा जानकारी एक साथ "ग्राहक" आयाम र "खरीद", "डिलिवरी" र "कल सेन्टर कल" तथ्यहरु, साथै "ग्राहक - ग्राहक प्रबन्धक मा भण्डारण गर्न सकिन्छ। "लिङ्क तालिका।

सामान्यतया, माथि वर्णन गरिएको नियमित (गैर-संस्करण) आयामहरूमा लागू हुन्छ, तर संस्करण गरिएकाहरूमा तिनीहरूको फरक स्केल हुन सक्छ: वस्तुको नयाँ संस्करणको उपस्थिति (विशेष गरी रिट्रोस्पेक्टमा) सबै सम्बन्धितको अद्यावधिक मात्र होइन। तालिकाहरू, तर सम्बन्धित वस्तुहरूको नयाँ संस्करणहरूको क्यास्केडिङ उपस्थितिमा - जब तालिका 1 तालिका 2 निर्माण गर्न प्रयोग गरिन्छ, र तालिका 2, आदि निर्माण गर्न तालिका 3 प्रयोग गरिन्छ। तालिका 1 को निर्माणमा तालिका 3 को एउटै विशेषता संलग्न नभए पनि (र अन्य स्रोतहरूबाट प्राप्त तालिका 2 को अन्य विशेषताहरू संलग्न छन्), यस निर्माणको संस्करणलाई न्यूनतम रूपमा अतिरिक्त ओभरहेडमा नेतृत्व गर्नेछ, र अधिकतममा अतिरिक्तमा। तालिका 3 मा संस्करणहरू। जसको यसमा कुनै पनि सरोकार छैन, र थप श्रृंखला तल।

3. पुन: कार्यको गैररेखीय जटिलता

एकै समयमा, अर्कोको आधारमा बनाइएको प्रत्येक नयाँ स्टोरफ्रन्टले ETL मा परिवर्तन गर्दा डाटा "भिन्न" सक्ने ठाउँहरूको संख्या बढाउँछ। यसले, बारीमा, प्रत्येक पछिको संशोधनको जटिलता (र अवधि) मा वृद्धि हुन्छ।

यदि माथिले विरलै परिमार्जित ETL प्रक्रियाहरूसँग प्रणालीहरू वर्णन गर्दछ भने, तपाईं यस्तो प्रतिमानमा बाँच्न सक्नुहुन्छ - तपाईंले भर्खरै निश्चित गर्न आवश्यक छ कि नयाँ परिमार्जनहरू सबै सम्बन्धित वस्तुहरूमा सही रूपमा बनाइएका छन्। यदि परिमार्जनहरू बारम्बार हुन्छ भने, संयोगवश "हराइरहेको" धेरै जडानहरूको सम्भावना उल्लेखनीय रूपमा बढ्छ।

यदि, यसको अतिरिक्त, हामीले ध्यानमा राख्छौं कि "संस्करण" ETL "गैर-संस्करण" भन्दा धेरै जटिल छ, यो सम्पूर्ण सुविधालाई बारम्बार अद्यावधिक गर्दा गल्तीहरूबाट बच्न धेरै गाह्रो हुन्छ।

डाटा भल्ट र एंकर मोडेलमा वस्तुहरू र विशेषताहरू भण्डारण गर्दै

लचिलो वास्तुकलाका लेखकहरू द्वारा प्रस्तावित दृष्टिकोण निम्नानुसार तयार गर्न सकिन्छ:

के परिवर्तनहरू उस्तै रहन्छ त्यसलाई छुट्याउन आवश्यक छ। त्यो हो, विशेषताहरू बाट अलग कुञ्जीहरू भण्डार गर्नुहोस्।

तर, भ्रममा पर्नु हुँदैन संस्करण गरिएको छैन संग विशेषता अपरिवर्तित: पहिलोले यसको परिवर्तनहरूको इतिहास भण्डार गर्दैन, तर परिवर्तन गर्न सक्छ (उदाहरणका लागि, इनपुट त्रुटि सुधार गर्दा वा नयाँ डाटा प्राप्त गर्दा); दोस्रोले कहिल्यै परिवर्तन गर्दैन।

डाटा भल्ट र एङ्कर मोडेलमा के अपरिवर्तनीय मान्न सकिन्छ भन्ने कुरामा दृष्टिकोण फरक छ।

वास्तुकलाको दृष्टिकोणबाट डाटा भल्ट, अपरिवर्तित मान्न सकिन्छ कुञ्जीहरूको सम्पूर्ण सेट - प्राकृतिक (संस्थाको TIN, स्रोत प्रणालीमा उत्पादन कोड, आदि) र सरोगेट। यस अवस्थामा, बाँकी विशेषताहरूलाई स्रोत र/वा परिवर्तनहरूको आवृत्ति अनुसार समूहहरूमा विभाजन गर्न सकिन्छ। प्रत्येक समूहको लागि छुट्टै तालिका राख्नुहोस् संस्करणहरूको स्वतन्त्र सेटको साथ।

प्रतिमानमा एंकर मोडेल अपरिवर्तित मानिन्छ केवल सरोगेट कुञ्जी सार। अरू सबै (प्राकृतिक कुञ्जीहरू सहित) यसको विशेषताहरूको एक विशेष मामला मात्र हो। जसमा सबै विशेषताहरू पूर्वनिर्धारित रूपमा एक अर्काबाट स्वतन्त्र छन्, त्यसैले प्रत्येक विशेषताको लागि ए अलग तालिका.

В डाटा भल्ट संस्था कुञ्जीहरू भएको तालिकाहरू भनिन्छ हुबामी। हबहरूले सधैं क्षेत्रहरूको निश्चित सेट समावेश गर्दछ:

• प्राकृतिक निकाय कुञ्जीहरू
• सरोगेट कुञ्जी
• स्रोतको लिङ्क
• समय थप्ने रेकर्ड गर्नुहोस्

हबहरूमा पोस्टहरू कहिल्यै परिवर्तन र कुनै संस्करण छैन। बाह्य रूपमा, हबहरू सरोगेटहरू उत्पन्न गर्नका लागि केही प्रणालीहरूमा प्रयोग गरिने ID-नक्सा प्रकार तालिकाहरूसँग धेरै मिल्दोजुल्दो छन्, तथापि, डाटा भल्टमा सरोगेटहरूको रूपमा व्यापार कुञ्जीहरूको सेटबाट ह्यास प्रयोग गर्न सिफारिस गरिन्छ। यस दृष्टिकोणले स्रोतहरूबाट सम्बन्धहरू र विशेषताहरू लोड गर्न सरल बनाउँछ (तपाईले सरोगेट प्राप्त गर्न हबमा सामेल हुन आवश्यक छैन, तपाईंले प्राकृतिक कुञ्जीको ह्यास गणना गर्न आवश्यक छ), तर अन्य समस्याहरू उत्पन्न गर्न सक्छ (सम्बन्धित, उदाहरणका लागि, टक्करहरूसँग। , केस र स्ट्रिङ कुञ्जीहरूमा छाप्न नसकिने क्यारेक्टरहरू, आदि।

अन्य सबै निकाय विशेषताहरू विशेष तालिकाहरूमा भण्डारण गरिन्छ भनिन्छ उपग्रहहरू। एउटै हबमा विशेषताहरूको विभिन्न सेटहरू भण्डारण गर्ने धेरै उपग्रहहरू हुन सक्छन्।

उपग्रहहरू बीच विशेषताहरूको वितरण सिद्धान्त अनुसार हुन्छ संयुक्त परिवर्तन - एउटा उपग्रहमा गैर-संस्करण विशेषताहरू भण्डारण गर्न सकिन्छ (उदाहरणका लागि, एक व्यक्तिको लागि जन्म मिति र SNILS), अर्कोमा - विरलै परिवर्तन गरिएका संस्करणहरू (उदाहरणका लागि, अन्तिम नाम र राहदानी नम्बर), तेस्रोमा - बारम्बार परिवर्तन गर्नेहरू (उदाहरणका लागि, डेलिभरी ठेगाना, कोटी, अन्तिम अर्डरको मिति, आदि)। यस अवस्थामा, संस्करणहरू व्यक्तिगत उपग्रहहरूको स्तरमा गरिन्छ, र सम्पूर्ण रूपमा इकाई होइन, त्यसैले विशेषताहरू वितरण गर्न सल्लाह दिइन्छ ताकि एक उपग्रह भित्रको संस्करणहरूको प्रतिच्छेदन न्यूनतम होस् (जसले भण्डारण गरिएका संस्करणहरूको कुल संख्या घटाउँछ। )।

साथै, डाटा लोडिङ प्रक्रियालाई अनुकूलन गर्न, विभिन्न स्रोतहरूबाट प्राप्त विशेषताहरू प्रायः व्यक्तिगत उपग्रहहरूमा समावेश गरिन्छ।

उपग्रहहरू हब मार्फत सञ्चार गर्छन् विदेशी कुञ्जी (जसले १ देखि धेरै कार्डिनलिटीसँग मेल खान्छ)। यसको मतलब यो हो कि धेरै विशेषता मानहरू (उदाहरणका लागि, एक ग्राहकको लागि धेरै सम्पर्क फोन नम्बरहरू) यो "पूर्वनिर्धारित" वास्तुकला द्वारा समर्थित छन्।

В एंकर मोडेल कुञ्जीहरू भण्डारण गर्ने तालिकाहरू भनिन्छ एंकरहरू। र तिनीहरू राख्छन्:

• केवल सरोगेट कुञ्जीहरू
• स्रोतको लिङ्क
• समय थप्ने रेकर्ड गर्नुहोस्

एंकर मोडेलको दृष्टिकोणबाट प्राकृतिक कुञ्जीहरू विचार गरिन्छ सामान्य विशेषताहरू। यो विकल्प बुझ्न अझ गाह्रो लाग्न सक्छ, तर यसले वस्तु पहिचान गर्न धेरै स्कोप दिन्छ।

उदाहरणका लागि, यदि एउटै संस्थाको बारेमा डाटा विभिन्न प्रणालीहरूबाट आउन सक्छ, जसमध्ये प्रत्येकले आफ्नै प्राकृतिक कुञ्जी प्रयोग गर्दछ। डाटा भल्टमा, यसले धेरै हबहरू (एक प्रति स्रोत + एक एकीकृत मास्टर संस्करण) को बरु जटिल संरचनाहरू निम्त्याउन सक्छ, जबकि एङ्कर मोडेलमा, प्रत्येक स्रोतको प्राकृतिक कुञ्जी आफ्नै विशेषतामा पर्दछ र स्वतन्त्र रूपमा लोड गर्दा प्रयोग गर्न सकिन्छ। अरू सबै।

तर यहाँ एउटा कपटी बिन्दु पनि छ: यदि विभिन्न प्रणालीका विशेषताहरू एउटै निकायमा मिलाइयो भने, सम्भवतः त्यहाँ केही छन्। "gluing" को नियम, जसद्वारा प्रणालीले बुझ्नुपर्छ कि विभिन्न स्रोतहरूबाट अभिलेखहरू संस्थाको एउटा उदाहरणसँग मेल खान्छ।

В डाटा भल्ट यी नियमहरूले सम्भवतः गठन निर्धारण गर्नेछ मास्टर इकाईको "सरोगेट हब" र कुनै पनि हिसाबले प्राकृतिक स्रोत कुञ्जीहरू र तिनीहरूको मौलिक विशेषताहरू भण्डारण गर्ने हबहरूलाई प्रभाव पार्दैन। यदि कुनै बिन्दुमा मर्ज नियमहरू परिवर्तन हुन्छन् (वा विशेषताहरू जसद्वारा यो प्रदर्शन गरिन्छ) अद्यावधिक गरिन्छ, यो सरोगेट हबहरू पुन: फर्म्याट गर्न पर्याप्त हुनेछ।

В एंकर मोडेल यस्तो निकाय प्रायः भण्डारण गरिनेछ एक मात्र एंकर। यसको मतलब यो हो कि सबै विशेषताहरू, तिनीहरू जुनसुकै स्रोतबाट आए पनि, एउटै सरोगेटमा बाध्य हुनेछन्। गलत तरिकाले मर्ज गरिएका अभिलेखहरू अलग गर्न र सामान्यतया, यस्तो प्रणालीमा मर्जको सान्दर्भिकता अनुगमन गर्न धेरै गाह्रो हुन सक्छ, विशेष गरी यदि नियमहरू धेरै जटिल छन् र बारम्बार परिवर्तन हुन्छन्, र एउटै विशेषता विभिन्न स्रोतहरूबाट प्राप्त गर्न सकिन्छ (यद्यपि यो निश्चित छ। सम्भव छ, किनकि प्रत्येक विशेषता संस्करणले यसको स्रोतमा लिङ्क राख्छ)।

कुनै पनि अवस्थामा, यदि तपाइँको प्रणाली कार्यक्षमता कार्यान्वयन गर्न मानिन्छ डुप्लिकेशन, रेकर्ड मर्ज र अन्य MDM तत्वहरू, यो चुस्त विधिहरूमा प्राकृतिक कुञ्जीहरू भण्डारण गर्ने पक्षहरूमा विशेष ध्यान दिन लायक छ। यो सम्भव छ कि ठूलो डाटा भल्ट डिजाइन अचानक मर्ज त्रुटिहरूको सन्दर्भमा सुरक्षित हुनेछ।

एंकर मोडेल भनिन्छ एक अतिरिक्त वस्तु प्रकार पनि प्रदान गर्दछ गाँठ यो अनिवार्य रूपमा विशेष छ लंगर को पतित प्रकार, जसमा एउटा मात्र विशेषता समावेश हुन सक्छ। नोडहरू फ्ल्याट डाइरेक्टरीहरू (उदाहरणका लागि, लिङ्ग, वैवाहिक स्थिति, ग्राहक सेवा वर्ग, आदि) भण्डारण गर्न प्रयोग गरिनु पर्छ। एंकरको विपरीत, गाँठ कुनै सम्बन्धित विशेषता तालिका छैन, र यसको मात्र विशेषता (नाम) सधैँ कुञ्जीसँग एउटै तालिकामा भण्डारण गरिन्छ। नोडहरू टाई टेबल (टाई) द्वारा एङ्करहरूसँग जोडिएका छन् जसरी एङ्करहरू एकअर्कासँग जोडिएका छन्।

Nodes को प्रयोग को बारे मा कुनै स्पष्ट राय छैन। उदाहरण को लागी, निकोले गोलोभ, जसले सक्रिय रूपमा रूसमा एंकर मोडेलको प्रयोगलाई बढावा दिन्छ, विश्वास गर्दछ (अव्यावहारिक रूपमा होइन) कि एकल सन्दर्भ पुस्तकको लागि यो निश्चित रूपमा भन्न सकिन्छ कि यो। संधै स्थिर र एकल-स्तर हुनेछ, त्यसैले यो तुरुन्तै सबै वस्तुहरूको लागि पूर्ण-एङ्कर प्रयोग गर्न राम्रो छ।

डाटा भल्ट र एंकर मोडेल बीचको अर्को महत्त्वपूर्ण भिन्नता उपलब्धता हो जडान को विशेषताहरु:

В डाटा भल्ट लिङ्कहरू हबहरू जस्तै पूर्ण-विकसित वस्तुहरू हुन्, र हुन सक्छन् आफ्नै विशेषताहरू। को एंकर मोडेल लिङ्कहरू एङ्करहरू जडान गर्न मात्र प्रयोग गरिन्छ आफ्नै विशेषता हुन सक्दैन। यो भिन्नताले महत्त्वपूर्ण रूपमा फरक मोडलिङ दृष्टिकोणमा परिणाम दिन्छ तथ्यहरू, जसलाई थप छलफल गरिनेछ।

तथ्य भण्डारण

यस अघि, हामीले मापन मोडलिङको बारेमा कुरा गर्यौं। तथ्यहरू अलि कम स्पष्ट छन्।

В डाटा भल्ट तथ्यहरू भण्डारण गर्नको लागि एक विशिष्ट वस्तु हो लिङ्क, जसको उपग्रहहरूमा वास्तविक संकेतकहरू थपिएका छन्।

यो दृष्टिकोण सहज देखिन्छ। यसले विश्लेषण गरिएका सूचकहरूमा सजिलो पहुँच प्रदान गर्दछ र सामान्यतया परम्परागत तथ्य तालिका जस्तै हुन्छ (केवल सूचकहरू तालिकामा होइन, तर "छिमेकी" तालिकामा भण्डारण गरिन्छ)। तर त्यहाँ पनि समस्याहरू छन्: मोडेलको विशिष्ट परिमार्जनहरू मध्ये एक - तथ्य कुञ्जीको विस्तार - आवश्यक छ। लिङ्कमा नयाँ विदेशी कुञ्जी थप्दै। र यो, बारीमा, मोडुलरिटी "ब्रेक" गर्दछ र सम्भावित रूपमा अन्य वस्तुहरूमा परिमार्जनको आवश्यकता निम्त्याउँछ।

В एंकर मोडेल जडानको आफ्नै विशेषताहरू हुन सक्दैन, त्यसैले यो दृष्टिकोणले काम गर्दैन - बिल्कुल सबै विशेषताहरू र सूचकहरू एक विशिष्ट एङ्करसँग जोडिएको हुनुपर्छ। यसबाट निस्किएको निष्कर्ष सरल छ- प्रत्येक तथ्यलाई पनि आफ्नै एन्कर चाहिन्छ। हामीले तथ्यको रूपमा बुझ्ने बानी बसालेका केहीका लागि, यो स्वाभाविक लाग्न सक्छ - उदाहरणका लागि, खरिदको तथ्यलाई वस्तु "अर्डर" वा "रसीद" मा पूर्ण रूपमा घटाउन सकिन्छ, सत्रमा साइट भ्रमण गर्ने, इत्यादि। तर त्यहाँ पनि तथ्यहरू छन् जसको लागि यस्तो प्राकृतिक "वाहक वस्तु" फेला पार्न सजिलो छैन - उदाहरणका लागि, प्रत्येक दिनको सुरुमा गोदामहरूमा सामानको अवशेष।

तदनुसार, एङ्कर मोडेलमा तथ्य कुञ्जी विस्तार गर्दा मोडुलरिटीको साथ समस्याहरू उत्पन्न हुँदैनन् (यो केवल सम्बन्धित एङ्करमा नयाँ सम्बन्ध थप्न पर्याप्त छ), तर तथ्यहरू प्रदर्शन गर्न मोडेलको डिजाइन कम अस्पष्ट छ; "कृत्रिम" एन्करहरू देखा पर्न सक्छन्। जसले व्यापार वस्तु मोडेललाई अस्पष्ट तरिकामा देखाउँछ।

लचिलोपन कसरी प्राप्त हुन्छ

दुवै अवस्थामा नतिजा निर्माण समावेश छ उल्लेखनीय रूपमा थप तालिकाहरूपरम्परागत मापन भन्दा। तर लाग्न सक्छ उल्लेखनीय रूपमा कम डिस्क ठाउँ परम्परागत आयामको रूपमा संस्करण गरिएका विशेषताहरूको समान सेटको साथ। स्वाभाविक रूपमा, यहाँ कुनै जादू छैन - यो सबै सामान्यीकरणको बारेमा हो। स्याटेलाइटहरू (डेटा भल्टमा) वा व्यक्तिगत तालिकाहरू (एङ्कर मोडेल) मा विशेषताहरू वितरण गरेर, हामी घटाउँछौं (वा पूर्ण रूपमा हटाउने) अरूलाई परिवर्तन गर्दा केही विशेषताहरूको मानहरूको नक्कल.

गर्न डाटा भल्ट जीत उपग्रहहरु बीच विशेषताहरु को वितरण मा निर्भर हुनेछ, र को लागी एंकर मोडेल — प्रति मापन वस्तु संस्करणहरूको औसत संख्याको लगभग सीधा समानुपातिक छ।

यद्यपि, स्पेस बचत एक महत्त्वपूर्ण हो, तर मुख्य होइन, विशेषताहरू अलग भण्डारण गर्ने फाइदा। सम्बन्धहरूको अलग भण्डारणको साथ, यो दृष्टिकोणले स्टोर बनाउँछ मोड्युलर डिजाइन। यसको मतलब यस्तो मोडेलमा व्यक्तिगत विशेषताहरू र सम्पूर्ण नयाँ विषय क्षेत्रहरू थप्दा जस्तो देखिन्छ अधिसंरचना वस्तुहरूको अवस्थित सेटमा तिनीहरूलाई परिवर्तन नगरी। र यो वास्तवमा के वर्णित विधिहरू लचिलो बनाउँछ।

यो पनि टुक्रा उत्पादनबाट ठूलो उत्पादनमा संक्रमणसँग मिल्दोजुल्दो छ - यदि परम्परागत दृष्टिकोणमा मोडेलको प्रत्येक तालिका अद्वितीय छ र विशेष ध्यान चाहिन्छ भने, लचिलो विधिहरूमा यो पहिले नै मानक "भागहरू" को सेट हो। एकातिर, त्यहाँ धेरै तालिकाहरू छन्, र डाटा लोड गर्ने र पुन: प्राप्त गर्ने प्रक्रियाहरू थप जटिल देखिनु पर्छ। अर्कोतर्फ, तिनीहरू बन्छन् विशिष्ट। जसको मतलब त्यहाँ हुन सक्छ स्वचालित र मेटाडेटा संचालित। प्रश्न "हामी यसलाई कसरी राख्नेछौं?", जसको जवाफले सुधारको डिजाइनमा कामको महत्त्वपूर्ण भाग लिन सक्छ, अब यसको लायक छैन (साथै काम प्रक्रियाहरूमा मोडेल परिवर्तनको प्रभावको बारेमा प्रश्न। )।

यसको मतलब यो होइन कि यस्तो प्रणालीमा विश्लेषकहरू आवश्यक पर्दैन - कसैले अझै पनि विशेषताहरूसँग वस्तुहरूको सेट मार्फत काम गर्नुपर्दछ र यो सबै कहाँ र कसरी लोड गर्ने भनेर पत्ता लगाउनुपर्दछ। तर काम को मात्रा, साथै संभावना र त्रुटि को लागत, उल्लेखनीय रूपमा कम छ। दुबै विश्लेषण चरणमा र ETL को विकासको क्रममा, जुन महत्त्वपूर्ण भागमा मेटाडेटा सम्पादन गर्न कम गर्न सकिन्छ।

गाढा पक्ष

माथिका सबैले दुबै दृष्टिकोणहरूलाई साँच्चै लचिलो, प्राविधिक रूपमा उन्नत र पुनरावृत्ति सुधारको लागि उपयुक्त बनाउँछ। निस्सन्देह, त्यहाँ "मलमा ब्यारेल" पनि छ, जुन मलाई लाग्छ तपाईंले पहिले नै अनुमान गर्न सक्नुहुन्छ।

डाटा विघटन, जसले लचिलो वास्तुकलाको मोड्युलरिटीलाई निम्त्याउँछ, तालिकाहरूको संख्यामा वृद्धि हुन्छ र तदनुसार, माथि नमूना लिँदा सामेल हुन। केवल आयामका सबै विशेषताहरू प्राप्त गर्नको लागि, क्लासिक स्टोरमा एउटा चयन पर्याप्त छ, तर लचिलो वास्तुकलालाई जोडहरूको सम्पूर्ण श्रृंखला चाहिन्छ। यसबाहेक, यदि रिपोर्टहरूको लागि यी सबै सामेलहरू अग्रिम लेख्न सकिन्छ, तब विश्लेषकहरू जो हातले SQL लेख्न अभ्यस्त छन् दोब्बर पीडा हुनेछ।

त्यहाँ धेरै तथ्यहरू छन् जुन यो अवस्थालाई सजिलो बनाउँदछ:

ठूला आयामहरूसँग काम गर्दा, यसका सबै विशेषताहरू लगभग कहिल्यै एकैसाथ प्रयोग हुँदैनन्। यसको मतलब यो मोडेलमा पहिलो नजरमा देखिने भन्दा कम जोडिने हुन सक्छ। डाटा भल्टले पनि उपग्रहहरूमा विशेषताहरू आवंटित गर्दा साझेदारीको अपेक्षित आवृत्तिलाई ध्यानमा राख्न सक्छ। एकै समयमा, हबहरू वा एन्करहरू आफैंलाई मुख्य रूपमा लोडिङ चरणमा सरोगेटहरू सिर्जना गर्न र म्याप गर्नको लागि आवश्यक पर्दछ र प्रश्नहरूमा विरलै प्रयोग गरिन्छ (यो विशेष गरी एन्करहरूको लागि सत्य हो)।

सबै जडानहरू कुञ्जीद्वारा हुन्छन्। थप रूपमा, डेटा भण्डारण गर्ने थप "संकुचित" तरिकाले स्क्यानिङ तालिकाहरूको ओभरहेडलाई घटाउँछ जहाँ यो आवश्यक छ (उदाहरणका लागि, विशेषता मानद्वारा फिल्टर गर्दा)। यसले यो तथ्यलाई निम्त्याउन सक्छ कि सामान्यीकृत डाटाबेसबाट जडानहरूको गुच्छाको साथ नमूना प्रति पङ्क्ति धेरै संस्करणहरूको साथ एक भारी आयाम स्क्यान गर्नु भन्दा पनि छिटो हुनेछ।

उदाहरण को लागी, यहाँ मा यो लेखमा एङ्कर मोडेलको कार्यसम्पादनको विस्तृत तुलनात्मक परीक्षण एउटा तालिकाबाट नमूना समावेश गरिएको छ।

धेरै इन्जिन मा निर्भर गर्दछ। धेरै आधुनिक प्लेटफर्महरूमा आन्तरिक जोइन अप्टिमाइजेसन संयन्त्रहरू छन्। उदाहरणका लागि, MS SQL र Oracle ले तालिकाहरूमा जोडिन "छाड्न" सक्छ यदि तिनीहरूको डेटा अन्य जोडहरू बाहेक कतै प्रयोग गरिएको छैन र अन्तिम चयन (तालिका/जोड उन्मूलन), र MPP भर्टिकालाई असर गर्दैन। Avito बाट सहकर्मीहरूको अनुभव, क्वेरी योजनाको केही म्यानुअल अप्टिमाइजेसन दिएर, एन्कर मोडेलको लागि उत्कृष्ट इन्जिन साबित भएको छ। अर्कोतर्फ, एंकर मोडेल भण्डारण गर्दै, उदाहरणका लागि, क्लिक हाउसमा, जसमा सीमित सामेल समर्थन छ, अझै धेरै राम्रो विचार जस्तो देखिँदैन।

थप रूपमा, दुबै वास्तुकलाहरूको लागि त्यहाँ छन् विशेष चालहरू, डेटा पहुँचलाई सजिलो बनाउँदै (क्वेरी कार्यसम्पादन दृष्टिकोणबाट र अन्तिम प्रयोगकर्ताहरूका लागि दुवै)। उदाहरण को लागी, बिन्दु-इन-समय तालिकाहरू डाटा भल्ट वा मा विशेष तालिका कार्यहरू एंकर मोडेलमा।

कुल

विचार गरिएको लचिलो वास्तुकलाको मुख्य सार तिनीहरूको "डिजाइन" को मोड्युलरिटी हो।

यो यो सम्पत्ति हो जसले अनुमति दिन्छ:

• मेटाडेटा तैनाती र आधारभूत ETL एल्गोरिदम लेख्नेसँग सम्बन्धित केही प्रारम्भिक तयारी पछि, चाँडै पहिलो परिणाम संग ग्राहक प्रदान केही स्रोत वस्तुहरूबाट डाटा समावेश गरी केही रिपोर्टहरूको रूपमा। यो पूरै वस्तु मोडेल मार्फत (शीर्ष स्तरमा पनि) सोच्न आवश्यक छैन।
• एउटा डाटा मोडेलले मात्र २-३ वस्तुहरूसँग काम गर्न थाल्छ (र उपयोगी हुन सक्छ), र त्यसपछि बिस्तारै बढ्छ (एन्कर मोडेल निकोलाईको बारेमा लागू गरियो माइसेलियम संग राम्रो तुलना)।
• विषय क्षेत्र विस्तार गर्ने र नयाँ स्रोतहरू थप्ने सहित अधिकांश सुधारहरू अवस्थित कार्यक्षमतालाई असर गर्दैन र पहिले नै काम गरिरहेको केहि तोड्ने जोखिम उत्पन्न गर्दैन.
• मानक तत्वहरूमा विघटन गर्नका लागि धन्यवाद, त्यस्ता प्रणालीहरूमा ETL प्रक्रियाहरू उस्तै देखिन्छन्, तिनीहरूको लेखनले आफैलाई एल्गोरिदमाइजेसनमा उधारो दिन्छ र अन्ततः, स्वचालन.

यो लचिलोपनको मूल्य हो प्रदर्शन। यसको मतलब यो होइन कि त्यस्ता मोडेलहरूमा स्वीकार्य प्रदर्शन प्राप्त गर्न असम्भव छ। प्रायः होइन, तपाईले चाहानु भएको मेट्रिक्स प्राप्त गर्नको लागि तपाईलाई विस्तारमा थप प्रयास र ध्यान चाहिन्छ।

अनुप्रयोगहरू

इकाई प्रकारहरू डाटा भल्ट

डाटा भल्ट बारे थप जानकारी:
Dan Lystadt को वेबसाइट
रूसी मा डाटा भल्ट बारे सबै
Habré मा Data Vault को बारेमा

इकाई प्रकारहरू एंकर मोडेल

एंकर मोडेलको बारेमा थप विवरणहरू:

एंकर मोडेलका सिर्जनाकर्ताहरूको वेबसाइट
Avito मा एंकर मोडेल लागू गर्ने अनुभव बारे लेख

सामान्य विशेषताहरु र विचार दृष्टिकोण को भिन्नता संग सारांश तालिका:

स्रोत: www.habr.com