הזרמה

מהו הזרמה

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

מושגי מפתח

אירוע הוא עובדה בלתי ניתנת לשינוי עם "event _ time" ו- "event _ id' ייחודי.
זמן אירוע נגד זמן עיבוד - הראשון מגיע מהמקור, השני - כאשר המפעיל למעשה ראה את האירוע.

• מגששים, מקפצים/גולשים, הפעלה.
• סימני מים - הערכה כי ”אירועים לפני T כבר הגיעו”, המאפשר לך לסגור חלונות ולהגביל את ההמתנה לנתונים מאוחרים.
• איחור - אירועים עם ”event _ time” פחות מסימן המים הנוכחי; כללי סיום מיושמים לעתים קרובות.
• מדינה - טבלאות מקומיות/מצב מתוח עבור צבירים, מצטרפים, שכפול.
• תרמיל גב - לחץ כאשר מפזרים את הזרם במורד הזרם; נשלט על ידי פרוטוקול וחוצץ.

בסיס ארכיטקטוני

1. מקור: מתווך אירועים (Kafka/NATS/Pulsar), CDC מ DB, תורים, קבצים/אספני רישומים.
2. מנוע הזרמה: מחשב חלונות, אגרגטים, שמחות, תבניות (CEP), מנהל את המצב ואת נקודות הביקורת.
3. SINK: מסד נתונים OLTP/OLAP, מנוע חיפוש, מטמון, נושאים, חנויות לבסיסי תצוגה/דיווחים.
4. רישום סכימה: שליטה אבולוציה מטען ותאימות.
5. יכולת תצפית: מדדים, איתור, רישומים, לוחות מחוונים של פיגור וסימני מים.

זמן סמנטיקה וסדר

תמיד מעדיפים את זמן האירוע: זו ההמלצה היחידה לעיכובים ולהפרעות.
אירועים יכולים לבוא מתוך סדר; הסדר מובטח רק בתוך מפתח המפלגה.

• לסגור חלונות ולפלוט תוצאות;
• להגביל ”כמה אנחנו מחכים ל” אירועים מאוחרים (”מותר _ איחור”).
• לאירועים מאוחרים, השתמש במחדלים/מצוקות: חישוב מחדש של צבירה ואירועים מתקנים.

מצב ואמינות

מצב מתוח: נתונים של אגרגטים (סכומים, דלפקים, מבנים להכפלה) נדחקים על ידי מפתחות.
Checkpoint/Savepoint - תמונות מצב תקופתיות להחלמה; Savepoint - תצלום מנוהל עבור נדידת גירסאות קוד.

• transactional ”לקרוא-מעובד-לכתוב” (להתחייב תנוחת skik + לקרוא);
• כיורים אידמפוטנטיים (upsert/merge) + שולחנות שכפול;
• על ידי הצגת אגרגטים אופטימיים (curncy).

חלונות, צבירה, להצטרף

• דוחות תקופתיים פשוטים (דקה, שעה).
• קפיצה/גלישה: ”גלישה” מדדים (תוך 5 דקות במרווחים של 1 דקות).
• פגישה: טבעי למפגשים מותאמים אישית ואנטי הונאה.
• Aggregations: sum/count/avg/axhlox-different (HyperLoglog), secondenties (TDiegent/CKMS).
• מצטרף זרם זרם: דורש חציצה שני הצדדים על ידי מפתח וזמן, כבוד 'allowed _ skew'.
• מצטרף זרם-טבלה (KTable) - מצרף תיקייה או מצב נוכחי (לדוגמה, ”מגבלות משתמש פעיל”).

עבודה עם נתונים lagfliclated

Dauplication: by 'event _ id' or' (producer_id, sequence); לאחסן את מפתחות ”נראה” עם TTL - חלון מחדש.
אירועים מאוחרים: אפשר חלונות לאחר עיבוד של X לאחר הסגירה (retractions/upserts).
כפילויות כוזבות: לכוון את האגרגטים בצורה אידמפוטית ולתקן את ה ”ALREADY_APPLIED” ביומנים.

סולם וביצועים

קישוט מפתח: מספק מקביליות; שימי לב למפתחות חמים.
Backpressure: להגביל מקביליות, להשתמש צרור ודחיסה בעת פרסום.
סימני מים: אל תהיו אגרסיביים מדי - סימני מים קשים מפחיתים את הציפייה, אלא מגבירים את שיעור העדכונים המאוחרים.
סטטוס: בחר את הפורמט (LookDB/state store/in memory) תוך התחשבות בגודל ובתבניות הגישה; לנקות את הטי-טי-אל.
צילום אוטומטי: על ידי lag, CPU, גודל מדינה, זמן GC.

אמינות והפעלה מחדש

כיור אידמפוטנטי או ביצוע עסקה עם קיבוע קיזוז הוא הבסיס לתקינות.
עיבוד מחדש לאחר הפעלה מחדש מותר; ההשפעה חייבת להישאר ”בדיוק פעם אחת”.
DLQ/חניון: שלח רשומות בעיה לחוט נפרד עם סיבות; לספק עיבוד מחדש.

תצפית (מה למדוד)

לאג על ידי מקור (על ידי זמן ועל ידי הודעה).
סימן מים/זמן האירוע הנוכחי ופרופורציה של אירועים מאוחרים.
מפעילי חיתוך/latency, p95/p99 מקצה לקצה.
גודל/rocksdb I/O, קצב ביקורת/משך.
שיעור DLQ, dauplication/Repray אחוז.
מעבד/GC/ערימה, זמן הפסקה.

