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

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

अब हमारे पास प्रति दिन लगभग 6 बिलियन भोजन की घटनाएं हैं, निकट भविष्य में हम 20-25 बिलियन तक पहुंच जाएंगे। और फिर - इतनी तेज गति से नहीं, हम वर्ष के अंत तक 40-50 बिलियन तक बढ़ जाएंगे जब हम हमारे लिए भोजन की सभी घटनाओं का वर्णन करेंगे।

सेट में 1 पंक्तियाँ। बीता हुआ: 0.287 सेकंड। 59.85 बिलियन पंक्तियों, 59.85 GB (208.16 बिलियन पंक्तियों / s, 208.16 GB / s) पर संसाधित।

कट के तहत विवरण।

प्रस्तावना

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

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

हम इस नतीजे पर पहुँचे कि अब इस तरह रहना संभव नहीं है। प्रत्येक टीम में डेटा होना चाहिए, उन पर क्वेरीज़ तेज़ होनी चाहिए, और डेटा स्वयं ही उपयोगी मापदंडों में सटीक और समृद्ध होना चाहिए।

इसलिए, हमने सांख्यिकी / एनालिटिक्स की नई प्रणाली के लिए स्पष्ट आवश्यकताएं तैयार की हैं:

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

रसोई में

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

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

पहले नमूने

हमने इस कॉन्फ़िगरेशन के साथ दो मशीनों का एक समूह तैनात किया है:
2xE5-2620 v4 (कुल में 32 कोर), 256G ram, 28T स्थान (ext4 के साथ raid10)।

प्रारंभ में, यह लेआउट के पास था, लेकिन फिर हमने दूर तक स्विच किया। ClickHouse में कई अलग-अलग टेबल इंजन हैं, लेकिन मुख्य मर्जट्री परिवार से हैं। हमने निम्न सेटिंग्स के साथ ReplpedReplacingMergeTree को चुना:

PARTITION BY dt ORDER BY (toStartOfHour(time), cityHash64(user_id), event_microsec, event_id) SAMPLE BY cityHash64(user_id) SETTINGS index_granularity = 8192; 

प्रतिकृति - इसका मतलब है कि तालिका को दोहराया गया है, और यह हमारी विश्वसनीयता आवश्यकताओं में से एक को हल करता है।

प्रतिस्थापित करना - तालिका प्राथमिक कुंजी द्वारा कटौती का समर्थन करती है: डिफ़ॉल्ट रूप से, प्राथमिक कुंजी सॉर्ट कुंजी से मेल खाती है, इसलिए ORDER BY अनुभाग आपको बताता है कि प्राथमिक कुंजी क्या है।

नमूना द्वारा - मैं भी नमूना लेने की कोशिश करना चाहता था: नमूना एक समान रूप से छद्म यादृच्छिक नमूना देता है।

index_granularity = 8192 इंडेक्स सेरिफ़्स (हाँ, यह विरल है) के बीच डेटा पंक्तियों की जादुई संख्या है, जिसका उपयोग डिफ़ॉल्ट रूप से किया जाता है। हमने इसे नहीं बदला।

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

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

गति की बात करें तो मेरा मतलब है कि एक भी अनुरोध 500 एमएस से अधिक समय तक नहीं चला और उनमें से ज्यादातर 50-100 एमएस में फिट हो गए। और यह दो मशीनों पर है - और वास्तव में, केवल एक गणना में शामिल था।

हमने यह सब देखा और कल्पना की कि UInt8 कॉलम के बजाय एक देश आईडी होगा, और Int8 कॉलम को डेटा द्वारा प्रतिस्थापित किया जाएगा, उदाहरण के लिए, उपयोगकर्ता की उम्र के बारे में। और उन्होंने महसूस किया कि ClickHouse हमारे लिए पूरी तरह से उपयुक्त है, अगर सब कुछ सही ढंग से किया जाए।

मजबूत डेटा टाइपिंग

ClickHouse का लाभ ठीक तब शुरू होता है जब सही डेटा स्कीमा बनता है। उदाहरण: प्लेटफ़ॉर्म स्ट्रिंग - ख़राब, प्लेटफ़ॉर्म Int8 + डिक्शनरी - अच्छा, लोकार्डिनैलिटी (स्ट्रिंग) - सुविधाजनक और अच्छा (मैं थोड़ी देर बाद लोकार्डिनालिटी के बारे में बात करूँगा)।

हमने php में एक विशेष जनरेटर वर्ग बनाया, जो अनुरोध पर, ClickHouse में तालिकाओं के आधार पर घटनाओं पर रैपर कक्षाएं बनाता है, और लॉगिंग के लिए एक एकल प्रवेश बिंदु है। मैं उस योजना का उदाहरण बताऊंगा जो निकली:

1. विश्लेषक / डेटा इंजीनियर / डेवलपर प्रलेखन का वर्णन करता है: कौन से क्षेत्र, संभव मूल्य, घटनाओं को लॉग इन करने की आवश्यकता है।
2. पिछले पैराग्राफ से डेटा संरचना के अनुसार ClickHouse में एक तालिका बनाई जाती है।
3. एक टेबल पर आधारित घटनाओं के लिए रैपिंग कक्षाएं उत्पन्न होती हैं।
4. उत्पाद टीम इस वर्ग के ऑब्जेक्ट के फ़ील्ड्स को भरती है, भेजती है।

योजना को php स्तर पर परिवर्तित करना और लॉगहाउस में तालिका को पहली बार बदले बिना लॉग डेटा का प्रकार काम नहीं करेगा। और यह, बदले में, टीम के साथ समन्वय के बिना, प्रलेखन में बदलाव और घटनाओं के विवरण के बिना नहीं किया जा सकता है।

प्रत्येक ईवेंट के लिए, आप दो सेटिंग सेट कर सकते हैं जो क्रमशः ClickHouse और hadoop पर भेजी गई घटनाओं के प्रतिशत को नियंत्रित करती हैं। मुख्य रूप से क्रमिक रोलिंग के लिए सेटिंग्स की आवश्यकता होती है अगर कुछ गलत हो जाता है तो लॉगिंग को काटने की क्षमता के साथ। हडूप से पहले, काफ्का का उपयोग करके मानक तरीके से डेटा वितरित किया जाता है। और ClickHouse में, वे लगातार मोड में KittenHouse के साथ एक योजना के माध्यम से उड़ान भरते हैं , जो कम से कम एकल ईवेंट डिलीवरी की गारंटी देता है।

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

denormalizing

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

कुल में, प्रत्येक तालिका में हमारे पास 50 से 200 कॉलम हैं, जबकि सभी तालिकाओं में सेवा क्षेत्र हैं। उदाहरण के लिए, त्रुटि लॉग error_log है - वास्तव में, हम त्रुटि को प्रकार की सीमा से बाहर कहते हैं। मामले में अजीब मान उम्र के साथ क्षेत्र में आकार के परे जाते हैं।

लो-कार्डिनैलिटी (T) टाइप करें

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

 dictGetString('os', 'os_name', toUInt64(os_id)) 

लेकिन एक और अधिक सुविधाजनक तरीका है - निम्न प्रकार का उपयोग करने के लिए LowCardinality (स्ट्रिंग), जो स्वचालित रूप से एक शब्दकोश बनाता है। मूल्यों के सेट की कम कार्डिनैलिटी की स्थिति के तहत LowCardinality के साथ प्रदर्शन स्ट्रिंग के साथ मौलिक रूप से अधिक है।

उदाहरण के लिए, हम ईवेंट प्रकार 'प्ले', 'पॉज़', 'रिवाइंड' के लिए लो-कार्डिनैलिटी (स्ट्रिंग) का उपयोग करते हैं। या मंच के लिए: 'वेब', 'एंड्रॉइड', 'आईफोन':

 SELECT vk_platform, count() FROM t WHERE dt = yesterday() GROUP BY vk_platform Elapsed: 0.145 sec. Processed 1.98 billion rows, 5.96 GB (13.65 billion rows/s., 41.04 GB/s.) 

सुविधा अभी भी प्रयोगात्मक है, इसलिए इसका उपयोग करने के लिए आपको प्रदर्शन करना होगा:

 SET allow_experimental_low_cardinality_type = 1; 

लेकिन एक एहसास है कि कुछ समय के बाद वह सेटिंग में नहीं रहेगी।

VKontakte डेटा एकत्रीकरण

चूंकि बहुत सारे कॉलम हैं, और बहुत सारी घटनाएं हैं, इसलिए प्राकृतिक इच्छा "पुराने" विभाजन को काटने की है, लेकिन पहले - इकाइयों को इकट्ठा करने के लिए। कभी-कभी, कच्ची घटनाओं (एक महीने या एक साल पहले) का विश्लेषण करना आवश्यक है, इसलिए हम एचडीएफएस में डेटा में कटौती नहीं करते हैं - कोई भी विश्लेषक किसी भी तारीख के लिए वांछित लकड़ी की छत से संपर्क कर सकता है।

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

दिनांक, user_id द्वारा एकत्रीकरण

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

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

मैं एक उदाहरण के साथ बताऊंगा:



एकत्रीकरण के बाद (दाईं ओर कई और कॉलम):



इस मामले में, एकत्रीकरण ठीक इसी प्रकार होता है (dt, user_id)। उपयोगकर्ता जानकारी वाले क्षेत्रों के लिए, इस तरह के एकत्रीकरण के साथ, आप किसी भी, किसी भी कार्य का उपयोग कर सकते हैं। उदाहरण के लिए, आप किसी भी हाइवे (प्लेटफ़ॉर्म) को एकत्र कर सकते हैं, यह जानने के लिए कि उपयोगकर्ता किस प्लेटफ़ॉर्म पर वीडियो इवेंट के लिए सबसे अधिक उपयोग कर रहा है। यदि वांछित है, तो आप groupUniqArray (प्लेटफॉर्म) का उपयोग कर सकते हैं और उन सभी प्लेटफार्मों की एक सरणी स्टोर कर सकते हैं, जिनसे उपयोगकर्ता ने घटना को उठाया था। यदि यह पर्याप्त नहीं है, तो आप प्लेटफ़ॉर्म और स्टोर के लिए अलग-अलग कॉलम बना सकते हैं, उदाहरण के लिए, विशिष्ट प्लेटफ़ॉर्म से आधे पर दिखाए गए अद्वितीय वीडियो की संख्या:

 uniqCombinedIf(cityHash64(video_owner_id, video_id), (platform = 'android') AND (event = '50p')) as uniq_videos_50p_android 

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

