आम्ही अत्यंत कार्यक्षम आणि स्वस्त डेटालेक कसे आयोजित केले आणि हे असे का आहे

आम्ही एका आश्चर्यकारक काळात राहतो जेव्हा तुम्ही अनेक रेडीमेड ओपन-सोर्स टूल्स द्रुतपणे आणि सहजपणे कनेक्ट करू शकता, स्टॅकओव्हरफ्लोच्या सल्ल्यानुसार, "एकाधिक अक्षरे" मध्ये न शोधता त्यांना तुमच्या "चेतना बंद" सह सेट करू शकता आणि लॉन्च करू शकता. ते व्यावसायिक ऑपरेशनमध्ये. आणि जेव्हा तुम्हाला अपडेट/विस्तार करण्याची गरज असते किंवा कोणीतरी चुकून काही मशीन्स रीबूट करते - तेव्हा तुम्हाला जाणवते की प्रत्यक्षात एक प्रकारचे वेडसर वाईट स्वप्न सुरू झाले आहे, सर्वकाही अचानक ओळखण्यापलीकडे अधिक गुंतागुंतीचे झाले आहे, मागे वळणे नाही, भविष्य अस्पष्ट आहे. आणि अधिक सुरक्षित, प्रोग्रामिंग ऐवजी, मधमाश्या पैदास करा आणि चीज करा.

हे काही कारण नाही की, अधिक अनुभवी सहकारी, त्यांचे डोके बग्सने विखुरलेले आणि त्यामुळे आधीच राखाडी, "क्युब्स" मध्ये "कंटेनर" च्या पॅकच्या अविश्वसनीयपणे जलद तैनातीबद्दल "फॅशनेबल भाषांमध्ये" अंगभूत समर्थनासह डझनभर सर्व्हरवर विचार करतात. असिंक्रोनस नॉन-ब्लॉकिंग I/O, नम्रपणे स्मित करा. आणि ते शांतपणे “मॅन ps” पुन्हा वाचत राहतात, त्यांच्या डोळ्यांतून रक्त येईपर्यंत “nginx” सोर्स कोडचा शोध घेतात आणि युनिट चाचण्या लिहितात, लिहितात. सहकाऱ्यांना माहित आहे की नवीन वर्षाच्या पूर्वसंध्येला जेव्हा "हे सर्व" एक दिवस रात्री स्टॅक केले जाईल तेव्हा सर्वात मनोरंजक गोष्ट येईल. आणि त्यांना युनिक्सचे स्वरूप, लक्षात ठेवलेले TCP/IP स्टेट टेबल आणि मूलभूत सॉर्टिंग-सर्च अल्गोरिदमचे सखोल आकलन करूनच मदत केली जाईल. चाइम्स स्ट्राइक म्हणून प्रणाली पुन्हा जिवंत करण्यासाठी.

अरे हो, मी थोडे विचलित झालो, परंतु मला आशा आहे की मी अपेक्षेची स्थिती व्यक्त करण्यात व्यवस्थापित केले आहे.
आज मला DataLake साठी सोयीस्कर आणि स्वस्त स्टॅक तैनात करण्याचा आमचा अनुभव सांगायचा आहे, जे पूर्णपणे भिन्न संरचनात्मक विभागांसाठी कंपनीमधील बहुतेक विश्लेषणात्मक कार्ये सोडवते.

काही काळापूर्वी, आम्हाला हे समजले होते की कंपन्यांना उत्पादन आणि तांत्रिक विश्लेषण या दोन्हीच्या फळांची गरज आहे (मशीन लर्निंगच्या स्वरूपात केकवर आयसिंगचा उल्लेख करू नका) आणि ट्रेंड आणि जोखीम समजून घेण्यासाठी - आम्हाला एकत्रित करणे आणि विश्लेषण करणे आवश्यक आहे. अधिक आणि अधिक मेट्रिक्स.

Bitrix24 मधील मूलभूत तांत्रिक विश्लेषण

