قياس الإعلانات يفقد أحداثًا عند الذروة: الوصلات والمفاتيح المكررة والربط مع المزايد

خط أحداث يفقد أحداثًا عند ذروة الحركة ولا يتطابق أبدًا مع سجلات المزايد قد يكون عطلين خلف عرَض واحد. الأول نقل: أحداث أُنشئت ولم تصل قط، عند وصلة لم يعدّها أحد. والثاني تعريفي: أحداث وصلت وعُدّت بقاعدة تختلف عن قاعدة سجل المزاد.

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

استعلام واحد يميّز الحدث المفقود من الحدث المتأخر

العطل الأول هو الفقد: أُنشئ الحدث ولم يصل قط، عند قفزة محددة ولسبب محدد. beacon لم يغادر الصفحة، وحافة أُعيد تشغيلها في منتصف النشر، وbuffer منتج امتلأ، ومستهلك ثبّت الـ offset قبل المعالجة.

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

• أعد تشغيل نافذة زمن الحدث نفسها بعد ساعة وست ساعات ويوم كامل من الوقت الذي تغطيه
• العجز الذي يتقلّص مع كل تشغيل يعني أن الأحداث تأخرت ولم تُفقد، وأن النقل سليم
• عُدّ مفاتيح إزالة التكرار المتمايزة لا الصفوف: نقل at-least-once يضمن إعادة التسليم، والمنحنى المبني على الصفوف يخفي عدًّا زائدًا
• العجز الذي يبقى ثابتًا يعني أن الأحداث ضاعت، والسؤال عند أي وصلة
• يحتاج الاختبار إلى طابع زمني لزمن الحدث، ومعرّف يصمد أمام إعادات المحاولة، ونافذة احتفاظ طويلة بما يكفي لإعادة تشغيل النافذة
• انشر منحنى الاستقرار كرسم بياني، لكل نوع حدث، بجانب الرقم الذي يفسّره

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

الأحداث تضيع عند وصلات لها أسماء، والوصلة غير المعدودة لا يمكن أن تُلام

هناك سبعة مواضع يُنشأ فيها حدث إعلاني ثم يكفّ عن الوجود بصمت، إضافة إلى إعداد واحد يبدو ضمانة وليس كذلك.

• الجمع على جانب العميل: الـ beacon ينطلق لكن المستند يُفرَّغ قبله، أو أن المادة الإعلانية كانت مخزّنة مؤقتًا أو مجلوبة مسبقًا أو محدَّثة تلقائيًا فتعدّ ما لا يعدّه سجل المزاد
• الاستقبال عند الحافة: حدود الاتصالات، ونفاد keep-alive، وإعادات التشغيل أثناء النشر، والصيغة الخطرة - إرجاع نجاح قبل أن يصير الحدث متينًا
• buffer المنتج: العميل يُحجب زمنًا محدودًا ثم يرفع خطأ، والكود الذي يلتقط الخطأ ولا يعدّ شيئًا هو حيث تموت البيانات
• متانة الـ broker: بلا إقرار مطلوب لا شيء يضمن وصول السجل؛ ومع الـ leader وحده يضيع السجل إذا سقط ذلك الـ leader قبل أن ينسخه الـ followers
• الإقرار من كل النسخ ليس متانة: فهو ينتظر مجموعة in-sync الحالية، التي يبلغ حدها الأدنى الافتراضي واحدًا، فذروة تدفع الـ followers إلى التأخر تُثبِّت على الـ leader وحده
• المستهلك: تثبيت الـ offset قبل المعالجة هو at-most-once، وهو إعداد افتراضي لا قرار - فالعميل يثبّت على مؤقّت ما لم يُطفأ ذلك
• تجاوز نافذة الاحتفاظ: المستهلك الذي يتأخر إلى ما وراء نافذة الاحتفاظ يجد الـ offset التالي محذوفًا، وسياسة إعادة الضبط الافتراضية تقفز به إلى رأس الـ log
• التحميل إلى المخزن العمودي: إدراجات fire-and-forget تقرّ بمجرد التخزين المؤقت، والـ materialised views التابعة تزيل التكرار عبر إعداد منفصل - وهنا يفترق الجدول الخام عن التقرير

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

