Hadoop म्हणजे काय, आणि ते K8s वरचे 10 मायक्रोसर्व्हिसेस का नाही

मागच्या आठवड्यात कुणीतरी मला हाच प्रश्न विचारला, आणि तो चांगला प्रश्न आहे कारण दोन्ही रचना डोळे बारीक करून पाहिल्या तर सारख्याच दिसतात. काही मशीन्स, मधे थोडं शेअर्ड स्टोरेज, आणि नोड्सवर पसरलेलं काम. मग एकाला “बिग डेटा” आणि दुसऱ्याला “मायक्रोसर्व्हिसेस” का म्हणतात? हे एकाच क्लस्टरसाठी दोन शब्द आहेत का? खरं सांगायचं तर, नाही. ते एकाच गोष्टीबद्दलच्या अगदी विरुद्ध गृहीतकांवर उभे आहेत: डेटा कुठे राहतो आणि कोण कुणाकडे जातो.

आधी Hadoop प्रत्यक्षात काय आहे ते उलगडून सांगतो, मग आपण दोन्ही गोष्टी शेजारी-शेजारी ठेवू.

Hadoop म्हणजे खरंतर काय?

Apache Hadoop हे अशा डेटासेट्सना साठवण्यासाठी आणि प्रोसेस करण्यासाठी असलेलं एक फ्रेमवर्क आहे, जे एका मशीनवर मावण्याइतके मोठे नसतात — आपण इथे टेराबाइट्सपासून पेटाबाइट्सपर्यंत बोलत आहोत. ते Apache Software Foundation ने बनवलं आणि ते स्वस्त कॉमोडिटी मशीन्सच्या क्लस्टरवर एका क्लासिक मास्टर-स्लेव्ह डिझाइनचं अनुसरण करतं [1]. याचा संपूर्ण मुद्दा असा आहे: एक प्रचंड महाग सर्व्हर विकत घेण्याऐवजी, तुम्ही ५० साधारण सर्व्हर विकत घेता आणि त्यांना एकत्र काम करायला लावता.

याला तीन थर आहेत, आणि ते समजून घेण्यासाठी तुम्हाला तिन्हींची खरोखर गरज आहे:

• HDFS (Hadoop Distributed File System) — स्टोरेज थर. हे तुमच्या मोठ्या फाइल्स घेतं, त्यांना ब्लॉक-आकाराच्या तुकड्यांत कापतं, आणि ते ब्लॉक्स क्लस्टरमधल्या सगळ्या मशीन्सच्या डिस्क्सवर विखुरतं [1].
• YARN (Yet Another Resource Negotiator) — रिसोर्स मॅनेजर. कोणतं काम कोणत्या मशीनवर चालवायचं हे ते ठरवतं, आणि रिसोर्स मॅनेजमेंट व जॉब शेड्युलिंग वेगवेगळ्या डीमन्समध्ये विभागतं [1].
• MapReduce — मूळ प्रोसेसिंग मॉडेल. तुम्ही एक “map” स्टेप आणि एक “reduce” स्टेप लिहिता, आणि फ्रेमवर्क त्या क्लस्टरभर समांतरपणे चालवतं [1].

HDFS तुमचा डेटा कसा पसरवतं

जेव्हा तुम्ही १ TB ची फाइल HDFS मध्ये टाकता, तेव्हा ती एका डिस्कवर बसत नाही. HDFS तिला ब्लॉक्समध्ये (डिफॉल्टनुसार प्रत्येकी १२८ MB) विभागतं आणि ते ब्लॉक्स स्लेव्ह नोड्सवर साठवतं. NameNode नावाचा एक मास्टर डीमन मेटाडेटा सांभाळतो — फाइलनेम्स, कोणते ब्लॉक्स कोणत्या फाइलचे आहेत, आणि सर्वांत महत्त्वाचं, प्रत्येक ब्लॉक कोणत्या मशीनवर आहे. प्रत्यक्ष ब्लॉक्स DataNodes वर राहतात, जे प्रत्येक मशीनवर चालणारे स्लेव्ह डीमन्स असतात [1].

