[[146569]]

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

突破設(shè)計(jì)原則

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

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

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

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

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

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

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

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

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

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

80%的數(shù)據(jù)請(qǐng)求只針對(duì)20%的數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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