चपळ DWH डिझाइन पद्धतींचे विहंगावलोकन

स्टोरेज सुविधा विकसित करणे हे एक दीर्घ आणि गंभीर उपक्रम आहे.

प्रोजेक्टच्या आयुष्यातील बरेच काही हे ऑब्जेक्ट मॉडेल आणि बेस स्ट्रक्चरचा सुरुवातीला किती चांगला विचार केला जातो यावर अवलंबून असते.

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

दुसरीकडे, सर्वसाधारणपणे व्यवसाय आणि विशेषत: ग्राहकांच्या गरजा त्वरीत बदलतात आणि डेटा "सखोल" आणि "रुंदीत" दोन्ही वाढतो. आणि इथेच तारेचा मुख्य तोटा दिसून येतो - मर्यादित लवचिकता.

आणि जर तुमच्या शांत आणि आरामदायी जीवनात DWH विकसक म्हणून अचानक:

• "कमीतकमी काहीतरी पटकन करण्यासाठी, आणि मग आपण पाहू" असे कार्य उद्भवले;
• आठवड्यातून किमान एकदा नवीन स्त्रोतांच्या जोडणीसह आणि व्यवसाय मॉडेलचे पुन्हा काम करून वेगाने विकसित होणारा प्रकल्प दिसू लागला;
• एक ग्राहक दिसला ज्याला सिस्टम कशी दिसली पाहिजे आणि तिने शेवटी कोणती कार्ये केली पाहिजे याची कल्पना नाही, परंतु प्रयोग करण्यास तयार आहे आणि सातत्याने त्याच्या जवळ जाताना इच्छित परिणाम सातत्याने परिष्कृत करतो;
• प्रोजेक्ट मॅनेजर चांगली बातमी घेऊन आला: "आणि आता आमच्याकडे चपळ आहे!"

किंवा तुम्ही स्टोरेज सुविधा कशा तयार करू शकता हे शोधण्यात तुम्हाला स्वारस्य असल्यास - कटमध्ये स्वागत आहे!

"लवचिकता" म्हणजे काय?

प्रथम, "लवचिक" म्हणण्यासाठी सिस्टममध्ये कोणते गुणधर्म असणे आवश्यक आहे ते परिभाषित करूया.

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

याचा अर्थ असा नाही की विकास प्रक्रिया आणि डेटा वेअरहाऊसची रचना पूर्णपणे असंबंधित आहेत. एकंदरीत, चपळ आर्किटेक्चरसाठी चपळ भांडार विकसित करणे लक्षणीय सोपे असावे. तथापि, सराव मध्ये, किंबल आणि डेटावॉल्टनुसार क्लासिक डीडब्ल्यूएचच्या चपळ विकासासह पर्याय आहेत - वॉटरफॉलनुसार, एका प्रकल्पावर त्याच्या दोन स्वरूपांमध्ये लवचिकतेच्या आनंदी योगायोगापेक्षा.

तर, लवचिक स्टोरेजमध्ये कोणती क्षमता असावी? येथे तीन मुद्दे आहेत:

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

आणि हो, या सर्व गरजा एका सिस्टीममध्ये पूर्ण करणे शक्य आहे (अर्थातच काही प्रकरणांमध्ये आणि काही आरक्षणांसह).

खाली मी डेटा वेअरहाऊससाठी दोन सर्वात लोकप्रिय चपळ डिझाइन पद्धतींचा विचार करेन - अँकर मॉडेल и डेटा व्हॉल्ट. कंसाच्या बाहेर सोडलेली उत्कृष्ट तंत्रे आहेत, उदाहरणार्थ, EAV, 6NF (त्याच्या शुद्ध स्वरूपात) आणि NoSQL सोल्यूशन्सशी संबंधित सर्व काही - ते काहीसे वाईट आहेत म्हणून नाही, आणि या प्रकरणात लेख मिळवण्याची धमकी देत ​​​​असेही नाही. सरासरी डिसरची मात्रा. हे सर्व थोड्या वेगळ्या वर्गाच्या उपायांशी संबंधित आहे - एकतर तुमच्या प्रकल्पाच्या एकूण आर्किटेक्चरची (जसे की EAV) पर्वा न करता तुम्ही विशिष्ट प्रकरणांमध्ये वापरू शकता अशा तंत्रांशी किंवा जागतिक स्तरावर इतर माहिती स्टोरेज पॅराडिग्म्सशी (जसे की आलेख डेटाबेस) आणि इतर पर्याय NoSQL).

