क्या आपकी टीम को डेटा इंजीनियर की आवश्यकता है?

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

आधुनिक स्टार्टअप्स में डेटा इंजीनियर की भूमिका तेजी से बदल रही है। क्या आप सुनिश्चित हैं कि आप अच्छी तरह से समझते हैं कि आपकी टीम को ऐसे विशेषज्ञ की आवश्यकता कब और क्यों हो सकती है?

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

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

यदि आप डेटा विशेषज्ञों की एक टीम का नेतृत्व कर रहे हैं, तो यह पोस्ट आपके लिए है।

एक डाटा इंजीनियर की भूमिका बदल रही है

आधुनिक सॉफ्टवेयर डेटा विश्लेषण और प्रसंस्करण से संबंधित अधिक उबाऊ काम को स्वचालित करना संभव बनाता है।

2012 में, उद्यम-पोषित स्टार्टअप में संपूर्ण डेटासेट का विश्लेषण करने के लिए कम से कम एक डेटा इंजीनियर की आवश्यकता थी। इस तरह के विशेषज्ञ को विभिन्न प्रणालियों से डेटा निकालना पड़ता था ताकि विश्लेषकों और कॉर्पोरेट ग्राहक उनके साथ आगे काम कर सकें। अक्सर यह किसी भी तरह से डेटा को बदलने के लिए आवश्यक था ताकि विश्लेषण करना आसान हो। डेटा इंजीनियर के बिना, डेटा विश्लेषण और प्रसंस्करण विशेषज्ञों के पास बस वह डेटा नहीं होता जिसके साथ वे काम कर सकते थे, इसलिए अक्सर यह डेटा इंजीनियर के साथ होता था जो टीम के गठन के लिए शुरू हुआ था।

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

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

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

डेटा इंजीनियर को ईटीएल नहीं लिखना चाहिए

2016 में, जेफ मैगनसन ने एक मौलिक पोस्ट लिखा, डेटा इंजीनियर्स ईटी नॉट ईटीएल लिखें । यह मेरी स्मृति में पहली पोस्ट थी जिसने इस तरह के बदलाव का आह्वान किया। यहाँ मेरा पसंदीदा हिस्सा है:

“पिछले 5 वर्षों में, डेटा प्रोसेसिंग टूल और प्रौद्योगिकियां विकसित हुई हैं। अधिकांश प्रौद्योगिकियां पहले ही इतनी विकसित हो चुकी हैं कि वे आपकी आवश्यकताओं के अनुकूल हो सकती हैं, जब तक कि निश्चित रूप से, आपको प्रति दिन डेटा या अरबों की घटनाओं की पेटाबाइट्स संसाधित करने की आवश्यकता नहीं है।

यदि आपको इन तकनीकों की क्षमताओं से परे जाने की आवश्यकता नहीं है, तो आपको अतिरिक्त समाधान विकसित करने के लिए अत्यधिक विशिष्ट प्रोग्रामर की टीम की आवश्यकता नहीं है।

यदि आप उन्हें किराए पर लेते हैं, तो वे जल्द ही ऊब जाएंगे। यदि वे ऊब गए, तो वे आपको Google, Facebook, LinkedIn, Twitter पर छोड़ देंगे - वे स्थान जहाँ उनका अनुभव वास्तव में आवश्यक है। यदि वे ऊब नहीं हैं, तो सबसे अधिक संभावना है कि वे औसत दर्जे के हैं। और औसत दर्जे के प्रोग्रामर वास्तव में सामान्य काम के बकवास के लिए जटिल, अनुपयुक्त की एक बड़ी मात्रा के निर्माण में सफल रहे, जिसे वे "समाधान" कहते हैं। * *

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

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

प्लेग जैसे विशेषज्ञों से दूर भागना। विश्लेषकों की आपकी टीम में वृद्धि दर में तेज़ी से गिरावट आएगी, और आप अपना सारा समय आधारभूत संरचना की समस्याओं को हल करने में लगाएंगे, और ऐसा बिल्कुल नहीं है जो आपके व्यवसाय में आय लाए।

ETL नहीं तो क्या?

क्या आपकी टीम को वास्तव में डेटा इंजीनियर की आवश्यकता है? हां।

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

डेटा इंजीनियर अभी भी किसी भी पेशेवर डेटा टीम का एक महत्वपूर्ण हिस्सा हैं।

