لماذا تُفسد الأعمدة المحسوبة في Power BI أداء التقارير وتُضخّم ذاكرة النموذج؟

By Mirko Peters · 2026-10-29

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

Automatically translated with AI from the original post. Read the English original

الاستخدام الخاطئ للأعمدة المحسوبة في Power BI قد يُضخّم ذاكرة نموذج البيانات لديك دون أن تلاحظ، ويُبطئ أوقات عرض التقارير. فعلى عكس المقاييس الديناميكية، تُقيَّم الأعمدة المحسوبة كل صف وتُخزّنه أثناء تحديث البيانات، مستهلكةً قدرًا كبيرًا من ذاكرة الوصول العشوائي ومضيفةً عبئًا إضافيًا على المعالجة عبر بنية مساحات العمل لديك.

النقاط الرئيسية

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

التكلفة الخفية للذاكرة في التقييم على مستوى الصف

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

غير أن Power BI محرك تحليلي وليس جدول بيانات. فكلما أنشأت عمودًا محسوبًا، فأنت تُوجّه محرك قاعدة البيانات VertiPaq إلى حساب هذه القيمة لكل صف في الجدول أثناء عملية تحديث البيانات. فإذا كان جدول المبيعات لديك يحتوي على خمسة ملايين صف، فإن العمود المحسوب الجديد يُضيف خمسة ملايين إدخال مستقل إلى النموذج الدلالي.

والأسوأ من ذلك أن الأعمدة المحسوبة تتداخل مع خوارزميات الضغط لدى المحرك. فيعتمد VertiPaq على الأعمدة ذات العدد الأساسي المنخفض (Low cardinality)، أي الأعمدة التي تحتوي على قيم متكررة، لضغط البيانات بكفاءة. أما العمود المحسوب الفريد فغالبًا ما يُفسد كفاءة الضغط هذه، فيُضاعف الذاكرة اللازمة للإبقاء على النموذج محمّلًا في الذاكرة. ومع نمو النموذج، قد يتجاوز هذا التضخم في الذاكرة بسرعة حدود سعة مساحة العمل لديك في السحابة من Microsoft.

كيف يحدّ السياق الثابت من مرونة إعداد التقارير

إلى جانب استهلاك الذاكرة، تفرض الأعمدة المحسوبة قيودًا وظيفية كبيرة بسبب طريقة تعاملها مع سياق التقييم. فالعمود المحسوب يعمل ضمن سياق الصف حصرًا؛ إذ يُقيّم قيم الصف الحالي بمعزل عن تفاعلات المستخدم، أو أدوات تقطيع البيانات، أو اختيارات الترشيح المتبادل على لوحة التقرير.

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

يتناقض هذا الجمود بشكل واضح مع المقاييس، إذ تُحتسب نتائجها فورًا استنادًا بالكامل إلى سياق المرشح الذي يطبّقه المستخدم في تلك اللحظة بعينها. فعندما يتفاعل المستخدم مع مرئية، يُعاد احتساب المقياس ليقدّم رؤى دقيقة ومرتبطة بالسياق، في حين أن العمود المحسوب لا يفعل أكثر من إعادة عرض البيانات الثابتة المخزّنة في الذاكرة RAM.

تصميم نماذج أخف للاستفادة من Microsoft Fabric وAzure

يتطلب إعداد التقارير السحابية على نطاق المؤسسات كفاءة عالية، لا سيما عند التوسع عبر Microsoft Fabric وAzure وبيئات بيانات Microsoft 365 المعقدة. فالنماذج الدلالية المتضخمة تستنزف موارد البنية التحتية، وتُبطئ أزمنة الاستجابة للاستعلامات، وتُحبط مستخدمي الأعمال الذين ينتظرون تحميل لوحات المعلومات.

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

أما بالنسبة لجميع الحسابات التحليلية الأخرى، مثل الإجماليات والمتوسطات والنسب والتجميعات المشروطة، فينبغي نقل المنطق إلى المقاييس. فالمقاييس لا تستهلك أي مساحة تخزين لأنها لا تحتفظ بالقيم في النموذج. بل تبقى في الذاكرة كشيفرة فقط، ولا تُنفَّذ إلا عندما تطلب مرئية البيانات. يحافظ هذا الأسلوب على سعة الذاكرة RAM، ويعظّم ضغط البيانات، ويُبقي بنيتك التحتية السحابية تعمل بسلاسة.

الخلاصة

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

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

الأسئلة المتداولة

لماذا تستهلك الأعمدة المحسوبة قدرًا كبيرًا من الذاكرة في Power BI؟

تُقيَّم الأعمدة المحسوبة كل صف على حدة أثناء تحديث البيانات، ثم تُخزَّن هذه القيم بشكل دائم في ذاكرة RAM الخاصة بالنموذج. وهذا يمنع محرك VertiPaq من ضغط البيانات بفعالية، ما يؤدي إلى تضخم النموذج بسرعة.

هل تشغل المقاييس مساحة تخزين في النموذج الدلالي لـ Power BI؟

لا، فالمقاييس لا تشغل مساحة تخزين. فهي تُحفظ ببساطة كتعريفات معادلات في البيانات الوصفية، ولا تُحسب ديناميكيًا إلا عندما تطلب مرئية أو تفاعل المستخدم هذا الحساب.

متى يكون استخدام العمود المحسوب مناسبًا فعلًا؟

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

كيف تؤثر الأعمدة المحسوبة على أداء عرض التقارير؟

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