前提

この記事を書く目的

思考整理、知識の定着、理解の深化
アウトプット力の向上
知識共有

この記事でやりたいこと

改訂新版［エンジニアのための］データ分析基盤入門＜基本編＞　データ活用を促進する！プラットフォーム＆データ品質の考え方

👆を読む
👇のアクションを行い目的を達成する
- まとめる
- アウトプットする

読書メモ

章	Link	概要
0	[速習]データ分析基盤と周辺知識	データ分析基盤入門プロローグ
1	[入門]データ分析基盤	データ分析基盤を取り巻く「人」「技術」「環境」
2	データエンジニアリングの基礎知識	4つのレイヤー
3	Link
4	Link
5	Link
6	Link
7	Link
8	Link
9	Link

0章 [速習]データ分析基盤と周辺知識

＜データ分析基盤を支える3つのシステム＞

💡ポイント💡

データ分析基盤の役割
➡ 「価値ある情報」を作ること
データをうまく活用するための組み合わせ
➡ SoR（記録）＋ SoE（やり取り）＋ SoI（分析）

☝️ちょっぴり深堀り☝️

SoR (System of Record)：記録のシステム
👉 会社の大事なデータを正しく管理するシステム
💡 商品情報、注文履歴など

SoE (System of Engagement)：ユーザーとやり取りするシステム
👉 お客さんやユーザーが実際に使うシステム
💡 ECサイト、スマホアプリなど

SoI (System of Insight)：データを活用するシステム
👉 SoRとSoEのデータを分析し、役立つ情報を作るシステム
💡 売上予測、おすすめ商品の提案など

🤔ECサイトを例にしてかんがえてみる

SoR：商品データや注文情報を管理
SoE：ユーザーがECサイトで商品を検索・購入
SoI：購入データを分析し、おすすめ商品を提案

1章 [入門]データ分析基盤

1章の全体の流れ

Topic	Summary
1.1: データ分析基盤の変遷	基盤そのものがどう進化したのか？
1.2: 処理基盤/クラスターの変遷	処理技術がどのように発展したか？
1.3: データの変遷	扱うデータの多様化と拡大について
1.4: データ分析基盤に関わる人の変遷	データ分析基盤に関わる人材やロール
1.5: データへの価値観の変化	データは量より質である
1.6: データに関わる開発の変遷	データに関わる開発における人や組織の関係性の変化

＜1.1: データ分析基盤の変遷＞

💡ポイント💡

データ分析基盤と処理の仕組みの進化
➡ コンピューターの進化とともに、データ分析基盤も進化した
データ分析基盤を構成する3要素
➡ データレイク＋データウェアハウス＋データマート

☝️ちょっぴり深堀り☝️

🖥️ 時代①：シングルノード時代（1990-2000代初頭）

■ 仕組み：シェアードエブリシング（すべて1台で処理）

🏚️1台のマシンでデータ保存と計算を全部やる
📊1台のPCやサーバーで、エクセルやDBを使って分析

■ 限界

📈データ量が増えると1台では処理しきれない
📉ディスクの読み書きが遅くなる

🏗️ 時代②：マルチノード/クラスター時代（2000-2010年代）

■ 仕組み：シェアードナッシング（それぞれが個別に保存して連携）

🔗複数のマシンがそれぞれ自分用のデータ保存場所を持って連携
🖧 Apache Hadoopなどの技術で複数コンピューターを連携（ビッグデータ時代）

■ 限界

🛠️複雑な管理が必要で専門性が高い
⚔️リソースの奪い合いが発生することも

☁️ 時代③：クラウド時代（2010年代後半～現在）

■ 仕組み：シェアードオンリーデータ（データは一か所に、処理は各々が必要に応じて）

🏢データは大きな共有倉庫に保存し、処理は別々のコンピューターで実行
🔄データ保存と計算処理の分離（例：S3にデータを保存、GlueやAthenaで処理）
⚡️必要な時に必要なだけ処理能力を使える