प्रत्येक ब्लॉकची रेप्लिकाही बनवली जाते (सहसा वेगवेगळ्या मशीन्सवर ३ प्रती), त्यामुळे एखादी डिस्क बंद पडली — आणि स्वस्त हार्डवेअरमध्ये डिस्क सतत बंद पडतात — तरी तुमचा डेटा टिकून राहतो. हाच भाग लोक दुर्लक्षित करतात: Hadoop गृहीत धरतं की फेल्युअर सामान्य आहे, अपवाद नव्हे.

MapReduce ते कसं प्रोसेस करतं

इथे एक हुशारीचा भाग आहे. सर्वसाधारण Hadoop रचनेत, कॉम्प्युट नोड्स आणि स्टोरेज नोड्स एकाच मशीन्स असतात. MapReduce फ्रेमवर्क आणि HDFS एकाच नोड्सच्या संचावर चालतात. यामुळे फ्रेमवर्कला प्रत्येक टास्क त्या नोडवर शेड्युल करता येतो जिथे डेटा आधीच भौतिकरीत्या आहे, आणि यामुळे क्लस्टरभर खूप जास्त एकत्रित बँडविड्थ मिळते [2].

ते शेवटचं वाक्य म्हणजे सगळा खेळ आहे. मी ते मोठ्या आवाजात सांगतो.

Hadoop ला परिभाषित करणारी एकमेव कल्पना: कोड हलवा, डेटा नाही

Hadoop मध्ये पहिल्या दिवसापासूनच भिनलेलं एक डिझाइन उद्दिष्ट: डेटाला कॉम्प्युटेशनकडे नेण्याऐवजी, कॉम्प्युटेशनला डेटाकडे न्या [3]. याला डेटा लोकॅलिटी म्हणतात, आणि ही काही “असली तर बरं” अशी ऑप्टिमायझेशन नाही — हेच Hadoop अस्तित्वात असण्याचं कारण आहे.

जरा विचार करा. तुमचा कोड — map फंक्शन — फार तर काही किलोबाइट्सचा असेल. ज्या डेटा ब्लॉकवर त्याला काम करायचं आहे तो १२८ MB चा आहे. जर तुम्ही डेटाला कोड जिथे आहे तिकडे पाठवलात, तर तुम्ही प्रत्येक ब्लॉकसाठी १२८ MB नेटवर्कवरून ढकलत आहात, आणि तुमच्याकडे हजारो ब्लॉक्स आहेत. नेटवर्क वितळून जाईल. त्याऐवजी, Hadoop तो छोटासा कोड त्या मशीनवर पाठवतं जिथे ब्लॉक आधीच आहे, आणि तो तिथेच चालवतं, लोकल डिस्कवरून वाचून [3].

Hadoop तर टास्क प्लेसमेंट किती चांगलं आहे याची क्रमवारीही ठरवतं:

• Data-local — टास्क बरोबर त्याच नोडवर चालतो जिथे ब्लॉक आहे. सर्वोत्तम परिस्थिती.
• Rack-local — बरोबर तो नोड मिळत नसेल, तर त्याच सर्व्हर रॅकमधल्या दुसऱ्या मशीनवर चालवा (रॅकमधलं नेटवर्क वेगवान असतं) [4].
• Off-rack — सर्वांत वाईट परिस्थिती, डेटा रॅक ओलांडतो. Hadoop हे टाळण्याचा कसून प्रयत्न करतं.

