מדוע עיבוד זרימת נתונים נשבר בשיאי עומס
עיבוד זרימת נתונים נשבר לא בשיא עצמו, אלא מעט קודם לכן — כשהתור עוד מחזיק מעמד, אבל השהיית עיבוד האירועים כבר חצתה את הגבול המותר. עומס השיא על המערכת מגיע באופן לא אחיד: מקורות חיצוניים ושירותים פנימיים מספקים אירועים בממוצע באופן אחיד, אך במרווחים קצרים — מהירים פי כמה.
הצינור מחזיק מעמד עד הרגע שבו קצב הקריאה תואם את קצב הכתיבה. ברגע שהצרכן מפגר, הפיגור מתחיל להזין את עצמו: עיבוד התור שנצבר דורש יותר משאבים מאשר עיבוד הזרימה הטרייה, והפער כבר אינו מתפוגג.
מיד לאחר מכן מתגלה אובדן אירועים בתור, וכמעט אף פעם לא כקריסה של הברוקר. האירוע נעלם בשקט: פג תוקף זמן האחסון של ה-topic בזמן שפירקו את המצטבר; ה-offset נרשם לפני הכתיבה בפועל של התוצאה; הצרכן קרס בין הקריאה לשמירה.
מבחוץ המערכת חיה, המדדים תקינים, אבל חלק מהאירועים לא הגיע — ומגלים זאת בבדיקת התאמות נתונים, ולא לפי התראת ניטור.
הצד השני של הבטחות המסירה — כפילויות של אירועים. בעת חלוקה מחדש של צרכנים בתוך קבוצה או מסירה חוזרת, אירוע אחד נכנס לעיבוד פעמיים, והאגרגט החלונאי סופר אותו כשניים. כפילות כזו בדוח אינה ניתנת להבחנה מקפיצה אמיתית, ולכן מתקבלת החלטה לפי מספר שלא היה קיים.
הסוג השלישי של כשלים — אי-התאמה של תחזיות בעת חישוב מחדש. אם עדכנו את המודל, אבל אירועים מהתור המצטבר עובדו עד הסוף עם מצב ישן, אותו אירוע מקבל הערכות שונות: משפיעים סדר ההגעה, רשומות שהגיעו באיחור, ולפי איזה זמן נאספו המאפיינים. הדוחות מפסיקים להתיישב זה עם זה, והאמון במערכת יורד מהר יותר מקצב גידול הפיגור.
כל שלושת הכשלים נוגעים למערכת, ולא למודל: הם מתגלים רק תחת עומס וכמעט אינם משוחזרים בזרימת בדיקה. להלן נסקור כיצד זה נסגר ברמת הצינור והשליטה בו.
מה נותן מעגל הזרימה: אפקט מדיד
מעגל הזרימה מחשב מאפיינים וקורא למודל בכל אירוע, ולא לפי לוח זמנים. להלן — האפקטים הנראים בתפעול: זמן תגובה, כשלים שנעלמו, עבודה ידנית שנחסכה ושקיפות.
הפחתת השהיית התחזיות
המאפיינים נאספים בחלון מחליק, המודל עונה על אותו אירוע, והתוצאה עוברת מיד ל-data mart ולשירות הצרכן. חישוב מחדש באצווה נותן תשובה כעבור דקות או שעות, ואילו הזרימה — בתוך שנייה מהאירוע, וההשהיה אינה גדלה עם נפח הזרימה.
סוג כשלים שהוסר: אובדנים וכפילויות
כתשתית תעבורה משמשת Apache Kafka: אישור מסירה וכתיבה אידמפוטנטית לפי מפתח האירוע מסירים סוג שלם של כשלים — הודעות אינן אובדות בעת הפעלה מחדש של הצרכן ואינן מכפילות את התחזית.
לאחר קריסת צומת, מעגל הזרימה ממשיך מהמיקום השמור, בלי בדיקת התאמות ידנית ובלי הרצה חוזרת של הנתונים המצטברים.
כמה עבודה ידנית חוסך חישוב מחדש אוטומטי
data marts של מאפיינים ואגרגטים מחושבים מחדש אוטומטית — לפי אירוע, ולא לפי הפעלה של מהנדס. בעבר חיפשו את אי-ההתאמה בעיניים והפעילו מחדש את המשימה ביד: שעות עבודה וחלון זמן שבו התקבלו החלטות לפי מספרים מיושנים. כעת ה-data mart מתיישב מעצמו, ורק מקרים הדורשים התערבות נרשמים ביומן.
ה-observability של מעגל הזרימה — פיגור הצרכן, השהיה בכל קטע, שיעור הרשומות הנדחות — הופך את ניתוח התקלה לקריאת מדדים. את השגיאה רואים לפני שהיא מגיעה למשתמש.
דרכי מסירת אירועים: מה לבחור לפי המשימה
מצב העיבוד נבחר לא לפי אופנה, אלא לפי ההשהיה המותרת ומחיר האירוע שהוחמץ. אם החלטה על הנתונים נדרשת פעם ביום, מעגל הזרימה מוסיף נקודות כשל ועלות תפעול בלי תועלת לתוצאה.
מצב אצווה לפי לוח זמנים
חישוב מחדש קורא את הפרוסה המצטברת, מחשב אגרגטים וכותב את התוצאה כולה. המגבלה — ההשהיה שווה למרווח ההפעלה, וקפיצה בנתונים מזיזה את החלון הבא. לדיווח, חישוב מחדש של מאפיינים ואימון מודלים זהו האפשרות הצפויה ביותר.
מיקרו-אצוות ותרשים זרימה טהור — היכן הגבול
מיקרו-אצווה אוסף אירועים על פני חלון קצר ומוסר אותם במקבץ: ההשהיה — שניות, והעלות קרובה לזו של אצווה. תרשים הזרימה מעבד כל אירוע עם הגעתו, אך דורש מצב נשמר, טיפול באירועים שהגיעו באיחור ומסירה חוזרת — בלי זה התוצאה מתפצלת בעת תקלה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| עיבוד אצווה לפי לוח זמנים | דיווח, חישוב מחדש של מאפיינים, אימון | ההשהיה שווה למרווח ההפעלה |
| מצב מיקרו-אצווה | מדדים ו-data marts בהשהיה של שניות | אירועים שהגיעו באיחור מסבכים את הלוגיקה |
| תרשים זרימה טהור | ניקוד, תגובה לאנומליה | מצב, חזרות, עלות תפעול |
| מעגל היברידי | תשובה מהירה בתוספת חישוב מחדש ברקע | נדרשת בדיקת התאמות בין תוצאת הזרימה לתוצאת האצווה |
מעגל היברידי מסיר את מגבלות תרשים הזרימה: הזרימה נותנת תשובה מהירה, וחישוב מחדש ברקע לפי לוח זמנים בודק ומתקן אותה. את בחירת מצב העיבוד מניחים בארכיטקטורה מראש — להעביר שירות מאצווה לזרימה בשלב מאוחר יקר יותר מאשר לחזות היברידי מראש.
כיצד אנו פורסים מעגל זרימה: שלבי העבודה
כל עוד פרופיל העומס אינו ברור, כל תרשים של מעגל זרימה נשאר בגדר השערה. לכן השלבים עוברים מהנתונים אל הקוד: כל צעד הבא נשען על התוצר של הקודם, ולא על הנחות לגבי אופן ההתנהגות של הזרימה.
ביקורת מקורות ופרופיל עומס
- ביקורת מקורות הנתונים — מלאי של topics, פורמטי הודעות, מפתחות partitioning ושיעור הרשומות ה"מלוכלכות". בפלט — מפת מקורות עם הערות על השהיות ועל שינויי סכמה ששוברים תאימות לאחור.
- פרופיל עומס — מצלמים את הזרימה האמיתית: שיאים, עונתיות, התפלגות לפי מפתחות. מכאן מחשבים את מספר המעבדים המקבילים ואת מרווח הזיכרון.
- תרשים מעגל הזרימה — מקבעים את הגבולות: היכן קוראים, היכן מעשירים, היכן קוראים למודל, היכן שומרים. בנפרד מתארים את סמנטיקת המסירה ואת סדר השמעת החלון מחדש בעת תקלה.
בדיקה על תעבורת צל לפני המיתוג
- ניפוי באגים על נתונים היסטוריים — הרצת מעגל הזרימה על הזרימה המצטברת ובדיקת התאמות מול הפתרון הנוכחי; את אי-ההתאמות מנתחים לפני המיתוג.
- בדיקת עומס — מזרימים זרימה גבוהה מהשיא המחושב ובוחנים היכן בדיוק יש ירידה בביצועים: גידול התור, פיגור העיבוד, שיעור התשובות בזמן.
- תעבורת צל — מעגל הזרימה החדש מחשב נתונים חיים במקביל לענף העבודה, והתוצאה לא נשלחת לשום מקום. כך בודקים את ההתנהגות באירועים נדירים ומוודאים שאי-ההתאמות נכנסות בסטייה המותרת.
- העברה לתפעול — מיתוג התעבורה, העברת קונפיגורציות לצוות, כללי התראות והוראות חזרה למעגל הזרימה הקודם.
מה נשאר אצלכם: תרשימים, נהלים, קונפיגורציות
אנחנו מוסרים את מעגל הזרימה לא כ"עובד", אלא ככזה שניתן לתחזק: המהנדס של הלקוח צריך להרים את הזרימה בעצמו, להוסיף שדה לאירוע ולהתאושש מתקלה בלי לחכות לנו. לכן בהעברה נכלל לא רק קוד, אלא גם מארג תוצרים שלפיהם ניתן ללוות ולפתח את עיבוד זרימת הנתונים בתוך הצוות.
תרשימי זרימה ותיאור פורמטי אירועים
- מפת זרימות: מקורות אירועים, תורים ו-partitionים, צרכנים, נתיב האירוע מהקליטה ועד הכתיבה לאחסון וקריאות חזרה.
- תיאור פורמטי אירועים עם גרסאות: שדות חובה ושדות אופציונליים, יחידות מידה, כללי תאימות בעת הוספת שדה.
- קונפיגורציות עיבוד: חלונות אגרגציה, פיגור מותר, חזרות בעת שגיאות, נקודות שמירה של המצב, עומק האחסון לפני שטיפה.
נהלי תגובה לתקלות
- רמות אירועים וזמן תגובה לכל אחת: פיגור הזרימה, אובדן אירועים, כשל המודל ב-inference.
- סדר הפעולות: כיצד לעצור את הקליטה, להשמיע מחדש קטע מנקודת השמירה האחרונה, להחזיר גרסה של סכמה או מודל.
- כללי גישה לנתונים: תפקידים, ממה מורכבת הגישה לכל זרימה, היכן נשמרים המפתחות וכיצד הם מוחלפים.
- תיעוד מעגל הזרימה: תרשים פריסה, תלויות, בעלי הזרימות, סדר ביצוע שינויים.
לכל סעיף מצורף רשימת בדיקה קצרה — הלקוח מקבל את העבודה בעצמו, ולא על סמך מילה.
מקרה בוחן: כיצד קיצרנו השהיות בשיא העומס
הלקוח — פלטפורמה שבה על כל אירוע מהמכשירים המודל חייב לענות בתוך אותה בקשה. בשיא הזרימה גדלה פי שלושה, ומעגל הזרימה לא החזיק מעמד: התחזיות נכנסו לתור, חלק מהאירועים אבד בעת הפעלה מחדש של הצומת, ולאחר כשל ההתאוששות נמשכה עשרות דקות — עבור העסק זה נראה כמו "השירות מהבהב".
מה היה לפני ומה נהיה אחרי
את הניתוח התחלנו מהזרימה: קראו אותה בצרכן אחד, ולכן לא היה מה להרחיב. פיצלנו את העיבוד לצרכנים עצמאיים של Kafka עם מפתח partitioning לפי מזהה המכשיר — סדר האירועים עבור אובייקט אחד נשמר, והעומס מתחלק בין הצמתים.
את מצב החלונות העברנו לאחסון עמיד בפני תקלות, והפעלה מחדש של צומת הפסיקה לאיין אובדן של ההקשר המצטבר.
| מדד | לפני | אחרי |
|---|---|---|
| השהיית התחזית בשיא | גידול פי 12 | גידול פי 1.4 |
| שיעור האירועים שאבדו | 3–4 % בשעת שיא | 0.02 % |
| התאוששות מעגל הזרימה לאחר כשל צומת | 20–35 דקות | עד 40 שניות |
את העיבוד החוזר הפכנו לאידמפוטנטי: לכל אירוע יש מפתח, ולכן השמעה מחדש של היומן אינה יוצרת כפילויות באחסון ואינה מפצלת אגרגטים. בדיוק סוג כשלים זה יצר רשומות כפולות לאחר תקלה ואילץ מהנדסים לבדוק את ה-data marts ידנית.
במה עיבוד זרימה שונה מעיבוד אצווה?
עיבוד אצווה מחשב לפי פרוסה מצטברת: הנתונים נאספים, והחישוב מופעל כולו לפי לוח זמנים. עיבוד זרימה קורא אירועים עם הגעתם ומעדכן את התוצאה ברציפות. ההבדל אינו בנפח, אלא בהשהיית התוצאה: במעגל אצווה היא שווה למרווח ההפעלה, ובזרימה — לזמן מעבר האירוע דרך החלון והמודל.
ההשהיה קובעת את גבול הישימות. כל עוד התשובה מגיעה פעם ביום, ניקוד ברגע הגשת הבקשה, התראה על אנומליה או רמז בממשק אינם אפשריים. הזרימה מזיזה את התגובה לשניות, אך משלמת על כך בעבודה מתמדת של מעגל הזרימה: הוא מחזיק את מצב האגרגטים בין אירועים ואינו "נרדם" בין הפעלות.
חישוב מחדש של נתונים היסטוריים הוא החוזק של גישת האצווה: מחליפים לוגיקה, מפעילים מחדש את התקופה, ומקבלים תמונה עקבית. בזרימה זוהי פעולה נפרדת — לשחזר את המצב לרגע הרצוי, להגביל את החלון ולעשות את הכתיבה אידמפוטנטית, אחרת עיבוד חוזר יכפיל את המונים ויעוות את ה-data mart.
מורכבות ניפוי הבאגים בזרימה גבוהה יותר מסיבה אובייקטיבית. חישוב אצווה ניתן לשחזור: יש פרוסת קלט, גרסת קוד ותוצאה. הזרימה תלויה בסדר האירועים, ברשומות שהגיעו באיחור, במצב המצטבר וברגע התקלה — נדרש יומן של אירועי קלט, נקודות ביקורת של המצב והשמעה מאותו מיקום.
גם הדרישות לאיכות הנתונים נבדלות: באצווה מבודדים רשומה פגומה, מתקנים ומחשבים מחדש, ואילו בזרימה שדה לא תואם שובר את העיבוד תוך כדי תנועה.
לכן אין להעמיד מעגלים זה כנגד זה, אלא לשלב ביניהם: הזרימה אחראית על הטריות, והאצווה — על השלמות ובדיקת ההתאמות. את הבחירה מכתיבה לא כמות הנתונים, אלא ההשהיה המותרת של התוצאה ומחיר הטעות.
ספקות טכניים נפוצים לפני ההתחלה
לפני ההתחלה צוותי הנדסה שואלים אותן שאלות: מה יקרה לאירועים שהגיעו באיחור, כיצד לא להכפיל תוצאות במסירה חוזרת, והאם מעגל הזרימה יעמוד בגידול הזרימה. להלן — תשובות קצרות על האופן שבו סיכונים אלה נסגרים בעיבוד זרימה בפועל.
מה קורה לאירועים שהגיעו באיחור?
את חלון האגרגציה מחשבים לפי זמן האירוע עצמו, ולא לפי זמן הגעתו, עם lag מותר מוגדר במפורש. כל מה שהגיע אחרי הגבול אינו נזרק: רשומות כאלה עוברות לזרימה נפרדת של חישוב משלים, וה-data marts הסופיים מתעדכנים — זנב הנתונים אינו אובד.
כיצד מובטח עיבוד אידמפוטנטי?
כל הודעה נושאת מפתח, וכתיבת התוצאה מתבצעת עם בדיקת המפתח הזה, ולכן מסירה חוזרת אינה יוצרת כפילות. בעת הפעלה מחדש הצינור ממשיך מהמיקום האחרון המאושר — תקלה אינה הופכת לערכים מוכפלים בדיווח.
כיצד נשלטת איכות הנתונים?
בכניסה מציבים בדיקות של סכמה, טווחים ושדות חובה, ואנומליות אינן מפילות את הזרימה, אלא מסומנות ועוברות להסגר. שיעור הרשומות הפסולות והסיבות להן נכנסים לניטור, כך שירידה באיכות המקור נראית לפני שהיא מגיעה למודלים.
האם מעגל הזרימה יעמוד בגידול העומס?
הצרכנים מתרחבים לפי מספר ה-partitionים, ולכן תפוקת המערכת גדלה בהוספת מעבדים בלי לשכתב את הלוגיקה. אנחנו מריצים מראש פרופיל של עומס שיא וקובעים באיזה קצב נדרש הרחבה.
כיצד מפעילים בלי סיכון לפרודקשן?
הולכים בשלבים: תחילה הרצת צל על עותק של הזרימה ובדיקת התאמות מול מעגל הזרימה הנוכחי, ואחר כך העברה הדרגתית של חלק מהתעבורה עם שמירה על מיתוג חזרה. חזרה לאחור היא חזרה למסלול הקודם, ולא שחזור מגיבוי.
נדון במשימה ונחזור עם הערכה ותוכנית
לשיחה עניינית אין צורך במסמך מוכן — די בתיאור של האופן שבו זרימת הנתונים חיה כיום. ככל שהנתונים הראשוניים מדויקים יותר, כך ההערכה ותוכנית העבודה מדויקות יותר.
- מקורות אירועים: אפליקציות, חיישנים, תורים, בסיסי נתונים — מהיכן מגיעים הנתונים, באיזה פורמט ובאיזו תדירות;
- תיאור התרשים הנוכחי: היכן נכון לעכשיו מחושב המודל, היכן נשמר מצב הזרימה, אילו קטעים כבר אינם עומדים בעומס;
- מגבלות עומס: מספר אירועי השיא בשנייה, ההשהיה המותרת של התשובה, נפחי האחסון;
- דרישות לאיכות ההחלטות: מה בדיוק חוזה המודל ואיזו טעות אתם מחשיבים כבלתי מקובלת;
- תשתית והרשאות גישה: מעגל זרימה משלכם או ענן, כללי אחסון והעברת נתונים;
- קריטריוני התחלת הפרויקט: איזו תוצאה בשלב הראשון תיחשב בעיניכם להצלחה.
בתגובה אנחנו שולחים הערכה ותוכנית עבודה: חלוקה לשלבים עם משכים, תרשים תנועת הנתונים, רשימת סיכונים ונקודות חזרה לאחור, הרכב הצוות ותחום האחריות בצד שלכם. אם לפי הנתונים הראשוניים ניכר שאין צורך לבנות מחדש חלק ממעגל הזרימה, נאמר זאת ישירות — זה מצמצם את היקף העבודה.
ניתן לדון במשימה גם בלי תיאור מלא: שלחו את מה שיש, ואת השאר נבהיר בשאלות.