Performance Optimization؛ سریع‌تر کردن مدل، DAX و گزارش Power BI

کتاب جامع Power BI — آموزش پروژه‌محور، تصویری و کاربردی

مقدمه؛ داشبورد حرفه‌ای نباید کاربر را منتظر بگذارد

ممکن است گزارش از نظر ظاهری عالی باشد، ولی هر بار که مدیر روی Slicer کلیک می‌کند چند ثانیه منتظر بماند. اینجا تجربه کاربری خراب می‌شود و اعتماد به داشبورد پایین می‌آید.

بهینه‌سازی Power BI فقط «سریع کردن DAX» نیست. منبع داده، Power Query، مدل، Cardinality، نوع اتصال، Measureها و تعداد Visualهای صفحه همگی می‌توانند روی سرعت اثر بگذارند.

۱۱.۱. Performance یک مسئله End-to-End است

شکل ۱۱-۱ — زنجیره‌ای که می‌تواند روی Performance اثر بگذارد

اگر Query منبع کند باشد، بهترین DAX دنیا هم مشکل را کامل حل نمی‌کند. اگر مدل حجیم و نامناسب باشد، Visual ساده هم ممکن است کند شود. اول باید Bottleneck را پیدا کنیم.

۱۱.۲. قبل از Optimization اندازه‌گیری کن

بهینه‌سازی بدون اندازه‌گیری یعنی حدس زدن. ابتدا مشخص کن کدام صفحه، Visual یا Query کند است و زمان تقریبی آن چقدر است.

نکته: اول Measure، بعد Optimize؛ چیزی را که اندازه نگرفته‌ای بهینه نکن.

۱۱.۳. Performance Analyzer

Performance Analyzer در Power BI Desktop کمک می‌کند زمان اجرای Visualها را بررسی کنیم و بفهمیم کدام بخش‌ها بیشتر زمان می‌گیرند.

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

۱۱.۴. تعداد Visualها مهم است

هر Visual می‌تواند Query و Rendering خودش را داشته باشد. صفحه‌ای با تعداد زیاد Card، Chart و Matrix ممکن است فشار غیرضروری ایجاد کند.

اگر Visual فقط برای پر کردن فضای خالی است، حذفش کن. طراحی مینیمال فصل هشتم به Performance هم کمک می‌کند.

۱۱.۵. مدل داده مهم‌تر از فرمول جادویی

شکل ۱۱-۲ — مدل تحلیلی منظم در برابر جدول عریض و تکراری

Star Schema معمولاً علاوه بر خوانایی، پایه بهتری برای مدل تحلیلی فراهم می‌کند. تکرار متن‌های طولانی در Fact و نگه داشتن ستون‌های غیرضروری می‌تواند مدل را سنگین کند.

۱۱.۶. ستون‌های غیرضروری را حذف کن

هر ستونی که وارد مدل می‌شود هزینه دارد. اگر یک ستون برای Relationship، Filter، Visual یا محاسبه لازم نیست، بررسی کن آیا واقعاً باید Load شود.

Source has 80 columns
Report needs 24 columns
→ Do not automatically load all 80

۱۱.۷. Cardinality چیست؟

Cardinality به تعداد مقادیر یکتای یک ستون مربوط است. ستون‌هایی مثل TransactionID، GUID یا متن‌های بسیار متنوع می‌توانند Cardinality بالایی داشته باشند.

قبل از وارد کردن چنین ستون‌هایی به مدل بپرس آیا واقعاً در گزارش لازم هستند.

۱۱.۸. Data Type درست

نوع داده را درست انتخاب کن. ستون عددی را بی‌دلیل Text نکن و ستون Date را به شکل رشته‌ای وارد مدل نکن.

نوع داده صحیح هم برای منطق مدل و هم برای مصرف حافظه و فشرده‌سازی اهمیت دارد.

۱۱.۹. Fact را از متن‌های تکراری سبک کن

در مدل ستاره‌ای، Fact بهتر است بیشتر کلیدها و مقادیر عددی را نگه دارد و توضیحات متنی در Dimension مناسب باشند.

FactSales: ProductKey = 125
DimProduct: ProductKey=125, ProductName='...'

۱۱.۱۰. Calculated Column یا Measure؟

Calculated Column در مدل ذخیره می‌شود، ولی Measure هنگام Query ارزیابی می‌شود. برای KPIهای پویا معمولاً Measure انتخاب طبیعی‌تری است.

این به معنی ممنوع بودن Calculated Column نیست؛ مسئله این است که برای هر محاسبه‌ای بی‌دلیل ستون نسازیم.

۱۱.۱۱. Measureهای پایه بساز

Total Sales = SUM(FactSales[SalesAmount])
Total Cost  = SUM(FactSales[CostAmount])
Profit      = [Total Sales] - [Total Cost]

ساخت Measureهای پایه و استفاده مجدد از آن‌ها، خوانایی و نگهداری را بهتر می‌کند و عیب‌یابی را ساده‌تر می‌سازد.

