हामीले कसरी एक उच्च कुशल र सस्तो DataLake संगठित गर्यौं र यो किन हो

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

यो कुनै कुराको लागि होइन कि अधिक अनुभवी सहकर्मीहरू, तिनीहरूको टाउको बगहरूले छरिएको छ र त्यसैले पहिले नै खैरो छ, "क्युबहरू" मा "कनटेनरहरू" को प्याकहरूको अविश्वसनीय रूपमा द्रुत तैनाथीको बारेमा विचार गर्दै "फैसन भाषाहरू" मा दर्जनौं सर्भरहरूमा निर्मित समर्थनको साथ। एसिन्क्रोनस नन-ब्लकिङ I/O, नम्रतापूर्वक मुस्कुराउनुहोस्। र तिनीहरू चुपचाप "man ps" पुन: पढ्न जारी राख्छन्, "nginx" स्रोत कोडमा उनीहरूको आँखा रगत नआएसम्म, र लेख्ने, लेख्ने, लेख्ने एकाइ परीक्षणहरू। सहकर्मीहरूलाई थाहा छ कि सबैभन्दा चाखलाग्दो कुरा तब आउनेछ जब "यी सबै" एक दिन नयाँ वर्षको पूर्वसन्ध्यामा राती दाँयामा लगाइन्छ। र तिनीहरूलाई युनिक्सको प्रकृति, याद गरिएको TCP/IP स्थिति तालिका र आधारभूत क्रमबद्ध-खोज एल्गोरिदमहरूको गहिरो बुझाइले मात्र मद्दत गर्नेछ। चाइम्स स्ट्राइकको रूपमा प्रणालीलाई पुन: जीवनमा ल्याउन।

ओह हो, म अलिकति विचलित भएँ, तर मलाई आशा छ कि मैले प्रत्याशाको अवस्था व्यक्त गर्न सफल भएँ।
आज म DataLake को लागि सुविधाजनक र सस्तो स्ट्याक प्रयोग गर्ने हाम्रो अनुभव साझा गर्न चाहन्छु, जसले कम्पनीमा पूर्ण रूपमा फरक संरचनात्मक विभाजनहरूको लागि अधिकांश विश्लेषणात्मक कार्यहरू समाधान गर्दछ।

केही समय अघि, हामीले बुझेका थियौं कि कम्पनीहरूलाई उत्पादन र प्राविधिक विश्लेषण दुवैको फल बढ्दो रूपमा चाहिन्छ (मेसिन लर्निङको रूपमा केकमा आइसिङ उल्लेख नगर्नुहोस्) र प्रवृत्ति र जोखिमहरू बुझ्नको लागि - हामीले सङ्कलन र विश्लेषण गर्न आवश्यक छ। अधिक र अधिक मेट्रिक्स।

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

धेरै वर्ष पहिले, Bitrix24 सेवाको सुरुवातको साथसाथै, हामीले एक सरल र भरपर्दो विश्लेषणात्मक प्लेटफर्म सिर्जना गर्न सक्रिय रूपमा समय र स्रोतहरू लगानी गर्यौं जसले पूर्वाधारमा समस्याहरू द्रुत रूपमा हेर्न र अर्को चरणको योजना बनाउन मद्दत गर्दछ। निस्सन्देह, यो सम्भव भएसम्म सरल र बुझ्न सक्ने तयारी उपकरणहरू लिन सल्लाह दिइयो। नतिजाको रूपमा, नागियोसलाई निगरानी र मुनिनलाई विश्लेषण र दृश्यका लागि छनोट गरियो। अब हामीसँग नागियोमा हजारौं चेकहरू छन्, मुनिनमा सयौं चार्टहरू छन्, र हाम्रा सहकर्मीहरूले तिनीहरूलाई हरेक दिन सफलतापूर्वक प्रयोग गर्छन्। मेट्रिकहरू स्पष्ट छन्, ग्राफहरू स्पष्ट छन्, प्रणाली धेरै वर्षदेखि विश्वसनीय रूपमा काम गरिरहेको छ र नयाँ परीक्षणहरू र ग्राफहरू यसमा नियमित रूपमा थपिन्छन्: जब हामीले नयाँ सेवा सञ्चालनमा राख्छौं, हामी धेरै परीक्षणहरू र ग्राफहरू थप्छौं। भाग्यले साथ दिओस्।

