שאילתות גלובליות

שאילתות גלובליות מאפשרות להריץ שאילתות SQL שמפנות לנתונים שמאוחסנים ביותר מאזור אחד. לדוגמה, אפשר להריץ שאילתה גלובלית שמצטרפת לטבלה שנמצאת ב-us-central1 עם טבלה שנמצאת ב-europe-central2. במאמר הזה מוסבר איך להפעיל ולהריץ שאילתות גלובליות בפרויקט.

לפני שמתחילים

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

הפעלת שאילתות גלובליות

כדי להפעיל שאילתות גלובליות בפרויקט או בארגון, משתמשים בהצהרה ALTER PROJECT SET OPTIONS או בהצהרה ALTER ORGANIZATION SET OPTIONS כדי לשנות את הגדרת ברירת המחדל.

  • כדי להריץ שאילתות גלובליות באזור מסוים, צריך להגדיר את הארגומנט enable_global_queries_execution לערך true באזור הזה עבור הפרויקט שמריץ את השאילתה.
  • כדי לאפשר לשאילתות גלובליות להעתיק נתונים מאזור מסוים, צריך להגדיר את הארגומנט enable_global_queries_data_access לערך true באזור הזה עבור הפרויקט שמכיל את הנתונים.
  • האפשרויות האלה מסומנות בכל פעם שהשאילתה ניגשת לטבלאות מרוחקות.
  • אפשר להריץ שאילתות גלובליות בפרויקט אחד ולשלוף נתונים מאזורים אחרים מפרויקט אחר.

דוגמה: הגדרה חוצת-פרויקטים

בדוגמה הבאה מוצג איך להריץ שאילתה בפרויקט אחד כדי לגשת לטבלה בפרויקט אחר.

נניח שיש לכם פרויקט query_project שמריץ משימות באזור us-central1, ואתם רוצים להריץ שאילתה שמתייחסת לטבלה data_project.dataset.my_table שנמצאת באזור europe-west1:

SET @@location='us-central1';
SELECT
  *
FROM
  `query_project.dataset.my_table`
  JOIN `data_project.dataset.my_other_table` USING id;

כדי שהשאילתה עם אחזור נתונים גלובלי הזו תפעל בהצלחה, נדרשת ההגדרה הבאה:

  1. צריך להפעיל את ההרצה של שאילתות גלובליות בפרויקט (query_project) באזור שבו מורצת שאילתה גלובלית (us-central1):

    ALTER PROJECT `query_project`
SET OPTIONS (
`region-us-central1.enable_global_queries_execution` = TRUE
);

  2. צריך להפעיל העתקת נתונים באמצעות שאילתות גלובליות מהפרויקט שמכיל את הנתונים (data_project) לאזור שלו (europe-west1):

    ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
);

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

צריך להריץ את הפעולות ALTER PROJECT האלה בנפרד כי הן מתייחסות לפרויקטים ולאזורים שונים. יכול להיות שיחלפו כמה דקות עד שהשינוי ייכנס לתוקף.

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

כדי להריץ שאילתה עם אחזור נתונים גלובלי, נדרשת ההרשאה bigquery.jobs.createGlobalQuery. התפקיד BigQuery Admin הוא התפקיד המוגדר מראש היחיד שמכיל את ההרשאה הזו. כדי להעניק הרשאה להריץ שאילתות גלובליות בלי להעניק את תפקיד האדמין ב-BigQuery, פועלים לפי השלבים הבאים:

  1. יוצרים תפקיד בהתאמה אישית, לדוגמה BigQuery global queries executor (מריץ שאילתות גלובליות ב-BigQuery).
  2. הוספת bigquery.jobs.createGlobalQuery לתפקיד הזה.
  3. מקצים את התפקיד הזה למשתמשים או לחשבונות שירות נבחרים.

שאילתת נתונים

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

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

SELECT id, tr_date, product_id, price FROM us_dataset.transactions
UNION ALL
SELECT id, tr_date, product_id, price FROM europe_dataset.transactions

המיקום ייבחר אוטומטית

במקרים הבאים, המיקום שבו צריך להריץ את השאילתה נקבע באופן אוטומטי ואי אפשר לשנות אותו:

  • שאילתות בשפת שינוי נתונים (הצהרות INSERT, UPDATE, DELETE) תמיד מופעלות במיקום של טבלת היעד.
  • שאילתות בשפת הגדרת נתונים (DDL), כמו הצהרת CREATE TABLE AS SELECT, תמיד מבוצעות במיקום שבו נוצר או משתנה משאב.
  • שאילתות עם טבלת יעד שצוינה תמיד מופעלות במיקום שבו נמצאת טבלת היעד.

בחירת מיקום

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

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

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

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

הסבר על שאילתות גלובליות

