משך: 2.5 שעות אקדמיות (113 דקות).

מטרת השיעור: הסטודנטים יבינו Tumbling/Sliding Windows לפי זמן, ויטפלו ב-Late Events עם Watermark.

בסוף השיעור הסטודנטים צריכים: להסביר את ההבדל בין Event Time ל-Processing Time, ליישם Tumbling Window עם Pandas, ולהגדיר Watermark סביר לתרחיש נתון.

דגש קריטי: ההבדל Event Time מול Processing Time הוא שורש כל הנושא — ודאו שהוא מובן היטב לפני שעוברים ל-Watermarks.


מהלך השיעור

חלק בשיעורמשךהערות ודגשים
פתיחה וחיבור5 דקותהזכירו deque(maxlen) מהפרויקט הקודם — “לפי כמות, לא זמן”
הבעיה: חלון לפי זמן דורש גישה אחרת15 דקות“כמה אירועים בכל דקה”
Tumbling Window20 דקותחלונות קבועים, groupby+floor
Sliding Window (זמן)15 דקותחופף, השוואה ל-Tumbling
Event Time מול Processing Time15 דקותשורש בעיית Late Events
Late Events + Watermark25 דקותפשרה מודעת, קישרו ל-TTL
תרגול מודרך18 דקותתרגיל 1+2

דגשים להעברת השיעור

  • הבדילו בבירור מ-deque(maxlen) מהפרויקט הקודם — שם זה היה “N אחרונים לפי כמות”, כאן זה “לפי זמן” — שני מושגים שונים שנשמעים דומים.
  • Event Time מול Processing Time דורש דוגמה קונקרטית מרשת לא-אמינה (הודעה שנשלחה ב-10:00 אבל הגיעה ב-10:00:05 עקב עומס) — לא רק הגדרה מופשטת.
  • קשרו Watermark ל-TTL על Redis מיחידה קודמת — אותו סוג החלטה: “פשרה סבירה, לא דיוק מוחלט”.

מושגים

Tumbling Window — חלונות קבועים, לא-חופפים. Sliding Window (זמן) — חלון נע, יכול לחפוף. Late Event — אירוע שמגיע אחרי סגירת החלון שלו. Watermark — גבול זמן סביר לסגירת חלון.


תרגיל חשיבה

שאלת פתיחה: “אם Watermark שלכם קצר מדי (למשל 1 שנייה), מה קורה עם הרבה Late Events שנדחים? ואם הוא ארוך מדי (למשל שעה)?”

מהלך: הובילו לתובנה על שני קצוות הפשרה: Watermark קצר מדי = הרבה אירועים אמיתיים נדחים בטעות (רשת קצת איטית = כבר “מאוחר מדי”); Watermark ארוך מדי = חלונות “נשארים פתוחים” זמן רב, מעכבים דוחות ותובנות בזמן-אמת. אין תשובה “נכונה” גלובלית — תלוי בטבע התעבורה והדרישה העסקית.

מה המרצה מראה בסוף: הריצו סימולציה עם כמה אירועים “מאוחרים” בדרגות שונות (שנייה אחת, 30 שניות, 5 דקות באיחור) מול Watermark של 30 שניות — הראו אילו מתקבלים ואילו נדחים, ואיך זה משתנה אם ה-Watermark משתנה ל-5 דקות.