锐浪报表数据源access_kylin+SuperSet实现实时大数据报表的快速开发

最近我的团队将报表计算引擎从阿里的OLAP分析中间价迁移到了kylin上，解决了非常多的问题，将一些我们的解决方案分享出来，希望对读者或者在用kylin的人有所帮助。

一、之前现状和问题

之前我们系统的报表都是基于阿里云的相关组件开发的，业务系统在业务代码中将数据同步到消息队列中，然后阿里OLAP分析中间件再从消息队列同步数据，再基于OLAP分析中间价提供的api开发查询逻辑，前端还要开发报表展示的代码。这种方式上线以后，随着数据量的不断增长暴露出了很多缺陷。

1. 经常会出现消息丢失的情况，或者系统变慢的情况。

2. 由于购买的阿里云的服务，相关中间件对我们来说一直是一个黑盒，问题很不好定位和解决，而且很多问题的解决依赖于阿里云，响应时效不是很及时，长此以来积累了大量的报表问题，客户抱怨声不断。

3. 开发工作量庞大，产品人员设计好一张报表以后，要上线要苦等一个多月的开发时间，而且遇到问题还无法上线。

基于以上问题我们觉得再继续用阿里的OLAP中间件作为我们的报表计算引擎，后续问题会越来越多。因此我们尝试使用新的报表引擎，这个报表引擎对我们一定不是一个黑盒。

二、报表计算引擎的选择(kylin)

基于以上几个问题，在对tidb，druid，kylin，mdrill等各种开源系统进行调研以后，最终选择了kylin作为我们的报表计算引擎，一方面是sql支持度相对来说比其他系统好比如精确distinct功能，一方面是和hadoop的几个组件集成得非常好，tidb和已有hadoop组件集成得不大好，需要重新搭建集群代价很大。还有就是基于java开发很符合团队的技能特点，可以根据业务特点定制我们自己的版本。

三、数据分钟级延迟问题解决(canal+flume+kafka)

选好了kylin这个报表计算引擎后，还需要解决的就是我们报表计算的数据延迟最大也要到分钟级别，这个可以通过kylin的kafka数据源来实现，配置方式见下面的链接。

http://kylin.apache.org/cn/docs/tutorial/cube_streaming.html

但是使用kafka还有一个问题就是业务系统的数据怎么实时的传输到kafka呢，之前都是在业务系统中编写数据发送逻辑到消息队列中，这种方式和业务系统耦合非常大，随便改点逻辑都需要依赖于业务系统上版本周期很长，沟通成本很大。因此我们采取了用阿里巴巴开源的canal抓取mysql binlog的方式，实时的去抓取mysql的增删改查数据，这种方式要开启mysql的binlog。Canal项目的主页：

https://github.com/alibaba/canal

有了canal抓取并解析binlog以后，还有一个问题要解决的是怎么让canal抓取到的数据可靠的传输到kafka中，基于canal和kafka的api自己开发的方式，成本很大，而且要考虑高可用，容错，扩展性等问题，再者我们的时间和开发资源也非常有限，因此我们基于flume的接口开发了一个canal source，充分利用flume的灵活性，扩展性，高可用，负载均衡和容错等特性，同时也可以和已有的source，channel和sink组件随意组合。

这样通过canal+flume+kafka和kylin的streaming cube特性，我们就很好的解决了数据分钟级别的延迟问题。

四、数据实时更新和删除问题

下一个要解决的问题就是数据的更新和删除的问题，这个我们是基于业务逻辑来解决的，当然我们在实现上会考虑好业务场景的通用性，每次更新和删除数据我们都不会去修改原来的数据，而是往kafka中插入新的数据并标记这条数据是删除，还是更新，并记录前后值的变化，同时在接入层面尽可能对数据进行去重处理，降低后续cube构建和sql编写的难度。

由于我们在数据层面和原来的变化了，因此我们还需要在sql层面进行改写，当然改写后的sql肯定要利用上kylin的预计算特性，否则查询速度很慢。

在解决数据实时更新和删除问题上，耗费了我们大量的时间，前后也讨论过很多种方案，而且实现起来需要对kylin的预计算特性有深入的了解，对维度设计要利用kylin的特性充分的进行精简，否则会走弯路。

下面是我们的model和cube界面：

五、并发查询问题

接下来就是并发查询的问题了，由于kylin本身就带有cache特性，负载均衡而且采用的是预计算模式，因此应付并发上很好办，负载均衡这一块开始准备用nginx做负载均衡，后来觉得自己维护还是很麻烦，而且我们其他系统已经在使用阿里的SLB做负载均衡了，因此最终我们还是用SLB来做负载均衡。

六、使用superset报表开发方式

最后要解决的一个问题就是开发效率的问题了，之前我们的报表开发后台首先要手工编写大量的sql，然后使用spring和mybatis编写大量的业务逻辑，并通过微服务的方式暴露接口，然后前端再根据接口，编写前端展示代码，而且移动端，电脑端都要写一套。

这种方式开发周期长，耗费人力大，而且工作挑战不大也比较枯燥，大家都很痛苦，产品等得痛苦，开发开发得痛苦。

因此我们调研了几个前端的工具，后来发现了airbnb开源的superset这个好东西，操作简单，图表美观，而且单表不支持的情况可以通过自定义sql来支持。最关键的是kylin对它进行了很好的集成，链接如下：

http://kylin.apache.org/blog/2018/01/01/kylin-and-superset/

还有一个关键点是superset的图表可以通过iframe嵌入到网页中数据不是静态的而是随时更新的，还支持在电脑端和手机端展示，对数据和图表的权限控制也做得非常到位。基本满足了自助开发，然后嵌入到页面中展示的要求，可以大大节省我们的报表开发周期和开发工作量，甚至可以做到让产品自助拖拽式开发。

Superset Kylin数据源配置：

图表开发：

Iframe嵌入：

七、最终的架构

八、一些实现细节

1. canal主备切换的时候数据会重复，这个问题需要在接入层面或者在canal层面注意，我们是在接入层面监测到切换后对最近数据进行实时去重（自己编写flume source带去重逻辑，会缓存一个可配置时间段的数据，因为canal切换很快所以不需要缓存很长时间，而且用storm里面的timecachmap不会影响到性能）。

2. kylin不支持hadoop和habse的高版本，之前我尝试把我们的集群升级到了hdp3.0版本（hive3.1，hadoop3.0，hbase2.1），也尝试修改kylin源码来适配高版本，但是改到后面发现工作量非常大，时间来不及只好又把集群回退到了hdp2.6.4版本，后面把kylin修改好以后再升级集群。

3. 查询一定要利用kylin的预计算特性否则时间会很长，尤其是子查询很可能会导致利用不上预计算特性。

4. 设计cube的时候维度一定要尽量精简。

5. Kylin的distinct有精确distinct和非精确的，精确的计算要占用非常大的内存。

6. steaming表是不能和lookup表进行join的。

7. superset支持iframe嵌入要修改一些配置权限配置和跨站访问配置，否则不能展示或者要登录。

跨站访问修改这个配置：

HTTP_HEADERS = {'X-Frame-Options': ' '}

免登录访问加入以下配置：

PUBLIC_ROLE_LIKE_GAMMA = True

Public 角色的permissions里把以下三个加上

can explore on Superset
can explore json on Superset
all database access on all_database_access

。