クラウド時代の現代、データの流れに沿って以下の3要素が連携
🏞️データレイク：あらゆる形式のデータがそのままぶちこまれる
🏬データウェアハウス：↑のデータを構造化したものがぶちこまれる
🛒データマート：特定の目的やユーザーのためのデータを活用できる状態

＜1.2: 処理基盤/クラスターの変遷＞

💡ポイント💡

1.2は主に「時代②：マルチノード/クラスター時代」と「時代③：クラウド時代」の解説
➡ Hadoopからクラウドへの進化の流れを掘り下げている
マルチノードとクラスター
➡ マルチノード：複数のコンピューター
➡ クラスター：複数のコンピューターを連携させて一つのシステムとして動かす仕組み

☝️ちょっぴり深堀り☝️

分散処理の発展

Apache ZooKeeperの登場でノード間の連携が向上
Hadoopが分散処理の覇権を握る

スレッド処理と分散処理の処理限界に対するアプローチ

スレッド処理：スケールアップ（縦に拡張）で解決
分散処理：スケールアウト（横に拡張）で解決

Hadoopのエコシステム

Hive、Sparkなどの関連技術が登場
MPPDBの登場（RedshiftやBigQueryの先駆け）

クラウドでの提供

Hadoop や MPPDB がクラウドで提供されるようになった
ストレージと計算処理が分離（デカップリング）することで、様々なサービスからビッグデータが使われるように（Kubernetes (k8s) などのコンテナ技術との統合）

留意点

🤔 選択肢が多すぎて何を使うべきか迷うことも
💡 適切な技術を選択することが求められる時代に

＜1.3: データの変遷＞

💡ポイント💡

1.3は「データ自体」の変化に焦点を当てている
➡ Excel時代と比べると多様なデータを扱うようになった
データの変化の観点
➡ 重要性・気密性UP。量もUP。種類もUP。活用方法も幅広く！

☝️ちょっぴり深堀り☝️

データ量は増加傾向
例）Facebookは10年前の約2倍のデータ量に１
2010年→月7PB(=7000TB)
2021年→月14PB程度

ビッグデータ技術の使いどころ
1GBを超えるファイルはビッグデータ技術使った方が良い

データの変化

🆙重要性

🙅 「なんとなくこう思う」という意思決定
🙆‍♀️ 「データに基づく」意思決定が重視される時代に

🆙機密性

個人識別情報（PII）を含むデータが増加している
データ保護規制の厳格化（改正個人情報保護法など）が行われる
複数データを組み合わせると個人特定につながる可能性もある
法律などの急激な変化に耐えられるデータ分析基盤が必要

🆙種類

昔：シングルノード時代は主にExcelやRDBのデータのみ
今：IoT、履歴情報、監視カメラ、各種センサーなど多種多様

🆙活用方法

昔：SQL/Excelによる単純集計・分析
今：不正検知、パーソナライズ、機械学習、AI予測、レコメンド、検索など多岐にわたる活用

＜1.4: データ分析基盤に関わる人の変遷＞

💡ポイント💡

1.4の焦点は「人間」
求められるスキルやバックグラウンドが違うデータ専門家の登場！
様々なステークホルダー（利害関係者）と協業していくことが要求されるようになる

👇ちょっぴり深掘り👇

データ専門家の3つの役割

役割	どんな人？	主なタスク
🧑‍💻データエンジニア ※この本のメインになる人！	データを集めて統合、分析をサポートする人データ分析基盤の管理者	データ分析基盤整備データパイプライン整備
🧠データサイエンティスト	コンピューターサイエンスや数学のバックグラウンドがあり、機械学習やディープラーニングの知見を持っている人	データから「パターン」と「関係」を元に知識や知恵を抽出/創出する
📊データアナリスト	ビジネス側の人とコミュニケーションを取りながら答えを導き出す人材	データマートのデータから「パターン」と「関係」を見出しビジネス価値を創出する

データエンジニアリングの領域

