تحسين أداء Power BI: DAX والنماذج والاستعلامات

تقرير Power BI الذي يستغرق تحميله 15 ثانية هو تقرير يتوقف المستخدمون عن استخدامه. الأداء ليس دقة فنية --- إنه الفرق بين اعتماد ذكاء الأعمال والتخلي عن ذكاء الأعمال. كل ثانية من وقت تحميل التقرير تقلل من تفاعل المستخدم بشكل ملموس. تُظهر الأبحاث باستمرار أن لوحات المعلومات التفاعلية (أقل من 3 ثوانٍ من وقت التحميل) تتلقى مرات مشاهدة أكثر بمقدار 4 إلى 5 أضعاف من تلك البطيئة (أكثر من 10 ثوانٍ)، والمستخدمون الذين يعانون من بطء متسق يعودون إلى العمليات اليدوية في غضون 30 يومًا.

والخبر السار هو أن مشكلات أداء Power BI تكون دائمًا قابلة للحل. في تجربتنا في تحسين مئات بيئات Power BI، ترجع 90% من مشكلات الأداء إلى أحد الأسباب الجذرية الخمسة: مقاييس DAX غير الفعالة، أو نماذج البيانات كبيرة الحجم، أو تصميم العلاقات السيئ، أو الاستخدام غير الملائم لـ DirectQuery، أو عدم كفاية سعة عبء العمل. يوفر هذا الدليل نهجًا منظمًا لتشخيص وحل كل مشكلة من هذه المشكلات.

إذا كانت بيئة Power BI لديك تواجه مشكلات في الأداء لا يستطيع فريقك حلها داخليًا، فإن [خدمات تحسين أداء Power BI] (/services/powerbi/performance-optimization) توفر التحليل العملي والمعالجة.

الوجبات الرئيسية

• يحدد محلل الأداء في Power BI Desktop العناصر المرئية والاستعلامات البطيئة --- ابدأ دائمًا هنا قبل التحسين
• يكشف DAX Studio ما إذا كانت الاستعلامات البطيئة تعاني من اختناق في محرك التخزين (مسح البيانات) أو محرك الصيغة (الحساب) --- يختلف الإصلاح بشكل كبير
• أخطاء أداء DAX الأكثر شيوعًا هي تداخل CALCULATE غير الضروري، واستخدام التكرارات حيث تكون المجمعات كافية، وإنشاء جداول متوسطة كبيرة
• يؤثر حجم النموذج بشكل مباشر على الأداء: يمكن أن تؤدي إزالة الأعمدة غير المستخدمة وتقليل عدد العناصر وتحسين أنواع البيانات إلى تقليص النماذج بنسبة 40-70%
• توفر جداول التجميع تحسينات في أداء الاستعلام بمعدل 10 إلى 100x لمجموعات البيانات الكبيرة عن طريق حساب البيانات الموجزة مسبقًا
• يعد DirectQuery أبطأ بمقدار 10 إلى 100 مرة من وضع الاستيراد للتقارير التفاعلية --- استخدمه فقط عندما تتطلب متطلبات حداثة البيانات ذلك حقًا
• يعد قياس الأداء قبل/بعده باستخدام المقاييس الموثقة أمرًا ضروريًا لإثبات تأثير التحسين ومنع التراجع

---

أدوات ومنهجية التشخيص

محلل الأداء

يعد محلل الأداء أداة تشخيصية مدمجة في Power BI Desktop. فهو يسجل وقت التنفيذ لكل استعلام يتم إنشاؤه بواسطة كل مرئي في صفحة التقرير، مع تقسيم الوقت إلى ثلاثة مكونات:

كيفية استخدام محلل الأداء:

1. افتح تقريرك في Power BI Desktop.
2. انتقل إلى عرض > محلل الأداء.
3. انقر فوق "بدء التسجيل".
4. التفاعل مع التقرير (تغيير عوامل التصفية، والتنقل بين الصفحات، وتطبيق شرائح).
5. انقر فوق "إيقاف".
6. قم بمراجعة النتائج مرتبة حسب المدة الإجمالية.

تفسير النتائج:

• إذا كان وقت استعلام DAX هو السائد، فإن المشكلة تكمن في المقاييس أو النموذج. استخدم DAX Studio لإجراء تحليل أعمق.
• إذا كان وقت العرض المرئي هو السائد، فإن المشكلة تكمن في التكوين المرئي (عدد كبير جدًا من نقاط البيانات، أو التنسيق الشرطي المعقد، أو مرئيات مخصصة ذات أداء سيئ).
• إذا كان الوقت "الآخر" هو السائد، فإن المشكلة تكمن في البنية الأساسية (زمن وصول الشبكة لـ DirectQuery، أو اختناقات البوابة، أو اختناق السعة).

الخطوة الحاسمة التي يتخطاها معظم الأشخاص: انسخ استعلام DAX من Performance Analyzer (انقر بزر الماوس الأيمن > "نسخ الاستعلام") والصقه في DAX Studio. يخبرك محلل الأداء بالمرئيات البطيئة. يخبرك DAX Studio بالسبب.

