مهندسی داده چیست؟ فراتر از ETL و ابزارها

فرض کن یک سیستم ساده داری.
یک Application، یک Database.

کاربرها داده تولید می‌کنند، داده در Database ذخیره می‌شود و هر وقت لازم باشد یک Query می‌زنی و جواب می‌گیری.

همه‌چیز کار می‌کند.

در این مرحله، تقریباً هیچ‌کس درباره‌ی «معماری داده» یا «سیستم توزیع‌شده» صحبت نمی‌کند.

اما حالا فرض کن همین سیستم رشد کند.

تعداد کاربران بیشتر می‌شود. چند Database دیگر اضافه می‌شود. سرویس‌های مختلف، داده‌های مختلفی تولید می‌کنند.

یک تیم Analytics می‌خواهد روی این داده‌ها گزارش بسازد.

تیم دیگری می‌خواهد از همان داده‌ها برای Machine Learning استفاده کند.

و حالا یک نیاز جدید هم وجود دارد:

بعضی تصمیم‌ها دیگر نمی‌توانند تا گزارش فردا صبح صبر کنند. باید همین حالا گرفته شوند.

اینجاست که یک سؤال ساده مطرح می‌شود:

وقتی حجم داده، سرعت تولید داده و تعداد سیستم‌ها زیاد می‌شود، واقعاً چه چیزی باید مهندسی شود؟

پاسخ این سؤال، نقطه‌ی شروع Data Engineering است.

Data Engineering فقط ETL نیست

یک تعریف رایج از Data Engineering این است: جمع‌آوری، انتقال، تبدیل و آماده‌سازی داده برای مصرف‌کننده‌های نهایی.

این تعریف اشتباه نیست.

اما یک بخش مهم را نادیده می‌گیرد:

مهندسی.

Data Engineering در اصل درباره‌ی طراحی، ساخت و نگهداری سیستم‌هایی است که داده را از محل تولید به محل مصرف می‌رسانند؛ آن را ذخیره می‌کنند، پردازش می‌کنند و برای استفاده آماده می‌کنند.

اما این سیستم‌ها باید در شرایط واقعی کار کنند:

• حجم داده رشد می‌کند.
• منابع داده زیاد و متنوع می‌شوند.
• بعضی مصرف‌کننده‌ها Batch می‌خواهند و بعضی Real-time.
• سیستم‌ها Fail می‌شوند.
• نیازهای کسب‌وکار تغییر می‌کنند.
• هزینه‌ی زیرساخت اهمیت پیدا می‌کند.

Collect → Store → Process → Transform → Serve

اما نکته‌ی مهم این است که هر فلش در این زنجیره، خودش یک مسئله‌ی مهندسی است.

چگونه داده را جمع کنیم بدون اینکه به سیستم منبع فشار وارد شود؟

چگونه ذخیره کنیم که هم قابل اعتماد باشد و هم هزینه‌ی منطقی داشته باشد؟

چگونه پردازش کنیم که با افزایش حجم داده، سیستم از کار نیفتد؟

چگونه بفهمیم داده‌ای که وارد سیستم شده، درست است؟

وقتی سیستم بزرگ می‌شود، مسئله عوض می‌شود

در یک سیستم کوچک، بسیاری از مشکلات دیده نمی‌شوند.

یک Query کند است؟ شاید بتوان آن را تحمل کرد.

یک Job شکست خورد؟ دوباره اجراش می‌کنیم.

Database کمی بزرگ شده؟ یک Server قوی‌تر می‌خریم.

اما Scale که بالا می‌رود، همین راه‌حل‌های ساده دیگر کافی نیستند.

وقتی داده ۱۰ برابر یا ۱۰۰ برابر شود، معماری قبلی ممکن است دیگر جواب ندهد.

وقتی صدها ماشین درگیر باشند، خرابی یک Node دیگر اتفاقی عجیب نیست.

وقتی Pipeline ده‌ها مرحله داشته باشد، پیدا کردن علت یک Failure خودش تبدیل به یک مسئله می‌شود.

و وقتی داده برای تصمیم‌های مهم کسب‌وکار استفاده شود، Data Quality دیگر یک موضوع فرعی نیست.

در این مرحله، مسائل اصلی Data Engineering خودشان را نشان می‌دهند:

• Scalability — اگر داده بیشتر شود چه اتفاقی می‌افتد؟
• Reliability — اگر یک بخش سیستم Fail شود چه می‌شود؟
• Fault Tolerance — آیا سیستم می‌تواند خرابی را تحمل کند؟
• Performance — داده با چه Latency و Throughput پردازش می‌شود؟
• Data Quality — چقدر می‌توان به داده اعتماد کرد؟
• Cost — این معماری چقدر هزینه دارد؟
• Observability — اگر چیزی خراب شود، چگونه بفهمیم چرا؟