分散システムの構築管理
データの取り込みやETLを通じたデータパイプラインの最適化
データが格納されているストレージの管理
ユーザーへのアクセス環境提供
データサイエンティストやデータアナリストの実験結果をプロダクトに反映し、自動化データパイプラインを作成

データエンジニアに求められる知識

スモールデータシステムの知識
最終的にスモールデータシステムの集合体がビッグデータになるため、スモールデータの知識も必要

＜1.5: データへの価値観の変化＞

💡ポイント💡

「量より質=Quality beats quantity」の考え方へシフト
⇨ 「インプットが間違えていれば、アウトプットも間違える」！（当たり前だ）
データ品質やメタデータ管理を通じたデータ管理が課題
⇨ メタデータ＝「データに関するデータ」のこと。データの信頼性を確保したり、データ活用を効率化したりするために不可欠らしい。
⇨ 例）データの作成日時・更新日時、データの形式や構造など。

👇ちょっぴり深掘り👇

データ価値観の変化

昔：「とにかくデータを集めさえすれば良い」
今：「意味をなさないデータを排除し、データ品質をより強化する」

量より質=Quality beats quantity

従来のデータ分析基盤では「とにかくデータがあれば良い」という考え方
インプットデータの品質が悪いと、分析結果も信頼できなくなる

データ品質と管理への注目度の高まり

Gartnerによると、データ収集や管理を課題と感じている人は少ない
（参考）https://www.sbbit.jp/article/cont1/35420
一方で、データ品質やメタデータ管理を通じたデータ管理が課題だと感じている企業が増加

＜1.6: データに関わる開発の変遷＞

💡ポイント💡

1.6の焦点は「データに関わる開発における人と組織の関係性の変化」
データに関わる開発の形は「エンジニア依存」から「自律分散型」へと進化した

👇ちょっぴり深掘り👇

エンジニア依存時代の課題

データ分析基盤は当初、エンジニアしか扱えない複雑なシステムだった
エンジニア以外のユーザーには難易度が高く、結果、データを使いたい人はみんなエンジニアに依頼することが多かった

エンジニアリソースの本末転倒

エンジニアは本来のシステム開発より「ユーザーのフォロー」に時間を割くように
システム構築よりも保守運用が主な業務になってしまう

2つの新しいアプローチの登場

１．DataOpsアプローチ

目的： データ収集から価値提供までの速度を最大化する
特徴： プロセス改善とツール整備に焦点をあて、エンジニア以外もデータにアクセスしやすくした

２．セルフサービスモデル

目的： 各個人が自分でデータを活用できる環境を作る
特徴： 権限委譲と役割分担に焦点をあて、エンジニアは基盤開発に集中し、ユーザーは各自でデータを活用

2章データエンジニアリングの基礎知識

2章の全体の流れ

Topic	Summary
2.1: データエンジニアリングの基本	データエンジニアリング業務のポイントや心構え
2.2: データの世界のレイヤー	データ分析基盤を俯瞰する
2.3: コレクティングレイヤー	データを集めるはなし
2.4: プロセシングレイヤー	データの変換処理のはなし
2.5: データ基盤分析におけるデータの種別とストレージ戦略	ストレージはデータ種別と用途に応じて選ぼう
2.6: ストレージレイヤー	3種の保存場所
2.7: アクセスレイヤー
2.8: セマンティックレイヤーとヘッドレスBI
2.9: まとめ

＜2.1: データエンジニアリングの基本＞

💡ポイント💡

データエンジニアリングの業務は広範囲
➡ インフラ構築、データパイプライン設計、データ品質管理など
核心的な4つの視点
➡ 「使いやすさ」「効率性」「継続性」「シンプルさ」
➡ 幅広い領域を上記の視点で捉えることが重要
シンプルな設計が最も重要な基本原則

👇ちょっぴり深掘り👇

核心的な4つの視点とは
単なる技術的手法ではなく、基盤構築の心構えっぽい。

