डेटा इंजीनियर या मरो: एक डेवलपर की कहानी

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

डेटा इंजीनियरिंग क्यों?

DE की मेरी यात्रा 2019 की गर्मियों में शुरू हुई, जब हम Xneg के लिए चलते हैं वितरित कंप्यूटिंग स्कूल, और वहां मुझे आत्मज्ञान प्राप्त हुआ। मुझे विषय, अध्ययन एल्गोरिदम और यहां तक ​​कि उनके बारे में भी दिलचस्पी होने लगी लिखना, और फिर आवेदन के दायरे के बारे में सोचा और जल्दी से पता चला कि हमारी कंपनी में व्यावहारिक अनुप्रयोग वितरित डेटाबेस है।

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

यदि आप डेटा Driven बनना चाहते हैं तो सबसे पहले इवेंट Driven बनें

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

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

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

विकास से संक्रमण होने पर कठिनाइयाँ

काम के पहले दिन मुझे कई कठिनाइयों का सामना करना पड़ा जिन्हें मैं आपके साथ साझा करना चाहता हूं।

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

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

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

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

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

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

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

बैठक के निष्कर्ष और घोषणा

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

और अंत में, घोषणा. चूँकि दिन के दौरान हमारे विषय पर मुलाकात ढूँढना कठिन है, इसलिए हमने अपना स्वयं का कार्यक्रम बनाने का निर्णय लिया। हम बदतर क्यों हैं? सौभाग्य से हमारे पास एक अद्भुत चीज़ है Schvepsss और हमारे दोस्त न्यू प्रोफेशन लैब, जो हमारी तरह महसूस करते हैं कि डेटा इंजीनियरों को गलत तरीके से ध्यान से वंचित किया जाता है।

इस अवसर का लाभ उठाते हुए, मैं उन सभी को आमंत्रित करता हूं जो आशाजनक शीर्षक "DE या DIE" के साथ हमारे पहले सामुदायिक मीटअप में आने के लिए आमंत्रित करते हैं, जो 27.02.2020 फरवरी, XNUMX को डोडो पिज्जा कार्यालय में होगा। विवरण यहां टाइमपैड.

अगर कुछ भी होता है, तो मैं वहां रहूंगा, आप मुझे व्यक्तिगत रूप से मेरे चेहरे पर बता सकते हैं कि मैं डेवलपर्स के बारे में कितना गलत हूं।

स्रोत: www.habr.com