ستوديو داكس

DAX Studio عبارة عن أداة مجانية مفتوحة المصدر توفر إمكانات تشخيصية عميقة لمحرك خدمات التحليل الأساسي لـ Power BI. إنها الأداة الأكثر أهمية في مجموعة أدوات أي مهندس أداء في Power BI.

إمكانيات DAX Studio الرئيسية:

توقيت الخادم: يُظهر التقسيم بين وقت استعلام محرك التخزين (SE) ومحرك الصيغة (FE).

• استعلامات محرك التخزين (SE) هي عمليات فحص للبيانات يتم تنفيذها على وحدة التخزين العمودية (محرك VertiPaq). فهي متوازية للغاية وسريعة. تظهر استعلامات SE كعبارات xmSQL في التتبع.
• عمليات محرك الصيغة (FE) هي عمليات حسابية أحادية الترابط يتم إجراؤها على نتائج استعلامات SE. تعتبر عمليات FE هي عنق الزجاجة الأساسي في معظم مقاييس DAX البطيئة.

هدف التحسين هو دفع أكبر قدر ممكن من العمل إلى محرك التخزين وتقليل عمليات محرك الصيغة.

خطط الاستعلام: يمكن لـ DAX Studio عرض خطط الاستعلام المنطقية والمادية، مما يوضح بالضبط كيفية معالجة المحرك لقياسك. بالنسبة للمستخدمين المتقدمين، تكشف خطط الاستعلام عن فرص التحسين غير المرئية في بيانات التوقيت وحدها.

محلل VertiPaq: يقوم بمسح نموذج البيانات بالكامل ويبلغ عن حجم العمود والأصل ونوع الترميز وحجم القاموس لكل عمود في كل جدول. هذه هي الطريقة التي تحدد بها الأعمدة والجداول كبيرة الحجم التي تعمل على تضخيم النموذج الخاص بك.

منهجية التحسين المنهجي

1. خط الأساس: سجل أوقات التحميل لكل صفحة باستخدام أداة تحليل الأداء. حجم نموذج المستند (ملف > معلومات > تقليل حجم الملف > تحليل). سجل مقاييس السعة إذا كانت على Premium/Fabric.

2. تحديد: فرز نتائج محلل الأداء حسب المدة الإجمالية. ركز على أبطأ 5 صور مرئية --- توفر أكبر تأثير عند تحسينها.

3. التشخيص: انسخ كل استعلام بطيء إلى DAX Studio. تحليل الوقت SE مقابل FE. تحديد أنماط DAX المحددة التي تسبب اختناقات FE.

4. التحسين: تطبيق الإصلاحات المستهدفة (الموضحة بالتفصيل أدناه). اختبار كل تغيير على حدة لقياس تأثيره.

5. التحقق: أعد تشغيل محلل الأداء وقارنه بخط الأساس. توثيق التحسين لكل تحسين.

6. المراقبة: قم بإعداد مراقبة مستمرة للأداء (مقاييس السعة، والمشكلات التي أبلغ عنها المستخدم، وفحوصات محلل الأداء الدورية) لمنع التراجع.

---

أنماط وإصلاحات DAX البطيئة

النمط 1: حساب التداخل غير الضروري

المشكلة:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

لا تضيف عبارات CALCULATE المتداخلة قوة --- فهي تضيف ارتباكًا وأحيانًا تزيد من حمل الأداء. تقوم كل عملية CALCULATE بإنشاء سياق عامل تصفية جديد، وقد يؤدي تداخلها إلى نتائج غير متوقعة وإجبار محرك الصيغة على إجراء انتقالات سياق زائدة عن الحاجة.

الإصلاح:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

دمج وسائط التصفية في حساب واحد. يتم تطبيق وسائط التصفية المتعددة في وقت واحد (التقاطع). وهذا ينتج نفس النتيجة مع التنفيذ الأنظف.

النموذج 2: التصفية باستخدام الكل بدلاً من مرشحات الأعمدة المباشرة

المشكلة:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

يفرض FILTER(ALL(Products), ...) على المحرك إنشاء جدول المنتجات بالكامل في محرك الصيغة، ثم يتكرر خلال كل صف لتطبيق عامل التصفية. بالنسبة للجدول الذي يحتوي على ملايين الصفوف، يكون هذا بطيئًا للغاية.

الإصلاح:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

يتم حل عوامل تصفية الأعمدة المباشرة في CALCULATE في محرك التخزين، وهو أمر أسرع من حيث الحجم. استخدم عامل التصفية فقط عندما تحتاج إلى تطبيق شرط معقد لا يمكن التعبير عنه كمقارنة أعمدة بسيطة (على سبيل المثال، التصفية على قيمة مقياس أو شرط يتضمن أعمدة متعددة).

