डेल्टा: डेटा सिंक्रोनाइज़ेशन और संवर्धन प्लेटफ़ॉर्म

दर पर एक नए प्रवाह के शुभारंभ की प्रत्याशा में डाटा इंजीनियर रोचक सामग्री का अनुवाद तैयार किया।

Обзор

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

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

इन समस्याओं के समाधान के लिए डेल्टा का विकास किया गया। डेल्टा अंततः डेटा सिंक्रनाइज़ेशन और संवर्धन के लिए एक सुसंगत, घटना-संचालित मंच प्रदान करता है।

मौजूदा समाधान

दोहरी प्रविष्टि

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

समस्याओं:

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

लॉग तालिका बदलें

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

समस्याओं:

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

एक अन्य समस्या उन प्रणालियों में स्कीमा परिवर्तन प्राप्त करने में है जो लेनदेन संबंधी स्कीमा परिवर्तनों का समर्थन नहीं करते हैं [1][2], जैसे कि MySQL। इसलिए, परिवर्तन करने का पैटर्न (उदाहरण के लिए, एक स्कीमा परिवर्तन) और लेनदेन को परिवर्तन लॉग तालिका में रिकॉर्ड करना हमेशा काम नहीं करेगा।

वितरित लेनदेन

वितरित लेनदेन का उपयोग कई विषम डेटा स्टोरों में लेनदेन को विभाजित करने के लिए किया जा सकता है ताकि ऑपरेशन या तो उपयोग किए गए सभी डेटा स्टोरों के लिए प्रतिबद्ध हो, या उनमें से किसी के लिए प्रतिबद्ध न हो।

समस्याओं:

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

डेल्टा

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

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

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

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

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

सीडीसी (चेंज-डेटा-कैप्चर)

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

डेल्टा-कनेक्टर कई अतिरिक्त सुविधाओं का समर्थन करता है जैसे:

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

वर्तमान में हम MySQL और Postgres का समर्थन करते हैं, जिसमें AWS RDS और ऑरोरा पर तैनाती भी शामिल है। हम कैसेंड्रा (मल्टी-मास्टर) का भी समर्थन करते हैं। आप डेल्टा-कनेक्टर के बारे में अधिक विवरण यहां पा सकते हैं ब्लॉग.

काफ्का और परिवहन परत

डेल्टा की इवेंट ट्रांसपोर्ट परत प्लेटफ़ॉर्म की मैसेजिंग सेवा पर बनाई गई है प्रधान सिद्धांत.

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

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

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

हमने भी बढ़ाया प्रतिकृति कारक 2 से 3 तक और न्यूनतम इनसिंक प्रतिकृतियां 1 से 2. इस क्लस्टर पर लिखने वाले प्रकाशकों को अन्य सभी से सहायता की आवश्यकता होती है, यह सुनिश्चित करते हुए कि 2 में से 3 प्रतिकृतियों में प्रकाशक द्वारा भेजे गए सबसे नवीनतम संदेश हैं।

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

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

स्ट्रीम प्रोसेसिंग फ्रेमवर्क

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

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

चित्र 3. डेल्टा में डीएसएल पर संवर्धन का उदाहरण

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

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

चित्र 4. डेल्टा स्ट्रीम प्रोसेसिंग फ्रेमवर्क आर्किटेक्चर

इस दृष्टिकोण के कई फायदे हैं:

• उपयोगकर्ता फ़्लिंक या SPaaS संरचना की बारीकियों में जाने के बिना अपने व्यावसायिक तर्क पर ध्यान केंद्रित कर सकते हैं।
• अनुकूलन ऐसे तरीके से किया जा सकता है जो उपयोगकर्ताओं के लिए पारदर्शी हो, और उपयोगकर्ता कोड (यूडीएफ) में किसी भी बदलाव की आवश्यकता के बिना त्रुटियों को ठीक किया जा सकता है।
• डेल्टा एप्लिकेशन अनुभव उपयोगकर्ताओं के लिए सरल है क्योंकि प्लेटफ़ॉर्म बॉक्स से बाहर लचीलापन और लचीलापन प्रदान करता है और विभिन्न प्रकार के विस्तृत मेट्रिक्स एकत्र करता है जिनका उपयोग अलर्ट के लिए किया जा सकता है।

उत्पादन उपयोग

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

चित्र 5. डेल्टा की उच्च स्तरीय वास्तुकला।

स्वीकृतियाँ

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

सूत्रों का कहना है

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. मार्टिन क्लेपमैन, एलेस्टेयर आर. बेर्स्फोर्ड, बोएर्ज स्विंगन: ऑनलाइन इवेंट प्रोसेसिंग। कम्यून. एसीएम 62(5): 43-49 (2019)। डीओआई: doi.org/10.1145/3312527

निःशुल्क वेबिनार के लिए साइन अप करें: "अमेज़ॅन रेडशिफ्ट स्टोरेज के लिए डेटा बिल्ड टूल।"

स्रोत: www.habr.com