עדכונים של טבלאות בזמן אמת באמצעות הטמעה של סימון נתונים שהשתנו (CDC)

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

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

מקצים תפקידים של ניהול זהויות והרשאות גישה (IAM) שמעניקים למשתמשים את ההרשאות הנדרשות לביצוע כל משימה שמופיעה במאמר הזה, ומוודאים שתהליך העבודה עומד בכל הדרישות המוקדמות.

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

כדי לקבל את ההרשאה שנדרשת לשימוש ב-Storage Write API, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ BigQuery Data Editor (roles/bigquery.dataEditor). להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

התפקיד המוגדר מראש הזה כולל את ההרשאה bigquery.tables.updateData, שנדרשת כדי להשתמש ב-Storage Write API.

יכול להיות שתוכלו לקבל את ההרשאה הזו גם בתפקידים בהתאמה אישית או בתפקידים אחרים שמוגדרים מראש.

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

דרישות מוקדמות

כדי להשתמש בהטמעה של CDC ב-BigQuery, תהליך העבודה צריך לעמוד בתנאים הבאים:

  • חובה להשתמש ב-Storage Write API בזרם ברירת המחדל.
  • חובה להשתמש בפורמט protobuf כפורמט ההעברה. אין תמיכה בפורמט Apache Arrow.
  • צריך להגדיר מפתחות ראשיים לטבלת היעד ב-BigQuery. יש תמיכה במפתחות ראשיים מורכבים שמכילים עד 16 עמודות.
  • צריכים להיות זמינים מספיק משאבי מחשוב של BigQuery כדי לבצע את פעולות השורות של CDC. חשוב לדעת שאם פעולות של שינוי שורות ב-CDC נכשלות, יכול להיות שיישארו נתונים שלא התכוונתם למחוק. מידע נוסף מופיע במאמר שיקולים לגבי נתונים שנמחקו.

מציינים שינויים ברשומות קיימות

בייבוא של נתוני CDC ב-BigQuery, עמודת ה-pseudocolumn‏ _CHANGE_TYPE מציינת את סוג השינוי שצריך לעבד בכל שורה. כדי להשתמש ב-CDC, צריך להגדיר את _CHANGE_TYPE כשמעבירים בסטרימינג שינויים בשורות באמצעות Storage Write API. בעמודה הווירטואלית _CHANGE_TYPE אפשר להזין רק את הערכים UPSERT ו-DELETE. טבלה נחשבת מופעלת ל-CDC בזמן ש-Storage Write API מעביר בסטרימינג שינויים בשורות לטבלה באופן הזה.

דוגמה עם הערכים UPSERT ו-DELETE

כדאי לעיין בטבלה הבאה ב-BigQuery:

מזהה שם שכר
100 צ'רלי 2000
101 Tal 3000
102 Lee 5,000

השינויים הבאים בשורות מועברים בסטרימינג על ידי Storage Write API:

מזהה שם שכר _CHANGE_TYPE
100 מחיקה
101 Tal 8000 UPSERT
105 Izumi 6000 UPSERT

הטבלה המעודכנת היא:

מזהה שם שכר
101 Tal 8000
102 Lee 5,000
105 Izumi 6000

ניהול של נתונים לא עדכניים בטבלה

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

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

הרצת שאילתות על טבלאות עם האפשרות max_staleness

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

בדוגמה הבאה, האפשרות max_staleness בטבלה מוגדרת ל-10 דקות, והפעולה האחרונה של החלת העבודה התרחשה בשעה T20:

זמן ההרצה של השאילתה מתרחש בתוך מרווח הזמן המקסימלי של נתוני הסטאלינג.

אם תבצעו שאילתה בטבלה בשעה T25, הגרסה הנוכחית של הטבלה תהיה ישנה ב-5 דקות, שזה פחות מmax_staleness מרווח הזמן של 10 דקות. במקרה הזה, BigQuery מחזיר את הגרסה של הטבלה בשעה T20, כלומר הנתונים שמוחזרים גם הם לא עדכניים ב-5 דקות.

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