القاعدة الأساسية: إذا كان شرط FILTER يشير إلى عمود واحد بمقارنة بسيطة، فاستبدله بوسيطة عامل التصفية CALCULATE المباشرة. فلتر احتياطي للظروف المعقدة حقًا.

النموذج 3: التكرارات حيث تكون أدوات التجميع كافية

المشكلة:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

يتكرر SUMX خلال كل صف في جدول المبيعات، ويقيم التعبير لكل صف في محرك الصيغة. بالنسبة لجدول المبيعات الذي يحتوي على 10 ملايين صف، فهذا يعني 10 ملايين عملية FE.

الإصلاح:

إذا كان الحساب عبارة عن ضرب بسيط لعمودين، فاحسبه مسبقًا كعمود محسوب:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

تعمل SUM في محرك التخزين، الذي يعالج البيانات العمودية على دفعات محسنة للغاية. يضيف العمود المحسوب حجم النموذج ولكنه يقلل بشكل كبير من وقت الاستعلام.

متى يجب الاحتفاظ بـ SUMX: استخدم SUMX عندما تحتاج إلى منطق شرطي على مستوى الصف (على سبيل المثال، SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) أو عند التكرار على جدول صغير (جداول الأبعاد التي تحتوي على آلاف، وليس ملايين، من الصفوف).

النموذج 4: جداول متوسطة كبيرة

المشكلة:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

يقوم SUMMARIZE بإنشاء جدول متوسط ​​في محرك الصيغة. إذا أدى الجمع بين الفئة والشهر إلى إنتاج 10000 صف، وقام [الحساب المعقد] بتشغيل استعلامات SE إضافية لكل صف، فستكون النتيجة أكثر من 10000 استعلام --- وهو نمط أداء كارثي يُعرف باسم "عواصف استعلام SE".

الإصلاح:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

من خلال تحقيق الإجمالي الفرعي ضمن ADDCOLUMNS (الذي يستخدم انتقال السياق بكفاءة)، فإن المراجع اللاحقة إلى @SubTotal لا تؤدي إلى تشغيل استعلامات SE إضافية. تضمن المتغيرات (VAR) أيضًا تقييم الجدول مرة واحدة فقط، حتى لو تمت الإشارة إليه عدة مرات.

النموذج 5: تأثير أداء الأمان على مستوى الصف

المشكلة:

يتم تقييم RLS مع تعبيرات DAX المعقدة لكل استعلام، مما يضيف الحمل الذي يتراكم عبر العناصر المرئية. يمكن أن تؤدي قاعدة RLS المكتوبة بشكل سيئ إلى مضاعفة أوقات تحميل التقرير أو ثلاثة أضعافها.

** قتلة أداء RLS الشائعة: **

• LOOKUPVALUE في مرشحات RLS (يفرض تقييم FE لكل صف)
• يحتوي على أو في عوامل التشغيل على طاولات كبيرة
• قواعد RLS تشير إلى التدابير بدلاً من مرشحات الأعمدة البسيطة
• RLS متعدد الجداول مع مشكلات في اتجاه التصفية المتقاطعة

الإصلاح:

• استخدم مقارنات الأعمدة البسيطة: [TenantId] = USERNAME() أو [Region] IN VALUES(SecurityTable[Region])
• حساب تعيينات الأمان مسبقًا في جدول أبعاد مخصص مع علاقات مباشرة
• تجنب التدابير في قواعد RLS --- استخدم عوامل التصفية على مستوى العمود فقط
• اختبار أداء RLS مع DAX Studio من خلال مقارنة أوقات الاستعلام مع RLS النشط وبدونه

---

تقليل حجم النموذج

سبب أهمية حجم الموديل

يقوم وضع Power BI Import بتخزين البيانات بتنسيق عمودي مضغوط للغاية (محرك VertiPaq). يؤثر حجم النموذج بشكل مباشر على:

• استهلاك الذاكرة: يجب أن يتناسب النموذج بأكمله مع الذاكرة. في الطرازات Premium/Fabric، تستهلك النماذج الأكبر حجمًا سعة أكبر وقد تؤدي إلى اختناق ضغط الذاكرة.
• مدة التحديث: تستغرق النماذج الأكبر حجمًا وقتًا أطول للتحديث لأنه يجب معالجة المزيد من البيانات وضغطها وتحميلها.
• أداء الاستعلام: تنتج النماذج الأكبر حجمًا عمليات مسح أكبر، مما يزيد من وقت الاستعلام حتى بالنسبة لـ DAX المحسّن جيدًا.
• حجم الملف: تكون ملفات PBIX ذات النماذج الكبيرة بطيئة في الحفظ والنشر والتنزيل.

تحديد المساهمين في حجم النموذج

استخدم محلل VertiPaq الخاص بـ DAX Studio (متقدم > عرض المقاييس) لتحديد أكبر الجداول والأعمدة:

تقنيات التحسين

إزالة الأعمدة غير المستخدمة:

