sql server ओएलएपी समाधान खरोंच से बनाते समय मुझे क्या याद रखना चाहिए?




sql-server ssis (2)

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

लेकिन इसमें कुछ कमियां हैं:

  • नए परिवर्तनों के लिए, यह काफी विकास गहन हो सकता है
  • उपयोगकर्ता डेटा के साथ ज्यादा प्रयोग नहीं कर सकता - यह हार्ड-कोडेड दृश्य के लिए लॉक किया गया है
  • बड़ी रिपोर्टों के लिए यह धीमा हो सकता है

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

इस संबंध में मेरे पास कुछ प्रश्न हैं:

1) वर्कफ़्लो से संबंधित:

  • "ब्लैक बॉक्स एसक्यूएल सर्वर" से "ओएलएपी तैयार करने के लिए तैयार" के लिए एक अच्छा विकास मार्ग क्या है?
  • किस सर्वर और सेवाओं की स्थापना की जानी चाहिए, और किस लिपियों को लिखा जाना चाहिए?
  • कौन सा सबसे कठिन / सबसे महत्वपूर्ण / सबसे अधिक समय-सघन भाग हैं?

2) ईटीएल:

  • मुझे लगता है कि अपने डेटा वेयरहाउस और प्रोडक्शन एसक्यूएल के लिए अलग-अलग सर्वरों के लिए सबसे अच्छा है?
  • ये कैसे सिंक में रखा जाता है (पुश / पुल)? किस प्रौद्योगिकी / भाषाओं का उपयोग करना?
  • मेरे लिए SSIS अति जटिल है, और ग्राफ़िकल वर्कफ़्लो मुझे अपील नहीं करता है - मैं एक टेक्स्ट आधारित स्क्रिप्ट की तरह काम करता हूं जो काम करता है क्या यह संभव है?
  • या क्या यह केवल एक स्रोत और एक गंतव्य के साथ ग्राफिकल क्लाइंट का उपयोग करने के लिए फायदेमंद है?

3) विकास:

  • सीआईआई उपकरण से यह कितना (डाटा एकीकरण, विश्लेषण सेवाएं) कुशलता से बनाए जा सकता है?
  • आसानी से उत्पादन और विकास के बीच सेटअप आगे और पीछे स्थानांतरित किया जा सकता है?

मैं किसी भी उत्तर से खुश हूं जो इसमें से कुछ को कवर करता है - और भले ही यह एमएस पर्यावरण है, मैं अन्य प्रौद्योगिकियों के फायदों के बारे में सुनना भी चाहता हूं।


मुझे केवल माइक्रोसॉफ्ट ओएलएपी के साथ अनुभव है, इसलिए मुझे जो पता है उसके बारे में मेरे दो सेंट हैं:

  1. यदि आप क्यूब्स को लागू कर रहे हैं, तो क्यूब्स के लिए स्रोत से उत्पादन SQL सर्वर अलग करें क्यूब्स को स्रोत डॉट कॉम से बहुत सीलेक्ट डायस्टिक्स कॉलम_नाम की आवश्यकता होती है। आप अपने मिशन महत्वपूर्ण उत्पादन प्रणाली को ब्लॉक करने के लिए क्यूब प्रसंस्करण नहीं करना चाहते हैं।

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

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

  4. यदि आपके पास कुछ प्रकार के स्रोत डेटा सिस्टम हैं, तो आप एक सुपर गतिशील स्थैतिक रिपोर्ट बनाने के साथ भाग ले सकते हैं। उदाहरण के लिए, मेरे पास सी # में लिखा गया एक रिपोर्ट है जो मूल रूप से उपयोगकर्ताओं को 30 कॉलम की सूची से कई कॉलमों का चयन करने की अनुमति देता है और कुछ दिनांक सीमा फ़ील्ड और फ़ील्ड फ़िल्टर सूचियों पर डेटा को फ़िल्टर करता है। यह सरल रिपोर्ट अंतिम उपयोगकर्ताओं के सभी तदर्थ रिपोर्ट अनुरोधों के लगभग 40% शामिल करता है क्योंकि यह सभी बुनियादी, मुख्य ग्राहक मीट्रिक और फ़ील्ड्स को कवर करता है। हमने हाल ही में इस रिपोर्ट को एसएसआरएस में स्थानांतरित कर दिया है और इससे हमें 100 की संख्या में फ़ील्ड की संख्या बढ़ाने और समग्र उपयोगकर्ता अनुभव में सुधार करने की अनुमति मिल गई है। रिपोर्टिंग प्लेटफ़ॉर्म के बावजूद, उपयोगकर्ताओं को एक स्थिर रिपोर्टिंग सिस्टम के दायरे में भी कुछ गतिशील लचीलेपन देना संभव है।

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

एक रिलेशनल डेटा स्टोर के साथ क्यूब्स का उपयोग कैसे करें पर फ़ीडबैक

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

इस दृष्टिकोण का लाभ इस प्रकार है:

  1. ओएलएपी के साथ आरंभ करने के लिए आपको पूरी ETL सबसिस्टम बनाने की आवश्यकता नहीं है क्योंकि यह अपेक्षाकृत आसान है।

  2. यह दृष्टिकोण प्रोटोटाइप के लिए अच्छी तरह से काम करता है कि आप अधिक दीर्घकालिक समाधान कैसे तैयार करना चाहते हैं। आप इसे 1-2 दिनों में प्रोटोटाइप कर सकते हैं और ओएलएपी के कुछ लाभ आज दिखा सकते हैं।

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

इस दृष्टिकोण का नुकसान इस प्रकार है:

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

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

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

मुझे बताएं कि क्या आप चाहते हैं कि मैं उपर्युक्त किसी भी बिंदु पर विस्तार करे। सौभाग्य।


आप मूल रूप से "मैं एक डीडब्ल्यूएच कैसे बनाऊँ" का मिलियन डॉलर का सवाल पूछ रहा हूं यह वास्तव में एक सवाल नहीं है जो निर्णायक रूप से उत्तर दिया जा सकता है।

फिर भी, यहां एक किकस्टार्ट है:

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

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

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

एमएस-एसक्यूएल एक डीबी के लिए एक अच्छा विकल्प है यदि आप लागत को ध्यान नहीं देते हैं प्राकृतिक ईटीएल उपकरण SSIS होगा, और यह एक ठोस उपकरण भी है

यहां तक ​​कि अगर आपके पहले परिवर्तन केवल "इस तालिका को लेते हैं और इसमें डंप करते हैं", तो आप अभी भी प्रक्रिया प्रबंधन के मामले में बहुत कुछ हासिल करते हैं (काम चल रहा है? क्या होता है अगर यह विफल हो जाता है? आदि) और डीबगिंग इसके अलावा, व्यवस्थित रूप से आवश्यकताओं और / या विशेष मामलों के साथ पेश किया जाना चाहिए के रूप में विकसित करना आसान है।







business-intelligence