數倉建設七大規範指南

一、數據模型架構規範

 

1.數據層次的劃分

 

• ODS：Operational Data Store，操作數據層，在結構上其與源系統的增量或者全量數據基本保持一致。它相當於DW數據的一個數據準備區，同時又承擔着基礎數據的記錄以及歷史變化。其主要作用是把基礎數據引入到DMP。

 

• CDM：Common Data Model，公共維度模型層，又細分爲DWD和DWS。它的主要作用是完成數據加工與整合，建立一致性的維度，構建可複用的面向分析和統計的明細事實表，以及彙總公共粒度的指標。

• DWD：Data Warehouse Detail，明細數據層。

• DWS：Data Warehouse Summary，彙總數據層。

 

• ADS：Application Data Service，應用數據層。

 

2.數據劃分及命名空間約定

 

請根據業務劃分數據並約定命名，建議針對業務名稱結合數據層次約定相關命名的英文縮寫，這樣可以給後續數據開發過程中，對項目空間、表、字段等命名作爲重要參照。

 

• 按業務劃分：命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用的ODS project。

• 按數據域劃分：命名時按照CDM層的數據進行數據域劃分，以便有效地對數據進行管理，以及指導數據表的命名。例如，"用戶"數據的英文可定義爲'user'。

• 按業務過程劃分：當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。業務過程是從數據分析角度看客觀存在的或者抽象的業務行爲動作。例如，用戶行爲數據域中的"登錄"這個業務過程的英文縮寫可約定命名爲'user_login'。

 

3.數據模型

 

模型是對現實事物的反映和抽象，能幫助我們更好地瞭解客觀世界。數據模型定義了數據之間關係和結構，使得我們可以有規律地獲取想要的數據。例如，在一個超市裏，商品的佈局都有特定的規範，商品擺放的位置是按照消費者的購買習慣以及人流走向進行擺放的。

 

1）數據模型的作用

 

數據模型是在業務需求分析之後，數據倉庫工作開始時的第一步。良好的數據模型可以幫助我們更好地存儲數據，更有效率地獲取數據，保證數據間的一致性。

 

2）模型設計的基本原則

 

• 高內聚和低耦合：一個邏輯和物理模型由哪些記錄和字段組成，應該遵循最基本的軟件設計方法論中的高內聚和低耦合原則。主要從數據業務特性和訪問特性兩個角度來考慮：將業務相近或者相關的數據、粒度相同數據設計爲一個邏輯或者物理模型；將高概率同時訪問的數據放一起，將低概率同時訪問的數據分開存儲。

 

• 核心模型與擴展模型分離：建立核心模型與擴展模型體系，核心模型包括的字段支持常用核心的業務，擴展模型包括的字段支持個性化或是少量應用的需要。在必須讓核心模型與擴展模型做關聯時，不能讓擴展字段過度侵入核心模型，以免破壞了核心模型的架構簡潔性與可維護性。

 

• 公共處理邏輯下沉及單一：底層公用的處理邏輯應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯在多處同時存在。

 

• 成本與性能平衡：適當的數據冗餘可換取查詢和刷新性能，不宜過度冗餘與數據複製。

 

• 數據可回滾：處理邏輯不變，在不同時間多次運行數據的結果需確定不變。

 

• 一致性：相同的字段在不同表中的字段名必須相同。

 

• 命名清晰可理解：表命名規範需清晰、一致，表命名需易於下游的理解和使用。

 

二、公共規範

 

1.層次調用約定

 

應用層應優先調用DW公共層數據，必須存在中間層數據，不允許應用層跨過中間層從ODS層重複加工數據。一方面，中間層團隊應該積極瞭解應用層數據的建設需求，將公用的數據沉澱到公共層，爲其他團隊提供數據服務；另一方面，應用層團隊也需積極配合中間層團隊進行持續的數據公共建設的改造。必須避免出現過度的ODS層引用、不合理的數據複製以及子集合冗餘。

 

• ODS層數據不能被應用層任務引用，中間層不能有沉澱的ODS層數據，必須通過CDM層的視圖訪問。CDM層視圖必須使用調度程序進行封裝，保持視圖的可維護性與可管理性。

• CDM層任務的深度不宜過大（建議不超過10層）。

• 原則上一個計算刷新任務只允許一個輸出表，特殊情況除外。

