Hadoop क्या है, और यह K8s पर 10 माइक्रोसर्विसेज़ क्यों नहीं है

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

पहले मैं समझाता हूँ कि Hadoop असल में है क्या, फिर हम दोनों को साथ-साथ रखकर देखेंगे।

Hadoop असल में क्या है?

Apache Hadoop एक ऐसा फ़्रेमवर्क है जो इतने बड़े डेटासेट को स्टोर और प्रोसेस करने के लिए बनाया गया है जो एक मशीन पर नहीं समा सकते — हम टेराबाइट से लेकर पेटाबाइट तक की बात कर रहे हैं। इसे Apache Software Foundation ने बनाया और यह सस्ती कमोडिटी मशीनों के क्लस्टर पर एक क्लासिक मास्टर-स्लेव डिज़ाइन का पालन करता है [1]। पूरी बात यह है: एक बड़ा महँगा सर्वर खरीदने के बजाय, आप 50 साधारण सर्वर खरीदते हैं और उन्हें मिलकर काम करवाते हैं।

इसमें तीन परतें हैं, और इसे समझने के लिए आपको वाकई तीनों की ज़रूरत है:

• HDFS (Hadoop Distributed File System) — स्टोरेज परत। यह आपकी बड़ी फ़ाइलों को लेती है, उन्हें ब्लॉक-आकार के टुकड़ों में काटती है, और उन ब्लॉक्स को क्लस्टर की सभी मशीनों की डिस्क पर बिखेर देती है [1]।
• YARN (Yet Another Resource Negotiator) — रिसोर्स मैनेजर। यह तय करता है कि कौन-सी मशीन कौन-सा काम चलाएगी, और रिसोर्स मैनेजमेंट तथा जॉब शेड्यूलिंग को अलग-अलग डेमॉन में बाँट देता है [1]।
• MapReduce — मूल प्रोसेसिंग मॉडल। आप एक “map” स्टेप और एक “reduce” स्टेप लिखते हैं, और फ़्रेमवर्क उन्हें पूरे क्लस्टर में समानांतर रूप से चलाता है [1]।

HDFS आपके डेटा को कैसे फैलाता है

जब आप 1 TB की फ़ाइल HDFS में डालते हैं, तो वह एक डिस्क पर नहीं बैठती। HDFS उसे ब्लॉक्स में तोड़ता है (डिफ़ॉल्ट रूप से 128 MB प्रत्येक) और उन ब्लॉक्स को स्लेव नोड्स में स्टोर करता है। NameNode नामक एक मास्टर डेमॉन मेटाडेटा रखता है — फ़ाइल नाम, कौन-से ब्लॉक किस फ़ाइल के हैं, और सबसे अहम, कौन-सी मशीन किस ब्लॉक को रखती है। असली ब्लॉक्स DataNodes पर रहते हैं, जो हर मशीन पर चलने वाले स्लेव डेमॉन हैं [1]।

हर ब्लॉक की कई कॉपी भी बनती हैं (आमतौर पर अलग-अलग मशीनों पर 3 कॉपी), ताकि अगर कोई डिस्क खराब हो जाए — और सस्ते हार्डवेयर के साथ, डिस्क लगातार खराब होती रहती हैं — तो आपका डेटा बचा रहे। यही वह बात है जिसे लोग नज़रअंदाज़ कर देते हैं: Hadoop यह मानकर चलता है कि विफलता सामान्य है, अपवाद नहीं।

MapReduce इसे कैसे प्रोसेस करता है

यहाँ चालाकी वाली बात है। एक सामान्य Hadoop सेटअप में, कंप्यूट नोड्स और स्टोरेज नोड्स एक ही मशीनें होती हैं। MapReduce फ़्रेमवर्क और HDFS नोड्स के एक ही सेट पर चलते हैं। इससे फ़्रेमवर्क हर टास्क को उसी नोड पर शेड्यूल कर सकता है जहाँ डेटा पहले से भौतिक रूप से मौजूद है, जिससे आपको पूरे क्लस्टर में बहुत ऊँची कुल बैंडविड्थ मिलती है [2]।

वह आख़िरी वाक्य ही पूरा खेल है। चलिए इसे ज़ोर देकर कहता हूँ।

वह एक विचार जो Hadoop को परिभाषित करता है: कोड को ले जाओ, डेटा को नहीं