हे इतकं का महत्त्वाचं आहे? कारण स्टोरेजच्या जगात ज्याला डेटा ग्रॅव्हिटी म्हणतात त्यामुळे — मोठे, ॲक्टिव्ह डेटासेट्स अॅप्लिकेशन्सना ते जिथे असतील तिकडे खेचतात, कारण डेटा हलवणं खूप संथ आणि खूप महाग होऊन बसतं [5]. स्टोरेज स्वतः अडसर नसतो; डेटा हलवणं असतं. भौतिकशास्त्र अशा मर्यादा लादतं ज्यांभोवती तुम्ही इंजिनिअरिंग करू शकत नाही — तुम्ही डेटा जितक्या वेगाने तयार करता तितक्या वेगाने तो पाठवू शकत नाही [5]. डेटा ग्रॅव्हिटीला Hadoop चं उत्तर म्हणजे तिच्याशी झगडणं सोडून देणं. कॉम्प्युटला डेटाकडे आणा. थोडक्यात, गुरुत्वाकर्षणाला शरण जा.

आता मायक्रोसर्व्हिसेस-ऑन-Kubernetes रचना

प्रश्नात वर्णन केलेली दुसरी गोष्ट कल्पना करा: Kubernetes क्लस्टरमध्ये चालणारे १० मायक्रोसर्व्हिसेस, जे सगळे काही शेअर्ड स्टोरेजशी (समजा एखादी नेटवर्क फाइल सिस्टम, किंवा क्लाउड ऑब्जेक्ट स्टोअर, किंवा मॅनेज्ड डेटाबेस) बोलत आहेत.

Kubernetes ची मूलभूत रचना स्टेटलेस अॅप्लिकेशन्ससाठी झाली होती — असे सर्व्हिसेस जे बंद पडल्यावर काहीही लक्षात ठेवण्याची गरज नसते. हीच स्टेटलेसनेस तो जादूचा परिणाम घडवते: डिक्लरेटिव्ह डिप्लॉयमेंट्स, हाय अव्हेलेबिलिटी, ऑटोस्केलिंग, आणि एखादा सर्व्हिस सहज थांबवणं, पुन्हा चालू करणं व क्लोन करण्याची क्षमता [6]. तुमचा शॉपिंग-कार्ट सर्व्हिस, तुमचा ऑथ सर्व्हिस, तुमचा पेमेंट सर्व्हिस — प्रत्येक एक छोटासा बॉक्स आहे जो एक रिक्वेस्ट हाताळतो आणि ती विसरून जातो.

आणि इथलं आर्किटेक्चरल तत्त्व Hadoop च्या तत्त्वाच्या अगदी उलट आहे. Kubernetes मायक्रोसर्व्हिस रचनेत, तुम्ही जाणीवपूर्वक स्टोरेजला कॉम्प्युटपासून वेगळं करता. स्टोरेज थर हा Kubernetes सांभाळत असलेल्या कॉम्प्युट थरापासून पूर्णपणे वेगळा केलेला असतो [6]. स्टेटलेस अॅप-सर्व्हर कॉम्प्युट अनेकदा अशा डेटा सर्व्हिसेसशी जोडलं जातं जे क्लस्टरच्या बाहेर चालतात [6].

मायक्रोसर्व्हिसेसच्या जगातूनच आलेला आणखी एक नियम आहे: सर्व्हिसेसनी डेटा स्टोअर शेअर करू नये. प्रत्येक सर्व्हिसने स्वतःचा डेटासेट स्वतः सांभाळावा अशी अपेक्षा असते, नेमकं याचसाठी की सर्व्हिसेसमधील लपलेल्या डिपेंडन्सी आणि नकळत होणारं कपलिंग टाळता यावं [6]. त्यामुळे “शेअर्ड स्टोरेज असलेले १० मायक्रोसर्व्हिसेस” हा वाक्प्रचारच थोडा संशयास्पद आहे — खरी मायक्रोसर्व्हिसेस आर्किटेक्चर शेअर्ड स्टोरेजपासून दूर ढकलते, प्रत्येक सर्व्हिसने आपापला तुकडा सांभाळावा याकडे. (या तणावाबद्दल तुम्ही Microsoft च्या AKS मायक्रोसर्व्हिसेस रेफरन्स आर्किटेक्चर मध्ये अधिक वाचू शकता.)

