העברת סביבות ל-Airflow 3 (זו לצד זו)

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

בדף הזה מוסבר איך להעביר DAG, נתונים והגדרות מסביבת Managed Airflow (דור 3) קיימת עם Airflow 2 לסביבות Managed Airflow (דור 3) עם Airflow 3.

מאת אל ‏Method מדריך
‫Managed Airflow (דור 3), ‏ Airflow 2 ‫Managed Airflow (דור 3), Airflow 3 העברה ידנית זה לצד זה במדריך הזה
‫Managed Airflow (דור 2) ‫Managed Airflow (דור 3) זה לצד זה, באמצעות סקריפט ההעברה מדריך להעברת סקריפטים
‫Managed Airflow (דור 2) ‫Managed Airflow (דור 3) זו לצד זו, באמצעות תמונות מצב מדריך להעברת תמונות מצב
‫Managed Airflow (Legacy Gen 1), Airflow 2 ‫Managed Airflow (דור 3) זו לצד זו, באמצעות תמונות מצב מדריך להעברת תמונות מצב
‫Managed Airflow (Legacy Gen 1), Airflow 2 ‫Managed Airflow (דור 2) זו לצד זו, באמצעות תמונות מצב מדריך להעברת תמונות מצב
‫Managed Airflow (Legacy Gen 1), Airflow 2 ‫Managed Airflow (דור 2) העברה ידנית זה לצד זה מדריך להעברה ידנית
‫Managed Airflow (Legacy Gen 1), Airflow 1 ‫Managed Airflow (דור 2), ‏ Airflow 2 זו לצד זו, באמצעות תמונות מצב מדריך להעברת תמונות מצב
‫Managed Airflow (Legacy Gen 1), Airflow 1 ‫Managed Airflow (דור 2), ‏ Airflow 2 העברה ידנית זה לצד זה מדריך להעברה ידנית
‫Managed Airflow (Legacy Gen 1), Airflow 1 ‫Managed Airflow (Legacy Gen 1), Airflow 2 העברה ידנית זה לצד זה מדריך להעברה ידנית

שינויים שהוצגו ב-Airflow 3

לפני שמתחילים להשתמש בסביבות Managed Airflow עם Airflow 3, כדאי להכיר את השינויים ש-Airflow 3 מביא לסביבות Managed Airflow (דור 3).

סקירה כללית של השינויים בגרסת הקהילה של Airflow 3 זמינה במאמר Apache Airflow 3 is Generally Available!.

ניהול גרסאות של DAG

  • ב-Airflow 3, ‏ DAG יפעל עד הסיום על סמך הגרסה שהייתה קיימת בתחילת ההפעלה, גם אם הועלתה גרסה חדשה בזמן שה-DAG פעל.

    • כל ההרצות של DAG בממשק המשתמש של Airflow משויכות עכשיו לגרסת ה-DAG המתאימה (הגרסה בזמן ההרצה). זה כולל את מבנה המשימה ואת קוד ה-DAG.

שיפורים במילוי חוסרים

ב-Airflow 3 בוצע שינוי משמעותי באופן הטיפול ב-backfill (הפעלה מחדש של צינורות להעברת נתונים לנתונים היסטוריים). תהליך מילוי החוסרים עובר מתהליך ידני לתכונה שניתן לצפות בה באופן מלא, שמשולבת במנוע הליבה של Airflow:

  • מעכשיו, המילויים החלקיים מנוהלים ישירות ב-Airflow scheduler, במקום להיחשב כתהליכים נפרדים וידניים. כך אפשר להרחיב את הפעילות בצורה טובה יותר וליהנות משליטה מדויקת יותר.
  • מעכשיו אפשר להפעיל, לעצור ולעקוב אחרי ההתקדמות של מילוי שטחי הפרסום ישירות דרך ממשק המשתמש של Airflow או קריאות ל-API, בנוסף ל-Airflow CLI.
  • מתזמן העבודות של Airflow מספק תצוגה טובה יותר של הסטטוס והתקינות של הרצות היסטוריות של מילוי חוסרים.
  • שיפורים במילוי חוסרים (backfill) חלים על כל תהליכי העבודה של ETL/ELT, למרות שהם נדרשו מאוד על ידי קהילת הלמידה החישובית (לצורך אימון מחדש של מודלים על נתונים ישנים).

