שדרוג של צינור עיבוד נתונים לסטרימינג

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

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

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

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

• ביצוע עדכונים במהלך הטיסה
• הפעלת עבודת החלפה
• הרצת צינורות עיבוד נתונים במקביל

למידע נוסף על בעיות שאתם עשויים להיתקל בהן במהלך עדכון ועל דרכים למנוע אותן, ראו אימות של עבודת החלפה ובדיקת תאימות של עבודה.

שיטות מומלצות

• שדרוג גרסת Apache Beam SDK בנפרד משינויים בקוד של צינורות הנתונים.
• אחרי כל שינוי, כדאי לבדוק את הצינור לפני שמבצעים עדכונים נוספים.
• חשוב לשדרג באופן קבוע את גרסת Apache Beam SDK שבה משתמש צינור הנתונים.
• כדאי להשתמש בשיטות אוטומטיות ככל האפשר, כמו עדכונים במהלך הטיסה או עדכונים אוטומטיים של צינורות מקבילים.
• כדאי להשתמש בקלט/פלט מנוהל כשזה אפשרי, כדי ליהנות משדרוגים אוטומטיים של גרסאות המחברים.

ביצוע עדכונים במהלך הטיסה

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

• העבודה צריכה להשתמש ב-Streaming Engine.
• המשימה צריכה להיות במצב פעיל.
• אתם משנים רק את מספר העובדים שהמשימה משתמשת בהם.

מידע נוסף זמין במאמר בנושא הגדרת טווח של שינוי גודל אוטומטי בדף בנושא שינוי גודל אוטומטי אופקי.

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

הפעלת משימת החלפה

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

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

הוראות להפעלת עבודת החלפה מופיעות במאמר בנושא הפעלת עבודת החלפה.

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

הפסקה והחלפה של צינורות עיבוד נתונים

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

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

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

הוראות מפורטות זמינות במאמר בנושא הפסקת פעולה של משימת Dataflow. אחרי שמסיימים את המשימה הנוכחית, מתחילים משימה חדשה עם אותו שם.

עיבוד מחדש של הודעות באמצעות Pub/Sub Snapshot ו-Seek

במקרים מסוימים, אחרי שמחליפים או מבטלים צינור נתונים שהתרוקן, יכול להיות שיהיה צורך לעבד מחדש הודעות Pub/Sub שנמסרו בעבר. לדוגמה, יכול להיות שתצטרכו להשתמש בלוגיקה עסקית מעודכנת כדי לעבד מחדש נתונים. Pub/Sub Seek היא תכונה שמאפשרת להפעיל מחדש הודעות מתמונת מצב של Pub/Sub. אפשר להשתמש ב-Pub/Sub Seek עם Dataflow כדי לעבד מחדש הודעות מהזמן שבו נוצר צילום המצב של המינוי.

במהלך הפיתוח והבדיקה, אפשר גם להשתמש ב-Pub/Sub Seek כדי להפעיל שוב ושוב את ההודעות הידועות, וכך לאמת את הפלט מצינור עיבוד הנתונים. כשמשתמשים ב-Pub/Sub Seek, לא מבצעים Seek לתמונת מצב של מינוי בזמן שצינור עיבוד נתונים צורך את המינוי. אם תעשו את זה, יכול להיות שהפעולה תבטל את הלוגיקה של סימן המים ב-Dataflow ותשפיע על העיבוד של הודעות Pub/Sub בדיוק פעם אחת.

הנה תהליך עבודה מומלץ ב-ה-CLI של gcloud לשימוש ב-Pub/Sub Seek עם צינורות Dataflow בחלון טרמינל:

1. כדי ליצור snapshot של המינוי, משתמשים בפקודה gcloud pubsub snapshots create:

   gcloud pubsub snapshots create SNAPSHOT_NAME --subscription=PIPELINE_SUBSCRIPTION_NAME
   

2. כדי לנקז את הנתונים מהצינור או לבטל אותו, משתמשים בפקודה gcloud dataflow jobs drain או בפקודה gcloud dataflow jobs cancel:

   gcloud dataflow jobs drain JOB_ID
   

   או

   gcloud dataflow jobs cancel JOB_ID
   

