سوق الحوسبة الموزعة والبيانات الضخمة، وفقًا لـ ، ينمو بنسبة 18-19٪ سنويًا. وهذا يعني أن مسألة اختيار البرامج لهذه الأغراض تظل ذات صلة. في هذا المنشور، سنبدأ بالسبب وراء الحاجة إلى الحوسبة الموزعة، ونتناول المزيد من التفاصيل حول اختيار البرامج، ونتحدث عن استخدام Hadoop باستخدام Cloudera، وأخيرًا نتحدث عن اختيار الأجهزة وكيفية تأثيرها على الأداء بطرق مختلفة.
لماذا تعتبر الحوسبة الموزعة ضرورية في الأعمال العادية؟ كل شيء هنا بسيط ومعقد في نفس الوقت. بسيطة - لأننا في معظم الحالات نقوم بإجراء عمليات حسابية بسيطة نسبيًا لكل وحدة من المعلومات. إنه أمر صعب لأن هناك الكثير من هذه المعلومات. كثير جدا. ونتيجة لذلك، فمن الضروري . وبالتالي، فإن حالات الاستخدام عالمية تمامًا: حيث يمكن استخدام الحسابات حيثما كان ذلك ضروريًا لمراعاة عدد كبير من المقاييس في مجموعة أكبر من البيانات.
أحد الأمثلة الحديثة: سلسلة مطاعم البيتزا Dodo Pizza استنادًا إلى تحليل قاعدة بيانات طلبات العملاء، عند اختيار بيتزا ذات طبقة عشوائية، يستخدم المستخدمون عادةً ست مجموعات أساسية فقط من المكونات بالإضافة إلى مجموعتين عشوائيتين. ووفقا لهذا، قام مطعم البيتزا بتعديل مشترياته. بالإضافة إلى ذلك، تمكنت من التوصية بشكل أفضل بالمنتجات الإضافية المقدمة للمستخدمين خلال مرحلة الطلب، مما أدى إلى زيادة الأرباح.
مثال آخر: سمحت عناصر المنتج لمتجر H&M بتقليل التشكيلة في المتاجر الفردية بنسبة 40%، مع الحفاظ على مستويات المبيعات. وقد تم تحقيق ذلك من خلال استبعاد العناصر سيئة البيع، وتم أخذ الموسمية في الاعتبار في الحسابات.
اختيار الأداة
معيار الصناعة لهذا النوع من الحوسبة هو Hadoop. لماذا؟ لأن Hadoop هو إطار عمل ممتاز وموثق جيدًا (يوفر نفس الهبر العديد من المقالات التفصيلية حول هذا الموضوع)، والذي يرافقه مجموعة كاملة من الأدوات المساعدة والمكتبات. يمكنك إدخال مجموعات ضخمة من البيانات المنظمة وغير المنظمة، وسيقوم النظام نفسه بتوزيعها بين قوة الحوسبة. علاوة على ذلك، يمكن زيادة هذه القدرات نفسها أو تعطيلها في أي وقت - وهي نفس قابلية التوسع الأفقي أثناء العمل.
في عام 2017، قامت شركة الاستشارات المؤثرة جارتنر أن Hadoop سوف يصبح عفا عليه الزمن قريبًا. السبب عادي تمامًا: يعتقد المحللون أن الشركات ستنتقل بشكل جماعي إلى السحابة، حيث سيكونون قادرين على الدفع مقابل استخدامهم لقدرة الحوسبة. العامل المهم الثاني الذي من المفترض أن "يدفن" Hadoop هو سرعته. لأن الخيارات مثل Apache Spark أو Google Cloud DataFlow أسرع من MapReduce، الذي يقوم عليه Hadoop.
يعتمد Hadoop على عدة ركائز، أبرزها تقنيات MapReduce (نظام لتوزيع البيانات لإجراء العمليات الحسابية بين الخوادم) ونظام الملفات HDFS. تم تصميم هذا الأخير خصيصًا لتخزين المعلومات الموزعة بين العقد العنقودية: يمكن وضع كل كتلة ذات حجم ثابت على عدة عقد، وبفضل النسخ المتماثل، يكون النظام مرنًا في مواجهة فشل العقد الفردية. بدلا من جدول الملفات، يتم استخدام خادم خاص يسمى NameNode.
يوضح الرسم التوضيحي أدناه كيفية عمل MapReduce. في المرحلة الأولى يتم تقسيم البيانات وفق معيار معين، وفي المرحلة الثانية يتم توزيعها حسب القوة الحاسوبية، وفي المرحلة الثالثة يتم الحساب.
تم إنشاء MapReduce في الأصل بواسطة Google لتلبية احتياجات البحث الخاصة به. ثم أصبح MapReduce رمزًا مجانيًا، وتولى Apache المشروع. حسنًا، انتقلت Google تدريجيًا إلى حلول أخرى. معلومة مثيرة للاهتمام: لدى Google حاليًا مشروع يسمى Google Cloud Dataflow، والذي تم وضعه كخطوة تالية بعد Hadoop، كبديل سريع له.
تظهر نظرة فاحصة أن Google Cloud Dataflow يعتمد على نسخة مختلفة من Apache Beam، في حين يتضمن Apache Beam إطار عمل Apache Spark الموثق جيدًا، والذي يسمح لنا بالتحدث عن نفس سرعة تنفيذ الحلول تقريبًا. حسنًا، يعمل Apache Spark بشكل مثالي على نظام ملفات HDFS، مما يسمح بنشره على خوادم Hadoop.
أضف هنا حجم الوثائق والحلول الجاهزة لـ Hadoop وSpark مقابل Google Cloud Dataflow، ويصبح اختيار الأداة واضحًا. علاوة على ذلك، يمكن للمهندسين أن يقرروا بأنفسهم أي كود يجب عليهم تشغيله - Hadoop أو Spark، مع التركيز على المهمة والخبرة والمؤهلات.
السحابة أو الخادم المحلي
لقد أدى الاتجاه نحو الانتقال العام إلى السحابة إلى ظهور مصطلح مثير للاهتمام مثل Hadoop كخدمة. في مثل هذا السيناريو، أصبحت إدارة الخوادم المتصلة مهمة جدًا. لأنه، للأسف، على الرغم من شعبيتها، فإن Hadoop النقي هو أداة يصعب تكوينها إلى حد ما، حيث يجب القيام بالكثير يدويًا. على سبيل المثال، قم بتكوين الخوادم بشكل فردي، ومراقبة أدائها، وتكوين العديد من المعلمات بعناية. بشكل عام، العمل مخصص للهواة وهناك فرصة كبيرة لإفساد مكان ما أو فقدان شيء ما.
لذلك، أصبحت مجموعات التوزيع المتنوعة، والتي تم تجهيزها في البداية بأدوات النشر والإدارة الملائمة، شائعة جدًا. إحدى التوزيعات الأكثر شعبية التي تدعم Spark وتجعل كل شيء سهلاً هي Cloudera. يحتوي على إصدارات مدفوعة ومجانية - وفي الإصدار الأخير تتوفر جميع الوظائف الأساسية، دون الحد من عدد العقد.
أثناء الإعداد، سيقوم Cloudera Manager بالاتصال عبر SSH بخوادمك. نقطة مثيرة للاهتمام: عند التثبيت، من الأفضل الإشارة إلى أنه يتم تنفيذه بواسطة ما يسمى بارسل: حزم خاصة، تحتوي كل منها على جميع المكونات الضرورية التي تم تكوينها للعمل مع بعضها البعض. هذه في الأساس نسخة محسنة من مدير الحزم.
بعد التثبيت، نتلقى وحدة تحكم إدارة المجموعة، حيث يمكنك رؤية القياس عن بعد للمجموعة، والخدمات المثبتة، بالإضافة إلى أنه يمكنك إضافة/إزالة الموارد وتحرير تكوين المجموعة.
ونتيجة لذلك، تظهر أمامك مقصورة الصاروخ الذي سيأخذك إلى المستقبل المشرق لـ BigData. ولكن قبل أن نقول "دعونا نذهب"، دعونا نتحرك تحت الغطاء.
متطلبات الأجهزة
تذكر Cloudera على موقعها الإلكتروني التكوينات المحتملة المختلفة. المبادئ العامة التي بنيت عليها موضحة في الرسم التوضيحي:
يمكن لـ MapReduce أن يطمس هذه الصورة المتفائلة. إذا نظرت مرة أخرى إلى الرسم البياني من القسم السابق، يصبح من الواضح أنه في جميع الحالات تقريبًا، يمكن أن تواجه مهمة MapReduce عنق الزجاجة عند قراءة البيانات من القرص أو من الشبكة. تمت الإشارة إلى هذا أيضًا في مدونة Cloudera. ونتيجة لذلك، بالنسبة لأي حسابات سريعة، بما في ذلك من خلال Spark، والتي تُستخدم غالبًا للحسابات في الوقت الفعلي، فإن سرعة الإدخال/الإخراج مهمة جدًا. لذلك، عند استخدام Hadoop، من المهم جدًا أن تشتمل المجموعة على آلات متوازنة وسريعة، والتي، بعبارة ملطفة، لا يتم ضمانها دائمًا في البنية التحتية السحابية.
يتم تحقيق التوازن في توزيع التحميل من خلال استخدام المحاكاة الافتراضية Openstack على الخوادم المزودة بوحدات معالجة مركزية قوية متعددة النواة. يتم تخصيص موارد المعالج الخاصة بها وأقراص محددة لعقد البيانات. في قرارنا محرك Atos Codex Data Lake تم تحقيق المحاكاة الافتراضية على نطاق واسع، ولهذا السبب نستفيد من حيث الأداء (يتم تقليل تأثير البنية التحتية للشبكة) ومن حيث التكلفة الإجمالية للملكية (يتم التخلص من الخوادم المادية الإضافية).
عند استخدام خوادم BullSequana S200، نحصل على حمل موحد للغاية، خاليًا من بعض الاختناقات. يتضمن الحد الأدنى من التكوين 3 خوادم BullSequana S200، كل منها يحتوي على اثنين من JBODs، بالإضافة إلى S200s الإضافية التي تحتوي على أربع عقد بيانات متصلة بشكل اختياري. فيما يلي مثال للحمل في اختبار TeraGen:
تُظهر الاختبارات ذات أحجام البيانات المختلفة وقيم النسخ المتماثل نفس النتائج من حيث توزيع التحميل بين عقد المجموعة. يوجد أدناه رسم بياني لتوزيع الوصول إلى القرص من خلال اختبارات الأداء.
تم إجراء الحسابات بناءً على الحد الأدنى من التكوين وهو 3 خوادم BullSequana S200. يتضمن 9 عقد بيانات و3 عقد رئيسية، بالإضافة إلى أجهزة افتراضية محجوزة في حالة نشر الحماية بناءً على OpenStack Virtualization. نتيجة اختبار TeraSort: حجم الكتلة 512 ميجابايت، معامل النسخ يساوي ثلاثة مع التشفير 23,1 دقيقة.
كيف يمكن توسيع النظام؟ هناك أنواع مختلفة من الملحقات المتوفرة لـ Data Lake Engine:
- عقد البيانات: لكل 40 تيرابايت من المساحة القابلة للاستخدام
- العقد التحليلية مع القدرة على تثبيت GPU
- خيارات أخرى حسب احتياجات العمل (على سبيل المثال، إذا كنت بحاجة إلى كافكا وما شابه)
يتضمن Atos Codex Data Lake Engine كلا من الخوادم نفسها والبرامج المثبتة مسبقًا، بما في ذلك مجموعة Cloudera المرخصة؛ Hadoop نفسها، OpenStack مع الأجهزة الافتراضية المستندة إلى RedHat Enterprise Linux kernel، ونسخ البيانات وأنظمة النسخ الاحتياطي (بما في ذلك استخدام عقدة النسخ الاحتياطي وCloudera BDR - النسخ الاحتياطي والتعافي من الكوارث). أصبح Atos Codex Data Lake Engine أول حل افتراضي يتم اعتماده .
إذا كنت مهتمًا بالتفاصيل، سنكون سعداء بالإجابة على أسئلتنا في التعليقات.
المصدر: www.habr.com