מבוא לשאילתות מתמשכות

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

יעדים ומקורות נתונים נתמכים

אתם יכולים לכתוב או לייצא את שורות הפלט שנוצרו על ידי שאילתה מתמשכת ליעדים הבאים:

• טבלאות ב-BigQuery
• טבלאות מנוהלות של Apache Iceberg
• נושאי Pub/Sub
• טבלאות Bigtable
• טבלאות Spanner

שאילתות מתמשכות יכולות לעבד נתונים שנכתבו בטבלאות BigQuery רגילות או בטבלאות מנוהלות של Apache Iceberg באחת מהשיטות הבאות:

• BigQuery Storage Write API (gRPC)
• BigQuery Storage Write API (REST)
• טעינה באצווה
• פקודת DML של INSERT
• פקודות של שפת טיפול בנתונים (DML) לשינוי נתונים, כמו DELETE,‏ UPDATE ו-MERGE, כשמייצאים נתונים ל-Pub/Sub.
• כתיבה מתוצאות של שאילתת אצווה לטבלה קבועה
• כתיבה מהתוצאות של שאילתה מתמשכת ב-BigQuery לטבלה קבועה
• מינוי ל-Pub/Sub BigQuery
• כתיבה מ-Dataflow ל-BigQuery
• כתיבה מ-Datastream ל-BigQuery באמצעות מצב כתיבה של הוספה בלבד

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

תרחישים לדוגמה

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

• שירותים לאינטראקציה מותאמת אישית עם הלקוחות: שימוש ב-AI גנרטיבי כדי ליצור הודעות מותאמות אישית לכל אינטראקציה עם הלקוחות.
• זיהוי אנומליות: פיתוח פתרונות שמאפשרים לזהות אנומליות ואיומים בנתונים מורכבים בזמן אמת, כדי להגיב לבעיות מהר יותר.
• תהליכים מותאמים אישית מבוססי-אירועים: אפשר להשתמש בשילוב של שאילתות מתמשכות עם Pub/Sub כדי להפעיל אפליקציות במורד הזרם על סמך נתונים נכנסים.
• העשרת נתונים וחילוץ ישויות: שימוש בשאילתות מתמשכות כדי לבצע העשרת נתונים וטרנספורמציה בזמן אמת באמצעות פונקציות SQL ומודלים של למידת מכונה.
• חילוץ, טעינה וטרנספורמציה (ETL) הפוכים: ביצוע ETL הפוך בזמן אמת למערכות אחסון אחרות שמתאימות יותר להצגת אפליקציות עם זמן אחזור קצר. לדוגמה, ניתוח או שיפור של נתוני אירועים שנכתבים ב-BigQuery, ואז העברה שלהם בסטרימינג לטבלאות מנוהלות ב-Bigtable, ב-Spanner או ב-Apache Iceberg לצורך הצגה באפליקציה.
• הפעלה אוטונומית של סוכנים: הפעלה של פייפליינים מבוססי-סוכנים בזמן אמת על סמך אירועים מורכבים שזוהו בסטרימינג של נתונים בזמן אמת. דוגמה לכך מופיעה בשיעור ה-Codelab בנושא יצירת סוכן לאינטראקציה עם נתונים מבוסס-אירועים באמצעות BigQuery וערכה לפיתוח סוכנים (ADK).
• מעקב אוטונומי אחרי נציגים: פיתוח מעקב והתראות אוטומטיים בזמן אמת לאינטראקציות של נציגים בזמן אמת באמצעות הפלאגין BigQuery Agent Analytics, שמעביר את כל נתוני המעקב של הנציגים, השימוש בכלים ויומני התפעול ישירות ל-BigQuery כדי לקבל תצפית מעמיקה על כוח העבודה של ה-AI.

פונקציונליות נתמכת

הפעולות הבאות נתמכות בשאילתות מתמשכות:

• הרצת הצהרות INSERT כדי לכתוב נתונים משאילתה מתמשכת לטבלה ב-BigQuery או לטבלה מנוהלת ב-Iceberg.

• מריצים הצהרות EXPORT DATA כדי לפרסם את הפלט של השאילתה המתמשכת בנושאי Pub/Sub.

  כדי להריץ שאילתות מתמשכות שמייצאות נתונים ל-Pub/Sub, צריך להשתמש בחשבון שירות. מידע נוסף על ייצוא נתונים ל-Pub/Sub

  מנושא Pub/Sub, אתם יכולים להשתמש בנתונים עם שירותים אחרים, כמו ביצוע ניתוח נתונים בזמן אמת באמצעות Dataflow, או שימוש בנתונים בתהליך עבודה של Application Integration.