التحسين الوحيد ذو التأثير الأعلى. يستهلك كل عمود في النموذج الخاص بك الذاكرة سواء تم استخدامه أم لا. قم بمراجعة النموذج الخاص بك وقم بإزالة أي عمود غير مُشار إليه في قاعدة مرئية أو قياس أو علاقة أو قاعدة RLS.

التأثير النموذجي: تقليل حجم النموذج بنسبة 20-40%.

تقليل أصل عمود النص:

يتم ضغط الأعمدة النصية التي تحتوي على العديد من القيم الفريدة (الأوصاف والعناوين والملاحظات) بشكل سيئ. إذا كان العمود مطلوبًا للعرض فقط (وليس للتصفية أو التجميع)، ففكر في نقله إلى جدول التفاصيل فقط أو اقتطاع القيم الطويلة.

بالنسبة للأعمدة المستخدمة في التجميع/التصفية، فكر في التجميع: بدلاً من 50000 اسم منتج فريد، قم بالتجميع في 500 فئة منتج مع جدول بحث منفصل لتفاصيل المنتج الفردية.

تحسين أنواع البيانات:

• استخدم عددًا صحيحًا بدلاً من العدد العشري عندما تكون القيم أرقامًا صحيحة (يوفر 50% لكل عمود)
• استخدم التاريخ بدلاً من DateTime عندما لا تكون هناك حاجة للوقت (يقلل من العلاقة الأساسية)
• تجنب تخزين القيم الرقمية كنص (ضغط النص أسوأ بكثير من الأرقام)
• استخدم القيمة المنطقية بدلاً من النص لأعمدة نعم/لا أو صواب/خطأ

التأثير النموذجي: تقليل حجم النموذج بنسبة 10-20%.

تقسيم الطاولات الكبيرة:

يمكن تقسيم جدول الحقائق المكون من 100 مليون صف إلى بيانات نشطة (السنة الحالية، يتم تحميلها عند كل تحديث) وبيانات تاريخية (السنوات السابقة، يتم تحميلها بشكل أقل تكرارًا أو تخزينها كمجموعات). يؤدي هذا إلى تقليل حجم النموذج ومدة التحديث.

جداول التجميع (موضحة بالتفصيل أدناه):

بالنسبة لجداول البيانات الفعلية الكبيرة، توفر جداول التجميع أكبر تحسين للأداء من خلال الحساب المسبق للبيانات التلخيصية بالتفاصيل التي يتم الاستعلام عنها بشكل شائع.

---

جداول التجميع

ما هي جداول التجميع؟

جداول التجميع هي جداول تلخيصية محسوبة مسبقًا تستعلم عنها Power BI بدلاً من فحص جدول التفاصيل بالكامل. عندما يعرض المستخدم مخططًا يوضح الإيرادات الشهرية حسب المنطقة، يستعلم Power BI عن جدول التجميع (الذي قد يحتوي على 120 صفًا: 10 مناطق × 12 شهرًا) بدلاً من جدول التفاصيل (الذي قد يحتوي على 50 مليون صف معاملة).

تكمن قوة جداول التجميع في كونها شفافة للإبلاغ عن المستهلكين. يتفاعل المستخدمون مع نفس الصور والمقاييس. يقوم Power BI تلقائيًا بتوجيه الاستعلامات إلى جدول التجميع عندما تتطابق دقة الاستعلام، وينتقل إلى جدول التفاصيل للتنقل لأسفل أو الاستعلامات على مستوى التفاصيل.

تصميم جداول التجميع

الخطوة 1: تحديد دقة التجميع.

قم بتحليل تقاريرك لتحديد تفاصيل الاستعلام الأكثر شيوعًا. بالنسبة للوحة المبيعات:

• معظم الاستعلامات المرئية التنفيذية على مستوى الشهر + المنطقة + فئة المنتج
• الاستعلام المرئي للمدير على مستوى الأسبوع + المتجر + المنتج
• الاستعلام عن جداول التفاصيل على مستوى المعاملات الفردية

قم بتصميم جدول تجميع واحد أو اثنين بالتفاصيل الأكثر شيوعًا التي يتم الاستعلام عنها.

الخطوة 2: إنشاء جدول التجميع.

في Power Query، قم بإنشاء جدول جديد يقوم بتجميع جدول البيانات الفعلية الخاص بك على مستوى دقة التجميع:

الخطوة 3: تكوين تعيينات التجميع.

في Power BI Desktop، حدد جدول التجميع، وانتقل إلى خصائص > إدارة التجميعات، وقم بتعيين كل عمود تجميع إلى عمود جدول التفاصيل المقابل له ووظيفته:

الخطوة 4: إخفاء جدول التجميع.

يجب ألا يتفاعل المستخدمون مع جدول التجميع مباشرة. قم بإخفائه من عرض التقرير. ويستخدمه Power BI تلقائيًا وبشفافية.

تأثير أداء التجميع

