نقل Hadoop إلى السحابة: ضعف السعة التخزينية وتكاليف العمليات الأقل

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

كانت مبنى التكنولوجيا الأصلي لدينا مجموعة ضخمة من البيانات باستخدام CDH (كلوديرا ديستريبيوتد هادوب) في مركز بيانات داخلي. مع نمو أعمالنا، ازداد حجم البيانات بشكل كبير.

للتعامل مع تحديات مثل دورات توسع طويلة وموارد الحوسبة والتخزين غير المتناسبة وتكاليف الصيانة العالية، قررنا تحويل هيكل بياناتنا والانتقال إلى السحابة، مع التبني للنهج المنفصل بين التخزين والحوسبة. بعد تقييم دقيق، تبنينا أليبابا كلاود إلاستتيك الماب ريدو (EMR) + جويسفس + خدمة أليبابا كلاود تخزين الكائنات (OSS).

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

في هذا المقال، سنشارك تصميمنا لبنية التكنولوجيا لنقل Hadoop إلى السحابة، ولماذا اخترنا JuiceFS+EMR+OSS، وكيف حققنا فوائد من البنية الجديدة. نهدف إلى تقديم رؤى ثمينة لأولئك الذين يواجهون تحديات مماثلة من خلال هذا المنشور.

بنيتنا القديمة والتحديات

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

البنية الأصلية

الشكل التالي يوضح بنيتنا السابقة، التي تضمنت مجموعة كبيرة بنية تحتية مبنية على CDH وضعت في مركز بيانات:

• كانت المكونات الرئيسية تشمل Hive، Spark، وHDFS.
• تغذت عدة نظم إنتاج البيانات، حيث كانت Kafka واحدة منها، في المجموعة.
• استخدمنا حلول تخزين أخرى، مثل TiDB، HBase، وMySQL، إلى جانب Kafka.

Original architecture at Yimian

تدفقت البيانات من الأنظمة التطبيقية العلوية وأنظمة جمع البيانات، حيث كتبت إلى Kafka. استخدمنا مجموعة Kafka Connect ل sycn البيانات إلى HDFS.

على رأس هذه البنية، طورنا منصة تطوير بيانات مخصصة تسمى OneWork لإدارة المهام المختلفة. تم جدولة هذه المهام عبر Airflow ومعالجتها في طاولات مهام.

نقاط الألم

كانت التحديات التي واجهناها كالتالي:

• نمو سريع لبيانات التطبيق ودورات توسيع طويلة: مجموعتنا CDH المُنشأة في عام 2016، كانت تعالج تريليونات البايتات من البيانات بحلول عام 2021. ومع ذلك، كان نمو البيانات غالباً ما يتجاوز التخطيط الأجهزي، مما أدى إلى توسيع متكرر كل ستة أشهر. هذا استهلك موارد ووقت كبيرين.
• الترابط بين التخزين والحوسبة وصعوبة في تخطيط السعة: يجعل الترابط الوثيق بين التخزين والحوسبة في الهندوس للعمارة التقليدية من الصعب توسيع وتخطيط بشكل مستقل حسب احتياجات التخزين أو الحوسبة. على سبيل المثال، توسيع التخزين يتطلب أيضا شراء موارد حوسبة غير ضرورية. هذا أدى إلى توزيع غير فعال للموارد.
• خوف من ترقية إصدار CDH: كان إصدار CDH قديمًا، وترددنا في الترقية من أسباب الاستقرار والتوافق.
• تكاليف تشغيل مرتفعة: مع حوالي 200 موظف، كان لدينا موظف تشغيل كامل الوقت واحد فقط. هذا أدى إلى حجم عمل كبير. لتخفيف هذا، ابحثنا عن بنية أكثر استقرارًا وبساطة.
• نقطة فشل في مركز بيانات واحد: تبقى كل البيانات في مركز بيانات واحد يشكل خطرًا طويل الأمد. في حالة حدوث أضرار في الكابلات أو قضايا أخرى، وجود مركز بيانات واحد يخلق نقطة فشل.

متطلباتنا للبنية الجديدة

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

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

لماذا اخترنا JuiceFS+EMR+OSS

بعد تقييمنا للحلول المختلفة، اخترنا EMR+JuiceFS+OSS لبناء منصة بيانات كبيرة منفصلة بين التخزين والحساب ونقلنا تدريجيًا مركز البيانات المحلي إلى السحابة.

New architecture at Yimian

في هذا الإعداد، يحل التخزين الكائني محل HDFS، ويعمل JuiceFS كطبقة البروتوكول بفضل دعمه لبروتوكولات POSIX وHDFS. في القمة، نستخدم حل Hadoop يدار جزئيًا، EMR. ويشمل Hive، Impala، Spark، Presto/Trino، ومكونات أخرى.

سحابة أليباباو سحابات عامة أخرى

بعد تقييمنا الدقيق، اخترنا سحابة أليبابا على AWS و Azure بسبب العوامل التالية:

• الاقتربات: منطقة التوافر لشركة أليبا كلاود في نفس المدينة التي يوجد فيها مركز البيانات الخاص بنا يضمن تأخرًا منخفضًا وتكاليف شبكية أقل.
• مكونات مفتوحة المصدر شاملة: خدمة أليبا كلاود EMR توفر مجموعة واسعة من مكونات مفتوحة المصدر المتعلقة بـ Hadoop. بالإضافة إلى استخدامنا الثقيل لـ Hive، Impala، Spark، و Hue، فإنها توفر تكاملًا مضطربًا مع Presto، Hudi، Iceberg، وأكثر من ذلك. خلال بحثنا، اكتشفنا أن EMR هي الوحيدة التي تشمل Impala بشكل أصلي، بينما تقدم AWS و Azure إما إصدارات أقل أو تتطلب تثبيتًا ونشرًا يدويًا.

JuiceFS مقابل JindoFS

ما هو JuiceFS؟

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

يتبنى JuiceFS الهيكل المنفصل للبيانات والأوصاف الوصفية، مما يسمح بتصميم نظام ملفات موزع. عند استخدام JuiceFS لتخزين البيانات، تكون البيانات مُحفوظة في تخزين الكائنات مثل Amazon S3، بينما يمكن تخزين البيانات الوصفية على قواعد بيانات مثل Redis، MySQL، TiKV، SQLite، وغيرها.

بالإضافة إلى POSIX، يتوافق JuiceFS بالكامل مع واجهة برمجة التطبيقات لـ HDFS، مما يسمح باستبدال HDFS بسلاسة لفصل التخزين عن الحساب.

The JuiceFS architecture

لماذا اخترنا JuiceFS على JindoFS

اخترنا JuiceFS على JindoFS بناءً على التفكير التالي:

• تصميم التخزين: يتبع JuiceFS نظام تخزين منفصل للبيانات والبيانات الوصفية، مما يسمح بتصميم نظام جهاز التخزين الموزع. تُحتفظ البيانات في تخزين الكائنات، بينما يمكن تخزين البيانات الوصفية في قواعد بيانات مختلفة مثل Redis و MySQL و TiKV و SQLite، مما يوفر مرونة أكبر. على النقيض، تتم التخزين المكتسب لبيانات JindoFS على القرص الثابت المحلي لمجموعة EMR، مما يجعل الصيانة والترقيات والتحولات أقل مرونة.
• مرونة التخزين: يوفر JuiceFS حلول تخزين متنوعة، مع دعم التحويل عبر الإنترنت بين خطط مختلفة وزيادة القدرة على النقل. يدعم JindoFS بيانات الكتلة فقط OSS.
• دعم مجتمع المفتوح المصدر: يعتمد JuiceFS على مجتمع مفتوح المصدر، مع دعم لجميع بيئات السحابة العمومية. هذا يسهم في التوسع في المستقبل إلى هيكلية متعددة السحاب.

تصميم الهيكل الكامل

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

A hybrid cloud architecture

في مخطط الهيكل:

• في الأعلى هي Airflow و OneWork، وكلاهما يدعم التوزيع الجماعي، لذا يمكن توسيعها بسهولة.
• على اليسار هو IDC، الذي يستخدم الهيكل التقليدي لـ CDH وبعض مجموعات Kafka.
• على اليمين هو مجموعة EMR المنشأة على سحابة عليبا.

يرتبط IDC ومجموعة EMR بخط مخصص عالي السرعة.

كيف نستفيد من الهيكل الجديد

فوائد فصل التخزين والحوسبة

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

تغيرات الأداء

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

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

• الانتقال من HDFS إلى JuiceFS
• ترقيات إصدار المكونات
• التغييرات في محرك Hive
• التغيرات في حمل الخوادم

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

القابلية المستخدم والاستقرار

لم نواجه مشاكل مع JuiceFS.

أثناء استخدام EMR، واجهنا بعض المشاكل الصغيرة. بشكل عام، يعتبر CDH أكثر استقرارًا وسهولة في الاستخدام.

تعقيد التنفيذ

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

تؤثر عوامل متعددة على التعقيد:

• سيناريوهات التطبيق (خارج الخط/فوري، عدد الجداول/المهام، التطبيقات العليا)
• إصدارات المكونات
• الأدوات الداعمة والاحتياطات

خطط المستقبل

تشمل خططنا المستقبلية:

• استمرار نقل باقي التطبيقات إلى الشبكة السحابية.
• استكشاف استراتيجية تخزين البارد/الساخن باستخدام JuiceFS+OSS. تتم تفكيك ملفات JuiceFS بالكامل على OSS، مما يجعل من الصعب تنفيذ تخزين متعدد المستويات على مستوى الملف. تتضمن نهجنا الحالي نقل البيانات الباردة من JuiceFS إلى OSS، وتحديدها كتخزين محفوظات، وتعديل موقع جداول Hive أو القسم بدون تأثير على الاستخدام.
• إذا زاد حجم البيانات وكان هناك ضغط على استخدام Redis، قد ننظر في المستقبل إلى تبديل إلى TiKV أو محركات أخرى.
• استكشاف حالات الحساب المرنة في EMR للحد من تكاليف الاستخدام بينما تلبي اتفاقيات مستوى الخدمة للتطبيقات.