1. なぜデータ基盤を構築し、層を分けるのか？
なぜ基盤が必要なのか？
- データ駆動型経営への移行: 経験や勘ではなく、事実（データ）に基づいた意思決定を行うため。
- AI/MLの土台: 将来的なAI活用には、高品質で整理されたデータが大量に必要不可欠であるため。
なぜ「レイヤー（層）」を分けるのか？
- 責務の分離: 「データの保存」「掃除」「統合」「活用」を混ぜると、どこかで変更があった瞬間に全体が壊れるからです。
- カオス（ゴミ屋敷化）の回避: 手っ取り早く生データをBIツールに繋ぐと、数値の定義がバラバラになり、誰もデータを信用しなくなります（Garbage In, Garbage Out）。
- 手戻りの最小化: ロジック変更があっても、前の層からやり直せる「再現性」を担保するためです。
2. どのようなアーキテクチャで実現するのか？
① ELT (Extract, Load, Transform) の採用
- 戦略: データを加工してから入れる（ETL）のではなく、「まずクラウドDWHに入れてから、中で加工する（ELT）」。
- 理由: クラウド（Snowflake/BigQuery）の強大な計算リソースを使えば、生データを最速で取り込め、試行錯誤のコストが劇的に下がるからです。
② レイヤード・アーキテクチャ
- 戦略: データをバケツリレーのように、段階的にきれいにしながら渡していく。
- ルール: 飛び級（Lakeから直接Martなど）は禁止。各層の役割を厳守する。
③ 列指向（Columnar）と不変性（Immutability）
- 戦略: 分析に特化した「列指向ストレージ」を採用し、過去データは上書きせず「追記」で履歴を残す。
- 理由: 分析クエリの高速化と、監査・リカバリ能力（タイムトラベル）を確保するため。
3. 具体的に何を構築し、どう運用するのか？
このパートが、現場で実装すべき具体的な「4つの層」と「6つの運用機能」です。
A. 構築する4つのレイヤー
| レイヤー | 別名 | 役割 | Must | アンチパターン |
|---|---|---|---|---|
| ① Data Lake | Raw / Bronze | ソースデータを**「そのまま」**保存する場所。 |
再現性確保 全ての源泉。ここがあればやり直せる状態にする。 |
加工・上書き フィルタリングしたり、過去データを消してはいけない。 |
| ② Staging | Integration / Silver | データの**「掃除と標準化」**をする場所。 |
クレンジング 型変換、重複排除、個人情報マスキングを行う。 |
ビジネスロジック 「売上の定義」など、解釈が入る計算はしない。 |
| ③ DWH | Core / Gold | 全社の**「真実の単一ソース」**を作る場所。 |
統合 スタースキーマで設計し、揺るぎないマスタを作る。 |
部署独自データ 特定部署にしか通じないローカルな定義を持ち込まない。 |
| ④ Data Mart | Serving | 特定用途向けに**「切り出し・集計」**した場所。 |
使いやすさ BIやAIが即座に使える形に事前計算しておく。 |
Lake直結 品質保証されていない生データを使ってはいけない。 |
B. 実装すべき6つの運用機能
「動けばいい」ではなく、「止まっても大丈夫」な仕組みを作ります。
1. データリネージ
- 「この数字はどこから来たか」の系譜を可視化する仕組み（dbtなど）。
- エラー発生時に、原因となる生データや加工処理を瞬時に特定するため。
2. オブザーバビリティ
- 「IDがNULL」「売上がマイナス」などの異常を毎日自動テストし、Slack通知する仕組み。
- 人間が目視でデータの品質を監視するのは不可能だから。
3. バックフィル設計
- 過去の日付を指定して、データを再生成できる冪等な（Idempotent）パイプライン。
- ロジックのバグ修正や、新指標の追加時に、過去1年分を洗い替える必要があるから。
4. ウォーターマーク
- データ処理の進捗を示す「しおり」。復旧時は少し前（-2時間など）に戻って再取得する。
- ネットワーク遅延などで遅れて届くデータ（Late Arrival）の取りこぼしを防ぐため。
5. FinOps（コスト管理）
- パーティショニング（日付分割）の強制と、予算アラート/リソース制限の実装。
-
SELECT *によるフルスキャンで発生する「クラウド破産」を防ぐため。
6. スキーマ・オン・リード（Schema-on-Read）
- 取り込み時はJSON型などで柔軟に受け入れ、読み出し時に型を定義する方式。
- データソース側の突然のカラム追加や変更で、夜間バッチが停止するのを防ぐため。