אבטחה ואמינות משופרות

  • ב-Airflow 3, משימות מתקשרות רק עם שרת ה-API המרכזי דרך Task SDK (ב-Airflow 2, למשימות הייתה גישה ישירה למסד הנתונים). שרת ה-API מנהל את החיבורים האלה בצורה יעילה. מסד הנתונים שלכם מוגן מפני עליות חדות בחיבורים, ולכן הסביבה כולה יציבה יותר בעומסים כבדים.

  • בעזרת ממשק חדש להפעלת משימות, Airflow 3 תומך בבידוד טוב יותר בין משימות, ומונע ממשימה אחת להפריע למשימה אחרת או לגשת לנתונים שלה.

  • ב-CLI של Airflow 3, הגישה הישירה למסד הנתונים כבר לא אפשרית. ממשק שורת פקודה חדש airflowctl הוא חבילה נפרדת שמיועדת במיוחד לגישה מרחוק דרך ה-API. במקום גישה ישירה למסד הנתונים, הוא מתקשר עם Airflow באמצעות ממשקי API, וזה מאובטח יותר.

תזמון מבוסס-אירועים ונכסי נתונים

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

  • ב-Airflow 3 הוצג קונספט חדש שנקרא Watchers. אלה רכיבים שעוקבים אחרי שינויים בנכס נתונים, ומאפשרים ל-Airflow להפעיל תהליכי עבודה ברגע שהנתונים מגיעים. במקום לבצע סקר (בדיקה כל דקה אם קובץ קיים), אפשר להפעיל עכשיו DAG באופן מיידי ברגע שהודעה מגיעה לתור הודעות.

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

ממשק משתמש מודרני של Airflow

  • ממשק המשתמש של Airflow נכתב מחדש מאפס באמצעות React (חלק הקצה) ו-FastAPI (חלק העורף).
  • ממשק המשתמש החדש של Airflow מבצע את הפעולות שלו באמצעות API בארכיטקטורת REST סטנדרטי ו-API ייעודי לפעולות בממשק המשתמש.
  • החלפת ההטמעה של Flask ב-FastAPI שיפרה משמעותית את מהירות התגובה של ממשק המשתמש של Airflow.
  • תצוגות הרשת והגרף אוחדו כדי לייעל את תהליך העבודה, וכך קל יותר לעבור בין מבני DAG ברמה גבוהה לבין יומני משימות ספציפיים.

שינויי תוכנה שעלולים לגרום לכשלים ב-Airflow 3

ב-Airflow 3 בוצעו כמה שינויים משמעותיים, שחלקם הם שינויים שעלולים לשבור את התאימות לאחור:

  • לא מובטח ש-DAGs קיימים מ-Airflow 2 יפעלו עם Airflow 3 ללא שינויים. צריך לבדוק אותם ואולי לשנות אותם על ידי שינוי של ייבוא, פרמטרים של DAG ופרטים אחרים של ההטמעה.

  • חלק מאפשרויות ההגדרה של Airflow 2 משנות את השם או מוסרות ב-Airflow 3. מידע נוסף על פרמטרים זמין בחומר העזר בנושא הגדרות של Airflow.

  • אין גישה ישירה למסד הנתונים של Airflow מקוד המשימה:

    • אי אפשר יותר לייבא ולהשתמש ישירות בקוד של משימות בסשנים או במודלים של מסד נתונים של Airflow.
    • אי אפשר להשתמש ב-PostgresHook וב-PostgresOperator עם החיבור airflow_db.

  • יכול להיות שחלק מחבילות PyPI בהתאמה אישית לא יהיו תואמות לגרסה החדשה של Airflow ולתלות שלה.

  • ‫REST API (/api/v1) הוחלף ב-/api/v2.

  • החלפנו את ה-SubDAGs ב-TaskGroups, ב-Assets וב-Data Aware Scheduling.

  • הסכמי רמת שירות (SLA) הוצאו משימוש והוסרו. הם הוחלפו בהתראות על מועד אחרון.

  • הוסר הארגומנט subdir בפקודות CLI.

  • חלק ממשתני ההקשר של Airflow הוסרו. מידע נוסף זמין במאמר Breaking Changes (שינויים שעלולים לשבור את התאימות) במסמכי התיעוד של Airflow.

  • פרמטר ה-DAG‏ catchup_by_default מוגדר עכשיו כ-False כברירת מחדל.

  • ההגדרה create_cron_data_intervals היא עכשיו False כברירת מחדל. כלומר, כברירת מחדל, המערכת תשתמש ב-CronTriggerTimetable במקום ב-CronDataIntervalTimetable.

  • רשימת השינויים ב-Airflow 3.0.0.

  • רשימת השינויים ב-Airflow 3.1.0