फिंगर अन द पल्स - उन्नत टेक्निकल एनालिटिक्स

समस्याहरूको बारेमा जानकारी प्राप्त गर्ने इच्छाले "जति सक्दो चाँडो" हामीलाई सरल र बुझ्न सकिने उपकरणहरू - pinba र xhprof को साथ सक्रिय प्रयोगहरूमा लैजायो।

पिनबाले हामीलाई PHP मा वेब पृष्ठहरूको भागहरूको सञ्चालनको गतिको बारेमा UDP प्याकेटहरूमा तथ्याङ्कहरू पठायो, र हामीले MySQL भण्डारणमा अनलाइन देख्न सक्छौं (Pinba छिटो घटना विश्लेषणका लागि आफ्नै MySQL इन्जिनसँग आउँछ) समस्याहरूको छोटो सूची र प्रतिक्रिया दिन्छ। उनीहरु। र xhprof ले स्वचालित रूपमा हामीलाई ग्राहकहरूबाट सबैभन्दा ढिलो PHP पृष्ठहरूको कार्यान्वयनको ग्राफहरू सङ्कलन गर्न र यसले के निम्त्याउन सक्छ भनेर विश्लेषण गर्न अनुमति दियो - शान्त रूपमा, चिया खन्याएर वा केहि बलियो।

केही समय अघि, टूलकिटलाई उल्टो अनुक्रमणिका एल्गोरिथ्ममा आधारित अर्को एकदम सरल र बुझ्न सकिने इन्जिनले भरिएको थियो, पूर्ण रूपमा पौराणिक लुसेन पुस्तकालयमा लागू गरिएको - लोचदार/किबाना। कागजातहरूको बहु-थ्रेडेड रेकर्डिङको सरल विचार लगहरूमा भएका घटनाहरूमा आधारित उल्टो लुसेन अनुक्रमणिकामा र फेस डिभिजन प्रयोग गरेर तिनीहरूको माध्यमबाट द्रुत खोजी वास्तवमै उपयोगी साबित भयो।

किबानामा "बाल्टी" "माथितिर बग्ने" जस्ता निम्न-स्तर अवधारणाहरू र अझै पूर्ण रूपमा नबिर्सिएको रिलेसनल बीजगणितको पुन: आविष्कार गरिएको भाषाको साथ किबानामा भिजुअलाइजेसनको बरु प्राविधिक उपस्थितिको बावजुद, उपकरणले हामीलाई निम्न कार्यहरूमा राम्रोसँग मद्दत गर्न थाल्यो:

• पछिल्लो घण्टामा P24 पोर्टलमा Bitrix1 क्लाइन्टले कति PHP त्रुटिहरू थिए र कुन? बुझ्नुहोस्, माफ गर्नुहोस् र छिटो सच्याउनुहोस्।
• जर्मनीका पोर्टलहरूमा विगत २४ घण्टामा कतिवटा भिडियो कलहरू गरिएका थिए, कुन गुणस्तरमा र च्यानल/नेटवर्कमा कुनै कठिनाइहरू थिए?
• प्रणाली कार्यक्षमता (PHP को लागि हाम्रो C विस्तार), नवीनतम सेवा अद्यावधिकमा स्रोतबाट कम्पाइल गरिएको र ग्राहकहरूलाई रोल आउट गरिएको, कत्तिको राम्रोसँग काम गर्दछ? त्यहाँ segfaults छन्?
• के ग्राहक डेटा PHP मेमोरीमा फिट हुन्छ? के त्यहाँ प्रक्रियाहरूमा छुट्याइएको मेमोरी भन्दा बढीको बारेमा कुनै त्रुटिहरू छन्: "मेमोरी बाहिर"? फेला पार्नुहोस् र तटस्थ गर्नुहोस्।

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

थप रूपमा, किबानाले तपाईंलाई निर्दिष्ट घटनाहरूको लागि सूचनाहरू व्यवस्थित गर्न अनुमति दिन्छ, र छोटो समयमा कम्पनीमा उपकरण विभिन्न विभागहरूका दर्जनौं कर्मचारीहरूले प्रयोग गर्न थाले - प्राविधिक समर्थन र विकासदेखि QA सम्म।

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