اینجاست که Data Engineering از «نوشتن ETL» فاصله می‌گیرد و به مهندسی سیستم تبدیل می‌شود.

چرا ETL دیگر تصویر کاملی از Data Engineering نیست؟

برای سال‌ها، تصویر ذهنی بسیاری از سیستم‌های داده این بود:

Database → ETL → Data Warehouse

این معماری هنوز هم در بسیاری از پروژه‌ها کاملاً مناسب است.

اما همه‌ی مسئله‌ها این‌قدر ساده نیستند.

فرض کن یک سیستم مالی داری و باید Fraud را تقریباً در لحظه تشخیص دهی.

نمی‌توانی منتظر یک Job شبانه بمانی.

یا فرض کن یک Database عملیاتی داری که میلیون‌ها تغییر در روز روی آن اتفاق می‌افتد.

خواندن مکرر کل جدول برای انتقال داده، روش مناسبی نیست.

اینجا مفاهیمی مثل CDC، Streaming، Distributed Processing، Distributed Storage و Lakehouse وارد معماری می‌شوند.

اما نکته‌ی مهم این است:

این فناوری‌ها برای حل مسئله به وجود آمده‌اند، نه برای مد شدن.

مسئله این نیست که کدام فناوری جدیدتر است؛ مسئله این است که برای این Problem، چه Architecture و چه Technology مناسب‌تر است؟

یک معماری واقعی چه شکلی است؟

فرض کنیم یک شرکت بزرگ داریم:

Application
      ↓
Database
      ↓
CDC
      ↓
Kafka
      ↓
Stream Processing
      ↓
Data Lake / Lakehouse
      ↓
Analytics / BI / ML

در نگاه اول، این فقط مجموعه‌ای از اسم‌هاست.

اما اگر از خودمان بپرسیم «هر بخش دقیقاً چه مشکلی را حل می‌کند؟»، معماری معنا پیدا می‌کند.

CDC

مشکل: چگونه تغییرات Database را بدون فشار غیرضروری روی سیستم عملیاتی دریافت کنیم؟

CDC به‌جای اینکه مرتباً کل جدول را بخواند، تغییرات داده را دنبال می‌کند.

Kafka

مشکل: چگونه داده یا Event را بین چند سیستم مختلف منتقل کنیم، بدون اینکه همه‌ی سیستم‌ها مستقیماً به یکدیگر وابسته باشند؟

Kafka یک لایه‌ی Event Streaming در معماری ایجاد می‌کند.

Stream Processing

مشکل: چگونه روی داده‌ای که همین الان در حال ورود است، پردازش انجام دهیم؟

مثلاً تشخیص Fraud، محاسبه‌ی Metric یا ساخت یک Aggregation لحظه‌ای.

Data Lake / Lakehouse

مشکل: داده‌های متنوع را کجا ذخیره کنیم تا هم مقیاس‌پذیر باشند و هم برای پردازش و تحلیل قابل استفاده؟

Analytics / BI / ML

در نهایت، داده باید به مصرف‌کننده‌ای برسد که بتواند از آن ارزش ایجاد کند.

Data Engineer دقیقاً چه چیزی را مهندسی می‌کند؟

اگر بخواهیم کار Data Engineer را ساده کنیم، با چند سؤال اساسی روبه‌رو هستیم.

Data Flow

داده از کجا می‌آید؟ از چه مسیری عبور می‌کند؟ و در نهایت به کجا می‌رسد؟

Storage

داده کجا ذخیره می‌شود؟ با چه Formatی؟ چگونه Partition می‌شود؟ Row-based یا Column-based؟

Processing

داده چگونه پردازش می‌شود؟ Batch یا Streaming؟ Single Node یا Distributed؟

Reliability

اگر یک Node وسط پردازش خراب شود چه اتفاقی می‌افتد؟

Scalability

اگر حجم داده ۱۰ برابر شود، آیا سیستم هنوز کار می‌کند؟

Performance

Bottleneck کجاست؟ CPU؟ Memory؟ Disk I/O؟ Network؟

Data Quality

چگونه مطمئن شویم داده‌ی ناقص، اشتباه یا تکراری وارد سیستم نشده است؟

Cost

آیا این معماری از نظر هزینه هم منطقی است؟

این‌ها سؤال‌هایی هستند که یک Data Engineer حرفه‌ای باید بتواند درباره‌ی آن‌ها فکر کند.

ابزارها هدف نیستند

اینجا به یکی از مهم‌ترین اصول Data Engineering می‌رسیم:

.Technology is a solution to a problem, not the problem itself

Spark، Kafka، Airflow، Flink، ClickHouse، Iceberg، Paimon و Kubernetes خودِ Data Engineering نیستند.

هرکدام برای حل مسئله‌ای مشخص ساخته شده‌اند.

• HDFS → Distributed Storage
• Spark → Distributed Processing
• Kafka → Event Streaming
• Flink → Stateful Stream Processing
• Iceberg / Paimon → Lakehouse
• Airflow → Orchestration
• ClickHouse → Fast Analytical Querying