ההבדלים בין סביבות עם Airflow 3 ו-Airflow 2

ההבדלים העיקריים בין סביבות Managed Airflow עם Airflow 2 לבין סביבות עם Airflow 3 הם:

מעבר ל-Airflow 3 זה לצד זה

תהליך ההעברה זה לצד זה כולל את השלבים הבאים:

  1. בדיקת התאימות ל-Airflow 3.
  2. יוצרים סביבת Airflow 3, מעבירים את ביטולי ההגדרות ואת משתני הסביבה.
  3. מתקינים חבילות PyPI בסביבת Airflow 3.
  4. העברה של משתנים, חיבורים ומאגרי חיבורים אל Airflow 3.
  5. העברת נתונים אחרים מקטגוריית הסביבה של Airflow 2.*.
  6. העברת משתמשים ותפקידים.
  7. מוודאים שגרפי ה-DAG מוכנים ל-Airflow 3.
  8. העברת DAG לסביבת Airflow 3.
  9. מעקב אחרי סביבת Airflow 3.

שלב 1: בודקים את התאימות ל-Airflow 3

כדי לבדוק תאימות ל-Airflow 3:

  • בודקים שהסביבה משתמשת ב-Airflow בגרסה 2.7 ואילך. מומלץ לשדרג קודם לגרסה האחרונה של Airflow 2, ורק אחר כך לעבור ל-Airflow 3.
  • בודקים שהסביבה תקינה ופועלת ללא בעיות במשך זמן מה.
  • מוודאים שגרפי ה-DAG וההגדרות של Airflow לא משתמשים בתכונות או בפונקציות שהוסרו ב-Airflow 3.
  • כדאי לקרוא את ההוראות לשינוי קובצי DAG כך שיהיו תואמים ל-Airflow 3 כדי להבין אם יהיה צורך לבצע שינויים בקובצי ה-DAG במהלך תהליך ההעברה.
  • כדי לבדוק את התאימות של קובצי ה-DAG של Airflow, אפשר להשתמש בכלי ruff שזמין בגרסת הקהילה של Airflow. הוראות מפורטות זמינות במאמר בדיקת התאימות של קובצי DAG ב-Airflow במסמכי Airflow.

שלב 2: יצירת סביבת Airflow 3, העברת ביטולים של הגדרות ומשתני סביבה

בשלב הזה, יוצרים סביבת Managed Airflow (דור 3) חדשה עם Airflow 3 ומתחילים להעביר את פרמטרים של התצורה מסביבת Airflow 2:

פועלים לפי השלבים ליצירת סביבת Managed Airflow (דור 3) ומבצעים את הפעולות הבאות:

  1. כשבוחרים גרסת Airflow, בוחרים גרסה עם Airflow 3.

  2. מעתיקים את כל האפשרויות התואמות לשינוי ההגדרות של Airflow מסביבת Airflow 2.

  3. מעתיקים את כל משתני הסביבה מהסביבה שלכם ב-Airflow 2.

  4. ממשיכים ליצירת סביבה עם Airflow 3.

בטבלה הבאה מפורטים כמה שינויים באפשרויות ההגדרה של Airflow. זו רשימה חלקית. מידע נוסף על שינויים באפשרויות ההגדרה של Airflow זמין במאמרים Airflow Configuration Reference ו-Airflow Release Notes במסמכי התיעוד של Airflow.

