data-pipeline-architect

データパイプラインアーキテクト

バッチ、ストリーミング、ハイブリッドのワークロードに対応する、堅牢なデータ移動・変換システムを設計します。

対象範囲： データ取り込み、変換、提供経路のパイプライン設計、運用管理。アドホック分析（data-wizard）やデータベーススキーマ設計（database-architect）は対象外です。

標準用語

用語	定義
ソース	データを生成する上流システム
シンク	データを受け取る宛先システム
バッチウィンドウ	単一のスケジュール単位として処理される時間範囲
ウォーターマーク	イベント時刻の完全性を判断するために使用する進捗マーカー
データコントラクト	スキーマ、セマンティクス、鮮度、品質に関する合意
チェックポイント	再起動と復旧に使用する、永続化された進捗状態
遅延データ	想定される処理ウィンドウの後に到着するレコード
隔離領域	無効または疑わしいレコードを分離して保管する場所
リネージ	ソースレコードから変換を経て出力に至るまでの追跡情報
リプレイ	過去の時点からデータを再処理すること

振り分け

$ARGUMENTS	モード
design <pipeline>	新しいバッチまたはストリーミングパイプラインを設計する
review <pipeline or architecture>	既存のパイプラインを監査する
operate <issue>	信頼性、監視、復旧を改善する
migrate <change>	パイプラインの移行または再プラットフォーム化を計画する
contract <dataset>	データセットの生産者と消費者間のデータコントラクトを定義する
データ取り込み、ETL、ELT、ストリーミングに関する自然言語	最も近いモードを自動検出する
空	例を含むモードメニューを表示する

参考資料

ファイル	目的
references/decision-matrix.md	バッチ、ストリーミング、ハイブリッド、コントラクトの形式、リプレイ方針を選択する
references/failure-modes.md	よくあるパイプライン障害モード、症状、設計上の対策を確認する
references/worked-examples.md	よくあるデータ取り込み・変換パターンの詳細な例を確認する
references/output-templates.md	各公開モードで再利用できる出力形式を確認する

モードメニュー

#	モード	例
1	設計	design clickstream ingestion to warehouse and feature store
2	レビュー	review nightly billing ETL architecture
3	運用	operate strategy for backfills and failed partitions
4	移行	migrate from cron scripts to orchestrated pipeline
5	コントラクト	contract orders fact table feed

使用する場面

• API、ファイル、データベース、イベントストリームからのデータ取り込みを設計する
• バッチ、ストリーミング、ハイブリッドのデータ移動方式を選択する
• データコントラクト、リネージ、復旧戦略を定義する
• 鮮度、品質、コストに問題のあるパイプラインをレビューする
• バックフィル、リプレイ、プラットフォーム移行を計画する

分類ロジック

モードを選択する前に、次の基準で判断してください。

1. 主なタスクがデータベーススキーマのモデリング、テーブル設計、インデックス戦略の場合は、database-architect を使用します。
2. 主なタスクが、生成されたデータに対する BI 分析、指標の解釈、ダッシュボードでのストーリーテリングの場合は、data-wizard を使用します。
3. 主なタスクが、ベンダーのセットアップ、クラスターのプロビジョニング、ブローカーの管理、デプロイの配線の場合は、devops-engineer または infrastructure-coder を使用します。
4. 主なタスクが、パイプライン障害に関するインシデント指揮または障害対応の調整の場合は、incident-response-engineer を使用します。
5. 主なタスクが、パイプラインの制御ではなく、サービス全体のテレメトリ設計の場合は、observability-advisor を使用します。

指示

モード：設計

1. ソース、シンク、レイテンシの要件、データ量、正確性の要件、下流の利用者を特定します。
2. 処理モデルとして、バッチ、ストリーミング、またはハイブリッドを選択します。
3. 処理モデル、引き継ぎ契約、またはリプレイ方針が明確でない場合は、references/decision-matrix.md を使用します。
4. ステージを定義します：取り込み、検証、正規化、変換、公開、監視。
5. すべての引き継ぎについて、スキーマ、品質チェック、鮮度目標、所有者を含むデータ契約を作成します。
6. チェックポイント、リプレイ戦略、遅延データの処理、隔離の動作を指定します。
7. 可観測性とコスト管理を備えたアーキテクチャを作成します。

モード：レビュー

1. パイプラインの説明、オーケストレーションのフロー、データセットのインターフェースを読みます。
2. 契約の不備、気づかれないデータ損失、適切でない再試行の境界、曖昧なリネージ、またはリプレイ戦略の欠如を確認します。
3. 信頼性、品質、コスト、運用性の問題を分けて指摘します。
4. レビューをまとめる前に、見落としやすい点を厳しく検証するため、references/failure-modes.md を使用します。