تتراكم هذه التحسينات عبر صفحات التقرير. قد يتم تحميل صفحة تحتوي على 10 عناصر مرئية، يستعلم كل منها عن جدول التجميع بدلاً من جدول التفاصيل، خلال ثانية واحدة بدلاً من 30 ثانية.

صيانة جدول التجميع

• تحديث جداول التجميع بنفس الجدول الزمني مثل جداول التفاصيل للحفاظ على الاتساق
• مراقبة معدلات نجاح التجميع باستخدام DAX Studio (تظهر أحداث التتبع ما إذا كانت الاستعلامات قد وصلت إلى التجميع أو فشلت)
• أضف جداول تجميع جديدة أثناء تحديد أنماط الاستعلام الشائعة الإضافية
• إزالة جداول التجميع التي يقل معدل ضربها عن 50% (تستهلك مساحة دون فائدة كافية)

---

تحسين الاستعلام المباشر

عندما يكون الاستعلام المباشر ضروريًا

يقوم DirectQuery بالاستعلام عن قاعدة البيانات المصدر في الوقت الفعلي بدلاً من استيراد البيانات إلى محرك الذاكرة في Power BI. من الضروري عندما:

• تتطلب متطلبات حداثة البيانات زمن وصول أقل من دقيقة (تداول الأسهم ومراقبة إنترنت الأشياء واكتشاف الاحتيال)
• تتجاوز مجموعة البيانات حدود حجم نموذج Power BI (10 جيجابايت على Premium P1، و25 جيجابايت على P2، وما إلى ذلك)
• يتطلب الامتثال أو الأمان عدم مغادرة البيانات للنظام المصدر مطلقًا
• تحتوي قاعدة البيانات المصدر بالفعل على وجهات نظر محققة واسعة النطاق وبنية تحتية للتجميع

بالنسبة لجميع السيناريوهات الأخرى، يُفضل وضع الاستيراد بشدة. يعد وضع الاستيراد أسرع بمعدل 10 إلى 100 مرة بالنسبة للاستعلامات التفاعلية ويوفر تجربة مستخدم أفضل.

استراتيجيات أداء الاستعلام المباشر

تقليل عدد العناصر المرئية في كل صفحة.

يقوم كل مرئي في وضع DirectQuery بإنشاء استعلام منفصل لقاعدة البيانات المصدر. تنشئ الصفحة التي تحتوي على 20 عنصرًا مرئيًا 20 استعلامًا متزامنًا عند تحميل الصفحة، بالإضافة إلى استعلامات إضافية عند تغيير عوامل التصفية. الحد من صفحات DirectQuery إلى 8-10 صور كحد أقصى.

تحسين قاعدة البيانات المصدر.

يرسل Power BI استعلامات SQL (أو استعلامات أصلية لمصادر غير SQL) إلى المصدر. يحدد أداء قاعدة البيانات المصدر أداء التقرير بشكل مباشر. ضمان:

• توجد الفهارس في كافة الأعمدة المستخدمة في عوامل التصفية والعلاقات والمقاييس
• الإحصائيات محدثة على الجداول التي تم الاستعلام عنها
• يحتوي خادم قاعدة البيانات على وحدة معالجة مركزية وذاكرة كافية للاستعلامات التحليلية المتزامنة إلى جانب أعباء العمل التشغيلية
• خذ بعين الاعتبار إنشاء طرق عرض مادية أو طرق عرض مفهرسة لأنماط الاستعلام الشائعة

تمكين خيارات تقليل الاستعلام.

في Power BI Desktop > الخيارات > تقليل الاستعلام، قم بتمكين:

• "تقليل عدد الاستعلامات المرسلة عن طريق عدم إرسال استعلامات التمييز المتبادل": يمنع التصفية المتبادلة بين العناصر المرئية من إنشاء استعلامات إضافية
• "إضافة زر تطبيق إلى كل مقسم شرائح": يقوم المستخدمون بضبط مقسمات شرائح متعددة قبل تنفيذ الاستعلامات، مما يقلل إجمالي حجم الاستعلام
• "إضافة زر تطبيق إلى جزء التصفية": نفس المبدأ بالنسبة لجزء التصفية

** استخدم وضع التخزين المزدوج بشكل استراتيجي. **

يمكن تعيين الجداول على الوضع "ثنائي"، الذي يقوم بتخزين البيانات في وضع الاستيراد (للاستعلامات المحلية السريعة) ويحافظ على اتصال DirectQuery (للعلاقات مع جداول DirectQuery). قم بتعيين جداول الأبعاد (المنتجات والعملاء والتواريخ) على الوضع الثنائي مع الاحتفاظ بجداول البيانات الفعلية الكبيرة في DirectQuery. يؤدي هذا إلى تحسين أداء المرشح ومقسم البيانات بشكل كبير دون التضحية بحداثة البيانات في جداول الحقائق.

تنفيذ التخزين المؤقت للاستعلام.

