資料倉庫應對資料爆發式增長
| 編輯推薦: |
| 本文來自於51cto，本文詳細介紹了資料倉庫的層次結構以及實時計算和離線計算等相關知識。 |
為什麼需要資料倉庫
隨著公司業務不斷髮展，資料種類和儲存呈現爆發式增長，繁多的業務資料如何被各業務中心分析和使用，如何有效組織和管理大量業務資料，減少大資料平臺相近邏輯重複計算、相近資料重複儲存，都將面臨巨大挑戰。
資料倉庫層次架構
資料倉庫層次整體劃分為三層：近源資料層、整合資料層和應用資料層，如下圖：
近源資料層
近源層是資料倉庫拷貝源資料提供整合的資料儲存區域，粒度、結構和源系統保持相同
緩衝區：儲存源系統每天的增量資料，可根據應用需要保留適當歷史週期的資料，不長期儲存資料
操作區：儲存資料倉庫最細節資料，按照業務源系統分類劃分;對資料做結構化處理，完整保留所有細節資料。
近源層是整個資料倉庫中資料量最大的部分。
整合資料層
明細區：採用維度建模方法，整合近源層資料，進行適度的反正規化設計明細事實資料表。
彙總區：根據應用層和其他下游系統取數需要，對明細事實資料進行適度彙總，提升取數效能。
維度區：數倉統一維度資料模型。
應用資料層
應用資料層為個性化彙總層，針對不是很通用統計維度、指標存放在此層中，本層計算通常只有自身業務關注的維度和指標，和其他業務線一般無交集 。
資料建模
資料建模是資料倉庫中的核心工作，蘇寧資料建模主要採用的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.對適合在客戶端採集實現的業務，由採集來實現，減輕大資料平臺計算壓力，也能通過資料採集優化有效避免部分業務的雙流關聯，提高實時計算效率和準確度。
名詞解釋：