यह पता चलता है कि किसी सेवा के DAU की गणना करने के लिए, इसके कुल के शीर्ष पर इस तरह के अनुरोध को निष्पादित करने के लिए पर्याप्त है:

 SELECT dt, count() as DAU FROM agg GROUP BY dt Elapsed: 0.078 sec. 

या गणना करें कि उपयोगकर्ता सप्ताह के कितने दिन सेवा में थे:

 SELECT days_in_service, count() AS uniques FROM ( SELECT uniqUpTo(7)(dt) AS days_in_service FROM agg2 WHERE dt > (yesterday() - 7) GROUP BY user_id ) GROUP BY days_in_service ORDER BY days_in_service ASC 7 rows in set. Elapsed: 2.922 sec. 

हम नमूने में तेजी ला सकते हैं, जबकि लगभग सटीकता खोए बिना:

 SELECT days_in_service, 10 * count() AS uniques FROM ( SELECT uniqUpTo(7)(dt) AS days_in_service FROM agg2 SAMPLE 1 / 10 WHERE dt > (yesterday() - 7) GROUP BY user_id ) GROUP BY days_in_service ORDER BY days_in_service ASC 7 rows in set. Elapsed: 0.454 sec. 

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

या 1/100 नमूने के साथ 4 सप्ताह के लिए समान - लगभग 1% कम सटीक परिणाम प्राप्त होते हैं।

 SELECT days_in_service, 100 * count() AS uniques FROM ( SELECT uniqUpTo(7)(dt) AS days_in_service FROM agg2 SAMPLE 1 / 100 WHERE dt > (yesterday() - 28) GROUP BY user_id ) GROUP BY days_in_service ORDER BY days_in_service ASC 28 rows in set. Elapsed: 0.287 sec. 

दूसरी ओर एकत्रीकरण

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

 SELECT starts FROM agg3 WHERE (dt = yesterday()) AND (video_id = ...) AND (video_owner_id = ...) 1 rows in set. Elapsed: 0.030 sec 

या कल शीर्ष 10 वीडियो दृश्य:

 SELECT video_id, video_owner_id, watches FROM video_agg_video_d1 WHERE dt = yesterday() ORDER BY watches DESC LIMIT 10 10 rows in set. Elapsed: 0.035 sec. 

नतीजतन, हमारे पास फॉर्म के समुच्चय की एक योजना है:

• उत्पाद के भीतर "तिथि, उपयोगकर्ता" द्वारा एकत्रीकरण;
• उत्पाद के भीतर "तारीख, बातचीत का उद्देश्य" द्वारा एकत्रीकरण;
• कभी-कभी अन्य अनुमान उत्पन्न होते हैं।

अज़कबन और टीमसिटी

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

अगला कदम समुच्चय का निर्माण है। ये बैश स्क्रिप्ट हैं जिसमें निम्नलिखित होते हैं:

• पहले हम शार्प की संख्या और शार्द से कुछ होस्ट प्राप्त करते हैं:
  
  

   SELECT shard_num, any(host_name) AS host FROM system.clusters GROUP BY shard_num 

• तब स्क्रिप्ट प्रत्येक शार्द के लिए क्रमिक रूप से निष्पादित होती है (क्लिकहाउस-क्लाइंट -एच $ होस्ट) फॉर्म का अनुरोध (उपयोगकर्ताओं द्वारा कुल के लिए):
  
  

   INSERT INTO ... SELECT ... FROM ... SAMPLE 1/$shards_count OFFSET 1/$shard_num 

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

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

कुल समय को घटनाओं में परिवर्तित करने में खर्च होने वाला कुल समय 15 मिनट है।

परीक्षण

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

तकनीकी रूप से, ये JUnit का उपयोग करके और ClickHouse के लिए jdbc ड्राइवर को लागू करने वाली साधारण इकाई परीक्षण हैं। सभी परीक्षणों के रन को टीमसिटी में लॉन्च किया जाता है और 1 धागे में लगभग 30 सेकंड लगते हैं, और विफलताओं के मामले में हमें अपने अद्भुत टीमसिटी बॉट से VKontakte सूचनाएं मिलती हैं।

निष्कर्ष

ClickHouse के केवल स्थिर संस्करणों का उपयोग करें और आपके बाल नरम और रेशमी होंगे। यह जोड़ने योग्य है कि ClickHouse धीमा नहीं करता है ।