継続的クエリでストリーム間結合を使用する

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

継続的クエリは、ステートフル オペレーションとして JOIN をサポートしています。ステートフル オペレーションを使用すると、継続的クエリで複数の行または時間間隔にわたって情報を保持する必要がある複雑な分析を実行できます。この機能を使用すると、クエリの実行中に必要なデータをメモリに保存することで、異なるストリームのイベントを関連付けることができます。ステートフル オペレーションの詳細については、 サポートされているステートフル オペレーションをご覧ください。

ストリーム間結合は、時間指向のデータの取り込みを行う 2 つ以上のテーブル間の結合オペレーションです。

サポートされている JOIN タイプ

継続的クエリでは、次の JOIN タイプがサポートされています。

  • ストリーム間 JOIN - 時間指向のデータの取り込みを行う 2 つ以上のテーブル間の結合オペレーション。
  • INNER JOIN

サポートされていない JOIN タイプ

継続的クエリでは、次の JOIN タイプはサポートされていません。

  • ストリームと静的テーブルの JOIN - 結合されたテーブルの少なくとも 1 つが、時間指向のデータの取り込みを行わない静的テーブルである結合。静的テーブルの例としては、ディメンション テーブルがあります。
  • INNER 以外の形式の JOIN オペレーション。
  • 時間指向の JOIN 句がない JOIN。

複数のストリームのデータを結合する

次のクエリは、タクシーの乗車テーブルをタクシーのリクエスト テーブルに結合し、5 分間の時間枠内でリクエスト元に最も近い利用可能なタクシーを特定して、このデータを別の BigQuery テーブルにエクスポートする方法を示しています。

INSERT INTO
 `real_time_taxi_streaming.matched_rides`
SELECT
 requests.timestamp AS request_time,
 requests.request_id,
 taxis.taxi_id,
 ST_DISTANCE(
   ST_GEOGPOINT(requests.longitude, requests.latitude),
   ST_GEOGPOINT(taxis.longitude, taxis.latitude)
   ) AS distance_in_meters,
 taxis.timestamp AS taxi_available_time
FROM
 APPENDS (TABLE `real_time_taxi_streaming.ride_requests`,
   CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE) AS requests
INNER JOIN
 APPENDS (TABLE `real_time_taxi_streaming.taxirides`,
   CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE) AS taxis
ON
 requests.geohash = taxis.geohash
WHERE
 taxis.ride_status = 'available'
 AND taxis._CHANGE_TIMESTAMP BETWEEN(requests._CHANGE_TIMESTAMP - INTERVAL 5 MINUTE) AND requests._CHANGE_TIMESTAMP
 AND ST_DWITHIN(
   ST_GEOGPOINT(requests.longitude, requests.latitude),
   ST_GEOGPOINT(taxis.longitude, taxis.latitude),
   2000 -- Distance in meters
   );

結合に関する考慮事項

以降のセクションでは、ストリーム間結合を実行する際に必要な考慮事項について説明します。

制限事項

  • INNER JOIN オペレーションのみがサポートされています。LEFTFULL OUTER などの形式は対象外です。
  • INNER JOIN オペレーションの各サイドで、継続的クエリの開始時間を指定する必要があります。
  • 結合キー(table1.user_id = table2.user_id など)に加えて、JOIN 句には、タイムスタンプ列を一定の間隔に制限する条件を含める必要があります。この条件により、システムが一致するイベントが別のストリームに到着するまで待機する時間が制限されます。たとえば、1 つのストリームのイベントを別のストリームのイベントと結合できるのは、タイムスタンプが 5 分以内の場合のみと指定できます。対称間隔に限定されません。たとえば、結合条件の一方のサイドで 5 分間隔を使用し、もう一方のサイドで 1 時間間隔を使用できます。
  • ストリーム間結合で継続的クエリを開始する場合、APPENDS 関数のみがサポートされます。CHANGES 関数はサポートされていません。
  • 結合オペレーションでサポートされているタイムスタンプ列は、_CHANGE_TIMESTAMP で定義される BigQuery システム時間列のみです。ユーザー定義の列はサポートされていません。
  • ウィンドウ集計と組み合わせて使用する場合は、ドキュメントに記載されているウィンドウ集計の制限事項をすべて 遵守する必要があります。

料金に関する考慮事項

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

次のステップ