[केस लोकोमाइज़र] ढाई साल में 20,000 बार तक हीट मैप की गणना कैसे तेज करें

यह आलेख केस लोकोमाइज़र श्रृंखला की एक निरंतरता है, यह भी देखें

• उपयोगकर्ता निर्देशांक के साथ अनाम डेटासेट से वास्तव में क्या ज्ञान निकाला जा सकता है
• ओपन वन रिंग - क्लाउड में स्पार्क पर जटिल डेटा प्रोसेसिंग प्रक्रियाओं के लचीले विन्यास के लिए एक टूलकिट (जल्द ही आ रहा है!)

नमस्ते



क्या आप जानते हैं कि पोस्टमार्टम क्या होता है? यह एक कहानी है कि हमें ऐसा जीवन कैसे मिला।

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

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

यह लेख वन रिंग का एक ऐतिहासिक परिचय है। इसमें कोई कोड नहीं है, और कहानी वैज्ञानिक की तुलना में अधिक लोकप्रिय है। लेकिन केवल विकास के बारे में, और विकास के ढाई साल के अलावा और कुछ नहीं।

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

• बड़ा डेटा बड़ा है
• हमारा मामला अमानक है
• C # और PostGIS में प्रोटोटाइप
• Hadoop MapReduce के लिए पहला दृष्टिकोण
• CI और स्पार्क का आगमन
• जियोस्पार्क पर तीसरा सन्निकटन
• जापानी विश्लेषकों और Azure से AWS में प्रवासन
• ऐश नजग दरबतुलुक, ऐश नजग गिमबतुल, ऐश नज्ग त्रकतुलुक, अग बुर्जुम इशी कृम्पतुल !!
• Uber H3 के साथ अनुकूलन और जियोकार्टिस
• सभी सफेद में

बड़ा डेटा बड़ा है

बड़ा डेटा आकार के बारे में नहीं है।

ग्रेटर लंदन क्षेत्र में एक मासिक डेटासेट में दसियों या यहां तक ​​कि सैकड़ों लाखों रिकॉर्ड हो सकते हैं, लेकिन यह बहुत ज्यादा नहीं है। शुरुआत से अंत तक उन पर एक एकल पुनरावृत्ति डिस्क से रैखिक पढ़ने की गति पर टिकी हुई है। यदि ड्राइव एक एसएसडी है, तो यह कुछ सेकंड का समय लेगा।

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

हमारी प्रक्रिया बहु-चरणीय है। प्रारंभिक कच्चे डेटा संवर्धन heuristics जो केवल एक पुनरावृत्ति मोड में काम करते हैं वे तेज़ हैं, और आप उन्हें कम से कम पायथन में, कम से कम C ++ में, यहां तक ​​कि PHP में भी लिख सकते हैं। कमजोर मशीन पर भी प्रोसेसिंग जल्दी होगी।

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

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

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

अपने आप में, इस तरह की गणना, यह पता चला है, अगर यह एकल है तो इतना खर्च नहीं होता है। और भले ही उनमें से लाखों हैं, यह, सिद्धांत रूप में, बकवास है।

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

ग्रेटर लंदन क्षेत्र के लिए, लगभग एक मिलियन प्रतिष्ठान स्टोर और आउटलेट श्रेणी में लक्षित POI में आते हैं। और जैसा कि मैंने कहा, मासिक डेटासेट दर्जनों में, सैकड़ों लाखों रिकॉर्ड उसके लिए आते हैं। और इसलिए हम ...

1,000,000 POI × N, 000,000 संकेत = N, 000,000,000,000 दूरी।

ओह, आओ। दूरी की गणना और थ्रेशोल्ड निरंतर तुलना के पागल खरबों।

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

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

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

... भले ही गणना का अंतिम परिणाम एक्सेल तालिका की एक स्क्रीन में ढह जाए।

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

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

खासकर अगर ...

हमारा मामला अमानक है

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

दृष्टिकोण संख्या १। डेटा लेक

डेटा के लिए जो समय के साथ जमा होता है, और हमेशा के लिए प्रासंगिक रहता है, एक विशेष प्रकार का भंडारण डिज़ाइन किया गया है, जिसे तथाकथित " डेटा लेक " कहा जाता है।

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

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

दृष्टिकोण संख्या 2। डेटा स्ट्रीमिंग

