स्रोत

नमस्कार, हेब्र! मेरा नाम मैक्सिम पिशिलिन है, और मैं MyGames पर BI-DWH (Mail.ru ग्रुप का गेमिंग डिवीजन) के विकास का नेतृत्व करता हूं। इस लेख में मैं इस बारे में बात करूंगा कि हमने ग्राहक-उन्मुख डेटालेक स्टोरेज कैसे और क्यों बनाया।

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

क्या हमें DataLake के लिए लाया

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

ऐसे गैर-मानक भंडारण क्यों?

आमतौर पर, बीआई-डीडब्ल्यूएच डेटालेक स्टोरेज के कार्यान्वयन को लागू नहीं करता है; इसे एक विशिष्ट समाधान नहीं कहा जा सकता है। और फिर ऐसी सेवाओं का निर्माण कैसे किया जाता है?

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

मान लीजिए कि एक कंपनी में एक और कंपनी का जन्म हुआ है। एक और विकास टीम और इसके तहत बुनियादी ढाँचा होना आकर्षक, लेकिन महंगा है। इसलिए, परियोजना को "झुका हुआ" होने की आवश्यकता है। यह अलग-अलग तरीकों से किया जा सकता है: डेटाबेस स्तर पर, स्टोर के सामने के स्तर पर, या कम से कम प्रदर्शन स्तर पर - समस्या हल हो गई है।

और अगर कंपनी का तीसरा प्रोजेक्ट है? "साझाकरण" पहले से ही बुरी तरह से समाप्त हो सकता है: संसाधनों के आवंटन या अधिकारों के उपयोग के साथ समस्याएं हो सकती हैं। उदाहरण के लिए, परियोजनाओं में से एक बाहरी टीम द्वारा किया जाता है जिसे पहले दो परियोजनाओं के बारे में कुछ भी जानने की आवश्यकता नहीं है। स्थिति और जोखिम भरी होती जा रही है।

अब कल्पना कीजिए कि तीन परियोजनाएं नहीं हैं, लेकिन बहुत अधिक हैं। और ऐसा हुआ कि यह वास्तव में हमारा मामला है।

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



व्यापार के लिए, यह बहुत अच्छा है, लेकिन बीआई-डीडब्ल्यूएच टीम के लिए कार्य को जटिल करता है।

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

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

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

आप हमारे बीआई-डीडब्ल्यूएच से क्या चाहते हैं?

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

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

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

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

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

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

लेकिन अगर हम अपने खेल में तालमेल बिठाना बंद कर दें तो क्या होगा? मान लीजिए कि हमें उन्हें एक एकल इनपुट एपीआई में डेटा भेजने की आवश्यकता है? परिणाम एक होगा - हर कोई बिखरने लगेगा।

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

क्या हम भंडारण को सरल तरीके से लागू कर सकते हैं?

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

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

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



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

इस सब ने हमें यह समझने के लिए प्रेरित किया कि हमें एक डाटालेक बनाने की आवश्यकता है।

डेटालेक कार्यान्वयन

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

Hadoop में स्विच करें

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

हडोप को लागू करने के बाद, हमें अपने पहले एकीकृत भंडारण के निम्नलिखित चित्र मिले:



डेटा को थोड़े से स्रोतों से Hadoop में एकत्र किया गया था, और फिर उस पर कई इंटरफेस बनाए गए थे: Ad-Hoc विश्लेषिकी के लिए BI उपकरण और सेवाएँ।

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

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

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

प्रक्रिया स्थापना

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

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

इस बिंदु पर, मैं लेख को समाप्त कर सकता था यदि रिपॉजिटरी का ऐसा संस्करण इसके लिए निर्धारित सभी लक्ष्यों को पूरा करेगा। लेकिन ऐसा है नहीं। क्यों?

Hadoop से पहले, हम पाँच परियोजनाओं के लिए डेटा और आँकड़े प्रदान कर सकते थे। Hadoop के कार्यान्वयन और टीम में वृद्धि के बिना, हम 10 परियोजनाओं को कवर करने में सक्षम थे। प्रक्रियाओं को स्थापित करने के बाद, हमारी टीम पहले ही 15 परियोजनाओं की सेवा दे चुकी है। यह अच्छा है, लेकिन हमारे पास 150 परियोजनाएं हैं। हमें कुछ नया चाहिए।

एयरफ्लो कार्यान्वयन

प्रारंभ में, हमने क्रोन का उपयोग करने वाले स्रोतों से डेटा एकत्र किया। दो परियोजनाएं सामान्य हैं। 10 - यह दर्द होता है, लेकिन ठीक है। हालाँकि, अब DataLake में 150 परियोजनाओं से लोड करने के लिए लगभग 12 हजार प्रक्रियाएँ प्रतिदिन भरी जाती हैं। क्रोन अब उपयुक्त नहीं है। ऐसा करने के लिए, हमें डेटा डाउनलोड स्ट्रीम को प्रबंधित करने के लिए एक शक्तिशाली टूल की आवश्यकता है।

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

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

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