आधारभूत व्यापार विश्लेषण

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

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

लामो समयको लागि, यो लचिलो समाधानले धेरै मद्दत गर्यो, तर बिस्तारै यो बुझाउन थाल्यो कि क्लिकहाउस रबर होइन र यसरी मजाक गर्न सकिदैन।

यहाँ यो राम्ररी बुझ्न महत्त्वपूर्ण छ कि क्लिकहाउस, जस्तै ड्रुइड, जस्तै Vertica, जस्तै Amazon RedShift (जो postgres मा आधारित छ), विश्लेषणात्मक इन्जिनहरू पर्याप्त सुविधाजनक एनालिटिक्सको लागि अनुकूलित हुन्छन् (योग, एकत्रीकरण, स्तम्भ द्वारा न्यूनतम-अधिकतम र केही सम्भावित जोडहरू। ), किनभने MySQL र हामीलाई ज्ञात अन्य (पङ्क्ति-उन्मुख) डाटाबेसहरूको विपरीत, सम्बन्ध तालिकाहरूको स्तम्भहरूको कुशल भण्डारणको लागि व्यवस्थित।

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

अजगर र विश्लेषकहरूको माग

हाम्रो कम्पनीसँग PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash मा 10-20 वर्षको लागि लगभग हरेक दिन कोड लेख्ने धेरै विकासकर्ताहरू छन्। त्यहाँ धेरै अनुभवी प्रणाली प्रशासकहरू पनि छन् जसले एक भन्दा बढी बिल्कुल अविश्वसनीय प्रकोपहरू अनुभव गरेका छन् जुन तथ्याङ्कको नियमहरूमा फिट हुँदैन (उदाहरणका लागि, जब छापा-१० मा धेरै डिस्कहरू बलियो बिजुली स्ट्राइकद्वारा नष्ट हुन्छन्)। यस्तो अवस्थामा, लामो समयसम्म यो स्पष्ट थिएन कि "पाइथन विश्लेषक" के हो। पाइथन PHP जस्तै हो, केवल नाम अलि लामो छ र त्यहाँ अनुवादकको स्रोत कोडमा दिमाग परिवर्तन गर्ने पदार्थहरूको थोरै कम निशानहरू छन्। यद्यपि, अधिक र अधिक विश्लेषणात्मक रिपोर्टहरू सिर्जना गर्दा, अनुभवी विकासकर्ताहरूले numpy, pandas, matplotlib, seaborn जस्ता उपकरणहरूमा साँघुरो विशेषज्ञताको महत्त्व बुझ्न थाले।
निर्णायक भूमिका, सम्भवतः, "लजिस्टिक रिग्रेसन" शब्दहरूको संयोजनबाट कर्मचारीहरूको अचानक बेहोश हुनु र हो, हो, पाइस्पार्क प्रयोग गरेर ठूलो डेटामा प्रभावकारी रिपोर्टिङको प्रदर्शनले खेलेको थियो।

Apache Spark, यसको कार्यात्मक प्रतिमान जसमा रिलेशनल बीजगणित पूर्ण रूपमा फिट हुन्छ, र यसको क्षमताहरूले MySQL मा अभ्यस्त विकासकर्ताहरूमा यस्तो प्रभाव पार्यो कि अनुभवी विश्लेषकहरूको साथ रैंकलाई बलियो बनाउन आवश्यकता दिनको रूपमा स्पष्ट भयो।

Apache Spark/Hadoop को थप प्रयासहरू टेक अफ गर्न र के स्क्रिप्ट अनुसार राम्रो भएन

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

