डेटा साइलो की समस्या ऑनलाइन व्यवसायों के लिए गठिया की तरह है क्योंकि उम्र बढ़ने के साथ लगभग हर किसी को यह समस्या हो जाती है। व्यवसाय वेबसाइटों, मोबाइल ऐप्स, H5 पेजों और अंतिम उपकरणों के माध्यम से ग्राहकों के साथ बातचीत करते हैं। किसी न किसी कारण से, इन सभी स्रोतों से डेटा को एकीकृत करना मुश्किल है। डेटा वहीं रहता है जहां वह है और आगे के विश्लेषण के लिए उसे आपस में जोड़ा नहीं जा सकता है। इस तरह डेटा साइलो बनता है। आपका व्यवसाय जितना बड़ा होगा, आपके पास उतने अधिक विविध ग्राहक डेटा स्रोत होंगे और उतनी ही अधिक संभावना होगी कि आप डेटा साइलो में फंस जाएंगे। जिस बीमा कंपनी के बारे में मैं इस पोस्ट में बात करने जा रहा हूं, उसके साथ बिल्कुल ऐसा ही होता है। 2023 तक, वे पहले ही 500 मिलियन से अधिक ग्राहकों को सेवा दे चुके हैं और 57 बिलियन बीमा अनुबंधों पर हस्ताक्षर कर चुके हैं। जब उन्होंने ऐसे डेटा आकार को समायोजित करने के लिए एक ग्राहक डेटा प्लेटफ़ॉर्म (सीडीपी) बनाना शुरू किया, तो उन्होंने कई घटकों का उपयोग किया। सीडीपी में डेटा साइलो अधिकांश डेटा प्लेटफ़ॉर्म की तरह, उनके सीडीपी 1.0 में एक बैच प्रोसेसिंग पाइपलाइन और एक वास्तविक समय स्ट्रीमिंग पाइपलाइन थी। ऑफ़लाइन डेटा को स्पार्क जॉब्स के माध्यम से इम्पाला में लोड किया गया था, जहां इसे टैग किया गया और समूहों में विभाजित किया गया। इस बीच, स्पार्क ने इसे वनआईडी गणना के लिए नेबुलाग्राफ को भी भेजा (इस पोस्ट में बाद में विस्तार से बताया गया है)। दूसरी ओर, वास्तविक समय डेटा को फ़्लिंक द्वारा टैग किया गया था और फिर HBase में संग्रहीत किया गया था, जो पूछताछ के लिए तैयार था। इससे सीडीपी में एक घटक-भारी संगणना परत बन गई: इम्पाला, स्पार्क, नेबुलाग्राफ और एचबेस। परिणामस्वरूप, ऑफ़लाइन टैग, रीयल-टाइम टैग और ग्राफ़ डेटा कई घटकों में बिखरे हुए थे। अनावश्यक भंडारण और भारी डेटा स्थानांतरण के कारण आगे की डेटा सेवाओं के लिए उन्हें एकीकृत करना महंगा था। इसके अलावा, भंडारण में विसंगतियों के कारण, उन्हें सीडीएच क्लस्टर और नेबुलाग्राफ क्लस्टर के आकार का विस्तार करना पड़ा, जिससे संसाधन और रखरखाव की लागत बढ़ गई। अपाचे डोरिस-आधारित सीडीपी सीडीपी 2.0 के लिए, उन्होंने गंदगी को साफ करने के लिए एक एकीकृत समाधान पेश करने का निर्णय लिया। सीडीपी 2.0 की गणना परत पर, वास्तविक समय और ऑफ़लाइन डेटा भंडारण और गणना दोनों करता है। अपाचे डोरिस प्राप्त करने के लिए, वे विधि का उपयोग करते हैं। उनके 30-थ्रेड अंतर्ग्रहण परीक्षण से पता चलता है कि यह प्रति सेकंड 300,000 से अधिक अप्सर्ट निष्पादित कर सकता है। लोड करने के लिए, वे और स्ट्रीम लोड के संयोजन का उपयोग करते हैं। इसके अलावा, वास्तविक समय रिपोर्टिंग में, जहां उन्हें कई बाहरी डेटा स्रोतों से डेटा निकालने की आवश्यकता होती है, वे के लिए सुविधा का लाभ उठाते हैं। ऑफ़लाइन डेटा स्ट्रीम लोड वास्तविक समय डेटा फ़्लिंक-डोरिस-कनेक्टर फ़ेडरेटेड प्रश्नों मल्टी-कैटलॉग इस सीडीपी पर ग्राहक विश्लेषणात्मक वर्कफ़्लो इस प्रकार है। सबसे पहले, वे ग्राहक जानकारी को छांटते हैं; फिर वे प्रत्येक ग्राहक को टैग संलग्न करते हैं। टैग के आधार पर, वे ग्राहकों को अधिक लक्षित विश्लेषण और संचालन के लिए समूहों में विभाजित करते हैं। इसके बाद, मैं इन कार्यभारों के बारे में विस्तार से बताऊंगा और आपको दिखाऊंगा कि अपाचे डोरिस उन्हें कैसे गति देता है। वनआईडी क्या आपके साथ कभी ऐसा हुआ है जब आपके उत्पादों और सेवाओं के लिए अलग-अलग उपयोगकर्ता पंजीकरण प्रणालियाँ हों? आप एक उत्पाद वेबपेज से यूजरआईडी ए का ईमेल और बाद में दूसरे से यूजरआईडी बी का सामाजिक सुरक्षा नंबर एकत्र कर सकते हैं। तब आपको पता चलता है कि यूजरआईडी ए और यूजरआईडी बी वास्तव में एक ही व्यक्ति के हैं क्योंकि वे एक ही फोन नंबर से चलते हैं। इसीलिए OneID एक विचार के रूप में सामने आता है। यह अपाचे डोरिस में सभी व्यावसायिक लाइनों की उपयोगकर्ता पंजीकरण जानकारी को एक बड़ी तालिका में एकत्रित करना, इसे क्रमबद्ध करना और यह सुनिश्चित करना है कि एक उपयोगकर्ता के पास एक अद्वितीय OneID है। इस प्रकार वे अपाचे डोरिस के कार्यों का लाभ उठाते हुए यह पता लगाते हैं कि कौन सी पंजीकरण जानकारी एक ही उपयोगकर्ता की है। टैगिंग सेवाएँ यह सीडीपी की जानकारी को समायोजित करता है, जो से आती है और कुल मिलाकर से जुड़ी होती है। 500 मिलियन ग्राहकों 500 से अधिक स्रोत तालिकाओं 2000 से अधिक टैग समयबद्धता के अनुसार, टैग को वास्तविक समय टैग और ऑफ़लाइन टैग में विभाजित किया जा सकता है। वास्तविक समय टैग की गणना अपाचे फ्लिंक द्वारा की जाती है और अपाचे डोरिस में फ्लैट तालिका में लिखी जाती है, जबकि ऑफ़लाइन टैग की गणना अपाचे डोरिस द्वारा की जाती है क्योंकि वे डोरिस में उपयोगकर्ता विशेषता तालिका, व्यवसाय तालिका और उपयोगकर्ता व्यवहार तालिका से प्राप्त होते हैं। डेटा टैगिंग में कंपनी की सर्वोत्तम पद्धति यहां दी गई है: 1. ऑफ़लाइन टैग: डेटा लेखन के चरम के दौरान, उनके विशाल डेटा पैमाने को देखते हुए, एक पूर्ण अपडेट आसानी से OOM त्रुटि का कारण बन सकता है। इससे बचने के लिए, वे अपाचे डोरिस के फ़ंक्शन का उपयोग करते हैं और सक्षम करते हैं। इससे मेमोरी खपत में काफी कमी आएगी और डेटा लोडिंग के दौरान सिस्टम स्थिरता बनी रहेगी। INSERT INTO SELECT आंशिक कॉलम अपडेट set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from ..... 2. वास्तविक समय टैग: वास्तविक समय टैग के लिए आंशिक कॉलम अपडेट भी उपलब्ध हैं क्योंकि वास्तविक समय टैग अलग-अलग गति से अपडेट किए जाते हैं। बस पर सेट करना है। partial_columns true curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load 3. उच्च-संगामिति बिंदु प्रश्न: अपने वर्तमान व्यवसाय आकार के साथ, कंपनी को 5000 क्यूपीएस से अधिक के समवर्ती स्तर पर टैग के लिए क्वेरी अनुरोध प्राप्त हो रहे हैं। वे उच्च प्रदर्शन की गारंटी के लिए रणनीतियों के संयोजन का उपयोग करते हैं। सबसे पहले, वे SQL के पूर्व-संकलन और पूर्व-निष्पादन के लिए एक अपनाते हैं। दूसरे, वे भंडारण और निष्पादन को अनुकूलित करने के लिए डोरिस बैकएंड और तालिकाओं के मापदंडों को ठीक करते हैं। अंत में, वे कॉलम-उन्मुख अपाचे डोरिस के पूरक के रूप में सक्षम करते हैं। तैयार कथन को पंक्ति कैश को में डोरिस बैकएंड पैरामीटर्स को फाइन-ट्यून करें: be.conf disable_storage_row_cache = false storage_page_cache_limit=40% तालिका निर्माण पर तालिका मापदंडों को ठीक करें: enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true 4. टैग गणना (जुड़ें): व्यवहार में, कई टैगिंग सेवाएँ डेटाबेस में मल्टी-टेबल जॉइन द्वारा कार्यान्वित की जाती हैं। इसमें अक्सर दस से अधिक टेबल शामिल होती हैं। इष्टतम गणना प्रदर्शन के लिए, वे डोरिस में रणनीति अपनाते हैं। सह-स्थान समूह ग्राहक समूहन सीडीपी 2.0 में ग्राहक समूहीकरण पाइपलाइन इस प्रकार है: अपाचे डोरिस ग्राहक सेवा से एसक्यूएल प्राप्त करता है, गणना निष्पादित करता है, और परिणाम सेट को SELECT INTO OUTFILE के माध्यम से S3 ऑब्जेक्ट स्टोरेज पर भेजता है। कंपनी ने अपने ग्राहकों को 10 लाख समूहों में बांटा है। ग्राहक समूहीकरण का कार्य, जिसे लगते थे, अब लगते हैं। इम्पाला में पूरा करने में पहले 50 सेकंड डोरिस में केवल 10 सेकंड अधिक सूक्ष्म विश्लेषण के लिए ग्राहकों को समूहीकृत करने के अलावा, कभी-कभी वे विपरीत दिशा में भी विश्लेषण करते हैं। यानी एक निश्चित ग्राहक को लक्षित करना और यह पता लगाना कि वह किस समूह से संबंधित है। इससे विश्लेषकों को ग्राहकों की विशेषताओं के साथ-साथ विभिन्न ग्राहक समूह कैसे ओवरलैप होते हैं, यह समझने में मदद मिलती है। अपाचे डोरिस में, इसे BITMAP फ़ंक्शंस द्वारा कार्यान्वित किया जाता है: यह जांचने का एक तेज़ तरीका है कि ग्राहक एक निश्चित समूह का हिस्सा है या नहीं, और , , और क्रॉस-विश्लेषण के लिए विकल्प हैं। BITMAP_CONTAINS BITMAP_OR BITMAP_INTERSECT BITMAP_XOR निष्कर्ष सीडीपी 1.0 से सीडीपी 2.0 तक, बीमा कंपनी स्पार्क+इम्पाला+एचबेस+नेबुलाग्राफ को बदलने के लिए एक एकीकृत डेटा वेयरहाउस अपाचे डोरिस को अपनाती है। यह डेटा साइलो को तोड़कर और डेटा प्रोसेसिंग पाइपलाइनों को सुव्यवस्थित करके उनकी डेटा प्रोसेसिंग दक्षता को बढ़ाता है। आने वाले सीडीपी 3.0 में, वे अधिक विविध और लचीले विश्लेषण के लिए रीयल-टाइम टैग और ऑफ़लाइन टैग को मिलाकर अपने ग्राहकों को समूहित करना चाहते हैं। और टीम इस अपग्रेड के दौरान सहायक भागीदार बने रहेंगे। अपाचे डोरिस समुदाय वेलोडीबी भी प्रकाशित किया गया है. यहाँ