לדוגמה, אם שולחים שאילתה לטבלה בשעה T35, ותהליך החלת השינויים בשורות בהמתנה לא הסתיים, הגרסה הנוכחית של הטבלה לא עדכנית כבר 15 דקות, שזה יותר ממרווח הזמן של 10 דקות max_staleness. במקרה הזה, בזמן ההרצה של השאילתה, BigQuery מחיל את כל השינויים בשורות בין T20 ל-T35 על השאילתה הנוכחית. כלומר, הנתונים שנכללים בשאילתה עדכניים לחלוטין, אבל יש עלות של השהיה נוספת בשאילתה. זה נחשב לתהליך מיזוג בזמן ריצה.

זמן הריצה של השאילתה חורג ממרווח הזמן המקסימלי של נתוני הסטאלינג.

הערך של max_staleness בטבלה צריך להיות בדרך כלל הגבוה מבין שני הערכים הבאים:

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

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

SELECT
  project_id,
  destination_table.dataset_id,
  destination_table.table_id,
  APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)] AS p95_background_apply_duration_in_seconds,
  CEILING(APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)]*2/60)+7 AS recommended_max_staleness_with_buffer_in_minutes
FROM `region-REGION`.INFORMATION_SCHEMA.JOBS AS job
WHERE
  project_id = 'PROJECT_ID'
  AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
  AND job_id LIKE "%cdc_background%"
GROUP BY 1,2,3;

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: שם האזור שבו נמצא הפרויקט. לדוגמה, us.
  • ‫PROJECT_ID: המזהה של הפרויקט שמכיל את הטבלאות ב-BigQuery שמשתנות על ידי הטמעה של CDC ב-BigQuery.

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

יצירת טבלה באמצעות האפשרות max_staleness

כדי ליצור טבלה באמצעות האפשרות max_staleness, משתמשים בהצהרה CREATE TABLE. בדוגמה הבאה נוצרת הטבלה employees עם מגבלה של max_staleness דקות:

CREATE TABLE employees (
  id INT64 PRIMARY KEY NOT ENFORCED,
  name STRING)
  CLUSTER BY
    id
  OPTIONS (
    max_staleness = INTERVAL 10 MINUTE);

שינוי האפשרות max_staleness בטבלה קיימת

כדי להוסיף או לשנות מגבלת max_staleness בטבלה קיימת, משתמשים בהצהרה ALTER TABLE. בדוגמה הבאה, מגדירים את המגבלה max_staleness בטבלה employees ל-15 דקות:

ALTER TABLE employees
SET OPTIONS (
  max_staleness = INTERVAL 15 MINUTE);

איך קובעים את הערך הנוכחי של טבלה max_staleness

כדי לקבוע את הערך הנוכחי של max_staleness בטבלה, מריצים שאילתה בתצוגה INFORMATION_SCHEMA.TABLE_OPTIONS. בדוגמה הבאה נבדק הערך הנוכחי של max_staleness בטבלה mytable:

SELECT
  option_name,
  option_value
FROM
  DATASET_NAME.INFORMATION_SCHEMA.TABLE_OPTIONS
WHERE
  option_name = 'max_staleness'
  AND table_name = 'TABLE_NAME';

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET_NAME: שם מערך הנתונים שבו נמצאת הטבלה עם CDC.
  • ‫TABLE_NAME: השם של הטבלה שמופעל בה CDC.

התוצאות מראות שהערך של max_staleness הוא 10 דקות:

+---------------------+--------------+
| Row |  option_name  | option_value |
+---------------------+--------------+
|  1  | max_staleness | 0-0 0 0:10:0 |
+---------------------+--------------+

מעקב אחרי ההתקדמות של פעולת upsert בטבלה

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

בדוגמה הבאה נבדק הערך upsert_stream_apply_watermark של הטבלה mytable:

SELECT upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
WHERE table_name = 'TABLE_NAME';

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET_NAME: שם מערך הנתונים שבו נמצאת הטבלה עם CDC.
  • ‫TABLE_NAME: השם של הטבלה שמופעל בה CDC.

התוצאה אמורה להיראות כך:

[{
 "upsert_stream_apply_watermark": "2022-09-15T04:17:19.909Z"
}]

פעולות Upsert מבוצעות על ידי חשבון השירות bigquery-adminbot@system.gserviceaccount.com ומופיעות בהיסטוריית העבודות של הפרויקט שמכיל את הטבלה עם CDC.

ניהול של הזמנה בהתאמה אישית

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

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