नतिजाको रूपमा, हामीले धेरै आन्तरिक विश्लेषणात्मक परियोजनाहरू "बाँच्यौं" जुन सक्रिय रूपमा Apache Spark (Spark Streaming, Spark SQL सहित) र Hadoop इकोसिस्टम (र यस्तै र अन्य) प्रयोग गर्दछ। तथ्यको बावजुद हामीले "यो" लाई राम्रोसँग तयार गर्न र निगरानी गर्न सिकेका छौं, र डाटाको प्रकृतिमा परिवर्तन र एकसमान RDD ह्यासिङको असन्तुलनका कारण "यो" व्यावहारिक रूपमा अचानक क्र्यास बन्द भयो, पहिले नै तयार भएको केहि लिने इच्छा। , क्लाउडमा कतै अद्यावधिक र प्रशासित बलियो र बलियो बढ्यो। यो समय थियो कि हामीले अमेजन वेब सेवाहरूको तयार क्लाउड एसेम्बली प्रयोग गर्ने प्रयास गर्यौं - EMR र, पछि, यसको प्रयोग गरेर समस्याहरू समाधान गर्ने प्रयास गरियो। EMR भनेको Cloudera/Hortonworks ले जस्तै इकोसिस्टमबाट थप सफ्टवेयरको साथ Amazon द्वारा तयार पारिएको Apache Spark हो।

विश्लेषणका लागि रबर फाइल भण्डारण तत्काल आवश्यकता हो

शरीरका विभिन्न भागहरूमा जलेको "पकाउने" हडूप/स्पार्कको अनुभव व्यर्थ थिएन। एकल, सस्तो र भरपर्दो फाइल भण्डारण सिर्जना गर्न आवश्यक छ जुन हार्डवेयर विफलताहरूको लागि प्रतिरोधी हुनेछ र जसमा विभिन्न प्रणालीहरूबाट विभिन्न ढाँचाहरूमा फाइलहरू भण्डारण गर्न र यस डेटाबाट रिपोर्टहरूको लागि कुशल र समय-कुशल नमूनाहरू बनाउन सम्भव हुनेछ। स्पष्ट

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

के Amazon S3 DataLake को लागि उम्मेदवार हो?

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

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

यदि तपाईंले Hadoop बाट आफ्नै चपहरू तयार नगरीकन, परिचित र प्रख्यात स्केलेबल क्लाउड भण्डारण Amazon S3 मा फाइलहरू भण्डार गर्नुभयो भने के हुन्छ?

यो स्पष्ट छ कि व्यक्तिगत डेटा "कम" छ, तर यदि हामीले यसलाई त्यहाँबाट बाहिर निकाल्यौं र "प्रभावी रूपमा ड्राइभ" गर्छौं भने अन्य डेटाको बारेमा के हुन्छ?

Amazon Web Services को क्लस्टर-bigdata-analytics इकोसिस्टम - धेरै सरल शब्दहरूमा

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


र तिनीहरू इम्बेडेड Hadoop/MapReduce क्लस्टरहरूमा क्लकवर्क जस्तै धेरै वर्षदेखि नियमित रूपमा चलिरहेका छन्। "सेट गर्नुहोस् र यसलाई बिर्सनुहोस्":

तपाईं विश्लेषकहरूका लागि क्लाउडमा जुपिटर ल्यापटपहरू सेटअप गरेर र एआई मोडेलहरूलाई युद्धमा तालिम दिन र प्रयोग गर्न AWS SageMaker सेवा प्रयोग गरेर डेटा सैतानवादमा प्रभावकारी रूपमा संलग्न हुन सक्नुहुन्छ। यो हाम्रो लागि कस्तो देखिन्छ यहाँ छ:

र हो, तपाईं क्लाउडमा आफ्नो लागि वा विश्लेषकको लागि ल्यापटप उठाउन सक्नुहुन्छ र यसलाई Hadoop/Spark क्लस्टरमा संलग्न गर्न सक्नुहुन्छ, गणना गर्नुहोस् र त्यसपछि सबै चीजहरू खाली गर्नुहोस्:

व्यक्तिगत विश्लेषणात्मक परियोजनाहरूका लागि साँच्चै सुविधाजनक र केहीका लागि हामीले ठूलो मात्रामा गणना र विश्लेषणका लागि EMR सेवा सफलतापूर्वक प्रयोग गरेका छौं। DataLake को लागी एक प्रणाली समाधान को बारे मा के हो, यसले काम गर्दछ? यस क्षणमा हामी आशा र निराशाको कगारमा थियौं र खोजी जारी राख्यौं।

