פיתוח צינורות כולל שלבים ומשימות שונים, כמו פיתוח קוד, בדיקה והעברה לסביבת הייצור. במסמך הזה נסביר:
- שיקולים לגבי אינטגרציה רציפה (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 חדשה. לחלופין, מערכות אחרות יכולות להשתמש בארטיפקטים כדי להפעיל משימות אצווה כשנדרש. לדוגמה, אפשר להשתמש ב-Cloud Composer כדי להריץ משימות אצווה בתהליך עבודה, או ב-Cloud Scheduler כדי לתזמן משימות אצווה.
יכול להיות שהפריסה של צינורות סטרימינג תהיה מורכבת יותר מאשר הפריסה של צינורות אצווה, ולכן יכול להיות שיהיה קשה יותר לבצע אוטומציה באמצעות פריסה רציפה. לדוגמה, יכול להיות שתצטרכו להבין איך להחליף או לעדכן צינור נתונים קיים להזרמה. אם אתם לא יכולים לעדכן את צינור הנתונים, או אם אתם בוחרים שלא לעדכן אותו, אתם יכולים להשתמש בשיטות אחרות, כמו תיאום של כמה משימות Dataflow, כדי למזער או למנוע שיבושים בפעילות העסקית.
זהויות ותפקידים שנדרשים ל-CI/CD
צינור ה-CI/CD שלכם מקיים אינטראקציה עם מערכות שונות כדי לבנות, לבדוק ולפרוס צינורות. לדוגמה, לצינור העברת הנתונים צריך להיות גישה למאגר קוד המקור. כדי לאפשר את האינטראקציות האלה, צריך לוודא שלצינור יש את הזהויות והתפקידים המתאימים. יכול להיות שפעילויות הצינור הבאות ידרשו גם הן שהצינור יכלול זהויות ותפקידים ספציפיים.
בדיקות שילוב עם שירותים חיצוניים, כולל Google Cloud Platform
כשמשתמשים ב-Direct Runner להרצת בדיקות אד-הוק או בדיקות שילוב מערכות, צינור הנתונים משתמש ב-Application Default Credentials (ADC) כדי לקבל פרטי כניסה. הגדרת ADC משתנה בהתאם למקום שבו מריצים את צינור העברת הנתונים. מידע נוסף זמין במאמר בנושא הגדרה של Application Default Credentials.
מוודאים שלחשבון השירות שמשמש לקבלת פרטי כניסה למשאבים של Google Cloud Platform שאליהם יש לצינור עיבוד הנתונים גישה, יש תפקידים והרשאות מספיקים.
פריסת ארטיפקטים בסביבות פריסה שונות
כשאפשר, כדאי להשתמש באמצעי אימות ייחודיים לכל סביבה (כלומר לכל פרויקט) ולהגביל את הגישה למשאבים בהתאם.
משתמשים בחשבונות שירות ייחודיים לכל פרויקט כדי לקרוא ולכתוב ארטיפקטים של פריסה בדלי אחסון. יכול להיות שתהליך הפריסה יצטרך להכין כמה ארטיפקטים, בהתאם לשימוש בתבנית בצינור עיבוד הנתונים. לדוגמה, יצירה של תבנית Dataflow והעברה שלה לסביבת Staging דורשת הרשאות לכתיבת ארטיפקטים של פריסה שנדרשים להפעלת צינור הנתונים, כמו קובץ התבנית של צינור הנתונים, לקטגוריה של Cloud Storage.
פריסת צינורות עיבוד נתונים לסביבות פריסה שונות
במקרים שבהם אפשר, משתמשים בחשבונות שירות ייחודיים לכל פרויקט כדי לגשת למשאבים בתוך הפרויקט ולנהל אותם Google Cloud , כולל גישה ל-Dataflow עצמו.
לחשבון השירות שבו משתמשים כדי ליצור ולנהל משימות Dataflow צריכות להיות הרשאות IAM מספיקות לניהול משימות. פרטים נוספים זמינים בקטע חשבון השירות של Dataflow בדף בנושא אבטחה והרשאות ב-Dataflow.
לחשבון השירות של העובד שמשמש להרצת משימות Dataflow צריכה להיות הרשאה לנהל משאבי Compute Engine בזמן שהמשימה פועלת, ולנהל את האינטראקציה בין צינור עיבוד הנתונים של Apache Beam לבין שירות Dataflow. פרטים מופיעים בקטע חשבון שירות של עובד בדף בנושא אבטחה והרשאות ב-Dataflow.
כדי לציין חשבון שירות של עובד (worker) שמנוהל על ידי משתמש למשימה, משתמשים ב--serviceAccount אפשרות של צינור עיבוד הנתונים.
אם לא מציינים חשבון שירות של Worker כשיוצרים עבודה, Dataflow מנסה להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.
במקום זאת, אנחנו ממליצים לציין חשבון שירות של עובד (worker) שמנוהל על ידי המשתמש בסביבות ייצור, כי לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine יש בדרך כלל הרשאות רחבות יותר מההרשאות שנדרשות לעבודות Dataflow.
בתרחישי ייצור, מומלץ להשתמש בחשבונות שירות נפרדים לניהול משימות Dataflow ולחשבון השירות של העובד. כך האבטחה משופרת בהשוואה לשימוש בחשבון שירות יחיד. לדוגמה, יכול להיות שחשבון השירות שמשמש ליצירת משימות Dataflow לא צריך לגשת למקורות וליעדים של נתונים או להשתמש במשאבים אחרים שמשמשים את הצינור. בתרחיש הזה, לחשבון השירות של העובד שמשמש להרצת משימות Dataflow מוענקות הרשאות להשתמש במשאבי צינור עיבוד הנתונים. לחשבון שירות אחר ליצירת משימות מוענקות הרשאות לניהול משימות Dataflow (כולל יצירה).
דוגמה לצינור עיבוד נתונים של CI/CD
בתרשים הבא מוצגת סקירה כללית של CI/CD לצינורות עיבוד נתונים, ללא תלות בכלי ספציפי. בנוסף, הדיאגרמה מציגה את הקשר בין משימות פיתוח, סביבות פריסה ומריצי צינורות.
בתרשים מוצגים השלבים הבאים:
פיתוח קוד: במהלך פיתוח הקוד, מפתח מריץ קוד של צינור מקומית באמצעות Direct Runner. בנוסף, מפתחים משתמשים בסביבת Sandbox להפעלה אד-הוק של צינור עיבוד נתונים באמצעות 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 מציעות יתרונות על פני תבניות קלאסיות לניהול תבניות.
- ב-Classic Templates, יכול להיות שכמה ארטיפקטים, כמו קובצי JAR, יישמרו במיקום זמני ב-Cloud Storage, אבל בלי תכונות לניהול של הארטיפקטים האלה. לעומת זאת, תבנית Flex מוכלת בקובץ אימג' של Docker. התמונה כוללת את כל יחסי התלות, מלבד מפרט FlexTemplate, שנדרשים לצינור שלך בארטיפקט פריסה אחד שמנוהל על ידי Artifact Registry.
- אתם יכולים להשתמש בתכונות לניהול קובצי אימג' של Docker בתבניות Flex. לדוגמה, אפשר לשתף בבטחה תבניות Flex על ידי מתן הרשאות pull (ובאופן אופציונלי push) ל-Artifact Registry, ולהשתמש בתגי קובצי אימג' של Docker לגרסאות שונות של תבניות Flex.
מפתחים יכולים להשתמש בתבניות קלאסיות ובתבניות גמישות כדי להפעיל משימות בפרויקט ששונה מהפרויקט שכולל את המאגר ואת קטגוריית האחסון שמארחת את נכסי התבנית, או רק את קטגוריית האחסון אם משתמשים בתבניות קלאסיות. התכונה הזו שימושית אם אתם צריכים לבודד את עיבוד הנתונים של כמה לקוחות לפרויקטים שונים ולמשימות שונות של צינורות נתונים. באמצעות תבניות Flex, אפשר לציין גרסאות שונות של קובץ אימג' של Docker לשימוש כשמפעילים צינור עיבוד נתונים. התכונה הזו מפשטת את ההחלפה בשלבים של צינורות לעיבוד אצווה או צינורות לעיבוד נתונים בזמן אמת בכמה פרויקטים, כשמעדכנים תבניות בהמשך.
תכונות של Dataflow לאופטימיזציה של השימוש במשאבים
Dataflow מספק את התכונות הבאות שספציפיות ל-Runner כדי לבצע אופטימיזציה של השימוש במשאבים, וכך לשפר את הביצועים ולהפחית את העלויות:
- Streaming Engine: Streaming Engine מעביר את ההפעלה של צינורות עיבוד נתונים של סטרימינג מתוך מכונות וירטואליות ייעודיות אל שירות ייעודי. היתרונות כוללים שיפור בתגובה להתאמה אוטומטית לעומס, צמצום המשאבים של worker VM שנצרכים ועדכוני שירות אוטומטיים ללא פריסה מחדש. במקרים מסוימים, אפשר גם לצמצם את השימוש במשאבים באמצעות עיבוד של לפחות פעם אחת בתרחישי שימוש שבהם אפשר לסבול כפילויות. מומלץ להפעיל את Streaming Engine לצינורות עיבוד נתונים בסטרימינג. התכונה מופעלת כברירת מחדל כשמשתמשים בגרסאות העדכניות ביותר של Apache Beam Java SDK או Python SDK.
- Dataflow Shuffle: שירות ארגון הנתונים של Dataflow מעביר פעולות ארגון נתונים של צינורות עיבוד נתונים של אצווה ממכונות וירטואליות (VM) של עובדים לשירות ייעודי. היתרונות כוללים הרצה מהירה יותר של רוב צינורות עיבוד הנתונים של Batch, צריכת משאבים מופחתת על ידי worker VMs, שיפור התגובה של התאמה אוטומטית לעומס ושיפור העמידות בפני תקלות. מומלץ להפעיל ארגון נתונים של Dataflow לצינורות עיבוד נתונים באצווה. התכונה מופעלת כברירת מחדל באמצעות Apache Beam Java SDK ו-Python SDK העדכני.
- Flexible resource scheduling (FlexRS): FlexRS מפחית את עלויות העיבוד באצווה באמצעות טכניקות מתקדמות לתזמון, שירות ארגון הנתונים של Dataflow ושילוב של VM זמני ומכונות וירטואליות רגילות.
עדכון צינורות עיבוד נתונים בשידור חי
איך משדרגים צינור עיבוד נתונים בסטרימינג
מחזור החיים של משימה ב-Dataflow
משימת Dataflow עוברת מחזור חיים שמיוצג על ידי מצבי משימה שונים.
כדי להריץ משימת Dataflow, צריך לשלוח אותה לאזור.
לאחר מכן, המשימה מנותבת לבק-אנד זמין של Dataflow באחד מהתחומים באזור. לפני ש-Dataflow מקצה קצה עורפי, המערכת מוודאת שיש לכם מספיק מכסות והרשאות להפעלת העבודה. אחרי שכל הבדיקות המקדימות האלה מסתיימות ומוקצה קצה עורפי, העבודה עוברת למצב JOB_STATE_PENDING. במשימות של FlexRS, יכול להיות שההקצאה של ה-backend תתעכב למועד מאוחר יותר, והמשימות האלה יעברו למצב JOB_STATE_QUEUED.
הקצה העורפי שמוקצה מקבל את העבודה להרצה ומנסה להפעיל עובדי Dataflow בפרויקט שלכם ב-Google Cloud Platform. האזור שנבחר למכונות הווירטואליות של העובדים תלוי במספר גורמים. במשימות אצווה שמשתמשות ב-ארגון נתונים של Dataflow, השירות גם מנסה לוודא שהבק-אנד של Dataflow וה-worker VM ממוקמים באותו אזור כדי למנוע תעבורה בין אזורים.
אחרי שהעובדים של Dataflow מתחילים, הם שולחים בקשה לעבודה מהקצה העורפי של Dataflow. הבק-אנד אחראי לפיצול העבודה לחלקים שניתנים להרצה במקביל, שנקראים חבילות, שמופצים בין העובדים. אם העובדים לא יכולים לטפל בעבודה הקיימת, ואם מופעלת התאמה אוטומטית לעומס (automatic scaling), הבק-אנד מפעיל עוד עובדים כדי לטפל בעבודה. באופן דומה, אם מפעילים יותר עובדים מהנדרש, חלק מהעובדים מושבתים.
אחרי שהעובדים של Dataflow מתחילים לפעול, קצה העורף של Dataflow פועל כמישור הבקרה כדי לתזמן את ביצוע העבודה. במהלך העיבוד, מישור הנתונים של המשימה מבצע פעולות ערבוב כמו GroupByKey, CoGroupByKey ו-Combine.
עבודות משתמשות באחת מההטמעות הבאות של מישור הנתונים לפעולות של ערבוב נתונים:
- מישור הנתונים פועל בתהליכי העבודה של Dataflow, ונתוני ה-Shuffle מאוחסנים בדיסקים קבועים.
- מישור הנתונים פועל כשירות, והוא מופרד ממכונות ה-VM של העובדים. יש שני וריאנטים להטמעה הזו, ואתם מציינים אותם כשאתם יוצרים את העבודה: ארגון נתונים של Dataflow לצינורות עיבוד נתונים באצווה ומנוע סטרימינג לצינורות עיבוד נתונים בסטרימינג. הערבוב מבוסס-השירותים משפר באופן משמעותי את הביצועים ואת יכולת ההתאמה של פעולות ערבוב הנתונים בהשוואה לערבוב מבוסס-העובדים.
משימות של סטרימינג שנכנסות למצב 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 פועלות, יכול להיות שהמשימות ייכשלו או ייעצרו. לגבי משימות אצווה, מפעילים מחדש את המשימה באזור אחר אם אפשר. חשוב לוודא שהנתונים שלכם זמינים באזורים שונים.
הפחתת הסיכון להפסקות שירות אזוריות באמצעות זמינות גבוהה או מעבר לגיבוי (failover)
במשימות סטרימינג, יש אפשרויות שונות לצמצום הסיכון לכשלים, בהתאם לסובלנות לתקלות ולתקציב של האפליקציה. במקרה של הפסקת חשמל אזורית, האפשרות הפשוטה והמשתלמת ביותר היא להמתין עד שההפסקה תסתיים. עם זאת, אם האפליקציה שלכם רגישה לזמן אחזור או אם עיבוד הנתונים לא יכול להיות מופרע או צריך להתחדש עם עיכוב מינימלי, האפשרויות מפורטות בקטעים הבאים.
זמינות גבוהה: רגישות לזמן אחזור ללא אובדן נתונים
אם האפליקציה לא יכולה לסבול אובדן נתונים, מריצים צינורות כפולים במקביל בשני אזורים שונים, ודואגים שצינורות יצרכו את אותם נתונים. אותם מקורות נתונים צריכים להיות זמינים בשני האזורים. אפליקציות במורד הזרם שתלויות בפלט של צינורות העיבוד האלה צריכות להיות מסוגלות לעבור בין הפלט משני האזורים האלה. בגלל השכפול של המשאבים, האפשרות הזו כרוכה בעלות הגבוהה ביותר בהשוואה לאפשרויות אחרות. דוגמה לפריסה מופיעה בקטע זמינות גבוהה ויתירות גיאוגרפית.
מעבר לגיבוי: רגיש לזמן אחזור עם אובדן נתונים פוטנציאלי
אם האפליקציה יכולה להתמודד עם אובדן נתונים פוטנציאלי, כדאי להפוך את מקור הנתונים של הסטרימינג לזמין בכמה אזורים. לדוגמה, באמצעות 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.