3. כדי לעבור לתמונת המצב, משתמשים בפקודה gcloud pubsub subscriptions seek:

   gcloud pubsub subscriptions seek SNAPSHOT_NAME
   

4. פריסת צינור חדש שמשתמש במינוי.

הפעלת צינורות במקביל

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

סקירה כללית של צינורות עיבוד נתונים מקבילים

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

התרשים הבא ממחיש את התהליך הזה.

בתרשים, Pipeline B הוא העבודה המעודכנת שמחליפה את Pipeline A. הערך t הוא חותמת הזמן של החלון המוקדם ביותר שPipeline B עיבד. הערך w הוא סימן המים של Pipeline A. לצורך פשטות, נניח שיש סימן מים מושלם בלי נתונים מאוחרים. זמן העיבוד והזמן שחלף מוצגים בציר האופקי. שני צינורות הנתונים משתמשים בחלונות קבועים (מתגלגלים) של חמש דקות. התוצאות מופעלות אחרי שהסימן עובר את סוף כל חלון.

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

מגבלות

יש מגבלות על שימוש בעדכונים אוטומטיים או ידניים של צינורות מקבילים:

• עדכונים אוטומטיים בלבד: המשימה המקבילה החדשה חייבת להיות משימה של Streaming Engine.
• השמות של העבודות הישנות והחדשות צריכים להיות שונים, כי אסור להריץ עבודות בו-זמנית עם אותו שם.
• הפעלת שני צינורות במקביל על אותו קלט עלולה להוביל לכפילות בנתונים, לצבירות חלקיות ולבעיות פוטנציאליות בסדר כשהנתונים מוכנסים ליעד. המערכת במורד הזרם צריכה להיות מתוכננת כך שתצפה לתוצאות האלה ותנהל אותן.
• כשקוראים מתוך מקור Pub/Sub, לא מומלץ להשתמש באותו מינוי לכמה צינורות, כי זה עלול לגרום לבעיות בדיוק. עם זאת, במקרים מסוימים, כמו צינורות נתונים של extract, transform, load (ETL), שימוש באותו מינוי בשני צינורות נתונים עשוי לצמצם את הכפילות. בעיות בהתאמה אוטומטית לעומס עלולות לקרות בכל פעם שמציינים ערך שונה מאפס עבור משך החפיפה. אפשר לצמצם את הסיכון הזה באמצעות התכונה לעדכון משימות בזמן שהן פועלות. מידע נוסף זמין במאמר בנושא שיפור ההתאמה האוטומטית לעומס של צינורות סטרימינג ב-Pub/Sub.
• ב-Apache Kafka, אפשר למזער כפילויות על ידי הפעלת offset committing ב-Kafka. כדי להפעיל את האפשרות 'שמירת אופסט' ב-Kafka, אפשר לעיין במאמר שמירה חוזרת ב-Kafka.

עדכונים אוטומטיים של צינורות מקבילים לעיבוד נתונים

‫Dataflow מספק תמיכה ב-API להפעלת עבודת החלפה מקבילה. ממשק ה-API הזה, שפועל בסגנון הצהרתי, מפשט את העבודה הידנית של הפעלת שלבים פרוצדורליים. מגדירים את העבודה שרוצים לעדכן, ואז עבודה חדשה פועלת במקביל לעבודה הישנה. אחרי שהמשימה החדשה פועלת למשך הזמן שציינתם, המשימה הישנה מתרוקנת. התכונה הזו מבטלת את ההשהיות בעיבוד במהלך העדכונים ומפחיתה את המאמץ התפעולי שנדרש לעדכון צינורות לא תואמים.

שיטת העדכון הזו מתאימה במיוחד לצינורות עיבוד נתונים שיכולים להכיל כפילויות או צבירות חלקיות, ושלא נדרש בהם סדר קפדני בזמן הוספת הנתונים. הוא מתאים במיוחד לצינורות ETL, וגם לצינורות שמשתמשים במצב סטרימינג של לפחות פעם אחת ובתהליך Redistribute transform עם ההגדרה allow duplicates שמוגדרת ל-true.

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

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

Java

--dataflowServiceOptions="parallel_replace_job_name=OLD_JOB_NAME" \
--dataflowServiceOptions="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

