【個推CTO談數據智能】之多維度分析系統的選型方法

“最近看到一句話：“架構設計的關鍵思維是判斷和取舍，程序設計的關鍵思維是邏輯和實現”，深以為然！
文 | 個推CTO Anson

引言
前文回顧：《數據智能時代來臨：本質及技術體系要求》作為本系列的第一篇文章，概括性地闡述了對于數據智能的理解以及推出了對應的核心技術體系要求：

數據智能就是以數據作為生產資料，通過結合大規模數據處理、數據挖掘、機器學習、人機交互、可視化等多種技術，從大量的數據中提煉、發掘、獲取知識，為人們在基于數據制定決策時提供有效的智能支持，減少或者消除不確定性。

從對數據智能的定義來看，數據智能的技術體系至少需要包含幾個方面，見下圖所示：

▲數據智能技術體系構成

其中數據資產治理、數據質量保證、數據智能下的安全計算體系會在后續的系列文章中重點闡述。

然而最近在實際工作中，發現大家對于如何處理多維數據進行分析以解決實際業務問題方面存在一些實實在在的困擾，特別是對于選擇什么樣的底層系統無所適從，畢竟有資源給大家進行試驗的公司并不是太多。

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

正文內容

分析系統的考量要素

CAP 理論大家都已經比較熟悉， C.A.P 之間無法兼得，只能有所取舍。在分析系統中同樣需要在三個要素間進行取舍和平衡，三要素分別是數據量、靈活性以及性能。

▲分析系統考量三要素

有的系統在數據量達到一定數量，譬如超過P級別后，在資源不變情況下，就無法滿足處理要求了，哪怕是一個簡單的分析需求。

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

數據查詢的過程分析

對數據進行聚合類型的查詢時，一般按照以下三個步驟進行：

▲實時查詢過程

首先，需要用索引檢索出數據所對應的行號或者索引位置，要求能夠從上億條數據中快速過濾出幾十萬或幾百萬的數據。這方面是搜索引擎最擅長的領域，因為一般關系型數據庫擅長用索引檢索出比較精確的少量數據。

然后從主存儲按行號或者位置進行具體數據的加載，要求能夠快速加載這過濾出的幾十上百萬條數據到內存里。這方面是分析型數據庫最擅長的領域，因為一般它們采用列式存儲，有的還會采用mmap的方式來加快數據的處理。

最后進行分布式計算，能夠把這些數據按照GROUP BY和SELECT的要求計算出最終的結果集。而這是大數據計算引擎最擅長的領域，如Spark、Hadoop等。

架構的比較和分析

結合以上兩方面的要素，在架構方面目前主要是三類：

MPP (Massively Parallel Processing)
基于搜索引擎的架構
預計算系統架構

MPP架構
傳統的RDBMS在ACID方面具有絕對的優勢。在大數據時代中，如果你的數據大部分依然還是結構化的數據，并且數據并不是如此巨大的話，不一定非要采用類似Hadoop這樣的平臺，自然也可以采用分布式的架構來滿足數據規模的增長，并且去解決數據分析的需求，同時還可以用我們熟悉的SQL來進行操作。

這個架構就是MPP(Massively Parallel Processing)–大規模并行處理。

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

這個架構下的系統有：Greenplum、Impala、Drill、Shark等，其中Greenplum (一般簡稱GP) 使用PostgreSQL作為底層數據庫引擎。

基于搜索引擎的架構
相對比MPP系統，搜索引擎在進行數據（文檔）入庫時將數據轉換為倒排索引，使用Term Index、Term Dictionary、Posting 三級結構建立索引，同時采用一些壓縮技術來進行空間的節省。

這些數據（文檔）會通過一定的規則（譬如對文檔ID進行哈希算法）分散到各個節點上。在進行數據檢索的時候，采用Scatter-Gather計算模型，在各個節點上分別進行處理后，集中到發起搜索的節點進行最終聚合。

這個架構下的系統主要有：ElasticSearch、Solr，一般采用DSL進行操作。

預計算系統架構
類似Apache Kylin這樣的系統就是預計算系統架構。其在數據入庫時對數據進行預聚合，通過事先建立一定的模型，對數據進行預先的處理，形成“物化視圖”或者數據Cube，這樣對于數據的大部分處理實際是在查詢階段之前就完成了，查詢階段相當于進行二次加工。

這個架構下的系統主要有: Kylin，Druid。雖然Kylin和Druid都屬于預計算系統架構，兩者之間還是有不少差別。

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

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

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

三種架構的對比
MPP架構的系統：
有很好的數據量和靈活性支持，但是對響應時間是沒有必然保證的。當數據量和計算復雜度增加后，響應時間會變慢，從秒級到分鐘級，甚至小時級都有可能。

搜索引擎架構的系統：
相對比MPP系統，犧牲了一些靈活性換取很好的性能，在搜索類查詢上能做到亞秒級響應。但是對于掃描聚合為主的查詢，隨著處理數據量的增加，響應時間也會退化到分鐘級。

預計算系統：
在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。

結合上面的分析，以上三種分別是：
對于數據量的支持從小到大
靈活性從大到小
性能隨數據量變大從低到高

因此，我們可以基于實際業務數據量的大小、對于靈活性和性能的要求綜合來進行考慮。譬如采用GP可能就能滿足大部分公司的需要，采用Kylin可以滿足超大數據量的需求等。

結語
最近看到一句話：“架構設計的關鍵思維是判斷和取舍，程序設計的關鍵思維是邏輯和實現”，深以為然！

未來，我們個推技術團隊也將不斷探索多維度分析系統的選型方法，與大家共同探討，一如既往地為各位開發者提供更優質的服務。

更多內容請關注：個推技術學院