一、業務背景

1.1 數據建模現狀：

互聯網企業往往存在多個產品線，每天源源不斷產出大量數據，這些數據服務于數據分析師、業務上的產品經理、運營、數據開發人員等各角色。為了滿足這些角色的各種需求，業界傳統數倉常采用的是經典分層模型的數倉架構，從ODS>DWD>DWS>ADS逐層建模，重點支持BI分析，如下圖：

1.2 當前業務特性與趨勢

互聯網產品快速迭代，業務發展越來越快，跨業務分析越來越多，數據驅動業務越來越重要。

數據服務的主要群體正在從數據研發轉向產品人員，使用門檻需要進一步降低。

二、面臨的問題

2.1 在數據驅動業務越來越重要的大趨勢下，面臨的問題

面臨著如下問題，如下圖：

2.2 思考

那么在生產實踐中如何解決上述面臨的問題及痛點呢，在對業務線進行調研和對具體用戶訪談后，根據調研和訪談結論，得出以下想法：

1）節約數倉整體存儲，數倉不分層，用更少的表滿足業務需求，比如一個主題一張寬表；

2）明確數據表使用方式，確保口徑清晰統一，避免業務方線下拉會溝通，降低溝通成本，提高溝通效率；

3）加速數據查詢，快速滿足業務需求，助力數據驅動業務。

三、技術方案

根據上述的想法，經過可行性分析后，提出一層大寬表模型替代經典數倉維度模型的技術方案，來解決數倉存儲大量冗余、表多且口徑不清晰和查詢性能低的問題。

3.1 大寬表模型替代經典數倉維度模型

3.1.1 大寬表模型架構

用一層大寬表在數倉層內替換使用維度模型建的表，在數倉層間替換傳統的ODS>DWD>DWS>ADS逐層建模的分層架構，最終報表和adhoc場景可直接使用大寬表，如下圖：

3.1.2 大寬表建設方案

根據產品功能和業務場景的不同，把日志分為不同主題，在各個主題內按各個業務使用的細節程度和業務含義進行寬表建設，建設時統一ods層與dwd層的表粒度，覆蓋下游業務所有字段需求，包含明細表所有字段，也覆蓋各層的維度字段及指標列，用來滿足上層的業務指標分析等各種需求，主要支持報表分析和adhoc場景查詢，具體如下圖：

3.1.3 大寬表建設原理

1）采用Parquet列式存儲，可支持寬表數百列，超多字段，再經過按列的高效壓縮和編碼技術，降低了數倉整體存儲空間，提高了IO效率，起到了降低上層應用延遲的效果

2）將各層之間的事實表復雜嵌套字段打平后與各個維度表、指標等進行join生成寬表，寬表的列最終分為公共屬性、業務維度屬性和指標屬性

3.1.4 寬表優點及性能

1）一層大寬表替換維度模型，通過極少的冗余，做到了表更少，口徑更清晰，同時業務使用上更方便，溝通更流暢，效率更高在同一主題內，建設寬表時將維度表join到事實表中后，事實表列變多，原以為會增加一些存儲，結果經過列式存儲中按列的高效壓縮和編碼技術，降低了存儲空間，在生產實踐場景中，發現存儲增加極少。替換后在數倉層內只有一張寬表，且表結構清晰明了，使得溝通效率大大提升，如下圖：

△圖5

2）經典數倉層與層存在大量冗余，一層大寬表替換多層數倉，數倉總存儲下降 30% 左右，節約了大量存儲

經典數倉架構中，同一主題在數倉間存在大量冗余存儲，比如業務上經常從ODS層抽取字段生成DWD層數據，抽取的字段在這兩層間就會出現大量冗余，同理，主題內其他層與層之間也存在大量冗余。在同一主題內按業務使用的細節程度和具體業務含義，將表粒度精簡后統一成一個粒度，按該粒度并包含下游業務所需字段，生成寬表，可避免數倉層間的大量冗余。也就是整個數倉無需分層，只有一層大寬表，一個主題有一到兩個寬表。在生產實踐中建設大寬表后，數倉總存儲下降30%左右，大大節約了存儲成本，如下圖：

3）性能對比

到這里可能會有疑問，寬表數據量既然變多了，在查詢上會不會有性能損失呢？

可分為三類場景：

場景1：經典數倉表和一層寬表存儲相近的情況下，寬表使用了列式存儲和統計濾波，簡單查詢，尤其是簡單聚合查詢會更快

場景2：依然是經典數倉表和一層寬表存儲相近的情況下，經典數倉中需要使用explode等函數進行的復雜計算場景，在寬表中絕大部分需求通過count、sum即可完成，因為寬表會將業務指標下沉，復雜字段拆分打平，雖然行數變多了，但避免了explode，get_json_object等耗時操作，查詢性能極高

場景3：經典數倉表和一層寬表存儲相差較大的情況下，寬表性能有一定的損失，但在業務接受范圍內，影響不大，如下圖：

3.1.5 寬表帶來的挑戰

寬表建模在提升數據易用性及查詢性能的同時，也帶來了一些挑戰：

1） 開發成本：寬表為了盡可能多的滿足業務需求，封裝了大量的ETL處理邏輯及關聯計算，這會使寬表代碼更加復雜，開發迭代維護成本更高。

2） 回溯成本：在業務迭代過程中，往往伴隨著指標口徑的升級、日志打點的變動，需要寬表回溯歷史數據。而寬表本身數據量較大，計算邏輯復雜，回溯時會額外消耗較多的計算資源，存在較高的回溯成本。

3） 產出時效：由于寬表本身上游數據源多、數據量大，當多個上游數據就緒時間不盡相同時，寬表的產出時效會出現木桶效應。

針對以上，結合實際應用我們探索了一些解決思路：

開發成本增加，主要原因是寬表進行了更多的ETL操作和封裝了更多的指標口徑計算，這本質上其實是研發成本和使用成本之間的權衡，將一部分下游用戶使用時再計算的成本提前封裝到寬表中。而如果寬表的下游用戶越多，這種研發成本的提升對整體業務成本實際上是下降的，也就是我們說的降低使用門檻、提升自助化率。因此在當前數據分析平民化的背景下，實際總成本是下降的。

回溯成本的增加，體現在原來只需回溯一個dws或ads層的小表，現在可能要回溯整張寬表。這里在實際生產中，我們在技術上可以探索一些優化方案，包括：

（1）將寬表設置不同的業務分區，回溯時只更新對應的分區數據；

（2）基于寬表作為輸入，回溯所需字段，避免重新執行生成寬表的復雜計算邏輯；

（3）利用在線服務夜間空余的潮汐資源，進一步降低回溯資源開銷。

上游多個數據源產出時效不同步的問題，這里可以考慮2種方式：

（1）通過上游數據流批一體化改造，提升上游數據時效性

（2）當上游數據無法提速時，可以考慮分批產出不同分區的數據，這種方式需要meta系統和調度系統同步支持，會提升系統復雜度。

更多的解決思路，歡迎大家進一步探討~

四、總結與規劃

1）寬表建模更適合面向快速迭代的數據驅動型業務，能夠提升業務效率

2）基于當前的業務實踐，寬表在存儲和查詢性能方面相比于傳統數倉更優

3）在業務效率提升的同時，寬表的建設會對數據生產和維護成本有所提升，還需結合實際應用進一步優化探索

未來規劃：基于寬表可以更方便的構建自助分析平臺，進一步提升業務分析效率。