वास्तविक समय में आने वाले डेटा के लिए और उन्हें जल्दी से संसाधित करने की आवश्यकता होती है (यानी, डेटा स्ट्रीमिंग), डेटा बसें, या संदेश कतारें डिज़ाइन की जाती हैं।

डेटा बस के साथ एक बुनियादी ढांचे में, एक छोर पर जनरेटर हैं, और दूसरे पर उपभोक्ता हैं, और डेटा स्ट्रीम स्वयं घटनाओं से बना है।

जेनरेटर उत्पन्न होते हैं, और उपभोक्ता, वास्तविक या निकट वास्तविक समय में, घटनाओं का विश्लेषण करते हैं, कुछ अंतिम परिणामों को जमा करते हैं, जो फिर से ऐसी घटनाएं उत्पन्न कर सकते हैं कि एग्रीगेटर्स का अगला सेट उसी बस के माध्यम से उपभोग करेगा, और अंतिम परिणाम प्राप्त होने तक, अंतिम परिणामों के भंडार में तह।

यह अपाचे काफ्का द्वारा संचालित है और एयरोस्पाइक की तरह तेज भंडारण है।

हमारा मामला

लेकिन हमारा मामला इन दोनों दृष्टिकोणों में फिट नहीं बैठता है।

सबसे पहले, हमारे लिए डेटा लेक रखने का कोई मतलब नहीं है, क्योंकि डेटासेट की प्रासंगिकता शायद ही कभी एक वर्ष से अधिक हो (2019 में 2016 के लिए किसी को भी उपयोगकर्ता ट्रैक की आवश्यकता नहीं है), और हर बार ग्राहकों को सभी संचित डेटा के पूरी तरह से अप्रत्याशित हिस्से की आवश्यकता होती है। इसके अलावा, इस तथ्य के कारण कि जनसंख्या और श्रेणी के प्रत्येक खंड के लिए अपना स्वयं का टेम्प्लेट बनाया जाता है, फिर भी हमें केवल आवश्यक टुकड़ा लेने के लिए मजबूर किया जाता है, और उन्हें एक सामान्य झील में विलय करने का कोई मतलब नहीं है। प्रत्येक मासिक डेटासेट को अपने मूल रूप में रखना आसान होता है - CSV फ़ाइलें अपनी अलग निर्देशिका में। फ़ाइल का पथ प्राप्त किया गया है ... / प्रदाता / देश / क्षेत्र / उप-क्षेत्र / वर्ष / माह / डेटासेट फ़ाइलें, और एक उपसमुच्चय का चयन फ़ाइल नाम मुखौटा द्वारा किया जाता है, उदाहरण के लिए, ... / तमोको / यूके / ग्रेटर_लूडन / * / 2019 / {6, 7.8} / * .सीएसवी।

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

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

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

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

C # और PostGIS में प्रोटोटाइप

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

इसने लोगों पर काम किया।

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

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

कच्चे डेटासेट के प्रसंस्करण के लिए अल्पविकसित आंकड़े PHP, Python और C ++ में लिखे गए थे, और हीट मैप की गति की मुख्य गणना C # में एक कार्यक्रम द्वारा की गई थी।



उसने इस तरह काम किया:

1. सबसे पहले, हम सीधे डाटासेट फ़ाइल से सरणी में स्ट्रिंग पढ़ते हैं।
2. इसे foreach'em चलाएं, polzakz पर हैश टेबल बनाएं।
3. POI आधार एक पोस्टग्रैड डेटाबेस में एक शाब्दिक तालिका है, जिसमें टाइप GEOMETRY के पोस्टगेज क्षेत्रों के साथ, और प्रत्येक उपयोगकर्ता संकेत और प्रत्येक POI के बीच की दूरी की गणना करने के लिए, ST_DISTANCE फ़ंक्शन को एक छोटे भंडारण के माध्यम से खींचा जाता है, परिणाम प्रत्येक उपयोगकर्ता के लिए एक हैश तालिका के साथ जोड़ा जाता है।
4. फिर हम सारणी में प्रत्येक कुंजी के लिए ब्याज स्कोर के परिणाम के संचय के साथ तालिका पर फॉर्च करते हैं।
5. एक बार फिर, प्रत्येक श्रेणी के लिए समूह।
6. गणना की समाप्ति के बाद, जो पूरी तरह से कुछ घंटों से लेकर एक सप्ताह के समय तक होती है, परिणाम CSV फ़ाइल में जोड़ा जाता है ...
7. ... और फिर भी मैन्युअल रूप से संसाधित, नक्शे पर आरोपित, और ArcGIS में कल्पना की गई।

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