"शास्त्रीय" दृष्टिकोनाच्या समस्या आणि लवचिक पद्धतींमध्ये त्यांचे निराकरण

"शास्त्रीय" दृष्टीकोनातून माझा अर्थ चांगला जुना तारा आहे (अंतर्निहित स्तरांच्या विशिष्ट अंमलबजावणीकडे दुर्लक्ष करून, किमबॉल, इनमॉन आणि CDM चे अनुयायी मला माफ करतील).

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

हे मॉडेल डेटाच्या स्पष्ट विभाजनावर आधारित आहे परिमाण и तथ्ये. आणि हे, धिक्कार, तार्किक आहे - शेवटी, बहुसंख्य प्रकरणांमध्ये डेटा विश्लेषण विशिष्ट विभागांमध्ये (परिमाण) विशिष्ट संख्यात्मक निर्देशक (तथ्य) च्या विश्लेषणापर्यंत खाली येते.

या प्रकरणात, ऑब्जेक्ट्समधील कनेक्शन परदेशी की वापरून सारण्यांमधील संबंधांच्या स्वरूपात स्थापित केले जातात. हे अगदी नैसर्गिक दिसते, परंतु लगेचच लवचिकतेची पहिली मर्यादा ठरते - कनेक्शनच्या कार्डिनॅलिटीची कठोर व्याख्या.

याचा अर्थ असा की टेबल डिझाइन स्टेजवर, तुम्ही संबंधित वस्तूंच्या प्रत्येक जोडीसाठी ते अनेक-ते-अनेक, किंवा फक्त 1-ते-अनेक, आणि “कोणत्या दिशेने” संबंधित असू शकतात हे अचूकपणे निर्धारित करणे आवश्यक आहे. हे थेट ठरवते की कोणत्या टेबलमध्ये प्राथमिक की असेल आणि कोणती परदेशी की असेल. जेव्हा नवीन आवश्यकता प्राप्त होतात तेव्हा ही वृत्ती बदलल्यास बहुधा बेस पुन्हा कार्यान्वित होईल.

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

आणि काही काळानंतर, सहकाऱ्यांनी एक नवीन विपणन धोरण सादर केले ज्यामध्ये ते त्याच स्थानावर कार्य करू शकतात एकाच वेळी अनेक जाहिराती. आणि आता आपल्याला एका वेगळ्या ऑब्जेक्टमध्ये संबंध विभक्त करून टेबल्स सुधारित करण्याची आवश्यकता आहे.

(सर्व व्युत्पन्न वस्तू ज्यामध्ये प्रमोशन चेक जोडले गेले आहे ते देखील सुधारणे आवश्यक आहे).

डेटा व्हॉल्ट आणि अँकर मॉडेलमधील संबंध

ही परिस्थिती टाळणे अगदी सोपे आहे: हे करण्यासाठी तुम्हाला विक्री विभागावर विश्वास ठेवण्याची गरज नाही. सर्व कनेक्शन सुरुवातीला वेगळ्या टेबलमध्ये संग्रहित केले जातात आणि त्यावर अनेक-ते-अनेक म्हणून प्रक्रिया करा.

हा दृष्टिकोन मांडण्यात आला डॅन लिन्स्टेड नमुनाचा भाग म्हणून डेटा व्हॉल्ट आणि पूर्णपणे समर्थित लार्स रॉनबॅक в अँकर मॉडेल.

