為什么需要數(shù)據(jù)倉庫

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

數(shù)據(jù)倉庫層次架構

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

 

 

近源數(shù)據(jù)層

近源層是數(shù)據(jù)倉庫拷貝源數(shù)據(jù)提供整合的數(shù)據(jù)存儲區(qū)域，粒度、結構和源系統(tǒng)保持相同

緩沖區(qū)：保存源系統(tǒng)每天的增量數(shù)據(jù)，可根據(jù)應用需要保留適當歷史周期的數(shù)據(jù)，不長期保存數(shù)據(jù)

操作區(qū)：存儲數(shù)據(jù)倉庫最細節(jié)數(shù)據(jù)，按照業(yè)務源系統(tǒng)分類劃分;對數(shù)據(jù)做結構化處理，完整保留所有細節(jié)數(shù)據(jù)。

近源層是整個數(shù)據(jù)倉庫中數(shù)據(jù)量最大的部分。

整合數(shù)據(jù)層

明細區(qū)：采用維度建模方法，整合近源層數(shù)據(jù)，進行適度的反范式設計明細事實數(shù)據(jù)表。

匯總區(qū)：根據(jù)應用層和其他下游系統(tǒng)取數(shù)需要，對明細事實數(shù)據(jù)進行適度匯總，提升取數(shù)性能。

維度區(qū)：數(shù)倉統(tǒng)一維度數(shù)據(jù)模型。

應用數(shù)據(jù)層

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

數(shù)據(jù)建模

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

維度表設計

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

維度表主鍵

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

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

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

維度反規(guī)范化處理

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

 

 

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

 

 

維度的合并和拆分

合并：

相同范圍數(shù)據(jù)，對應多張表存儲屬性不同，根據(jù)維度分析需要整合至一張維度表中，整合后減少事實表和維度表關聯(lián)次數(shù)，方便數(shù)據(jù)分析和加快數(shù)據(jù)統(tǒng)計計算。

不同數(shù)據(jù)范圍，對應多張表存儲信息，根據(jù)維度分析需要將相同屬性整合到一張表中，不同表中差異化的數(shù)據(jù)整合到各自數(shù)據(jù)表中。

拆分：

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

 

 

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

 

 

需要結合業(yè)務數(shù)據(jù)情況和數(shù)據(jù)分析要求，合理使用合并和拆分方法。

緩慢變化維

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

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

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

 

 

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

 

 

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

 

 

快照維度表

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

層次維表

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

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

 

 

深度輕微差別層級：比如蘇寧銷售目錄關系，表現(xiàn)為三到五級層級關系，層級關系不固定，但層級深度有限，可以基于最大深度和業(yè)務規(guī)則建立維度表。如下圖：

 

 

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

 

 

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

事實表設計

維度模型設計過程

選擇業(yè)務過程：業(yè)務過程由組織完成的微觀活動。例如易購交易過程包含：下單、支付、發(fā)貨、收貨、退貨等，明確了業(yè)務過程根據(jù)業(yè)務需求選擇和建模有關的業(yè)務過程。

申明粒度：確認事實表中每一行數(shù)據(jù)的準確粒度，以交易過程舉例，對應粒度為交易時間、會員、商家、商品，申請粒度和主鍵(單號)等價，不要以數(shù)據(jù)主鍵來定義數(shù)據(jù)粒度

確定維度：根據(jù)業(yè)務需要確認需要分析的業(yè)務維度，包含時間、地點、人物、環(huán)境等，常見包含日期、會員、商品、渠道、設備等

確定事實：事實也稱為度量，根據(jù)業(yè)務需要和數(shù)據(jù)來源確認度量。

事務事實表

事務可以理解為業(yè)務操作最基本的動作，他可表示特定時間、空間發(fā)生的一個事件。如果某個事務發(fā)生，將在對應事實表中建立對應一行記錄，它能實現(xiàn)對細節(jié)行為數(shù)據(jù)的分析。

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

 

 

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

 

 

周期快照事實

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

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

累計快照事實表

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

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

 

 

數(shù)據(jù)處理常見問題

離線數(shù)據(jù)處理

1)表存儲格式

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

2)數(shù)據(jù)壓縮

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

3)數(shù)據(jù)傾斜

在表數(shù)據(jù)處理過程中，多種情況會發(fā)生數(shù)據(jù)傾斜：

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

2. 兩大表關聯(lián)，其中表中關鍵key值存在部分鍵值數(shù)據(jù)非常大，導致數(shù)據(jù)傾斜

個別鍵值，比如null值數(shù)據(jù)非常大，對個別鍵值做rand處理，打散數(shù)據(jù)

非個別的鍵值數(shù)據(jù)量很多，比如熱銷商品訪問數(shù)據(jù)量會比其他商品數(shù)據(jù)量大，可以首先統(tǒng)計topN數(shù)據(jù)量Key列表到topN表中，將量大表先和topN表關鍵，這樣topN數(shù)據(jù)可以先mapjoin，剩下數(shù)據(jù)common join，可以避免數(shù)據(jù)傾斜。

出現(xiàn)數(shù)據(jù)傾斜還是需要先分析key值數(shù)據(jù)分布情況確認解決方案。

實時數(shù)據(jù)處理

1)數(shù)據(jù)重復

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

2)雙數(shù)據(jù)流關聯(lián)

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

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

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

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

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

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

大促計算保障

電商行業(yè)，大促業(yè)務量是日常業(yè)務量的很多倍，暴增的數(shù)據(jù)量對計算平臺各環(huán)節(jié)都會帶來較大的挑戰(zhàn)。

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

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

名詞解釋：

 

 

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

標簽： 大數(shù)據(jù) 大數(shù)據(jù)平臺 大數(shù)據(jù)平臺開發(fā) 大數(shù)據(jù)中心 代碼 電商 電商行業(yè) 數(shù)據(jù)分析

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。