「データウェアハウスを構築して」と上司から突然言われた人へ

## はじめに

◆この記事は何？
この記事では、次の3つについて解説します
1. データウェアハウスの重要な基本概念
2. 構築時の注意点
3. 学習に役立つ参考資料

◆対象は？
データウェアハウス構築について学びたい人

◆この記事のねらい
- 初学者がデータウェアハウスについて何を学べばいいか分かる
- データウェアハウス構築の注意点がわかる

## 押さえておくと良いこと

### 業務データベースと分析データベース

データの利用の観点から、データベースは業務データベースと分析データベースに分けることができます。データウェアハウスは分析データベースに相当します。

データベースの利用目的が異なるため、業務データベースと分析データベースは分離して構築します。仮に一緒に構築してしまうと、分析に利用するクエリやプログラムはサーバに大きく負荷がかかるため業務データベースに支障を与える可能性があります。

データウェアハウスは大量データを保持し、大量データを分析処理する必要があります。

そのため、<font color="red">**業務データベースとは違ったアーキテクチャ、データモデリングテクニックが必要となります。**</font>

### データウェアハウス

#### データウェアハウスの特性

業務データベースとの違いを理解するために、データウェアハウスの特性を押さえます。

データウェアハウスの4つの特性は以下のとおりです。データウェアハウスとは、次の4つの特徴を持ったデータベースといえます。

**(1)サブジェクトごとに編成されていること**
サブジェクトとは、顧客や商品のようにデータとしてまとまりのある分野のことです。サブジェクトごとに編成することで、アプリケーションにとらわれず、さまざまな角度からデータを分析できるようになります。

**(2)データが統合されていること**
分析システムでは、分析対象のデータをさまざまな源泉から集めてきます。名寄せして、データ型と値の表現を統一します。また、使えるカラムを選別して合成します。このような処理をデータ統合といいます。

**(3)データが時系列であること**
言い換えると、過去のデータを持っていることです。分析のためには、最新データだけでなく、履歴データが必要です。

**(4)データが永続すること**
言い換えると、一度記録したら原則は消さない、更新しない、ということです。

### アーキテクチャ

データウェアハウスがどこに位置するかを理解するために、全体像となるアーキテクチャを押さえます。

![技術記事用_図作成.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/616496/bf5c209f-3ae9-4c4f-cf36-1e81279780ce.png)

#### 「データウェアハウス」という言葉が指すもの

「データウェアハウス」という言葉が、設計の意味で使われているのか、前述したSQLアーキテクチャのような機能を持つ製品の意味で使われるのか注意が必要です。

書籍「実践的データ基盤への処方箋」より引用します。

> データレイク層とデータマート層の中間にあたる「データウェアハウス層」（設計上の役割）と、大規模なデータ処理に特化した「データウェアハウス製品」（ツール）は、同じ「データウェアハウス」という言葉で、混乱を招きやすいと筆者は感じています。かつては「データウェアハウス製品」というツールは、「データウェアハウス層」のデータを管理するために使われていました。データウェアハウス製品の性能向上によって、データレイク層やデータマート層のデータを扱うことが容易になったため、用語の持つ意味が分離したのだと筆者は解釈しています。

この記事では、構築に焦点を当てるため、データウェアハウス層だけでなく、データレイク層やデータマート層にも言及します。

### データレイク

データレイク層は、**元のデータをコピーして、1つのシステムに集約したもの**を指します。データソース（＝水源）から流れてきたデータを蓄える場所なのでレイク（湖）と呼びます。

### データマート

データマートとは、1つのサブジェクトを分析するための専用データベースです。例えば、顧客データマート、商品データマート、店舗データマートのように、サブジェクトごとに別々のデータマートを作成します。

商品(データ)が加工され売り出されている状態を市場（マート）に見立てています。

### スタースキーマ

**データウェアハウスのモデリングと業務データベースのモデリングは異なります。**
スタースキーマは、BIツールから参照しやすいテーブル設計方式の一つです。

スタースキーマでは、ファクトテーブルとディメンションテーブルを組み合わせます。

製品によっては、「ファクト」のことを「メジャー」ということがあります。
ディメンションテーブルとは、分析の切り口となる属性値です。

![技術記事用_図作成_スタースキーマの例.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/616496/5d2c0d00-b639-b127-c104-8a31c88cca79.png)

ファクトテーブルとでィメンションテーブルに分けることで、分析のパフォーマンスが上がるなどのメリットがあります。

このように、星型（スター）でデータ構造（スキーマ）を表現できることから、スタースキーマと呼ばれます。

![技術記事用_図作成_スタースキーマ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/616496/77647a50-278c-25bc-edbb-eadcc0d361cf.png)


### スター型とスノーフレーク型

スタースキーマの類似の設計手法として、「スノーフレークスキーマ」があります。これらの設計手法を総称して「ディメンショナルモデリング」と呼びます。

スノーフレークスキーマを理解したい方は、まずはDataBricksの用語集を確認するのがおすすめです。

https://www.databricks.com/jp/glossary/snowflake-schema

### データ転送

#### ETLとELT

ETLは、Extract・Transform・Loadの頭文字です。システムのデータベースからデータを取り出し（Extract）、分析システムへ入れるための変形・加工を行って（Transform）、分析データベースにデータを入れる（Load）、一連の操作です。