अनेक वर्षांपूर्वी, Bitrix24 सेवा सुरू केल्यावर, आम्ही एक साधे आणि विश्वासार्ह विश्लेषणात्मक प्लॅटफॉर्म तयार करण्यासाठी सक्रियपणे वेळ आणि संसाधने गुंतवली ज्यामुळे पायाभूत सुविधांमधील समस्या त्वरित पाहण्यास आणि पुढील चरणाची योजना करण्यात मदत होईल. अर्थात, शक्य तितक्या सोपी आणि समजण्यायोग्य अशी तयार साधने घेण्याचा सल्ला दिला गेला. परिणामी, विश्लेषणासाठी आणि व्हिज्युअलायझेशनसाठी निरीक्षणासाठी नागिओस आणि मुनिन निवडले गेले. आता आमच्याकडे नागिओसमध्ये हजारो चेक आहेत, मुनिनमध्ये शेकडो तक्ते आहेत आणि आमचे सहकारी दररोज त्यांचा यशस्वीपणे वापर करतात. मेट्रिक्स स्पष्ट आहेत, आलेख स्पष्ट आहेत, सिस्टम अनेक वर्षांपासून विश्वासार्हपणे काम करत आहे आणि नवीन चाचण्या आणि आलेख त्यात नियमितपणे जोडले जातात: जेव्हा आम्ही नवीन सेवा कार्यान्वित करतो तेव्हा आम्ही अनेक चाचण्या आणि आलेख जोडतो. नशीब.

फिंगर ऑन द पल्स - प्रगत तांत्रिक विश्लेषण

समस्यांबद्दलची माहिती “शक्य तितक्या लवकर” प्राप्त करण्याच्या इच्छेने आम्हाला साध्या आणि समजण्यायोग्य साधनांसह सक्रिय प्रयोग केले - पिनबा आणि xhprof.

पिनबा ने आम्हाला PHP मधील वेब पेजेसच्या काही भागांच्या ऑपरेशनच्या गतीबद्दल UDP पॅकेटमध्ये आकडेवारी पाठवली आणि आम्ही MySQL स्टोरेजमध्ये ऑनलाइन पाहू शकतो (Pinba जलद इव्हेंट विश्लेषणासाठी स्वतःचे MySQL इंजिनसह येते) समस्यांची एक छोटी यादी आणि प्रतिसाद त्यांना आणि xhprof ने आम्हाला क्लायंटकडून सर्वात हळू असलेल्या PHP पृष्ठांच्या अंमलबजावणीचे आलेख गोळा करण्याची आणि यामुळे काय होऊ शकते याचे विश्लेषण करण्याची परवानगी दिली - शांतपणे, चहा ओतणे किंवा काहीतरी मजबूत.

काही काळापूर्वी, रिव्हर्स इंडेक्सिंग अल्गोरिदमच्या आधारे टूलकिट दुसर्या बर्‍यापैकी साध्या आणि समजण्यायोग्य इंजिनसह पुन्हा भरले गेले होते, जे पौराणिक ल्युसेन लायब्ररी - इलास्टिक/किबाना मध्ये उत्तम प्रकारे लागू केले गेले होते. दस्तऐवजांचे एकाधिक-थ्रेडेड रेकॉर्डिंग लॉगमधील घटनांच्या आधारे व्यस्त ल्युसीन इंडेक्समध्ये करण्याची साधी कल्पना आणि फेसट डिव्हिजन वापरून त्यांच्याद्वारे द्रुत शोध खरोखर उपयुक्त ठरला.

किबाना मधील "बादली" "वरच्या दिशेने वाहते" सारख्या निम्न-स्तरीय संकल्पनांसह आणि अद्याप पूर्णपणे विसरलेले नसलेल्या रिलेशनल बीजगणिताची पुन्हा शोधलेली भाषा असलेल्या व्हिज्युअलायझेशनचे तांत्रिक स्वरूप असूनही, साधनाने आम्हाला पुढील कार्यांमध्ये चांगली मदत करण्यास सुरुवात केली:

• Bitrix24 क्लायंटच्या p1 पोर्टलवर गेल्या तासात किती PHP त्रुटी होत्या आणि कोणत्या? समजून घ्या, क्षमा करा आणि त्वरीत दुरुस्त करा.
• मागील २४ तासांत जर्मनीमधील पोर्टलवर किती व्हिडिओ कॉल्स केले गेले, कोणत्या गुणवत्तेसह आणि चॅनल/नेटवर्कमध्ये काही अडचणी होत्या?
• नवीनतम सेवा अपडेटमध्ये स्त्रोताकडून संकलित केलेली आणि क्लायंटसाठी आणलेली सिस्टीम कार्यक्षमता (PHP साठी आमचा C विस्तार) किती चांगल्या प्रकारे कार्य करते? तेथे segfaults आहेत?
• ग्राहक डेटा PHP मेमरीमध्ये बसतो का? प्रक्रियांना वाटप केलेली मेमरी ओलांडण्याबद्दल काही त्रुटी आहेत का: "मेमरी संपली"? शोधा आणि तटस्थ करा.

