Microsoft Fabric Data Warehouse چیست؟ معماری، OneLake، Polaris و مقایسه با SQL Server

صور کنید یک شرکت خرده‌فروشی، داده تراکنشی را در SQL Server نگه می‌دارد، برای گزارش‌گیری تحلیلی از یک Data Warehouse جداگانه در Azure Synapse استفاده می‌کند، و برای داده نیمه‌ساختاریافته (لاگ کلیک، رویدادهای اپلیکیشن موبایل) یک Data Lake مجزا در Azure Data Lake Storage دارد. هر بار که تیم BI بخواهد گزارشی بسازد که این سه منبع را ترکیب کند، باید داده را بین سیستم‌ها Copy، Transform و هماهنگ نگه دارد یعنی سه‌نسخه از یک واقعیت، با ریسک ناهماهنگی دائمی.

Microsoft Fabric Data Warehouse دقیقاً برای حل همین مسئله طراحی شده: یک موتور Data Warehousing کاملاً مبتنی بر T-SQL که روی یک لایه ذخیره‌سازی واحد به نام OneLake اجرا می‌شود و با Lakehouse، Power BI و ابزارهای تحلیلی دیگر این پلتفرم به‌اشتراک گذاشته می‌شود. برای مدیران زیرساخت و DBAهایی که سال‌ها با SQL Server کار کرده‌اند، این محصول شبیه یک ادامه طبیعی به‌نظر می‌رسد، اما از نظر معماری تفاوت‌های بنیادینی دارد که در ادامه بررسی می‌شود.

این سرویس دقیقاً در کجای اکوسیستم Microsoft Fabric قرار می‌گیرد

Microsoft Fabric یک پلتفرم یکپارچه SaaS برای تحلیل داده است که Data Engineering، Data Warehousing، Data Science، Real-Time Analytics و Power BI را زیر یک چتر واحد قرار می‌دهد. در این اکوسیستم، Fabric Warehouse یکی از چند تجربه (Experience) موجود است که مخصوص بار کاری تحلیلی ساختاریافته و مبتنی بر T-SQL طراحی شده، در کنار Lakehouse که برای داده نیمه‌ساختاریافته و بار کاری Spark مناسب‌تر است.

نکته‌ای که سردرگمی زیادی ایجاد می‌کند این است که Warehouse و Lakehouse، هر دو روی همان فرمت ذخیره‌سازی (Delta Parquet) و همان لایه فیزیکی (OneLake) کار می‌کنند. یعنی جدولی که در یک Warehouse ساخته می‌شود، از طریق یک Lakehouse یا یک Notebook Spark در همان Workspace نیز قابل خواندن است، بدون فرآیند جداگانه Export/Import. این برخلاف مدل قدیمی Synapse است که Dedicated SQL Pool و Spark Pool، دو فضای ذخیره‌سازی کاملاً جدا داشتند.

برای یک سازمان که تیم مهندسی داده با Python/Spark کار می‌کند و تیم BI با T-SQL، این یکپارچگی یعنی هر دو تیم می‌توانند روی یک نسخه از داده کار کنند، نه دو کپی که باید هماهنگ نگه داشته شوند مزیتی که در معماری‌های قدیمی‌تر تقریباً هیچ‌وقت به‌طور کامل محقق نمی‌شد.

OneLake کاهش نیاز به کپی‌های تکراری داده

OneLake لایه ذخیره‌سازی واحد و سازمانی این پلتفرم است که می‌توان آن را مشابه یک OneDrive برای داده تصور کرد یعنی یک فضای ذخیره‌سازی واحد در سطح Tenant که همه Workspaceهای Fabric می‌توانند از فضای مشترک OneLake استفاده کنند. هر داده‌ای که در Fabric Data Warehouse نوشته می‌شود، به‌صورت فایل‌های Parquet در قالب فرمت باز Delta Lake در OneLake ذخیره می‌شود.

این طراحی یک تفاوت بنیادین با SQL Server دارد: در SQL Server، داده در فایل‌های اختصاصی MDF/LDF با فرمت داخلی مایکروسافت ذخیره می‌شود که فقط توسط موتور SQL Server قابل خواندن است. در Fabric، چون فرمت ذخیره‌سازی Delta Parquet است، همان داده را می‌توان مستقیماً با Spark یا با ابزارهای خارج از اکوسیستم مایکروسافت مانند Databricks خواند. برای اتصال Power BI مشخصاً، این یعنی از طریق حالت Direct Lake نیازی به کپی کردن داده در حافظه مدل گزارش نیست این ادعا در بخش‌های بعدی با دقت بیشتری محدوده‌بندی می‌شود، چون در همه سناریوهای ورود داده یا بین همه سرویس‌ها به همین شکل مطلق صدق نمی‌کند.

برای یک بانک یا یک اپراتور مخابراتی که چندین تیم تحلیلی مختلف (ریسک، بازاریابی، مالی) روی داده مشترک کار می‌کنند، این معماری یعنی حذف بسیاری از Pipelineهای ETL که صرفاً برای انتقال داده بین سیستم‌های جزیره‌ای ساخته شده بودند.

موتور محاسباتی Polaris تفاوت بنیادین با موتور SQL Server

موتور اجرای Query در Fabric Warehouse، به نام Polaris، یک موتور توزیع‌شده (Distributed) و بدون‌سرور (Serverless) است که کاملاً از موتور SQL Server کلاسیک متفاوت است. در SQL Server سنتی، پردازش Query روی یک نمونه (Instance) با منابع محاسباتی ثابت انجام می‌شود برای افزایش کارایی، باید سخت‌افزار قوی‌تر خرید یا Scale-up کرد.