परिणामी, आम्हाला लवचिक पद्धतींचे पहिले विशिष्ट वैशिष्ट्य मिळते:

ऑब्जेक्ट्समधील संबंध हे मूळ घटकांच्या गुणधर्मांमध्ये साठवले जात नाहीत, परंतु ते एक स्वतंत्र प्रकारचे ऑब्जेक्ट आहेत.

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

ही अनावश्यकता, पहिल्या दृष्टीक्षेपात, बदलांसाठी लक्षणीय लवचिकता प्रदान करते. अशी रचना केवळ विद्यमान लिंक्सच्या कार्डिनॅलिटीमध्ये बदल करण्यासाठीच नव्हे तर नवीन जोडण्यासाठी देखील सहनशील बनते - जर आता चेक पोझिशनमध्ये कॅशियरचा दुवा असेल ज्याने तो तोडला असेल तर अशा दुव्याचे स्वरूप सहज दिसेल. कोणत्याही विद्यमान वस्तू आणि प्रक्रियांवर परिणाम न करता विद्यमान सारण्यांवर अॅड-ऑन बनणे.

2. डेटा डुप्लिकेशन

लवचिक आर्किटेक्चरद्वारे सोडवलेली दुसरी समस्या कमी स्पष्ट आहे आणि प्रथम स्थानावर अंतर्निहित आहे. SCD2 प्रकार मोजमाप (दुसऱ्या प्रकाराची परिमाणे हळूहळू बदलत आहेत), जरी तेच नाही.

क्लासिक वेअरहाऊसमध्ये, परिमाण हे सामान्यत: एक सारणी असते ज्यामध्ये सरोगेट की (पीके म्हणून) आणि स्वतंत्र स्तंभांमध्ये व्यवसाय की आणि विशेषतांचा संच असतो.

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

जर परिमाणात कमीतकमी एक वारंवार बदलणारी आवृत्ती विशेषता समाविष्ट असेल तर, अशा परिमाणाच्या आवृत्त्यांची संख्या प्रभावी असेल (जरी उर्वरित गुणधर्म आवृत्तीत नसतील किंवा कधीही बदलत नसतील), आणि अशा अनेक विशेषता असल्यास, आवृत्त्यांची संख्या त्यांच्या संख्येवरून वेगाने वाढतात. हा परिमाण डिस्क स्पेसची महत्त्वपूर्ण रक्कम घेऊ शकतो, जरी तो संग्रहित केलेला बराचसा डेटा इतर पंक्तींमधील अपरिवर्तनीय विशेषता मूल्यांची डुप्लिकेट आहे.

त्याच वेळी, ते खूप वेळा वापरले जाते विकृतीकरण — काही विशेषता जाणूनबुजून मूल्य म्हणून संग्रहित केल्या जातात, संदर्भ पुस्तक किंवा दुसर्‍या परिमाणाचा दुवा म्हणून नाही. हा दृष्टीकोन डेटा ऍक्सेसला गती देतो, डायमेंशन ऍक्सेस करताना जोडण्यांची संख्या कमी करतो.

सहसा या ठरतो तीच माहिती एकाच वेळी अनेक ठिकाणी साठवली जाते. उदाहरणार्थ, निवासस्थानाचा प्रदेश आणि क्लायंटच्या श्रेणीबद्दलची माहिती एकाच वेळी “क्लायंट” परिमाणे आणि “खरेदी”, “डिलिव्हरी” आणि “कॉल सेंटर कॉल” तथ्ये तसेच “क्लायंट - क्लायंट व्यवस्थापक” मध्ये संग्रहित केली जाऊ शकते. "लिंक टेबल.

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

3. पुनर्कार्याची नॉनलाइनर जटिलता

त्याच वेळी, दुसर्‍याच्या आधारावर तयार केलेले प्रत्येक नवीन स्टोअरफ्रंट ईटीएलमध्ये बदल केल्यावर डेटा "विचलित" होऊ शकतात अशा ठिकाणांची संख्या वाढवते. यामुळे, त्यानंतरच्या प्रत्येक पुनरावृत्तीची जटिलता (आणि कालावधी) वाढते.

