تقنية

البيانات المتأخرة: متى تحتاج نتيجة الفترة إلى تحديث؟

عد مبدئي سبعة ثم سجل إضافي صحيح غير مكرر للفترة يؤدي إلى عدد محدث ثمانية
رسم أصلي يوضح تحديث النتيجة؛ مدة التحديث تحددها سياسة المسار.

البيانات المتأخرة قد تصل بعد أن أعددنا نتيجة للفترة التي وقع فيها الحدث. تعرض أمثلة Apache Beam أحداثا تصل خارج ترتيب وقوعها، ونتائج تحدث عند وصول بيانات متأخرة وفق إعدادات المعالجة. [1]

الخلاصة السريعة

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

  • قد يصل السجل خارج ترتيب وقوع الأحداث؛ وصوله لاحقا لا ينقل وقت الحدث تلقائيا إلى فترة لاحقة. [1]
  • في مثال إرجاع افتراضي، وصول سجل إضافي صحيح للفترة يغير عدها من سبعة إلى ثمانية، بشرط ألا يكون مكررا.
  • تستخدم Beam تقدير watermark لتقدم وصول البيانات؛ قد يكون تقديرا إرشاديا وتظل بيانات متأخرة ممكنة. [1]
  • وثق مدة القبول والتحديث وما يحدث بعد إغلاقه؛ قاعدة التأخير ليست إذنا بقبول كل سجل دون فحص.

بأي معنى يكون السجل متأخرا؟

يفصل مثال Beam بين وقت الحدث ووقت المعالجة، ويوضح أن أحداثا قد تصل متأخرة أو خارج ترتيبها. [1]

في مثال تعليمي لإعارة أدوات، ننشر عند 10:00 عد الإرجاعات التي وقعت قبل ذلك في فترة محددة. بعد النشر تصل رسالة عن إرجاع وقع 09:58. هي متأخرة عن موعد إعداد النتيجة الذي اخترناه، لكن وقت الحدث الموثق يخص الفترة السابقة. نكتب تعريف التأخر المستخدم بدلا من الاكتفاء بوصف «متأخر» دون مرجع.

كيف يتغير عدد مبدئي؟

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

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

ماذا يعني تقدير تقدم البيانات؟

يوضح Beam watermark لتقدير متى يمكن افتراض وصول بيانات النافذة بشكل معقول، ويذكر استخدام تقدير إرشادي، مع إعدادات تتعامل مع وصول لاحق. [1]

نشرح الفكرة هنا دون اقتراح أن كل مصدر يقدم الضمان نفسه. ظهور مؤشر تقدم لا يكفي وحده لكتابة «لم يعد أي سجل ممكنا». يحتاج تفسيره إلى معنى المؤشر وطريقة المصدر وإعدادات المسار. اخترنا مثال الإرجاع لتوضيح الفرق بين النتيجة المنشورة وما يصل بعدها؛ ليس نسخة من لعبة المصدر.

ما القاعدة التي نكتبها للمثال؟

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

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

المصادر ومتابعة القراءة

  1. Apache Beam: Mobile Gaming Example — event time, watermark and late data (يفتح في نافذة جديدة)beam.apache.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.