Kubernetes मध्ये तुम्ही जेव्हा स्टोरेज जोडता, तेव्हा सहसा क्लस्टरला NFS, GlusterFS, किंवा Amazon EFS, Azure Files आणि Google Cloud Filestore सारख्या क्लाउड फाइल सिस्टम्सवरून एक्सपोज केलेल्या पारंपरिक इन्फ्रास्ट्रक्चरशी जोडता [6]. कॉम्प्युट आणि स्टोरेज वेगवेगळ्या मशीन्सवर असतात, नेटवर्कने जोडलेले. डिझाइननुसारच डेटा रिमोट असतो.

शेजारी-शेजारी: खरा फरक

तर, अमूर्त बोलणं थांबवू. इथे ते खरोखर वेगळे होतात.

मुख्य मथळा: Hadoop जाणीवपूर्वक कॉम्प्युट आणि स्टोरेज एकत्र ठेवतं; Kubernetes मायक्रोसर्व्हिसेस जाणीवपूर्वक त्यांना वेगळं करतात. ते एकाच कल्पनेचे दोन प्रकार नाहीत. ते दोन वेगवेगळ्या प्रश्नांची उत्तरं आहेत.

Hadoop विचारतं: “माझ्याकडे डेटाचा एक डोंगर स्थिर पडून आहे. नेटवर्कचा गळा न आवळता मी त्या सगळ्यावर कॉम्प्युटेशन कसं चालवू?”

Kubernetes मायक्रोसर्व्हिसेस विचारतात: “माझ्याकडे छोट्या, स्वतंत्र रिक्वेस्ट्सचा महापूर आहे. मी त्यांना विश्वासार्हपणे कसं सर्व्ह करू, प्रत्येक भाग स्वतंत्रपणे कसा स्केल करू, आणि क्रॅश कसे सहन करू?”

हे डोक्यात बसवण्यासाठी एक उदाहरण

समजा तुम्ही एक ई-कॉमर्स साइट चालवता.

Kubernetes वरचे मायक्रोसर्व्हिसेस म्हणजे तुमचं चलनवलन करणारं दुकान: एक यूजर “add to cart” वर क्लिक करतो, कार्ट सर्व्हिस ते हाताळतो, इन्व्हेंटरी सर्व्हिस स्टॉक तपासतो, पेमेंट सर्व्हिस कार्डवर पैसे आकारतो. दहा छोटे सर्व्हिसेस, प्रत्येक ट्रॅफिकनुसार स्केल होणारा, प्रत्येक आदर्शपणे स्वतःचा डेटा सांभाळणारा. रिक्वेस्ट्स छोट्या असतात, प्रत्येकाला लागणारा डेटा छोटा असतो, आणि लेटन्सी हीच सर्व काही असते. इथे काही KB नेटवर्कवरून एका शेअर्ड डेटाबेसकडे पाठवणं अगदी ठीक आहे.

आता, रात्री २ वाजता, तुम्हाला खरेदीचे पॅटर्न शोधण्यासाठी गेल्या पाच वर्षांतील प्रत्येक ऑर्डर तपासायची आहे. तो ८ TB ऐतिहासिक लॉग्स आहे. तुम्ही ८ TB एका मायक्रोसर्व्हिसमधून नेटवर्कवरून खेचणार नाही — तुमचं नेटवर्क आणि तुमचं पाकीट दोन्ही डेटा ग्रॅव्हिटी मुळे मरतील [5]. हे Hadoop-आकाराचं काम आहे: डेटा HDFS वर ठेवा, विश्लेषणाचा कोड ब्लॉक्स जिथे आहेत तिकडे पाठवा, समांतरपणे प्रोसेस करा, आणि एक सारांश लिहून काढा. डेटा कधीच हलत नाही; कोड हलतो.

एकच कंपनी, दोन पूर्णपणे वेगवेगळ्या समस्या, दोन पूर्णपणे वेगवेगळी आर्किटेक्चर्स. ते स्पर्धक नाहीत — खरं सांगायचं तर, ते अनेकदा एकाच इमारतीत सहअस्तित्वात असतात.

