معماری پردازش پرس‌وجوهای فدرال

یکپارچگی منطقی در دنیای فیزیکی پراکنده

🔴 ۱. مقدمه: شکست استراتژی «یک مخزن برای همه چیز»

برای دو دهه، دکترین اصلی مدیریت داده در سازمان‌ها بر یک اصل استوار بود: تجسیم فیزیکی (Physical Consolidation).
ایده این بود که تمام داده‌ها را از سیستم‌های عملیاتی (ERP, CRM, Web Logs) استخراج کنیم (Extract)، آن‌ها را تغییر دهیم (Transform) و در یک مخزن واحد و عظیم مثل Data Warehouse یا بعدها Data Lake بارگذاری کنیم (Load).

اما با ظهور Big Data و معماری‌های ابری، این رویکرد با بن‌بست‌های جدی مواجه شد:

• جاذبه داده (Data Gravity): حجم داده‌ها آن‌قدر زیاد شده (پتابایت) که جابجایی آن‌ها به یک مکان مرکزی، از نظر هزینه پهنای باند و زمان، غیرممکن یا بسیار گران است.

• تاخیر در دسترسی (Data Latency): فرآیندهای ETL/ELT معمولاً شبانه اجرا می‌شوند. کسب‌وکارها نیاز به تحلیل Real-time دارند، نه تحلیل داده‌های دیروز.

• تنوع منابع: داده‌ها دیگر فقط ساختاریافته (SQL) نیستند. ما با NoSQL، فایل‌های Parquet در S3، لاگ‌های Kafka و APIهای SaaS سروکار داریم.

در این نقطه، معماری پردازش فدرال به عنوان راه‌حلی برای دسترسی به داده‌ها «در محل سکونت‌شان» (Data in Place) ظهور کرد.

🟠 ۲. تعریف و فلسفه: فدریشن داده (Data Federation) چیست؟

پردازش پرس‌وجوی فدرال (Federated Query Processing) یک لایه انتزاعی نرم‌افزاری است که به کاربران اجازه می‌دهد چندین منبع داده ناهمگن (Heterogeneous) را طوری پرس‌وجو کنند که گویی تمام داده‌ها در یک پایگاه داده واحد رابطه‌ای (Relational) قرار دارند.

تفاوت کلیدی با انبار داده:

• در Data Warehouse، داده‌ها کپی و جابجا می‌شوند.

• در Data Federation، داده‌ها در منبع اصلی باقی می‌مانند. موتور پردازش، کوئری را به سمت داده می‌برد، نه داده را به سمت کوئری (تا حد امکان).

این رویکرد گاهی «انبار داده منطقی» (Logical Data Warehouse) یا «مجازی‌سازی داده» (Data Virtualization) نیز نامیده می‌شود.

🟡 ۳. معماری کلان سیستم‌های پردازش فدرال

یک موتور فدرال مدرن (مانند Trino یا Starburst) معمولاً از یک معماری MPP (Massively Parallel Processing) پیروی می‌کند. اجزای آن:

🟢 الف) لایه کلاینت (Client Interface)

نقطه ورود کاربر است. معمولاً پروتکل‌های استاندارد JDBC/ODBC یا REST API را ارائه می‌دهد. ابزارهای BI (مانند Tableau, PowerBI) یا نوت‌بوک‌های Jupyter به این لایه متصل می‌شوند و کوئری‌های SQL استاندارد (ANSI SQL) ارسال می‌کنند.

🟢 ب) هسته هماهنگ‌کننده (Coordinator Node)

این «مغز متفکر» کلاستر است. وظایف آن عبارتند از:

• دریافت کوئری SQL از کلاینت.

• تجزیه (Parse) و اعتبارسنجی کوئری.

• تدوین طرح اجرا (Execution Plan).

• مدیریت Workerها و توزیع وظایف.

هماهنگ‌کننده هیچ پردازش سنگینی روی داده‌ها انجام نمی‌دهد؛ او فقط مدیر پروژه است.

🟢 ج) لایه محاسباتی کارگر (Worker Nodes)

این‌ها «عضلات» سیستم هستند:

• اتصال به منابع داده.

• خواندن داده‌ها.

• انجام عملیات سنگین مثل فیلتر کردن، Join، Aggregation و مرتب‌سازی.

• تبادل داده‌های میانی با یکدیگر (Data Shuffle) برای تکمیل Joinها.

🟢 د) کانکتورها (Connectors / SPI)

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

• کانکتور PostgreSQL: کوئری را به SQL بومی پستگرس ترجمه می‌کند.

• کانکتور Kafka: استریم‌ها را به صورت جدول می‌بیند.

• کانکتور Hive/S3: فایل‌های Parquet/ORC را باز کرده و می‌خواند.

🟣 ۴. کالبدشکافی موتور پردازش: زیر کاپوت چه می‌گذرد؟

وقتی شما یک کوئری ساده می‌نویسید، یک فرآیند پیچیده مهندسی آغاز می‌شود:

مرحله ۱: تجزیه و تحلیل (Parsing & Analysis)

متن SQL به یک درخت نحوی انتزاعی (AST) تبدیل می‌شود. سیستم چک می‌کند که آیا جداول و ستون‌ها وجود دارند؟ آیا کاربر دسترسی دارد؟ نوع داده‌ها (Type Checking) درست است؟

مرحله ۲: بهینه‌سازی منطقی (Logical Optimization)

در اینجا، موتور سعی می‌کند کوئری را بدون توجه به نحوه اجرای فیزیکی آن، ساده‌تر کند:

• حذف شروط همیشه صادق (Constant Folding).

• حذف ستون‌های اضافی که در نتیجه نهایی استفاده نمی‌شوند (Column Pruning).

مرحله ۳: بهینه‌ساز مبتنی بر هزینه (Cost-Based Optimizer – CBO)

این قلب تپنده سیستم است. CBO باید تصمیم بگیرد «چگونه» کوئری را اجرا کند.

سناریو: Join کردن یک جدول کوچک (۱۰۰۰ ردیف) با یک جدول غول‌پیکر (۱ میلیارد ردیف).

تصمیم: CBO با نگاه به آمار جداول (Statistics)، تصمیم می‌گیرد جدول کوچک را در حافظه تمام Workerها کپی کند (Broadcast Join) به جای اینکه جدول بزرگ را جابجا کند (Partitioned Join). این تصمیم می‌تواند سرعت را ۱۰۰ برابر کند.

🟢 تکنیک حیاتی: Predicate Pushdown (فروبردن شرط‌ها)

این مهم‌ترین مفهوم در فدریشن است.
فرض کنید کوئری شما این است:

SELECT * FROM huge_table_in_mysql WHERE id > 5000

• روش غلط (بدون Pushdown): موتور فدرال تمام ۱ میلیون رکورد را از MySQL می‌خواند، به حافظه Worker می‌آورد و سپس خودش شرط id > 5000 را چک می‌کند. این کار شبکه را نابود می‌کند.

• روش صحیح (با Pushdown): موتور فدرال می‌فهمد که MySQL خودش می‌تواند فیلتر کند. پس کوئری SELECT * FROM table WHERE id > 5000 را به MySQL می‌فرستد و فقط رکوردهای فیلتر شده را دریافت می‌کند.

این تکنیک برای Aggregation (مثل SUM, COUNT) و Limit (TOP 10) نیز اعمال می‌شود.

🔵 ۵. سناریوی عملیاتی گام‌به‌گام: تحلیل ۳۶۰ درجه مشتری

هدف: پیدا کردن مشتریانی که در ماه گذشته خریدی داشته‌اند (SQL Server) اما لاگ‌های وب‌سایت نشان می‌دهد که شکایات ثبت کرده‌اند (MongoDB) و ساکن کالیفرنیا هستند.

منابع داده:

• SQL Server: جدول Orders (تراکنشی).

• MongoDB: کالکشن Support_Logs (نیمه ساخت‌یافته).

• S3 (Parquet): جدول Customers (اطلاعات پایه).

کوئری کاربر:

SELECT 
    c.name, 
    o.amount, 
    l.complaint_text
FROM 
    s3.datalake.customers c
JOIN 
    sqlserver.db.orders o ON c.id = o.customer_id
JOIN 
    mongo.logs.support l ON c.email = l.email
WHERE 
    c.state = 'CA' 
    AND o.date > DATE '2023-10-01'

گام ۱: دریافت و برنامه‌ریزی

هماهنگ‌کننده (Coordinator) کوئری را دریافت می‌کند. CBO فعال می‌شود.

گام ۲: Pushdown و خواندن موازی

• S3 Connector: فقط فایل‌های Parquet مربوط به مشتریان ایالت ‘CA’ را می‌خواند (Partition Pruning).

• SQL Server Connector: کوئری SELECT customer_id, amount FROM orders WHERE date > '2023-10-01' را تولید کرده و به SQL Server می‌فرستد (Projection & Predicate Pushdown).

• MongoDB Connector: چون Mongo اسکیما ندارد، موتور احتمالاً فیلد email و complaint_text را درخواست می‌کند.

گام ۳: توزیع داده (Shuffle & Join)

Workerها داده‌های فیلتر شده را دریافت می‌کنند.
ابتدا جدول Customers (که با شرط CA کوچک شده) با Orders جوین می‌شود.
برای Join، داده‌ها بر اساس customer_id هش (Hash) شده و بین Workerها پخش می‌شوند تا رکوردهای با ID یکسان در یک نود قرار بگیرند.

گام ۴: Dynamic Filtering

موتور هوشمند متوجه می‌شود که فقط مشتریان کالیفرنیا مد نظر هستند. پس ID این مشتریان را استخراج کرده و به صورت پویا (Dynamic) به Workerهایی که مشغول خواندن SQL Server هستند تزریق می‌کند تا حتی داده‌های کمتری از SQL Server خوانده شود.

