הגדרת אפשרויות הטבלה

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

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

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

  1. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  2. מפעילים את BigLake API, אם הוא עדיין לא מופעל.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

  3. מגדירים את הקטלוג הייעודי לזמן ריצה של Lakehouse באמצעות נקודת הקצה של קטלוג REST של Apache Iceberg.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להגדרת אפשרויות הטבלה, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט ובקטגוריית האחסון:

  • מגדירים את מאפייני הטבלה במצב הפצת פרטי כניסה: עורך BigLake ‏ (roles/biglake.editor) – הפרויקט
  • מגדירים את מאפייני הטבלה במצב שאינו מצב הפצת פרטי כניסה:
    • עריכת BigLake‏ (roles/biglake.editor) – הפרויקט
    • משתמש באובייקטים באחסון (roles/storage.objectUser) – הקטגוריה של Cloud Storage

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

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

שיקולים לגבי ההגדרות

כשמגדירים את האפשרויות של הטבלה, חשוב להביא בחשבון את הדרישות ואת פעולות ברירת המחדל הבאות:

טבלאות Iceberg נתמכות

למרות שהקטלוג הייעודי לזמן ריצה של Lakehouse תומך בטבלאות Apache Iceberg בגרסה 2 (GA) ובגרסה 3 (תצוגה מקדימה), יכולות מנוהלות (BigQuery DML וניהול טבלאות) נתמכות רק בטבלאות Iceberg בגרסה 2. אין תמיכה בטבלאות Iceberg V1. כדי לשדרג טבלאות קיימות בגרסה 1, קראו את המאמר שדרוג טבלאות Iceberg מגרסה 1 לגרסה 2.

דרישה להנפקת פרטי כניסה

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

הפעלת BigQuery DML

הפעלת פקודות של שפת הטיפול בנתונים (DML) ב-BigQuery מאפשרת יכולת כתיבה הדדית מ-BigQuery בטבלאות Apache Iceberg שנוצרו באמצעות מנועי קוד פתוח.

ההצהרות הנתמכות כוללות את INSERT,‏ UPDATE,‏ DELETE ו-MERGE, וגם הצהרות DDL סטנדרטיות כמו CREATE TABLE,‏ ALTER TABLE ו-DROP TABLE, חוץ מאלה שלא נתמכות בטבלאות Apache Iceberg ב-BigQuery.

הפעלת BigQuery DML לטבלאות חדשות

כשיוצרים טבלה מ-BigQuery, ניהול הטבלאות ו-DML ב-BigQuery מופעלים כברירת מחדל. כשיוצרים טבלה ממנועים בקוד פתוח, מגדירים את מאפיין הטבלה gcp.biglake.bigquery-dml.enabled = true באמצעות תחביר ה-DDL של המנוע.

לדוגמה, ב-Spark SQL:

CREATE TABLE NAMESPACE.TABLE_NAME (id int, data string)
USING ICEBERG
TBLPROPERTIES ('gcp.biglake.bigquery-dml.enabled' = true);

הפעלת BigQuery DML בטבלאות קיימות

כדי להפעיל את BigQuery DML בטבלה קיימת, מעדכנים את מאפיין הטבלה.

לדוגמה, ב-Spark SQL:

ALTER TABLE NAMESPACE.TABLE_NAME
SET TBLPROPERTIES ('gcp.biglake.bigquery-dml.enabled' = true);

השבתת BigQuery DML

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

לדוגמה, ב-Spark SQL:

ALTER TABLE NAMESPACE.TABLE_NAME
SET TBLPROPERTIES ('gcp.biglake.bigquery-dml.enabled' = false);

הפעלת ניהול שולחנות

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

