צינורות ML ב-Apache Airflow: היכן נשבר חישוב מחדש של מודלים
חישוב מחדש של מודל מופעל לעיתים קרובות ידנית: מהנדס מכניס פרוסת נתונים עדכנית ומפעיל לפי הסדר הכנת מאפיינים, אימון וולידציה. כל עוד יש שלושה-ארבעה שלבים, הסכימה נשענת על הזיכרון של אדם אחד, אבל די להוסיף חישוב של ויטרינות נתונים או אימון מחדש לפי לוח זמנים — והסדר של ההרצה נשבר. המודל מתאמן על נתונים חלקיים, והפער צף כבר בסביבת הייצור, כשמדד האיכות זז בלי סיבות נראות לעין.
בעת כשל באמצע הצינור הכול מתחיל מהתחלה: ארטיפקטים ביניים לא נשמרים, והרצה חוזרת אורכת אותו זמן כמו הראשונה. הפעלה מחדש ידנית של משימות הופכת לפעולה נפרדת — צריך לזכור מאיזה שלב להמשיך, אילו ענפים כבר עבדו, ולא לדרוס תוצאה מוצלחת שעוד תעזור.
כאב נפרד — יכולת שחזור של ניסויים. אחרי שבוע אף אחד לא יגיד על איזו פרוסת נתונים התקבל המדד הנוכחי, אילו היפרפרמטרים היו בקונפיג ומה ההבדל בין ההרצה הקודמת לזו שלפניה. אין עם מה להשוות מודלים, וחזרה לגרסה קודמת הופכת לאימון מחדש בעיניים עצומות.
כל ארבע נקודות הכשל — הפעלה ידנית, סדר שלבים נוקשה, אובדן מצב בעת נפילה וניסויים שאינם ניתנים לשחזור — מטופלות בשכבת אורקסטרציה אחת של האימון. נפרט כיצד זה נסגר.
מה נותנת אורקסטרציה מנוהלת של אימון וחישוב מחדש של מודלים
אימון שוטף הופך לעבודה ידנית כשמפעילים שלבים מהזיכרון: ייצוא נתונים בחלון אחד, אימון באחר, פריסה — כשהמהנדס מתפנה. המתזמן Apache Airflow מחליף את ההסכמה הזו בלוח זמנים: האימון רץ לפי לוח שנה או לפי הופעת נתונים טריים.
האפקט המדיד הראשון — זמן הכנת המודל. שרשרת משימות ML «בדיקת נתונים, אימון, הערכת איכות, פריסה» עוברת בלי הפסקות לתיאום, וביומן ההרצות רואים איזה שלב אוכל יותר זמן. השני — שיעור המשימות עם התערבות ידנית: נשארים רק חזרה על שלב שנפל ואישור פריסה.
בקרת איכות הנתונים מוצבת בתחילת השרשרת. בדיקת סכימה, שלמות וטווחי ערכים לא מניחה לאימון להמשיך אם הסט לא עבר בדיקה: למרשם לא נכנס מודל שחושב על זבל. זה סוג הכשל שמפסיק לקרות.
אמינות החישוב מחדש נשענת על חזרות והתראות על כשלים. משימה שנפלה מופעלת מחדש, מצב השלבים הקודמים נשמר, והתראה נשלחת לצ'אט העבודה עם ציון המשימה והלוג — התורן רואה את הסיבה בלי לקרוא את כל היסטוריית ההרצה.
כך אורקסטרציה מעבירה את אימון המודלים משגרה למצב שבו התערבות נדרשת להחלטות, ולא להפעלת השרשרת.
אפשרויות הרצה: מתזמן, סקריפטים, סכימה היברידית
הבחירה בין מתזמן, סקריפטים וסכימה היברידית היא שאלה של מספר התלויות ותדירות ההפעלות מחדש, לא של טעם. נשווה גישות בשני צירים: מתי האפשרות מתאימה ואילו מגבלות היא מביאה לתחזוקה.
סקריפטים ידניים לפי לוח זמנים מחזיקים כל עוד השרשרת לינארית והכשל מנותח בעיניים. ברגע שמופיע הסתעפות, המתנה לנתונים ממערכת אחרת או צורך לחזור רק על השלב שנפל, סביבם מצטברות בדיקות ידניות: היומנים מפוזרים, נקודת ההמשך לא נשמרת, והרצה שהתעכבה נערמת על הבאה.
סכימה היברידית מפרידה אחריות: חישובים כבדים ומשימות חד-פעמיות נשארים במקום שבו הם כבר עובדים, ולוח הזמנים והתלויות נלקחים על ידי המתזמן — ב-Apache Airflow זה גרף משימות ומצב של כל הרצה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סקריפטים לפי לוח זמנים | תהליך לינארי של 1–3 שלבים, מקור נתונים אחד, הרצות נדירות | אין חזרה מאמצע השרשרת והיסטוריית הרצות, עותקים מתחרים בעת עיכוב |
| מתזמן משימות | הסתעפויות, כמה מקורות, חישוב מחדש של חלק מהגרף, דיווח שוטף | פריסה ותחזוקה של מאגר מצבים, משמעת בתיאור הגרף |
| סכימה היברידית | כבר יש סקריפטים עובדים ושירותים חיצוניים, מעבר חלקי | שני מקומות של אמת — נדרשים כללים מפורשים מה רץ איפה |
אין אפשרות נכונה אוניברסאלית: עבור ויטרינה אחת מתזמן הוא מיותר, ועבור שרשרת של עשרה חישובים מחדש תלויים הסקריפטים הופכים למקור כשלים. לכן בהערכה אנחנו תמיד מפרקים כמה נקודות הסתעפות יש לתהליך ובאיזו תדירות יהיה צריך להפעיל אותו מחדש.
איך אנחנו בונים אורקסטרציה: שלבי העבודה
לפני שמגדירים אורקסטרציה, צריך להבין איך ההרצות חיות עכשיו: איפה החישוב נשען על הפעלה ידנית, איפה לוח הזמנים מוכר לאדם אחד, וחישוב מחדש לילי שנפל מבחינים בו רק לפי תלונות בבוקר. בהמשך — מסלול בן שישה שלבים שאנחנו עוברים ב-Apache Airflow.
-
סקר הרצות. אוספים מלאי: אילו משימות יש, מי הבעלים שלהן, מאיפה מגיעים הנתונים ולאן הם הולכים, איפה יש שלבים ידניים. עבור כל אחת מתעדים משך, תדירות ונקודות כשל.
-
סכימת תלויות. בונים גרף: מה באמת תלוי במה, איפה מותרת הרצה מקבילה ואיפה נדרש רצף נוקשה. קשרים מיותרים מסירים — הם מאריכים את המסלול הקריטי ומסתירים כשלים אמיתיים.
-
הגדרת לוחות זמנים. קושרים הרצות לרגע הופעת הנתונים, לא לשעה נוחה. חלונות מאמתים מול לוח המקורות, כדי שהחישוב לא ירוץ על ייצוא חלקי ולא יתחרה עם תהליכים אחרים על משאבים.
-
כללי הפעלה מחדש. קובעים מספר חזרות, השהיה ביניהן ומחלקים משימות לבטוחות להרצה חוזרת ואלה שדורשות החלטה ידנית. בנפרד מתארים אילו כשלים מקפיצים את התורן ואילו נכבים מעצמם.
-
הרשאות וסביבות. חיבורים למאגרים, פרטי זיהוי והרשאות מוציאים לחיבורים מנוהלים, בלי מפתחות בקוד. סביבת העבודה וסביבת הבדיקות מופרדות, כדי שבדיקות לא ייגעו בנתוני הייצור.
-
קבלת התוצאה. מריצים טווח היסטורי על נתונים אמיתיים, משווים את התוצאה לחישוב ייחוס, בודקים איפה משימות נתקעות ומה מתחשב מחדש יותר מהצפוי. מוסרים את הסכימה המוגדרת יחד עם נוהל תורנות וניתוח אירועים.
קונפיגורציות, נהלים ותיעוד למסירה
פרויקט אורקסטרציה של צינורות ML מסתיים לא בהצגת גרף עובד, אלא בחבילה שאיתה הצוות שלכם נשאר לעבוד באופן עצמאי. להלן מה מועבר פיזית ואיפה זה נמצא אחרי המסירה.
- קונפיגורציות עבודה של Apache Airflow: פרמטרים של המתזמן והמבצעים, פולים, תורים, מגבלות משימות במקביל — כקבצים במאגר הקוד, בלי עריכות ידניות דרך ממשק האינטרנט.
- סכימת תלויות משימות: מפת גרפים עם מקורות נתונים, נקודות כניסה, העברות תוצאות בין משימות וקשירה ללוח זמנים ולטריגרים חיצוניים.
- הרשאות גישה ותפקידים: הפרדה לפי צוותים וסביבות, חשבונות שירות נפרדים, סדר מתן ושלילת גישה לסודות ולמאגרים.
- תיעוד הרצות: איך מוסיפים משימה חדשה, איך מוציאים שינוי ללוח זמנים, מה לבדוק לפני העלאה לסביבת הייצור.
- נוהל תגובה לכשלים: סיווג תקלות, סדר הפעלה מחדש בלי לאבד תוצאות שכבר חושבו, ערוצי התראה, זמני תגובה ונקודות הסלמה.
- הגדרות נראות: אילו מטריקות ויומנים נאספים, איפה הוגדרו ספי התראות ומי מקבל אותן.
- חומרי העברת ידע: ניתוח מבנה המערכת בסביבה חיה יחד עם המהנדסים שלכם.
החבילה נשארת עובדת: אפשר להוסיף משימות וכללים חדשים בתוך הצוות שלכם, בלי לחזור אלינו על כל שינוי.
מקרה בוחן: חישוב מחדש של מודלים בלי הפעלות ידניות
שרשרת הכנת הנתונים והאימון נשענה על הפעלות ידניות: מהנדס לפי צ'קליסט הרים ייצוא, ניקוי ואימון, עקב אחר חלון הלילה והעביר ארטיפקטים בין שלבים. כל כשל — ייצוא שנפל, סכימת מקור שהשתנתה, חוסר במשאבים — עצר את כל השרשרת עד הבוקר.
בסופו של דבר יותר משליש מההרצות הסתיימו באופן חלקי, ופער בין גרסאות הנתונים והמודל צף כבר בשלב בדיקת האיכות.
מה שינינו
שרשרת ההכנה והאימון תוארה ב-Apache Airflow כצינור ML של משימות תלויות עם לוח זמנים, ניסיונות חוזרים וזמני פסק. השלבים נעשו אידמפוטנטיים: כל אחד כותב תוצאה למאגר עם גרסאות, ולכן חזרה אחרי כשל מרימה ארטיפקטים ביניים מוכנים, במקום לחשב הכול מחדש. לפני האימון נוספו בדיקות רעננות ושלמות נתונים, ואחריו — קיבוע גרסת סט הנתונים והמודל.
מטריקות לפני ואחרי
שיעור ההרצות המוצלחות עלה מ-62% ל-97%, הפעלות ידניות מחדש הצטמצמו מכמה בשבוע למקרים בודדים בחודש. התגובה לכשל ירדה משעות לדקות: המשימה חוזרת אוטומטית, והמהנדס מקבל התראה רק כשהניסיונות מוצו.
הבדיקות מכסות את כל המעברים הקריטיים בין שלבים, ולכן אי-סנכרון בין נתונים למודל הפסיק להגיע לבדיקת האיכות, וחזרה לגרסה קודמת מתבצעת בהרצה אחת.
במה שונה Airflow ממתזמן בכתיבה עצמית
מתזמן בכתיבה עצמית מחזיק כל עוד יש שניים-שלושה צינורות, התלויות לינאריות, וההרצה מתרחשת פעם ביום. הלוגיקה בדרך כלל חיה בסקריפט אחד עם קריאות עוקבות, לוח הזמנים — ב-cron, והידע על סדר השלבים נשאר בראש של מהנדס אחד.
הפתרון עובד, אבל נתקע כשהמערכת גדלה: כל שלב חדש מאריך את הסקריפט, ויום אחד אף אחד כבר לא מעז לגעת בו.
הכשל החוזר הראשון מופיע בהפעלה מחדש. משימה נפלה באמצע — ההרצה חוזרת כולה, משכפלת נתונים שכבר נטענו, והניתוח נעשה ידנית.
לזה מתווספים המתנות דרך השהיה בתוך התהליך, היעדר חזרות עם השהיה הולכת וגדלה, לוגים במקומות שונים והיסטוריה אפסית: למה ההרצה של אתמול הסתיימה אחרת מזו של היום, אין במה לשחזר.
אורקסטרטור משנה את המודל — תלויות בין שלבים מתוארות במפורש, ולא נובעות מסדר השורות. מכאן ההשלכות המעשיות: הפעלה מחדש רק של המשימה שנפלה, חזרות אוטומטיות, השלמה של מרווחים שהוחמצו, יומן מצבים לכל שלב, בידוד סביבות ושימוש חוזר באופרטורים מוכנים במקום העתקת קוד. Apache Airflow סוגר את זה בכלים סטנדרטיים, ולא בתוספות תוצרת בית.
אין צורך להעביר את ההרצות הקיימות כולן. המסלול המעשי — לעטוף את הסקריפטים הנוכחיים במשימות, להשאיר את אופן ההרצה הקודם כרשת ביטחון, ולמשך זמן מה להריץ את שניהם במקביל תוך השוואת תוצאות. אחר כך מפרקים את הסקריפט המונוליטי לשלבים עם פרמטרים משלהם והפעלה חוזרת.
קריטריון בחירת הכלי פשוט: צינור לינארי אחד משרת את cron, אבל ברגע שמופיעות תלויות, סביבות שונות ודרישות לשחזוריות, סכימה בכתיבה עצמית עולה יותר מאורקסטרציה.
שאלות טכניות לפני תחילת הפרויקט
לפני ההתחלה הצוות הטכני שואל לא שאלות על הכלי, אלא על איך אורקסטרציה של צינורות ML על Apache Airflow תשתלב במערך הקיים: מה יקרה לסקריפטים שכבר נכתבו, מי יקבל גישה, איך יתנהג החישוב בעת כשל. להלן תשובות ישירות למה שהכי часто עולה בשלב ההערכה.
האם סקריפטים מוכנים יצטרכו להיכתב מחדש לכלי החדש?
לא. סקריפטים קיימים מתחברים כמשימות נפרדות, ואנחנו מתארים עבורם תלויות, לוח זמנים וכללי חזרות. בדרך מסירים את מה שמפריע להעברה: נתיבים קשיחים, פרטי זיהוי בתוך הקוד, הרצה ידנית ממכונת המפתח.
איך מופרדת הגישה בתוך הצוות?
הגישות מופרדות לפי תפקידים: מפתח צינור, תורן, קורא יומנים — כל אחד רואה רק את התחום שלו. סודות נשמרים בנפרד ומוזרקים ברגע ההרצה, ולא נמצאים בקוד. ביומן רואים איזו משימה ובאיזה חשבון הורצה.
מה קורה אם משימה נופלת באמצע?
החישוב מתחדש מנקודת הקטיעה: חלקים שכבר חושבו לא מחושבים מחדש ולא משוכפלים במאגר. מספר החזרות וההתנהגות אחריהן נקבעים במדיניות; אם הכשל חוזר, הצינור נעצר ומודיע לתורן, במקום לשכפל את השגיאה לכל הוויטרינה.
האם זמן החישוב מחדש יגדל אחרי המעבר?
החישוב מחדש מופעל לפי לוח זמנים ולפי אירוע, שלבים כבדים עוברים במקביל בין המבצעים. בשלב ההערכה מחשבים בכמה פעמים יתקצר חלון החישוב מחדש על הנפחים שלכם, ובודקים זאת בפיילוט לפני ההטמעה העיקרית.
נדון במשימת האורקסטרציה של האימון שלכם
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים לראות את סכימת ההרצות שלכם בשלמותה: איך קשורים שלבי האימון, איפה הם נעצרים ומה קורה לנתונים ביניהם. להלן רשימה של מה שכדאי להחזיק בהישג יד כשנשב לדון במשימה.
- כמה משימות יש בשרשרת ובאיזו תדירות היא מופעלת: לפי לוח זמנים, לפי אירוע או אחרי הופעת מנה חדשה של נתונים;
- איפה בדיוק זה נקרע: משימה שנפלה, חישוב מחדש, הפעלה ידנית — מה נעשה היום בידיים;
- איך נתונים מועברים בין שלבים — קבצים, טבלאות, ייצואי ביניים — ומי דואג שההרצות לא יתערבבו זו בזו;
- מה כבר אוטומטי ומה נשען על סקריפטים ועל מהנדס תורן;
- אילו בדיקות איכות נתונים צריכות לעבור לפני תחילת האימון ומה לעשות אם הן לא עברו;
- איך אתם לומדים על תקלה — מייל, צ'אט, שיחה — וכעבור כמה זמן מתחילת הכשל;
- האם נדרשת חזרה לגרסה קודמת של המודל וכמה זמן היא צריכה לקחת.
בהמשך אין צורך לתאר הכול בבת אחת. ניקח תרחיש אחד — הנפוץ ביותר או הכואב ביותר — ונבנה אותו ב-Apache Airflow מהתחלה ועד הסוף: הרצת ניסיון על תרחיש אחד תראה איך המערכת מתנהגת על הנתונים ולוח הזמנים שלכם. לפי התוצאות נחזור עם הערכה ותוכנית עבודה לשאר השרשראות.