7.2 डेटा इंजीनियरिंग

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

• पाइपलाइन सॉफ़्टवेयर हैं और इनके वर्ज़न कंट्रोल, टेस्टिंग, समीक्षा, और CI/CD के हक़दार हैं।
• आइडेम्पोटेंट, पुनरुत्पादनीय ट्रांसफ़ॉर्मेशन को प्राथमिकता दें जो सुरक्षित रूप से फिर से चलाए जा सकें।
• डेटा प्रवाह को ऑब्ज़र्वेबल बनाएँ: ताज़गी, वॉल्यूम, स्कीमा, और गुणवत्ता की निगरानी करें।
• कच्ची तालिकाओं को फेंकने के बजाय अपने उपभोक्ताओं के लिए डेटा को जानबूझकर मॉडल करें।
• नवीनता के बजाय वास्तविक लेटेंसी आवश्यकताओं के आधार पर बैच या स्ट्रीमिंग चुनें।
• स्टोरेज प्रारूप, पार्टीशनिंग, और कंप्यूट लागत को प्रथम-श्रेणी चिंताओं के रूप में अनुकूलित करें।
• इनजेशन, ट्रांसफ़ॉर्मेशन, और सर्विंग को अलग करें ताकि हर एक स्वतंत्र रूप से विकसित हो सके।
• ज़ोर से और जल्दी विफल हों; एक टूटी हुई पाइपलाइन चुपचाप गलत डेटा से ज़्यादा सुरक्षित है।

सिफ़ारिशें

ETL या ELT को जानबूझकर चुनें

ETL डेटा को गंतव्य में लोड करने से पहले परिवर्तित करता है। ELT (एक्सट्रैक्ट, लोड, ट्रांसफ़ॉर्म) पहले कच्चा डेटा लोड करता है और इसे एक शक्तिशाली वेयरहाउस या लेकहाउस के अंदर परिवर्तित करता है। आधुनिक क्लाउड प्लेटफ़ॉर्म ने ELT को डिफ़ॉल्ट बना दिया है, क्योंकि स्टोरेज सस्ता है और कंप्यूट लचीला है, और कच्चा डेटा रखने से आप लॉजिक बदलने या बग सामने आने पर पुनः प्रोसेस कर सकते हैं। एनालिटिक्स वर्कलोड के लिए ELT को प्राथमिकता दें: कच्चा अपरिवर्तनीय डेटा उतारें, फिर उसके ऊपर स्तरीकृत ट्रांसफ़ॉर्मेशन बनाएँ। लोड-पूर्व ट्रांसफ़ॉर्मेशन उन मामलों के लिए बचाकर रखें जहाँ गोपनीयता, लागत, या संविदात्मक बाध्यताएँ डेटा उतरने से पहले सफ़ाई या फ़िल्टरिंग की माँग करती हैं।

बैच और स्ट्रीमिंग पाइपलाइन को उनकी लेटेंसी आवश्यकताओं के लिए डिज़ाइन करें

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

स्पष्ट डिपेंडेंसी के साथ ऑर्केस्ट्रेट करें

पाइपलाइनों को स्पष्ट डिपेंडेंसी, रीट्राई, और शेड्यूलिंग के साथ कार्यों के डायरेक्टेड एसाइक्लिक ग्राफ़ (DAG) के रूप में व्यक्त करने के लिए एक ऑर्केस्ट्रेटर का इस्तेमाल करें। यह आपको इस बात की दृश्यता देता है कि क्या चला, क्या विफल हुआ, और क्या ब्लॉक है, साथ ही बैकफ़िल और नियतात्मक रूप से फिर से चलाने की क्षमता। डिपेंडेंसी को केवल घड़ी के समय पर नहीं बल्कि डेटा उपलब्धता पर आधारित करें, ताकि डाउनस्ट्रीम जॉब अनुमान पर चलने के बजाय अपस्ट्रीम डेटा की प्रतीक्षा करें। ऑर्केस्ट्रेशन लॉजिक को वर्ज़न कंट्रोल में रखें, और DAG बदलावों को कोड बदलावों की तरह मानें।

उपभोग के लिए डेटा मॉडल करें

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

पाइपलाइनों को आइडेम्पोटेंट और टेस्ट करने योग्य बनाएँ

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

