Odnoklassniki पर बीआई: डीडब्ल्यूएच को डेटा संग्रह और वितरण

पिछली बार (http://habrahabr.ru/company/odnoklassniki/blog/149391/) हमने ग्राफ़ और डेस्क की एक प्रणाली के बारे में बात की थी जिसका उपयोग हम साइट और उपयोगकर्ता गतिविधि की निगरानी के लिए करते हैं। हमें प्रति दिन दो ट्रिलियन (2,000,000,000,000) से अधिक घटनाओं को लॉग इन करना होगा। इस पोस्ट में, हम वर्णन करेंगे कि हम इस डेटा को कैसे इकट्ठा करते हैं, इसे प्रोसेस करते हैं और इसे रिपॉजिटरी में अपलोड करते हैं।

डेटा की प्रकृति

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

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

लकड़हारा

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

एकत्रीकरण के परिणामस्वरूप, हम डेटा को 1000 बार संपीड़ित करते हैं - भीड़ के घंटे में 5 मिनट में 20 बिलियन रिकॉर्ड के बजाय, हमें केवल 20 मिलियन रिकॉर्ड मिलते हैं। यह है, इसे हल्के ढंग से लगाने के लिए, एक बहुत बड़ा अंतर।

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

आइए दोनों दृष्टिकोणों की तुलना करें। औसत लिखने की लंबाई 200 बाइट्स है।
1) गैर-एकत्रित डेटा
डेटा की मात्रा प्रति सेकंड - 20,000,000,000 (रिकॉर्ड) * 200 (बाइट्स) / 120 सेकंड = 33 जीबी / सेकंड
प्रति दिन डेटा की राशि - 2,000,000,000,000 (रिकॉर्ड) * 200 (बाइट्स) = 400 टीबी / दिन
2) एकत्र डेटा
डेटा मात्रा प्रति सेकंड - 20,000,000 (रिकॉर्ड) * 200 (बाइट्स) / 120 सेकंड = 33 एमबी / सेकंड
प्रति दिन डेटा की राशि - 2,000,000,000 (रिकॉर्ड) * 200 (बाइट्स) = 400 जीबी / दिन

यदि हमने डेटा एकत्र नहीं किया है, तो केवल आँकड़ों के लिए हमें 33 GB * 8 = 264 Gb / s नेटवर्क क्षमता की आवश्यकता होगी।

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

इंटरमीडिएट डेटा वेयरहाउस: एवोल्यूशन

यदि कोई मध्यवर्ती भंडारण नहीं था, तो DWH सर्वर का हिस्सा 4000 समानांतर सत्र होगा जो 33 एमबी प्रति सेकंड की गति से डेटा लिखेंगे। इस तरह के भार के समानांतर, कोई भी डेटा प्रोसेसिंग असंभव होगा।

मध्यवर्ती डेटा वेयरहाउस का कार्य:
1) 4000 लकड़हारा अनुप्रयोगों से प्राप्त डेटा को जल्दी से बचाएं;
2) डीडब्ल्यूएच सर्वर को जल्दी से ताजा डेटा दे;
3) DWH पर अपलोड होने के बाद पुराने डेटा को जल्दी से हटा दें।

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

2008 साल

2008 में, हमारे पास अभी तक DWH नहीं था, लेकिन 300 सर्वर थे जिन्होंने 20 टेबल के साथ एक डेटाबेस में अपना लॉग लिखा था। एक ही डेटाबेस में सीधे डेटा तक पहुंचकर एक अलग एप्लिकेशन उत्पन्न ग्राफिक्स। प्रत्येक तालिका में एक निश्चित अवधि में तेजी से पढ़ने को सुनिश्चित करने के लिए तारीख और समय के अनुसार एक क्लस्टर सूचकांक था।

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

2009 साल

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

हमने दिनांक और समय के अनुसार डेटा को अनलोड करने के लिए फ़िल्टर किया। उसी समय, एक ही समय में बहुत सारे डेटा थे, और वे अतुल्यकालिक रूप से दिखाई दिए। मुझे "सुरक्षा के बड़े मार्जिन" के साथ डेटा अपलोड करना था। इसलिए, हमने प्रत्येक तालिका में ऑटो-इंक्रीमेंट के साथ एक बिगिंट आईडी कॉलम जोड़ा और इस कॉलम पर एक इंडेक्स बनाया। उसके बाद, हम पहले से ही एक बार केवल एक रिकॉर्ड अनलोड कर सकते थे।

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

2010 का साल

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

हम यह देखने और ट्रिगर का उपयोग करने में सक्षम थे।



