מינויים ל-BigQuery

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

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

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

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

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

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

לפני שמתחילים

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

  • איך Pub/Sub פועל ומהם המונחים השונים של Pub/Sub.

  • סוגי המינויים השונים שנתמכים ב-Pub/Sub והסיבות לשימוש במינוי ל-BigQuery.

  • איך BigQuery פועל ואיך מגדירים ומנהלים טבלאות BigQuery.

תהליך העבודה של מינוי ל-BigQuery

בתמונה הבאה מוצג תהליך העבודה בין מינוי ל-BigQuery לבין BigQuery.

זרימת ההודעות במינוי ל-BigQuery
איור 1. תהליך העבודה למינוי BigQuery

הנה תיאור קצר של תהליך העבודה שמופיע באיור 1:

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

מאפיינים של מינוי ל-BigQuery

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

מידע נוסף זמין במאמר מאפיינים של BigQuery.

תאימות סכימה

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

ב-Pub/Sub וב-BigQuery משתמשים בדרכים שונות להגדרת הסכימות. סכימות של Pub/Sub מוגדרות בפורמט Apache Avro או Protocol Buffer, ואילו סכימות של BigQuery מוגדרות באמצעות מגוון פורמטים.

בהמשך מופיעה רשימה של פרטים חשובים לגבי תאימות הסכימה בין נושא ב-Pub/Sub לבין טבלה ב-BigQuery.

  • הודעות שמכילות שדה בפורמט לא תקין לא נכתבות ב-BigQuery.

  • בסכימת BigQuery, ‏ INT, ‏ SMALLINT, ‏ INTEGER,‏ BIGINT, ‏ TINYINT ו-BYTEINT הם כינויים ל-INTEGER, ‏ DECIMAL הוא כינוי ל-NUMERIC ו-BIGDECIMAL הוא כינוי ל-BIGNUMERIC.

  • אם הסוג בסכימת הנושא הוא string והסוג בטבלת BigQuery הוא JSON,‏ TIMESTAMP,‏ DATETIME,‏ DATE,‏ TIME,‏ NUMERIC או BIGNUMERIC, כל ערך בשדה הזה בהודעת Pub/Sub צריך להיות בפורמט שצוין עבור סוג הנתונים ב-BigQuery.

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

בטבלה הבאה מפורט מיפוי של פורמטים שונים של סכימות לסוגי נתונים ב-BigQuery.

סוגי Avro

‫Avro Type סוג הנתונים ב-BigQuery
null Any NULLABLE
boolean BOOLEAN
int INTEGER, NUMERIC או BIGNUMERIC
long INTEGER, NUMERIC או BIGNUMERIC
float FLOAT64, NUMERIC או BIGNUMERIC
double FLOAT64, NUMERIC או BIGNUMERIC
bytes BYTES, NUMERIC או BIGNUMERIC
string ‫STRING, JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC או BIGNUMERIC
record RECORD/STRUCT
array מתוך Type REPEATED Type
‫map with value type ValueType REPEATED STRUCT <key STRING, value ValueType>
‫union עם שני סוגים, אחד שהוא null והשני Type NULLABLE Type
אחר union לא ניתן למיפוי
fixed BYTES, NUMERIC או BIGNUMERIC
enum INTEGER

סוגים לוגיים של Avro

סוג לוגי של Avro סוג הנתונים ב-BigQuery
timestamp-micros TIMESTAMP
timestamp-millis TIMESTAMP
date DATE
time-micros TIME
time-millis TIME
duration INTERVAL
decimal NUMERIC או BIGNUMERIC

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

סוג מאגר אחסון לפרוטוקולים סוג הנתונים ב-BigQuery
double FLOAT64, NUMERIC או BIGNUMERIC
float FLOAT64, NUMERIC או BIGNUMERIC
int32 ‫INTEGER, NUMERIC, BIGNUMERIC או DATE
int64 ‫INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME או TIMESTAMP
uint32 ‫INTEGER, NUMERIC, BIGNUMERIC או DATE
uint64 NUMERIC או BIGNUMERIC
sint32 INTEGER, NUMERIC או BIGNUMERIC
sint64 ‫INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME או TIMESTAMP
fixed32 ‫INTEGER, NUMERIC, BIGNUMERIC או DATE
fixed64 NUMERIC או BIGNUMERIC
sfixed32 ‫INTEGER, NUMERIC, BIGNUMERIC או DATE
sfixed64 ‫INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME או TIMESTAMP
bool BOOLEAN
string ‫STRING, JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC או BIGNUMERIC
bytes BYTES, NUMERIC או BIGNUMERIC
enum INTEGER
message RECORD/STRUCT
oneof לא ניתן למיפוי
map<KeyType, ValueType> REPEATED RECORD<key KeyType, value ValueType>
enum INTEGER
repeated/array of Type REPEATED Type