ऑब्ज़र्वेबिलिटी और विश्वसनीयता को इंस्ट्रुमेंट करें

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

स्टोरेज और लागत को अनुकूलित करें

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान	सबसे अच्छा फ़िट
ELT (उसी जगह ट्रांसफ़ॉर्म)	कच्चा डेटा रखता है, सस्ता स्टोरेज, पुनः-प्रोसेस करने योग्य	बड़ा स्टोरेज फुटप्रिंट, गवर्नेंस चाहिए	क्लाउड एनालिटिक्स
ETL (लोड से पहले ट्रांसफ़ॉर्म)	लागत नियंत्रित करता है, संवेदनशील डेटा को जल्दी फ़िल्टर करता है	कच्चा डेटा खो देता है, पुनः-प्रोसेस करना कठिन	विनियमित या सीमित लोड
बैच	सरल, टेस्ट करने योग्य, आसान बैकफ़िल	अधिक लेटेंसी	अधिकांश एनालिटिक्स
स्ट्रीमिंग	कम लेटेंसी, रीयल-टाइम प्रतिक्रिया	जटिल, महंगा, टेस्ट करना कठिन	धोखाधड़ी, ऑप्स अलर्टिंग
स्टार स्कीमा	गवर्न किया गया, पुन: उपयोग योग्य, सेल्फ़-सर्विस-अनुकूल	पहले से मॉडलिंग प्रयास	साझा BI
चौड़ी तालिका	ज्ञात क्वेरी के लिए तेज़, सरल	डुप्लिकेशन, कम लचीला	संकीर्ण उच्च-प्रदर्शन उपयोग

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या आपने जानबूझकर ETL के बजाय ELT चुना है, और क्या आप कच्चा अपरिवर्तनीय डेटा रख रहे हैं ताकि लॉजिक बदलने या बग सामने आने पर आप पुनः प्रोसेस कर सकें? इस अध्याय का डिफ़ॉल्ट ELT है: कच्चा डेटा सस्ते में उतारें, फिर स्तरीकृत ट्रांसफ़ॉर्मेशन बनाएँ, क्योंकि कच्चा डेटा रखने से आप हफ़्तों बाद किसी नियम के बदलने या बग सामने आने पर सब कुछ फिर से चला सकते हैं। कच्चा डेटा मिटाना उस विकल्प को बंद कर देता है और एक आम, दर्दनाक ग़लती है। ETL के लिए प्रतिस्पर्धी मामला विनियमित या सीमित लोड में वास्तविक है, जहाँ गोपनीयता, लागत, या अनुबंध शर्तें डेटा उतरने से पहले फ़िल्टरिंग या मास्किंग की माँग करती हैं। प्रमाण लाएँ: आपको इतिहास को कितनी बार पुनः प्रोसेस करने की ज़रूरत पड़ी है, और जब आप नहीं कर पाए तो इसकी कीमत क्या थी? एक ऐसी सरकारी या उद्यम पाइपलाइन के लिए जिसे किसी भी आँकड़े को स्रोत तक ट्रेस करना ही होता है, अपरिवर्तनीय कच्चे रिकॉर्ड एक ऑडिट-योग्यता आवश्यकता भी हैं, इसलिए जवाब आपकी स्टोरेज नीति और आपकी कानूनी बचाव-योग्यता दोनों को आकार देता है।

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

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

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

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

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

क्षेत्र-विशेष दृष्टिकोण

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

छोटा व्यवसाय। बिना किसी समर्पित डेटा इंजीनियर के, एक इकाई को इकट्ठा करने के बजाय एक एकीकृत स्टैक खरीदने को प्राथमिकता दें। एक मैनेज्ड ELT सेवा प्लस एक क्लाउड वेयरहाउस आपको उन्हें बनाए रखने के लिए एक प्लेटफ़ॉर्म टीम के बिना कनेक्टर, शेड्यूलिंग, और स्टोरेज देता है। इस चुनाव को एक पाइपलाइन परियोजना के बजाय डेटा स्वच्छता के रूप में फ़्रेम करें: जानें कि कौन-से स्रोत सिस्टम आपकी रिपोर्टों को फ़ीड करते हैं, कच्चा डेटा रखें ताकि एक गलत संख्या को ट्रेस और पुनः-प्रोसेस किया जा सके, और ऐसे टूल चुनें जिनकी लागत पूर्वानुमेय हो ताकि एक फ़ुल-टेबल स्कैन मासिक बजट को न उड़ा दे।

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

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