“पण माझे मायक्रोसर्व्हिसेसही डेटा प्रोसेस करतात!”

नक्कीच करतात. इथेच गोष्ट अवघड होते, आणि इथेच तुलना धूसर वाटते. एक मायक्रोसर्व्हिस नक्कीच एखादी फाइल वाचू शकतो, तिचं रूपांतर करू शकतो, आणि ती परत लिहू शकतो. मग खरी रेषा कोणती?

ते तीन गोष्टींवर अवलंबून आहे:

1. व्हॉल्यूम आणि लोकॅलिटी. एक मायक्रोसर्व्हिस एक रो, एक डॉक्युमेंट, एक छोटासा ब्लॉब आणतो — तो रिमोट डेटा कॉम्प्युटकडे खेचतो. मोठ्या प्रमाणावर Hadoop हे करायला नकार देतं कारण डेटा हलवण्याइतका मोठा असतो, म्हणून ते कॉम्प्युट डेटाकडे पाठवतं [3]. जर तुमच्या कामाचा अडसर “मी सगळा डेटा वाचण्याइतकाही वेगाने वाचू शकत नाही” हा असेल, तर तुम्ही Hadoop च्या क्षेत्रात आहात.

2. कामाचा सूक्ष्मपणा. मायक्रोसर्व्हिसेस रिक्वेस्ट्स मध्ये विचार करतात — छोट्या, वेगळ्या, कमी लेटन्सीच्या. Hadoop जॉब्स मध्ये विचार करतं — संपूर्ण डेटासेटवर दीर्घकाळ चालणारे बॅच पास जिथे तुम्ही आनंदाने मिनिटं किंवा तास वाट पाहता [7]. MapReduce चं बॅच स्वरूप प्रत्यक्षात रिअल-टाइम कामासाठी लेटन्सीच्या समस्या निर्माण करतं, आणि नेमकं याचमुळे ते लाइव्ह रिक्वेस्ट्स सर्व्ह करण्यासाठी चुकीचं साधन आहे [7].

3. कपलिंगची विचारसरणी. मायक्रोसर्व्हिसेसना सैल कपलिंग आणि स्वतंत्र स्टोरेज मालकी हवी असते जेणेकरून टीम्स एकमेकांच्या मार्गात न येता वेगाने काम करू शकतील [6]. Hadoop ला कॉम्प्युट आणि स्टोरेजचं घट्ट सहस्थान हवं असतं जेणेकरून ते नेटवर्कची लढाई जिंकू शकेल. ही उद्दिष्टं अक्षरशः एकमेकांच्या विरुद्ध आहेत.

त्यामुळे थोडंसं डेटा प्रोसेसिंग करणारा मायक्रोसर्व्हिस अजूनही मायक्रोसर्व्हिसच असतो. तो “बिग डेटा सिस्टम” तेव्हा बनतो जेव्हा डेटा हा अढळ गुरुत्वकेंद्र असतो आणि कॉम्प्युटला त्याभोवती परिक्रमा करावी लागते.

जाणून घेण्यासारखी एक गोष्ट: अगदी बिग डेटाही “शुद्ध” Hadoop पासून दूर गेलं

बिग डेटासाठी Hadoop अजूनही डिफॉल्ट आहे असं भासवलं तर मी तुमच्यावर अन्याय करेन. ते आता तसं राहिलेलं नाही. Hadoop ने डिस्ट्रिब्युटेड कॉम्प्युटिंगचा पाया घातला, पण नव्या प्रोजेक्ट्ससाठी ते मागे पडत आहे [7]. MapReduce प्रत्येक स्टेपदरम्यान मधले निकाल डिस्कवर लिहितं, जे संथ आहे, म्हणून Apache Spark आलं आणि त्याने त्याच प्रकारची डिस्ट्रिब्युटेड प्रोसेसिंग मोठ्या प्रमाणात मेमरीमध्ये केली, ज्यामुळे इटरेटिव्ह आणि इंटरॅक्टिव्ह काम कमालीचं वेगवान झालं [7].

