हमने अत्यधिक कुशल और सस्ती डेटालेक का आयोजन कैसे किया और ऐसा क्यों है

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

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

अरे हाँ, मैं थोड़ा विचलित हो गया, लेकिन मुझे आशा है कि मैं प्रत्याशा की स्थिति बताने में कामयाब रहा।
आज मैं डेटालेक के लिए एक सुविधाजनक और सस्ता स्टैक तैनात करने में अपना अनुभव साझा करना चाहता हूं, जो पूरी तरह से अलग-अलग संरचनात्मक प्रभागों के लिए कंपनी में अधिकांश विश्लेषणात्मक कार्यों को हल करता है।

कुछ समय पहले, हमें यह समझ में आया कि कंपनियों को उत्पाद और तकनीकी विश्लेषण (मशीन लर्निंग के रूप में केक पर आइसिंग का उल्लेख नहीं करना) दोनों के फल की आवश्यकता है और रुझानों और जोखिमों को समझने के लिए - हमें एकत्र करने और विश्लेषण करने की आवश्यकता है अधिक से अधिक मेट्रिक्स।

Bitrix24 में बुनियादी तकनीकी विश्लेषण

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

पल्स पर उंगली - उन्नत तकनीकी विश्लेषिकी

समस्याओं के बारे में "जितनी जल्दी हो सके" जानकारी प्राप्त करने की इच्छा ने हमें सरल और समझने योग्य उपकरणों - पिनबा और xhprof के साथ सक्रिय प्रयोगों के लिए प्रेरित किया।

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

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

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

• Bitrix24 क्लाइंट में पिछले घंटे में p1 पोर्टल पर कितनी PHP त्रुटियाँ थीं और कौन सी? समझें, क्षमा करें और शीघ्र सुधार करें।
• पिछले 24 घंटों में जर्मनी में पोर्टलों पर कितनी वीडियो कॉल की गईं, किस गुणवत्ता के साथ और क्या चैनल/नेटवर्क के साथ कोई कठिनाइयाँ थीं?
• नवीनतम सेवा अद्यतन में स्रोत से संकलित और ग्राहकों के लिए रोल आउट की गई सिस्टम कार्यक्षमता (PHP के लिए हमारा C एक्सटेंशन) कितनी अच्छी तरह काम करती है? क्या कोई सेगफ़ॉल्ट हैं?
• क्या ग्राहक डेटा PHP मेमोरी में फ़िट होता है? क्या प्रक्रियाओं को आवंटित मेमोरी से अधिक होने के बारे में कोई त्रुटि है: "मेमोरी से बाहर"? खोजें और बेअसर करें।

यहाँ एक ठोस उदाहरण है. गहन और बहु-स्तरीय परीक्षण के बावजूद, बहुत ही गैर-मानक केस और क्षतिग्रस्त इनपुट डेटा वाले क्लाइंट को एक कष्टप्रद और अप्रत्याशित त्रुटि प्राप्त हुई, एक सायरन बजा और इसे तुरंत ठीक करने की प्रक्रिया शुरू हुई:

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

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

बेसिक बिजनेस एनालिटिक्स

हर कोई जानता है कि कंपनियों में बिजनेस एनालिटिक्स अक्सर एक्सेल के अत्यधिक सक्रिय उपयोग से शुरू होता है। लेकिन मुख्य बात यह है कि बात यहीं ख़त्म नहीं होती. क्लाउड-आधारित Google Analytics भी आग में घी डालता है - आप जल्दी ही अच्छी चीज़ों के आदी होने लगते हैं।

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

काफी समय तक इस लचीले समाधान से काफी मदद मिली, लेकिन धीरे-धीरे यह समझ आने लगी कि ClickHouse रबर नहीं है और इसका इस तरह मजाक नहीं उड़ाया जा सकता।

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

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

अजगर और विश्लेषकों की मांग