• 如果多個任務刷新輸出一個表（不同任務插入不同的分區），調度上需要建立一個依賴多個刷新任務的虛擬任務，通常下游應該依賴此虛擬任務。

• CDM彙總層應優先調用CDM明細層。在調用可累加類指標計算時，CDM彙總層儘量優先調用已經產出的粗粒度彙總層，以避免大量彙總都直接從海量的明細數據層計算。

• CDM明細層累計快照事實表優先調用CDM事務型事實表，以保持數據的一致性產出。

• 避免應用層過度引用和依賴CDM層明細數據，需有針對性地建設好CDM公共彙總層。

 

2.數據類型規範

 

ODS層的數據類型應基於源系統數據類型轉換。如源數據爲MySQL時的轉換規則如下：

 

 

CDM數據公共層如果是引用ODS層數據，則默認使用ODS層字段的數據類型。其衍生加工數據字段按以下標準執行：

 

• 金額類及其它小數點數據使用DOUBLE類型。

• 字符類數據使用STRING類型。

• ID類和整形數值使用BIGINT類型。

• 時間類型數據使用STRING類型（如果有特殊的格式強制要求，可以選擇性使用DATETIME類型）。

• 狀態使用STRING類型。

 

3.公共字段定義規範

 

數據統計日期的分區字段按以下標準：

 

• 按天分區：dt(YYYYMMDD)

• 按小時分區：hh(00-23)

• 按分鐘：mi (00-59)

• is_{業務}：表示布爾型數據字段。"Y","N"表示，不允許出現空值域。

• 原則上不需要冗餘分區字段。

 

4.數據冗餘

 

1）相關數據冗餘

 

一個表做寬表冗餘維度屬性時，應該遵循以下建議準則：

 

• 冗餘字段與表中其它字段高頻率（大於3個下游應用SQL）同時訪問。

• 冗餘字段的引入不應造成其本身的刷新完成時間產生過多後延。

• 公共層數據不允許字段重複率大於60%的相同粒度數據表冗餘，可以選擇在原表基礎上拓寬或者在下游應用中通過JOIN方式實現。

 

2）子集合冗餘

 

當需要從一個集合中冗餘一部分記錄作爲另外一張表存在時，可以優先考慮子分區方式，但多級子分區不應超過（5級）。只有以下情況才考慮冗餘：

 

• 子類型表有較多（大於10）個字段，而父類型表並不存在。

• 子集合的過濾條件會被多次（大於5次）應用。

 

5.數據拆分

 

數據的水平和垂直拆分是按照訪問熱度分佈和數據表"非空或者0值"的數據值在行列二維空間上分佈情況進行劃分的。

 

• 在物理上劃分核心模型和擴展模型，將其字段進行垂直劃分。

• 將訪問相關度較高的列在一個表存儲，將訪問相關度較低的字段分開存儲。

• 將經常用到的where條件按記錄行進行水平切分或者冗餘；水平切分可以考慮二級分區手段，以避免多餘的數據複製與冗餘。

• 將出現大量空值和零值的統計彙總表，依據其空值和零值分佈狀況可以做適當的水平和垂直切分，以減少存儲和下游的掃描數據量。

 

6.空值處理原則

 

• 彙總類指標的空值：空值處理，填充爲零，當前DMP基於列存儲的壓縮技術不會由於填充大量空值導致存儲成本上升。

• 維度屬性值爲空：在彙總到對應維度上時，對於無法對應的統計事實，記錄行會填充爲-99（未知），對應維表會出現一條-99（未知）的記錄。

 

7.數據倉庫中表格的命名規範

如下表所示：

 

 

三、數據存儲及生命週期管理規範

 

 

數據質量規範

 

• 每個ODS全量表必須配置唯一性字段標識。

• 每個ODS全量表必須做分區空數據監控。

• 建議對重要表的重要枚舉類型字段做枚舉值變化及枚舉值分佈監控。

• 建議對ODS表的數據量及數據記錄數設置上週同比無變化監控，用於監控源系統是否下線或者已遷移。

• 只有有監控要求的表才創建數據質量管控層，應由DMP的數據質量配置完成。

• 每個ODS層全表都必須要有註釋。

 

四、CDM公共維度層設計規範

 

1.設計準則

 

1）一致性維度規範

 

公共層的維度表中相同維度屬性在不同物理表中的字段名稱、數據類型、數據內容必須保持一致。除了以下特例：

 

• 在不同的實際物理表中，如果由於維度角色的差異，需要使用其他的名稱，其名稱也必須是規範的維度屬性的別名。比如：定義一個標準的用戶ID時，如果在一個表中，分別要表示正式用戶ID，訪客ID，那麼設計規範階段就預先對用戶ID分別定義正式用戶ID和訪客ID。

• 如果由於歷史原因，在暫時不一致的情況下，必須在規範的維度定義一個標準維度屬性，不同的物理名也必須是來自標準維度屬性的別名。

 

2）維度的組合與拆分

 

①組合原則

 

• 將維度所描述業務相關性強的字段在一個物理維表實現，相關性一般指：經常需要一起查詢、報表展現，比如商品基本屬性和所屬品牌；兩個維度屬性間是否存在天然的關係等。

• 無相關性的維度可以適當考慮雜項維度，比如交易，可以構建一個交易雜項維度收集交易的特殊標記屬性、業務分類等信息。也可以將雜項維度退化在事實表中處理，不過容易造成事實表相對龐大，加工處理較爲複雜。

• 所謂的行爲維度是經過彙總計算的指標，在下游的應用使用時將其當維度處理。如果有需要，度量指標可以作爲行爲維度冗餘到維度表中。

 

②拆分與冗餘

 

• 對於維度屬性過多，涉及源較多的維度表，可以做適當拆分。

• 比如用戶表，建議拆分爲核心表和擴展表。核心表相對字段較少，刷新產出時間較早，優先使用。擴展表字段較多，且可以冗餘核心表部分字段，刷新產出時間較晚，適合數據分析人員使用。

• 根據維度屬性的業務不相關性，將相關度不大的維度屬性拆分爲多個物理表存儲。

 

• 數據記錄數較大的維度表，可以適當冗餘一些子集合，以減少下游掃描數據量：

• 比如用戶表，可以根據當天是否有行爲，產出一個有活躍行爲的相關維表，以減少應用的數據掃描量。

• 可根據所屬業務掃描數據範圍大小的不同，進行適當子集合冗餘。

 

2.表命名規範

 

命名規則：{project_name}.dim{業務/pub}{維度定義}[_{自定義命名標籤}]，所謂的pub是類似與具體業務無關，各個業務部都可以共用，例如時間維度。

 

3.數據存儲及生命週期管理規範

 

CDM公共維度層的表的類型爲維度表，存儲方式爲按天分區。

 

最長存儲保留策略：

 

模型設計者根據自身業務需求設置表的生命週期管理。您可依據3個月內的最大需要訪問的跨度設置保留策略，具體計算方式如下。

 

• 當3個月內的最大訪問跨度小於或等於4天時，建議將保留天數設爲7天。

• 當3個月內的最大訪問跨度小於或等於12天時，建議將保留天數設爲15天。

• 當3個月內的最大訪問跨度小於或等於30天時， 建議將保留天數設爲33天。

• 當3個月內的最大訪問跨度小於或等於90天時，建議將保留天數設爲93天。

• 當3個月內的最大訪問跨度小於或等於180天時， 建議將保留天數設爲183天。

• 當3個月內的最大訪問跨度小於或等於365天時，建議將保留天數設爲368天。

 

五、CDM明細層設計規範

 

1.表命名規範

 

命名規則：{project_name}.dwd{業務縮寫/pub}{數據域縮寫}{業務過程縮寫}[{自定義表命名標籤縮寫}]{刷新週期標識}{單分區增量全量標識}。

 

說明：

 

• pub表示數據包括多個業務的數據。

• 單分區增量全量標識：i表示增量，f表示全量。

 

2.數據存儲及生命週期管理規範

 

CDM明細層的表的類型爲事實表，存儲方式爲按天分區。

 

事務型事實表一般永久保存。週期性快照事實表根據業務需求設置生命週期管理。您可依據3個月內的最大需要訪問的跨度設置保留策略，具體計算方式如下：

 

• 當3個月內的最大訪問跨度小於或等於4天時，建議將保留天數設爲7天。

• 當3個月內的最大訪問跨度小於或等於12天時，建議將保留天數設爲15天。

• 當3個月內的最大訪問跨度小於或等於30天時， 建議將保留天數設爲33天。

• 當3個月內的最大訪問跨度小於或等於90天時，建議將保留天數設爲93天。

• 當3個月內的最大訪問跨度小於或等於180天時， 建議將保留天數設爲183天。

• 當3個月內的最大訪問跨度小於或等於365天時，建議將保留天數設爲368天。

 

3.事務型事實表設計準則

 

事務型事實表主要用於分析行爲與追蹤事件。事務事實表獲取業務過程中的事件或者行爲細節，然後通過事實與維度之間關聯，可以非常方便地統計各種事件相關的度量，比如瀏覽UV，搜索次數等等。

 

• 基於數據應用需求的分析設計事務型事實表，如果下游存在較大的針對某個業務過程事件的分析指標需求，可以考慮基於某一個事件過程構建事務型事實表。

• 事務型事實表一般選用事件發生日期或時間作爲分區字段，這種分區方式可以方便下游的作業數據掃描執行分區裁剪。

• 明細層事實表的冗餘子集的原則能有利於降低上層數據訪問的IO開銷。

• 明細層事實表維度退化到事實表原則能有利於減少上層數據訪問的JOIN成本。

 

4.週期快照型事實表

 

週期快照型事實表主要用於分析狀態型或者存量型事實，快照是指以預定的時間間隔來採樣狀態度量。

 

5.累計快照事實表

 

累計快照事實表是基於多個業務過程聯合分析從而構建的事實表，如採購單的流轉環節等。

 

累計快照事實表主要用於分析事件之間的時間間隔與週期，比如用交易的支付與發貨之間的間隔，來分析發貨速度，或在支付和退款環節分析支付退款率等等；同時也可以用於幫助分析一些少量的、且對刷新時間不是非常敏感的指標統計，比如，在當前事務型事實表不支持，且只有少量的統計指標時，需分析交易的關閉和發貨，就可以基於累計快照事實表進行計算。

 

六、CDM彙總層設計規範

 

1.命名規範

 

命名規則：{project_name}.dws{業務縮寫/pub}{數據域縮寫}{數據粒度縮寫}[{自定義表命名標籤縮寫}]{統計時間週期範圍縮寫}{刷新週期標識}{單分區增量全量標識}。

 

說明：

 

• 關於統計時間週期範圍縮寫，在缺省情況下，離線計算應該包括最近一天（1d）,最近N天（nd）和歷史截至當天(td)三個表，如果出現nd的表的字段過多，需要拆分時，只允許以一個統計週期單元作爲原子拆分，即一個統計週期拆分一個表，比如最近7天(_1w)拆分一個表；不允許拆分出來的一個表存儲多個統計週期的。

• 對於{刷新週期標識}和{單分區增量全量標識}在彙總層不做強制要求。單分區增量全量標識：i：表示增量，f表示全量。

• 對於小時表不管是按天刷新還是按小時刷新, 都用_hh 來表示。

• 對於分鐘表不管是按天刷新還是按小時刷新,都用_mm來表示。

 

2.數據存儲及生命週期管理規範

 

CDM彙總層的表的類型爲事實表，存儲方式爲按天分區。

 

事務型事實表一般永久保存。週期性快照事實表根據業務需求設置生命週期管理。您可依據3個月內的最大需要訪問的跨度設置保留策略，具體計算方式如下：

 

• 當3個月內的最大訪問跨度小於或等於4天時，建議將保留天數設爲7天。

• 當3個月內的最大訪問跨度小於或等於12天時，建議將保留天數設爲15天。

• 當3個月內的最大訪問跨度小於或等於30天時， 建議將保留天數設爲33天。

• 當3個月內的最大訪問跨度小於或等於90天時，建議將保留天數設爲93天。

• 當3個月內的最大訪問跨度小於或等於180天時， 建議將保留天數設爲183天。

• 當3個月內的最大訪問跨度小於或等於365天時，建議將保留天數設爲368天。

 

七、表設計規範

 

DMP中不同類型計算任務的操作對象（輸入、輸出）都是表。表設計是否合理將影響存儲和計算的性能，進而影響到存儲和計算的計費。

 

1.表設計主要目標

 

1）降低存儲成本

 

合理的表設計可以降低數據分層設計上的冗餘存儲，減少中間表的數據量大小。對錶數據的生命週期進行正確地管理，也能夠直接降低存儲的數據量及存儲成本。

 

2)降低計算成本

 

規範化的表設計可以幫助使用者優化數據的讀取，從而減少計算過程中的冗餘讀寫和計算，提升計算性能，降低計算成本。

 

3)降低維護複雜度

 

規範化的表分層設計能夠直接體現業務的特點。例如，在規範化設計表的同時對數據通道中的數據採集方式進行優化，可以減少分佈式系統中小文件的問題，降低表和分區維護的數量等複雜度。

 

2.表設計的影響

 

1）表設計所影響的操作：表創建、入數據、表更新、表刪除、表管理。

 

2）導入數據場景（區分要做實時數據採集還是離線批量數據寫入）：

 

• 導入即查詢與計算

• 多次導入，定時查詢與計算

• 導入後生成中間表進行計算

 

說明：

 

• 合理的表設計和數據集成周期管理能夠降低數據在存儲期間的成本。

• DMP優先計算批量數據集成庫並按業務邏輯進行計算，例如按照分區進行計算。

• 導入後立即查詢與計算，需要考慮每次導入的數據量，減少流式小量數據導入。

• 不合理的數據導入及存儲（小文件）會影響整體的存儲性能、計算性能、運維穩定性。

 

3.表設計步驟

 

• 確定所屬項目空間，依據業務過程規劃表類型，分析數據層次。

• 定義表描述，進行權限定義與Owner定義。

• 依據數據量、數據集成特點定義分區表或非分區表。

• 定義字段或分區字段。

• 進行表創建、錶轉換。

• 明確導入數據場景的相關因素（包括批量數據寫入、流式數據寫入、條式數據插入）。

• 定義表和分區數據生命週期。

 

說明：

 

• 創建完表後，您可以依據業務變化修改表的schema，例如設置生命週期：RangeClustering。

• 在表設計階段，需要特別注意區分數據的場景（批量數據寫入、流式數據寫入、週期性條式數據插入）。

• 合理使用非分區表和分區表。建議採用分區表來設計日誌表、事實表，原始採集表等，並按照時間進行分區。

• 注意各種表和分區的限制條件。

 

4.表數據存儲規範

 

1)按數據分層規範數據的生命週期

 

• 源表ODS層：每天從業務系統同步過來的數據，全部保留，生命週期定義永久保存。當下遊數據受損時，可以從ODS恢復數據。若ODS每天同步過來的是全量表，則可以通過全表拉鍊的方式來壓縮存儲。

• 數據倉庫（基礎）層： 至少保留一份完整的全量數據（不必像ODS那樣存儲冗餘的全量表）。您可以通過拆表或者做分區來提升性能。

• 數據集市層：數據將被按需保留1~3年。數據集市的數據比較容易生成，所以無需保留久遠的歷史數據。

 

2)按數據的變更和歷史規範數據的保存

 

• 客戶屬性、產品屬性不斷在變更。將這些屬性的歷史變化情況記錄下來，以便追溯某個時點的值。

• 在事實表裏冗餘維表的字段，即把"事件發生時"的各種維度屬性值與該事件綁定起來。使用者無需關聯多張表就可以使用數據。此方式僅可應用於數據應用層。

• 用拉鍊表或者日快照的形式，記錄維表的變化情況。這使得數據結構變得靈活、易於擴展，數據一致性得到了增強，數據加工者可以更加方便地管理數據。此方式僅可應用於數據基礎層。

 

5.數據導入通道與表設計

 

通道類型：

 

• Datahub：規劃寫入的分區與寫入流量之間的關係，做到每64M進行一次commit。

• 數據集成或DataX：規劃寫入的表分區的頻率，做到每64M進行一次commit，以免commit空目錄。

• DTS：規劃寫入的表存量分區與增量分區的關係，設置commit頻率。

• Console（Run SQL or Tunnel upload）：需要避免高頻小數據量文件的插入或者上傳。

• SDK執行SQL的insert into語句：對錶或者分區上傳時需要注意在插入到分區後使用merge語句進行小文件整理操作，以免對一個分區或者非分區表插入多次。

 

說明：

 

• DMP導入數據的通道只能是Tunnel SDK或執行SQL的insert into語句，請避免流式插入。

• 以上各通道本身均由自身邏輯進行流式數據寫入、批量數據寫入、週期調度寫入。

• 當使用數據通道寫入表或分區時，需將一次寫入的數據量控制在合理範圍，例如64M以上。

 

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

 