उपरोक्त क्वचितच सुधारित ईटीएल प्रक्रियेसह सिस्टमचे वर्णन करत असल्यास, आपण अशा प्रतिमानात जगू शकता - आपल्याला फक्त सर्व संबंधित वस्तूंमध्ये नवीन बदल योग्यरित्या केले गेले आहेत याची खात्री करणे आवश्यक आहे. पुनरावृत्ती वारंवार होत असल्यास, चुकून अनेक कनेक्शन "गहाळ" होण्याची शक्यता लक्षणीय वाढते.

या व्यतिरिक्त, आम्ही हे लक्षात घेतले की "आवृत्ती केलेले" ETL "नॉन-व्हर्जन केलेले" पेक्षा लक्षणीयरीत्या अधिक क्लिष्ट आहे, ही संपूर्ण सुविधा वारंवार अद्यतनित करताना चुका टाळणे खूप कठीण होते.

डेटा व्हॉल्ट आणि अँकर मॉडेलमध्ये वस्तू आणि विशेषता संग्रहित करणे

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

जे समान राहते त्यापासून कोणते बदल वेगळे करणे आवश्यक आहे. म्हणजेच विशेषतांपासून वेगळ्या की साठवा.

तथापि, एखाद्याने गोंधळ करू नये आवृत्ती नाही सह विशेषता अपरिवर्तित: पहिला त्याच्या बदलांचा इतिहास संचयित करत नाही, परंतु बदलू शकतो (उदाहरणार्थ, इनपुट त्रुटी सुधारताना किंवा नवीन डेटा प्राप्त करताना); दुसरा कधीही बदलत नाही.

डेटा व्हॉल्ट आणि अँकर मॉडेलमध्ये नेमके काय अपरिवर्तनीय मानले जाऊ शकते यावर दृष्टिकोन भिन्न आहेत.

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

उपमा मध्ये अँकर मॉडेल अपरिवर्तित मानले जाते फक्त सरोगेट की सार बाकी सर्व काही (नैसर्गिक कळासहित) हे फक्त त्याच्या गुणधर्मांचे एक विशेष प्रकरण आहे. ज्यामध्ये सर्व गुणधर्म डीफॉल्टनुसार एकमेकांपासून स्वतंत्र आहेत, म्हणून प्रत्येक गुणधर्मासाठी a स्वतंत्र टेबल.

В डेटा व्हॉल्ट एंटिटी की असलेल्या टेबल्स म्हणतात हुबामी. हबमध्ये नेहमी फील्डचा निश्चित संच असतो:

• नैसर्गिक अस्तित्व की
• सरोगेट की
• स्त्रोताशी दुवा
• वेळ जोडून रेकॉर्ड करा

हब मधील पोस्ट कधीही बदलू नका आणि कोणत्याही आवृत्त्या नाहीत. बाहेरून, हब हे सरोगेट्स व्युत्पन्न करण्यासाठी काही प्रणालींमध्ये वापरल्या जाणार्‍या आयडी-मॅप प्रकार सारण्यांसारखेच असतात, तथापि, डेटा व्हॉल्टमध्ये सरोगेट्स म्हणून व्यवसाय कीच्या संचामधून हॅश वापरण्याची शिफारस केली जाते. हा दृष्टीकोन स्त्रोतांकडून संबंध आणि गुणधर्म लोड करणे सोपे करते (सरोगेट मिळविण्यासाठी हबमध्ये सामील होण्याची आवश्यकता नाही, फक्त नैसर्गिक कीच्या हॅशची गणना करा), परंतु इतर समस्या निर्माण करू शकतात (उदाहरणार्थ, टक्कर, केस आणि न छापण्यायोग्य) स्ट्रिंग की मधील वर्ण, इ. पी.), म्हणून ते सामान्यतः स्वीकारले जात नाही.