उदाहरण

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

उद्यम। एक वैश्विक खुदरा विक्रेता ने सैकड़ों हाथ से लिखी एक्सट्रैक्ट स्क्रिप्ट को एक ELT स्टैक से बदल दिया। मैनेज्ड कनेक्टर कच्चा स्रोत डेटा उतारते हैं, एक ट्रांसफ़ॉर्मेशन फ़्रेमवर्क एक लेकहाउस में टेस्ट किए गए, वर्ज़न-नियंत्रित मॉडल बनाता है, और एक ऑर्केस्ट्रेटर रीट्राई और बैकफ़िल के साथ डिपेंडेंसी प्रबंधित करता है। डेटा टेस्ट स्रोत सिस्टम से स्कीमा बहाव को डैशबोर्ड तक पहुँचने से पहले पकड़ लेते हैं। पार्टीशन किए गए कॉलमनार स्टोरेज ने क्वेरी लागत को काफ़ी हद तक घटा दिया, जबकि ताज़गी को दैनिक से घंटेवार में सुधार दिया।

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

व्यवसाय मामला: प्रेरणाएँ, ROI, और TCO

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

अपनाने की लागत में प्लेटफ़ॉर्म टूलिंग, टेस्ट की गई मॉड्यूलर पाइपलाइन बनाने का इंजीनियरिंग समय, और डेटा को सॉफ़्टवेयर की तरह मानने का अनुशासन शामिल है। इसे न अपनाने की लागत के विरुद्ध तौलें: नाज़ुक कस्टम जॉब जिन्हें केवल उनके लेखक समझते हैं, कार्यकारियों द्वारा खोजी गई चुपचाप डेटा भ्रष्टाचार, फ़ुल-टेबल स्कैन से बढ़ता क्लाउड खर्च, और डेटा की प्रतीक्षा में अटके विश्लेषक। नेतृत्व के लिए, डेटा इंजीनियरिंग को उस बुनियाद के रूप में फ़्रेम करें जो एनालिटिक्स, BI, और AI को भरोसेमंद और किफ़ायती बनाती है। यहाँ कम-निवेश करें, और आप उसके ऊपर हर डेटा पहल के प्रतिफल को सीमित कर देते हैं।

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

1. आरंभ: तदर्थ स्क्रिप्ट और मैन्युअल चलाना, बिना टेस्ट या निगरानी के। विफलताएँ डाउनस्ट्रीम उपभोक्ताओं द्वारा खोजी जाती हैं, जॉब सुरक्षित रूप से फिर से चलाने योग्य नहीं हैं, और क्लाउड लागत अप्रबंधित और अश्रेय है।
2. विकास: कुछ टीमों ने एक ऑर्केस्ट्रेटर अपनाया है और बुनियादी ट्रांसफ़ॉर्मेशन को वर्ज़न कंट्रोल में डाला है, लेकिन संगठन में अभ्यास असंगत है। कभी-कभार टेस्ट मौजूद हैं, आइडेम्पोटेंस असमान है, और टूटी हुई पाइपलाइन का मतलब अभी भी प्रतिक्रियाशील आग बुझाना है।
3. मानकीकरण: एक स्तरीकृत स्टेजिंग-कोर-मार्ट मॉडल के साथ ELT, टेस्ट किया गया और वर्ज़न-नियंत्रित, टीमों में लागू दस्तावेज़ीकृत मानक है। रीट्राई और बैकफ़िल के साथ ऑर्केस्ट्रेट की गई डिपेंडेंसी, CI में चलने वाले डेटा टेस्ट, और स्टार-स्कीमा मॉडलिंग व पार्टीशनिंग के लिए साझा परंपराएँ हर समूह पर छोड़ने के बजाय पूरे संगठन में लागू हैं।
4. प्रबंधन: प्लेटफ़ॉर्म को मापा और नियंत्रित किया जाता है। ताज़गी, वॉल्यूम, स्कीमा, और वितरण की निगरानी की जाती है जिसमें अलर्ट मालिक टीमों तक रूट होते हैं, और पाइपलाइन SLA, औसत पहचान समय, डेटा-गुणवत्ता पास दर, और प्रति-पाइपलाइन व प्रति-क्वेरी कंप्यूट लागत बेसलाइन के विरुद्ध ट्रैक की जाती हैं। रोलबैक और किल सीमाएँ प्रमाण पर लागू की जाती हैं, और लागत व विश्वसनीयता के नामित मालिक लक्ष्यों के प्रति जवाबदेह हैं।
5. समन्वय: पाइपलाइनों को CI/CD, डेटा अनुबंधों, और स्वचालित असामान्यता पहचान के साथ पूरी तरह सॉफ़्टवेयर की तरह माना जाता है जो उपभोक्ताओं से पहले बहाव पकड़ लेता है। जहाँ लेटेंसी वास्तव में भुगतान करती है वहाँ बैच और स्ट्रीमिंग लॉजिक एकीकृत है, प्लेटफ़ॉर्म को लगातार सुधारा जाता है और यह सेल्फ़-सर्विस है, और वर्कलोड के बदलने के साथ क्षमता, स्टोरेज टियर, और लागत को अनुकूली रूप से फिर से संतुलित किया जाता है ताकि नए डेटा उत्पाद एक स्थिर बुनियाद पर तेज़ी से भेजे जाएँ।

