بناء أرشيف ويب بحجم بيتابايت

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

عادةً، تضحي بإحداهما من أجل الأخرى. لكن في حالتنا، عند العمل مع بيتابايت من البيانات في AWS، لم تؤثر هذه المفاضلة على سرعتنا - بل أثرت على المحفظة.

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

هذه قصة كيف قمنا بتحسينه لجعله أكثر كفاءة وفعالية من حيث التكلفة!

الجزء 0: كيف انتهى بنا المطاف بإنفاق 100,000 دولار في رسوم AWS!

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

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

انتهى هذا الخطأ الصادق بتكلفتنا ما يقرب من 100,000 دولار في رسوم AWS!

الآن، قمت بإصلاح خطأ واجهة برمجة التطبيقات على الفور (وأضفت حدودًا صارمة)، لكن نقطة الضعف المعمارية ظلت قائمة. كانت قنبلة موقوتة...

دعني أخبرك قصة بنية أرشيف الويب من Bright Data: كيف قدت النظام إلى فخ التخزين "الرخيص" وكيف خرجت منه باستخدام خط أنابيب إعادة الترتيب.

الجزء 1: إرث "الكتابة أولاً"

عندما بدأت العمل على أرشيف الويب، كان النظام يستوعب بالفعل تدفقًا هائلاً من البيانات: ملايين الطلبات في الدقيقة، وعشرات التيرابايت يوميًا. تم بناء البنية الأساسية بهدف أساسي: التقاط كل شيء دون فقدان البيانات.

اعتمد على الاستراتيجية الأكثر متانة لأنظمة الإنتاجية العالية: سجل الإضافة فقط.

1. يتم تخزين البيانات (HTML، JSON) مؤقتًا.
2. بمجرد وصول المخزن المؤقت إلى ~300 ميجابايت، يتم "إغلاقه" في أرشيف TAR.
3. ينتقل الأرشيف إلى S3.
4. بعد 3 أيام، تنتقل الملفات إلى S3 Glacier Deep Archive.

بالنسبة لمرحلة الاستيعاب، كان هذا التصميم مثاليًا. تخزين البيانات في Deep Archive يكلف بنسات، وإنتاجية الكتابة غير محدودة تقريبًا.

المشكلة: تلك الدقة في التسعير

عملت البنية المعمارية بشكل مثالي للكتابة... حتى جاء العملاء يطلبون البيانات التاريخية. هنا واجهت تناقضًا أساسيًا:

• النظام يكتب حسب الوقت: يحتوي أرشيف من الساعة 12:00 ظهرًا على مزيج من cnn.com، وgoogle.com، وshop.xyz.
• النظام يقرأ حسب المجال: يسأل العميل: "أعطني جميع الصفحات من cnn.com للعام الماضي."

هنا يكمن الخطأ الذي ألهم هذه المقالة. مثل العديد من المهندسين، اعتدت على التفكير في زمن الاستجابة، والعمليات في الثانية، والإنتاجية. لكنني أغفلت نموذج فواتير AWS Glacier.

اعتقدت: "حسنًا، استرجاع بضعة آلاف من الأرشيفات بطيء (48 ساعة)، لكنه ليس مكلفًا للغاية."

الواقع: لا تفرض AWS رسومًا على مكالمة واجهة برمجة التطبيقات فحسب، بل أيضًا على حجم البيانات المستعادة ($ لكل جيجابايت مسترجع).

تأثير "البايت الذهبي"

تخيل أن عميلاً يطلب 1,000 صفحة من مجال واحد. نظرًا لأن منطق الكتابة كان زمنيًا، يمكن أن تنتشر هذه الصفحات عبر 1,000 أرشيف TAR مختلف.

لإعطاء العميل هذه البيانات المفيدة البالغة 50 ميجابايت، تحدث كارثة:

1. يجب على النظام تشغيل استعادة لـ 1,000 أرشيف.
2. يرفع 300 جيجابايت من البيانات من "المجمد" (1,000 أرشيف × 300 ميجابايت).
3. تفرض AWS علينا رسومًا لاستعادة 300 جيجابايت.
4. أستخرج الـ 50 ميجابايت المطلوبة وأتخلص من الـ 299.95 جيجابايت الأخرى 🤯.

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