AWS ग्लु - स्टेरोइडहरूमा सफासँग प्याकेज गरिएको Apache Spark

यो पत्ता लाग्यो कि AWS सँग "Hive/Pig/Spark" स्ट्याकको आफ्नै संस्करण छ। Hive को भूमिका, i.e. DataLake मा फाइलहरू र तिनीहरूका प्रकारहरूको क्याटलग "डेटा क्याटलग" सेवाद्वारा गरिन्छ, जसले Apache Hive ढाँचासँग यसको अनुकूलता लुकाउँदैन। तपाईले यस सेवामा तपाईका फाइलहरू कहाँ छन् र तिनीहरू कुन ढाँचामा छन् भन्ने बारे जानकारी थप्न आवश्यक छ। डाटा s3 मा मात्र होइन, डाटाबेसमा पनि हुन सक्छ, तर त्यो यस पोष्टको विषय होइन। यहाँ हाम्रो DataLake डाटा डाइरेक्टरी कसरी व्यवस्थित गरिएको छ:

फाइलहरू दर्ता छन्, उत्कृष्ट। यदि फाइलहरू अद्यावधिक गरिएका छन् भने, हामी क्रलरहरूलाई या त म्यानुअल रूपमा वा तालिकामा सुरू गर्छौं, जसले तालबाट तिनीहरूको बारेमा जानकारी अद्यावधिक गर्नेछ र तिनीहरूलाई बचत गर्नेछ। त्यसपछि तालबाट डाटा प्रशोधन गर्न सकिन्छ र नतिजाहरू कतै अपलोड गर्न सकिन्छ। सरल अवस्थामा, हामी s3 मा पनि अपलोड गर्छौं। डाटा प्रशोधन कहीं पनि गर्न सकिन्छ, तर यो सुझाव दिइन्छ कि तपाइँ AWS Glue API मार्फत उन्नत क्षमताहरू प्रयोग गरेर Apache Spark क्लस्टरमा प्रशोधन कन्फिगर गर्नुहोस्। वास्तवमा, तपाईंले पाइस्पार्क लाइब्रेरी प्रयोग गरेर राम्रो पुरानो र परिचित पाइथन कोड लिन सक्नुहुन्छ र निगरानीको साथ केही क्षमताको क्लस्टरको N नोडहरूमा यसको कार्यान्वयन कन्फिगर गर्न सक्नुहुन्छ, Hadoop को हिम्मतमा खन्ने र डकर-मोकर कन्टेनरहरू तानेर र निर्भरता द्वन्द्वहरू हटाउन बिना। ।

फेरि, एक साधारण विचार। त्यहाँ Apache Spark कन्फिगर गर्न आवश्यक छैन, तपाईंले केवल pyspark को लागि पाइथन कोड लेख्न आवश्यक छ, यसलाई आफ्नो डेस्कटपमा स्थानीय रूपमा परीक्षण गर्नुहोस् र त्यसपछि क्लाउडमा ठूलो क्लस्टरमा चलाउनुहोस्, स्रोत डेटा कहाँ छ र परिणाम कहाँ राख्ने भनेर निर्दिष्ट गर्नुहोस्। कहिलेकाहीँ यो आवश्यक र उपयोगी छ, र यहाँ हामीले यसलाई कसरी सेट अप गर्छौं:

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

आर्केस्ट्राको बारेमा के हो? यदि कार्य खस्यो र गायब भयो भने के हुन्छ? हो, यो Apache Pig शैलीमा एक सुन्दर पाइपलाइन बनाउने प्रस्ताव गरिएको छ र हामीले तिनीहरूलाई प्रयास पनि गर्यौं, तर अहिलेको लागि हामीले PHP र JavaScript मा हाम्रो गहिरो अनुकूलित अर्केस्ट्रेशन प्रयोग गर्ने निर्णय गर्यौं (म बुझ्छु, त्यहाँ संज्ञानात्मक असन्तुष्टि छ, तर यसले काम गर्दछ, वर्ष र त्रुटि बिना)।

तालमा भण्डारण गरिएका फाइलहरूको ढाँचा प्रदर्शनको कुञ्जी हो

