מבוא לטבלאות חיצוניות ב-BigLake

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

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

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

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

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

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

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

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

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

צירופים בין עננים

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

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

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

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

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

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

ההרשאות הנדרשות

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

  • bigquery.jobs.create
  • bigquery.tables.getData

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

עלויות של צירוף בין עננים

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

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

דוגמאות לצירוף בין עננים

השאילתה הבאה מצטרפת לטבלת 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. אפשר לראות את פעולת ה-CTAS של הילד ואת המטא-נתונים שלה בהיסטוריית הפעולות.

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;

דוגמה נוספת: הצטרפות בין עננים:

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:

ארכיטקטורת BigLake.

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

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

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

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

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

מגבלות

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

  • ‫BigLake לא תומך בפרטי כניסה עם הרשאות מוגבלות מ-Dataproc 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 תומכות בפורמטים הבאים:

  • אי אפשר להשתמש במטא-נתונים במטמון עם טבלאות חיצוניות של 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
‫BigQuery משתמש ב-CMETA כמערכת מבוזרת של מטא-נתונים כדי לטפל בטבלאות גדולות בצורה יעילה. ‫CMETA מספק מטא-נתונים פרטניים ברמת העמודה והבלוק, שאפשר לגשת אליהם דרך טבלאות מערכת. המערכת הזו עוזרת לשפר את הביצועים של השאילתות על ידי אופטימיזציה של הגישה לנתונים ושל העיבוד שלהם. כדי לשפר עוד יותר את ביצועי השאילתות בטבלאות גדולות, BigQuery שומר מטמון של מטא-נתונים. משימות רענון של CMETA דואגות שהמטמון הזה יהיה עדכני.

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

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

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


תמחור על פי דרישה
מהדורות Standard,‏ Enterprise ו-Enterprise Plus

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

רענון ידני של מטמון המטא-נתונים.
תחויבו על בסיס בייט על העיבוד של רענון המטמון.
יחידות קיבולת (Slot) בהקצאות של הזמנות עם QUERYסוג העבודה נצרכות במהלך רענון המטמון.

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

אם אין BACKGROUND מקומות שמורים זמינים לרענון מטמון המטא-נתונים, BigQuery משתמש אוטומטית ביחידות קיבולת (slot) בQUERY מקומות שמורים במקום זאת, אם אתם משתמשים במהדורת Enterprise או Enterprise Plus.

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

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

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

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