डेल्टा: डेटा सिंक्रोनाइझेशन आणि एनरिचमेंट प्लॅटफॉर्म

दराने नवीन प्रवाह सुरू होण्याच्या अपेक्षेने डेटा अभियंता आम्ही मनोरंजक सामग्रीचे भाषांतर तयार केले आहे.

विहंगावलोकन

आम्ही एका बर्‍यापैकी लोकप्रिय पॅटर्नबद्दल बोलू ज्याद्वारे ऍप्लिकेशन्स एकाधिक डेटा स्टोअर्स वापरतात, जिथे प्रत्येक स्टोअरचा वापर स्वतःच्या उद्देशांसाठी केला जातो, उदाहरणार्थ, डेटाचे प्रमाणिक स्वरूप (MySQL, इ.) संग्रहित करण्यासाठी, प्रगत शोध क्षमता प्रदान करा (ElasticSearch, इ.) .), कॅशिंग (Memcached, इ.) आणि इतर. सामान्यतः, एकाधिक डेटा स्टोअर वापरताना, त्यापैकी एक प्राथमिक स्टोअर म्हणून आणि इतर डेरिव्हेटिव्ह स्टोअर म्हणून कार्य करते. फक्त समस्या ही आहे की हे डेटा स्टोअर्स कसे सिंक्रोनाइझ करायचे.

आम्ही अनेक भिन्न नमुने पाहिले ज्याने एकाधिक स्टोअर समक्रमित करण्याच्या समस्येचे निराकरण करण्याचा प्रयत्न केला, जसे की दुहेरी लेखन, वितरित व्यवहार इ. तथापि, या दृष्टिकोनांना वास्तविक जीवनातील वापर, विश्वासार्हता आणि देखरेखीच्या दृष्टीने महत्त्वपूर्ण मर्यादा आहेत. डेटा सिंक्रोनाइझेशन व्यतिरिक्त, काही अनुप्रयोगांना बाह्य सेवांवर कॉल करून डेटा समृद्ध करणे देखील आवश्यक आहे.

या समस्या सोडवण्यासाठी डेल्टा विकसित करण्यात आला. डेल्टा शेवटी डेटा सिंक्रोनाइझेशन आणि समृद्धीसाठी एक सुसंगत, इव्हेंट-चालित प्लॅटफॉर्म प्रदान करते.

विद्यमान उपाय

दुहेरी नोंद

दोन डेटा स्टोअर्स समक्रमित ठेवण्यासाठी, तुम्ही ड्युअल राइट वापरू शकता, जे एका स्टोअरवर लिहिते आणि नंतर लगेच दुसऱ्या स्टोअरला लिहिते. पहिल्या रेकॉर्डिंगचा पुन्हा प्रयत्न केला जाऊ शकतो आणि प्रयत्नांची संख्या संपल्यानंतर प्रथम अपयशी ठरल्यास दुसरे रद्द केले जाऊ शकते. तथापि, दुसर्‍या स्टोअरवर लिहिणे अयशस्वी झाल्यास दोन डेटा स्टोअर सिंक होऊ शकतात. ही समस्या सामान्यत: पुनर्प्राप्ती प्रक्रिया तयार करून सोडवली जाते जी कालांतराने पहिल्या स्टोरेजमधून दुसऱ्या स्टोरेजमध्ये डेटा पुन्हा हस्तांतरित करू शकते किंवा डेटामध्ये फरक आढळल्यासच असे करू शकते.

समस्या:

पुनर्प्राप्ती प्रक्रिया पार पाडणे हे एक विशिष्ट काम आहे जे पुन्हा वापरले जाऊ शकत नाही. याव्यतिरिक्त, जोपर्यंत पुनर्संचयित प्रक्रिया होत नाही तोपर्यंत स्टोरेज स्थानांमधील डेटा समक्रमित राहतो. दोनपेक्षा जास्त डेटा स्टोअर्स वापरल्यास उपाय अधिक गुंतागुंतीचा बनतो. शेवटी, पुनर्संचयित प्रक्रिया मूळ डेटा स्त्रोतावर लोड जोडू शकते.

