एंटरप्राइज़ डेटा का आधुनिकीकरण: Hadoop, Netezza और डेटा प्लेटफ़ॉर्म की दिशा में बदलाव

डेटा परिवेश की स्थिति

किसी भी Tier-1 बैंक के डेटा परिवेश में इतिहास की परतें मिलेंगी। एक मेनफ़्रेम। 2000 के दशक में लिया गया Oracle वेयरहाउस। नियामकीय रिपोर्टिंग की ज़रूरत के लिए खरीदा गया Netezza उपकरण। एनालिटिक्स टीम द्वारा स्थापित Hadoop क्लस्टर। SAS कार्यभार। Tableau। SQL Server। Azure या AWS का बढ़ता उपयोग। हर परत उस दिन किसी की समस्या का सही उत्तर थी, जब उसे खरीदा गया।

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

रणनीतिक लैंडिंग ज़ोन के रूप में Hadoop

नए और असंरचित कार्यभारों के लिए Hadoop रणनीतिक विकल्प था। पढ़ते समय स्कीमा लागू करने से पहले लक्ष्य स्कीमा पर सहमति बनाए बिना कच्चा डेटा रख सकते थे; HDFS और Hive मेटास्टोर ने अलग-अलग डोमेन के डेटा जोड़ने के लिए एक भौतिक स्थान दिया; खुले इकोसिस्टम (Spark, Hive, Impala, आगे उपयोग होने वाली नोटबुक) ने अलग अवसंरचना खड़ी किए बिना एनालिटिक्स टीमों को ज़रूरी लचीलापन दिया।

हमारा आर्किटेक्चर नियम सरल था: यदि नया कार्यभार कच्चा इवेंट डेटा रखता है, विभिन्न डोमेन जोड़ता है या लचीली कंप्यूट क्षमता चाहने वाले डेटा वैज्ञानिकों के काम आता है, तो Hadoop चुना जाए। यदि वह सुव्यवस्थित डेटा मार्ट पर पंक्ति-स्तर की नियामकीय रिपोर्टिंग करता है, तो वहीं रहे जहाँ है।

तात्कालिक ज़रूरतों के भरोसेमंद साधन के रूप में Netezza

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

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

प्लेटफ़ॉर्म चयन का निर्णय-वृक्ष

नई पहलों के प्लेटफ़ॉर्म चयन को मंज़ूरी देने के लिए बैठक नहीं, बार-बार उपयोग किया जा सकने वाला निर्णय-वृक्ष चाहिए। हमने यह अपनाया:

• क्या यह मॉडल किए गए मार्ट पर नियामकीय रिपोर्टिंग है? → मौजूदा वेयरहाउस स्टैक (Netezza या Oracle)।
• क्या इसमें कच्चा, लचीली स्कीमा वाला इवेंट डेटा रखा जाता है? → Hadoop लैंडिंग ज़ोन।
• क्या यह लेनदेन संबंधी कार्यभार है? → परिचालन डेटाबेस, वेयरहाउस समूह नहीं।
• क्या यह नोटबुक के माध्यम से किया जाने वाला खोजपरक विश्लेषण है? → फ़ेडरेशन द्वारा मॉडल किए गए मार्ट तक केवल पढ़ने की पहुँच वाला Hadoop।
• क्या डेटा सेट नया और उसका उपभोक्ता क्लाउड-नेटिव है? → क्लाउड डेटा प्लेटफ़ॉर्म का मार्ग, स्थानीय परिवेश में वापस आने वाला सोच-समझकर तय किया गया एकतरफ़ा प्रवाह।

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

बिना लालफ़ीताशाही के गवर्नेंस

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

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

आपकी डेटा रणनीति के लिए इसका अर्थ

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

अपने डेटा परिवेश पर फिर विचार कर रहे हैं?

SEYSO ने Tier-1 बैंकों के लिए एंटरप्राइज़ डेटा आर्किटेक्चर पर परामर्श दिया है — प्लेटफ़ॉर्म चुनना, दोहराव हटाना और कई प्लेटफ़ॉर्म वाले डेटा परिवेश का प्रबंधन करना। यदि आप फैलते वेयरहाउस स्टैक, कम उपयोग वाले Hadoop क्लस्टर या क्रम तय करने की माँग वाले क्लाउड डेटा माइग्रेशन का सामना कर रहे हैं, तो हम बात करना चाहेंगे।