قم بتمكين "التخزين المؤقت للاستعلام" في إعدادات مجموعة بيانات Power BI Service. يؤدي هذا إلى تخزين نتائج الاستعلام مؤقتًا لفترة قابلة للتكوين، وتقديم النتائج المخزنة مؤقتًا للاستعلامات المتطابقة. يعد التخزين المؤقت للاستعلام فعالاً بشكل خاص للوحات المعلومات التي يعرضها العديد من المستخدمين باستخدام نفس عوامل التصفية (على سبيل المثال، لوحة معلومات تنفيذية تعرض المقاييس على مستوى الشركة).

---

مراقبة أداء القدرات

مقاييس السعة الرئيسية

بالنسبة للمؤسسات ذات السعة المميزة أو النسيجية، فإن أداء البنية التحتية لا يقل أهمية عن تصميم التقارير. يمكن أن يؤدي تقييد السعة إلى ضعف أداء التقارير حتى التي تم تحسينها بشكل جيد.

المقاييس التي يجب مراقبتها:

تطبيق قياسات سعة النسيج من Microsoft

توفر Microsoft تطبيقًا مخصصًا لمراقبة السعة في Power BI Service. قم بتثبيته من AppSource وقم بتوصيله بقدرتك. وهو يوفر:

• استخدام وحدة المعالجة المركزية في الوقت الحقيقي والتاريخي مع تقسيمها حسب نوع عبء العمل
• تحليل الاختناق التفاعلي يوضح العمليات التي أدت إلى الاختناق
• استهلاك الذاكرة من خلال مجموعة البيانات مع تاريخ الإخلاء
• تحديث اتجاهات الأداء
• النسب المئوية لأداء الاستعلام

قم بمراجعة هذا التطبيق أسبوعيًا أثناء مراحل التحسين وشهريًا أثناء الحالة المستقرة.

السعة ذات الحجم الصحيح

تؤدي القدرة غير المتوفرة إلى الاختناق وضعف تجربة المستخدم. الإفراط في توفير القدرات يهدر المال. يتطلب الحجم الصحيح فهم نمط عبء العمل الخاص بك:

• ساعات الاستخدام القصوى: تشهد معظم المؤسسات حملًا أعلى بمقدار 2-3 مرات خلال ساعات العمل مقارنة بالليل. إذا كان حجمك مناسبًا للذروة ولديك وحدات SKU الخاصة بـ Fabric F، ففكر في التوقف مؤقتًا طوال الليل أو تقليص حجمه خلال ساعات العمل خارج ساعات العمل.
• التحديث مقابل التعارض التفاعلي: تتنافس عمليات تحديث البيانات والاستعلامات التفاعلية على نفس موارد السعة. جدولة عمليات التحديث المكثفة خارج ساعات الذروة التفاعلية. إذا لم يكن ذلك ممكنًا، ففكر في قدرات منفصلة للتحديث وأحمال العمل التفاعلية.
• توقعات النمو: خطة لمدة 6-12 شهرًا من النمو. يميل حجم النموذج وعدد المستخدمين وتعقيد الاستعلام إلى الزيادة بمرور الوقت. بناء 30-50% من الإرتفاع في حجم السعة.

---

قبل/بعد المقارنة المعيارية

لماذا تعتبر المقارنة المعيارية مهمة؟

التحسين بدون قياس هو تخمين. قبل/بعد قياس الأداء يثبت أن التغييرات تؤدي إلى تحسين الأداء، وتقيس التحسن بالنسبة لأصحاب المصلحة، وتخلق خط أساس لاكتشاف الانحدار المستقبلي.

منهجية المقارنة المعيارية

الخطوة 1: تحديد المقاييس.

الخطوة 2: تسجيل خط الأساس.

قبل إجراء أي تغييرات، سجل جميع المقاييس. قم بتشغيل "محلل الأداء" 10 مرات لحساب ارتفاع درجة حرارة ذاكرة التخزين المؤقت وتنوعها. سجل المتوسط ​​(P50) والمئوي 95 (P95) لكل مقياس.

الخطوة 3: تنفيذ التغييرات بشكل تدريجي.

قم بإجراء تحسين واحد في كل مرة وأعد القياس بعد كل تغيير. يحدد هذا التحسينات التي حققت أكبر تأثير ويمنع إخفاء الانحدار مع تحسين في مكان آخر.

الخطوة 4: تسجيل مقاييس ما بعد التحسين.

بعد كل التحسينات، قم بتسجيل نفس المقاييس باستخدام نفس المنهجية. عرض النتائج في جدول المقارنة:

| متري | قبل | بعد | تحسين | |--------|--------|-------------|-----|-----| | وقت تحميل الصفحة 1 (P50) | 8.2 ثانية | 1.4 ثانية | أسرع بنسبة 83% | | وقت تحميل الصفحة 1 (ص95) | 14.5 ثانية | 2.8 ثانية | أسرع بنسبة 81% | | أبطأ استعلام مرئي | 6,200 مللي ثانية | 450 مللي ثانية | أسرع بنسبة 93% | | حجم الموديل | 2.4 جيجا | 0.9 جيجا | أصغر بنسبة 62% | | مدة التحديث | 12 دقيقة | 4 دقائق | أسرع بنسبة 67% |