• הרצת הצהרות EXPORT DATA כדי לייצא נתונים מ-BigQuery לטבלאות Bigtable. מידע נוסף זמין במאמר ייצוא נתונים ל-Bigtable.

• מריצים הצהרות EXPORT DATA כדי לייצא נתונים מ-BigQuery לטבלאות של Spanner. מידע נוסף זמין במאמר ייצוא נתונים ל-Spanner (‏ETL הפוך).

• הפעלת הפונקציות הבאות של AI גנרטיבי:

  • AI.GENERATE

  • AI.GENERATE_TEXT

    • כדי להשתמש בפונקציה הזו, צריך מודל מרוחק של BigQuery ML שמבוסס על מודל של Gemini Enterprise Agent Platform.

• קריאה לפונקציות ה-AI הבאות:

  • ML.UNDERSTAND_TEXT
  • ML.TRANSLATE

  כדי להשתמש בפונקציות האלה, צריך מודל מרוחק של BigQuery ML ב-AI ב-Cloud API.

• נרמול נתונים מספריים באמצעות הפונקציה ML.NORMALIZER.

• ניתוח ועיבוד של נתוני JSON, כולל תמיכה בפונקציות JSON ובביטול ההתאמה של JSON.

• שימוש בפונקציות GoogleSQL ללא שמירת מצב, למשל פונקציות המרה. בפונקציות ללא שמירת מצב, כל שורה מעובדת בנפרד משורות אחרות בטבלה.

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

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

• שימוש בפונקציה CHANGES של היסטוריית השינויים כדי לעבד נתונים שהשתנו, כולל הוספות ושינויים, מנקודת זמן ספציפית כשמייצאים נתונים ל-Pub/Sub. עם זאת, אין תמיכה ב-CHANGES כשמשתמשים בפעולה עם שמירת מצב או כששולחים שאילתות לטבלאות מנוהלות של Iceberg.

• שליחת שאילתות לתצוגות, כל עוד שאילתת ה-SQL הבסיסית של התצוגה היא שאילתה מתמשכת תקינה.

פעולות נתמכות עם שמירת מצב

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

כדי לבקש תמיכה או לשלוח משוב על התכונה הזו, שלחו אימייל לכתובת [e-mail].

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

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

• JOINs
• צבירות וחלונות
• UNION ALL

הרשאה

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

מיקומים

רשימת האזורים הנתמכים מופיעה במאמר מיקומים של שאילתות מתמשכות ב-BigQuery.

מגבלות

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

• המצב של הנתונים שנקלטו נשמר רק בשביל הפעולות הספציפיות עם שמירת מצב בגרסת טרום-השקה (Preview). שאילתות מתמשכות תומכות עכשיו בסוגים מסוימים של JOIN, צבירות וצבירות של חלונות, אבל הן מוגבלות לפעולות ספציפיות עם שמירת מצב. לא כל סוגי הפעולות עם שמירת מצב נתמכים.

• אי אפשר להשתמש ביכולות ה-SQL הבאות בשאילתה מתמשכת, אלא אם הן מופיעות ברשימה של פעולות נתמכות עם שמירת מצב:

  • אופרטורי השאילתה הבאים:

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • אופרטורים של קבוצות בשאילתות, חוץ מ-UNION ALL.

  • ההצהרה SELECT DISTINCT

  • EXISTS או NOT EXISTS שאילתות משנה

  • ביטויי CTE רקורסיביים

  • פונקציות בהגדרת המשתמש (UDF)

  • קריאות לפונקציות אנליטיות (window function)

  • פונקציות של BigQuery ML שלא מפורטות בקטע פונקציונליות נתמכת

  • הצהרות של שפת הגדרת נתונים (DDL)

  • פקודות של שפת טיפול בנתונים (DML), חוץ מ-INSERT.

  • הצהרות של שפת בקרת נתונים (DCL)

  • הצהרות EXPORT DATA שלא מטרגטות את Bigtable,‏ Pub/Sub או Spanner.

  • שפה פרוצדורלית

  • הצהרות על ניפוי באגים

