導讀：早在多年以前在Hadoop系列分佈式計算與存儲、消息中間件還沒有成熟的時候，數據倉庫主要基於Oracle的數倉建設。但隨着時間的推移，傳統數據倉庫的數據計算與存儲，已經無法很好地支持海量數據的計算與存儲，這樣大數據 ( 分佈式 ) 技術開始火熱起來。本文將爲大家介紹58數據倉庫團隊使用Hadoop開源技術軟件從0-1以及1-N數倉的建設和演進過程。主要內容包括：
-
商業數倉介紹
-
商業數倉1.0
-
商業數倉2.0
-
商業數倉3.0
0158商業數倉介紹
1. 58數倉規模
隨着數據量的不斷增加，現在58數據倉庫每天數據增量在25TB+；在調度系統上，數據倉庫的整體作業爲2000多個；資源使用情況佔用大數據平臺整體資源的1/3左右；數倉團隊人員規模爲15+。
2. 商業數倉架構
58商業數倉架構分爲四層：
-
ODS ( 貼源層 )：其中包括埋點的數據採集、傳輸，離線、實時、多維分析所使用數據的源頭；
-
DWD ( 明細數據層 )：涵蓋了業務數據倉庫、客戶數據倉庫、廣告數據倉庫、全站用戶行爲數據倉庫等等；
-
DWA ( 彙總層 )：集中建設通用性的維度和指標，降低業務開發需求成本；
-
APP層 ( 應用層 )：主要涵蓋了業務場景、分析主題、OLAP多維分析引擎幾方面，包括了智慧數、商家參謀、監控平臺、效果數據、特徵挖掘等應用。
02商業數倉1.0
1. 業務背景
① 處於業務初創時期，缺少數據
起步階段，業務比較單一，所以造成缺少數據的情況。
② 擁有的數據呈爆發式增長
隨着技術的發展以及企業和用戶的需求，數據呈現爆發式的增長，數據量環比上月增加100%左右。在處理數據方面，主要圍繞準確性、及時性、穩定性來做，保證數據倉庫有準確的數據，並且可以及時看到數據。
2. 技術狀況
當時數據傳輸使用的是5年前的技術——rsync ( 凌晨定時把文件put搭配HDFS文件系統上面，但是存在嚴重的及時性問題，在調度作業前需要把所有文件到傳輸到HDFS上面去 )；
調度方面——dsap ( 類似crontab定時器，可以在指定的時間調度起來作業，但是作業之間沒有依賴，穩定性得不到保障 )；
研發方面——MapReduce ( 倉庫整體都是使用MR代碼來實現各項功能，其中開發的效率比較低 )。
3. 調度升級
針對58倉庫1.0的問題，首先是需要解決的問題是穩定性問題，因爲dsap是屬於定時調度，存在超時問題，所以針對調度，短期採用文件依賴的方法，經過不斷迭代，最終形成了的58DP工具平臺。
4. 代碼升級
由於底層ODS、DWD的數據格式多樣，數據處理邏輯複雜，依舊沿用MapReduce，到了DWA、APP層，逐漸改用Hive SQL來處理。
5. 傳輸升級
解決及時性問題上，rsync換成了Apache Flume + Kafka來解決時性問題。
6. 代碼優化
針對ODS、DWD層的MR進行setup優化、DistibutedCache優化，在APP層採用通用的Hive優化方法進行性了一些優化。
7. 指標標準定義
在數據應用層發佈了統一的數據標準，計算標準，指標邏輯含義清晰定義等。
8. 監控
增加了一系列的監控，比如說這個表的數據在某個時間點可以給提供下游，關鍵指標的監控、作業完成時間的監控、指標波動監控等。
9. 流量來源的劃分
對於來源劃分，採用SPM等參數的方式來區分；對於SEO等無法通過參數方式來區分的場景，58這邊採用的是通過Nginx日誌獲取一跳URL，然後再根據相關邏輯進行流量來源劃分。
10. 小結
在商業數倉第一階段主要建設數據穩定性、準確性和及時性。其中2、3、4小節主要用來提升穩定性，5、6小節提升及時性，7、8、9小節用來提高準確性。
03商業數倉2.0
1. 背景
在商業數據倉庫1.0中，存在兩方面的問題：
-
其數據內容不夠豐富 ( 不能讓數據很好的實現商業變現 )，所以在數倉2.0中進行了迭代升級；
-
企業對於實時性的要求不斷升級 ( 在數倉底層使用的Flume+Kafka組件已經可以支持實時的要求 )，實時和離線多維分析場景支持不夠。
2. 全站行爲數據建設
PC/M端：根據用戶的一次展現，通過ID傳到列表頁/詳情頁/行爲頁，這一套採用的是標準參數傳遞的方式進行傳輸。
APP端：採用sidDict參數傳遞的方式進行數據傳輸。
主要問題：
-
參數傳遞涉及到的流程多，保證所有流程、步驟都正確傳遞的成本極高
-
受業務線迭代影響極大，出現問題排查成本極高
-
用戶行爲串連匹配率不高，並且已經到達了瓶頸
所以，我們採用狀態機的方式，通過用戶標識 ( Cookieid、imei ) 進行數據的串聯。
效果：
-
串聯比例大幅度提升、匹配率95%+；
-
開發成本減低、可維護性高；
-
擴展性強
3. 息壤
在實時方面進行提升，可以從不同維度、不同粒度看到各個項的實時數據，以供企業、用戶及時修正。
實時的技術架構採用的是 Kafka + Sparkstreaming + Druid；目前最新採用的是Flink技術。
04商業數倉3.0
1. 系統性
在數倉3.0階段，對DWD層每個煙囪獨立倉庫進行整合，即開發數據中臺，提高數據的複用性，把數據的能力進一步提升。
把相似的內容進行模型化建設，將異構的數據進行統一化的處理流程。
以LEGO廣告系統流程爲核心，對標到數據處理的流程上，制定標準ODS層數據格式，其餘老系統數據映射到對應標準ODS 層，再以數據漏斗形式，進行串聯全流程數據，產出DWD層表。
2. 產品化
客戶：
-
效果數據：客戶推廣效果數據展示、分析
-
商家參謀：針對供需指數，投放相應數據量的廣告
分析決策：智慧樹 ( Dashboard、監控平臺 )
技術分析：實時ab測、洞察平臺 ( 實時效果，實時監控 )。
05總結58商業數倉目前經歷了3個階段，在商業數倉第一階段主要建設數據穩定性、準確性和及時性；第二階段主要圍繞數據豐富度進行建設；第三階段主要是圍數倉的體系化、產品化的建設。