लॉग टेबल बदला

जेव्हा टेबल्सच्या संचामध्ये बदल होतात (जसे की रेकॉर्ड घालणे, अपडेट करणे आणि हटवणे), त्याच व्यवहाराचा भाग म्हणून बदल नोंदी लॉग टेबलमध्ये जोडल्या जातात. दुसरा थ्रेड किंवा प्रक्रिया लॉग टेबलवरून सतत इव्हेंटची विनंती करते आणि त्यांना एक किंवा अधिक डेटा स्टोअरमध्ये लिहिते, आवश्यक असल्यास, सर्व स्टोअरद्वारे रेकॉर्डची पुष्टी झाल्यानंतर लॉग टेबलमधून इव्हेंट काढून टाकते.

समस्या:

हा पॅटर्न लायब्ररी म्हणून अंमलात आणला पाहिजे आणि आदर्शपणे तो वापरणाऱ्या ऍप्लिकेशनचा कोड न बदलता. पॉलीग्लॉट वातावरणात, अशा लायब्ररीची अंमलबजावणी कोणत्याही आवश्यक भाषेत असली पाहिजे, परंतु भाषांमध्ये कार्यक्षमता आणि वर्तनाची सुसंगतता सुनिश्चित करणे खूप कठीण आहे.

MySQL सारख्या ट्रान्झॅक्शनल स्कीमा बदलांना [1][2] सपोर्ट न करणार्‍या सिस्टीममध्ये स्कीमा बदल मिळविण्यात दुसरी समस्या आहे. म्हणून, बदल करण्याची पद्धत (उदाहरणार्थ, स्कीमा बदल) आणि बदल लॉग टेबलमध्ये व्यवहारानुसार रेकॉर्ड करणे नेहमीच कार्य करणार नाही.

वितरित व्यवहार

वितरीत व्यवहारांचा वापर एकाधिक विषम डेटा स्टोअरमध्ये व्यवहार विभाजित करण्यासाठी केला जाऊ शकतो जेणेकरुन ऑपरेशन एकतर वापरलेल्या सर्व डेटा स्टोअरसाठी वचनबद्ध असेल किंवा त्यापैकी कोणत्याहीसाठी वचनबद्ध नसेल.

समस्या:

विषम डेटा स्टोअरसाठी वितरित व्यवहार ही खूप मोठी समस्या आहे. त्यांच्या स्वभावानुसार, ते केवळ सामील असलेल्या प्रणालींच्या सर्वात कमी सामान्य भाजकावर अवलंबून राहू शकतात. उदाहरणार्थ, तयारीच्या टप्प्यात अर्जाची प्रक्रिया अयशस्वी झाल्यास XA व्यवहार अंमलबजावणीला अवरोधित करतात. याव्यतिरिक्त, XA डेडलॉक शोध प्रदान करत नाही किंवा आशावादी समवर्ती नियंत्रण योजनांना समर्थन देत नाही. याव्यतिरिक्त, इलास्टिकसर्च सारख्या काही प्रणाली XA किंवा इतर कोणत्याही विषम व्यवहार मॉडेलला समर्थन देत नाहीत. अशा प्रकारे, विविध डेटा स्टोरेज तंत्रज्ञानामध्ये अणु लेखन सुनिश्चित करणे हे ऍप्लिकेशन्ससाठी एक अतिशय आव्हानात्मक कार्य आहे [3].

डेल्टा

