変更要約: §4.4「Microsoft Fabric(統合分析プラットフォーム)」を新設(2026改訂で分析ドメインの中心となった Fabric/OneLake/レイクハウス/リアルタイムインテリジェンス/Data Activator の陳腐化を是正)。既存の Synapse 中心構成に Fabric を追加
4.1分析の流れとデータウェアハウス/データレイク
データ分析の一般的な流れ(取り込み→処理→格納→可視化)と、データウェアハウスとデータレイクの違い、ETL/ELT を理解します。
データ分析は、データを集めて、整えて、貯めて、見せるという流れで進みます。この一連を理解すると、各 Azure サービスがどこを担うかが見えてきます。
4.1.1分析の流れ
- 取り込み(ingest):さまざまなソースからデータを集める。
- 処理(process):クレンジングや変換でデータを整える。
- 格納(store):ウェアハウスやレイクに貯める。
- 可視化(visualize):レポートやダッシュボードで見せる。
この流れの出発点は多様なデータソース(業務DB・ログ・IoT・外部 API など)で、終着点は人が見るレポートやダッシュボードです。途中の「処理」では、欠損や形式の不揃いを整えるクレンジングと、分析しやすい形に整形する変換が行われます。第1章で学んだ OLTP(業務システム)から、この分析の流れを通じて OLAP(分析基盤)へデータが渡る、という全体像を押さえましょう。
4.1.2データウェアハウスとデータレイク
データを「貯める」格納先には、目的の異なる2つがあります。データウェアハウス は、あらかじめ整形・構造化したデータを分析・集計に最適化して格納します。スキーマが定義済みなので集計クエリが速く、定型的なレポートに向きます。データレイク は、生のまま多様なデータ(構造化・半構造化・非構造化)を、形式を問わず大量に安価に貯められます。「まず貯めて、使うときに整える」発想で、機械学習や探索的分析の素材置き場として使われます。両者を組み合わせ、レイクに生データを貯めつつ整形済みをウェアハウスで分析する レイクハウス という考え方もあります。
| 観点 | データウェアハウス | データレイク |
|---|---|---|
| 格納するデータ | 整形済みの構造化 | 生・多様(構造化〜非構造化) |
| スキーマ | 書き込み時に定義 | 読み取り時に解釈 |
| 向く用途 | 定型レポート・集計 | 探索的分析・機械学習 |
ソースから格納先へデータを移す処理が ETL(Extract 抽出 → Transform 変換 → Load 格納)と ELT(Extract → Load → Transform)です。違いは変換のタイミングで、先に変換してから貯めるのが ETL、先に貯めてから必要に応じて変換するのが ELT。大量データを扱うクラウドでは、まずレイクに貯めてから処理する ELT がよく使われます。
分析の4段階(深掘りの方向): 記述的(descriptive:何が起きたか/集計・レポート)→ 診断的(diagnostic:なぜ起きたか/原因分析)→ 予測的(predictive:今後どうなるか/機械学習)→ 処方的(prescriptive:どうすべきか/推奨アクション)。右にいくほど高度になり、DP-900 では「どの問いがどの段階か」を結べると理解が深まります。
Q. ウェアハウスとレイク、どちらを使う? 定型の集計レポートならウェアハウス、形式が多様で「まず貯めたい」「機械学習にも使う」ならレイク。両立がレイクハウス。Q. ETL と ELT の選び方は? 取り込み時に整形が必要なら ETL、大量データを素早く取り込んで後で柔軟に処理するなら ELT。Q. クレンジングとは? 欠損・重複・表記揺れなどを直してデータの品質を上げる処理です。
「整理済みの構造化データで分析=データウェアハウス」「生の多様なデータを大量に=データレイク」、そして ETL(先に変換)/ELT(後で変換) の違いが頻出です。分析の4段階(記述的/診断的/予測的/処方的)も押さえましょう。
4.1.3この節のまとめ
- 分析の流れ:取り込み→処理→格納→可視化
- ウェアハウス(整理済み構造化)/レイク(生の多様)、ETL/ELT
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. 整理された構造化データを格納し、分析や集計に最適化されたものはどれですか?
Q2. 構造化から非構造化まで、生のまま多様なデータを大量に格納できるのはどれですか?
Q3. データ分析パイプラインの一般的な順序として正しいものはどれですか?

