מבוא ל-Storage Write API‏ (gRPC)

אתם יכולים להשתמש ב-BigQuery Storage Write API‏ (gRPC) כדי להזרים נתונים ל-BigQuery. במאמר הזה מתוארת הארכיטקטורה של Storage Write API ‏ (gRPC), היכולות שלו ותרחישי שימוש.

בפרויקטים חדשים מומלץ להשתמש ב-Storage Write API ‏ (gRPC) במקום ב-Storage Write API ‏ (REST). המחיר של Storage Write API ‏ (gRPC) נמוך יותר והוא כולל תכונות חזקות יותר, כולל סמנטיקה של מסירה חד-פעמית.

ההרשאות הנדרשות

כדי להשתמש ב-Storage Write API ‏ (gRPC), אתם צריכים הרשאות bigquery.tables.updateData.

התפקידים המוגדרים מראש הבאים של ניהול זהויות והרשאות גישה (IAM) כוללים את ההרשאות bigquery.tables.updateData:

  • bigquery.dataEditor
  • bigquery.dataOwner
  • bigquery.admin

במאמר תפקידים והרשאות מוגדרים מראש יש מידע נוסף על תפקידים והרשאות ב-IAM ב-BigQuery.

היקפי הרשאות

כדי להשתמש ב-Storage Write API‏ (gRPC) צריך להגדיר אחד מהיקפי ההרשאות הבאים של OAuth:

  • https://www.googleapis.com/auth/bigquery
  • https://www.googleapis.com/auth/cloud-platform
  • https://www.googleapis.com/auth/bigquery.insertdata

מידע נוסף מופיע במאמר סקירה כללית על אימות.

סקירה כללית על Storage Write API‏ (gRPC)

ההפשטה העיקרית ב-Storage Write API‏ (gRPC) היא stream. הנתונים נכתבים לטבלה ב-BigQuery באמצעות זרם. יותר מזרם אחד יכולים לכתוב בו-זמנית לאותה טבלה.

ברירת מחדל לשידור

‫Storage Write API‏ (gRPC) מספק זרם ברירת מחדל, שנועד לתרחישי סטרימינג שבהם הנתונים מגיעים באופן רציף. המאפיינים שלו הם:

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

אם אתם עוברים מ-Storage Write API (REST), כדאי להשתמש בזרם ברירת המחדל. יש לו סמנטיקה דומה של כתיבה, עם עמידות גבוהה יותר של הנתונים ופחות הגבלות על שינוי הגודל.

תהליך ה-API:

  1. ‫AppendRows (לולאה)

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

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

אתם יכולים ליצור במפורש מקור נתונים אם אתם צריכים את אחת מההתנהגויות הבאות:

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

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

כשיוצרים זרם, מציינים סוג. הסוג קובע מתי הנתונים שנכתבים לזרם יהיו גלויים לקריאה ב-BigQuery.

סוג בהמתנה

בסוג בהמתנה, הרשומות נשמרות בזיכרון במצב בהמתנה עד שמבצעים את הזרם. כשמבצעים קומיט של זרם, כל הנתונים בהמתנה הופכים לזמינים לקריאה. הפעולה commit היא פעולה אטומית. אפשר להשתמש בסוג הזה לעומסי עבודה (workloads) של אצווה, כחלופה למשימות טעינה ב-BigQuery. מידע נוסף זמין במאמר בנושא טעינת נתונים באצווה באמצעות Storage Write API‏ (gRPC).

תהליך ה-API:

  1. CreateWriteStream
  2. ‫AppendRows (לולאה)
  3. FinalizeWriteStream
  4. BatchCommitWriteStreams

סוג ההתחייבות

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

תהליך ה-API:

  1. CreateWriteStream
  2. ‫AppendRows (לולאה)
  3. ‫FinalizeWriteStream (אופציונלי)

סוג עם זיכרון זמני

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

תהליך ה-API:

  1. CreateWriteStream
  2. ‫AppendRows ⇒ FlushRows (לולאה)
  3. ‫FinalizeWriteStream (אופציונלי)

בחירת סוג

תרשים הזרימה הבא יעזור לכם להחליט איזה סוג הכי מתאים לעומס העבודה שלכם:

תמונה

פרטי ה-API

כשמשתמשים ב-Storage Write API, כדאי להביא בחשבון את הנקודות הבאות:

AppendRows

ה-method‏ AppendRows מוסיף רשומה אחת או יותר לזרם. הקריאה הראשונה אל AppendRows חייבת להכיל שם של מקור נתונים יחד עם סכימת הנתונים, שצוינה כ-DescriptorProto. לחלופין, אפשר להוסיף סכימת חץ מסודרת בקריאה הראשונה אל AppendRows אם אתם מבצעים המרה של נתונים בפורמט Apache Arrow. מומלץ לשלוח אצווה של שורות בכל קריאה ל-AppendRows. אל תשלחו שורה אחת בכל פעם.

טיפול במאגר אחסון לפרוטוקולים

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

אם אתם מתכוונים לצרוך את ה-API ישירות עם הודעת מאגר אחסון לפרוטוקולים מוגדרת מראש, הודעת מאגר אחסון לפרוטוקולים לא יכולה להשתמש במגדיר package, וכל הסוגים המקוננים או סוגי המספור צריכים להיות מוגדרים בהודעת הבסיס ברמה הבסיסית (root). אסור להשתמש בהפניות להודעות חיצוניות. לדוגמה, אפשר לעיין ב-sample_data.proto.

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

טיפול ב-Apache Arrow

‫Apache Arrow הוא פורמט אוניברסלי של עמודות וארגז כלים רב-לשוני לעיבוד נתונים. ‫Apache Arrow מספק פורמט זיכרון מבוסס-עמודות שאינו תלוי בשפה, לנתונים שטוחים והיררכיים, ומאורגן לפעולות ניתוח יעילות בחומרה מודרנית. ‫Storage Write API‏ (gRPC) תומך בהטמעה של Arrow באמצעות סכימת Arrow מסודרת ונתונים במחלקה AppendRowsRequest. ספריות הלקוח של Python ו-Java כוללות תמיכה מובנית בהעברה של נתונים בפורמט Apache Arrow.

FinalizeWriteStream

השיטה FinalizeWriteStream מסיימת את הזרם כך שלא ניתן להוסיף לו נתונים חדשים. השיטה הזו נדרשת בסוג Pending והיא אופציונלית בסוגים Committed ו-Buffered. שידור ברירת המחדל לא תומך בשיטה הזו.

טיפול בשגיאות

אם מתרחשת שגיאה, התגובה google.rpc.Status יכולה לכלול StorageError בפרטי השגיאה. כדי למצוא את סוג השגיאה הספציפי, אפשר לעיין בStorageErrorCode. מידע נוסף על מודל השגיאות של Google API זמין במאמר שגיאות.

חיבורים

‫Storage Write API ‏ (gRPC) הוא gRPC API שמשתמש בחיבורים דו-כיווניים. השיטה AppendRows יוצרת חיבור לסטרים. אפשר לפתוח כמה חיבורים בזרם ברירת המחדל. ההוספות האלה הן אסינכרוניות, ולכן אפשר לשלוח סדרה של פעולות כתיבה בו-זמנית. הודעות התגובה בכל חיבור דו-כיווני מגיעות באותו סדר שבו הבקשות נשלחו.

לסטרימינג שנוצר על ידי אפליקציה יכול להיות רק חיבור פעיל אחד. מומלץ להגביל את מספר החיבורים הפעילים ולהשתמש בחיבור אחד לכתיבה של כמה שיותר נתונים. כשמשתמשים בזרם ברירת המחדל ב-Java או ב-Go, אפשר להשתמש בריבוב (multiplexing) של Storage Write API‏ (gRPC) כדי לכתוב לכמה טבלאות יעד עם חיבורים משותפים.

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

‫BigQuery סוגר את חיבור ה-gRPC אם החיבור נשאר במצב סרק יותר מדי זמן. אם זה קורה, קוד התגובה הוא HTTP 409. החיבור ל-gRPC יכול להיסגר גם אם השרת מופעל מחדש או מסיבות אחרות. אם מתרחשת שגיאת חיבור, צריך ליצור חיבור חדש. ספריות הלקוח של Java ו-Go מתחברות מחדש באופן אוטומטי אם החיבור נסגר.

תמיכה בספריות לקוח

