التحديث التزايدي في Power BI: التعامل مع مجموعات البيانات الكبيرة بكفاءة

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

لا يستغرق جدول المعاملات الذي يحتوي على 50 مليون صف، والذي يتم تحديثه بالكامل كل 4 ساعات، وقتًا طويلاً فحسب - بل إنه يهدر الموارد في إعادة تحميل البيانات التي لم تتغير. يعمل التحديث التزايدي على حل هذه المشكلة عن طريق تحميل السجلات الجديدة والمتغيرة فقط، مع الاحتفاظ بالبيانات التاريخية التي لا تتغير. إذا تم ذلك بشكل صحيح، يمكن تحديث مجموعة البيانات التي استغرق تحديثها سابقًا 3 ساعات في أقل من 10 دقائق.

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

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

• مجموعات بيانات أقسام التحديث التزايدية حسب التاريخ، مع تحميل البيانات الحديثة فقط في كل دورة تحديث
• يتطلب عمود التاريخ والوقت في جدول الحقائق ومعلمتي Power Query (RangeStart، RangeEnd)
• يتم الاحتفاظ بالبيانات التاريخية في الأقسام القديمة التي لا يتم إعادة الاستعلام عنها أبدًا بعد التحميل الأولي
• مطلوب Power BI Premium (أو Fabric) للتحديث المتزايد مع أكثر من 10 أقسام
• يؤدي خيار الكشف عن تغييرات البيانات إلى تقليل المعالجة عن طريق تحديث الأقسام التي تغيرت فيها البيانات فقط
• تعمل الجداول المختلطة (التي تجمع بين الاستيراد وDirectQuery) على تمكين البيانات في الوقت الفعلي إلى جانب أقسام الاستيراد التاريخية
• يتطلب التكوين الصحيح فهم طي Power Query — حيث تعمل الاستعلامات غير القابلة للطي على قطع التحديث المتزايد
• مراقبة صحة القسم عبر نقطة نهاية XMLA وأدوات الطرف الثالث تمنع حالات الفشل الصامتة

---

كيف يعمل التحديث التزايدي

يبدأ فهم التحديث التزايدي بفهم كيفية تقسيم بيانات Power BI.

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

يؤدي التحديث التزايدي إلى تقسيم جدول الحقائق إلى أقسام متعددة، يغطي كل منها نطاقًا زمنيًا محددًا:

• القسم 1: 01-01-2020 إلى 31-12-2020 (تاريخي، لم يتم تحديثه مطلقًا)
• القسم 2: 01-01-2021 إلى 31-12-2021 (تاريخي، لم يتم تحديثه مطلقًا)
• القسم 3: 01-01-2022 إلى 31-12-2022 (تاريخي، لم يتم تحديثه مطلقًا)
• القسم 4: 01-01-2023 إلى 31-12-2023 (تاريخي، لم يتم تحديثه مطلقًا)
• القسم 5: 01-01-2024 إلى 31-12-2024 (يتم التحديث شهريًا)
• القسم 6: 01-01-2025 إلى 31-03-2025 (يتم التحديث يوميًا)
• القسم 7: 01-04-2025 إلى الحالي (يتم تحديثه كل ساعة أو عند الطلب)

في كل عملية تحديث مجدولة، تتم معالجة الأقسام الأحدث فقط (5 و6 و7 في هذا المثال). تظل الأقسام التاريخية سليمة منذ أن تم تحميلها لأول مرة. وهذا يعني أن دورة التحديث لا تعالج سوى جزء صغير من إجمالي البيانات، مما يقلل بشكل كبير من الوقت والذاكرة وتحميل النظام المصدر.

---

المتطلبات والمتطلبات

قبل تكوين التحديث التزايدي، تأكد من استيفاء هذه المتطلبات الأساسية:

الترخيص: يتوفر التحديث التزايدي في Power BI Pro (مع قيود) وPower BI Premium/Fabric (القدرة الكاملة). باستخدام Pro، يمكنك تكوين ما يصل إلى 10 فترات تحديث. يزيل Premium هذا الحد ويضيف ميزة "اكتشاف تغييرات البيانات".

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

