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

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

טבלאות חיצוניות שאינן BigLake מאפשרות לשלוח שאילתות לנתונים מובנים במאגרי נתונים חיצוניים. כדי לשלוח שאילתות לטבלה חיצונית שאינה BigLake, צריך הרשאות לטבלה החיצונית ולמקור הנתונים החיצוני. לדוגמה, כדי להריץ שאילתה בטבלה חיצונית שאינה BigLake ומשתמשת במקור נתונים ב-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.
  • אי אפשר להשתמש בשיטה TableDataList API בפורמט JSON כדי לאחזר נתונים מטבלאות חיצוניות. מידע נוסף זמין במאמר tabledata.list. כדי לעקוף את ההגבלה הזו, אפשר לשמור את תוצאות השאילתה בטבלת יעד. אחר כך אפשר להשתמש בשיטה TableDataList בטבלת התוצאות.
  • אי אפשר להריץ משימת BigQuery שמייצאת נתונים מטבלה חיצונית. כדי לעקוף את ההגבלה הזו, אפשר לשמור את תוצאות השאילתה בטבלת יעד. לאחר מכן, מריצים עבודת חילוץ על טבלת התוצאות.
  • אי אפשר להעתיק טבלה חיצונית.
  • אי אפשר להפנות לטבלה חיצונית בשאילתת טבלת תווים כלליים לחיפוש.
  • טבלאות חיצוניות לא תומכות באשכולות. הם תומכים בחלוקה למחיצות בדרכים מוגבלות. פרטים נוספים זמינים במאמר בנושא שאילתות על נתונים שחולקו למחיצות באופן חיצוני.
  • כששולחים שאילתה למקור נתונים חיצוני שאינו Cloud Storage, התוצאות לא נשמרות במטמון. (יש תמיכה בשאילתות GoogleSQL ב-Cloud Storage). תחויבו על כל שאילתה שמופעלת על טבלה חיצונית, גם אם תפעילו את אותה שאילתה כמה פעמים. אם אתם צריכים להריץ שאילתה שוב ושוב על טבלה חיצונית שלא משתנה לעיתים קרובות, כדאי לכתוב את תוצאות השאילתה בטבלה קבועה ולהריץ את השאילתות על הטבלה הקבועה במקום זאת.
  • אפשר להריץ עד 16 שאילתות בו-זמנית במקור נתונים חיצוני של Bigtable.
  • בהרצת בדיקה של שאילתה לכמה מסדי נתונים שמשתמשת בטבלה חיצונית, יכול להיות שיוחזר ערך של 0 בייט של נתונים, גם אם השורות הוחזרו. הסיבה לכך היא שלא ניתן לקבוע את כמות הנתונים שעובדו מהטבלה החיצונית עד שהשאילתה בפועל מסתיימת. הפעלת השאילתה לכמה מסדי נתונים כרוכה בעלות על עיבוד הנתונים האלה.
  • אי אפשר להשתמש ב-_object_metadata כשם עמודה בטבלאות חיצוניות. הוא שמור לשימוש פנימי.
  • ב-BigQuery אין תמיכה בהצגת נתוני סטטיסטיקה של אחסון טבלאות עבור טבלאות חיצוניות.
  • בטבלאות חיצוניות אין תמיכה בשמות עמודות גמישים.
  • ‫BI Engine לא תומך בשאילתות לטבלאות חיצוניות.
  • ‫BigQuery לא תומך בData Boost for 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 כפופה למגבלות של עבודות טעינה.

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

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

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

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

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

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

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

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

תמחור

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

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

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

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

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

  • מידע על התמחור של Bigtable זמין במאמר תמחור.

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

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