Import مقابل DirectQuery مقابل Direct Lake: اختيار وضع التخزين المناسب في Power BI

By Mirko Peters · 2026-10-22

مقارنة بين أوضاع التخزين Import وDirectQuery وDirect Lake في Power BI لتحسين أداء التقارير وحداثة البيانات وتكاليف البنية التحتية.

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

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

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

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

فهم أوضاع التخزين في Power BI

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

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

آليات وضع Import والمقايضات

وضع Import هو الخيار الافتراضي والأكثر شيوعاً لدى المبتدئين. عند استخدامه، يسحب Power BI نسخة من بيانات المصدر ويضغطها بشدة، إذ يحقق غالباً نسبة ضغط تبلغ 10:1، ثم يحمّلها مباشرة إلى الذاكرة (RAM) داخل خدمة Power BI.

لأن البيانات موجودة بالكامل في الذاكرة، تُعرض المرئيات بسرعة فائقة، ويستطيع المستخدمون التقطيع والتحليل والتصفية دون انتظار الاتصالات بقواعد البيانات الخارجية. غير أن المقايضة الكبرى تتعلق بحداثة البيانات، فالأرقام المستوردة لا تكون أحدث من آخر تحديث مجدول. وفي السعات المشتركة لـ Power BI يمكنك تحديث البيانات حتى ثماني مرات في اليوم، بينما تتيح السعات Premium حتى 48 تحديثاً يومياً. وإذا كان عملك يتطلب تحديثات خلال أقل من دقيقة، فإن وضع Import وحده لن يكفي.

DirectQuery لاحتياجات الوقت الفعلي

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

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

Direct Lake: الميزة التي يتيحها Fabric

قُدِّم Direct Lake خصيصاً لمنصة Microsoft Fabric ليسدّ الفجوة بين سرعة وضع Import والحداثة الفورية للبيانات في DirectQuery. يقرأ Direct Lake جداول Delta المخزّنة في OneLake، وهو مخزن البيانات التحليلية الموحّد في Fabric، ويحمّل إلى الذاكرة عند الطلب الأعمدة المحددة فقط التي يحتاجها الاستعلام.

أبرز ما يميّز Direct Lake هو آلية التحديث. فعلى خلاف وضع Import الذي يتطلب نسخاً كاملاً للبيانات وإعادة تحميلها، لا يحدّث التحديث في Direct Lake سوى البيانات الوصفية (وهي عملية تسميها Microsoft "التأطير")، ويتم ذلك في ثوانٍ معدودة. وبذلك يحقق أداءً بسرعة الذاكرة دون عبء تكرار البيانات كل ليلة. وتجدر الإشارة إلى أن Direct Lake يتطلب اشتراك سعة Microsoft Fabric مدفوعة، ما يجعله حلاً بمستوى المؤسسات وليس ترقية مجانية.

بناء النماذج المركبة لتحقيق أفضل أداء

لستم مجبرين على اختيار نمط تخزين واحد لنموذج الدلالي بأكمله. فبالجمع بين أنواع تخزين مختلفة ضمن نموذج واحد، تنشئون ما تسميه Microsoft نموذجاً مركباً. ومن الأنماط الكلاسيكية الفعّالة جداً وضع جداول الأبعاد الصغيرة والمستقرة (مثل قوائم المنتجات أو فئات العملاء) في وضع Import لتحقيق التصفية الفورية، مع وضع جداول الحقائق الضخمة والمتنامية بسرعة (مثل سجلات المعاملات) في DirectQuery أو الاعتماد على Direct Lake.

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

الخاتمة

يعتمد الاختيار بين Import وDirectQuery وDirect Lake في نهاية المطاف على حجم مؤسستكم وميزانيتكم ومتطلباتكم للبيانات الفورية. فبمطابقة نمط التخزين مع الإيقاع التشغيلي لبيانات عملكم، يمكنكم بناء بيئات تحليلية موثوقة وسريعة الاستجابة. وللاطلاع على المزيد حول إعداد نماذج دلالية متينة، استمعوا إلى الحلقة الكاملة واشتركوا في البودكاست للحصول على رؤى يومية حول السحابة من Microsoft.

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

هل يمكنني دمج جداول Import وDirectQuery في نموذج Power BI نفسه؟

نعم. يدعم Power BI النماذج المركبة، ما يتيح تعيين أنماط تخزين مختلفة لجداول فردية ضمن النموذج الدلالي نفسه.

كم مرة يمكنني تحديث نموذج Power BI المستورد؟

على السعة المشتركة، يمكن تنفيذ عمليات التحديث المجدولة حتى 8 مرات في اليوم. وعلى سعة Premium أو Fabric، يمكنكم جدولة التحديث حتى 48 مرة في اليوم.

هل يتطلب Direct Lake مستوى ترخيص خاصاً؟

نعم، يتطلب Direct Lake اشتراك سعة Microsoft Fabric، في حين يمكن تشغيل Import وDirectQuery بتراخيص Power BI المجانية أو Pro القياسية.

ماذا يحدث لحسابات DAX في وضع DirectQuery؟

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