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

BigQuery の継続的クエリは、ステートフル オペレーションとして集計とウィンドウ処理をサポートしています。これにより、複数の行または時間間隔にわたってストリーミング データを分析できます。この機能により、継続的クエリの実行中に必要な状態をメモリに保存することで、30 分間の平均などの計算指標を時系列で計算できます。

ウィンドウ処理機能について

ウィンドウ関数は、変更を行ったトランザクションの commit 時間を示すシステム時間に基づいて、データを論理コンポーネント(ウィンドウ)に割り当てます。BigQuery では、これらの関数はテーブル値関数(TVF)であり、元のすべての列と 2 つの追加列(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 を持つ行が最初のウィンドウに割り当てられます。これらのウィンドウは互いに排他的で重複しないため、タイムスタンプを持つすべての要素が 1 つのウィンドウに割り当てられます。

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

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

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

構文

TUMBLE(TABLE table, "timestamp_column", window_size)

定義

  • table: BigQuery テーブル名。これは、APPENDS 関数でラップされた標準の BigQuery テーブルである必要があります。この引数の前には 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 は、そのウィンドウに関連するすべてのデータを処理した後にのみ、集計結果を出力します。

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

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

制限事項

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

次のステップ