पहले दिन से Hadoop में एक डिज़ाइन लक्ष्य गहराई से बसा है: कंप्यूटेशन को डेटा के पास ले जाओ, बजाय इसके कि डेटा को कंप्यूटेशन के पास ले जाओ [3]। इसे डेटा लोकैलिटी कहते हैं, और यह कोई “अच्छा-तो-है” किस्म का ऑप्टिमाइज़ेशन नहीं है — यही वह कारण है जिसके लिए Hadoop अस्तित्व में है।

ज़रा सोचिए। आपका कोड — map फ़ंक्शन — शायद कुछ किलोबाइट का है। जिस डेटा ब्लॉक को इसे प्रोसेस करना है वह 128 MB का है। अगर आप डेटा को वहाँ भेजते हैं जहाँ कोड है, तो आप हर ब्लॉक के लिए नेटवर्क पर 128 MB धकेल रहे हैं, और आपके पास हज़ारों ब्लॉक्स हैं। नेटवर्क पिघल जाएगा। इसके बजाय, Hadoop छोटे-से कोड को उस मशीन पर भेजता है जो पहले से ब्लॉक रखती है, और उसे वहीं चलाता है, लोकल डिस्क से पढ़ते हुए [3]।

Hadoop यह भी रैंक करता है कि किसी टास्क की प्लेसमेंट कितनी अच्छी है:

• Data-local — टास्क ठीक उसी नोड पर चलता है जो ब्लॉक रखता है। सबसे बढ़िया स्थिति।
• Rack-local — ठीक वही नोड नहीं मिल पाता, तो उसे उसी सर्वर रैक की किसी दूसरी मशीन पर चलाओ (रैक के भीतर नेटवर्क तेज़ होता है) [4]।
• Off-rack — सबसे खराब स्थिति, डेटा रैक पार करता है। Hadoop इससे बचने की पूरी कोशिश करता है।

यह इतना मायने क्यों रखता है? क्योंकि स्टोरेज की दुनिया में एक चीज़ है जिसे डेटा ग्रैविटी कहते हैं — बड़े, सक्रिय डेटासेट एप्लिकेशन को अपनी ओर खींचते हैं चाहे वे कहीं भी रहें, क्योंकि डेटा को हिलाना बहुत धीमा और बहुत महँगा हो जाता है [5]। स्टोरेज खुद रुकावट नहीं है; डेटा मूवमेंट रुकावट है। भौतिकी ऐसी सीमाएँ लगाती है जिनके आसपास आप इंजीनियरिंग नहीं कर सकते — आप डेटा को उतनी तेज़ी से नहीं भेज सकते जितनी तेज़ी से उसे बना सकते हैं [5]। डेटा ग्रैविटी के प्रति Hadoop का जवाब था इससे लड़ना बंद कर देना। कंप्यूट को डेटा के पास ले आओ। यानी मूल रूप से, ग्रैविटी के आगे आत्मसमर्पण कर दो।

अब Kubernetes पर माइक्रोसर्विसेज़ वाला सेटअप

उस दूसरी चीज़ की कल्पना कीजिए जिसका सवाल में ज़िक्र था: एक Kubernetes क्लस्टर में चलती 10 माइक्रोसर्विसेज़, जो सभी किसी साझा स्टोरेज से बात कर रही हैं (मान लीजिए कोई नेटवर्क फ़ाइल सिस्टम, या कोई क्लाउड ऑब्जेक्ट स्टोर, या कोई मैनेज्ड डेटाबेस)।

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

और यहाँ वास्तुशिल्प सिद्धांत Hadoop के सिद्धांत के बिल्कुल विपरीत है। एक Kubernetes माइक्रोसर्विसेज़ सेटअप में, आप जानबूझकर स्टोरेज को कंप्यूट से अलग करते हैं। स्टोरेज परत उस कंप्यूट परत से पूरी तरह अलग होती है जिसे Kubernetes मैनेज करता है [6]। स्टेटलेस ऐप-सर्वर कंप्यूट अक्सर ऐसी डेटा सर्विसेज़ से जुड़ता है जो क्लस्टर के बाहर ही चलती हैं [6]।

