【51CTO.com原創稿件】為什么需要數據倉庫

隨著公司業務不斷發展，數據種類和存儲呈現爆發式增長，繁多的業務數據如何被各業務中心分析和使用，如何有效組織和管理大量業務數據，減少大數據平臺相近邏輯重復計算、相近數據重復存儲，都將面臨巨大挑戰。

數據倉庫層次架構

數據倉庫層次整體劃分為三層：近源數據層、整合數據層和應用數據層，如下圖：

近源數據層

近源層是數據倉庫拷貝源數據提供整合的數據存儲區域，粒度、結構和源系統保持相同

• 緩沖區：保存源系統每天的增量數據，可根據應用需要保留適當歷史周期的數據，不長期保存數據
• 操作區：存儲數據倉庫最細節數據，按照業務源系統分類劃分;對數據做結構化處理，完整保留所有細節數據。

近源層是整個數據倉庫中數據量***的部分。

整合數據層

• 明細區：采用維度建模方法，整合近源層數據，進行適度的反范式設計明細事實數據表。
• 匯總區：根據應用層和其他下游系統取數需要，對明細事實數據進行適度匯總，提升取數性能。
• 維度區：數倉統一維度數據模型。

應用數據層

應用數據層為個性化匯總層，針對不是很通用統計維度、指標存放在此層中，本層計算通常只有自身業務關注的維度和指標，和其他業務線一般無交集 。

數據建模

數據建模是數據倉庫中的核心工作，蘇寧數據建模主要采用的kimball維度建模方法，建模主要分兩塊，維度表設計和事實表設計。

維度表設計

維度是數據倉庫的核心，他提供了數據分析的視角和標準，大部分的維度表數據量都相對較小，但是他是整個數據倉庫的核心，整個的數據建模都是圍繞著維度來建設。

維度表主鍵

維度表在數據倉庫中有不可替代的重要地位，因此維度表主鍵的確認也尤其重要，維度表的主鍵用于和事實表做關聯使用，所以維度表主鍵也為事實表的外鍵，維表主鍵可由有業務含義的自然鍵組成;也可由無意義的代理建組成，比如使用流水號、自然鍵+日期等方式。

維表相對靜態、不隨時間變化直接使用自然鍵作為主鍵，比如：業務狀態碼、性別、城市省份等不會隨著時間改變而改變主鍵對應業務含義，一般直接使用業務自然鍵作為主鍵;維表隨著時間的變化而產生變化需要考慮使用代理鍵作為主鍵。蘇寧門店代碼,會因為組織法人等信息變更，生門店代碼會發生變化，對應主鍵的業務含義會隨著時間的變化而改變，使用一個代理鍵和業務門店代碼映射，可以識別歷史和當前不通的門店代碼為一個門店。

實際使用過程中，由于在大數據平臺中生成穩定代理鍵和自然鍵關系比較復雜，一般使用流水號代理鍵使用非常少。

維度反規范化處理

在OLTP系統中，一般表設計都遵循3NF等規范化要求要求建立數據模型，這個可以有效避免數據冗余以及數據不一致性，如下圖：

然而在OLAP系統中，使用規范化，會導致數據表關聯操作多、性能差，在OLAP系統中，數據是相對穩定的，此時往往會采用反規范化處理，根據分析需要建立對應維度寬表，降低模型查詢復雜度，提升批處理查詢性能。如下圖：

維度的合并和拆分

合并：

• 相同范圍數據，對應多張表存儲屬性不同，根據維度分析需要整合至一張維度表中，整合后減少事實表和維度表關聯次數，方便數據分析和加快數據統計計算。
• 不同數據范圍，對應多張表存儲信息，根據維度分析需要將相同屬性整合到一張表中，不同表中差異化的數據整合到各自數據表中。

拆分：

• 根據屬性的使用頻率、屬性變化程度、屬性數據計算產生時間等角度分析多維度屬性做適當拆分，常用的信息在一張表中，對異變、冷門屬性拆分到另外一張表中，對出數比較晚的數據也做單獨拆分，可以盡可能保障主數據模型出數穩定和提前出數時間。如下圖：



• 根據業務細分或者業務數據使用熱度進行拆分，例如蘇寧商品目前已經到十億+級別數據量，其中很大一部分商品已經不在售賣，不會產生流量和交易，可以將近N月產生流量或交易數據分別建立維度表，減少事實表和維度表關聯系統消耗。如下圖：

需要結合業務數據情況和數據分析要求，合理使用合并和拆分方法。

緩慢變化維

緩慢變化主要是解決記錄數據倉庫中數據歷史變化，實際根據業務需要我們會有多種處理方式。

以會員會員張三舉例，9月1日前公司地址為南京市玄武區蘇寧大道一號總部一期;9月2日由原公司地址總部一期變更為總部二期，對應多種處理方式包含覆蓋方式、新增列方式和新增行方式，下面對每種方式處理方法單獨介紹。

• 覆蓋方式：維度屬性的變化，維度舊的屬性總是被新值所覆蓋，不保留歷史狀態數據，當數據不需要保留歷史記錄，不需要執行以前的報表，可以采取此方式。如下圖：



• 新增列方式：新增數據列記錄對應列數據變化前數據，可以記錄指定列數據變化情況。如下圖：



• 新增行方式：當維度數據發生變更，維度表新增一條維度記錄，并且分配新的代理主鍵，通常配合有效開始時間、有效結束時間、有效標識使用。如下圖：

快照維度表

在實際大數據平臺開發過程中，產生唯一代理鍵和生成緩慢變化為拉鏈表是比較困難和復雜的，在很多實際的場景中是基于計算周期，每個周期生成一份快照表，保留每個周期的快照數據，采用快照表方式維護簡單使用也比較方便，弊端也很明顯浪費存儲，在數據量不是特別大的情況下使用此方式還是比較合適的。

層次維表

通常維度之間往往存在層次關系，關系的層級可能是固定的，也可能是不固定的

• 固定深度層級：比如蘇寧采購目錄層級關系，表現為固定四級層級關系，為提高查詢性能，將表設置為固定四層寬表。如下圖：



• 深度輕微差別層級：比如蘇寧銷售目錄關系，表現為三到五級層級關系，層級關系不固定，但層級深度有限，可以基于***深度和業務規則建立維度表。如下圖：



• 深度可變層級：對于深度層級不確定維表，在建模和使用都相對較復雜，可以采用橋接表方式，對每個可能的路徑保留一行，確保能遍歷所有層次。還以銷售目錄舉例，如下圖：

由上圖可見，橋接表加工處理比較復雜，且帶來雙算的隱患，實際模型設計中，多選擇扁平化模型設計方法來解決業務問題。

事實表設計

維度模型設計過程

• 選擇業務過程：業務過程由組織完成的微觀活動。例如易購交易過程包含：下單、支付、發貨、收貨、退貨等，明確了業務過程根據業務需求選擇和建模有關的業務過程。
• 申明粒度：確認事實表中每一行數據的準確粒度，以交易過程舉例，對應粒度為交易時間、會員、商家、商品，申請粒度和主鍵(單號)等價，不要以數據主鍵來定義數據粒度
• 確定維度：根據業務需要確認需要分析的業務維度，包含時間、地點、人物、環境等，常見包含日期、會員、商品、渠道、設備等
• 確定事實：事實也稱為度量，根據業務需要和數據來源確認度量。

事務事實表

事務可以理解為業務操作最基本的動作，他可表示特定時間、空間發生的一個事件。如果某個事務發生，將在對應事實表中建立對應一行記錄，它能實現對細節行為數據的分析。

如下已訂單下單和支付過程具體，如下圖：

在實際設計過程中，如果多個業務動作的維度和度量都基本相同，可以考慮將多個業務過程合并為一張事實表，合并可以減少數據開發工作量和方便以后業務變更。如下圖：

周期快照事實

如果希望分析某個業務在某個固定的、可預測的事件間隔內的累計性能，可使用周期快照事實表，利用周期快照可對一天、一周、一個月結束時建立數據快照，存儲到事實表中，周期快照事實表可用于記錄事實每個周期的變化情況。

例如我們業務中通常對會員累計支付金額、積分余額、會員等級、商品庫存等做周期快照，方便分析會員、商品等屬性對應度量值，而不需要長期聚集事務歷史。

累計快照事實表

累計快照表示具有確定的開始和結束時間以及此期間所有中間過程的步驟，累計快照適中會表示多個日期外鍵，表示主要時間或過程里程碑。

以交易過程舉例，統計訂單對應下單到支付時長、支付到發貨時長、發貨到收貨時長、支付到收貨時長等，事務事實表計算復雜，性能差，比較適合采用累積快照事實表。如下圖：

數據處理常見問題

離線數據處理

1)表存儲格式

盡可能避免使用textfile存儲格式。數據內容中時常會出現換行、tab等一些特殊字符，使用textfile容易出現數據行錯位、列錯位等情況，如果特殊情況不可避免使用textfile格式，盡量選擇json文件格式，或者多個特殊分隔符作為行和列分隔符。

2)數據壓縮

建議使用orc或rc等壓縮方式存儲表，以cpu換存儲和時間 ，加快讀寫效率。

3)數據傾斜

在表數據處理過程中，多種情況會發生數據傾斜：

1. 大小表關聯，走common join，由于關聯key值在大表中分布不均勻，可以開啟mapjoin，將小表加載到內存，大表不需要根據key做hash分布，不會出現數據分布不均情況。

