OLAP对比

OLAP产品	Kylin	Druid	Clickhouse	Impala+Kudu	Presto+HDFS	ElasticSearch+Hbase
支持数据规模	百TB~数十PB（几十亿~百亿）	百TB~PB	百TB~PB（几亿~几十亿）	TB~PB	GB~数十PB	GB~TB
查询性能	分析：亚秒级，支持高并发 明细：不支持	分析：亚秒级，支持高并发 明细：不支持	分析：单表亚秒级~2秒内 明细：单表亚秒级，Join在一些情况下性能不佳	分析：秒级~分钟级 明细：秒级	分析：秒级~分钟级 明细：秒级~分钟级	分析：不支持 明细：亚秒级，支持高并发
数据更新能力	微批量，定期预聚合hive数据	准实时	准实时，数据写入吞吐量能到200M/s	支持快速随机update，实时性高， Kudu提供了更新数据和删除数据的能力	取决于存储引擎，HDFS基本是T+1	两份存储，一致性不好保证
灵活性 扩展性	业务变更需要重新开发和对历史数据计算	业务变更需要重新开发和对历史数据计算	业务变更只需重写sql，非常灵活	业务变更只需重写sql，非常灵活	业务变更只需重写sql，非常灵活	有一定开发工作量
特点	1. 适合高并发固定模式查询 如百度指数 2. 系统稳定性强 3. 精准去重场景优势很大	1. 流批一体 2. 插入效率高，更新不太好 3. 适合处理星型模型数据	1. 查询非常灵活，但不经常查，采用现算就比较节省资源，由于查询量少，即使每个查询消耗计算资源大整体来说也可以是划算的 2. 非常多列且 where 条件随意组合的用户标签筛选，复杂即席查询性能非常快	1. 增量实时写 Kudu ，全量离线写 HDFS 2. Kudu 只保留当天数据，前一天的写 HDFS 3. 使用 Kudu 解决 HDFS 小文件问题	1. 跨数据源的联邦查询 2. 支持多表 join ，支持复杂查询，应用范围更广	1. ElasticSearch存索引数据，Hbase存明细数据
不适用场景和缺点	1. 业务经常变化，需要重新刷新 Hive 任务，重新计算结果写入 Hbase 2. 几十个维度交叉度太深会导致预计算结果膨胀很大 3. 不支持明细查询	1. 超高基维度 2. 跨数据源 join 3. 跨天去重，业务方希望做到精确查询，无法做到 4. 无法查询明细 5. Sql 支持较差	1. 多表关联场景不适用 2. DB 数据频繁 update 的分析需求（如订单状态频繁变更） 3. 分析查询并发最好不超 100QPS	1. 数据量较大，并发任务较多的时候，集群会很不稳定，需要有实时监测和人工干预，严重依赖集群资源 2. 并发能力较差 3. 多系统运维成本高	1. 多张大表关联操作容易 OOM 2. 并发造成性能下降非常明显	1. 没有 SQL 引擎 2. 不适合数据分析 3. 数据一致性问题 4. 级联查询支持不好