مقایسه حالت های ذخیره سازی Direct Lake و Import و ترکیبی در (Semantic Models) Microsoft Fabric
مرجع سریع – خلاصه‌ای از انواع Storage Mode
| حالت (Mode) | داده‌ها کجا ذخیره می‌شوند؟ | هزینه به‌روزرسانی (Refresh) | محدودیت‌های ویژگی‌ها | کاربرد رایج |
|---|---|---|---|---|
| Import | در Vertipaq داخل مدل معنایی (Semantic Model) | کپی کامل (یا افزایشی) داده و فشرده‌سازی | بدون محدودیت | مدل‌های کوچک تا متوسط؛ ابعاد با انعطاف بالا |
| Direct Lake | جداول Parquet/Delta در Fabric Lakehouse یا Warehouse | فقط بازنگری متادیتا (metadata reframing)؛ تبدیل داده حین کوئری | بدون Power Query؛ بدون ستون‌ها یا جداول محاسباتی (calc columns/tables) (فعلاً)؛ محدودیت در سلسله‌مراتب Excel | جدول‌های واقعیتی بسیار بزرگ که به‌ندرت نیاز به تغییر ساختار دارند |
| Direct Lake + Import | ترکیبی (برای هر جدول به‌صورت جداگانه) | جداول Import به‌روزرسانی می‌شوند؛ جداول Direct Lake فقط بازنگری می‌شوند | امکانات Import قابل استفاده هستند؛ محدودیت‌های Direct Lake همچنان باقی‌اند | سناریوهای ترکیبی—واقعیت‌های بزرگ، ابعاد قابل تغییر |
حالت Import (پایه‌ای‌ترین روش)
معماری در ۶۰ ثانیه:
در این حالت، داده‌ها از منبع کپی می‌شوند → تبدیل (transform) می‌شوند → سپس در قالب Vertipaq فشرده می‌شوند. قالب ستونی Vertipaq بالاترین نرخ فشرده‌سازی و سرعت کوئری را ارائه می‌دهد، و زمانی که امکان به‌روزرسانی کامل (full refresh) داشته باشید، تقریباً نیازی به نگهداری خاصی ندارد.
مزایا:
بهترین عملکرد خام در اجرای کوئری‌ها (چون در زمان اجرا نیاز به تبدیل فرمت وجود ندارد).
تمام ویژگی‌های مدل‌سازی در دسترس هستند — شامل Power Query، ستون‌ها/جداول محاسباتی، سلسله‌مراتب‌های کاربر، Drill-through و غیره.
مدل ذهنی ساده: «فقط کار می‌کند.»
معایب:
زمان به‌روزرسانی با حجم داده‌ها مقیاس می‌گیرد؛ به‌روزرسانی کامل برای جداول بالای ۱۰۰ میلیون ردیف می‌تواند بسیار زمان‌بر و دشوار باشد.
نیاز به ذخیره‌سازی مضاعف (هم در منبع و هم در نسخه فشرده‌شده Vertipaq).
توسعه‌دهندگان ممکن است به ستون‌های محاسباتی (calculated columns) وابسته شوند، در حالی که یک راه‌حل مبتنی بر مهندسی داده می‌تواند تمیزتر و بهتر باشد.
Import همچنان استاندارد طلایی باقی می‌ماند — تا زمانی که محدودیت‌های زمانی به‌روزرسانی یا هزینه ذخیره‌سازی مضاعف تبدیل به چالش شوند.
Direct Lake – واقعاً چه چیزی تغییر می‌کند؟
در حالت Direct Lake، مرحله‌ی کپی داده‌ها در قالب Vertipaq حذف می‌شود و داده‌ها به‌صورت فشرده‌شده در قالب‌های Parquet یا Delta باقی می‌مانند. زمانی که یک کوئری اجرا می‌شود، داده‌ها در لحظه به فرمت Vertipaq تبدیل (transcode) می‌شوند.
هزینه‌ها جابه‌جا می‌شوند:
Pipeline مهندسی داده باید خروجی Parquet با فشرده‌سازی مناسب تولید کند (شامل clustering خوب، عدم وجود فایل‌های خیلی کوچک و موارد مشابه).
تأخیر در کوئری شامل زمان transcoding زمانی است که برای اولین بار یک ستون خوانده می‌شود.
محدودیت‌هایی که باید به آن توجه کرد (نسخه پیش‌نمایش مه ۲۰۲۵):
عدم پشتیبانی از Power Query transforms
عدم پشتیبانی از calculated columns/tables (طبق roadmap ابتدا calc tables اضافه خواهند شد)
در Excel: عدم پشتیبانی از user-defined hierarchies؛ قابلیت drill through غیرفعال است.
جمع‌بندی:
برای جدول‌های fact بسیار بزرگ که به دفعات زیاد به‌روزرسانی می‌شوند، این مصالحه‌ها می‌توانند ارزشمند باشند؛ اما برای ابعاد (dimensions) که ساختارشان مرتب تغییر می‌کند، چندان مناسب نیستند.
| نوع | روش اتصال (Connect Option) | حالت جایگزین در صورت کمبود حافظه | مسیر امنیتی (Security Path) | وضعیت |
|---|---|---|---|---|
| Direct Lake on OneLake | اتصال مستقیم به OneLake | هیچ‌کدام (خطا صادر می‌شود) | امنیت مبتنی بر OneLake (آماده برای آینده) | در حال تبدیل شدن به گزینه پیش‌فرض |
| Direct Lake via SQL Endpoint | اتصال از طریق SQL Endpoint | به حالت DirectQuery (SQL) بازمی‌گردد | امنیت مبتنی بر SQL | قدیمی (Legacy)؛ نگه داشته شده برای موارد خاص و غیرمعمول |
چرا مدل‌های ترکیبی (Composite) کلاسیک دچار مشکل می‌شوند؟
الگوی قدیمی ترکیبی از Import + Direct Lake، در واقع دو Semantic Model جدا را به هم متصل می‌کرد. زمانی که روابط (Relationships) بین این دو مدل برقرار می‌شوند:
فهرست‌های فیلتر اضافی در برنامه کوئری (query plan) حمل می‌شود.
Blank-row propagation دچار اختلال می‌شود.
وقتی کلید ارتباطی (Crossing key) Cardinality متوسط یا بالا داشته باشد، عملکرد به شدت کاهش می‌یابد.
برای ابعاد کوچک (دموگونه) مناسب است، اما برای ابعاد واقعی و بزرگ ناپایدار و شکننده خواهد بود.
Direct Lake + Import – نحوه عملکرد
مدل ترکیبی جدید به شما اجازه می‌دهد که برای هر جدول به صورت جداگانه مشخص کنید که حالت Import باشد یا Direct Lake، و همه این جداول داخل یک مدل معنایی (Semantic Model) واحد قرار دارند. درونی، Vertipaq همه جداول را به‌عنوان یک “قاره” واحد در نظر می‌گیرد، بنابراین روابط (Relationships) طبیعی و سریع برقرار می‌شوند.
نمای کلی روند کار (Workflow snapshot)
یک مدل Direct Lake با نوع OneLake بسازید.
جداول Import را وارد یا ایجاد کنید (از طریق Tabular Editor 2/3 یا به‌زودی مستقیماً در محصول).
اعتبارنامه‌ها (credentials) را تنظیم کنید تا سرویس بتواند جداول Import را به‌روزرسانی کند.
روابط معمول را بسازید؛ یک بار مدل را به‌روزرسانی (refresh) کنید.
model boundary tax از بین می‌رود؛ جدول‌های بزرگ واقعیت (fact) در Direct Lake هستند و ابعاد (dimensions) سریع و قابل تغییر در Import قرار می‌گیرند.
مواردی که هنوز در مرحله پیش‌نمایش (preview) هستند:
پشتیبانی رابط کاربری (GUI) هنوز کامل نیست؛ فعلاً استفاده از Tabular Editor آسان‌ترین راه است.
اولین به‌روزرسانی (refresh) گاهی تا زمان پراکندگی اعتبارنامه‌ها (credential propagation) متوقف می‌شود — یک دقیقه صبر کنید و دوباره امتحان کنید.
خلاصه مرحله به مرحله
داده‌ها و نام‌ها را بر اساس محیط خودتان تنظیم کنید.
ایجاد مدل Direct Lake پایه (stub)
اتصال به OneLake → فقط جدول Sales را انتخاب کنید → انتشار (Publish).
افزودن معیارهای اصلی (Measures) که فقط به جدول Sales ارجاع دارند.
وارد کردن ابعاد Import
مدل فقط Import که از طریق SQL endpoint ساخته شده را باز کنید.
جداول Product، Customer، Date و Store را با استفاده از Tabular Editor در مدل Direct Lake کپی کنید.
تغییرات را ذخیره کنید.
تنظیم اعتبارنامه‌ها (Credential mapping)
در سرویس، یک اتصال جدید به نام (“Contoso–DL”) با استفاده از اعتبارنامه‌های OAuth ایجاد کنید.
SQL endpoint را به این اتصال نگاشت (Map) کنید.
تا زمانی که اعتبارنامه‌ها منتقل شوند، منتظر بمانید.
اولین به‌روزرسانی کامل (Full refresh)
داده‌های ابعاد Import بارگذاری می‌شوند، بدون اینکه منتظر جدول Sales باشید.
ایجاد روابط معمول بین جدول Sales و کلیدهای ابعاد
ذخیره تغییرات و انجام به‌روزرسانی سریع متادیتا (Metadata refresh).
آزمون کوئری
یک ماتریس DAX ساخته شده که از ستون محاسباتی Product[Price Range] و همچنین مجموع مقدار فروش (Sales Amount) استفاده می‌کند.
زمان‌بندی‌های سرور نشان می‌دهد که فقط یک کوئری از Storage Engine اجرا شده — یعنی هیچ مرز مدل (model boundary) شکسته نشده است.
کی کدام حالت را انتخاب کنیم؟
| سناریو (Scenario) | حالت پیشنهادی (Recommended mode(s)) | دلیل (Rationale) |
|---|---|---|
| ابعاد نیاز به ستون‌های محاسباتی موقت (ad hoc) یا شکل‌دهی با Power Query دارد | Import | انعطاف‌پذیری مهم‌تر از صرفه‌جویی اندک در فضای ذخیره‌سازی است. |
| فقط جدول‌های بزرگ با بیش از ۵۰ میلیون ردیف و تغییرات مکرر (بیش از یک بار در ساعت) | Direct Lake | از واردکردن مجدد عظیم داده‌ها جلوگیری می‌کند؛ هزینه تبدیل (transcoding) کم است. |
| ترکیبی: جدول‌های بزرگ fact و ابعاد قابل شکل‌دهی | Direct Lake + Import | بهترین ترکیب هر دو حالت، با عملکرد یک مدل واحد. |
| تیم BI مهارت کافی در Tabular Editor ندارد و کندی به‌روزرسانی را تحمل می‌کند | Import | ساده‌تر تا زمانی که رابط کاربری (GUI) بهبود یابد. |
| نیاز به امنیت دقیق در سطح SQL و fallback | Direct Lake via SQL endpoint | موارد خاص؛ پذیرفتن پیچیدگی بیشتر. |
جدول‌ها/ستون‌های محاسباتی در Direct Lake – جدول‌های محاسباتی به زودی در roadmap قرار دارند؛ ستون‌های محاسباتی بعداً اضافه می‌شوند.
نمایه‌های ماده‌ای (Materialised views) – وعده داده شده برای اصلاحات کوچک ابعاد بدون نیاز به Import؛ هنوز در مراحل اولیه است.
پشتیبانی GUI – انتظار می‌رود ابتدا بهبودها برای OneLake در دسکتاپ و ویرایشگر وب بیاید.
کیفیت فشرده‌سازی – به اندازه فایل‌ها و clustering در Lakehouse توجه کنید؛ Vertipaq در زمان کوئری نمی‌تواند مشکل فشرده‌سازی را جبران کند.
نکات کلیدی مهم
حالت Import هنوز زنده و مرجع اصلی برای عملکرد و انعطاف‌پذیری است.
Direct Lake بار به‌روزرسانی جداول بزرگ را حذف می‌کند اما بار مسئولیت را به مهندسی داده منتقل می‌کند.
مدل‌های ترکیبی کلاسیک برای دموهای ساده Direct Lake و Import خوب است اما برای داده‌های واقعی و بزرگ کند و ناپایدار است.
حالت پیش‌نمایش Direct Lake + Import بالاخره اجازه می‌دهد مدل را به شکل منطقی تقسیم کنیم: جداول بزرگ fact در Direct Lake می‌مانند و ابعاد Import می‌شوند تا آماده تغییر باشند.
در حال حاضر راه‌اندازی نیازمند Tabular Editor و صبر است؛ اما تا نسخه عمومی (GA) ابزارها به شکل بهتری یکپارچه خواهند شد.
دیدگاهتان را بنویسید