セクション2: Data Warehouse Basics

Goals of a data warehouse

Centralized and consistent location for data
User-friendly (easy to understand)
Must load data consistently and repeatedly (ETL)
Data must be accessible fast (query performance)
Reporting and data visualization built on top

集約して、分かりやすく、理解しやすく、信頼のおけるSSOTにする。一貫した繰り返しのETLが必要

satokiyo

セクション3: Data Warehouse Architecture

Staging layerはなぜ必要なのか？

ソースシステムに負荷をかけたくない。出来るだけ素早くデータをExtractして、一旦DWHに持ってきたい（=ステージングレイヤ）。そのあとで変換したい。
ソースはRDBとは限らない。csvファイルだったりするので、いったんテーブルの形にしたい

😀 ※ ETL → ELTが主流になった昨今では、ソースから一旦そのままロードし（EL）、そのあとでTransformすることも多いので、ステージングレイヤという考え方自体ちょっとややこしくなりつつある気がする。DWHに複製したソーステーブルは、Permanentのステージングレイヤとも捉えられるし、DWHの一つのレイヤとも捉えられるし、もし後で削除するなら、Temporaryのステージングレイヤとも捉えられるのではないか？

Data MartはDWH(のcoreレイヤ)の部分集合

ODS(Operational Data Storage)とDWHとEAI

ODSはDWHと類似しているが、オペレーション用途/分析用途かが違う。履歴保持は求められないが、リアルタイム性が求められる
ODS＝EAI（Enterprise Application Integration）と同じ？
[あなたが欲しいデータ分析基盤は、本当にデータ分析基盤ですか？]

satokiyo

セクション4: Dimensional Modeling

What is Dimensional Modeling?

DWHでの分析用に最適化されたデータのモデリング手法（organize）
Facts(指標、Measurements)とDimension(文脈、Context)

Why Dimensional Modeling?

Performance and Usability

Factテーブルの特徴

Factテーブルは分析用DWHの中心であり、ビジネスのキーとなる指標を保持する。Dimensionによって集計、分析される。

Factテーブルの特徴

additive(数値)な値をもつ(※semi-/non- additiveなfactもある。これらは分析価値は低い。下参照)
mesureable(測定可能)⇔descriptive(説明的？)
イベント、トランザクションデータ
特定の日時、時間に発生する（Date/Timeのカラムがある。これ自体はfactではなくdimension）

Grain：factの粒度

Additivity

semi-/non- additiveは、要するに足すことに意味がないDimensionのこと。日付が典型。

Dimensions tableの特徴

Snowflake schemaを使うとしたら、Data MartではなくCoreレイヤ

satokiyo

セクション5: Facts

３つのタイプのfactテーブルがある

Transactional fact table
Periodic Snapshot fact table
Accumulating Snapshot fact table

⇒ 粒度(Grain)が異なるだけ。どのperiodでAggragateするかでGrainが決まる。テーブルのサイズが大きく違ってくる。分析目的に沿ったGrainをちゃんと決めておくのが大事。
⇒ Accumulating Snapshotが最もDimensionが多くなるのが面白い(Date FKがたくさんあることによる)

Factless fact tableとは？

上記の3つのメインタイプ以外にも、Factless fact tableが存在する。それがmetrics(指標)を持たないfactless fact table。(ex: Employee registration, mail open event ..etc.)

😀 fact tableは特定のビジネスプロセスに関連する指標(fact)やdimensionを保持するテーブルであり、factは1指標に過ぎない。fact tableには複数のfactが存在し得るし、逆にfactを持たないfact tableもあり得る。

サロゲートキーはMIIK(Monotonically Increasing Integer Key)とHashのどちらがいい？

Surrogate keys in dbt: Integers or hashes? | dbt Developer Blog

ストレージのコストが高くついた時代は、MIIKが使われていた。バイト数が少ないので。ハッシュはユニークな文字列に過ぎないので、データ容量は大きくなる。

要件によるが、現代では基本的にはハッシュの方がいい。

ハッシュキーを使うと

dbtでの変換処理が冪等になる（ハッシュ計算が決定的なので）

Using hashed keys makes our transformations idempotent
— every dbt run results in the same exact outputs every time.

These hashing functions are deterministic
, meaning the same set of inputs will always produce the same output.
ストレージは増え、Joinの計算コストも増大するが、現代のDWHでは問題にならなくなっている。

The analytical warehouses we use now no longer have the same constraints that traditional warehouses had — joins on strings aren’t notably less performant than those on integers, and storing slightly larger values in the surrogate key column is peanuts given the relative cost of storage on these platforms.
メンテナンスが楽。MIIKでキーのupdate作業などは慎重にやらないと不整合が起こる。。