פורמט _CHANGE_SEQUENCE_NUMBER

בעמודה הווירטואלית _CHANGE_SEQUENCE_NUMBER אפשר להזין רק ערכים של STRING, שנכתבים בפורמט קבוע. הפורמט הקבוע הזה משתמש בערכים STRING שנכתבים בפורמט הקסדצימלי, ומחולקים לקטעים באמצעות קו נטוי /. כל מקטע יכול לכלול עד 16 תווים הקסדצימליים, ומותרים עד ארבעה מקטעים לכל _CHANGE_SEQUENCE_NUMBER. הטווח המותר של _CHANGE_SEQUENCE_NUMBER הוא בין 0/0/0/0 ל-FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF. הערכים של _CHANGE_SEQUENCE_NUMBER יכולים לכלול אותיות רישיות וקטנות.

אפשר להשתמש בקטע אחד כדי להגדיר מפתחות בסיסיים למיון. לדוגמה, כדי להזמין מפתחות רק על סמך חותמת הזמן של עיבוד רשומה משרת אפליקציות, אפשר להשתמש בקטע אחד: '2024-04-30 11:19:44 UTC', שמוצג כערך הקסדצימלי על ידי המרת חותמת הזמן למילישניות מ-Epoch, '18F2EBB6480' במקרה הזה. הלוגיקה להמרת נתונים לפורמט הקסדצימלי היא באחריות הלקוח שמבצע את הפעולה ב-BigQuery באמצעות Storage Write API.

התמיכה בכמה קטעים מאפשרת לכם לשלב כמה ערכים של לוגיקת עיבוד במפתח אחד, כדי להתאים לתרחישי שימוש מורכבים יותר. לדוגמה, כדי להזמין מפתחות על סמך חותמת הזמן של עיבוד רשומה משרת אפליקציות, מספר רצף ביומן והסטטוס של הרשומה, אפשר להשתמש בשלושה קטעים: '2024-04-30 11:19:44 UTC' / '123' / 'complete', שכל אחד מהם מבוטא כהקסדצימלי. סדר הקטעים הוא שיקול חשוב לדירוג של לוגיקת העיבוד. מערכת BigQuery משווה את הערכים של _CHANGE_SEQUENCE_NUMBER על ידי השוואה של החלק הראשון, ואז השוואה של החלק הבא רק אם החלקים הקודמים היו שווים.

‫BigQuery משתמש ב-_CHANGE_SEQUENCE_NUMBER כדי לבצע מיון על ידי השוואה בין שני שדות _CHANGE_SEQUENCE_NUMBER או יותר כערכים מספריים לא חתומים.

כדאי לעיין בדוגמאות הבאות להשוואה בין כללים ובתוצאות העדיפות שלהם:_CHANGE_SEQUENCE_NUMBER

  • דוגמה 1:

    • רשומה מס' 1: _CHANGE_SEQUENCE_NUMBER = '77'
    • רשומה מס' 2: _CHANGE_SEQUENCE_NUMBER = '7B'

    תוצאה: רשומה מס' 2 נחשבת לרשומה העדכנית ביותר כי '7B' > '77' (כלומר '123' > '119')

  • דוגמה 2:

    • הקלטה מס' 1: _CHANGE_SEQUENCE_NUMBER = 'FFF/B'
    • רשומה מס' 2: _CHANGE_SEQUENCE_NUMBER = 'FFF/ABC'

    תוצאה: רשומה מס' 2 נחשבת לרשומה האחרונה כי FFF/ABC > FFF/B (כלומר, ‎4095/2748 > 4095/11)

  • דוגמה 3:

    • רשומה מס' 1: _CHANGE_SEQUENCE_NUMBER = 'BA/FFFFFFFF'
    • רשומה מס' 2: _CHANGE_SEQUENCE_NUMBER = 'ABC'

    תוצאה: רשומה מס' 2 נחשבת לרשומה העדכנית ביותר כי 'ABC' > 'BA/FFFFFFFF' (כלומר, ‎'2748' > '186/4294967295')

  • דוגמה 4:

    • ‫Record #1: _CHANGE_SEQUENCE_NUMBER = 'FFF/ABC'
    • רשומה מס' 2: _CHANGE_SEQUENCE_NUMBER = 'ABC'

    תוצאה: רשומה מספר 1 נחשבת לרשומה העדכנית ביותר כי 'FFF/ABC' > 'ABC' (כלומר '4095/2748' > '2748')

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

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