येथे एक ठोस उदाहरण आहे. कसून आणि बहु-स्तरीय चाचणी असूनही, क्लायंटला, एक अतिशय मानक नसलेली केस आणि खराब झालेले इनपुट डेटा, एक त्रासदायक आणि अनपेक्षित त्रुटी प्राप्त झाली, एक सायरन वाजला आणि त्वरीत निराकरण करण्याची प्रक्रिया सुरू झाली:

याव्यतिरिक्त, किबाना आपल्याला निर्दिष्ट इव्हेंटसाठी सूचना आयोजित करण्याची परवानगी देते आणि थोड्याच वेळात कंपनीमधील साधन विविध विभागांमधील डझनभर कर्मचार्‍यांकडून वापरले जाऊ लागले - तांत्रिक समर्थन आणि विकासापासून ते QA पर्यंत.

कंपनीमधील कोणत्याही विभागाच्या क्रियाकलापांचा मागोवा घेणे आणि मोजणे सोयीचे झाले आहे - सर्व्हरवरील लॉगचे मॅन्युअली विश्लेषण करण्याऐवजी, तुम्हाला फक्त एकदा पार्सिंग लॉग सेट करावे लागतील आणि आनंद घेण्यासाठी त्यांना लवचिक क्लस्टरवर पाठवावे लागेल, उदाहरणार्थ, किबानामध्ये विचार करणे मागील चंद्र महिन्यासाठी 3-डी प्रिंटरवर छापलेल्या दोन डोकी असलेल्या मांजरीच्या पिल्लांची संख्या डॅशबोर्ड.

मूलभूत व्यवसाय विश्लेषण

प्रत्येकाला माहित आहे की कंपन्यांमधील व्यवसाय विश्लेषणे बर्‍याचदा, होय, एक्सेलच्या अत्यंत सक्रिय वापराने सुरू होतात. पण मुख्य म्हणजे ते तिथेच संपत नाही. क्लाउड-आधारित Google Analytics देखील आगीत इंधन जोडते - तुम्हाला त्वरीत चांगल्या गोष्टींची सवय होऊ लागते.

आमच्या सामंजस्याने विकसनशील कंपनीमध्ये, मोठ्या डेटासह अधिक गहन कार्य करणारे "संदेष्टे" दिसू लागले. अधिक सखोल आणि बहुआयामी अहवालांची आवश्यकता नियमितपणे दिसू लागली आणि वेगवेगळ्या विभागातील लोकांच्या प्रयत्नातून, काही काळापूर्वी एक सोपा आणि व्यावहारिक उपाय आयोजित केला गेला - क्लिकहाऊस आणि पॉवरबीआय यांचे संयोजन.

बर्‍याच काळापासून, या लवचिक समाधानाने खूप मदत केली, परंतु हळूहळू समज येऊ लागले की क्लिकहाऊस रबर नाही आणि त्याची अशी थट्टा केली जाऊ शकत नाही.

येथे हे नीट समजून घेणे महत्त्वाचे आहे की क्लिकहाऊस, ड्रुइड सारखे, व्हर्टिका सारखे, Amazon RedShift सारखे (जे पोस्टग्रेसवर आधारित आहे), विश्लेषणात्मक इंजिने आहेत ज्या योग्यरित्या सोयीस्कर विश्लेषणासाठी ऑप्टिमाइझ केलेली आहेत (बेरीज, एकत्रीकरण, स्तंभानुसार किमान-जास्तीत जास्त आणि काही संभाव्य जोडण्या. ), कारण मायएसक्यूएल आणि आम्हाला ज्ञात असलेल्या इतर (पंक्ती-ओरिएंटेड) डेटाबेसच्या विपरीत, रिलेशनल टेबलच्या स्तंभांच्या कार्यक्षम संचयनासाठी आयोजित केले आहे.

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

अजगर आणि विश्लेषकांची मागणी

