Hologres：Hologres開發規範

數倉分層

資料倉儲以分層建設為主包含如下幾類分層，其中CDM包含DWD、DWS、DIM。在Hologres中通過Schema隔離不同的分層。

• ODS（Operational Data Store）：操作資料層

• CDM（Common Data Model）：公用維度模型層

  • DWD（Data Warehouse Detail）：詳細資料層

  • DWS（Data Warehouse Summary）：摘要資料層

  • DIM（Dimension）：維度資料層

• ADS（Application Data Service）：應用資料層

不同公司可根據業務的複雜程度選擇適當的顆粒度，如一個公司存在多個BU（Business Unit），則以BU縮寫作為Schema的首碼。

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}。

表命名規範

Table Group命名規範

若是業務需要建立多個Table Group，命名可以採取${bu}_{數倉分層名}_{業務定義}_tg的規範。

視圖命名規範

持久化視圖命名規則與樣本如下。

• 規則

  • DWS：${bu}_dws.資料域_資料粒度縮寫_業務過程_[{自訂詞根}]_統計時間周期_v。

  • ADS：${bu}_ads.業務域_維度_[{自訂詞根}]_{重新整理周期標識}_v。

• 樣本

  taobao_dws.trd_byr_itm_ord_cm_v

外表命名規範

在原有MaxCompute表名基礎下加ext尾碼，具體樣本如下。

taobao_dim.camp_ext

暫存資料表命名規範

在原有表名基礎下加tmp首碼及數字序號尾碼，具體樣本如下。

taobao_dim.tmp_camp_01

常用縮寫詞

內表規範

建立表之前必須按照資料模型規範確定表和欄位的命名，並根據需求確認表的生命週期，為表和欄位添加完整注釋，相關規範如下。

• 強控規範（如不符合則不允許發布）：

  • 輸出的表與欄位需包含Comment，適用於全平台資料研發操作環境，表的Comment應確保描述資訊簡練、清晰。

  • 建表語句中需包含有表的生命週期（time_to_live_in_seconds）。

  • 建表語句需帶有分布鍵索引（distribute_key），分部鍵選擇原則如下。

    足夠分散、最常JOIN或者GROUP BY的欄位。例如買家商品表，可以設定user_id和item_id，但如果常關聯的KEY為user_id，則分布鍵設定user_id而非user_id和item_id。

  • 進行關聯查詢的表需要建立在同一個Table Group中。

  • 同一個實體ID，在所有事實表和維表中保持名稱和資料類型一致，比如交易表中使用者ID為user_id，在維表中也為user_id，而不能是uid，同時資料類型保持一致，減少資料類型的轉換。

  • 所有物理表的分區欄位預設使用ds表示。

• 建議規範：

  • 建表語句應當帶有bitmap_columns、segment_key、cluster_key任意之一。

  • 在不明確欄位基數情況下，不建議設定建表屬性dictionary_encoding_columns（字典索引），您可調用如下內容將屬性置空。

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

  • 建表屬性orientation（資料存放區格式）建議使用column，可以設定為row。

    說明

    除非明確該表的查詢能夠始終指定所有的primary key（等於或者in），否則盡量不要使用row，不設定時預設是用column儲存。

  • 建表屬性bitmap_columns（位元編碼），bitmap可以對隱藏檔內部的資料進行快速過濾。

    • 建議把filter條件的資料建成bitmap_columns，預設情況下會將所有的TEXT欄位設定。

    • 不建議枚舉值過多的欄位，比如user_id，建議活動ID這類指標設定為bitmap_columns。

  • 建表屬性event_time_column需用在與即時寫入有關的欄位上，例如事件時間戳記。

  • 建表屬性clustering_key聚簇索引，Hologres會在聚簇索引上對資料進行排序，建立聚簇索引能夠加速在索引列上的range和filter查詢，僅能設定一組。對於範圍過濾適用，比如gmv分檔時。

MaxCompute外表規範

Hologres支援通過外表對MaxCompute進行加速查詢，可簡化資料同步的流程。為了提升計算效能，非必要情境不建議您使用內表與外表關聯。為更好的管理和維護外表，請遵循如下規範。

• 強控規範：您需嚴格按照外表命名規範，在原有的MaxCompute表名基礎下增加ext尾碼。

• 建議規範：

  • 保留外表的DDL，做好版本之間的管理。

  • 不建議內表與外表關聯使用，建議採用外表同步至內表的方式。

視圖規範

• 強控規範：您需嚴格按照視圖命名規範。

• 建議規範：

  • 建議您開啟任務調度，保障後續開發作業依賴鏈路完整。

  • 建議不同粒度的視圖單獨建立，避免綜合請求計算量過大。

    例如，cw、cm、nd、1d等，可分別建立4個視圖。如存在分端，則建立pc、wap、app。如分採集方式，可以分ut和非ut。

生命週期（僅限內表）規範

建議規範：

若是有分區表，建議按照即時任務寫入當天分區，並且按照數倉分層設定合適的TTL，且更新的歷史資料不應該寫入已經超過TTL設定的分區。

Table Group規範（可選）

欄位類型規範

欄位類型需嚴格按照如下要求進行建立。

基礎資料型別 (Elementary Data Type)參考

目前，Hologres資料類型與PostgreSQL資料類型相容，但支援的資料類型是PostgreSQL的一個子集。詳細欄位類型及MaxCompute映射，請參見資料類型匯總。

貨幣單位及精度

貨幣單位統一為美元。除非模型有特殊說明，否則金額相關的資料不做任何四捨五入操作，以免後續匯總計算中造成不同口徑的匯總結果不一致。

強控規範：

• SQL最外層及子查詢內層不需要計算的欄位禁止使用select *操作，所有操作必須明確指定列名。

• Where條件中空欄位和Null 字元串要進行必要的Coalesce處理。

建議規範：

• 常採用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操作歷史分區，避免資料指標大起大落。