מבוא לטבלאות BigLake

במסמך הזה מופיעה סקירה כללית של BigLake. מניחים שהקוראים מכירים טבלאות של מסדי נתונים וניהול זהויות והרשאות גישה (IAM). כדי לשלוח שאילתות לנתונים שמאוחסנים במאגרי הנתונים הנתמכים, צריך קודם ליצור טבלאות BigLake ואז לשלוח להן שאילתות באמצעות תחביר GoogleSQL:

• יוצרים טבלאות BigLake ב-Cloud Storage ואז מריצים שאילתות.
• יוצרים טבלאות Amazon S3 BigLake ואז מריצים שאילתות.
• יוצרים טבלאות BigLake ב-Azure Blob Storage ואז מריצים שאילתה.

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

טבלאות BigLake מאפשרות להריץ שאילתות על נתונים מובְנים במאגרי נתונים חיצוניים באמצעות הקצאת הרשאות גישה. הענקת הרשאות גישה מפרידה בין הגישה לטבלת BigLake לבין הגישה למאגר הנתונים הבסיסי. חיבור חיצוני שמשויך לחשבון שירות משמש לחיבור למאגר הנתונים. חשבון השירות מטפל באחזור הנתונים ממאגר הנתונים, ולכן צריך רק להעניק למשתמשים גישה לטבלת BigLake. כך אפשר לאכוף אבטחה ברמת הטבלה, כולל אבטחה ברמת השורה וברמת העמודה. בטבלאות BigLake שמבוססות על Cloud Storage, אפשר גם להשתמש בהסתרת נתונים דינמית. מידע נוסף על פתרונות ניתוח מרובי עננים באמצעות טבלאות BigLake עם נתונים מ-Amazon S3 או מ-Blob Storage זמין במאמר בנושא BigQuery Omni.

מאגרי נתונים נתמכים

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

• ‫Amazon S3 באמצעות BigQuery Omni
• ‫Blob Storage באמצעות BigQuery Omni
• Cloud Storage

תמיכה בטבלה זמנית

טבלאות BigLake שמבוססות על Cloud Storage יכולות להיות זמניות או קבועות. טבלאות BigLake שמבוססות על Amazon S3 או על Blob Storage חייבות להיות קבועות.

כמה קובצי מקור

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

צירופים ב-BigQuery Omni

בעזרת הצטרפות ל-BigQuery Omni, אפשר להריץ שאילתות שכוללות אזורים שלGoogle Cloud ושל BigQuery Omni. אתם יכולים להשתמש בפעולות של GoogleSQL JOIN כדי לנתח נתונים בפתרונות אחסון שונים, כמו AWS,‏ Azure, מערכי נתונים ציבוריים ושירותים אחרים של Google Cloud . הצטרפות ל-BigQuery Omni מבטלת את הצורך להעתיק נתונים ממקורות שונים לפני שמריצים שאילתות.

אפשר להפנות לטבלאות BigLake בכל מקום בהצהרת SELECT כאילו הן טבלאות BigQuery רגילות, כולל בהצהרות של שפת טיפול בנתונים (DML) ושל שפת הגדרת נתונים (DDL) שמשתמשות בשאילתות משנה כדי לאחזר נתונים. אפשר להשתמש בכמה טבלאות BigLake מעננים שונים ובטבלאות BigQuery באותה שאילתה. כל הטבלאות ב-BigQuery צריכות להיות מאותו אזור.

ההרשאות הנדרשות לצירוף ב-BigQuery Omni

כדי לקבל את ההרשאות שדרושות להרצת הצטרפות ב-BigQuery Omni, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט שבו מתבצעת ההצטרפות:

• BigQuery Data Viewer (roles/bigquery.dataViewer)
• BigQuery Job User (roles/bigquery.jobUser)

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

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

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

עלויות של הצטרפות ב-BigQuery Omni

כשמריצים פעולת צירוף ב-BigQuery Omni,‏ BigQuery מנתח את השאילתה לחלקים מקומיים ומרוחקים. החלק המקומי נחשב לשאילתה רגילה באזור BigQuery. החלק המרוחק מומר לפעולת CREATE TABLE AS SELECT (CTAS) בטבלת BigLake שאליה מתבצעת ההפניה באזור BigQuery Omni, ונוצרת טבלה זמנית באזור BigQuery שלכם. לאחר מכן, BigQuery משתמש בטבלה הזמנית הזו כדי להפעיל את הצירוף של BigQuery Omni ומוחק את הטבלה באופן אוטומטי אחרי שמונה שעות.

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

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

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

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

מגבלות של הצטרפות ב-BigQuery Omni

