今どきの分析フローを考察(DWH内のお話し)
少し前にdbt labのDeveloper BlogでHow We Structure our dbt Projectsを読んだため、そのメモと私の思想も組み込んで備忘録とします。
間違っているよや言っていることがよくわからないなどありましたらコメントお願い致します。
この記事によるとDWH(データウェアハウス内)では3つ(4つ)のスキーマが存在するべきとしています。各層の名称は以下のようになります。1から4に数字が進むにつれてデータが整備されていきます。またこれから行う作業はdbtを使用して行うことがおすすめされています。なぜならデータの変換(T)を行うことに特化したサービスこそがdbtだからです。dbtの良さについては別途記事にします。この記事もdbtを使用することを前提に話を進めていきます。
- Source
- Staging
- (Intermediate)
- Marts
では各層の簡単な説明及び実施内容等をつらつらと記載します。
1. Source
各APIやデータやサードパーティ経由で取得したデータを保持しておくレイヤ―になります。
とりあえず取得したデータはここに突っ込んでおけばよいと思います。
説明は以上！です。
Sourceの定義やテストなどの設定はyamlファイルを作成し、そこで行います。
2. Staging
Source層のテーブルと1対1になるように設計されます。基本的にSource層に格納されているデータの簡単な整備を行うレイヤーになります。下に、実際行う一例を挙げます。
- カラムのリネームを行う
- データタイプやタイムゾーンを修正する
- 空文字を
NULLに置き換えるといった簡単なクレンジングを行う - オブジェクトのフラット化(構造化)等を行う
- ユニークかつ非NULLであるプライマリーキーの設定を行う
- 重複しているレコードの削除を行う
- サロゲートキーの作成を行う(datavaultで使用します)
Staging層では、データソースが複数ある場合は、その都度ディレクトリを作成します。
また、sqlファイルの命名規則として次の3つが代表的です。
-
stg_<ソース名>_<オブジェクト名>.sql
- オブジェクトのモデル
- 基本的にビューで持たせる(パフォーマンスが欲しい場合はテーブルで保持する)
-
scr_<ソース名>.yml
-
sourceの定義を行う(テストやドキュメントなど)
-
-
stg_<ソース名>.yml
-
modelsの定義を行う(テストやドキュメントなど)
-
また変換作業を行う際はbase modelを使用することが推奨されています。base modelとはカラムのリネームやキャストなどを専門に行うsqlになります。下記はサンプルクエリになります。
with source as (
select * from {{ source('braintree', 'payments') }}
),
renamed as (
select
id as payment_id,
order_id,
convert_timezone('America/New_York', 'UTC', createdat) as created_at,
...
from source
)
select * from renamed
3. (Intermediate)
複雑な処理を行う際に使用されるのはこの中間スキーマです。
以下は私の雑感になります。
最近datavaultというものが流行っているようです。最近その存在を知りました。まだまだ不勉強であるので詳しくを分かりませんがお話を聞く限り、このintermediate層にこの処理を行う(行おうとしている)企業があるように感じます。datavaultについて学んでから個々の雑感は再度書き直したいです。
4. Marts
ビジネスの実態に沿ったテーブルを作成します。ここでは各部署・テーマごとにディレクトリを作成します。本記事ではファクト・ディメンジョンモデルを例に紹介します。(ファクト・ディメンジョンモデルの説明は割愛します)基本的にこのモデルでは文字通りファクトとディメンジョンが存在します。
- fct_<ほげほげ>
- ザックリいうと縦長いテーブルです。トランザクションやセッション記録、注文履歴など変更できないイベントログがこれにあたります。
- dim_<ほげほげ>
- ザックリいうと横長いテーブルにあたります。各実態の変更しうる詳細なレコードが記録されています。製品、従業員、企業情報などがこれにあたります。
まとめ
このようにレイヤーごとに定義するべきことがあるようですね。個人的にdbtは非常に便利な変換ツールなのでより注目していきたいと思います。