כדי להריץ שאילתות גלובליות בצורה יעילה וחסכונית, חשוב להבין את המנגנון שמאחורי ההרצה שלהן.

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

  1. קובעים איפה צריך להריץ את השאילתה – בהצהרה של המשתמש או באופן אוטומטי. המיקום הזה נקרא מיקום ראשי, וכל שאר המיקומים שאליהם מתייחסת השאילתה הם מרוחקים.
  2. מריצים שאילתת משנה בכל אזור מרוחק כדי לאסוף את הנתונים שנדרשים להשלמת השאילתה באזור הראשי.
  3. מעתיקים את הנתונים האלה ממיקומים מרוחקים למיקום הראשי.
  4. שמירת הנתונים בטבלאות זמניות במיקום הראשי למשך 24 שעות.
  5. מריצים שאילתה סופית עם כל הנתונים שנאספו במיקום הראשי.
  6. החזרת תוצאות השאילתה.

מערכת BigQuery מנסה לצמצם את כמות הנתונים שמועברים בין אזורים. דוגמה:

SET @@location = 'EU';
SELECT
  t1.col1, t2.col2
FROM
  eu_dataset.table1 t1
  JOIN us_dataset.table2 t2 using col3
WHERE
  t2.col4 = 'ABC'

ב-BigQuery אין צורך לשכפל את כל הטבלה t2 מארה"ב לאיחוד האירופי. מספיק להעביר רק את העמודות המבוקשות (col2 ו-col3) ורק את השורות שתואמות לתנאי WHERE (t2.col4 = 'ABC'). עם זאת, המנגנונים האלה, שנקראים pushdowns, תלויים במבנה השאילתה, ולפעמים כמות הנתונים שמועברת עשויה להיות גדולה. מומלץ לבדוק שאילתות גלובליות על קבוצת משנה קטנה של נתונים ולוודא שהנתונים מועברים רק כשצריך.

ניראות (observability)

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

היסטוריית הפעולות

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

Jobs REST API

כשקוראים ל-method‏ jobs.get, המשאב Job שמוחזר מכיל את השדות הבאים באובייקט JobStatistics:

  • ‫statistics.global_query_remote_regions: מערך של מחרוזות שמייצגות את האזורים המרוחקים ששאילתה גלובלית ניגשת לנתונים שלהם. השדה הזה מתמלא רק עבור עבודות של שאילתות גלובליות ראשיות באזור הביצוע הראשי. הוא ריק במקרה של עבודות של שאילתות גלובליות של צאצאים ושל שאילתות באזור יחיד.
  • ‫statistics.parent_global_query_job: אובייקט JobReference (projectId, ‏ jobId, ‏ location) שמזהה את עבודת השאילתה הגלובלית הראשית. השדה הזה מאוכלס רק עבור עבודות של שאילתות גלובליות צאצא (שאילתות משנה מרחוק ועבודות העתקה בין אזורים) שמופעלות באזורים מרוחקים בשם שאילתה גלובלית. הערך לא מוגדר לגבי עבודות של שאילתות גלובליות ראשיות ושאילתות באזור יחיד.

יומני ביקורת

ביומני ביקורת של Cloud, האובייקט BigQueryAuditMetadata מכיל את השדות הבאים באובייקט JobStats:

  • ‫jobStats.globalQueryRemoteRegions: מערך של מחרוזות שמייצגות את האזורים המרוחקים שהשאילתה ניגשת אליהם. השדה הזה מתמלא רק עבור עבודות של שאילתות גלובליות ראשיות באזור הביצוע הראשי.
  • ‫jobStats.parentGlobalQueryJobId: מזהה המשימה של משימת השאילתה עם אחזור נתונים גלובלי הראשית. השדה הזה מאוכלס עבור עבודות משניות שמופעלות באזורים מרוחקים.
  • ‫jobStats.parentGlobalQueryJobLocation: המיקום של משימת השאילתה הגלובלית הראשית. השדה הזה מאוכלס עבור עבודות משניות שמופעלות באזורים מרוחקים.

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

כדי למצוא את כל העבודות של צאצאים מרוחקים שמשויכות לשאילתה גלובלית של אב, אפשר לשלוח שאילתה ליומני ביקורת באמצעות Log Analytics או מערך נתונים של יעד יומן מיוצא:

SELECT
  timestamp,
  proto_payload.audit_log.resource_name AS resource_name,
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobConfig.queryConfig.query) AS query
FROM
  `PROJECT_ID.LOG_DATASET._AllLogs`
WHERE
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobStats.parentGlobalQueryJobId) = 'PARENT_JOB_ID';

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט ב-Google Cloud.
  • ‫LOG_DATASET: מערך הנתונים המקושר ב-BigQuery ל-Log Analytics או מערך הנתונים של יעד יומן הנתונים.
  • ‫PARENT_JOB_ID: מזהה המשימה של משימת השאילתה עם אחזור נתונים גלובלי הראשית.

השבתת שאילתות גלובליות

כדי להשבית את השאילתות הגלובליות בפרויקט או בארגון, משתמשים ב-ALTER PROJECT SET OPTIONS statement או ב-ALTER ORGANIZATION SET OPTIONS statement כדי לשנות את הגדרת ברירת המחדל.

  • כדי להשבית שאילתות גלובליות באזור מסוים, מגדירים את הארגומנט enable_global_queries_execution לערך false או NULL באזור הזה.
  • כדי למנוע משאילתות גלובליות להעתיק נתונים מאזור מסוים, צריך להגדיר את הארגומנט enable_global_queries_data_access לערך false או NULL באותו אזור.

