एजाइल डीडब्ल्यूएच डिजाइन पद्धतियों का अवलोकन

भंडारण सुविधा विकसित करना एक लंबा और गंभीर कार्य है।

किसी परियोजना का जीवन काफी हद तक इस बात पर निर्भर करता है कि प्रारंभ में ऑब्जेक्ट मॉडल और डेटाबेस संरचना पर कितनी अच्छी तरह से विचार किया गया है।

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

दूसरी ओर, सामान्य रूप से व्यवसाय और विशेष रूप से ग्राहकों की आवश्यकताएं तेजी से बदलती रहती हैं, और डेटा “गहराई” और “व्यापकता” दोनों में बढ़ता रहता है। और यहीं पर स्टार का मुख्य नुकसान सामने आता है - सीमित लचीलापन.

और यदि एक DWH डेवलपर के रूप में आपके शांत और आरामदायक जीवन में अचानक:

• कार्य यह था कि “कम से कम कुछ तो जल्दी करो, फिर देखेंगे”;
• एक तेजी से विकसित होने वाली परियोजना सामने आई है, जिसमें नए स्रोत जुड़ रहे हैं और व्यवसाय मॉडल पर कम से कम सप्ताह में एक बार पुनः काम किया जा रहा है;
• एक ग्राहक सामने आया है जिसे कोई विचार नहीं है कि सिस्टम कैसा दिखना चाहिए और इसे अंततः क्या कार्य करना चाहिए, लेकिन वह प्रयोगों के लिए तैयार है और वांछित परिणाम के निरंतर परिशोधन के साथ लगातार सन्निकटन के लिए तैयार है;
• प्रोजेक्ट मैनेजर खुशखबरी लेकर आया: "अब हमारे पास एजाइल है!"

या यदि आप यह जानने में रुचि रखते हैं कि आप भंडारण सुविधाएं कैसे बना सकते हैं - तो आपका स्वागत है!

"लचीलेपन" का क्या अर्थ है?

सबसे पहले, आइए परिभाषित करें कि किसी प्रणाली को “लचीला” कहलाने के लिए उसमें क्या गुण होने चाहिए।

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

इसका मतलब यह नहीं है कि विकास प्रक्रिया और डेटा वेयरहाउस की संरचना किसी भी तरह से जुड़ी नहीं हैं। कुल मिलाकर, एजाइल का उपयोग करके एक लचीली वास्तुकला रिपोजिटरी विकसित करना काफी आसान होना चाहिए। हालांकि, व्यवहार में, किमबॉल के अनुसार क्लासिक डीडब्ल्यूएच के एजाइल विकास और वाटरफॉल के अनुसार डेटावॉल्ट के साथ भिन्नताओं का सामना करना अधिक आम बात है, बजाय एक परियोजना पर इसके दो रूपों में लचीलेपन के सुखद संयोगों के।

तो, लचीले भंडारण में क्या क्षमताएं होनी चाहिए? यहां तीन बिंदुओं पर प्रकाश डालना आवश्यक है:

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

और हां, इन सभी आवश्यकताओं को एक ही प्रणाली में पूरा करना संभव है (बेशक, कुछ मामलों में और कुछ आरक्षणों के साथ)।

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

“क्लासिकल” दृष्टिकोण की समस्याएं और चुस्त कार्यप्रणाली में उनके समाधान

"शास्त्रीय" दृष्टिकोण से मेरा तात्पर्य अच्छे पुराने स्टार से है (अंतर्निहित परतों के विशिष्ट कार्यान्वयन की परवाह किए बिना, किमबॉल, इनमॉन और सीडीएम के अनुयायी मुझे क्षमा करें)।

1. कनेक्शनों की कठोर कार्डिनैलिटी

इस तरह के मॉडल का आधार डेटा का स्पष्ट विभाजन है DIMENSIONS и तथ्य (तथ्य). और यह बात तर्कसंगत है - आखिरकार, अधिकांश मामलों में डेटा विश्लेषण कुछ निश्चित खंडों (आयामों) में कुछ संख्यात्मक संकेतकों (तथ्यों) के विश्लेषण पर निर्भर करता है।