हमारी कंपनी में कई डेवलपर हैं जो PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash में 10-20 वर्षों से लगभग हर दिन कोड लिखते हैं। ऐसे कई अनुभवी सिस्टम प्रशासक भी हैं जिन्होंने एक से अधिक अविश्वसनीय आपदाओं का अनुभव किया है जो आंकड़ों के नियमों में फिट नहीं होती हैं (उदाहरण के लिए, जब रेड -10 में अधिकांश डिस्क एक मजबूत बिजली की हड़ताल से नष्ट हो जाती हैं)। ऐसी परिस्थितियों में, लंबे समय तक यह स्पष्ट नहीं था कि "पायथन विश्लेषक" क्या है। पायथन PHP की तरह है, केवल नाम थोड़ा लंबा है और दुभाषिया के स्रोत कोड में दिमाग बदलने वाले पदार्थों के निशान थोड़े कम हैं। हालाँकि, जैसे-जैसे अधिक से अधिक विश्लेषणात्मक रिपोर्टें बनाई गईं, अनुभवी डेवलपर्स ने नम्पी, पांडा, मैटप्लोटलिब, सीबॉर्न जैसे उपकरणों में संकीर्ण विशेषज्ञता के महत्व को तेजी से समझना शुरू कर दिया।
निर्णायक भूमिका, सबसे अधिक संभावना है, "लॉजिस्टिक रिग्रेशन" शब्दों के संयोजन से कर्मचारियों की अचानक बेहोशी और हाँ, हाँ, पाइस्पार्क का उपयोग करके बड़े डेटा पर प्रभावी रिपोर्टिंग के प्रदर्शन द्वारा निभाई गई थी।

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

Apache Spark/Hadoop के आगे के प्रयास और जो स्क्रिप्ट के अनुसार नहीं हुए

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

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

एनालिटिक्स के लिए रबर फ़ाइल भंडारण एक तत्काल आवश्यकता है

शरीर के विभिन्न हिस्सों में जलन के साथ Hadoop/Spark को "खाना पकाने" का अनुभव व्यर्थ नहीं था। एक एकल, सस्ता और विश्वसनीय फ़ाइल भंडारण बनाने की आवश्यकता जो हार्डवेयर विफलताओं के लिए प्रतिरोधी हो और जिसमें विभिन्न प्रणालियों से विभिन्न प्रारूपों में फ़ाइलों को संग्रहीत करना और इस डेटा से रिपोर्ट के लिए कुशल और समय-कुशल नमूने बनाना संभव हो। स्पष्ट।

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

क्या Amazon S3 डेटालेक के लिए उम्मीदवार है?

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

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

यदि आप Hadoop से अपनी स्वयं की चॉप्स तैयार किए बिना, परिचित और प्रसिद्ध स्केलेबल क्लाउड स्टोरेज Amazon S3 में फ़ाइलें संग्रहीत करते हैं तो क्या होगा?

यह स्पष्ट है कि व्यक्तिगत डेटा "कम" है, लेकिन अन्य डेटा के बारे में क्या होगा अगर हम इसे वहां ले जाएं और "इसे प्रभावी ढंग से चलाएं"?

अमेज़ॅन वेब सर्विसेज का क्लस्टर-बिगडेटा-एनालिटिक्स इकोसिस्टम - बहुत सरल शब्दों में

AWS के साथ हमारे अनुभव को देखते हुए, Apache Hadoop/MapReduce का लंबे समय से विभिन्न सॉस के तहत सक्रिय रूप से उपयोग किया गया है, उदाहरण के लिए डेटापाइपलाइन सेवा में (मुझे अपने सहयोगियों से ईर्ष्या है, उन्होंने इसे सही तरीके से तैयार करना सीखा)। यहां हम DynamoDB तालिकाओं से विभिन्न सेवाओं से बैकअप सेट करते हैं:


और वे कई वर्षों से घड़ी की कल की तरह एम्बेडेड Hadoop/MapReduce क्लस्टर पर नियमित रूप से चल रहे हैं। "इसे सेट करो और इसे भूल जाओ":

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

और हाँ, आप अपने लिए या क्लाउड में किसी विश्लेषक के लिए एक लैपटॉप ले सकते हैं और इसे Hadoop/Spark क्लस्टर से जोड़ सकते हैं, गणना कर सकते हैं और फिर सब कुछ ठीक कर सकते हैं:

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

एडब्ल्यूएस गोंद - स्टेरॉयड पर बड़े करीने से पैक किया गया अपाचे स्पार्क

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

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

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

इस प्रकार, यदि आपको s3 में डेटा का उपयोग करके स्पार्क क्लस्टर पर कुछ गणना करने की आवश्यकता है, तो हम पायथन/पाइस्पार्क में कोड लिखते हैं, इसका परीक्षण करते हैं, और क्लाउड को शुभकामनाएं देते हैं।

ऑर्केस्ट्रेशन के बारे में क्या? यदि कार्य गिर गया और गायब हो गया तो क्या होगा? हां, अपाचे पिग शैली में एक सुंदर पाइपलाइन बनाने का प्रस्ताव है और हमने उन्हें आजमाया भी है, लेकिन अभी के लिए हमने PHP और जावास्क्रिप्ट में हमारे गहन अनुकूलित ऑर्केस्ट्रेशन का उपयोग करने का निर्णय लिया है (मैं समझता हूं, संज्ञानात्मक असंगति है, लेकिन यह काम करता है, के लिए) वर्ष और त्रुटियों के बिना)।