بنابراین یک Data Engineer خوب کسی نیست که فقط ابزارهای بیشتری بلد باشد.

کسی است که بتواند بگوید:

مسئله چیست؟

و بعد:

چه راه‌حلی برای این مسئله مناسب‌تر است؟

پشت فناوری‌های Data Engineering چه می‌گذرد؟

وقتی با فناوری‌های Data Engineering روبه‌رو می‌شویم، بهتر است فقط نپرسیم:

«این Technology چیست؟»

سؤال مهم‌تر این است:

چه مسئله‌ای باعث شد این Technology به وجود بیاید؟

برای فهمیدن یک فناوری، باید کمی به عقب برگردیم.

چه محدودیتی وجود داشت؟

معماری قبلی کجا به مشکل خورد؟

چه چیزی باید بهتر می‌شد؟

و این Technology دقیقاً چه بخشی از آن مسئله را حل کرد؟

Problem
   ↓
Limitation
   ↓
Architecture
   ↓
Technology
   ↓
Trade-off

این نگاه کمک می‌کند فناوری‌ها را به‌جای حفظ کردن، درک کنیم.

در «دیتا مهندس» قرار نیست فقط فناوری‌ها را یاد بگیریم؛ قرار است بفهمیم چه مسئله‌ای پشت تولد هر فناوری بوده است.

از مسئله تا فناوری

برای مثال، به چند فناوری مهم Data Engineering نگاه کنیم.

• HDFS → وقتی یک Server دیگر برای ذخیره‌سازی داده کافی نبود.
• MapReduce → وقتی پردازش حجم عظیم داده روی یک ماشین دیگر امکان‌پذیر نبود.
• Spark → وقتی نیاز به پردازش سریع‌تر و انعطاف‌پذیرتر داده‌های توزیع‌شده داشتیم.
• Kafka → وقتی سیستم‌ها نیاز داشتند Eventها را به‌صورت قابل اعتماد و مقیاس‌پذیر جابه‌جا کنند.
• Flink → وقتی پردازش Stateful و Real-time اهمیت پیدا کرد.
• Iceberg / Paimon → وقتی ذخیره‌سازی فایل‌های ساده به‌تنهایی برای ساخت یک Data Lake قابل اعتماد کافی نبود.
• ClickHouse → وقتی تحلیل حجم عظیم داده با Latency پایین به یک مسئله تبدیل شد.
• Airflow → وقتی اجرای دستی و وابستگی‌های پیچیده‌ی Pipelineها دیگر قابل مدیریت نبود

در این نگاه، Technology دیگر یک اسم برای حفظ کردن نیست.

هر Technology پاسخی است به یک یا چند مسئله‌ی مهندسی.

پس یک Data Engineer چگونه فکر می‌کند؟

وقتی با یک مسئله‌ی جدید روبه‌رو می‌شویم، بهتر است از Technology شروع نکنیم.

ابتدا خود مسئله را بررسی کنیم.

Problem
   ↓
Data Source
   ↓
Data Volume
   ↓
Data Velocity
   ↓
Batch یا Streaming؟
   ↓
Storage
   ↓
Processing
   ↓
Reliability
   ↓
Scalability
   ↓
Performance
   ↓
Cost
   ↓
Technology Choice

یعنی:

اول مسئله.

بعد محدودیت‌ها.

بعد معماری.

و در نهایت Technology.

اگر از ابزار شروع کنیم، ممکن است مسئله را با ابزار تطبیق دهیم؛ اما اگر از مسئله شروع کنیم، ابزار را برای حل آن انتخاب می‌کنیم.

از اینجا به بعد چه چیزی یاد می‌گیریم؟

این مقاله قرار نبود یک Tutorial برای HDFS یا Spark یا Kafka باشد.

هدف، ساختن یک نقشه برای ادامه‌ی مسیر بود.

در ادامه‌ی مسیر «دیتا مهندس» قرار است هرکدام از این مسائل را باز کنیم؛ از خود مسئله شروع کنیم، به معماری برسیم و بعد ببینیم چه فناوری‌هایی برای حل آن به وجود آمده‌اند.

• Distributed Storage → HDFS
• Distributed Processing → MapReduce / Spark
• Streaming → Kafka / Flink
• Data Lake / Lakehouse → Iceberg / Paimon
• Analytical Querying → ClickHouse / Trino
• Orchestration → Airflow

هدف این است که در نهایت فقط ندانیم هر Technology چیست؛ بلکه بدانیم چرا به وجود آمده، چه مسئله‌ای را حل می‌کند و چه Trade-offهایی دارد.

اول مسئله را بفهم؛ بعد ابزار را انتخاب کن.

چون ابزارها تغییر می‌کنند؛ اما مسئله‌های مهندسی، ماندگارترند.