פיתוח צינורות כולל שלבים ומשימות שונים, כמו פיתוח קוד, בדיקה והעברה לסביבת הייצור. במסמך הזה מוסבר:
- שיקולים לגבי אינטגרציה רציפה (CI) ופיתוח רציף (CD) לתמיכה בגרסאות build אוטומטיות, בבדיקות ובפריסת צינורות עיבוד נתונים בסביבות שונות.
- תכונות של Dataflow לאופטימיזציה של הביצועים וניצול המשאבים בסביבת הייצור.
- גישות ונקודות מעקב לעדכון צינורות עיבוד נתונים בסטרימינג בסביבת ייצור.
- שיטות מומלצות לשיפור האמינות של צינורות עיבוד נתונים בסביבת ייצור.
אינטגרציה רציפה (CI)
שילוב רציף (CI) מחייב את המפתחים למזג קוד למאגר משותף לעיתים קרובות, וזה שימושי לאפליקציות שמשתנות הרבה, כמו אתרים שמתעדכנים לעיתים קרובות. למרות שצינורות עיבוד נתונים לא משתנים בדרך כלל כמו סוגים אחרים של אפליקציות, שיטות CI מספקות יתרונות רבים לפיתוח צינורות עיבוד נתונים. לדוגמה, אוטומציה של בדיקות מספקת משוב מהיר כשנתקלים בפגמים ומקטינה את הסיכוי שרגרסיות ייכנסו לבסיס הקוד.
אוטומציה של בדיקות היא חלק חשוב מ-CI. כשמשלבים את התכונה הזו עם כיסוי בדיקות מתאים, אפשר להריץ את חבילת הבדיקות בכל שליחת קוד. שרת ה-CI יכול לפעול בשילוב עם כלי לאוטומציה של בנייה כמו Maven כדי להריץ את חבילת הבדיקות כאחד או יותר מהשלבים של צינור ה-CI. אפשר לארוז קוד שעובר בהצלחה בדיקות יחידה ובדיקות שילוב, ולהפוך אותו לארטיפקטים של פריסה שמפעילים צינורות. הגרסה הזו נקראת גרסה שעברה בהצלחה.
המספר והסוגים של ארטיפקטים של פריסה שנוצרו מ-build שעבר בהצלחה משתנים בהתאם לאופן ההפעלה של צינורות. באמצעות Apache Beam Java SDK, אפשר לארוז את קוד צינור הנתונים בקובץ JAR להפעלה עצמית. אחר כך אפשר לאחסן את קובץ ה-JAR בדלי שמארח את הפרויקט של סביבת הפריסה, כמו פרויקט הטרום-ייצור או הייצור Google Cloud . אם משתמשים ב-Classic Templates (סוג של הפעלה מבוססת תבנית), פריטי הארכיטקט של הפריסה כוללים קובץ תבנית JSON, קובץ JAR של הצינור ותבנית מטא-נתונים אופציונלית. לאחר מכן אפשר לפרוס את הארטיפקטים בסביבות פריסה שונות באמצעות אספקה רציפה, כמו שמוסבר בקטע הבא.
פיתוח רציף (continuous delivery) ופריסה רציפה (continuous deployment)
פיתוח רציף (CD) מעתיק פריטי פריסה לסביבת פריסה אחת או יותר שמוכנות להפעלה ידנית. בדרך כלל, הארטיפקטים שנבנו על ידי שרת ה-CI נפרסים בסביבת טרום-ייצור אחת או יותר כדי להריץ בדיקות מקצה לקצה. סביבת הייצור מתעדכנת אם כל הבדיקות מקצה לקצה עוברות בהצלחה.
בצינורות לעיבוד נתונים באצווה, פריסה רציפה יכולה להפעיל את הצינור ישירות כעבודת Dataflow חדשה. לחלופין, מערכות אחרות יכולות להשתמש בפריטי ה-Artifact כדי להפעיל עבודות אצווה כשנדרש. לדוגמה, אתם יכולים להשתמש ב-Managed Service for Apache Airflow כדי להריץ משימות באצווה בתהליך עבודה, או ב-Cloud Scheduler כדי לתזמן משימות באצווה.
יכול להיות שהפריסה של צינורות להזרמת נתונים תהיה מורכבת יותר מאשר הפריסה של צינורות לעיבוד נתונים באצווה, ולכן יכול להיות שיהיה קשה יותר להפוך אותה לאוטומטית באמצעות פריסה רציפה. לדוגמה, יכול להיות שתצטרכו להבין איך להחליף או לעדכן צינור נתונים קיים להזרמת נתונים. אם אתם לא יכולים לעדכן צינור נתונים, או אם אתם בוחרים לא לעדכן אותו, אתם יכולים להשתמש בשיטות אחרות, כמו תיאום של כמה משימות Dataflow, כדי למזער או למנוע שיבושים בפעילות העסקית.
זהויות ותפקידים שנדרשים ל-CI/CD
צינור ה-CI/CD שלכם מקיים אינטראקציה עם מערכות שונות כדי לבנות, לבדוק ולפרוס צינורות. לדוגמה, לצינור העברת הנתונים צריך להיות גישה למאגר קוד המקור. כדי לאפשר את האינטראקציות האלה, צריך לוודא שלצינור יש את הזהויות והתפקידים המתאימים. יכול להיות שפעילויות הצינור הבאות ידרשו גם הן שהצינור יכלול זהויות ותפקידים ספציפיים.
בדיקות שילוב עם שירותים חיצוניים, כולל Google Cloud
כשמשתמשים ב-Direct Runner להרצת בדיקות אד-הוק או בדיקות שילוב מערכות, צינור הנתונים משתמש ב-Application Default Credentials (ADC) כדי לקבל פרטי כניסה. הגדרת ADC משתנה בהתאם למקום שבו מריצים את צינור העיבוד. מידע נוסף זמין במאמר בנושא הגדרה של Application Default Credentials.
חשוב לוודא שלחשבון השירות שמשמש לקבלת פרטי כניסה למשאביGoogle Cloud שאליהם יש לצינור עיבוד הנתונים גישה יש תפקידים והרשאות מספיקים.
פריסת ארטיפקטים בסביבות פריסה שונות
כשאפשר, כדאי להשתמש בפרטי כניסה ייחודיים לכל סביבה (כלומר לכל פרויקט) ולהגביל את הגישה למשאבים בהתאם.
משתמשים בחשבונות שירות ייחודיים לכל פרויקט כדי לקרוא ולכתוב ארטיפקטים של פריסה בדלי אחסון. יכול להיות שתהליך הפריסה יצטרך להכין כמה ארטיפקטים, בהתאם לכך אם צינור עיבוד הנתונים משתמש בתבנית. לדוגמה, יצירה של תבנית Dataflow והעברה שלה לשלב ההכנה מחייבת הרשאות לכתיבת ארטיפקטים של פריסה שנדרשים להפעלת צינור הנתונים, כמו קובץ התבנית של צינור הנתונים, לקטגוריה של Cloud Storage.
פריסת צינורות עיבוד נתונים לסביבות פריסה שונות
במקרים שבהם אפשר, משתמשים בחשבונות שירות ייחודיים לכל פרויקט כדי לגשת למשאבים בתוך הפרויקט ולנהל אותם Google Cloud , כולל גישה ל-Dataflow עצמו.
לחשבון השירות שבו אתם משתמשים כדי ליצור ולנהל משימות Dataflow צריכות להיות הרשאות IAM מספיקות לניהול משימות. פרטים נוספים זמינים בקטע חשבון השירות של Dataflow בדף בנושא אבטחה והרשאות ב-Dataflow.
לחשבון השירות של העובד שמשמש להרצת משימות Dataflow צריכה להיות הרשאה לנהל משאבי Compute Engine בזמן שהמשימה פועלת, ולנהל את האינטראקציה בין צינור העיבוד של Apache Beam לבין שירות Dataflow. פרטים מופיעים בקטע חשבון שירות של Worker בדף בנושא אבטחה והרשאות ב-Dataflow.
כדי לציין חשבון שירות של עובד (worker) שמנוהל על ידי משתמש למשימה, משתמשים ב--serviceAccount אפשרות של צינור עיבוד הנתונים.
אם לא מציינים חשבון שירות של Worker כשיוצרים עבודה, Dataflow מנסה להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.
במקום זאת, אנחנו ממליצים לציין חשבון שירות של עובד (worker) שמנוהל על ידי המשתמש עבור סביבות Production, כי לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine יש בדרך כלל הרשאות רחבות יותר מההרשאות שנדרשות לעבודות Dataflow.
בתרחישי ייצור, מומלץ להשתמש בחשבונות שירות נפרדים לניהול משימות Dataflow ולחשבון השירות של העובד. כך האבטחה משופרת בהשוואה לשימוש בחשבון שירות יחיד. לדוגמה, יכול להיות שחשבון השירות שמשמש ליצירת משימות Dataflow לא צריך לגשת למקורות וליעדים של נתונים, או להשתמש במשאבים אחרים שמשמשים את הצינור. בתרחיש הזה, לחשבון השירות של העובד שמשמש להרצת משימות Dataflow מוענקות הרשאות להשתמש במשאבי צינור. לחשבון שירות אחר ליצירת משימות מוענקות הרשאות לניהול משימות Dataflow (כולל יצירה).
דוגמה לצינור עיבוד נתונים של CI/CD
בתרשים הבא מוצגת סקירה כללית של CI/CD לצינורות עיבוד נתונים, ללא התייחסות לכלי ספציפי. בנוסף, בתרשים מוצג הקשר בין משימות פיתוח, סביבות פריסה והרצת צינורות.
בתרשים מוצגים השלבים הבאים:
פיתוח קוד: במהלך פיתוח הקוד, מפתח מריץ קוד של צינור מקומית באמצעות Direct Runner. בנוסף, מפתחים משתמשים בסביבת ארגז חול להרצת צינורות עיבוד נתונים אד-הוק באמצעות Dataflow Runner.
בצינורות עיבוד נתונים טיפוסיים של CI/CD, תהליך האינטגרציה הרציפה מופעל כשמפתח מבצע שינוי במערכת לבקרת מקורות, למשל כשמבצעים דחיפה של קוד חדש למאגר.
פיתוח ובדיקה: בתהליך האינטגרציה הרציפה, קוד צינור הנתונים עובר קומפילציה ואז מופעלות בדיקות יחידה ובדיקות אינטגרציה של טרנספורמציות באמצעות Direct Runner. אפשר גם להריץ בדיקות אופציונליות של שילוב מערכות, כולל בדיקות שילוב עם מקורות חיצוניים ועם יעדים באמצעות מערכי נתונים קטנים לבדיקה.
אם הבדיקות מצליחות, תהליך ה-CI שומר את ארטיפקטי הפריסה, שיכולים לכלול קובצי JAR, תמונות Docker ומטא-נתונים של תבניות, שנדרשים להפעלת הצינור למיקומים שאפשר לגשת אליהם בתהליך של אספקה רציפה. בהתאם לסוגי ארטיפקטים הפריסה שנוצרים, יכול להיות שתשתמשו ב-Cloud Storage וב-Artifact Registry כדי לאחסן את סוגי הארטיפקטים השונים.
מסירה ופריסה: בתהליך של פיתוח רציף, מתבצעת העתקה של ארטיפקטים של פריסה לסביבת טרום-ייצור, או שהארטיפקטים האלה הופכים לזמינים לשימוש בסביבה הזו. מפתחים יכולים להריץ באופן ידני בדיקות מקצה לקצה באמצעות Dataflow Runner, או להשתמש בפריסה רציפה כדי להתחיל את הבדיקה באופן אוטומטי. בדרך כלל, קל יותר להפעיל גישה לפריסה רציפה בצינורות עיבוד נתונים של אצווה מאשר בצינורות עיבוד נתונים של סטרימינג. צינורות להעברת נתונים באצווה לא פועלים באופן רציף, ולכן קל יותר להחליף אותם בגרסה חדשה.
תהליך העדכון של צינורות הנתונים לסטרימינג יכול להיות פשוט או מורכב, ומומלץ לבדוק את העדכונים בסביבת טרום-ייצור. יכול להיות שפרוצדורות העדכון לא יהיו עקביות בין הגרסאות. לדוגמה, יכול להיות שצינור יתעדכן באופן שלא יאפשר עדכונים במקום. לכן, לפעמים קשה לבצע אוטומציה של עדכוני צינורות באמצעות פריסה רציפה.
אם כל הבדיקות מקצה לקצה עוברות בהצלחה, אפשר להעתיק את פריטי הפריסה או להפוך אותם לזמינים בסביבת הייצור כחלק מתהליך האספקה הרציפה. אם צינור הנתונים החדש מעדכן או מחליף צינור נתונים קיים של סטרימינג, צריך להשתמש בהליכים שנבדקו בסביבת טרום-ייצור כדי לפרוס את צינור הנתונים החדש.
השוואה בין ביצוע משימות ללא תבנית לבין ביצוע משימות עם תבנית
אפשר ליצור משימת Dataflow באמצעות Apache Beam SDK ישירות מסביבת פיתוח. סוג כזה של עבודה נקרא עבודה לא מבוססת-תבנית. הגישה הזו נוחה למפתחים, אבל יכול להיות שתעדיפו להפריד בין המשימות של פיתוח צינורות העברת נתונים והרצה שלהם. כדי לבצע את ההפרדה הזו, אפשר להשתמש בתבניות Dataflow, שמאפשרות להכין ולהריץ את צינורות עיבוד הנתונים כמשימות עצמאיות. אחרי שתבנית הועברה לסביבת Staging, משתמשים אחרים, כולל משתמשים שאינם מפתחים, יכולים להריץ את העבודות מהתבנית באמצעות Google Cloud CLI, מסוףGoogle Cloud או Dataflow API בארכיטקטורת REST.
Dataflow מציע את סוגי תבניות העבודות הבאים:
- תבניות קלאסיות: מפתחים משתמשים ב-Apache Beam SDK כדי להריץ את קוד צינור הנתונים ולשמור את גרף הביצוע בסדרת JSON כתבנית. Apache Beam SDK מעביר את קובץ התבנית למיקום ב-Cloud Storage, יחד עם כל התלויות שנדרשות על ידי קוד צינור הנתונים.
- תבניות גמישות: מפתחים משתמשים ב-Google Cloud CLI כדי לארוז את הפייפליין כקובץ אימג' של Docker, שמאוחסן ב-Artifact Registry. בנוסף, נוצר באופן אוטומטי קובץ מפרט של Flex Template והוא מאוחסן במיקום ב-Cloud Storage שצוין על ידי המשתמש. קובץ המפרט של תבנית Flex מכיל מטא-נתונים שמתארים איך להריץ את התבנית, כמו פרמטרים של צינורות.
בנוסף לתכונות של תבניות Flex שמפורטות במסמכי התיעוד המקושרים, תבניות Flex מציעות יתרונות על פני תבניות קלאסיות בניהול תבניות.
- בתבניות קלאסיות, יכול להיות שכמה ארטיפקטים, כמו קובצי JAR, מאוחסנים במיקום זמני ב-Cloud Storage, אבל אין תכונות לניהול של כמה ארטיפקטים כאלה. לעומת זאת, תבנית Flex מוכלת בקובץ אימג' של Docker. התמונה כוללת את כל יחסי התלות, מלבד מפרט FlexTemplate, שנדרשים לצינור שלכם בארטיפקט פריסה אחד שמנוהל על ידי Artifact Registry.
- אתם יכולים להשתמש בתכונות לניהול קובצי אימג' של Docker בתבניות Flex. לדוגמה, אפשר לשתף בבטחה תבניות Flex על ידי מתן הרשאות משיכה (ובאופן אופציונלי גם הרשאות דחיפה) ל-Artifact Registry, ולהשתמש בתגי קובצי אימג' של Docker לגרסאות שונות של תבניות Flex.
מפתחים יכולים להשתמש בתבניות קלאסיות ובתבניות גמישות כדי להפעיל משימות בפרויקט ששונה מהפרויקט שבבעלותו נמצאת המאגר והקטגוריה לאחסון שמארחים את נכסי התבנית, או רק הקטגוריה לאחסון אם משתמשים בתבניות קלאסיות. התכונה הזו שימושית אם אתם צריכים לבודד את עיבוד הנתונים של כמה לקוחות לפרויקטים שונים ולמשימות שונות בצינורות. באמצעות תבניות Flex, אפשר לציין גרסאות שונות של קובץ אימג' של Docker לשימוש כשמפעילים צינור עיבוד נתונים. התכונה הזו מפשטת את ההחלפה בשלבים של צינורות לעיבוד אצווה או צינורות לעיבוד נתונים בזמן אמת בכמה פרויקטים כשמעדכנים תבניות בהמשך.
תכונות של Dataflow לאופטימיזציה של השימוש במשאבים
Dataflow מספק את התכונות הבאות שספציפיות ל-Runner כדי לבצע אופטימיזציה של השימוש במשאבים, וכך לשפר את הביצועים ולהפחית את העלויות:
- Streaming Engine: Streaming Engine מעביר את ההפעלה של צינורות עיבוד נתונים של סטרימינג מתוך מכונות וירטואליות של עובדים אל שירות ייעודי. היתרונות כוללים שיפור בתגובה להתאמה אוטומטית לעומס, צמצום המשאבים של worker VM שנצרכים ועדכוני שירות אוטומטיים ללא פריסה מחדש. במקרים מסוימים, אפשר גם לצמצם את השימוש במשאבים באמצעות עיבוד של לפחות פעם אחת לתרחישי שימוש שיכולים לסבול כפילויות. מומלץ להפעיל את מנוע הסטרימינג לצינורות עיבוד נתונים בסטרימינג. התכונה מופעלת כברירת מחדל כשמשתמשים בגרסאות העדכניות של Apache Beam Java SDK או Python SDK.
- Dataflow Shuffle: שירות ארגון הנתונים של Dataflow מעביר פעולות ארגון נתונים של צינורות עיבוד נתונים של אצווה ממכונות וירטואליות (VM) של עובדים לשירות ייעודי. היתרונות כוללים הרצה מהירה יותר של רוב פייפליינים של אצווה, צריכת משאבים מופחתת על ידי worker VMs, שיפור התגובה של התאמה אוטומטית לעומס ושיפור העמידות בפני תקלות. מומלץ להפעיל מיון נתונים (Shuffle) ב-Dataflow לצינורות עיבוד נתונים באצווה. התכונה מופעלת כברירת מחדל באמצעות Apache Beam Java SDK ו-Python SDK העדכני.
- Flexible resource scheduling (FlexRS): FlexRS מפחית את עלויות העיבוד באצווה באמצעות טכניקות מתקדמות לתזמון, שירות Dataflow Shuffle ושילוב של מכונות וירטואליות שניתנות להפסקת פעולה ומכונות וירטואליות רגילות.
עדכון צינורות עיבוד נתונים בסטרימינג בסביבת הייצור
איך משדרגים צינור עיבוד נתונים בסטרימינג
מחזור החיים של משימה ב-Dataflow
משימת Dataflow עוברת מחזור חיים שמיוצג על ידי מצבי משימה שונים.
כדי להריץ משימת Dataflow, שולחים אותה לאזור.
לאחר מכן, המשימה מנותבת לבק-אנד זמין של Dataflow באחד מהתחומים באזור. לפני ש-Dataflow מקצה קצה עורפי, המערכת מוודאת שיש לכם מספיק מכסות והרשאות להפעלת העבודה. אחרי שבדיקות הטרום-טיסה האלה מסתיימות ומוקצה קצה עורפי, העבודה עוברת למצב JOB_STATE_PENDING. במשימות של FlexRS, יכול להיות שההקצאה של ה-Backend תתעכב לזמן מאוחר יותר, והמשימות האלה יעברו למצב JOB_STATE_QUEUED.
הקצה העורפי שהוקצה מקבל את העבודה להרצה ומנסה להפעיל עובדי Dataflow בפרויקט Google Cloud . האזור שנבחר למכונות הווירטואליות של העובדים תלוי במספר גורמים. לגבי עבודות באצווה שמשתמשות ב-ארגון נתונים של Dataflow, השירות גם מנסה לוודא שהבק-אנד של Dataflow וה-worker VMs ממוקמים באותו תחום (zone) כדי למנוע תעבורת נתונים בין תחומים.
אחרי שהעובדים של Dataflow מתחילים, הם שולחים בקשה לעבודה מהקצה העורפי של Dataflow. הקצה העורפי אחראי לפיצול העבודה לחלקים שניתן להריץ במקביל, שנקראים חבילות, שמופצים בין העובדים. אם ה-workers לא יכולים לטפל בעבודה הקיימת, ואם מופעלת התכונה של התאמה אוטומטית לעומס (automatic scaling), ה-בק-אנד מפעיל עוד workers כדי לטפל בעבודה. באופן דומה, אם מפעילים יותר עובדים מהנדרש, חלק מהעובדים מושבתים.
אחרי שהתהליך מתחיל, ה-backend של Dataflow פועל כמישור הבקרה כדי לתזמן את הביצוע של העבודה. במהלך העיבוד, מישור הנתונים של המשימה מבצע פעולות ערבוב כמו GroupByKey, CoGroupByKey ו-Combine.
עבודות משתמשות באחת מההטמעות הבאות של מישור הנתונים לפעולות של ערבוב:
- מישור הנתונים פועל בתהליכי העבודה של Dataflow, ונתוני ה-Shuffle מאוחסנים בדיסקים קבועים.
- מישור הנתונים פועל כשירות, והוא מופרד ממכונות ה-VM של העובדים. להטמעה הזו יש שני וריאנטים, ואתם מציינים אותם כשאתם יוצרים את העבודה: ארגון נתונים של Dataflow לצינורות עיבוד נתונים באצווה ו-Streaming Engine לצינורות עיבוד נתונים בסטרימינג. הערבוב מבוסס-השירות משפר באופן משמעותי את הביצועים ואת יכולת ההתאמה של פעולות ערבוב הנתונים בהשוואה לערבוב מבוסס-העובד.
משימות של סטרימינג שנכנסות למצב JOB_STATE_RUNNING ממשיכות לפעול ללא הגבלת זמן עד שהן מבוטלות או מרוקנות, אלא אם מתרחש כשל במשימה. משימות אצווה נעצרות אוטומטית כשכל העיבוד מסתיים או אם מתרחשת שגיאה שלא ניתן לתקן. בהתאם לאופן שבו המשימה נעצרת, Dataflow מגדיר את הסטטוס של המשימה לאחד מכמה סטטוסים סופיים, כולל JOB_STATE_CANCELLED, JOB_STATE_DRAINED או JOB_STATE_DONE.
שיטות מומלצות לאמינות של צינורות עיבוד נתונים
בקטע הזה נדון בכשלים שעשויים להתרחש כשעובדים עם Dataflow, ובשיטות מומלצות לעבודות Dataflow.
פועלים לפי עקרונות הבידוד
המלצה כללית לשיפור האמינות הכוללת של צינור הנתונים היא לפעול לפי עקרונות הבידוד שמאחורי אזורים ואזורי זמינות. מוודאים שלצינורות אין תלות קריטית באזורים שונים. אם יש לכם צינור עיבוד נתונים עם תלות קריטית בשירותים מכמה אזורים, כשל באחד מהאזורים האלה יכול להשפיע על צינור עיבוד הנתונים. כדי למנוע את הבעיה הזו, מומלץ לפרוס למספר אזורים כדי ליצור יתירות וגיבוי.
יצירת תמונות מצב של Dataflow
Dataflow מציע תכונה של תמונת מצב שמאפשרת ליצור גיבוי של מצב צינור הנתונים. אפשר לשחזר את תמונת המצב של צינור העברת הנתונים לצינור חדש של Dataflow להזרמת נתונים באזור או באזור אחר. לאחר מכן, אפשר להתחיל את העיבוד מחדש של ההודעות בנושאי Pub/Sub או Kafka החל מחותמת הזמן של התמונה. אם מגדירים צילומי מצב קבועים של צינורות הנתונים, אפשר למזער את הזמן של יעד זמן השחזור (RTO).
מידע נוסף על תמונות מצב של Dataflow
טיפול בשגיאות בשליחת משרות
שולחים משימות Dataflow שלא מבוססות על תבנית באמצעות Apache Beam SDK. כדי לשלוח את המשימה, מריצים את צינור עיבוד הנתונים באמצעות Dataflow Runner, שמוגדר כחלק מהאפשרויות של צינור עיבוד הנתונים. ערכת ה-SDK של Apache Beam מעבירה קבצים למחסן ביניים ב-Cloud Storage, יוצרת קובץ בקשה למשימה ושולחת את הקובץ ל-Dataflow.
לחלופין, משימות שנוצרו מתבניות Dataflow משתמשות בשיטות שונות לשליחה, שמסתמכות בדרך כלל על Templates API.
יכול להיות שיוחזרו שגיאות שונות מ-Dataflow שמצביעות על כשל במשימה עבור משימות של תבניות ומשימות שלא מבוססות על תבניות. בקטע הזה נדון בסוגים שונים של כשלים בשליחת משימות ובשיטות מומלצות לטיפול בהם או לצמצום שלהם.
ניסיון חוזר לשליחת עבודות אחרי כשלים זמניים
אם משימה לא מתחילה לפעול בגלל בעיה בשירות Dataflow, כדאי לנסות להפעיל אותה מחדש כמה פעמים. ניסיון חוזר יכול לפתור בעיות זמניות בשירות.
צמצום הסיכון לכשלים אזוריים על ידי ציון אזור של עובד
Dataflow מספק זמינות אזורית וזמין במספר אזורים. כשמשתמש שולח עבודה לאזור בלי לציין במפורש אזור, Dataflow מנתב את העבודה לאזור באזור שצוין על סמך זמינות המשאבים.
האפשרות המומלצת למיקום משימות היא לציין אזור של עובד באמצעות הדגל --region במקום הדגל --zone, ככל האפשר. השלב הזה מאפשר ל-Dataflow לספק רמה נוספת של עמידות בפני תקלות לצינורות הנתונים, על ידי בחירה אוטומטית של האזור הכי טוב למשימה. היתרון הזה לא חל על משימות שבהן מצוין אזור באופן מפורש, והן ייכשלו אם יתרחשו בעיות באזור. אם שליחת משימה נכשלת בגלל בעיה אזורית, לרוב אפשר לפתור את הבעיה על ידי ניסיון חוזר לשלוח את המשימה בלי לציין אזור באופן מפורש.
צמצום הסיכון לכשלים אזוריים על ידי אחסון נתונים בכמה אזורים
אם אזור שלם לא זמין, כדאי לנסות להריץ את העבודה באזור אחר. חשוב לחשוב על הזמינות של הנתונים במקרים של כשלים במשימות באזורים שונים. כדי להגן על הנתונים מפני תקלות באזור יחיד בלי להעתיק אותם ידנית לכמה אזורים, כדאי להשתמש במשאבים שמאחסנים את הנתונים באופן אוטומטי בכמה אזורים. Google Cloud לדוגמה, אפשר להשתמש בקטגוריות של Cloud Storage בשני אזורים ובמספר אזורים. אם אזור אחד הופך ללא זמין, אפשר להריץ מחדש את צינור הנתונים באזור אחר שבו הנתונים זמינים.
דוגמה לשימוש בשירותים מרובי-אזורים עם Dataflow מופיעה במאמר בנושא זמינות גבוהה ויתירות גיאוגרפית.
טיפול בכשלים בהפעלת צינורות
אחרי ששולחים עבודה ומקבלים אותה, הפעולות התקינות היחידות שאפשר לבצע בעבודה הן:
- ביטול של משימות אצווה
- עדכון, ניקוי או ביטול של משימות סטרימינג
אי אפשר לשנות את המיקום של משימות פעילות אחרי ששולחים את המשימה. אם אתם לא משתמשים ב-FlexRS, בדרך כלל העיבוד של הנתונים מתחיל תוך כמה דקות אחרי השליחה. יכולות לעבור עד שש שעות עד שיתחיל עיבוד הנתונים בעבודות FlexRS.
בקטע הזה נדון בכשלים בהרצת משימות ובשיטות מומלצות לטיפול בהם.
מעקב אחרי עבודות כדי לזהות ולפתור בעיות שנגרמות משגיאות זמניות
לגבי משימות באצווה, המערכת מנסה שוב ארבע פעמים חבילות שכוללות פריט שנכשל. Dataflow מפסיק את העבודה אם חבילה אחת נכשלה ארבע פעמים. התהליך הזה מטפל בהרבה בעיות זמניות. עם זאת, אם מתרחש כשל ממושך, בדרך כלל מגיעים במהירות למגבלת הניסיונות החוזרים המקסימלית, מה שמאפשר לכשל להתרחש במהירות.
לצורך מעקב וניהול אירועים, מגדירים כללי התראה לזיהוי משימות שנכשלו. אם משימה נכשלת, צריך לבדוק את יומני המשימות כדי לזהות כשלים במשימות שנגרמו בגלל פריטי עבודה שנכשלו וחריגה ממגבלת הניסיונות החוזרים.
במשימות סטרימינג, Dataflow מנסה שוב ושוב לבצע פריטי עבודה שנכשלו, ללא הגבלה. העבודה לא מסתיימת. עם זאת, יכול להיות שהעבודה תיעצר עד שהבעיה תיפתר. יצירת כללי מדיניות למעקב כדי לזהות סימנים של צינור נתונים תקוע, כמו עלייה בחביון המערכת וירידה בעדכניות הנתונים. כדי לזהות צווארי בקבוק בצינור שנובעים מפריטי עבודה שנכשלים שוב ושוב, כדאי להטמיע רישום שגיאות בקוד של צינור הנתונים.
הפעלה מחדש של משימות באזור אחר אם מתרחשת הפסקת חשמל באזור
אחרי שהעבודה מתחילה, עובדי Dataflow שמריצים קוד משתמש מוגבלים לאזור אחד. אם מתרחש הפסקת חשמל אזורית, לרוב היא משפיעה על משימות Dataflow, בהתאם להיקף ההפסקה.
במקרים של הפסקות שמשפיעות רק על שרתים עורפיים של Dataflow, השירות המנוהל מעביר את השרתים העורפיים באופן אוטומטי לאזור אחר כדי שהעבודה תוכל להימשך. אם העבודה משתמשת ב-ארגון נתונים של Dataflow, אי אפשר להעביר את ה-Backend בין אזורים. אם מתבצעת העברה של קצה עורפי של Dataflow, יכול להיות שהעבודות ייעצרו באופן זמני.
אם מתרחש הפסקת חשמל אזורית, סביר להניח שהעבודות הפעילות ייכשלו או ייעצרו עד שהזמינות של האזור תשוחזר. אם אזור מסוים לא זמין למשך תקופה ארוכה, צריך להפסיק את העבודות (ביטול לעבודות באצווה וניקוי לעבודות בסטרימינג) ואז להפעיל אותן מחדש כדי לאפשר ל-Dataflow לבחור אזור חדש תקין.
הפעלה מחדש של עבודות אצווה באזור אחר אם מתרחשת הפסקת חשמל אזורית
אם מתרחש שיבוש אזורי באזור שבו משימות Dataflow פועלות, יכול להיות שהמשימות ייכשלו או ייעצרו. לגבי עבודות באצווה, מפעילים מחדש את העבודה באזור אחר אם אפשר. חשוב לוודא שהנתונים זמינים באזורים שונים.
להפחית את הסיכון להפסקות חשמל אזוריות באמצעות זמינות גבוהה או מעבר לגיבוי בעת כשל
במשימות סטרימינג, יש אפשרויות שונות לצמצום הסיכון לכשלים, בהתאם לסובלנות לתקלות ולתקציב של האפליקציה. במקרה של הפסקת חשמל אזורית, האפשרות הפשוטה והמשתלמת ביותר היא להמתין עד שההפסקה תסתיים. עם זאת, אם האפליקציה שלכם רגישה לזמן אחזור או אם עיבוד הנתונים לא יכול להיות מופרע או צריך להתחדש עם עיכוב מינימלי, האפשרויות מפורטות בקטעים הבאים.
זמינות גבוהה: רגישות לזמן אחזור ללא אובדן נתונים
אם האפליקציה לא יכולה לסבול אובדן נתונים, צריך להפעיל צינורות כפולים במקביל בשני אזורים שונים, ולגרום לצינורות לצרוך את אותם נתונים. אותם מקורות נתונים צריכים להיות זמינים בשני האזורים. אפליקציות במורד הזרם שתלויות בפלט של צינורות העיבוד האלה צריכות להיות מסוגלות לעבור בין הפלט משני האזורים האלה. בגלל השכפול של המשאבים, האפשרות הזו כרוכה בעלות הגבוהה ביותר בהשוואה לאפשרויות אחרות. דוגמה לפריסה מופיעה בקטע זמינות גבוהה ויתירות גיאוגרפית.
מעבר לגיבוי: רגישות לזמן הטעינה עם אובדן נתונים פוטנציאלי
אם האפליקציה יכולה להתמודד עם אובדן נתונים פוטנציאלי, כדאי להפוך את מקור הנתונים של הסטרימינג לזמין בכמה אזורים. לדוגמה, באמצעות Pub/Sub, אפשר לשמור על שני מינויים עצמאיים לאותו נושא, אחד לכל אזור. אם מתרחש הפסקת שירות אזורית, צריך להפעיל פייפליין חלופי באזור אחר, ולגרום לפייפליין לצרוך נתונים ממינוי הגיבוי.
הפעלה מחדש של מינוי הגיבוי לזמן המתאים כדי למזער את אובדן הנתונים בלי לפגוע בזמן האחזור. אפליקציות במורד הזרם צריכות לדעת איך לעבור לפלט של צינור הנתונים הפועל, בדומה לאפשרות של זמינות גבוהה. האפשרות הזו משתמשת בפחות משאבים מאשר הפעלת צינורות כפולים, כי רק הנתונים משוכפלים.
זמינות גבוהה ויתירות גיאוגרפית
אפשר להריץ כמה צינורות עיבוד נתונים של סטרימינג במקביל כדי לעבד נתונים בזמינות גבוהה. לדוגמה, אתם יכולים להריץ שתי משימות מקבילות של סטרימינג באזורים שונים, וכך ליהנות מיתירות גיאוגרפית ומסובלנות לתקלות בעיבוד הנתונים.
אם תביאו בחשבון את הזמינות הגיאוגרפית של מקורות ושל יעדי נתונים, תוכלו להפעיל צינורות נתונים מקצה לקצה בהגדרה של זמינות גבוהה וריבוי אזורים. בתרשים הבא מוצגת פריסה לדוגמה.
בתרשים מוצג התהליך הבא:
Pub/Sub פועל ברוב האזורים בעולם, ולכן השירות מציע גישה מהירה לנתונים גלובליים, תוך מתן שליטה במיקום שבו ההודעות מאוחסנות. Pub/Sub יכול לאחסן באופן אוטומטי הודעות שפורסמו באזור Google Cloud הקרוב ביותר למנויים, או שאתם יכולים להגדיר אותו לשימוש באזור ספציפי או בקבוצה ספציפית של אזורים באמצעות מדיניות אחסון הודעות.
לאחר מכן, שירות Pub/Sub מעביר את ההודעות למנויים ברחבי העולם, בלי קשר למקום שבו ההודעות מאוחסנות. לקוחות Pub/Sub לא צריכים לדעת את מיקומי השרתים שאליהם הם מתחברים, כי מנגנוני איזון עומסים גלובליים מפנים את התנועה למרכז הנתונים הקרוב ביותר שלGoogle Cloud שבו מאוחסנות ההודעות.
Dataflow פועל באזורים ספציפיים Google Cloud . הפעלת צינורות מקבילים ב Google Cloud אזורים נפרדים מאפשרת לבודד את העבודות מכשלים שמשפיעים על אזור יחיד. בתרשים מוצגים שני מופעים של אותו צינור, כל אחד פועל באזור Google Cloud נפרד.
צינורות Dataflow מקבילים כותבים לשני אזורים נפרדים ב-BigQuery, וכך מספקים יתירות גיאוגרפית. באזור מסוים, BigQuery מאחסן באופן אוטומטי עותקים של הנתונים שלכם בשני אזורים שונים של Google Cloud . מידע נוסף זמין במאמר תכנון התאוששות מאסון במאמרי העזרה של BigQuery.