ELTは、分析データベース上でSQLを用いてTransformを行います。分析データベースのリソースを活用できます。分析データベースに並列RDBMSやHadoopを用いる場合はELT主体で考えます。

#### ストリーム転送

ETLのようなバルク転送は、毎晩バッチで一括転送する仕組みに対して、ストリーム転送は常に行を送り続ける仕組みです。

例えば、Amazon Kinesisが相当します。

## 構築・運用時に気をつけること

構築・運用時に気をつけることの一例を紹介します。

### アーキテクチャ

**データを逆流させないようにする**
例えば、データマート層からデータウェアハウス層にデータを流さないようにします。

### データ収集

**①リアルタイム性を確認する**
データ転送方法の検討時に、「リアルタイム性」がどれほどリアルタイムなのかを確認します。「リアルタイム」は人によって定義が変わる場合があるため、定量的に確認するようにします。要件によってデータ転送方法を使い分けます。

**②負荷を確認する**
特に、SQLを利用したデータベースからのデータ収集では負荷を確認します。
負荷を意識していなければ、分析用のデータ収集によって、業務データベースし支障をきたす可能性があります。

### データレイク層

**①元のデータをそのままコピーする。集計しないようにする**

「同じデータをコピーするのは無駄」「元データのままだと使いにくい」という背景から発生します。
データ活用が進むと、データ分析の観点が増えるため、集計してしまうと使えなくなる可能性があります。

**②複数箇所にデータレイクをつくらないようにする**

データレイクを複数箇所に設置すると、運用が複雑になります。

### データウェアハウス層

業務データベースと分析データベースは違います。

**①分析データベースのためのデータモデリングを採用する**
前述のように、分析データベースは業務データベースとデータモデリングが異なります。

スタースキーマなどの分析用のデータモデリングを採用します。

**②分析用データベース向きのSQLにする**
分析に向いたSQLにします。
データ分析用データベースは、データの一部だけの更新・削除は苦手です。

例えば、UPDATE文で更新しようとして処理が終わらない、というのは初学者が陥りがちなアンチパターンです。

### データマート層

データマートは構築時よりも運用時に気をつけます。

データマートは時間の経過とともに劣化します。そのため、使われないデータマートが発生していきます。

**アクセス数が減ってきたときの対応策を考える**

不要になったデータマートを削除するようにします。






## 初学者におすすめの書籍・記事

初学者におすすめの記事、役に立つWebページ、書籍を紹介します。難易度順に並べています。

**(1)Webページ「データウェアハウス／BI技術を学ぼう！」**

データウェアハウスを学ぶ上での導入がわかりやすい連載記事です。

https://el.jibun.atmarkit.co.jp/dwbi/2011/05/1-c6a3.html

**(2)Webページ「DataBricks Glossary」**

DataBricksの用語集です。わからない単語を調べるときに便利です。

https://www.databricks.com/jp/glossary

**(3)書籍[「10年戦えるデータ分析入門」](https://amzn.asia/d/4lDevRh)の11章「10年戦えるデータ分析システム」**

平易でわかりやすいです。データウェアハウスに関連する概念や気をつけることがわかります。

**(4)書籍[「実践的データ基盤への処方箋」](https://amzn.asia/d/gUCkBfw)**

データ活用についてわかりやすく書かれています。

**(5)書籍[「データ分析基盤入門＜基本編＞」](https://amzn.asia/d/2i9n8ls)**

「10年戦えるデータ分析入門」や「実践的データ基盤への処方箋」よりも詳細に書かれています。

**(6)ベストプラクティス集**

Webで公開されているベストプラクティス集によって、理解を深めることができます。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/best-practices.html

https://dev.classmethod.jp/articles/dbt-project-building-best-practices-03-purpose-built-transformation-steps/

## 関連用語

データウェアハウスに関連する用語を紹介します。

| 用語 | 意味 |
|:-:|:-:|
| 仮想データマート | DWHと物理的に同じデータベース内にあるデータマートのこと |
| スタースキーマ | ディメンジョンモデルの別名 |
| データコンソリデーション | データマートを統合する活動|
| バルク転送 | バルクロードとバルクエクスポートをまとめた言い方 |
| データスチュワード| データ整備の推進者 |
| SSOT | Single Source of Trust, 信頼できる唯一の情報源 |

## おわりに

この記事では、①データウェアハウスを学ぶ上で押さえておくと良い概念②構築で気をつけること③初学者におすすめの記事・書籍を紹介しました。

データウェアハウス構築を始める際の参考になれば幸いです。

## 参考

[「データウェアハウス／BI技術を学ぼう！」](https://el.jibun.atmarkit.co.jp/dwbi/2011/05/1-c6a3.html)

[「10年戦えるデータ分析入門」](https://amzn.asia/d/4lDevRh)

[「実践的データ基盤への処方箋」](https://amzn.asia/d/gUCkBfw)

[「データ分析基盤入門＜基本編＞」](https://amzn.asia/d/2i9n8ls)

[Qiita「データウェアハウスのデータモデリングを整理してみた」](https://qiita.com/zumax/items/41458d3509859f310ed8)