طي الاستعلام: يجب أن يدعم استعلام Power Query الذي يقوم بتحميل جدول الحقائق طي الاستعلام — القدرة على ترجمة خطوات تحويل Power Query إلى استعلام مصدر (SQL، وما إلى ذلك) ينفذه النظام المصدر. في حالة انقطاع طي الاستعلام، يفشل التحديث التزايدي بصمت — حيث يتم تحميل جميع البيانات في كل تحديث، مما يؤدي إلى إحباط الغرض.

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

---

التكوين خطوة بخطوة

الخطوة 1: إنشاء معلمات Power Query المطلوبة

في Power BI Desktop، افتح Power Query Editor. انتقل إلى إدارة المعلمات → معلمة جديدة.

قم بإنشاء معلمتين تمامًا كما يلي (الأسماء حساسة لحالة الأحرف ويجب أن تتطابق تمامًا):

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

الخطوة 2: تصفية جدول الحقائق باستخدام هذه المعلمات

في محرر Power Query، حدد جدول الحقائق الخاص بك. قم بتطبيق مرشح على عمود التاريخ والوقت باستخدام المعلمات:

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

تعتبر خطوة التصفية هذه ضرورية: يجب طيها إلى مصدر البيانات. للتحقق من الطي، انقر بزر الماوس الأيمن فوق خطوة الاستعلام الأخيرة وتحقق مما إذا كان "عرض الاستعلام الأصلي" متاحًا. إذا كان باللون الرمادي، فهذا يعني أن الطي قد تم كسره - تحقق من خطوات التحويل الموجودة فوقه والتي تؤدي إلى كسر سلسلة الطي.

الخطوة 3: التحقق من طي الاستعلام

فواصل طي الاستعلام الأكثر شيوعًا بسبب:

• الوظائف المخصصة التي لا يمكن ترجمتها إلى SQL
• دمج (ضم) استعلامين حيث لا يتم طي أحدهما أو كليهما
• بعض وظائف تحويل النص (Text.Upper، Text.PadStart)
• استخدام عمليات القائمة (List.Contains)
• إضافة عمود فهرس
• عمليات تحويل نوع معين

إذا انقطع الطي، فأعد بناء الاستعلام لدفع العمليات التي بها مشكلات إلى خطوة لاحقة بعد عامل تصفية التاريخ - أو قم بإجراء التحويل في طريقة عرض في قاعدة البيانات المصدر بدلاً من Power Query.

الخطوة 4: تكوين سياسة التحديث التزايدي

في Power BI Desktop، انقر بزر الماوس الأيمن فوق جدول الحقائق في جزء الحقول → التحديث التزايدي.

خيارات التكوين:

• تخزين الصفوف في السنوات/الأشهر/الأيام التقويمية N الأخيرة: يحدد هذا إجمالي النافذة التاريخية المحفوظة في النموذج. تتم إزالة البيانات الأقدم من هذا تلقائيًا من النموذج (الأقسام المسقطة).

• تحديث الصفوف فقط في السنوات/الأشهر/الأيام التقويمية N الأخيرة: يحدد هذا الإطار المتداول الذي يتم إعادة تحديثه في كل دورة. يتم التعامل مع البيانات الأقدم من هذه النافذة على أنها تاريخية (غير قابلة للتغيير) ولا يتم تحديثها مرة أخرى أبدًا.

• اكتشاف تغييرات البيانات: (للإصدار المميز فقط) يستخدم عمود تاريخ/وقت منفصل (عادةً عمود "آخر تعديل") لاكتشاف الأقسام التاريخية التي غيرت البيانات ويعيد معالجة تلك الأقسام فقط.

مثال لتكوين قاعدة بيانات المعاملات مع 5 سنوات من التاريخ:

• صفوف المتجر في آخر 5 سنوات
• تحديث الصفوف فقط في آخر 3 أيام

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

الخطوة 5: النشر والتحقق

قم بنشر التقرير إلى خدمة Power BI. سيستغرق التحديث الأول بعد النشر وقتًا أطول من التحديثات اللاحقة — حيث يقوم بتحميل كافة البيانات التاريخية وإنشاء كافة الأقسام لأول مرة. هذا هو المتوقع.

---

التكوين المتقدم: كشف تغييرات البيانات

يضيف خيار "اكتشاف تغييرات البيانات" في Premium طبقة أخرى من الكفاءة. وهو يعمل عن طريق الاستعلام عن عمود معين (عادةً عمود last_modified_date) لتحديد ما إذا كان قد تم تحديث أي سجلات في القسم التاريخي. يتم تحديث الأقسام التي تغيرت فيها البيانات بالفعل فقط.

