表的限制項
表(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萬。
分區數量和數據量建議
在計算的時候可以使用分區裁剪是分區的優勢。
建議單個分區中數據量不要太大，如可以單個分區中數據在1萬條，但是建了5萬個分區。
應儘量避免分區數據傾斜，單個表不同分區的數據量差異查過100萬以上。
做分區設計時應合理規劃分區個數，較細粒度的分區在跨分區掃描時會影響到SQL的執行性能。
單個分區中數據量較大的情況下，MaxCompute執行任務時會做分片處理不影響分區裁剪的優勢。
單個分區中文件數較多時，會影響MaxComputeInstance數量，造成資源浪費和SQL性能的影響。
採用多級分區，先按日期分區，然後按交易類型分區。
拆表，一種交易類型就獨立成一張表，再每張表按日期分區。
維度表不做分區。