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

כדי לבקש תמיכה או לשלוח משוב על התכונה הזו, אפשר לשלוח אימייל לכתובת 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 יפיק את התוצאות המצטברות רק אחרי שהוא יעבד את כל הנתונים הרלוונטיים לחלון הזמן הזה.

לדוגמה, אם מבצעים TUMBLEצבירה של חלון של 5 דקות בטבלה user_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

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