לחלופין, אפשר לציין את מזהה המשרה הישנה:

--dataflowServiceOptions="parallel_replace_job_id=OLD_JOB_ID" \
--dataflowServiceOptions="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

Python

--dataflow_service_options="parallel_replace_job_name=OLD_JOB_NAME" \
--dataflow_service_options="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

לחלופין, אפשר לציין את מזהה המשרה הישנה:

--dataflow_service_options="parallel_replace_job_id=OLD_JOB_ID" \
--dataflow_service_options="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

Go

--dataflow_service_options="parallel_replace_job_name=OLD_JOB_NAME" \
--dataflow_service_options="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

לחלופין, אפשר לציין את מזהה המשרה הישנה:

--dataflow_service_options="parallel_replace_job_id=OLD_JOB_ID" \
--dataflow_service_options="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

gcloud

--additional-experiments="parallel_replace_job_name=OLD_JOB_NAME" \
--additional-experiments="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

לחלופין, אפשר לציין את מזהה המשרה הישנה:

--additional-experiments="parallel_replace_job_id=OLD_JOB_ID" \
--additional-experiments="parallel_replace_job_min_parallel_pipelines_duration=DURATION"

מחליפים את המשתנים הבאים:

• צריך לספק את parallel_replace_job_name או את parallel_replace_job_id כדי לזהות את המשרה שרוצים להחליף.
  • ‫OLD_JOB_NAME: אם משתמשים ב-parallel_replace_job_name, השם של המשימה שרוצים להחליף.
  • ‫OLD_JOB_ID: אם משתמשים ב-parallel_replace_job_id, המזהה של המשימה שרוצים להחליף.

• חובה לציין ערך parallel_replace_job_min_parallel_pipelines_duration.

  • ‫DURATION: משך הזמן המינימלי ששני צינורות העיבוד פועלים במקביל, כמספר שלם או כמספר נקודה צפה. אחרי שהזמן הזה חולף, נשלח אות ניקוז לעבודה הישנה.

    משך הזמן צריך להיות בין 0 שניות (0s) ל-31 ימים (744h). משתמשים ב-s, ב-m וב-h כדי לציין שניות, דקות ושעות. לדוגמה, 10m הוא 10 דקות.

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

הפעלה ידנית של צינורות מקבילים

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

טיפול בפלט משוכפל

בדוגמה הבאה מתואר אחד מהפתרונות לטיפול בפלט כפול. שני צינורות הנתונים כותבים פלט ליעדים שונים, משתמשים במערכות במורד הזרם כדי לשלוח שאילתות לתוצאות, ומבטלים כפילויות בתוצאות מהתקופה החופפת. בדוגמה הזו נעשה שימוש בצינור שקורא נתוני קלט מ-Pub/Sub, מבצע עיבוד מסוים וכותב את התוצאות ל-BigQuery.