一張表裏有很多個一級分區，每個一級分區都會按時間存儲二級分區，每個二級分區都會存儲所有的列。

 

• 請設置分區的數量上限。

• 請避免每個分區中只存少量數據。

• 分區的條件設置應以方便數據的查詢和計算爲前提。

• 避免每個分區中出現多次的數據寫入。

 

7.表和分區設計基本規則

 

1）所有的表、字段名要使用統一的命名規範：

 

• 命名應能區分該表的業務類型。

• 命名應能區分該表是"事實表"或"維度表"、"日誌表"、"極限存儲表"（待發布的功能）。

• 命名應能區分該表的實體信息。

 

2）不同表中具有相同業務含義的字段要定義成統一的數據類型，避免不必要的類型轉換。

 

3）分區設計及使用規則：

 

• 支持新增分區，不支持新增分區字段。

• 單表支持分區數量爲6萬。

• 對於多級分區的表，如果想添加新的分區，則必須指明全部的分區值。

• 不支持修改分區列的列名，只能修改分區列對應的值。修改多級分區的一個或者多個分區值時，多級分區的每一級的分區值都必須寫上。

 

8.分區設計

 

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

 

通過分區字段，您可以劃分數據掃描範圍，更加方便地管理數據。

 

您在可以在創建表時設置普通字段和分區字段。通常，普通字段可以被理解爲數據文件的數據，而分區字段可以被理解爲文件系統的目錄。表的存儲空間的佔用主要是普通字段的空間佔用。

 

分區列雖不直接存儲數據，但如同文件系統裏的目錄，可以方便您管理數據。例如，在計算時若指定具體的分區，則計算過程中只需查詢對應分區，從而減少計算輸入量。

 

分區表的分區列的級數不能超過6級，即底層存儲數據的目錄層數不能超過6層。您應爲分區表設置合適的生命週期。當部分數據的生命週期與其它數據不同時，您可以通過細粒度分區實現對部分數據的管理。

 

說明：

 

• 設置分區字段時，您可以從數據管理和常用的數據掃描方面考慮，來選擇對應的字段。

• 不具備規律或類型數量大於10000且不經常作爲查詢條件的字段，應被設置成普通字段。

• 分區字段定義依據

 

2）按優先級高低排序

 

• 分區列的選擇應充分考慮時間因素，儘量避免對於存量分區進行更新。

• 如果有多個事實表（不包括維度表）進行join，應將查詢條件where範圍的列作爲分區列。

• 選擇group by或distinct包含的列作爲分區列。

• 選擇值分佈均勻的列，而不要選擇分區傾斜的列作爲分區列。

• 常用SQL語句中若經常包含某列的等值或in的查詢條件，則選擇該列作爲分區列。例如：

   

select … from** table where id =123 and** ….;

 

3）分區個數定義依據

 

• 時間分區：建議按天或月進行分區。如果按小時進行分區，則二級分區的平均數量不應超過8個。

• 地域分區：若對省、市、縣進行分區，則應考慮進行多級分區。23個省，5個自治區，4個直轄市，2個特別行政區，50個地區（州、盟），661個市（其中直轄市4個、地級市283個、縣級市374個），1636個縣（自治縣、旗、自治旗、特區和林區），按照最細粒度縣進行分區後，不應再按照更細粒度小時進行分區。

• 單分區與多級分區：在單分區下，建議每次提交64M數據。如果爲多級分區，則需保證每個最細粒度級分區下的二級分區的數據都遵循單分區個數規則。

• 單表分區：單表分區數（包括下級分區）不能超過6萬。

 

3）分區數量和數據量建議

 

• 在計算的時候可以使用分區裁剪是分區的優勢。

• 建議單個分區中數據量不要太大。

• 應儘量避免分區數據傾斜，避免單個表不同分區的數據量差異超過100萬。

• 做分區設計時應合理規劃分區個數，較細粒度的分區在跨分區掃描時會影響到SQL的執行性能。

• 單個分區中數據量較大的情況下，DMP執行任務時會做分片處理不影響分區裁剪的優勢。

• 單個分區中文件數較多時，會影響DMP Instance數量，造成資源浪費和SQL性能的影響。

• 採用多級分區，先按日期分區，然後按交易類型分區。

• 拆表，一種交易類型獨立成一張表，然後每張表按日期分區。

• 維度表不做分區。

作者丨白梟