通过和其它同学交流，有一个感觉就是大家都觉得Kylin还不错，但并不是特别有信心，或者不知道非要用它的理由是什么，或者它和其它系统的对比是什么样的？这里也有部分测试结果可以和大家分享。
整个测试基于SSB的数据集，也是完全开源的，实际上是专门用于星型模型OLAP场景下的测试。整个测试数据集是非常标准的五张表，可以配置一些参数决定生成的数据集规模，然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括：Presto，Kylin1.3，Kylin1.5和Druid。数据规模包含千万、亿、十亿三种规模；维度个数为30个；指标个数为50个。典型的测试场景包括：上卷、下钻，和常用的聚合函数。
这里挑选了典型的五个查询场景：一个事实表的过滤和聚合；五张表全关联之后的查询；两个Count Dstinct指标和两个Sum指标；后面两个查询包含8~10个的维度过滤。
这张图是千万规模下的一个测试结果，包括了四个系统。我们在用Kylin或者其它系统之前没有专门用于OLAP分析的引擎，只能用通用的。Presto是其中表现非常好的引擎，但是在OLAP这种特定的场景下，可以看到不管跟Kylin还是Druid相比差的都比较多，所以前两个测试包含了Presto结果，后面就没有包含了
这里比较有趣的现象是在第三个查询，Kylin1.5反而比Kylin1.3要慢一些。这个地方我们还没有搞清楚是什么原因，后面会详细的看一下。当然这个也可以证明数据没有修改过，是真实的测试数据。
从后面的两个查询上可以看到，在千万规模的级别，和Druid还是有比较大的差距。这主要和它们的实现模式相关，因为Druid会把所有的数据预处理完以后都加载到内存里，在做一些小数据量聚合的时候，可以达到非常快的速度；但是Kylin要到HBase上读，相对来说它的性能要差一些，但也完全能满足需求。
在亿级的规模上情况又有了变化，还是看后面两个查询，Kylin1.3基本上是一个线性的增长，这个数据已经变得比较难看了，这是由于Kylin1.3在扫描HBase的时候是串行方式，但是Kylin1.5反而会有更好的表现，这是因为Kylin1.5引入了HBase并行Scan，大大降低了扫描的时间。Kylin1.5的数据会shard到不同的region上，在千万量级上数据量还比较小，没有明显的体现，但是上亿以后，随着数据量上升，region也变多了，反而能把并发度提上去。所以在这里可以看到Kylin1.5表现会更好。这里也可以看出，在数据量成数量级上升后，Kylin表现的更加稳定，在不同规模数据集上依然可以保持不错的查询性能。而Druid随着数据量的增长性能损失也成倍增长。
刚才是在性能方面做的一些分析，其实对于一个系统来说，性能只是一个方面，除此之外，我们也会去考量其它方面的情况，主要有以下四点。
第一，功能的完备性。刚才提到我们所有的数据必须是精确的，但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如Druid性能表现确实更好，但是它去重计数没有办法做到精确。
第二，系统的易用性。作为一个平台服务，不仅要把系统用起来，还要维护它，因此要考虑部署和监控的成本。这方面Kylin相对来说也是比较好的。Druid一个集群的角色是非常多的，如果要把这个系统用起来的话，可能光搭这个环境，起这些服务都要很长的时间。这个对于我们做平台来讲，实际上是一个比较痛的事。不管是在部署，还是加监控的时候，成本都是相对比较高的。另外一个查询接口方面，我们最熟悉或者最标准，最好用的当然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL，当然现在也有一些插件，但是在功能的完备性和数据的效率上都不如原生的支持。
第三，数据成本。刚才提到了有些数据需要做一些预处理，比如表的拉平或者表达式列的变换，除此之外还有一些格式的转化，比如有的系统只能读TEXT格式，这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询，这个时间中间有多长。数据存储和服务的时候需要多少机器资源，这个都可以归为数据成本，就是使用这个数据需要付出的成本。
第四，查询灵活性。经常有业务方问到，如果Cube没定义的话怎么办？现在当然查询只能失败。这个说明有的查询模式不是那么固定的，可能突然要查一个数，但以后都不会再查了。实际上在需要预定义的OLAP引擎上，这种需求普遍来讲支持都不是太好。
这张图是各个系统全方位的一个对比。
从查询效率上看，这里表现最不好的就是Presto，表现最好的应该是Druid和Kylin1.5，两者不相上下。从功能完备性上来讲，确实Presto语法和UDF等等是很完备的，Kylin会稍微差一些，但比Druid好一点。
系统易用性上区别不是太大，这里主要考虑有没有标准的SQL接口或者部署成本高不高，用户上手能不能更快，目前来看Druid接口上确实不够友好，需要去翻它的文档才知道怎么去写查询的语法。
在查询成本上，Presto是最好的，因为几乎不需要做什么特殊的处理，基本上Hive能读的数据Presto也都能读，所以这个成本非常低。Druid和Kylin的成本相对较高，因为都需要提前的预计算，尤其是Kylin如果维度数特别多，而且不做特别优化的话，数据量还是很可观的。
最后从灵活性上来讲， Presto只要SQL写出来怎么查都可以，Druid和Kylin都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。
刚才比较客观的对比了几个系统，接下来再总结一下Kylin的优势。
第一，性能非常稳定。因为Kylin依赖的所有服务，比如Hive、HBase都是非常成熟的，Kylin本身的逻辑并不复杂，所以稳定性有一个很好的保证。目前在我们的生产环境中，稳定性可以保证在99.99%以上。同时查询时延也比较理想。我们现在有一个业务线需求，每天查询量在两万次以上，95%的时延低于1秒，99%在3秒以内。基本上能满足我们交互式分析的需求。
第二，对我们特别重要的一点，就是数据的精确性要求。其实现在能做到的只有Kylin，所以说我们也没有什么太多其他的选择。
第三，从易用性上来讲，Kylin也有非常多的特点。首先是外围的服务，不管是Hive还是HBase，只要大家用Hadoop系统的话基本都有了，不需要额外工作。在部署运维和使用成本上来讲，都是比较低的。其次，有一个公共的Web页面来做模型的配置。相比之下Druid现在还是基于配置文件来做。这里就有一个问题，配置文件一般都是平台方或者管理员来管理的，没办法把这个配置系统开放出去，这样在沟通成本和响应效率上都不够理想。Kylin有一个通用的Web Server开放出来，所有用户都可以去测试和定义，只有上线的时候需要管理员再review一下，这样体验就会好很多。
第四，最后一点就是活跃开放的社区和热心的核心开发者团队，社区里讨论非常开放，大家可以提自己的意见及patch，修复bug以及提交新的功能等，包括我们美团团队也贡献了很多特性，比如写入不同的HBase集群等。这里特别要指出的是核心团队都是中国人，这是Apache所有项目里唯一中国人为主的顶级项目，社区非常活跃和热心，有非常多的中国工程师。特别是当你贡献越来越多的时候，社区会邀请成为committer等，包括我自己及团队成员也已经是Apache Kylin的committer。同时也非常高兴看到以韩卿为首的Apache Kylin核心团队在今年初成立的创业公司Kyligence，相信可以为整个项目及社区的发展带来更大的空间和未来。
在未来工作方面，我们认为Kylin还有一些不理想的方面，我们也会着力去做优化和改进。
第一，精确去重计数。刚才提到只支持Int，接下来有一个方案会支持所有的数据类型，能够扩展大家使用精确去重的场景范围（补充说明：目前该功能已在1.5.3版本中实现）。
第二，在查询效率和Build效率上也看到了一些可以优化的部分。比如队列资源拆分，我们所有计算集群的资源都是按照业务线核算成本的，但是现在Kylin本身还不太支持，这个我们也会抓紧去做，相信在很多公司也有类似的需求。还有大结果集和分页。当结果到了上百万的量级时，查询时延会上升到几十秒。同时在查询的时候有可能需要排序并且分页，就是把结果全读出来之后，根据其中的一个指标再order by，这个开销也是比较大的。我们也会想办法进行优化。
最后，Kylin1.5之后有明细数据和Streaming特性出来，后面也会做这方面的尝试。
Q1：之前在Build的时候一直提到成本的问题，能给出一个估计值吗，如果一百亿的数据，需要多少时间？
孙业锐：有一个简单数据，大概是两亿行数据，维度的话有十四五个，Build时间不超过两个小时，Build出来的数据是五六百G。
Q2：原始值是多大？
孙业锐：把这个数据抽出来之后，就是只参与Build的数据压缩后只有几个G。
Q3：Kerberos认证失效的问题你们遇到过没有？
孙业锐： Kerberos认证完之后，会在本地临时目录下有一个ticket问题，每天在外部定时刷新一下就可以了，服务是不用停的。
主持人：我补充一下我们为什么选择SQL接口？Kylin解决的是真正的用户面是谁，其实是业务人员和分析人员，他只会SQL，几乎那些人很少说再学个JAVA，所以能给他一个标准的SQL这个是让他上船最快的事情。其实这就是易用性很重要。
刚才看到了Kylin在千万级规模和亿级规模的表现，如果数据规模上到十亿，百亿，千亿的时候，我相信Kylin应该会秒杀所有一切。因为我们现在有另一个案例，生产环境上千亿规模的一张表，可以做到90%查询在1.8秒以内。另外我觉得非常好的一点，像美团、京东这边贡献了很多patch，其实就是把需求提出来，大家可以一起来做。
