MaxCompute:ディメンションデータレイヤー

受領確認のビジネスプロセスでは、商品と受領場所の2つの観点からディメンションを定義できます。 このチュートリアルでは、各製品が同じ場所で購入および受領されることを前提としています。 製品の観点から、次のディメンションを定義できます。

• プロダクトID

• プロダクト名

• プロダクト価格

• プロダクトステータス

  0: 新しい; 1: アイドル; 2: 中古

• プロダクトカテゴリID

• プロダクトカテゴリ名

• 商品 ID

• 商品名

• プロダクトの販売ステータス:

  0: 正常; 1: 削除される; 2: 棚から取られる; 3: 決して棚に置かない

• プロダクトの市

• プロダクトの県

受領場所の観点から、次のディメンションを定義できます。

• 都市コード

• 都市名

• 県コード

• 県名

ディメンションを定義した後、データを補足してディメンションテーブルを生成できます。 ディメンションテーブルを設計するときは、次の提案に注意してください。

• 各ディメンションテーブルのサイズを1,000万個以下のデータエントリに制限します。

• MAPJOINを使用してディメンションテーブルを他のテーブルに結合します。

• ディメンションテーブルの頻繁な更新は避けてください。

ディメンションテーブルを設計するときは、次の点を考慮する必要があります。

• ディメンションテーブルのデータの安定性。

  例えば、会社Aの電子商取引メンバーデータは、通常、期限切れにならないが、データは、いつでも更新され得る。 この場合、完全なメンバーデータを格納するパーティションを作成する必要があります。 一部のデータエントリが更新されない場合は、履歴テーブルと日次テーブルを作成する必要があります。 デイリーテーブルは、現在有効なデータエントリを格納し、テーブルデータを適切なサイズに保つために使用されます。 履歴テーブルでは、有効期限に基づいて対応するパーティションにデータが挿入されます。 各パーティションは、対応する時間に満了するデータエントリを格納する。

• 垂直分割が必要かどうか。

  ディメンションテーブルに未使用の属性が多数含まれている場合、またはテーブルに含まれる属性フィールドが多すぎるためにデータクエリが遅くなる場合は、フィールドを分割して複数のディメンションテーブルを作成する必要があります。

• 水平分割が必要かどうか。

  一部のデータエントリが他のデータエントリと異なる場合は、ディメンションテーブルを複数のテーブルに分割したり、マルチレベルパーティションを設計したりできます。

• データクエリの時間制限。

  一般に、コアディメンションテーブルに関するデータクエリの実行時間は厳密に制限されます。

ディメンションテーブルを設計するには、次の手順を実行します。

1. 最初にディメンションを定義し、ディメンションの一致を保障して下さい。

2. このチュートリアルで使用するスタースキーマの中央ファクトテーブルを構成するプライマリディメンションテーブルを指定します。 運用データストア (ODS) テーブルであるプライマリディメンションテーブルは、関連するビジネスシステムからのデータを直接同期します。 たとえば、s_auctionテーブルは、製品に関する情報を記録し、フロントエンド製品センターシステムからのデータを同期します。 このテーブルはプライマリディメンションテーブルです。

3. 関連するディメンションテーブルを指定します。 データウェアハウスは、ソースビジネスシステムのデータを集約します。 異なるビジネスシステムまたは同じビジネスシステム内のディメンションテーブルが関連付けられます。 ビジネスロジックの分析に基づいて、プライマリディメンションテーブルに関連付けるテーブルを指定し、ディメンション属性を生成するテーブルの一部を選択します。 例えば、製品ディメンションは、カテゴリ、販売者、およびショップなどのディメンションに関連付けられる。

4. ディメンション属性を2つのフェーズで指定します。 最初のフェーズでは、ディメンション属性を選択するか、プライマリディメンションテーブルから新しいディメンション属性を生成します。 2番目のフェーズでは、ディメンション属性を選択するか、関連するディメンションテーブルから新しいディメンション属性を生成します。 例えば、ディメンション属性を選択するか、または主要ディメンションテーブルs_auctionおよびカテゴリ、販売者、および店舗寸法に関する関連寸法テーブルから製品ディメンションに対する新しいディメンション属性を生成する。 ディメンション属性から、次のディメンションを定義できます。

   • できるだけ多くのディメンション属性を生成します。

   • できるだけ多くの意味のある説明を提供します。

   • 数値属性とファクトを区別します。

   • できるだけ多くの一般的なディメンション属性を見つけます。

DIMレイヤーでのディメンションテーブルの命名規則は、dim_{Abbreviated business unit/pub }_{ Abbreviated dimension}[_{Abbreviated custom table tag}] です。 命名規則では、pubは、ディメンションが特定のビジネスユニットとは無関係であり、時間ディメンションなどの各ビジネスユニットで共有できることを示します。 設定例：

• 地域共通情報のテーブル: dim_pub_area

• A社のeコマースマーケティング事業部門における完全な製品の表: dim_asale_itm

このチュートリアルでは、次のステートメントを使用して、DIMレイヤーでディメンションテーブルを作成できます。

CREATE TABLE IF NOT EXISTS dim_asale_itm
(
    item_id BIGINT COMMENT 'Product ID',
    item_title STRING COMMENT 'Product name',
    item_price DOUBLE COMMENT 'Product price in RMB',
    item_stuff_status BIGINT COMMENT 'Product status: 0: new; 1: idle; 2: second-hand',
    cate_id BIGINT COMMENT 'Product category ID',
    cate_name STRING COMMENT 'Product category name',
    commodity_id BIGINT COMMENT 'Commodity ID',
    commodity_name STRING COMMENT 'Commodity name',
    item_status BIGINT COMMENT 'Product sales status: 0: normal; 1: deleted; 2: taken off the shelf; 3: never put on the shelf',
    city STRING COMMENT 'City of the product',
    prov STRING COMMENT 'Province of the product',
)
COMMENT 'Table of full products'
PARTITIONED BY (ds STRING COMMENT 'Date: yyyymmdd');

CREATE TABLE IF NOT EXISTS dim_pub_area
(
    city_code STRING COMMENT 'City code',
    city_name STRING COMMENT 'City name',
    prov_code STRING COMMENT 'Province code',
    prov_name STRING COMMENT 'Province name',
)
COMMENT 'Table of common regional information'
PARTITIONED BY (ds STRING COMMENT 'Date: yyyymmdd')
LIFECYCLE 3600;