डेटा वेयरहाउसिंग पर कुछ समय बिताते हुए, मैंने ईटीएल (एक्स्ट्रा ट्रांसफॉर्म लोड) और ईएलटी (लोड ट्रांसफॉर्म निकालें) प्रक्रियाएं बनाई हैं। ऐसा लगता है कि ईएलटी डेटा गोदामों को पॉप्युलेट करने का एक नया दृष्टिकोण है जो क्लस्टर कंप्यूटिंग संसाधनों का अधिक आसानी से लाभ उठा सकता है। मैं यह सुनना चाहता हूं कि अन्य लोग क्या सोचते हैं कि ईटीएल और ईएलटी के फायदे एक-दूसरे पर हैं और जब आपको एक या दूसरे का उपयोग करना चाहिए।कौन सा बेहतर है, ईटीएल या ईएलटी?
तो ईटीएल और ईएलटी दोनों के साथ अच्छी तरह से खेला जाने के बाद, मैं इस निष्कर्ष पर पहुंचा हूं कि आपको ईएलटी से हर कीमत पर बचना चाहिए। ईटीएल वास्तव में इसे लोड करने से पहले अपने गोदाम के लिए डेटा तैयार करता है। ईएलटी हालांकि गोदाम में कच्चे डेटा को लोड करता है और आप इसे जगह में बदल देते हैं। यदि आपके पास व्यस्त डेटा गोदाम है तो यह समस्याग्रस्त है। यदि किसी तालिका पर एक रिपोर्टिंग क्वेरी चल रही है जिसे आप अपडेट करने का प्रयास कर रहे हैं, तो आपकी क्वेरी अवरुद्ध हो जाएगी। नतीजतन, रिपोर्टों को पकड़ने या अपडेट को अवरुद्ध करने के लिए प्रश्नों की रिपोर्ट करना संभव है।
अब आप में से कुछ कह सकते हैं कि रिपोर्टिंग प्रश्नों को अद्यतन को अवरुद्ध करने की आवश्यकता नहीं है और आप गंदे पढ़ने की अनुमति देने के लिए अपना अलगाव स्तर निर्धारित कर सकते हैं। रिपोर्टिंग प्रश्नों को आम तौर पर सॉफ्टवेयर इंजीनियरों द्वारा निष्पादित नहीं किया जाता है। उन्हें व्यावसायिक उपयोगकर्ताओं द्वारा निष्पादित किया जाता है ताकि आप उनके अलगाव स्तर को सही तरीके से सेट करने के लिए उन पर भरोसा न करें। साथ ही, सभी रिपोर्ट गंदे पढ़ने को सहन नहीं कर सकती हैं।
ऐसे मामले हैं जहां ईएलटी काम कर सकता है, हालांकि इसे आपके डेटा गोदाम में पेश करके खतरनाक है और इसके परिणामस्वरूप, मैं आपकी स्वच्छता और रखरखाव के लिए अनुशंसा करता हूं, इससे बचें।
मैं दोनों का उपयोग करता हूं। यह बस सुविधा और कार्यक्षमता का मामला है। यह सब मामले पर निर्भर करता है। कभी-कभी मैं टीईएल करता हूं - यानी ट्रांसफॉर्म स्रोत डेटाबेस (संग्रहीत प्रक्रिया या दृश्य में) में किया जाता है और फिर निकाला जाता है और सीधे लोड किया जाता है।
जो उत्तर देना बेहतर है - समस्या पर निर्भर करता है।
मैं जब भी संभव हो बहु-चरण ईटीएल - निकालें, निकालें, साफ, अनुरूप, वितरित) पसंद करते हैं। मैं प्रत्येक निकालने, साफ करने और अनुरूप कदम के बाद इंटरमीडिएट सीएसवी फाइलों को भी रखता हूं; कुछ डिस्क स्थान लेता है, लेकिन काफी उपयोगी है। जब भी डीडब्ल्यू को ईटीएल, या डीडब्ल्यू स्कीमा में बग्स के कारण फिर से लोड किया जाना है, तो फिर से स्रोत सिस्टम से पूछने की कोई आवश्यकता नहीं है - यह पहले से ही फ्लैट फाइलों में है। यह आवश्यक होने पर स्टेजिंग क्षेत्र में फ्लैट फ़ाइलों के माध्यम से grep, sed और awk करने में सक्षम होने के लिए भी काफी सुविधाजनक है। ऐसे मामले में जब कई स्रोत सिस्टम होते हैं जो एक ही डीडब्ल्यू में भोजन करते हैं, तो प्रत्येक स्रोत सिस्टम के लिए केवल निकालने के चरणों को विकसित (और बनाए रखा जाना) - साफ, अनुरूप और कदम प्रदान करना आम है।
मैं ईएलटी पसंद करता हूं। कोई कह सकता है कि यह नॉर्म के खिलाफ है। पारंपरिक तरीकों के खिलाफ मानसिकता और डिजाइन दृष्टिकोण में बदलाव की आवश्यकता है। लेकिन यह मौजूदा हार्डवेयर और कौशल सेट का उपयोग करता है, और विकास प्रक्रिया में लागत और जोखिम को कम करता है।
यदि हम ईटीएल दृष्टिकोण में संदर्भित अखंडता सुनिश्चित करना चाहते हैं, तो डेटा को लक्ष्य से ईटीएल सर्वर (इंजन) में डाउनलोड किया जाना चाहिए। लेकिन हमें इसे ईटीएल दृष्टिकोण में करने की आवश्यकता नहीं है।
ईएलटी दृष्टिकोण से सर्वश्रेष्ठ प्राप्त करने के लिए एक खुले दिमाग की आवश्यकता होती है।
मैं इससे असहमत हूं। मुझे लगता है कि दोनों दृष्टिकोणों के लिए एक जगह है। यदि स्थिति की अनुमति देता है तो मैं व्यक्तिगत रूप से ईएलटी पसंद करता हूं। अधिकतर डेटा गोदामों को उनके रखरखाव खिड़कियों के दौरान रात में लोड किया जाता है ... और यदि आप फॉलो-द-सन पर्यावरण में डेटा गोदामों का जिक्र कर रहे हैं, तो आप बिना किसी दृष्टिकोण के चलते मुद्दों पर भाग लेंगे (मुझे एक प्राप्त करने की आवश्यकता हो सकती है थोड़ा रचनात्मक)। मुझे लगता है कि ईएलटी के साथ मेरा अधिक नियंत्रण है .. अभिलेखीय उद्देश्यों के लिए कच्चे डेटा को बनाए रखने की आपकी क्षमता का उल्लेख नहीं करना। –
एक और चीज जो मैं जोड़ना चाहता था ...मुझे लगता है कि ईएलटी को इसे बनाए रखने के लिए अधिक अनुभवी डेटाबेस/एसक्यूएल संसाधनों की आवश्यकता है क्योंकि डेटाबेस के अंदर काम का बड़ा हिस्सा हो रहा है। यह, एक चौराहे के रास्ते में, एप्लिकेशन बनाम डेटाबेस प्रश्न के समान प्रश्न है ... http://stackoverflow.com/questions/119540/business-logic-database-or-plication-layer –
कोई सही उत्तर नहीं है .. .. –