हम इवेंट प्रोसेसिंग को प्रति सेकंड 1.6 मिलियन तक बढ़ाते हैं

जब हाईलाड ++ प्रतिभागियों ने अलेक्जेंडर क्रेशिनिकोव की रिपोर्ट के लिए आया, तो उन्होंने प्रति सेकंड 1,600,000 घटनाओं के प्रसंस्करण के बारे में सुना। उम्मीदें पूरी नहीं हुईं ... क्योंकि प्रदर्शन की तैयारी के दौरान, यह आंकड़ा 1,800,000 तक चला गया - इसलिए, हाईलाड ++ पर, वास्तविकता अपेक्षाओं से अधिक है।

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



डिक्रिप्शन से, आप सीखेंगे कि कैसे आपने Badoo में ClickHouse के साथ Spark + Hadoop बंडल को बदल दिया, हार्डवेयर को 3 बार बचाया और 6 बार लोड बढ़ाया , क्यों और किस माध्यम से प्रोजेक्ट में आंकड़े एकत्र करना है, और फिर इस डेटा का क्या करना है।



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

सांख्यिकी संग्रह

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

सांख्यिकी जीवन चक्र

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

चरण को परिभाषित करें - औपचारिककरण

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

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

मौखिक रूप से बातचीत करना संभव है, लेकिन यह तब बेहतर होता है जब यह औपचारिक रूप से होता है - घटनाओं की स्पष्ट संरचना में।

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

घटना का विवरण "पंजीकरण":

enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 userid =1; required Gender usergender = 2; required int32 time =3; required int32 countryid =4; } 

पंजीकरण कार्यक्रम में उपयोगकर्ता, क्षेत्र, घटना के समय और उपयोगकर्ता के पंजीकरण के देश के बारे में जानकारी होती है। यह जानकारी विश्लेषकों के लिए उपलब्ध है, और भविष्य में, व्यवसाय समझता है कि हम क्या एकत्र करते हैं।

मुझे औपचारिक विवरण की आवश्यकता क्यों है?

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



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

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

चरण सारांश को परिभाषित करें

हमने तय किया कि आँकड़े - यह महत्वपूर्ण है और एक निश्चित विषय क्षेत्र का वर्णन किया गया है - यह अच्छा है, आप पर रह सकते हैं।

चरण जमा करें - डेटा संग्रह

हमने सिस्टम बनाने का फैसला किया ताकि जब कोई व्यावसायिक घटना घटित हो - पंजीकरण, एक संदेश भेजना, जैसे - इस जानकारी को सहेजने के साथ ही, हम अलग से एक निश्चित सांख्यिकीय घटना भेजते हैं।

कोड में, आँकड़े एक साथ व्यापार घटना के साथ भेजे जाते हैं।

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

EDL के माध्यम से विवरण:

 enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 user_id =1; required Gender user_gender = 2; required int32 time =3; required int32 country_id =4; } 

हमारे पास पंजीकरण कार्यक्रम का विवरण है। एक एपीआई स्वचालित रूप से उत्पन्न होता है, कोड से डेवलपर्स के लिए सुलभ, जो 4 लाइनों में आपको आंकड़े भेजने की अनुमति देता है।

EDL आधारित API:

 \EDL\Event\Regist ration::create() ->setUserId(100500) ->setGender(Gender: :MALE) ->setTime(time()) ->send(); 

इवेंट डिलीवरी

यह हमारी बाहरी व्यवस्था है। हम ऐसा इसलिए करते हैं क्योंकि हमारे पास अविश्वसनीय सेवाएं हैं जो फ़ोटो डेटा के साथ काम करने के लिए एक एपीआई प्रदान करती हैं, कुछ और के बारे में। वे सभी डेटा को नए newfangled डेटाबेस में संग्रहीत करते हैं, जैसे कि Aerospike और CockroachDB।