الخطوة 5: جدولة المراقبة المستمرة.

يتدهور الأداء بمرور الوقت مع نمو البيانات وإضافة مقاييس جديدة وإنشاء صور مرئية جديدة. قم بجدولة مراجعات الأداء ربع السنوية باستخدام نفس المنهجية لاكتشاف الانحدار مبكرًا.

بالنسبة للمؤسسات التي تحتاج إلى تحسين منهجي للأداء باستخدام مقاييس قبل/بعد موثقة، توفر ECOSIRE خدمات أداء Power BI الشاملة بما في ذلك تحليل DAX Studio وتحسين النموذج وضبط السعة.

---

تقنيات التحسين المتقدمة

مجموعات الحساب

تستبدل مجموعات الحساب متغيرات القياس المتكررة بمنطق الحساب القابل لإعادة الاستخدام. بدلاً من إنشاء مقاييس منفصلة لـ MTD وQTD وYTD والسنة السابقة والنمو السنوي لكل مقياس أساسي، تطبق مجموعة الحساب هذه التحويلات ديناميكيًا.

فائدة الأداء: يعني وجود مقاييس أقل في النموذج بصمة بيانات وصفية أصغر وتحميل أسرع للنموذج. والأهم من ذلك، أن مجموعات الحساب تشجع المقاييس الأساسية الأبسط، والتي تميل إلى الأداء بشكل أفضل من المقاييس المعقدة الشاملة.

النماذج المركبة

تجمع النماذج المركبة بين وضع الاستيراد وجداول DirectQuery في نموذج واحد. استخدم وضع الاستيراد لجداول الأبعاد وجداول البيانات الفعلية التي يتم الاستعلام عنها بشكل متكرر، وDirectQuery للجداول الكبيرة جدًا التي تتغير بشكل متكرر للغاية بالنسبة للاستيراد.

مزايا الأداء: يتم تشغيل عمليات البحث عن الأبعاد وعمليات التصفية بسرعة الاستيراد (ميكروثانية) بينما تعمل استعلامات جدول البيانات الفعلية بسرعة DirectQuery (مئات المللي ثانية إلى الثواني). النتيجة الصافية أفضل بكثير من DirectQuery النقي.

تحديث تزايدي

يقوم التحديث التزايدي بتحميل البيانات الجديدة والمتغيرة فقط أثناء التحديث، بدلاً من إعادة تحميل مجموعة البيانات بأكملها. بالنسبة لجدول مكون من 100 مليون صف حيث يتغير 100000 صف فقط يوميًا، فإن التحديث المتزايد يقلل وقت التحديث بنسبة 99%.

التكوين: تحديد معلمة RangeStart وRangeEnd في Power Query. قم بتكوين سياسة التحديث المتزايد لتحديد عدد أيام/أشهر البيانات المطلوب تحديثها ومقدار البيانات التاريخية المطلوب الاحتفاظ بها. يقوم Power BI تلقائيًا بتقسيم مجموعة البيانات وتحديث الأقسام النشطة فقط.

فائدة الأداء: انخفاض كبير في مدة التحديث واستهلاك السعة أثناء التحديث. يتيح أيضًا التحديث في الوقت الفعلي باستخدام أقسام DirectQuery على سعة النسيج.

طي الاستعلام

يؤدي طي الاستعلام إلى دفع تحويلات Power Query مرة أخرى إلى قاعدة البيانات المصدر، وتنفيذها كـ SQL أصلي بدلاً من محرك Power Query. تعمل الاستعلامات المطوية بشكل أسرع بكثير لأن محرك قاعدة البيانات يقوم بتحسينها وتنفيذها محليًا.

كيفية التحقق: انقر بزر الماوس الأيمن على أي خطوة في Power Query Editor وتحقق من توفر "عرض الاستعلام الأصلي". إذا كان الأمر كذلك، فسيتم طي الاستعلام إلى تلك الخطوة. إذا كان باللون الرمادي، فقد انكسر الطي في خطوة سابقة.

فواصل قابلة للطي شائعة: أعمدة مخصصة ذات تعبيرات M، ودمج الجداول من مصادر مختلفة، وتحويلات معينة (تحويلات نوع محورية ومعقدة). عند طي الفواصل، يتم تنفيذ كافة التحويلات اللاحقة في محرك Power Query، وهو أبطأ بشكل ملحوظ بالنسبة لمجموعات البيانات الكبيرة.

---

الأسئلة الشائعة

ما هو الهدف الجيد لوقت تحميل تقرير Power BI؟

