背景：B公司，前美纳斯上市公司，上亿App用户，近年来数据呈爆发式增长，每天行为日志达10T，原有的hive+mysql（查询太慢，存储太大），hive+impala（界面不友好，需要写sql语言，门槛较高，不方便运营人员查询数据，对多维数据查询较慢），已经满足不了当下需求，急需要一个能支持大规模数据查询，速度又快，使用零门槛的查询服务，几套方案选择后，最终选择了Kylin，主要看重的是它支持大规模数据快速查询，而且是兼容我们现有Hadoop框架的，这对我们开发和使用来说成本很低。

基本情况：

2016年初，开始调研，上半年开始部署测试试用，截至17年底，生产环境每天cube要处理数据总条数为150亿条，原始日志大小每天约450G（去重压缩后），纬度16个,单表膨胀率在4%内，单表查询60亿条数据，延迟5秒返回结果。我们部署了kylin集群模式，一个all节点，3个query查询服务节点（32G内存，8核cpu），Nginx实现负载均衡，hbase集群只用了10台机器，所以很多数据只存了30天的。上线初期遇到很多问题，没有达到预期效果，经过慢慢优化和实践，运行2年了,现在运行比较稳定，支撑了我们80%数据业务查询需求，性能也基本符合我们的预期了。其实kylin部署安装很简单，主要是在cube设计优化技巧方面需要花功夫。

​

查询性能和cube性能优化

我们刚开始也走过一些弯路，在创建cube的时候，不了解高级设置里的奥秘，配置的cube，运行时间非常长，膨胀率达300%，非常占用空间，前台查询没有预想中那么快，经过查询文档和实践，我们对cube进行了一些优化：

一、Aggregation Groups优化

Includes : 表示需要参加group by 的维度，也是主要参与聚合的维度，业务需要经常查询显示的字段可放这里。这里如果放太多字段，占用空间较大，预计算时间较长，膨胀率也较高。

Mandatory Dimensions ：高频维度，必须要或经常要用到的维度放在此地，会提高查询速度。

Hierarchy Dimensions ：有层级关系的维度，如年、月、日

Joint Dimensions ：不常用到的维度放在此处，可以降低存储和计算量。

​

16个维度，9个维度放在Includes里，3个维度放在Mandatory Dimensions里，4个放在Joint Dimensions里，膨胀率在2%内。

​

二、Rowkeys优化

Rowkeys的顺序对查询性能有一定程度的影响，一般把过滤条件大的放在前面，如：时间，用户类型等，不需要过滤的放后面：如手机机型，系统版本等，这样做的目的是最大化先把查询扫描范围缩小，提高查询速度。这些配置都对业务的了解和数据结构有一定的了解才行，因为最终都是为了业务查询而设计的。

三、正确的Segment策略​

影响查询速度的还有一个比较重要的因素是Segment的多少，如果你的数据是按日期增量更新，产生的Segment会越来越多，如果不进行定期合并，查询的速度会因为数据量的增大而变慢，kylin的刷新设置里给我们提供了很好的策略，默认自动合并策略是7,28，代表的是每隔7天合并最近7天的Segment，每隔28天合并前面7天合并后的Segment，这样做的目的是hbase表不会越来越多，前端查询的时候也不用扫描那么多表了，如：7天内的数据扫描一个表就够了，大大提升了查询速度；另外一个是如果数据非常大，又不是非常重要，可以设置保留天数，比如只保留30天的构建数据，这样Segment只有30天的记录存在，这样也不会使Segment越来越多，从而提高查询速度。

集群模式更能提供查询性能

刚开始我们也是单机模式，用一台机器既做cube构建，同时又做查询服务，在cube忙的时候，服务器内存和cpu非常高，这个时候查询请求多的话，往往会造成查询超时或失败，严重影响前台体验，隔三差五收到产品、运营人员吐槽和投诉报表查询失败，迫于形势压力我们做了集群模式，目前集群模式是一台all集群，3台query服务器，用Nginx负载均衡，效果很明显，all节点主要负载cube构建去了，查询的请求被分摊到3台query机器上，忙的时候也没有出现过查询超时或失败的情况了。

Kylin集成Superset可视化展示平台

搭建Superset（前身是caravel），Superset是用python写的，安装的时候会碰到各种环境和python包的问题，搭建好了Superset后，让他支持kylin其实就很简单了，只需安装一个pykylin包就好了（这里感谢作者WuXiang，晓文兄的支持），这样就支持kylin数据源了，当然我们还顺便安装了mysql驱动包，mysql和kylin数据源就都支持可视化数据查询了。用superset的优点就是图形多样性，并且支持维度和指标自由组合，拉取自己想要的数据保存为数据图表，最后把把多个数据图表放在一个页面里，这样每天只要打开这个页面就可以看到自己想要的数据了。被运营和产品同事堪称为周报、月报数据神器。

​

​

我们走过的弯路

1）Cube的设计不合理导致cube膨胀率高，构建时间长，占用空间大等问题，后来仔细研究了cube的高级设置和不段的测试，才有了现在的比较合理的配置。

2）内存不足，导致服务不稳定，经常被挂，kylin还是比较耗内存的，尤其当你要构建的数据量比较大的时候，所以我们后来配置了32G的内存服务器，KYLIN_JVM_SETTINGS的-Xmx23g配置了23G，基本就能满足了。

3）Nginx负载均衡的时候，监听的端口号要对应好，因为我们自己封装了kylin的jdbc查询数据连接池，所以Nginx里的配置监听端口号的时候要跟这个连接池里面的url端口号一致，这个端口号不一定要7070，可以自己给一个其他的，只要能对应上就可以了。

平台存在的问题：

1）cube设计完后，跑了数据之后就不能修改了，因为难免后面会加字段或修改配置什么的，这样一次性的设计不是很人性化。

2)  不能删除任意SEGMENT，只能删除最新的那个，不方便处理有问题的SEGMENT重新刷数据。（有时候重刷不行，必须要删除才行）