डेल्टा विद्यमान डेटा सिंक्रोनाइझेशन सोल्यूशन्सच्या मर्यादांचे निराकरण करण्यासाठी डिझाइन केले गेले होते आणि ऑन-द-फ्लाय डेटा समृद्धी देखील सक्षम करते. आमचे ध्येय या सर्व गुंतागुंतींना ऍप्लिकेशन डेव्हलपर्सपासून दूर ठेवणे हे होते जेणेकरून ते व्यवसाय कार्यक्षमतेच्या अंमलबजावणीवर पूर्णपणे लक्ष केंद्रित करू शकतील. पुढे आम्ही "चित्रपट शोध" चे वर्णन करणार आहोत, नेटफ्लिक्सच्या डेल्टासाठी वास्तविक वापर केस.

नेटफ्लिक्स मोठ्या प्रमाणावर मायक्रोसर्व्हिस आर्किटेक्चर वापरते आणि प्रत्येक मायक्रोसर्व्हिस सामान्यत: एका प्रकारचा डेटा सर्व्ह करते. चित्रपटाविषयीची मूलभूत माहिती मूव्ही सर्व्हिस नावाच्या मायक्रो सर्व्हिसमध्ये असते आणि संबंधित डेटा जसे की निर्माते, अभिनेते, विक्रेते इत्यादींबद्दलची माहिती इतर अनेक मायक्रो सर्व्हिसेसद्वारे व्यवस्थापित केली जाते (म्हणजे डील सर्व्हिस, टॅलेंट सर्व्हिस आणि व्हेंडर सर्व्हिस).
नेटफ्लिक्स स्टुडिओमधील व्यावसायिक वापरकर्त्यांना अनेकदा विविध चित्रपट निकषांवर शोधण्याची आवश्यकता असते, म्हणूनच त्यांच्यासाठी सर्व चित्रपट-संबंधित डेटा शोधण्यात सक्षम असणे खूप महत्वाचे आहे.

डेल्टापूर्वी, मूव्ही डेटा अनुक्रमित करण्यापूर्वी मूव्ही शोध टीमला एकाधिक मायक्रोसर्व्हिसेसमधून डेटा खेचणे आवश्यक होते. याशिवाय, संघाला अशी प्रणाली विकसित करायची होती जी इतर मायक्रो सर्व्हिसेसकडून बदलांची विनंती करून वेळोवेळी शोध निर्देशांक अपडेट करेल, जरी त्यात कोणतेही बदल नसले तरीही. ही प्रणाली त्वरीत जटिल आणि देखरेख करणे कठीण बनले.

आकृती 1. डेल्टासाठी मतदान प्रणाली
डेल्टा वापरल्यानंतर, खालील आकृतीमध्ये दर्शविल्याप्रमाणे सिस्टम इव्हेंट चालित प्रणालीमध्ये सरलीकृत करण्यात आली. CDC (चेंज-डेटा-कॅप्चर) इव्हेंट डेल्टा-कनेक्टर वापरून कीस्टोन काफ्का विषयांवर पाठवले जातात. डेल्टा स्ट्रीम प्रोसेसिंग फ्रेमवर्क (फ्लिंकवर आधारित) वापरून तयार केलेला डेल्टा अॅप्लिकेशन एखाद्या विषयावरून CDC इव्हेंट प्राप्त करतो, इतर मायक्रोसर्व्हिसेस कॉल करून त्यांना समृद्ध करतो आणि शेवटी समृद्ध केलेला डेटा Elasticsearch मधील शोध निर्देशांकात पास करतो. संपूर्ण प्रक्रिया जवळजवळ रिअल टाइममध्ये घडते, म्हणजेच डेटा वेअरहाऊसमध्ये बदल केल्यावर, शोध निर्देशांक अद्यतनित केले जातात.

आकृती 2. डेल्टा वापरून डेटा पाइपलाइन
पुढील विभागांमध्ये, आम्ही डेल्टा-कनेक्टरच्या ऑपरेशनचे वर्णन करू, जे स्टोरेजला जोडते आणि सीडीसी इव्हेंट्स ट्रान्सपोर्ट लेयरवर प्रकाशित करते, जी एक रिअल-टाइम डेटा ट्रान्समिशन इन्फ्रास्ट्रक्चर आहे जी सीडीसी इव्हेंट्सना काफ्का विषयांवर मार्गस्थ करते. आणि अगदी शेवटी, आम्ही डेल्टा स्ट्रीम प्रोसेसिंग फ्रेमवर्कबद्दल बोलू, जे ऍप्लिकेशन डेव्हलपर डेटा प्रोसेसिंग आणि एन्रिचमेंट लॉजिकसाठी वापरू शकतात.

