מבוא ל-BigQuery Storage Write API

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

היתרונות של שימוש ב-Storage Write API

סמנטיקה של מסירה בדיוק פעם אחת. ‫Storage Write API תומך בסמנטיקה של בדיוק פעם אחת באמצעות שימוש בהיסטים של הזרם. בניגוד לשיטה tabledata.insertAll, ‏ Storage Write API אף פעם לא כותב שתי הודעות עם אותו היסט בתוך זרם, אם הלקוח מספק היסטים של זרם כשמוסיפים רשומות.

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

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

פרוטוקול יעיל. ה-Storage Write API יעיל יותר מהשיטה הקודמת insertAll כי הוא משתמש בסטרימינג של gRPC ולא ב-REST על HTTP. בנוסף, Storage Write API תומך בפורמט הבינארי מאגר אחסון לפרוטוקולים ובפורמט העמודות Apache Arrow, שהם פורמטים יעילים יותר מ-JSON. בקשות כתיבה הן אסינכרוניות עם סדר מובטח.

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

עלות נמוכה יותר. העלות של Storage Write API נמוכה משמעותית מזו של insertAll Streaming API מהדור הקודם. בנוסף, אתם יכולים להעלות עד 2 TiB בחודש בחינם.

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

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

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

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

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

היקפי הרשאות

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

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

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

סקירה כללית על Storage Write API

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

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

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

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

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

רצף הפעולות של ה-API:

  1. ‫AppendRows (חזרה)

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

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

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

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

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

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

סוג בהמתנה

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

רצף הפעולות של ה-API:

  1. CreateWriteStream
  2. ‫AppendRows (חזרה)
  3. FinalizeWriteStream
  4. BatchCommitWriteStreams

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

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

תהליך ה-API:

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

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

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

תהליך ה-API:

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

בחירת סוג

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

תמונה

פרטי ה-API

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

AppendRows

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

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

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

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

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

טיפול ב-Apache Arrow

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

FinalizeWriteStream

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

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

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

חיבורים

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

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

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

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

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

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

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

דוגמאות קוד שקשורות ל-Storage Write API מופיעות במאמר כל דוגמאות הקוד של BigQuery.

לקוח Java

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

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

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

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

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

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

לקוח Go

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

לקוח Python

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

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

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

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

לקוח NodeJS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חלוקה למחיצות לפי עמודה של יחידת זמן

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

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

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

Fluent Bit Storage Write API output plugin

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

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

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

מדדי פרויקט של Storage Write API

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

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

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

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

מגבלות

  • התמיכה בהרצת הצהרות DML לשינוי נתונים שהועברו לאחרונה באמצעות סטרימינג לא חלה על נתונים שהועברו באמצעות insertAll streaming API.
  • אין תמיכה בהרצת הצהרות DML משנות בתוך טרנזקציה עם כמה הצהרות על נתונים שהועברו לאחרונה בסטרימינג.

מכסות של Storage Write API

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

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

חישוב התפוקה

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

תמחור של Storage Write API

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

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

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

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

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

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

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

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

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

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

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