الجزء 2: إصلاح الخطأ: خط أنابيب إعادة الترتيب

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

لذلك، صممت خط أنابيب إعادة الترتيب، وهي عملية خلفية "تزيل تجزئة" الأرشيف.

هذه عملية ETL (استخراج، تحويل، تحميل) غير متزامنة، مع عدة مكونات أساسية حاسمة:

1. الاختيار: لا معنى لفرز البيانات التي لا يطلبها العملاء. وبالتالي، أوجه جميع البيانات الجديدة إلى خط الأنابيب، وكذلك البيانات التي طلب العملاء تحديدًا استعادتها. ندفع أكثر من اللازم للاسترداد في المرة الأولى، لكن هذا لا يحدث مرة ثانية.

   \

2. التبديل (التجميع): يقوم عدة عمال بتنزيل الملفات غير المرتبة بالتوازي وتنظيم المخازن المؤقتة حسب المجال. نظرًا لأن النظام غير متزامن، فأنا لا أقلق بشأن تحميل التدفق الوارد على الذاكرة. يتعامل العمال مع الحمل بوتيرتهم الخاصة.

   \

3. إعادة الكتابة: أكتب الملفات المرتبة مرة أخرى إلى S3 تحت بادئة جديدة (للتمييز بين الملفات المرتبة والملفات الخام).

• قبل: 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• بعد: 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. تبديل البيانات الوصفية: في Snowflake، جدول البيانات الوصفية هو للإضافة فقط. إجراء MERGE INTO أو UPDATE مكلف للغاية.

• الحل: وجدت أنه من الأكثر كفاءة أخذ جميع السجلات ليوم معين، وكتابتها إلى جدول منفصل باستخدام JOIN، وحذف سجلات اليوم الأصلية، وإدراج اليوم بأكمله مرة أخرى مع السجلات المعدلة. تمكنت من معالجة أكثر من 300 يوم وأكثر من 160 مليار عملية تحديث في بضع ساعات فقط على مستودع Snowflake بحجم 4X-Large.

النتيجة

غير هذا التغيير اقتصاديات المنتج بشكل جذري:

• دقة محددة: الآن، عندما يطلب عميل cnn.com، يستعيد النظام فقط البيانات حيث يوجد cnn.com.
• الكفاءة: اعتمادًا على تفاصيل الطلب (المجال بأكمله مقابل عناوين URL محددة عبر regex)، حققت تخفيضًا بنسبة 10% إلى 80% في استرجاع "البيانات غير المرغوب فيها" (وهو ما يتناسب مباشرة مع التكلفة).
• قدرات جديدة: بعيدًا عن مجرد توفير المال على عمليات التفريغ، فتح هذا حالات استخدام تجارية جديدة تمامًا. نظرًا لأن استرجاع البيانات التاريخية لم يعد مكلفًا بشكل مؤلم، يمكننا الآن تحمل تكلفة استخراج مجموعات بيانات ضخمة لـ تدريب نماذج الذكاء الاصطناعي، وإجراء أبحاث سوق طويلة الأمد، وبناء قواعد معرفية لأنظمة الذكاء الاصطناعي للتفكير فيها (فكر في محركات البحث المتخصصة). ما كان سابقًا مهمة انتحارية مالية أصبح الآن عملية قياسية.

نحن نوظف

تقوم Bright Data بتوسيع نطاق أرشيف الويب أكثر. إذا كنت تستمتع بـ:

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

فأنا أود التحدث معك.

نحن نوظف مهندسي Node.js أقوياء للمساعدة في بناء الجيل التالي من أرشيف الويب. وجود خبرة في هندسة البيانات و ETL يعد ميزة كبيرة. لا تتردد في إرسال سيرتك الذاتية إلى [email protected].

المزيد من التحديثات قادمة مع استمراري في توسيع نطاق الأرشيف - ومع استمراري في إيجاد طرق جديدة ومبتكرة لكسره!

\