Push Query と Pull Query: 継続クエリと一問一答を正しく使い分ける

ksqlDB は Kafka の上で SQL ライクにストリーム処理を行うためのコンポーネントで、結果の取得方法として Push Query と Pull Query を持ちます。両者は名前が似ていますが、設計思想も適用場面も異なります。

本稿では、継続的に結果が流れ続ける Push（継続クエリ）と、必要なときに現在値を一度だけ取得する Pull（一問一答）の違いを、内部動作、性能、一貫性、そして CCDAK 試験での出題傾向を踏まえて解説します。

なぜ Push と Pull を区別するのか

Push Query は新着データに応じて結果が途切れなく配信される継続クエリです。変化が起きるたびにクライアントへイベントとして届けるため、サブスクリプション型の UI 更新、アラート、リアルタイムメトリクスに向きます。

Pull Query は現在の集計結果や最新状態を、問い合わせの都度一度だけ返す一問一答です。キーに対する現在値の参照や API の同期レスポンスに適します。

• Push = 継続配信（EMIT CHANGES 必須）。ストリームにもテーブルにも適用可。
• Pull = 現在値の単発取得。対象はテーブルのみ（マテリアライズされた状態が必要）。
• 試験観点: Pull はキー指向の現在値参照、Push は変更の逐次配信。まずここを取り違えないこと。

実行モデルと内部構造

ksqlDB は Kafka トピックを消費し、永続クエリ（CSAS/CTAS）で中間結果をトピックとステートストアにマテリアライズします。Push Query はこのストリームやテーブルの更新を逐次クライアントへ流し、Pull Query はマテリアイズドテーブルの現在値をキーで読み出します。

Pull Query はテーブルが前提です。内部的には状態ストア（一般的に RocksDB バックエンド）からキー検索を行い、現在の合流済み・集計済みの値を返します。Push は新規レコード到着や再計算のたびに下流へイベントとして送出します。

• 永続クエリがテーブルを構築し、テーブルが Pull の参照元になる。
• Push は結果ストリームを開きっぱなしにし、サーバ側からクライアントへプッシュ。
• Pull は RPC 的。リクエスト/レスポンスで完結し、通常はキー等価条件が要件。

データフローとクエリの位置づけ

ユースケースと選択基準

意思決定の基準は、継続的に変化を受け取りたいか（Push）、それとも今の確定値だけが必要か（Pull）です。API 設計、UI、アラート、バッチ後処理など、データ利用形態に合わせて選びます。

もう一つの軸は、マテリアライズドテーブルが用意できるかどうかです。Pull はテーブル必須で、ストリームを直接 Pull することはできません。

• リアルタイム画面更新、通知、しきい値監視 → Push
• サービス間の同期問い合わせ、ダッシュボードのオンデマンド参照 → Pull
• 大量配信・低遅延を優先 → Push、SLA 明快な単発応答 → Pull

書き方と典型パターン（ksqlDB）

Push は EMIT CHANGES が鍵語です。永続クエリ（CREATE STREAM/TABLE AS SELECT ... EMIT CHANGES）にすれば結果をトピックとテーブルへ継続出力します。トランジエントに試す場合は SELECT ... EMIT CHANGES を対話実行します。

Pull はテーブルに対してキー条件で現在値を問い合わせます。ストリームには発行できません。全表スキャンのような Pull は通常の運用では想定されません。

• Push を一時的に止めたい場合は LIMIT を付けるか、クライアント側で接続を閉じる。
• Pull はキーを指定して低遅延で返す前提。即時性と整合性はテーブルの更新タイミングに依存。
• 永続クエリが生むテーブル名やスキーマを意図どおりに設計しておくと Pull が簡潔になる。

Push と Pull の具体例（ksqlDB CLI/REST）

---- サンプルデータ定義 ----
CREATE STREAM orders (
  order_id VARCHAR KEY,
  user_id  VARCHAR,
  amount   DECIMAL(9,2),
  ts       BIGINT
) WITH (
  KAFKA_TOPIC='orders',
  VALUE_FORMAT='JSON'
);

-- ユーザーごとの累計をマテリアイズ（永続クエリ: Table を作成）
CREATE TABLE spend_by_user AS
  SELECT user_id,
         SUM(amount) AS total_amount
  FROM orders
  GROUP BY user_id
  EMIT CHANGES;

---- Push Query（トランジエント、しきい値超過を即時配信） ----
-- ksql> プロンプトで実行（終了は Ctrl+C または LIMIT）
SELECT user_id, total_amount
FROM spend_by_user
WHERE total_amount >= 1000
EMIT CHANGES;

-- 早期終了させたい場合
SELECT user_id, total_amount
FROM spend_by_user
EMIT CHANGES LIMIT 50;

---- Pull Query（現在値を一問一答で取得） ----
-- ksql> プロンプトで実行
SELECT total_amount FROM spend_by_user WHERE user_id='u_123';

-- REST 呼び出し例（Pull は /query エンドポイント）
curl -s -X POST http://localhost:8088/query \
  -H 'Content-Type: application/vnd.ksql.v1+json; charset=utf-8' \
  -d '{"ksql": "SELECT total_amount FROM spend_by_user WHERE user_id=\"u_123\";"}'

-- Push を REST で受け取りたい場合（/query-stream など）
curl -N -s -X POST http://localhost:8088/query-stream \
  -H 'Content-Type: application/vnd.ksql.v1+json; charset=utf-8' \
  -d '{"sql": "SELECT user_id, total_amount FROM spend_by_user EMIT CHANGES;"}'

遅延・可用性・一貫性の実務観点

Push は連続配信のため、クライアント数とフィルタ条件がスループットに直結します。必要最小限の列選択と述語で下流負荷を抑えます。停止条件があるなら LIMIT を使い切断を明確にします。

Pull は状態ストアのキー検索なので低遅延です。ただし、参照するのはマテリアイズ済みの現在値であって、上流トピックの直近レコードが必ず反映済みとは限りません。整合性はテーブル更新の伝播までの遅延に依存します。

可用性面では、Pull は担当パーティションを持つノードが応答します。フェイルオーバによりスタンバイから提供される場合、直前の更新が未反映の可能性を理解して設計するのが安全です。

• Push: 列のプロジェクション最小化、述語で早期フィルタ、不要なジョイン回避。
• Pull: キーを必ず指定。ウィンドウ付きテーブルはウィンドウ境界の指定が必要。
• 処理の exactly-once はストリーム処理の性質であり、Pull の読み出し結果に強整合性を保証するものではない。

試験対策の要点と落とし穴（CCDAK）

CCDAK では、Push/Pull の適用対象、終了条件、テーブル必要性、そしてキー条件の有無が頻出です。名称で連想せず、内部動作までイメージして選択肢を切り分けてください。

• Pull はテーブルに対する現在値取得。ストリームは対象外。
• Push は EMIT CHANGES が必要。LIMIT を付けても Push は Push（終了条件付き）である点に注意。
• Pull は通常キー等価条件が前提。全表スキャンを Pull で行う設計は試験では誤り選択肢になりやすい。
• 永続クエリが生成するマテリアイズドテーブルが Pull の土台。テーブル未作成では Pull は成立しない。
• 整合性の表現に注意: Pull は最新トピックではなく、最新にマテリアイズ済みの状態を返す。

問題で確認

よくある質問