Metabase أم Power BI: ما يحسم الاختيار لفريق صغير

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

من يبني التقرير عندكم؟

في Metabase يبني التقرير صاحب السؤال: يفتح المتصفح، ويختار جدولًا، ويحدد مقياسًا وتجميعًا، ويحفظ الرسم. وSQL متاح لمن يريده، والنموذج يجمع عمليات الربط فيبدأ الجميع من الجداول نفسها.

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

كل خيار ينقل الثمن ولا يلغيه. في Metabase يقع الثمن على الاتساق: عشرة أشخاص يعرّفون العميل النشط بعشر طرق ولا شيء يمنعهم. وفي Power BI يقع على الطابور: كل سؤال جديد ينتظر الكاتب، والكاتب مشغول في مكان آخر.

أين يسمح للبيانات أن تعيش؟

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

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

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

ما الذي تصونونه في الشهر السادس؟

Metabase: المثبّت، ويحتاج تحديثات ونسخة احتياطية؛ وصلاحيات مستخدم قاعدة البيانات، وتنحرف مع تغيّر المخطط؛ والأسئلة المحفوظة التي تنكسر حين يعاد تسمية عمود. والانكسار صاخب: خطأ يظهر على بطاقة، ويسأل أحدهم عن السبب.

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

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

كيف تعمل الصلاحيات فعلًا؟

Metabase يربط الصلاحية بالبيانات. تُمنح مجموعة حق الوصول إلى قاعدة أو مخطط أو جدول، وتصفية الصفوف وإخفاء الأعمدة متاحان في الإصدارات المدفوعة. والسؤال الذي يطرحه المستخدم: هل ترى هذه المجموعة هذا الجدول؟

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

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

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

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

كيف تقررون بالترتيب؟

1. سموا من سيبني أول تقرير يتصرف عليه أحد. إن كان الجواب «المدير، مرة واحدة»، فالمشكلة ليست في الأداة.
2. سموا الثاني والثالث ممن سيسألون سؤالًا الشهر القادم. تعدد السائلين يرجّح المتصفح، وكاتب واحد يرجّح النموذج.
3. اكتبوا قيد البيانات في جملة: أي الجداول لا تخرج، وفي أي بلد تبقى.
4. ابنوا سؤالًا حقيقيًا في كل أداة على بياناتكم لا على بيانات العرض. ثم أعيدوا تسمية عمود وراقبوا ما يحدث.
5. طابقوا رسمًا واحدًا مع النظام المصدر يدويًا، وانظروا هل يصمد الرقم في الرحلة.
6. حددوا مالك الأداة في الشهر السادس، باسمه، قبل التوقيع.

أين يخطئ الفريق؟

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

متى لا يصلح أي منهما

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

ما لا يغطيه هذا الرأي

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

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

نبني تعريف الرقم قبل الشاشة، لأن الترخيص قرار رخيص والتعريف هو ما يبقى.