10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)
本書では、分析システムのあるべき形として、「SQL中心アーキテクチャ」というものが提唱されている。
BigQueryを中心に据えたデータ基盤を作りたいと思っていたので、大変参考になった。
SQL中心アーキテクチャとは
- 1. 必要なデータを1つのデータベースに集める
- 2. データの加工には原則としてSQLだけを用いる
- 3. データベース内を論理的にソースデータ層・DWH層・アプリケーション層の3層に区分する
SQL中心アーキテクチャの利点
- 企業のデータはほとんどRDBMSかHadoopにある
- RDBMSもHadoopも共通点としてSQLが使える
- サイズの制約がない
- データ量が数MBでも数PBでも制約なく使える
- BigQueryのような強力なデータベースの力を活かせる
- エンジニアとプランナーの共通言語として優れている
SQL中心アーキテクチャの3つの層
ソースデータ層
- 元データをそのまま格納した層
DWH層
- 整理・統合された汎用共通データモデル層
- 例: アプリケーション層で共通で使われる利益集計テーブルや、広告費用集計のテーブル
アプリケーション層
- 特定の分析や分析システムに特化したデータや、集計済みテーブルを格納する層（データマート）
- 例: DWH層の利益集計と広告費用集計から出したROIテーブル
段階的な構築
3層管理は面倒だと思われがちだが、以下のようなイメージで段階的に進めていくと面倒ではないはず。
- 1. まずは元データをそのままデータソース層に貯める
- 分析者は5、6人であればデータソース層から直接分析すれば問題ない
- 2. 分析者が多くなり、データソース層だけでは厳しくなったらアプリケーション層を作る
- 主に集計テーブルや、BIツール用のテーブルを作る
- 3. さらに分析者が多くなり、アプリケーション層が乱立し、曖昧なデータの定義が混乱を生み出したらDWHを作る
- 共通部分をくくりだし、アプリケーション層で曖昧だった定義を共通化し固める
ETLよりELTを使う
ETL
- Extract -> Transform -> Load という順番で、Transformしてから分析データベースに入れる
ELT
- Extract -> Load -> Transform という順番で、分析データベースに入れてからTransformする
BigQueryのような強力なデータベースを利用している場合は、ELTモデルの方が恩恵を受けられるという理由で、本書ではELTの方が推奨されている