Data Warehouse Detail (DWD) レイヤーは、個々のビジネスプロセスを中心に構築された詳細なファクトテーブルを格納します。データウェアハウスのディメンションモデリングの中核として、Data Warehouse Service (DWS) レイヤーと DWD レイヤーのファクトテーブルは、どちらもビジネスプロセスに基づいて設計されます。DWD レイヤーは最もアトミックなレコードを保持し、下流の分析のために完全なビジネスコンテキストを維持します。
ワイドテーブルを構築するには、常に別のディメンションテーブルを結合するのではなく、キーディメンション属性を直接ファクトテーブルに複製します。これらの格納されたディメンション列は、逆ディメンションと呼ばれます。これにより、クエリが高速化され、追加の結合なしでデータのフィルター処理や集計が可能になります。
ファクトのタイプとテーブルのタイプ
ファクトのタイプ
ファクトテーブルの各メジャーは、次の 3 つのカテゴリのいずれかに分類されます:
| ファクトのタイプ | 説明 | 例 |
|---|---|---|
| 添加剤 | どのディメンションでも正しく合計できる | 収益、数量 |
| 半加法 | 一部のディメンションでは正しく合計できるが、すべてではない | 在庫残高 (場所や商品ごとには有効だが、月をまたいで合計することはできない) |
| 非加算 | まったく合計できない | 比率、パーセンテージ |
非加算ファクトは、格納する前に加算可能なコンポーネントに分解します。たとえば、比率の分子と分母を別々の加算列として格納します。
ファクトテーブルのタイプ
DWD レイヤーは 3 種類のファクトテーブルをサポートしています。ビジネスプロセスが時間とともにどのように展開するかに合わせて、タイプを選択してください。
| タイプ | 使用するケース | 主な特徴 |
|---|---|---|
| トランザクションファクトテーブル | 特定の時点でのイベントをキャプチャする場合 | 最もアトミックなデータを格納する。アトミックファクトテーブルとも呼ばれる |
| 定期スナップショットファクトテーブル | 一定の間隔で状態を記録する場合 | 予測可能なスケジュール (日次、週次) で行が挿入される |
| 累積スナップショットファクトテーブル | プロセスの開始から終了までを追跡する場合 | 主要なマイルストーンに対応する複数の日付列があり、プロセスの進行に応じて行が更新される |
適切なタイプの選択に関するガイダンスについては、データウェアハウス構築ガイドをご参照ください。
DWD レイヤーにおけるファクトテーブルの設計
DWD レイヤーでファクトテーブルをモデリングする際は、以下の原則に従ってください。
推奨事項:
ディメンションやメジャーを選択する前に、統計粒度を宣言します。粒度は、1 つの行が何を表すか (例:1 つの注文明細、1 つのトランザクション) を定義します。
1 つのビジネスプロセスに関連するすべてのメジャーを 1 つのファクトテーブルに含めます。
テーブルごとに単一の粒度のメジャーのみを格納します。
異なるファクトテーブル間で、1 つのメジャーには同じ単位を使用します。
非加算ファクトは、加算可能なコンポーネントに分解します。
逆ディメンションを使用して、不要な結合を避け、クエリのパフォーマンスを向上させます。
null のメジャー値は明示的に処理します。ゼロ、null、または番兵値のいずれを格納するかを事前に決定します。
非推奨事項:
DWD レイヤーのファクトテーブルを複数のディメンションに関連付けないでください。混合ディメンションテーブルは粒度を曖昧にし、集計を混乱させます。
異なる粒度のメジャーを同じテーブルに混在させないでください。
4 ステップの設計プロセス
モデル化したい各ビジネスプロセスについて、以下のステップを順番に実行します:
ビジネスプロセスの選択 — 測定するイベントやアクティビティ (例:注文作成、支払い、出荷) を特定します。
粒度の宣言 — 1 つの行が何を表すかを定義します。これは、以降のすべての決定におけるセマンティックアンカーとなります。
ディメンションの選択 — イベントのコンテキスト (誰が、何を、どこで、いつ) を提供するディメンションを選択します。
メジャーの選択 — イベントを定量化する数値ファクトを選択します。
ディメンションやメジャーを選択する前に粒度を宣言することで、最も一般的なモデリングの間違いである、異なる詳細レベルのデータを同じテーブルに含めてしまうことを防ぎます。
DWDレイヤーの設計仕様に準拠する
命名規則
ファクトテーブル名は、次のパターンに従います:
dwd_{business_unit|pub}_{data_domain}_{business_process}[_{custom_tag}]_{partition_type}| セグメント | 説明 |
|---|---|
dwd | DWD レイヤーを識別する固定プレフィックス |
{business_unit} または pub | 業務部門の略称。データが複数の業務部門にまたがる場合は、pub を使用します。 |
{data_domain} | データドメインの略称(例:取引を表す trd、商品を表す itm) |
{business_process} | ビジネスプロセスの略称 |
{custom_tag} | 追加的な曖昧さ排除のための任意タグ |
{partition_type} | di:日次増分、df:日次完全 |
例:
| テーブル名 | 説明 |
|---|---|
dwd_asale_trd_ordcrt_trip_di | A 社の e コマースビジネスにおける航空券注文、日次増分でロード |
dwd_asale_itm_item_df | A 社の e コマースビジネスにおける商品スナップショット、日次フルでロード |
このチュートリアルで扱うテーブル
このチュートリアルでは、e コマースシナリオ向けに 3 つの DWD ファクトテーブルを構築します:
| テーブル名 | 説明 |
|---|---|
dwd_asale_trd_itm_di | トランザクション商品情報のファクトテーブル |
ods_asale_trd_mbr_di | トランザクションメンバー情報のファクトテーブル |
dwd_asale_trd_ord_di | トランザクション注文情報のファクトテーブル |
テーブルの作成
3 つのテーブルはすべて逆ディメンションを使用しており、主要な属性フィールドをファクトテーブルに直接埋め込むことで、クエリ時の結合の必要性を減らしています。各テーブルは日付 (ds) でパーティション化され、保持期間は 400 日です。
CREATE TABLE IF NOT EXISTS dwd_asale_trd_itm_di
(
item_id BIGINT COMMENT '商品 ID',
item_title STRING COMMENT '商品名',
item_price DOUBLE COMMENT '商品価格',
item_stuff_status BIGINT COMMENT '商品ステータス:0: 新品、1: 遊休品、2: 中古品',
item_prov STRING COMMENT '商品の省',
item_city STRING COMMENT '商品の市',
cate_id BIGINT COMMENT '商品カテゴリ ID',
cate_name STRING COMMENT '商品カテゴリ名',
commodity_id BIGINT COMMENT 'コモディティ ID',
commodity_name STRING COMMENT 'コモディティ名',
buyer_id BIGINT COMMENT '購入者 ID'
)
COMMENT 'トランザクション商品情報のファクトテーブル'
PARTITIONED BY (ds STRING COMMENT '日付')
LIFECYCLE 400;
CREATE TABLE IF NOT EXISTS ods_asale_trd_mbr_di
(
order_id BIGINT COMMENT '注文 ID',
bc_type STRING COMMENT '事業カテゴリ',
buyer_id BIGINT COMMENT '購入者 ID',
buyer_nick STRING COMMENT '購入者のニックネーム',
buyer_star_id BIGINT COMMENT '購入者のスター ID',
seller_id BIGINT COMMENT '販売者 ID',
seller_nick STRING COMMENT '販売者のニックネーム',
seller_star_id BIGINT COMMENT '販売者のスター ID',
shop_id BIGINT COMMENT 'ショップ ID',
shop_name STRING COMMENT 'ショップ名'
)
COMMENT 'トランザクションメンバー情報のファクトテーブル'
PARTITIONED BY (ds STRING COMMENT '日付')
LIFECYCLE 400;
CREATE TABLE IF NOT EXISTS dwd_asale_trd_ord_di
(
order_id BIGINT COMMENT '注文 ID',
pay_order_id BIGINT COMMENT '支払い注文 ID',
pay_status BIGINT COMMENT '支払いステータス:1: 未払い、2: 支払い済み、3: 返金済み',
succ_time STRING COMMENT 'トランザクション終了時刻',
item_id BIGINT COMMENT '商品 ID',
item_quantity BIGINT COMMENT '購入商品数量',
confirm_paid_amt DOUBLE COMMENT '受領確認済み商品の総収益',
logistics_id BIGINT COMMENT '物流注文 ID',
mord_prov STRING COMMENT '受取人の省',
mord_city STRING COMMENT '受取人の市',
mord_lgt_shipping BIGINT COMMENT '配送方法:1: 普通郵便、2: 速達便、3: EMS',
mord_address STRING COMMENT '受取人の住所',
mord_mobile_phone STRING COMMENT '受取人の携帯電話番号',
mord_fullname STRING COMMENT '受取人名',
buyer_nick STRING COMMENT '購入者のニックネーム',
buyer_id BIGINT COMMENT '購入者 ID'
)
COMMENT 'トランザクション注文情報のファクトテーブル'
PARTITIONED BY (ds STRING COMMENT '日付')
LIFECYCLE 400;次のステップ
これらのファクトテーブルの上に DWS レイヤーを構築し、BI ツール用の集計サマリーを作成します。
エンドツーエンドのモデリングガイドラインについては、データウェアハウス構築ガイドをご確認ください。