הסבר על צבירה של חלונות בזמן אמת בשאילתות רציפות

כדי לבקש תמיכה או לשלוח משוב על התכונה הזו, אפשר לשלוח אימייל לכתובת bq-continuous-queries-feedback@google.com.

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

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

פונקציות TVF של חלונות נתמכות רק בשאילתות רציפות של BigQuery.

פונקציות TVF של חלונות שונות מקריאות לפונקציות אנליטיות.

פונקציות צבירה נתמכות

הפונקציות הבאות של צבירה נתמכות:

פונקציות צבירה שלא נתמכות

פונקציות הצבירה הבאות לא נתמכות:

הפונקציה TUMBLE

הפונקציה TUMBLE מקצה נתונים למרווחי זמן לא חופפים (חלונות מתגלגלים) בגודל שצוין. לדוגמה, חלון של 5 דקות מקבץ אירועים במרווחי זמן נפרדים כמו [2026-01-01 12:00:00, 2026-01-01 12:05:00) ו-[2026-01-01 12:05:00, 2026-01-01 12:10:00). שורה עם ערך חותמת זמן 2026-01-01 12:03:18 משויכת לחלון הראשון. חלונות הזמן האלה נפרדים ולא חופפים, ולכן כל רכיב עם חותמת זמן משויך לחלון זמן אחד בלבד.

בתרשים הבא מוצג איך הפונקציה TUMBLE מקצה אירועים למרווחי זמן לא חופפים:

הפונקציה TUMBLE מקצה אירועים למקטעי זמן לא חופפים.

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

תחביר

TUMBLE(TABLE table, "timestamp_column", window_size)

הגדרות

  • ‫table: שם הטבלה ב-BigQuery. הערך הזה חייב להיות טבלה ב-BigQuery רגילה שמוקפת בפונקציה APPENDS. המילה TABLE חייבת להופיע לפני הארגומנט הזה.

  • ‫timestamp_column: מחרוזת STRING מילולית שמציינת את שם העמודה בטבלת הקלט שמכילה את שעת האירוע. הערכים בעמודה הזו מקצים כל שורה לחלון. העמודה _CHANGE_TIMESTAMP, שמגדירה את זמן המערכת ב-BigQuery, היא העמודה היחידה שנתמכת ב-timestamp_column. אין תמיכה בעמודות שהוגדרו על ידי המשתמש.

  • window_size: ערך INTERVAL שמגדיר את משך הזמן של כל חלון עוקב. הגודל המקסימלי של חלון הוא 24 שעות. לדוגמה: INTERVAL 30 SECOND.

תשובה

הפונקציה TUMBLE מחזירה פלט עם העמודות הבאות:

  • כל העמודות של טבלת הקלט בזמן הפעלת השאילתה.

  • ‫window_start: ערך TIMESTAMP שמציין את שעת ההתחלה כולל של חלון הזמן שאליו הרשומה משתייכת.

  • ‫window_end: ערך TIMESTAMP שמציין את שעת הסיום הבלעדית של חלון הזמן שאליו משתייכת הרשומה.

יצירת חומרים בפלט

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

לדוגמה, אם מבצעים צבירה של חלון של 5 דקות בטבלה TUMBLEuser_clickstream, התוצאות של המרווח [10:15; 10:20) מופקות רק אחרי שהשאילתה מעבדת רשומות עם _CHANGE_TIMESTAMP של 10:20 או מאוחר יותר. באותו רגע, BigQuery מחשיב את החלון כסגור. בנוסף, נפתח חלון ומתחיל לצבור נתונים ברגע שמופיעה הרשומה הראשונה ששייכת לטווח הזמן הספציפי הזה.

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

מגבלות

  • הפונקציה TUMBLE נתמכת רק בשאילתות רציפות של BigQuery.
  • כשמתחילים שאילתה מתמשכת עם הפונקציה TUMBLE, אפשר להשתמש רק בפונקציה APPENDS. הפונקציה CHANGES לא נתמכת.
  • עמודת הזמן של מערכת BigQuery שמוגדרת על ידי _CHANGE_TIMESTAMP היא timestamp_column היחידה שנתמכת. אין תמיכה בעמודות שהוגדרו על ידי המשתמש.
  • הגודל המקסימלי של חלון הוא 24 שעות.
  • כשמריצים את פונקציית החלונות TUMBLE, נוצרות שתי עמודות פלט נוספות: window_start ו-window_end. צריך לכלול לפחות אחת מהעמודות האלה בהצהרת GROUP BY בתוך הצהרת SELECT שמבצעת את צבירת החלונות.
  • כשמשתמשים בפונקציה TUMBLE עם צירופי שאילתות מתמשכות, צריך לפעול בהתאם לכל המגבלות של צירופי שאילתות מתמשכות.

שיקולי תמחור

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

דוגמאות

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

INSERT INTO
 `real_time_taxi_streaming.driver_stats`

WITH ride_completions AS (
 SELECT
   _CHANGE_TIMESTAMP as bq_changed_ts,
   CAST(timestamp AS DATE) AS ride_date,
   taxi_id,
   meter_reading,
   passenger_count
 FROM
   APPENDS(TABLE `real_time_taxi_streaming.taxirides`,
     CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE)
 WHERE
   ride_status = 'dropoff')

 SELECT
   ride_date,
   window_end,
   taxi_id,
   COUNT(taxi_id) AS total_rides_per_half_hour,
   ROUND(AVG(meter_reading),2) AS avg_fare_per_half_hour,
   SUM(passenger_count) AS total_passengers_per_half_hour
FROM
  tumble(TABLE ride_completions,"bq_changed_ts",INTERVAL 30 MINUTE)
GROUP BY
  window_end,
  ride_date,
  taxi_id

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