architecting-data

データアーキテクチャ

目的

モダンなクラウドネイティブデータプラットフォームの戦略的なデータアーキテクチャの意思決定を、アーキテクトやプラットフォームエンジニアに案内します。

このスキルを使用するタイミング

次の場合にこのスキルを呼び出します：

• 新しいデータプラットフォームを設計する場合、またはレガシーシステムをモダナイズする場合
• データレイク、データウェアハウス、データレイクハウスのいずれを選ぶか検討する場合
• データモデリング手法（ディメンショナル、正規化、データボルト、ワイドテーブル）を決定する場合
• 集中型アーキテクチャとデータメッシュアーキテクチャを評価する場合
• オープンテーブル形式（Apache Iceberg、Delta Lake、Apache Hudi）を選定する場合
• メダリオンアーキテクチャ（ブロンズ、シルバー、ゴールドの各レイヤー）を設計する場合
• データガバナンスとカタログ化を実装する場合

コアコンセプト

1. ストレージパラダイム

分析データストレージの主要なパターンは3つあります：

データレイク： 大規模な未加工データの集中リポジトリ

• スキーマオンリード、コスト最適化（$0.02-0.03/GB/month）
• 使用する場面：多様なデータソース、探索的分析、ML/AIのトレーニングデータ

データウェアハウス： BIに最適化された構造化リポジトリ

• スキーマオンライト、ACIDトランザクション、高速なクエリ
• 使用する場面：BI要件が明確で、強力なガバナンスが必要な場合

データレイクハウス： データレイクの柔軟性とデータウェアハウスの信頼性を組み合わせたハイブリッド

• オープンテーブル形式（Iceberg、Delta Lake）、オブジェクトストレージ上でのACID
• 使用する場面：BIとMLが混在するワークロード、コスト最適化（データウェアハウスより60～80％低コスト）

意思決定フレームワーク：

• BI／レポートのみ＋クエリが既知 → データウェアハウス
• ML/AIが中心＋未加工データが必要 → データレイクまたはデータレイクハウス
• BIとMLの混在＋コスト最適化 → データレイクハウス（推奨）
• 探索的／用途が不明 → データレイク

詳しい比較については、references/storage-paradigms.mdを参照してください。

2. データモデリング手法

主要なモデリングパターンは4つあります：

ディメンショナル（Kimball）： BI向けのスター／スノーフレークスキーマ

• 使用する場面：クエリパターンが既知の場合、BIダッシュボード、傾向分析

正規化（3NF）： トランザクションシステムの冗長性を排除

• 使用する場面：OLTPシステム、頻繁な更新、高い一貫性が必要な場合

Data Vault 2.0： 完全な監査証跡を備えた柔軟なモデル

• 使用する場面：コンプライアンス要件、複数のデータソース、アジャイルなデータウェアハウジング

ワイドテーブル： 非正規化され、列指向ストレージに最適化

• 使用する場面：MLフィーチャーストア、データサイエンスノートブック、高性能ダッシュボード

意思決定フレームワーク：

• 分析（BI）＋クエリが既知 → ディメンショナル（スター型スキーマ）
• トランザクション（OLTP） → 正規化（3NF）
• コンプライアンス／監査 → Data Vault 2.0
• データサイエンス／ML → ワイドテーブル

詳しいパターンについては、references/modeling-approaches.mdを参照してください。

3. データメッシュの原則

大規模な組織（500人超）向けの分散型アーキテクチャです。

4つの基本原則：

1. ドメイン指向の分散化
2. プロダクトとしてのデータ（SLA、品質、ドキュメント）
3. セルフサービス型データインフラストラクチャ
4. 連合型の計算ガバナンス

準備状況の評価（各項目を1～5点で採点）：

1. ドメインの明確さ
2. チームの成熟度
3. プラットフォームの能力
4. ガバナンスの成熟度
5. 規模の必要性
6. 組織の賛同

スコア： 24～30：有力候補 | 18～23：ハイブリッド | 12～17：まず基盤を構築 | 6～11：集中型

危険信号： 小規模な組織（100人未満）、ドメインが不明確、プラットフォームチームがない、ガバナンスが弱い