1. במצב ההתחלתי, צינור הסטרימינג הקיים (Pipeline A) פועל וקורא הודעות מנושא ב-Pub/Sub‏ (Topic) באמצעות מינוי (Subscription A). התוצאות נכתבות לטבלה ב-BigQuery (טבלה א'). התוצאות נצרכות דרך תצוגה ב-BigQuery, שפועלת כחזית להסתרת שינויים בטבלה הבסיסית. התהליך הזה הוא יישום של שיטת עיצוב שנקראת תבנית חזית. התרשים הבא מציג את המצב ההתחלתי.

   

2. יוצרים מינוי חדש (מינוי ב') לצינור המעודכן. פורסים את צינור עיבוד הנתונים המעודכן (Pipeline B), שקורא מנושא Pub/Sub (Topic) באמצעות Subscription B וכותב לטבלה נפרדת ב-BigQuery (Table B). התרשים הבא ממחיש את התהליך הזה.

   

   בשלב הזה, Pipeline A ו-Pipeline B פועלים במקביל וכותבים את התוצאות לטבלאות נפרדות. אתם מתעדים את הזמן t כחותמת הזמן של החלון המלא המוקדם ביותר שעובד על ידי Pipeline B.

3. כשהסימן של Pipeline A חורג מהזמן t, מרוקנים את Pipeline A. כשמרוקנים את הצינור, כל החלונות הפתוחים נסגרים והעיבוד של הנתונים בתהליך מסתיים. אם צינור הנתונים מכיל חלונות וחשובים לכם חלונות מלאים (בהנחה שאין נתונים מאוחרים), לפני שמרוקנים את צינור הנתונים א', מריצים את שני צינורות הנתונים עד שמתקבלים חלונות חופפים מלאים. הפסקת משימת הסטרימינג של צינור A אחרי שכל הנתונים בתהליך יעובדו וייכתבו בטבלה A. התרשים הבא מציג את השלב הזה.

   

4. בשלב הזה, פועל רק Pipeline B. אפשר להריץ שאילתה מתצוגת BigQuery (תצוגת חזית), שמשמשת כחזית לטבלה א' ולטבלה ב'. לגבי שורות עם חותמת זמן זהה בשתי הטבלאות, צריך להגדיר את התצוגה כך שהשורות יוחזרו מטבלה ב', או שאם השורות לא קיימות בטבלה ב', המערכת תחזור לטבלה א'. התרשים הבא מציג את התצוגה (Façade View) שקוראת מטבלה א' ומטבלה ב'.

   

   בשלב הזה, אפשר למחוק את מינוי א'.

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

טיפול במוטציות של סכימה

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

נניח שיש צינור שקורא הודעות שמכילות מטען ייעודי (payload) בפורמט JSON מנושא Pub/Sub. הצינור ממיר כל הודעה למופע של TableRow ואז כותב את השורות לטבלה ב-BigQuery. הסכימה של טבלת הפלט דומה להודעות שעוברות עיבוד בצינור. בתרשים הבא, הסכימה נקראת סכימה א'.

עם הזמן, סכמת ההודעה עשויה להשתנות בדרכים משמעותיות. לדוגמה, שדות נוספים, מוסרים או מוחלפים. ‫Schema A מתפתח לסכימה חדשה. בדיון שבהמשך, הסכימה החדשה נקראת סכימה ב'. במקרה הזה, צריך לעדכן את Pipeline A, והסכימה של טבלת הפלט צריכה לתמוך ב-Schema B.

בטבלת הפלט, אפשר לבצע שינויים מסוימים בסכימה בלי להשבית את המערכת. לדוגמה, אפשר להוסיף שדות חדשים או לשנות את מצבי העמודות, כמו שינוי מ-REQUIRED ל-NULLABLE, בלי השבתה. המוטציות האלה בדרך כלל לא משפיעות על שאילתות קיימות. עם זאת, מוטציות בסכימה שמשנות או מסירות שדות קיימים בסכימה גורמות לשבירת שאילתות או לשיבושים אחרים. הגישה הבאה מאפשרת לבצע שינויים בלי להשבית את המערכת.

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

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

בתהליך המתוקן, Pipeline A מעבד הודעות שמשתמשות ב-Schema A וכותב את הפלט ל-Staging Table A, שיש לו סכימה תואמת. הטבלה הראשית מכילה נתונים היסטוריים שנכתבו על ידי גרסאות קודמות של צינור הנתונים, וגם תוצאות שמתבצע מיזוג שלהן באופן תקופתי מטבלת הביניים. הצרכנים יכולים לשאול שאלות לגבי נתונים עדכניים, כולל נתונים היסטוריים ונתונים בזמן אמת, באמצעות תצוגת הפסאדה.

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

הצינור המעודכן כותב לטבלת ביניים נוספת (Staging Table B) שמשתמשת בSchema B. אתם יכולים להשתמש בתהליך עבודה מתואם כדי ליצור את טבלת הביניים החדשה לפני שתעדכנו את צינור הנתונים. מעדכנים את תצוגת החזית כך שתכלול תוצאות מטבלת הביניים החדשה, ואפשר להשתמש בשלב קשור בתהליך העבודה.

בתרשים הבא מוצג התהליך המעודכן שבו טבלת הביניים ב' כוללת את סכימה ב', ומוסבר איך התצוגה החזיתית מתעדכנת כך שתכלול תוכן מהטבלה הראשית ומשתי טבלאות הביניים.

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

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

• כאן אפשר למצוא שלבים מפורטים לעדכון צינור קיים.