OLAP 到现在也都是两个套路：一个用空间换时间，一个充分利用所有资源快速计算。
前者就是 MOLAP（多维在线分析），后者就是 ROLAP（关系型在线分析），当然还有一个混合的，那个不管。
Kylin 和 Druid 都是 MOLAP 的典范，ClickHouse 则是 ROLAP 的佼佼者。
kudu 是一个支持 OLAP 的大数据存储引擎，也能用来做 OLAP。
如果你的业务部门要求高并发高性能，那就可以用 Kylin 和 Druid，这两个都是预计算的套路，你给他设定好分析路线，kylin 建 CUBE，Druid 做各种 group by 的计算，业务部门分析的时候就等于是直接查询已经计算好的结果。
速度和并发量的表现都非常棒。缺点是吃存储，分析路径比较死，加一个维度得改模型。
如果你的业务部门人不多，就内部用，但是比较挑剔，要非常高的自由度，那就可以用 ClickHouse。这个你建各种表就好了。
业务部门基于数据关系自己选择，CK 现算，给答案。这个单表查询效率超高，join 的话不太满意。而且因为都是现算的，并发量上不去。最关键的是CK所在的服务器基本干不了别的，查几条数据都有可能吃掉50%以上的 CPU。
利益相关：Apache Kylin 的商业公司 Kyligence 方案架构师，对kylin的场景，出过几个方案，恰巧最近正在调研 clickhouse，尝试回答一下。
相同点
Kylin 和 ClickHouse 都能通过 SQL 的方式在 PB 数据量级下,亚秒级(95%查询 2s内返回)返回 OLAP(在线分析查询) 查询结果
不同应用场景
Kylin 适合高并发，固定模式查询场景，例如：报表分析，留存分析，用户标签画像分析，用户行为漏斗分析，归因分析等。
ClickHouse 适合低并发,灵活即席查询场景,也支持例如:报表分析,留存分析,用户标签画像分析,用户行为漏斗分析,归因分析等.
原理不同
Kylin 是基于 Hadoop 平台，通过预计算，通过定义 cube 模型，将结果预计算保存,之后当 SQL 请求过来直接可以以查表的方式获取结果，使用预计算的一个形象的类比就是 九九乘法表，大家都知道，乘法是加法的简化版本，如果你背熟了九九乘法表，下一次做乘法的时候,就可以直接得到结果。
kylin 就是一个帮你记住 “九九乘法表” 的工具, 让你在使用 SQL 查询的时候,能够直接拿到结果,能够在O(1) 复杂度下得到计算结果。
ClickHouse 是 MPP 架构的列式存储 RDBMS (关系型数据库),通过极致使用 CPU 的性能达到高性能的 OLAP 分析。