詳しいガイドについては、references/data-mesh-guide.mdを参照してください。

4. メダリオンアーキテクチャ

標準的なレイクハウスパターン：ブロンズ（未加工）→ シルバー（クリーンアップ済み）→ ゴールド（ビジネスレベル）

ブロンズレイヤー： ソースデータの完全なコピー。不変で、追記のみ

シルバーレイヤー： 検証、重複排除、型付けが済んだデータ

ゴールドレイヤー： ビジネスロジック、集計、ディメンショナルモデル、MLフィーチャー

レイヤーごとのデータ品質：

• ブロンズ → シルバー：スキーマ検証、型チェック、重複排除
• シルバー → ゴールド：ビジネスルールの検証、参照整合性
• ゴールド：異常検知、統計的チェック

パターンについては、references/medallion-pattern.mdを参照してください。

5. オープンテーブルフォーマット

データレイクで ACID トランザクションを有効にします。

Apache Iceberg: マルチエンジン対応、ベンダー中立（Context7：スコア 79.7）

• 使用する場合：ベンダーロックインを避けたい場合、複数エンジンに柔軟に対応したい場合

Delta Lake: Databricks エコシステム、Spark に最適化

• 使用する場合：Databricks を採用している場合

Apache Hudi: CDC と頻繁なアップサートに最適化

• 使用する場合：CDC が多いワークロード

推奨： 新規プロジェクトには Apache Iceberg（ベンダー中立で、最も幅広くサポートされています）

比較については、references/table-formats.md を参照してください。

6. モダンデータスタック

標準レイヤー：

• 取り込み：Fivetran、Airbyte、Kafka
• ストレージ：Snowflake、Databricks、BigQuery
• 変換：dbt（Context7：スコア 87.0）、Spark
• オーケストレーション：Airflow、Dagster、Prefect
• 可視化：Tableau、Looker、Power BI
• ガバナンス：DataHub、Alation、Great Expectations

ツールの選定：

• Fivetran と Airbyte：構築済みコネクタか、コスト重視か
• Snowflake と Databricks：BI 重視か、ML 重視か
• dbt と Spark：SQL ベースか、大規模処理か

詳細な推奨事項については、references/tool-recommendations.md と references/modern-data-stack.md を参照してください。

7. データガバナンス

データカタログ： 検索可能なデータインベントリ（DataHub、Alation、Collibra）

データリネージ： データフローを追跡します（OpenLineage、Marquez）

データ品質： 検証とテスト（Great Expectations、Soda、dbt tests）

アクセス制御：

• RBAC：ロールベース（sales_analyst ロール）
• ABAC：属性ベース（行レベルセキュリティ）
• 列レベル：PII の動的データマスキング

ガバナンスのパターンについては、references/governance-patterns.md を参照してください。

意思決定フレームワーク

フレームワーク 1：ストレージパラダイムの選択

ステップ 1：主なユースケースを特定する

• BI／レポートのみ → データウェアハウス
• ML／AI が主目的 → データレイクまたはレイクハウス
• BI と ML の混在 → データレイクハウス
• 探索的な用途 → データレイク

ステップ 2：予算を評価する

• 予算に余裕があり、クエリが既知 → データウェアハウス
• コスト重視で、柔軟性が必要 → データレイクハウス

組織規模別の推奨：

• スタートアップ（<50）：データウェアハウス（シンプルさ）
• 成長期（50-500）：データレイクハウス（バランス）
• エンタープライズ（>500）：ハイブリッドまたは統合型レイクハウス

references/decision-frameworks.md を参照してください。

フレームワーク 2：データモデリングのアプローチ

意思決定ツリー：

• 分析（BI）ワークロード → ディメンショナルまたはワイドテーブル
• トランザクション（OLTP） → 正規化（3NF）
• コンプライアンス／監査 → Data Vault 2.0
• データサイエンス／ML → ワイドテーブル

references/decision-frameworks.md を参照してください。

フレームワーク 3：データメッシュの準備状況

6 要素の評価を使用します。スコアの解釈：

