MPP DB 是 大數據實時分析系統 將來的選擇嗎？

大數據領域，實時分析系統（在線查詢）是最多見的一種場景，前面寫了一個《實時分析系統(HIVE/HBASE/IMPALA)淺析》討論業界當前常見的方案。互聯網公司用得比較可能是HIVE/HBASE，如騰訊基於HIVE深度定製改造，更名爲TDW，小米等公司選用HBASE等。關於HIVE/HBASE/IMPALA介紹等能夠看我前面的文章。

當前在實時分析系統中，最難的是多維度複雜查詢，目前沒有一個很好的解決方案，這兩天和人討論到MPP DB（分佈式數據庫，以Greenplum爲最典型表明）。若是從性能來說，MPP DB在多維複雜查詢性能確實要好於HIVE/HBASE/IMPALA等，所以有很多聲音認爲，MPP DB是適合這種場景的將來的解決方案。MPP DB看似對多維度複雜查詢性能較好，可是同時有兩個致命的缺點，你們選型的時候不得不考慮：

一、擴展性：

MPP DB都號稱都能擴展到1000個節點以上，實際在應用過程當中，就我目前從公開資料看到的不超過100個節點，如支付寶中用Greenplum來作財務數據分析的最大一個集羣60多臺機器。另外和Greenplum公司交流，在廣東移動最大的用來作數據存儲的，也就100臺之內。這和hadoop動不動4,5千個節點一個節點集羣簡直不在一個數量級上。

爲何MPP DB擴展性很差？

有不少緣由，有產品成熟度，也有應用廣度的問題，可是最根本的仍是架構自己的問題。講到架構這裏就要先講下CAP原則：

Consistency(一致性), 數據一致更新，全部數據變更都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

MPP DB仍是基於原DB擴展而來，DB裏面自然追求一致性（Consistency），必然帶來分區容錯性較差。集羣規模變得太大，業務數據太多時，MPP DB的元數據管理就徹底是一個災難。元數據巨大無比，一旦出錯很難恢復，動不動致使毀庫。

因此MPP DB要在擴展性上有質的提示，要對元數據，以及數據存儲有架構上的突破，下降對一致性的要求，這樣擴展性才能提高，不然的話很難相信一個MPP DB數據庫是能夠容易擴展的。

 

二、併發的支持：

 

一個查詢系統，設計出來就是提供人用的，因此能支持的同時併發越高越好。MPP DB核心原理是一個大的查詢經過分析爲一一個子查詢，分佈到底層的執行，最後再合併結果，說白了就是經過多線程併發來暴力SCAN來實現高速。這種暴力SCAN的方法，對單個查詢來講，動用了整個系統的能力，單個查詢比較快，但同時帶來用力過猛的問題，整個系統能支持的併發必然不高，從目前實際使用的經驗來講，也就支持50～100的併發能力。

當前HBASE/IMPALA應對複雜查詢時，也是經過全盤SCAN的方法來實現的，這種場景下，硬盤數量越多越好，轉速越快越好。HBASE爲何號稱支持上千併發，這也是在特定的場景下（查詢時帶用戶標示，即帶row key)才能實現的，複雜查詢場景下，什麼系統都歇菜。

 

因此MPP DB應用場景已經很是明顯了，適合小集羣（100之內），低併發的（50左右）的場景。MPP DB將來是否是趨勢，我不知道，可是至少目前來看，用MPP DB來應對大數據的實時分析系統是很是吃力的。