CDC (चेंज-डेटा-कॅप्चर)

आम्ही डेल्टा-कनेक्टर नावाची एक CDC सेवा विकसित केली आहे, जी डेटा स्टोअरमधून रिअल टाइममध्ये केलेले बदल कॅप्चर करू शकते आणि त्यांना प्रवाहात लिहू शकते. व्यवहार लॉग आणि स्टोरेज डंपमधून रिअल-टाइम बदल घेतले जातात. डंप वापरले जातात कारण व्यवहार लॉग सहसा बदलांचा संपूर्ण इतिहास संचयित करत नाहीत. बदल सामान्यत: डेल्टा इव्हेंट्स म्हणून अनुक्रमित केले जातात, म्हणून प्राप्तकर्त्याला बदल कुठून आला याबद्दल काळजी करण्याची गरज नाही.

डेल्टा-कनेक्टर अनेक अतिरिक्त वैशिष्ट्यांचे समर्थन करते जसे की:

• काफ्का मागील सानुकूल आउटपुट डेटा लिहिण्याची क्षमता.
• सर्व टेबल्स, विशिष्ट टेबल किंवा विशिष्ट प्राथमिक की साठी कधीही मॅन्युअल डंप सक्रिय करण्याची क्षमता.
• डंप भागांमध्ये पुनर्प्राप्त केले जाऊ शकतात, त्यामुळे अयशस्वी झाल्यास पुन्हा सुरू करण्याची आवश्यकता नाही.
• टेबलवर कुलूप लावण्याची गरज नाही, जे आमच्या सेवेद्वारे डेटाबेस लेखन रहदारी कधीही अवरोधित केले जाणार नाही याची खात्री करणे खूप महत्वाचे आहे.
• AWS उपलब्धता झोनमध्ये अनावश्यक उदाहरणांमुळे उच्च उपलब्धता.

आम्ही सध्या AWS RDS आणि Aurora वर तैनातीसह MySQL आणि Postgres चे समर्थन करतो. आम्ही कॅसॅन्ड्राला (मल्टी-मास्टर) देखील समर्थन देतो. आपण येथे डेल्टा-कनेक्टरबद्दल अधिक तपशील शोधू शकता ब्लॉग पोस्ट.

काफ्का आणि वाहतूक स्तर

डेल्टाचा इव्हेंट ट्रान्सपोर्ट लेयर प्लॅटफॉर्मच्या मेसेजिंग सेवेवर तयार केला आहे धोरण.

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

डेल्टासह, आम्हाला सीडीसी इव्हेंट्स व्युत्पन्न स्टोअरमध्ये वितरण सुनिश्चित करण्यासाठी मजबूत टिकाऊपणाची हमी हवी होती. या उद्देशासाठी, आम्ही प्रथम श्रेणी ऑब्जेक्ट म्हणून खास डिझाइन केलेले काफ्का क्लस्टर प्रस्तावित केले. तुम्ही खालील सारणीमध्ये काही ब्रोकर सेटिंग्ज पाहू शकता:

कीस्टोन काफ्का क्लस्टर्समध्ये, अस्वच्छ नेता निवडणूक सहसा प्रकाशक प्रवेशयोग्यता सुनिश्चित करण्यासाठी समाविष्ट केले जाते. जर असंक्रमित प्रतिकृती नेता म्हणून निवडली गेली तर यामुळे संदेश गमावला जाऊ शकतो. नवीन उच्च उपलब्धता काफ्का क्लस्टरसाठी, पर्याय अस्वच्छ नेता निवडणूक संदेश हानी टाळण्यासाठी बंद केले.