2. 兩大表關聯，其中表中關鍵key值存在部分鍵值數據非常大，導致數據傾斜

• 個別鍵值，比如null值數據非常大，對個別鍵值做rand處理，打散數據
• 非個別的鍵值數據量很多，比如熱銷商品訪問數據量會比其他商品數據量大，可以首先統計topN數據量Key列表到topN表中，將量大表先和topN表關鍵，這樣topN數據可以先mapjoin，剩下數據common join，可以避免數據傾斜。

出現數據傾斜還是需要先分析key值數據分布情況確認解決方案。

實時數據處理

1)數據重復

在實時數據處理過程中，不論使用storm、sparkstreaming、flink，因為在保證大數據大吞吐計算情況下，往往較難保證數據事務，在環境或者計算出現異常情況下，容易出現某個批次部分數據重復計算，在很多數據業務分析往往是無法接受的，對需要準確性統計的計算場景，緩存每次計算結束的列表，每次計算前根據已計算列表驗證當前數據是否已經計算過，對計算過的數據跳過本次計算，這樣程序異常或者重啟，重新讀取kafka數據會跳過已經計算完成的數據。對用戶流量類大數據量做到精確統計消耗成本太高，可以根據實際業務需要選擇對應方案。

2)雙數據流關聯

多數情況，在實時指標分析過程中，指標和維度往往能通過一個數據源來分析計算得出，在某些場景下，指標對應維度會對應不同的數據源，這時候就需要將兩個數據源根據業務ID關聯起來，然而兩個實時數據流可能會出現1.兩個數據流數據不同步，2.數據采集可能存在一定的數據丟失，導致可能部分pv再等待另外一個流永遠都等不到。

以流量PV指標舉例，分析維度包含：城市、頁面類型、供應商等，其中流量訪問日志里面包含PV_ID、城市、頁面類型等信息，流量庫存日志包含PV_ID、供應商等信息，pv數指標對應維度分表對應兩個數據源中，在離線計算中join直接解決，在實時計算過程中又怎么關聯呢?

首先需要分析兩個數據流哪個是主數據流，所有的統計數據以主流為基礎，保證主流數據不丟失，部分場景也可能兩個流合并作為主數據流;

其次需要對兩個數據流設定一定的緩存，對未關聯上的數據先記錄到緩存中，等待另外數據流做關聯操作，緩存需要有持久化機制，保證系統出現問題或者程序重啟緩存不會丟失;

再次設置緩存時長，由于包括數據丟失等可能情況會導致數據無法關聯情況，此時需要根據業務定義緩存時長，對超過時長還未關聯到的數據根據業務做對應處理。

在實際實時模型設計盡可能減少雙流關聯的計算場景，一方面雙流關聯開發較復雜，另外一方面雙流關聯相比單流數據準確性存在下降的可能性，在上舉例中，可以通過上游采集系統在訪問流添加供應商等維度，由一個數據流支撐對應指標和維度，雙流在采集端容易做業務合并的盡可能在采集端做業務合并。

大促計算保障 

電商行業，大促業務量是日常業務量的很多倍，暴增的數據量對計算平臺各環節都會帶來較大的挑戰。

離線計算，1.數據暴增首先帶來的是底層平臺HDFS計算壓力，需要根據預估業務量擴容平臺計算能力;2.數據暴增容易帶來數據傾斜問題，例如大促爆款商品等呈現分化數據會導致數據分布嚴重不均勻，需要打散數據，有效利用平臺資源分散計算，縮短計算時間;3.提前分析核心業務線，識別關鍵路徑，對關鍵路徑中慢節點做拆分優化，提高計算并行能力，縮短關鍵路徑時間。在大促保障期間，通過計算傾斜的優化和關鍵路徑的拆分優化，有效提前整體出數時間。

實時計算：1.根據預估業務量擴容實時計算storm、spark streaming、flink等平臺資源;2.在流處理業務中，根據業務數據量、業務重要程度對業務計算做拆分，避免集群內業務互相影響，對storm需要根據業務做集群拆分，盡可能將數據量大非核心業務拆分單獨集群，避免集群內非核心業務搶占核心業務資源3.合理利用數據緩存有效提高實時計算能力;4.對適合在客戶端采集實現的業務，由采集來實現，減輕大數據平臺計算壓力，也能通過數據采集優化有效避免部分業務的雙流關聯，提高實時計算效率和準確度。

名詞解釋： 

作者：彭虎，蘇寧易購IT總部大數據中心技術副總監，12年IT從業經驗，專長大數據hive、storm、spark等數據計算技術，對數據建模、數據計算、多維分析有著專業認知和研究，致力于數據倉庫探索研究、數據質量分析、數據計算保障。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】