चर्चा के लिए विचार

• आपके स्टैक में “रीयल-टाइम” वास्तव में अपनी लागत कहाँ अर्जित करता है, और यह कहाँ एक इच्छापूर्ण सोच है?
• आपकी कौन-सी पाइपलाइन आज सुरक्षित रूप से फिर से नहीं चलाई जा सकतीं, और इसे ठीक करने के लिए क्या करना होगा?
• आपके क्लाउड डेटा बिल का कितना हिस्सा पूरे स्कैन और गायब पार्टीशन से आता है?
• क्या आपके विश्लेषक मॉडल किए गए मार्ट का उपभोग करते हैं या कच्ची तालिकाओं का, और इसकी उन्हें क्या कीमत चुकानी पड़ती है?
• किसी डेटा घटना का पता लगाने में आपका औसत समय क्या है, और इसे सबसे पहले कौन खोजता है?
• क्या बैच और स्ट्रीमिंग लॉजिक को एकीकृत करने से आपका रखरखाव बोझ घटेगा या जोखिम बढ़ेगा?

मुख्य निष्कर्ष

• पाइपलाइनों को सॉफ़्टवेयर की तरह मानें: वर्ज़न कंट्रोल, टेस्ट, समीक्षा, CI/CD, और ऑब्ज़र्वेबिलिटी।
• स्तरीकृत, टेस्ट किए गए मॉडल के साथ ELT को प्राथमिकता दें; पुनः-प्रोसेसिंग के लिए कच्चा डेटा रखें।
• डिफ़ॉल्ट रूप से बैच चुनें और केवल वहाँ स्ट्रीमिंग चुनें जहाँ लेटेंसी वास्तव में भुगतान करती है।
• ट्रांसफ़ॉर्मेशन को आइडेम्पोटेंट बनाएँ ताकि पुनः-चलाना सुरक्षित हो।
• स्टार स्कीमा या जानबूझकर चौड़ी तालिकाओं के साथ उपभोक्ताओं के लिए डेटा मॉडल करें।
• ताज़गी, वॉल्यूम, स्कीमा, और वितरण की निगरानी करें, और डेटा घटनाओं को आउटेज की तरह मानें।
• स्टोरेज प्रारूप, पार्टीशनिंग, और कंप्यूट लागत को प्रथम-श्रेणी चिंताओं के रूप में अनुकूलित करें।

संदर्भ और आगे पढ़ने के लिए

• Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
• Ralph Kimball and Margy Ross, “The Data Warehouse Toolkit.”
• Martin Kleppmann, “Designing Data-Intensive Applications.”
• Bill Inmon, “Building the Data Warehouse.”
• James Densmore, “Data Pipelines Pocket Reference.”
• Nathan Marz and James Warren, “Big Data” (Lambda architecture).
• Barr Moses and colleagues, “Data Quality Fundamentals” (data observability).