استهدف أقل من 3 ثوانٍ للوحات المعلومات المستخدمة بشكل متكرر وأقل من 5 ثوانٍ للتقارير التحليلية التفصيلية. تتوافق هذه الأهداف مع توقعات المستخدم من تطبيقات الويب وتحافظ على مستوى المشاركة المرتفع. يجب إعطاء الأولوية للتقارير التي تتجاوز 10 ثوانٍ باستمرار من أجل التحسين. قم بقياس وقت التحميل من منظور المستخدم (بما في ذلك الشبكة والعرض)، وليس فقط وقت استعلام DAX. يجب أن يكون إجمالي وقت استعلام DAX لمحلل الأداء بالإضافة إلى وقت العرض المرئي أقل من ثانيتين لكل مرئي لتحقيق تحميل صفحة مدته 3 ثوانٍ مع 8-10 مرئيات.

هل يجب أن أفضّل دائمًا وضع الاستيراد على DirectQuery؟

بالنسبة للتقارير التفاعلية التي يستهلكها مستخدمو الأعمال، نعم --- يعد وضع الاستيراد هو الخيار الأفضل دائمًا تقريبًا. يعد وضع الاستيراد أسرع بمعدل 10 إلى 100 مرة بالنسبة للاستعلامات، ولا يعتمد على أداء قاعدة البيانات المصدر أثناء عرض التقرير، ويدعم النطاق الكامل لوظائف DAX وميزات الذكاء الاصطناعي. استخدم DirectQuery فقط عندما يكون لديك مطلب حقيقي لحداثة البيانات في أقل من دقيقة، أو عندما تتجاوز مجموعة البيانات الخاصة بك حدود حجم الاستيراد، أو عندما يتطلب الامتثال بقاء البيانات في النظام المصدر. خذ بعين الاعتبار النماذج المركبة كحل وسط: قم باستيراد الأبعاد والحقائق التي يتم الاستعلام عنها بشكل متكرر، وDirectQuery فقط الجداول التي تحتاج حقًا إلى الحداثة في الوقت الفعلي.

كم مرة يجب أن أقوم بإجراء عمليات تدقيق الأداء في تقارير Power BI الخاصة بي؟

إجراء تدقيق شامل للأداء ربع سنوي لتقارير الإنتاج. بين عمليات التدقيق، راقب مقاييس السعة أسبوعيًا وتحقق من أي بطء أبلغ عنه المستخدم على الفور. تشمل الأحداث الرئيسية التي يجب أن تؤدي إلى إجراء تدقيق فوري ما يلي: نمو كبير في حجم البيانات (زيادة بأكثر من 25%)، وإضافة صفحات تقرير جديدة أو مقاييس DAX المعقدة، والتغييرات في توافق المستخدم (نمو المستخدم بعد الإطلاق)، وتغييرات السعة (الترقية أو الرجوع إلى إصدار سابق أو الترحيل).

هل يمكنني تحسين أداء Power BI دون تغيير تقاريري؟

نعم إلى حد ما. تتضمن التحسينات على مستوى البنية التحتية ما يلي: ترقية سعة SKU، وتمكين التخزين المؤقت للاستعلام في إعدادات الخدمة، وجدولة عمليات التحديث المكثفة خارج ساعات الذروة، وتكوين تجميع البوابة لتحسين الإنتاجية، وتحسين قاعدة البيانات المصدر (الفهارس والإحصائيات وطرق العرض المادية). تعمل هذه التغييرات على تحسين الأداء دون لمس ملفات التقرير. ومع ذلك، فإن التحسينات الأكثر تأثيرًا تتضمن عادةً تغييرات على مستوى التقرير: إعادة كتابة قياس DAX، وتقليل حجم النموذج، وجداول التجميع، وتقليل العدد المرئي. ويعالج تحسين البنية التحتية القيود المفروضة على القدرات؛ تحسين التقرير يعالج الكفاءة.

ما أسباب تباطؤ تقارير Power BI بمرور الوقت؟

خمسة أسباب شائعة: (1) نمو حجم البيانات --- تستغرق نفس الاستعلامات وقتًا أطول مع نمو الجداول من مليون إلى 10 ملايين صف. (2) تراكم القياس --- تتم إضافة مقاييس جديدة دون تحسين المقاييس الموجودة، وتؤدي التفاعلات بين المقاييس إلى تعقيد مضاعف. (3) التوسيع البصري --- يضيف المستخدمون المزيد من العناصر المرئية لكل صفحة، مما يؤدي إلى إنشاء استعلامات إضافية. (4) تضخم النموذج --- تتم إضافة أعمدة وجداول جديدة دون إزالة الأعمدة والجداول غير المستخدمة. (5) نمو المستخدم المتزامن --- يتنافس عدد أكبر من المستخدمين على نفس موارد السعة. قم بمعالجة هذه المشكلات من خلال عمليات تدقيق الأداء ربع السنوية، وسياسات الحوكمة التي تحد من العدد المرئي وتقيس التعقيد، ومراقبة القدرات الاستباقية.