• שאילתות מתמשכות לא תומכות במקורות הנתונים הבאים:

  • טבלאות חיצוניות.
  • תצוגות של סכימת מידע.
  • טבלאות תווים כלליים לחיפוש.
  • נתוני עדכון או הוספה (upsert) של סימון נתונים שהשתנו (CDC).
  • תצוגות מהותיות.
  • תצוגות שבהן שאילתת ה-SQL הבסיסית משתמשת בתכונות שלא נתמכות, כמו פונקציות בהגדרת המשתמש (UDF), טבלאות חיצוניות או טבלאות עם CDC.

• שאילתות מתמשכות לא תומכות באמצעי האבטחה ברמת column- וברמת השורה.

• הפלט של שאילתה מתמשכת כפוף למכסות ולמגבלות המובנות של שירות היעד שאליו הפלט מיוצא.

• כשמייצאים נתונים ל-Bigtable, ל-Spanner או לנקודות קצה מבוססות-מיקום ב-Pub/Sub, אפשר לטרגט רק משאבים של Bigtable, של Spanner או של Pub/Sub שנמצאים באותו Google Cloudאזור כמו מערך הנתונים ב-BigQuery שמכיל את הטבלה ששולחים אליה שאילתה. ההגבלה הזו לא חלה כשמייצאים נתונים לנקודות קצה גלובליות של Pub/Sub. למידע נוסף על ייצוא למדיניות ניתוב של פרופיל אפליקציה ב-Bigtable, קראו את שיקולים לגבי מיקום.

• אי אפשר להריץ שאילתה מתמשכת מקנבס נתונים.

• אי אפשר לשנות את ה-SQL שמשמש בשאילתה מתמשכת בזמן שמשימת השאילתה המתמשכת פועלת. מידע נוסף זמין במאמר שינוי ה-SQL של שאילתה מתמשכת.

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

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

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

מגבלות על הזמנות

• כדי להריץ שאילתות מתמשכות, צריך ליצור הזמנה של מהדורת Enterprise או Enterprise Plus עם סוג הקצאה CONTINUOUS. שאילתות מתמשכות לא תומכות במודל החיוב על פי דרישה.
• כשיוצרים הקצאת הזמנה ב-CONTINUOUS, ההזמנה המשויכת מוגבלת ל-500 מיקומים לכל היותר. כדי לבקש להגדיל את המגבלה הזו, אפשר לפנות לכתובת [e-mail].
• אי אפשר ליצור הקצאת הזמנה שמשתמשת בסוג העבודה שונה באותה הזמנה כמו הקצאת הזמנה של שאילתה מתמשכת.

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

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

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

התאמה אוטומטית לעומס (autoscaling) של מיקומים

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

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

שיתוף משבצות לא פעילות

שאילתות מתמשכות יכולות להשתמש בשיתוף משבצות לא פעילות כדי לשתף משאבי משבצות שלא בשימוש עם הזמנות וסוגי עבודה אחרים.

• עדיין צריך להקצות הזמנה ל-CONTINUOUS כדי להריץ שאילתה מתמשכת, ואי אפשר להסתמך רק על משבצות לא פעילות מהזמנות אחרות. לכן, כדי להקצות הזמנה של CONTINUOUS, צריך להגדיר ערך שאינו אפס ל-baseline של ה-slots או להגדיר ערך שאינו אפס להתאמה אוטומטית לעומס (autoscaling) של ה-slots.
• אפשר לשתף רק משבצות בסיסיות במצב חוסר פעילות או משבצות שהוקצו בהתחייבות מהקצאת הזמנה של CONTINUOUS. אי אפשר לשתף משבצות שמותאמות אוטומטית כמשבצות לא פעילות בהזמנות אחרות.

תמחור

בשאילתות מתמשכות אפשר להשתמש בהתאמה גמישה לעומס ב-BigQuery.

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

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

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

• התמחור של Bigtable
• התמחור של Pub/Sub
• התמחור של Spanner
• תמחור פלטפורמת סוכנים

הערכת דרישות הקיבולת של ה-slots

מכיוון שכל עומס עבודה הוא שונה, בדרך כלל אי אפשר להעריך מראש את מספר ה-slots המדויק שנדרש לשאילתות מתמשכות. מספר ה-slots שנדרשים לשאילתות המתמשכות תלוי בשילוב של כמה גורמים:

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

באופן עקרוני, אפשר להעריך את הדרישה הכוללת ל-slots כפונקציה של עומס העבודה של השאילתה המתמשכת:

מספר משבצות משוער ≈ מספר השאילתות המתמשכות x ∑ (קצב הנתונים x מורכבות השאילתה)

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

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

נסו ליצור שאילתה מתמשכת.