إزالة التكرار تحتاج مفتاحًا موجودًا قبل أول إعادة محاولة

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

• المنتج الـ idempotent يزيل التكرارات الناتجة عن إعادات محاولة المنتج داخل جلسة واحدة، وKafka يفعّله افتراضيًا منذ 3.0 إلى جانب الإقرار من كل النسخ
• ذلك الإعداد الافتراضي مشروط: إعداد متعارض من تهيئة أقدم يعطّل الـ idempotence بصمت، فاسأل العملية العاملة عمّا لديها
• لا يرى تكرارًا على مستوى التطبيق: عملية انهارت ثم أعادت الإرسال، أو beacon انطلق مرتين، أو مشغّل أعاد تشغيل مهمة استقبال
• إزالة تكرار الإدراج في ClickHouse تحسب هاش محتوى الكتلة، فالمستهلك الذي يعيد تجميع الدفعات بعد إعادة توازن يرسل الصفوف نفسها بشكل جديد فيخطئ الهاش
• النافذة محدودة بالكتل وبالزمن، وعلى الجداول غير المنسوخة قيمتها الافتراضية صفر، أي مطفأة؛ ورمز إدراج يزيل ذلك الاعتماد
• exactly-once داخل الـ log يغطي consume-transform-produce، والقفزة إلى قاعدة بيانات تحليلية تقع خارج ذلك الحد مهما وعد النقل

فالشكل العملي هو نقل at-least-once بمفاتيح idempotent. إزالة التكرار وقت الكتابة تبقي فاتورة التخزين معقولة؛ وإزالة التكرار وقت القراءة هي ما يجعل الرقم صحيحًا. والدمج لا يجمع أبدًا أجزاءً من أقسام مختلفة، فالتكرار الذي يهبط في القسم التالي لا يُحلّ إلا حين يسأل استعلام.

الـ back pressure يقرر إن كان الفقد رقمًا أم إشاعة

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

• طوابير محدودة عند كل قفزة، مع رفض صريح بدل النمو. فالطابور غير المحدود ينقل الفقد إلى ضغط الذاكرة وإعادة تشغيل
• زمن حجب المنتج وحجم الـ buffer قراران يخصان السعة: حدّدهما من الذروة التي قِستها، وأنذر على الزمن المقضي في الحجب
• أسقِط حسب الفئة لا عشوائيًا: أحداث الظهور والأحداث القابلة للفوترة تبقى، والتشخيصات تذهب أولًا، وكل حدث مُسقَط يزيد عدّادًا موسومًا
• تأخّر المستهلك هو back pressure مرئي. أنذر على عمر أقدم حدث غير معالج وعلى سرعة تغيّر التأخر

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

الوصول المتأخر بنيوي، ونصف عدم التطابق تقويم

يقول إرشاد تنفيذ OpenRTB ذلك مباشرة: التسلسل من طلب الإعلان مرورًا بالمزاد وصولًا إلى العرض والفوترة ليس معاملاتيًا في جوهره. فأطراف كثيرة تقف بين العدّين.

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

لا أحد من الحقلين عقد. يقول الإرشاد صراحة إن إشعار فوترة يصل بعد مدة الصلاحية التي أعلنها المزايد قد يظل قابلًا للفوترة - وهو نقاش سياسات بين المزايد ومنصة التبادل لا شيء يفرضه البروتوكول.