आम्ही पण वाढलो प्रतिकृती घटक 2 ते 3 पर्यंत आणि किमान इनसिंक प्रतिकृती 1 ते 2. या क्लस्टरवर लिहिणाऱ्या प्रकाशकांना इतर सर्वांकडून acks आवश्यक आहेत, याची खात्री करून की 2 पैकी 3 प्रतिकृतींमध्ये प्रकाशकाने पाठवलेले सर्वात वर्तमान संदेश आहेत.

जेव्हा ब्रोकर उदाहरण संपुष्टात येते, तेव्हा नवीन उदाहरण जुन्याची जागा घेते. तथापि, नवीन ब्रोकरला सिंक्रोनाइझ न केलेल्या प्रतिकृतींसह पकडणे आवश्यक आहे, ज्यास काही तास लागू शकतात. या परिस्थितीसाठी पुनर्प्राप्ती वेळ कमी करण्यासाठी, आम्ही स्थानिक ब्रोकर डिस्कऐवजी ब्लॉक डेटा स्टोरेज (Amazon इलास्टिक ब्लॉक स्टोअर) वापरण्यास सुरुवात केली. जेव्हा एखादी नवीन घटना संपुष्टात आलेल्या ब्रोकर उदाहरणाची जागा घेते, तेव्हा ते संपुष्टात आलेल्या उदाहरणाचा EBS व्हॉल्यूम संलग्न करते आणि नवीन संदेश प्राप्त करण्यास सुरवात करते. ही प्रक्रिया बॅकलॉग क्लिअरन्स वेळ तासांपासून मिनिटांपर्यंत कमी करते कारण नवीन उदाहरणाला यापुढे रिक्त स्थितीतून प्रतिकृती तयार करण्याची आवश्यकता नाही. एकूणच, वेगळे स्टोरेज आणि ब्रोकर लाइफसायकल ब्रोकर स्विचिंगचा प्रभाव लक्षणीयरीत्या कमी करतात.

डेटा वितरण हमी आणखी वाढवण्यासाठी, आम्ही वापरले संदेश ट्रॅकिंग सिस्टम अतिपरिस्थितीत कोणताही संदेश नष्ट होणे शोधण्यासाठी (उदाहरणार्थ, विभाजन लीडरमध्ये घड्याळ डिसिंक्रोनाइझेशन).

प्रवाह प्रक्रिया फ्रेमवर्क

डेल्टाचा प्रोसेसिंग लेयर Netflix SPaaS प्लॅटफॉर्मच्या वर तयार केला आहे, जो Netflix इकोसिस्टमसह Apache Flink एकीकरण प्रदान करतो. प्लॅटफॉर्म वापरकर्ता इंटरफेस प्रदान करतो जो आमच्या टायटस कंटेनर व्यवस्थापन प्लॅटफॉर्मच्या शीर्षस्थानी फ्लिंक जॉब्स आणि फ्लिंक क्लस्टर्सचे ऑर्केस्ट्रेशन व्यवस्थापित करतो. इंटरफेस जॉब कॉन्फिगरेशन्स देखील व्यवस्थापित करतो आणि वापरकर्त्यांना फ्लिंक जॉब्स पुन्हा कंपाइल न करता डायनॅमिकपणे कॉन्फिगरेशन बदल करण्यास अनुमती देतो.

डेल्टा Flink आणि SPaaS वर आधारित प्रवाह प्रक्रिया फ्रेमवर्क प्रदान करते जे वापरते भाष्य-आधारित डीएसएल (डोमेन स्पेसिफिक लँग्वेज) तांत्रिक तपशील अमूर्त करण्यासाठी. उदाहरणार्थ, बाह्य सेवांना कॉल करून इव्हेंट्स कोणत्या टप्प्यावर समृद्ध होतील ते परिभाषित करण्यासाठी, वापरकर्त्यांनी खालील DSL लिहिणे आवश्यक आहे आणि फ्रेमवर्क त्यावर आधारित एक मॉडेल तयार करेल, जे Flink द्वारे कार्यान्वित केले जाईल.

