إعادة ابتكار نهج Sprout Social للبيانات الضخمة

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

نظرًا لأننا نقوم بتخزين إصدارات متعددة من الرسائل ، يتم تكليف مهندسي Sprout بـ "إعادة إنشاء العالم" عدة مرات في اليوم - وهي عملية أساسية تتطلب التكرار عبر مجموعة البيانات بأكملها لدمج كل جزء من رسالة اجتماعية في "مصدر حقيقة" واحد.

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

مفاتيح نهج البيانات الضخمة الخاص بـ Sprout

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

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

للمساعدة في تقليل مقدار الوقت الذي يأتي من إدارة هذه الأنظمة بمئات تيرابايت من البيانات ، اجتمعت فرق التطوير والبنية التحتية في Sprout لإيجاد حل أفضل من تشغيل مجموعات Hadoop ذاتية الإدارة. كانت أهدافنا هي:

• اسمح لمهندسي Sprout بإنشاء مجموعات بيانات كبيرة وإدارتها وتشغيلها بشكل أفضل
• تقليل الوقت المستغرق من المهندسين لامتلاك النظام وصيانته يدويًا
• خفض التكاليف غير الضرورية للتوفير المفرط بسبب توسع المجموعة
• توفير أساليب وموثوقية أفضل للتعافي من الكوارث

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

تقييم بدائل أنماط البيانات الجديدة

أحد الحلول التي أخذتها فرقنا بعين الاعتبار كانت مستودعات البيانات. تعمل مستودعات البيانات كمخزن مركزي لتحليل البيانات وتجميعها ، ولكنها تشبه إلى حد كبير قواعد البيانات العلائقية التقليدية مقارنة بـ Hbase. يتم تنظيم بياناتهم وتصفيتها ولها نموذج بيانات صارم (أي وجود صف واحد لكائن واحد).

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

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

تقليل النفقات العامة والصيانة باستخدام AWS EMR

بالنظر إلى ما تعلمناه عن تخزين البيانات وحلول البحيرة ، بدأنا في البحث عن أدوات بديلة تعمل على إدارة Hbase. بينما قررنا أن استخدامنا الحالي لـ Hbase كان فعالًا لما نقوم به في Sprout ، سألنا أنفسنا: "كيف يمكننا تشغيل Hbase بشكل أفضل لخفض العبء التشغيلي مع الحفاظ على أنماط الاستخدام الرئيسية لدينا؟"

كان هذا عندما بدأنا في تقييم خدمة Amazon Elastic Map Reduce (EMR) المُدارة لـ Hbase. تطلب تقييم السجلات الطبية الإلكترونية (EMR) تقييم أدائها بنفس الطريقة التي اختبرنا بها مستودعات البيانات ومستودعات البحيرات ، مثل اختبار استيعاب البيانات لمعرفة ما إذا كان بإمكانها تلبية متطلبات الأداء الخاصة بنا. كان علينا أيضًا اختبار تخزين البيانات والتوافر العالي والتعافي من الكوارث للتأكد من أن السجلات الطبية الإلكترونية تناسب احتياجاتنا من منظور البنية التحتية / الإدارة.

حسنت ميزات EMR حلنا الحالي المدار ذاتيًا ومكنتنا من إعادة استخدام أنماطنا الحالية للقراءة والكتابة وتشغيل الوظائف بنفس الطريقة التي فعلنا بها مع Hbase. واحدة من أكبر فوائد EMR هي استخدام نظام ملفات EMR (EMRFS) ، الذي يخزن البيانات في S3 بدلاً من العقد نفسها.

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

تم اختبار عملية الترحيل بسهولة مسبقًا وتنفيذها لترحيل مليارات السجلات إلى مجموعات السجلات الطبية الإلكترونية الجديدة دون أي توقف للعملاء. أظهرت المجموعات الجديدة أداءً محسنًا وخفض التكاليف بنسبة 40٪ تقريبًا. لقراءة المزيد حول كيف ساعد الانتقال إلى EMR في تقليل تكاليف البنية التحتية وتحسين أدائنا ، تحقق من دراسة الحالة الخاصة بـ Sprout Social مع AWS.

ما تعلمناه

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

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