אפשרות Airflow 2 אפשרות Airflow 3
[scheduler]min_file_process_interval [dag_processor]min_file_process_interval
[webserver]rbac_user_registration_role [api]rbac_user_registration_role
[core]dag_file_processor_timeout [dag_processor]dag_file_processor_timeout
[scheduler]dag_dir_list_interval [dag_processor]refresh_interval
[scheduler]max_threads [dag_processor]parsing_processes
[scheduler]parsing_processes [dag_processor]parsing_processes
[webserver]instance_name [api]instance_name
[scheduler]scheduler_zombie_task_threshold [scheduler]task_instance_heartbeat_timeout
[webserver]rbac הוצא משימוש
[api]auth_backend=airflow.api.auth.backend.deny_all הוצא משימוש
[api]auth_backends=airflow.api.auth.backend.deny_all הוצא משימוש
[api]composer_auth_user_registration_role הוצא משימוש

שלב 3: התקנת חבילות PyPI בסביבת Airflow 3

אחרי שיוצרים את סביבת Airflow 3, צריך להתקין בה חבילות PyPI:

  1. מעתיקים את דרישות חבילת PyPI מהסביבה שלכם ב-Airflow 2.
  2. מתחילים את פעולת העדכון של חבילות PyPI וממתינים עד שהסביבה תתעדכן.

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

שלב 4: ייצוא משתנים, חיבורים ומאגרי חיבורים מ-Airflow 2

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

צריך להעביר מאגרי כתובות רק אם יש לכם מאגרי כתובות בהתאמה אישית שאינם default_pool. אחרת, מדלגים על פקודות שמייצאות ומייבאות מאגרי כתובות.

  1. מייצאים משתנים מסביבת Airflow 2:

    gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    variables -- export /home/airflow/gcs/data/variables.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  2. ייצוא חיבורים מסביבת Airflow 2:

    gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    connections -- export /home/airflow/gcs/data/connections.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  3. מייצאים מאגרי משאבים מסביבת Airflow 2:

    gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    pools -- export /home/airflow/gcs/data/pools.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  4. מקבלים את השם של הקטגוריה בסביבת Airflow 2:

    gcloud composer environments describe AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    --format="value(storageConfig.bucket)"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  5. מורידים את הקבצים variables.json, connections.json ו-pools.json מהספרייה /data של דלי הסביבה Airflow 2 לספרייה מקומית:

    gcloud storage cp gs://AIRFLOW_2_BUCKET/data/variables.json ./variables.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/connections.json ./connections.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/pools.json ./pools.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_BUCKET: השם של הקטגוריה בסביבת Airflow 2, שקיבלתם בשלב הקודם.

שלב 5: ייבוא משתנים, חיבורים ומאגרי חיבורים ל-Airflow 3

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

צריך להעביר מאגרי כתובות רק אם יש לכם מאגרי כתובות בהתאמה אישית שאינם default_pool. אחרת, מדלגים על פקודות שמייצאות ומייבאות מאגרי כתובות.

  1. מגדירים את airflowctl להרצת פקודות Airflow CLI בסביבת Airflow 3.

  2. ייבוא משתנים, חיבורים ומאגרי משאבים לסביבת Airflow 3 באמצעות airflowctl:

    airflowctl variables import ./variables.json
airflowctl connections import ./connections.json
airflowctl pools import ./pools.json

  3. מוודאים שהמשתנים, החיבורים והמאגרים מיובאים לסביבת Airflow 3:

    airflowctl variables list
airflowctl connections list
airflowctl pools list

  4. ניקוי קובצי JSON:

    gcloud storage rm gs://AIRFLOW_2_BUCKET/data/variables.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/connections.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/pools.json
rm ./variables.json
rm ./connections.json
rm ./pools.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_2_BUCKET: השם של הקטגוריה בסביבת Airflow 2.

שלב 6: העברת נתונים אחרים מהקטגוריה של סביבת Airflow 2