आमच्या कंपनीमध्ये अनेक डेव्हलपर आहेत जे PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash मध्ये 10-20 वर्षे जवळजवळ दररोज कोड लिहितात. असे बरेच अनुभवी सिस्टम प्रशासक देखील आहेत ज्यांनी एकापेक्षा जास्त पूर्णपणे अविश्वसनीय आपत्ती अनुभवल्या आहेत जे सांख्यिकी नियमांमध्ये बसत नाहीत (उदाहरणार्थ, जेव्हा रेड -10 मधील बहुसंख्य डिस्क जोरदार विजेच्या धडकेने नष्ट होतात). अशा परिस्थितीत, "पायथन विश्लेषक" म्हणजे काय हे बर्याच काळापासून स्पष्ट झाले नाही. पायथन हे PHP सारखे आहे, फक्त नाव थोडे मोठे आहे आणि इंटरप्रिटरच्या स्त्रोत कोडमध्ये मन बदलणार्‍या पदार्थांचे थोडे कमी ट्रेस आहेत. तथापि, जसजसे अधिकाधिक विश्लेषणात्मक अहवाल तयार केले गेले, तसतसे अनुभवी विकसकांना numpy, pandas, matplotlib, seaborn सारख्या साधनांमधील अरुंद स्पेशलायझेशनचे महत्त्व अधिकाधिक समजू लागले.
निर्णायक भूमिका, बहुधा, "लॉजिस्टिक रीग्रेशन" या शब्दांच्या संयोगातून कर्मचार्‍यांच्या अचानक बेहोश होणे आणि होय, होय, पायस्पार्क वापरून मोठ्या डेटावर प्रभावी अहवाल देण्याचे प्रात्यक्षिक खेळले गेले.

Apache Spark, त्याचे कार्यात्मक प्रतिमान ज्यावर रिलेशनल बीजगणित पूर्णपणे बसते आणि त्याच्या क्षमतांनी MySQL ची सवय असलेल्या विकसकांवर अशी छाप पाडली की अनुभवी विश्लेषकांसह रँक मजबूत करण्याची गरज दिवसेंदिवस स्पष्ट होत गेली.

अपाचे स्पार्क/हडूपचे पुढील प्रयत्न आणि स्क्रिप्टनुसार काय पूर्ण झाले नाही

तथापि, हे लवकरच स्पष्ट झाले की स्पार्कमध्ये काहीतरी पद्धतशीरपणे योग्य नाही किंवा आपले हात चांगले धुणे आवश्यक आहे. जर Hadoop/MapReduce/Lucene स्टॅक बर्‍यापैकी अनुभवी प्रोग्रामरने बनवले असेल, जे जावा मधील स्त्रोत कोड किंवा लुसीनमधील डग कटिंगच्या कल्पनांवर बारकाईने लक्ष दिल्यास स्पष्ट होते, तर स्पार्क, अचानक, विदेशी भाषेत स्काला लिहिला जातो, जो आहे. व्यावहारिकतेच्या दृष्टिकोनातून खूप विवादास्पद आणि सध्या विकसित होत नाही. आणि कमी ऑपरेशन्ससाठी मेमरी ऍलोकेशनसह अतार्किक आणि अतिशय पारदर्शक कामामुळे स्पार्क क्लस्टरवरील गणना नियमितपणे कमी झाल्यामुळे (अनेक कळा एकाच वेळी येतात) त्याच्याभोवती वाढण्यास जागा असलेल्या एखाद्या गोष्टीचा प्रभामंडल तयार झाला आहे. याव्यतिरिक्त, मोठ्या संख्येने विचित्र उघडे बंदर, सर्वात अनाकलनीय ठिकाणी वाढणाऱ्या तात्पुरत्या फायली आणि जार अवलंबित्वांमुळे परिस्थिती बिघडली - ज्यामुळे सिस्टम प्रशासकांना एक भावना होती जी लहानपणापासून प्रसिद्ध होती: तीव्र द्वेष (किंवा कदाचित त्यांना साबणाने हात धुवावे लागतील).