• لكل حدث ثلاثة طوابع زمنية وواحد فقط يقود النافذة: ساعة الجهاز، وهي غير موثوقة؛ وزمن الاستلام عند الحافة، وهو متأخر؛ وزمن المزاد، وهو المرجع
• وثمة رابع حيث توفّره منصة التبادل، وهو الماكرو الذي يحمل لحظة تحقّق الظهور؛ وحيث يغيب تفترض المواصفة أن الإشعار تبعه بثوانٍ
• الـ watermark يعلن أن زمن الحدث بلغ نقطة معينة وأنه لا يُتوقع وصول عناصر أقدم، فيكون التأخر المسموح به معاملًا تختاره أنت
• انشر نافذة التأخر لكل نوع حدث مع سياسة إعادة بيان الأرقام: تتحرك الأرقام ما دامت مفتوحة ثم تتجمد، وتُسجَّل التحركات
• عُدّ الحدث المتأخر وضع عليه علامة تأخر، لأن إسقاطه إسقاط لإنفاق فُوترت عليه

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

المطابقة تربط على المعرّفات التي يحملها البروتوكول أصلًا

المعرّفات التي تستبدلها منصة التبادل في روابط الإشعار والتتبع هي معرّف المزاد من طلب المزايدة، ومعرّف الظهور، ومعرّف المزايدة حيث أنشأه المزايد. ولا واحد من الثلاثة مفتاح بمفرده.

تصف المواصفة معرّف المزاد بأنه فريد على مستوى منصة التبادل لا فريد عالميًا: منصتا تبادل قد تسلّمانك السلسلة نفسها في اليوم نفسه. ومعرّف الظهور فريد داخل طلب المزايدة الخاص به فقط، وكثيرًا ما يكون 1 حرفيًا. ومعرّف المزايدة اختياري.

المفتاح الذي يصمد مركّب: منصة التبادل أو الـ seat الذي تعاملت عبره، زائد معرّف المزاد، زائد معرّف الظهور. أنشئه في جانب المزايد وقت المزاد، وعامل أي شيء أقصر منه كبادئة لا كمفتاح.

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

• المزادات الفائزة، من سجل المزايد - العدّ الوحيد الذي يخصك بالكامل
• إشعارات الفوز التي استلمتها منصة التبادل - الفرق هو فقد الإشعارات وانتهاء المهل، وبحسب المواصفة لا يعني إشعار الفوز بالضرورة أن التسليم حدث
• الـ beacons المستلمة عند حافتك - الفرق هو الجمع على جانب العميل وكل وصلة فوقه
• الأحداث بعد إزالة التكرار - الفرق هو إعادات المحاولة، ويجب أن يكون مستقرًا من أسبوع لآخر
• الأحداث بعد ترشيح الحركة غير الصالحة - الفرق هو معدل ترشيح تنشره أنت لا تكتشفه لاحقًا
• الأحداث القابلة للفوترة - الفرق هو قاعدة الفوترة، والإشعار مكانه جانب الخادم، حيث تقيّد منصة التبادل الإيراد

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

ما لا يمنحك إياه خط أحداث معاد بناؤه

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

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

• لا يجعل العدّين متساويين: كل جانب يعدّ أحداثًا مختلفة عن قصد، والفرق يُشرح ولا يُزال أبدًا
• لا يستعيد أحداثًا أُسقطت قبل وجود أدوات القياس - منحنى الاستقرار يبدأ يوم تبدأ العدّادات
• لا يلغي إعادة بيان الأرقام: يتحرك رقم الأمس ما دامت نافذة التأخر مفتوحة، والعمل الذي لا يحتمل ذلك يحتاج إغلاقًا أكثر تأخرًا
• لا يصمد أمام غياب الماكروات: بلا معرّفات المزاد في الـ beacons لا ينتج أي تصميم تخزين ربطًا على مستوى الحدث
• لا يجعل البيانات المُعايَنة قابلة للربط لاحقًا، لأن أخذ العينات يقرر أي الأسئلة تبقى قابلة للإجابة قبل أن يُكتب الصف
• لا يحل محل قائمة الإفصاح التي يتوقعها تدقيق على طريقة MRC: نقطة الالتقاط، وتواتر التسجيل، وتقديرات زمن الاستجابة، وقواعد التعامل مع التناقضات

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

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

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