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

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

‫Apache Beam מספקת הטמעה לדוגמה של מחבר הקלט/פלט של Pub/Sub לשימוש על ידי רכיבי 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.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

המשך 

--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, מהסיבות הבאות:

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

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

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

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