一、業(yè)務背景

1.1 數(shù)據(jù)建模現(xiàn)狀：

互聯(lián)網(wǎng)企業(yè)往往存在多個產(chǎn)品線，每天源源不斷產(chǎn)出大量數(shù)據(jù)，這些數(shù)據(jù)服務于數(shù)據(jù)分析師、業(yè)務上的產(chǎn)品經(jīng)理、運營、數(shù)據(jù)開發(fā)人員等各角色。為了滿足這些角色的各種需求，業(yè)界傳統(tǒng)數(shù)倉常采用的是經(jīng)典分層模型的數(shù)倉架構(gòu)，從ODS>DWD>DWS>ADS逐層建模，重點支持BI分析，如下圖：

1.2 當前業(yè)務特性與趨勢

互聯(lián)網(wǎng)產(chǎn)品快速迭代，業(yè)務發(fā)展越來越快，跨業(yè)務分析越來越多，數(shù)據(jù)驅(qū)動業(yè)務越來越重要。

數(shù)據(jù)服務的主要群體正在從數(shù)據(jù)研發(fā)轉(zhuǎn)向產(chǎn)品人員，使用門檻需要進一步降低。

二、面臨的問題

2.1 在數(shù)據(jù)驅(qū)動業(yè)務越來越重要的大趨勢下，面臨的問題

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

2.2 思考

那么在生產(chǎn)實踐中如何解決上述面臨的問題及痛點呢，在對業(yè)務線進行調(diào)研和對具體用戶訪談后，根據(jù)調(diào)研和訪談結(jié)論，得出以下想法：

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

2）明確數(shù)據(jù)表使用方式，確保口徑清晰統(tǒng)一，避免業(yè)務方線下拉會溝通，降低溝通成本，提高溝通效率；

3）加速數(shù)據(jù)查詢，快速滿足業(yè)務需求，助力數(shù)據(jù)驅(qū)動業(yè)務。

三、技術(shù)方案

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

3.1 大寬表模型替代經(jīng)典數(shù)倉維度模型

3.1.1 大寬表模型架構(gòu)

用一層大寬表在數(shù)倉層內(nèi)替換使用維度模型建的表，在數(shù)倉層間替換傳統(tǒng)的ODS>DWD>DWS>ADS逐層建模的分層架構(gòu)，最終報表和adhoc場景可直接使用大寬表，如下圖：

3.1.2 大寬表建設(shè)方案

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

3.1.3 大寬表建設(shè)原理

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

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

3.1.4 寬表優(yōu)點及性能

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

△圖5

2）經(jīng)典數(shù)倉層與層存在大量冗余，一層大寬表替換多層數(shù)倉，數(shù)倉總存儲下降 30% 左右，節(jié)約了大量存儲

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

3）性能對比

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

可分為三類場景：

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

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

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

3.1.5 寬表帶來的挑戰(zhàn)

寬表建模在提升數(shù)據(jù)易用性及查詢性能的同時，也帶來了一些挑戰(zhàn)：

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

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

3） 產(chǎn)出時效：由于寬表本身上游數(shù)據(jù)源多、數(shù)據(jù)量大，當多個上游數(shù)據(jù)就緒時間不盡相同時，寬表的產(chǎn)出時效會出現(xiàn)木桶效應。

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

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

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

（1）將寬表設(shè)置不同的業(yè)務分區(qū)，回溯時只更新對應的分區(qū)數(shù)據(jù)；

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

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

上游多個數(shù)據(jù)源產(chǎn)出時效不同步的問題，這里可以考慮2種方式：

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

（2）當上游數(shù)據(jù)無法提速時，可以考慮分批產(chǎn)出不同分區(qū)的數(shù)據(jù)，這種方式需要meta系統(tǒng)和調(diào)度系統(tǒng)同步支持，會提升系統(tǒng)復雜度。

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

四、總結(jié)與規(guī)劃

1）寬表建模更適合面向快速迭代的數(shù)據(jù)驅(qū)動型業(yè)務，能夠提升業(yè)務效率

2）基于當前的業(yè)務實踐，寬表在存儲和查詢性能方面相比于傳統(tǒng)數(shù)倉更優(yōu)

3）在業(yè)務效率提升的同時，寬表的建設(shè)會對數(shù)據(jù)生產(chǎn)和維護成本有所提升，還需結(jié)合實際應用進一步優(yōu)化探索

未來規(guī)劃：基于寬表可以更方便的構(gòu)建自助分析平臺，進一步提升業(yè)務分析效率。