معماری داده و اصول طراحی سامانه‌های تحلیلی (Enterprise Data Architecture)

مبحث ۱: معماری داده

Data Architecture

۱. این مبحث دقیقاً درباره چیست؟

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

بدون معماری داده مناسب، سازمان با مشکلاتی مانند داده‌های پراکنده، ناسازگار، غیرقابل دسترس و بی‌کیفیت مواجه می‌شود. معماری داده پایه و بنیان تمام پروژه‌های هوش مصنوعی و تحلیل داده است — زیرا بدون داده سازمان‌یافته و قابل اعتماد، هیچ مدل AI کارآمد نخواهد بود.

این مبحث در واقع «نقشه کلی» سیستم داده سازمان است و درک آن برای مباحث بعدی (انبار داده، دریاچه داده، حاکمیت داده و...) ضروری است.

۲. تعریف ساده

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

۳. تعریف تخصصی

تعریف تخصصی: معماری داده مجموعه‌ای از مدل‌ها، سیاست‌ها، قوانین و استانداردها است که ساختار فیزیکی و منطقی داده‌ها، جریان داده (Data Flow)، یکپارچه‌سازی (Integration)، مدیریت و امنیت داده‌ها را در یک سازمان تعریف می‌کند. طبق چارچوب DAMA-DMBOK، معماری داده یکی از ۱۱ حوزه اصلی مدیریت داده محسوب می‌شود.

۴. مفاهیم کلیدی

۴.۱. اجزای اصلی معماری داده 🔴

۴.۲. OLTP vs OLAP 🔴

نکته کلیدی آزمون: OLTP = عملیاتی (تراکنش) | OLAP = تحلیلی (گزارش)

۴.۳. ETL vs ELT 🔴

نکته آزمونی: در ETL ابتدا داده تمیز می‌شود سپس ذخیره. در ELT ابتدا همه داده ذخیره شده سپس در مقصد تبدیل می‌شود.

۴.۴. داده ساختاریافته vs نیمه‌ساختاریافته vs بدون ساختار 🔴

نکته مهم: حدود ۸۰-۹۰٪ داده‌های سازمانی بدون ساختار هستند. دریاچه داده برای مدیریت این نوع داده‌ها طراحی شده.

۴.۵. پایگاه داده رابطه‌ای vs NoSQL 🔴

۴.۶. ACID vs BASE 🟠

۴.۷. قضیه CAP 🟠

در یک سیستم توزیع‌شده، فقط می‌توان دو مورد از سه را تضمین کرد: - C (Consistency) — سازگاری: همه نودها داده یکسان دارند - A (Availability) — دسترس‌پذیری: سیستم همیشه پاسخ می‌دهد - P (Partition Tolerance) — تحمل پارتیشن: سیستم با قطع ارتباط بین نودها کار می‌کند

نکته: P تقریباً همیشه لازم است، پس انتخاب واقعی بین C و A است.

۵. چگونه کار می‌کند؟

جریان کلی داده در معماری سازمانی:

منابع داده (Sources)
├── پایگاه‌داده عملیاتی (OLTP)
├── فایل‌ها و لاگ‌ها
├── API و وب‌سرویس
├── سنسورها و IoT
└── شبکه‌های اجتماعی
        ↓
جمع‌آوری / ETL / ELT
        ↓
ذخیره‌سازی
├── انبار داده (Data Warehouse) → داده ساختاریافته و تمیز
├── دریاچه داده (Data Lake) → همه انواع داده (خام)
└── Data Lakehouse → ترکیب هر دو
        ↓
پردازش و تحلیل
├── داشبورد و BI
├── گزارش‌گیری
├── مدل‌های ML/AI
└── تحلیل بلادرنگ
        ↓
مصرف‌کنندگان
├── مدیران ← تصمیم‌گیری
├── تحلیلگران ← بینش
├── سیستم‌های AI ← پیش‌بینی
└── برنامه‌ها ← خدمات

۶. مثال واقعی

معماری داده یک بانک بزرگ

منابع: سیستم Core Banking (OLTP)، ATM، موبایل بانک، وب‌سایت، شبکه‌های اجتماعی

جمع‌آوری: ETL شبانه از Core Banking + Streaming از تراکنش‌های لحظه‌ای

ذخیره‌سازی: انبار داده برای گزارش‌های مالی + دریاچه داده برای لاگ‌ها و داده‌های بدون ساختار

تحلیل: داشبورد مدیریتی + مدل ML تشخیص تقلب + گزارش‌های نظارتی بانک مرکزی

۷. مثال خیلی ساده

معماری داده مثل سیستم آب‌رسانی شهر است: - منابع آب = منابع داده (سد، چاه) - لوله‌کشی = ETL/ELT (انتقال) - مخزن اصلی = انبار داده / دریاچه داده (ذخیره) - تصفیه‌خانه = پاکسازی و تبدیل داده - شیر آب خانه = داشبورد و گزارش (مصرف)

۸. تفاوت مفاهیم مشابه

انبار داده vs دریاچه داده vs Data Lakehouse 🔴

ارجاع: جزئیات بیشتر در مباحث ۲ (انبار داده) و ۳ (دریاچه داده).

۹. مزایا و محدودیت‌ها

مزایا ✅

