مسیر یادگیری مهندسی داده؛ نقشهٔ راه شش‌ماهه از صفر تا اولین پروژه

مهندسی داده چیست و چه فرقی با تحلیل داده دارد؟

اگر داده را آب بخوانیم، تحلیلگر داده کسی است که از شیر آب لیوان برمی‌دارد و می‌خورد؛ اما مهندس داده کسی است که چاه می‌کند، لوله‌کشی می‌کند، مخزن می‌سازد و مطمئن می‌شود آب — تمیز و پایدار — به شیر برسد. کار مهندس داده ساخت و نگهداری خطوط لوله‌ای است که داده را از ده‌ها منبع (اپ، سایت، سامانه‌های فروش) جمع می‌کنند، پاک می‌کنند، تبدیل می‌کنند و به انبار داده می‌رسانند؛ همان داده‌ای که تحلیلگرها و مدل‌های هوش مصنوعی با آن کار می‌کنند. برای درک مرز این دو نقش، مسیر یادگیری تحلیل داده را هم ببینید و بعد تصمیم بگیرید کدام به شما می‌آید.

چرا این مسیر ارزش شش ماه وقت دارد؟ چون تقاضا برای آن بیشتر از عرضه است: هر شرکتی که داده دارد و می‌خواهد با آن تصمیم بگیرد، دیر یا زود به مهندس داده نیاز پیدا می‌کند و این نقش، به‌عنای معماری سمت داده، یکی از پرسالارترین نقش‌های فنی بازار است. پیش‌نیاز ورود: راحت بودن با کامپیوتر و کمی برنامه‌نویسی؛ بقیه در مسیر ساخته می‌شود.

ماه ۱ و ۲: پایتون و SQL؛ دو ستون اصلی

هر دو زبان دنیای داده را همین دو ماه خوب یاد می‌گیرید، چون مهندس داده هر روز با هر دو زندگی می‌کند. در پایتون روی این‌ها تمرکز کنید: کار با فایل و CSV، لیست و دیکشنری، توابع، و بعد کتابخانهٔ pandas برای دستکاری داده (خواندن، فیلتر، تجمیع، ادغام). منبع پیشنهادی همان شروع مسیر یادگیری پایتون است با تمرکز بیشتر روی بخش داده. در SQL بروید فراتر از SELECT ساده: JOIN انواعش، GROUP BY، توابع پنجره‌ای (Window Functions) و زیرکوئری؛ این‌ها ابزار روزمرهٔ تبدیل داده در دیتابیس‌اند و نقطهٔ شروع درست، یک آموزش گام‌به‌گام SQL از صفر است.

پروژهٔ پایان دو ماه: یک فایل واقعی (مثلاً دادهٔ باز فروش خانه یا ورزش‌های عمومی) را با pandas بخوانید، پاک‌سازی کنید (مقادیر خالی، تاریخ‌های ناهمگون) و نتیجه را در دیتابیس PostgreSQL بریزید و با SQL سه گزارش از آن بسازید. این پروژه کوچک، اسکلت هر خط لولهٔ دادهٔ واقعی است: بگیر، پاک کن، بریز، گزارش بگیر.

ماه ۳: مدل‌سازی داده و انبار داده

این ماه از «کاربر دیتابیس» به «معمار داده» ارتقا می‌کنید. مفاهیم کلیدی: طراحی جدول و کلیدها و نرمال‌سازی (به‌اندازه، نه افراط)؛ بعد مدل‌سازی انبار داده با رویکرد ستاره‌ای (Star Schema): جدول واقعیت در وسط و جدول‌های ابعاد اطرافش. این مدل، زبان مشترک همهٔ ابزارهای گزارش‌گیری است و فهمش، تفاوت مهندس داده از برنامه‌نویس معمولی است. با دو دنیای دیتابیس هم آشنا شوید: OLTP (همان PostgreSQL رابطه‌ای برای عملیات روزمره) در برابر OLAP و انبارهای ستون‌محور مثل ClickHouse که برای تحلیل‌های سنگین ساخته شده‌اند.

تمرین ماه: برای یک فروشگاه آنلاین، مدل انبار داده بسازید — جدول واقعیت «سفارش» و ابعاد «مشتری»، «محصول»، «زمان» — و آن را در PostgreSQL پیاده کنید و با دادهٔ ساختگی پر کنید. معیار خروج: بتوانید برای چهارتا سؤال تحلیلی پرتکرار («فروش هر ماه؟ پرفروش‌ترین دسته؟») کوئری بنویسید و مدل‌تان پاسخگو باشد؛ اگر پاسخگو نبود، مدل را عوض کنید نه کوئری را — این دقیقاً همان تفکر مهندسی داده است.

