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

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

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

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

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