एक और नियम है जो खुद माइक्रोसर्विसेज़ की दुनिया से आता है: सर्विसेज़ को डेटा स्टोर साझा नहीं करना चाहिए। हर सर्विस से अपेक्षा होती है कि वह अपने डेटासेट का मालिक खुद हो, ठीक इसलिए ताकि सर्विसेज़ के बीच छिपी निर्भरताओं और आकस्मिक कपलिंग से बचा जा सके [6]। तो “साझा स्टोरेज वाली 10 माइक्रोसर्विसेज़” वाक्यांश पहले से ही थोड़ा संदिग्ध है — सच्ची माइक्रोसर्विसेज़ वास्तुकला साझा स्टोरेज से दूर धकेलती है, इस ओर कि हर सर्विस अपने हिस्से की मालिक हो। (इस तनाव के बारे में आप Microsoft की AKS माइक्रोसर्विसेज़ रेफ़रेंस आर्किटेक्चर में और पढ़ सकते हैं।)

जब आप Kubernetes में स्टोरेज जोड़ते हैं, तो आप आमतौर पर क्लस्टर को NFS, GlusterFS, या Amazon EFS, Azure Files, और Google Cloud Filestore जैसी क्लाउड फ़ाइल सिस्टम पर उजागर पारंपरिक इन्फ़्रास्ट्रक्चर से जोड़ते हैं [6]। कंप्यूट और स्टोरेज अलग-अलग मशीनों पर होते हैं, जो नेटवर्क से जुड़े होते हैं। डेटा डिज़ाइन के हिसाब से ही दूरस्थ होता है।

आमने-सामने: असली फ़र्क़

तो चलिए अमूर्त बातें छोड़ते हैं। यहाँ है जहाँ ये सचमुच अलग होते हैं।

मुख्य बात: Hadoop कंप्यूट और स्टोरेज को जानबूझकर एक साथ रखता है; Kubernetes माइक्रोसर्विसेज़ उन्हें जानबूझकर अलग करती हैं। ये एक ही विचार के दो स्वाद नहीं हैं। ये दो अलग सवालों के जवाब हैं।

Hadoop पूछता है: “मेरे पास डेटा का एक पहाड़ शांत बैठा है। मैं नेटवर्क का दम घोंटे बिना इस सब पर कंप्यूटेशन कैसे चलाऊँ?”

Kubernetes माइक्रोसर्विसेज़ पूछती हैं: “मेरे पास छोटी, स्वतंत्र रिक्वेस्ट की बाढ़ है। मैं इन्हें भरोसेमंद ढंग से कैसे परोसूँ, हर हिस्से को अलग से कैसे स्केल करूँ, और क्रैश से कैसे बचूँ?”

एक परिदृश्य जो बात को साफ़ कर देगा

मान लीजिए आप एक ई-कॉमर्स साइट चलाते हैं।

Kubernetes पर माइक्रोसर्विसेज़ आपकी चलती-फिरती दुकान हैं: एक यूज़र “add to cart” पर क्लिक करता है, कार्ट सर्विस इसे संभालती है, इन्वेंट्री सर्विस स्टॉक जाँचती है, पेमेंट सर्विस कार्ड से पैसे काटती है। दस छोटी सर्विसेज़, हर एक ट्रैफ़िक के हिसाब से स्केल करती हुई, हर एक आदर्श रूप से अपने डेटा की मालिक। रिक्वेस्ट छोटी हैं, हर एक जिस डेटा को छूती है वह छोटा है, और लेटेंसी ही सब कुछ है। यहाँ नेटवर्क पर किसी साझा डेटाबेस को कुछ KB भेजना बिल्कुल ठीक है।

अब, रात 2 बजे, आप पिछले पाँच साल के हर ऑर्डर का विश्लेषण करना चाहते हैं ताकि खरीदारी के पैटर्न मिल सकें। वह 8 TB ऐतिहासिक लॉग है। आप 8 TB को नेटवर्क पर किसी माइक्रोसर्विस के ज़रिए नहीं खींचने वाले — आपका नेटवर्क और आपका बटुआ, दोनों डेटा ग्रैविटी से मर जाएँगे [5]। यह Hadoop-आकार का काम है: डेटा को HDFS पर पार्क करो, विश्लेषण कोड को वहाँ भेजो जहाँ ब्लॉक्स रहते हैं, उसे समानांतर में पीसो, और एक सारांश लिख दो। डेटा कभी नहीं हिलता; कोड हिलता है।