קיימות ספריות לקוח ל-Storage Write API ‏ (gRPC) בשפות תכנות שונות, והן חושפות את מבני ה-API הבסיסיים שמבוססים על gRPC. ה-API הזה מבוסס על תכונות מתקדמות כמו סטרימינג דו-כיווני, שעשויות לדרוש עבודת פיתוח נוספת כדי לתמוך בהן. לכן, יש מספר הפשטות ברמה גבוהה יותר שזמינות ל-API הזה, שמפשטות את האינטראקציות האלה ומפחיתות את הדאגות של המפתחים. מומלץ להשתמש בהפשטות אחרות של הספריות האלה, כשהדבר אפשרי.

בקטע הזה מפורטים שפות וספריות שבהן סיפקנו למפתחים יכולות נוספות מעבר ל-API שנוצר.

כדי לראות דוגמאות קוד שקשורות ל-Storage Write API ‏ (gRPC), אפשר לעיין בכל דוגמאות הקוד של BigQuery.

לקוח Java

ספריית הלקוח Java מספקת שני אובייקטים של כתיבה:

  • ‫StreamWriter: מקבל נתונים בפורמט של מאגר פרוטוקולים.

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

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

אובייקט הכתיבה מנהל חיבור Storage Write API ‏ (gRPC). אובייקט הכתיבה מנקה אוטומטית את הבקשות, מוסיף את כותרות הניתוב האזורי לבקשות ומתחבר מחדש אחרי שגיאות בחיבור. אם אתם משתמשים ישירות ב-gRPC API, אתם צריכים לטפל בפרטים האלה.

אפשר גם להשתמש בפורמט ההטמעה של Apache Arrow כפרוטוקול חלופי להטמעת נתונים באמצעות Storage Write API ‏ (gRPC). מידע נוסף זמין במאמר שימוש בפורמט Apache Arrow להטמעת נתונים.

לקוח Go

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

לקוח Python

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

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

כדי לקבל מידע נוסף על השימוש ב-Protocol Buffers עם Python, אפשר לקרוא את המדריך בנושא יסודות Protocol Buffers ב-Python.

אתם יכולים גם להשתמש בפורמט ההטמעה של Apache Arrow כפרוטוקול חלופי להטמעת נתונים באמצעות Storage Write API. מידע נוסף זמין במאמר בנושא שימוש בפורמט Apache Arrow להעברת נתונים.

לקוח NodeJS

ספריית הלקוח NodeJS מקבלת קלט JSON ומספקת תמיכה בחיבור מחדש אוטומטי. במאמרי העזרה מוסבר איך להשתמש בלקוח.

הכינוי לא זמין

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

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

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

הזרמה לטבלאות מחולקות למחיצות

‫Storage Write API ‏ (gRPC) תומך בסטרימינג של נתונים לתוך טבלאות עם חלוקה למחיצות.

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

בטבלאות עם מחיצות לפי זמן הטמעה ועם מחיצות לפי עמודה של יחידת זמן, אפשר להחריג נתונים שלא חולקו למחיצות משאילתה על ידי סינון הערכים של NULL מהמחיצה __UNPARTITIONED__ באמצעות אחת מהעמודות הווירטואליות (_PARTITIONTIME או _PARTITIONDATE, בהתאם לסוג הנתונים המועדף).

חלוקה למחיצות (partitioning) לפי זמני כתיבת הנתונים

כשמבצעים סטרימינג לטבלה מחולקת למחיצות (Partitions) לפי זמני כתיבת הנתונים,‏ Storage Write API ‏(gRPC) מסיק את מחיצת היעד מתוך השעה הנוכחית במערכת לפי UTC.

אם אתם מזרימים נתונים לטבלה עם מחיצות יומיות, אתם יכולים לבטל את ההיסק של התאריך על ידי ציון קישוט מחיצה כחלק מהבקשה. כוללים את ה-decorator בפרמטר tableID. לדוגמה, אפשר להזרים ל-partition שמתאים לתאריך 2025-06-01 בטבלה table1 באמצעות קישוט ה-partition‏ table1$20250601.

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

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

חלוקה למחיצות (partitioning) של עמודה של יחידת זמן

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

חלוקה למחיצות (partitioning) של טווח מספרים שלמים

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

פלאגין פלט של Fluent Bit Storage Write API ‏ (gRPC)

