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

אתם יכולים להשתמש באפשרויות של טבלאות בקטלוג ייעודי לזמן ריצה של 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) – הפרויקט
    • ‫Storage Object User‏ (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);

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

כדי להפעיל את 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 שפג תוקפם על ידי יצירת הגדרה נוספת של קובץ snapshot בקובץ מטא-נתונים חדש, שמשמיט הפניות לקובצי ה-snapshot שהוסרו.

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

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

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

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

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

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

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

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

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

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

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

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

  • אתם רוצים דחיסת קבצים אוטומטית ברקע (coalesce), תפוגה אוטומטית של תמונת מצב ואיסוף אשפה אחרי 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 וברירות המחדל שלהן פעילים.

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

  • אם הטבלה מכילה תמונות מצב עם תגים או הסתעפויות, המערכת מדלגת על תפוגת תמונות המצב של כל הטבלה. המערכת מתעלמת משמירה בהתאמה אישית שמוגדרת באמצעות ALTER... RETAIN x DAYS, ומתעלמת מכל הערכים שמוגדרים למאפיין history.expire.max-ref-age-ms. מנועי קוד פתוח עדיין יכולים לבצע פקיעת תוקף של קובצי snapshot.
  • ניהול הטבלאות לא משפיע על התוקף של הסכימות או של מפרטי המחיצות. הקובץ 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 תומכות רק ב-copy-on-write.
write.update.mode copy-on-write משימות כתיבה וניהול טבלאות ב-BigQuery תומכות רק ב-copy-on-write.
write.merge.mode copy-on-write משימות כתיבה וניהול טבלאות ב-BigQuery תומכות רק ב-copy-on-write.
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 לא יעמדו בהם.

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