| 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. 级联查询支持不好 |