בשלב הזה מעבירים את הנתונים שנותרו ממאגר (bucket) של סביבת Airflow 2.

  1. מקבלים את השם של הקטגוריה בסביבת Airflow 3:

    gcloud composer environments describe AIRFLOW_3_ENV \
    --location AIRFLOW_3_LOCATION \
    --format="value(storageConfig.bucket)"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_3_ENV: השם של סביבת Airflow 3.
    • ‫AIRFLOW_3_LOCATION: האזור שבו נמצאת סביבת Airflow 3.

  2. מייצאים פלאגינים מהבאקט של סביבת Airflow 2 אל הספרייה /plugins בבאקט של סביבת Airflow 3:

    gcloud composer environments storage plugins export \
  --destination=AIRFLOW_3_BUCKET/plugins \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_3_BUCKET: השם של הקטגוריה בסביבת Airflow 3, שקיבלתם בשלב הקודם.
    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  3. בודקים שהספרייה /plugins יובאה בהצלחה:

    gcloud composer environments storage plugins list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_3_ENV: השם של סביבת Airflow 3.
    • ‫AIRFLOW_3_LOCATION: האזור שבו נמצאת סביבת Airflow 3.

  4. מייצאים את הספרייה /data מסביבת Airflow 2 לסביבת Airflow 3:

    gcloud composer environments storage data export \
  --destination=AIRFLOW_3_BUCKET/data \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AIRFLOW_3_BUCKET: השם של הקטגוריה בסביבת Airflow 3, שקיבלתם בשלב הקודם.
    • ‫AIRFLOW_2_ENV: השם של סביבת Airflow 2.
    • ‫AIRFLOW_2_LOCATION: האזור שבו נמצאת סביבת Airflow 2.

  5. בודקים שהתיקייה /data יובאה בהצלחה:

    gcloud composer environments storage data list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION

שלב 7: העברת משתמשים ותפקידים

אי אפשר להעביר משתמשים ותפקידים כי airflowctl עדיין לא תומך בפקודות users ו-roles.

שלב 8: מוודאים שגרפי ה-DAG מוכנים ל-Airflow 3

  1. משנים את קובצי ה-DAG של Airflow כדי להפוך אותם לתואמים ל-Airflow 3.

  2. בדיקת משימות שנכתבו בהתאמה אישית לגישה ישירה למסד הנתונים של Airflow:

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

    אפשר להשתמש באחת מהגישות החלופיות כדי להפסיק את הגישה הישירה למסד הנתונים של Airflow במשימות:

    אם שאילתות במסד הנתונים המיוצא של Airflow לא מתאימות לתרחיש השימוש שלכם, ואם גם לקוח Python של Airflow וגם airflowctl לא מספקים את הפונקציונליות הנדרשת, כדאי לשלוח בקשה לנקודות קצה חדשות של API או לתכונות חדשות של Task SDK בגרסת הקהילה של Airflow.

  3. אם יש לכם KubernetesExecutor משימות, צריך להחליף את queue="kubernetes" ב-executor="KubernetesExecutor" בהגדרות האופרטורים.

    דוגמה למשימת KubernetesExecutor ב-Airflow 3:

    PythonOperator(
task_id="airflow3_kubernetes_executor_task",
dag=dag,
python_callable=f,
executor="KubernetesExecutor",
)

  4. אם משתמשים במשתנה הסביבה AIRFLOW__WEBSERVER__BASE_URL בקוד של המשימות, צריך להחליף אותו באפשרות [api]base_url בהגדרות של Airflow.

    דוגמה לאופן קבלת הערך הזה ב-Airflow 3:

    from airflow.configuration import conf

webserver_base_url = conf.get("api", "base_url")

שלב 9: מעבירים את ה-DAG לסביבת Airflow 3

אלו בעיות פוטנציאליות שעלולות לקרות כשמעבירים DAG בין סביבות:

  • אם DAG מופעל (לא מושהה) בשתי הסביבות, כל סביבה מריצה עותק משלה של ה-DAG, לפי התזמון. יכול להיות שזה יוביל להפעלות בו-זמניות של DAG לאותם נתונים ולאותו זמן ביצוע.

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

מניעת הפעלות מקבילות של DAG

