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

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

‫Apache Beam מספקת הטמעה לדוגמה של מחבר הקלט/פלט של Pub/Sub לשימוש על ידי רכיבי Runner שאינם Dataflow. עם זאת, רכיב ה-runner של Dataflow משתמש בהטמעה מותאמת אישית משלו של המחבר. ההטמעה הזו מתבססת על שירותים ועל ממשקי API פנימיים של Google Cloud Platform כדי להציע סימני מים עם השהיה נמוכה, דיוק גבוה של סימני מים וביטול כפילויות יעיל לעיבוד הודעות בדיוק פעם אחת. המחבר זמין ל-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.subscription.consume
  • pubsub.subscription.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 מפתחות לערבוב. בעבודות שלא מבוססות על מנוע הסטרימינג, מספר המפתחות הוא חזקת 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

Go 

--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 שמסננים הודעות לא יגרמו לבעיות בהתאמת קנה מידה אוטומטית.

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