بدون الكشف عن تغييرات البيانات: يتم دائمًا تحديث النافذة المتدرجة لمدة 3 أيام، حتى لو لم تتغير البيانات في آخر 3 أيام.

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

وهذا مفيد بشكل خاص للسيناريوهات التي:

• تتم كتابة بيانات المصدر مرة واحدة ونادرًا ما يتم تحديثها (أحداث الإلحاق فقط غير القابلة للتغيير)
• الفترة الزمنية المتغيرة كبيرة (على سبيل المثال، 30 يومًا) ولكن لا توجد تغييرات في معظم الأيام
• سعة الاستعلام عن نظام المصدر مقيدة

يجب فهرسة عمود الكشف عن تغييرات البيانات في قاعدة البيانات المصدر - يستعلم محرك التحديث عن هذا العمود لكل قسم في كل دورة تحديث.

---

الجداول المختلطة: الوقت الحقيقي + البيانات التاريخية

يقدم Power BI Fabric/Premium جداول مختلطة — مزيج قوي من وضع الاستيراد (الأقسام التاريخية) ووضع DirectQuery (بيانات اليوم الحالي). يؤدي ذلك إلى تمكين لوحات المعلومات التي تعرض البيانات المحدثة حتى الدقيقة الحالية إلى جانب بيانات الاستيراد التاريخية.

في تكوين جدول مختلط:

• الأقسام التاريخية (الأمس والأقدم) موجودة في وضع الاستيراد - سريعة ومخزنة مؤقتًا وقابلة للتجميع بالكامل
• قسم اليوم الحالي في وضع DirectQuery - يتم تشغيل الاستعلامات مباشرة على قاعدة البيانات المصدر

تجربة المستخدم سلسة — حيث تمتد الاستعلامات إلى كلا الوضعين بشفافية. يقوم استعلام "مبيعات هذا الأسبوع مقابل الأسبوع الماضي" بسحب بيانات الأمس من قسم الاستيراد وبيانات اليوم عبر DirectQuery، ودمجها في نتيجة واحدة.

اعتبارات للجداول المختلطة:

• يعتمد أداء DirectQuery بشكل كامل على أداء قاعدة البيانات المصدر - قاعدة البيانات البطيئة تعني بطء الاستعلامات الحالية
• لا يستفيد قسم DirectQuery من تحسينات وضع الاستيراد (لا يوجد ضغط VertiPaq ولا تجميعات مسبقة)
• يتطلب مساحة عمل مميزة أو قماشية

---

مراقبة صحة التحديث المتزايد

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

فحص نقطة نهاية XMLA: يكشف Power BI Premium عن نقطة نهاية XMLA يمكن لأدوات مثل SQL Server Management Studio (SSMS) أو Tabular Editor أو Azure Analysis Services الاتصال بها. من هناك، يمكنك الاستعلام عن بيانات تعريف القسم لمعرفة آخر وقت تحديث لكل قسم وما إذا كانت هناك أية أقسام في حالة خطأ.

Tabular Editor 2 (مجاني): اتصل بمساحة العمل المميزة عبر XMLA وافحص جدول الأقسام في النموذج. يعرض كل قسم اسمه ونطاق التاريخ والطابع الزمني لآخر تحديث وحالته. هذه هي الأداة الأكثر عملية لتشخيص مشكلات التحديث المتزايد.

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

أنماط الفشل الشائعة:

---

التحقق من طي الاستعلام عمليًا

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

الاختبار الأول: عرض الاستعلام الأصلي. بعد إضافة خطوة عامل التصفية RangeStart/RangeEnd في Power Query، انقر بزر الماوس الأيمن فوق الخطوة. إذا كان "عرض الاستعلام الأصلي" متاحًا ويظهر استعلام SQL مع عبارة WHERE لتصفية النطاق الزمني، فإن الطي يعمل.

الاختبار 2: التحقق من SQL التي تم إنشاؤها. يجب أن يحتوي الاستعلام الأصلي على شيء مثل:

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

إذا كانت جملة WHERE مفقودة، فهذا يعني أن الطي قد تعطل ويتم تطبيق عامل التصفية في محرك Power Query بعد تحميل كافة البيانات من المصدر.

