عندما لا يكون نقل البيانات الخطوة الاولى

غالبا ما تبدأ مناقشات التحليل بعد ان تكون البيانات قد انتقلت بالفعل.

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

هذا النموذج مناسب جدا في كثير من الحالات.

لكن خلفه افتراض نادرا ما نفكر فيه: **يجب ان تنتقل البيانات اولا حتى نستطيع الاستفادة منها.**

هنا تطرح الحوسبة الطرفية سؤالا مختلفا.

ماذا لو تمت بعض المعالجة في المكان نفسه الذي تنشأ فيه البيانات؟

هذا لا يعني الاستغناء عن Cloud، ولا عن Data Warehouse، ولا عن منصة التحليل المركزية. الفكرة ببساطة هي اننا لسنا مضطرين دائما الى ارسال كل قطعة بيانات في رحلة كاملة قبل ان نستطيع فحصها، او تصفيتها، او التحقق منها، او حتى اتخاذ اجراء بناء عليها.

هذا هو جوهر Edge Computing: تنفيذ جزء من المعالجة بالقرب من مصدر البيانات بدلا من الاعتماد الكامل على خادم او منصة مركزية.

تعريف بسيط، لكن اثره على تصميم النظام قد يكون كبيرا جدا.

اسهل طريقة لفهم Edge Computing

تخيل متجرا كبيرا.

قد يحتوي المتجر اليوم على اجهزة POS، وقارئات باركود، ومستشعرات على الرفوف، وانظمة تبريد، وكاميرات، واجهزة محمولة، وانظمة اخرى تنتج البيانات طوال اليوم.

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

لكن ليس كل شيء يجب ان ينتظر وصوله الى تلك المنصة.

تخيل مثلا ان درجة حرارة احد المجمدات خرجت عن النطاق الامن.

في تلك اللحظة لا يهم كثيرا كيف يقارن هذا المجمد مع 200 مجمد اخر لدى الشركة. المهم ان هناك مشكلة تحتاج الى استجابة الان.

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

الجانبان مهمان، لكن لكل منهما دور مختلف.

المعالجة المحلية تهتم بما يحدث الان، بينما تمنحنا المنصة المركزية الصورة الاوسع.

هذه هي Edge Computing بصورة عملية.

لماذا نرسل بيانات اكثر اذا كان بامكاننا ارسال بيانات افضل؟

هناك ميل طبيعي في مشاريع البيانات الى التفكير بهذه الطريقة: اجمع كل شيء اولا، ثم نقرر لاحقا ما الذي نحتاجه.

احيانا يكون هذا منطقيا.

واحيانا يعني اننا ننقل ونخزن ونعالج كميات ضخمة من البيانات لا تضيف قيمة حقيقية.

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

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

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

لهذا ترتبط Edge Computing عادة بثلاث فوائد عملية: تقليل زمن الاستجابة، وتقليل استهلاك Bandwidth، وزيادة قدرة النظام على الاستمرار عندما لا يكون الاتصال مثاليا.

وهذه الفوائد مرتبطة ببعضها.

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

احيانا لا تهم ثوان قليلة، واحيانا تكون هي المشكلة كلها

كلمة Latency تبدو تقنية جدا حتى نضعها داخل موقف حقيقي.

فريق مالي يراجع ربحية الشهر الماضي لن يتاثر كثيرا اذا استغرق الحساب 200 millisecond اضافية.

سيارة متصلة يجب ان تتعامل مع جسم ظهر امامها مباشرة لديها مشكلة مختلفة تماما.

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

هذا لا يعني ان كل نظام في هذه المجالات يحتاج الى Edge Computing.

المهم هو ان قيمة المعالجة المركزية تتغير عندما يصبح الانتظار نفسه جزءا من المشكلة.

اذا كان القرار يستطيع الانتظار، فقد تبقى المعالجة المركزية الخيار الابسط.

اما اذا كان القرار يجب ان يحدث الان، فالتصميم يحتاج الى اجابة اخرى.

متى تصبح Edge Computing منطقية؟