झील में संग्रहीत फ़ाइलों का प्रारूप प्रदर्शन की कुंजी है

दो और मुख्य बिंदुओं को समझना बहुत, बहुत महत्वपूर्ण है। झील में फ़ाइल डेटा पर क्वेरीज़ को जितनी जल्दी हो सके निष्पादित किया जा सके और नई जानकारी जोड़े जाने पर प्रदर्शन ख़राब न हो, इसके लिए आपको यह करना होगा:

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

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

AWS एथेना - जैक-इन-द-बॉक्स

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

S3 में डेटा द्वारा संचालित एथेना इंजन पौराणिक कथाओं पर आधारित है हाथ की सफ़ाई - डेटा प्रोसेसिंग के दृष्टिकोण के एमपीपी (विशाल समानांतर प्रसंस्करण) परिवार का एक प्रतिनिधि, डेटा को वहीं ले जाता है जहां वह है, s3 और Hadoop से लेकर कैसेंड्रा और साधारण टेक्स्ट फ़ाइलों तक। आपको बस एथेना से SQL क्वेरी निष्पादित करने के लिए कहना होगा, और फिर सब कुछ "जल्दी और स्वचालित रूप से काम करता है।" यह ध्यान रखना महत्वपूर्ण है कि एथेना "स्मार्ट" है, यह केवल आवश्यक शार्ड फ़ोल्डरों में जाता है और अनुरोध में केवल आवश्यक कॉलम पढ़ता है।

एथेना के अनुरोधों की कीमत भी दिलचस्प है। हम भुगतान करते हैं स्कैन किए गए डेटा की मात्रा. वे। प्रति मिनट क्लस्टर में मशीनों की संख्या के लिए नहीं, बल्कि... वास्तव में 100-500 मशीनों पर स्कैन किए गए डेटा के लिए, केवल अनुरोध को पूरा करने के लिए आवश्यक डेटा।

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

वैसे, यहां बताया गया है कि हम s3 में अपना डेटा कैसे साझा करते हैं:

परिणामस्वरूप, कुछ ही समय में, कंपनी के पूरी तरह से अलग-अलग विभागों ने, सूचना सुरक्षा से लेकर एनालिटिक्स तक, सक्रिय रूप से एथेना से अनुरोध करना शुरू कर दिया और सेकंडों में, काफी लंबी अवधि में "बड़े" डेटा से उपयोगी उत्तर प्राप्त करने लगे: महीने, आधा साल, आदि पी.

लेकिन हम आगे बढ़े और उत्तर के लिए क्लाउड पर जाने लगे ODBC ड्राइवर के माध्यम से: एक विश्लेषक एक परिचित कंसोल में एक SQL क्वेरी लिखता है, जो 100-500 मशीनों पर "पैसे के लिए" s3 को डेटा भेजता है और आमतौर पर कुछ सेकंड में उत्तर देता है। आरामदायक। और तेज। मुझे अभी भी इस पर विश्वास नहीं हो रहा है.

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

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

निष्कर्ष

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

यह पता चला कि कंपनी के पूरी तरह से अलग-अलग विभागों की जरूरतों के लिए एक प्रभावी, तेज़ और सस्ता संचालित डेटालेक बनाना पूरी तरह से अनुभवी डेवलपर्स की क्षमताओं के भीतर है, जिन्होंने कभी आर्किटेक्ट के रूप में काम नहीं किया है और नहीं जानते कि वर्गों पर वर्ग कैसे बनाएं तीर और Hadoop पारिस्थितिकी तंत्र से 50 शब्द जानें।

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

यदि आप क्लाउड पर नहीं जाना चाहते हैं और ओपन-सोर्स परियोजनाओं का समर्थन, अद्यतन और पैच करना पसंद करते हैं, तो आप Hadoop और Presto के साथ सस्ती कार्यालय मशीनों पर स्थानीय स्तर पर हमारी तरह एक योजना बना सकते हैं। मुख्य बात यह नहीं है कि रुकें और आगे बढ़ें, गिनें, सरल और स्पष्ट समाधान खोजें, और सब कुछ निश्चित रूप से काम करेगा! सभी को शुभकामनाएँ और फिर मिलेंगे!

स्रोत: www.habr.com