מבוא לטבלאות אובייקטים

טבלאות אובייקטים הן טבלאות לקריאה בלבד של אובייקטים של נתונים לא מובְנים ב-Cloud Storage. הם מאפשרים לנתח נתונים לא מובְנים באמצעות פונקציות מרוחקות או הסקת מסקנות ב-BigQuery ML, ואז לצרף את התוצאות לשאר הנתונים המובְנים ב-BigQuery.

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

יצירת טבלאות אובייקטים

כדי ליצור טבלת אובייקטים, אפשר להשתמש בהצהרה CREATE EXTERNAL TABLE, כמו בדוגמה הבאה:

CREATE EXTERNAL TABLE `myproject.mydataset.myobjecttable`
WITH CONNECTION `myproject.us.myconnection`
OPTIONS ( object_metadata = 'SIMPLE', uris = ['gs://mybucket/*'] );

מידע נוסף על יצירת טבלאות אובייקטים זמין במאמר יצירת טבלאות אובייקטים.

סכימת טבלת האובייקטים

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

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

בטבלה הבאה מתוארת הסכימה הקבועה שבה משתמשות טבלאות האובייקטים:

שם השדה סוג מצב תיאור
uri מחרוזת יכול להיות ריק ‫uri: מזהה המשאב האחיד (URI) של האובייקט, בפורמט gs://bucket_name/[folder_name/]object_name.
generation מספר שלם יכול להיות ריק מספר הגנרציה של האובייקט, שמזהה את גרסת האובייקט.
content_type מחרוזת יכול להיות ריק השדה Content-Type של נתוני האובייקט, שמזהה את סוג המדיה. אם אובייקט מאוחסן ללא Content-Type, הוא מוחזר בתור application/octet-stream.
size מספר שלם יכול להיות ריק השדה Content-Length של הנתונים בבייטים.
md5_hash מחרוזת יכול להיות ריק גיבוב MD5 של הנתונים, שמקודד באמצעות base64. מידע נוסף על השימוש בגיבוב MD5 זמין במאמר מטא-נתונים של אובייקטים ב-Cloud Storage.
updated TIMESTAMP יכול להיות ריק הפעם האחרונה שבה בוצע שינוי במטא-נתונים של האובייקט.
metadata רשומה מרובה ערכים מטא-נתונים בהתאמה אישית של האובייקט. כל פריט של מטא-נתונים מיוצג כצמד מפתח/ערך בשדות הצאצא (metadata.)name ו-(metadata.)value של השדה metadata.
(metadata.)name מחרוזת יכול להיות ריק מזינים רשומת מטא-נתונים מסוימת.
(metadata.)value מחרוזת יכול להיות ריק ערך ברשומת מטא-נתונים ספציפית.
ref STRUCT יכול להיות ריק מטא-נתונים של Cloud Storage בניהול Google, שמאוחסנים בפורמט ObjectRef.

אפשר להשתמש בעמודה הזו כדי לשמור על ערכי ObjectRef בטבלאות רגילות. ערכי ObjectRef מאפשרים לשלב נתוני אובייקטים עם נתונים מובְנים.

השורות בטבלת אובייקטים נראות בערך כך:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  | ref.uri              | ref.version | ref.authorizer | ref.details                                              |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              | gs://mybucket/a.jpeg | 12345678    | us.conn        | {"gcs_metadata":{"content_type":"image/jpeg","md5_hash"… |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              | gs://mybucket/b.bmp  | 23456789    | us.conn        | {"gcs_metadata":{"content_type":"image/bmp","md5_hash"…  |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

תרחישים לדוגמה

אתם יכולים לשלוח שאילתות למטא-נתונים בטבלת אובייקטים באותו אופן שבו אתם שולחים שאילתות לכל טבלה אחרת ב-BigQuery. עם זאת, תרחיש השימוש העיקרי בטבלאות אובייקטים הוא הנגשת נתונים לא מובְנים לצורך ניתוח. אתם יכולים להשתמש ב-BigQuery ML כדי להריץ הסקות על טבלאות אובייקטים של תמונות באמצעות מודלים של TensorFlow,‏ TensorFlow Lite ו-PyTorch. אתם יכולים גם להשתמש בפונקציות מרוחקות כדי לנתח נתונים לא מובְנים כמעט בכל דרך שתרצו. לדוגמה, אתם יכולים ליצור פונקציה מרוחקת שמאפשרת לנתח תמונות באמצעות Cloud Vision, או פונקציה שמאפשרת לחלץ מטא-נתונים ממסמכי PDF באמצעות Apache Tika.

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

שילוב תיאור תרחיש לדוגמה מדריך
הפונקציה AI.GENERATE_TEXT ליצור טקסט באמצעות Gemini Enterprise Agent Platform, שותף או מודל פתוח. אתם רוצים ליצור טקסט מנתוני אובייקטים. יצירת טקסט באמצעות הפונקציה AI.GENERATE_TEXT
הפונקציה AI.GENERATE_EMBEDDING יוצרים הטמעות באמצעות מודל מולטי-מודאלי של Gemini Enterprise Agent Platform. אתם רוצים ליצור הטמעות לנתוני וידאו או תמונה כדי להשתמש בהן בחיפושים וקטוריים, בקלט של מודלים או בתרחישים אחרים לדוגמה. יצירת הטמעות של תמונות באמצעות הפונקציה AI.GENERATE_EMBEDDING