आणि व्यापक इकोसिस्टम प्रचंड आहे — Hadoop म्हणजे फक्त MapReduce नाही. त्यातून अशी साधनं वाढली:

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

मजेची गोष्ट म्हणजे, आधुनिक क्लाउड-डेटा जगाने अंशतः Hadoop चा मूळ धडा विसरून टाकला आहे. BigQuery आणि Snowflake सारखी साधनं जाणीवपूर्वक पुन्हा स्टोरेजला कॉम्प्युटपासून वेगळं करतात — Kubernetes मायक्रोसर्व्हिसेस वापरतात तेच डीकपलिंग — कारण क्लाउडमध्ये ऑब्जेक्ट स्टोरेज आणि कॉम्प्युट यांच्यातली नेटवर्क बँडविड्थ इतकी वेगवान आणि स्वस्त झाली की डेटा लोकॅलिटी २००८ सालच्या तुलनेत कमी महत्त्वाची झाली. त्यामुळे एका गमतीशीर अर्थाने, लंबक “सगळं एकत्र ठेवा” (Hadoop) पासून “सगळं वेगळं करा” (क्लाउड डेटा वेअरहाऊसेस आणि मायक्रोसर्व्हिसेस दोन्ही) कडे झुकला. AI वर्कलोड्स पुन्हा एकदा डेटा व्हॉल्यूम्सचा स्फोट करत असताना हे टिकेल का, हा खुला प्रश्न आहे — काही लोकांचं म्हणणं आहे की डेटा ग्रॅव्हिटी जोरात परत येत आहे आणि ती खरंतर कधी गेलीच नव्हती [5].

तर, ते एकच गोष्ट आहेत की नाही?

नाही. आणि मी हे सर्वांत स्वच्छपणे असं मांडू शकतो.

मायक्रोसर्व्हिसेस चालवणारा Kubernetes क्लस्टर म्हणजे एक रिक्वेस्ट-सर्व्ह करणारं यंत्र. कॉम्प्युट स्टेटलेस आणि हलकं ठेवणं, आणि डेटा अशा ठिकाणी ढकलणं जिथे तो शेअर केला जाऊ शकतो किंवा स्वतंत्रपणे सांभाळला जाऊ शकतो — ही त्याची प्रवृत्ती आहे. नेटवर्क डेटा कॉम्प्युटकडे नेतं, आणि ते स्वीकारार्ह आहे कारण प्रत्येक रिक्वेस्ट अगदी थोड्याशा डेटाला स्पर्श करते [6].

Hadoop म्हणजे एक डेटा-प्रोसेस करणारं यंत्र. कॉम्प्युट करणाऱ्या त्याच डिस्क्सवर डेटा खिळवून ठेवणं ही त्याची प्रवृत्ती आहे, कारण पेटाबाइट्स हलवणं म्हणजे भौतिकशास्त्राविरुद्ध हरणारी लढाई आहे. नेटवर्क कोड डेटाकडे नेतं [3].

जर तुम्हाला फक्त एकच ओळ लक्षात ठेवायची असेल: मायक्रोसर्व्हिसेस डेटाला कोडकडे नेतात; Hadoop कोडला डेटाकडे नेतं. बाकी सगळं — डीमन्स, रेप्लिकेशन, YARN शेड्युलिंग, StatefulSets — त्याच एका निर्णयातून वाहत येतं.

ते वरवरच्या गोष्टींमध्ये एकमेकांशी जुळतात (क्लस्टर्स, डिस्ट्रिब्युशन, फॉल्ट टॉलरन्स), म्हणूनच हा प्रश्न विचारणं इतकं स्वाभाविक आहे. पण ही आर्किटेक्चर्स कोणत्याही डिस्ट्रिब्युटेड सिस्टममधल्या सर्वांत महाग गोष्टीबद्दलच्या — वायरवरून बाइट्स हलवण्याबद्दलच्या — अगदी विरुद्ध पैजांवर उभी आहेत.

End

स्रोत

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)