डेटा मेष: एक मोनोलिथ के बिना डेटा के साथ कैसे काम किया जाए

नमस्कार, हेब्र! डोडो पिज्जा इंजीनियरिंग में हम वास्तव में डेटा से प्यार करते हैं (और जो अब उन्हें पसंद नहीं करते हैं?)। अब इस बारे में एक कहानी होगी कि डोडो पिज्जा की दुनिया के सभी डेटा को कैसे संचित किया जाए और किसी भी कंपनी के कर्मचारी को इस डेटा ऐरे से सुविधाजनक सुविधा दी जाए। तारांकन के तहत चुनौती: डेटा इंजीनियरिंग टीम की नसों को बचाओ।

असली प्लाइशकिंस की तरह, हम अपने पिज़्ज़ेरिया के काम के बारे में सभी प्रकार की जानकारी सहेजते हैं:

• सभी उपयोगकर्ता आदेश याद रखें;
• हम जानते हैं कि Syktyvkar में बहुत पहले पिज्जा बनाने में कितना समय लगा;
• हम देखते हैं कि अभी वोरोनिश में गर्मी के शेल्फ पर पिज्जा ठंडा होने में कितना समय है;
• उत्पादों के राइट-ऑफ पर डेटा स्टोर करें;
• और भी बहुत कुछ।

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

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

हमें "डेटा" से क्या मतलब है

आरंभ करने के लिए, आइए निर्णय लेते हैं कि डोडो पिज्जा इंजीनियरिंग में डेटा से हमारा क्या मतलब है:

• ईवेंट जो सेवाएं भेजते हैं (हमारे पास एक सामान्य बस है जो रैबिटएमक्यू का उपयोग करके बनाई गई है);
• डेटाबेस के अंदर रिकॉर्ड (हमारे लिए, यह MySQL और CosmosDB है);
• मोबाइल एप्लिकेशन और वेबसाइट से क्लिकस्ट्रीम।

इस डेटा का उपयोग करने और उस पर भरोसा करने के लिए डोडो पिज्जा व्यवसाय के लिए, यह महत्वपूर्ण है कि निम्नलिखित शर्तें पूरी हों:

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

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

पारंपरिक दृष्टिकोण - डेटा लेक

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

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

इस परिदृश्य के साथ, टीम बहुत उदास बिल्लियों बन जाती है और इसीलिए:

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

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

डेटा लेक से डेटा मेश तक बहना

सौभाग्य से, न केवल हमने खुद से यह सवाल पूछा। वास्तव में, इसी तरह की समस्या पहले से ही उद्योग में हल हो गई है (हाललुजाह!)। केवल दूसरे क्षेत्र में: आवेदन परिनियोजन। हां, मैं DevOps के दृष्टिकोण के बारे में बात कर रहा हूं, जहां टीम यह निर्धारित करती है कि उनके द्वारा बनाए गए उत्पाद को कैसे तैनात किया जाए।

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

• बड़ी डेटा झील को डेटा डोमेन में विभाजित करें जो डोमेन-संचालित डिज़ाइन डोमेन के समान हैं। प्रत्येक डोमेन एक छोटा बाउंडेड संदर्भ है।
• फ़ीचर टीम, जो DDD डोमेन के लिए ज़िम्मेदार है, वह संबंधित डेटा डोमेन के लिए भी ज़िम्मेदार है। वे सर्किट को स्टोर करते हैं, उसमें बदलाव करते हैं, उसमें डेटा लोड करते हैं। उसी समय, वे खुद को सब कुछ जानते हैं: एप्लिकेशन को बदलने पर डेटा लोडिंग को कैसे बदलना है और कुछ भी नहीं तोड़ना है। ज्ञान कहीं नहीं जाता। डेटा खोलने के लिए, उन्हें कहीं भी नहीं जाना होगा। टीम स्वयं ही परिचालन डेटा को बदलने से लेकर तीसरे पक्षों तक विश्लेषणात्मक डेटा प्रदान करने के लिए एक पूर्ण विकास चक्र का संचालन करती है। एक टीम डोमेन (व्यवसाय डोमेन और डेटा डोमेन दोनों) से जुड़ी हर चीज का मालिक है।
• डेटा इंजीनियर - फ़ीचर टीम के भीतर एक भूमिका। इसके लिए व्यक्ति का होना जरूरी नहीं है, लेकिन यह जरूरी है कि टीम के पास यह योग्यता हो।

इस बीच, डेटा इंजीनियरिंग टीम ...

यदि आप कल्पना करते हैं कि यह सब एक उंगली के क्लिक पर महसूस होता है, तो यह दो सवालों के जवाब देने के लिए बना हुआ है:

डाटा इंजीनियरिंग टीम अब क्या करेगी? डोडो पिज्जा इंजीनियरिंग में पहले से ही एक / एसआरई प्लेटफॉर्म टीम है। इसका काम डेवलपर्स को सेवाओं की आसान तैनाती के लिए उपकरण देना है। डेटा इंजीनियरिंग टीम केवल डेटा के लिए एक ही भूमिका निभाएगी।

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

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

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

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

हमारे पास ऐसा करने के कई तरीके हैं:

1. DevForum , जिसमें हम आपको बताएंगे कि हमने जो प्रक्रिया बनाई है वह कैसी दिखती है, कौन से उपकरण हैं और उनका उपयोग कैसे करें।
2. DevForum में बात करने से हमें उत्पाद डेवलपर्स से प्रतिक्रिया एकत्र करने में मदद मिलेगी। उसके बाद, हम उत्पाद टीमों में शामिल होने और उन्हें डेटा के प्रकाशन के साथ समस्याओं को हल करने में मदद करेंगे, टीमों के लिए प्रशिक्षण का आयोजन करेंगे।

डेटा की खपत

अब मैंने डेटा प्रकाशित करने के बारे में बहुत बात की। लेकिन खपत भी है। इस मुद्दे के बारे में क्या?

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

इस तरह से हम डोडो पिज्जा इंजीनियरिंग में डेटा के साथ काम कर रहे हैं। हम इस पर आपके विचारों को टिप्पणियों में पढ़कर प्रसन्न हैं।