【個推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能夠知足超大數據量的需求等。

結語

最近看到一句話：「架構設計的關鍵思惟是判斷和取捨，程序設計的關鍵思惟是邏輯和實現」，深覺得然！

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