इस मामले में, वस्तुओं के बीच कनेक्शन विदेशी कुंजी द्वारा तालिकाओं के बीच कनेक्शन के रूप में निर्धारित किए जाते हैं। यह काफी स्वाभाविक लगता है, लेकिन इससे लचीलेपन की पहली सीमा तुरंत सामने आ जाती है - कनेक्शन की कार्डिनैलिटी की सख्त परिभाषा.

इसका मतलब यह है कि तालिका डिजाइन चरण में आपको संबंधित वस्तुओं की प्रत्येक जोड़ी के लिए स्पष्ट रूप से परिभाषित करना होगा कि क्या उन्हें कई-से-कई के रूप में संबंधित किया जा सकता है, या केवल 1-से-कई के रूप में, और "किस दिशा में"। इससे सीधे तौर पर यह निर्धारित होता है कि किस तालिका में प्राथमिक कुंजी होगी और किसमें विदेशी कुंजी होगी। नई आवश्यकताएं प्राप्त होने पर इस अनुपात को बदलने से संभवतः डेटाबेस में पुनः कार्य करना पड़ेगा।

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

और कुछ समय बाद, सहकर्मियों ने एक नई मार्केटिंग रणनीति पेश की, जिसमें उसी स्थिति पर कार्रवाई की जा सकती है एक ही समय में कई प्रमोशन. और अब आपको कनेक्शन को एक अलग ऑब्जेक्ट में विभाजित करके तालिकाओं को परिष्कृत करने की आवश्यकता है।

(सभी व्युत्पन्न वस्तुएं जिनमें चेक प्रोमो से जुड़ता है, उन्हें भी अब संशोधन की आवश्यकता है)।

डेटा वॉल्ट और एंकर मॉडल में संबंध

ऐसी स्थिति से बचना काफी आसान निकला: आपको बिक्री विभाग पर भरोसा करने की ज़रूरत नहीं है; इसके लिए, यह पर्याप्त है सभी कनेक्शन प्रारंभ में अलग-अलग तालिकाओं में संग्रहीत किए जाते हैं और अनेक-से-अनेक प्रक्रिया करें।

यह दृष्टिकोण प्रस्तावित किया गया था डैन लिन्स्टेड द्वारा प्रतिमान के भाग के रूप में डेटा वॉल्ट और पूर्णतः समर्थित लार्स रोनबैक द्वारा в एंकर मॉडल.

परिणामस्वरूप, हमें लचीली कार्यप्रणाली की पहली विशिष्ट विशेषता मिलती है:

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

В डेटा वॉल्ट ऐसी लिंकिंग तालिकाओं को कहा जाता है संपर्कऔर में एंकर मॉडल - टाई. पहली नज़र में, वे बहुत समान हैं, हालांकि नाम उनके अंतर को समाप्त नहीं करता है (जिस पर नीचे चर्चा की जाएगी)। दोनों आर्किटेक्चर में, लिंक टेबल लिंक कर सकते हैं किसी भी संख्या में संस्थाएँ (जरूरी नहीं कि 2 हो).

यह अनावश्यक प्रतीत होने वाली सुविधा संशोधनों के लिए महत्वपूर्ण लचीलापन प्रदान करती है। ऐसी संरचना न केवल मौजूदा लिंकों की कार्डिनैलिटी में परिवर्तन के प्रति सहनशील हो जाती है, बल्कि नए लिंकों को जोड़ने के प्रति भी सहनशील हो जाती है - यदि अब किसी चेक आइटम में उसे पंच करने वाले कैशियर का लिंक भी है, तो ऐसे लिंक का प्रकट होना किसी भी मौजूदा ऑब्जेक्ट और प्रक्रिया को प्रभावित किए बिना मौजूदा तालिकाओं में एक ऐड-ऑन बन जाएगा।

2. डेटा दोहराव

लचीली वास्तुकला द्वारा हल की गई दूसरी समस्या कम स्पष्ट है और मुख्य रूप से अंतर्निहित है SCD2 प्रकार के माप (दूसरे प्रकार के धीरे-धीरे बदलते आयाम), हालाँकि केवल वे ही नहीं।

एक क्लासिक डेटा वेयरहाउस में, आयाम आम तौर पर एक तालिका होती है जिसमें एक सरोगेट कुंजी (PK के रूप में) और अलग-अलग कॉलम में व्यवसाय कुंजियों और विशेषताओं का एक सेट होता है।

