[[146569]]

傳統(tǒng)企業(yè)的OLAP幾乎都是基于關(guān)系型數(shù)據(jù)庫，在面臨“大數(shù)據(jù)”分析瓶頸，甚至實時數(shù)據(jù)分析的挑戰(zhàn)時，在架構(gòu)上如何應(yīng)對？本文試擬出幾個大數(shù)據(jù)OLAP平臺的設(shè)計要點，意在拋磚引玉。

突破設(shè)計原則

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

以下是我列出的一些NoSQL數(shù)據(jù)庫在設(shè)計上的模式：

文檔數(shù)據(jù)庫：數(shù)據(jù)結(jié)構(gòu)是類JSON，可以使用嵌入（Embed）或文檔引用（Reference）的方式來為兩個不同的文檔對象建立關(guān)系；

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

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

搜索和查詢的區(qū)別在于，對返回內(nèi)容的排序，搜索引擎?zhèn)戎赜谖谋痉治龊完P(guān)鍵字權(quán)重的處理上，而查詢通常只是對數(shù)據(jù)進行單列或多列排序返回即可。

數(shù)據(jù)存儲的二八原則

不少企業(yè)在解決海量數(shù)據(jù)存儲的問題上，要么是把關(guān)系數(shù)據(jù)庫全部往Hadoop上一導(dǎo)入，要么是把以前的非結(jié)構(gòu)化數(shù)據(jù)如日志、點擊流往NoSQL數(shù)據(jù)庫中寫入，但***往往發(fā)現(xiàn)前者還是無法解決大數(shù)據(jù)分析的性能瓶頸，后者也無法回答數(shù)據(jù)如何發(fā)揮業(yè)務(wù)價值的問題。

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

20%的數(shù)據(jù)發(fā)揮著80%的業(yè)務(wù)價值；

80%的數(shù)據(jù)請求只針對20%的數(shù)據(jù)。

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

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

理解企業(yè)的數(shù)據(jù)處理需求

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

查詢：快速響應(yīng)組合條件查詢、模糊查詢、標(biāo)簽

搜索：包括對非結(jié)構(gòu)化文檔的搜索、返回結(jié)果的排序

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

挖掘：支持挖掘算法、機器學(xué)習(xí)的訓(xùn)練集

針對不同的數(shù)據(jù)處理需求，可能需要設(shè)計不同的數(shù)據(jù)存儲，還需要考慮如何快速地將數(shù)據(jù)復(fù)制到對應(yīng)的存儲點并進行合適的結(jié)構(gòu)轉(zhuǎn)換，以供分析人員快速響應(yīng)業(yè)務(wù)的需求。

離線數(shù)據(jù)與在線數(shù)據(jù)

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

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