关于OLAP如何选型的思考

思考因素

关注点

1. 数据规模：数据量级多大，一次查询 Scan 的数据规模（百亿、十亿）；
2. 实时性：是否要求实时写入、实时可见；
3. 查询类型：即席查询、还是固化查询；
4. 查询延时：查询响应延时要求、是否需要高并发（MPP 架构基本不要考虑并发，水位就那些，可能一次查询就打满，讨论并发没有意义）；
5. 写入吞吐：需要支持的写入吞吐是多少（对于预建索引的引擎，需要考虑其优化方式，要和实时可见性做折衷）；
6. 查询模式：这一步往往和模型的设计同时进行，是否宽表、是否需要 join、是否时序数据等；
7. 精确度：是否要求 100%精确，尤其是基数计算，一些引擎可能不支持精确去重，这点可以和查询延时做权衡；
8. 产品其他功能性需求：这个需要根据实际情况评估优先级，考虑哪些功能对其可用，如租户、安全等。
9. 运维方式及成本

适用场景

Presto适用场景

• Presto特别适合小型Query，Presto对小型任务也有比较好的性能表现。
• 维度不确定的即席查询(adhoc)，满足秒级或分钟级返回。
• 一般用于报表(BI报表、自定义报表)，数据质量检测，活动营销。Aapche Impala强依赖于CDH的生态，Apache Drill和Apache HAWQ社区都不太活跃。因此现在Presto风头强于 Impala;

Aapche Impala强依赖于CDH的生态，Apache Drill和Apache HAWQ社区都不太活跃。因此现在Presto风头强于 Impala;

Kylin适用场景

• 原始数据百亿条，希望亚秒级获得数据分析结果。
• 超大数据集下查询要求。 数据模型或查询模式相对固定(固化查询)，同时多表查询聚合复杂。 查询分析历史数据(数据T + 1)。
• 一般用于固定的数据可视化报表。
• 另外，Kylin对建模能力要求较高，3.0提供的Planner引擎可以进行智能建模。

Druid使用场景

• 对SQL没有强需求，对实时数据提取，高性能查询和高可用要求较高的要求。
• 数据的插入频率非常高，但是更新频率非常低。
• 数据具有时间属性，Druid 进行了特殊优化。
• 一般用于监控系统(网络性能监控)，风控服务，应用性能指标，点击流分析，在线营销等。

ClickHouse适用场景

• 在大宽表上进行大量聚合计算，没有复杂Join操作，需要秒级返回的需求；
• 查询并发度不高，对SQL兼容性要求不高；
• 数据不直接依赖HDFS，无事务需求。
• 一般用于统计分析服务，精细化运营工具(如广告投放)，用户行为实时分析

 

Doris适用场景

• 个人理解可以认为是Presto的加速版，一站式OLAP实时分析数据库。
• 数据不直接依赖HDFS，接受MySQL标准，有适量join和大量聚合操作。
• 一般用于新业务场景，无Hadoop数仓历史背景，一站式OLAP数据库和实时数据仓库

ClickHouse和Doris的选择

1. 业务场景复杂数据规模巨大，希望投入研发力量做定制开发，选ClickHouse
2. 希望一站式的分析解决方案，少量投入研发资源，选择Doris