視点	ポイント	概要
🌐使いやすさ	みんなにデータを届けよう	データの利用者がデータを容易に活用できるようにすること。
⚡効率性	パフォーマンスとコストの最適化	データ処理の速度を高めつつ、運用コストを抑えること。
📊継続性	データドリブンの土台	データ分析基盤を一度作って終わりにせず、継続的に改善し続けること。
🧩シンプルさ	シンプルイズベスト	複雑な構成を避け、シンプルで堅牢なシステムを構築すること。

使いやすさの工夫

使いやすいデータ環境には自然と人が集まる
様々なインターフェース（SQL、API、ファイル操作）の提供でデータ活用を促進
データドメイン知識（データの意味や使い方）を分かりやすく表現することが重要

コスト最適化の重要性

コストの最小化は利益の最大化
月10万円の削減は、月10万円の売上向上と同じ効果がある

継続性の確保

データ分析基盤は作成したら終わりでなく、勝負はむしろそのあと
科学的に継続してモニタリングし、KPIを設定することが重要

シンプルな構成の大切さ

データ分析基盤は一度構築すると、後から移行するのが非常に困難
簡単そうに見えて難しいポイント
了解しました！ポイントを修正し、それに合わせて深掘り部分も調整します。

＜2.2: データの世界のレイヤー＞

データ分析基盤を理解する際は、常にデータがどのレイヤーを通過し、どのように変化していくかを意識することで、複雑な技術スタックも整理して把握できる

💡ポイント💡

データ分析基盤の世界を俯瞰するための4つの基本レイヤー構造を解説
書籍を読み進める際も「どのレイヤーの話か」を意識すると理解が深まる

👇ちょっぴり深掘り👇

データ分析基盤の4つの基本レイヤー

レイヤー	主な役割	データの流れの中での位置づけ
コレクティングレイヤー	データを集める	入口：様々なソースからデータを取得
プロセシングレイヤー	データを処理する	変換：生データを価値ある形に加工
ストレージレイヤー	データを保存する	保管：処理前後のデータを適切に格納
アクセスレイヤー	データを利用する	出口：ユーザーがデータ価値を得る接点

コレクティングレイヤー（データを収集するレイヤー）

収集方法に応じて適切な技術選択が必要：
- ストリーミング：絶え間ないデータ収集
- バッチ：一定量のデータをまとめて収集
- プロビジョニング：とりまの仮データを事前配置
- イベントドリブン：イベント発生時に収集

プロセシングレイヤー（データを処理するレイヤー）

価値を引き出すための変換工程
生データから「関係」と「パターン」を見つけるための主なアクション：
- ETL (Extract Transform Load)：データの抽出・変換・読込の一連の流れ
- データラングリング：生データを分析用に整形する作業
- 品質計算/メタデータ計算：データの正確性評価と付随情報の生成
- 暗号化/難読化/匿名化：セキュリティと個人情報保護のための加工
- モデル作成と推論：機械学習モデルの構築と予測処理の実行

ストレージレイヤー（データを保存するレイヤー）

全レイヤーの基盤となる重要な保管機能
システム全体の安定性と拡張性を支えるために必要なこと：
- 将来的な拡大（TB〜PB級）に対応できる設計
- 高い故障耐性と処理速度の両立
- データとメタデータの適切な管理

アクセスレイヤー（ユーザーとの接点）

データ価値を実際に活用するための出口
目的に応じた多様なインターフェースがある：
1. GUI：視覚的な操作と監視
2. BIツール(SQL)：構造化データの分析
3. API：システム連携とデータ提供
4. 直接アクセス：高度な分析と処理
5. 分散メッセージング：ストリーミングデータ活用

＜2.3: コレクティングレイヤー - データを集める＞

💡ポイント💡

コレクティングレイヤー＝データ分析基盤への「入口」
4つの異なる方法でデータを収集
➡ ストリーミング、バッチ、プロビジョニング、イベントドリブン

👇ちょっぴり深掘り👇