ניהול הטבלאות מאפשר לכם לבצע את הפעולות הבאות:

  • תפוגת תוקף של קובצי Snapshot ואיסוף אשפה: תפוגת התוקף של קובצי Snapshot מנהלת את השמירה והמחיקה של קובצי נתונים ומטא-נתונים מקובצי Snapshot של טבלאות. התהליך הזה פועל באופן אוטומטי ברקע אחרי כל שינוי בנתונים. תוקף קובצי ה-snapshot פג בהתאם למאפייני טבלת Iceberg שהמשתמש הגדיר, history.expire.max-snapshot-age-ms ו-history.expire.min-snapshots-to-keep בטבלה. הוא מסיר רשומות של תמונות מצב שפג תוקפן על ידי יצירת הגדרה נוספת של תמונת מצב בקובץ מטא-נתונים חדש, שמשמיט הפניות לתמונות המצב שהוסרו.

    • מגבלה: אם בטבלה יש תגים או הסתעפויות, המערכת מדלגת על פקיעת התוקף של קובץ ה-snapshot ועל איסוף הזבל שמשויך אליו. מידע נוסף מופיע בקטע מגבלות.

    • מגבלה: ניהול הטבלאות לא מטפל בהסרת קבצים שאינם בתיקייה. מידע נוסף מופיע בקטע מגבלות.

  • ‫Coalesce (דחיסה): התהליך הזה אחראי על שמירת צורת הנתונים, על ידי מיזוג קבצים קטנים לקבצים גדולים יותר. האיחוד פועל באופן אוטומטי ברקע אחרי כל שינוי בנתונים. הקבצים נבחרים לדחיסה אם הגודל הממוצע שלהם ללא דחיסה קטן מ-50% מגודל קובץ היעד של 256MB. כל פעולת איחוד יוצרת תמונת מצב חדשה של הטבלה. בדרך כלל, משימות איחוד נכנעות לפעולות DML שפועלות, ומנסות שוב אחריהן. עם זאת, כדי למנוע מצב שבו לא מתבצעת אופטימיזציה של האחסון, משימת איחוד מופעלת באופן יזום כל 24 שעות אם הנתונים עומדים בדרישות לאיחוד.

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

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

בוחרים אם להפעיל את ניהול השולחנות

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

מפעילים את ניהול הטבלאות (gcp.biglake.table-management.enabled = true) כשכל התנאים הבאים מתקיימים:

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

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

  • חלון זמן של עד 7 ימים (5 ימים כברירת מחדל) לשמירת תמונת מצב ולמסע בזמן עונה על הדרישות שלכם.

  • הטבלה עומדת בדרישות של יכולות מנוהלות (ראו מגבלות).

כדאי להשאיר את ניהול הטבלאות מושבת (ברירת המחדל לטבלאות שנוצרו ממנועי קוד פתוח, או להגדיר את gcp.biglake.table-management.enabled = false) ולנהל את תחזוקת הטבלאות בעצמכם אם מתקיים אחד מהתנאים הבאים:

  • אתם מריצים פרוצדורות של תחזוקה או דחיסה בהתאמה אישית במנועים בקוד פתוח כמו Apache Spark,‏ Apache Flink או Trino, במיוחד אם הטבלאות שלכם מסתמכות על פריסות של מיון ליניארי או z-ordering שלא נשמרות ב-coalesce.

  • הטבלאות שלכם משתמשות בתגי תמונת מצב או בהסתעפויות של Apache Iceberg (שגורמים לניהול הטבלה לדלג על תפוגת תמונת המצב), או דורשות שמירה של תמונת המצב ו-Time Travel למשך יותר מ-7 ימים.

  • הקטלוג משתמש בפרטי הכניסה של משתמשי הקצה (הרשאות ישירות של ניהול זהויות והרשאות גישה (IAM) ב-Cloud Storage) במקום במצב הפצת פרטי כניסה.

  • הטבלאות שלכם משתמשות בתכונות שלא נתמכות ביכולות המנוהלות (במקרה כזה, גם ניהול הטבלאות וגם BigQuery DML צריכים להישאר מושבתים), כמו Apache Iceberg בגרסת פורמט 3, מצב merge-on-read, חלוקה למחיצות לפי כמה עמודות או לפי IDENTITY, או נתיבים מותאמים אישית לאחסון נתונים ומטא-נתונים. רשימה מלאה של תכונות שלא נתמכות מופיעה בקטע מגבלות.

הפעלת ניהול טבלאות בטבלאות חדשות

