継続的クエリでのウィンドウ集計について

この機能のサポートをリクエストする場合やフィードバックを提供する場合は、 bq-continuous-queries-feedback@google.com までメールをお送りください。

BigQuery の継続的クエリは、ステートフル オペレーションとして集計とウィンドウ処理をサポートしています。 ステートフル オペレーションを使用すると、継続的クエリで複数の行または時間間隔にわたって情報を保持する必要がある複雑な分析を実行できます。この機能を使用すると、クエリの実行中に必要なデータをメモリに保存することで、30 分間の平均などの指標を時間経過とともに計算できます。

ウィンドウ関数は、変更を行ったトランザクションのコミット時刻を示すシステム時刻に基づいて、データを論理コンポーネント(ウィンドウ)に割り当てます。BigQuery では、これらの関数はテーブル値関数(TVF)であり、元のすべての列と window_start 列と window_end 列の 2 つの追加列を含むテーブルを返します。これらの列は、各ウィンドウの時間間隔を示します。ステートフル オペレーションの詳細については、 サポートされているステートフル オペレーションをご覧ください。

ウィンドウ処理 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 の行は、最初のウィンドウに割り当てられます。これらのウィンドウは重複せず、重複しないため、タイムスタンプ付きのすべての要素は 1 つのウィンドウに割り当てられます。

次の図は、TUMBLE 関数が重複しない時間間隔にイベントを割り当てる方法を示しています。

TUMBLE 関数は、イベントを重複しない時間間隔に割り当てます。

この関数は、リアルタイム イベント処理で使用して、集計を実行する前に時間範囲でイベントをグループ化できます。

構文

TUMBLE(TABLE table, "timestamp_column", window_size)

定義

  • table: BigQuery テーブル名。これは、標準 BigQuery テーブル 関数でラップされている必要があります。APPENDSこの引数の前には TABLE という単語を付ける必要があります。

  • timestamp_column: イベント時刻を含む入力テーブルの列の名前を指定する STRING リテラル。この列の値は、各行をウィンドウに割り当てます。BigQuery システム時刻を定義する _CHANGE_TIMESTAMP 列は、サポートされている唯一の timestamp_column です。ユーザー定義の列はサポートされていません。

  • window_size: 各タンブリング ウィンドウの期間を定義する INTERVAL 値。ウィンドウ サイズは最大 24 時間です。例: INTERVAL 30 SECOND

出力

TUMBLE 関数は、次の列を含む出力を返します。

  • クエリの実行時の入力テーブルのすべての列。

  • window_start: レコードが属するウィンドウの開始時刻(包括的)を示す TIMESTAMP 値。

  • window_end: レコードが属するウィンドウの終了時刻(排他的)を示す TIMESTAMP 値。

出力のマテリアライズ

BigQuery の継続的クエリでは、BigQuery がウィンドウを確定またはクローズするまで、ウィンドウ集計で特定の時間間隔の出力が生成されません。 この動作により、BigQuery は、そのウィンドウの関連データをすべて処理した後にのみ、集計結果を出力します。

たとえば、5 分間の TUMBLE ウィンドウ集計を user_clickstream テーブルで実行する場合、間隔 [10:15; 10:20) の結果は、クエリが _CHANGE_TIMESTAMP が 10:20 以降のレコードを処理した後にのみ 出力されます。その時点で、BigQuery はウィンドウが閉じられたと見なします。 また、特定の時間範囲に属する最初のレコードが表示されると、ウィンドウが開き、データの蓄積が開始されます。

ウィンドウが開いている間、BigQuery は中間集計結果を保持する必要があります。これには状態の保存が必要であり、BigQuery は中間集計結果を保持する必要があります。 この状態は、ウィンドウが閉じるまでアクティブ メモリに残しておく必要があるため、ウィンドウの期間を長くしたり、大量のストリームを処理したりすると、保存されたコンテキストの量が増加し、スロット使用率が高くなります。詳細については、料金に関する考慮事項をご覧ください。

制限事項

  • TUMBLE 関数は、BigQuery の継続的クエリでのみサポートされています。
  • TUMBLE 関数を使用して継続的クエリを開始する場合は、APPENDS 関数のみを使用できます。CHANGES 関数はサポートされていません。
  • _CHANGE_TIMESTAMP で定義された BigQuery システム時刻列は、サポートされている唯一の timestamp_column です。ユーザー定義の列はサポートされていません。
  • ウィンドウ サイズは最大 24 時間です。
  • TUMBLE ウィンドウ関数を実行すると、window_startwindow_end の 2 つの追加出力列が生成されます。ウィンドウ集計を実行する SELECT ステートメント内の GROUP BY ステートメントに、これらの列の少なくとも 1 つを含める必要があります。
  • 継続的クエリ結合で TUMBLE 関数を使用する場合は、継続的クエリ結合のすべての 制限事項に従う必要があります。

料金に関する考慮事項

BigQuery の継続的クエリでは、ジョブの実行中に消費された コンピューティング容量(スロット) に基づいて課金されます。このコンピューティング ベースのモデルは、ウィンドウ処理などのステートフル オペレーションにも適用されます。ウィンドウ処理では、クエリがアクティブな間、BigQuery が「状態」を保存する必要があるため、追加のスロットリソースが消費されます。一般に、ウィンドウ内に保存されるコンテキストまたはデータが多いほど(ウィンドウの期間が長い場合など)、BigQuery が保持する必要がある状態が多くなります。これにより、スロット使用率が高くなります。

次のクエリは、タクシーの乗車テーブルに対してクエリを実行して、30 分ごとにタクシー 1 台あたりの乗車数、乗客数、平均運賃のストリーミング平均を取得し、このデータを 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

次のステップ