בדוגמה הבאה מוצג איך משביתים שאילתות גלובליות ברמת הפרויקט:

ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-REGION.enable_global_queries_execution` = false,
  `region-REGION.enable_global_queries_data_access` = false
);

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: שם הפרויקט שרוצים לשנות
  • ‫REGION: שם האזור שבו רוצים להשבית את השאילתות הגלובליות

יכול להיות שיחלפו כמה דקות עד שהשינוי ייכנס לתוקף.

תמחור

העלות של שאילתה גלובלית מורכבת מהרכיבים הבאים:

  • עלות החישוב של כל שאילתת משנה במיקומים מרוחקים, על סמך מודל התמחור שלכם במיקומים האלה
  • עלות החישוב של השאילתה הסופית באזור שבו היא מופעלת, על סמך מודל התמחור שלכם באזור הזה
  • העלות של העתקת נתונים בין מיקומים שונים, בהתאם לתמחור של רפליקציית נתונים
  • העלות של אחסון נתונים שהועתקו מאזורים מרוחקים לאזור הראשי (למשך 24 שעות), בהתאם לתמחור האחסון

מכסות

מידע על מכסות שקשורות לשאילתות גלובליות זמין במאמר Query jobs.

מגבלות

  • פרטי ההפעלה וגרף ההפעלה של שאילתה לא מציגים את מספר הבייטים שעברו עיבוד והועברו ממיקומים מרוחקים. המידע הזה מופיע בעבודות העתקה שאפשר למצוא בהיסטוריית העבודות. למזהה המשימה של משימת העתקה שנוצרה על ידי שאילתה גלובלית יש את מזהה המשימה של משימת השאילתה כקידומת.
  • אין תמיכה בשאילתות גלובליות במצב סביבת ארגז חול.
  • שאילתות גלובליות לא אפשריות כשמשתמשים בנקודות קצה אזוריות.
  • השהייה בשאילתות גלובליות גבוהה יותר מאשר בשאילתות באזור יחיד, כי נדרש זמן להעברת נתונים בין אזורים.
  • שאילתות גלובליות לא משתמשות במטמון כדי למנוע העברת נתונים בין אזורים.
  • אי אפשר לשלוח שאילתות לגבי עמודות פסאודו, כמו _PARTITIONTIME, באמצעות שאילתות גלובליות.
  • אי אפשר להריץ שאילתות גלובליות על עמודות מסוג RANGE.
  • אי אפשר לשלוח שאילתות לעמודות באמצעות שמות עמודות גמישים עם שאילתות גלובליות.
  • אי אפשר לשלוח שאילתה לגבי תצוגות של INFORMATION_SCHEMA מאזור מרוחק בשאילתה גלובלית.
  • אין תמיכה בתצוגות מורשות ובשגרות מורשות גלובליות (כשניתנת לתצוגה או לשגרה במיקום אחד הרשאה לגשת למערך נתונים במיקום אחר). במקום זאת, יוצרים תצוגות מורשות באזור שבו הנתונים נמצאים, ומריצים שאילתות על התצוגות המורשות באמצעות שאילתות גלובליות.
  • אין תמיכה בתצוגות חומריות של שאילתות גלובליות.
  • אם השאילתה הגלובלית מפנה לעמודות STRUCT, לא מוחלים שיפורים על אף אחת מהשאילתות המשניות המרוחקות. כדי לשפר את הביצועים, כדאי ליצור תצוגה באזור המרוחק שמסננת עמודות STRUCT ומחזירה רק את השדות הנדרשים כעמודות נפרדות.
  • הביצוע של שאילתות גלובליות לא מתבצע באופן אטומי. במקרים שבהם שכפול הנתונים מצליח, אבל השאילתה הכוללת נכשלת, עדיין תחויבו על שכפול הנתונים.
  • טבלאות זמניות שנוצרות באזורים מרוחקים כחלק מהרצת שאילתות גלובליות מוצפנות רק באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) אם מפתח CMEK שהוגדר להצפנת התוצאות של השאילתה הגלובלית (ברמת הטבלה, מערך הנתונים או הפרויקט) הוא גלובלי. כדי לוודא שטבלאות זמניות מרוחקות תמיד מוגנות באמצעות CMEK, צריך להגדיר מפתח KMS כברירת מחדל לפרויקט שבו מופעלות שאילתות גלובליות באזור המרוחק.
  • אין תמיכה בשאילתות גלובליות ב-Assured Workloads.
  • שאילתה גלובלית אחת יכולה לגשת לעד 10 טבלאות מרוחקות בכל אזור.
  • שאילתות גלובליות נתמכות רק ב-Data Studio כשהן עטופות בתצוגה ומוגדרות לשימוש בפרטי הכניסה של הצופה.