יצירת הטמעות של סרטונים באמצעות הפונקציה AI.GENERATE_EMBEDDING
מודלים מיובאים של BigQuery ML ייבוא מודלים של TensorFlow,‏ TensorFlow Lite או ONNX ל-BigQuery ML כדי להריץ הסקות מקומיות ב-BigQuery . אתם משתמשים במודלים בקוד פתוח או במודלים בהתאמה אישית שעומדים במגבלות הנתמכות. מדריך: הרצת הסקה בטבלת אובייקטים באמצעות מודל וקטור תכונות
פונקציות Cloud Run להשתמש בפונקציות Cloud Run כדי לקרוא לשירותים או למודלים שמתארחים. זהו השילוב הכי כללי. אתם מארחים בעצמכם את המודלים ב-Compute Engine, ב-Google Kubernetes Engine או בתשתית אחרת שבבעלות הלקוח.
הפונקציה ML.ANNOTATE_IMAGE להשתמש ב-Cloud Vision API כדי להוסיף הערות לתמונות. אתם רוצים להוסיף הערות לתמונות באמצעות מודל שעבר אימון מראש של Vision API. הוספת הערות לתמונות באמצעות הפונקציה ML.ANNOTATE_IMAGE
הפונקציה ML.PROCESS_DOCUMENT משתמשים ב-Document AI API כדי לחלץ תובנות ממסמכים. אתם רוצים להשתמש במעבדי מסמכים מותאמים אישית או כאלה שאומנו מראש ב-Document AI. עיבוד מסמכים באמצעות הפונקציה ML.PROCESS_DOCUMENT
הפונקציה ML.TRANSCRIBE משתמשים ב-Speech-to-Text API כדי לתמלל קובצי אודיו. אתם רוצים להשתמש במזהי דיבור מאומנים מראש או בהתאמה אישית של Speech-to-Text. תמלול קובצי אודיו באמצעות הפונקציה ML.TRANSCRIBE

אם אתם רוצים לצרף את התוצאות לנתונים מובְנים אחרים, אתם יכולים ליצור תצוגה או טבלה מתוצאות הניתוח. לדוגמה, ההצהרה הבאה יוצרת טבלה על סמך תוצאות ההסקה:

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

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

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

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

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

אחר כך אתם יכולים להשתמש באינדקס כדי למצוא את מה שאתם צריכים בתוצאות האלה:

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

יתרונות

ניתוח נתונים לא מובְנים באופן מקורי ב-BigQuery מספק את היתרונות הבאים:

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

כתובות URL חתומות

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

משתמשים בפונקציה EXTERNAL_OBJECT_TRANSFORM כדי ליצור כתובות URL חתומות, כמו בדוגמה הבאה:

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE `mydataset.myobjecttable`, ['SIGNED_URL']);

התוצאות שיתקבלו יהיו דומות לתוצאות הבאות:

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
—--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
—--------------------------------------------------------------------------------------------------

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

בקרת גישה

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

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

הגדרת מדיניות גישה ברמת השורה בטבלת אובייקטים מגבילה את הגישה של משתמש או קבוצה למטא-נתונים של האובייקטים בשורות שנבחרו, וגם לאובייקטים שמיוצגים על ידי השורות האלה. לדוגמה, ההצהרה הבאה מעניקה למשתמשת Alice גישה רק לשורות שמייצגות אובייקטים שנוצרו לפני 25 ביוני 2022:

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

כשהמדיניות הזו של גישה ברמת השורה מוגדרת, התוצאות הבאות נכונות לגבי אליס:

  • הרצת השאילתה SELECT * FROM my_dataset.my_object_table; מחזירה רק שורות עם ערך updated לפני 25 ביוני 2022.
  • הפעלת הסקה ב-my_dataset.my_object_table מחזירה רק חיזויים לאובייקטים שיש להם ערך updated לפני 25 ביוני 2022.
  • יצירת כתובות URL חתומות ל-my_dataset.my_object_table יוצרת רק כתובות URL לאובייקטים שיש להם ערך updated לפני 25 ביוני 2022.

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

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

מודל אבטחה

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

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

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

קובצי אובייקטים נתמכים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • אם אתם מרעננים באופן ידני את מטמון המטא-נתונים של טבלה, ומגדירים את מרווח הזמן של הנתונים הישנים ליומיים, אתם צריכים להריץ את הפרוצדורה של המערכת BQ.REFRESH_EXTERNAL_METADATA_CACHE כל יומיים או פחות אם אתם רוצים שהפעולות בטבלה ישתמשו במטא-נתונים שנשמרו במטמון.
  • אם אתם מרעננים באופן אוטומטי את מטמון המטא-נתונים של טבלה, ומגדירים את מרווח הזמן ל-30 דקות, יכול להיות שחלק מהפעולות בטבלה יקראו מ-Cloud Storage אם רענון מטמון המטא-נתונים יימשך יותר זמן מהחלון הרגיל של 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;

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

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