כשיוצרים טבלה מ-BigQuery, ניהול הטבלה ו-DML מופעלים כברירת מחדל. כשיוצרים טבלה ממנועי קוד פתוח, צריך להגדיר את המאפיין gcp.biglake.table-management.enabled. כשמפעילים את ניהול הטבלאות, BigQuery DML מופעל באופן אוטומטי אם הוא עדיין לא מופעל.

לדוגמה, ב-Spark SQL:

CREATE TABLE NAMESPACE.TABLE_NAME (id int, data string)
USING ICEBERG
TBLPROPERTIES ('gcp.biglake.table-management.enabled' = true);

הפעלת ניהול טבלאות בטבלאות קיימות

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

Spark SQL 

ALTER TABLE NAMESPACE.TABLE_NAME
SET TBLPROPERTIES ('gcp.biglake.table-management.enabled' = true);

BigQuery 

ALTER TABLE `PROJECT_ID.CATALOG_ID.NAMESPACE.TABLE_NAME`
SET OPTIONS (`properties.gcp.biglake.table-management` = "enabled");

השבתת ניהול השולחנות

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

Spark SQL 

ALTER TABLE NAMESPACE.TABLE_NAME
SET TBLPROPERTIES ('gcp.biglake.table-management.enabled' = false);

BigQuery 

ALTER TABLE `PROJECT_ID.CATALOG_ID.NAMESPACE.TABLE_NAME`
SET OPTIONS (`properties.gcp.biglake.table-management` = "disabled");

מגבלות

המגבלות על יכולות מנוהלות (כמו יכולת פעולה הדדית של כתיבה ב-BigQuery וניהול טבלאות) כוללות:

מגבלות כלליות

  • היכולות המנוהלות נתמכות רק בטבלאות Apache Iceberg שנוצרו בקטלוג הייעודי לזמן ריצה של Lakehouse באמצעות נקודת הקצה של קטלוג REST של Apache Iceberg.
  • כל המגבלות הקיימות על טבלאות Apache Iceberg שמנוהלות על ידי BigQuery חלות על פעולות שבהן מופעלות יכולות מנוהלות.
  • אי אפשר להשתמש ביכולות מנוהלות בטבלאות עם Apache Iceberg בגרסת פורמט 3. אפשר להצטרף ליכולות המנוהלות רק בטבלאות בגרסה 2 (מפרט Iceberg v2).
  • אין תמיכה ביכולות מנוהלות בטבלאות עם חלוקה מתקדמת למחיצות, כמו חלוקה למחיצות לפי STRING, חלוקה למחיצות לפי כמה עמודות או התפתחות של מחיצות.
  • אי אפשר להשתמש ביכולות המנוהלות בטבלאות שמוגדר בהן סדר מיון (לדוגמה, באמצעות הפרוצדורה WRITE ORDER BY או ההגדרה write.distribution.mode = range).
  • אין תמיכה ביכולות מנוהלות בטבלאות Iceberg v2 שמשתמשות במצב merge-on-read. אפשר להצטרף ליכולות המנוהלות רק בטבלאות שמשתמשות במצב עדכון, מחיקה ומיזוג של העתקה בזמן כתיבה.
  • יכולות מנוהלות לא תומכות בקובצי נתונים שנדחסו באמצעות קודקים של gzip, lz4 או brotli (write.parquet.compression-codec). רק סוגי הדחיסה zstd ו-snappy נתמכים בקובצי נתונים.
  • היכולות המנוהלות לא נתמכות בטבלאות אם הסכימה מכילה מזהי מפתחות ראשיים בתצוגת עץ (identifier-field-ids) שמפנים לנתיבים או לשדות בתצוגת עץ במבנה.
  • אי אפשר להשתמש ביכולות הניהול בטבלאות עם מיקומים מותאמים אישית של נתונים או מטא-נתונים (write.data.path ו-write.metadata.path). כדי לשמור קובצי נתונים ומטא-נתונים, צריך להשתמש במיקום ברירת המחדל של הקטגוריה ב-Cloud Storage.
  • אי אפשר להשתמש באשכולות של BigQuery בטבלאות Apache Iceberg שמנוהלות על ידי הקטלוג הייעודי לזמן ריצה של Lakehouse.
  • אם טבלה נוצרת עם סוג הנתונים NUMERIC ב-BigQuery, כל עדכוני הסכימה מ-Spark נכשלים כי Spark קורא את NUMERIC בתור NUMERIC(38,9). כדי לעקוף את הבעיה, כשיוצרים טבלאות עם הסוג NUMERIC ב-BigQuery, צריך להגדיר במפורש את הדיוק ל-NUMERIC(38,9).
  • בעיה מוכרת: אי אפשר למחוק עמודה ב-BigQuery באמצעות DDL (ALTER TABLE ... DROP COLUMN) ומיד לאחר מכן להוסיף מחדש עמודה עם אותו שם.