هناك اربع حالات تجعل فكرة المعالجة بالقرب من المصدر اكثر وضوحا: القرارات التي تحتاج الى استجابة فورية، وتدفقات البيانات الكبيرة جدا، وضعف او عدم استقرار الاتصال، والحالات التي يفضل فيها ابقاء بعض البيانات محليا لاسباب تتعلق بالخصوصية.

خذ الاتصال مثلا.

قد تعمل قطعة من المعدات في موقع بعيد ويتوقف اتصالها بالشبكة لعدة دقائق. اذا كانت كل وظيفة مفيدة فيها تعتمد على الوصول المستمر الى نظام مركزي، فهذا يعني ان النظام يعتمد على شيء لا يستطيع التحكم به.

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

والان فكر في حجم البيانات.

قد تنتج كاميرا ذكية كمية ضخمة من الفيديو، بينما ما تحتاجه الشركة فعليا هو معرفة ان حدثا معينا وقع في وقت معين.

بدلا من ارسال الفيديو الكامل دائما، يمكن تنفيذ جزء من التحليل بالقرب من الكاميرا واستخراج المعلومة المطلوبة فقط.

هنا يتغير السؤال من:

**كيف سننقل كل هذه البيانات؟**

الى:

**ما البيانات التي نحتاج فعلا الى نقلها؟**

وهذا سؤال معماري افضل بكثير.

العلاقة مع Business Intelligence اكبر مما تبدو عليه

للوهلة الاولى قد تبدو Edge Computing موضوعا يخص البنية التحتية اكثر مما يخص Business Intelligence.

وهذا مفهوم، لاننا في BI نفكر عادة بما يحدث بعد وصول البيانات: Data Warehouse، وETL، والنماذج، ومؤشرات الاداء KPI، والتقارير، والـ Dashboards، والتنبيهات، والتحليل.

لكن جودة BI تبدأ قبل فتح اي Dashboard.

اذا دخلت بيانات سيئة الى الـ Pipeline، فلن يحل شكل التقرير المشكلة.

واذا دخلت الاف الاحداث غير المهمة الى المنصة، فسيتعين على شخص ما او عملية ما التخلص من هذا الضجيج لاحقا.

واذا وصلت معلومة مهمة بعد فوات الوقت المناسب لاتخاذ القرار، فقد يشرح لك الـ Dashboard ما حدث بشكل ممتاز، لكنه لن يساعد في القرار الذي كان يجب اتخاذه قبل خمس دقائق.

وهنا تصبح Edge Computing جزءا من قصة BI.

لان المعالجة بالقرب من المصدر تستطيع تحسين البيانات قبل ان تبدأ رحلتها الطويلة، وتقلل الضجيج، وتسرع التعامل مع الاحداث المهمة.

لكنني ارى ان القيمة اكبر من مجرد "بيانات اسرع".

القيمة الحقيقية هي اتخاذ **قرار افضل حول ما الذي يستحق ان يصبح جزءا من البيانات التحليلية اصلا**.

مثال المصنع يوضح الفكرة اكثر

تخيل ماكينة انتاج تحتوي على عدة Sensors تراقب الحرارة، والاهتزاز، والضغط، وسرعة التشغيل.

يمكن للنظام التقليدي ارسال كل قراءة الى المنصة المركزية.

وقد يكون هذا مطلوبا فعلا اذا كانت الشركة تحتاج الى الاحتفاظ بكل قراءة.

لكن في كثير من الحالات لا تكون المنصة المركزية مهتمة بكل قيمة منفردة بقدر اهتمامها بالاتجاهات، والحالات غير الطبيعية، والانحرافات، والاحداث المهمة.

يمكن لطبقة Edge تنفيذ جزء من العمل الاول بالقرب من الماكينة.

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

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

Edge ترى اللحظة.

اما BI فيرى القصة المحيطة بهذه اللحظة.

وهذا تقسيم للعمل اكثر فائدة من محاولة جعل كل شيء محليا او كل شيء مركزيا.

استخدام Edge Computing لا يعني بالضرورة ان التصميم اصبح افضل

