data-engineering

データエンジニアリングの方法論

データエンジニアリングは、データ駆動型システムの運用を支える基盤です。この方法論では、リレーショナルデータベースやベクトルストアから、グラフデータベース、時系列ストア、それらの間でデータを移動する変換パイプラインまで、データインフラストラクチャの運用、保守、進化を扱います。

モデルがデータ変換を提案する場合は、AI 境界ワークフローを読み込み、 関連する記録を使用してください。

データエンジニアの担当領域

担当すること	担当しないこと
データベースの運用 — リレーショナル、ベクトル、グラフ、時系列ストア全体にわたるスキーマ管理、インデックス作成、バックアップ／復旧、移行	データモデリングとスキーマ設計 — これはデータアーキテクトの担当です
データ変換パイプライン — dbt モデル、ETL/ELT パターン、増分ロード、増分戦略	統計分析と実験 — これはデータサイエンティストの担当です
分析 SQL — ウィンドウ関数、CTE、クエリ最適化、実行計画の分析、スタースキーマクエリ	トレーニングインフラストラクチャとモデルのデプロイ — これは ML エンジニアの担当です
グラフデータベースの運用 — Neo4j のデータモデリング、Cypher クエリ、グラフアルゴリズム、インポート／エクスポート	アプリケーションレベルのデータアクセスパターン — これは開発者の担当です
時系列データベースの運用 — InfluxDB のスキーマ設計、ダウンサンプリング、保持ポリシー、Telegraf	インフラストラクチャのプロビジョニング — これはプラットフォームエンジニアの担当です
データ品質の監視 — 整合性チェック、重複排除、異常検知、鮮度の検証	ビジュアルダッシュボードの設計 — これはアナリスト／プロダクトデザインおよび UX の担当です
ストレージインフラストラクチャ — 容量計画、パフォーマンス調整、アーカイブ戦略

参考ファイル

参考資料	読み込むタイミング
references/sql-analytical-patterns.md	分析 SQL を記述するとき — ウィンドウ関数、CTE、実行計画の読み取り、スタースキーマクエリ、エンジン固有の最適化（PostgreSQL、DuckDB、ClickHouse、BigQuery、Snowflake）
references/dbt-patterns.md	dbt を使用してデータ変換パイプラインを設計するとき — プロジェクト構造、モデリングレイヤー（staging/intermediate/facts/dimensions）、マテリアライゼーション、テスト、スナップショット、Jinja マクロ、CI/CD、dbt Mesh
references/etl-pipeline-design.md	信頼性の高いデータパイプラインを構築するとき — 抽出戦略（全件、増分、CDC）、変換レイヤー、検証ゲート、エラー処理、冪等性
references/data-quality.md	データの整合性を監視するとき — 品質の側面、検証ルールの種類、異常検知、重複排除戦略、パイプラインの健全性シグナル
references/graph-databases.md	グラフデータベースを扱うとき — Neo4j のデータモデリング、Cypher クエリパターン（トラバーサル、集計、経路探索）、インポート戦略、グラフアルゴリズム、パイプラインとの統合
references/time-series-databases.md	時系列データベースを扱うとき — InfluxDB のデータモデル（測定値、タグ、フィールド）、スキーマ設計（カーディナリティ）、ダウンサンプリング、保持、Telegraf による取り込み、TimescaleDB／QuestDB／Prometheus との比較
references/vector-db-operations.md	ベクトルデータベースを管理するとき — Milvus、Qdrant、Chroma — インデックスの種類、コレクションのライフサイクル、次元の移行、バックアップ戦略
references/database-migrations.md	スキーマを進化させるとき — ゼロダウンタイム移行パターン、ロールバック計画、バージョン管理されたスキーマ、テストファーストの移行
references/backup-and-recovery.md	データストアの種類ごとのバックアップ戦略、RPO/RTO の計画、WAL アーカイブ、スナップショット管理、復旧計画のテンプレート
references/ai-transformation-boundaries.md	モデル支援による変換の受け入れ、再試行、コスト、公開の境界を定義するとき

関連スキル

• postgres — PostgreSQL サーバー自体の運用：設定レビュー、インデックスとクエリプランの診断、バキューム／肥大化の管理、WAL アーカイブとポイントインタイムリカバリ、レプリケーションとフェイルオーバー、アップグレード。このスキルではエンジン固有のランブックを扱い、データエンジニアリングではエンジンに依存しない方法論を扱います。
• supabase — Supabase プラットフォームの運用：マイグレーション、RLS、Auth、Storage、Functions、セルフホスト。エージェントの Supabase タスクの能力を測定するには、agent evals harness reference を使用してください。

基本原則

整合性のないデータはノイズです — データを投入する品質を超える価値のあるパイプライン、モデル、ダッシュボードはありません。すべての境界で検証してください。

運用しやすさを考慮して設計する — すべてのデータベース、パイプライン、ストアには、本番環境に移行する前に監視、バックアップ、復旧手順を定義する必要があります。障害を検知できなければ、復旧できません。

冪等性は必須です — すべてのパイプラインは、1 回実行しても 2 回実行しても同じ結果を生成する必要があります。重複への対処は任意ではありません。

スキーマ変更はコード変更です — すべてのマイグレーションには、レビュー、テスト、ロールバック計画が必要です。スキーマのドリフトは、複利のように膨らむ技術的負債です。

ストレージの特性を把握する — アクセスパターン、保持要件、増加率、整合性保証によって、適切なストレージアーキテクチャが決まります。慣れではなく、データに基づいて選択してください。