Polaris در مقابل، هر Query را به واحدهای کوچک‌تر تقسیم می‌کند و آن‌ها را روی مجموعه‌ای از گره‌های محاسباتی به‌صورت موازی اجرا می‌کند، بدون آنکه DBA نیازی به مدیریت این گره‌ها داشته باشد. این یعنی یک Query تحلیلی سنگین روی چند میلیارد ردیف، به‌جای اجرا روی یک هسته پردازشی، بین ده‌ها Worker موازی تقسیم می‌شود و نتیجه ترکیب‌شده بازمی‌گردد.

اثر عملی این تفاوت برای DBA این است که تنظیم دستی Index، Fill Factor، یا برنامه‌ریزی Maintenance Plan برای Rebuild Index، به این شکل که در SQL Server می‌شناسیم، در این معماری وجود ندارد در عوض، در Fabric Data Warehouse خبری از طراحی و نگهداری دستی Index مانند SQL Server نیست. موتور Polaris نحوه سازمان‌دهی و بهینه‌سازی داده را متناسب با معماری ستونی و توزیع‌شده خود مدیریت می‌کند و تمرکز توسعه‌دهنده بیشتر بر مدل داده و الگوی توزیع Query است تا طراحی Index. برای DBAیی که سال‌ها تخصص خود را روی تنظیم دستی Index و Query Plan گذاشته، این تغییر معنی‌دار است: بخشی از این مهارت‌ها به معماری داده و مدل‌سازی جدول منتقل می‌شود، نه حذف تنظیم عملکرد به‌کلی.

چرا Polaris در عمل سریع‌تر است نگاهی داخل موتور اجرا

سؤالی که تقریباً هر DBA هنگام مواجهه با این معماری می‌پرسد این است که این سرعت از کجا می‌آید. پاسخ در ترکیب چند تکنیک اجرای Query است که در موتور SQL Server کلاسیک به این شکل وجود ندارد.

اول، Distributed Execution: به‌جای اجرای یک Query روی یک Thread یا مجموعه محدودی از Threadها، Polaris آن را به گراف اجرای موازی تقسیم می‌کند. در این فرآیند، Shuffle (جابه‌جایی داده بین گره‌ها برای عملیات‌هایی مانند Join یا Group By) و Broadcast (ارسال یک نسخه کوچک از جدول به همه گره‌ها، مناسب برای Join جداول کوچک با جداول بزرگ) دو الگوی کلیدی هستند که بهینه‌ساز Query به‌صورت خودکار بین آن‌ها انتخاب می‌کند.

دوم، Columnar Execution و Vectorized Execution: داده در فرمت Parquet به‌صورت ستونی ذخیره می‌شود، یعنی برای Query‌ای که فقط به سه ستون از یک جدول ۵۰ ستونی نیاز دارد، فقط همان سه ستون از دیسک خوانده می‌شود. Vectorized Execution به این معناست که عملیات روی دسته‌هایی از مقادیر (Batch) به‌جای یک ردیف در هر لحظه انجام می‌شود، که بهره‌وری CPU را به‌طور قابل‌توجهی افزایش می‌دهد.

سوم، Predicate Pushdown و Partition Elimination: شرط‌های فیلتر (WHERE) تا حد امکان به نزدیک‌ترین لایه به فایل فیزیکی هل داده می‌شوند، و اگر جدول بر اساس یک ستون (مثلاً تاریخ) Partition شده باشد، موتور می‌تواند کل بخش‌هایی از داده را که با شرط Query مطابقت ندارند، بدون خواندن حتی یک بایت از آن‌ها نادیده بگیرد.

نتیجه این است که Polaris به‌جای افزایش قدرت یک سرور، بار پردازشی را بین چندین گره توزیع می‌کند و به همین دلیل برای Queryهای تحلیلی بزرگ عملکرد بسیار بهتری نسبت به معماری سنتی SQL Server دارد این تفاوت، نه یک بهبود جزئی، بلکه یک تغییر بنیادین در نحوه پردازش داده حجیم تحلیلی است.

تفاوت بنیادین جدایی کامل ذخیره‌سازی از محاسبات

شاید مهم‌ترین تفاوت معماری این پلتفرم با SQL Server، جدایی کامل لایه ذخیره‌سازی از لایه محاسباتی است. در SQL Server، چه نسخه on-premises و چه Azure SQL Managed Instance، ذخیره‌سازی و محاسبات به‌هم گره خورده‌اند افزایش فضای دیسک یا افزایش قدرت CPU معمولاً نیازمند تغییر در همان منبع (Instance یا Server) است.

در Fabric Warehouse، داده در OneLake به‌صورت مستقل از منابع محاسباتی نگهداری می‌شود و مصرف محاسباتی بر اساس واحدی به نام Capacity Unit (CU) اندازه‌گیری و صورتحساب می‌شود، نه بر اساس حجم داده ذخیره‌شده. یعنی یک سازمان می‌تواند چند صد ترابایت داده در OneLake نگه دارد بدون آنکه هزینه محاسباتی ثابتی برای آن پرداخت کند، و فقط زمانی که Query واقعی روی آن اجرا می‌شود، هزینه محاسباتی متحمل شود.

این مدل برای فروشگاه‌های اینترنتی با بار فصلی مزیت مشخصی دارد: به‌جای Provisioning ثابت برای اوج بار سالانه، Capacity می‌تواند بر اساس نیاز واقعی Scale شود. البته این مزیت به قیمت پیچیدگی جدیدی می‌آید که در بخش هزینه‌ها با جزئیات بیشتری بررسی می‌شود.

سازگاری T-SQL، اما نه معادل کامل