इतर सर्व घटक गुणधर्म विशेष सारण्यांमध्ये संग्रहित केले जातात ज्याला म्हणतात उपग्रह. एका हबमध्ये गुणधर्मांचे विविध संच संचयित करणारे अनेक उपग्रह असू शकतात.

उपग्रहांमधील गुणधर्मांचे वितरण तत्त्वानुसार होते संयुक्त बदल — एका उपग्रहामध्ये नॉन-व्हर्जन नसलेल्या विशेषता संग्रहित केल्या जाऊ शकतात (उदाहरणार्थ, एखाद्या व्यक्तीसाठी जन्मतारीख आणि SNILS), दुसर्‍यामध्ये - क्वचितच आवृत्ती बदलणारे (उदाहरणार्थ, आडनाव आणि पासपोर्ट क्रमांक), तिसऱ्यामध्ये - वारंवार बदलणारे (उदाहरणार्थ, वितरण पत्ता, श्रेणी, शेवटच्या ऑर्डरची तारीख इ.). या प्रकरणात, व्हर्जनिंग वैयक्तिक उपग्रहांच्या पातळीवर चालते, आणि संपूर्णपणे अस्तित्वात नाही, म्हणून विशेषता वितरीत करण्याचा सल्ला दिला जातो जेणेकरुन एका उपग्रहातील आवृत्त्यांचे छेदनबिंदू कमीतकमी असेल (ज्यामुळे संग्रहित आवृत्त्यांची एकूण संख्या कमी होते. ).

तसेच, डेटा लोडिंग प्रक्रिया ऑप्टिमाइझ करण्यासाठी, विविध स्त्रोतांकडून प्राप्त केलेले गुणधर्म अनेकदा वैयक्तिक उपग्रहांमध्ये समाविष्ट केले जातात.

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

В अँकर मॉडेल की साठवणाऱ्या टेबलांना म्हणतात अँकर. आणि ते ठेवतात:

• फक्त सरोगेट की
• स्त्रोताशी दुवा
• वेळ जोडून रेकॉर्ड करा

अँकर मॉडेलच्या दृष्टिकोनातून नैसर्गिक की मानल्या जातात सामान्य गुणधर्म. हा पर्याय समजण्यास अधिक कठीण वाटू शकतो, परंतु तो ऑब्जेक्ट ओळखण्यास अधिक वाव देतो.

उदाहरणार्थ, जर एकाच घटकाबद्दलचा डेटा वेगवेगळ्या प्रणालींमधून येऊ शकतो, ज्यापैकी प्रत्येक स्वतःची नैसर्गिक की वापरते. डेटा व्हॉल्टमध्ये, यामुळे अनेक हब (एक प्रति स्त्रोत + एक एकीकृत मास्टर आवृत्ती) ऐवजी अवजड संरचना होऊ शकते, तर अँकर मॉडेलमध्ये, प्रत्येक स्त्रोताची नैसर्गिक की त्याच्या स्वतःच्या गुणधर्मात येते आणि स्वतंत्रपणे लोड करताना वापरली जाऊ शकते. इतर सर्व.

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

В डेटा व्हॉल्ट हे नियम बहुधा निर्मिती निश्चित करतील प्रमुख घटकाचे "सरोगेट हब". आणि कोणत्याही प्रकारे नैसर्गिक स्त्रोत की आणि त्यांचे मूळ गुणधर्म संचयित करणार्‍या हबवर प्रभाव टाकत नाही. जर काही क्षणी विलीनीकरणाचे नियम बदलले (किंवा ज्या गुणधर्मांद्वारे ते केले जाते ते अद्ययावत केले जातात), ते सरोगेट हबचे रीफॉर्मेट करण्यासाठी पुरेसे असेल.

