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



51 का क्या मतलब है

चूंकि हम संदेशों के कई संस्करणों को संग्रहीत करते हैं, स्प्राउट इंजीनियरों को दिन में कई बार 'दुनिया को फिर से बनाने' का काम सौंपा जाता है - एक आवश्यक प्रक्रिया जिसमें सामाजिक संदेश के हर हिस्से को 'सच्चाई के स्रोत' में समेकित करने के लिए पूरे डेटा सेट के माध्यम से पुनरावृति की आवश्यकता होती है।



उदाहरण के लिए, किसी एक ट्विटर पोस्ट के लाइक, कमेंट और रीट्वीट पर नज़र रखना। ऐतिहासिक रूप से, हम इतनी बड़ी मात्रा में डेटा को बनाए रखने और काम करने के लिए स्व-प्रबंधित Hadoop समूहों पर निर्भर रहे हैं। प्रत्येक हडूप क्लस्टर स्प्राउट प्लेटफॉर्म के विभिन्न हिस्सों के लिए जिम्मेदार होगा- एक ऐसा अभ्यास जो स्प्राउट इंजीनियरिंग टीम में बड़े पैमाने पर डेटा परियोजनाओं के प्रबंधन के लिए निर्भर है।

स्प्राउट के बड़े डेटा दृष्टिकोण की कुंजी

हमारा Hadoop इकोसिस्टम Apache Hbase पर निर्भर था, जो एक स्केलेबल और वितरित NoSQL डेटाबेस है। बड़े डेटा को संसाधित करने के हमारे दृष्टिकोण के लिए Hbase महत्वपूर्ण बनाता है, यह न केवल संपूर्ण डेटासेट पर त्वरित रेंज स्कैन करने की क्षमता है, बल्कि तेज़, यादृच्छिक, एकल रिकॉर्ड लुकअप भी करता है।

Hbase हमें डेटा को बल्क लोड करने और रैंडम डेटा को अपडेट करने की भी अनुमति देता है ताकि हम ऑर्डर से बाहर या आंशिक अपडेट के साथ आने वाले संदेशों और सोशल मीडिया डेटा के साथ आने वाली अन्य चुनौतियों को आसानी से हैंडल कर सकें। हालाँकि, स्व-प्रबंधित Hadoop क्लस्टर हमारे इन्फ्रास्ट्रक्चर इंजीनियरों पर उच्च परिचालन लागतों का बोझ डालते हैं, जिसमें मैन्युअल रूप से आपदा वसूली, क्लस्टर विस्तार और नोड प्रबंधन शामिल हैं।

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

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

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



नए डेटा पैटर्न विकल्पों का मूल्यांकन

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

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

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



एडब्ल्यूएस ईएमआर के साथ ओवरहेड और रखरखाव को कम करना

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

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

EMR की सुविधाओं ने हमारे वर्तमान स्व-प्रबंधित समाधान में सुधार किया और हमें अपने वर्तमान पैटर्न को पढ़ने, लिखने और काम करने के लिए उसी तरह से पुन: उपयोग करने में सक्षम बनाया, जिस तरह हमने Hbase के साथ किया था। ईएमआर के सबसे बड़े लाभों में से एक ईएमआर फाइल सिस्टम (ईएमआरएफएस) का उपयोग है, जो स्वयं नोड्स के बजाय एस3 में डेटा संग्रहीत करता है।

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

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

हमने क्या सीखा

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

भाग्यशाली संख्या 23 अर्थ

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

अपने दोस्तों के साथ साझा करें: