Hologres:Hologres を使用した開発のベストプラクティス

データウェアハウス階層

データウェアハウスは通常、階層的に構築されます。主な階層は以下の通りです。共通データモデル (CDM) 階層には、データウェアハウス詳細 (DWD)、データウェアハウスサマリー (DWS)、およびディメンション (DIM) 階層が含まれます。Hologres では、スキーマを使用して異なる階層を分離できます。

• オペレーショナルデータストア (ODS)：オペレーショナルデータ層。

• 共通データモデル (CDM)：パブリックディメンションモデル層。

  • データウェアハウス詳細 (DWD)：詳細データ層。

  • DWS (データウェアハウスサマリー)：データウェアハウスサマリー。

  • ディメンション (DIM)：ディメンションデータ層。

• アプリケーションデータサービス (ADS)：アプリケーションデータ層。

ビジネスの複雑さに応じて、適切な粒度を選択できます。たとえば、企業に複数の業務部門 (BU) がある場合、BU の略語をスキーマのプレフィックスとして使用できます。

create schema ${bu}_ads;
create schema ${bu}_ads_dev;
create schema ${bu}_dwd;
create schema ${bu}_dwd_dev;
create schema ${bu}_dws;
create schema ${bu}_dws_dev;
create schema ${bu}_dim;
create schema ${bu}_dim_dev;
create schema ${bu}_ods;
create schema ${bu}_ods_dev;

データドメインの略語

異なるデータドメインの共有コードを定義して、全社的な標準を確立します。以下の表にいくつかの例を示します。

ジョブの命名規則

命名規則は、内部タスクと同期タスクで異なります。規則は以下の通りです。

• 内部 SQL タスク (非同期タスク)：holo_{target_table_name}。このフォーマットは、外部テーブルタスクと区別するためのものです。

• Hologres へのデータインポート：{source}2holo_{target_table_name}。

• Hologres からのデータエクスポート：holo2{target}_{target_table_name}。

テーブルの命名規則

テーブルグループの命名規則

ビジネスで複数のテーブルグループが必要な場合は、次の形式で名前を付けます：${bu}_{data_warehouse_layer_name}_{business_definition}_tg。

ビューの命名規則

次のセクションでは、永続ビューの命名規則と例を示します。

• 規則

  • DWS：${bu}_dws.data_domain_data_granularity_abbreviation_business_process_[{custom_root}]_statistical_period_v。

  • ADS：${bu}_ads.business_domain_dimension_[{custom_root}]_{refresh_period_identifier}_v。

• 例

  taobao_dws.trd_byr_itm_ord_cm_v

外部テーブルの命名規則

元の MaxCompute テーブル名に ext サフィックスを追加します。次のコードに例を示します。

taobao_dim.camp_ext

一時テーブルの命名規則

元のテーブル名に tmp プレフィックスと数字のサフィックスを追加します。次のコードに例を示します。

taobao_dim.tmp_camp_01

一般的な略語

内部テーブルの標準

テーブルを作成する前に、データモデル標準に従ってテーブルとそのフィールドの名前を決定します。また、要件に基づいてテーブルのライフサイクルを確認し、テーブルとそのフィールドに完全なコメントを追加する必要があります。関連する標準は以下の通りです。

• 厳格な標準 (これらの標準が満たされていない場合、公開は許可されません)：

  • 出力テーブルとそのフィールドにはコメントを含める必要があります。この規則は、プラットフォーム上のすべてのデータ開発シナリオに適用されます。テーブルのコメントは簡潔で明確でなければなりません。

  • テーブル作成ステートメントでは、テーブルのライフサイクル (time_to_live_in_seconds) を指定する必要があります。

  • テーブル作成ステートメントでは、分散キー (distribute_key) を指定する必要があります。分散キーを選択するための原則は以下の通りです。

    十分に分散され、JOIN または GROUP BY 操作で最も頻繁に使用されるフィールドを選択します。たとえば、購入者-アイテムテーブルの場合、user_id と item_id を分散キーとして設定できます。ただし、user_id が結合で最も頻繁に使用されるキーである場合は、分散キーを user_id と item_id の両方ではなく、user_id のみに設定します。

  • クエリで結合されるテーブルは、同じテーブルグループに作成する必要があります。

  • すべてのファクトテーブルとディメンションテーブルで、同じエンティティ ID に同じ名前とデータ型を使用します。たとえば、トランザクションテーブルのユーザー ID が user_id の場合、ディメンションテーブルでも uid ではなく user_id でなければなりません。データ型の変換を減らすために、データ型の一貫性を保ちます。

  • デフォルトでは、すべての物理テーブルのパーティションフィールドとして ds を使用します。