בטיחות וציות

סיווג נתונים: לסמן PII/PCI בתרשים, לאחסן את המינימום, להצפין מצב ותמונות.
בקרת גישה: ACLs נפרדים לטבלאות נושא/מצב וכיורים.
חזרות: בהתאם לדרישות המשפטיות (GDPR/זכות להישכח).
ביקורת: log 'event _ id',' trace _ id ', תוצאה:' Applied/ALVE _ APPLID/RETRIFED '.

תבניות יישום

1. CDC # נורמליזציה של אירועי דומיין: לא לשדר שינויים בבסיסי נתונים גולמיים, מפה לעובדות עסקיות מובנות.
2. Outbox עבור יצרנים: העברה עובדה + אירוע - בעסקת מסד נתונים אחת.
3. ליבה נגד מועשר: מטען מינימלי בזרימה קריטית, העשרה - אסינכרוני.
4. יש להרכיב מחדש-ידידותיות: תחזיות/תצוגות מחדש מן היומן.
5. אידמפוטנטיות על ידי עיצוב: operation/event key, upsert מזימות, גרסאות של צבירה.

בדיקות

יחידה/רכוש מבוסס: אינווריאנטים של אגרגטים ושינויים.
בדיקות זרם: זרם אירוע קבוע עם off-off-officlates ו-lauplication checks.
חלונות מוזהבים: חלונות ייחוס/אגרגטים והתאמות מאוחרות.
הזרקת אשמה: נפילה בין ”אפקט מוקלט” ל ”קיזוז מחויב”.
מבחנים בהילוך חוזר: הרכבה מחדש של התצוגה מתחילת הרישום = מצב נוכחי.

עלות ואופטימיזציה

חלונות וסימן מים משפיעים על איחור/משאבים: ככל שהחלון ארוך יותר וככל שהחלון גדול יותר, כך המצב גדול יותר.
קודקים ודחיסה: איזון מעבד/רשת.
פלט חבורה: פחות שיחות רשת ועסקאות.
סינון מוקדם ("pushdown'): זרוק עודף קרוב ככל האפשר למקור.

Antipatterns

לקשור לעיבוד זמן שבו יש צורך בזמן אירוע = אנליטיקה שגויה.
חוסר אידמפוטנטיות בכיור = השפעות כפולות בהחייאה מחדש.
מגה-מפתחות גלובליים: מחיצה חמה אחת שוברת מקביליות.
CDCs גולמי כאירועים ציבוריים: דלפו סכמות DB, שבריריות באבולוציה.
אין DLQ: ”רעיל” הודעות לחסום את כל הצינור.
עיכוב קשה קבוע במקום סימן מים: המתנה נצחית או איבוד נתונים.

דוגמאות של תחומים

תשלומים/פיננסים

התשלום של הזרם. חלונות נגד הונאה (session + CEP), סבא של "מבצע _ id'.
אפקט של פעם אחת בדיוק כאשר פורסם לפנקס חשבונות (גרסת upsert +).

שיווק/פרסום

הזזת חלונות של CTR/המרות, הצטרף לחיצות והתרשמות עם סובלנות 'TenName', צבירה למכרז.

iGaming/online services

איזון/גבולות בזמן אמת, משימות/הישגים (חלונות הפעלה), תבניות אנטי הונאה והתראות.

תבניות מיני (פסאודו קוד)

חלון עם סימני מים ועדכונים מאוחרים

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

כיור טרנסצונלי עם קיבוע קיזוז

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

בדיקת ייצור

[ ] זמן אירוע ואסטרטגיית סימן מים מוגדרים; חלונות ומאוחרים נבחרים.

[ ] כיור אידמפוטנטי או ביצוע עסקה עם קיזוז.

[ ] סכימה רישום ודרכי תאימות מופעלים; אבולוציה תוספתית.

[ ] Metrics: lag, watermark, p95/p99, DLQ, גודל המדינה, משך נקודת ביקורת.

[ ] בדיקות: מחוץ לסדר, שכפולים, הפעלות מחדש, שידור חוזר.

[ ] מדיניות PII/שמירה על המדינה וצילומים.

[ תוכנית ] ואסטרטגיות תרגיל.

[ ] תיעוד של חוזי חלונות והתאמות (עדכונים מאוחרים).

FAQ

זמן אירוע נדרש?
אם תקינות המדדים והעקביות חשובה, כן. זמן עיבוד מתאים לחישובים טכניים/ניטור, אבל מעוות אנליטיקה.

זה נחוץ בדיוק פעם אחת?
נקודה: להשפעות קריטיות. לעתים קרובות יותר, לפחות פעם אחת + כיור אידמפוטנטי זה מספיק.

איך לבחור חלונות?

לבנות על SLAs עסקים: ”5 דקות אחרונות” ”מקפצים”, ”הפעלות משתמש” session, ”דוחות דקות”

מה לעשות עם נתונים מאוחרים?
אפשר "allowed _ lateness' והתאמות הנפקה (upsert/rext). תצוגת הלקוחות חייבת להיות מסוגלת לעדכן.

סך הכל

כמו גם איטיות נמוכה, זרימה היא משמעת של זמן, מצב וחוזים. הבחירה הנכונה של זמן אירוע, חלונות וסימני מים, בתוספת השפעות אידמפוטנטיות, תצפית ובדיקות להפוך את הצינור אמין, רבייתי וחסכוני - ולתת עסקים כאן ועכשיו פתרונות, לא כל לילה אחר.