Post by Eng. Mohammed

أسعد الله أوقاتكم بكل خير ‏‏ Enterprise Data Engineering Techniques for Handling Late Arriving Events انقطاع 6 ساعات في شركة اتصالات يكشف حجم الخسائر التشغيلية. ما يريد قياسه فعليا هو: كيف تفكر عندما تفشل الأنظمة في العالم الحقيقي؟ - شركة اتصالات تخدم أكثر من 50 مليون مشترك. جميع سجلات المكالمات CDRs تتدفق لحظيا من الشبكة إلى منصة البيانات: Data Pipeline Platform 👈 في نهاية اليوم: - تم احتساب الفواتير - تم تحديث لوحات المتابعة - تم إرسال تقرير الإيرادات - تم إغلاق الDaily Partitions لكن بعد ساعتين تم اكتشاف Network Switches كان متوقفا لمدة 6 ساعات. وفجأة وصلت: 15 مليون مكالمة متأخرة. السؤال هنا ليس: كيف أقوم بإعادة تشغيل الPipeline؟ السؤال الحقيقي هو: كيف أصمم المنصة من البداية بحيث تتعامل مع هذا النوع من الفشل دون التأثير على Business؟ - لأن إعادة معالجة يوم كامل قد تعني: - ساعات من إعادة الحساب - استهلاك موارد هائل - تأخير التقارير - و غيرها من المشاكل هل الحل تشغيل ال Job او نجعل إعادة التشغيل غير ضرورية أساسا؟ 📌 التصميم المؤسسي الصحيح - الاعتماد على Event Time : 👉 وقت حدوث المكالمة أهم من وقت وصولها. قد تصل البيانات متأخرة 6 ساعات أو حتى يوم كامل، لكن يجب أن يتم احتسابها وفقا لوقت الحدث الحقيقي. - بناء Fact Tables غير قابلة للتعديل 👉 بدلا من تعديل السجلات القديمة: CALL_REVENUE = +50$ يتم إنشاء سجل تصحيحي: ADJUSTMENT = +50$ وبذلك نحافظ على تاريخ كامل لكل التغييرات. - استخدام Delta Corrections 👉 بدلا من إعادة حساب مليارات السجلات: Original Revenue = 100M$ Late Calls Revenue = +5M$ Adjusted Revenue = 105M$ تصحيح صغير بدل إعادة بناء ضخمة. - استخدم Idempotent Processing 👉 إذا وصلت نفس المكالمة مرتين بسبب إعادة الإرسال من المصدر: CALL_ID يصبح مفتاحا فريدا يمنع التكرار. - استخدم Watermarks 👉 في Apache Flink : يتم السماح بوصول البيانات المتأخرة ضمن نافذة زمنية محددة دون كسر الAggregations. - فهم Reconciliation Layer 👉 كل شركة كبيرة تمتلك طبقة مخصصة للإجابة عن سؤال واحد: هل الأرقام الموجودة في التقارير مطابقة للأرقام الموجودة في الأنظمة التشغيلية؟ هذه Layer هي اخر خط دفاع قبل وصول البيانات الخلاصة: - المشكلة ليست في البيانات المفقودة. - المشكلة ليست في البيانات المتأخرة. - المشكلة الحقيقية هي أن النظام تم تصميمه بافتراض أن كل شيء سيعمل دائما بشكل مثالي. والحقيقة أن: - الأنظمة تتعطل - الشبكات تتوقف - الأحداث تتأخر - الرسائل تتكرر - المصادر تفشل Data Engineering is not about moving data. It's about preserving trust in data when everything goes wrong. بالتوفيق دائما و ابدا 🌹 يمكنك الاطلاع علي البرنامج التدريبي الخاص بي في هندسة البيانات 📌للاطلاع علي Sample Preview قبل الاشتراك https://lnkd.in/dy6asjwU في حالة الاشتراك يمكنك التواصل مع الرقم لتكملة الإجراءات https://wa.me/201500029999 📌للاطلاع أيضا علي النسخة اللايف من تدريب هندسة البيانات Data Engineer 8 -Month 1:1 Coaching https://lnkd.in/dnP4JEU2 شير حتي يستفيد الجميع ❤️ Eng.Mohammed