データ収集の4つの方法

方法	特徴	ユースケース	メリット	デメリット
🔄 ストリーミング	途切れることなくデータを連続処理	リアルタイム監視が必要な場合（ウェブサイトのアクセス分析、IoTセンサー監視）	リアルタイム処理が可能	リリース難易度が高く、コストも高い
📦 バッチ	一定以上の塊のデータを一括処理	日次/週次の売上レポート、大量データの定期処理	スループットの向上が可能	リアルタイム性は低い
🔍 プロビジョニング	「仮の、準備」という意味で一時的にデータを取り込む	データ検証や一時的な分析が必要な場合	自由度が高く分析の幅が広がる	不要データが蓄積しやすい
⚡ イベントドリブン	特定イベント発生時に都度処理を実行	ファイルのアップロード検知、システムアラート対応	応答性向上、時間分散、リソース分散が可能	複雑性の増加（システム設計・管理が複雑になる）

＜2.4: プロセシングレイヤー - データを変換する＞

💡ポイント💡

プロセシングレイヤーではデータの様々な変換処理が行われる
様々な変換処理
- データラングリング
- ETL
- セキュリティ処理
- モデル作成・適用
全体像

👇ちょっぴり深掘り👇

データラングリングとETL

項目	データラングリング	ETL
目的	データの探索的な分析、価値発見	データソースの統合・変換する
担当者	データサイエンティストデータアナリスト	データエンジニア
プロセス	探索的な手法・データストラクチャリング・データクレンジング・データエンリッチング	正規のワークフロー
関係性	ETLの前段階として活用される	データラングリングで発見したルールをETLに組み込む

++ データラングリングの探索プロセス ++

No	探索的分析プロセス	作業
1.	🤔「最近、特定カテゴリの売上が急増している気がする…」という仮説を持つ	（前段階：問題意識・仮説形成）
2.	📊ExcelやJupyter Notebookで売上データをいろいろな切り口で集計	データストラクチャリング・生データを分析可能な形式に整形・異なるソースのデータを結合・集計しやすい形に変換
3.	💡「あ！週末夜間、20代女性が購入する商品パターンに変化があるっぽ？！」と発見	（中間段階：パターン発見）
4.	🧪この発見をさらに深堀りするため、データの精度を高める	データクレンジング・外れ値の除去・欠損値の処理・重複データの排除
5.	🔍さらに追加データを収集・結合し、ビジネスに役立つ気づきに昇華	データエンリッチング・顧客属性データの追加・時間帯情報の付加・商品カテゴリ情報の追加

++ ETLのワークフロー ++
ECサイトの売上データを処理する場合👨‍💻

Extract（抽出）:
- 注文データベースから注文情報を取得
- 在庫管理システムから商品情報を取得
- 顧客管理システムから顧客情報を取得
Transform（変換）:
- 日付フォーマットを統一（YYYYMMDDに変換）
- 商品金額に消費税を追加計算
- 都道府県コードを地域グループに集約（例：「13」→「関東」）
- 注文IDと顧客IDを紐付け
Load（読み込み）:
- 処理済みデータをデータウェアハウスの売上テーブルに格納

セキュリティ処理
クォレンティーンゾーン（機密情報を保持する隔離された領域）のデータを利用する場合、データを通常の状態とは違うデータに変換するマスク処理を検討する

暗号化(encryption): データを読めなくする
難読化(obfuscation): データを理解しにくくする
匿名化(anonymization): 個人識別情報を完全に取り除く

モデルの作成と適用

モデルとは:
入力データから何らかの判断や予測を行うためのルールの集合体
例）1時間以内に100km以上離れた場所での利用があれば不正判定
モデル適用とは:
モデルを使って予測すること
例）「このユーザーが次に買いそうな商品」を予測
適用タイプ:
- バッチ推論: 保存されたデータに対して一括処理
- オンライン推論: リアルタイムに到着するデータに順次適用

