プロンプトと適用範囲
ビジネス側は、BigQuery に書き込まれたデータによって迅速にアラートがトリガーされ、結果がテーブル、Pub/Sub、Bigtable、または Spanner に送信されることを求めています。BigQuery の continuous query を使用すべきかどうか、また入力セマンティクス、認可、ランタイム、リージョン、コスト、リカバリをどのように処理するかを説明してください。回答を SQL 構文だけに限定しないでください。
面接官がテストしていること
- continuous query を一定間隔のポーリングではなく、継続的に実行される SQL として理解しているかどうか。
- レイテンシとデータセマンティクスに基づいて、Dataflow、Pub/Sub、通常のクエリとの相対的な位置付けができるかどうか。
- Enterprise エディション、
CONTINUOUS予約、サービスアカウント、およびリージョンの制約を確認しているかどうか。 - 重複出力、バックプレッシャー、モニタリング、再起動時の動作、およびコストに対処しているかどうか。
明確化のための質問
- 入力は追記専用（append-only）ですか、それとも既存の行が更新・削除される可能性がありますか？重複は許容されますか？
- 送信先は BigQuery、Pub/Sub、Bigtable、Spanner のいずれですか？また、コンシューマーは安全に再試行できますか？
- どのようなレイテンシ、ランタイム、データリージョンの保証が必要ですか？プロジェクトはそのためにプロビジョニングされていますか？
- 障害発生後、処理はどこから再開されますか？また、ラグ、エラー、出力ボリュームはどのようにモニタリングされますか？
30秒での回答
まず、要件が真に継続的な処理であるかを確認します。continuous query は受信した BigQuery データを分析して結果を書き込みまたはエクスポートしますが、エディション、キャパシティ、認可、リージョンの制約があります。冪等性キーを定義し、送信先を選択し、サービスアカウント、CONTINUOUS 予約、モニタリングを準備します。制御されたトラフィックでレイテンシ、重複、コスト、停止、リカバリを検証し、この機能を無制限で無料の Cron の代替品として扱わないようにします。
ステップバイステップの設計
1. まずデータセマンティクスを定義する
continuous query は BigQuery テーブルに書き込まれたデータを処理し続けます。追記、遅延イベント、更新、削除はそれぞれ異なる意味を持ちます。ビジネス側で複雑な状態、イベント時間ウィンドウ、または厳密な順序付けが必要な場合は、サポートされている SQL の動作を確認し、Dataflow などのストリームプロセッサと比較します。
2. 出力パスを選択する
ドキュメントでは、結果を BigQuery テーブルに挿入するか、Pub/Sub、Bigtable、Spanner への EXPORT DATA を使用することがサポートされています。ダウンストリームのスループット、順序付け、冪等性、リージョンに基づいて選択します。Pub/Sub は別のイベント処理ステージに役立ちます。テーブルへの直接書き込みには重複排除と保持キーが必要です。
3. ランタイムと認可の制約を確認する
ユーザーアカウントまたはサービスアカウントを使用して continuous query を作成および実行できます。Pub/Sub へのエクスポートにはサービスアカウントが必要です。ユーザーアカウントのジョブは最大2日間実行でき、サービスアカウントのジョブは最大150日間実行できます。continuous query には Enterprise または Enterprise Plus エディションと、タイプ CONTINUOUS の予約割り当てが必要です。
4. 予算、モニタリング、リカバリ
continuous query では BigQuery のキャパシティコンピューティング料金が適用され、受信側のサービスには個別に費用が発生します。クエリ固有のメトリクス、入力から出力までのレイテンシ、エラー、再起動、出力ボリュームをモニタリングし、停止、再構築、アラートの手順を定義します。冪等性キーまたはウォーターマークから復旧し、許容可能な範囲のみを再再生（リプレイ）することで、再起動によって副作用が重複しないようにします。
質の高い模範解答
私は continuous query をデータプロダクトの運用上の制約として評価します。BigQuery に書き込まれたデータを継続的に分析し、結果を BigQuery、Pub/Sub、Bigtable、または Spanner に書き込みまたはエクスポートできますが、追記と変更のセマンティクス、および重複の許容度によってそれが適しているかどうかが決まります。Enterprise エディション、CONTINUOUS 予約、サービスアカウント、最大ランタイム、およびリージョン境界を検証します。出力コントラクトで冪等性、再試行、デッドレター処理を定義し、テレメトリでラグ、バックログ、エラー、コストをカバーします。ローンチ前に、制御されたトラフィックでレイテンシと再起動時の動作をテストし、明示的な一時停止、再開、バックフィル手順を用意します。ワークロードに豊富なイベント時間状態、厳密な順序付け、またはより長寿命のトポロジが必要な場合は、すべてのリアルタイム要件を BigQuery に無理に押し込むのではなく、専用のストリームプロセッサを比較検討します。
よくある間違い
- continuous query を毎分1回実行されるクエリとして扱うこと。
- Enterprise または Enterprise Plus、
CONTINUOUS予約、またはサービスアカウントの要件を無視すること。 - すべての送信先が同一の順序付けと重複のセマンティクスを持っていると仮定すること。
- 再起動、重複、遅延データのためのウォーターマークや冪等性キーを省略すること。
- BigQuery のキャパシティとダウンストリームサービスの価格を考慮せずに SQL のレイテンシのみを測定すること。
- 2日間または150日間のランタイム制限を、恒久的な実行の保証として扱うこと。
フォローアップの質問と回答
どのような場合に Dataflow を選択しますか？
ワークロードに複雑なイベント時間ウィンドウ、状態管理、厳密な順序付け、豊富なコネクタ、または長寿命のトポロジが必要な場合は、Dataflow または別のストリームプロセッサを比較してください。その境界は SQL の行数ではなく、セマンティクスと運用面にあります。
再起動後のアラートの重複をどのように防ぎますか？
各出力にイベントまたはビジネス冪等性キーを含め、ダウンストリームで重複排除またはトランザクション処理を行い、ウォーターマークと処理バッチを記録します。安全な再生境界から再開し、回避できない重複の動作についてはコンシューマーに対してドキュメント化します。
コストが許容可能かどうかをどのように判断しますか？
キャパシティスロット、取り込みとストレージ、さらに Pub/Sub、Bigtable、または Spanner の料金を個別に試算します。定常状態、アイドル期間、ピーク時の負荷テストを実施し、観測されたレイテンシとスロット消費量に基づいて予算を調整します。