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

تتضمن بيئات الحوسبة التفرعية النموذجية:
- MapReduce
- التحليلات ضمن قاعدة البيانات
- واجهة تمرير الرسائل Message Passing Interface (MPI)

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

في بيئة المعالجة التفرعية يُخصّص لكل معالجٍ ذاكرةٌ يستخدمها أثناء الحسابات على البيانات المخصصة له، ولذلك فإنْ فرضنا أن مجموعة الأرقام التي نريد إيجاد متوسطها الحسابي موزعةٌ على عدة معالجات فإنّ كلَّ معالجٍ يقوم بإيجاد المتوسط الحسابي للأرقام التي خُصِّصت له، ثم يسلّم كل من هذه المعالجات النتيجةَ الخاصة به إلى المعالج المركزي أو المتحكم لإيجاد المتوسط الحسابي للأرقام كلها.

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

لنلقِ نظرةً على كيفية تعامل MapReduce مع أعمال البيانات الكبيرة، يُستخدم إطار العمل هذا بشكل مشترك مع نظام ملفات هادوب الموزعة HDFS لكن هناك أيضاً استخداماتٌ لـ MapReduce في تخزين البيانات. تقوم فكرة عمل إطار MapReduce على قيام متحكمٍ مركزيٍّ بتوزيع العمل باستخدام تابع تخطيط على كل المعالجات المتاحة، يقوم كل معالجٍ بشكلٍّ مستقلٍ ويتم تلقيم النتائج إلى مرحلة التقليل التي ينفذها المقلّل الذي يلخص عمل المعالجات في مرحلة التخطيط. يتم حالياً كتابة كود كل من مرحلتي التخطيط والتقليل باستخدام لغة JAVA. هناك أيضاً أدواتٌ ذات مستوى أعلى وتحليلات تستخدم MapReduce، على سبيل المثال Pig وHive أداتان مفتوحتا المصدر، تتيح واجهاتٌ شبيهةٌ بالـ SQL لنظام ملفات هادوب الموسعة HDFS لأنّه من الأسهل أحياناً استخدام SQL من استخدام شيفرةٍ مخصّصةٍ توفّر نفس الإمكانيات الموروثة من SQL.

التقنية التفرعيّة الثانية هي مصطلحٌ محملٌ بشكلٍ زائد يدعى التحليل ضمن قواعد البيانات in-database analytic، هناك طريقتان لاستخدام هذا المصطلح، الأولى تشير إلى الإمكانيات الموسعة للغة SQL المسماة الامتدادات المعرّفة من قبل المستخدم User-defined والتي تأخذ شيفرةً مخصصة وتنفذها ضمن قاعدة البيانات. والثانية هي التحليلات التفرعية المبنية مسبقاً prebuilt، parallelized analytics التي تنفذ ضمن قاعدة البيانات. تنقل كلا الطريقتين المعالجةَ الحسابية إلى البيانات حيث أماكن تخزينها، ما يجنبنا مشكلة تأخير الأداء الناتجة عن عنق الزجاجة المرتبطة بنقل البيانات الكبيرة.

يوجد ثلاثة أنماط من الامتدادات المعرَّفة من قبل المستخدم تعتمدها لغة SQL هي:
· توابع معرفة من قبل المستخدم User-defined functions (UDF): يؤدي مهمة ويعيد قيمة واحدة.
· الإجمالي المعرف من قبل المستخدم User-defined aggregate (UDA): يختصر مجموعة من البيانات ويعيد قيمة واحدة.
· توابع الجداول المعرفة من قبل المستخدم User-defined table function (UDTF): تأخذ مجموعة بيانات من نفس الشكل (مثلاً عشرة أعمدة ومئة سطر) وتعيد تشكيل الخرج (يصبح مثلاً عمودين وخمسمائة سطر).

في بيئة تخزينِ بيانات تفرعية تنفذ لغة SQL مع الامتدادات المعرّفة من قبل المستخدم تفرعياً بشكلٍ أوتوماتيكيٍّ دون الحاجة لإنجاز البرمجة التفرعية بشكلٍ صريح. من ناحيةٍ أُخرى وكما هو الحال في MapReduce يحتاج المبرمج الذي يقوم بكتابة الامتداد فهمَ كيفية برمجة الحسابات كالوسيطِ مثلاً حتى لو قامت SQL بتوزيع حمل العمل. تكون المخططات مكافئةً لتوابع الجداول المعرفة من قِبَل المستخدم UDTFs، والمقلصاتُ مكافئةً للإجمالي المعرف من قبل المستخدم UDAs.

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

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

· محدودية الأقراص
· محدودية الدخل/الخرج
· محدودية الذاكرة
· محدودية وحدات المعالجة

تعني محدودية القرص أنك ببساطة لا تملك سعة تخزين كافية، محدودية الدخل/الخرج تعني أن عرض النطاق ليس كافياً للتحرك حول البيانات حتى تلبي احتياجات الأعمال. يمكن توضيح الفكرة بمثال عن أنبوب قطره عشرة إنش وتحاول ضغط حجم قدره خمسين تيرا بايت من البيانات الكبيرة خلال خمس دقائق لتمكين اتفاقيات مستوى الخدمة Service Level Agreement (SLA) التي تتطلبها أعمالك، في الوقت الذي تحتاج فيه لأنبوب قطره 100 إنش حتى تلبي هذه المتطلبات.

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

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

----------------------------------------------------

المصدر:
هنا