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

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

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

  • bigquery.tables.getData
  • bigquery.jobs.create
  • storage.buckets.get
  • storage.objects.get

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

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

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

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

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

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

אם אתם יוצרים טבלה חיצונית שהיא לא BigLake שמבוססת על Cloud Storage, אתם יכולים להשתמש בכמה מקורות נתונים חיצוניים, בתנאי שלמקורות הנתונים האלה יש את אותה סכימה. האפשרות הזו לא נתמכת בטבלה חיצונית שהיא לא BigLake, שמבוססת על Bigtable או על Google Drive.

מגבלות

המגבלות הבאות חלות על טבלאות חיצוניות:

  • ב-BigQuery אין הבטחה לעקביות של נתונים בטבלאות של נתונים חיצוניים. שינויים בנתונים הבסיסיים בזמן ששאילתה פועלת יכולים לגרום להתנהגות לא צפויה.
  • יכול להיות שביצועי השאילתות בטבלאות חיצוניות יהיו איטיים בהשוואה לשאילתות על נתונים בטבלה רגילה ב-BigQuery. אם מהירות השאילתה חשובה לכם, טענו את הנתונים ל-BigQuery במקום להגדיר מקור נתונים חיצוני. הביצועים של שאילתה שכוללת טבלה חיצונית תלויים בסוג האחסון החיצוני. לדוגמה, שליחת שאילתות על נתונים שמאוחסנים ב-Cloud Storage מהירה יותר משליחת שאילתות על נתונים שמאוחסנים ב-Google Drive. באופן כללי, ביצועי השאילתה של טבלה חיצונית אמורים להיות שווים לקריאת הנתונים ישירות ממקור הנתונים.
  • אי אפשר לשנות טבלאות נתונים חיצוניות באמצעות DML או שיטות אחרות. טבלאות חיצוניות הן לקריאה בלבד ב-BigQuery.
  • אי אפשר להשתמש ב-method‏ TableDataList של API בפורמט JSON כדי לאחזר נתונים מטבלאות חיצוניות. מידע נוסף זמין במאמר tabledata.list. כדי לעקוף את המגבלה הזו, אפשר לשמור את תוצאות השאילתה בטבלת יעד. אחר כך אפשר להשתמש בשיטה TableDataList בטבלת התוצאות.
  • אי אפשר להריץ משימה ב-BigQuery שמייצאת נתונים מטבלה חיצונית. כדי לעקוף את המגבלה הזו, אתם יכולים לשמור את תוצאות השאילתה בטבלת יעד. לאחר מכן, מריצים משימת חילוץ על טבלת התוצאות.
  • אי אפשר להעתיק טבלה חיצונית.
  • אי אפשר להפנות לטבלה חיצונית בשאילתה של טבלת תווים כלליים לחיפוש.
  • טבלאות חיצוניות לא תומכות באשכולות. הן תומכות בחלוקה למחיצות בדרכים מוגבלות. למידע נוסף, ראו שליחת שאילתות לנתונים שחולקו למחיצות באופן חיצוני.
  • כששולחים שאילתה למקור נתונים חיצוני שהוא לא Cloud Storage, התוצאות לא נשמרות במטמון. (יש תמיכה בשאילתות GoogleSQL ב-Cloud Storage). אתם מחויבים על כל שאילתה בטבלה חיצונית, גם אם אתם מריצים את אותה שאילתה כמה פעמים. אם אתם צריכים להריץ שאילתה שוב ושוב על טבלה חיצונית שלא משתנה לעיתים קרובות, כדאי לכתוב את תוצאות השאילתה בטבלה קבועה ולהריץ את השאילתות על הטבלה הקבועה.
  • אתם יכולים להריץ עד 16 שאילתות בו-זמנית במקור נתונים חיצוני של Bigtable.
  • הרצה של שאילתה לכמה מסדי נתונים שמשתמשת בטבלה חיצונית עשויה לדווח על גבול תחתון של 0 בייטים של נתונים, גם אם מוחזרות שורות. הסיבה לכך היא שאי אפשר לקבוע את כמות הנתונים שעובדו מהטבלה החיצונית עד שהשאילתה עצמה מסתיימת. הרצת השאילתה לכמה מסדי נתונים כרוכה בעלות על עיבוד הנתונים האלה.
  • אי אפשר להשתמש ב-_object_metadata כשם עמודה בטבלאות חיצוניות. היא שמורה לשימוש פנימי בלבד.
  • ב-BigQuery אי אפשר להציג נתונים סטטיסטיים של אחסון טבלאות חיצוניות.
  • טבלאות חיצוניות לא תומכות בשמות גמישים של עמודות.
  • ‫BI Engine לא תומך בשאילתות לטבלאות חיצוניות.
  • ב-BigQuery אין תמיכה ב-Data Boost כשקוראים נתוני Bigtable מ-BigQuery.
  • ב-BigQuery אין תמיכה בחלונות זמן לשמירת נתונים מסוג Time Travel או Fail-safe בטבלאות חיצוניות. עם זאת, בטבלאות חיצוניות של Apache Iceberg, אתם יכולים להשתמש בסעיף FOR SYSTEM_TIME AS OF כדי לגשת לתמונות מצב שנשמרות במטא-נתונים של Iceberg.
  • כל המגבלות הספציפיות לפורמט חלות:

שיקולים בקשר למיקום

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

Cloud Storage

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

  • קטגוריות באזור יחיד

    אם הקטגוריה של Cloud Storage נמצאת באזור us-central1 (איווה), מערך הנתונים ב-BigQuery צריך להיות באזור us-central1 (איווה) או במספר האזורים US.

    אם הקטגוריה של Cloud Storage נמצאת באזור europe-west4 (הולנד), מערך הנתונים ב-BigQuery צריך להיות באזור europe-west4 (הולנד) או במספר האזורים EU.

    אם הקטגוריה של Cloud Storage נמצאת באזור europe-west1 (בלגיה), מערך הנתונים התואם ב-BigQuery צריך להיות גם באזור europe-west1 (בלגיה) או במספר אזורים EU.

  • קטגוריות בשני אזורים

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

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

    אם הקטגוריה של Cloud Storage נמצאת באזור הכפול המוגדר מראש ASIA1, מערך הנתונים התואם ב-BigQuery צריך להיות באזור asia-northeast1 (טוקיו) או באזור asia-northeast2 (אוסקה).

    אם הקטגוריה של Cloud Storage נמצאת בשני אזורים שניתנים להגדרה, שכוללים את האזור australia-southeast1 (סידני) ואת האזור australia-southeast2 (מלבורן), הקטגוריה התואמת של BigQuery צריכה להיות באזור australia-southeast1 (סידני) או באזור australia-southeast2 (מלבורן).

  • קטגוריות במספר אזורים

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

    אם מערך הנתונים ב-BigQuery נמצא במספר האזורים US, הקטגוריה התואמת ב-Cloud Storage צריכה להיות במספר האזורים US, באזור היחיד us-central1 (איווה), בשני אזורים שכוללים את us-central1 (איווה), כמו שני האזורים NAM4, או בשני אזורים שניתנים להגדרה שכוללים את us-central1.

    אם מערך הנתונים ב-BigQuery נמצא במספר האזורים EU, הקטגוריה התואמת ב-Cloud Storage צריכה להיות במספר האזורים EU, באזור היחיד europe-west1 (בלגיה) או europe-west4 (הולנד), או בשני אזורים שכוללים את europe-west1 (בלגיה) או europe-west4 (הולנד), כמו שני האזורים EUR4, או בשני אזורים שניתנים להגדרה שכוללים את europe-west1 או europe-west4.

מידע נוסף על מיקומי Cloud Storage נתמכים זמין במאמר מיקומי קטגוריות במסמכי התיעוד של Cloud Storage.

Bigtable

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

  • אזור יחיד: אם מערך הנתונים ב-BigQuery נמצא במיקום האזורי בלגיה (europe-west1), המכונה התואמת ב-Bigtable צריכה להיות באזור בלגיה.
  • מספר אזורים: מכיוון שהביצועים של שאילתות חיצוניות תלויים בזמן אחזור מינימלי וברוחב פס אופטימלי של הרשת, לא מומלץ להשתמש במיקומים של מערכי נתונים במספר אזורים לטבלאות חיצוניות ב-Bigtable.

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

Google Drive

שיקולי מיקום לא רלוונטיים למקורות נתונים חיצוניים ב-Google Drive.

העברת נתונים בין מיקומים

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

  1. מייצאים את הנתונים מהטבלאות ב-BigQuery לקטגוריה של Cloud Storage.

    אין חיובים על ייצוא נתונים מ-BigQuery, אבל יש חיובים על אחסון הנתונים שיוצאו ב-Cloud Storage. הייצוא ל-BigQuery כפוף למגבלות על משימות חילוץ.

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

    העברת נתונים בין אזורים כרוכה בחיובים על תעבורת נתונים יוצאת (egress) ברשת ב-Cloud Storage.

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

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

אפשר גם להשתמש ב- Managed Service for Apache Airflow כדי להעביר ולהעתיק מערכי נתונים גדולים באופן פרוגרמטי.

למידע נוסף על השימוש ב-Cloud Storage לאחסון ולהעברה של מערכי נתונים גדולים, קראו את המאמר שימוש ב-Cloud Storage עם Big Data.

אופטימיזציה של שאילתות בטבלאות חיצוניות ב-Cloud Storage

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

‫Rapid Cache מספק מטמון קריאה אזורי שמגובה ב-SSD לקטגוריות של Cloud Storage. כשהתכונה מופעלת, BigQuery משתמש ב-Rapid Cache כדי להציג בקשות קריאה של אובייקטים, ומספק לכם:

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

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

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

תמחור

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

אם הנתונים שלכם מאוחסנים ב-ORC או ב-Parquet ב-Cloud Storage, קראו את המאמר חישוב גודל הנתונים.

בנוסף, תחויבו על אחסון הנתונים ועל כל המשאבים שבהם משתמשת אפליקציית המקור, בכפוף להנחיות התמחור של האפליקציה:

  • למידע על התמחור של Cloud Storage, ראו תמחור של Cloud Storage. החיובים ב-Cloud Storage עשויים לכלול את הדברים הבאים:

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

  • למידע על התמחור של Bigtable, קראו את המאמר תמחור.

  • למידע על התמחור של Drive, ראו תמחור.

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