ماه ۴: خط لولهٔ داده و ابزارهای واقعی

حالا چیزها را به هم وصل می‌کنید. مفهوم مرکزی ماه چهارم ETL/ELT است: استخراج داده از منبع، تبدیل و بارگذاری در مقصد. با Apache Airflow آشنا شوید که دفترچهٔ برنامهٔ خطوط لوله است: تسک‌ها را به‌صورت گرافی می‌چیند، زمان‌بندی می‌کند و خطاها را گزارش می‌دهد. محیط Airflow را با Docker راه بیندازید و یک خط لولهٔ ساده بسازید: هر روز صبح، دادهٔ CSV از یک آدرس عمومی را دانلود کند، با pandas پاک کند و در جدول انبار داده درج کند — همان پروژهٔ ماه دو، اما خودکار و زمان‌بندی‌شده.

در همین ماه، دو مفهوم را هم فقط در حد شناخت بخوانید تا در مصاحبه غافلگیر نشوید: دادهٔ جاری (Streaming) و ابزارهایی مثل Kafka که برای دادهٔ لحظه‌ای ساخته شده‌اند، و dbt که تبدیل‌های SQL را نسخه‌بندی‌شده و قابل‌تست می‌کند. تحلیلگر و مهندس داده، دو چشم یک چهره‌اند و شناخت سمت مقابل، کار هر دو را بهتر می‌کند.

ماه ۵: ابر، داکر و اصول عملیاتی

دادهٔ واقعی روی سرورها زندگی می‌کند و این ماه، سکونت شما به سرور است. سه موضوع: Docker در حد عملی (نوشتن Dockerfile ساده، اجرای کانتینر Postgres و Airflow با docker-compose)؛ ابر در حد شناخت و کار مقدماتی (یک حساب رایگان سرویس‌هایی مثل AWS یا GCP، مفهوم S3 برای ذخیرهٔ فایل و مفهوم ماشین مجازی)؛ و ابزارهای مدیریت مثل Git که برای هر پروژهٔ داده‌ای لازم است و یادگیری‌اش یک بعدازظهر وقت می‌گیرد. نکتهٔ عملی مهندسی داده: داده‌ها حجیم‌اند و همه‌جا کپی نمی‌شوند؛ عادت بگیرید روی نمونهٔ کوچک توسعه بدهید و فقط در پایان، روی دادهٔ کامل اجرا کنید.

پروژهٔ ماه پنجم: همان خط لولهٔ ماه چهارم را کامل داکری کنید؛ یعنی با یک دستور روی هر ماشین اجرا شود و لاگ‌هایش قابل دنبال‌کردن باشد. این «قابل‌اجرا بودن روی هر ماشین» دقیقاً همان چیزی است که در آگهی‌های شغلی، Docker را خواسته‌اند.

ماه ۶: پروژهٔ پایانی و ورود به بازار کار

پروژهٔ پایانی باید یک داستان کامل باشد: منبع دادهٔ واقعی انتخاب کنید (داده‌های باز عمومی مثل قیمت ارز، آب‌وهوا یا ورزش)، خط لوله‌ای بسازید که هر روز اجرا شود، داده را در انبار مدل‌شده بریزد و در پایان، یک داشبورد ساده (با ابزارهایی مثل Metabase یا حتی یک صفحهٔ گزارش ساده) روی آن بگذارد. کل مسیر — از دانلود تا داشبورد — را در گیت‌هاب با README خوب منتشر کنید: معماری، دیاگرام خط لوله، دستور اجرا و تصمیم‌های طراحی. این پروژه در مصاحبه، جای صحبت‌های کلی را می‌گیرد.

برای بازار کار واقع‌بین باشید: عنوان «مهندس داده» معمولاً چند سال تجربه می‌خواهد و نقش‌های ورودی با نام‌های «تحلیلگر داده»، «توسعه‌دهنده داده» یا کارهای ETL شروع می‌شوند؛ پورتفولیوی قوی همین‌جا پل می‌زند. عادت یادگیری با پروژهٔ واقعی و روش خودآموزی مؤثر را در طول مسیر رها نکنید؛ مهندسی داده حوزه‌ای است که ابزارهایش هر دو سال عوض می‌شوند اما مبانیش — SQL، مدل‌سازی، تفکر خط لوله‌ای — می‌مانند. شش ماه با این نقشه، شما را به «کسی که می‌تواند خط لوله بسازد» می‌رساند؛ بقیه‌اش تجربهٔ ساختن است.