एयरफ्लो अनुकूलन योग्य है, यह ऑपरेटरों के ऊपर बनाया गया है - ये विशिष्ट स्रोतों के साथ काम करने के लिए प्लगइन्स हैं। कुछ ऑपरेटर बॉक्स से बाहर आते हैं, कई ने एयरफ्लो समुदाय लिखा है। यदि आप चाहें, तो आप अपना खुद का ऑपरेटर बना सकते हैं, इसके लिए इंटरफ़ेस बहुत सरल है।

हम एयरफ्लो का उपयोग कैसे करते हैं?

उदाहरण के लिए, हमें PostgreSQL से Hadoop में एक तालिका लोड करने की आवश्यकता है। sql_sensor_battle_log कार्य यह देखने के लिए जांचता है कि स्रोत के पास कल के लिए आवश्यक डेटा है या नहीं। यदि हां, तो load_stg_data_from_battle_log कार्य PG से डेटा load_stg_data_from_battle_log और इसे Hadoop में जोड़ता है। अंत में, load_oda_data_from_battle_log प्रारंभिक प्रसंस्करण करता है: कहते हैं, यूनिक्स समय से मानव पठनीय समय में परिवर्तित।

ऐसे कार्यों की श्रृंखला में, डेटा एक इकाई से एक स्रोत में लिया जाता है:



और इसलिए - सभी संस्थाओं से हमें एक स्रोत की आवश्यकता है:



डाउनलोड का यह सेट डीएजी है। और फिलहाल हमारे पास कच्चे डेटा को लोड करने, प्रसंस्करण करने, बदलने और उस पर स्टोरफ्रंट बनाने के लिए 250 ऐसे डीएजी हैं।

अद्यतन एकीकृत भंडारण योजना इस प्रकार है:

1. एयरफ्लो की शुरुआत के बाद, हम स्रोतों की संख्या में तेजी से वृद्धि करने में सक्षम थे - 400 टुकड़े तक। डेटा स्रोत आंतरिक (हमारे खेल से) और बाहरी: खरीदे गए आँकड़े सिस्टम, विषम एपीआई दोनों हैं। यह एयरफ्लो है जो हमें अपने सभी 150 खेलों से डेटा को संसाधित करने वाली 12 हजार प्रक्रियाओं को दैनिक निष्पादित और नियंत्रित करने की अनुमति देता है।
   
2. हमारे एयरफ्लो के बारे में अधिक विस्तार से, डीन सफीना ने अपने लेख ( https://habr.com/ru/company/mailru/blog/344398/ ) में लिखा। और Telegram ( https://t.me/ruairflow ) पर एयरफ़्लो समुदाय से भी जुड़ें। एयरफ्लो के बारे में कई सवालों को प्रलेखन की मदद से हल किया जा सकता है, लेकिन कभी-कभी अधिक कस्टम अनुरोध दिखाई देते हैं: मैं एयरफ्लो को डॉकटर में कैसे पैक कर सकता हूं, तीसरे दिन क्यों काम नहीं करता है और यह सब। इसका जवाब इस समुदाय में दिया जा सकता है।
   

DataLake में क्या सुधार करना है

इस बिंदु पर, DWH डेवलपर्स को भरोसा है कि सब कुछ तैयार है और अब आप शांत हो सकते हैं। दुर्भाग्य से या सौभाग्य से, DataLake में कसने के लिए अभी भी कुछ है।

डेटा की गुणवत्ता

DataLake में बड़ी संख्या में तालिकाओं के साथ, डेटा गुणवत्ता पहले भुगतना है। उदाहरण के लिए, भुगतान के साथ एक तालिका लें। इसमें user_id, राशि, दिनांक और भुगतान का समय शामिल है:


हर दिन लगभग 10 हजार भुगतान होते हैं:



एक बार दिन के लिए तालिका में केवल 28 प्रविष्टियाँ आईं। हां, और user_id सब खाली है:





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

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

डाउनलोड को प्राथमिकता दें

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

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

रात्रि बैच की अवधि की निगरानी करना

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

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

संसाधन नियंत्रण

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

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

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

वास्तुकला लचीलापन

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

उदाहरण के लिए, हमने एक नया मोबाइल गेम लॉन्च किया। वह क्लाइंट से JSON से Nginx लिखती है, Nginx काफ्का को डेटा फेंकता है, हम इसे स्पार्क का उपयोग करके पार्स करते हैं और इसे Hadoop में डालते हैं। सब कुछ काम करता है, कार्य बंद है।



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



इसमें एक बेहतरीन JSON पार्सिंग इंजन है जो तुरंत डेटा को तालिकाओं में विघटित करता है। हम पहले काफ्का से क्लिकहाउस तक जानकारी भेजते हैं, और वहां से हम इसे हडोप में लेते हैं। इससे हमारी समस्या पूरी तरह से हल हो गई।

बेशक, हम अपने डेटालेक स्टोरेज में चिड़ियाघर सिस्टम को प्रजनन नहीं करने की कोशिश करते हैं, लेकिन हम विशिष्ट कार्यों के लिए सबसे उपयुक्त तकनीकों का चयन करने की कोशिश करते हैं।

क्या यह इसके लायक था?

क्या यह एक गुणवत्ता नियंत्रण प्रणाली, एयरफ्लो से निपटने और व्यावसायिक प्रक्रियाओं को स्थापित करने के लिए Hadoop को तैनात करने के लिए लायक था? बेशक यह मूल्य था:

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