מגבלות

  • טבלאות אובייקטים הן לקריאה בלבד, כי הן ממופות לאובייקטים של נתונים לא מובְנים ב-Cloud Storage. אי אפשר לשנות טבלת אובייקטים או את הנתונים שלה.
  • אי אפשר להשתמש בטבלאות אובייקטים ב-SQL מדור קודם או בסביבות ענן אחרות, כמו Amazon Web Services (AWS) ו-Microsoft Azure.
  • אם אתם רוצים להסיק מסקנות באמצעות BigQuery ML, המודל וטבלת האובייקטים שבהם אתם משתמשים צריכים לעמוד בדרישות שמפורטות בקטע מגבלות.
  • שאילתות שכוללות טבלאות אובייקטים לא יכולות לגשת ליותר מ-10GB של מטא-נתונים של אובייקטים. לדוגמה, אם שאילתה ניגשת ל-100TB משילוב של עמודות מטא-נתונים בטבלאות אובייקטים ונתוני אובייקטים דרך כתובות URL חתומות, רק 10GB מתוך 100TB יכולים להגיע מעמודות המטא-נתונים.
  • טבלאות אובייקטים כפופות לאותן מגבלות כמו כל הטבלאות החיצוניות האחרות ב-BigQuery. למידע נוסף, ראו מכסות.
  • שאילתות בטבלאות אובייקטים כפופות לאותן מגבלות כמו כל השאילתות האחרות ב-BigQuery. למידע נוסף, ראו מכסות.
  • פונקציות מרוחקות שמעבדות נתונים לא מובְנים מטבלאות אובייקטים כפופות לאותן מגבלות כמו כל הפונקציות המרוחקות האחרות.
  • כתובות URL חתומות שנוצרו לאובייקטים בטבלת אובייקטים פגות אחרי 6 שעות, שזו מגבלת הזמן להרצת שאילתות.
  • אי אפשר להסיק מסקנות באמצעות BigQuery ML בתמחור על פי דרישה או במהדורת Standard.

  • הפונקציות הבאות לא נתמכות בתמחור על פי דרישה או במהדורת Standard:

  • טבלאות אובייקטים יכולות להכיל עד 300 מיליון שורות. כדי להשיג ביצועים אופטימליים של שאילתות ורישום, ציינו עד 10 מזהי URI של מקורות באפשרות uris של טבלת אובייקטים. אם תציינו יותר מ-10 מזהי URI של קטגוריות, המספר המקסימלי של קבצים שטבלת האובייקטים יכולה לתמוך בהם יקטן, ושאילתות עלולות להיכשל עם שגיאת זיכרון Resources exceeded during query execution אם המספר הכולל של הקבצים בקטגוריות גדול. אם אתם צריכים להפנות ליותר מ-10 קטגוריות, פצלו אותן לכמה טבלאות אובייקטים.

  • פעולות UNION ALL שמשלבות טבלאות אובייקטים ריקות ולא ריקות לא נתמכות, ויכול להיות שתופיע שגיאה.

  • בתוך היקף של VPC Service Controls, פונקציות AI לא יכולות לעבד את העמודה ref של טבלת אובייקטים. העמודה ref תמיד משתמשת בחיבור של טבלת האובייקטים בתור המאשר שלה, כלומר BigQuery יוצרת כתובת URL חתומה מסוג HTTPS לאובייקט, ו-Gemini Enterprise Agent Platform חוסמת אחזורים מסוג HTTP ו-HTTPS לפרויקטים בתוך היקף. הפונקציה כותבת את השגיאה INVALID_ARGUMENT: HTTP links are not supported for requests restricted by VPCSC. בשדה status של הפלט שלה. כדי לנתח את האובייקט, צריך להעביר ערך OBJ.MAKE_REF(uri) עם ארגומנט אחד, ששולח את ה-URI של Cloud Storage למודל בלי ליצור כתובת URL חתומה. ‫OBJ.MAKE_REF מאחזר מטא-נתונים של אובייקטים מ-Cloud Storage בכל פעם שהוא פועל, וזה יכול להיות פחות יעיל לעומסי עבודה גדולים. מידע נוסף זמין במאמר ניהול ערכי ObjectRef.

עלויות

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

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

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


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

שימוש בטבלאות אובייקטים עם BigQuery sharing

טבלאות אובייקטים תואמות ל-BigQuery sharing (לשעבר Analytics Hub). אפשר לפרסם מערכי נתונים שמכילים טבלאות אובייקטים בתור רשומות לשיתוף. מנויי השיתוף יכולים להירשם לנתונים האלה, שמקצים בפרויקט שלהם מערך נתונים לקריאה בלבד שנקרא מערך נתונים מקושר. המנויים יכולים לשלוח שאילתות לכל הטבלאות במערך הנתונים המקושר, כולל כל טבלאות האובייקטים. מידע נוסף זמין במאמר הרשמה ל-listing.

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