הגדרת הזמנה ב-BigQuery לשימוש בהטמעה של CDC

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

משימות הטמעה של BigQuery CDC שמחילות שינויים בשורות בהמתנה במרווח max_staleness נחשבות למשימות ברקע ומשתמשות בסוג ההקצאה BACKGROUND או BACKGROUND_CHANGE_DATA_CAPTURE, ולא בסוג ההקצאה QUERY. לעומת זאת, שאילתות מחוץ לטווח max_staleness שדורשות שינויים בשורות שיוחלו בזמן הריצה של השאילתה משתמשות בסוג ההקצאה QUERY. גם בטבלאות ללא הגדרה של max_staleness או בטבלאות שבהן max_staleness מוגדר כ-0 נעשה שימוש בסוג ההקצאה QUERY. משימות רקע של הטמעת נתוני CDC ב-BigQuery שמתבצעות ללא הקצאה של BACKGROUND או BACKGROUND_CHANGE_DATA_CAPTURE, מחויבות לפי תמחור על פי דרישה. ההיבט הזה חשוב כשמתכננים את אסטרטגיית ניהול עומסי העבודה (workload) להעברה של נתוני CDC ל-BigQuery.

כדי להגדיר הזמנה ב-BigQuery לשימוש ב-CDC, מתחילים בהגדרת הזמנה באזור שבו נמצאים הטבלאות ב-BigQuery. למידע על גודל ההזמנה, אפשר לעיין במאמר גודל ההזמנות של BACKGROUND ומעקב אחריהן. אחרי שיוצרים הזמנה, מקצים את פרויקט BigQuery להזמנה ומגדירים את האפשרות job_type לערך BACKGROUND על ידי הפעלת ההצהרה CREATE ASSIGNMENT הבאה:

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-REGION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  job_type = 'BACKGROUND');

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ADMIN_PROJECT_ID: המזהה של פרויקט הניהול שבבעלותו המקום השמור.
  • ‫REGION: שם האזור שבו נמצא הפרויקט. לדוגמה, us.
  • ‫RESERVATION_NAME: השם של ההזמנה.
  • ‫ASSIGNMENT_ID: מזהה ההקצאה. המזהה צריך להיות ייחודי לפרויקט ולמיקום, להתחיל ולהסתיים באות קטנה או במספר, ולהכיל רק אותיות קטנות, מספרים ומקפים.
  • ‫PROJECT_ID: המזהה של הפרויקט שמכיל את הטבלאות ב-BigQuery שמשתנות על ידי הטמעה של BigQuery CDC. הפרויקט הזה משויך להזמנה.

גודל והזמנות של BACKGROUND צגים

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

SELECT
  period_start,
  SUM(period_slot_ms) / (1000 * 60) AS slots_used
