168大数据

标题: 开源OLAP系统小结 [打印本页]

作者: 168主编 时间: 2021-6-21 19:29
标题: 开源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的基础上做了下向量化加速的优化；

欢迎光临 168大数据 (http://www.bi168.cn/)