۱۱.۱۲. FILTER را بی‌دلیل روی Fact بزرگ اجرا نکن

FILTER بسیار مفید است، اما اگر برای یک شرط ساده روی جدول Fact بسیار بزرگ استفاده شود، ممکن است هزینه محاسباتی بیشتری ایجاد کند.

Simple filter when possible:
CALCULATE([Total Sales], DimBranch[BranchKey] = 10)

هدف حفظ منطق درست و ساده است؛ قبل از بازنویسی فرمول، نتیجه و Performance را اندازه بگیر.

۱۱.۱۳. Iteratorها را آگاهانه استفاده کن

توابعی مثل SUMX برای محاسبات ردیفی لازم‌اند، ولی وقتی یک SUM ساده همان نتیجه را می‌دهد، Iterator اضافه لازم نیست.

SUM(FactSales[SalesAmount])
vs
SUMX(FactSales, FactSales[SalesAmount])

سادگی معمولاً نقطه شروع خوبی است.

۱۱.۱۴. VAR فقط برای زیبایی نیست

Variableها Expression را خواناتر می‌کنند و جلوی تکرار منطق در همان Measure را می‌گیرند.

Growth % =
VAR CurrentValue = [Total Sales]
VAR PreviousValue = [Sales Previous Year]
RETURN DIVIDE(CurrentValue-PreviousValue, PreviousValue)

۱۱.۱۵. Relationshipهای اضافی

مدل را با Relationshipهای بی‌استفاده و مسیرهای مبهم پیچیده نکن. Ambiguity و Filter Direction نامناسب هم فهم مدل را سخت می‌کند و هم می‌تواند Queryها را پیچیده‌تر کند.

۱۱.۱۶. Bidirectional Filter را پیش‌فرض نکن

Cross-filter دوطرفه در بعضی سناریوها لازم است، ولی استفاده گسترده و بی‌دلیل از آن می‌تواند مدل را پیچیده کند.

اول مدل یک‌طرفه و ساده را طراحی کن و فقط با دلیل مشخص سراغ Bidirectional برو.

۱۱.۱۷. Import Mode

در Import، داده داخل مدل Power BI بارگذاری می‌شود و Queryهای گزارش معمولاً از مدل Import شده پاسخ می‌گیرند.

این روش در بسیاری از سناریوهای تحلیلی Performance خوبی دارد، ولی Refresh و اندازه مدل باید مدیریت شوند.

۱۱.۱۸. DirectQuery

در DirectQuery بخش مهمی از Queryها هنگام تعامل کاربر به منبع داده ارسال می‌شوند. بنابراین Performance منبع، شبکه، Index و Query تولیدشده اهمیت زیادی پیدا می‌کند.

User click → Power BI → Source query → Database → Result → Visual

۱۱.۱۹. Import یا DirectQuery؟

انتخاب Mode باید بر اساس نیاز تازگی داده، حجم، زیرساخت و SLA انجام شود؛ نه بر اساس یک قانون ثابت.

۱۱.۲۰. Query Folding

در Power Query، وقتی Transformها بتوانند به منبع منتقل شوند، منبع بخشی از پردازش را انجام می‌دهد. این مفهوم Query Folding است.

Filter early
Select needed columns
Let source do work when folding is possible

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

۱۱.۲۱. Transformهای سنگین را بررسی کن

Mergeهای متعدد، عملیات پیچیده روی متن و پردازش حجم زیاد داده ممکن است Refresh را کند کنند.

اگر Transform سنگین است، بررسی کن آیا بخشی از آن بهتر است در Database، View یا ETL مرکزی انجام شود.

۱۱.۲۲. Source Optimization

گاهی مشکل اصلاً Power BI نیست. Query SQL ممکن است Table Scan سنگین داشته باشد یا View منبع کند طراحی شده باشد.

در چنین شرایطی باید با تیم Database روی Index، Query Plan، View و معماری منبع کار کرد.

۱۱.۲۳. Matrixهای خیلی بزرگ

Matrix با تعداد زیاد Row/Column و Measure می‌تواند Query و Rendering سنگینی ایجاد کند.

به جای نمایش هزاران ردیف در صفحه Executive، Drill Through یا صفحه جزئیات بساز.

۱۱.۲۴. Slicerهای High-Cardinality

قرار دادن ستون‌هایی با هزاران مقدار یکتا در Slicer همیشه تجربه خوبی ایجاد نمی‌کند. هم UX و هم Performance را بررسی کن.

برای جست‌وجوی مشتری یا محصول ممکن است طراحی صفحه جزئیات یا فیلتر هدفمند مناسب‌تر باشد.

۱۱.۲۵. Performance و RLS

امنیت هم می‌تواند روی Queryها اثر بگذارد. Dynamic RLS پیچیده و Relationshipهای امنیتی سنگین باید با کاربران مختلف تست شوند.

بعد از فعال‌سازی RLS فقط صحت امنیت را تست نکن؛ سرعت گزارش را هم در Context همان Role بررسی کن.

۱۱.۲۶. Refresh Performance

