我最近看了一篇文章，名为《开源项目的正确打开方式》，文章中把开源项目的研究分成了三个阶段：选、用、修改。
一是怎么选开源项目，包括满足业务需求，具备运维能力，项目基本成熟，团队靠谱，社区活跃等等；
二是怎么用开源项目，包括深入研究仔细测试，做好应急以防万一，小心应用灰度发布，结合业务场景做好参数调整等等；
三是怎么修改开源项目，就是保持纯洁加以包装，发明适合自己的轮子。
目前我们团队处于第二阶段，我希望未来我们能够有更多的成熟经验，也能够为 Kylin 社区做一些贡献。
我们为什么选择 Kylin
首先，我们的数据规模决定要选择高效的处理技术。
北京移动的用户规模超过两千万，每天入库的原始数据超过三百亿条。经过处理后入库的数据是 3TB，而集群规模是 400TB 存储；每天执行的任务超过 800 个，其中大概有 600-700 个是属于临时产生的任务，所以我们的集群很繁忙。如果不选择高效的数据处理技术，将无法满足分析需求。Kylin 可以在夜间非忙时进行一些预计算，这样可以满足一些临时任务的数据需求，从而提升集群的工作效率。
我们选择 Kylin 的第二点原因是数据需求的困境。
这两年，分析人员、优化人员对数据的临时性查询越来越多，探索性数据需求越来越旺盛，我们需要找到一个方法来满足这类需求。首先，我们寻求固定化报表的解决，相信大家都会去做。我们也是原来做了很多报表放在 MySQL 里供查询。但这样做非常不灵活，开发周期缓慢，而且经常出现需求变更和需求不明确的情况，所以报表只适用于固定化场景的情况。
使用 Hive 和 Spark Sql 可以满足探索性数据分析的需求，但 Hive 速度较慢，Spark Sql 对内存资源要求很高，不适合多并发。如果应用的场景是数据来源固定，但是查询不固定且要求速度时，Kylin 就是一个选择了。
我们选择 Kylin 的第三点原因是它部署速度快，查询速度快。
如果了解 Kylin 的话就知道，Kylin 建立一个项目只需要简单几步：选定事实表，选定维度，选定测量值，选定好过滤条件，再把一些优化条件设定好之后，这个项目基本就建立完成了，学习成本相对比较低。
从查询速度上而言，我做过一个测试，原始数据大小 103GB，条目数 11 亿，任务是统计用户数。我用 Hive 测试，任务花费 1522 秒，Spark Sql 测试是 125 秒，用 Kylin 测试用时 3.43 秒。
诚然，Kylin 预计算也要花费时间和资源，但它是在晚上闲时进行的，所以当应用这个预计算结果足够多时，之前预计算的花费也是值得的。
使用 Kylin 的应用场景
首先介绍下我们的离线平台的架构变化。
下图左半部分是应用 Kylin 之前的架构，前台查询都基于 MySQL，底层数据是抽取后放入到 MySQL。个人认为这是一个割裂的架构，即大数据平台和前台查询模块不是一体的。我们也曾尝试把前台查询对接到 Hive 上，但效率比较低。下图右半部分是我们现在的架构，Kylin 可以有效的衔接前后台。
接下来介绍一下我们的第一个应用场景。
下图是用户上网统计表的字段说明，蓝色字段是这个表的维度，绿色字段是测量值。首先是统计报表，即基于日期、时间等八个维度统计用户上网的流量和、次数和等等。
在实践中，我们发现用户 ID 这个维度最好不要放到项目中，原因是 Kylin 不推荐基数高的字段作为维度，而我们 ID 的基数是 2000 万以上。那如果应用场景就是基于用户 ID 的该如何处理呢？我们的做法就是把用户上网的统计表全部八个维度一起作为一个维度来看，从而避免了单一维度基数过高的问题。
当我把 ID 作为输入条件时，查询结果就是原始表中符合条件的记录，这样基于这个表的各种灵活查询场景都可以满足了。
下图是两个子场景的一些统计数据，原始的数据是 47GB。统计报表任务执行时间是 80 分钟，详单任务执行时间是 51 分钟，都是在白天忙时执行的。第一个任务膨胀率是 36%，第二个任务膨胀率是 47%，即两个任务相加产生的预计算结果数据小于原始数据。
第二个场景比较有意思，业务人员的诉求是查询到不同方向的流量信息，就像一个交通路口，我们想分别统计到东、南、西、北各个方向上的流量是多少。
下图就是这个表的主要字段说明，它是一张宽表，有 40 多列。这个表需要特别说明的是 Hostname 的基数超过五百万，Rate 取值范围是 0.00-100%，而各个方向上流量的数值就更加离散了，从 0 到几亿。这么多维度，数值离散，再加上某些字段的基数很高，为我们设计查询造成了困难。
通过和业务人员了解需求，其核心诉求是明确在各个方向上是否产生过流量，所以我们对原始数据进行了重新设计，为各个方向设计了 Flag 字段：就是这个方向只要有流量，我就把 Flag 变成 1，如果没有流量，Flag 就变成零。
通过这么设计后，我们大部分查询可以将时间控制在 20 秒以内，基本满足需求；但范围查询，如查询成功率大于 90.00% 的情况，执行时长超过 200 秒，无法满足业务查询需求，这种类型的查询目前用 Spark Sql 满足。可以说 Kylin 可以支持我们 70%-80% 的 OLAP 分析。
使用 Kylin 时应注意哪些问题
接下来我想分享一下使用 Kylin 时的注意事项，实际上就是我们曾经踩过的“坑”。
第一，设计好你的原始数据：首先要处理好脏数据，不要把过多的数据处理工作让 Kylin 来完成；再者是原始数据表字段类型的选择，测量值要选择 Double 而不是 Float 型；还有就是要控制测量值长度的控制范围。
第二，设计好你的 Cube。在设计查询任务时，要首先思考一下——真的所有维度都需要吗？这个问题不仅是问你的，也是问你能接触到的业务人员的。
这里分享一个我们的惨痛经历：我们第一次尝试建立 cube 时，有两个非常高基数的维度，分别是两千万以上和三百万以上，建立 cube 的任务执行了 8 个小时，数据膨胀了 28 倍不止（详见下图）。
从我了解到的情况，Kylin 的 cube 膨胀率一般不会超过 50%，可见这是设计 cube 的问题。最终我们这个需求分拆为两个 cube，膨胀率和不到 100%，查询速度也满足需求。
第三，选择合适的维度、测量值类型。举个例子，我们的一个应用场景里有三个维度分别是应用大类（比如门户网站）、应用小类（比如新浪）和 Host（www.sina.com），这三个维度是有层级关系的，所以在选择维度时就不要用 normal 而应该选择 hierarchy。还有就是理解每个参数的信息，好好理解 Cube 建立和设计的思想。比如某个维度基数超过两千万时，它就不适合用字典，只需要规定下其长度就好。
基于 Kylin 的前景规划
最后讲一下我们的规划：首先，将 Kylin 升级到 1.5 版本，支持 TopN 功能。我们当前的版本是 1.2，当基于某些基数较高的维度复杂查询时，就会出现下图的报错。其实，对于基数较高的查询场景，可以通过不同的 TopN 加排序来满足。
第二个规划是重新思考 Cube 引擎的选择。我们有一些应用场景是要快速回溯很近一段时间的数据，比如投诉和故障的信息。这种需求场景的查询是很不确定的。而我们每天数据量级是几百亿条，天粒度来执行 Kylin 是无法满足需求的。现在 Kylin 已经解耦 MapReduce，我们正在考虑采用 Spark Streaming 作为运算引擎，采用 micro cube 的方式实现准实时的 OLAP 分析。
第三个规划是要设计符合需求的拖拽前台界面。原因很简单：一是支持探索性数据查询。作为一个开发人员，你一定希望自己设计的查询系统用户黏性大，采用拖拽式方便用户使用；二是规定化前台界面，屏蔽后台技术细节，避免低效的查询出现。
最后，我们会持续关注 Kylin 的发展变化。目前，Kylin 一般只支持 15 个维度，而我们的一些应用场景是远远大于这个限制的，我们怎么基于宽表的 OLAP 查询，怎么更快更好的查询到数据？我们想把 Kylin 应用到我们的标签业务上，这就要求系统支持灵活多变且具有一定的时效性，我们该如何做到？这些问题都需要在进一步的学习和交流中找到答案。