जब आपको किसी प्रकार की रिपोर्टिंग बनाने की आवश्यकता होती है, तो आपको नहीं जाना होगा और लड़ना होगा: "दोस्तों, यह आपके पास कितना है और कितना है?" - सभी डेटा को एक अलग प्रवाह में भेजा जाता है। प्रसंस्करण कन्वेयर - बाहरी प्रणाली। एप्लिकेशन के संदर्भ से, हम व्यावसायिक लॉजिक रिपॉजिटरी के सभी डेटा को खोल देते हैं, और इसे एक अलग पाइपलाइन में भेजते हैं।

संग्रह चरण एप्लिकेशन सर्वर की उपलब्धता को मानता है। हमारे पास यह PHP है।

ट्रांसपोर्ट

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

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

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

तीसरा पैरामीटर स्केलेबिलिटी है। चूंकि हम प्रति सेकंड लाखों घटनाओं के बारे में बात कर रहे हैं, इसलिए भविष्य की मापनीयता को ध्यान में रखना अच्छा होगा।

कई परिवहन विकल्प हैं: आरडीबीएमएस एप्लिकेशन, फ्लूम, काफ्का या एलएसडी। हम एलएसडी का उपयोग करते हैं - यह हमारा विशेष तरीका है।

लाइव स्ट्रीमिंग डेमॉन

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

सबसे महत्वपूर्ण बात, यह है कि बैटरस ओपनसोर्स - इस सॉफ़्टवेयर पर भरोसा नहीं करने का कोई कारण नहीं है।

यदि यह एक आदर्श दानव था, तो काफ्का के बजाय हम हर सम्मेलन में एलएसडी पर चर्चा करेंगे, लेकिन हर एलएसडी की मरहम में एक मक्खी है। हमारी अपनी सीमाएँ हैं जिनके साथ हम सहज हैं: हम एलएसडी में प्रतिकृति समर्थन नहीं करते हैं और इसकी कम से कम एक बार डिलीवरी की गारंटी है। इसके अलावा, पैसे के लेन-देन के लिए, यह सबसे उपयुक्त परिवहन नहीं है, लेकिन आपको आम तौर पर "एसिड" डेटाबेस के माध्यम से पैसे के साथ संचार करने की आवश्यकता है - एसीआईडी ​​का समर्थन करना।

चरण सारांश लीजिए

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

चरण प्रक्रिया - डाटा प्रोसेसिंग

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

ग्राफिक्स

चार्ट कई रूपों में आते हैं।



या, उदाहरण के लिए, इतिहास वाला एक ग्राफ़ जो 10 वर्षों के लिए डेटा दिखाता है।



चार्ट भी ऐसे ही हैं।



यह कुछ एबी परीक्षण का परिणाम है, और यह आश्चर्यजनक रूप से न्यूयॉर्क में क्रिसलर भवन के समान है।

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

हम प्रति सेकंड 1.8 मिलियन घटनाओं में कैसे बढ़े हैं

यह एक लंबी कहानी है - लाखों आरपीएस एक दिन में नहीं होते। ब्रेट एक कंपनी है जिसका एक दशक का इतिहास है, और हम कह सकते हैं कि कंपनी के साथ डाटा प्रोसेसिंग सिस्टम बढ़ता गया।



पहले तो हमारे पास कुछ नहीं था। हमने डेटा एकत्र करना शुरू किया - यह प्रति सेकंड 5,000 घटनाओं को निकला । एक MySQL होस्ट और कुछ नहीं! कोई भी संबंधपरक डीबीएमएस इस कार्य के साथ सामना करेगा, और यह इसके साथ सहज होगा: आपके पास लेन-देन होगा - डेटा डालें, इससे अनुरोध प्राप्त करें - सब कुछ शांत और अच्छी तरह से काम करता है। तो हम थोड़ी देर के लिए रहते थे।

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

हम बुश में आदर्श वाक्य "अजेय बल" है । हम रुकने वाले नहीं थे और आगे बढ़े। जिस समय हमने प्रति सेकंड 200,000 घटनाओं की सीमा को पार किया, हमने एक औपचारिक विवरण बनाने का फैसला किया, जिसके बारे में मैंने ऊपर बताया। इससे पहले, कुछ अराजकता थी, और अब हमें घटनाओं का एक संरचित रजिस्टर मिला है: हमने सिस्टम को स्केल करना शुरू कर दिया, Hadoop को कनेक्ट किया , सभी डेटा Hive तालिकाओं में चले गए ।

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

