【個(gè)推CTO談數(shù)據(jù)智能】之多維度分析系統(tǒng)的選型方法

“最近看到一句話：“架構(gòu)設(shè)計(jì)的關(guān)鍵思維是判斷和取舍，程序設(shè)計(jì)的關(guān)鍵思維是邏輯和實(shí)現(xiàn)”，深以為然！
文 | 個(gè)推CTO Anson

引言
前文回顧：《數(shù)據(jù)智能時(shí)代來(lái)臨：本質(zhì)及技術(shù)體系要求》作為本系列的第一篇文章，概括性地闡述了對(duì)于數(shù)據(jù)智能的理解以及推出了對(duì)應(yīng)的核心技術(shù)體系要求：

數(shù)據(jù)智能就是以數(shù)據(jù)作為生產(chǎn)資料，通過(guò)結(jié)合大規(guī)模數(shù)據(jù)處理、數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、人機(jī)交互、可視化等多種技術(shù)，從大量的數(shù)據(jù)中提煉、發(fā)掘、獲取知識(shí)，為人們?cè)诨跀?shù)據(jù)制定決策時(shí)提供有效的智能支持，減少或者消除不確定性。

從對(duì)數(shù)據(jù)智能的定義來(lái)看，數(shù)據(jù)智能的技術(shù)體系至少需要包含幾個(gè)方面，見(jiàn)下圖所示：

▲數(shù)據(jù)智能技術(shù)體系構(gòu)成

其中數(shù)據(jù)資產(chǎn)治理、數(shù)據(jù)質(zhì)量保證、數(shù)據(jù)智能下的安全計(jì)算體系會(huì)在后續(xù)的系列文章中重點(diǎn)闡述。

然而最近在實(shí)際工作中，發(fā)現(xiàn)大家對(duì)于如何處理多維數(shù)據(jù)進(jìn)行分析以解決實(shí)際業(yè)務(wù)問(wèn)題方面存在一些實(shí)實(shí)在在的困擾，特別是對(duì)于選擇什么樣的底層系統(tǒng)無(wú)所適從，畢竟有資源給大家進(jìn)行試驗(yàn)的公司并不是太多。

故此我和團(tuán)隊(duì)一起研究，同時(shí)也借鑒了外部的一些資料，針對(duì)這個(gè)議題撰寫了本系列的第二篇文章，主要圍繞“多維度分析系統(tǒng)的選型方法”的主題，供大家參考，希望能縮短大家的決策時(shí)間。

正文內(nèi)容

分析系統(tǒng)的考量要素

CAP 理論大家都已經(jīng)比較熟悉， C.A.P 之間無(wú)法兼得，只能有所取舍。在分析系統(tǒng)中同樣需要在三個(gè)要素間進(jìn)行取舍和平衡，三要素分別是數(shù)據(jù)量、靈活性以及性能。

▲分析系統(tǒng)考量三要素

有的系統(tǒng)在數(shù)據(jù)量達(dá)到一定數(shù)量，譬如超過(guò)P級(jí)別后，在資源不變情況下，就無(wú)法滿足處理要求了，哪怕是一個(gè)簡(jiǎn)單的分析需求。

靈活性主要指操作數(shù)據(jù)時(shí)的方式是否靈活，比如對(duì)于一般的分析師而言，使用SQL來(lái)操作是首選，沒(méi)有太多的約束，如果使用特定領(lǐng)域的語(yǔ)言 (DSL) 相對(duì)就比較受限；另外一個(gè)意思是操作是否受預(yù)先條件的限制，譬如是否支持在多個(gè)維度下進(jìn)行靈活的即席(Ad-Hoc)查詢；最后一個(gè)就是性能要求，是否滿足多并發(fā)操作、能否在秒級(jí)進(jìn)行響應(yīng)。

數(shù)據(jù)查詢的過(guò)程分析

對(duì)數(shù)據(jù)進(jìn)行聚合類型的查詢時(shí)，一般按照以下三個(gè)步驟進(jìn)行：

▲實(shí)時(shí)查詢過(guò)程