特徴	バッチ推論	オンライン推論
処理タイミング	定期的（日次/週次など）	リアルタイム（即時）
データ量	大量のデータをまとめて処理	単一/少量のデータを処理
レイテンシ	高い（分〜時間）	低い（ミリ秒〜秒）
リソース効率	高い（まとめて効率的に処理）	低い（常時待機が必要）
用途例	・月次レポート・定期的なレコメンド更新・リスク分析	・ウェブサイトの動的コンテンツ・リアルタイム不正検知・チャットボット

リバースETL

データ分析基盤からデータを取り出し外部システムに連携すること
用途例）BIツールでのデータ可視化、外部アプリケーションへのデータ提供

【従来の流れ】
業務システム → ETL/データラングリング → 分析基盤 → 分析結果
【リバースETL】
分析結果 → リバースETL → 業務システム → ビジネスアクション

＜2.5: データ分析基盤におけるデータの種別とストレージ戦略＞

データ種別と用途に応じた適切なストレージ戦略をしよう

💡ポイント💡

データ種別に応じた適切なストレージ戦略が効率的なデータ管理の鍵！
データには3つの種別がある
- プレゼンテーションデータ
- プロセスデータ
- メタデータ
データの種別とアクティビティの組み合わせで最適な保存先を選択しよう

👇ちょっぴり深掘り👇

データの3分類とその定義

データ種別	定義	例
📊プレゼンテーションデータ	ユーザーが最終的に触れるデータ	・BIツールでの可視化データ・モデルが予測・推論した結果として出てきたデータなど
⚙️プロセスデータ	プレゼンテーションデータを作成するためのデータ	・モデル作成用のデータ・データレイクに保存されたローデータなど
📝メタデータ	データを補足するための情報	・どのシステムから取得されたか情報・どのような処理が施されたか情報・データの生成日時情報など

データ種別とストレージレイヤーの関係（表2.1より改変）
データ種別と用途に応じた適切なストレージ戦略

用途	データ種別3分類	データ種別詳細	推奨保存先	主な製品	選定理由
生データの取得・保管	プロセス	ローデータ/マスターデータ	データレイク	・Amazon S3 ・Azure Data Lake Storage ・Google Cloud Storage ・Hadoop HDFS	大量データを安価に保存でき、構造化が不要
データの前処理・整形	プロセス	クレンジング後データ	データレイク	同上	処理済みでも基礎データとして保持が必要
処理途中の経過保存	プロセス	中間データ	DWH（*テンポラリーゾーン）	・Redshift ・BigQuery ・Snowflake	一時的な保存で、後の検証やデバッグに利用
データの探索・試行分析	プロセス	一時的な分析用データ	DWH（*テンポラリーゾーン）	・Redshift ・Athena ・BigQuery	Jupyterなどでの分析時に一時的に必要
データの出所・履歴管理	メタ	メタデータ	メタデータストア	・AWS Glue Data Catalog ・Azure Purview ・Google Data Catalog ・Apache Atlas	データの出所や変換履歴を管理、監査対応に必須
ビジネス分析向けデータ提供	プレゼンテーション	BI用集計済みデータ	DWH/データレイク	・Redshift ・BigQuery ・Snowflake ・Databricks Delta	SQLによる柔軟な分析のために構造化が必要
機械学習モデルの結果保管	プレゼンテーション	モデル推論結果データ	DWH/メタデータストア	・Redshift ・BigQuery ・Snowflake ・MLflow	構造化された形で保存と関連メタデータの管理
ファイルとしてのデータ活用	プロセス/プレゼンテーション	アクセス用ファイル	DWH/DWHデータマート	・Redshift ・BigQuery ・Tableau Hyper	直接アクセスできる形式で保存が必要
他システムとの連携用データ準備	プレゼンテーション	サマライズしたデータ	DWHデータマート/プレゼンテーションデータストア	・Amazon RDS ・Google Cloud SQL ・MongoDB ・Elasticsearch	高速アクセスが求められ、最適化された形式が必要