В अँकर मॉडेल अशी संस्था बहुधा संग्रहित केली जाईल एकमेव अँकर. याचा अर्थ असा आहे की सर्व गुणधर्म, ते कोणत्याही स्रोतातून आलेले असले तरीही, समान सरोगेटला बांधील असतील. चुकीने विलीन केलेले रेकॉर्ड वेगळे करणे आणि सर्वसाधारणपणे, अशा प्रणालीमध्ये विलीन होण्याच्या प्रासंगिकतेचे निरीक्षण करणे अधिक कठीण असू शकते, विशेषत: जर नियम खूपच गुंतागुंतीचे असतील आणि वारंवार बदलत असतील, आणि समान गुणधर्म वेगवेगळ्या स्त्रोतांकडून मिळू शकतात (जरी ते नक्कीच आहे. शक्य आहे, कारण प्रत्येक विशेषता आवृत्ती त्याच्या स्त्रोताशी लिंक ठेवते).

कोणत्याही परिस्थितीत, जर तुमची प्रणाली कार्यक्षमतेची अंमलबजावणी करायची असेल डुप्लिकेशन, रेकॉर्ड विलीन करणे आणि इतर MDM घटक, चपळ पद्धतींमध्ये नैसर्गिक की संचयित करण्याच्या पैलूंवर विशेष लक्ष देणे योग्य आहे. विलीनीकरण त्रुटींच्या संदर्भात अधिकाधिक डेटा व्हॉल्ट डिझाइन अचानक अधिक सुरक्षित होण्याची शक्यता आहे.

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

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

डेटा व्हॉल्ट आणि अँकर मॉडेलमधील आणखी एक महत्त्वाचा फरक म्हणजे उपलब्धता कनेक्शनचे गुणधर्म:

В डेटा व्हॉल्ट लिंक हब सारख्याच पूर्ण वाढ झालेल्या वस्तू आहेत आणि असू शकतात स्वतःचे गुणधर्म. द अँकर मॉडेल दुवे फक्त अँकर जोडण्यासाठी वापरले जातात आणि त्यांचे स्वतःचे गुणधर्म असू शकत नाहीत. या फरकाचा परिणाम लक्षणीयपणे भिन्न मॉडेलिंग पध्दतींमध्ये होतो तथ्ये, ज्याची पुढे चर्चा केली जाईल.

तथ्य संचयन

याआधी, आम्ही प्रामुख्याने मापन मॉडेलिंगबद्दल बोललो. वस्तुस्थिती थोडी कमी स्पष्ट आहे.

В डेटा व्हॉल्ट तथ्ये संग्रहित करण्यासाठी एक विशिष्ट वस्तू आहे दुवा, ज्यांच्या उपग्रहांमध्ये वास्तविक निर्देशक जोडले जातात.

हा दृष्टिकोन अंतर्ज्ञानी वाटतो. हे विश्‍लेषित संकेतकांमध्‍ये सहज प्रवेश प्रदान करते आणि ते साधारणपणे पारंपारिक तथ्य सारणीसारखेच असते (केवळ निर्देशक टेबलमध्येच संग्रहित केले जात नाहीत, परंतु "शेजारी" मध्ये असतात). परंतु त्यात काही तोटे देखील आहेत: मॉडेलच्या ठराविक बदलांपैकी एक - फॅक्ट कीचा विस्तार - आवश्यक आहे लिंकवर नवीन परदेशी की जोडत आहे. आणि हे, यामधून, मॉड्यूलरिटी "ब्रेक" करते आणि संभाव्यत: इतर वस्तूंमध्ये बदल करण्याची आवश्यकता निर्माण करते.

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

त्यानुसार, अँकर मॉडेलमध्ये तथ्य की विस्तृत करताना मॉड्यूलरिटीसह समस्या उद्भवत नाहीत (संबंधित अँकरमध्ये फक्त नवीन संबंध जोडणे पुरेसे आहे), परंतु तथ्य प्रदर्शित करण्यासाठी मॉडेल डिझाइन करणे कमी अस्पष्ट आहे; "कृत्रिम" अँकर दिसू शकतात. जे व्यवसाय ऑब्जेक्ट मॉडेल अस्पष्ट मार्गाने प्रदर्शित करतात.

लवचिकता कशी प्राप्त होते

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

