क्या आप गलत समझ गए थे

- हमें प्रति दिन एक मिलियन से अधिक ट्वीट मिलते हैं, और हमारे सर्वर के पास उन्हें संसाधित करने का समय नहीं है। इसलिए, हम क्लस्टर पर Hadoop स्थापित करना चाहते हैं और प्रसंस्करण वितरित करना चाहते हैं।

यह एक कम्प्यूटेशनल रूप से भारी भावुक विश्लेषण था , इसलिए मुझे विश्वास हो सकता है कि ट्वीट्स की एक बड़ी धारा को संभालने के लिए एक सर्वर के पास वास्तव में पर्याप्त सीपीयू नहीं है।

- पहले से संसाधित डेटा के साथ आप क्या करने जा रहे हैं?
- सबसे अधिक संभावना है, हम उन्हें MySQL में जोड़ देंगे, जैसा कि हमने पहले किया था, या यहां तक ​​कि उन्हें हटा दें।
"तो आप निश्चित रूप से Hadoop की जरूरत नहीं है।"

मेरे पूर्व सहयोगी पहले Hadoop पर वितरित कंप्यूटिंग के बारे में बात करने से दूर थे। और हर बार मैंने पूरी गलतफहमी देखी कि इस प्लेटफॉर्म का आविष्कार और विकास क्यों हुआ।

सामान्यतया, डेटा प्रोसेसिंग में कई विशिष्ट स्थितियों का सामना करना पड़ता है, और उनमें से प्रत्येक के पास अपने दृष्टिकोण और अपने उपकरण हैं। मुख्य पर विचार करें।

सक्रिय डेटा की स्पॉट प्रोसेसिंग

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

स्केलिंग करते समय, डेटाबेस में संग्रहीत डेटा की अधिकतम मात्रा के साथ यहां मुख्य समस्या उत्पन्न होती है। हालाँकि, भले ही उपयोग किया गया DBMS किसी वितरित संरचना का समर्थन नहीं करता है, लेकिन आवेदन स्तर पर विभाजन करके समस्या को आसानी से हल किया जा सकता है।

वास्तविक समय स्ट्रीम प्रसंस्करण

कभी-कभी, हालांकि, भंडारण पर जोर नहीं दिया जाता है, लेकिन डेटा प्रोसेसिंग पर। यह ठीक यही स्थिति है कि मेरे पूर्व सहयोगी ने भावुक विश्लेषण में शामिल किया। उन्हें वास्तविक समय में ट्वीट प्राप्त करने, उनका विश्लेषण करने और गतिशील रूप से उत्पन्न चार्ट पर परिणाम प्रदर्शित करने की आवश्यकता थी। एक मिलियन दैनिक ट्वीट समस्या नहीं थे - आखिरकार, यह UTF16 एन्कोडिंग का उपयोग करके 140 मिलियन से अधिक वर्ण या 280MB से अधिक नहीं है। समस्या इन ट्वीट्स का वास्तविक समय विश्लेषण था।

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

ऐतिहासिक डेटा का बैच प्रसंस्करण

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

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

हम सभी डेटा को एक वितरित ओरेकल डेटाबेस में लोड कर सकते हैं और सक्रिय लोगों के साथ उसी तरह काम कर सकते हैं। लेकिन इस मामले में, एप्लिकेशन सर्वर क्रमिक रूप से डेटाबेस से डेटा लेगा और क्रमिक रूप से प्रत्येक रिकॉर्ड की प्रक्रिया करेगा, जो बेहद अक्षम है।

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

लोड को वितरित करने और संचार चैनल को अतिप्रवाह नहीं करने का एकमात्र तरीका नोड्स के बीच डेटा की आवाजाही को कम करना है । और इसके लिए उन मशीनों पर स्थानीय रूप से अधिकतम गणना करना आवश्यक है जहां संसाधित डेटा निहित है। यह डेटा स्थानीयता का सिद्धांत है जो MapReduce प्रतिमान और Hadoop के सभी को रेखांकित करता है।

MapReduce पर अधिक

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

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

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

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

इसलिए, सही कार्यों के लिए सही उपकरण का उपयोग करें, और आप खुश होंगे!