एक ही कंपनी, दो बिल्कुल अलग समस्याएँ, दो बिल्कुल अलग वास्तुकलाएँ। ये प्रतिस्पर्धी नहीं हैं — सच कहूँ तो, ये अक्सर एक ही इमारत में साथ-साथ रहती हैं।

“पर मेरी माइक्रोसर्विसेज़ भी तो डेटा प्रोसेस करती हैं!”

बेशक करती हैं। यहीं बात पेचीदा हो जाती है, और यहीं तुलना धुँधली लगने लगती है। एक माइक्रोसर्विस ज़रूर एक फ़ाइल पढ़ सकती है, उसे रूपांतरित कर सकती है, और वापस लिख सकती है। तो फिर असली रेखा क्या है?

यह तीन बातों पर निर्भर करता है:

1. मात्रा और लोकैलिटी। एक माइक्रोसर्विस एक पंक्ति, एक दस्तावेज़, एक छोटा ब्लॉब लाती है — यह दूरस्थ डेटा को कंप्यूट के पास खींचती है। Hadoop इतने बड़े पैमाने पर ऐसा करने से इनकार करता है क्योंकि डेटा हिलाने के लिए बहुत बड़ा है, इसलिए वह कंप्यूट को डेटा के पास भेजता है [3]। अगर आपके काम की रुकावट यह है कि “मैं तो सारा डेटा पढ़ भी नहीं पाता इतनी तेज़ी से,” तो आप Hadoop के इलाके में हैं।

2. काम की महीनता। माइक्रोसर्विसेज़ रिक्वेस्ट के हिसाब से सोचती हैं — छोटी, अलग-थलग, कम-लेटेंसी वाली। Hadoop जॉब्स के हिसाब से सोचता है — पूरे डेटासेट पर लंबे समय तक चलने वाले बैच पास, जहाँ आप खुशी-खुशी मिनटों या घंटों इंतज़ार करते हैं [7]। MapReduce की बैच प्रकृति असल में रियल-टाइम काम के लिए लेटेंसी की समस्याएँ पैदा करती है, और यही ठीक वह कारण है जिससे यह लाइव रिक्वेस्ट परोसने के लिए ग़लत औज़ार है [7]।

3. कपलिंग का दर्शन। माइक्रोसर्विसेज़ ढीली कपलिंग और स्वतंत्र स्टोरेज स्वामित्व चाहती हैं ताकि टीमें एक-दूसरे के रास्ते में आए बिना तेज़ी से आगे बढ़ सकें [6]। Hadoop कंप्यूट और स्टोरेज की कसकर एक-साथ स्थिति चाहता है ताकि वह नेटवर्क की लड़ाई जीत सके। ये लक्ष्य सचमुच एक-दूसरे का खंडन करते हैं।

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

जानने लायक एक पेच: बिग डेटा भी “शुद्ध” Hadoop से दूर हट गया

अगर मैं आपको यह आभास दूँ कि Hadoop अब भी बिग डेटा के लिए डिफ़ॉल्ट है, तो मैं आपके साथ अन्याय करूँगा। अब ऐसा नहीं है। Hadoop ने डिस्ट्रिब्यूटेड कंप्यूटिंग का बीड़ा उठाया, पर नई परियोजनाओं के लिए इसका इस्तेमाल घट रहा है [7]। MapReduce हर स्टेप के बीच मध्यवर्ती नतीजों को डिस्क पर लिखता है, जो धीमा है, इसलिए Apache Spark आया और उसी किस्म की डिस्ट्रिब्यूटेड प्रोसेसिंग ज़्यादातर मेमोरी में करने लगा, जिससे पुनरावृत्त (iterative) और इंटरैक्टिव काम नाटकीय रूप से तेज़ हो गया [7]।

और व्यापक इकोसिस्टम बहुत बड़ा है — Hadoop सिर्फ़ MapReduce नहीं है। इसने ऐसे औज़ार उगाए जैसे:

• Hive — एक डेटा-वेयरहाउस परत जो आपको HiveQL नामक SQL-जैसी भाषा से HDFS डेटा पर क्वेरी करने देती है [8]।
• HBase — एक डिस्ट्रिब्यूटेड डेटाबेस जो अरबों पंक्तियों और लाखों कॉलम वाली टेबलों में संरचित डेटा स्टोर करता है, सीधे HDFS पर बैठा हुआ [8]।
• Pig — एक उच्च-स्तरीय प्लेटफ़ॉर्म जो बड़े डेटासेट को लोड, फ़िल्टर और रूपांतरित करने के लिए PigLatin का उपयोग करता है [8]।