• אי אפשר להשתמש בצירופים של BigQuery Omni ברמת השימוש בחינם של BigQuery ובארגז החול של BigQuery.
• יכול להיות שהצטברויות לא יועברו לאזורים של BigQuery Omni אם השאילתה מכילה הצהרות JOIN.
• כל טבלה זמנית משמשת רק לשאילתת BigQuery Omni אחת, ולא נעשה בה שימוש חוזר גם אם אותה שאילתה חוזרת על עצמה כמה פעמים.
• הגודל המקסימלי של כל העברה הוא 60GB. במילים אחרות, אם מחילים מסנן על טבלת BigLake וטוענים את התוצאה, היא צריכה להיות קטנה מ-60GB. במקרה הצורך, אפשר לבקש שינוי מכסות. אין הגבלה על מספר הבייטים שנסרקים.
• שאילתות של צירוף ב-BigQuery Omni משתמשות במכסה פנימית על קצב השאילתות. אם קצב השאילתות חורג מהמכסה, יכול להיות שתקבלו שגיאה All our servers are busy processing data transferred between regions. ברוב המקרים, ניסיון חוזר של השאילתה אמור לפתור את הבעיה. כדי להגדיל את המכסה הפנימית ולתמוך בקצב גבוה יותר של שאילתות, צריך לפנות לתמיכה.
• הצטרפות ל-BigQuery Omni נתמכת רק באזורים ב-BigQuery שמוצבים באותו מיקום עם האזורים התואמים ב-BigQuery Omni, ובאזורים US ו-EU במספר אזורים. לשאילתות של צירוף ב-BigQuery Omni שמופעלות באזורים US או EU במספר אזורים יש גישה רק לנתונים באזורים של BigQuery Omni בארה"ב או באיחוד האירופי, בהתאמה.
• אם שאילתת צירוף ב-BigQuery Omni מפנה ל-10 מערכי נתונים או יותר מאזורים של BigQuery Omni, יכול להיות שהיא תיכשל עם השגיאה Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. כדי להימנע מהבעיה הזו, מומלץ לציין מיקום באופן מפורש כשמריצים שאילתת איחוד ב-BigQuery Omni שמפנה ליותר מ-10 מערכי נתונים. חשוב לדעת שאם מציינים באופן מפורש אזור BigQuery והשאילתה מכילה רק טבלאות BigLake, השאילתה מופעלת כשאילתת BigQuery Omni וכוללת עלויות של העברת נתונים.
• אי אפשר להריץ שאילתות על עמודת ה-pseudo‏ _FILE_NAME באמצעות צירופים של BigQuery Omni.
• כשמפנים לעמודות של טבלת BigLake בWHERE פסקה, אי אפשר להשתמש בערכים מילוליים INTERVAL או RANGE.
• בג'ובים של צירוף ב-BigQuery Omni לא מדווח על מספר הבייטים שעוברים עיבוד והעברה מעננים אחרים. המידע הזה זמין בעבודות ה-CTAS של הילד שנוצרות כחלק מהרצת שאילתות ב-BigQuery Omni.
• תצוגות מורשות ושגרות מורשות שמפנות לטבלאות או לתצוגות של BigQuery Omni נתמכות רק באזורים של BigQuery Omni.
• אם השאילתה שלכם ב-BigQuery Omni מפנה לעמודות STRUCT, לא יחולו דחיפות על אף אחת מהשאילתות המשנה המרוחקות. כדי לשפר את הביצועים, כדאי ליצור תצוגה באזור BigQuery Omni שמפצלת את השדות הנדרשים מעמודות STRUCT לעמודות נפרדות.
• ‫Collation לא נתמך בצירופים של BigQuery Omni.
• הצטרפות של BigQuery Omni לא תומכת בהצטרפות של תצוגות BigQuery Omni באמצעות פסקה ORDER BY.

דוגמאות לצירוף ב-BigQuery Omni

השאילתה הבאה מצטרפת לטבלת orders באזור BigQuery עם טבלת lineitem באזור BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

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

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

אחרי שהטבלה הזמנית נוצרת, הפעולה JOIN מסתיימת והשאילתה הבאה מופעלת:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

דוגמה נוספת: BigQuery Omni join הבא:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

בשאילתה הזו, סעיף LIMIT לא מועבר לאזור BigQuery Omni. כל הלקוחות בפלח השוק FURNITURE מועברים קודם לאזור BigQuery, ורק אחר כך מוחלת ההגבלה של 10.

מחברים

אפשר לגשת לנתונים בטבלאות BigLake שמבוססות על Cloud Storage באמצעות מחברים של BigQuery, מכלי עיבוד נתונים אחרים. לדוגמה, אפשר לגשת לנתונים בטבלאות BigLake מ-Apache Spark,‏ Apache Hive,‏ TensorFlow,‏ Trino או Presto. ממשק BigQuery Storage API אוכף מדיניות ניהול ברמת השורה והעמודה על כל גישה לנתונים בטבלאות BigLake, כולל דרך מחברים.