* 一時データである場合はテンポラリーゾーンへの保存が好ましい

テンポラリーゾーンとは？

一時的な保存領域で、一定時間で削除される
ローデータのような大量データをJupyter Notebookなどから参照してデータラングリングなどを行う際に便利
データ観察（データラングリング）や一時的なテーブル作成のために利用される

適切なストレージ選択の重要性

データの種別とアクティビティに応じて適切な保存場所を都度選択する必要がある
効率的なデータ管理とデータ利用を実現するために重要

＜2.6: ストレージレイヤー＞

💡ポイント💡

データを保存する場所は大きく3種類ある
- データレイク/DWH
- プレゼンテーションデータストア
- メタデータストア
それぞれ役割が違うので使い分けが重要

📊 データストア一覧表

データストア	場所の例（書籍から）	用途（ざっくり）
データレイク	• Amazon S3 • Google Cloud Storage • HDFS	• データの大きな倉庫 • 生のデータをとりあえず保存
データウェアハウス (DWH)	• Amazon Redshift • Google BigQuery	• 整理された分析用の倉庫 • 分析しやすい形でデータを保存
プレゼンテーションデータストア	• KVS • リレーショナルDB	• 見せるための倉庫 • アプリやBIツールと連携するデータ
メタデータストア	• AWS Glue DataCatalog • OpenMetadata	• データの説明書を保管 • データについてのデータを管理

👇ちょっぴり深掘り👇

＜データレイク/DWH＞

データレイクは手を加えず「そのまま保存」が特徴
DWHは「分析しやすく整理」されているのがポイント
クラウド時代は両方の境界があいまいになりつつある

データ活用型におけるマスターデータ管理
データ分析基盤のマスターを作成してデータレイク/DWHで管理する

データ活用型？
- データ分析基盤の外にあるシステムのデータを集約して利用する方法
- 昨今これがよく使われるそう
マスターデータ管理？
- 各システムのデータ（バラバラのマスターデータ）をマージ
- 自分が必要なデータ分析基盤専用のマスターデータを作成する
- バラバラのマスターをDWH内で一元管理することで分析精度を向上

ライフサイクル管理
データレイク/DWHの運用課題

不要データの削除が重要
データレイク/DWHにはデータが蓄積され続けるため寿命管理が必須
特にデータレイクは際限なく膨らむリスクがあり、コスト増大につながる
数PBものデータで月に数百万円もかかるため

ゾーン管理
データレイク/DWHの内部設計

データレイク/DWH内のデータを5つのゾーンに分けて整理することが一般的
生データ→分析用データに変換するまでの流れを管理しやすくする仕組みにすることが大切
データの状態に応じた適切な保管場所になるよう設計しましょう

📊 データのゾーン一覧表

ゾーン名	役割	例えるなら
ローゾーン	生データをそのまま保存	倉庫の搬入口
ステージングゾーン	加工途中のデータを保存	工場の作業場
ゴールドゾーン	分析用に整えられた最終データ	商品の陳列棚
クォレンティンゾーン	機密情報を隔離保存	金庫室
テンポラリーゾーン	一時的に使うデータの保管場所	作業デスク

＜プレゼンテーションデータストア＞

アプリケーションなど外部システムとの連携のためのデータ提供場所
「見せる」ことに特化したデータストア
「組み込みBI」を実現し、普段使うアプリで分析結果を見られる

📊 プレゼンテーションデータストアの使い分け

利用ケース	推奨ストレージ	具体例
高速応答が必要（システム連携）	KVS (Key-Value Store)	• モデル適用後のデータ提供 • 外部APIとの連携
分析利用（BIツール向け）	DWH内のテーブル	• サマライズした集計データ • 月次/カテゴリー別の集計

＜メタデータストア＞

データについてのデータを管理する専用の保管庫
「このデータはいつ更新された？」などのデータについての疑問の回答となるデータ
データ理解を助け、次のアクションにつなげる重要な役割