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

צירופים ב-BigQuery Omni

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

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

ההרשאות הנדרשות להצטרפות ל-BigQuery Omni

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

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

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

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

כדי להריץ שאילתת JOIN ב-BigQuery Omni, נדרשות ההרשאות הבאות:

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

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

עלויות של צירוף ב-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 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. פעולות JOIN ב-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 ותחויבו בעלויות של העברת נתונים.
  • אי אפשר לשלוח שאילתה לעמודה המדומה _FILE_NAME באמצעות צירופים של BigQuery Omni.
  • כשמפנים לעמודות של טבלת BigLake בסעיף WHERE, אי אפשר להשתמש בערכים מילוליים של INTERVAL או RANGE.
  • במשימות של BigQuery Omni לא מדווח מספר הבייטים שעובדו והועברו מעננים אחרים. המידע הזה זמין במשימות הצאצא של CTAS שנוצרות כחלק מהרצת השאילתה ב-BigQuery Omni.
  • תצוגות מורשות ושגרות מורשות שמפנות לטבלאות או לתצוגות של BigQuery Omni נתמכות רק באזורים של BigQuery Omni.
  • אם השאילתה ב-BigQuery Omni מפנה לעמודות STRUCT, לא מתבצעת דחיפה למטה של שאילתות משנה מרוחקות. כדי לשפר את הביצועים, כדאי ליצור תצוגה באזור של BigQuery Omni שפורקת את השדות הנדרשים מעמודות STRUCT לעמודות נפרדות.
  • אי אפשר להשתמש באיסוף בצירופים של BigQuery Omni.
  • בפעולות JOIN ב-BigQuery Omni אי אפשר להשתמש בסעיף ORDER BY כדי לצרף תצוגות של BigQuery Omni.

דוגמאות לצירוף ב-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. אתם יכולים לראות את משימת ה-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;

דוגמה נוספת: נניח שיש לכם את הצירוף הבא ב-BigQuery Omni:

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 לא תומך בפרטי כניסה עם היקף מצומצם מאימות של אשכול אישי ב-Managed Service for Apache Spark. כדי לעקוף את הבעיה ולהשתמש באשכולות עם אימות אישי, צריך להחדיר את פרטי הכניסה באמצעות גבול גישה ריק עם הדגל --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, שאילתות על הקבצים לא יחזירו את הנתונים המעודכנים עד לרענון הבא של המטמון של המטא-נתונים. זה עלול להוביל לתוצאות לא צפויות. לדוגמה, אם מוחקים קובץ וכותבים קובץ חדש, יכול להיות שתוצאות השאילתה לא יכללו את הקובץ הישן ואת הקובץ החדש, בהתאם למועד האחרון שבו עודכנו המטא-נתונים במטמון.
    • בטבלאות BigLake שמפנות לנתונים ב-Amazon S3 או ב-Blob Storage, אי אפשר להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) עם מטא-נתונים במטמון.

מודל אבטחה

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

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

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

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

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

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

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

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

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

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

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