आपके डेटा इंजीनियरों को पाइपलाइनों का निर्माण नहीं करना चाहिए, जिसके लिए पहले से तैयार समाधान हैं और SQL डेटा परिवर्तनों को लिखें। यहाँ वे क्या पर ध्यान केंद्रित करना चाहिए:

• संगठन और अंतर्निहित डेटा अवसंरचना का अनुकूलन,
• कस्टम पाइपलाइनों का निर्माण और समर्थन,
• पाइपलाइनों और प्रश्नों के डिजाइन और प्रदर्शन में सुधार करके डेटा विशेषज्ञों की एक टीम का समर्थन,
• गैर-SQL डेटा परिवर्तनों का निर्माण।

संगठन और अंतर्निहित डेटा अवसंरचना का अनुकूलन

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

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

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

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

डेटा इंजीनियर अक्सर CI / CD पाइपलाइन के निर्माण और रखरखाव के लिए भी जिम्मेदार होते हैं जो डेटा के बुनियादी ढांचे का प्रबंधन करते हैं। 2012 में, कई कंपनियों के पास संस्करण नियंत्रण, प्रबंधन और परीक्षण के लिए एक बहुत ही कमजोर बुनियादी ढांचा था, लेकिन अब सब कुछ बदल रहा है, और यही डेटा इंजीनियर पीछे हैं।

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

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

कस्टम पाइपलाइनों का निर्माण और रखरखाव

हालांकि डेटा इंजीनियरों को अब पोस्टग्रेज या सेल्सफोर्स को मैन्युअल रूप से डेटा ट्रांसफर करने की आवश्यकता नहीं है, विक्रेताओं के पास 100 एकीकरण विकल्पों के बारे में "केवल" है। हमारे अधिकांश ग्राहक तुरंत डेटा स्रोतों के 75 से 90% तक पहुंच सकते हैं, जिसके साथ वे काम करते हैं।

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

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

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

पाइपलाइनों और प्रश्नों के डिजाइन और प्रदर्शन में सुधार करके डेटा विशेषज्ञों की एक टीम के लिए समर्थन

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

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

यह प्रवृत्ति 2014 में विकसित हुई जब लुकर ने पीडीटी टूल जारी किया । जब डेटा विशेषज्ञों की पूरी टीम 500+ नोड्स से डेटा प्रोसेसिंग डिग्राफ का निर्माण करना शुरू कर देती है और पिछले दो वर्षों में dbt का उपयोग करके बड़े डेटा सेट को संसाधित करना शुरू कर देती है। इस स्तर पर, मॉडल को आधुनिक टीमों में गहराई से निहित किया गया है और विश्लेषकों को हमेशा की तरह स्वतंत्रता दी है।

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

1. जब आपको उत्पादकता बढ़ाने की आवश्यकता हो

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

2. जब कोड बहुत जटिल हो जाता है

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

गैर SQL डेटा परिवर्तनों का निर्माण

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

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

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

आपकी टीम को डेटा इंजीनियर की आवश्यकता कब होती है?

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

1. आपकी टीम में 3 डेटा विज्ञान विश्लेषक / विशेषज्ञ हैं,
2. आपके BI प्लेटफ़ॉर्म में 50 सक्रिय उपयोगकर्ता हैं,
3. आपके संग्रहण में सबसे बड़ी तालिका 1 बिलियन पंक्तियों तक पहुँचती है,
4. आप जानते हैं कि आपको अगली कुछ तिमाहियों में 3 या अधिक कस्टम डेटा प्रोसेसिंग पाइपलाइनों का निर्माण करने की आवश्यकता है, और वे सभी महत्वपूर्ण हैं।

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

समझने की मुख्य बात यह है कि डेटा इंजीनियर का व्यवसाय के लिए कोई मूल्य नहीं है, इसका मुख्य काम आपके विश्लेषकों की उत्पादकता को बढ़ाना है। , KPI – . - , : , -, 33 %, , , .

, data scientist- .

, , – 5 1: / data science -. , , , .

?

- . , :

« , , - . . , - ( ) .
, – -, / data science. -, , , , . -, : “, , , ”».

. - – , , . .

, , :) . , , , , – - .

, - , – , . , , , !

, Skyeng :

Skyeng 30+ - -. , , . Amazon Redshift , Stitch Matillion ETL 40+ -, Segment , Redash Tableau , Amazon SageMaker ML.

— - . , MVP- , , . , , , Tableau .

, , , - . , , : , .

- -, , , , . 90% , . , Skyeng.