परिणामी, आम्ही अनेक अंतर्गत विश्लेषणात्मक प्रकल्प “जगले” आहेत जे सक्रियपणे Apache Spark (स्पार्क स्ट्रीमिंग, Spark SQL सह) आणि Hadoop इकोसिस्टम (आणि असेच पुढे) वापरतात. कालांतराने आम्ही "ते" तयार करणे आणि त्याचे निरीक्षण करणे चांगले शिकलो हे असूनही, आणि डेटाच्या स्वरूपातील बदल आणि एकसमान आरडीडी हॅशिंगच्या असंतुलनामुळे, आधीच तयार काहीतरी घेण्याची इच्छा यामुळे "ते" व्यावहारिकरित्या अचानक क्रॅश होणे थांबले. , अद्ययावत आणि प्रशासित कुठेतरी ढग मजबूत आणि मजबूत वाढले. यावेळी आम्ही अॅमेझॉन वेब सर्व्हिसेसची रेडीमेड क्लाउड असेंब्ली वापरण्याचा प्रयत्न केला - ईएमआर आणि, त्यानंतर, त्याचा वापर करून समस्या सोडवण्याचा प्रयत्न केला. EMR म्हणजे क्लाउडेरा/हॉर्टनवर्क्स बिल्ड प्रमाणेच, इकोसिस्टममधील अतिरिक्त सॉफ्टवेअरसह Amazon द्वारे तयार केलेले Apache Spark आहे.

विश्लेषणासाठी रबर फाइल स्टोरेज ही तातडीची गरज आहे

शरीराच्या विविध भागांना जळलेल्या हडूप/ स्पार्कचा “स्वयंपाक” करण्याचा अनुभव व्यर्थ ठरला नाही. हार्डवेअर अयशस्वी होण्यास प्रतिरोधक असणारे एकल, स्वस्त आणि विश्वासार्ह फाइल स्टोरेज तयार करण्याची गरज आहे ज्यामध्ये वेगवेगळ्या प्रणालींमधून फाइल्स वेगवेगळ्या फॉरमॅटमध्ये संग्रहित करणे शक्य होईल आणि या डेटाच्या अहवालासाठी कार्यक्षम आणि वेळ-कार्यक्षम नमुने तयार करणे शक्य होईल. स्पष्ट

20-पानांचे Java ट्रेस वाचून आणि स्पार्क हिस्ट्री सर्व्हर आणि बॅकलिट भिंगाचा वापर करून क्लस्टरच्या किलोमीटर-लांब तपशीलवार लॉगचे विश्लेषण करून या प्लॅटफॉर्मचे सॉफ्टवेअर अपडेट करणे हे नवीन वर्षाचे दुःस्वप्न बनू नये अशी माझी इच्छा होती. मला एक साधे आणि पारदर्शक साधन हवे होते ज्यासाठी हूड अंतर्गत नियमित डायव्हिंगची आवश्यकता नसते जर विकसकाची मानक MapReduce विनंती कार्यान्वित करणे थांबवल्यास डेटा वर्करची मेमरी कमी झाल्यामुळे स्रोत डेटा विभाजन अल्गोरिदम योग्यरित्या निवडला नाही.

Amazon S3 डेटालेकसाठी उमेदवार आहे का?

Hadoop/MapReduce च्या अनुभवाने आम्हाला हे शिकवले की आम्हाला एक स्केलेबल, विश्वासार्ह फाइल सिस्टम आणि त्यावरील स्केलेबल कामगारांची आवश्यकता आहे, डेटाच्या जवळ "येणे" जेणेकरून डेटा नेटवर्कवर चालवू नये. कामगारांना वेगवेगळ्या फॉरमॅटमधला डेटा वाचता आला पाहिजे, परंतु शक्यतो अनावश्यक माहिती वाचू नये आणि कामगारांसाठी सोयीस्कर असलेल्या फॉरमॅटमध्ये डेटा अगोदरच साठवता येईल.

पुन्हा एकदा, मूळ कल्पना. एकाच क्लस्टर विश्लेषणात्मक इंजिनमध्ये मोठा डेटा "ओतण्याची" इच्छा नाही, जे लवकरच किंवा नंतर गुदमरेल आणि तुम्हाला ते कुरुप करावे लागेल. मला फाईल्स, फक्त फाईल्स, समजण्यायोग्य फॉरमॅटमध्ये संग्रहित करायच्या आहेत आणि भिन्न परंतु समजण्यायोग्य साधनांचा वापर करून त्यावर प्रभावी विश्लेषणात्मक क्वेरी करू इच्छित आहेत. आणि वेगवेगळ्या फॉरमॅटमध्ये अधिकाधिक फाइल्स असतील. आणि इंजिन नाही तर स्त्रोत डेटा शार्ड करणे चांगले आहे. आम्हाला एक्स्टेंसिबल आणि सार्वत्रिक डेटालेकची आवश्यकता आहे, आम्ही ठरवले...

