データアーキテクチャとは
組織のデータ資産を管理するための仕様・フレームワーク・計画の総体 。データの収集・格納・配布・消費に関するマスタープラン。
"Data Architecture defines the blueprint for managing data assets by aligning with organizational strategy to establish strategic data requirements and designs to meet those requirements."
データアーキテクチャの目的
1. データ資産の管理に関する標準と仕様 を定義する2. ビジネス戦略と整合したデータ構造 を設計する3. データ統合・共有の基盤となる標準と規則 を提供する4. ストレージ・アクセス・移動の長期的な計画 を立てる
1 エンタープライズアーキテクチャ（EA）フレームワーク
TOGAF — 最も広く使われるEAフレームワーク
Domain 1
Business Architecture
ビジネス戦略・組織・プロセス
Domain 2 ← DAMA主管
Data Architecture
データ構造・管理・EDM
Domain 3
Application Architecture
アプリケーション・インターフェース
Domain 4
Technology Architecture
インフラ・ネットワーク・ハードウェア
🔑 試験ポイント: TOGAFの4ドメイン順序は Business → Data → Application → Technology
Zachman Framework — 6×6マトリクス
企業アーキテクチャを「What（何）× Who（誰）」の6×6マトリクスで整理するフレームワーク。
視点 / 質問
Why（なぜ）
How（どのように）
What（何を）
Who（誰が）
When（いつ）
Where（どこで）
内容
動機・目標
機能・プロセス
データ・エンティティ 人・組織
時間・スケジュール
場所・ネットワーク
TOGAFとの違い
TOGAFはプロセス（ADM）中心。Zachmanはマトリクス（分類）中心。両方を組み合わせて使うことが多い。
Zachmanの特徴
6行（ステークホルダー視点）×6列（質問）のマトリクス。データの「What」列がデータアーキテクチャに対応。
2 データアーキテクチャスタイル比較
モダンデータアーキテクチャの4層構造
Source Layer（ソース層）
RDB / IoT / ログ / API / SaaS — データの発生源
▼
Storage / Ingestion Layer（格納・取込層）
Data Lake（S3/GCS）/ Data Warehouse（Snowflake/BigQuery）/ ODS — 一元管理
▼
Processing / Transform Layer（処理・変換層）
ETL/ELT / Spark / Stream Processing（Kafka・Flink）— バッチ/リアルタイム
▼
Serving / Consumption Layer — BI / ML / API
4
Serving / Consumption Layer
BI（Tableau/Power BI）、ML API、アドホッククエリ — データの消費層
消費
3
Processing / Transform Layer
ETL/ELT変換・Spark処理・ストリーム処理 — データの加工・変換層
処理
2
Storage / Ingestion Layer
Data Lake・DWH・ODS — データの一元格納・管理層
格納
1
Source Layer
RDB・IoTデバイス・ログ・API・SaaS — データの発生源
発生源
🏢 Data Warehouse（DWH）
Schema-on-Write 構造化データのみ
ETLで事前変換 → 高品質な構造化データを格納。BI・レポーティングに最適化。
✓ 高品質・一貫性
✓ 高速クエリ（OLAP最適化）
✗ 非構造化データに不向き
✗ スキーマ変更コストが高い
🌊 Data Lake
Schema-on-Read 全形式OK
生データをあらゆる形式で格納。読み取り時にスキーマを適用。ML・DS用途に適す。
✓ 柔軟・低コスト格納
✓ 非構造化データ対応
✗ データスワンプ化リスク
✗ BI用途に速度が遅い
🏠 Data Lakehouse
両方対応 全形式
Data Lake + DWHの特性を統合。Delta Lake/Icebergでトランザクション保証を追加。
✓ DWH品質 + Lake柔軟性
✓ BI/ML両方対応
✗ 設計・運用が複雑
✗ 学習コストあり
🕸️ Data Mesh
ドメイン分散 全形式
ドメインチームがデータプロダクトを自律的に所有・管理。中央ボトルネックを解消。
✓ 中央チームのボトルネック解消
✓ ドメイン専門性を活用
✗ 一貫性確保が困難
✗ 各ドメインに開発力が必要
アーキテクチャスタイル詳細比較
スタイル スキーマ方式 データ種別 特徴・用途
DWH Schema-on-Write 構造化のみ
高品質・分析最適化。BI/レポーティング向け
Data Mart Schema-on-Write 構造化のみ
DWHの部門特化サブセット
ODS Schema-on-Write 構造化
Operational Data Store。リアルタイム統合データ
Data Lake Schema-on-Read 全形式（構造化/非構造化/半構造化）
柔軟・低コスト。ML/DS向け。スワンプ化リスクあり
Data Lakehouse 両方対応
全形式
DWH+Lake統合。Delta Lake/Iceberg利用
Data Mesh ドメイン分散
全形式
4原則（Domain/Product/Self-serve/Federated Gov）
Lambda Architecture —
全形式
バッチ + ストリーム処理を統合。2コードベース問題あり
Kappa Architecture —
全形式
ストリーム処理のみで統一。単一コードベース
3 エンタープライズデータモデル（EDM）
EDMの構造と役割
EDM（Enterprise Data Model） とは、組織全体のビジネスエンティティとその関係を定義した概念・論理データモデル 。部門横断の共通言語を提供する「データの地図」。
主要なビジネスエンティティとその関係
データドメインの定義
組織全体の共通言語を提供
各システム間のデータ連携基盤
Enterprise Data Model
│
├── Subject Area: Customer Mgmt
│ ├── Customer (Entity)
│ ├── Address (Entity)
│ └── Contact (Entity)
│
├── Subject Area: Product Mgmt
│ ├── Product (Entity)
│ └── Pricing (Entity)
│
└── Subject Area: Financial
├── Account (Entity)
└── Transaction (Entity)
アーキテクチャ文書の種類
文書 内容
EDM エンタープライズデータモデル組織全体のデータ構造の概念・論理モデル DFD データフロー図データがシステム間をどう流れるか DB Architecture 物理的なデータストアの構成 Integration Arch システム間のデータ連携方式
4 データアーキテクトの役割
Enterprise Data Architect
組織全体のデータアーキテクチャを策定・管理。EDM・データ標準・データ統合方式の設計。
全社スコープ
Solution Data Architect
特定のプロジェクト・システムの設計。EDMに準拠した物理データベース設計。
プロジェクト単位
Data Infrastructure Architect
ストレージ・処理基盤・クラウドプラットフォームの設計・管理。
インフラ特化
🔑 試験ポイント: Enterprise Data Architect = 全社。Solution Data Architect = 特定プロジェクト。混同注意。
🔑 TOGAFの4ドメイン（順番ごと覚える）
Business
→
Data ← ここ！
→
Application
→
Technology
アーキテクチャスタイル クイック比較
スタイル スキーマ データ種別 最大の特徴
DWH Schema-on-Write 構造化のみ 高品質・分析最適化 Data Lake Schema-on-Read 全種（生データ） 柔軟・低コスト。スワンプ化注意 Lakehouse 両方対応 全種 DWH+Lake統合（Delta Lake） Data Mesh ドメイン分散 全種 自律型データプロダクト（4原則） Lambda — 全種 バッチ + ストリーム統合 Kappa — 全種 ストリームのみ（単一コードベース）
重要フレームワーク比較
フレームワーク 構造 特徴
TOGAF 4ドメイン + ADMプロセス 最広用EAフレームワーク。プロセス（ADM）中心 Zachman 6行×6列マトリクス Why/How/What/Who/When/Where × 視点（分類整理に強い）
接続数の計算（試験頻出）
Point-to-Point接続
N個のシステム → N×(N-1)/2 個の接続
10システム = 45接続（管理不能）
Hub-and-Spoke（ESB）
N個のシステム → N 個の接続
10システム = 10接続4以上ならHub有利
絶対に覚えるキーワード
TOGAF = 4ドメイン EAフレームワーク
EDM = 組織全体の概念・論理モデル
Data Lake = Schema-on-Read
DWH = Schema-on-Write
Zachman = 6×6マトリクス
Lambda = バッチ+ストリーム
Kappa = ストリームのみ
Enterprise Architect = 全社スコープ
Solution Architect = プロジェクト単位
4以上ならHub-and-Spoke有利
⚡ 試験直前「これだけ覚えろ」ボックス
1
TOGAFの4ドメイン順: Business → Data → Application → Technology
2
EDM（Enterprise Data Model） = 組織全体の概念・論理モデル（共通言語）
3
Data Lake = Schema-on-Read （生データ格納）/ DWH = Schema-on-Write
4
Lambda = バッチ + ストリーム / Kappa = ストリームのみ（運用シンプル）
5
Zachman = 6×6マトリクス（Why/How/What/Who/When/Where）
6
Enterprise Data Architect = 全社スコープ / Solution = 特定プロジェクト
7
N個のシステムをP2P接続 = N×(N-1)/2 。4以上はHub-and-Spokeが有利
Case 1 データプラットフォームのアーキテクチャ選択
背景: 急成長フィンテック企業（DAU: 300万人）。本番DBへの分析クエリ負荷・2TB/日のログ増加・リアルタイム不正検知要件・ML用データアクセスの4つの課題が同時発生。
アーキテクチャ検討の比較
Option 1: Data Warehouse（不採用）
ソース → ETL → DWH（Snowflake/BigQuery）→ BI
✓ 構造化データに最適
✗ 非構造化データ（ログ）に不向き
Option 2: Data Lake（不採用）
ソース → [Data Lake（S3/GCS）] → Spark → ML / Adhoc分析
↓
BI（クエリが遅い）
✓ あらゆる形式のデータを低コストで保管
✗ 品質管理が困難（「データスワンプ」化）
Option 3: Data Lakehouse（採用）
ソース → [Data Lake（S3）]
↓ Delta Lake / Iceberg でトランザクション保証
[Lakehouse Layer]
├── [BI Layer]（Databricks SQL / Redshift Spectrum）
├── [ML Layer]（Spark / MLflow）
└── [Streaming Layer]（Kafka + Spark Streaming）
✓ 非構造化+構造化を統一基盤で管理
✓ ML用途もLake側に直接アクセス
Case 2 Data Mesh への移行
背景: 大手メディア企業（事業部門数12、データエンジニア4名）。中央集権型データチームがボトルネック — データリクエストのバックログ80件以上、平均6週間待ち、中央チームが全ドメインを理解できない状態。
Data Mesh の4原則（Specialist試験頻出）
1.
Domain Ownership（ドメインオーナーシップ）
データは生成したドメインチームが所有・管理。例: ECチームはEC関連データを、広告チームは広告データを管理。
2.
Data as a Product（データをプロダクトとして扱う）
データはETLの副産物ではなく、消費者のためのUI/APIを持つプロダクト。
Data Product の特性:
□ Discoverable（データカタログで検索可能）
□ Addressable（一意のURIを持つ）
□ Trustworthy（SLAとDQ保証）
□ Self-describing（メタデータと文書化）
□ Interoperable（標準フォーマット）
□ Secure（アクセス制御）
3.
Self-serve Data Platform（セルフサービスプラットフォーム）
各ドメインが独立してデータプロダクトを構築・運用できる基盤。インフラ・デプロイ・監視・カタログ登録を自動化。
4.
Federated Computational Governance（連邦型計算ガバナンス）
各ドメインが自律的だが、グローバル標準（データフォーマット・セキュリティポリシー・インターオペラビリティ仕様）は守る。
Data Mesh vs 従来型DWH — 選択基準
状況 推奨
小〜中規模、ドメインが少ない 従来型DWH データドメインが多く、各ドメインに開発力がある Data Mesh 中央チームがボトルネックになっている Data Mesh を検討 データの整合性・一貫性が最重要 従来型DWH（Mesh はFederated故に難しい）
Case 3 エンタープライズデータモデル（EDM）の設計
EDMがないとどうなるか
問題1: 「顧客」の定義が部門ごとに異なる
営業部門: 「見込み客も顧客」
請求部門: 「支払い実績のある法人のみ」
マーケ部門: 「メールを受信している全員」
→ 同じ「顧客数」レポートで数字が3倍異なる
問題2: N×(N-1)/2 個の変換ロジック
EDMがあれば各システムがEDMに準拠するだけで連携が簡単に
EDMの段階的構築
P1
主要エンティティの特定（概念レベル） 部門横断WS → ER図（20〜50エンティティ）
P2
定義の合意 Business Glossaryへ登録。Stewardを任命
P3
論理モデルへの展開 属性・データ型・制約・ビジネスルールの定義
P4
物理実装への参照 EDMを参照してDB設計。乖離をガバナンスで管理
Case 4 TOGAF × DAMA の組み合わせ
TOGAFの4ドメインとDAMAの関係
ドメイン 内容 DAMAとの関係
Business Architecture ビジネスプロセス・組織 Business Glossary / Data Governance Data Architecture データエンティティ・フロー EDM / Data Lineage（DAMA主管） Application Architecture アプリケーション・連携 Data Integration Architecture Technology Architecture インフラ・プラットフォーム Data Storage / Database選定
ADM（Architecture Development Method）とデータ管理
Phase A: Architecture Vision（全体ビジョン）
→ データ戦略の方向性
Phase B: Business Architecture
→ ビジネスプロセスとデータの関係
Phase C: Information Systems Architecture
Data Architecture部分:
→ EDMの構築
→ データリネージの定義
→ セキュリティ要件
Phase D: Technology Architecture
→ DWHプラットフォーム選定
→ データベース技術の選定
Lambda vs Kappa — 選択基準
Lambda Architecture
ソース
├──→ [Batch Layer]（正確・遅い）→ [Serving]
└──→ [Speed Layer]（近似・速い）→ ↗
問題: 2つのレイヤーで同じロジックを実装（メンテナンス負荷）
Kappa Architecture
ソース → [Stream Processing（Kafka+Flink）]
→ [Serving Layer]
利点: 単一コードベース。ストリームの再生でバッチも処理可能。
✓ 過去データの再処理が頻繁
✓ 運用シンプルさ優先の場合
Hub-and-Spoke vs Point-to-Point
試験頻出の計算: N個のシステムを接続する場合
Point-to-Point: N×(N-1)/2 個の接続。例：10システム = 45接続
Hub-and-Spoke（ESB/APIゲートウェイ）: N 個の接続。例：10システム = 10接続
システム数が4以上ならHub-and-Spokeが有利 （試験頻出の判断基準）