ייצוג של תאריך ושעה כמספר שלם

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

סוג הנתונים ב-BigQuery ייצוג של מספר שלם
DATE מספר הימים מאז ראשית זמן יוניקס, 1 בינואר 1970
DATETIME התאריך והשעה במיקרו-שניות, שמוצגים כזמן אזרחי באמצעות CivilTimeEncoder
TIME הזמן במיקרו-שניות, שמוצג כזמן אזרחי באמצעות CivilTimeEncoder
TIMESTAMP מספר המיקרו-שניות מאז ראשית זמן יוניקס, 1 בינואר 1970, 00:00:00 UTC

הטמעה של סימון נתונים שהשתנו (CDC) ב-BigQuery

מינויים ל-BigQuery תומכים בעדכוני הטמעה של CDC (לכידת נתונים משתנים) כשuse_topic_schema או use_table_schema מוגדרים לערך true במאפייני המינוי. כדי להשתמש בתכונה עם use_topic_schema, צריך להגדיר את הסכימה של הנושא עם השדות הבאים:

  • ‫_CHANGE_TYPE (חובה): שדה string שמוגדר לערך UPSERT או DELETE.

    • אם ההגדרה של _CHANGE_TYPE בהודעת Pub/Sub שנכתבת לטבלה ב-BigQuery היא UPSERT,‏ BigQuery מעדכן את השורה עם אותו מפתח אם היא קיימת, או מוסיף שורה חדשה אם היא לא קיימת.

    • אם הודעת Pub/Sub שנכתבה לטבלה ב-BigQuery כוללת _CHANGE_TYPE שמוגדר ל-DELETE,‏ BigQuery מוחק את השורה בטבלה עם אותו מפתח, אם היא קיימת.

  • ‫_CHANGE_SEQUENCE_NUMBER (אופציונלי): שדה string שמוגדר כדי לוודא שעדכונים ומחיקות שבוצעו בטבלה ב-BigQuery יעברו עיבוד לפי הסדר. ההודעות לאותו מפתח שורה צריכות להכיל ערך _CHANGE_SEQUENCE_NUMBER שעולה באופן מונוטוני. להודעות עם מספרי רצף שקטנים ממספר הרצף הכי גבוה שעובד בשורה, אין השפעה על השורה בטבלה ב-BigQuery. מספר הרצף צריך להיות בפורמט _CHANGE_SEQUENCE_NUMBER.

כדי להשתמש בתכונה עם use_table_schema, צריך לכלול את השדות הקודמים בהודעת ה-JSON.

מידע על תמחור זמין במאמר בנושא תמחור של הטמעת CDC ב-BigQuery.

טבלאות Apache Iceberg שמנוהלות על ידי BigQuery

אפשר להשתמש במינויים ל-BigQuery עם טבלאות מנוהלות של Iceberg בלי לבצע שינויים נוספים.

טבלאות מנוהלות של Iceberg מספקות את הבסיס לבניית אגמי נתונים בפורמט פתוח ב- Cloud de Confiance by S3NS. הטבלאות האלה מציעות את אותה חוויה מנוהלת לחלוטין כמו טבלאות BigQuery רגילות (מובנות), אבל הנתונים מאוחסנים בדלי אחסון בבעלות הלקוח בפורמט Parquet, כדי לאפשר פעולה הדדית עם פורמטים של טבלאות פתוחות ב-Iceberg.

מידע על יצירת טבלה מנוהלת בפורמט Iceberg ב-BigQuery זמין במאמר בנושא יצירת טבלאות מנוהלות בפורמט Iceberg.

טיפול בכשלים בשליחת הודעות

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

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

מכסות ומגבלות

יש מגבלות מכסה על נפח הנתונים (throughput) של מנויי BigQuery בכל אזור. מידע נוסף זמין במאמר בנושא מכסות ומגבלות ב-Pub/Sub.

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

תמחור

למחירים של מינויים ל-BigQuery, אפשר לעיין בדף התמחור של Pub/Sub.

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