Get best of the week

كيفية التغلب على الأخطاء عند إنشاء التقارير في Power BI وتأتي إلى بناء نظام تحميل للبيانات الضخمة



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

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

تنصل


أنا أتحدث عن كميات كبيرة من البيانات وأعرض أمثلة على التحميل وأخذ عينات من Google Analytics 360. في المشاريع التي تحتوي على كمية صغيرة من البيانات ، قد لا توجد مثل هذه الصعوبات. لقد قابلت جميع المشاكل المحددة في الممارسة وفي المقالة أصف فقط تجربتي في الحل - يمكن أن تكون تجربتك مختلفة تمامًا.

موصل Yandex.Metrica


تتميز Yandex.Metrica بظروف أخذ عينات معتدلة وواجهة بديهية مقارنة ببرنامج Google Analytics. لذلك ، يفضل العديد من المسوقين Yandex.Metrica وبناء تقارير BI حول تحميل البيانات من هناك. للقيام بذلك ، استخدم موصل مكسيم أوفاروف. هذه الطريقة غير آمنة ولا تسمح بمعالجة الطلبات المعقدة.

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

أول ناقص كبير هو أنه من أجل استخدام الموصل ، في Power BI ، تحتاج إلى تمكين إعداد "تجاهل مستويات الخصوصية" ، وإلا فلن يعمل.



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



اتصال البيانات مجهول. ومع ذلك ، لا يوجد إذن أو تحقق من وجود إذن لاستخدام هذه البيانات لهؤلاء المستخدمين المسموح لهم حقًا.



لكي تعمل هذه الموصلات ، تحتاج إلى الحصول على رمز وصول عبر بروتوكول OAuth. يوفر وصف الموصل رابطًا حول كيفية منح التطبيق حق الوصول إلى حسابك.



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



النقص الثاني هو أن Yandex.Metrica API لا يمكنها معالجة كميات كبيرة من البيانات في المشاريع الكبيرة ، ونتيجة لذلك ، يرفض الموصل أيضًا العمل مع الاستعلامات المعقدة على بيانات Yandex.Metrica الأولية - لا يتم تحميلها.

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



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



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

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


لكي يتمكن جميع أصحاب المصلحة داخل الشركة من استخدام التقرير المستند إلى موصل Yandex.Metrica API ، تحتاج إلى نشر التقرير في خدمة PowerBI. في هذه الحالة ، يجب أيضًا تجاهل مستويات الخصوصية.


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

في الخطأ ، يشار إلى



جدول "الوظيفة المطلوبة " للتو: تم الحصول على هذا الجدول بسبب وظيفة PQYM ، والتي تعمل مع مصدر بيانات خارجي - Yandex.Metrica API. لا تعمل آلية تحديث التقارير في Power BI وتطلب إعادة الجمع بين الاستعلامات. ويرجع ذلك إلى الروابط الداخلية لطلب واحد للاتصال بطلب خارجي ، وكذلك بسبب بنية الوظيفة نفسها.



قررنا عدم استخدام مثل هذا الرابط عند إنشاء التقارير والتحول إلى تفريغ البيانات من Yandex.Metrica API عبر نصوص Python ، المزيد عن هذا لاحقًا في المقالة.

موصل Google Analytics


لإنشاء تقارير حول بيانات Google Analytics (نحن نتحدث عن التنزيل المباشر من نظام التحليلات) ، هناك أيضًا موصل Maxim Uvarov.

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



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



يمكنك إعادة كتابة بعض البيانات في الموصل نفسه والبدء في استخدامه للتطبيق الخاص بك. للقيام بذلك ، قم بتسجيل “OAuth 2.0 Client ID” على cloud.google.com، احصل على رموز الدخول وأدخل مفاتيح الوصول الضرورية في آلية عملها. ولكن حتى هذه الإجراءات لن تساعد في مكافحة أخذ العينات وتحديث تقاريرك.

كلما لمست البيانات المجمعة لـ Google Analytics API ، سنواجه دائمًا أخذ العينات.

يحتوي الموصل على خيار التفريغ في يوم واحد ، ولكن حتى لا يتم حفظه دائمًا. يوضح مؤشر أخذ العينات المدمج في الموصل أنه موجود حتى في يوم واحد.



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

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



يتداخل الخطأ نفسه لآلية العمل ، فقط وظائف PQGA.


رفضنا أيضًا العمل مع هذا الموصل.

رابط Google Analytics الأصلي


في بعض الأحيان يقدم كل من Google و Microsoft تنازلات لبعضهما البعض: يحتوي Power BI خارج الصندوق على موصل Google Analytics قياسي. لسوء الحظ ، لا يوجد مثل هذا الخيار لـ Yandex.Metrica.


يتم تنفيذ آلية العمل مع Google Analytics API بشكل أكثر ملاءمة هنا من موصل Maxim Uvarov ، ولكن أثناء تنزيل عدد كبير من المؤشرات ، يتم أخذ عينات البيانات أيضًا. الأرقام المكررة في لقطة الشاشة هي بيانات العينة.


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

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

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


وفقًا لملاحظاتي ، في تصنيف جلسات Shopping Stage ، لم يتمكن موصل واحد من تحميل البيانات بشكل طبيعي دون أخذ عينات من كميات كبيرة من البيانات.

في الموصل القياسي ، لا يمكنك تخصيص تواريخ التنزيل. كل ما هو ببساطة مجموعة مختارة من المعلمات والمقاييس من واجهات برمجة تطبيقات Google Analytics مرتبة في مجلدات.


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

