मिथकों और बिग डेटा के बारे में किंवदंतियों

पायलट कार्यों के लिए हमारे समूहों में से एक (डेटा नोड: 18 सर्वर / 2 सीपीयू, 12 कोर, 64 जीबी रैम /, 12 डिस्क, 3 टीबी, एसएटीए - एचपी DL380g)

- बिग डेटा सामान्य रूप से क्या है?
हर कोई जानता है कि यह बड़ी मात्रा में डेटा संसाधित कर रहा है। लेकिन, उदाहरण के लिए, 20 गीगाबाइट्स या 4 पेटाबाइट्स के ओरेकल डेटाबेस के साथ काम करना बिग डेटा अभी तक नहीं है, यह सिर्फ एक हाईलोड डेटाबेस है।

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

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

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

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

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

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

"लेकिन यह राक्षसी रूप से धीमा है, है ना?"
हमेशा नहीं। दो परिस्थितियाँ हैं जहाँ यह तुलना करने के लिए समझ में आता है:

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

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

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

- फिर, सम्मेलनों में हर कोई बिग डेटा के बारे में बात क्यों करता है?
क्योंकि प्रवृत्ति फैशनेबल है, पत्रकारों को प्यार करता है। यहां तक ​​कि अगर आप ऑनलाइन स्टोर के 50 हजार रिकॉर्ड की प्रक्रिया करते हैं और इसे बिग डेटा कहते हैं, तो यह एक प्रेस विज्ञप्ति में लिखने के लिए पर्याप्त होगा।

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

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

- प्लेटफॉर्म की संरचना क्या है?

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

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

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

मुझे लगता है कि आप यह जानना चाहते होंगे कि हम निम्न स्तर पर डेटा के साथ कैसे काम करते हैं, या हार्डवेयर के बारे में सुनते हैं। यदि विषय दिलचस्प है - लिखें।