FROM
  region-REGION.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE
  DATE(job_creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
  AND CURRENT_DATE()
  AND job_id LIKE '%cdc_background%'
GROUP BY
  period_start
ORDER BY
  period_start DESC;

מחליפים את REGION בשם האזור שבו נמצא הפרויקט. לדוגמה, us.

שיקולים לגבי נתונים שנמחקו

  • פעולות הטמעה של CDC ב-BigQuery משתמשות במשאבי מחשוב של BigQuery. אם פעולות ה-CDC מוגדרות לשימוש בחיוב על פי דרישה, הן מתבצעות באופן קבוע באמצעות משאבים פנימיים של BigQuery. אם פעולות ה-CDC מוגדרות עם הזמנה של BACKGROUND או BACKGROUND_CHANGE_DATA_CAPTURE, הזמינות של המשאבים שמוגדרים בהזמנה חלה על פעולות ה-CDC. אם אין מספיק משאבים זמינים בהזמנה שהוגדרה, יכול להיות שייקח יותר זמן מהצפוי לעבד פעולות CDC, כולל מחיקה.
  • פעולת CDC DELETE נחשבת כפעולה שהוחלה רק אחרי שחותמת הזמן upsert_stream_apply_watermark עברה את חותמת הזמן שבה ה-Storage Write API העביר את הפעולה בסטרימינג. מידע נוסף על חותמת הזמן upsert_stream_apply_watermark זמין במאמר מעקב אחרי התקדמות של פעולת upsert בטבלה.
  • כדי להחיל פעולות CDC DELETE שמגיעות לא לפי הסדר, BigQuery שומר חלון שימור של מחיקות למשך יומיים. פעולות בטבלה DELETE מאוחסנות למשך התקופה הזו לפני שמתחיל Google Cloud תהליך מחיקת הנתונים הרגיל. פעולות DELETE שמתבצעות במסגרת חלון השמירה למחיקה מחויבות לפי תמחור האחסון הרגיל ב-BigQuery.

מגבלות

  • הטמעה של CDC ב-BigQuery לא מבצעת אכיפה של מפתחות, ולכן חשוב לוודא שהמפתחות הראשיים שלכם הם ייחודיים.
  • מספר העמודות במפתחות ראשיים לא יכול להיות גדול מ-16.
  • בטבלאות עם CDC מופעל, לא יכולות להיות יותר מ-2,000 עמודות ברמה העליונה שמוגדרות על ידי הסכימה של הטבלה.
  • בטבלאות עם CDC אי אפשר להשתמש בתכונות הבאות:
  • טבלאות עם CDC שבהן מתבצעים מיזוגים בזמן ריצה כי הערך max_staleness של הטבלה נמוך מדי, לא יכולות לתמוך בפעולות הבאות:
  • פעולות ייצוא ב-BigQuery בטבלאות שמופעל בהן CDC לא מייצאות שינויים בשורות שהועברו לאחרונה בסטרימינג ושעדיין לא הוחלו על ידי עבודת רקע. כדי לייצא את הטבלה המלאה, צריך להשתמש בדף חשבון EXPORT DATA.
  • אם השאילתה מפעילה מיזוג בזמן ריצה בטבלה עם חלוקה למחיצות, המערכת סורקת את כל הטבלה, גם אם השאילתה מוגבלת לקבוצת משנה של המחיצות.
  • אם אתם משתמשים ב-Standard edition,‏ BACKGROUND הזמנות לא זמינות, ולכן כשמחילים שינויים בשורות בהמתנה, נעשה שימוש במודל התמחור על פי דרישה. עם זאת, אפשר להריץ שאילתות על טבלאות עם CDC בכל מהדורה.
  • אי אפשר להריץ שאילתות על העמודות הפסאודונימיות _CHANGE_TYPE ו-_CHANGE_SEQUENCE_NUMBER כשמבצעים קריאה של טבלה.
  • אין תמיכה בשילוב בין שורות עם ערכים UPSERT או DELETE בעמודה _CHANGE_TYPE לבין שורות עם ערכים INSERT או ערכים לא מוגדרים בעמודה _CHANGE_TYPE באותו חיבור, והפעולה הזו גורמת לשגיאת האימות הבאה: The given value is not a valid CHANGE_TYPE.

תמחור של הטמעת CDC ב-BigQuery

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

חישוב אומדנים של עלויות ההטמעה של CDC ב-BigQuery

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

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

משימות ההטמעה של BigQuery CDC מחולקות לשלוש קטגוריות:

  • משימות להחלה ברקע: משימות שפועלות ברקע במרווחי זמן קבועים שמוגדרים על ידי הערך max_staleness בטבלה. העבודות האלה מחילות שינויים בשורות שהועברו בסטרימינג לאחרונה לטבלה עם CDC.
  • משרות שאילתה: שאילתות GoogleSQL שמופעלות בחלון max_staleness וקוראות רק מהטבלה הראשונית של CDC.
  • מיזוג של עבודות בזמן ריצה: עבודות שמופעלות על ידי שאילתות GoogleSQL אד-הוק שמופעלות מחוץ לחלון max_staleness. העבודות האלה צריכות לבצע מיזוג דינמי של טבלת הבסיס של CDC ושל שינויי השורות שהועברו בסטרימינג לאחרונה בזמן הריצה של השאילתה.

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

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

שיטות מומלצות להטמעת נתונים ב-BigQuery CDC

בנוסף לשיטות המומלצות הכלליות לניהול עלויות ב-BigQuery, אפשר להשתמש בטכניקות הבאות כדי לייעל את העלויות של פעולות הטמעה של CDC ב-BigQuery:

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

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