开源OLAP系统小结

大数据的声音虽然没有前几年热闹，但hadoop生态圈的造轮子脚步一点也没停下来。最近几天有空，梳理一下各种OLAP的计算和存储框架。

• 纯计算框架(query engine) SQL on hadoop
  
  • Impala 目前在国内已经有不少商业客户在使用，估计是cloudera的国内市场推广做的不错。
    
    • 比较典型的MPP数据库架构，元数据需要单独的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公司主导；
    • MapR已经挂了，这项目估计也黄了
      
  • presto 最初是facebook主导开发，开源后传统的数仓公司TeraData提供商业支持。
    
    • 支持的多种数据源，mysql redis kafka cassandra等，支持的数据源比Drill要少，对Json数据的支持没有Drill好
    • 内部的架构有点像impala，一个coodinator+多个worker。
      
  • Hive 把SQL翻译成Hadoop上的MapReduce task，性能着实堪忧，目前也增加了CBO和vectorization等新特性。当然map reduce中间结果存盘确实是个硬伤。
  • SparkSQL 跟其他的OLAP引擎不同，sparkSQL分析的数据以RDD/DataFrame方式存放在spark集群中。
    
    • sparkSQL的CBO要到最新的2.2版本才支持，vectorization特性还在开发中
    • spark的扩展性比较好
      
• 存储框架(data store)
  
  • kudu kudu是一套完全独立的分布式存储引擎，很多设计概念上借鉴了HBase，但是又跟HBase不同
    
    • 不需要HDFS，通过raft做数据复制；sharding策略支持keyrange和hash多种；
    • 数据格式在parquet基础上做了些修改，支持二级索引，更像一个列式存储，而不是HBase schema-free的kv方式
    • kudu也是cloudera主导的项目，跟hadoop ecosystem结合比较好，尤其impala，通过impala可以支持update操作
    • kudu相对于原有parquet和ORC格式主要还是做增量更新的
      
• 数仓
  
  • 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
      
  • Druid Druid的整体定位跟kylin比较像，适用于存储和查询eventlog。
    
    • 首先它没有自己的存储引擎，而是依赖于HDFS S3等; native查询接口是Http+json，SQL接口需要依赖于社区的库或者Hive；不支持Join。
    • 数据以上卷（roll-up）的方式从外部导入。简单的说对导入时，根据用户指定的统计策略，对某些列（维度）的数据做聚合统计，将聚合数据存盘以节省存储空间。导入有方式，事实和批量；导入时会根据对数据做分片，还可以指定列的索引(索引建在分片上)和压缩方式
    • java开发，使用的公司比较多，阿里，netflix，ebay等， 有个公司imply提供商业支持。
      
  • clickhouse 俄罗斯yandex开源的一个数仓产品，c++编写。跟palo或者mesa定位类似，目前官方文档是俄语的，国内有一些翻译，有人在尝试；
    
    • 最近几年国内ck社区发展挺快的
    • ck、pinot跟Druid都比较像，算是web-scale数据仓吧，对事务支持比较弱，对并行计算友好；这个三者跟spark比，双大表的join需要reshuffle的场景支持的没那么好
      
  • greenplum 很老的一个MPP DataWareHouse，基于PgSQL内核开发，跟比较传统的数仓vertica和redshift大致是同一时代的产品。最初被EMC收购，后来转给pivotal。hadoop上的廉价/免费轮子很多，索性就开源了。
    
    • gp架构比较老，一个master负责查询优化，查询调度和元数据存储，master
    • 多个segment server每个都是pg实例，pg的代码做了大量修改（查询优化，事务管理等等），特别地，自己给pg做了一个列存；
    • deepgreen在gp的基础上做了下向量化加速的优化；