यदि कोई आयाम संस्करण निर्धारण का समर्थन करता है, तो संस्करण वैधता समय सीमाएं फ़ील्ड के मानक सेट में जोड़ दी जाती हैं, और स्रोत में प्रत्येक पंक्ति के लिए रिपॉजिटरी में एकाधिक संस्करण दिखाई देते हैं (संस्करण विशेषताओं में प्रत्येक परिवर्तन के लिए एक)।

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

साथ ही, बहुत बार इसका प्रयोग भी किया जाता है असमान्यीकरण — कुछ विशेषताओं को जानबूझकर किसी निर्देशिका या अन्य आयाम के संदर्भ के बजाय मान के रूप में संग्रहीत किया जाता है। यह दृष्टिकोण किसी आयाम तक पहुँचने के दौरान जॉइन की संख्या को कम करके डेटा एक्सेस को गति प्रदान करता है।

आमतौर पर इसका परिणाम यह होता है एक ही जानकारी एक ही समय में कई स्थानों पर संग्रहीत होती है. उदाहरण के लिए, निवास के क्षेत्र और ग्राहक की श्रेणी के बारे में जानकारी एक साथ आयाम "ग्राहक", और तथ्य "खरीद", "वितरण" और "कॉल सेंटर अनुरोध", साथ ही साथ लिंक तालिका "ग्राहक - ग्राहक प्रबंधक" में संग्रहीत की जा सकती है।

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

3. शोधन की गैर-रैखिक जटिलता

साथ ही, एक दूसरे के ऊपर बनाए गए प्रत्येक नए स्टोरफ्रंट से उन स्थानों की संख्या बढ़ जाती है, जहां ETL में परिवर्तन किए जाने पर डेटा "विचलित" हो सकता है। इसके परिणामस्वरूप, प्रत्येक आगामी संशोधन की जटिलता (और अवधि) में वृद्धि होती है।

यदि उपरोक्त बातें शायद ही कभी संशोधित ETL प्रक्रियाओं वाली प्रणालियों पर लागू होती हैं, तो ऐसे प्रतिमान में रहना संभव है - यह सुनिश्चित करना पर्याप्त है कि सभी संबंधित वस्तुओं में नए संशोधन सही ढंग से दर्ज किए गए हैं। यदि संशोधन बार-बार होते हैं, तो कई कनेक्शनों के गलती से “छूट जाने” की संभावना काफी बढ़ जाती है।

यदि हम यह भी ध्यान में रखें कि "संस्करणित" ETL "गैर-संस्करणित" की तुलना में काफी अधिक जटिल है, तो इन सभी चीजों को बार-बार संशोधित करते समय त्रुटियों से बचना काफी कठिन हो जाता है।

डेटा वॉल्ट और एंकर मॉडल में ऑब्जेक्ट और विशेषताओं को संग्रहीत करना

लचीली वास्तुकला के लेखकों द्वारा प्रस्तावित दृष्टिकोण को निम्नानुसार तैयार किया जा सकता है:

जो बदलता है उसे जो अपरिवर्तित रहता है उससे अलग करना आवश्यक है। अर्थात्, कुंजियों को विशेषताओं से अलग संग्रहित करें।

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

डेटा वॉल्ट और एंकर मॉडल में वास्तव में क्या अपरिवर्तनीय माना जा सकता है, इस पर अलग-अलग विचार हैं।

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

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

В डेटा वॉल्ट जिन तालिकाओं में इकाई कुंजियाँ होती हैं उन्हें कहा जाता है केन्द्रों. हब में हमेशा फ़ील्ड का एक निश्चित सेट होता है:

• इकाई की प्राकृतिक कुंजियाँ
• सरोगेट कुंजी
• स्रोत से लिंक करें
• प्रविष्टि जोड़े जाने का समय

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

संस्थाओं की अन्य सभी विशेषताएं विशेष तालिकाओं में संग्रहित की जाती हैं जिन्हें कहा जाता है उपग्रहों. एक हब में विभिन्न विशेषताओं को संग्रहित करने वाले अनेक उपग्रह हो सकते हैं।

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

