डाटा मेष: कसरी मोनोलिथ बिना डाटासँग काम गर्ने

हे, हबर! हामी डोडो पिज्जा इन्जिनियरिङमा डेटा मन पराउँछौं (आजकल कसलाई मन पर्दैन?)। यो डोडो पिज्जाको संसारमा सबै डेटा कसरी जम्मा गर्ने र प्रत्येक कर्मचारीलाई यो विशाल डेटा सेटमा सजिलो पहुँच दिने भन्ने बारे हाम्रो कथा हो। लक्ष्य भनेको डेटा इन्जिनियरिङ टोलीलाई सतर्क राख्नु हो।

साँचो प्लायस्किन्स जस्तै, हामी हाम्रा पिज्जेरियाहरूको सञ्चालनको बारेमा सबै प्रकारका जानकारी सङ्कलन गर्दैछौं:

• हामी सबै प्रयोगकर्ता अर्डरहरू सम्झन्छौं;
• हामीलाई थाहा छ सिक्टिभ्करमा पहिलो पिज्जा बनाउन कति समय लाग्यो;
• हामी देख्छौं कि अहिले भोरोनेजमा वार्मिङ शेल्फमा पिज्जा चिसो हुन कति समय लाग्छ;
• हामी उत्पादन राइट-अफमा डेटा भण्डारण गर्छौं;
• र धेरै धेरै अन्य।

डोडो पिज्जामा डेटासँग काम गर्ने जिम्मेवारी हाल धेरै टोलीहरू रहेका छन्, जसमध्ये एउटा डाटा इन्जिनियरिङ टोली हो। उनीहरूको हालको कार्य (अर्थात्, हाम्रो) कम्पनीका प्रत्येक कर्मचारीलाई यो विशाल डेटा सेटमा सुविधाजनक पहुँच प्रदान गर्नु हो।

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

"डेटा" भन्नाले हामीले के बुझ्छौं?

पहिले, डोडो पिज्जा इन्जिनियरिङमा डेटा भन्नाले के बुझिन्छ भनेर परिभाषित गरौं:

• सेवाहरूद्वारा पठाइएका घटनाहरू (हामीसँग RabbitMQ प्रयोग गरेर बनाइएको साझा बस छ);
• डाटाबेस भित्रका रेकर्डहरू (हाम्रो लागि यो MySQL र CosmosDB हो);
• मोबाइल एप र वेबसाइटबाट क्लिकस्ट्रिम।

डोडो पिज्जाले यो डेटा प्रयोग गर्न र यसमा भर पर्नको लागि, निम्न सर्तहरू पूरा गर्नु महत्त्वपूर्ण छ:

• तिनीहरू अभिन्न हुनुपर्छ। हामीले प्रशोधन, भण्डारण र प्रदर्शनको क्रममा डेटा परिवर्तन नगर्ने कुरामा निश्चित हुनुपर्छ। यदि व्यवसायहरूले हाम्रो डेटालाई विश्वास गर्न सक्दैनन् भने, यसको कुनै उपयोग हुनेछैन।
• तिनीहरू समय-मुद्रित हुनुपर्छ र अधिलेखन गर्नु हुँदैन। यसको अर्थ यो हो कि कुनै पनि समयमा, हामी त्यो अवधिको डेटा हेर्न र पछाडि फर्कन सक्षम हुन चाहन्छौं। उदाहरणका लागि, जुलाई ८, २०१८ मा कति पिज्जा बिक्री भए भनेर पत्ता लगाउन।
• तिनीहरू भरपर्दो हुनुपर्छ। डेटा सङ्कलन र भण्डारण गर्दा, हामीले निष्ठा मात्र होइन विश्वसनीयता पनि कायम राख्नुपर्छ। हामी डेटा, वा समयको टुक्रा गुमाउन सक्दैनौं, किनभने तिनीहरूको साथ, हामी हाम्रा ग्राहकहरूको विश्वास गुमाउँछौं (बाह्य र आन्तरिक दुवै)।
• तिनीहरूसँग स्थिर योजना हुनुपर्छ - हामी यस डेटाको लागि प्रश्नहरू लेख्छौं। रिफ्याक्टर गरिएको एप्लिकेसनले कोड यति धेरै परिवर्तन गर्‍यो कि हाम्रा क्वेरीहरूले काम गर्न छोडे भने हामीलाई साँच्चै मन पर्दैन। क्वेरीहरू लेख्ने व्यक्तिले सबै कुरा पूर्ण रूपमा बिग्रिएसम्म तपाईंले रिफ्याक्टर गर्नुभएको कहिल्यै थाहा पाउने छैन। हामी हाम्रा ग्राहकहरूबाट यस बारेमा सुन्न चाहँदैनौं।

