डेटा प्रतिकृति। Attunity Replिकेट और Greenplum

इस लेख में, मैं DWH के निर्माण में TCS बैंक द्वारा उपयोग की जाने वाली तकनीकों का वर्णन जारी रखना चाहूंगा। यह आलेख उन लोगों के लिए रुचि का हो सकता है जो ग्रीनप्लम डीबीएमएस के आधार पर बनाए गए ऑनलाइन स्टोरेज लोकेशन के लिए ऑपरेशनल सोर्स से डेटा को दोहराने के लिए लॉगइनिंग चेंज डेटा कैप्चर (सीडीसी) का उपयोग करने की योजना बनाते हैं।

प्रवेश के बदले।

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

प्रतिकृति के लिए आवश्यक बैंक के स्रोत सिस्टम के लिए सारांश संकेतक

बैंक में DWH को ग्रीनप्लम DBMS के आधार पर बनाया गया है, प्रतिकृति के लिए आवश्यक सभी डेटा स्रोत Oracle DBMS द्वारा प्रबंधित किए जाते हैं। प्रतिकृति स्रोतों के सारांश संकेतक तालिका में दिए गए हैं:

पैरामीटर	मूल्य
प्रतिकृति के लिए स्रोत प्रणालियों की संख्या	5
प्रतिकृति तालिकाओं की संख्या	~ २००
लेनदेन लॉग की मात्रा (जीबी / घंटा)
कम से कम	10
अधिकतम	160
औसत	~ 40
प्रति दिन संचालन की कुल संख्या	~ 50 मिलियन

तैयार समाधानों के लिए खोजें।

CDC समाधान के रूप में, हमने निम्नलिखित उत्पादों पर विचार किया:

• ओरेकल गोल्डन गेट। एक उत्पाद वर्तमान में ओरेकल द्वारा विकसित और बनाए रखा गया है। एक अद्भुत उत्पाद, जैसा कि यह हमें लगता था, स्रोत प्रणालियों से परिवर्तनों को पढ़ने की स्थिरता और प्रदर्शन के संदर्भ में। हालांकि, गोल्डन गेट के नुकसान में यह तथ्य शामिल है कि यह ग्रीनप्लाम बॉक्स से बाहर का समर्थन नहीं करता है, प्रारंभिक डेटा लोडिंग के कोई अंतर्निहित साधन नहीं हैं
  
• Informatica Data Replicator। ओरेकल को सोर्स के रूप में सपोर्ट करने वाले और ग्रीनप्लम को रिसीवर के रूप में सपोर्ट करने वाले प्रॉडक्ट में शुरुआती डेटा लोडिंग टूल्स हैं। उत्पाद स्रोत और रिसीवर के बीच डेटा अखंडता की गारंटी देता है, हालांकि, इसके लिए प्रतिकृति के प्रारंभ के समय खुले सभी लेनदेन के लिए लेन-देन लॉग की उपलब्धता की आवश्यकता होती है, जो लेन-देन लॉग के लिए डिस्क स्टोरेज सिस्टम की मात्रा पर सीमाओं के मद्देनजर हमेशा स्वीकार्य नहीं है
  
• Attunity प्रतिकृति ओरेकल को एक स्रोत के रूप में और ग्रीनप्लम को एक रिसीवर के रूप में सपोर्ट करने वाले नए उत्पाद, इन्फॉर्मेटाटा डेटा रेप्लिकेटर की तरह, प्रारंभिक डेटा लोडिंग के लिए उपकरण हैं। समाधान में एक सरल नियंत्रण प्रणाली है, जिसका उद्देश्य आउट-ऑफ-द-बॉक्स काम करना है
  

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

उत्पादन में परियोजना शुरू

इसलिए, हमने उत्पाद Attunity Replicate चुना है। यह एकमात्र ऐसा उत्पाद है जो हमारे पायलट प्रोजेक्ट की सभी आवश्यकताओं को पूरा करता है। परिचय के समय, संस्करण 2.0 प्रासंगिक था।
इस संस्करण में, परिवर्तनों को लागू करने के लिए एकमात्र तरीका लागू किया गया था - पंक्ति-दर-पंक्ति, जिसमें स्रोत पर प्रत्येक परिवर्तन रिसीवर पर एक स्वतंत्र SQL क्वेरी के रूप में लागू किया गया था:

update target set f1='a', f2='b', f3='c' where key='key1' 

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

 update target set f1 = decode(net.f1, null, target.f1, '<ATT_NULL>', null, net.f1) ,f2 = decode(net.f2, null, target.f2, '<ATT_NULL>', null, net.f2) ,... from net where target.key=net.key 

यहाँ नेट वह सारणी है, जिसमें परिवर्तन की गणना पुनर्मिलन द्वारा "गणना" की जाती है। इस परिशोधन के क्रियान्वयन के परिणामस्वरूप, रिसीवर के आधार पर प्रश्नों की संख्या में तेजी से कमी आई है और हम अब अपने स्रोतों से होने वाले परिवर्तनों की पूरी मात्रा को संसाधित करने में सक्षम हैं। इस तकनीक को एट्यूनिटी टर्बो स्ट्रीम सीडीसी तकनीक कहा जाता था और यह पूरी तरह से न्यायसंगत है: स्रोत डेटा पर औसत भार के साथ ग्रीनप्लम में औसतन 60-80 सेकंड की देरी होती है। बेशक, समस्याएं हैं। स्रोत पर एक पीक लोड के साथ (उदाहरण के लिए, जब ट्रेडिंग दिन को बंद करते हुए), देरी बढ़ जाती है, कभी-कभी काफी, 1.5 घंटे तक। इसका कारण इस तथ्य में निहित है कि Attunity प्रतिकृति लॉगमैन के माध्यम से काम करती है, जो हमेशा पीक लोड के दौरान डेटाबेस लॉग को संसाधित करने का प्रबंधन नहीं करती है।
परिवर्तनों को लागू करने की प्रक्रिया में, तथाकथित लागू संघर्ष संभव हैं - रिसीवर में परिवर्तन लागू करने का टकराव। सबसे आम हैं: 0 पंक्तियाँ प्रभावित (कोई रिकॉर्ड रिसीवर पर अपडेट नहीं किया गया था) और डुप्लिकेट कीज़ (रिसीवर में पहले से मौजूद रिकॉर्ड को सम्मिलित करते हुए)। सिस्टम के सामान्य संचालन के दौरान, ये टकराव प्रारंभिक लोडिंग पर संभव है, क्योंकि रिसीवर में डेटा की स्थिरता सुनिश्चित करने के लिए, पुनरावृत्ति एक पूर्ण अपलोड की तुलना में थोड़ी देर पहले डेटा में परिवर्तन कैप्चर करना शुरू करता है। Attuity Replicate ऐसे संघर्षों और स्विचों को पंक्ति-दर-पंक्ति मोड में बदल देता है, उन्हें आगे के विश्लेषण के लिए एक विशेष सिस्टम टेबल में संग्रहीत करता है।

LogMiner पर काम करें।

सीडीसी समाधान एक स्रोत के लेनदेन लॉग को पढ़ने के लिए दो अलग-अलग तंत्रों का उपयोग कर सकते हैं: स्वयं का तंत्र (बाइनरी रीडर) और स्वयं डीबीएमएस स्रोत का तंत्र। Oracle के मामले में, यह Oracle LogMiner है, जो डेटा को दो मोड में लौटा सकता है:

• कमिटेड डेटा (केवल आरंभ किए गए लेनदेन के लिए DML लौटाता है)
• कच्चा डेटा (सभी लेनदेन के बारे में डेटा लौटाता है)

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

परियोजना की वर्तमान स्थिति

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

एक निष्कर्ष के बजाय

यह लेख हमारे बैंक में DWH प्रौद्योगिकियों को कवर करने के तरीके पर दूसरा कदम है। अहेड ऑनलाइन-वेयरहाउस के बारे में एक कहानी है (जिसका आधार, जैसा कि आप अनुमान लगा सकते हैं, सीडीसी लॉग खनन था) और बहुत कुछ।