• 24-30：データメッシュを導入する
• 18-23：ハイブリッドアプローチ
• 12-17：まず基盤を構築する
• 6-11：集中型

references/decision-frameworks.md を参照してください。

フレームワーク 4：オープンテーブルフォーマットの選択

意思決定ツリー：

• マルチエンジンの柔軟性 → Apache Iceberg
• Databricks エコシステム → Delta Lake
• 頻繁なアップサート／CDC → Apache Hudi

推奨： 新規プロジェクトには Apache Iceberg

references/decision-frameworks.md を参照してください。

一般的なシナリオ

スタートアップのデータプラットフォーム

コンテキスト： 50 人のスタートアップ、PostgreSQL + MongoDB + Stripe

推奨：

• ストレージ：BigQuery または Snowflake
• 取り込み：Airbyte または Fivetran
• 変換：dbt
• オーケストレーション：dbt Cloud
• アーキテクチャ：シンプルなデータウェアハウス

references/scenarios.md を参照してください。

エンタープライズのモダナイゼーション

コンテキスト： レガシーな Oracle データウェアハウスがあり、クラウドへの移行が必要です

推奨事項：

• ストレージ：データレイクハウス（Databricks または Iceberg を使用した Snowflake）
• 戦略：CDC による段階的な移行
• アーキテクチャ：メダリオン（ブロンズ、シルバー、ゴールド）
• コスト削減：60-80%

references/scenarios.mdを参照してください。

データメッシュの評価

コンテキスト： 従業員 200 人の企業で、中央データチームは 5 人です

推奨事項： まだ導入しないでください。まず基盤を整備します。

• 組織の規模が小さすぎます（推奨規模は 500 人以上）
• 中央チームはまだボトルネックになっていません
• セルフサービスプラットフォームとガバナンスに投資してください

references/scenarios.mdを参照してください。

ツールの推奨事項

調査で検証済み（Context7、2025 年 12 月）

dbt： スコア 87.0、コードスニペット 3,532 件以上

• SQL ベースの変換、バージョン管理、テスト
• データ変換の業界標準

Apache Iceberg： スコア 79.7、コードスニペット 832 件以上

• オープンテーブルフォーマット、複数エンジン対応、ベンダー中立
• 本番環境での使用実績あり（Netflix、Apple、Adobe）

ユースケース別のツールスタック：

スタートアップ： BigQuery + Airbyte + dbt + Metabase（月額 $1K 未満）

成長期： Snowflake + Fivetran + dbt + Airflow + Tableau（月額 $10K-50K）

エンタープライズ： Snowflake + Databricks + Fivetran + Kafka + dbt + Airflow + Alation（月額 $50K-500K）

references/tool-recommendations.mdを参照してください。

実装パターン

パターン 1：メダリオンアーキテクチャ

-- Bronze: Raw ingestion
CREATE TABLE bronze.raw_customers (_ingested_at TIMESTAMP, _raw_data STRING);

-- Silver: Cleaned
CREATE TABLE silver.customers AS
SELECT json_extract(_raw_data, '$.id') AS customer_id, ...
FROM bronze.raw_customers
QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY _ingested_at DESC) = 1;

-- Gold: Business-level
CREATE TABLE gold.fact_sales AS
SELECT s.order_id, d.date_key, c.customer_key, ...
FROM silver.sales s
JOIN gold.dim_date d ON s.order_date = d.date;

パターン 2：Apache Iceberg テーブル

CREATE TABLE catalog.db.sales (order_id BIGINT, amount DECIMAL(10,2))
USING iceberg
PARTITIONED BY (days(order_date));

-- Time travel
SELECT * FROM catalog.db.sales TIMESTAMP AS OF '2025-01-01';

パターン 3：dbt による変換

-- models/staging/stg_customers.sql
WITH source AS (SELECT * FROM {{ source('raw', 'customers') }}),
cleaned AS (
  SELECT customer_id, UPPER(customer_name) AS customer_name
  FROM source WHERE customer_id IS NOT NULL
)
SELECT * FROM cleaned

完全な例はexamples/を参照してください。

ベストプラクティス