यी सबै आवश्यकताहरूलाई विचार गर्दै, हामीले निष्कर्ष निकाल्यौं कि डोडोमा रहेको डेटा सेवाको सार्वजनिक API जस्तै एक उत्पादन हो। तदनुसार, डेटा सेवाको स्वामित्वमा रहेको टोलीको स्वामित्वमा हुनुपर्छ। साथै, डेटा स्कीमामा परिवर्तनहरू सधैं पछाडि-कम्प्याटिबल हुनुपर्छ।

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

ठूलो डेटाको विश्वसनीय भण्डारण र प्रशोधन गर्ने समस्या समाधान गर्न, यस्तो जानकारीको समूहसँग काम गर्ने धेरै कम्पनीहरूले अपनाएको परम्परागत दृष्टिकोण भनेको डेटा लेक हो। यस दृष्टिकोणको साथ, डेटा इन्जिनियरहरूले सबै प्रणाली घटकहरूबाट जानकारी सङ्कलन गर्छन् र यसलाई एउटै ठूलो भण्डारण सुविधामा भण्डारण गर्छन् (उदाहरणका लागि, Hadoop, Azure Kusto, Apache Cassandra, वा यदि डेटा फिट हुन्छ भने MySQL प्रतिकृति पनि)।

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

यस परिदृश्यमा, टोली धेरै दुःखी बिरालो बन्छ, र यहाँ कारण छ:

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

यो टोली ठूलो संख्यामा आवश्यकताहरूको सङ्घारमा छ र ती सबै पूरा गर्न सक्षम हुने सम्भावना कम छ। साथै, तिनीहरू निरन्तर समयको दबाब र तनावमा हुनेछन्। हामी वास्तवमै त्यो चाहँदैनौं। त्यसकारण, हामीले डेटा विश्लेषण गर्न सक्षम हुँदै यी समस्याहरू कसरी समाधान गर्ने भन्ने बारे सोच्नुपर्छ।

डेटा लेकबाट डेटा मेषमा बग्ने

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

थटवर्क्सका सल्लाहकार झामक देहघानीले डेटा लेक समस्याहरू समाधान गर्न यस्तै दृष्टिकोण प्रस्ताव गरेका थिए। नेटफ्लिक्स र स्पोटिफाईले कसरी समान चुनौतीहरूको सामना गरे भनेर अवलोकन गरेपछि, उनले एउटा आकर्षक लेख लेखिन्। मोनोलिथिक डाटा लेकभन्दा बाहिर वितरित डाटा मेसमा कसरी सर्ने(यसको लिङ्क लेखको सुरुमा थियो)। हामीले यसबाट लिएका मुख्य विचारहरू:

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

यसैबीच, डाटा इन्जिनियरिङ टोली...

यदि हामी कल्पना गर्छौं कि यो सबै औंलाको चुट्किलाले साकार पार्न सकिन्छ, तब दुई प्रश्नहरूको उत्तर दिन बाँकी छ:

डाटा इन्जिनियरिङ टोलीले अब के गर्नेछ? डोडो पिज्जा इन्जिनियरिङसँग पहिले नै प्लेटफर्म/SRE टोली छ। यसको लक्ष्य विकासकर्ताहरूलाई सजिलैसँग सेवाहरू तैनाथ गर्न उपकरणहरू प्रदान गर्नु हो। डाटा इन्जिनियरिङ टोलीले समान भूमिका खेल्नेछ, तर डाटाको लागि।

सञ्चालन डेटालाई विश्लेषणात्मक डेटामा रूपान्तरण गर्नु एक जटिल प्रक्रिया हो। सम्पूर्ण कम्पनीको लागि विश्लेषणात्मक डेटा पहुँचयोग्य बनाउनु अझ चुनौतीपूर्ण छ। डाटा इन्जिनियरिङ टोलीले यी चुनौतीहरूलाई सम्बोधन गर्नेछ।

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

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

डोडोको एउटा ठूलो फाइदा भनेको हामीलाई आन्तरिक तालिम मन पर्छ। त्यसैले, हाम्रो हालको योजना यो हो: डाटा इन्जिनियरिङ टोलीले केही सेवाहरूबाट डाटा प्रकाशित गर्न थाल्छ, र हामी यसमा हुँदासम्म, हामी प्रयास गरिरहनेछौं। एक पटक हामी विश्वस्त हुन्छौं कि हामीसँग प्रकाशनको लागि तयार प्रक्रिया छ, हामी यसलाई फिचर टोलीसँग साझा गर्न थाल्नेछौं।

हामीसँग यो गर्ने धेरै तरिकाहरू छन्:

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

डेटा खपत

मैले अहिले डेटा प्रकाशनको बारेमा धेरै कुरा गरिसकेको छु। तर त्यहाँ खपत पनि छ। त्यसको बारेमा के भन्नु हुन्छ?

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

डोडो पिज्जा इन्जिनियरिङमा हामी यसरी डेटा प्रशोधन गर्छौं। हामी यसबारे टिप्पणीहरूमा तपाईंको विचार सुन्न चाहन्छौं।

स्रोत: www.habr.com