इसके अलावा, डेटा लोडिंग प्रक्रिया को अनुकूलित करने के लिए, विभिन्न स्रोतों से प्राप्त विशेषताओं को अक्सर अलग-अलग उपग्रहों में रखा जाता है।

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

В एंकर मॉडल कुंजियाँ संग्रहीत करने वाली तालिकाएँ कहलाती हैं एंकर. और वे रखते हैं:

• केवल सरोगेट कुंजियाँ
• स्रोत से लिंक करें
• प्रविष्टि जोड़े जाने का समय

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

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

लेकिन यहाँ एक पेचीदा बात है: यदि विभिन्न प्रणालियों की विशेषताओं को एक इकाई में संयोजित किया जाता है, तो कुछ समस्याएँ उत्पन्न होने की संभावना है। “चिपकाने” के नियम, जिसके द्वारा सिस्टम को यह समझना चाहिए कि विभिन्न स्रोतों के रिकॉर्ड एक इकाई के एक उदाहरण के अनुरूप हैं।

В डेटा वॉल्ट ये नियम संभवतः गठन का निर्धारण करेंगे "सरोगेट हब" मास्टर इकाई और किसी भी तरह से उन हब को प्रभावित नहीं करेंगे जो स्रोतों की प्राकृतिक कुंजियों और उनकी मूल विशेषताओं को संग्रहीत करते हैं। यदि किसी बिंदु पर ग्लूइंग नियम बदल जाते हैं (या जिन विशेषताओं के द्वारा यह किया जाता है उन्हें अपडेट किया जाता है) तो यह सरोगेट हब को सुधारने के लिए पर्याप्त होगा।

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

किसी भी स्थिति में, यदि आपका सिस्टम कार्यक्षमता को कार्यान्वित करने वाला है डुप्लीकेशन हटाना, रिकॉर्डों का विलय करना और अन्य एमडीएम तत्व, यह विशेष रूप से चुस्त कार्यप्रणाली में प्राकृतिक कुंजियों को संग्रहीत करने के पहलुओं पर बारीकी से विचार करने लायक है। शायद भारी डेटा वॉल्ट डिजाइन अचानक मर्ज त्रुटियों से सुरक्षित हो जाएगा।

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

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

डेटा वॉल्ट और एंकर मॉडल के बीच एक और महत्वपूर्ण अंतर इसकी उपस्थिति है लिंक की विशेषताएँ:

В डेटा वॉल्ट लिंक हब की तरह ही पूर्ण विकसित ऑब्जेक्ट हैं और इनका उपयोग किया जा सकता है स्वयं की विशेषताएँ. में एंकर मॉडल लिंक का उपयोग केवल एंकरों को जोड़ने के लिए किया जाता है उनकी अपनी विशेषताएँ नहीं हो सकतीं. इस अंतर के परिणामस्वरूप मॉडलिंग के दृष्टिकोण में काफी भिन्नता आ जाती है। तथ्य, जिस पर आगे चर्चा की जाएगी।

तथ्यों का भंडारण

अब तक हम मुख्यतः आयामी मॉडलिंग के बारे में बात करते रहे हैं। तथ्य थोड़े कम स्पष्ट हैं।

В डेटा वॉल्ट तथ्यों को संग्रहीत करने के लिए एक विशिष्ट वस्तु है जोड़ना, जिन उपग्रहों में वास्तविक संकेतक जोड़े गए हैं।

यह दृष्टिकोण सहज प्रतीत होता है। यह विश्लेषित संकेतकों तक आसान पहुंच प्रदान करता है और आम तौर पर एक पारंपरिक तथ्य तालिका के समान होता है (केवल संकेतक तालिका में नहीं, बल्कि एक "पड़ोसी" तालिका में संग्रहीत होते हैं)। लेकिन इसमें कुछ खामियां भी हैं: मॉडल में एक सामान्य संशोधन - तथ्य कुंजी का विस्तार - की आवश्यकता होती है लिंक में एक नई विदेशी कुंजी जोड़ना. और यह, बदले में, मॉड्यूलरिटी को “तोड़ता” है और संभावित रूप से अन्य वस्तुओं में संशोधन की आवश्यकता पैदा करता है।

