ELT को तोड़कर समझना: जब Silo नहीं, Graph की ज़रूरत हो

• ELT(Extract, Load, Transform) का उपयोग संगठन के भीतर डेटा विश्लेषण और सॉफ़्टवेयर विकास के बीच मौजूद "Silo" को जोड़ने के लिए किया जाता है, लेकिन यही Silo संरचना स्वयं समस्या की जड़ है

• ELT सिर्फ Silo के बीच एक bridge है। जिस दुनिया में Silo नहीं होते, वह "Graph" है

ELT सोच की सीमाएँ

• ऐसी दुनिया में जहाँ एक Silo में सॉफ़्टवेयर है और दूसरे Silo में डेटा विश्लेषण, ELT बहुत मायने रखता है
• ELT, Silo संरचना को आधार मानकर काम करता है
  • जब सॉफ़्टवेयर डेवलपमेंट टीम और डेटा विश्लेषण टीम अलग होती हैं, तब "Extract" का काम पैदा होता है
  • सॉफ़्टवेयर टीम को डेटा टीम के काम में रुचि नहीं होती, और डेटा टीम डेटाबेस permissions का उपयोग कर मनमाने ढंग से डेटा extract कर लेती है
  • extract के बाद ही data quality और modeling जैसे engineering principles लागू होते हैं, लेकिन तब तक बहुत देर हो चुकी होती है
• Conway का नियम काम करता है
  • "संगठन जिन सिस्टमों को बनाता है, उनका डिज़ाइन उस संगठन की communication structure जैसा होता है"
• Silo मानसिकता के कारण ETL/ELT/Reverse ETL, आधुनिक डेटा आर्किटेक्चर की जटिलता को संभालने के लिए उपयुक्त नहीं हैं
  • अब डेटा सिर्फ operational systems और analytics systems तक सीमित नहीं है, बल्कि SaaS से प्रतिनिधित्व किए जाने वाले तीसरे डेटा डोमेन तक फैल चुका है
  • डेटा region और cloud, backend और SaaS के बीच प्रवाहित होता है
  • अब पहले की तुलना में 100 गुना अधिक applications मौजूद हैं, संगठन software-driven हो रहे हैं, और software systems के बीच संबंधों का जाल लगातार अधिक जटिल होता जा रहा है

Graph सोच की ज़रूरत

• अगर सॉफ़्टवेयर टीम और डेटा टीम तालमेल से सहयोग करें, तो ELT की तरह डेटा को extract और store करने वाले मॉडल की जगह Graph model अपनाया जा सकता है
  • ऐसे Graph की कल्पना करें जो डेटा को "Consume" करने वाले nodes से बना हो
  • हर node डेटा का उत्पादन या उपभोग करता है, और स्वाभाविक रूप से एक network या Graph बनता है
• Graph सोच के फायदे:
  • डेटा extraction कम होता है, और consumption बढ़ता है
  • high-quality datasets के इर्द-गिर्द data modeling बढ़ती है
  • data cleaning, raw data storage, और pipeline errors को ठीक करने का काम घटता है
  • batch processes की जगह incremental processing और streaming sources का उपयोग होता है
  • analytics सिर्फ strategic decision-making tools तक सीमित नहीं रहता, बल्कि operational use cases तक फैलता है
  • टीमों के बीच सहयोग और alignment बढ़ता है, Silo कम होते हैं

निष्कर्ष

• ELT सोच, सॉफ़्टवेयर और डेटा टीमों के बीच मौजूद disconnect को दर्शाने वाले Conway के नियम का परिणाम है
• सभी मौजूदा ETL/ELT tools को फेंकने की ज़रूरत नहीं है, लेकिन फोकस data consumption और भरोसेमंद derived datasets के निर्माण पर होना चाहिए
• व्यवहारिक रूप से Shift Left अभी भी एक aspirational चरण में है, और मौजूदा legacy infrastructure तथा integration समस्याएँ अब भी मौजूद हैं
  • Shift Left : सॉफ़्टवेयर विकास जीवन चक्र (SDLC) के शुरुआती चरण में महत्वपूर्ण development practices को एकीकृत करने की रणनीति
• जो संगठन Graph सोच को अपनाएँगे, उन्हें डेटा उपयोग, AI ROI, और व्यावसायिक परिणामों में सबसे बड़े लाभ मिलेंगे

"Extract जैसा कुछ नहीं है। सिर्फ Consume है।" – डेटा Yoda

[udopeanut]

डेटामेश किताब पढ़ने के बाद काफ़ी कुछ समझ में आता है।

[softer]

मैं graph-आधारित decision-making पर लगातार ideation कर रहा हूँ, और अच्छा होगा अगर इसी तरह सोचने वाले लोग एक साथ आ सकें।

[kimsk]

ऐसे समय में इस्तेमाल होने वाला शब्द ideation है, यह अब पता चला। मैंने एक नई चीज़ सीखी। व्यक्तिगत रूप से यह मेरे लिए बहुत रुचि का विषय है। अगर हम इकट्ठा हो सकें तो बहुत अच्छा होगा।

[jwseo]

क्या कोई इसे थोड़ा और समझा सकता है? क्या लेखक का मतलब यह है कि graph से निकले सभी datasets को अलग-अलग store और manage किया जाता है? अगर ऐसा नहीं है, तो यह ETL से किस तरह अलग है, यह मुझे ठीक से समझ नहीं आ रहा।

[rlaehdus2003]

मौजूदा संरचना, जिसमें operational domain और analytics domain अलग-अलग हैं, के बारे में कहा गया है कि इसमें silo जैसी संरचनात्मक समस्या है। डेटा आर्किटेक्चर बनाते समय इन दोनों को अलग-अलग सोचने के बजाय, data producer और consumer के रूप में देखना चाहिए।

अब operational data और analytics data के बीच की सीमा धुंधली होती जा रही है, इसलिए graph thinking, या graph mindset, अपनाने की बात की गई है.

मुझे ऐसा लगता है कि operational data और analytics data को साफ़ तौर पर अलग करने के बजाय, operational data की निरंतरता में data consumer और producer को अलग करके data access को data flow के नज़रिए से देखा जा रहा है, भले ही भूमिकाएँ अलग हों।

ऐसा लगता है कि बात डेटा आर्किटेक्चर के उस दृष्टिकोण से की जा रही है जहाँ operational data का analysis होता है, फिर वह वापस operation में जाता है, और फिर दोबारा analysis में लौटता है।