हमारे लिए, जावा नया था, हमें यह पसंद आया और हमने समझा कि अलग तरीके से क्या किया जा सकता है।

400,000 से 800,000 घटनाओं के प्रति सेकंड के चरण में, हमने Hadoop को इसके शुद्धतम रूप में बदल दिया और Hive, विश्लेषणात्मक प्रश्नों के निष्पादक के रूप में, स्पार्क स्ट्रीमिंग के साथ, मीट्रिक का जेनेरिक मैप / कम और वृद्धिशील गणना लिखी। 3 साल पहले मैंने बताया कि हमने यह कैसे किया। तब हमें ऐसा लगा कि स्पार्क हमेशा के लिए जीवित रहेगा, लेकिन जीवन ने अन्यथा फैसला कर लिया - हम हाडोप की सीमाओं में भाग गए। शायद अगर हमारी अन्य शर्तें होतीं, तो हम हडोप के साथ रहना जारी रखते।

Hadoop पर रेखांकन की गणना के अलावा, एक और समस्या, अविश्वसनीय चार मंजिला SQL क्वेरी थी जो विश्लेषकों द्वारा संचालित की गई थी, और ग्राफ़ जल्दी से अपडेट नहीं किए गए थे। तथ्य यह है कि परिचालन डेटा प्रसंस्करण के साथ एक मुश्किल काम है, ताकि यह वास्तविक समय, तेज और शांत हो।

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

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

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

बस क्लिकहाउस लें और इसके साथ रहें।

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

ClickHouse

ClickHouse पिछले दो वर्षों का एक प्रचार है और इसे पेश करने की आवश्यकता नहीं है: केवल 2018 में HighLoad ++ में मुझे इसके बारे में पाँच रिपोर्टें , साथ ही सेमिनार और बैठकें याद हैं।

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

ClickHouse में घटनाओं के पूरे प्रवाह को कैसे स्थानांतरित करें? दो डेटा केंद्रों से डेटा को कैसे संयोजित करें? इस तथ्य से कि हम प्रवेशकर्ताओं के पास आए और कहा: "दोस्तों, चलो ClickHouse स्थापित करें", वे नेटवर्क को दो बार मोटा नहीं बनायेंगे, और देरी आधी है। नहीं, नेटवर्क अभी भी पहले वेतन की तरह पतला और छोटा है।

परिणाम कैसे संग्रहीत करें ? Hadoop में, हम समझ गए कि ग्राफिक्स कैसे बनाएं - लेकिन जादू ClickHouse पर इसे कैसे करें? जादू की छड़ी शामिल नहीं है। कैसे समय श्रृंखला भंडारण के लिए परिणाम देने के लिए?

जैसा कि संस्थान में मेरे व्याख्याता ने कहा, 3 डेटा योजनाओं पर विचार करें: रणनीतिक, तार्किक और भौतिक।

सामरिक भंडारण योजना

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

भौतिक भंडारण योजना

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

भंडारण तर्क

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

दृष्टिकोण संख्या 1 - प्रति घटना तालिका। यह पहला दृष्टिकोण, हमने MySQL के साथ प्राप्त अनुभव से अतिरिक्त लिया - हमने ClickHouse में प्रत्येक घटना के लिए एक टैबलेट बनाया। यह बहुत तार्किक लगता है, लेकिन हम कई कठिनाइयों में आ गए।

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