לדוגמה, בתרשים הבא מוצג איך BigQuery Storage API מאפשר למשתמשים לגשת לנתונים מורשים באמצעות מנועי שאילתות בקוד פתוח כמו Apache Spark:

מידע נוסף על מחברים שנתמכים על ידי BigQuery זמין במאמר מחברים של BigQuery.

טבלאות BigLake במאגרי אובייקטים

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

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

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

מגבלות

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

• ‫BigLake לא תומך בפרטי כניסה עם הרשאות מוגבלות מ-Managed Service for Apache Spark Personal Cluster Authentication. כפתרון עקיף, כדי להשתמש באשכולות עם אימות אשכולות אישי, צריך להחדיר את פרטי הכניסה באמצעות גבול גישה ריק עם הדגל --access-boundary=<(echo -n "{}"). לדוגמה, הפקודה הבאה מפעילה סשן של העברת פרטי כניסה בפרויקט בשם myproject עבור האשכול בשם mycluster:

  gcloud dataproc clusters enable-personal-auth-session \
      --region=us \
      --project=myproject \
      --access-boundary=<(echo -n "{}") \
      mycluster
  

• טבלאות BigLake הן לקריאה בלבד. אי אפשר לשנות טבלאות BigLake באמצעות הצהרות DML או שיטות אחרות.

• טבלאות BigLake תומכות בפורמטים הבאים:

  • Avro
  • CSV
  • Delta Lake
  • Iceberg
  • JSON
  • ORC
  • Parquet

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

• ‫BigQuery Storage API לא זמין בסביבות ענן אחרות, כמו AWS ו-Azure.

• אם משתמשים במטא-נתונים ששמורים במטמון, חלות המגבלות הבאות:

  • אפשר להשתמש רק במטא-נתונים במטמון עם טבלאות BigLake בפורמטים Avro,‏ ORC,‏ Parquet,‏ JSON ו-CSV.
  • אם יוצרים, מעדכנים או מוחקים קבצים ב-Amazon S3, שאילתות על הקבצים לא יחזירו את הנתונים המעודכנים עד לרענון הבא של מטמון המטא-נתונים. זה עלול להוביל לתוצאות לא צפויות. לדוגמה, אם מוחקים קובץ וכותבים קובץ חדש, יכול להיות שתוצאות השאילתה לא יכללו את הקובץ הישן ואת הקובץ החדש, בהתאם למועד העדכון האחרון של המטא-נתונים שנשמרו במטמון.
  • אי אפשר להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) עם מטא-נתונים במטמון בטבלאות BigLake שמפנות לנתונים ב-Amazon S3 או ב-Blob Storage.

מודל אבטחה

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

• מנהלים של מאגרי נתונים. בדרך כלל, האדמינים האלה מנהלים את כללי המדיניות של ניהול זהויות והרשאות גישה (IAM) בקטגוריות ובאובייקטים של Cloud Storage.
• אדמינים של מחסן נתונים (data warehouse). בדרך כלל האדמינים האלה יוצרים, מוחקים ומעדכנים טבלאות.
• מנתחי נתונים. מנתחי נתונים בדרך כלל קוראים נתונים ומריצים שאילתות.

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

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

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

• טבלאות BigLake ב-Amazon S3
• טבלאות BigLake ב-Cloud Storage

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

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

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

יש שני מאפיינים ששולטים בתכונה הזו:

• Maximum staleness מציין מתי שאילתות משתמשות במטא-נתונים שנשמרו במטמון.
• מצב מטמון של מטא-נתונים מציין את אופן איסוף המטא-נתונים.

כשמפעילים שמירת מטא-נתונים במטמון, מציינים את המרווח המקסימלי של מטא-נתונים לא עדכניים שמתקבל על הדעת לפעולות שמתבצעות בטבלה. לדוגמה, אם מציינים מרווח של שעה אחת, פעולות שמתבצעות בטבלה משתמשות במטא-נתונים שנשמרו במטמון אם הם רועננו בשעה האחרונה. אם המטא-נתונים שבמטמון ישנים יותר, הפעולה חוזרת לאחזור מטא-נתונים ממאגר הנתונים (Amazon S3 או Cloud Storage). אפשר לציין מרווח זמן בין 30 דקות ל-7 ימים.

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

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

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

  אם תבצעו כמה רענונים ידניים בו-זמנית, רק אחד מהם יצליח.

אם לא מרעננים את מטמון המטא-נתונים, התוקף שלו פג אחרי 7 ימים.

