MaxCompute 表(Table)設計規范

表的限制項
表(Table)設計規范表設計主要目標
- 分區字段和普通字段的選擇
- 分區字段定義依據
- 分區個數定義依據
- 分區數量和數據量建議
- 按數據分層規范數據生命周期
- 按數據的變更和歷史規范數據的保存
- 表設計的影響
- 表設計步驟
- 表數據存儲規范
- 數據導入通道與表設計
- 分區設計與邏輯存儲的對應
- 表和分區設計基本規則
- 分區設計

表的限制項

表(Table)設計規范表設計主要目標

降低存儲成本。合適的表設計可以在數據分層設計上降低冗余存儲，減少中間表數據量大小。同時正確的對表數據進行生命周期管理，更能夠直接降低存儲的數據量以降低存儲成本。
降低計算成本。對表設計規范化，以便在后續對表數據進行查詢計算過程中，可以依據這些規范優化數據的讀取，減少計算過程中的冗余讀寫和計算，提升計算性能的同時降低成本。
降低維護復雜度。規范化的表分層設計能夠直接體現業務的特點。如通過對數據通道中數據采集方式進行優化，同時對表進行規范化設計，可以減少分布式系統中小文件的問題，同時也減少表和分區維護的數量等復雜度。

表設計的影響

影響的操作:表創建/入數據/表更新/表刪除/表管理。導入數據場景(區分要做實時數據采集還是離線批量數據寫入):

導入即查詢與計算。
多次導入，定時查詢與計算。
導入后生成中間表進行計算。
注意:
合理的表設計和數據集成周期管理能夠使數據在存儲期間降低成本。 - MaxCompute優先作為批量數據集成庫以及按業務邏輯進行計算，如按照分區進行計算。
導入后立即查詢與計算，需要考慮每次導入數據量，減少流式小量數據導入。
不合理的數據導入及存儲(小文件)會對整體存儲性能，計算性能，運維穩定性造成影響。

表設計步驟

確定所屬項目空間，依據業務過程規劃表類型，屬于哪個數據層次。
定義表描述，權限定義與Owner定義。
依據數據量、數據集成特點定義分區表或者非分區表。
定義字段，或分區字段
表創建/表轉換
明確導入數據場景的相關因素(包括批量數據寫入/流式數據寫入/條式數據插入)。
定義表和分區數據生命周期。

注意:

表創建之后可以依據業務變化進行表schema的修改，如設置生命周期，RangeClustering。
在設計階段需要特別注意區分數據的場景(批量數據寫入/流式數據寫入/周期性條式數據插入)。
合理使用非分區表和分區表。日志表，事實表，原始采集表等建議使用分區表，按照時間分區。
注意各種表和分區的限制條件。

表數據存儲規范

按數據分層規范數據生命周期

源表ODS層: 每天從業務系統同步過來的數據，全部保留，生命周期定義永久保存。以防備下游數據受損時可以從ODS恢復。若ODS每天同步過來的是全量表，可以通過全表拉鏈的方式來壓縮存儲。
數據倉庫(基礎)層: 至少保留一份完整的全量數據(不必像ODS那樣冗余多份全量)。考慮到性能因素，可以考慮拆表或者做分區。
數據集市層: 按需保留1~3年時?。數據集市的數據較容易生成，無需保留那么?時間的歷史數據

按數據的變更和歷史規范數據的保存

會變化數據怎么存:

客戶屬性、產品屬性天天變，將這些屬性的歷史變化情況記錄下來，以方便追溯某個時點的值。
在事實表里面冗余維表的字段，即把”事件發生時“的各種維度屬性值與該事件綁定起來。比較方便使用者，不需關聯多張表就可以用數據，在數據應用層使用。
用拉鏈表或者日快照的形式，記錄維表的變化情況。比較方便數據加工者，數據結構靈活，擴展方便，容易管理，且數據一致性更好。在數據基礎層使用。

數據導入通道與表設計

通道類型:

Datahub ，規劃寫入的分區以及寫入流量的關系，做到64M commit一次。
數據集成或DataX，規劃寫入的表分區的頻率，做到64M commit一次，避免commit空目錄。 DTS，規劃寫入的表存量分區與增量分區的關系，做commit頻率設置。
Console (Run SQL or Tunnel upload)，避免高頻小數據量文件的插入或者上傳。
SDK Run Sql之insert into，對表或者分區上傳時需要注意插入到分區后進行小文件整理操作，避免對一個分區或者非分區表插入多次，插入后需要merge。

注意:

MaxCompute導入數據的通道只有Tunnel SDK或者執行SQL的Insert into，避免流式插入。
以上各通道本身均有自身邏輯進行流式數據寫入，批量數據寫入，周期調度寫入。
數據通道寫表或分區時需要注意將一次寫入的數據量控制在合理的值如64M以上。

分區設計與邏輯存儲的對應

如上圖，表一共m 個一級分區，每個一級分區都會按時間存儲二級分區，每個二級分區都會存儲所有的列。對分區進行設計的注意事項:

分區限制數量上限。
避免每個分區中只有少量數據。
按照分區條件查詢和計算。
避免每個分區中多次數據寫入。

表和分區設計基本規則

所有的表、字段名要使用統一的命名規范。
- 要能夠區分該表的業務類型。
- 要能夠區分該表是“事實表”或“維度表”，“日志表”，“極限存儲表”(待發布功能)。
- 要能夠區分該表的實體信息。
不同表中具有相同業務含義的字段要定義統一的數據類型:
- 避免不必要的類型轉換。
分區設計及使用一般規則:
- 支持新增分區，不支持新增分區字段。
- 單表支持分區數量為6萬。
- 對于多級分區的表，如果想添加新的分區，必須指明全部的分區值。
- 不支持修改分區列列名，只能修改分區列對應的值。修改多級分區的一個或者多個分區值，多級分區的每一級的分區值都必須寫上。

分區設計

分區字段和普通字段的選擇

分區字段的作用:

方便數據的管理。
劃分數據掃描范圍。
創建表的時候，可以設置普通字段和分區字段。在絕大多數情況下，可以把普通字段理解成數據文件的數據，而分區字段可以理解成文件系統的目錄。表的存儲空間的占用是普通字段的空間占用。分區列雖然不直接存儲數據，但是如同文件系統里的目錄，方便數據管理，同時在計算時若指定具體的分區，計算過程中只查詢對應分區，從而減少計算輸入量。分區表的分區列的個數不能超過6級，也可以理解成底層存儲數據的目錄層數不能超過6層。對分區表設置合適的生命周期，可以按照分區細粒度做到對部分數據進行周期管理。

注意:

可以從數據管理范圍和常用的數據掃描范圍考慮將對應字段設置成分區字段。
對于不具備規律或者類型數量大于10000且不經常作為查詢條件的字段設置成普通字段。

分區字段定義依據

按優先級高低排序:

區列的選擇應充分考慮時間因素，盡量避免對于存量分區進行更新。
如果有多個事實表(不包括維度表)進行join，查詢條件where范圍的列作為分區列。選
擇group by 或distinct 包含的列作為分區列。
選擇值分布均勻的列，不要選擇分區傾斜的列作為分區列。
常用SQL包含某列的等值或in查詢條件，選擇該列作為分區列。

例如:

Select?...?from?table?where?id=123?and?....;

分區個數定義依據

時間分區:可按天進行分區或者按月進行分區，如按照小時進行分區，二級分區平均數量不應大于8 個。
地域分區:省，市，縣進行分區，考慮進行多級分區。23個省，5個自治區，4個直轄市，2個特別行政區;50個地區(州、盟);661個市，其中:直轄市4個;地級市283個;縣級市374個;1636個縣(自治縣、旗、自治旗、特區和林區)，按照最細粒度縣級進行分區后更細粒度不應再按照小時進行分區。
單分區下的數據建議64M數據提交一次。如果為多級分區，保證每個最細粒度級分區下的二級分區的數據都是按照這個規則。
單表分區數(包括下級分區)不能超過6萬。