و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
چرا DirectQuery همیشه کند است؟
Power BI طی سالهای اخیر از یک ابزار مصورسازی ساده به پلتفرمی قدرتمند برای هوش تجاری سازمانی تبدیل شده است. اما وقتی صحبت از مدلهای DirectQuery میشود، حتی قدرتمندترین سرورهای SQL هم گاهی زیر بار Queryها خم میشوند.
DirectQuery، بر خلاف مدل Import، دادهها را درون Power BI ذخیره نمیکند. هر بار که کاربر با گزارش تعامل میکند (مثلاً فیلتر، اسلایس یا دریلداون)، Power BI مستقیماً به پایگاه داده اصلی درخواست میفرستد. نتیجه؟
اگر Query پیچیده، شبکه کند، یا مدل بهینه نباشد، گزارشها بهجای چند ثانیه، در چند دقیقه پاسخ میدهند.
در این مقاله جامع، قصد داریم از دید یک Data Engineer و DBA حرفهای بررسی کنیم که چطور میتوان DirectQuery را بهینه کرد تا هم از مزایای Real-Time بودن استفاده کنیم و هم سرعت را قربانی نکنیم.
DirectQuery چیست؟
DirectQuery مدلی است که Power BI در آن به جای ذخیرهسازی داده در حافظه داخلی، مستقیماً به منبع داده (مثل SQL Server ،Synapse ،Fabric Lakehouse یا Snowflake) متصل میشود.
هر بار که کاربر در گزارش تغییری ایجاد میکند:
- Power BI Query جدیدی تولید میکند.
- آن Query به منبع داده ارسال میشود.
- نتیجه برمیگردد و بصریسازی (Visualization) تازه میشود.
تفاوت با Import Mode
| ویژگی | Import | DirectQuery |
|---|---|---|
| سرعت پاسخ | بسیار بالا (In-memory) | وابسته به Database |
| حجم داده | محدود به RAM | تقریباً نامحدود |
| Real-time بودن | ❌ خیر | ✅ بله |
| فشار روی دیتابیس | پایین | بالا |
| بهینهسازی Query | در Power BI | در Database |
چالش اصلی DirectQuery
- تعداد زیاد Queryها: هر ویژوال (Visual) در Power BI حداقل یک Query اجرا میکند.
- تغییر مکرر Context: فیلترهای کاربران باعث اجرای Queryهای متنوع میشود.
- وابستگی به Performance دیتابیس: هر تأخیر در SQL Server مستقیماً در Power BI دیده میشود.
- Latency شبکه یا Gateway: مخصوصاً وقتی Gateway بین Power BI Service و دیتابیس On-Prem وجود دارد.
بنابراین بهینهسازی DirectQuery نیاز به رویکردی چند لایه دارد:
- بهینهسازی مدل Power BI
- بهینهسازی Query Folding
- بهینهسازی Gateway و شبکه
- بهینهسازی دیتابیس مبدا
Query Folding؛ قلب پنهان DirectQuery
تعریف ساده
Query Folding فرآیندی است که در آن Power BI تغییرات مدل (فیلتر، محاسبه، Join و …) را به زبان SQL ترجمه کرده و آن را به دیتابیس اصلی میفرستد. هر چه Query Folding بهتر انجام شود، عملکرد سریعتر است. اما اگر Folding “شکسته” شود (مثلاً با یک تابع سفارشی یا Join غیرقابلپشتیبانی)، Power BI مجبور میشود دادهها را بخواند و پردازش را در سمت خودش انجام دهد؛ فاجعهای برای عملکرد.
نحوه بررسی Folding
در Power Query Editor، روی مرحله مورد نظر راستکلیک کرده و گزینهی View Native Query را انتخاب کنید. اگر فعال نباشد، یعنی Folding در آن مرحله از بین رفته است.
نکته طلایی
بهتر است تحول داده (Transformations) در سطح SQL View انجام شود، نه در Power Query.
راهکارهای بهینهسازی در سمت Power BI
۱. محدودسازی ستونها و ردیفها
فقط دادههایی را بارگذاری کنید که در گزارش واقعاً نیاز دارید. هر ستون یا جدول اضافی باعث تولید Queryهای پیچیدهتر میشود.
۲. استفاده از Measures بهجای Calculated Columns
Calculated Column در مدل DirectQuery ممکن است برای هر سطر Query جدا بسازد. در مقابل، Measures در زمان Query ارزیابی میشوند و معمولاً در سطح SQL بهینهتر ترجمه میشوند.
۳. کاهش تعداد ویژوالها
هر Visual معادل یک Query است. بهجای ۲۰ نمودار در یک صفحه، از صفحههای تفکیکشده یا Drillthrough استفاده کنید.
۴. فعالسازی Aggregation Table
در Power BI میتوانید جداول تجمیعی (Aggregation) بسازید تا کوئریهای کلی از دیتابیس اجرا نشوند. مثلاً جدول SalesAgg شامل دادههای خلاصه ماهانه باشد و فقط در صورت نیاز جزئیات از جدول اصلی خوانده شود.
۵. استفاده از Composite Model (Import + DirectQuery)
در Power BI 2025، میتوانید بخشی از دادهها را Import کنید (مثلاً Lookups) و دادههای حجیمتر را DirectQuery نگه دارید. این رویکرد ترکیبی بهترین تعادل بین سرعت و تازگی دادههاست.
راهکارهای بهینهسازی در سمت دیتابیس
۱. طراحی Index مؤثر
برای Queryهای DirectQuery باید ایندکسهای خاص طراحی شوند، بهویژه روی ستونهای Join و فیلتر.
مثلاً:
CREATE INDEX IX_Sales_Date_Region ON Sales (OrderDate, Region);
۲. سادهسازی Viewها
Power BI معمولاً از Viewها برای خواندن داده استفاده میکند.
Viewهای تو در تو و پیچیده باعث کندی Folding میشوند.
۳. استفاده از Statistics بهروز
Outdated Statistics باعث انتخاب Plan اشتباه در SQL Server میشود.
برای بهروزرسانی منظم:
EXEC sp_updatestats;
۴. مانیتور Query Planها
در SQL Server 2025 میتوانید از Query Store برای تشخیص Planهای سنگین مربوط به Power BI استفاده کنید:
SELECT TOP 10 query_text_id, total_cpu_time, total_duration
FROM sys.query_store_runtime_stats;
۵. استفاده از Materialized Views یا Indexed Views
در SQL Server یا Synapse میتوانید Viewهای از پیش محاسبهشده بسازید تا Queryهای DirectQuery سریعتر پاسخ دهند.
بهینهسازی Gateway و شبکه
۱. محل Gateway
Gateway باید تا حد ممکن نزدیک به منبع داده باشد (از نظر شبکه). Latency بین Gateway و SQL Server باید کمتر از ۱۰ میلیثانیه باشد.
۲. Parallel Queries
در تنظیمات Dataset → Performance → Query Reduction، گزینه Parallel Queries را فعال کنید تا Power BI بتواند چند Query را همزمان اجرا کند.
۳. اندازه Timeout
در برخی محیطها باید Timeout را افزایش دهید تا Queryهای پیچیده در زمان مجاز اجرا شوند.
Power BI و SQL Server 2025: معماری پیشنهادی
در معماریهای جدید، ترکیب Fabric Lakehouse و SQL Server 2025 با DirectQuery Hybrid بهینهترین عملکرد را ارائه میدهد:
- دادههای حجیم در Fabric (با Cache Aggregation)
- دادههای تحلیلی در SQL Server با ایندکس Columnstore
- مدل Power BI با Query Folding فعال
این ترکیب باعث میشود که حتی مدلهای Real-Time هم در کمتر از ۲ ثانیه پاسخ بدهند.
مانیتورینگ عملکرد DirectQuery
استفاده از Power BI Performance Analyzer
در View → Performance Analyzer، میتوانید ببینید هر ویژوال چقدر زمان صرف Query و Render کرده است.
در سمت SQL Server
با اجرای Query زیر میتوان Queryهای اخیر Power BI را شناسایی کرد:
SELECT TOP 20 last_execution_time, total_elapsed_time, text
FROM sys.dm_exec_query_stats
CROSS APPLY sys.dm_exec_sql_text(sql_handle)
WHERE text LIKE '%$Table%';
تکنیکهای پیشرفته
۱. Partitioning هوشمند
در SQL Server، جداول Fact را بر اساس تاریخ پارتیشنبندی کنید تا فقط دادههای مربوط به محدودهی زمانی گزارش خوانده شود.
۲. Parameterized Views
از پارامترها در View برای کاهش حجم دادههای بازگشتی استفاده کنید.
۳. Server-Side Row-Level Security
اگر RLS را در Power BI اعمال کنید، ممکن است هر Query برای هر کاربر جداگانه اجرا شود.
با پیادهسازی RLS در سمت SQL (View فیلترشده با SUSER_NAME)، میتوان بار پردازش را کاهش داد.
مثال عملی: بهینهسازی گزارش فروش روزانه
قبل از بهینهسازی:
- Query Folding در میانه مسیر شکسته بود.
- هر Refresh حدود ۲۵ ثانیه طول میکشید.
بعد از تغییرات:
- تمام Transformations به View منتقل شد.
- ایندکس روی ستون Date ایجاد شد.
- از Aggregation Table ماهانه استفاده شد.
نتیجه:
⏱ زمان پاسخ کاهش یافت از ۲۵ ثانیه به ۴ ثانیه
📈 مصرف CPU سرور ۴۰٪ کاهش یافت
مزایا و معایب DirectQuery
| مزایا | معایب |
|---|---|
| داده همیشه تازه (Real-Time) | وابستگی کامل به Performance دیتابیس |
| بدون محدودیت حجم داده | Query Folding ممکن است بشکند |
| امنیت در سطح منبع داده | نیاز به Gateway پایدار |
| ادغام با RLS در SQL | سرعت پایینتر نسبت به Import |
نتیجهگیری
در Power BI 2025، DirectQuery به لطف پیشرفت در Query Folding، Aggregation و Fabric Integration بسیار کارآمدتر از قبل شده است.
اما اصل طلایی همچنان برقرار است:
“سرعت DirectQuery به اندازه کندترین Query در منبع داده است.”
برای بهترین عملکرد:
- مدل را ساده نگه دارید
- Transformations را به SQL منتقل کنید
- از Aggregations و Hybrid Mode استفاده کنید
- دیتابیس را ایندکس و مانیتور کنید
اگر بهینهسازی درست انجام شود، DirectQuery میتواند تقریباً به سرعت Import Mode عمل کند، با مزیت همیشگی Real-Time Data.
سوالات متداول (FAQ)
۱. آیا DirectQuery همیشه کندتر از Import است؟
بله، اما با بهینهسازی مناسب میتوان اختلاف را به حداقل رساند.
۲. آیا میتوان DirectQuery را با Import ترکیب کرد؟
بله، با Composite Model میتوان دادههای حجیم را DirectQuery و Lookups را Import کرد.
۳. چگونه بفهمم Folding فعال است؟
در Power Query → View Native Query را بررسی کنید.
۴. آیا Cache در DirectQuery مفید است؟
بله، Power BI برای نتایج تکراری Cache داخلی دارد که باعث افزایش سرعت میشود.
خدمات BI Performance و مانیتورینگ از لاندا
تیم لاندا با تجربه در SQL Server، Fabric، و Power BI Performance Tuning به شما کمک میکند تا:
- DirectQuery خود را بهینه کنید.
- زمان پاسخ گزارشها را تا ۸۰٪ کاهش دهید.
- مدلهای Hybrid و Aggregation را پیادهسازی کنید.
برای ارزیابی رایگان عملکرد داشبوردهای Power BI خود، با مشاوران لاندا تماس ✆ بگیرید.
نظری داده نشده