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

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

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

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

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

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

  2. מפעילים את BigLake API.

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    להפעלת ה-API

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

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

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

  • הגדרת מאפייני הטבלה במצב של מכירת כרטיסי גישה: עורך BigLake ‏ (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 בטבלה. הוא מסיר רשומות של תמונות מצב שתוקפן פג מקובץ metadata.json, ואז מוחק פיזית קבצים של נתונים ומטא-נתונים שהיו שייכים רק לתמונות מצב שתוקפן פג ושלא קיימת יותר הפניה אליהם בתמונות מצב פעילות.

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

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

  • איחוד (דחיסה): תהליך האיחוד אחראי לשמירה על הצורה של הנתונים, על ידי מיזוג קבצים קטנים לקבצים גדולים יותר. האיחוד פועל אוטומטית ברקע אחרי כל שינוי בנתונים. קבצים נבחרים לדחיסה אם הגודל הממוצע שלהם ללא דחיסה קטן מ-50% מגודל קובץ היעד של 256MB. כל פעולת מיזוג יוצרת תמונת מצב חדשה של הטבלה. בדרך כלל, עבודות של מיזוג נתונים נדחות ומנסות שוב אחרי הפעלה של פעולות 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 באמצעות נקודת הקצה של קטלוג Apache Iceberg REST.
  • כל המגבלות הקיימות לגבי טבלאות 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, TIMESTAMP ו-TIMESTAMPTZ עם טרנספורמציות hour, day, month ו-year (למעט טרנספורמציית hour בשדות DATE).
  • אין תמיכה ביכולות מנוהלות בטבלאות עם טרנספורמציות 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 שמוגדר כברירת מחדל בקטלוג Lakehouse REST משמש לכתיבת קובצי נתונים.
write.metadata.path table location + /metadata הנתיב של קטגוריית ברירת המחדל ב-Cloud Storage שהוגדר לקטלוג Lakehouse 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 לא יתאימו להם.

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