В एंकर मॉडल किसी रिश्ते की अपनी विशेषताएं नहीं हो सकतीं, इसलिए यह दृष्टिकोण काम नहीं करेगा - सभी विशेषताओं और संकेतकों को एक विशिष्ट एंकर से जोड़ा जाना चाहिए। इसका निष्कर्ष सरल है - प्रत्येक तथ्य को अपने स्वयं के आधार की भी आवश्यकता होती है. कुछ लोगों के लिए जिन्हें हम तथ्यों के रूप में समझने के आदी हैं, यह स्वाभाविक लग सकता है - उदाहरण के लिए, खरीद के तथ्य को आसानी से ऑब्जेक्ट "ऑर्डर" या "चेक" तक कम किया जा सकता है, किसी वेबसाइट पर जाना - एक सत्र तक, आदि। लेकिन ऐसे तथ्य भी हैं जिनके लिए इस तरह की प्राकृतिक "वाहक वस्तु" को ढूंढना इतना आसान नहीं है - उदाहरण के लिए, प्रत्येक दिन की शुरुआत में गोदामों में शेष सामान।

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

लचीलापन कैसे प्राप्त किया जाता है?

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

के लिए डेटा वॉल्ट लाभ उपग्रहों में विशेषताओं के वितरण पर निर्भर करेगा, और एंकर मॉडल — प्रति माप वस्तु के संस्करणों की औसत संख्या के लगभग सीधे आनुपातिक है।

हालाँकि, अलग-अलग विशेषता भंडारण का मुख्य लाभ नहीं, बल्कि महत्वपूर्ण लाभ है, क्योंकि इसमें स्थान में वृद्धि होती है। लिंक के अलग-अलग भंडारण के साथ, यह दृष्टिकोण रिपोजिटरी बनाता है मॉड्यूलर डिजाइन. इसका अर्थ यह है कि ऐसे मॉडल में व्यक्तिगत विशेषताओं और सम्पूर्ण नए विषय क्षेत्रों को जोड़ने पर यह इस प्रकार दिखाई देगा: सुपरस्ट्रक्चर किसी मौजूदा ऑब्जेक्ट सेट पर बिना कोई परिवर्तन किए। और यही बात वर्णित कार्यप्रणालियों को लचीला बनाती है।

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

इसका मतलब यह नहीं है कि ऐसी प्रणाली में विश्लेषकों की बिल्कुल भी आवश्यकता नहीं है - किसी को तो विशेषताओं के साथ वस्तुओं के समूह के माध्यम से काम करना ही होगा और यह पता लगाना होगा कि यह सब कहां और कैसे लोड किया जाए। लेकिन काम की मात्रा, साथ ही त्रुटि की संभावना और लागत, काफी कम हो जाती है। विश्लेषण चरण में और ETL विकास के दौरान, जो काफी हद तक मेटाडेटा के संपादन पर निर्भर करता है।

अंधेरा पक्ष

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

डेटा विघटन, जो लचीली वास्तुकला की मॉड्यूलरिटी का आधार है, तालिकाओं की संख्या में वृद्धि करता है और तदनुसार, उपरि लागत चयन करते समय जुड़ने पर. किसी आयाम की सभी विशेषताओं को प्राप्त करने के लिए, क्लासिक स्टोरेज में एक चयन पर्याप्त होता है, लेकिन एक लचीली वास्तुकला के लिए जॉइन की एक पूरी श्रृंखला की आवश्यकता होगी। इसके अलावा, यदि इन सभी जोइन्स को रिपोर्ट के लिए पहले से लिखा जा सके, तो जो विश्लेषक SQL को हाथ से लिखने के आदी हैं, उन्हें दोगुना नुकसान होगा।

ऐसे कई तथ्य हैं जो इस स्थिति को आसान बनाते हैं:

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

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

उदाहरण के लिए, यहाँ यह इस आलेख में एक तालिका के नमूने के साथ एंकर मॉडल के प्रदर्शन का विस्तृत तुलनात्मक परीक्षण शामिल है।

