怎么設計企業級大數據分析平臺？

傳統企業的OLAP幾乎都是基于關系型數據庫，在面臨“大數據”分析瓶頸，甚至實時數據分析的挑戰時，在架構上如何應對？本文試擬出幾個大數據OLAP平臺的設計要點，意在拋磚引玉。

突破設計原則

建設企業的大數據管理平臺（Big Data Management Platform），第一個面臨的挑戰來自歷史數據結構，以及企業現有的數據庫設計人員的觀念、原則。數據關系、ACID在關系數據庫幾十年的統治時期是久得人心，不少開發人員都有過為文檔、圖片設計數據表，或將文檔、圖片序列化為二進制文件存入關系數據庫的經歷。在BDMP之上，我們需要對多種不同的格式的數據進行混合存儲，這就必須意識到曾經的原則已經不再適用——One size dosen’t fit all，新的原則——One size fits a bunch.

以下是我列出的一些NoSQL數據庫在設計上的模式：

文檔數據庫：數據結構是類JSON，可以使用嵌入（Embed）或文檔引用（Reference）的方式來為兩個不同的文檔對象建立關系；

列簇數據庫：基于查詢進行設計，有寬行（Wild Rows）和窄行（Skinny Rows）的設計決策；

索引數據庫：基于搜索進行設計，在設計時需要考慮對對每個字段內容的處理（Analysis）。

搜索和查詢的區別在于，對返回內容的排序，搜索引擎側重于文本分析和關鍵字權重的處理上，而查詢通常只是對數據進行單列或多列排序返回即可。

數據存儲的二八原則

不少企業在解決海量數據存儲的問題上，要么是把關系數據庫全部往Hadoop上一導入，要么是把以前的非結構化數據如日志、點擊流往NoSQL數據庫中寫入，但最后往往發現前者還是無法解決大數據分析的性能瓶頸，后者也無法回答數據如何發揮業務價值的問題。

在數據的價值和使用上，其實也存在著二八原則：

20%的數據發揮著80%的業務價值；

80%的數據請求只針對20%的數據。

目前來看，不管是數據存儲處理、分析還是挖掘，最完整和成熟的生態圈還是基于關系型數據庫，比如報表、聯機分析等工具；另外就是數據分析人員更偏重于查詢分析語言如SQL、R、Python數據分析包而不是編程語言。

企業大數據平臺建設的二八原則是，將20%最有價值的數據——以結構化的形式存儲在關系型數據庫中供業務人員進行查詢和分析；而將80%的數據——以非結構化、原始形式存儲在相對廉價的Hadoop等平臺上，供有一定數據挖掘技術的數據分析師或數據工程師進行下一步數據處理。經過加工的數據可以以數據集市或數據模型的形式存儲在NoSQL數據庫中，這也是后面要講到的“離線”與“在線”數據。

理解企業的數據處理需求

數據庫到數據倉庫，是事務型數據到分析型數據的轉變，分析型數據需要包括的是：分析的主題、數據的維度和層次，以及數據的歷史變化等等。而對大數據平臺來說，對分析的需求會更細，包括：

查詢：快速響應組合條件查詢、模糊查詢、標簽

搜索：包括對非結構化文檔的搜索、返回結果的排序

統計：實時反映變化，如電商平臺的在線銷售訂單與發貨計算出的庫存顯示

挖掘：支持挖掘算法、機器學習的訓練集

針對不同的數據處理需求，可能需要設計不同的數據存儲，還需要考慮如何快速地將數據復制到對應的存儲點并進行合適的結構轉換，以供分析人員快速響應業務的需求。

離線數據與在線數據

根據不同的企業業務，對“離線”的定義其實不一樣，在這里離線數據特指在業務場景中適用于“歷史數據”的部分。常見的歷史數據查詢分析一般來自于特定時間段，設計上需要考慮的是將數據存入歷史庫中時，建立時間索引。另一種情況是某種業務問題的定位或分析，在數據量巨大的情況下，基于Hadoop或Spark等框架編寫分析算法并直接在平臺上運行，可以大大節約數據導出導入、格式轉換與各種分析工具對接的時間。

在線數據處理按照存儲和分析的先后順序，可分為批處理（先存儲后分析）和流處理（先分析后存儲）兩類。Cassandra數據庫的設計采用上數據追加寫入模式，可以支持實時批處理；流式計算平臺則有Apache Storm、Yahoo S4等開源框架，商業平臺有Amazon Kenisis（部署在云端）。企業的實時分析需求往往有特定的應用場景，需要對業務和現行系統有深入的理解才能設計出一個合理的架構。