हमारे पास एक हजार से अधिक अलग-अलग कार्यक्रम हैं, जो हमें प्रति मशीन एक उच्च INSERT दर देता है - हम लगातार एक हजार तालिकाओं में सभी डेटा रिकॉर्ड करते हैं। ClickHouse के लिए, यह एक विरोधी पैटर्न है। यदि पेप्सी का नारा है - "लाइव इन बिग सीप्स", तो क्लिकहाउस - "लाइव इन बिग बैच" । यदि ऐसा नहीं किया जाता है, तो प्रतिकृति काटा जाता है, ClickHouse नई आवेषण को स्वीकार करने से इनकार करता है - एक अप्रिय योजना।

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

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

दृष्टिकोण संख्या 3 - सामान्य तालिका। हमारे पास एक विशाल तालिका है जिसमें हम सरणियों में डेटा संग्रहीत करते हैं, क्योंकि ClickHouse गैर-स्केलर डेटा प्रकारों का समर्थन करता है। यही है, हम एक कॉलम शुरू करते हैं जिसमें विशेषताओं के नाम संग्रहीत होते हैं, और एक अलग कॉलम जिसमें सरणी के मूल्य संग्रहीत होते हैं।



यहां ClickHouse अपना कार्य बहुत अच्छे से करता है। यदि हमारे पास केवल डेटा डालने के लिए होता है, तो हम मौजूदा इंस्टॉलेशन में 10 गुना अधिक बार निचोड़ लेंगे।

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

ऐसी तालिका से चयन कैसे करें? हमारा काम लिंग द्वारा वर्गीकृत पंजीकरण को गिनना है। पहले आपको एक सरणी में खोजने की आवश्यकता है कि कौन सी स्थिति लिंग स्तंभ से मेल खाती है, फिर इस सूचकांक के साथ दूसरे कॉलम में चढ़ें और डेटा प्राप्त करें।

इस डेटा पर रेखांकन कैसे बनाएं

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

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

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

इलाज कैसे करें

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

धीरे-धीरे निवेदन

हमारे पास एक धीमा अनुरोध है - आज और कल के लिए अद्वितीय उपयोगकर्ताओं की गणना करने के लिए।

 SELECT uniq(user_id) FROM table WHERE dt IN (today(), yesterday()) 

भौतिक विमान में, हम कल के लिए राज्य के लिए चयन कर सकते हैं, इसका बाइनरी प्रतिनिधित्व प्राप्त कर सकते हैं, इसे कहीं बचा सकते हैं।

 SELECT uniq(user_id), 'xxx' AS ts, uniqState(user id) AS state FROM table WHERE dt IN (today(), yesterday()) 

आज के लिए, हम सिर्फ इस स्थिति को बदलते हैं कि यह आज होगा: 'yyy' AS ts और WHERE dt = today() और टाइमस्टैम्प जिसे हम "xxx" और "yyy" कहेंगे। , , 2 .

 SELECT uniqMerge(state) FROM ageagate_table WHERE ts IN ('xxx', 'yyy') 

:

• , ;
• ;
• .

, - . . , , , , ClickHouse, : «, ! , !»

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



, - time series. : , , , time series.

time series : , , timestamp . , , . . , , , — , . , , ClickHouse -, , .

, , ClickHouse:

— « », — .

time series 2 , 20 20-80 . . ClickHouse GraphiteMergeTree , time series, .

8 ClickHouse , 6 - , 2 : 2 — , . 1.8 . , 500 . , 1,8 , 500 ! .

Hadoop

2 . . 3 , CPU — 4 . , .

Process

, , , . , , ClickHouse 3 000 . , , , overkill.

, , . ClickHouse, . , , , . , 8 3–4 . — .

Present —

, ? time series, time series , , , .



Drop Detect — SQL : SQL- , , .



Anomaly Detection — . , , 2% , — 40, , , , .

— , , - , Anomaly Detection.

Anomaly Detection

, time series . : , , . time series . , , . , drop detection — , .

UI.



. - , — . -, .

Present

, , . , : 1000 — alarm, 0 — alarm. .

Anomaly Detection , . Anomaly Detection Exasol , ClickHouse. Anomaly Detection 2 , .

, , 4 .

, , , . , , . , .

HighLoad++ , HighLoad++ - . , , :)

, PHP Russia , , . , , , 1,8 /, , 1 .