• 推奨標準：

  • テーブル作成ステートメントでは、bitmap_columns、segment_key、または cluster_key のうち、少なくとも 1 つのプロパティを指定する必要があります。

  • フィールドのカーディナリティが不明な場合は、dictionary_encoding_columns (辞書インデックス) テーブルプロパティを設定しないでください。次のステートメントを実行して、プロパティを空に設定できます。

    call set_table_property('table_name', 'dictionary_encoding_columns','')

  • orientation (データストレージフォーマット) テーブルプロパティには、column フォーマットを推奨します。このプロパティを row に設定することもできます。

    説明

    テーブルに対するすべてのクエリで、常にすべての primary key 列を equals または in 演算子を使用して指定できることを確認できない限り、row フォーマットを使用しないでください。このプロパティが設定されていない場合、デフォルトで column ストレージフォーマットが使用されます。

  • bitmap_columns (ビットエンコーディング) テーブルプロパティは、bitmap を有効にして、ストレージファイル内のデータを迅速にフィルタリングします。

    • bitmap_columns を filter 条件で使用されるフィールドに設定します。デフォルトでは、すべての TEXT フィールドが含まれます。

    • user_id のようなカーディナリティの高いフィールドを bitmap_columns として設定しないでください。アクティビティ ID などのメトリックを bitmap_columns として設定することを推奨します。

  • event_time_column テーブルプロパティは、イベントタイムスタンプなど、リアルタイム書き込みに関連するフィールドに使用する必要があります。

  • clustering_key (クラスターインデックス) テーブルプロパティは、指定されたクラスターインデックスに基づいてデータをソートします。クラスターインデックスを作成すると、インデックス列に対する range および filter クエリを高速化できます。クラスターインデックスは 1 つだけ設定できます。このプロパティは、GMV をバケット化する場合など、範囲フィルタリングに適しています。

MaxCompute 外部テーブルの標準

Hologres は、外部テーブルを介して MaxCompute のクエリを高速化し、データ同期プロセスを簡素化できます。コンピューティングパフォーマンスを向上させるために、必要でない限り、内部テーブルと外部テーブルを結合しないでください。外部テーブルをより適切に管理および保守するには、これらの標準に従う必要があります。

• 厳格な標準：元の MaxCompute テーブル名に ext サフィックスを追加して、外部テーブルの命名規則に厳密に従う必要があります。

• 推奨標準：

  • テーブルスキーマの DDL を保持し、バージョン管理下に置きます。

  • 内部テーブルと外部テーブルを結合しないでください。代わりに、外部テーブルから内部テーブルにデータを同期します。

標準を表示

• 厳格な標準：ビューの命名規則に厳密に従う必要があります。

• 推奨標準：

  • タスクスケジューリングを有効にして、後続の開発ジョブの依存関係チェーンの整合性を確保します。

  • 複雑なリクエストによる過剰な計算を避けるために、異なる粒度に対して個別のビューを作成します。

    たとえば、cw、cm、nd、および 1d に対して 4 つの個別のビューを作成できます。異なるクライアントがある場合は、pc、wap、および app のビューを作成できます。異なる収集方法を使用する場合は、ut と非 ut に分けることができます。

ライフサイクル (内部テーブルのみ) の標準

推奨標準：

パーティションテーブルの場合、リアルタイムタスクデータを当日のパーティションに書き込みます。データウェアハウス階層に基づいて適切な TTL を設定します。TTL を既に超えているパーティションに更新された履歴データを書き込まないでください。

テーブルグループの標準 (オプション)

フィールドタイプの標準

フィールドタイプは、次の要件に厳密に従って作成する必要があります。

基本データ型のリファレンス

Hologres のデータ型は PostgreSQL のデータ型と互換性がありますが、Hologres はその一部のみをサポートしています。フィールドタイプと MaxCompute とのマッピングの詳細については、「データ型サマリー」をご参照ください。

通貨単位と精度

通貨単位は USD です。モデルで特に指定されていない限り、金額関連のデータを丸めないでください。この方法は、異なる統計方法を使用する集計計算での不整合を防ぎます。

厳格な標準：

• SQL ステートメントの最外層およびサブクエリ内では、計算を必要としないフィールドに対して select * を使用しないでください。すべての操作で列名を明示的に指定する必要があります。

• WHERE 句では、Coalesce 関数を使用して null フィールドと空の文字列を処理する必要があります。

推奨標準：

• 頻繁に使用する count distinct フィールドを distribution_key として使用します。複数の count distinct 操作の組み合わせについては、ステートメントを手動で書き換える必要があります。

  select count(distinct userid)
       , count(distinct case when stat_date = '20201111' then userid end) 
  from t group by cate_id;
  
  --次のように書き換えます
  select count(1), sum(c) from 
  (
    select userid
         , cate_id
         , cast(count(case when stat_date = '20201111' then 1 end) > 0) as c 
    from t 
    group by cate_id, userid
  ) t1 
  group by cate_id;

• オフラインスケジューリングタスクの場合、パーティションテーブルに対して analyze table 操作を実行します。

• 長期的な使用シナリオでは、ATTACH/DETACH 操作を使用して履歴パーティションに対するバッチ操作を行い、データメトリックの急激な変動を回避します。