一是怎么选开源项目，包括满足业务需求，具备运维能力，项目基本成熟，团队靠谱，社区活跃等等；
二是怎么用开源项目，包括深入研究仔细测试，做好应急以防万一，小心应用灰度发布，结合业务场景做好参数调整等等；
三是怎么修改开源项目，就是保持纯洁加以包装，发明适合自己的轮子。
目前我们团队处于第二阶段，我希望未来我们能够有更多的成熟经验，也能够为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应用到我们的标签业务上，这就要求系统支持灵活多变且具有一定的时效性，我们该如何做到？这些问题都需要在进一步的学习和交流中找到答案。
提问环节
提问：您刚才提到的基数较高的维度复杂查询时报错的问题，能再介绍一下吗？
回答：我们的应用场景是基于域名的统计，想要把域名按照流量、次数、人数进行汇总排名，由于域名量超过200万，Kylin在扫描全部数据时会导致内存不足的问题，所以引起了这个报错。
提问：在我们的使用场景中也遇到了类似的问题，所以一直没有办法应用Kylin。
回答：这个问题其实可以利用TopN来基本满足需求，因为很多时候我们只关心80%的情况，或者通过逆序来查询剩余的数据，我们将尽快升级到1.5版来检验TopN功能。
扫一扫
506
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