Hadoop MapReduce के लिए पहला दृष्टिकोण

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

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

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



उन्होंने इस मामले में Microsoft Azure में पांच वर्चुअल मशीनों पर Hadoop के "बड़े क्लस्टर" को उठाया। क्यों अज़ूर सबसे पहले, स्टार्टअप के लिए पहले कुछ वर्षों के लिए एक बड़ी छूट है। दूसरे, नक्शे के विज़ुअलाइज़ेशन के लिए विंडोज के लिए आर्कगिस डेस्कटॉप पहले से ही इस क्लाउड में तैनात किया गया था।

Hadoop क्लस्टर को मैन्युअल रूप से परिनियोजित किया गया था, न कि संबंधित Azure HDInsight सेवा से, जिसे कॉन्फ़िगर करना मुश्किल था। Postgre+PostGIS (- , MR ), . , POI .

, . - PostGIS, , , . , , , , .

, - ( , ) generic « », Senior Java Developer , Big Data . , - - .

, :( , , , , . .

, , . PostGIS , , 5000 . , , . — , ST_DISTANCE , , 40 , , POI .

, , , C# Java. , , - . , . , , .

MapReduce , HDFS , , . , - . — , - , , - .

PostGIS , — .

CI Spark

— ! — , … . — , , , , — . (, - , . # .)

. , , flow , , , .

, . TeamCity , , , . MR TC, .

, , , , , Azure Blob Storage. , / HDFS.

Azure HDInsight — Hortonworks HDP ( ), - API, - Ambari . , , — , - , — . HDP Sandbox 11 , , , . , , , , OOM, .

HDP, Apache Spark. Spark / , , , MR, . RDD — .

Azure Templates PowerShell edge node PostGIS — - , , , , HDFS .

, , , TC , MR, Spark, , HDInsight, — . , .ini ( ), , .

. , , . .

GeoSpark

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

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

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

पराजित होने वाली अगली बड़ी समस्या कार्टेशियन उत्पाद × POI संकेतों की गणना करने के तर्क से आई है।

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

उत्तर: ज्यामितीय ग्रिड पर सिग्नल और POI दोनों का विभाजन ।

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

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

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

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

यह पता चला कि 99% गणना ज्यामितीय विभाजन के साथ सैकड़ों बार त्वरित हुई थी, और लंबी पूंछ के 1% ने पूरे अनुकूलन को लगभग कुछ भी नहीं घटाया।

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

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

जापानी विश्लेषकों और Azure से AWS में प्रवासन

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

जापानी दूरसंचार की "बेटी" के साथ एकीकृत करने की परियोजना ने हमारी परियोजना को लगभग मार दिया। संभावनाएं पागल जापानी विज्ञापन बाजार के लिए एक विशेष डेटा प्रदाता बनने के लिए चमक रही थीं, और व्यापार थोड़ा सा है ... उह, मैं टिप्पणी के बिना कर सकता हूं।

सबसे पहले, कोई Azure। केवल AWS, केवल कट्टर।

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



कुछ बिंदु पर, मैंने थोड़ा ध्यान दिया, और "प्राथमिक संचालन" का एक सेट बनाया - RDD पर लगभग 15 आदिम क्रियाएं जैसे बुनियादी तरीकों को कॉल करना, जैसे कि जोड़ना, मैप करना, डिफ़ॉल्ट मानों को नीचे रखना, कॉलम मानों को जोड़ना - और ऐसे अन्य छोटे ऑपरेशन - जल्दी से गणना श्रृंखला के तर्क को बदलें, जैसे कि यह SQL कथनों का एक समूह था।

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

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

2016-2017 के लिए उपयोगकर्ता संकेतों के साथ परीक्षण (जो कि, छोटा है) डेटासेट, जिस पर हमें तकनीक पर काम करना था, 5 टेराबाइट डेटा, 14,000,000,000 रिकॉर्ड है। अकेले टोक्यो में, कई मिलियन POI हैं, और होक्काइडो क्षेत्र में ग्रिड में 1,600,000 सेल हैं।

और 47 जापानी सिद्धियों में से प्रत्येक के लिए सभी दो हजार श्रेणियों के कार्ड को "मक्खी पर" माना जाना चाहिए, क्योंकि इसे क्लाउड सेवा के रूप में बेचा जाना चाहिए।

मस्तिष्क को तोड़ने का एक महान कार्य। "गणना गति" और "डेटा वॉल्यूम" के संदर्भ में हमारी तत्कालीन क्षमताओं की तुलना में कहीं अधिक परिमाण के तीन या चार आदेश।

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

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

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

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

लेकिन S3 के साथ नहीं। यहाँ मुसीबत वहाँ से निकल गई जहाँ उन्होंने इंतज़ार नहीं किया। S3 की अघोषित सीमा है। उदाहरण के लिए, एक बाल्टी में ~ 11,000,000 से अधिक ऑब्जेक्ट नहीं हो सकते हैं, क्योंकि एपीआई के गहरे आंत्र में वे प्रत्येक (हर!) के लिए लेक्सिकोग्राफ़िक क्रम में कुंजियों को सॉर्ट करते हैं, और इसके लिए आवंटित बफर बस सॉर्टिंग की अनुमति नहीं देता है। अधिक लाइनें, खासकर यदि वे लंबे हैं। गणना को गति देने के लिए, हमने अंत में विभाजन को मर्ज नहीं किया, और कुछ बिंदु पर हम इस सीमा में भाग गए, जिसके बाद प्रक्रिया बंद हो गई।

मन के अनुसार, विलय करना होगा, और यहां तक ​​कि एक उपकरण भी है - s3-dist-cp उपयोगिता, लेकिन इसका उपयोग एक अलग सिरदर्द है। एलियंस के लिए शिकारियों ने यह सुनिश्चित करने के लिए उपयोगिता लिखी, यह बहुत ही स्पष्ट व्यवहार करता है। और इसका एक घातक दोष है - मर्ज की गई फ़ाइल के तहत आपको HDFS पर उतनी ही जगह चाहिए जितनी सभी मूल ले। और आकार के सैकड़ों बाइट्स से दसियों मेगाबाइट्स के दसियों विभाजन के दसियों फाइलों को विलय करने के लिए 25 मशीनों के क्लस्टर में फैला हुआ है, यह बहुत लंबे समय तक चलेगा।

हालांकि, पहले से ही बाल्टी में एक लाख वस्तुओं के साथ, S3 चुपचाप यह अनुरोध करने के लिए शुरू होता है। और अंततः स्थिरता की स्थिति में यह आम तौर पर एक आपदा है - स्पार्क, अगले डेस्क की प्रतीक्षा किए बिना कई बार सहमत संख्या गिर सकती है। एक समाधान है - EMRFS मालिकाना अमेज़ॅन ऐड-ऑन का उपयोग करें, लेकिन यह डायनमोबीडी के शीर्ष पर काम करता है, और यह एक बहुत महंगी चीज है। और प्रति सेकंड अनुरोधों की संख्या पर अपनी सीमा के साथ।

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

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

नुकसान यह है कि जापान मेष जाल केवल जापान के लिए लागू है और द्वीप के क्षेत्र ऐतिहासिक रूप से होने का दावा करते हैं, लेकिन बाकी दुनिया के लिए नहीं। लेकिन कम से कम जापानी के लिए धीमी जियोस्पार्क को छोड़ना संभव हो गया, और बाहरी ज्यामिति के संदर्भ के बिना संकेतों को समान रूप से विभाजित करना। और "लंबी पूंछ" के प्रस्थान के साथ, गणना तुरंत 10 पर एक बार फिर से तेज हो गई।

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

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

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

आह। मुझे डरावनी और थरथराहट वाली यह परियोजना याद है।

ऐश नजग दरबतुलुक, ऐश नजग गिमबतुल, ऐश नज्ग त्रकतुलुक, अग बुर्जुम इशी कृम्पतुल !!

लेकिन सकारात्मक से, सभी एल्गोरिदम का दस्तावेजीकरण करने के अलावा, सामान्य सुधार भी थे।

हमने जावा जूनियर में एक छात्र को सीखा, और उसने भौगोलिक पुस्तकालयों के एक समूह का अध्ययन किया, जिसके परिणामस्वरूप वह आखिरकार सही का चयन करने में सफल रहा और उसे पोस्टगिस के वातावरण से बाहर निकाल दिया।

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

जब तक हमें पता चला कि हमें एक सामान्य भू-भाग (अधिमानतः PostGIS, WGS84 में समान) के साथ एक परिवाद की आवश्यकता थी, परिणाम अपेक्षित परिणामों से सहमत नहीं थे। लेकिन जियोग्राफिकल में जाने के बाद, पोस्टग्रे कनेक्शन के रूप में अड़चन को खत्म कर दिया गया, और गति की गणना करने के अंतिम चरण को 40 गुना तेज किया गया। गोलोव्नायक ने आधार के तहत एक अलग आरडीएस उदाहरण के अतिरिक्त विन्यास के साथ छोड़ दिया और पीओआई के साथ एक डंप अपलोड किया, जो एस 3 में सामान्य डेटासेट में चला गया। एकीकरण!

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

एक और महत्वपूर्ण बिंदु। एक बार, umpteenth के लिए, बाध्यकारी स्क्रिप्टों को देख रहे हैं जो एक के बाद एक स्पार्क मॉड्यूल को कॉल करते हैं, मैंने सोचा, लेकिन हम किस तरह के शैतान के साथ शॉर्ट-सर्किट करते हैं?

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



यदि आप एचडीएफएस को 24 मध्यवर्ती कॉल से छुटकारा दिलाते हैं, विशेष रूप से यह गणना लगभग 50 गुना तेज है।

लेकिन क्या होगा अगर आप प्रक्रिया टेम्पलेट में चर समर्थन जोड़ते हैं ताकि आपको हर बार संपत्ति स्टोर में मापदंडों को बदलने के लिए टास्क.इन को पुनर्जीवित नहीं करना पड़े?

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

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

सहकर्मियों ने परियोजना को "द रिंग ऑफ ऑम्निपोटेंस" कहने के प्रस्ताव पर विरोध किया, - वन रिंग - लेकिन थोड़ा स्वस्थ पाथोस कभी चोट नहीं पहुंचाएगा।

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

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

मापदंडों को संसाधित करने के एकीकृत तर्क के साथ, मॉड्यूल कॉन्फ़िगरेशन के लिए एक अलग एकीकृत ऑब्जेक्ट मॉडल बनाना, और एक ही प्रक्रिया के भीतर एक दूसरे के साथ मॉड्यूल के कॉन्फ़िगरेशन की वैधता और स्थिरता पर सामान्य जांच करना संभव था। CSV — RDD, . , .

RDD, ? , Spark SQL. , Spark — , , white paper, Python, . , .

… . .

, CSV Text ( ), , , . , , CSV, Text. — RDD , ( ), , white paper.

«» Java . , ( RDD) , , , . , .

tasks.ini . , -. DSL — , . JSON .

- Spark jobs.

, Spark job . - . , , .

, :

• , ,
• , , DSL ,
• , — ,
• AWS, .

, . Web UI , , . UI, , - .

Uber H3

, . , , .

- , , , . ( . EE , ; - , REST).

.

— , . , , , . - . — . , — .

. , , . , , . , — , , — .

, . , - , , , , . , , , , .

, .

Spark — . RDD , , . , , , . , , - Spark, , .

— , .

, . , , .map(), , , , JVM .

, , , , , . , .

, , , , .

, One Ring 29 ( ). — 43, , , . , , 10 000 , . - , - .map() .mapPartition(), .

— . . Japan Mesh, , , .

— Uber H3 .

, H3 «hexagonal tree» — . , ( ), , , . , , .

H3, , .

, , — 2.5 , — , , , , - ( , , S3 , ). TC , - , .

— Operation ( Scala, ), , , One Ring , .

, AWS. - , S3, Spark Livy — .

— ?!

- . — VSCode, , Visio. :



REST One Ring, , , 10 , . JSF , , - . SPA - . , .

One Ring ( , ), , . - , , .

, data engineers, . : . GIS, burst- .

( , - ) , , , One Ring .

* One Ring OSS Locomizer. , clean room, , .

… pomadchin , sshikov , dartov .