在數據倉庫建設過程中，我們不可避免地要執行數據任務，那麽如何配置這些任務才是最好的呢？如果任務調度配置出現問題，就會導致任務出現瓶頸，或者不能及時提供業務需要的數據。這個時候，我們需要首先從調度方面考慮。有些任務的調度時間設置是否不合理？還是有些任務的優先級設置不合理？
對於數據倉庫的建模，可以分為3NF建模和維度建模。建議使用維度建模，可以按照星型模型或者雪花型模型架構建模。3NF建模方法或者實體建模方法的應用會更差，很多情況下性能會更差，但是3NF會避免數據冗余，擴展性會更好。而維度建模會有壹定的數據冗余，冗余度很高，但是對於上層用戶來說，使用起來會方便很多，查詢性能也會好很多。雖然犧牲了壹些擴展性，但還是在可以接受的範圍內。之所以在大數據的框架下推薦維度建模，是因為建模產生的數據冗余對於大數據的離線數據倉庫來說並不高，因為都屬於SATA磁盤存儲，所以存儲成本很低。
總之，建議妳在大數據框架下使用維度建模和星型模型或者雪花模型建模，這樣更方便後續的運維和後續的數據使用，性能會更好。星型模型其實是中間的事實表，周圍是壹堆維度表，結構會更簡單，使用起來更方便，性能更好。對於雪花模型，維度表可以繼續與其他維度表相關聯。這種方式就是雪花模型，比星型模型稍微復雜壹點。其實，星型模型也可以理解為壹個相對簡單的雪花模型。這裏推薦妳用明星款。當然，如果業務非常復雜，必要時可以使用雪花模型。這是因為星型模型雖然有數據冗余，但其結構相對簡單易懂，只需要從A傳到B，不需要關聯a C。
除了以上兩個重點，還有壹些小點需要註意，比如中間表的使用。我們壹般把數據倉庫分為三層，第壹層是緩沖，第二層是集成，第三層是應用。但並不是嚴格的分為三層，中間可能會有壹些中間表來存儲中間計算的結果。如果能夠很好地使用中間表，數據倉庫的可用性和整體性能將會得到增強。中間表的使用主要是在幾個倉庫的二層，因為要集成數據，但是集成的數據還是明細數據。對於這些表來說，數據量往往比較大，會有很多下遊任務依賴這個表，所以可以做壹些溫和的匯總，也就是做壹些大眾匯總的中間表，這樣應用層可以節省很多計算和成本。另外，雖然建議使用中間表，但是也要註意中間表的數量，因為如果中間表太多，依賴級別也會太多。
在壹些業務場景中，我們還需要拆分壹個寬表。壹般拆分壹個表發生在表中有很多字段，幾個字段的輸出時間晚了，會耽誤整個表的交付時間。在這種情況下，我們可以單獨拆分這些字段，這樣其他業務的使用就不會受到幾個字段的影響。
與表拆分相反的是表合並。隨著業務的增加，可能會有多個表存儲類似的數據指標。這時候我們可以把多個表整合成壹個表，減少數據任務的冗余。
表分區的功能壹定要合理使用，對性能影響很大。壹級分區壹般以天為單位劃分。建議妳每天增量做或者全量做。反之，二級分區會有更多的選擇。首先我們需要知道是否為烤箱建立二級分區，然後我們需要選擇建立二級分區的方式。二級分區比較適合where語句中經常用到的字段，這個字段應該是可枚舉的，比如部門名稱。這裏還有壹個前提，就是如果這個領域的值分布很不均勻，那麽不建議做二次劃分。
離線倉庫盤點的計算任務基本都是用SQL實現的，這裏只說如何在SQL中優化。我們通常在數據處理、數據清洗、數據轉換和數據處理中使用SQL。對於大數據體系下SQL的優化，主要集中在減少數據輸入和避免數據傾斜兩大方面。減少數據輸入是核心點。如果數據輸入量過大，會占用大量計算資源。但是離線倉庫盤點經常會遇到數據偏斜，數據偏斜有幾種，需要進行相應的優化。
對於分區表，合理使用分區可以過濾數據，避免掃描整個表，有效減少計算的數據輸入。
SQL支持只讀取壹次源數據，然後將它寫入多個目標表，從而確保只有壹個查詢。語法如下
當我們使用join、Reduce或UDF時，先過濾數據也能有效地提高任務的效率。
當數據在Map階段發生傾斜時，第壹種處理方式反饋到業務層面，看是否可以通過業務層面的修改使kv值均勻分布。如果業務層面處理不了，可以調整Map的數量，即增加Map的計算節點。默認情況下，每256M的數據為壹個計算節點，我們可以減少，即增加Map處理的節點數，使數據分段更加均勻。
加入階段的傾斜也很常見，需要分分鐘處理以下情況的解決方案:
減少傾斜有幾種可能的情況:
綜上所述，性能調優歸根結底是因為資源不足或者資源使用不合理，或者是因為任務分配不暢，使得部分資源分配和利用不合理。