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

שאילתות גלובליות מאפשרות להריץ שאילתות 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.
  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

בחירת מיקום

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

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

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

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

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

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

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

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

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

כדי להשתמש בנתונים שנמצאים במיקומים שונים, צריך לשכפל אותם למיקום אחד. התרשים הבא הוא אבסטרקציה של תהליך העבודה של שאילתה גלובלית שמבוצעת על ידי 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.globalQueryRemoteRegions: מערך של מחרוזות שמייצגות את האזורים המרוחקים ששאילתה גלובלית ניגשת לנתונים שלהם. השדה הזה מתמלא רק עבור עבודות של שאילתות גלובליות ראשיות באזור הביצוע הראשי. הוא ריק במקרה של עבודות שאילתה גלובליות של צאצאים ושאילתות באזור יחיד.
  • ‫statistics.parentGlobalQueryJob: אובייקט 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.
  • ‫LOG_DATASET: מערך הנתונים המקושר ב-BigQuery ל-Log Analytics או מערך הנתונים של יעד sink ביומן.
  • ‫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.

מגבלות

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