گام ۵: تجمیع نهایی

نتایج Join اول با داده‌های MongoDB (بر اساس ایمیل) Join می‌شود و نتیجه نهایی به کلاینت بازگردانده می‌شود.

🟤 ۶. تکنولوژی‌های پیشرو

• Trino (سابقاً PrestoSQL): استاندارد طلایی پردازش فدرال. متن‌باز، بسیار سریع، و مقیاس‌پذیر. توسط فیس‌بوک برای کوئری روی ۳۰۰ پتابایت داده ساخته شد.

• Starburst: نسخه Enterprise تریینو. امکانات امنیتی، کانکتورهای بیشتر و بهینه‌سازی‌های خاص ارائه می‌دهد.

• Dremio: تمرکز شدید روی Data Lakehouse. از تکنولوژی Apache Arrow (فرمت ستونی در حافظه) برای سرعت فوق‌العاده استفاده می‌کند و مفهومی به نام Data Reflections (نوعی کش هوشمند) دارد.

• Google BigQuery Omni: اجازه می‌دهد کوئری‌های BigQuery روی داده‌های AWS S3 یا Azure Blob اجرا شوند بدون جابجایی داده.

⚫ ۷. چالش‌های فنی و استراتژی‌های کاهش ریسک

فدریشن جادو نیست و هزینه دارد.

چالش ۱: گلوگاه شبکه (Network Bottleneck)

انتقال حجم زیاد داده بین دیتابیس منبع و موتور فدرال می‌تواند شبکه را اشباع کند.
راهکار: استفاده حداکثری از Pushdown، فشرده‌سازی داده‌ها در حین انتقال (LZ4, Zstd) و استفاده از فرمت‌های ستونی باینری.

چالش ۲: ناهمگونی عملکرد (Performance Skew)

اگر در یک Join، یکی از منابع (مثلاً یک MySQL قدیمی) کند باشد، کل کوئری کند می‌شود. سیستم به اندازه کندترین جزء خود سریع است.
راهکار: تعریف Timeout برای منابع، استفاده از Materialized Views در لایه فدرال برای کش کردن داده‌های منابع کند.

چالش ۳: امنیت (Security Explosion)

چگونه دسترسی کاربری که در LDAP شرکت است را به MongoDB که یوزرهای خودش را دارد نگاشت کنیم؟
راهکار: استفاده از Identity Federation (مانند Kerberos یا OAuth). موتور فدرال با یک «Service Account» قدرتمند به منابع وصل می‌شود اما در لایه خودش، دسترسی‌های کاربر نهایی را چک می‌کند (User Impersonation یا View-based access control).

🟢 ۸. رابطه با Data Mesh و Data Fabric

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

• Data Mesh: این یک مفهوم سازمانی است (تمرکززدایی و مالکیت داده توسط تیم‌های دامنه). برای اینکه تیم‌ها بتوانند «محصولات داده» (Data Products) خود را به اشتراک بگذارند بدون اینکه آن‌ها را کپی کنند، به یک موتور پرس‌وجوی فدرال نیاز دارند تا این محصولات را به هم وصل کند.

• Data Fabric: این رویکرد بر استفاده از متادیتا و هوش مصنوعی برای یکپارچگی تمرکز دارد. موتور فدرال به عنوان لایه دسترسی (Access Layer) در دیتا فابریک عمل می‌کند.

🔵 ۹. آینده فدریشن: پردازش هوشمند و کشینگ معنایی

آینده این معماری به سمت هوشمندتر شدن می‌رود:

• کشینگ معنایی (Semantic Caching): سیستم به جای کش کردن بایت‌ها، معنای کوئری را می‌فهمد. اگر قبلاً «فروش کل سال» محاسبه شده، برای کوئری «فروش ماه دی»، از کش سالانه استفاده می‌کند و آن را فیلتر می‌کند.

• Machine Learning for Optimizer: استفاده از ML برای پیش‌بینی زمان اجرای کوئری و انتخاب بهترین منابع به صورت پویا.

• Hybrid Execution: بخشی از کوئری روی لبه (Edge) و بخشی در ابر پردازش شود.

🟣 ۱۰. نتیجه‌گیری

معماری پردازش پرس‌وجوی فدرال، پایان دوران دیکتاتوری انبار داده‌های یکپارچه است. این معماری به سازمان‌ها چابکی (Agility) می‌دهد تا بدون ماه‌ها زمان برای ساخت پایپ‌لاین‌های ETL، به داده‌ها دسترسی پیدا کنند.

برای معماران سازمانی، گذار به فدریشن به معنای پذیرش پیچیدگی در لایه محاسبات برای خرید سادگی در لایه مدیریت داده است. با استفاده از ابزارهایی مانند Trino و رعایت اصول بهینه‌سازی (Pushdown)، می‌توان پلی مستحکم بین جزایر داده‌ای سازمان بنا کرد و رویای «Single Source of Truth» را به صورت منطقی، و نه فیزیکی، محقق ساخت.