करण्यासाठी डेटा व्हॉल्ट विजेतेपद उपग्रहांमधील गुणधर्मांच्या वितरणावर आणि यासाठी अवलंबून असेल अँकर मॉडेल — प्रत्येक मापन ऑब्जेक्टच्या आवृत्त्यांच्या सरासरी संख्येच्या जवळजवळ थेट प्रमाणात आहे.

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

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

याचा अर्थ असा नाही की अशा प्रणालीमध्ये विश्लेषकांची अजिबात आवश्यकता नाही - एखाद्याला अद्याप गुणधर्मांसह ऑब्जेक्ट्सच्या संचाद्वारे कार्य करणे आवश्यक आहे आणि ते कोठे आणि कसे लोड करावे हे शोधणे आवश्यक आहे. परंतु कामाचे प्रमाण, तसेच त्रुटीची शक्यता आणि किंमत लक्षणीयरीत्या कमी झाली आहे. विश्लेषणाच्या टप्प्यावर आणि ईटीएलच्या विकासादरम्यान, जे महत्त्वपूर्ण भागामध्ये मेटाडेटा संपादित करण्यासाठी कमी केले जाऊ शकते.

काळी बाजू

वरील सर्व दोन्ही दृष्टिकोन खरोखर लवचिक, तांत्रिकदृष्ट्या प्रगत आणि पुनरावृत्ती सुधारण्यासाठी योग्य बनवतात. अर्थात, "मलममध्ये बॅरल" देखील आहे, ज्याचा तुम्ही आधीच अंदाज लावू शकता असे मला वाटते.

डेटाचे विघटन, जे लवचिक आर्किटेक्चरच्या मॉड्यूलरिटीला अधोरेखित करते, ज्यामुळे टेबल्सच्या संख्येत वाढ होते आणि त्यानुसार, ओव्हरहेड सॅम्पलिंग करताना सामील होण्यासाठी. एका परिमाणाचे सर्व गुणधर्म सहज मिळवण्यासाठी, क्लासिक स्टोअरमध्ये एक निवड करणे पुरेसे आहे, परंतु लवचिक आर्किटेक्चरसाठी संपूर्ण मालिका जोडणे आवश्यक आहे. शिवाय, जर रिपोर्ट्ससाठी हे सर्व सामीलीकरण आगाऊ लिहिता आले तर, एसक्यूएल हाताने लिहिण्याची सवय असलेल्या विश्लेषकांना दुप्पट त्रास होईल.

अशी अनेक तथ्ये आहेत जी ही परिस्थिती सुलभ करतात:

मोठ्या परिमाणांसह कार्य करताना, त्याचे सर्व गुणधर्म जवळजवळ कधीही एकाच वेळी वापरले जात नाहीत. याचा अर्थ मॉडेलमध्ये पहिल्या दृष्टीक्षेपात दिसते त्यापेक्षा कमी जोडणी असू शकतात. डेटा व्हॉल्ट उपग्रहांना विशेषता वाटप करताना शेअरिंगची अपेक्षित वारंवारता देखील विचारात घेऊ शकते. त्याच वेळी, लोडिंग स्टेजवर सरोगेट्स तयार करण्यासाठी आणि मॅपिंग करण्यासाठी हब किंवा अँकर स्वतः आवश्यक असतात आणि क्वचितच प्रश्नांमध्ये वापरले जातात (हे विशेषतः अँकरसाठी सत्य आहे).

सर्व जोडणी की द्वारे आहेत. याव्यतिरिक्त, डेटा संचयित करण्याचा अधिक "संकुचित" मार्ग आवश्यक असलेल्या स्कॅनिंग टेबलचे ओव्हरहेड कमी करतो (उदाहरणार्थ, विशेषता मूल्यानुसार फिल्टर करताना). यामुळे हे वस्तुस्थिती निर्माण होऊ शकते की जॉइन्सच्या गुच्छांसह सामान्यीकृत डेटाबेसमधून नमुना घेणे प्रति पंक्तीच्या अनेक आवृत्त्यांसह एक हेवी डायमेंशन स्कॅन करण्यापेक्षा अधिक वेगवान असेल.

