Direct Lake در مقابل Import Mode در Power BI
انتخاب صحیح بین Direct Lake و Import Mode در Power BI چیست؟
کوئری‌ها در Import Mode سریع‌تر از Direct Lake اجرا می‌شوند: فقط در بهترین سناریوهای ممکن، عملکرد کوئری در Direct Lake مشابه Import است، به این معنا که معمولاً Direct Lake کندتر است، هرچند این اختلاف ممکن است ناچیز باشد.
Direct Lake جایگزینی برای Import Mode نیست: Fabric، Direct Lake را به عنوان یک گزینه‌ی اضافی ارائه می‌دهد، اما حالت‌های Import و DirectQuery همچنان در دسترس هستند.
Direct Lake جایگزینی برای DirectQuery Mode هم نیست: Direct Lake برای سناریوهای نزدیک به زمان واقعی (near-real-time) مناسب است که مشابه Import Mode هستند، اما نمی‌تواند مانند DirectQuery، سناریوهای زمان واقعی (real-time) را مدیریت کند.
Direct Lake ترکیبی از بهترین‌های Import و DirectQuery نیست: Direct Lake منحصر به فرد و متفاوت از Import و DirectQuery است؛ برای سناریوهای خاص مناسب است، سریع‌تر از Import نیست و جایگزین DirectQuery هم نمی‌شود.
Import و Direct Lake در زمان اجرای کوئری به میزان یکسانی حافظه مصرف می‌کنند: زمانی که از فرمت بزرگ (large format) برای مدل Import استفاده می‌شود، فقط ستون‌های مورد استفاده در کوئری‌ها به حافظه بارگذاری می‌شوند. این ویژگی در Direct Lake هم وجود دارد، اما منحصراً مختص Direct Lake نیست.
Direct Lake در مقایسه با Import محدودیت‌هایی در مدل‌سازی دارد: نمی‌توانید از ستون‌های محاسبه شده (calculated columns)، جداول محاسبه شده (calculated tables) و سلسله مراتب‌های کاربری MDX در Direct Lake استفاده کنید. مورد آخر بر تجربه کاربری Excel هنگام استفاده از مدل‌های semantic منتشر شده در Power BI تأثیر می‌گذارد.
Direct Lake برای مدل semantic نیاز به جداول فیزیکی دارد: در صورت استفاده از view، موتور از DirectQuery استفاده می‌کند و سطح عملکرد نزدیک به Import از بین می‌رود. ایجاد ساختاری که ۱۰۰٪ با مدل‌های semantic تطابق داشته باشد اغلب نیازمند ایجاد یک نسخه اضافی از داده‌هاست.
مدل‌های Direct Lake برای دستیابی به فشرده‌سازی بهینه به مهارت‌های فنی بیشتری نیاز دارند: در حالت Import، فشرده‌سازی توسط VertiPaq مدیریت می‌شود، در حالی که در Direct Lake به نحوه بارگذاری داده‌ها در فرمت Delta بستگی دارد.
کوئری‌ها در Import Mode سریع‌تر از Direct Lake اجرا می‌شوند
هنگامی که از Direct Lake استفاده می‌کنید، ستون‌های موجود در قالب Delta با استفاده از همان موتور VertiPaq که در Import Mode استفاده می‌شود، به حافظه بارگذاری می‌شوند. زمانی که داده هنوز در حافظه قرار نگرفته، اولین باری که یک کوئری اجرا می‌شود، داده باید به فرمت VertiPaq تبدیل شود. در Import Mode، داده‌ی دودویی (binary) مستقیماً در حافظه بارگذاری می‌شود، در حالی که در Direct Lake پردازش اضافه‌ای برای تطبیق داده‌ها با فرمت VertiPaq لازم است. بنابراین، بارگذاری اولیه نمی‌تواند سریع‌تر باشد و کوئری‌های بعدی نیز نمی‌توانند سریع‌تر باشند، چرا که فرمت داده‌ها یکسان است. علاوه بر این، عملکرد کوئری‌ها پس از بارگذاری داده در حافظه به شدت به سطح فشرده‌سازی فایل‌های Parquet مورد استفاده در فرمت Delta بستگی دارد، که در ادامه توضیح داده خواهد شد.
Direct Lake جایگزینی برای Import Mode نیست
جدید بودن Direct Lake به این معنا نیست که برای تمام موارد استفاده بهتر است. در واقع، این یک گزینه‌ی اضافی برای سناریوهایی است که در آن‌ها یک Lakehouse قبلاً شامل جداولی است که می‌توانند بدون تبدیل‌های اضافی مستقیماً در حافظه بارگذاری شوند.
Direct Lake جایگزینی برای DirectQuery Mode هم نیست
در Direct Lake، تغییرات نیازمند یک به‌روزرسانی سریع اما ضروری در مدل Semantic هستند که کش (cache) را پاک کرده و داده‌ها را دوباره از Lakehouse به حافظه بارگذاری می‌کند. این به‌روزرسانی می‌تواند به صورت خودکار یا دستی انجام شود. در DirectQuery، این کار هرگز لازم نیست و هیچ تأخیری برای سناریوهای real-time وجود ندارد (البته به قیمت کاهش عملکرد کوئری). Direct Lake برای سناریوهای near-real-time مشابه Import Mode مناسب است و گزینه‌های متفاوتی برای کنترل بهتر به‌روزرسانی‌های Lakehouse ارائه می‌دهد.
Direct Lake ترکیبی از بهترین ویژگی‌های Import و DirectQuery نیست
Direct Lake نه Import است و نه DirectQuery. Direct Lake در مدیریت سناریوهایی که حجم داده در حافظه جا نمی‌شود اما تنها بخشی از ستون‌ها کوئری می‌شوند (و در نتیجه احتمال بازگشت به DirectQuery کم است) بهتر از DirectQuery عمل می‌کند. در واقع، زمانی که داده‌ها می‌توانند در حافظه بارگذاری شوند، Direct Lake از سیستمی مشابه (اما کندتر از) Import استفاده می‌کند و در صورت نبود حافظه کافی یا ناسازگاری مدل semantic با Direct Lake (مثلاً زمانی که داده‌ها از یک View بارگذاری می‌شوند)، به DirectQuery بازمی‌گردد.
مصرف حافظه Direct Lake و Import یکسان است
قابلیت بارگذاری ستونی بر اساس نیاز در یک مدل semantic از دسامبر ۲۰۲۱ معرفی شده و مختص Direct Lake نیست؛ این ویژگی به طور پیش‌فرض برای تمام مدل‌های semantic بزرگ در دسترس است.
انتقال به Direct Lake به خاطر این ویژگی معمولاً منطقی نیست؛ زیرا Direct Lake و Import از این نظر تقریباً یکسان‌اند! تفاوت اصلی اینجاست که اگر حافظه کافی برای بارگذاری ستون‌ها وجود نداشته باشد، Direct Lake به DirectQuery سوئیچ می‌کند (که تفاوت عملکرد چشمگیری دارد)، در حالی که در Import، کاربر با خطای کمبود حافظه مواجه می‌شود. این تفاوت در مدل‌های بسیار بزرگ (مثلاً بالای ۲۰۰ تا ۴۰۰ گیگابایت) اهمیت دارد، ولی برای مدل‌های کوچک‌تر از ۱۰ تا ۲۰ گیگابایت تقریباً بی‌اهمیت است و برای مقادیر میانی بستگی به شرایط دارد.
Direct Lake نسبت به Import محدودیت‌های مدل‌سازی دارد
نبود ستون‌های محاسباتی (Calculated Columns) و جداول محاسباتی (Calculated Tables) در Direct Lake، توانایی حل برخی مسائل مدل‌سازی درون مدل semantic را کاهش می‌دهد. این محدودیت ممکن است نیاز به تغییر در فرآیند آماده‌سازی داده را ایجاد کند.
به عنوان مثال، نداشتن موتور VertiPaq برای ساخت جداول محاسباتی تجمیعی (مثل اسنپ‌شات‌های تجمیعی مورد نیاز برای مجموع‌های غیر-ویژوال در RLS) می‌تواند زمان کلی پردازش مدل semantic را افزایش دهد. محاسبه این جداول در Lakehouse ممکن است کندتر از VertiPaq باشد.
در حال حاضر، جداول محاسباتی که به جداول موجود در Lakehouse ارجاع نمی‌دهند، پشتیبانی می‌شوند (مثل جداول پارامتری)، ولی این محدودیت همچنان برای بسیاری از موارد استفاده (مثلاً جداول تاریخ داینامیک یا جداول اسنپ‌شات) مشکل‌ساز است.
علاوه بر این، مدل‌های Direct Lake ایجاد شده در Fabric به طور پیش‌فرض حساس به بزرگی و کوچکی حروف (Case-Sensitive) هستند. بنابراین، انتقال یک مدل Import یا DirectQuery به Direct Lake می‌تواند نتایج متفاوتی با وجود داده‌ها و DAX یکسان ایجاد کند. برای تنظیم درست collation باید از ابزارهایی مثل Tabular Editor، TMSL یا ویرایش دستی فایل BIM استفاده کرد.
در حال حاضر Direct Lake از حالت‌های ذخیره‌سازی ترکیبی پشتیبانی نمی‌کند (گرچه این محدودیت احتمالاً موقتی است) و تمام جداول باید در یک Lakehouse یا Warehouse باشند و همه آن‌ها باید Direct Lake Storage Mode داشته باشند.
Direct Lake نیاز به جداول فیزیکی در مدل semantic دارد
برای استفاده از موتور VertiPaq در Direct Lake، باید به یک جدول فیزیکی در Lakehouse متصل شوید. اگر نیاز به کوچک‌ترین تغییری در جدول وجود داشته باشد، استفاده از View باعث می‌شود موتور مجبور شود داده‌ها را به صورت SQL و با DirectQuery کوئری کند. در Direct Lake، هیچ Viewی به حافظه بارگذاری نمی‌شود.
به عنوان مثال، اگر ستونی با نام گروه نیاز به ترتیب خاصی غیر از ترتیب حروف الفبا (مثل Small، Medium، Large) داشته باشد، می‌توان با یک ستون عددی اضافه این کار را انجام داد. استفاده از View برای این منظور در Import Mode معمول است، اما در Direct Lake امکان‌پذیر نیست زیرا باعث سوئیچ به DirectQuery می‌شود و مزایای عملکردی Direct Lake از بین می‌رود. بنابراین، ستون‌های اضافی باید مستقیماً به جدول Delta افزوده شوند یا در صورت نیاز، یک نسخه‌ی کپی از جدول ساخته شود.
هدف از استفاده از Direct Lake معمولاً حفظ یک نسخه‌ی واحد از داده‌هاست. اما اگر مجبور به ایجاد نسخه‌ی دیگری از داده‌ها شوید، این کار منجر به افزایش هزینه‌های توسعه می‌شود. با این حال، اگر این جداول در ابزارهای گزارش‌گیری دیگری هم استفاده شوند، این کار توجیه بیشتری خواهد داشت. در غیر این صورت، تفاوت چندانی با ایجاد نسخه‌ی فشرده در Import Mode ندارد.
مدل‌های Direct Lake برای رسیدن به فشرده‌سازی بهینه، مهارت فنی بیشتری نیاز دارند
فشرده‌سازی‌ای که VertiPaq در حالت Import به طور پیش‌فرض ارائه می‌دهد، به سختی می‌تواند با بهینه‌سازی بیشتر (مثل تنظیم پارتیشن‌بندی و توزیع داده) بهتر شود.
اما برای دستیابی به نتایجی مشابه با Direct Lake، توسعه‌دهنده باید:
فرمت داخلی Parquet را به خوبی بشناسد
الگوریتم‌های فشرده‌سازی مناسب را انتخاب کند
یک استراتژی دقیق برای پارتیشن‌بندی و نحوه ذخیره فایل‌ها در Lakehouse داشته باشد
این یعنی نیاز به مهارت‌های فنی بیشتر و زمان اضافه‌تر وجود دارد. افزایش هزینه برای رسیدن به همان عملکرد، معمولاً بازگشت سرمایه (ROI) مناسبی ندارد، مگر اینکه دلایل خیلی قوی دیگری وجود داشته باشد.
نتیجه‌گیری
ما از Direct Lake هیجان‌زده‌ایم، چون مشکلات ۲ تا ۳ درصد از مدل‌هایی که در Import سخت مدیریت می‌شدند (مدل‌های بالای ۲۰۰/۴۰۰ گیگابایت) را حل می‌کند.
اما اگر مدل شما در Import به خوبی کار می‌کند، دلیلی برای استفاده از Direct Lake وجود ندارد. اگر هم ترجیح می‌دهید داده‌ها را در Lakehouse نگه دارید، می‌توانید همچنان از Import Mode استفاده کنید.
دیدگاهتان را بنویسید