データ統合と相互運用性とは
異なるシステム・組織・ユーザー間でデータを取得・移動・配布・変換・一致させるプロセス。
相互運用性（Interoperability） = 異なるシステムが相互に連携・通信できる能力
ETL vs ELT 比較
ETL（Extract → Transform → Load）
Source → [Extract] → [Transform] → [Load] → Target
変換をロード前に実施
バッチ処理
伝統的DWH
オンプレミス向け
有利な条件: ターゲットに生データを置きたくない・複雑な変換ロジック
ELT（Extract → Load → Transform）
Source → [Extract] → [Load] → [Transform（in target）] → Target
変換をロード後にターゲット側で実施
クラウドDWH向け
BigQuery
Snowflake
有利な条件: テラバイト以上・スキーマ変更が多い・クラウドDWH使用
| 比較軸 | ETL | ELT |
|---|
| 変換タイミング | ロード前 | ロード後 |
| 向き先 | 伝統的DWH（オンプレミス） | クラウドDWH（BigQuery, Snowflake） |
| セキュリティ | 生データがターゲットに残らない | 未変換データがクラウドに存在 |
| ツール例 | Informatica, IBM DataStage, Talend | dbt, Fivetran, Airbyte |
CDC（Change Data Capture）— 変更データキャプチャ
ソースシステムのデータ変更（INSERT/UPDATE/DELETE）を検知してターゲットに伝播する手法。
| CDC手法 | 仕組み | 効率性 | 制約 |
|---|
| ログベース |
DBトランザクションログ（binlog/WAL）を監視 |
最も効率的 |
ログへのアクセス権限必要 |
| タイムスタンプ |
最終更新日時（updated_at）で変更検知 |
シンプル |
DELETEを検知できない |
| トリガーベース |
DBトリガーで変更をキャプチャ |
シンプルに実装可 |
ソースDBに追加負荷 |
データ統合アーキテクチャパターン
🔗 Point-to-Point
システム間を直接接続。N×(N-1)/2 本の接続が必要。
スモールスタートには適するがスケール困難
接続数: 5システム = 10本、10システム = 45本
🔄 Hub-and-Spoke / ESB
中央ハブ（ESB）を経由して全システムが接続。
N本の接続のみ必要。SOAの中核
接続数: 5システム = 5本、10システム = 10本
🌐 データ仮想化
物理的にデータを移動させずに統合ビューを提供。リアルタイムアクセス可能。
例: Denodo, TIBCO
規制でデータ移動が制限される場合に有効
⚡ API統合
RESTful API / GraphQL / SOAP による接続。
マイクロサービスアーキテクチャに最適
API Gateway でルーティング・認証を一元管理
ESB vs API Gateway
🚌 ESB（Enterprise Service Bus）
- •システム間のメッセージ仲介
- •プロトコル変換・ルーティング
- •SOA（Service Oriented Architecture）の中核
- •MuleSoft, IBM MQ, TIBCO
重厚な企業システム統合向け
🔀 API Gateway
- •REST/GraphQL API の一元管理
- •認証・認可・レート制限
- •マイクロサービス向け
- •Kong, AWS API Gateway, Nginx
クラウドネイティブ・マイクロサービス向け
メッセージングパターン
| パターン | 説明 | 例 |
|---|
| 同期 |
リクエスト-レスポンス方式（即時応答） |
REST API |
| 非同期 |
メッセージキューを使った非同期処理 |
RabbitMQ, SQS |
| Pub-Sub |
パブリッシャーがイベント発行、サブスクライバーが受信 |
Kafka |
データ変換の種類
| 変換 | 説明 |
|---|
| マッピング | ソース項目→ターゲット項目の対応付け |
| 変換（Conversion） | データ型・フォーマット変換（日付形式等） |
| 集計（Aggregation） | 合計・平均・カウントの計算 |
| フィルタリング | 条件に合うデータのみ選択 |
| 結合（Join） | 複数ソースのデータを結合 |
| エンリッチメント | 外部データによる補完 |
Q1.ETLとELTの最大の違いはどれか？
✅ C) ETL=変換後にロード、ELT=ロード後にターゲット側で変換。クラウドDWH（BigQuery/Snowflake）はELTが一般的。
Q2.DBトランザクションログを監視してデータ変更を検知するCDC手法はどれか？
✅ C) ログベースCDC — DBのトランザクションログ（MySQL binlog / PostgreSQL WAL等）を監視。最も効率的で、DELETEも検知可能。
Q3.物理的にデータを移動させずに、複数のソースを統合した仮想的なビューを提供する技術はどれか？
✅ C) データ仮想化 — データを物理的にコピーせずに統合ビューを提供（Denodo等）。コンプライアンス上データ移動が制限される場合に有効。
Q4.ESB（Enterprise Service Bus）の主な役割はどれか？
✅ B) ESBはシステム間の仲介役。SOA（Service Oriented Architecture）アーキテクチャの中核。
Q5.Point-to-Point 接続で N=5 のシステムがある場合、最大で何本の接続が必要か？
✅ B) 10本 — N×(N-1)/2 = 5×4/2 = 10本。Hub-and-Spoke なら5本で済む。
Q6.イベントを発行するパブリッシャーと、興味のあるイベントを受信するサブスクライバーで構成されるメッセージングパターンはどれか？
✅ C) Publish-Subscribe — Kafkaが代表例。送信者（Publisher）が受信者（Subscriber）を知らなくてよい疎結合なパターン。
Case 1: マイクロサービス環境でのデータ統合
背景: EC企業がモノリシックシステムをマイクロサービスに移行中（12サービス）。在庫サービス・注文サービス・配送サービスの在庫数が不一致。サービス間の直接DBアクセスによる密結合が問題。
❌ アンチパターン（問題のある実装）
注文サービス → [Orders DB]
↓（直接DB接続）← 密結合！独立デプロイ不可
在庫サービス → [Inventory DB]
↓（直接DB接続）
配送サービス → [Delivery DB]
✅ 改善案1: Choreography（コレオグラフィー）
注文サービス → [Event: OrderPlaced] → Kafka
↓
在庫サービス ← [Event受信] → 在庫引当て
↓
配送サービス ← [Event受信] → 配送準備
👍 疎結合・各サービスが独立
👎 複雑な業務フローのデバッグが困難
✅ 改善案2: Orchestration（オーケストレーション）
[注文オーケストレーター]
→ 在庫サービスへ「在庫確保」API呼出
→ 成功 → 配送サービスへ「配送依頼」API呼出
→ 失敗 → 補償トランザクション（在庫を戻す）
👍 業務フローが一か所で管理（可視性高い）
👎 オーケストレーターがSPOF（単一障害点）
採用した方針（ハイブリッド）:
• シンプルな通知 → Choreography
• 複雑なトランザクション（在庫確保＋決済＋配送）→ Orchestration + Sagaパターン
Case 2: ETL vs ELTの実践的選択
Before（ETL方式）
オンプレ源泉DB
↓（Extract）
ETLサーバー（8コア）
↓（Transform: 変換・正規化）
DWH（on-prem）← 8時間かかる
問題: ETLサーバーがボトルネック
After（ELT方式）
オンプレ源泉DB
↓（Extract + Load: そのまま転送）
BigQuery Staging Area
↓（Transform: BigQueryの並列処理）
BigQuery DWH ← 30分に短縮！
効果: 変換処理が30分に短縮
| 条件 | 推奨 |
|---|
| ターゲット（DWH）の処理能力がソースより高い | ELT |
| クラウドDWH（BigQuery/Snowflake）を使用 | ELT |
| データ量がテラバイト以上 | ELT |
| ターゲットDBに生データを置きたくない | ETL |
| 複雑な変換ロジックが必要 | ETL |
Case 3: CDCの実装パターン
Debezium + Kafka の標準構成
MySQL（ソース）
↓ Debezium Connector（binlogを読み取ってKafkaに書き込み）
[Kafka Topic: mydb.orders]
↓ Kafka Connect Sink Connector
[Snowflake DWH] [下流マイクロサービス]
Debeziumのメッセージ構造
{
"op": "u", // u=update, c=create, d=delete
"before": {"id": 1, "status": "pending"},
"after": {"id": 1, "status": "shipped"},
"source": {
"table": "orders",
"ts_ms": 1699000000000
}
}
| CDC手法 | メリット | デメリット |
|---|
| ログベース | 追加負荷ゼロ。DELETE検知可 | ログアクセス権限必要 |
| トリガーベース | シンプルに実装可能 | DBに負荷。スキーマ変更時にトリガーも変更 |
| タイムスタンプ | 最もシンプル | DELETEを検知できない |
Case 4: データ仮想化 vs 物理統合の選択基準
シナリオ: 本社のアナリストが5つの地域システム（別ベンダーのCRM）のデータを統合して見たい。データ移動は規制上制限がある。
[CRM Japan] [CRM US] [CRM EU] [CRM APAC] [CRM AU]
↓ ↓ ↓ ↓ ↓
[Data Virtualization Layer（Denodo等）]
↓（仮想統合ビュー）
[アナリスト] ← SQLクエリ（あたかも1つのDBのように）
| 状況 | 推奨 |
|---|
| リアルタイム参照・少量データ | データ仮想化 |
| データ移動が規制で制限される | データ仮想化 |
| 大量データの集計分析 | 物理統合（ETL/ELT） |
| ソースシステムが非常に多い | ハイブリッド |
Specialist試験：統合パターン選択問題
問題1
ERPシステムからDWHへ毎日在庫データを転送。在庫変更は1日5,000件。現在は毎晩100万件全件フルエクストラクトしているが非効率。最適な改善策は？
解答: Log-based CDCの導入。5,000件の変更のみキャプチャし転送データ量を99.5%削減。Timestamp-based CDCはDELETEが検知できないという制約がある。
問題2
10個のシステムがPoint-to-Pointで45の接続。管理困難。どのアーキテクチャに移行すべきか？
解答: Hub-and-Spoke（ESBまたはAPIゲートウェイ）。10本の接続に削減。Pub-Subパターンで疎結合な設計に。
問題3
ELTアプローチのデメリットとして最も重要なものはどれか？
解答: ターゲットDBに未変換・未クレンジングのデータが存在しデータ品質管理が遅れる。ターゲットのコンピューティングコスト（クエリ課金）が増加。生データがクラウドDWHに存在することへのセキュリティ考慮も必要。