רענון ידני ואוטומטי של מטמון מתבצעים עם עדיפות לשאילתות INTERACTIVE.

שימוש בהזמנות ב-BACKGROUND

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

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

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

• אם אתם מרעננים ידנית את מטמון המטא-נתונים של טבלה, והגדרתם את מרווח הזמן של הנתונים המיושנים ליומיים, אתם צריכים להריץ את BQ.REFRESH_EXTERNAL_METADATA_CACHE הפרוצדורה של המערכת כל יומיים או פחות, אם אתם רוצים שהפעולות בטבלה ישתמשו במטא-נתונים שנשמרו במטמון.
• אם אתם מרעננים באופן אוטומטי את מטמון המטא-נתונים של טבלה, והגדרתם את מרווח הזמן של הנתונים הלא עדכניים ל-30 דקות, יכול להיות שחלק מהפעולות שלכם בטבלה יקראו ממאגר הנתונים אם רענון מטמון המטא-נתונים יימשך יותר זמן מהחלון הרגיל של 30 עד 60 דקות.

כדי למצוא מידע על עבודות רענון של מטא-נתונים, מריצים שאילתה על התצוגה INFORMATION_SCHEMA.JOBS, כמו בדוגמה הבאה:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

בטבלאות BigLake ב-Cloud Storage שמבוססות על קובצי Parquet, סטטיסטיקות של הטבלה נאספות במהלך רענון מטמון המטא-נתונים ומשמשות לשיפור תוכניות השאילתות.

מידע נוסף על שמירת מטא-נתונים במטמון

מידע נוסף על הגדרת אפשרויות לשמירה במטמון של מטא-נתונים זמין במאמרים בנושא יצירת טבלאות BigLake ב-Amazon S3 או יצירת טבלאות BigLake ב-Cloud Storage.

טבלאות עם מטמון ותצוגות חומריות

אתם יכולים להשתמש בתצוגות חומריות על טבלאות עם מטמון מטא-נתונים של BigLake כדי לשפר את הביצועים והיעילות כשמבצעים שאילתות על נתונים מובנים שמאוחסנים ב-Cloud Storage או ב-Amazon Simple Storage Service ‏ (Amazon S3). התצוגות החומריות האלה פועלות כמו תצוגות חומריות בטבלאות אחסון שמנוהלות על ידי BigQuery, כולל היתרונות של רענון אוטומטי והתאמה חכמה.

שילובים

אפשר לגשת לטבלאות BigLake ממספר תכונות אחרות של BigQuery וממספר שירותים של ה-CLI של gcloud, כולל השירותים הבאים שמודגשים כאן.

BigQuery sharing (לשעבר Analytics Hub)

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

BigQuery ML

אתם יכולים להשתמש ב-BigQuery ML כדי לאמן ולהפעיל מודלים ב-BigLake ב-Cloud Storage.

Sensitive Data Protection

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

עלויות

העלויות משויכות להיבטים הבאים של טבלאות BigLake:

• הרצת שאילתות על הטבלאות.
• רענון מטמון המטא-נתונים.

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

בטבלה הבאה אפשר לראות איך מודל התמחור משפיע על אופן החיוב של העלויות האלה:

בנוסף, תחויבו על אחסון וגישה לנתונים על ידי Cloud Storage,‏ Amazon S3 ו-Azure Blob Storage, בהתאם להנחיות התמחור של כל מוצר.

כש-BigQuery מבצע אינטראקציה עם Cloud Storage, יכול להיות שתחויבו בעלויות הבאות של Cloud Storage:

• עלויות אחסון הנתונים לפי כמות הנתונים המאוחסנים.
• עלויות אחזור נתונים עבור גישה לנתונים בסוגי האחסון Nearline,‏ Coldline ו-Archive. חשוב לנקוט משנה זהירות כשמבצעים שאילתות בטבלאות או כשמרעננים את מטמון המטא-נתונים ביחס לסוגי האחסון האלה, כי החיובים יכולים להיות משמעותיים.
• עלויות שימוש ברשת עבור נתונים שקוראים באזורים שונים, למשל כשמערך הנתונים ב-BigQuery והקטגוריה ב-Cloud Storage נמצאים באזורים שונים.
• חיובים על עיבוד נתונים. עם זאת, לא תחויבו על קריאות ל-API שמתבצעות על ידי BigQuery בשמכם, כמו קריאות לרישום או לקבלת משאבים.

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

• איך משדרגים טבלאות חיצוניות לטבלאות BigLake
• איך יוצרים טבלת BigLake ב-Cloud Storage
• איך יוצרים טבלת Amazon S3 BigLake
• איך יוצרים טבלת BigLake ב-Blob Storage
• איך יוצרים בדיקות של איכות הנתונים באמצעות Knowledge Catalog