बहुत कुछ इंजन पर निर्भर करता है। कई आधुनिक प्लेटफार्मों में जोड़ों को अनुकूलित करने के लिए आंतरिक तंत्र मौजूद हैं। उदाहरण के लिए, MS SQL और Oracle टेबल पर जॉइन को “स्किप” कर सकते हैं यदि उनका डेटा अन्य जॉइन के अलावा कहीं भी उपयोग नहीं किया जाता है और अंतिम चयन (टेबल/जॉइन उन्मूलन) को प्रभावित नहीं करता है, और MPP Vertica ऐसा कर सकता है एविटो के सहकर्मियों का अनुभवक्वेरी योजना के कुछ मैनुअल अनुकूलन को देखते हुए, यह एंकर मॉडल के लिए एक बेहतरीन इंजन साबित हुआ है। दूसरी ओर, उदाहरण के लिए, एंकर मॉडल को क्लिक हाउस पर संग्रहीत करना, जिसमें सीमित जॉइन समर्थन है, इस बिंदु पर एक अच्छा विचार नहीं लगता है।

इसके अलावा, दोनों आर्किटेक्चर के लिए हैं विशेष तकनीक, जिससे डेटा तक पहुंच आसान हो जाती है (क्वेरी प्रदर्शन और अंतिम उपयोगकर्ताओं दोनों के संदर्भ में)। उदाहरण के लिए, बिन्दु-समय सारणी डेटा वॉल्ट में या विशेष तालिका कार्य एंकर मॉडल में.

कुल मिलाकर

विचाराधीन लचीली वास्तुकलाओं का मुख्य सार उनके “निर्माण” की मॉड्यूलरिटी है।

यह वह गुण है जो यह अनुमति देता है:

• मेटाडेटा को तैनात करने और बुनियादी ETL एल्गोरिदम लिखने से जुड़ी कुछ प्रारंभिक तैयारी के बाद, ग्राहक को पहला परिणाम शीघ्रता से प्रदान करें कुछ स्रोत वस्तुओं से प्राप्त डेटा वाली कुछ रिपोर्टों के रूप में। इसके लिए सम्पूर्ण ऑब्जेक्ट मॉडल पर (यहां तक ​​कि उच्च स्तर पर भी) पूरी तरह से विचार करना आवश्यक नहीं है।
• एक डेटा मॉडल सिर्फ 2-3 ऑब्जेक्ट्स के साथ काम करना शुरू कर सकता है (और उपयोगी हो सकता है), और फिर धीरे-धीरे बढ़ना (एंकर मॉडल निकोले के सापेक्ष) लागू माइसीलियम के साथ एक सुंदर तुलना)।
• अधिकांश सुधार, जिसमें विषय क्षेत्र का विस्तार करना और नए स्रोत जोड़ना शामिल है मौजूदा कार्यक्षमता को प्रभावित नहीं करता है और पहले से काम कर रही किसी चीज़ को तोड़ने का जोखिम पैदा नहीं करता है.
• मानक तत्वों में विघटन के कारण, ऐसी प्रणालियों में ETL प्रक्रियाएं एक समान दिखती हैं, उनके लेखन को एल्गोरिथम बनाया जा सकता है और अंततः, स्वचालन.

ऐसे लचीलेपन की कीमत है उत्पादकता. इसका मतलब यह नहीं है कि ऐसे मॉडलों पर स्वीकार्य प्रदर्शन हासिल करना असंभव है। अधिकतर मामलों में, आपको अपने इच्छित मीट्रिक्स को प्राप्त करने के लिए अधिक प्रयास और विस्तार पर ध्यान देने की आवश्यकता हो सकती है।

क्षुधा

इकाई प्रकार डेटा वॉल्ट

डेटा वॉल्ट के बारे में अधिक जानकारी:
डैन लिस्टेड की वेबसाइट
रूसी में डेटा वॉल्ट के बारे में सब कुछ
Habr पर डेटा वॉल्ट के बारे में

इकाई प्रकार एंकर मॉडल

एंकर मॉडल के बारे में अधिक जानकारी:

एंकर मॉडल के रचनाकारों की साइट
एविटो में एंकर मॉडल को लागू करने के अनुभव के बारे में एक लेख

विचारित दृष्टिकोणों की सामान्य विशेषताओं और अंतरों के साथ एक सारांश तालिका:

स्रोत: www.habr.com