Hadoop वरून तुमची स्वतःची चॉप्स तयार न करता, तुम्ही परिचित आणि सुप्रसिद्ध स्केलेबल क्लाउड स्टोरेज Amazon S3 मध्ये फाइल्स संचयित केल्यास काय?

हे स्पष्ट आहे की वैयक्तिक डेटा "कमी" आहे, परंतु आम्ही तो तेथे नेला आणि "ते प्रभावीपणे चालवले" तर इतर डेटाचे काय?

Amazon वेब सेवांचे क्लस्टर-बिगडेटा-अ‍ॅनालिटिक्स इकोसिस्टम - अगदी सोप्या शब्दात

AWS सह आमच्या अनुभवाचा आधार घेत, Apache Hadoop/MapReduce तेथे बर्याच काळापासून विविध सॉस अंतर्गत सक्रियपणे वापरले गेले आहे, उदाहरणार्थ डेटापाइपलाइन सेवेमध्ये (मला माझ्या सहकाऱ्यांचा हेवा वाटतो, त्यांनी ते योग्यरित्या कसे तयार करावे हे शिकले). येथे आम्ही DynamoDB सारण्यांमधून वेगवेगळ्या सेवांमधून बॅकअप सेट करतो:


आणि ते अनेक वर्षांपासून क्लॉकवर्क सारख्या एम्बेडेड हॅडूप/मॅपरेड्यूस क्लस्टरवर नियमितपणे चालू आहेत. "ते सेट करा आणि विसरा":

तुम्ही विश्लेषकांसाठी क्लाउडमध्ये ज्युपिटर लॅपटॉप सेट करून आणि एआय मॉडेल्सना युद्धात प्रशिक्षित करण्यासाठी आणि तैनात करण्यासाठी AWS सेजमेकर सेवा वापरून डेटा सैतानिझममध्ये प्रभावीपणे व्यस्त राहू शकता. आमच्यासाठी ते कसे दिसते ते येथे आहे:

आणि हो, तुम्ही स्वतःसाठी किंवा क्लाउडमधील विश्लेषकासाठी एक लॅपटॉप उचलू शकता आणि तो हडूप/स्पार्क क्लस्टरशी संलग्न करू शकता, गणना करू शकता आणि नंतर सर्वकाही खाली करू शकता:

वैयक्तिक विश्लेषणात्मक प्रकल्पांसाठी खरोखर सोयीस्कर आहे आणि काहींसाठी आम्ही मोठ्या प्रमाणात गणना आणि विश्लेषणासाठी EMR सेवा यशस्वीरित्या वापरली आहे. डेटालेकसाठी सिस्टम सोल्यूशनचे काय, ते कार्य करेल? या क्षणी आम्ही आशा आणि निराशेच्या मार्गावर होतो आणि शोध चालू ठेवला.

AWS ग्लू - स्टिरॉइड्सवर सुबकपणे पॅकेज केलेले अपाचे स्पार्क

असे दिसून आले की AWS कडे “Hive/Pig/Spark” स्टॅकची स्वतःची आवृत्ती आहे. पोळ्याची भूमिका, i.e. DataLake मधील फाइल्स आणि त्यांचे प्रकार कॅटलॉग "डेटा कॅटलॉग" सेवेद्वारे केले जातात, जे Apache Hive फॉरमॅटसह त्याची सुसंगतता लपवत नाही. तुमच्या फाइल्स कुठे आहेत आणि त्या कोणत्या फॉरमॅटमध्ये आहेत याबद्दल तुम्हाला या सेवेमध्ये माहिती जोडण्याची आवश्यकता आहे. डेटा केवळ s3 मध्येच नाही तर डेटाबेसमध्ये देखील असू शकतो, परंतु तो या पोस्टचा विषय नाही. आमची DataLake डेटा निर्देशिका कशी आयोजित केली जाते ते येथे आहे:

