ईटीएल मिशन से कैसे संपर्क करें?

कुछ सामान्य ईटीएल युक्तियाँ

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

2. यदि SQL2000 डेटाबेस एक गड़बड़ है, तो आप शायद पाएंगे कि SSISडेटा प्रवाह डेटा से निपटने का एक अनाड़ी तरीका है। एक नियम के रूप में, ईटीएल उपकरण जटिलता के साथ खराब पैमाने पर; वित्त कंपनियों में सभी डेटावेयरहाउस परियोजनाओं में से आधे की तरह कुछ स्पष्ट वास्तुकला निर्णय के रूप में संग्रहीत प्रक्रिया कोड के साथ किया जाता है - ठीक इसी कारण से। यदि आपको बड़ी मात्रा में कोड इंप्रोक्स करना है, तो सभी . डालने पर विचार करें sprocs में कोड का।
   
   एक ऐसी प्रणाली के लिए जिसमें बहुत सारे जटिल स्क्रबिंग या परिवर्तन शामिल हैं, 100% स्पोक दृष्टिकोण कहीं अधिक रखरखाव योग्य है क्योंकि यह सभी परिवर्तनों और व्यावसायिक तर्क को एक ही स्थान पर रखने का एकमात्र व्यवहार्य तरीका है। मिश्रित ईटीएल/स्प्रोक सिस्टम के साथ, आपको पूरे परिवर्तन को ट्रैक करने, समस्या निवारण, डीबग करने या बदलने के लिए कई स्थानों पर देखना होगा।

3. ईटीएल टूल का सबसे अच्छा स्थान उन सिस्टमों पर है जहां आपके पास अपेक्षाकृत सरल परिवर्तनों के साथ बड़ी संख्या में डेटा स्रोत हैं।

4. कोड को परीक्षण योग्य बनाएं, ताकि आप घटकों और टेस्टिन अलगाव को अलग कर सकें। कोड जिसे केवल एक ईटीएल उपकरण में जटिल डेटा प्रवाह के बीच से ही निष्पादित किया जा सकता है, परीक्षण करना बहुत कठिन है।

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

6. एक सामान्य धीरे-धीरे बदलते आयाम हैंडलर बनाएं या उपलब्ध होने पर शेल्फ से एक का उपयोग करें। यह इस कार्यक्षमता को इकाई परीक्षण के लिए आसान बनाता है। यदि इसका परीक्षण नहीं किया जा सकता है, तो सिस्टम परीक्षण को सभी कोने के मामलों का परीक्षण करने की आवश्यकता नहीं है, केवल यह प्रस्तुत किया गया डेटा सही है या नहीं। यह उतना जटिल नहीं है जितना लगता है - मैंने जो आखिरी लिखा था वह टी-एसक्यूएल कोड की लगभग 600 या 700 लाइनें थी। वही किसी भी सामान्य स्क्रबिंग फ़ंक्शन के लिए जाता है।

7. यदि संभव हो तो धीरे-धीरे लोड करें।

8. अपना कोड लिखिए - क्या यह लॉग प्रविष्टियां करता है, संभवतः डायग्नोस्टिक्स जैसे चेक योग या गणना रिकॉर्ड करता है। इसके बिना, समस्या निवारण लगभग असंभव है। इसके अलावा, इसके लिए त्रुटि प्रबंधन के बारे में सोचने के लिए अभिकथन जाँच एक अच्छा तरीका है (क्या पंक्ति की गणना b में एक समान पंक्ति में होती है, A:B संबंध वास्तव में 1:1) है।

9. सिंथेटिक चाबियों का प्रयोग करें। स्रोत सिस्टम से प्राकृतिक कुंजियों का उपयोग करना आपके सिस्टम को डेटा स्रोतों से जोड़ता है, और अतिरिक्त स्रोतों को जोड़ना मुश्किल बनाता है। सिस्टम में चाबियां और संबंध हमेशा लाइन अप होना चाहिए - कोई नल नहीं। त्रुटियों के लिए, 'रिकॉर्ड नहीं किया गया', आयाम तालिका में एक विशिष्ट 'त्रुटि' या 'रिकॉर्ड नहीं की गई' प्रविष्टियां करें और उनका मिलान करें।

10. यदि आप एक ऑपरेशनल डेटा स्टोर (कई धार्मिक युद्ध का विषय) बनाते हैं, तो स्टार स्कीमा में ODS कुंजियों को रीसायकल न करें। हर तरह से आयाम बनाने के लिए ODS कुंजियों में शामिल हों, लेकिन एक प्राकृतिक कुंजी से मेल खाते हैं। यह आपको ओडीएस को मनमाने ढंग से छोड़ने और फिर से बनाने की अनुमति देता है - संभवतः इसकी संरचना को बदल रहा है - स्टार स्कीमा को परेशान किए बिना। इस क्षमता का होना एक वास्तविक रखरखाव जीत है, क्योंकि आप ODS संरचना को बदल सकते हैं या किसी भी समय ODS की एक क्रूर-बल पुन:तैनाती कर सकते हैं।

अंक 1-2 और 4-5 का मतलब है कि आप एक ऐसा सिस्टम बना सकते हैं जहां सभी किसी दिए गए सबसिस्टम के लिए कोड का (जैसे एक एकल आयाम या तथ्य तालिका) सिस्टम में एक और केवल एक ही स्थान पर रहता है। इस प्रकार का आर्किटेक्चर बड़ी संख्या में डेटा स्रोतों के लिए भी बेहतर है।

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

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

प्वाइंट 7 एक सामान्य प्रदर्शन युक्ति है जिसे आपको बड़े डेटा वॉल्यूम के लिए देखने की आवश्यकता होगी। ध्यान दें कि आपको सिस्टम के कुछ हिस्सों के लिए केवल वृद्धिशील लोडिंग की आवश्यकता हो सकती है; छोटी संदर्भ तालिकाओं और आयामों के लिए आपको इसकी आवश्यकता नहीं हो सकती है।

प्वाइंट 8 किसी भी हेडलेस प्रक्रिया के लिए जर्मन है। यदि यह रात के दौरान स्तन ऊपर जाता है, तो आप अगले दिन क्या गलत हुआ यह देखने का कुछ लड़ने का मौका चाहते हैं। यदि कोड ठीक से लॉग नहीं करता है कि क्या हो रहा है और त्रुटियों को पकड़ता है, तो आपको इसका निवारण करना बहुत कठिन काम होगा।

प्वाइंट 9 डेटा वेयरहाउस को अपना जीवन देता है। जब वेयरहाउस की अपनी चाबियां हों तो आप स्रोत सिस्टम को आसानी से जोड़ और छोड़ सकते हैं। धीरे-धीरे बदलते आयामों को लागू करने के लिए गोदाम की चाबियां भी जरूरी हैं।

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