این معماری از T-SQL به‌عنوان زبان اصلی پشتیبانی می‌کند، که برای DBAها و توسعه‌دهندگانی که سال‌ها با SQL Server کار کرده‌اند، منحنی یادگیری را به‌شدت کاهش می‌دهد. با این حال، این سازگاری کامل نیست و تفاوت‌های مهمی وجود دارد که در پروژه‌های مهاجرت واقعی، معمولاً بزرگ‌ترین منبع اشتباه هستند.

برای مثال، این پلتفرم از Stored Procedureهای پیچیده با Cursor، از Triggerها، و از برخی توابع تعریف‌شده توسط کاربر (Scalar UDF) که در SQL Server رایج‌اند، پشتیبانی نمی‌کند. همچنین محدودیت‌های Isolation Level متفاوت است، معماری تراکنش‌ها مبتنی بر نسخه‌بندی داده (MVCC) و مناسب بارهای تحلیلی است و از نظر رفتار با SQL Server سنتی تفاوت دارد.

-- در SQL Server معمول است:
CREATE TRIGGER trg_AfterInsert ON Orders
AFTER INSERT AS ...

-- در Fabric Data Warehouse این ساختار پشتیبانی نمی‌شود
-- منطق معادل باید در Pipeline یا Stored Procedure جداگانه پیاده‌سازی شود.

توصیه عملی برای هر پروژه مهاجرت این است که پیش از شروع، یک ارزیابی سازگاری (Compatibility Assessment) روی کدهای T-SQL موجود انجام شود، نه اینکه فرض شود «چون T-SQL است، بدون تغییر اجرا می‌شود». تجربه پروژه‌های واقعی نشان می‌دهد این فرض نادرست، رایج‌ترین دلیل تأخیر در پروژه‌های مهاجرت است.

یکی دیگر از تفاوت‌های مهم، مدل اجرای تراکنش‌ها است. SQL Server برای بارهای کاری OLTP با تراکنش‌های کوتاه، پرتعداد و هم‌زمان طراحی شده و قابلیت‌هایی مانند Locking، Isolation Levelهای متنوع و مدیریت دقیق تراکنش‌ها را در اختیار قرار می‌دهد. در مقابل، Microsoft Fabric Data Warehouse برای پردازش‌های تحلیلی (OLAP) بهینه شده است. اگرچه از تراکنش‌ها و ویژگی‌های ACID برای عملیات پشتیبانی‌شده استفاده می‌کند، اما معماری آن برای اجرای حجم بالای تراکنش‌های کوچک و هم‌زمان مانند سیستم‌های ثبت سفارش، بانکداری یا ERP طراحی نشده است. بنابراین هنگام مهاجرت نباید انتظار داشت همان الگوهای تراکنشی SQL Server بدون تغییر در Fabric نیز بهترین کارایی را داشته باشند.

Direct Lake تغییری که مدل گزارش‌گیری Power BI را بازتعریف کرد

پیش از این پلتفرم، Power BI دو حالت اصلی اتصال داشت: Import، که داده را در حافظه مدل کپی می‌کند و سریع است اما نیازمند Refresh دوره‌ای و محدود به حجم حافظه است و DirectQuery، که هر بار مستقیماً به منبع داده Query می‌زند و برای داده حجیم مناسب است اما کندتر و وابسته به کارایی منبع داده.

Direct Lake حالت سومی است: Power BI مستقیماً فایل‌های Delta Parquet را از OneLake می‌خواند، بدون ایجاد یک Import Model سنتی که نیازمند Refresh دوره‌ای باشد (مثل Import) و بدون نیاز به اجرای Query روی موتور SQL برای هر تعامل کاربر (مثل DirectQuery). این یعنی سرعتی نزدیک به Import، با تازگی داده‌ای نزدیک به DirectQuery. لازم به ذکر است این مزیت مشخصاً برای مسیر Power BI به OneLake صدق می‌کند در سایر مسیرهای ورود داده به Warehouse، مانند بارگذاری از یک منبع خارجی، همچنان یک مرحله انتقال داده اولیه لازم است.

اثر عملی این ویژگی برای یک تیم BI بزرگ، حذف یکی از قدیمی‌ترین مصالحه‌های طراحی گزارش است: دیگر لازم نیست بین «سرعت» و «تازگی داده» یکی را انتخاب کرد. برای یک شرکت بیمه که گزارش‌های ریسک باید هم سریع باز شوند و هم دقیقه‌به‌دقیقه به‌روز باشند، این تغییر معماری، ارزشی به‌مراتب بیشتر از صرفاً یک بهبود کارایی دارد.

مدل امنیتی چندلایه از Instance تا Entra ID و Purview

در SQL Server سنتی، امنیت معمولاً در سطح Instance، Database، Schema و Object تعریف می‌شود، با Loginها و Roleهای آشنا برای هر DBA. در این پلتفرم، مدل امنیتی چند لایه اضافه دارد که باید هم‌زمان مدیریت شوند.

لایه هویت، بر پایه Microsoft Entra ID (نام جدید Azure Active Directory) است همه دسترسی‌ها، چه انسانی و چه بین‌سرویسی، از این هویت مرکزی عبور می‌کنند. برای ارتباط بین سرویس‌ها بدون نگهداری رمز عبور یا کلید در کد، Managed Identity استفاده می‌شود، همان‌طور که در نمونه COPY INTO بخش بعد دیده می‌شود. لایه بعدی، Workspace-level Roles است که تعیین می‌کند چه کسی به کل یک Workspace دسترسی دارد، پیش از آنکه اصلاً به سطح Object برسیم.