首先，需要用索引檢索出數(shù)據(jù)所對(duì)應(yīng)的行號(hào)或者索引位置，要求能夠從上億條數(shù)據(jù)中快速過(guò)濾出幾十萬(wàn)或幾百萬(wàn)的數(shù)據(jù)。這方面是搜索引擎最擅長(zhǎng)的領(lǐng)域，因?yàn)橐话?a title="關(guān)系型數(shù)據(jù)庫(kù)" target="_blank" href="http://kemok4.com/mysql/">關(guān)系型數(shù)據(jù)庫(kù)擅長(zhǎng)用索引檢索出比較精確的少量數(shù)據(jù)。

然后從主存儲(chǔ)按行號(hào)或者位置進(jìn)行具體數(shù)據(jù)的加載，要求能夠快速加載這過(guò)濾出的幾十上百萬(wàn)條數(shù)據(jù)到內(nèi)存里。這方面是分析型數(shù)據(jù)庫(kù)最擅長(zhǎng)的領(lǐng)域，因?yàn)橐话闼鼈儾捎昧惺酱鎯?chǔ)，有的還會(huì)采用mmap的方式來(lái)加快數(shù)據(jù)的處理。

最后進(jìn)行分布式計(jì)算，能夠把這些數(shù)據(jù)按照GROUP BY和SELECT的要求計(jì)算出最終的結(jié)果集。而這是大數(shù)據(jù)計(jì)算引擎最擅長(zhǎng)的領(lǐng)域，如Spark、Hadoop等。

架構(gòu)的比較和分析

結(jié)合以上兩方面的要素，在架構(gòu)方面目前主要是三類：

MPP (Massively Parallel Processing)
基于搜索引擎的架構(gòu)
預(yù)計(jì)算系統(tǒng)架構(gòu)

MPP架構(gòu)
傳統(tǒng)的RDBMS在ACID方面具有絕對(duì)的優(yōu)勢(shì)。在大數(shù)據(jù)時(shí)代中，如果你的數(shù)據(jù)大部分依然還是結(jié)構(gòu)化的數(shù)據(jù)，并且數(shù)據(jù)并不是如此巨大的話，不一定非要采用類似Hadoop這樣的平臺(tái)，自然也可以采用分布式的架構(gòu)來(lái)滿足數(shù)據(jù)規(guī)模的增長(zhǎng)，并且去解決數(shù)據(jù)分析的需求，同時(shí)還可以用我們熟悉的SQL來(lái)進(jìn)行操作。

這個(gè)架構(gòu)就是MPP(Massively Parallel Processing)–大規(guī)模并行處理。

當(dāng)然實(shí)際上MPP只是一個(gè)架構(gòu)，其底層未必一定是RDBMS, 而可以是架設(shè)在Hadoop底層設(shè)施并且加上分布式查詢引擎(由Query Planner、Query Coordinator和Query Exec Engine等組成)，不使用MapReduce這樣的批處理方式。

這個(gè)架構(gòu)下的系統(tǒng)有：Greenplum、Impala、Drill、Shark等，其中Greenplum (一般簡(jiǎn)稱GP) 使用PostgreSQL作為底層數(shù)據(jù)庫(kù)引擎。

基于搜索引擎的架構(gòu)
相對(duì)比MPP系統(tǒng)，搜索引擎在進(jìn)行數(shù)據(jù)（文檔）入庫(kù)時(shí)將數(shù)據(jù)轉(zhuǎn)換為倒排索引，使用Term Index、Term Dictionary、Posting 三級(jí)結(jié)構(gòu)建立索引，同時(shí)采用一些壓縮技術(shù)來(lái)進(jìn)行空間的節(jié)省。

這些數(shù)據(jù)（文檔）會(huì)通過(guò)一定的規(guī)則（譬如對(duì)文檔ID進(jìn)行哈希算法）分散到各個(gè)節(jié)點(diǎn)上。在進(jìn)行數(shù)據(jù)檢索的時(shí)候，采用Scatter-Gather計(jì)算模型，在各個(gè)節(jié)點(diǎn)上分別進(jìn)行處理后，集中到發(fā)起搜索的節(jié)點(diǎn)進(jìn)行最終聚合。

這個(gè)架構(gòu)下的系統(tǒng)主要有：ElasticSearch、Solr，一般采用DSL進(jìn)行操作。

