開源OLAP系統小結

大數據的聲音雖然沒有前幾年熱鬧，但hadoop生態圈的造輪子腳步一點也沒停下來。最近幾天有空，梳理一下各種OLAP的計算和存儲框架。

• 純計算框架(query engine)
• Impala 目前在國內已經有不少商業客戶在使用，估計是cloudera的國內市場推廣做的不錯。
• 架構上，元數據需要單獨的mysql/pgsql來存儲，需要兩個單獨的stateserver和catalogserver來管理集群狀態和元數據的變化；
• SQL compilation支持。CBO和vectorization介紹不詳細，向量化估計是通過LLVM實現的；
• 對數據源的支持比較少，很多nosql是不支持的；
• C++開發，cloudera主導；
• Drill Drill是一個純粹的SQL query engine，支持多種data source，例如Hadoop storage， S3-style雲存儲，NoSQL存儲。
• 主要特點是支持多種的data source（HDFS HBase Mongo S3 kafka openTSDB等等），查詢前不需要etl工具做轉換，跟BI工具集成比較好；
• 支持SQL compilation，CBO這塊用的calcite，支持data locality aware，predicate 可以下推到store層，如果store層有對應的filter。
• 架構中比較有特點的兩個地方：
• meta data持久化存儲，放在底層存儲引擎中，不像hive還需要一個mysql；
• 用一個distributed in-memory k/v cache（infinispan，jboss cache的後繼項目）來緩存查詢查詢計劃分片，執行中間結果和統計信息。
• SQL compilation,Vectorization, pipeline等技術都支持，對外宣稱支持pipeline的並不多。
• java開發，MapR公司主導；
• impala和drill不同的技術路線跟兩個公司的定位有很大關係。
• presto 最初是facebook主導開發，開源後傳統的數倉公司TeraData提供商業支持。
• 支持的多種數據源，mysql redis kafka cassandra等，支持的數據源比Drill要少，對Json數據的支持沒有Drill好
• 內部的架構有點像impala，一個coodinator+多個worker。
• Hive 最初Hive的性能著實堪憂，目前也增加了CBO和vectorization等新特性。當然map reduce中間結果存檔確實是個硬傷。
• SparkSQL 跟其他的OLAP引擎不同，sparkSQL分析的數據以RDD/DataFrame方式存放在spark集群中。
• sparkSQL的CBO要到最新的2.2版本才支持，vectorization特性還在開發中
• 存儲框架(data store)
• kudu kudu是一套完全獨立的分散式存儲引擎，很多設計概念上借鑒了HBase，但是又跟HBase不同
• 不需要HDFS，通過raft做數據複製；sharding策略支持keyrange和hash多種；
• 數據格式在parquet基礎上做了些修改，支持二級索引，更像一個列式存儲，而不是HBase schema-free的kv方式
• kudu也是cloudera主導的項目，跟hadoop ecosystem結合比較好，尤其impala，通過impala可以支持update操作
• Druid Druid的整體定位跟kylin比較像，適用於存儲和查詢eventlog。
• 首先它沒有自己的存儲引擎，而是依賴於HDFS S3等; native查詢介面是Http+json，SQL介面需要依賴於社區的庫或者Hive；不支持Join。
• 數據以上卷（roll-up）的方式從外部導入。簡單的說對導入時，根據用戶指定的統計策略，對某些列（維度）的數據做聚合統計，將聚合數據存檔以節省存儲空間。導入有方式，事實和批量；導入時會根據對數據做分片，還可以指定列的索引(索引建在分片上)和壓縮方式
• java開發，使用的公司比較多，阿里，netflix，ebay等， 有個公司imply提供商業支持。
• Hybrid compute/storage
• palo palo是百度開源的一個數倉產品，官方說法是谷歌mesa和clouderaimpala的結合
• palo實現了SQL查詢引擎和分散式存儲引擎，不依賴任何hadoop組件
• palo的meta data並不依賴於一個單點的metadata storage（例如hive的mysql），而是通過Paxos-like協議做了多點複製，這樣的多個節點可以同時提供查詢能力
• sharding策略是先按照某個列做key-range（例如時間戳）切分，然後再按照hash（例如UserID）切分
• 存儲引擎方面，palo支持ORC或者parquet這種方式的列存
• 為了支持近實時導入，存儲引擎層實現了MVCC
• 保存全量數據的同時，支持rollup 物化視圖
• 簡單的多租戶支持
• C++編寫，利用LLVM實現vectorization
• clickhouse 俄羅斯yandex開源的一個數倉產品，c++編寫。跟palo或者mesa定位類似，目前官方文檔是俄語的，國內有一些翻譯，有人在嘗試
• greenplum 很老的一個MPP DataWareHouse，基於PgSQL內核開發，跟比較傳統的數倉vertica和redshift大致是同一時代的產品。最初被EMC收購，後來轉給pivotal。hadoop上的廉價/免費輪子很多，索性就開源了。
• gp架構比較老，一個master負責查詢優化，查詢調度和元數據存儲，master
• 多個segment server每個都是pg實例，pg的代碼做了大量修改（查詢優化，事務管理等等），特別地，自己給pg做了一個列存；
• deepgreen在gp的基礎上做了下向量化加速的優化；

參考

https://en.wikipedia.org/wiki/Apache_Impala

https://www.cloudera.com/documentation/cdh/5-0-x/Impala/Installing-and-Using-Impala/ciiu_concepts.html

https://drill.apache.org/architecture/

https://drill.apache.org/blog/2017/12/15/drill-1.12-released/

https://en.wikipedia.org/wiki/Apache_Drill

https://en.wikipedia.org/wiki/Presto_(SQL_query_engine)

https://en.wikipedia.org/wiki/Apache_Hive

https://cwiki.apache.org/confluence/display/Hive/Vectorized+Query+Execution

https://hortonworks.com/blog/hive-0-14-cost-based-optimizer-cbo-technical-overview/

https://issues.apache.org/jira/browse/SPARK-16060

https://databricks.com/blog/2017/08/31/cost-based-optimizer-in-apache-spark-2-2.html

http://kudu.apache.org/overview.html

https://en.wikipedia.org/wiki/Druid_(open-source_data_store)

http://druid.io/docs/0.11.0/design/index.html

https://hortonworks.com/blog/apache-hive-druid-part-1-3/

https://github.com/baidu/palo

About the Greenplum Architecture

greenplum-db/greenplum-db.github.io

推薦閱讀：