MaxCompute 表(Table)設計規範

• 表的限制項

• 表(Table)設計規範 表設計主要目標

  • 表設計的影響
  • 表設計步驟

  • 表數據存儲規範

    • 按數據分層規範數據生命週期
    • 按數據的變動和歷史規範數據的保存
  • 數據導入通道與表設計
  • 分區設計與邏輯存儲的對應
  • 表和分區設計基本規則

  • 分區設計

    • 分區字段和普通字段的選擇
    • 分區字段定義依據
    • 分區個數定義依據
    • 分區數量和數據量建議

表的限制項

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

• 下降存儲成本。 合適的表設計能夠在數據分層設計上下降冗餘存儲，減小中間表數據量大小。同時正 確的對錶數據進行生命週期管理，更可以直接下降存儲的數據量以下降存儲成本。
• 下降計算成本。 對錶設計規範化，以便在後續對錶數據進行查詢計算過程當中，能夠依據這些規範優化 數據的讀取，減小計算過程當中的冗餘讀寫和計算，提高計算性能的同時下降成本。
• 下降維護複雜度。 規範化的表分層設計可以直接體現業務的特色。如經過對數據通道中數據採集方式 進行優化，同時對錶進行規範化設計，能夠減小分佈式系統中小文件的問題，同時也減小表和分區維 護的數量等複雜度。

表設計的影響

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

• 導入即查詢與計算。
• 屢次導入，定時查詢與計算。
• 導入後生成中間表進行計算。
  注意:
• 合理的表設計和數據集成周期管理可以使數據在存儲期間下降成本。 - MaxCompute優先做爲批量數據集成庫以及按業務邏輯進行計算，如按照分區進行計算。
• 導入後當即查詢與計算，須要考慮每次導入數據量，減小流式小量數據導入。
• 不合理的數據導入及存儲(小文件)會對總體存儲性能，計算性能，運維穩定性形成影響。

表設計步驟

1. 肯定所屬項目空間，依據業務過程規劃表類型，屬於哪一個數據層次。
2. 定義表描述，權限定義與Owner定義。
3. 依據數據量、數據集成特色定義分區表或者非分區表。
4. 定義字段，或分區字段
5. 表建立/錶轉換
6. 明確導入數據場景的相關因素(包括批量數據寫入/流式數據寫入/條式數據插入)。
7. 定義表和分區數據生命週期。

注意:

• 表建立以後能夠依據業務變化進行表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性能的影響。
• 採用多級分區，先按日期分區，而後按交易類型分區。
• 拆表，一種交易類型就獨立成一張表，再每張表按日期分區。
• 維度表不作分區。