Yandex में प्रौद्योगिकी वास्तविक समय मेप्रिड्यूस। किसी बड़ी चीज को कैसे तेज किया जाए

कुछ समय पहले हमने हैबर पर बताया कि यैंडेक्स की खोज अधिक व्यक्तिगत हो गई। यह पिछले कुछ अनुरोधों और कार्यों पर ध्यान केंद्रित करते हुए न केवल स्थायी, बल्कि उपयोगकर्ता के अल्पकालिक हितों को भी ध्यान में रखता है।

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



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

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

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

प्रसंस्करण चरण सख्त क्रम में किए जाते हैं (आखिरकार, प्रत्येक चरण डेटा उत्पन्न करता है जिसे अगले में संसाधित किया जाएगा), और एक कुंजी के साथ अंतिम परिणाम प्राप्त करने के लिए, आपको सभी प्रसंस्करण के अंत की प्रतीक्षा करने की आवश्यकता है। इनपुट डेटा में मामूली बदलाव के साथ भी, चरणों की पूरी श्रृंखला को फिर से चलाने की आवश्यकता है, क्योंकि पुनरावृत्ति के बिना यह निर्धारित करना असंभव है कि इन परिवर्तनों से कौन से मध्यवर्ती परिणाम प्रभावित होंगे। आने वाले डेटा के निरंतर प्रवाह के साथ (और हमारे खोज इंजन से लगभग 200 एमबी / एस की गति से एक धारा है), ऐसी प्रणाली प्रभावी ढंग से काम करने में असमर्थ है, और इस पद्धति का उपयोग करके कुछ ही सेकंड में उपयोगकर्ता क्रियाओं की प्रतिक्रिया प्राप्त करना असंभव है।

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

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

आर्किटेक्चर

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

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

इसके अलावा, यह स्पष्ट हो गया कि ऑपरेशन की आवश्यक गति सुनिश्चित करने के लिए, गणना में शामिल सभी डेटा को मेमोरी में संग्रहीत किया जाना चाहिए, जिसके लिए हमने एक विशेष आर्किटेक्चर लागू किया।



आइए हम आरेख में प्रदर्शित कार्यों के अनुक्रम को और अधिक विस्तार से विश्लेषित करें:

1. यह सब इस तथ्य से शुरू होता है कि आने वाले अनुरोध हैंडलर डेटा को पार्स करता है और प्रत्येक कुंजी के लिए एक अलग लेनदेन शुरू करता है।
2. इस मामले में, लेन-देन को लॉन्च होने की पुष्टि होने के बाद ही माना जाता है कि ऑपरेशन की शुरुआत (रेडरकार्ड) का रिकॉर्ड डिस्क पर सहेजा गया है।
3. लेनदेन शुरू होने के बाद, आने वाले अनुरोध की प्रतिक्रिया नेटवर्क पर भेजी जाती है, और लेनदेन वर्कफ़्लो द्वारा प्रसंस्करण के लिए कतारबद्ध होता है।
4. अगला, वर्कफ़्लो लेनदेन को चुनता है और, कुंजी की स्थानीयता के आधार पर, या तो इसे नेटवर्क पर भेजता है और पुष्टि की प्रतीक्षा करता है, या प्रसंस्करण सामग्री बनाता है जिसमें संचालन किया जाता है।
5. भविष्य में, लेनदेन को एक दूसरे से अलग करने में संसाधित किया जाता है: शुरू करने के बाद, एक ब्रंच को सिस्टम की सामान्य स्थिति से दूर ले जाया जाता है, और प्रसंस्करण के पूरा होने पर, परिवर्तन स्वीकार किए जाते हैं।
6. सभी डेटा को मेमोरी में संग्रहीत किया जाता है, जो कि संचालन को कम करने के अनुकूलन के लिए बेहद महत्वपूर्ण है।
7. संशोधित कुंजी पर डेटा समय-समय पर स्थायी भंडारण में बैकअप के रूप में संग्रहीत किया जाता है।
8. लेनदेन को संसाधित करने के बाद, इसका परिणाम डिस्क पर दर्ज किया जाता है, और लॉग से रिकॉर्ड की पुष्टि होने पर, इसे पूरा माना जाता है।
9. इसके अलावा, एक लेनदेन बच्चे के लेनदेन को रोक सकता है, जिस स्थिति में सब कुछ दोहराता है, चौथे पैरा से शुरू होता है।
10. राज्य को पुनर्स्थापित करने की प्रक्रिया में, डेटा को स्थायी भंडारण से पुनर्प्राप्त किया जाता है और लॉग द्वारा पुन: प्रस्तुत किया जाता है, अपूर्ण लेनदेन को फिर से शुरू किया जाता है। यदि लेन-देन को निरस्त करने की आवश्यकता है, तो AbortRecord को लॉग को लिखा जाता है (एक संकेतक है कि राज्य को बहाल करने पर इस लेनदेन को फिर से शुरू करने की आवश्यकता नहीं है)।

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



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

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

RealTime MapReduce के लिए संभावनाएँ

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

खोज संकेत का अनुकूलन भी तुरन्त किया जा सकता है। फिर उपयोगकर्ता को दिए गए क्वेरी विकल्प कुछ सेकंड पहले वह क्या देख रहे थे, इस पर निर्भर करेगा।

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

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