کندی Report و کندی Refresh دو مسئله متفاوت‌اند. Refresh می‌تواند به دلیل Source، Power Query، حجم داده یا Gateway کند باشد.

۱۱.۲۷. Incremental Refresh؛ مفهوم

وقتی Fact تاریخی بسیار بزرگ است، Refresh کامل همه تاریخچه ممکن است پرهزینه باشد. Incremental Refresh در سناریوهای مناسب کمک می‌کند بخش‌های جدید یا تغییرکرده مدیریت شوند.

پیاده‌سازی دقیق آن به نوع منبع، ظرفیت و تنظیمات محیط بستگی دارد؛ در پروژه واقعی قبل از طراحی باید محدودیت‌های محیط را بررسی کنیم.

۱۱.۲۸. روش عیب‌یابی مرحله‌ای

شکل ۱۱-۳ — از Visual تا منبع، Bottleneck را مرحله‌ای پیدا کن

اگر صفحه کند است، اول Visual کند را پیدا کن؛ بعد DAX و مدل را بررسی کن. اگر DirectQuery یا Refresh مسئله دارد، به Source و شبکه هم برس.

۱۱.۲۹. سناریوی شرکت هانا

فرض کنیم صفحه Executive شرکت هانا ۱۲ ثانیه برای نمایش کامل زمان می‌برد. به جای بازنویسی تصادفی Measureها، این مسیر را می‌رویم:

1) Performance Analyzer
2) Find slow visuals
3) Check visual count
4) Inspect measures
5) Inspect model/cardinality
6) Check source/query mode
7) Re-test

بعد از هر تغییر دوباره زمان را اندازه می‌گیریم.

۱۱.۳۰. بودجه Performance

برای پروژه حرفه‌ای بهتر است یک انتظار قابل اندازه‌گیری داشته باشیم؛ مثلاً صفحات اصلی در شرایط معمول باید در زمان قابل قبول سازمان پاسخ دهند.

عدد دقیق باید با زیرساخت، حجم داده و SLA پروژه تعیین شود؛ مهم این است که Performance یک معیار پذیرش باشد، نه چیزی که آخر پروژه یادمان بیفتد.

۱۱.۳۱. خطاهای رایج Performance

خطای اول: وارد کردن همه ستون‌های Source.

خطای دوم: جدول Fact پر از متن‌های تکراری.

خطای سوم: Visualهای زیاد در یک صفحه.

خطای چهارم: DAX پیچیده برای جبران مدل ضعیف.

خطای پنجم: DirectQuery بدون بررسی Database.

خطای ششم: Bidirectional Filter در همه‌جا.

خطای هفتم: Optimization بدون Benchmark.

۱۱.۳۲. Best Practiceهای Performance

مدل ستاره‌ای و ساده بساز.

ستون‌های غیرضروری را حذف کن.

Data Type را درست انتخاب کن.

Cardinality را بشناس.

Measureهای ساده و قابل استفاده مجدد بساز.

Power Query و Query Folding را بررسی کن.

صفحه را با Visualهای ضروری نگه دار.

Performance را بعد از RLS و روی داده واقعی هم تست کن.

۱۱.۳۳. تمرین پایه

یک صفحه گزارش را با Performance Analyzer بررسی کن و سه Visual کندتر را یادداشت کن. قبل از تغییر، زمان فعلی را ثبت کن.

۱۱.۳۴. تمرین متوسط

مدل را بررسی کن و پنج ستون غیرضروری یا High-Cardinality پیدا کن. توضیح بده حذف هرکدام چه اثری روی کاربرد گزارش دارد.

۱۱.۳۵. تمرین کاربردی

یک Measure پیچیده را انتخاب کن، آن را با VAR و Measureهای پایه بازنویسی کن و قبل و بعد را از نظر خوانایی و Performance مقایسه کن.

۱۱.۳۶. تمرین چالشی

برای یک Fact بزرگ تصمیم بگیر Import، DirectQuery یا طراحی ترکیبی چه مزایا و ریسک‌هایی دارد. نیاز تازگی داده، حجم، زیرساخت و رفتار کاربران را در تصمیم لحاظ کن.

۱۱.۳۷. پروژه نهایی فصل؛ Performance Audit شرکت هانا

برای داشبورد شرکت هانا یک Audit کامل انجام بده.

در پایان یک گزارش کوتاه Before/After بساز که نشان دهد کدام تغییرها بیشترین اثر را داشته‌اند.

جمع‌بندی فصل یازدهم

Performance Optimization یعنی پیدا کردن گلوگاه واقعی و اصلاح آن با داده و اندازه‌گیری. گاهی مشکل یک Measure است، گاهی مدل، گاهی SQL و گاهی فقط یک صفحه بیش از حد شلوغ.

Measure → Find bottleneck → Change one thing → Re-measure → Document

در فصل بعد وارد Governance و مدیریت حرفه‌ای BI می‌شویم: Naming Convention، مالکیت داده، مستندسازی، Data Quality، انتشار کنترل‌شده، چرخه تغییر و ساخت یک BI قابل اداره در سازمان.