תוסף הפלט של Fluent Bit Storage Write API ‏ (gRPC) מאפשר להטמיע רשומות JSON ב-BigQuery באופן אוטומטי, בלי שתצטרכו לכתוב קוד. כדי להתחיל להזרים נתונים באמצעות הפלאגין הזה, צריך רק להגדיר פלאגין קלט תואם וקובץ הגדרות. ‫Fluent Bit הוא מעבד יומנים ומשגר בפלטפורמות שונות בקוד פתוח, שמשתמש בפלאגינים של קלט ופלט כדי לטפל בסוגים שונים של מקורות נתונים ויעדים.

הפלאגין הזה תומך בפעולות הבאות:

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

תמיכה ב-Apache Iceberg

אתם יכולים להשתמש ב-Storage Write API ‏ (gRPC) עם Lakehouse for Apache Iceberg כדי להזרים נתונים לטבלאות Iceberg. מידע נוסף זמין במאמר BigQuery Storage Write API (gRPC) במאמרי העזרה בנושא Lakehouse.

מדדי פרויקט של Storage Write API ‏ (gRPC)

כדי לעקוב אחרי מדדים של הטמעת נתונים באמצעות Storage Write API ‏ (gRPC), אפשר להשתמש בתצוגה INFORMATION_SCHEMA.WRITE_API_TIMELINE או במדדים Google Cloud .

שימוש בשפת טיפול בנתונים (DML) עם נתונים שהוזרמו לאחרונה

אתם יכולים להשתמש בשפת טיפול בנתונים (DML), כמו ההצהרות UPDATE, DELETE או MERGE, כדי לשנות שורות שנכתבו לאחרונה בטבלת BigQuery באמצעות BigQuery Storage Write API ‏ (gRPC). פעולות כתיבה מהזמן האחרון הן פעולות שהתרחשו ב-30 הדקות האחרונות.

למידע נוסף על שימוש ב-DML כדי לשנות את הנתונים שמוזרמים, אפשר לעיין במאמר בנושא שימוש בשפת טיפול בנתונים.

מגבלות

  • התמיכה בהפעלת הצהרות DML לשינוי נתונים שהועברו לאחרונה בסטרימינג לא חלה על נתונים שהועברו בסטרימינג באמצעות Storage Write API (REST).
  • אין תמיכה בהרצת הצהרות DML משנות בתוך טרנזקציה עם כמה הצהרות על נתונים שהועברו לאחרונה בסטרימינג.

מכסות של Storage Write API ‏ (gRPC)

מידע על מכסות ומגבלות של Storage Write API ‏ (gRPC) זמין במאמר מכסות ומגבלות של BigQuery Storage Write API ‏ (gRPC).

אתם יכולים לעקוב אחרי השימוש במכסות של חיבורים בו-זמניים ושל קצב העברת הנתונים בGoogle Cloud דף המכסות במסוף.

חישוב התפוקה

נניח שהמטרה שלכם היא לאסוף יומנים מ-100 מיליון נקודות קצה שיוצרים 1,500 רשומות ביומן בכל דקה. אחר כך אפשר לאמוד את קצב העברת הנתונים באמצעות הנוסחה 100 million * 1,500 / 60 seconds = 2.5 GB per second. צריך לוודא מראש שיש לכם מכסת נתונים מספקת כדי להעביר את נפח התעבורה הזה.

תמחור של Storage Write API‏ (gRPC)

למידע על תמחור, ראו תמחור של הטמעת נתונים.

תרחיש שימוש לדוגמה

נניח שיש פייפליין לעיבוד נתוני אירועים מיומני נקודות קצה. האירועים נוצרים באופן רציף וצריכים להיות זמינים להרצת שאילתות ב-BigQuery בהקדם האפשרי. רעננות הנתונים היא בעלת חשיבות עליונה בתרחיש השימוש הזה, ולכן Storage Write API ‏ (gRPC) היא הבחירה הטובה ביותר להטמעת נתונים ב-BigQuery. ארכיטקטורה מומלצת לשמירה על יעילות נקודות הקצה האלה היא שליחת אירועים ל-Pub/Sub, שממנו הם נצרכים על ידי צינור Dataflow לסטרימינג שמעביר את הנתונים ישירות ל-BigQuery.

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

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

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

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

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

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

דוגמה מפורטת לשימוש ב-Storage Write API ‏ (gRPC) זמינה במאמר בנושא הזרמת נתונים באמצעות Storage Write API ‏ (gRPC).

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