1. シンプルに始める： 過剰な設計を避け、まずはデータウェアハウスまたは基本的なデータレイクハウスから始めます
2. 早い段階からガバナンスに投資する： 初日からカタログ、リネージ、品質管理に取り組みます
3. メダリオンアーキテクチャ： ブロンズ、シルバー、ゴールドを使い、品質レイヤーを明確にします
4. オープンテーブルフォーマット： ベンダーロックインを避けるため、Iceberg または Delta Lake を優先します
5. メッシュ導入の準備状況を評価する： 時期尚早な分散化は避けます（従業員 500 人未満）
6. 品質を自動化する： テスト（Great Expectations、dbt）を CI/CD に統合します
7. パイプラインを監視する： オブザーバビリティは非常に重要です（鮮度、品質、健全性）
8. コードとしてドキュメント化する： セルフサービス向けに dbt docs、DataHub、YAML を使用します
9. 増分ロード： 新規または変更されたデータのみをロードします（ウォーターマーク列）
10. ビジネスとの整合性： テクノロジーだけでなく、成果に合わせてアーキテクチャを整えます

アンチパターン

• ❌ データスワンプ：ガバナンスやカタログ化のないデータレイク
• ❌ 時期尚早なメッシュ：組織が準備できる前のメッシュ導入
• ❌ ツールの乱立：統合されていないツールが多すぎる状態
• ❌ 品質チェックなし：「入力がゴミなら、出力もゴミ」
• ❌ 集中化によるボトルネック：大規模組織（従業員 500 人超）で単一チームに依存する状態
• ❌ ベンダーロックイン：移行手段のない独自フォーマット
• ❌ リネージなし：「これはどこから来たのか？」に答えられない状態
• ❌ 過剰な設計：単純なユースケースに複雑なアーキテクチャを適用すること

他のスキルとの連携

直接的な依存関係：

• ingesting-data： ETL/ELT の仕組み、Fivetran、Airbyte の実装
• data-transformation： dbt と Dataform の詳細な実装
• streaming-data： リアルタイムパイプライン向けの Kafka、Flink

補完関係：

• databases-relational： ソースシステムとしての PostgreSQL、MySQL
• databases-document： ソースとしての MongoDB、DynamoDB
• ai-data-engineering： フィーチャーストア、ML トレーニングパイプライン
• designing-distributed-systems： CAP 定理、一貫性モデル
• observability： パイプラインの健全性、データ品質メトリクスの監視

後続スキル：

• visualizing-data： BI とダッシュボードのパターン
• sql-optimization： クエリのパフォーマンスチューニング

一般的なワークフロー：

エンドツーエンド分析：

data-architecture (warehouse) → ingesting-data (Fivetran) →
data-transformation (dbt) → visualizing-data (Tableau)

AI/ML 向けデータプラットフォーム：

data-architecture (lakehouse) → ingesting-data (Kafka) →
data-transformation (dbt features) → ai-data-engineering (feature store)

参考資料

リファレンスファイル：

• decision-frameworks.md - 4つの意思決定フレームワークの詳細
• storage-paradigms.md - レイク、ウェアハウス、レイクハウスの比較
• modeling-approaches.md - ディメンショナル、正規化、データボルト、ワイド
• data-mesh-guide.md - データメッシュの原則と実装
• medallion-pattern.md - ブロンズ、シルバー、ゴールドの各レイヤー
• table-formats.md - Iceberg、Delta Lake、Hudiの比較
• tool-recommendations.md - ツールの分析と推奨事項
• modern-data-stack.md - ツールのカテゴリと選定
• governance-patterns.md - カタログ、リネージ、品質、アクセス制御
• scenarios.md - スタートアップ、エンタープライズ、データメッシュのシナリオ

例：

• examples/dbt-project/ - メダリオンアーキテクチャを採用したdbtプロジェクト

外部リソース：

• Apache Iceberg：https://iceberg.apache.org/
• dbtドキュメント：https://docs.getdbt.com/
• データメッシュ（Zhamak Dehghani）：https://www.datamesh-architecture.com/
• Databricksメダリオン：https://www.databricks.com/glossary/medallion-architecture