مسئله: میلیونها کلیک/نمایش تبلیغ در روز؛ باید هر دقیقه بدانی هر کمپین چقدر خرج کرده تا سقف بودجه را enforce کنی، و فردا گزارش دقیق مالی بدهی. دو نیاز ناسازگار: سرعتِ لحظهای و دقتِ حسابداری.
۱-۲) نیازمندی و تخمین
- FR: ثبت نمایش/کلیک، شمارش per کمپین در پنجره دقیقه/روز، توقف کمپین در اتمام بودجه، گزارش مالی دقیق.
- NFR: حجم رویداد وحشتناک (100K+/s در پیک)، تأخیر enforce بودجه <1min ،دقت گزارش = ۱۰۰٪ (پول است)، حذف کلیک تکراری/ربات.
- تخمین: 100K رویداد/s با میانگین 200B ≈ 20MB/s ورودی — سیستم باید هم جریان را هضم کند هم دسته پایانی را.
۳) طراحی — دو مسیر، یک حقیقت
DIAGRAMمعماری Lambda
Ad Server
→
Kafka — رویداد خام
→
Stream — شمارش لحظهای → KV
→
Batch — پردازش دقیق شبانه
→
OLAP — گزارش مالی
- مسیر سریع: Flink/Spark Streaming رویدادها را در پنجرههای زمانی (window) تجمیع و در Redis/KV بهروز میکند — ad server قبل از نمایش، سقف بودجه را از همین KV میخواند (تأخیر ثانیهای قابل قبول، صفر نه).
- مسیر دقیق: رویدادهای خام در دریاچه (S3/Parquet) فرود میآیند و پردازش دستهای شبانه، اعداد نهایی حسابداری را در OLAP (فصل ۱۲) میسازد — اگر جریان چیزی را جا انداخته بود، دسته اصلاحش میکند (Lambda architecture).
- Exactly-once در تجمیع: رویداد با id یکتا + پردازش idempotent (فصل ۴) تا retry ،کلیک را دوبار نشناسد؛ Kafka transactions (درس ۴۲) همینجا کاربرد دارند.
- حذف تقلب: فیلتر ربات و dedup بر اساس (user ،ad ،window) قبل از شمارش مالی — هر کلیک جعلی، پولِ واقعی است.
۴) عمق و گلوگاه
- Watermaking: رویدادها دیر میرسند (موبایل آفلاین)؛ پنجره باید بفهمد «چقدر صبر کنم برای دیررسها» — trade-off تأخیر در برابر کاملبودن.
- Starvation کمپینهای کوچک: تجمیعگر درشتگرا کمپین کوچک را قورت میدهد — دقت پنجره را با قانون کسبوکار تنظیم کن.
- Hot key: کمپین وایرال یک کلید را میسوزاند — شارد شمارنده (counter splitting) و جمع هنگام خواندن.
به زبان ساده
تجمیع کلیک تبلیغات دو مسیر دارد: شمارش لحظهای تقریبی برای «بستن کمپین پر شده» و پردازش دقیق شبانه برای فاکتور پول — و هیچ کلیکی نباید دوبار شمرده شود.
مثال واقعی
مثل صندوق رأی و شمارش نهایی: نتایج زنده (خبرگزاری) سریع و تقریبی است؛ آنچه مهر و ثبت میشود، شمارش دقیق کاغذی فرداست.