फायली नोंदणीकृत आहेत, छान. जर फायली अपडेट केल्या गेल्या असतील, तर आम्ही क्रॉलर स्वहस्ते किंवा शेड्यूलवर लॉन्च करतो, जे त्यांच्याबद्दलची माहिती तलावातून अपडेट करेल आणि त्यांना जतन करेल. मग तलावातील डेटावर प्रक्रिया केली जाऊ शकते आणि निकाल कुठेतरी अपलोड केले जाऊ शकतात. सर्वात सोप्या बाबतीत, आम्ही s3 वर देखील अपलोड करतो. डेटा प्रोसेसिंग कुठेही केले जाऊ शकते, परंतु असे सुचवले जाते की तुम्ही AWS Glue API द्वारे प्रगत क्षमता वापरून Apache Spark क्लस्टरवर प्रक्रिया कॉन्फिगर करा. खरं तर, तुम्ही pyspark लायब्ररी वापरून चांगला जुना आणि परिचित पायथन कोड घेऊ शकता आणि काही क्षमतेच्या क्लस्टरच्या N नोड्सवर मॉनिटरिंगसह त्याची अंमलबजावणी कॉन्फिगर करू शकता, Hadoop मध्ये खोदून न घेता आणि डॉकर-मोकर कंटेनर ड्रॅग न करता आणि अवलंबित्व संघर्ष दूर करू शकता. .

पुन्हा एकदा, एक साधी कल्पना. Apache Spark कॉन्फिगर करण्याची गरज नाही, तुम्हाला फक्त pyspark साठी पायथन कोड लिहावा लागेल, तुमच्या डेस्कटॉपवर स्थानिक पातळीवर त्याची चाचणी घ्या आणि नंतर क्लाउडमधील मोठ्या क्लस्टरवर चालवा, स्त्रोत डेटा कुठे आहे आणि परिणाम कुठे ठेवावा हे निर्दिष्ट करा. कधीकधी हे आवश्यक आणि उपयुक्त असते आणि आम्ही ते कसे सेट करतो ते येथे आहे:

अशा प्रकारे, जर तुम्हाला s3 मधील डेटा वापरून स्पार्क क्लस्टरवर काहीतरी मोजायचे असेल, तर आम्ही python/pyspark मध्ये कोड लिहू, त्याची चाचणी करू आणि क्लाउडला शुभेच्छा.

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

तलावामध्ये संग्रहित केलेल्या फायलींचे स्वरूप कार्यप्रदर्शनाची गुरुकिल्ली आहे

आणखी दोन महत्त्वाचे मुद्दे समजून घेणे खूप महत्त्वाचे आहे. तलावातील फाइल डेटावरील क्वेरी शक्य तितक्या लवकर कार्यान्वित करण्यासाठी आणि नवीन माहिती जोडल्यावर कार्यप्रदर्शन खराब होऊ नये म्हणून, तुम्हाला हे करणे आवश्यक आहे:

• फायलींचे स्तंभ स्वतंत्रपणे संग्रहित करा (जेणेकरून तुम्हाला स्तंभांमध्ये काय आहे हे समजून घेण्यासाठी सर्व ओळी वाचण्याची गरज नाही). यासाठी आम्ही कॉम्प्रेशनसह पर्केट फॉरमॅट घेतला
• भाषा, वर्ष, महिना, दिवस, आठवडा यासारख्या फोल्डर्समध्ये फाइल्स शार्ड करणे खूप महत्वाचे आहे. या प्रकारची शार्डिंग समजणारी इंजिने सलग सर्व डेटा न चाळता फक्त आवश्यक फोल्डर पाहतील.

मूलत:, अशाप्रकारे, तुम्ही वर टांगलेल्या विश्लेषणात्मक इंजिनसाठी सर्वात कार्यक्षम स्वरूपात स्त्रोत डेटा मांडता, जे अगदी शार्ड केलेल्या फोल्डरमध्ये देखील निवडकपणे फायलींमधून फक्त आवश्यक स्तंभ प्रविष्ट आणि वाचू शकतात. तुम्हाला डेटा कुठेही "भरण्याची" आवश्यकता नाही (स्टोरेज फक्त फुटेल) - फक्त योग्य स्वरूपात फाइल सिस्टममध्ये त्वरित सुज्ञपणे ठेवा. अर्थात, येथे हे स्पष्ट केले पाहिजे की डेटालेकमध्ये एक मोठी csv फाईल संग्रहित करणे, ज्याला स्तंभ काढण्यासाठी क्लस्टरद्वारे ओळीने ओळीने वाचणे आवश्यक आहे, ते फारसे सूचविले जात नाही. हे सर्व का घडत आहे हे अद्याप स्पष्ट नसल्यास वरील दोन मुद्द्यांचा पुन्हा विचार करा.

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