उदाहरणार्थ, येथे हे लेखात एका टेबलमधील नमुना असलेल्या अँकर मॉडेलच्या कामगिरीची तपशीलवार तुलनात्मक चाचणी आहे.

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

याव्यतिरिक्त, दोन्ही आर्किटेक्चरसाठी आहेत विशेष हालचाली, डेटा प्रवेश सुलभ करणे (क्वेरी कार्यप्रदर्शन दृष्टिकोनातून आणि अंतिम वापरकर्त्यांसाठी दोन्ही). उदाहरणार्थ, पॉइंट-इन-टाइम टेबल डेटा व्हॉल्टमध्ये किंवा विशेष टेबल कार्ये अँकर मॉडेलमध्ये.

एकूण

विचारात घेतलेल्या लवचिक आर्किटेक्चरचे मुख्य सार म्हणजे त्यांच्या "डिझाइन" ची मॉड्यूलरिटी.

ही मालमत्ता परवानगी देते:

• मेटाडेटा उपयोजन आणि मूलभूत ETL अल्गोरिदम लिहिण्याशी संबंधित काही प्रारंभिक तयारी केल्यानंतर, ग्राहकाला प्रथम परिणाम त्वरीत प्रदान करा फक्त काही स्त्रोत ऑब्जेक्ट्सचा डेटा असलेल्या दोन अहवालांच्या स्वरूपात. संपूर्ण ऑब्जेक्ट मॉडेलचा (अगदी वरच्या स्तरावर) पूर्णपणे विचार करणे आवश्यक नाही.
• डेटा मॉडेल फक्त 2-3 ऑब्जेक्ट्ससह कार्य करण्यास (आणि उपयुक्त ठरू शकते) आणि नंतर हळूहळू वाढतात (अँकर मॉडेल निकोलाई बद्दल लागू मायसेलियमशी छान तुलना).
• विषय क्षेत्र विस्तृत करणे आणि नवीन स्रोत जोडणे यासह बर्‍याच सुधारणा विद्यमान कार्यक्षमतेवर परिणाम करत नाही आणि आधीपासून कार्यरत असलेली एखादी गोष्ट खंडित होण्याचा धोका नाही.
• मानक घटकांमध्ये विघटन केल्याबद्दल धन्यवाद, अशा प्रणालींमधील ईटीएल प्रक्रिया सारख्याच दिसतात, त्यांचे लेखन अल्गोरिदमीकरणाकडे जाते आणि शेवटी, ऑटोमेशन.

या लवचिकतेची किंमत आहे कामगिरी. याचा अर्थ असा नाही की अशा मॉडेल्सवर स्वीकार्य कामगिरी प्राप्त करणे अशक्य आहे. बर्‍याचदा, तुम्हाला हवे असलेले मेट्रिक्स साध्य करण्यासाठी तुम्हाला अधिक प्रयत्न आणि तपशीलाकडे लक्ष देण्याची आवश्यकता असू शकते.

अनुप्रयोग

अस्तित्व प्रकार डेटा व्हॉल्ट

डेटा व्हॉल्ट बद्दल अधिक माहिती:
डॅन लिस्टाडची वेबसाइट
रशियन भाषेत डेटा व्हॉल्ट बद्दल सर्व
Habré वर डेटा व्हॉल्ट बद्दल

अस्तित्व प्रकार अँकर मॉडेल

अँकर मॉडेलबद्दल अधिक तपशील:

अँकर मॉडेलच्या निर्मात्यांची वेबसाइट
अविटोमध्ये अँकर मॉडेल लागू करण्याच्या अनुभवाबद्दल लेख

सामान्य वैशिष्ट्यांसह सारांश सारणी आणि विचारात घेतलेल्या दृष्टिकोनातील फरक:

स्त्रोत: www.habr.com