پاسخ کوتاه: هوش مصنوعی به طور کامل جایگزین مهندسان داده نخواهد شد؛ بلکه کارهای تکراری مانند تهیه پیشنویس SQL، چارچوببندی پایپلاین، آزمایشها و مستندسازی را خودکار خواهد کرد. اگر نقش شما عمدتاً کار با مالکیت کم و تیکتمحور است، بیشتر در معرض خطر قرار دارد؛ اگر قابلیت اطمینان، تعاریف، حاکمیت و پاسخ به حوادث را در اختیار دارید، هوش مصنوعی عمدتاً شما را سریعتر میکند.
نکات کلیدی:
مالکیت: پاسخگویی در قبال نتایج را در اولویت قرار دهید، نه فقط تولید سریع کد.
کیفیت: تستها، قابلیت مشاهده و قراردادها را بسازید تا خطوط لوله قابل اعتماد باقی بمانند.
مدیریت: حریم خصوصی، کنترل دسترسی، نگهداری و ردیابیهای حسابرسی را در مالکیت انسان نگه دارید.
مقاومت در برابر سوء استفاده: خروجیهای هوش مصنوعی را به عنوان پیشنویس در نظر بگیرید؛ آنها را بررسی کنید تا از اشتباههای بیمورد جلوگیری شود.
تغییر نقش: زمان کمتری را صرف تایپ کردن مطالب تکراری و زمان بیشتری را صرف طراحی سیستمهای بادوام کنید.
اگر بیش از پنج دقیقه در تیمهای داده وقت گذرانده باشید، این جمله را شنیدهاید - که گاهی زمزمه میشود، و گاهی مانند یک پیچش داستانی در طول جلسه مطرح میشود: آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد؟
و... میفهمم. هوش مصنوعی میتواند SQL تولید کند، خطوط لوله بسازد، ردیابی پشته را توضیح دهد، مدلهای dbt را پیشنویس کند، حتی با اطمینان نگرانکنندهای طرحهای انبار را پیشنهاد دهد. GitHub Copilot برای SQL درباره مدلهای dbt GitHub Copilot
مثل این است که به یک لیفتراک نگاه کنید که در حال یادگیری تردستی است. چشمگیر، کمی نگرانکننده، و شما کاملاً مطمئن نیستید که این برای شغل شما چه معنایی دارد 😅
اما حقیقت به اندازه تیتر مرتب و تمیز نیست. هوش مصنوعی کاملاً در حال تغییر مهندسی دادهها است. بخشهای کسلکننده و تکراری را خودکار میکند. لحظههای «میدانم چه میخواهم اما نمیتوانم نحو را به خاطر بیاورم» را سرعت میبخشد. همچنین انواع جدیدی از هرج و مرج را ایجاد میکند.
پس بیایید آن را به درستی طرح کنیم، بدون خوشبینیِ دست و پا چلفتی یا وحشتِ نابودی.
مقالاتی که شاید بعد از این مطلب دوست داشته باشید بخوانید:
🔗 آیا هوش مصنوعی جایگزین رادیولوژیستها خواهد شد؟
چگونه هوش مصنوعی تصویربرداری، گردش کار، دقت و نقشهای آینده را تغییر میدهد.
🔗 آیا هوش مصنوعی جایگزین حسابداران خواهد شد؟
ببینید کدام وظایف حسابداری توسط هوش مصنوعی خودکارسازی میشوند و کدام وظایف توسط انسان انجام میشوند.
🔗 آیا هوش مصنوعی جایگزین بانکداران سرمایهگذاری خواهد شد؟
تأثیر هوش مصنوعی را بر معاملات، تحقیقات و روابط با مشتری درک کنید.
🔗 آیا هوش مصنوعی جایگزین نمایندگان بیمه خواهد شد؟
بیاموزید که چگونه هوش مصنوعی، بیمه گری، فروش و پشتیبانی مشتری را متحول میکند.
چرا سوال «هوش مصنوعی جایگزین مهندسان داده میشود» مدام مطرح میشود 😬
این ترس از یک جای بسیار خاص ناشی میشود: مهندسی داده کارهای تکراری زیادی دارد.
-
نوشتن و بازسازی SQL
-
ساخت اسکریپتهای مصرف
-
نگاشت فیلدها از یک طرحواره به طرحواره دیگر
-
ایجاد تستها و مستندات اولیه
-
اشکالزدایی از خطاهای خط لوله که ... تا حدودی قابل پیشبینی هستند
هوش مصنوعی به طور غیرمعمولی در الگوهای تکرارپذیر خوب است. و بخش بزرگی از مهندسی داده دقیقاً همین است - الگوهایی که روی هم انباشته میشوند. پیشنهادات کد GitHub Copilot
همچنین، اکوسیستم ابزارها از قبل پیچیدگی را «پنهان» کرده است:
-
کانکتورهای ELT مدیریتشده Fivetran
-
محاسبات بدون سرور AWS Lambda (محاسبات بدون سرور)
-
تجهیز انبار با یک کلیک
-
تنظیم خودکار مقیاسپذیری آپاچی ایرفلو
-
چارچوبهای تبدیل اعلانی dbt چیست؟
بنابراین وقتی هوش مصنوعی ظاهر میشود، میتواند مانند آخرین قطعه احساس شود. اگر پشته از قبل انتزاعی شده باشد و هوش مصنوعی بتواند کد چسب را بنویسد... چه چیزی باقی میماند؟ 🤷
اما نکتهای که مردم از آن غافل میشوند این است: مهندسی داده عمدتاً تایپ کردن نیست. تایپ کردن بخش آسان آن است. بخش سخت آن، وادار کردن واقعیت مبهم، سیاسی و متغیر کسبوکار به رفتاری قابل اعتماد است.
و هوش مصنوعی هنوز با آن تاریکی دست و پنجه نرم میکند. انسانها هم در این مشکل دست و پنجه نرم میکنند - آنها فقط بداههپردازی بهتری انجام میدهند.
کاری که مهندسان داده واقعاً تمام روز انجام میدهند (حقیقت ناخوشایند) 🧱
بیایید رک باشیم - عنوان شغلی «مهندس داده» مثل این است که شما از ریاضی محض موتور موشک بسازید. در عمل، شما در حال ایجاد اعتماد.
یک روز معمولی کمتر درگیر «اختراع الگوریتمهای جدید» و بیشتر درگیر موارد زیر است:
-
مذاکره با تیمهای بالادستی در مورد تعاریف دادهها (دردناک اما ضروری)
-
بررسی دلیل تغییر یک معیار (و اینکه آیا این تغییر واقعی است)
-
مدیریت رانش طرحواره و غافلگیریهای «کسی نیمهشب یک ستون اضافه کرد»
-
اطمینان از اینکه خطوط لوله، خود-توان، قابل بازیابی و قابل مشاهده هستند
-
ایجاد گاردریلهایی برای جلوگیری از اشتباه تحلیلگران پاییندستی در ساخت داشبوردهای بیمعنی
-
مدیریت هزینهها تا انبار شما به آتش پول تبدیل نشود 🔥
-
ایمنسازی دسترسی، حسابرسی، انطباق، سیاستهای نگهداری اصول GDPR (کمیسیون اروپا) محدودیت ذخیرهسازی (ICO)
-
ساخت محصولات دادهای که مردم بتوانند بدون پیام دادن به شما از آنها استفاده کنند - 20 سوال
بخش بزرگی از این شغل، اجتماعی و عملیاتی است:
-
«این میز مال کیست؟»
-
«آیا این تعریف هنوز معتبر است؟»
-
«چرا CRM دادههای تکراری را صادر میکند؟»
-
«میتونیم این معیار رو بدون خجالت به مدیران اجرایی منتقل کنیم؟» 😭
مطمئناً هوش مصنوعی میتواند در بخشهایی از این امر کمک کند. اما جایگزینی کامل آن ... یک کار طاقتفرسا است.
چه چیزی یک نسخه قوی از نقش مهندسی داده را میسازد؟ ✅
این بخش اهمیت دارد زیرا صحبتهای مربوط به جایگزینی معمولاً فرض را بر این میگذارد که مهندسان داده عمدتاً «سازندگان خطوط لوله» هستند. این مثل این است که فرض کنیم سرآشپزها عمدتاً «سبزی خرد میکنند». این بخشی از کار است، اما خودِ شغل نیست.
یک نسخه قوی از یک مهندس داده معمولاً به این معنی است که آنها میتوانند اکثر این موارد را انجام دهند:
-
طراحی برای تغییر
دادهها تغییر میکنند. تیمها تغییر میکنند. ابزارها تغییر میکنند. یک مهندس خوب سیستمهایی میسازد که هر بار واقعیت عطسه میکند، از هم نمیپاشند 🤧 -
تعریف قراردادها و انتظارات
«مشتری» به چه معناست؟ «فعال» به چه معناست؟ وقتی یک ردیف دیر میرسد چه اتفاقی میافتد؟ قراردادها بیشتر از کدهای پیچیده از هرج و مرج جلوگیری میکنند. استاندارد قرارداد داده باز (ODCS) ODCS (GitHub) -
قابلیت مشاهده را در همه چیز بگنجانید
نه فقط «آیا اجرا شد» بلکه «آیا به درستی اجرا شد». تازگی، ناهنجاریهای حجم، انفجارهای تهی، تغییرات توزیع. قابلیت مشاهده دادهها (Dynatrace) قابلیت مشاهده دادهها چیست؟ -
مثل یک بزرگسال،
بین سرعت در مقابل صحت، هزینه در مقابل تأخیر، انعطافپذیری در مقابل سادگی، تعادل برقرار کنید. هیچ خط لوله بینقصی وجود ندارد، فقط خطوط لولهای وجود دارند که میتوانید با آنها کنار بیایید. -
نیازهای تجاری را به سیستمهای بادوام تبدیل کنید.
مردم معیارها را درخواست میکنند، اما آنچه نیاز دارند یک محصول دادهای است. هوش مصنوعی میتواند کد را تهیه کند، اما نمیتواند به طور جادویی مینهای زمینی تجاری را بشناسد. -
دادهها را ساکت نگه دارید.
بالاترین تعریف برای یک پلتفرم داده این است که هیچکس در مورد آن صحبت نکند. دادههای بیوقفه، دادههای خوبی هستند. مثل لولهکشی. فقط وقتی متوجه آنها میشوید که از کار میافتند 🚽
اگر این کارها را انجام میدهید، سوال «آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد؟» کمی بیربط به نظر میرسد. هوش مصنوعی میتواند جایگزین وظایف، نه مالکیت.
جایی که هوش مصنوعی همین الان هم به مهندسان داده کمک میکند (و واقعاً عالی است) 🤖✨
هوش مصنوعی فقط بازاریابی نیست. اگر به خوبی استفاده شود، یک نیروی فزایندهی مشروع است.
۱) SQL و کار تبدیل سریعتر
-
ترسیم اتصالات پیچیده
-
نوشتن توابع پنجرهای که ترجیح میدهید به آنها فکر نکنید
-
تبدیل منطق زبان ساده به اسکلتهای پرسوجو
-
بازسازی کوئریهای زشت به CTEهای خوانا در GitHub Copilot برای SQL
این خیلی مهم است زیرا اثر «صفحه خالی» را کاهش میدهد. شما هنوز هم نیاز به اعتبارسنجی دارید، اما به جای ۰٪ از ۷۰٪ شروع میکنید.
۲) اشکالزدایی و ریشهیابی علت خطا در breadcrumbs
هوش مصنوعی در موارد زیر عملکرد مناسبی دارد:
-
توضیح پیامهای خطا
-
پیشنهاد دادن که کجا را جستجو کنیم
-
توصیه مراحل تایپ «بررسی عدم تطابق طرحواره» GitHub Copilot
مثل این است که یک مهندس جوان خستگیناپذیر داشته باشید که هرگز نمیخوابد و گاهی اوقات با اطمینان دروغ میگوید 😅
۳) مستندسازی و غنیسازی کاتالوگ دادهها
تولید خودکار:
-
توضیحات ستون
-
خلاصه مدلها
-
توضیحات دودمان
-
پیشنویس اسناد dbt با عنوان «این جدول برای چه کاری استفاده میشود؟»
بینقص نیست، اما نفرین خطوط لولهی مستند نشده را میشکند.
۴) داربستها را آزمایش و بررسی کنید
هوش مصنوعی میتواند پیشنهاد دهد:
-
تستهای پایهای null
-
بررسیهای منحصر به فرد بودن
-
ایدههای یکپارچگی ارجاعی
-
ادعاهای سبک «این معیار هرگز نباید کاهش یابد» آزمونهای دادههای dbt انتظارات بزرگ: انتظارات
باز هم - شما هنوز تصمیم میگیرید که چه چیزی مهم است، اما این کار بخشهای روتین را سرعت میبخشد.
۵) کد «چسب» خط لوله
قالبهای پیکربندی، چارچوبهای YAML، پیشنویسهای DAG برای تنظیم و هماهنگسازی. این چیزها تکراری هستند و هوش مصنوعی هم چیزهای تکراری را به عنوان صبحانه میخورد 🥣 DAGهای Apache Airflow
جایی که هوش مصنوعی هنوز در حال تقلا است (و این هسته اصلی آن است) 🧠🧩
این بخشی است که بیشترین اهمیت را دارد، زیرا به سوال جایگزینی با بافت واقعی پاسخ میدهد.
۱) ابهام و تغییر تعاریف
منطق کسبوکار به ندرت واضح است. مردم در اواسط جمله نظرشان را عوض میکنند. «کاربر فعال» تبدیل میشود به «کاربر فعال پرداختکننده» تبدیل میشود به «کاربر فعال پرداختکننده، به جز گاهی اوقات، بدون بازپرداخت»... میدانید که قضیه از چه قرار است.
هوش مصنوعی نمیتواند این ابهام را بپذیرد. فقط میتواند حدس بزند.
۲) پاسخگویی و ریسک
وقتی یک خط لوله خراب میشود و داشبورد اجرایی اطلاعات بیمعنی نشان میدهد، یک نفر باید:
-
تریاژ
-
تأثیر ارتباط
-
آن را درست کن
-
جلوگیری از عود
-
کالبدشکافی را بنویسید
-
تصمیم بگیرید که آیا کسب و کار هنوز میتواند به اعداد هفته گذشته اعتماد کند یا خیر
هوش مصنوعی میتواند کمک کند، اما نمیتواند به شیوهای معنادار پاسخگو باشد. سازمانها بر اساس ارتعاشات اداره نمیشوند - آنها بر اساس مسئولیت اداره میشوند.
۳) تفکر سیستمی
پلتفرمهای داده، اکوسیستمهایی هستند: دریافت، ذخیرهسازی، تبدیل، هماهنگسازی، مدیریت، کنترل هزینه، توافقنامه سطح خدمات (SLA). تغییر در یک لایه، موجهایی را به دنبال دارد. مفاهیم آپاچی ایرفلو
هوش مصنوعی میتواند بهینهسازیهای محلی را پیشنهاد دهد که باعث ایجاد درد جهانی میشود. مثل این است که با برداشتن در، صدای جیرجیر آن را درست کنید 😬
۴) امنیت، حریم خصوصی، انطباق
اینجاست که خیالپردازیهای جایگزین به پایان میرسند.
-
کنترلهای دسترسی
-
امنیت سطح ردیف سیاستهای دسترسی به ردیف Snowflake امنیت سطح ردیف BigQuery
-
مدیریت PII چارچوب حریم خصوصی NIST
-
قوانین نگهداری محدودیت ذخیرهسازی (ICO) راهنمای اتحادیه اروپا در مورد نگهداری
-
مسیرهای حسابرسی NIST SP 800-92 (مدیریت لاگ) CIS Control 8 (مدیریت لاگ حسابرسی)
-
محدودیتهای مربوط به محل نگهداری دادهها
هوش مصنوعی میتواند سیاستها را تدوین کند، اما اجرای ایمن آنها یک مهندسی واقعی است.
۵) «ناشناختههای ناشناخته»
حوادث دادهای اغلب غیرقابل پیشبینی هستند:
-
یک API فروشنده، معناشناسی را بیسروصدا تغییر میدهد
-
یک فرض منطقه زمانی برعکس میشود
-
یک backfill یک پارتیشن را کپی میکند
-
مکانیسم تلاش مجدد باعث نوشتن مضاعف میشود
-
یک ویژگی جدید محصول، الگوهای رویداد جدیدی را معرفی میکند
هوش مصنوعی وقتی که موقعیت یک الگوی شناختهشده نباشد، ضعیفتر است.
جدول مقایسه: در عمل چه چیزی چه چیزی را کاهش میدهد 🧾🤔
در زیر یک دیدگاه عملی ارائه شده است. منظور «ابزارهایی که جایگزین انسانها میشوند» نیست، بلکه ابزارها و رویکردهایی هستند که وظایف خاصی را کوچکتر میکنند.
| ابزار / رویکرد | مخاطب | حس و حال قیمت | چرا کار میکند؟ |
|---|---|---|---|
| کمک خلبانان کد هوش مصنوعی (کمک کنندههای SQL + Python) گیتهاب کمک خلبان | مهندسانی که کد زیادی مینویسند | از رایگان تا پولی | در scaffolding، refactors، syntax عالی است... گاهی اوقات به شکلی بسیار خاص از خود راضی است |
| کانکتورهای ELT مدیریتشده Fivetran | تیمها از ساختن ingestion خسته شدهاند | اشتراک-y | درد ناشی از بلعیدن سفارشی را از بین میبرد، اما به روشهای جدید و سرگرمکنندهای آن را تسکین میدهد |
| پلتفرمهای مشاهدهپذیری دادهها مشاهدهپذیری دادهها (Dynatrace) | هر کسی که دارای SLA است | متوسط تا سازمانی | ناهنجاریها را زود تشخیص میدهد - مانند آلارمهای دود برای خطوط لوله 🔔 |
| چارچوبهای تبدیل (مدلسازی اعلانی) dbt | هیبریدهای تحلیلی + DE | معمولاً ابزار + محاسبه | منطق را ماژولار و قابل آزمایش میکند، و اسپاگتی کمتری ارائه میدهد |
| کاتالوگهای داده + لایههای معنایی لایه معنایی dbt | سازمانهایی با سردرگمی متریک | بستگی دارد، در عمل | یک بار «حقیقت» را تعریف میکند - بحثهای بیپایان در مورد معیارها را کاهش میدهد |
| هماهنگی با قالبها Apache Airflow | تیمهای پلتفرمگرا | هزینه عملیات + باز شدن | گردشهای کاری را استاندارد میکند؛ DAGهای دانه برفی کمتری ایجاد میکند |
| تولید اسناد dbt با کمک هوش مصنوعی | تیمهایی که از نوشتن مستندات متنفرند | ارزان تا متوسط | مستندهای «به اندازه کافی خوب» میسازد تا دانش از بین نرود |
| سیاستهای حاکمیت خودکار چارچوب حریم خصوصی NIST | محیطهای تنظیمشده | سازمانی-y | به اجرای قوانین کمک میکند - اما هنوز برای طراحی قوانین به انسان نیاز دارد |
توجه کنید چه چیزی کم است: ردیفی که میگوید «برای حذف مهندسان داده، دکمه را فشار دهید». بله… آن ردیف وجود ندارد 🙃
خب… آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد یا فقط نقش آنها را تغییر خواهد داد؟ 🛠️
پاسخ غیر نمایشی این است: هوش مصنوعی جایگزین بخشهایی از گردش کار خواهد شد، نه خود حرفه.
اما این میدهد . و اگر آن را نادیده بگیرید، فشار را احساس خواهید کرد.
چه چیزهایی تغییر میکند:
-
زمان کمتر برای نوشتن کدهای تکراری
-
زمان کمتر برای جستجوی اسناد
-
زمان بیشتر برای بررسی، اعتبارسنجی، طراحی
-
زمان بیشتر برای تعریف قراردادها و انتظارات کیفی، استاندارد قرارداد داده باز (ODCS)
-
زمان بیشتر برای همکاری با محصولات، امنیت و امور مالی
این یک تغییر ظریف است: مهندسی داده کمتر به «ساخت خطوط لوله» و بیشتر به «ساخت یک سیستم محصول داده قابل اعتماد» تبدیل میشود
و در یک چرخش آرام، این ارزشمندتر است، نه کمتر.
همچنین - و من این را میگویم حتی اگر دراماتیک به نظر برسد - هوش مصنوعی تعداد افرادی را که میتوانند مصنوعات دادهای تولید کنند افزایش میدهد، که این امر نیاز به کسی را برای حفظ سلامت کل ماجرا افزایش میدهد. خروجی بیشتر به معنای سردرگمی بیشتر است. GitHub Copilot
مثل اینه که به همه یه دریل برقی بدی. عالیه! حالا یکی باید قانون «لطفا لوله آب رو سوراخ نکن» رو اجرا کنه 🪠
مهارتهای جدیدی که همچنان ارزشمند هستند (حتی با وجود هوش مصنوعی در همه جا) 🧠⚙️
اگر یک چک لیست کاربردی و «مقاوم در برابر آینده» میخواهید، به این شکل است:
طرز فکر طراحی سیستم
-
مدلسازی دادههایی که از تغییر جان سالم به در میبرند
-
بدهبستانهای دستهای در مقابل پخش جریانی
-
تفکر تأخیر، هزینه، قابلیت اطمینان
مهندسی کیفیت دادهها
-
قراردادها، اعتبارسنجیها، تشخیص ناهنجاری استاندارد قرارداد دادههای باز (ODCS) مشاهدهپذیری دادهها (Dynatrace)
-
توافقنامههای سطح خدمات (SLA)، توافقنامههای سطح خدمات (SLO)، عادات واکنش به حوادث
-
تحلیل ریشهای علت با انضباط (نه با احساسات)
معماری حاکمیت و اعتماد
-
الگوهای دسترسی
-
قابلیت حسابرسی NIST SP 800-92 (مدیریت لاگ)
-
حریم خصوصی با طراحی چارچوب حریم خصوصی NIST
-
مدیریت چرخه عمر دادهها، راهنمای اتحادیه اروپا در مورد نگهداری دادهها
تفکر پلتفرمی
-
قالبهای قابل استفاده مجدد، مسیرهای طلایی
-
الگوهای استاندارد برای مصرف، تبدیلها، آزمایش دادههای Fivetran dbt
-
ابزارهای سلف سرویس که ذوب نمیشوند
ارتباطات (بله، واقعاً)
-
نوشتن اسناد واضح
-
همترازی تعاریف
-
مودبانه اما قاطعانه «نه» گفتن
-
توضیح بده بستانها بدون اینکه مثل ربات به نظر برسید 🤖
اگر بتوانید این کارها را انجام دهید، سوال «آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد؟» کمتر تهدیدآمیز میشود. هوش مصنوعی به اسکلت بیرونی شما تبدیل میشود، نه جایگزین شما.
سناریوهای واقعبینانهای که در آنها برخی از نقشهای مهندسی داده کوچک میشوند 📉
خب، یه بررسی سریع واقعیت بکنم، چون همه چیز آفتاب و ایموجیهای رنگی نیست 🎉
برخی از نقشها بیشتر در معرض دید هستند:
-
نقشهای صرفاً مصرفکننده که در آنها همه چیز استاندارد است
-
تیمهایی که عمدتاً گزارشهای تکراری با حداقل جزئیات دامنه انجام میدهند
-
سازمانهایی که در آنها با مهندسی داده مانند «میمونهای SQL» رفتار میشود (تلخ، اما واقعی)
-
نقشهای کممسئولیت که در آنها کار فقط تیکت و کپی-پیست است
هوش مصنوعی به همراه ابزارهای مدیریتشده میتواند این نیازها را کاهش دهد.
اما حتی در آنجا، جایگزینی معمولاً به این شکل است:
-
افراد کمتری کارهای تکراری انجام میدهند
-
تأکید بیشتر بر مالکیت پلتفرم و قابلیت اطمینان
-
تغییر به سمت «یک نفر میتواند از خطوط لوله بیشتری پشتیبانی کند»
بنابراین بله - الگوهای تعداد کارکنان میتوانند تغییر کنند. نقشها تکامل مییابند. عناوین شغلی تغییر میکنند. این بخش واقعی است.
با این حال، نسخهای از این نقش که مالکیت و اعتماد بالایی دارد، همچنان پابرجاست.
خلاصه پایانی 🧾✅
آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد؟ نه به آن شکل کامل و بینقصی که مردم تصور میکنند.
هوش مصنوعی:
-
خودکارسازی وظایف تکراری
-
سرعت بخشیدن به کدنویسی، اشکالزدایی و مستندسازی GitHub Copilot برای SQL مستندسازی dbt
-
کاهش هزینه تولید خطوط لوله
اما مهندسی داده اساساً در مورد موارد زیر است:
-
پاسخگویی
-
طراحی سیستم
-
اعتماد، کیفیت و حاکمیت، استاندارد قرارداد داده باز (ODCS)، چارچوب حریم خصوصی NIST
-
تبدیل واقعیتهای مبهم کسبوکار به محصولات دادهای قابل اعتماد
هوش مصنوعی میتواند در این زمینه کمک کند... اما «مالک» آن نیست.
اگر مهندس داده هستید، این حرکت ساده است (نه آسان، اما ساده):
به مالکیت، کیفیت، تفکر پلتفرمی و ارتباطات تکیه کنید. بگذارید هوش مصنوعی کارهای کلیشهای را انجام دهد در حالی که شما بخشهای مهم را مدیریت میکنید.
و آره - بعضی وقتا این یعنی بزرگِ جمع باشی. نه پر زرق و برق. هرچند که خیلی قدرتمنده 😄
آیا هوش مصنوعی جایگزین مهندسان داده خواهد شد؟ هوش مصنوعی
جایگزین برخی از وظایف خواهد شد، نردبان شغلی را تغییر خواهد داد و بهترین مهندسان داده را ارزشمندتر خواهد کرد. داستان واقعی همین است.
مثال دنیای واقعی: ساخت یک گردش کار بررسی خط لوله داده با کمک هوش مصنوعی 🛠️
سناریو
یک شرکت تجارت الکترونیک کوچک را تصور کنید که یک مهندس داده، دو تحلیلگر و یک مشکل بسیار آشنا دارد: داشبورد مالی هر زمان که ارائه دهنده خدمات پرداخت نام یک فیلد را تغییر میدهد، دچار مشکل میشود.
این تیم نمیخواهد هوش مصنوعی «مالک» خط تولید باشد. این کار خطرناک خواهد بود. در عوض، آنها از هوش مصنوعی به عنوان دستیار اول برای کارهای روتین اما مهم استفاده میکنند: نوشتن اسکلت مدل dbt، پیشنهاد تستها، تهیه پیشنویس مستندات و ایجاد چک لیست برای بررسی کد.
مهندس داده انسانی همچنان مسئولیت طراحی نهایی، تعاریف دادهها، قوانین دسترسی و استقرار تولید را بر عهده دارد. هوش مصنوعی به سادگی سرعت مراحل میانی پیچیده را افزایش میدهد.
آنچه گردش کار نیاز دارد
قبل از استفاده از هوش مصنوعی، تیم زمینه کافی برای مفید بودن آن را فراهم میکند:
-
طرح جدول پرداختهای موجود
-
تعاریف معیارهای مالی هدف، مانند «درآمد خالص»، «مبلغ بازپرداخت» و «پرداخت تسویهشده»
-
قراردادهای نامگذاری برای مدلهای dbt
-
نمونههایی از آزمایشهای تایید شده
-
یک قرارداد داده کوتاه برای فید پرداختها
-
قوانینی برای مدیریت اطلاعات شخصی، پرداختهای ناموفق، موارد تکراری و سوابق دیررسیده
-
نمونهای از حوادث گذشته، شامل اینکه چه مشکلی پیش آمده و چگونه برطرف شده است
نکتهی کلیدی این نیست که «از هوش مصنوعی بخواهیم یک خط لوله بسازد». این خیلی مبهم است.
رویکرد قویتر این است: «قوانین ما این است، طرحواره این است، رفتار مورد انتظار این است. چیزی را پیشنویس کنید که بتوانیم آن را بررسی کنیم.»
دستورالعمل مثال
شما در حال کمک به تهیه پیشنویس یک مدل dbt برای دادههای پرداختهای ما هستید. از طرحواره و قوانین زیر برای ایجاد یک مدل اولیه، تستهای dbt پیشنهادی و یادداشتهای مستندسازی استفاده کنید.
مدل باید درآمد تسویهشده روزانه را با استفاده از order_id و payment_provider محاسبه کند. پرداختهای ناموفق، تراکنشهای آزمایشی و بازپرداختهای کمشده را فقط زمانی که وضعیت بازپرداخت برابر با "confirmed" باشد، حذف کند.
ستونها را از خودتان اختراع نکنید. اگر ستونی مورد نیاز وجود ندارد، به جای حدس زدن، آن را در قسمت «سوالات برای بررسی انسانی» فهرست کنید.
همچنین آزمونهایی برای منحصر به فرد بودن، مقادیر تهی، مقادیر پذیرفته شده و معقول بودن درآمد پیشنهاد دهید. هر منطقی را که میتواند بر گزارشگری مالی تأثیر بگذارد، علامتگذاری کنید.
چگونه آن را آزمایش کنیم
یک آزمایش معقول، کوچک و عمداً پیش پا افتاده است:
-
یک طرح پرداخت خوب و شناختهشده را به هوش مصنوعی بدهید و بررسی کنید که آیا از ایجاد فیلدهای جدید اجتناب میکند یا خیر.
-
یک طرحواره با ستون refund_status گمشده به آن بدهید و ببینید آیا به جای حدس زدن، سؤال میپرسد یا خیر.
-
SQL تولید شده را روی یک مجموعه دادهی آزمایشی (staging) اجرا کنید، نه روی یک مجموعه دادهی عملیاتی (production).
-
خروجی را با 20 رکورد پرداخت که به صورت دستی بررسی شدهاند مقایسه کنید.
-
از یک تحلیلگر و مهندس داده بخواهید که قبل از ادغام، تعاریف را بررسی کنند.
-
تستهای پذیرفتهشده را به CI اضافه کنید تا خط لوله پس از استقرار، خود را بررسی کند.
نکته مهم این است که هوش مصنوعی را روی حالتهای شکستی که بیشتر از همه از آنها میترسید، آزمایش کنید: ستونهای ساختگی، منطق درآمد اشتباه، عدم مدیریت بازپرداخت و ردیفهای تکراری بیسروصدا.
نتیجه
نتیجهی تشریحی: بر اساس زمانبندی سه نمونه وظیفهی تغییر خط لوله قبل و بعد از استفاده از این گردش کار.
قبل از استفاده از هوش مصنوعی، این مهندس حدود ۵ ساعت و ۳۰ دقیقه برای هر تغییر وقت صرف میکرد: تقریباً ۲ ساعت نوشتن SQL، ۱ ساعت ایجاد تست، ۴۵ دقیقه نوشتن اسناد و بقیه را بررسی موارد حاشیهای با امور مالی.
با استفاده از هوش مصنوعی فقط برای پیشنویسهای اولیه، همین نوع تغییر حدود ۲ ساعت و ۱۰ دقیقه طول کشید. بیشترین صرفهجویی مربوط به چارچوببندی آزمایشی و پیشنویسهای مستندسازی بود که از ۱ ساعت و ۴۵ دقیقه به حدود ۲۵ دقیقه کاهش یافت.
مرحله بررسی انسانی هنوز حدود ۴۵ دقیقه طول کشید و نباید حذف شود.
در آزمون سه وظیفهای، هوش مصنوعی ۱۸ بررسی پیشنهاد داد. مهندس ۱۱ مورد را پذیرفت، ۵ مورد را ویرایش کرد و ۲ مورد را رد کرد، زیرا آنها قوانین تجاری را نادرست فرض کرده بودند. تعداد موارد رد شده مهم است: این ثابت میکند که گردش کار نیاز به بررسی دارد، نه اعتماد کورکورانه.
چه چیزی میتواند اشتباه پیش برود؟
هوش مصنوعی میتواند یک خط تولید را کاملتر از آنچه هست، نشان دهد.
نقاط شکست رایج عبارتند از:
-
ابداع ستونهایی که باورپذیر به نظر میرسند
-
برخورد یکسان با بازپرداختها، برگشت وجه و پرداختهای ناموفق
-
مشکلات مربوط به منطقه زمانی در درآمد روزانه وجود ندارد
-
پیشنهاد آزمونهای عمومی که خطاهای مالی را نشان نمیدهند
-
نوشتن مستنداتی که مطمئن به نظر میرسند اما عدم قطعیت را پنهان میکنند
-
فراموش کردن قوانین حریم خصوصی وقتی دادههای نمونه حاوی جزئیات مشتری هستند
یک قانون خوب: هوش مصنوعی میتواند مدل را تهیه کند، اما یک انسان باید تعاریف، منطق مالی، کنترل دسترسی و انتشار محصول را تأیید کند.
نکته کاربردی
نسخه ارزشمند هوش مصنوعی در مهندسی داده «جایگزینی مهندس داده» نیست، بلکه «حذف صفحه خالی و سپس بررسی دقیق» است.
این یعنی SQL سریعتر، تستهای سریعتر و مستندسازی اولیه بهتر، در حالی که مهندس هنوز بخش مهمتر را در اختیار دارد: اینکه آیا دادهها صحیح، قابل اعتماد، ایمن و قابل توضیح هستند یا خیر.
سوالات متداول
آیا هوش مصنوعی به طور کامل جایگزین مهندسان داده خواهد شد؟
در بیشتر سازمانها، هوش مصنوعی به احتمال زیاد وظایف خاصی را بر عهده میگیرد تا اینکه نقش را به طور کامل حذف کند. این فناوری میتواند تهیه پیشنویس SQL، داربستبندی پایپلاین، اولین مجوزهای مستندسازی و ایجاد تستهای اولیه را تسریع کند. اما مهندسی داده همچنین مالکیت و پاسخگویی را به همراه دارد، به علاوه کار نه چندان جذابِ تبدیل واقعیت آشفته کسبوکار به یک سیستم قابل اعتماد. این بخشها هنوز به انسانها نیاز دارند تا تصمیم بگیرند که «درست» چیست و در صورت بروز مشکل، مسئولیت آن را بر عهده بگیرند.
هوش مصنوعی در حال حاضر چه بخشهایی از مهندسی داده را خودکار میکند؟
هوش مصنوعی در کارهای تکرارپذیر بهترین عملکرد را دارد: تهیه و بازسازی SQL، تولید اسکلتهای مدل dbt، توضیح خطاهای رایج و تولید طرحهای کلی مستندات. همچنین میتواند تستهایی مانند بررسیهای تهی یا منحصر به فرد بودن را چارچوببندی کند و کد «چسب» الگو را برای ابزارهای تنظیم تولید کند. برد در گرو حرکت است - شما به یک راهحل کارآمد نزدیکتر میشوید - اما هنوز باید صحت آن را تأیید کنید و مطمئن شوید که با محیط شما مطابقت دارد.
اگر هوش مصنوعی بتواند SQL و pipelines را بنویسد، چه چیزی برای مهندسان داده باقی میماند؟
کارهای زیادی انجام میشود: تعریف قراردادهای داده، مدیریت رانش طرحواره و اطمینان از اینکه خطوط لوله، خود-توان، قابل مشاهده و قابل بازیابی هستند. مهندسان داده وقت خود را صرف بررسی تغییرات معیارها، ایجاد محافظ برای کاربران پاییندستی و مدیریت بدهبستانهای هزینه و قابلیت اطمینان میکنند. این کار اغلب به ایجاد اعتماد و «آرام» نگه داشتن پلتفرم داده خلاصه میشود، به این معنی که به اندازه کافی پایدار باشد که هیچکس مجبور نباشد هر روز به آن فکر کند.
هوش مصنوعی چگونه کار روزمره یک مهندس داده را تغییر میدهد؟
این روش معمولاً باعث کاهش حجم مطالب تکراری و «زمان جستجو» میشود، بنابراین شما زمان کمتری را صرف تایپ کردن و زمان بیشتری را صرف بررسی، اعتبارسنجی و طراحی میکنید. این تغییر، نقش را به سمت تعریف انتظارات، استانداردهای کیفیت و الگوهای قابل استفاده مجدد به جای کدنویسی دستی همه چیز سوق میدهد. در عمل، احتمالاً کارهای مشارکتی بیشتری با محصول، امنیت و امور مالی انجام خواهید داد - زیرا ایجاد خروجی فنی آسانتر، اما مدیریت آن دشوارتر میشود.
چرا هوش مصنوعی با تعاریف مبهم تجاری مانند «کاربر فعال» مشکل دارد؟
از آنجا که منطق کسبوکار ایستا یا دقیق نیست - در اواسط پروژه تغییر میکند و بسته به ذینفعان متفاوت است. هوش مصنوعی میتواند تفسیری را تدوین کند، اما وقتی تعاریف تکامل مییابند یا تضادهایی بروز میکنند، نمیتواند تصمیم را به خود اختصاص دهد. مهندسی داده اغلب نیاز به مذاکره، مستندسازی فرضیات و تبدیل الزامات فازی به قراردادهای پایدار دارد. این کار «هماهنگی انسانی» دلیل اصلی این است که این نقش حتی با بهبود ابزارها از بین نمیرود.
آیا هوش مصنوعی میتواند مدیریت دادهها، حریم خصوصی و انطباق با قوانین را با خیال راحت انجام دهد؟
هوش مصنوعی میتواند به تدوین سیاستها یا پیشنهاد رویکردها کمک کند، اما اجرای ایمن همچنان نیازمند مهندسی واقعی و نظارت دقیق است. مدیریت شامل کنترلهای دسترسی، مدیریت اطلاعات شخصی، قوانین نگهداری، مسیرهای حسابرسی و گاهی اوقات محدودیتهای اقامت است. اینها حوزههای پرخطری هستند که در آنها «تقریباً درست» قابل قبول نیست. انسانها باید قوانین را طراحی کنند، اجرای آنها را تأیید کنند و در قبال نتایج انطباق پاسخگو باشند.
با پیشرفت هوش مصنوعی، چه مهارتهایی برای مهندسان داده ارزشمند باقی میمانند؟
مهارتهایی که سیستمها را انعطافپذیر میکنند: تفکر طراحی سیستم، مهندسی کیفیت داده و استانداردسازی مبتنی بر پلتفرم. قراردادها، قابلیت مشاهده، عادات واکنش به حوادث و تحلیل ریشهای منظم، زمانی که افراد بیشتری بتوانند به سرعت مصنوعات دادهای تولید کنند، اهمیت بیشتری پیدا میکنند. ارتباطات نیز به یک عامل متمایزکننده تبدیل میشود - هماهنگسازی تعاریف، نوشتن اسناد واضح و توضیح بدهبستانها بدون دردسر، بخش بزرگی از قابل اعتماد نگه داشتن دادهها است.
کدام نقشهای مهندسی داده بیشتر در معرض خطر هوش مصنوعی و ابزارهای مدیریتشده هستند؟
نقشهایی که بهطور خاص بر روی مصرف تکراری یا گزارشهای استاندارد متمرکز هستند، بیشتر در معرض خطر قرار دارند، بهخصوص زمانی که رابطهای ELT مدیریتشده اکثر منابع را پوشش میدهند. کارهای کممالکیت و مبتنی بر تیکت میتوانند کاهش یابند، زیرا هوش مصنوعی و انتزاع، تلاش در هر خط لوله را کاهش میدهند. اما این معمولاً به این صورت به نظر میرسد که افراد کمتری وظایف تکراری انجام میدهند، نه اینکه «هیچ مهندس دادهای وجود نداشته باشد». نقشهای با مالکیت بالا که بر قابلیت اطمینان، کیفیت و اعتماد متمرکز هستند، پایدار میمانند.
چگونه باید از ابزارهایی مانند GitHub Copilot یا dbt با هوش مصنوعی بدون ایجاد هرج و مرج استفاده کنم؟
خروجی هوش مصنوعی را به عنوان یک پیشنویس در نظر بگیرید، نه یک تصمیم. از آن برای تولید اسکلتهای پرسوجو، بهبود خوانایی یا چارچوببندی تستها و اسناد 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
-
مستندات Snowflake - سیاستهای دسترسی به سطرها - docs.snowflake.com
-
مستندات گوگل کلود - امنیت سطح ردیف BigQuery - docs.cloud.google.com
-
استاندارد قرارداد داده باز BITOL (ODCS) نسخه ۳.۱.۰ - bitol-io.github.io
-
BITOL (GitHub) - استاندارد قرارداد داده باز - github.com
-
آپاچی ایرفلو - مستندات (پایدار) - airflow.apache.org
-
آپاچی ایرفلو - DAGها (مفاهیم اصلی) - 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 - شروع به کار - fivetran.com
-
فایوتران - کانکتورها - fivetran.com
-
مستندات AWS - راهنمای توسعهدهندگان AWS Lambda - docs.aws.amazon.com
-
گیتهاب - گیتهاب کوپایلوت - github.com
-
اسناد گیتهاب - دریافت پیشنهاد کد در IDE با GitHub Copilot - docs.github.com
-
آموزش مایکروسافت - گیتهاب کمک خلبان برای SQL (افزونه VS Code) - learn.microsoft.com
-
مستندات Dynatrace - مشاهدهپذیری دادهها - docs.dynatrace.com
-
دیتاگلکسی - مشاهدهپذیری دادهها چیست؟ - datagalaxy.com
-
مستندات انتظارات بزرگ - مروری بر انتظارات - docs.greatexpectations.io