מגבלות של מסע בזמן

  • כשניהול הטבלאות מופעל, הערך המקסימלי המותר למאפיין history.expire.max-snapshot-age-ms הוא 30 ימים (2592000000 אלפיות השנייה), והערך המקסימלי המומלץ הוא 7 ימים (604800000 אלפיות השנייה). הערך המקסימלי המותר למאפיין history.expire.min-snapshots-to-keep הוא 100.
  • הגדרות של מסע בזמן ברמת הפרויקט או ברמת מערך הנתונים ב-BigQuery לא חלות. רק מאפייני טבלאות Iceberg וברירות המחדל שלהן פעילים.

מגבלות בניהול טבלאות

  • אם הטבלה מכילה קובצי snapshot עם תגים או הסתעפויות, המערכת מדלגת על תפוגת התוקף של קובצי ה-snapshot בכל הטבלה. המערכת מתעלמת משמירה בהתאמה אישית שמוגדרת באמצעות ALTER... RETAIN x DAYS, ומתעלמת מכל הערכים שמוגדרים למאפיין history.expire.max-ref-age-ms. מנועי קוד פתוח עדיין יכולים לבצע פקיעת תוקף של תמונות מצב.
  • ניהול הטבלאות לא גורם לפקיעת התוקף של סכימות או של מפרטי מחיצות. הקובץ metadata.json שומר את ההיסטוריה המלאה של הסכימות והמפרטים של המחיצות, גם אם אין תמונות מצב שמתייחסות למזהי הסכימות האלה.

  • קובץ שאינו בתיקייה שנוצרו על ידי BigQuery או מנועי קוד פתוח לא מנוקים על ידי ניהול הטבלאות. מנועי קוד פתוח יכולים לבצע ניקוי של קבצים שאינם בתיקייה (לדוגמה, באמצעות הפרוצדורה remove_orphan_files של Spark כשהאפשרות prefix_listing מוגדרת ל-true).

  • ‫Coalesce לא תומך ב-z-ordering ובמיון ליניארי. אם הטבלה מכילה את המאפיינים האלה, לא מובטח שהפריסה תישמר אחרי הפעלת האיחוד. אם הטבלאות שלכם מכילות את המאפיינים האלה, אל תפעילו את ניהול הטבלאות.

מגבלות החלוקה למחיצות

  • כשיוצרים או רושמים טבלאות ממנועי קוד פתוח, היכולות המנוהלות תומכות רק בחלוקה למחיצות לפי סוגי השדות DATE,‏ DATETIME ו-TIMESTAMP עם הטרנספורמציות hour,‏ day,‏ month ו-year (חוץ מהטרנספורמציה hour בשדות DATE), וסוגי השדות INTEGER.
  • אי אפשר להשתמש ביכולות מנוהלות בטבלאות עם טרנספורמציות של IDENTITY. צריך לציין את הטרנספורמציה באופן מפורש.
  • פקודות CREATE OR REPLACE בטבלאות עם יכולות מנוהלות נתמכות רק אם הן משתמשות באותו מפרט חלוקה למחיצות. ההחלפות הבאות לא נתמכות:
    • החלפת טבלה שלא חולקה למחיצות בטבלה שחולקה למחיצות.
    • החלפת טבלה מחולקת למחיצות בטבלה שלא מחולקת למחיצות.
    • החלפת טבלה מחולקת למחיצות בטבלה עם מפרט חלוקה למחיצות אחר.
  • אין תמיכה במתן שמות לשדות של מחיצות בהתאמה אישית. טבלאות שנוצרו או נרשמו ממנועי קוד פתוח חייבות לפעול לפי מוסכמות מתן השמות של שדות החלוקה למחיצות שמוגדרות כברירת מחדל במנוע (הוספת _ ושם הטרנספורמציה, כמו _hour,‏ _day,‏ _month או _year). לדוגמה, בשדה בשם time_date שמשתמש בטרנספורמציה DAY, ערך שדה החלוקה למחיצות הצפוי הוא: json { "field-id": 1, "source-id": 1, "name": "time_date_day", "transform": transform }