आकृती 3. डेल्टामधील DSL वर समृद्धीचे उदाहरण

प्रक्रिया फ्रेमवर्क केवळ शिकण्याची वक्र कमी करत नाही तर सामान्य प्रवाह प्रक्रिया वैशिष्ट्ये देखील प्रदान करते जसे की डुप्लिकेशन, स्कीमॅटायझेशन आणि सामान्य ऑपरेशनल समस्या सोडवण्यासाठी लवचिकता आणि लवचिकता.

डेल्टा स्ट्रीम प्रोसेसिंग फ्रेमवर्कमध्ये दोन प्रमुख मॉड्यूल्स आहेत, DSL आणि API मॉड्यूल आणि रनटाइम मॉड्यूल. DSL आणि API मॉड्यूल DSL आणि UDF (User-Defined-Function) API प्रदान करते जेणेकरून वापरकर्ते त्यांचे स्वतःचे प्रक्रिया तर्क (जसे की फिल्टरिंग किंवा ट्रान्सफॉर्मेशन) लिहू शकतात. रनटाइम मॉड्यूल DSL पार्सरची अंमलबजावणी प्रदान करते जे DAG मॉडेल्समधील प्रक्रिया चरणांचे अंतर्गत प्रतिनिधित्व तयार करते. एक्झिक्युशन घटक वास्तविक फ्लिंक स्टेटमेंट्स सुरू करण्यासाठी आणि शेवटी फ्लिंक अॅप्लिकेशन चालवण्यासाठी DAG मॉडेल्सचा अर्थ लावतो. फ्रेमवर्कचे आर्किटेक्चर खालील आकृतीमध्ये स्पष्ट केले आहे.

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

या पद्धतीचे अनेक फायदे आहेत:

• वापरकर्ते Flink किंवा SPaaS संरचनेची माहिती न घेता त्यांच्या व्यावसायिक तर्कावर लक्ष केंद्रित करू शकतात.
• ऑप्टिमायझेशन अशा प्रकारे केले जाऊ शकते जे वापरकर्त्यांसाठी पारदर्शक असेल आणि वापरकर्ता कोड (UDF) मध्ये कोणतेही बदल न करता त्रुटी निश्चित केल्या जाऊ शकतात.
• डेल्टा ऍप्लिकेशन अनुभव वापरकर्त्यांसाठी सोपा केला आहे कारण प्लॅटफॉर्म बॉक्सच्या बाहेर लवचिकता आणि लवचिकता प्रदान करतो आणि विविध तपशीलवार मेट्रिक्स एकत्रित करतो ज्याचा वापर अलर्टसाठी केला जाऊ शकतो.

उत्पादन वापर

डेल्टा एक वर्षाहून अधिक काळ उत्पादनात आहे आणि अनेक Netflix स्टुडिओ अनुप्रयोगांमध्ये महत्त्वाची भूमिका बजावते. शोध अनुक्रमणिका, डेटा स्टोरेज आणि इव्हेंट-चालित वर्कफ्लो यासारख्या वापर प्रकरणांची अंमलबजावणी करण्यासाठी तिने संघांना मदत केली. खाली डेल्टा प्लॅटफॉर्मच्या उच्च-स्तरीय आर्किटेक्चरचे विहंगावलोकन आहे.

आकृती 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. मार्टिन क्लेपमन, अॅलिस्टर आर. बेरेसफोर्ड, बोर्ज स्विंगेन: ऑनलाइन इव्हेंट प्रक्रिया. कम्युन. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

विनामूल्य वेबिनारसाठी साइन अप करा: "ऍमेझॉन रेडशिफ्ट स्टोरेजसाठी डेटा बिल्ड टूल."

स्त्रोत: www.habr.com