छोटो उत्तर: एआईले डेटा इन्जिनियरहरूलाई सिधै प्रतिस्थापन गर्दैन; यसले SQL ड्राफ्टिङ, पाइपलाइन स्क्याफोल्डिङ, परीक्षण र कागजात जस्ता दोहोरिने कामलाई स्वचालित गर्नेछ। यदि तपाईंको भूमिका प्रायः कम-स्वामित्व, टिकट-संचालित काम हो भने, यो बढी खुला हुन्छ; यदि तपाईंसँग विश्वसनीयता, परिभाषा, शासन, र घटना प्रतिक्रिया छ भने, एआईले मुख्यतया तपाईंलाई छिटो बनाउँछ।
मुख्य कुराहरू:
स्वामित्व: छिटो कोड उत्पादन गर्नु मात्र होइन, परिणामहरूको लागि जवाफदेहितालाई प्राथमिकता दिनुहोस्।
गुणस्तर: पाइपलाइनहरू विश्वसनीय रहून् भनेर परीक्षण, अवलोकनयोग्यता, र सम्झौताहरू निर्माण गर्नुहोस्।
शासन: गोपनीयता, पहुँच नियन्त्रण, अवधारण, र लेखापरीक्षण ट्रेलहरू मानव स्वामित्वमा राख्नुहोस्।
दुरुपयोग प्रतिरोध: एआई आउटपुटहरूलाई ड्राफ्टको रूपमा व्यवहार गर्नुहोस्; आत्मविश्वासपूर्ण गलत हुनबाट बच्न तिनीहरूलाई समीक्षा गर्नुहोस्।
भूमिका परिवर्तन: बयलरप्लेट टाइप गर्न कम समय र टिकाउ प्रणाली डिजाइन गर्न बढी समय खर्च गर्नुहोस्।
यदि तपाईंले डेटा टोलीहरू वरिपरि पाँच मिनेटभन्दा बढी समय बिताउनुभएको छ भने, तपाईंले यो निषेध सुन्नुभएको छ - कहिलेकाहीं फुसफुसाएको, कहिलेकाहीं बैठकभरि कथानक मोड जस्तै सुरु गरिएको: के एआईले डेटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ?
अनि... म बुझ्छु। AI ले SQL उत्पन्न गर्न सक्छ, पाइपलाइनहरू निर्माण गर्न सक्छ, स्ट्याक ट्रेसहरू व्याख्या गर्न सक्छ, dbt मोडेलहरू ड्राफ्ट गर्न सक्छ, अनिश्चित आत्मविश्वासका साथ गोदाम स्किमाहरू पनि सुझाव दिन सक्छ। SQL को लागि GitHub Copilot dbt मोडेलहरूको बारेमा GitHub Copilot
यो फोर्कलिफ्टले जुगल गर्न सिकेको हेरिरहेको जस्तो लाग्छ। प्रभावशाली, थोरै चिन्ताजनक, र तपाईं आफ्नो कामको लागि यसको अर्थ के हो भनेर पूर्ण रूपमा निश्चित हुनुहुन्न 😅
तर सत्य शीर्षक भन्दा कम सफा छ। एआईले डेटा इन्जिनियरिङलाई पूर्ण रूपमा परिवर्तन गरिरहेको छ। यसले सुस्त, दोहोर्याउन सकिने बिटहरूलाई स्वचालित गर्दैछ। यसले "मलाई थाहा छ म के चाहन्छु तर वाक्य रचना सम्झन सक्दिन" क्षणहरूलाई गति दिइरहेको छ। यसले नयाँ प्रकारको अराजकता पनि जन्माइरहेको छ।.
त्यसैले हात हल्लाउने आशावाद वा विनाशकारी आतंक बिना, यसलाई राम्रोसँग प्रस्तुत गरौं।.
यसपछि पढ्न मन लाग्ने लेखहरू:
🔗 के एआईले रेडियोलोजिस्टहरूलाई प्रतिस्थापन गर्नेछ?
इमेजिङ एआईले कार्यप्रवाह, शुद्धता र भविष्यका भूमिकाहरूलाई कसरी परिवर्तन गर्छ।.
🔗 के एआईले लेखाकारहरूलाई प्रतिस्थापन गर्नेछ?
एआईले कुन लेखा कार्यहरू स्वचालित बनाउँछ र के मानव रहन्छ हेर्नुहोस्।.
🔗 के एआईले लगानी बैंकरहरूलाई प्रतिस्थापन गर्नेछ?
सम्झौता, अनुसन्धान, र ग्राहक सम्बन्धहरूमा AI को प्रभाव बुझ्नुहोस्।.
🔗 के एआईले बीमा एजेन्टहरूलाई प्रतिस्थापन गर्नेछ?
एआईले बीमाङ्कन, बिक्री र ग्राहक समर्थनलाई कसरी रूपान्तरण गर्छ जान्नुहोस्।.
“एआईले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्छ” भन्ने प्रश्न किन बारम्बार उठिरहन्छ 😬
डर एकदमै विशिष्ट ठाउँबाट आउँछ: डेटा इन्जिनियरिङमा धेरै दोहोरिने काम हुन्छ।
-
SQL लेखन र रिफ्याक्टरिङ
-
इन्जेसन स्क्रिप्टहरू निर्माण गर्दै
-
एउटा स्कीमाबाट अर्को स्कीमामा फिल्डहरूको म्यापिङ
-
परीक्षण र आधारभूत कागजातहरू सिर्जना गर्दै
-
पाइपलाइन विफलताहरू डिबग गर्दै जुन ... एक प्रकारको अनुमानित छ
दोहोरिने ढाँचाहरूमा एआई असामान्य रूपमा राम्रो छ। र डेटा इन्जिनियरिङको एक भाग ठ्याक्कै त्यस्तै हो - ढाँचाहरूमा स्ट्याक गरिएका ढाँचाहरू। GitHub Copilot कोड सुझावहरू
साथै, उपकरण इकोसिस्टमले पहिले नै जटिलता "लुकाउँदै" छ:
-
व्यवस्थित ELT कनेक्टरहरू Fivetran कागजातहरू
-
सर्भरलेस कम्प्युट AWS ल्याम्ब्डा (सर्भरलेस कम्प्युट)
-
एक-क्लिक गोदाम प्रावधान
-
स्वतः-स्केलिंग अर्केस्ट्रेसन अपाचे एयरफ्लो कागजातहरू
-
घोषणात्मक रूपान्तरण फ्रेमवर्क dbt भनेको के हो?
त्यसैले जब AI देखा पर्दछ, यो अन्तिम टुक्रा जस्तो महसुस हुन सक्छ। यदि स्ट्याक पहिले नै सारांशित छ, र AI ले ग्लु कोड लेख्न सक्छ ... के बाँकी छ? 🤷
तर मानिसहरूले छोड्ने कुरा यहाँ छ: डेटा इन्जिनियरिङ मुख्यतया टाइपिङ होइन। टाइपिङ सजिलो भाग हो। गाह्रो भाग भनेको अस्पष्ट, राजनीतिक, परिवर्तनशील व्यावसायिक वास्तविकतालाई भरपर्दो प्रणाली जस्तो व्यवहार गर्नु हो।
अनि एआई अझै पनि त्यो धमिलोपनसँग संघर्ष गरिरहेको छ। मानिसहरू पनि संघर्ष गरिरहेका छन् - तिनीहरूले अझ राम्रोसँग सुधार गर्छन्।.
डेटा इन्जिनियरहरूले दिनभरि वास्तवमा के गर्छन् (अनौठो सत्य) 🧱
स्पष्ट कुरा गरौं - "डेटा इन्जिनियर" भन्ने पदको शीर्षक सुन्दा तपाईं शुद्ध गणितबाट रकेट इन्जिनहरू निर्माण गरिरहनुभएको जस्तो लाग्छ। व्यवहारमा, तपाईं विश्वास।
एउटा सामान्य दिन भनेको "नयाँ एल्गोरिदमहरू आविष्कार गर्नु" भन्दा कम र बढी हो:
-
डेटा परिभाषाहरूको बारेमा अपस्ट्रीम टोलीहरूसँग वार्ता गर्दै (पीडादायी तर आवश्यक)
-
मेट्रिक किन परिवर्तन भयो (र यो वास्तविक हो कि होइन) भनेर अनुसन्धान गर्दै
-
स्कीमा ड्रिफ्ट र "कसैले मध्यरातमा स्तम्भ थप्यो" आश्चर्यहरू ह्यान्डल गर्दै
-
पाइपलाइनहरू अक्षम, पुन: प्राप्तियोग्य, अवलोकनयोग्य छन् भनी सुनिश्चित गर्ने
-
डाउनस्ट्रीम विश्लेषकहरूले गल्तिले बकवास ड्यासबोर्डहरू निर्माण नगरून् भनेर रेलिङहरू सिर्जना गर्दै
-
तपाईंको गोदाम पैसाको आगोमा परिणत नहोस् भनेर लागत व्यवस्थापन गर्ने 🔥
-
पहुँच, लेखा परीक्षण, अनुपालन, अवधारण नीतिहरू सुरक्षित गर्ने GDPR सिद्धान्तहरू (युरोपेली आयोग) भण्डारण सीमा (ICO)
-
तपाईंलाई DM नगरीकनै मानिसहरूले वास्तवमा प्रयोग गर्न सक्ने डेटा उत्पादनहरू निर्माण गर्ने २० प्रश्नहरू
कामको ठूलो हिस्सा सामाजिक र परिचालन हो:
-
"यो टेबल कसको हो?"
-
"के यो परिभाषा अझै पनि मान्य छ?"
-
"CRM ले किन डुप्लिकेटहरू निर्यात गरिरहेको छ?"
-
"के हामी यो मेट्रिकलाई बिना लाज कार्यकारीहरूलाई पठाउन सक्छौं?" 😭
पक्कै पनि, AI ले यसको केही भागहरूमा मद्दत गर्न सक्छ। तर यसलाई पूर्ण रूपमा प्रतिस्थापन गर्नु... एक झन्झटिलो काम हो।.
डेटा इन्जिनियरिङ भूमिकाको बलियो संस्करण के हो? ✅
यो खण्ड महत्त्वपूर्ण छ किनकि प्रतिस्थापन वार्ताले सामान्यतया डेटा इन्जिनियरहरू मुख्यतया "पाइपलाइन निर्माणकर्ताहरू" हुन् भन्ने मान्दछ। यो शेफहरूले मुख्यतया "तरकारीहरू काट्छन्" भन्ने अनुमान गर्नु जस्तै हो। यो कामको अंश हो, तर यो काम होइन।.
डेटा इन्जिनियरको बलियो संस्करणको अर्थ सामान्यतया उनीहरूले यी मध्ये धेरैजसो गर्न सक्छन्:
-
परिवर्तनको लागि डिजाइन
डेटा परिवर्तन हुन्छ। टोलीहरू परिवर्तन हुन्छन्। उपकरणहरू परिवर्तन हुन्छन्। एक असल इन्जिनियरले यस्ता प्रणालीहरू निर्माण गर्दछन् जुन वास्तविकताले हाच्छिउँ गर्दा पनि ध्वस्त हुँदैनन् 🤧 -
सम्झौता र अपेक्षाहरू परिभाषित गर्नुहोस्
"ग्राहक" को अर्थ के हो? "सक्रिय" को अर्थ के हो? विवाद ढिलो आइपुग्दा के हुन्छ? सम्झौताहरूले फेन्सी कोडले भन्दा बढी अराजकतालाई रोक्छ। खुला डेटा सम्झौता मानक (ODCS) ODCS (GitHub) -
सबै कुरामा अवलोकनयोग्यता निर्माण गर्नुहोस्
"के यो चल्यो" मात्र होइन तर "के यो सही रूपमा चल्यो"। ताजापन, भोल्युम विसंगतिहरू, शून्य विस्फोटहरू, वितरण परिवर्तनहरू। डेटा अवलोकनयोग्यता (डाइनाट्रेस) डेटा अवलोकनयोग्यता भनेको के हो? -
वयस्कको लागि
गति बनाम शुद्धता, लागत बनाम विलम्बता, लचिलोपन बनाम सरलता जस्ता सम्झौताहरू गर्नुहोस्। कुनै पनि उत्तम पाइपलाइन हुँदैन, केवल पाइपलाइनहरू जुन तपाईंसँग बाँच्न सक्नुहुन्छ। -
व्यवसायिक आवश्यकताहरूलाई टिकाउ प्रणालीमा रूपान्तरण गर्नुहोस्
मानिसहरूले मेट्रिक्स माग्छन्, तर उनीहरूलाई डेटा उत्पादन चाहिन्छ। एआईले कोड ड्राफ्ट गर्न सक्छ, तर यसले जादुई रूपमा व्यवसायिक बारुदी सुरुङहरू थाहा पाउन सक्दैन। -
डेटालाई शान्त राख्नुहोस्
डेटा प्लेटफर्मको सबैभन्दा ठूलो प्रशंसा भनेको यसको बारेमा कोही पनि कुरा गर्दैन। अप्रत्याशित डेटा राम्रो डेटा हो। प्लम्बिंग जस्तै। तपाईंले यो तब मात्र याद गर्नुहुन्छ जब यो असफल हुन्छ 🚽
यदि तपाईं यी कामहरू गर्दै हुनुहुन्छ भने, "के AI ले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ?" भन्ने प्रश्न अलि कम सुनिन थाल्छ... एआईले स्वामित्वलाई होइन, कार्यहरूलाई प्रतिस्थापन गर्न सक्छ ।
जहाँ एआईले पहिले नै डेटा इन्जिनियरहरूलाई मद्दत गरिरहेको छ (र यो साँच्चै राम्रो छ) 🤖✨
एआई केवल मार्केटिंग मात्र होइन। राम्रोसँग प्रयोग गरिएको, यो एक वैध बल गुणक हो।.
१) छिटो SQL र रूपान्तरण कार्य
-
जटिल जोडहरूको मस्यौदा तयार गर्दै
-
तपाईंले सोच्नै नहुने विन्डो प्रकार्यहरू लेख्दै
-
सरल भाषाको तर्कलाई क्वेरी स्केलेटनमा परिणत गर्दै
-
पढ्न सकिने CTEs मा कुरूप प्रश्नहरूको पुन:फ्याक्टरिङ गर्दै SQL को लागि GitHub Copilot
यो ठूलो छ किनकि यसले "खाली पृष्ठ" प्रभावलाई कम गर्छ। तपाईंले अझै पनि प्रमाणीकरण गर्न आवश्यक छ, तर तपाईंले ०% को सट्टा ७०% बाट सुरु गर्नुहुन्छ।.
२) डिबगिङ र जरा कारण ब्रेडक्रम्ब्स
एआई निम्न कुराहरूमा राम्रो छ:
-
त्रुटि सन्देशहरू व्याख्या गर्दै
-
कहाँ हेर्ने भनेर सुझाव दिँदै
-
"चेक स्किमा मिसम्याच" प्रकारका चरणहरू सिफारिस गर्दै GitHub Copilot
यो एक अथक जुनियर इन्जिनियर हुनु जस्तै हो जो कहिल्यै सुत्दैन र कहिलेकाहीं आत्मविश्वासका साथ झूट बोल्छ 😅
३) कागजात र डेटा क्याटलग संवर्धन
स्वतः उत्पन्न:
-
स्तम्भ विवरणहरू
-
मोडेल सारांशहरू
-
वंश व्याख्याहरू
-
"यो तालिका केको लागि प्रयोग गरिन्छ?" ड्राफ्ट dbt कागजातहरू
यो उत्तम छैन, तर यसले कागजात नभएका पाइपलाइनहरूको अभिशापलाई तोड्छ।.
४) मचान र जाँचहरूको परीक्षण गर्नुहोस्
एआईले प्रस्ताव गर्न सक्छ:
-
आधारभूत शून्य परीक्षणहरू
-
विशिष्टता जाँचहरू
-
सन्दर्भात्मक अखण्डता विचारहरू
-
"यो मेट्रिक कहिल्यै घट्नु हुँदैन" शैलीको दाबी dbt डेटा परीक्षणहरू महान अपेक्षाहरू: अपेक्षाहरू
फेरि - तपाईं अझै पनि के महत्त्वपूर्ण छ निर्णय गर्नुहुन्छ, तर यसले नियमित भागहरूलाई गति दिन्छ।.
५) पाइपलाइन "ग्लु" कोड
कन्फिग टेम्प्लेटहरू, YAML स्क्याफोल्डहरू, अर्केस्ट्रेसन DAG ड्राफ्टहरू। ती चीजहरू दोहोरिने छन् र AI ले ब्रेकफास्टमा दोहोरिने खान्छ 🥣 Apache Airflow DAGs
जहाँ एआई अझै पनि संघर्ष गरिरहेको छ (र यो यसको मूल हो) 🧠🧩
यो भाग सबैभन्दा महत्त्वपूर्ण छ, किनकि यसले वास्तविक बनावटको साथ प्रतिस्थापन प्रश्नको जवाफ दिन्छ।.
१) अस्पष्टता र परिवर्तनशील परिभाषाहरू
व्यापारिक तर्क विरलै स्पष्ट हुन्छ। मानिसहरूले वाक्यको बीचमा आफ्नो विचार परिवर्तन गर्छन्। "सक्रिय प्रयोगकर्ता" "सक्रिय भुक्तानी प्रयोगकर्ता" बन्छ "कहिलेकाहीं बाहेक फिर्ता बाहेक सक्रिय भुक्तानी प्रयोगकर्ता" बन्छ... तपाईंलाई थाहा छ यो कस्तो छ।.
एआईले त्यो अस्पष्टतालाई स्वीकार गर्न सक्दैन। यसले केवल अनुमान गर्न सक्छ।.
२) जवाफदेहिता र जोखिम
जब पाइपलाइन बिग्रन्छ र कार्यकारी ड्यासबोर्डले बकवास देखाउँछ, कसैले:
-
ट्राइज
-
प्रभाव सञ्चार गर्नुहोस्
-
यसलाई ठीक गर्नुहोस्
-
पुनरावृत्ति रोक्न
-
पोस्टमार्टम लेख्नुहोस्
-
व्यवसायले गत हप्ताको तथ्याङ्कलाई अझै पनि विश्वास गर्न सक्छ कि सक्दैन भन्ने निर्णय गर्नुहोस्।
एआईले सहयोग गर्न सक्छ, तर यो अर्थपूर्ण तरिकाले जवाफदेही हुन सक्दैन। संस्थाहरू भाइब्समा चल्दैनन् - तिनीहरू जिम्मेवारीमा चल्छन्।.
३) प्रणाली सोच
डेटा प्लेटफर्महरू पारिस्थितिक प्रणाली हुन्: इन्जेसन, भण्डारण, रूपान्तरण, अर्केस्ट्रेसन, शासन, लागत नियन्त्रण, SLA। एक तहको तरंगमा परिवर्तन। अपाचे एयरफ्लो अवधारणाहरू
एआईले विश्वव्यापी पीडा सिर्जना गर्ने स्थानीय अप्टिमाइजेसनहरू प्रस्ताव गर्न सक्छ। यो ढोका हटाएर चिच्याउने ढोका ठीक गर्नु जस्तै हो 😬
४) सुरक्षा, गोपनीयता, अनुपालन
यहीँनेर प्रतिस्थापन कल्पनाहरू मर्छन्।.
-
पहुँच नियन्त्रणहरू
-
पङ्क्ति-स्तर सुरक्षा स्नोफ्लेक पङ्क्ति पहुँच नीतिहरू BigQuery पङ्क्ति-स्तर सुरक्षा
-
NIST गोपनीयता फ्रेमवर्क ह्यान्डल गर्दै PII
-
रिटेन्सन नियमहरू भण्डारण सीमा (ICO) रिटेन्सन सम्बन्धी EU मार्गदर्शन
-
अडिट ट्रेल्स NIST SP 800-92 (लग व्यवस्थापन) CIS नियन्त्रण 8 (लेखापरीक्षण लग व्यवस्थापन)
-
डेटा रेसिडेन्सी सीमितताहरू
एआईले नीतिहरू मस्यौदा गर्न सक्छ, तर तिनीहरूलाई सुरक्षित रूपमा कार्यान्वयन गर्नु वास्तविक इन्जिनियरिङ हो।.
५) "अज्ञात अज्ञातहरू"
डेटा घटनाहरू प्रायः अप्रत्याशित हुन्छन्:
-
विक्रेता API ले चुपचाप अर्थशास्त्र परिवर्तन गर्छ।
-
समयक्षेत्रको धारणा उल्टिन्छ
-
ब्याकफिलले विभाजनको नक्कल बनाउँछ
-
पुन: प्रयास संयन्त्रले दोहोरो लेखन निम्त्याउँछ
-
नयाँ उत्पादन सुविधाले नयाँ कार्यक्रम ढाँचाहरू प्रस्तुत गर्दछ
परिस्थिति ज्ञात ढाँचा नभएको बेला एआई कमजोर हुन्छ।.
तुलना तालिका: व्यवहारमा के ले के घटाइरहेको छ 🧾🤔
तल एउटा व्यावहारिक दृष्टिकोण दिइएको छ। "मानिसहरूलाई प्रतिस्थापन गर्ने उपकरणहरू" होइन, तर निश्चित कार्यहरूलाई संकुचित गर्ने उपकरणहरू र दृष्टिकोणहरू।.
| उपकरण / दृष्टिकोण | दर्शक | मूल्यको अवस्था | यो किन काम गर्छ? |
|---|---|---|---|
| एआई कोड कोपाइलटहरू (SQL + पाइथन सहयोगीहरू) GitHub कोपाइलट | धेरै कोड लेख्ने इन्जिनियरहरू | निःशुल्क रूपमा भुक्तानी गर्न मिल्ने | स्क्याफोल्डिङ, रिफ्याक्टर, सिन्ट्याक्समा उत्कृष्ट... कहिलेकाहीँ एकदमै विशिष्ट तरिकाले प्रयोग गरिन्छ। |
| व्यवस्थित ELT कनेक्टरहरू Fivetran | इन्जेसन निर्माण गर्दा टोलीहरू थाकेका छन् | सदस्यता-y | कस्टम इन्जेसन पीडा हटाउँछ, तर रमाइलो नयाँ तरिकाहरूमा ब्रेक गर्छ |
| डेटा अवलोकनयोग्यता प्लेटफर्महरू डेटा अवलोकनयोग्यता (डाइनाट्रेस) | SLA हरूको स्वामित्व भएको जो कोही पनि | मध्यदेखि उद्यमसम्म | पाइपलाइनहरूको लागि धुवाँ अलार्म जस्तै - चाँडै नै असामान्यताहरू पत्ता लगाउँछ 🔔 |
| रूपान्तरण फ्रेमवर्क (घोषणात्मक मोडेलिङ) dbt | एनालिटिक्स + DE हाइब्रिडहरू | सामान्यतया उपकरण + गणना | तर्कलाई मोड्युलर र परीक्षणयोग्य बनाउँछ, कम स्पेगेटी |
| डेटा क्याटलग + सिमेन्टिक तहहरू dbt सिमेन्टिक तह | मेट्रिक भ्रम भएका संस्थाहरू | व्यवहारमा निर्भर गर्दछ, | "सत्य" लाई एक पटक परिभाषित गर्दछ - अनन्त मेट्रिक बहसहरूलाई कम गर्दछ |
| टेम्प्लेटहरू सहितको अर्केस्ट्रेसन अपाचे एयरफ्लो | प्लेटफर्म-मनपर्ने टोलीहरू | खुला + सञ्चालन लागत | कार्यप्रवाहलाई मानकीकृत गर्छ; कम स्नोफ्लेक DAG हरू |
| एआई-सहायता प्राप्त कागजात dbt कागजात उत्पादन | कागजात लेख्न मन नपराउने टोलीहरू | सस्तो देखि मध्यम | ज्ञान हराउँदैन भनेर "पर्याप्त राम्रो" कागजातहरू बनाउँछ |
| स्वचालित शासन नीतिहरू NIST गोपनीयता ढाँचा | नियमन गरिएको वातावरण | इन्टरप्राइज-वाई | नियमहरू लागू गर्न मद्दत गर्छ - तर अझै पनि नियमहरू डिजाइन गर्न मानिसहरू चाहिन्छ। |
के छुटेको छ याद गर्नुहोस्: "डेटा इन्जिनियरहरू हटाउन बटन थिच्नुहोस्" भन्ने पङ्क्ति। हो... त्यो पङ्क्ति अवस्थित छैन 🙃
त्यसो भए... के एआईले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ, वा भूमिका परिवर्तन गर्नेछ? 🛠️
नाटकीय नभएको उत्तर यहाँ छ: एआईले कार्यप्रवाहका केही भागहरूलाई प्रतिस्थापन गर्नेछ, पेशालाई होइन।
तर यसले भूमिकालाई पुन: कन्फिगर गर्नेछ । र यदि तपाईंले त्यसलाई बेवास्ता गर्नुभयो भने, तपाईंले निचोड महसुस गर्नुहुनेछ।
के परिवर्तन हुन्छ:
-
कम समयमै बयलरप्लेट लेख्ने
-
कागजातहरू खोज्न कम समय
-
समीक्षा गर्ने, प्रमाणित गर्ने, डिजाइन गर्ने बढी समय
-
सम्झौता र गुणस्तर अपेक्षाहरू परिभाषित गर्न थप समय खुला डेटा अनुबंध मानक (ODCS)
-
उत्पादन, सुरक्षा, वित्तसँग बढी समय साझेदारी गर्नुहोस्
यो सूक्ष्म परिवर्तन हो: डेटा इन्जिनियरिङ "पाइपलाइनहरू निर्माण गर्ने" बारे कम र "भरपर्दो डेटा उत्पादन प्रणाली निर्माण गर्ने" बारे बढी हुन्छ।
अनि शान्त मोडमा, त्यो बढी मूल्यवान छ, कम होइन।.
साथै - र म यो भन्न गइरहेको छु कि यो नाटकीय सुनिए पनि - एआईले डेटा कलाकृतिहरू उत्पादन गर्न सक्ने व्यक्तिहरूको संख्या बढाउँछ, जसले गर्दा सम्पूर्ण कुरालाई स्वस्थ राख्न कसैको आवश्यकता बढ्छ। बढी आउटपुटको अर्थ बढी सम्भावित भ्रम हो। GitHub Copilot
यो त सबैलाई पावर ड्रिल दिए जस्तै हो। राम्रो! अब कसैले "कृपया पानीको पाइपमा ड्रिल नगर्नुहोस्" नियम लागू गर्नुपर्छ 🪠
नयाँ सीप स्ट्याक जुन मूल्यवान रहन्छ (जताततै AI भए पनि) 🧠⚙️
यदि तपाईं व्यावहारिक "भविष्य-प्रमाण" चेकलिस्ट चाहनुहुन्छ भने, यो यस्तो देखिन्छ:
प्रणाली डिजाइन मानसिकता
-
परिवर्तनलाई टिकाउने डेटा मोडलिङ
-
ब्याच बनाम स्ट्रिमिङ ट्रेडअफहरू
-
ढिलाइ, लागत, विश्वसनीयता सोच
डेटा गुणस्तर इन्जिनियरिङ
-
सम्झौताहरू, प्रमाणीकरणहरू, विसंगति पत्ता लगाउने खुला डेटा सम्झौता मानक (ODCS) डेटा अवलोकनयोग्यता (डाइनाट्रेस)
-
SLA, SLO, घटना प्रतिक्रिया बानीहरू
-
अनुशासनको साथ मूल कारण विश्लेषण (भाइब्स होइन)
शासन र विश्वास संरचना
-
पहुँच ढाँचाहरू
-
लेखा परीक्षण योग्यता NIST SP 800-92 (लग व्यवस्थापन)
-
डिजाइन अनुसार गोपनीयता NIST गोपनीयता ढाँचा
-
डेटा जीवनचक्र व्यवस्थापन अवधारणमा EU मार्गदर्शन
प्लेटफर्म सोच
-
पुन: प्रयोग गर्न मिल्ने टेम्प्लेटहरू, सुनौलो बाटोहरू
-
इन्जेसन, रूपान्तरण, परीक्षण फाइभट्रान डीबीटी डेटा परीक्षणहरूको
-
पग्लिँदैन र नपग्लिने स्व-सेवा उपकरणहरू
सञ्चार (हो, साँच्चै)
-
स्पष्ट कागजातहरू लेख्दै
-
परिभाषाहरू पङ्क्तिबद्ध गर्दै
-
विनम्रतापूर्वक तर दृढतापूर्वक "होइन" भन्नु
-
रोबोट जस्तो नभईकन सम्झौताको व्याख्या गर्दै 🤖
यदि तपाईंले यी गर्न सक्नुहुन्छ भने, "के एआईले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ?" भन्ने प्रश्न कम खतरनाक हुन्छ। एआई तपाईंको एक्सोस्केलेटन बन्छ, तपाईंको प्रतिस्थापन होइन।.
यथार्थपरक परिदृश्यहरू जहाँ केही डेटा इन्जिनियरिङ भूमिकाहरू संकुचित हुन्छन् 📉
ठीक छ, छिटो वास्तविकता जाँच गर्नुहोस्, किनकि यो सबै घाम र इमोजी कन्फेटी होइन 🎉
केही भूमिकाहरू बढी खुला छन्:
-
शुद्ध इन्जेसन-मात्र भूमिकाहरू जहाँ सबै कुरा मानक कनेक्टरहरू हुन् फाइभट्रान कनेक्टरहरू
-
टोलीहरूले न्यूनतम डोमेन सूक्ष्मताका साथ प्रायः दोहोरिने रिपोर्टिङ पाइपलाइनहरू गरिरहेका छन्
-
डेटा इन्जिनियरिङलाई "SQL बाँदर" को रूपमा व्यवहार गरिने संस्थाहरू (कठोर, तर सत्य)
-
कम स्वामित्वका भूमिकाहरू जहाँ काम केवल टिकट र कपी-पेस्ट मात्र हो
एआई प्लस व्यवस्थित टुलिङले ती आवश्यकताहरूलाई कम गर्न सक्छ।.
तर त्यहाँ पनि, प्रतिस्थापन सामान्यतया यस्तो देखिन्छ:
-
दोहोरिने एउटै काम गर्ने मानिसहरू कम छन्
-
प्लेटफर्म स्वामित्व र विश्वसनीयतामा बढी जोड
-
"एक व्यक्तिले धेरै पाइपलाइनहरूलाई समर्थन गर्न सक्छ" तर्फको परिवर्तन
त्यसैले हो - कर्मचारी संख्याको ढाँचा परिवर्तन हुन सक्छ। भूमिकाहरू विकसित हुन्छन्। शीर्षकहरू परिवर्तन हुन्छन्। त्यो भाग वास्तविक हो।.
तैपनि, भूमिकाको उच्च-स्वामित्व, उच्च-विश्वास संस्करण कायमै छ।.
समापन सारांश 🧾✅
के एआईले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ? मानिसहरूले कल्पना गरेको सफा र पूर्ण तरिकाले होइन।
एआईले गर्नेछ:
-
दोहोरिने कार्यहरू स्वचालित गर्नुहोस्
-
कोडिङ, डिबगिङ, र कागजातहरू छिटो बनाउनुहोस् SQL dbt कागजातहरूको लागि GitHub Copilot
-
पाइपलाइन उत्पादन लागत घटाउने
तर डेटा इन्जिनियरिङ मूल रूपमा निम्न बारे हो:
-
जवाफदेहिता
-
प्रणाली डिजाइन
-
विश्वास, गुणस्तर, र शासन खुला डेटा अनुबंध मानक (ODCS) NIST गोपनीयता रूपरेखा
-
अस्पष्ट व्यापारिक वास्तविकतालाई भरपर्दो डेटा उत्पादनहरूमा अनुवाद गर्दै
एआईले त्यसमा मद्दत गर्न सक्छ... तर यसले यसको "स्वामित्व" लिँदैन।.
यदि तपाईं डेटा इन्जिनियर हुनुहुन्छ भने, यो कदम सरल छ (सजिलो होइन, तर सरल):
स्वामित्व, गुणस्तर, प्लेटफर्म सोच, र सञ्चारमा भर पर्नुहोस्। तपाईंले महत्त्वपूर्ण भागहरू ह्यान्डल गर्दा एआईलाई बोइलरप्लेट ह्यान्डल गर्न दिनुहोस्।
अनि हो - कहिलेकाहीँ यसको अर्थ कोठामा वयस्क हुनु हो। आकर्षक होइन। शान्त रूपमा शक्तिशाली भए पनि 😄
के एआईले डाटा इन्जिनियरहरूलाई प्रतिस्थापन गर्नेछ?
यसले केही कार्यहरूलाई प्रतिस्थापन गर्नेछ, भर्याङ फेरबदल गर्नेछ, र उत्कृष्ट डाटा इन्जिनियरहरूलाई अझ मूल्यवान बनाउनेछ। वास्तविक कथा यही हो।
वास्तविक संसारको उदाहरण: एआई-सहायता प्राप्त डेटा पाइपलाइन समीक्षा कार्यप्रवाह निर्माण गर्दै 🛠️
परिदृश्य
एउटा सानो ई-कमर्स कम्पनीको कल्पना गर्नुहोस् जहाँ एक डेटा इन्जिनियर, दुई विश्लेषक र एउटा धेरै परिचित समस्या छ: भुक्तानी प्रदायकले क्षेत्रको नाम परिवर्तन गर्दा वित्त ड्यासबोर्ड बिग्रिरहन्छ।.
टोलीले पाइपलाइनको "स्वामित्व" एआईले लिओस् भन्ने चाहँदैन। त्यो जोखिमपूर्ण हुनेछ। बरु, तिनीहरूले नियमित तर महत्त्वपूर्ण कामको लागि एआईलाई पहिलो-ड्राफ्ट सहायकको रूपमा प्रयोग गर्छन्: dbt मोडेल स्केलेटन लेख्ने, परीक्षणहरू सुझाव दिने, कागजातहरू मस्यौदा गर्ने, र कोड समीक्षाको लागि चेकलिस्ट सिर्जना गर्ने।.
मानव डेटा इन्जिनियरसँग अझै पनि अन्तिम डिजाइन, डेटा परिभाषा, पहुँच नियमहरू, र उत्पादन तैनाती स्वामित्व हुन्छ। एआईले जटिल मध्य खण्डलाई मात्र गति दिन्छ।.
कार्यप्रणालीलाई के चाहिन्छ
एआई प्रयोग गर्नु अघि, टोलीले यसलाई उपयोगी हुन पर्याप्त सन्दर्भ दिन्छ:
-
अवस्थित भुक्तानी तालिका योजना
-
लक्षित वित्त मेट्रिक परिभाषाहरू, जस्तै "खुद राजस्व", "फिर्ता रकम", र "स्थगित भुक्तानी"
-
dbt मोडेलहरूको लागि नामकरण परम्पराहरू
-
स्वीकृत परीक्षणका उदाहरणहरू
-
भुक्तानी फिडको लागि छोटो डेटा सम्झौता
-
PII, असफल भुक्तानी, डुप्लिकेट, र ढिलो आइपुग्ने रेकर्डहरू ह्यान्डल गर्ने नियमहरू
-
विगतका घटनाहरूको नमूना, के गल्ती भयो र कसरी समाधान गरियो भन्ने सहित
मुख्य कुरा "AI लाई पाइपलाइन बनाउन भन्नुहोस्" होइन। त्यो धेरै अस्पष्ट छ।.
बलियो दृष्टिकोण यो हो: "यहाँ हाम्रा नियमहरू छन्, यहाँ योजना छ, यहाँ अपेक्षित व्यवहार छ। हामीले समीक्षा गर्न सक्ने केही ड्राफ्ट बनाउनुहोस्।"
उदाहरण निर्देशन
तपाईं हाम्रो भुक्तानी डेटाको लागि dbt मोडेलको मस्यौदा तयार गर्न मद्दत गर्दै हुनुहुन्छ। पहिलो-पास मोडेल, सुझाव गरिएका dbt परीक्षणहरू, र कागजात नोटहरू सिर्जना गर्न तलका स्किमा र नियमहरू प्रयोग गर्नुहोस्।.
मोडेलले order_id र payment_provider द्वारा दैनिक सेटल गरिएको राजस्व गणना गर्नुपर्छ। असफल भुक्तानीहरू बहिष्कार गर्नुहोस्, परीक्षण कारोबारहरू बहिष्कार गर्नुहोस्, र refund_status = "पुष्टि" हुँदा मात्र फिर्ताहरू घटाउनुहोस्।.
स्तम्भहरू आविष्कार नगर्नुहोस्। यदि आवश्यक स्तम्भ छुटेको छ भने, अनुमान गर्नुको सट्टा "मानव समीक्षाका लागि प्रश्नहरू" अन्तर्गत सूचीबद्ध गर्नुहोस्।.
विशिष्टता, शून्य मान, स्वीकृत मान, र राजस्व उचितताको लागि परीक्षणहरू पनि सुझाव दिनुहोस्। वित्तीय रिपोर्टिङलाई असर गर्न सक्ने कुनै पनि तर्कलाई फ्ल्याग गर्नुहोस्।.
यसलाई कसरी परीक्षण गर्ने
एउटा समझदार परीक्षण सानो र जानाजानी सांसारिक हुन्छ:
-
एआईलाई एउटा ज्ञात-राम्रो भुक्तानी योजना दिनुहोस् र यसले आविष्कार गर्ने क्षेत्रहरूलाई बेवास्ता गर्छ कि गर्दैन भनेर जाँच गर्नुहोस्।.
-
यसलाई रिफन्ड_स्टेटस स्तम्भ छुटेको एउटा स्किमा दिनुहोस् र अनुमान गर्नुको सट्टा यसले प्रश्न सोध्छ कि सोध्दैन हेर्नुहोस्।.
-
उत्पन्न गरिएको SQL लाई स्टेजिङ डेटासेट विरुद्ध चलाउनुहोस्, उत्पादन होइन।.
-
आउटपुटलाई म्यानुअली जाँच गरिएका २० भुक्तानी रेकर्डहरूसँग तुलना गर्नुहोस्।.
-
मर्ज गर्नु अघि विश्लेषक र डेटा इन्जिनियरलाई परिभाषाहरूको समीक्षा गर्न भन्नुहोस्।.
-
स्वीकृत परीक्षणहरू CI मा थप्नुहोस् ताकि पाइपलाइनले तैनाती पछि आफैंलाई जाँच गरिरहन्छ।.
महत्त्वपूर्ण कुरा भनेको तपाईंलाई सबैभन्दा बढी डर लाग्ने असफलता मोडहरूमा AI परीक्षण गर्नु हो: बनाइएका स्तम्भहरू, गलत राजस्व तर्क, छुटेको फिर्ता ह्यान्डलिङ, र मौन डुप्लिकेट पङ्क्तिहरू।.
नतिजा
उदाहरणीय परिणाम: यो कार्यप्रवाह प्रयोग गर्नु अघि र पछि तीन नमूना पाइपलाइन-परिवर्तन कार्यहरूको समयको आधारमा।.
एआई प्रयोग गर्नु अघि, इन्जिनियरले प्रति परिवर्तन लगभग ५ घण्टा ३० मिनेट बिताउँथे: लगभग २ घण्टा SQL लेख्न, १ घण्टा परीक्षणहरू सिर्जना गर्न, ४५ मिनेट कागजातहरू लेख्न, र बाँकी वित्तसँग एज केसहरू जाँच गर्न।.
पहिलो ड्राफ्टको लागि मात्र एआई प्रयोग गरिएको हुनाले, उही प्रकारको परिवर्तनले लगभग २ घण्टा १० मिनेट लियो। सबैभन्दा ठूलो बचत परीक्षण मचान र कागजात ड्राफ्टबाट भयो, जुन १ घण्टा ४५ मिनेटबाट घटेर लगभग २५ मिनेटमा झर्यो।.
मानव समीक्षा चरणमा अझै पनि लगभग ४५ मिनेट लाग्यो, र यसलाई हटाउनु हुँदैन।.
तीन-कार्य परीक्षणमा, एआईले १८ वटा जाँचहरू सुझाव दियो। इन्जिनियरले ११ वटा स्वीकार गरे, ५ वटा सम्पादन गरे र २ वटा अस्वीकार गरे किनभने उनीहरूले व्यापार नियमहरू ग्रहण गरे जुन सत्य थिएनन्। त्यो अस्वीकृति गणना महत्त्वपूर्ण छ: यसले कार्यप्रवाहलाई समीक्षा आवश्यक छ, अन्धविश्वास होइन भनेर प्रमाणित गर्दछ।.
के बिग्रन सक्छ?
एआईले पाइपलाइनलाई अहिलेको भन्दा पूर्ण देखाउन सक्छ।.
सामान्य असफलता बिन्दुहरू समावेश छन्:
-
विश्वसनीय लाग्ने स्तम्भहरू आविष्कार गर्दै
-
फिर्ता, चार्जब्याक र असफल भुक्तानीहरूलाई एउटै कुराको रूपमा व्यवहार गर्ने
-
दैनिक राजस्वमा समय क्षेत्र सम्बन्धी समस्याहरू छुटेका छन्
-
वित्तीय त्रुटिहरू नपक्रने सामान्य परीक्षणहरूको सुझाव दिने
-
आत्मविश्वासी लाग्ने तर अनिश्चितता लुकाउने कागजात लेख्ने
-
नमूना डेटामा ग्राहक विवरणहरू हुँदा गोपनीयता नियमहरू बिर्सनु
एउटा राम्रो नियम: एआईले मोडेलको मस्यौदा तयार गर्न सक्छ, तर मानिसले परिभाषा, पैसाको तर्क, पहुँच नियन्त्रण, र उत्पादन रिलीजमा हस्ताक्षर गर्नुपर्छ।.
व्यावहारिक टेकवे
डेटा इन्जिनियरिङमा एआईको मूल्यवान संस्करण "डेटा इन्जिनियरलाई बदल्नुहोस्" होइन। यो "खाली पृष्ठ हटाउनुहोस्, त्यसपछि कडा समीक्षा गर्नुहोस्" हो।.
यसको अर्थ छिटो SQL, छिटो परीक्षण, र राम्रो पहिलो-पास कागजात हो, जबकि इन्जिनियरले अझै पनि सबैभन्दा महत्त्वपूर्ण भागको स्वामित्व लिन्छ: डेटा सही, विश्वसनीय, सुरक्षित, र व्याख्यायोग्य छ कि छैन।.
सोधिने प्रश्न
के एआईले डेटा इन्जिनियरहरूलाई पूर्ण रूपमा प्रतिस्थापन गर्नेछ?
धेरैजसो संस्थाहरूमा, एआईले भूमिकालाई पूर्ण रूपमा मेटाउनुको सट्टा विशिष्ट कार्यहरू लिने सम्भावना बढी हुन्छ। यसले SQL ड्राफ्टिङ, पाइपलाइन स्क्याफोल्डिङ, कागजात पहिलो पास, र आधारभूत परीक्षण सिर्जनालाई गति दिन सक्छ। तर डेटा इन्जिनियरिङले स्वामित्व र जवाफदेहिता पनि बोक्छ, साथै अव्यवस्थित व्यापार वास्तविकतालाई भरपर्दो प्रणाली जस्तो व्यवहार गर्ने अनग्लामर काम पनि गर्छ। ती भागहरूमा अझै पनि मानिसहरूलाई "सही" कस्तो देखिन्छ भनेर निर्णय गर्न र चीजहरू बिग्रँदा जिम्मेवारी लिन आवश्यक छ।.
एआईले पहिले नै डाटा इन्जिनियरिङका कुन भागहरूलाई स्वचालित बनाउँदैछ?
एआईले दोहोरिने काममा उत्कृष्ट प्रदर्शन गर्छ: SQL ड्राफ्टिङ र रिफ्याक्टरिङ, dbt मोडेल स्केलेटनहरू उत्पन्न गर्ने, सामान्य त्रुटिहरू व्याख्या गर्ने, र कागजात रूपरेखाहरू उत्पादन गर्ने। यसले शून्य वा विशिष्टता जाँचहरू जस्ता स्क्याफोल्ड परीक्षणहरू पनि गर्न सक्छ र अर्केस्ट्रेसन उपकरणहरूको लागि टेम्प्लेट "ग्लु" कोड उत्पन्न गर्न सक्छ। जित गति हो - तपाईं काम गर्ने समाधानको नजिक सुरु गर्नुहुन्छ - तर तपाईंले अझै पनि शुद्धता प्रमाणित गर्न र यो तपाईंको वातावरणमा फिट हुन्छ भनेर सुनिश्चित गर्न आवश्यक छ।.
यदि एआईले SQL र पाइपलाइनहरू लेख्न सक्छ भने, डाटा इन्जिनियरहरूको लागि के बाँकी रहन्छ?
धेरै कुराहरू: डेटा सम्झौताहरू परिभाषित गर्ने, स्कीमा ड्रिफ्ट ह्यान्डल गर्ने, र पाइपलाइनहरू अक्षम, अवलोकनयोग्य र पुन: प्राप्तियोग्य छन् भनी सुनिश्चित गर्ने। डेटा इन्जिनियरहरूले मेट्रिक परिवर्तनहरूको अनुसन्धान गर्न, डाउनस्ट्रीम प्रयोगकर्ताहरूको लागि रेलिङहरू निर्माण गर्न, र लागत र विश्वसनीयता ट्रेडअफहरू व्यवस्थापन गर्न समय खर्च गर्छन्। काम प्रायः विश्वास निर्माण गर्ने र डेटा प्लेटफर्मलाई "शान्त" राख्ने, जसको अर्थ यति स्थिर हुन्छ कि कसैले पनि यसको बारेमा दिनहुँ सोच्नु पर्दैन।.
एआईले डेटा इन्जिनियरको दैनिक काममा कसरी परिवर्तन ल्याउँछ?
यसले सामान्यतया बोइलरप्लेट र "लुकअप समय" लाई ट्रिम गर्छ, त्यसैले तपाईंले टाइप गर्न कम समय र समीक्षा, प्रमाणीकरण र डिजाइन गर्न बढी समय खर्च गर्नुहुन्छ। त्यो परिवर्तनले सबै कुरा हातले कोडिङ गर्नुको सट्टा अपेक्षाहरू, गुणस्तर मापदण्डहरू, र पुन: प्रयोग गर्न मिल्ने ढाँचाहरू परिभाषित गर्ने भूमिकालाई अगाडि बढाउँछ। व्यवहारमा, तपाईंले उत्पादन, सुरक्षा, र वित्तसँग बढी साझेदारी कार्य गर्नुहुनेछ - किनभने प्राविधिक आउटपुट सिर्जना गर्न सजिलो हुन्छ, तर शासन गर्न गाह्रो हुन्छ।.
"सक्रिय प्रयोगकर्ता" जस्ता अस्पष्ट व्यावसायिक परिभाषाहरूसँग एआई किन संघर्ष गर्छ?
किनभने व्यापार तर्क स्थिर वा सटीक हुँदैन - यो परियोजनाको बीचमा परिवर्तन हुन्छ र सरोकारवाला अनुसार फरक हुन्छ। एआईले व्याख्याको मस्यौदा तयार पार्न सक्छ, तर परिभाषाहरू विकसित हुँदा वा द्वन्द्व सतहमा आउँदा निर्णयको स्वामित्व लिन सक्दैन। डेटा इन्जिनियरिङलाई प्रायः वार्ता, धारणाहरूको दस्तावेजीकरण र अस्पष्ट आवश्यकताहरूलाई टिकाउ सम्झौताहरूमा परिणत गर्न आवश्यक पर्दछ। त्यो "मानव पङ्क्तिबद्धता" कार्य एक मुख्य कारण हो जुन टुलिङ सुधार हुँदा पनि भूमिका गायब हुँदैन।.
के एआईले डेटा प्रशासन, गोपनीयता र अनुपालनको काम सुरक्षित रूपमा सम्हाल्न सक्छ?
एआईले नीतिहरूको मस्यौदा तयार गर्न वा दृष्टिकोणहरू सुझाव दिन मद्दत गर्न सक्छ, तर सुरक्षित कार्यान्वयनले अझै पनि वास्तविक इन्जिनियरिङ र सावधानीपूर्वक निरीक्षणको आवश्यकता पर्दछ। शासनमा पहुँच नियन्त्रणहरू, PII ह्यान्डलिङ, अवधारण नियमहरू, लेखा परीक्षणहरू, र कहिलेकाहीं आवासीय अवरोधहरू समावेश छन्। यी उच्च जोखिम क्षेत्रहरू हुन् जहाँ "लगभग सही" स्वीकार्य छैन। मानिसहरूले नियमहरू डिजाइन गर्नुपर्छ, कार्यान्वयन प्रमाणित गर्नुपर्छ, र अनुपालन परिणामहरूको लागि जवाफदेही रहनुपर्छ।.
एआईमा सुधार हुँदै जाँदा डेटा इन्जिनियरहरूका लागि कस्ता सीपहरू मूल्यवान रहन्छन्?
प्रणालीहरूलाई लचिलो बनाउने सीपहरू: प्रणाली डिजाइन सोच, डेटा गुणस्तर इन्जिनियरिङ, र प्लेटफर्म-मनको मानकीकरण। धेरै मानिसहरूले डेटा कलाकृतिहरू द्रुत रूपमा उत्पन्न गर्न सक्दा अनुबंध, अवलोकनयोग्यता, घटना प्रतिक्रिया बानी, र अनुशासित मूल कारण विश्लेषण अझ महत्त्वपूर्ण हुन्छ। सञ्चार पनि एक भिन्नता बन्छ - परिभाषाहरू पङ्क्तिबद्ध गर्ने, स्पष्ट कागजातहरू लेख्ने, र नाटक बिना ट्रेडअफहरू व्याख्या गर्ने डेटा विश्वसनीय राख्ने एक ठूलो भाग हो।.
एआई र व्यवस्थित टुलिङबाट कुन डेटा इन्जिनियरिङ भूमिकाहरू सबैभन्दा बढी जोखिममा छन्?
दोहोरिने इन्जेसन वा मानक रिपोर्टिङ पाइपलाइनहरूमा केन्द्रित भूमिकाहरू बढी खुला हुन्छन्, विशेष गरी जब व्यवस्थित ELT कनेक्टरहरूले धेरैजसो स्रोतहरू समेट्छन्। कम-स्वामित्व, टिकट-संचालित काम संकुचित हुन सक्छ किनभने AI र अमूर्तताले प्रति पाइपलाइन प्रयास घटाउँछ। तर यो सामान्यतया दोहोरिने कार्यहरू गर्ने कम मानिसहरू जस्तो देखिन्छ, "कुनै डेटा इन्जिनियरहरू छैनन्" होइन। विश्वसनीयता, गुणस्तर र विश्वासमा केन्द्रित उच्च-स्वामित्व भूमिकाहरू टिकाउ रहन्छन्।.
अराजकता सिर्जना नगरी म कसरी GitHub Copilot वा dbt जस्ता उपकरणहरू AI सँग प्रयोग गर्न सक्छु?
एआई आउटपुटलाई निर्णय होइन, मस्यौदाको रूपमा व्यवहार गर्नुहोस्। यसलाई क्वेरी स्केलेटनहरू उत्पन्न गर्न, पठनीयता सुधार गर्न, वा स्क्याफोल्ड dbt परीक्षणहरू र कागजातहरू प्रयोग गर्नुहोस्, त्यसपछि वास्तविक डेटा र किनारा केसहरू विरुद्ध प्रमाणित गर्नुहोस्। यसलाई बलियो परम्पराहरूसँग जोड्नुहोस्: अनुबंधहरू, नामकरण मानकहरू, अवलोकनयोग्यता जाँचहरू, र समीक्षा अभ्यासहरू। लक्ष्य भनेको विश्वसनीयता, लागत नियन्त्रण, वा शासनलाई त्याग नगरी छिटो डेलिभरी हो।.
सन्दर्भ सामग्रीहरू
-
युरोपेली आयोग - डेटा सुरक्षाको व्याख्या: GDPR सिद्धान्तहरू - commission.europa.eu
-
सूचना आयुक्तको कार्यालय (ICO) - भण्डारण सीमा - ico.org.uk
-
युरोपेली आयोग - डेटा कति समयसम्म राख्न सकिन्छ र के यसलाई अद्यावधिक गर्न आवश्यक छ? - commission.europa.eu
-
राष्ट्रिय मानक तथा प्रविधि संस्थान (NIST) - गोपनीयता रूपरेखा - nist.gov
-
NIST कम्प्युटर सुरक्षा स्रोत केन्द्र (CSRC) - SP 800-92: कम्प्युटर सुरक्षा लग व्यवस्थापनको लागि गाइड - csrc.nist.gov
-
इन्टरनेट सुरक्षा केन्द्र (CIS) - अडिट लग व्यवस्थापन (CIS नियन्त्रणहरू) - cisecurity.org
-
स्नोफ्लेक कागजात - पङ्क्ति पहुँच नीतिहरू - docs.snowflake.com
-
गुगल क्लाउड डकुमेन्टेसन - बिगक्वेरी पङ्क्ति-स्तर सुरक्षा - docs.cloud.google.com
-
BITOL - खुला डेटा अनुबंध मानक (ODCS) v3.1.0 - bitol-io.github.io
-
BITOL (GitHub) - खुला डेटा अनुबंध मानक - github.com
-
अपाचे एयरफ्लो - कागजात (स्थिर) - airflow.apache.org
-
अपाचे एयरफ्लो - DAGs (मूल अवधारणाहरू) - airflow.apache.org
-
dbt ल्याब्स डकुमेन्टेसन - dbt भनेको के हो? - docs.getdbt.com
-
dbt ल्याब्स डकुमेन्टेसन - dbt मोडेलहरूको बारेमा - docs.getdbt.com
-
dbt ल्याब्स डकुमेन्टेसन - डकुमेन्टेसन - docs.getdbt.com
-
dbt ल्याब्स कागजात - डेटा परीक्षण - docs.getdbt.com
-
dbt ल्याब्स डकुमेन्टेसन - dbt सिमेन्टिक लेयर - docs.getdbt.com
-
फाइभट्रान डकुमेन्टेसन - सुरु गर्दै - fivetran.com
-
फाइभट्रान - कनेक्टरहरू - fivetran.com
-
AWS कागजात - AWS ल्याम्ब्डा विकासकर्ता गाइड - docs.aws.amazon.com
-
GitHub - GitHub सह-पायलट - github.com
-
GitHub कागजातहरू - GitHub Copilot को साथ तपाईंको IDE मा कोड सुझावहरू प्राप्त गर्दै - docs.github.com
-
माइक्रोसफ्ट लर्न - SQL को लागि GitHub कोपाइलट (VS कोड एक्सटेन्सन) - learn.microsoft.com
-
डायनाट्रेस कागजात - डेटा अवलोकनयोग्यता - docs.dynatrace.com
-
डाटाग्यालेक्सी - डाटा अवलोकनयोग्यता भनेको के हो? - datagalaxy.com
-
उत्कृष्ट अपेक्षाहरूको दस्तावेजीकरण - अपेक्षाहरूको सिंहावलोकन - docs.greatexpectations.io