प्रत्येक तालिका के लिए एक समान जोड़ी बनाई गई थी और इसे नाम दिया गया, जिसमें अंत _1 और _2 को जोड़ा गया। मूल तालिका के समान नाम के साथ एक दृश्य बनाया गया। सर्वर इस दृश्य को लिखते हैं। हमने दृश्य में सम्मिलित ट्रिगर के बजाय जोड़ा, जो एक सप्ताह के लिए _1 के अंत के साथ तालिका में लिखता है, और दूसरे सप्ताह के अंत तक तालिका के साथ _2 है।

स्विचिंग दो चरणों में होती है। सबसे पहले, केवल ट्रिगर स्विच किया जाता है, और दृश्य स्वयं पिछली तालिका से डेटा पढ़ता है। DWH ने पिछली तालिका से सभी डेटा डाउनलोड करने के बाद, दृश्य स्विच किया।

उसके बाद, पुरानी टेबलों के डेटा को प्रभावी रूप से ट्रंकट टेबल कमांड से हटा दिया जाता है।

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

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

2011 वर्ष

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

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

2012 साल

डिस्क कतार MS SQL लॉग मैनेजर द्वारा बनाई गई थी, जो डेटाबेस लॉग फ़ाइल के साथ काम करती है। उस समय, हमारे पास MS SQL 2005 मानक संस्करण डेटाबेस था। विशेषज्ञों ने दावा किया कि MS SQL 2008 लॉग मैनेजर MS SQL 2005 की तुलना में बेहतर परिमाण का एक क्रम है। हमने इसे जाँचने और MS SQL 2008 एंटरप्राइज़ संस्करण पर स्विच करने का निर्णय लिया। डिस्क कतार वास्तव में परिमाण के एक क्रम से कम हो गई!

उसी समय, हमने डेटा को हटाने के लिए विभाजन तालिका का उपयोग करने का निर्णय लिया। यही है, वे 2009 के मॉडल पर लौट आए, लेकिन आईडी द्वारा केवल क्लस्टर इंडेक्स को 20 मिलियन रिकॉर्ड के विभाजन में विभाजित किया गया था। विभाजन 100% पूर्ण होने के बाद और सभी DWH सर्वर ने डेटा डाउनलोड किया है, ये विभाजन हटा दिए गए हैं।

SQL सर्वर में विभाजन डेवलपर्स के लिए "अदृश्य" हैं, और यह समाधान कोड को जटिल नहीं करता है। विभाजन हटाना और जोड़ना ऑनलाइन होता है, कनेक्शन और डेटा का नुकसान नहीं होता है।

परिणाम निम्नलिखित वास्तुकला है:



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

प्रारंभ में, हमारे पास ऐसा एक आधार था, लेकिन अब हमारे पास उनमें से कई हैं। कारण इस प्रकार है:
1) प्रत्येक बड़ी होस्टिंग में एक लॉग डेटाबेस होना चाहिए, ताकि समस्याओं की मेजबानी करते समय हम सभी आँकड़े खो न दें;
2) लॉग्स डेटाबेस कार्य के साथ सामना करने के लिए संघर्ष करता है क्योंकि डेटा की मात्रा बढ़ जाती है।

मध्यवर्ती डेटा वेयरहाउस से डेटा को लोड करना

लॉग डेटाबेस के लेखन के साथ समानांतर में, डेटा उन्हें DWH डेटाबेस से पंप किया जाता है।



एक एकल थ्रेड में एक DWH सर्वर सभी लॉग डेटाबेस में प्रत्येक तालिका का सर्वेक्षण करता है और पिछले पंपिंग के बाद दिखाई देने वाले सभी नए रिकॉर्डों को पंप करता है।

आइए गणना करें कि 5 मिनट के भीतर डेटा अपलोड कितनी तेजी से होना चाहिए। प्रदूषित तालिकाओं की संख्या 300 * 4 = 1200 है। यह पता चलता है कि औसतन 300/1200 = 0.25 सेकंड एक तालिका को आवंटित किए जाते हैं। क्या होगा अगर औसत तालिका में अधिक समय लगता है? स्केल! हम एक और DWH सर्वर डालते हैं और एक सर्वर पर आधे टेबल और दूसरे सर्वर पर अपलोड करते हैं।



यदि अधिक टेबल या डेटा हैं और फिर से 2 मिनट के भीतर रखना असंभव है, तो हम एक और DWH सर्वर डालते हैं, आदि। अब हमारे पास 3 ऐसे DWH सर्वर हैं।

अगले लेख में

अगले लेख में, हम इस बारे में बात करेंगे कि हमने DWH सर्वर में डेटा लोडिंग का निर्माण कैसे किया, और प्रति टेबल औसतन 0.25 सेकंड का खर्च क्या है।