दुई थप मुख्य बुँदाहरू बुझ्न यो धेरै, धेरै महत्त्वपूर्ण छ। तालमा रहेको फाइल डाटामा प्रश्नहरू जतिसक्दो चाँडो कार्यान्वयन गर्न र नयाँ जानकारी थप्दा कार्यसम्पादन खस्किन नदिनको लागि, तपाईंले:

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

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

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

र त्यसपछि, ताल सिर्जना गर्दा, हामी कुनै न कुनै रूपमा अमेजन एथेना पार गर्यौं। अचानक यो पत्ता लाग्यो कि हाम्रा ठूला लग फाइलहरूलाई फोल्डर शार्डहरूमा सही (पार्केट) स्तम्भ ढाँचामा सावधानीपूर्वक व्यवस्थित गरेर, तपाईंले तिनीहरूबाट अत्यन्तै जानकारीपूर्ण छनोटहरू गर्न सक्नुहुन्छ र Apache Spark/Glue क्लस्टर बिना रिपोर्टहरू निर्माण गर्न सक्नुहुन्छ।

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

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

र सही रूपमा सेयर गरिएका फोल्डरहरूबाट आवश्यक स्तम्भहरू मात्र अनुरोध गरेर, यो पत्ता लाग्यो कि एथेना सेवाले हामीलाई महिनामा दसौं डलर खर्च गर्छ। ठीक छ, उत्कृष्ट, लगभग निःशुल्क, क्लस्टरहरूमा एनालिटिक्सको तुलनामा!

वैसे, यहाँ हामी कसरी s3 मा हाम्रो डाटा साझा गर्छौं:

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

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

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

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

निष्कर्ष

लामो, तर पीडादायी बाटो पार गरिसकेपछि, जोखिम र जटिलताको स्तर र समर्थनको लागतलाई निरन्तर रूपमा पर्याप्त रूपमा मूल्याङ्कन गर्दै, हामीले डाटालेक र एनालिटिक्सको लागि समाधान फेला पार्यौं जुन स्वामित्वको गति र लागत दुवैको साथ हामीलाई खुशी पार्न कहिल्यै बन्द हुँदैन।

यसले पत्ता लगायो कि कम्पनीका पूर्णतया फरक विभागहरूको आवश्यकताहरूको लागि डाटालेक सञ्चालन गर्न प्रभावकारी, छिटो र सस्तो निर्माण गर्नु पूर्णतया अनुभवी विकासकर्ताहरूको क्षमता भित्र छ जसले वास्तुकारको रूपमा काम नगरेका र स्क्वायरहरूमा स्क्वायरहरू कसरी कोर्ने भनेर जान्दैनन्। तीरहरू र Hadoop इकोसिस्टमबाट 50 सर्तहरू जान्नुहोस्।

यात्राको सुरुमा, मेरो टाउको खुला र बन्द सफ्टवेयरका धेरै जंगली चिडियाखानाहरू र सन्तानहरूप्रतिको जिम्मेवारीको भारको बुझाइबाट विभाजित भएको थियो। सरल उपकरणहरूबाट आफ्नो DataLake निर्माण सुरु गर्नुहोस्: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., प्रतिक्रिया सङ्कलन गर्दै र भइरहेको प्रक्रियाहरूको भौतिक विज्ञानलाई गहिरो रूपमा बुझ्दै। सबै जटिल र धमिलो - यसलाई शत्रु र प्रतिस्पर्धीहरूलाई दिनुहोस्।

यदि तपाईं क्लाउडमा जान चाहनुहुन्न र खुला स्रोत परियोजनाहरूलाई समर्थन गर्न, अद्यावधिक गर्न र प्याच गर्न चाहनुहुन्छ भने, तपाईंले स्थानीय रूपमा हाम्रो जस्तै योजना बनाउन सक्नुहुन्छ, सस्तो अफिस मेसिनहरूमा Hadoop र Presto माथि। मुख्य कुरा रोक्न र अगाडि बढ्नु होइन, गणना गर्नुहोस्, सरल र स्पष्ट समाधानहरू खोज्नुहोस्, र सबै कुरा निश्चित रूपमा काम गर्नेछ! सबैलाई शुभकामना र फेरि भेट्नुहोस्!

स्रोत: www.habr.com