בסביבת Airflow 3, מחליפים את dags_are_paused_at_creation אפשרות ההגדרה של Airflow. אחרי שתבצעו את השינוי הזה, כל ה-DAG החדשים יושהו כברירת מחדל.

קטע מפתח ערך
core dags_are_paused_at_creation True

מניעת הפעלות מיותרות או חסרות של DAG

מציינים תאריך התחלה סטטי חדש ב-DAG שמעבירים לסביבת Airflow 3.

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

לדוגמה, אם ה-DAG שלכם פועל בשעות 15:00, ‏ 17:00 ו-21:00 מדי יום בסביבת Airflow 2, ההפעלה האחרונה של ה-DAG הייתה בשעה 15:00, ואתם מתכננים להעביר את ה-DAG בשעה 15:15, אז תאריך ההתחלה של סביבת Airflow 3 יכול להיות היום בשעה 14:45. אחרי שמפעילים את ה-DAG בסביבת Airflow 3, ‏ Airflow מתזמן הפעלה של ה-DAG לשעה 17:00.

דוגמה נוספת: אם ה-DAG פועל בשעה 00:00 בכל יום בסביבת Airflow 2, ההפעלה האחרונה של ה-DAG התרחשה בשעה 00:00 ב-26 במרץ 2026, ואתם מתכננים להעביר את ה-DAG בשעה 13:00 ב-26 במרץ 2026, אז תאריך ההתחלה של סביבת Airflow 3 יכול להיות 23:45 ב-25 במרץ 2026. אחרי שמפעילים את ה-DAG בסביבת Airflow 3,‏ Airflow מתזמן הפעלה של DAG לשעה 00:00 ב-27 במרץ 2026.

העברה של קובצי DAG אחד אחד לסביבת Airflow 3

כדי להעביר כל DAG, פועלים לפי ההליך הבא:

  1. מוודאים שתאריך ההתחלה החדש ב-DAG מוגדר כמו שמתואר בקטע הקודם.

  2. מעלים את ה-DAG המעודכן לסביבת Airflow 3. ה-DAG הזה מושהה בסביבת Airflow 3 בגלל החלפת ההגדרה, ולכן עדיין לא מתוזמנים ריצות של DAG.

  3. בממשק האינטרנט של Airflow, עוברים אל DAGs ובודקים אם יש שגיאות תחביר שדווחו ב-DAG.

  4. בזמן שבו אתם מתכננים להעביר את ה-DAG:

    1. משהים את ה-DAG בסביבת Airflow 2.

    2. מבטלים את ההשהיה של ה-DAG בסביבת Airflow 3.

    3. בודקים שהרצת ה-DAG החדשה מתוזמנת לשעה הנכונה.

    4. מחכים להרצת ה-DAG בסביבת Airflow 3 ובודקים אם ההרצה הושלמה בהצלחה.

  5. בהתאם לשאלה אם הרצת ה-DAG הצליחה:

    • אם ההרצה של ה-DAG מצליחה, אפשר להמשיך ולהשתמש ב-DAG מהסביבה של Airflow 3. בסופו של דבר, כדאי למחוק את גרסת Airflow 2 של ה-DAG.

    • אם הפעלת ה-DAG נכשלה, צריך לנסות לפתור את הבעיה ב-DAG עד שהיא תפעל בהצלחה ב-Airflow 3.

      במקרה הצורך, תמיד אפשר לחזור לגרסה Airflow 2 של ה-DAG:

      1. משהים את ה-DAG בסביבת Airflow 3.

      2. מבטלים את ההשהיה של ה-DAG בסביבת Airflow 3. הפעולה הזו מתזמנת הפעלה חדשה של DAG לאותו תאריך ולאותה שעה של הפעלת ה-DAG שנכשלה.

      3. כשמוכנים להמשיך עם גרסה Airflow 3 של ה-DAG, משנים את תאריך ההתחלה, מעלים את הגרסה החדשה של ה-DAG לסביבת Airflow 3 וחוזרים על התהליך.

שלב 10: מעקב אחרי סביבת Airflow 3

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

המאמרים הבאים