العصي في عجلات من جوجل


لاحظنا مؤخرًا قفلًا غريبًا - عند محاولة تهيئة التحديث للموصل "الأصلي" لبرنامج Google Analytics ، ظهر خطأ في التفويض من خلال حساب Google في واجهة خدمة Power BI.



حاولنا أن نكتشف من Google ما يجب فعله في مثل هذه الحالة وكيفية "تبييض" سمعة الحساب ، لكن محاولاتنا باءت بالفشل. حاولنا تسجيل حسابات جديدة وتسجيل الدخول من خلال أجهزة مختلفة - حظرت Google أي محاولات ترخيص.

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

خيارات الحل


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

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

أشهر الخدمات:


يتيح لك كل نظام من هذه الأنظمة تكوين الدفق اليومي للبيانات غير المستندة إلى عينات من أنظمة تحليلات الويب (Yandex.Metrics و Google Analytics) إلى قواعد البيانات (على سبيل المثال ، BigQuery أو Azure SQL Database أو Microsoft SQL Server أو ClickHouse) للاتصال عبر Power BI وإنشاء التقارير.

إذا كانت الأدوات المدرجة باهظة الثمن بالنسبة للشركة ، فيمكنك محاولة تنفيذ نظام تحميل البيانات واستخدام Power BI + Python + Any Cloud Server (أو Yandex.Cloud) + PostgreSQL. هذه هي الطريقة التي نستخدمها عند إنشاء تقارير BI.

نظام تفاعل النظام:


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

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

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

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

هناك عدد كبير من الشركات التي تقدم خدمات التخزين السحابي. بناءً على التفضيلات الشخصية ، تم اختيار Yandex . Cloud .

مزايا Yandex.Cloud:

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



تتم كتابة التحميلات الناتجة إلى قاعدة بيانات PostgreSQL. تم اختيار قاعدة البيانات هذه لأنها DBMS مرتبطة بالكائنات (تعمل مع المصفوفات متعددة الأبعاد ودعم JSON من "الصندوق" - يجب أن تكون لهياكل البيانات المعقدة). إنها مرنة وموثوقة ومجانية ولديها أيضًا مجتمع ضخم من الدعم.

يحتوي Power BI على موصل مباشر مدمج في PostgreSQL. في أول اتصال ، تحتاج إلى تثبيت Npgsql إضافية . يخبرك Power BI بهذا ويوفر ارتباطًا.


لتكوين تحديثات التقرير عند استخدام التخزين السحابي ، يجب تكوين Power BI Gateway . هناك حاجة لتكوين تحديث إعداد تقارير BI وضمان أمان البيانات السرية عند نقلها من قاعدة بيانات ، والتي يجب أن تكون موجودة في دائرة تكنولوجيا المعلومات الداخلية في مؤسستك ، أو على خادم سحابي آمن.

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


بعد تنزيل بوابة Power BI وتشغيلها ، يظهر مربع حوار.


لتسجيل البوابة وتشغيلها ، يلزم تقديم بيانات اعتماد الخدمة السحابية لخدمة Power BI.


بعد كل الإعدادات ، ستظهر نافذة حول بوابة العمل. بعد ذلك ، تحتاج إلى إجراء إعدادات إضافية.


هناك بديل أبسط لتخصيص PostgreSQL هو Google BigQuery. يحتوي Power BI على موصل مضمن في Google BigQuery. في هذه الحالة ، من الضروري اتباع مبدأ "سبع مرات لحساب التكلفة ، مرة واحدة لتلبية الطلب".


يمكن استخدام BigQuery مجانًا لمدة عام ، ببساطة عن طريق ربط بطاقة مصرفية عند الموافقة على استخدام الخدمة. لن يتم خصم المال بعد الموعد النهائي دون علمك. مزيد من التعريفات - وفقًا لتعريفات النظام نفسه ، ولكن مع بعض "الإيجابيات" اللطيفة.

إذا لم تصل البيانات التي تم تنزيلها من أنظمتك إلى 10 غيغابايت في الشهر (!) ، فلن تكون هناك رسوم على التنزيل.


إذا لم تتجاوز المعالجة الشهرية للبيانات 1 تيرابايت ، فلن يتم فرض أي رسوم على ذلك أيضًا. إذا كان أكثر ، ثم 5 دولارات لكل علاج 1 تيرابايت.


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


تم وصف التعريفات بمزيد من التفصيل في صفحة BigQuery.

ملخص


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

الأول هو تدفق الخدمات. فهي سهلة الاستخدام ، ولديها دعم فني مستمر وتكامل جاهز مع مستودعات البيانات.

سلبيات:

  • تكاليف ملموسة على كميات كبيرة من البيانات.
  • تم توفير نوع محدود من التكامل.
  • عمليات غير مضبوطة على جانب مزود خدمة البث للعمل مع معلوماتك.

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

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

من الضروري تجميع بياناتك وهيكليتها وتجميعها من أنظمة التحليلات ومن تطبيقات الهاتف المحمول ومن خدمات العملاء الأخرى. سيساعد كل هذا في المستقبل على تحليل جمهورك ومنتجاتك في أي قسم. المعلومات والبيانات تحكم الآن العالم وأحيانًا تكلف أكثر من المال.

سأتحدث عن كيفية تنفيذ النهج الموصوف في المقالة لنقل بيانات التحليلات إلى قاعدة بيانات PostgreSQL باستخدام نصوص Python وتفاصيل التنفيذ في المقالات التالية.

More articles:


All Articles