מגבלות שקשורות למאפיינים של טבלאות Iceberg בהתאמה אישית

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

מאפיין (property) ערך ברירת המחדל פרטים
format-version 2 היכולות המנוהלות תומכות רק בטבלאות Iceberg בגרסה 2.
write.format.default parquet הטבלאות תומכות רק בקובצי נתונים בפורמט Parquet.
write.data.path table location + /data הנתיב שמוגדר כברירת מחדל לקטגוריה של Cloud Storage בנקודת הקצה של קטלוג ה-REST של Apache Iceberg משמש לכתיבת קובצי נתונים.
write.metadata.path table location + /metadata הנתיב שמוגדר כברירת מחדל לקטגוריה של Cloud Storage לנקודת הקצה של קטלוג ה-REST של Apache Iceberg משמש לכתיבת קובצי מטא-נתונים.
write.delete.mode copy-on-write משימות כתיבה וניהול טבלאות ב-BigQuery תומכות רק בהעתקה בזמן כתיבה.
write.update.mode copy-on-write משימות כתיבה וניהול טבלאות ב-BigQuery תומכות רק בהעתקה בזמן כתיבה.
write.merge.mode copy-on-write משימות כתיבה וניהול טבלאות ב-BigQuery תומכות רק בהעתקה בזמן כתיבה.
write.delete.isolation-level זיהוי מחמיר של התנגשויות שינויים שמשנים את הקובץ metadata.json (כולל התנגשויות בנתונים, התנגשויות במטא-נתונים, קריאות פנטום או כתיבה בו-זמנית ללא התנגשות) גורמים לטרנזקציה הבו-זמנית להיכשל ולנסות שוב.
write.update.isolation-level זיהוי מחמיר של התנגשויות התנהגות זהה לזו של write.delete.isolation-level.
write.merge.isolation-level זיהוי מחמיר של התנגשויות התנהגות זהה לזו של write.delete.isolation-level.

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

מאפיין (property) ערך ברירת המחדל פרטים
write.parquet.compression-codec zstd אופטימיזציה של כתיבה ואחסון ב-BigQuery תומכת רק בפורמטים של דחיסה zstd ו-snappy. אין תמיכה בפורמטים אחרים של דחיסה (כמו gzip,‏ brotli ו-lz4).
write.metadata.compression-codec null אפשר להגדיר את המדיניות לערך null או gzip.
history.expire.max-snapshot-age-ms ‫432000000 (5 ימים) אפשר להגדיר כל מספר שלם חיובי עד 2592000000 (30 ימים) כשניהול הטבלאות מופעל. מומלץ להגדיר עד 7 ימים (604800000 אלפיות השנייה). משימות ניהול הטבלאות מוחקות תמונות מצב ישנות יותר מהמשך שצוין.
history.expire.min-snapshots-to-keep 1 אפשר להגדיר כל מספר שלם חיובי עד 100 כשניהול הטבלאות מופעל. משימות ניהול הטבלאות שומרות לפחות את המספר הזה של תמונות מצב.

אפשר להגדיר מאפייני כתיבה אחרים של Apache Iceberg, כמו write.target-file-size-bytes ו-write.parquet.page-size-bytes, ממנועים בקוד פתוח, אבל יכול להיות שמשימות הכתיבה וניהול הטבלאות ב-BigQuery לא יעמדו בהם.

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