दिलचस्प बात यह है कि आधुनिक क्लाउड-डेटा दुनिया ने Hadoop के मूल सबक को आंशिक रूप से भुला दिया है। BigQuery और Snowflake जैसे औज़ार जानबूझकर स्टोरेज को कंप्यूट से फिर अलग करते हैं — वही डिकपलिंग जो Kubernetes माइक्रोसर्विसेज़ इस्तेमाल करती हैं — क्योंकि क्लाउड में, ऑब्जेक्ट स्टोरेज और कंप्यूट के बीच नेटवर्क बैंडविड्थ इतनी तेज़ और सस्ती हो गई कि डेटा लोकैलिटी 2008 की तुलना में कम मायने रखती है। तो एक मज़ेदार तरीके से, पेंडुलम “सब कुछ एक साथ रखो” (Hadoop) से झूलकर “सब कुछ अलग करो” (क्लाउड डेटा वेयरहाउस और माइक्रोसर्विसेज़ दोनों) की ओर चला गया। जैसे-जैसे AI वर्कलोड फिर से डेटा की मात्रा को विस्फोटित करता है, यह स्थिति टिकेगी या नहीं, यह एक खुला सवाल है — कुछ लोग तर्क देते हैं कि डेटा ग्रैविटी ज़ोर-शोर से वापस आ रही है और असल में कभी गई ही नहीं थी [5]।

तो, क्या ये एक ही चीज़ हैं या नहीं?

नहीं। और मैं इसे सबसे साफ़ तरीके से यूँ कह सकता हूँ।

माइक्रोसर्विसेज़ चलाता एक Kubernetes क्लस्टर एक रिक्वेस्ट-परोसने वाली मशीन है। इसकी प्रवृत्ति है कंप्यूट को स्टेटलेस और हल्का रखना, और डेटा को बाहर वहाँ धकेलना जहाँ उसे साझा किया जा सके या स्वतंत्र रूप से उसका मालिक हुआ जा सके। नेटवर्क डेटा को कंप्यूट के पास ले जाता है, और यह स्वीकार्य है क्योंकि हर रिक्वेस्ट बहुत थोड़ा डेटा छूती है [6]।

Hadoop एक डेटा-पीसने वाली मशीन है। इसकी प्रवृत्ति है डेटा को उन्हीं डिस्क पर कील ठोककर रखना जो कंप्यूट करती हैं, क्योंकि पेटाबाइट हिलाना भौतिकी के खिलाफ़ हारने वाली लड़ाई है। नेटवर्क कोड को डेटा के पास ले जाता है [3]।

अगर आपको सिर्फ़ एक पंक्ति याद रहे: माइक्रोसर्विसेज़ डेटा को कोड के पास ले जाती हैं; Hadoop कोड को डेटा के पास ले जाता है। बाकी सब कुछ — डेमॉन, रेप्लिकेशन, YARN शेड्यूलिंग, StatefulSets — उसी एक फ़ैसले से बहता है।

ये सतही तरीकों से ओवरलैप करते हैं (क्लस्टर, डिस्ट्रिब्यूशन, फ़ॉल्ट टॉलरेंस), यही वजह है कि यह सवाल पूछना इतना स्वाभाविक है। पर ये वास्तुकलाएँ किसी भी डिस्ट्रिब्यूटेड सिस्टम की सबसे महँगी चीज़ को लेकर विपरीत दाँव पर बनी हैं: तार के पार बाइट हिलाना।

समाप्त

स्रोत

1. Apache Hadoop Architecture - HDFS, YARN & MapReduce (TechVidvan)
2. Apache Hadoop 3.3.5 – MapReduce Tutorial (Official Docs)
3. Data Locality in Hadoop: The Most Comprehensive Guide (DataFlair)
4. Introduction to Data Locality in Hadoop MapReduce (TechVidvan)
5. What Is Data Gravity in Cloud Architecture? (simplyblock)
6. Kubernetes Assimilation and the Need of Persistent Storage (Lightbits)
7. Hadoop vs. Spark: Which One Should You Choose? (Back4App)
8. Exploring the Hadoop Ecosystem: Hive, Pig, HBase, and More (Medium)