Row-Level Security (RLS) با همان منطق T-SQL آشنا در SQL Server پیاده‌سازی می‌شود:

CREATE FUNCTION dbo.fn_SecurityPredicate(@RegionID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Result
WHERE @RegionID = CAST(SESSION_CONTEXT(N'RegionID') AS INT);

CREATE SECURITY POLICY RegionFilter
ADD FILTER PREDICATE dbo.fn_SecurityPredicate(RegionID)
ON dbo.Sales
WITH (STATE = ON);

اما یک لایه حاکمیتی هم اضافه می‌شود که در SQL Server سنتی معادل مستقیمی ندارد: Microsoft Purview، که برای طبقه‌بندی داده حساس (Sensitivity Labels مانند «محرمانه» یا «فقط داخلی»)، و برای رهگیری مسیر داده از منبع تا گزارش نهایی (Data Lineage) استفاده می‌شود. برای یک بانک یا شرکت بیمه، ترکیب Sensitivity Labels و Lineage در Purview یعنی می‌توان نشان داد یک فیلد حساس از کدام منبع، از طریق کدام Pipeline، به کدام گزارش نهایی رسیده است.

مدل هزینه از vCore/DTU به Capacity Unit

مدل قیمت‌گذاری SQL Server، چه در Azure SQL Database (DTU یا vCore) و چه در لایسنس on-premises، معمولاً بر اساس منابع محاسباتی اختصاص‌یافته به یک منبع مشخص است. Fabric از یک مدل متفاوت به نام Capacity Unit (CU) استفاده می‌کند که در سطح یک Fabric Capacity خریداری می‌شود و بین همه Workloadهای این پلتفرم در آن Capacity به‌اشتراک گذاشته می‌شود.

این مدل اشتراکی مزیت دارد: اگر تیم BI امروز بار کاری کمی روی Warehouse دارد اما تیم مهندسی داده در حال اجرای Pipelineهای سنگین Spark است، منابع محاسباتی مشترک، بدون نیاز به خرید جداگانه برای هر بخش، بین آن‌ها توزیع می‌شود. اما همین اشتراک‌گذاری یک ریسک عملیاتی جدید ایجاد می‌کند: اگر یک تیم Query سنگین و بدون بهینه‌سازی اجرا کند، می‌تواند منابع Capacity مشترک را برای تیم‌های دیگر هم مصرف کند، پدیده‌ای که به آن Noisy Neighbor گفته می‌شود.

برای مدیریت این ریسک، ابزارهایی مانند Capacity Metrics App ارائه می‌شود که مصرف هر Item را در سطح Capacity رصد می‌کند. توصیه عملی برای سازمان‌های بزرگ، تفکیک Capacityهای جداگانه برای بار کاری تولید و توسعه، و پایش منظم این متریک‌ها پیش از آنکه مصرف یک تیم روی تجربه کاربری تیم‌های دیگر اثر بگذارد است.

الگوهای ورود داده از COPY INTO تا Dataflows Gen2

ورود داده به Fabric Data Warehouse چند مسیر اصلی دارد که هرکدام برای سناریوی متفاوتی مناسب‌اند.
برای بارگذاری حجیم و سریع فایل‌های موجود در OneLake یا Azure Blob Storage، دستور T-SQL به نام COPY INTO مستقیم‌ترین راه است:

COPY INTO dbo.Sales
FROM 'https://onelake.dfs.fabric.microsoft.com/workspace/lakehouse/Files/sales/*.parquet'
WITH (
    FILE_TYPE = 'PARQUET',
    CREDENTIAL = (IDENTITY = 'Managed Identity')
);

جهت سناریوهایی که نیاز به Transform قبل از بارگذاری دارند، Dataflows Gen2 یک تجربه Low-code شبیه Power Query ارائه می‌دهد.
و برای Pipelineهای پیچیده‌تر با وابستگی زمانی و Orchestration، Data Pipelines مشابه Azure Data Factory عمل می‌کنند.

یک قابلیت که برای سازمان‌هایی با چند سیستم منبع اهمیت دارد، Cross-Database Query است: امکان نوشتن یک Query T-SQL که هم‌زمان از چند Warehouse یا Lakehouse مختلف در همان Workspace داده می‌خواند:

SELECT s.OrderID, c.CustomerName
FROM SalesWarehouse.dbo.Orders AS s
JOIN CustomerLakehouse.dbo.Customers AS c
    ON s.CustomerID = c.CustomerID;

این قابلیت از نظر کاربرد، تا حدی یادآور Linked Server در SQL Server است، اما بر پایه معماری مشترک OneLake و Fabric پیاده‌سازی شده و معمولاً نیاز به پیکربندی و مدیریت پیچیده Linked Server را ندارد.

Database Mirroring در Microsoft Fabric همگام‌سازی بدون ETL

یکی از قابلیت‌هایی که Microsoft Fabric را از بسیاری از پلتفرم‌های تحلیلی متمایز می‌کند، Database Mirroring است. این قابلیت امکان همگام‌سازی تقریباً بلادرنگ (Near Real-Time) داده‌ها از برخی پایگاه‌های داده عملیاتی به OneLake را فراهم می‌کند، بدون آنکه نیاز باشد برای هر جدول یک Pipeline یا فرآیند ETL جداگانه طراحی شود.

در معماری‌های سنتی، معمولاً داده ابتدا از SQL Server استخراج (Extract)، سپس تبدیل (Transform) و در نهایت در Data Warehouse بارگذاری (Load) می‌شد. علاوه بر هزینه نگهداری این Pipelineها، هرگونه تغییر در ساختار جداول یا افزایش حجم داده می‌توانست فرآیند ETL را پیچیده‌تر و پرهزینه‌تر کند.

در Fabric، Database Mirroring این روند را ساده‌تر می‌کند. پس از برقراری اتصال، تغییرات پایگاه داده به‌صورت پیوسته به OneLake منتقل می‌شوند و داده‌ها در قالب Delta Lake در دسترس سایر سرویس‌های Fabric قرار می‌گیرند. در نتیجه، Lakehouse، Warehouse، Notebookهای Spark و Power BI می‌توانند روی نسخه‌ای تقریباً به‌روز از داده کار کنند، بدون اینکه لازم باشد برای هر تغییر، فرآیند بارگذاری مجدد اجرا شود.

البته باید توجه داشت که Mirroring جایگزین کامل ETL نیست. این قابلیت وظیفه انتقال و همگام‌سازی داده را بر عهده دارد، اما اگر سازمان نیازمند پاک‌سازی داده، تجمیع اطلاعات از چند سامانه، اعمال قوانین تجاری یا ساخت مدل‌های تحلیلی پیچیده باشد، همچنان استفاده از Data Pipelineها، Dataflow Gen2 یا Notebookهای Spark ضروری خواهد بود.

به همین دلیل، Database Mirroring را باید ابزاری برای کاهش پیچیدگی انتقال داده دانست، نه حذف کامل فرآیندهای مهندسی داده. در بسیاری از پروژه‌های سازمانی، Mirroring برای دریافت داده خام استفاده می‌شود و سپس همان داده در لایه‌های بعدی Fabric پردازش، غنی‌سازی و برای گزارش‌گیری آماده می‌شود.

برای سازمان‌هایی که سال‌ها داده‌های عملیاتی خود را در SQL Server نگهداری کرده‌اند، این قابلیت می‌تواند زمان در دسترس قرار گرفتن داده در محیط تحلیلی را به‌طور محسوسی کاهش دهد و نیاز به توسعه و نگهداری تعداد زیادی Pipeline انتقال داده را کمتر کند. با این حال، پیش از انتخاب این روش باید بررسی شود که پایگاه داده مبدأ جزو منابع پشتیبانی‌شده توسط قابلیت Mirroring در نسخه فعلی Microsoft Fabric باشد، زیرا این قابلیت برای همه موتورهای پایگاه داده و همه سناریوها در دسترس نیست و دامنه پشتیبانی آن به‌مرور در حال گسترش است.

Database Mirroring در Microsoft Fabric یک قابلیت اختصاصی این پلتفرم است و نباید با Database Mirroring قدیمی SQL Server که برای High Availability استفاده می‌شد اشتباه گرفته شود این دو قابلیت اهداف و معماری متفاوتی دارند.

مقایسه فنی Microsoft Fabric Data Warehouse در برابر SQL Server

پیش از ورود به بحث محدودیت‌ها و مهاجرت، مرور فشرده تفاوت‌های کلیدی در یک نگاه کمک می‌کند:

ویژگی	SQL Server	Microsoft Fabric Data Warehouse
فرمت ذخیره‌سازی	فایل اختصاصی MDF/LDF	Delta Parquet (باز) روی OneLake
مدل محاسباتی	Instance واحد، Scale-up	Polaris، توزیع‌شده و Scale-out
مدیریت ساختار فیزیکی	Index دستی توسط DBA	خودکار توسط موتور
مدل هزینه	vCore / DTU / لایسنس on-prem	Capacity Unit مشترک بین Workloadها
پشتیبانی از تراکنش	ACID کامل، سطح ردیف	تراکنش‌های ACID برای بارهای تحلیلی، مناسب OLAP، نه OLTP پرتراکنش
اتصال Power BI	Import / DirectQuery	Direct Lake (بدون Copy در مسیر گزارش)
یکپارچگی با Spark	نیازمند ETL میانی	مستقیم از طریق OneLake
Trigger / Cursor / CLR	پشتیبانی کامل	پشتیبانی نمی‌شود
در دسترس بودن بالا (HA)	Always On Availability Groups	High Availability و بازیابی خطا به‌صورت مدیریت‌شده توسط سرویس Fabric انجام می‌شود.
بار کاری مناسب	OLTP و تحلیلی سبک	تحلیلی و گزارش‌گیری در مقیاس بزرگ

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

Microsoft Fabric Data Warehouse در برابر Synapse Dedicated SQL Pool

سؤالی که این روزها تقریباً هر سازمانی که قبلاً روی Azure Synapse سرمایه‌گذاری کرده می‌پرسد این است: آیا باید مهاجرت کرد؟ تفاوت اصلی این دو، دقیقاً در همان جدایی ذخیره‌سازی از محاسبات نهفته است. Synapse Dedicated SQL Pool، با وجود قدرت پردازشی بالا، همچنان یک مدل Provisioning ثابت دارد DWU (Data Warehouse Unit) باید از پیش انتخاب و برای آن هزینه پرداخت شود، صرف‌نظر از میزان استفاده واقعی.

این پلتفرم جدید این مدل را با Capacity Unit اشتراکی و مقیاس‌پذیر جایگزین کرده و علاوه بر آن، برخلاف Synapse که Storage اختصاصی خودش را دارد، مستقیماً روی OneLake کار می‌کند یعنی داده‌ای که در Synapse Dedicated Pool ذخیره می‌شد، برای استفاده در Spark یا Power BI نیاز به Export داشت، در حالی که در این معماری این مرز حذف شده است.

از منظر عملیاتی، مایکروسافت مسیر توسعه محصول را به‌وضوح به‌سمت Microsoft Fabric هدایت کرده و امکانات جدید عمدتاً در این پلتفرم عرضه می‌شوند، نه در Synapse Dedicated Pool. برای سازمان‌هایی که سرمایه‌گذاری سنگینی روی Synapse دارند، توصیه عملی، برنامه‌ریزی یک مسیر مهاجرت تدریجی (نه فوری) است: شروع با بارهای کاری جدید روی این پلتفرم، در حالی که Workloadهای حساس فعلی روی Synapse تا زمان اطمینان کامل از سازگاری باقی می‌مانند.

مقایسه چهار راهکار داده مایکروسافت

انتخاب بین SQL Server، Azure SQL Database، Azure Synapse Analytics و Microsoft Fabric Data Warehouse تنها به امکانات فنی وابسته نیست بلکه به نوع بار کاری، معماری سازمان و نیازهای تحلیلی بستگی دارد. هر یک از این محصولات برای سناریوی متفاوتی طراحی شده‌اند و جایگزین مستقیم یکدیگر نیستند.

این جدول نشان می‌دهد که Microsoft Fabric Data Warehouse قرار نیست جای SQL Server یا Azure SQL Database را بگیرد. SQL Server و Azure SQL Database همچنان بهترین انتخاب برای سامانه‌های تراکنشی (OLTP) هستند، در حالی که Azure Synapse Analytics و Microsoft Fabric برای تحلیل داده در مقیاس بزرگ طراحی شده‌اند. تفاوت اصلی این دو نیز در معماری یکپارچه Fabric است جایی که Warehouse، Lakehouse، Spark و Power BI همگی روی OneLake کار می‌کنند و دیگر نیازی به نگهداری چندین نسخه از یک مجموعه داده وجود ندارد. همین یکپارچگی، مهم‌ترین دلیل حرکت تدریجی مایکروسافت و بسیاری از سازمان‌ها به سمت Microsoft Fabric در پروژه‌های جدید تحلیلی است.

آنچه این پلتفرم برای آن ساخته نشده

شفافیت درباره محدودیت‌ها به‌اندازه معرفی مزایا اهمیت دارد، چون بسیاری از ناامیدی‌های پروژه‌های مهاجرت از انتظارات نادرست ناشی می‌شود، نه از ضعف واقعی محصول. Fabric Data Warehouse از ابتدا برای بار کاری تحلیلی (OLAP) طراحی شده، نه برای تراکنش‌های آنی با حجم بالای عملیات کوچک (OLTP).

مشخصاً، این محصول برای موارد زیر مناسب نیست: پردازش هزاران تراکنش UPDATE یا DELETE کوچک و همزمان که در سیستم‌های سفارش یا پرداخت رایج است Triggerها برای اجرای منطق خودکار پس از تغییر داده CLR Integration برای اجرای کد دات‌نت داخل موتور دیتابیس Service Broker برای پیام‌رسانی درون‌دیتابیسی Replication کلاسیک SQL Server Change Data Capture (CDC) به شکل سنتی آن و SQL Server Agent برای زمان‌بندی Jobهای داخل Instance.

نبود این قابلیت‌ها ضعف طراحی نیست، بلکه نتیجه مستقیم معماری توزیع‌شده و بدون‌سرور این پلتفرم است همان معماری‌ای که سرعت و مقیاس‌پذیری تحلیلی را ممکن می‌کند. سازمانی که تلاش کند این محصول را برای بار کاری OLTP به کار ببرد، معماری را برخلاف طراحی اصلی آن فشار می‌دهد. توصیه صریح این است: برای این سناریوها، SQL Server یا Azure SQL Database همچنان انتخاب درست است.

چک‌لیست پیش از شروع مهاجرت

پیش از هر تصمیم قطعی برای انتقال یک Data Warehouse موجود، مرور این فهرست می‌تواند بسیاری از شگفتی‌های ناخوشایند را زودتر آشکار کند. بررسی سازگاری T-SQL روی مجموعه‌ای واقعی از Stored Procedureها و Viewهای پرمصرف شناسایی همه Triggerهای فعال در پایگاه داده فعلی و طراحی معادل آن‌ها به‌شکل Pipeline بررسی Cursorهای موجود در کدهای قدیمی، چون این ساختار در معماری توزیع‌شده معنایی ندارد شناسایی هر نوع وابستگی به CLR Integration.

همچنین باید بررسی SQL Agent Jobهای فعلی و برنامه‌ریزی جایگزینی آن‌ها با Data Pipelines یا Notebookهای زمان‌بندی‌شده تحلیل الگوی مصرف Stored Procedureها از نظر پیچیدگی منطقی برای تخمین حجم بازنویسی لازم و برآورد اولیه هزینه Capacity بر اساس حجم Query و ساعات اوج مصرف، به‌جای تکیه صرف بر تخمین‌های فروشنده.

این چک‌لیست نباید به‌عنوان یک فرآیند صرفاً مستندسازی دیده شود هدف آن، تبدیل یک تصمیم مهاجرت پرریسک به مجموعه‌ای از تصمیمات کوچک‌تر و قابل‌ارزیابی است، پیش از آنکه هزینه واقعی پروژه صرف شود.

اشتباه رایج فرض کردن مهاجرت یک‌به‌یک از SQL Server

رایج‌ترین اشتباهی که در پروژه‌های مهاجرت واقعی دیده می‌شود، برخورد با این معماری به‌عنوان «همان SQL Server، فقط در فضای ابری» است. این فرض باعث می‌شود تیم پروژه، طراحی جدول و Stored Procedureهای موجود را بدون بازبینی معماری منتقل کند، و بعد با خطاهای سازگاری یا کارایی پایین در تولید مواجه شود.

طراحی جدول باید بر پایه اصول Distributed Query Processing باشد، نه مدل Row-store سنتی SQL Server. مثلاً انتخاب کلید Join مناسب برای کاهش Data Shuffle بین گره‌های محاسباتی Polaris، اهمیتی مشابه انتخاب Index در SQL Server سنتی دارد، اما با منطق کاملاً متفاوت. همچنین برخی الگوهای رایج SQL Server مانند استفاده گسترده از Temp Table برای مراحل میانی پردازش، باید با دقت بیشتری طراحی شوند چون رفتار Tempdb معادل در این معماری توزیع‌شده متفاوت است.

توصیه عملی، اجرای یک فاز Proof of Concept با زیرمجموعه‌ای واقعی از داده و Queryهای پرمصرف سازمان، پیش از تصمیم نهایی مهاجرت کامل است این فاز معمولاً بسیاری از فرضیات نادرست را زودتر آشکار می‌کند، وقتی هزینه اصلاح هنوز پایین است.

سناریوی سازمانی مهاجرت یک شرکت بیمه از Synapse Dedicated Pool

یک شرکت بیمه را در نظر بگیرید که برای سال‌ها از Azure Synapse Dedicated SQL Pool برای گزارش‌گیری ریسک استفاده کرده است. تیم IT با مشکل هزینه ثابت بالای Dedicated Pool مواجه است، چون باید ظرفیت را برای پیک ماهانه (بستن حساب‌های مالی) Provision کند، در حالی که در بقیه روزهای ماه، بیشتر این ظرفیت بلااستفاده می‌ماند.

با مهاجرت به این پلتفرم، این شرکت می‌تواند از مدل Capacity Unit مقیاس‌پذیر استفاده کند: در روزهای عادی با Capacity کوچک‌تر کار کند و در دوره بستن حساب‌های مالی، Capacity را موقتاً افزایش دهد. علاوه بر این، چون داده در OneLake با فرمت باز Delta Parquet ذخیره می‌شود، تیم علم داده شرکت که با Python و Spark کار می‌کند، می‌تواند مستقیماً همان داده ریسک را برای مدل‌های پیش‌بینی زیان بخواند، بدون نیاز به Export جداگانه که پیش‌تر هفته‌ها زمان می‌برد.

نتیجه عملی این مهاجرت، علاوه بر کاهش هزینه ثابت زیرساخت، کاهش زمان از «تولید داده خام» تا «در دسترس بودن برای گزارش مدیریتی» بوده است.

تغییر نقش DBA از تنظیم Index به طراحی معماری داده

برای DBAیی که سال‌ها روی SQL Server تخصص ساخته، انتقال به این پلتفرم به‌معنای یادگیری چند مهارت جدید و کنار گذاشتن برخی عادت‌های قدیمی است. مهارت‌هایی مانند تنظیم دستی Index، مدیریت Maintenance Plan، یا تنظیم دقیق Tempdb، در این معماری یا وجود ندارند یا به‌شکل کاملاً متفاوتی مدیریت می‌شوند.

در عوض، مهارت‌هایی مثل طراحی الگوی توزیع داده مناسب برای کاهش Shuffle، درک عمیق از فرمت Delta Lake و نحوه مدیریت Versioning و Vacuum فایل‌های Parquet، و آشنایی با مدل امنیتی چندلایه OneLake و Purview اهمیت پیدا می‌کنند. DBAهایی که این انتقال را با موفقیت انجام داده‌اند، معمولاً به «معمار داده در یک پلتفرم مشترک بین چند تیم» تبدیل شده‌اند نقشی که هم‌پوشانی زیادی با مسئولیت‌های مهندسی داده پیدا می‌کند. این انتقال مهارتی معمولاً سه تا شش ماه زمان می‌برد و باید در برنامه‌ریزی زمانی هر پروژه مهاجرت لحاظ شود.

Best Practiceهای طراحی مدل داده

طراحی درست جدول در این معماری، تأثیر مستقیمی بر کارایی Polaris دارد. اولین اصل، انتخاب کلید Join بر اساس ستون‌هایی با Cardinality بالا و توزیع یکنواخت است کلید Joinی که بیشتر مقادیر آن یکسان باشد (مثلاً یک فلگ دودویی)، باعث تمرکز داده روی تعداد محدودی از گره‌ها و کاهش موازی‌سازی واقعی می‌شود.

دومین اصل، پایبندی به Star Schema به‌جای مدل کاملاً نرمال‌شده (Normalized) است جدول Fact مرکزی با جداول Dimension اطراف آن، الگویی است که بهینه‌ساز Polaris برای آن طراحی شده و از Joinهای زنجیره‌ای پرهزینه جلوگیری می‌کند. سومین اصل، Partitioning هوشمند بر پایه ستون‌هایی که در اکثر Queryها در شرط WHERE استفاده می‌شوند (معمولاً تاریخ)، برای بهره‌گیری کامل از Partition Elimination است.

همچنین بهتر است از Join روی ستون‌هایی با Cardinality بسیار پایین، مانند ستون‌های وضعیت (Active/Inactive)، پرچم‌های Yes/No یا مقادیر دودویی مشابه، تا حد امکان اجتناب شود. در چنین شرایطی احتمال توزیع نامتوازن داده بین گره‌های پردازشی افزایش می‌یابد و موتور ناچار به انجام Data Shuffle بیشتری خواهد بود که می‌تواند زمان اجرای Queryهای تحلیلی را افزایش دهد. انتخاب کلیدهای Join با توزیع یکنواخت‌تر، معمولاً بهره‌وری اجرای موازی در Polaris را بهبود می‌دهد.

نکته آخر، انتخاب نوع جدول متناسب با الگوی مصرف: جداول با حجم بسیار بالا و Query تحلیلی سنگین در Warehouse مناسب‌تر است، در حالی که داده نیمه‌ساختاریافته یا در حال تغییر مکرر با اسکیمای غیرثابت، معمولاً بهتر است ابتدا در Lakehouse مدیریت شود و در صورت نیاز، از طریق Shortcut یا View به Warehouse متصل شود، نه اینکه از ابتدا در Warehouse بارگذاری شود.

جمع‌بندی

Microsoft Fabric قرار نیست جای SQL Server را بگیرد بلکه قرار است جای معماری‌های چندتکه‌ای را بگیرد که سازمان‌ها سال‌ها برای ترکیب داده تراکنشی، انبار داده و Data Lake ساخته بودند. SQL Server همچنان بهترین گزینه برای بار کاری OLTP، تراکنش‌های پیچیده و سناریوهایی است که به Trigger، CLR یا Replication کلاسیک وابسته‌اند اما زمانی که سازمان به یک بستر تحلیلی یکپارچه، مقیاس‌پذیر و مبتنی بر OneLake نیاز دارد، Fabric Data Warehouse معماری مدرن‌تری ارائه می‌دهد که Direct Lake، Polaris و مدل هزینه Capacity Unit را در یک پلتفرم واحد کنار هم قرار می‌دهد.

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

پرسش‌های متداول FAQ

آیا Microsoft Fabric Data Warehouse می‌تواند جایگزین کامل SQL Server شود؟ خیر این پلتفرم برای بار کاری تحلیلی طراحی شده و برای OLTP، Trigger یا تراکنش‌های پرتکرار کوچک مناسب نیست.

آیا داده در Fabric Warehouse با فرمت SQL Server سازگار است؟ خیر داده در فرمت باز Delta Parquet روی OneLake ذخیره می‌شود، نه در فایل‌های MDF/LDF اختصاصی مایکروسافت.

آیا Index در Fabric Data Warehouse وجود دارد؟ به‌شکل دستی و قابل تنظیم توسط DBA خیر بهینه‌سازی ساختار فیزیکی داده توسط موتور Polaris به‌صورت خودکار انجام می‌شود.

آیا Direct Lake همیشه به‌معنای صفر Copy داده است؟ این ویژگی مشخصاً مسیر Power BI به OneLake را بدون کپی در حافظه مدل ممکن می‌کند سایر مسیرهای ورود داده همچنان به یک مرحله بارگذاری نیاز دارند.

آیا مهاجرت از Synapse Dedicated Pool ساده است؟ بستگی به میزان وابستگی به قابلیت‌های اختصاصی Synapse دارد توصیه عملی، ارزیابی سازگاری و اجرای یک Proof of Concept پیش از تصمیم نهایی است.

آیا Fabric Data Warehouse از Stored Procedure پشتیبانی می‌کند؟
Stored Procedure پشتیبانی می‌شود، اما همه قابلیت‌های T-SQL موجود در SQL Server (مانند Triggerها، برخی UDFها و تعدادی از الگوهای پیچیده برنامه‌نویسی) در دسترس نیستند.

هزینه Capacity Unit چگونه محاسبه می‌شود؟
بر اساس مصرف محاسباتی مشترک بین همه Workloadهای یک Fabric Capacity، نه بر اساس حجم داده ذخیره‌شده در OneLake.

آیا می‌توان هم‌زمان از Warehouse و Lakehouse در یک پروژه استفاده کرد؟
بله، و این الگو رایج است داده نیمه‌ساختاریافته در Lakehouse و داده تحلیلی ساختاریافته در Warehouse نگهداری می‌شود.

نقش Microsoft Purview در این معماری چیست؟
طبقه‌بندی داده حساس با Sensitivity Labels و رهگیری مسیر داده از منبع تا گزارش نهایی از طریق Data Lineage.

آیا برای شروع کار با Fabric Warehouse باید Synapse را کنار گذاشت؟
لزوماً نه بسیاری از سازمان‌ها یک دوره هم‌زیستی (Coexistence) را طی می‌کنند تا اطمینان کامل از سازگاری Workloadهای حساس حاصل شود.

آیا Microsoft Fabric Data Warehouse از Columnstore Index استفاده می‌کند؟
خیر. در Fabric Data Warehouse مفهومی مانند ایجاد یا مدیریت دستی Columnstore Index توسط کاربر وجود ندارد. موتور Polaris به‌صورت خودکار ساختارهای ذخیره‌سازی ستونی را مدیریت و بهینه می‌کند.

آیا Microsoft Fabric انتخاب درستی برای سازمان شماست؟

همه سازمان‌ها به Microsoft Fabric نیاز ندارند و همه پروژه‌ها هم نباید از SQL Server به Fabric مهاجرت کنند. انتخاب درست، به حجم داده، نوع بار کاری، هزینه، معماری فعلی و اهداف آینده کسب‌وکار بستگی دارد.

اگر در حال برنامه‌ریزی برای راه‌اندازی Data Warehouse، مهاجرت از SQL Server یا Azure Synapse، طراحی معماری داده، یا توسعه راهکارهای هوش تجاری (BI) هستید، توسعه فناوری اطلاعات لاندا می‌تواند با بررسی زیرساخت و نیازهای سازمان شما، مناسب‌ترین مسیر را پیشنهاد و اجرا کند.

همین امروز با کارشناسان لاندا تماس ✆ بگیرید و پیش از سرمایه‌گذاری، معماری مناسب سازمان خود را با اطمینان انتخاب کنید.