CCDAK対策にも効く：ksqlDB の Materialized Views — テーブルとクエリパターン

ksqlDB のテーブルは、継続クエリで算出した結果を RocksDB のステートストアに保持し、Kafka のチェンジログ・トピックで耐障害性を確保するマテリアライズド・ビューです。これにより、低レイテンシなキー参照（Pull Query）と、継続配信（Push Query）の両方に対応できます。

本稿では、テーブルの成り立ちと内部、Pull/Push の使い分け、キー設計とパーティショニング、典型的なクエリパターン、運用と試験対策ポイントを、CCDAK で問われる要点に沿って解説します。

テーブルとマテリアライズド・ビューの基礎

ksqlDB の世界では、Stream は「不変のイベント列」、Table は「最新状態のアップサート表現」です。CREATE TABLE AS SELECT のような永続クエリは、計算結果をローカルのステートストアに維持し、背後で Kafka のトピックに変更履歴（チェンジログ）を永続化します。これが実質的なマテリアライズド・ビューです。

テーブルは主キーでインデックス化され、Pull Query による即時参照が可能です。一方で、Push Query は新規更新が発生するたびにストリームとして結果を押し流します。CCDAK では、用途に応じて Stream と Table、Pull と Push を正しく選ぶ設問が頻出します。

• テーブル＝アップサート（同一キーの最新値が有効）
• マテリアライズド・ビュー＝永続クエリで維持されるテーブル（結果が事前計算・保持）
• Pull Query＝キーを指定して即時読み出し（同期リクエスト）
• Push Query＝結果更新を連続配信（サブスクリプション型）

裏側のしくみ：Kafka トピックとステートストア

ksqlDB の永続クエリは Kafka Streams アプリケーションとして実行され、各パーティションに対応する RocksDB ステートストアを持ちます。更新はローカルに適用されるとともに、チェンジログ・トピックへ複製されます。ノード障害時はチェンジログから状態が復元されます。

再バランス時はパーティション担当が移動し、新しい担当ノードがチェンジログからキャッチアップします。これにより、マテリアライズド・ビューは耐障害性を保ちつつ、一貫性のある結果を提供できます。実運用では、チェンジログ・トピックの保護（適切な replication.factor と cleanup.policy）を確認します。

• ローカル状態：RocksDB（パーティションごと）
• 耐障害性：チェンジログ・トピックに更新を永続化
• スケールアウト：パーティション単位で並列実行
• 復元：担当変更・障害時にチェンジログからリストア
• 整合性：アップサートの順序は同一キー内でパーティション順序に従う

Pull と Push の使い分け（比較表つき）

Pull Query は主キー条件での即時参照に最適です。ksqlDB はキーに基づき適切なノードへルーティングし、ローカルのマテリアイズド・ビューからすぐに応答します。一方、Push Query は連続的な更新通知に向き、監視ダッシュボードや下流へのストリーミング連携で有効です。

従来の Kafka コンシューマで同等を実現しようとすると、アプリ側で状態管理や照会機能を自作する必要があります。ksqlDB のテーブルはこれを標準機能として提供します。

• 単発のキー参照＝Pull Query
• 最新の変化を流し続けたい＝Push Query
• 自作の状態管理が不要＝ksqlDB テーブルの利点

キー設計とパーティショニング：引けるビューにする

Pull Query は主キーでの検索を前提とします。すなわち、GROUP BY で指定したキー、あるいはテーブル定義の主キーに対する等価条件が必要です。適切なキー設計とパーティショニングが、低レイテンシ参照の成否を分けます。

JOIN や再パーティショニングが絡む場合、ksqlDB は必要に応じて再パーティション用トピックを自動作成します。結合ではキーとパーティション数の整合が重要で、必要に応じて PARTITION BY を用いた明示的な再パーティショニングを行います。

• Pull Query は主キーの等価条件が基本（範囲検索はユースケースと実装に依存）
• GROUP BY でビューのキーが決まる。キー変更時は再パーティショニングが発生
• JOIN はコーパーティショニングが前提。キーとパーティション数の整合を確認
• 高カーディナリティのキーはスケールに有利だが局所性とホットキーに注意

マテリアライズド・ビューのデータフロー（概念）

代表的なクエリパターン：集計・参照・結合

テーブルは集計やディメンション参照を事前計算し、即時照会を可能にします。以下は典型的な定義と利用例です。

試験対策の観点では、CTAS によるテーブル作成＝マテリアイズ、Pull＝キー参照、Push＝連続配信、JOIN 時のキー整合と再パーティショニング、という対応関係を押さえておきましょう。

• 集計テーブル：COUNT/SUM などを GROUP BY でアップサート
• Pull Query：主キー指定で即時参照（同期）
• Push Query：更新を連続配信（監視・下流連携）
• 参照結合：Stream と Table の JOIN でエンリッチ

ksqlDB の定義例（マテリアイズ＋参照＋結合）

/* ソースストリーム定義 */
CREATE STREAM pageviews (
  user_id VARCHAR,
  page VARCHAR,
  ts BIGINT
) WITH (
  KAFKA_TOPIC='pageviews',
  VALUE_FORMAT='JSON'
);

/* ユーザー属性のディメンションテーブル（参照用） */
CREATE TABLE users (
  user_id VARCHAR PRIMARY KEY,
  plan VARCHAR
) WITH (
  KAFKA_TOPIC='users',
  VALUE_FORMAT='JSON'
);

/* 集計テーブル（マテリアライズド・ビュー） */
CREATE TABLE pv_count_by_user AS
SELECT user_id, COUNT(*) AS view_cnt
FROM pageviews
GROUP BY user_id
EMIT CHANGES;

/* Pull Query：単発のキー参照（最新の集計を即時取得） */
SELECT view_cnt FROM pv_count_by_user WHERE user_id='u-123';

/* Push Query：更新があるたびにストリーミング */
SELECT user_id, view_cnt FROM pv_count_by_user EMIT CHANGES;

/* 参照結合：ストリームをディメンション情報でエンリッチ */
CREATE STREAM enriched_pageviews AS
SELECT p.user_id, p.page, u.plan
FROM pageviews p
LEFT JOIN users u
ON p.user_id = u.user_id
EMIT CHANGES;

運用と試験対策ポイント：再構築・障害対応・設計の勘所

マテリアライズド・ビューを再構築したい場合は、元トピックに必要な履歴が残っていること（十分な保持期間やコンパクション）が前提です。クエリを再作成すれば、ksqlDB は最初から読み直し、状態を再構築します。

障害やリバランス時は、チェンジログからローカル状態が復元されます。スケールはパーティション数とノード数に依存し、ホットキーがあると偏りが生じます。キー分布とパーティション設計は必ず検討しましょう。

• 再構築＝クエリ再作成＋ソース履歴の確保（保持期間・compact を検討）
• 結合や GROUP BY でキーが変わると再パーティショニング・トピックが作成される
• Pull はキー必須。Push は連続配信。用途で選ぶ
• CCDAK では Stream と Table のセマンティクス、キーとパーティション、テーブルのマテリアイズとチェンジログの関係が頻出

問題で確認

よくある質問