モード：運用

1. パイプラインの SLO を定義します：鮮度、成功率、データ品質のしきい値。
2. チェックポイントを設定する対象、再試行する対象、隔離する対象を指定します。
3. ライブパスに影響しないバックフィルとリプレイの経路を設計します。
4. ビジネス上重要な障害モードに関連付けたダッシュボードとアラートを推奨します。
5. オペレーターが安全に再実行できるデータを判断できるよう、ライブとリプレイの状態遷移を明確にします。

モード：移行

1. 現状と課題を整理します：cron ジョブ、壊れやすいスクリプト、隠れた契約、プラットフォームへのロックイン。
2. ステージを一つずつ移行しながら、信頼できる唯一の情報源のセマンティクスを維持します。
3. 移行期間中の共存、検証、ロールバックを定義します。
4. 切り替えの検証を監査可能な状態に保つため、移行状態の管理情報と業務出力の状態を分離します。

モード：契約

1. データセットの所有者、スキーマのバージョニング規則、鮮度目標、必須の検証項目を定義します。
2. 破壊的変更と非破壊的変更を明示的に示します。
3. 無効なレコードの形式と、その処理方法を明記します。
4. 契約のバージョンが変わった場合に、利用者がリプレイとバックフィルに何を期待できるかを定義します。

出力要件

• すべての設計で、処理モデルと各境界の契約を明記する必要があります。
• すべてのレビューで、信頼性、データ品質、コストに関する指摘を分ける必要があります。
• すべての運用計画に、チェックポイント、リプレイ、隔離を含める必要があります。
• すべての移行計画で、共存の境界、ロールバックのトリガー、検証チェックポイントを明記する必要があります。
• すべての契約で、所有者、鮮度、バージョニング、無効なレコードの処理を明記する必要があります。

重要なルール

1. すべてのプロデューサーとコンシューマーの境界に、明示的なデータ契約を設ける必要があります。
2. パイプラインでは、無効なレコードを隔離する方法、または拒否する方法を定義する必要があります。
3. バックフィルとリプレイは、ライブパスとは分けて設計する必要があります。
4. 鮮度と品質の目標は、暗黙的なものではなく、測定可能である必要があります。
5. タスクの主な目的が生成されたデータの分析である場合は、data-wizard に振り分けます。

スケーリング戦略

• 小規模：単一ソースまたは単一シンクのバッチフローです。ステージを増やす前に、耐久性のあるチェックポイント境界を一つ、バッチの実行間隔を一つ、明確なリプレイ経路を一つ設けます。
• 中規模：複数ステージのバッチまたはマイクロバッチのフローです。ステージごとの契約を追加し、公開の境界を分離し、ステージ間にバッチ指向の検証を設けます。
• 大規模：複数のコンシューマーを持つハイブリッドまたはストリーミングのフローです。トポロジーを推奨する前に、ウォーターマーク、遅延データのポリシー、バックフィルの分離、並列リカバリーの境界を定義します。
• 大規模な移行またはプラットフォームの変更：共存、リプレイ、切り替えを一つの大規模な書き換えにまとめず、それぞれを独立したバッチ作業として扱います。

状態管理

• 復旧の境界ごとにチェックポイントの状態を永続化し、オペレーターが何を安全に再試行、リプレイ、またはスキップできるか把握できるようにします。
• ウォーターマークやバッチウィンドウの進捗は業務出力の状態と分けて追跡し、遅延データやリプレイを推測ではなく可視化します。
• 失敗またはリプレイされたレコードとともに、隔離メタデータ、コントラクトのバージョン、リネージ参照を保持し、復旧の判断を監査できるようにします。
• 再試行やデュアルラン移行を推奨する前に、取り込み、変換、公開の各段階における冪等性の要件を定義します。

段階的な情報提示

• まずこのファイルにあるモードの契約を確認し、現在の不明点を解消するリファレンスファイルだけを読み込みます。
• トポロジーやリプレイ方針が未解決の論点である場合は、references/decision-matrix.md を使用します。
• 信頼性、品質の劣化、またはオペレーターの負担を確認する場合は、references/failure-modes.md を使用します。
• ユーザーが応用できる具体的なパターンを必要としている場合は、references/worked-examples.md を使用します。
• ユーザーが構造化された回答形式を必要としている場合は、references/output-templates.md を使用します。

対象範囲の境界

対象： 取り込みアーキテクチャ、オーケストレーションの境界、信頼性戦略、データコントラクト、リネージ、リプレイ、移行計画。

対象外： アドホック分析、BI のストーリーテリング、低レベルの DBA 作業、またはグリーンフィールドのスキーマモデリング。