استعادة الطي: إذا انقطع تحويل مخصص عن الطي، فانقله بعد خطوة عامل تصفية التاريخ، أو قم بإجراء التحويل في طريقة عرض SQL في قاعدة البيانات المصدر وقم بتوصيل Power BI بطريقة العرض بدلاً من الجدول.

---

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

هل يعمل التحديث التزايدي مع كافة مصادر البيانات؟

يعمل التحديث التزايدي مع أي مصدر بيانات يدعم طي الاستعلام وتصفية النطاق الزمني، بما في ذلك SQL Server وAzure SQL وPostgreSQL وSnowflake وBigQuery وAzure Synapse وDatabricks. ولا يعمل بشكل جيد مع المصادر التي لا تدعم طي الاستعلام (ملفات Excel، وCSV المسطح، وبعض واجهات برمجة تطبيقات REST) ​​— في هذه الحالات، لا يزال التحديث الكامل مطلوبًا. بالنسبة للمصادر غير القابلة للطي، يعد تنظيم البيانات في قاعدة بيانات SQL قبل اتصال Power BI هو الحل البديل الموصى به.

ما هو ترخيص Power BI المطلوب للتحديث المتزايد؟

يتوفر التحديث التزايدي في Power BI Pro (يقتصر على 10 فترات تحديث)، وPower BI Premium لكل سعة، وPower BI Premium لكل مستخدم (PPU)، وقدرات Microsoft Fabric. تتطلب ميزة "اكتشاف تغييرات البيانات" والجداول المختلطة Premium أو Fabric. بالنسبة لمعظم تطبيقات المؤسسات التي تحتوي على أكثر من 10 أقسام تاريخية، يلزم وجود Premium أو Fabric.

كيف يتعامل التحديث المتزايد مع البيانات المتأخرة؟

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

هل يمكن للتحديث المتزايد العمل على جداول الأبعاد، وليس الحقائق فقط؟

تم تصميم التحديث التزايدي لجداول الحقائق الكبيرة ويتطلب عمود تصفية التاريخ والوقت. لا تحتوي معظم جداول الأبعاد (المنتجات والعملاء والمواقع) على عمود قسم تاريخ/وقت مناسب وهي صغيرة بما يكفي بحيث يكون التحديث الكامل مناسبًا. بالنسبة لجداول الأبعاد التي تتغير ببطء والتي أصبحت كبيرة (جداول العملاء التي تحتوي على أكثر من 50 مليون صف)، يتمثل الأسلوب البديل في استخدام طرق عرض SQL في قاعدة البيانات المصدر لتصفية السجلات التي تم تغييرها مؤخرًا ومعالجة الاحتفاظ بالمحفوظات في طبقة قاعدة البيانات بدلاً من Power BI.

كيف يمكنني معرفة الأقسام الموجودة في نموذج التحديث التزايدي الخاص بي؟

أسهل طريقة هي توصيل Tabular Editor (الإصدار المجاني 2) بمساحة عمل Power BI Premium الخاصة بك عبر نقطة نهاية XMLA. ضمن الجداول → [الجدول الخاص بك] → الأقسام، سترى جميع الأقسام التي تم إنشاؤها مع نطاقاتها الزمنية وآخر طوابع زمنية تمت معالجتها. يتصل SQL Server Management Studio (SSMS) أيضًا عبر XMLA ويعرض تفاصيل القسم في Object Explorer.

ماذا يحدث إذا فشل التحديث المتزايد جزئيًا؟

إذا فشل التحديث في منتصف الطريق، فسيقوم Power BI بإعادة محاولة الأقسام الفاشلة. لا تتم إعادة معالجة الأقسام التي اكتملت بنجاح قبل الفشل، بل تتم إعادة محاولة الأقسام الفاشلة فقط. يعني سلوك إعادة المحاولة هذا أن التحديث التزايدي أكثر مرونة في مواجهة انقطاعات نظام المصدر العابرة مقارنة بالتحديث الكامل. إذا فشل القسم باستمرار، فسيظل القسم في آخر حالة تم تحميلها بنجاح بينما يستمر تحديث الأقسام الجديدة بشكل طبيعي.

---

الخطوات التالية

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

خدمات تحسين أداء Power BI من ECOSIRE تتضمن تصميم التحديث المتزايد وتنفيذه لمجموعات بيانات المؤسسة واسعة النطاق. اتصل بنا لتقييم بنية التحديث الحالية لديك وتحديد فرص التحسين.