هذه نقطة مهمة لان التقنيات الجيدة تتحول احيانا الى تصميم سيئ عندما نصر على استخدامها في كل مكان.

اذا لم يكن العمل حساسا للوقت، وكان الاتصال مستقرا، وحجم البيانات معقولا، وكانت المعالجة المركزية تعمل بشكل جيد، فقد تضيف Edge Computing طبقة جديدة من التعقيد دون فائدة حقيقية.

وهناك ايضا مسالة الاتساق.

عندما يتم توزيع Business Rules على عدد كبير من الاجهزة او المواقع، تصبح عملية تعديلها ومراقبتها اصعب. تغيير قاعدة واحدة في نظام مركزي اسهل بكثير من التأكد من تحديث المنطق نفسه على مئات الاجهزة.

كما ان بعض انواع التحليل لا يمكن ان تعيش محليا وحدها.

قد يعرف فرع ما ما يحدث داخل ذلك الفرع، لكنه لا يستطيع بمفرده معرفة اداء الشركة بالكامل.

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

لذلك لا يجب ان يبدأ السؤال هكذا:

**اين يمكننا استخدام Edge Computing؟**

السؤال الافضل هو:

**ما المشكلة التي سنحلها فعليا عندما نعالج هذه البيانات بالقرب من مصدرها؟**

اذا لم تكن هناك اجابة واضحة، فغالبا يكون التصميم الابسط هو الخيار الافضل.

Edge والتحليل المركزي ليسا بديلين لبعضهما

لا ارى Edge Computing بديلا عن التحليل المركزي.

كل منهما يرى نوعا مختلفا من الصورة.

قد يعرف النظام المحلي ان الماكينة ترتفع حرارتها الان، بينما تستطيع المنصة المركزية معرفة ان هذه المشكلة اصبحت تتكرر اكثر خلال الاشهر الاخيرة.

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

وقد تكتشف كاميرا حدثا معينا دون ارسال كامل الفيديو، بينما يستطيع النظام المركزي دراسة هذا النوع من الاحداث عبر عشرات المواقع وعلى مدى اشهر.

لهذا لا يجب ان يتحول النقاش الى Edge مقابل Cloud، او Local مقابل Central.

في كثير من الانظمة، الاجابة الصحيحة ستكون مزيجا من الاثنين.

بعض المعالجة يجب ان تحدث بالقرب من المصدر لان السرعة، او الاتصال، او حجم البيانات، او الخصوصية تجعل ذلك منطقيا.

ومعالجة اخرى يجب ان تبقى مركزية لان المقارنة، والتاريخ، والحوكمة، وتجميع البيانات، والتحليل على مستوى المؤسسة تحتاج الى رؤية اوسع.

السؤال الاهم هو: اين يجب ان يحدث الذكاء؟

لفترة طويلة كان النموذج الافتراضي في تصميم الانظمة التحليلية واضحا: انقل البيانات اولا، ثم تعامل معها.

Edge Computing تعطينا خيارا اخر.

قد يكون من الافضل التحقق من البيانات قبل ارسالها.

وقد يكون من الافضل اكتشاف الحدث محليا.

وقد يكون القرار الفوري من مسؤولية النظام الموجود عند المصدر، بينما يبقى التحليل طويل المدى في المنصة المركزية.

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

لا توجد اجابة واحدة تناسب الجميع.

الموضوع يعتمد على ما الذي يحاول النظام تحقيقه.

لهذا ارى Edge Computing اقل كـ "تقنية جديدة يجب استخدامها"، واكثر كقرار معماري يحدد **اين يجب ان تحدث المعالجة، واين يجب ان يحدث الذكاء**.

التحليل المركزي ما زال مهما جدا، وفي حالات كثيرة سيبقى المكان الذي تتكون فيه الصورة الاشمل والقرارات الاكثر اهمية.

لكن ليس كل ذكاء بحاجة الى انتظار وصول البيانات اليه.

احيانا يكون التصميم الافضل هو ان يحدث جزء من التفكير في المكان نفسه الذي تولد فيه البيانات.