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

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

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

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

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

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

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

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

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

    להפעלת ה-API

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

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

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

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

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

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

שיקולי הגדרה

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

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

יש תמיכה רק בטבלאות Apache Iceberg V2 (זמינות כללית) ו-V3 (גרסת Preview). אין תמיכה בטבלאות 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 בטבלאות קיימות

כדי להפעיל DML ב-BigQuery בטבלה קיימת, צריך לעדכן את מאפיין הטבלה.

לדוגמה, ב-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);

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

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

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

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

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

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

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

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

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

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

כשיוצרים טבלה מ-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);

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

השבתת ניהול הטבלאות מונעת הוספה לתור של משימות אופטימיזציה עתידיות ברקע, אבל משימות פעילות שנמצאות בתהליך יושלמו. השבתת ניהול הטבלה לא משביתה את שפת הטיפול בנתונים (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).
  • בעיה ידועה: לא ניתן להשתמש ב-DDL ‏(ALTER TABLE ... DROP COLUMN) כדי להסיר עמודה ב-BigQuery ואז להוסיף אותה מחדש עם אותו שם.

מגבלות על שימוש בטיימר

  • כשהתכונה 'ניהול טבלאות' מופעלת, הערך המקסימלי המומלץ של המאפיין history.expire.max-snapshot-age-ms הוא 7 ימים.
  • ההגדרות ברמת הפרויקט או ברמת מערך הנתונים ב-BigQuery עבור time travel לא חלות. רק מאפייני ברירת המחדל של טבלאות Iceberg פעילים.

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

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

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

  • הפונקציה Coalesce לא תומכת במיון ליניארי ובמיון לפי ציר Z. אם הטבלה מכילה את המאפיינים האלה, אין ערובה לכך שהפריסה תישמר אחרי הפעלת coalesce. אם הטבלאות שלכם מכילות את המאפיינים האלה, הפעולה הכי טובה היא לא להפעיל את ניהול הטבלאות.

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

  • כשיוצרים או רושמים טבלאות ממנועי קוד פתוח, היכולות המנוהלות תומכות בחלוקה למחיצות רק בשדות מסוג 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 v2.
write.format.default parquet בטבלאות יש תמיכה רק בקובצי נתונים בפורמט Parquet.
write.data.path table location + /data נתיב ברירת המחדל של קטגוריית Cloud Storage שמוגדר לנקודת הקצה של קטלוג Apache Iceberg REST משמש לכתיבת קובצי נתונים.
write.metadata.path table location + /metadata נתיב ברירת המחדל של קטגוריית Cloud Storage שמוגדר לנקודת הקצה של קטלוג Apache Iceberg REST משמש לכתיבת קובצי מטא-נתונים.
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 ימים) אפשר להגדיר כל מספר שלם חיובי, אבל מומלץ להגדיר עד 7 ימים (604,800,000 מילישניות) כשהאפשרות 'ניהול טבלה' מופעלת. משימות לניהול טבלאות מוחקות תמונות מצב ישנות יותר ממשך הזמן שצוין.
history.expire.min-snapshots-to-keep 1 אפשר להגדיר כל מספר שלם חיובי. במשימות לניהול טבלאות נשמרות לפחות מספר תמונות המצב הזה.

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

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