個推CTO深度解析資料智慧之多維度分析系統的選型方法
##引言 前文回顧：《資料智慧時代來臨：本質及技術體系要求》作為本系列的第一篇文章，概括性地闡述了對於資料智慧的理解以及推出了對應的核心技術體系要求：
資料智慧就是以資料作為生產資料，通過結合大規模資料處理、資料探勘、機器學習、人機互動、視覺化等多種技術，從大量的資料中提煉、發掘、獲取知識，為人們在基於資料制定決策時提供有效的智慧支援，減少或者消除不確定性。
從對資料智慧的定義來看，資料智慧的技術體系至少需要包含幾個方面，見下圖所示：
其中資料資產治理、資料質量保證、資料智慧下的安全計算體系會在後續的系列文章中重點闡述。
然而最近在實際工作中，發現大家對於如何處理多維資料進行分析以解決實際業務問題方面存在一些實實在在的困擾，特別是對於選擇什麼樣的底層系統無所適從，畢竟有資源給大家進行試驗的公司並不是太多。
故此我和團隊一起研究，同時也借鑑了外部的一些資料，針對這個議題撰寫了本系列的第二篇文章，主要圍繞“多維度分析系統的選型方法”的主題，供大家參考，希望能縮短大家的決策時間。
##正文內容
###分析系統的考量要素
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可以滿足超大資料量的需求等。
##結語 最近看到一句話：“架構設計的關鍵思維是判斷和取捨，程式設計的關鍵思維是邏輯和實現”，深以為然！
未來，我們個推技術團隊也將不斷探索多維度分析系統的選型方法，與大家共同探討，一如既往地為各位開發者提供