預(yù)計(jì)算系統(tǒng)架構(gòu)
類似Apache Kylin這樣的系統(tǒng)就是預(yù)計(jì)算系統(tǒng)架構(gòu)。其在數(shù)據(jù)入庫(kù)時(shí)對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合，通過(guò)事先建立一定的模型，對(duì)數(shù)據(jù)進(jìn)行預(yù)先的處理，形成“物化視圖”或者數(shù)據(jù)Cube，這樣對(duì)于數(shù)據(jù)的大部分處理實(shí)際是在查詢階段之前就完成了，查詢階段相當(dāng)于進(jìn)行二次加工。

這個(gè)架構(gòu)下的系統(tǒng)主要有: Kylin，Druid。雖然Kylin和Druid都屬于預(yù)計(jì)算系統(tǒng)架構(gòu)，兩者之間還是有不少差別。

Kylin是使用Cube的方式來(lái)進(jìn)行預(yù)計(jì)算（支持SQL方式），一旦模型確定，要去修改的成本會(huì)比較大，基本上需要重新計(jì)算整個(gè)Cube，而且預(yù)計(jì)算不是隨時(shí)進(jìn)行，是按照一定策略進(jìn)行，這個(gè)也限制了其作為實(shí)時(shí)數(shù)據(jù)查詢的要求。

而Druid 更加適合做實(shí)時(shí)計(jì)算、即席查詢（目前還不支持SQL），它采用Bitmap作為主要索引方式，因此可以很快地進(jìn)行數(shù)據(jù)的篩選及處理，但是對(duì)于復(fù)雜的查詢來(lái)說(shuō)， 性能上比Kylin要差。

基于上面的分析，Kylin一般主推超大數(shù)據(jù)量下的離線的OLAP引擎，Druid是主推的大數(shù)據(jù)量下的實(shí)時(shí)OLAP引擎。

三種架構(gòu)的對(duì)比
MPP架構(gòu)的系統(tǒng)：
有很好的數(shù)據(jù)量和靈活性支持，但是對(duì)響應(yīng)時(shí)間是沒(méi)有必然保證的。當(dāng)數(shù)據(jù)量和計(jì)算復(fù)雜度增加后，響應(yīng)時(shí)間會(huì)變慢，從秒級(jí)到分鐘級(jí)，甚至小時(shí)級(jí)都有可能。

搜索引擎架構(gòu)的系統(tǒng)：
相對(duì)比MPP系統(tǒng)，犧牲了一些靈活性換取很好的性能，在搜索類查詢上能做到亞秒級(jí)響應(yīng)。但是對(duì)于掃描聚合為主的查詢，隨著處理數(shù)據(jù)量的增加，響應(yīng)時(shí)間也會(huì)退化到分鐘級(jí)。

預(yù)計(jì)算系統(tǒng)：
在入庫(kù)時(shí)對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合，進(jìn)一步犧牲靈活性換取性能，以實(shí)現(xiàn)對(duì)超大數(shù)據(jù)集的秒級(jí)響應(yīng)。

結(jié)合上面的分析，以上三種分別是：
對(duì)于數(shù)據(jù)量的支持從小到大
靈活性從大到小
性能隨數(shù)據(jù)量變大從低到高

因此，我們可以基于實(shí)際業(yè)務(wù)數(shù)據(jù)量的大小、對(duì)于靈活性和性能的要求綜合來(lái)進(jìn)行考慮。譬如采用GP可能就能滿足大部分公司的需要，采用Kylin可以滿足超大數(shù)據(jù)量的需求等。

結(jié)語(yǔ)
最近看到一句話：“架構(gòu)設(shè)計(jì)的關(guān)鍵思維是判斷和取舍，程序設(shè)計(jì)的關(guān)鍵思維是邏輯和實(shí)現(xiàn)”，深以為然！

未來(lái)，我們個(gè)推技術(shù)團(tuán)隊(duì)也將不斷探索多維度分析系統(tǒng)的選型方法，與大家共同探討，一如既往地為各位開(kāi)發(fā)者提供更優(yōu)質(zhì)的服務(wù)。

更多內(nèi)容請(qǐng)關(guān)注：個(gè)推技術(shù)學(xué)院