קריאה מ-Pub/Sub אל Dataflow

בדף הזה מוסבר על שיטות מומלצות לקריאה מ-Pub/Sub ב-Dataflow.

‫Apache Beam מספקת הטמעה לדוגמה של מחבר Pub/Sub I/O לשימוש על ידי רכיבי Runner שאינם Dataflow. עם זאת, רכיב ה-runner של Dataflow משתמש בהטמעה מותאמת אישית משלו של המחבר. ההטמעה הזו מתבססת על ממשקי API פנימיים ושירותים של Google Cloudכדי להציע סימני מים עם השהיה נמוכה, דיוק גבוה של סימני מים וביטול כפילויות יעיל לעיבוד הודעות בדיוק פעם אחת. המחבר זמין ל-Java,‏ Python ו-Go.

עיבוד בדיוק פעם אחת

‫Pub/Sub מפריד בין מפרסמי אירועים לבין צרכני אירועים. האפליקציה מפרסמת הודעות בנושא, ו-Pub/Sub מעביר את ההודעות למנויים באופן אסינכרוני.

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

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

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

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

ביטול כפילויות לפי מאפיין של הודעה

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

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

למידע נוסף על שימוש במאפייני מזהה, אפשר לעיין בנושאי העזרה הבאים בנושא SDK:

מינויים

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

אם מציינים נושא, המחבר יוצר מינוי זמני חדש. המינוי הזה ייחודי לכל צינור.

חותמות זמן וסימני מים

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

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

למידע נוסף על השימוש בחותמות זמן של אירועים, אפשר לעיין בנושאים הבאים בחומר העזר בנושא SDK:

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

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

  • pubsub.subscriptions.create
  • pubsub.subscriptions.consume
  • pubsub.subscriptions.delete

בנוסף, צריך לתת לו את ההרשאה pubsub.topics.attachSubscription בנושא Pub/Sub. מומלץ ליצור תפקיד בהתאמה אישית לניהול זהויות והרשאות גישה שמכיל רק את ההרשאות האלה.

מידע נוסף על סימני מים זמין בדף StackOverflow בנושא חישוב סימני מים של Pub/Sub ב-Dataflow.

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

Pub/Sub Seek

Pub/Sub Seek מאפשר למשתמשים להפעיל מחדש הודעות שאושרו בעבר. אפשר להשתמש ב-Pub/Sub Seek עם Dataflow כדי לעבד מחדש הודעות בצינור עיבוד נתונים.

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

כדי לעבד מחדש הודעות באמצעות Pub/Sub Seek, מומלץ להשתמש בתהליך העבודה הבא:

  1. יוצרים snapshot של המינוי.
  2. יוצרים מינוי חדש לנושא Pub/Sub. המינוי החדש יקבל את תמונת המצב.
  3. מרוקנים את העבודה הנוכחית ב-Dataflow או מבטלים אותה.
  4. שולחים מחדש את צינור הנתונים באמצעות המינוי החדש.

מידע נוסף מופיע במאמר בנושא עיבוד מחדש של הודעות באמצעות Pub/Sub Snapshot ו-Seek.

מקביליות של מקור Pub/Sub

מקור הנתונים של Pub/Sub מקצה לכל הודעה מפתח דטרמיניסטי לעיבוד, ומשתמש במפתחות האלה כדי לערבב את ההודעות. בעבודות של Streaming Engine, נעשה שימוש ב-1,024 מפתחות לערבול. בעבודות שאינן Streaming Engine, מספר המפתחות הוא החזקה הנמוכה ביותר של 2 שגדולה מ-(4 * maximum workers).

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

Java 

--dataflowServiceOptions=num_pubsub_keys=NUMBER_OF_KEYS

Python 

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

המשך 

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

מחליפים את NUMBER_OF_KEYS במספר המפתחות. החזקה הבאה של 2 שגדולה מהערך שצוין או שווה לו.

לדוגמה, כדאי להגדיר את האפשרות הזו במצבים הבאים:

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

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

תכונות של Pub/Sub שלא נתמכות

התכונות הבאות של Pub/Sub לא נתמכות בהטמעה של מחבר ה-I/O של Pub/Sub ב-Dataflow runner.

השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

כשיוצרים מינוי ל-Pub/Sub, אפשר להגדיר אותו כך שישתמש במדיניות ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). עם זאת, השהיה מעריכית לפני ניסיון חוזר לא פועלת עם Dataflow. במקום זאת, צריך ליצור את המינוי עם מדיניות הניסיון החוזר Retry immediately.

השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מופעלת על ידי אישור שלילי או כשתוקף מועד האישור פג. עם זאת, Dataflow לא שולח אישורים שליליים כשהקוד של צינור העברת הנתונים נכשל. במקום זאת, המערכת מנסה שוב ושוב לעבד את ההודעה, ומאריכה כל הזמן את המועד האחרון לאישור קבלת ההודעה.

נושאים להודעות ללא מוצא

לא מומלץ להשתמש בנושאי הודעות שלא נמסרו ב-Pub/Sub עם Dataflow, מהסיבות הבאות:

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

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

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

משלוח של הודעות ב-Pub/Sub בדיוק פעם אחת

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

סדר ההודעות ב-Pub/Sub

הזמנת הודעות היא תכונה ב-Pub/Sub שמאפשרת למנוי לקבל הודעות לפי הסדר שבו הן פורסמו.

לא מומלץ להשתמש בהזמנת הודעות ב-Dataflow, מהסיבות הבאות:

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

טרנספורמציות של הודעות יחידות ב-Pub/Sub

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

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