आणि मग, एक तलाव तयार करताना, आम्ही कसा तरी चुकून ऍमेझॉन एथेनाला भेटलो. अचानक असे घडले की आमच्या प्रचंड लॉग फाइल्स फोल्डर शार्ड्समध्ये योग्य (पार्केट) कॉलम फॉरमॅटमध्ये काळजीपूर्वक व्यवस्थित करून, तुम्ही त्यांच्याकडून अत्यंत माहितीपूर्ण निवडी करू शकता आणि अपाचे स्पार्क/ग्लू क्लस्टरशिवाय अहवाल तयार करू शकता.

s3 मधील डेटाद्वारे समर्थित अथेना इंजिन पौराणिक कथांवर आधारित आहे पटकन - MPP (मॅसिव्ह पॅरलल प्रोसेसिंग) डेटा प्रोसेसिंगच्या दृष्टिकोनाच्या कुटुंबाचा एक प्रतिनिधी, जिथे तो आहे तिथे डेटा घेऊन, s3 आणि Hadoop पासून Cassandra आणि सामान्य मजकूर फाइल्स. तुम्हाला फक्त एथेनाला SQL क्वेरी कार्यान्वित करण्यास सांगण्याची आवश्यकता आहे आणि नंतर सर्वकाही "त्वरीत आणि स्वयंचलितपणे कार्य करते." हे लक्षात घेणे महत्वाचे आहे की एथेना “स्मार्ट” आहे, ती फक्त आवश्यक शार्ड केलेल्या फोल्डर्सवर जाते आणि विनंतीमध्ये आवश्यक असलेले स्तंभ वाचते.

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

आणि योग्यरित्या शार्ड केलेल्या फोल्डर्समधून फक्त आवश्यक स्तंभांची विनंती करून, हे दिसून आले की अथेना सेवेसाठी आम्हाला महिन्याला दहा डॉलर्स खर्च करावे लागतात. बरं, क्लस्टरवरील विश्लेषणाच्या तुलनेत उत्तम, जवळजवळ विनामूल्य!

तसे, आम्ही आमचा डेटा s3 मध्ये कसा शेअर करतो ते येथे आहे:

परिणामी, थोड्याच वेळात, माहितीच्या सुरक्षिततेपासून विश्लेषणापर्यंत कंपनीतील पूर्णपणे भिन्न विभागांनी अथेनाला सक्रियपणे विनंत्या करण्यास सुरुवात केली आणि त्वरीत, काही सेकंदात, बर्‍याच कालावधीत "मोठ्या" डेटाकडून उपयुक्त उत्तरे प्राप्त केली: महिने, अर्धा वर्ष, इ. पी.

पण आम्ही अजून पुढे गेलो आणि उत्तरांसाठी मेघाकडे जाऊ लागलो ODBC ड्रायव्हर द्वारे: एक विश्लेषक परिचित कन्सोलमध्ये SQL क्वेरी लिहितो, जी 100-500 मशीनवर “पेनीजसाठी” s3 ला डेटा पाठवते आणि सामान्यतः काही सेकंदात उत्तर देते. आरामदायक. आणि जलद. माझा अजूनही विश्वास बसत नाही.

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

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

निष्कर्ष

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

असे दिसून आले की कंपनीच्या पूर्णपणे भिन्न विभागांच्या गरजांसाठी डेटालेक ऑपरेट करण्यासाठी एक प्रभावी, जलद आणि स्वस्त तयार करणे अगदी अनुभवी विकसकांच्या क्षमतेमध्ये आहे ज्यांनी कधीही आर्किटेक्ट म्हणून काम केले नाही आणि स्क्वेअरवर स्क्वेअर कसे काढायचे हे माहित नाही. बाण आणि हडूप इकोसिस्टममधील 50 संज्ञा जाणून घ्या.

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

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

स्त्रोत: www.habr.com