• یکپارچگی: دسترسی واحد به داده‌های پراکنده
• کیفیت: بهبود کیفیت و سازگاری داده‌ها
• مقیاس‌پذیری: طراحی برای رشد آینده
• تصمیم‌گیری بهتر: داده‌های قابل اعتماد = تصمیم بهتر

محدودیت‌ها ⛔

• پیچیدگی: طراحی و پیاده‌سازی زمان‌بر
• هزینه اولیه: سرمایه‌گذاری قابل توجه
• مدیریت تغییر: نیاز به همکاری بین واحدهای سازمانی
• Legacy Systems: سیستم‌های قدیمی ممکن است با معماری جدید سازگار نباشند

۱۰. کاربردهای مهم

۱۱. دیدگاه مشاورهای

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

• وقتی داده‌ها در سیستم‌های مختلف پراکنده هستند
• وقتی گزارش‌ها ناسازگار هستند
• وقتی می‌خواهید پروژه AI/ML راه‌اندازی کنید
• وقتی نیاز به تحلیل بلادرنگ دارید

انتخاب بین SQL و NoSQL:

• داده ساختاریافته + تراکنش ACID → SQL
• داده متنوع + مقیاس افقی + انعطاف → NoSQL

۱۲. 🔴 نکات طلایی آزمون

1. OLTP = عملیاتی (تراکنش) | OLAP = تحلیلی (گزارش)
2. ETL: استخراج → تبدیل → بارگذاری | ELT: استخراج → بارگذاری → تبدیل
3. ۸۰-۹۰٪ داده‌ها بدون ساختار: تصویر، ویدیو، متن آزاد
4. SQL = ACID (سازگاری قوی) | NoSQL = BASE (سازگاری تدریجی)
5. CAP: در سیستم توزیع‌شده فقط ۲ از ۳ (C, A, P) قابل تضمین
6. Schema-on-Write = DW (نوشتن اسکیما هنگام ذخیره) | Schema-on-Read = DL (خواندن اسکیما هنگام استفاده)
7. مقیاس‌پذیری: SQL = عمودی (Scale Up) | NoSQL = افقی (Scale Out)
8. انواع NoSQL: Document, Key-Value, Column-Family, Graph
9. Data Lakehouse: ترکیب مزایای DW و DL
10. داده ساختاریافته → SQL/DW | بدون ساختار → NoSQL/DL

۱۳. ⚠️ دام‌های رایج آزمون

دام ۱: «OLTP و OLAP یکی هستند.»
❌ OLTP = تراکنش‌های عملیاتی (INSERT/UPDATE). OLAP = تحلیل و گزارش (SELECT پیچیده).

دام ۲: «ETL و ELT تفاوتی ندارند.»
❌ تفاوت در محل تبدیل: ETL خارج از مقصد، ELT داخل مقصد.

دام ۳: «NoSQL یعنی بدون SQL و بهتر از SQL.»
❌ NoSQL = Not Only SQL (فقط SQL نیست). هرکدام برای نیاز متفاوتی مناسب‌اند.

دام ۴: «قضیه CAP یعنی می‌توان هر سه را همزمان داشت.»
❌ فقط ۲ از ۳ قابل تضمین است. P معمولاً ضروری است، پس انتخاب بین C و A.

۱۴. 🧠 خلاصه یک‌دقیقه‌ای

اگر فقط یک دقیقه وقت داشتم...

• معماری داده = نقشه کلی جریان داده سازمان (جمع‌آوری → ذخیره → پردازش → مصرف)
• OLTP = عملیاتی/تراکنش | OLAP = تحلیلی/گزارش
• ETL = تبدیل قبل از بارگذاری | ELT = تبدیل بعد از بارگذاری
• ساختاریافته (جدول) | نیمه‌ساختاریافته (JSON) | بدون ساختار (تصویر)
• SQL = ACID + عمودی | NoSQL = BASE + افقی
• CAP: فقط ۲ از ۳ (Consistency, Availability, Partition Tolerance)
• ۸۰-۹۰٪ داده‌ها بدون ساختار
• DW = ساختاریافته + تمیز | DL = همه‌چیز + خام | Lakehouse = ترکیب

۱۵. نقشه ذهنی

معماری داده (Data Architecture)
│
├── منابع → جمع‌آوری → ذخیره → پردازش → مصرف
│
├── انواع سیستم
│   ├── OLTP ← تراکنش عملیاتی
│   └── OLAP ← تحلیل و گزارش
│
├── انتقال داده
│   ├── ETL ← تبدیل قبل از بارگذاری
│   └── ELT ← تبدیل بعد از بارگذاری
│
├── انواع داده
│   ├── ساختاریافته (SQL, CSV)
│   ├── نیمه‌ساختاریافته (JSON, XML)
│   └── بدون ساختار (Image, Video, Text)
│
├── پایگاه داده
│   ├── SQL (رابطه‌ای) ← ACID, Scale Up
│   └── NoSQL ← BASE, Scale Out
│       ├── Document (MongoDB)
│       ├── Key-Value (Redis)
│       ├── Column (Cassandra)
│       └── Graph (Neo4j)
│
├── ذخیره‌سازی
│   ├── Data Warehouse ← ساختاریافته
│   ├── Data Lake ← همه‌چیز (خام)
│   └── Data Lakehouse ← ترکیب
│
└── قوانین
    ├── ACID vs BASE
    └── قضیه CAP (۲ از ۳)

۱۶. ارتباط با سایر مباحث

۱۷. سؤالات احتمالی آزمون