做网站加班,网站项目意义,北京网络公司网站,青春网页制作素材最近我的团队将报表计算引擎从阿里的OLAP分析中间价迁移到了kylin上#xff0c;解决了非常多的问题#xff0c;将一些我们的解决方案分享出来#xff0c;希望对读者或者在用kylin的人有所帮助。一、 之前现状和问题之前我们系统的报表都是基于阿里云的相关组件开发的#x…最近我的团队将报表计算引擎从阿里的OLAP分析中间价迁移到了kylin上解决了非常多的问题将一些我们的解决方案分享出来希望对读者或者在用kylin的人有所帮助。一、 之前现状和问题之前我们系统的报表都是基于阿里云的相关组件开发的业务系统在业务代码中将数据同步到消息队列中然后阿里OLAP分析中间件再从消息队列同步数据再基于OLAP分析中间价提供的api开发查询逻辑前端还要开发报表展示的代码。这种方式上线以后随着数据量的不断增长暴露出了很多缺陷。1. 经常会出现消息丢失的情况或者系统变慢的情况。2. 由于购买的阿里云的服务相关中间件对我们来说一直是一个黑盒问题很不好定位和解决而且很多问题的解决依赖于阿里云响应时效不是很及时长此以来积累了大量的报表问题客户抱怨声不断。3. 开发工作量庞大产品人员设计好一张报表以后要上线要苦等一个多月的开发时间而且遇到问题还无法上线。基于以上问题我们觉得再继续用阿里的OLAP中间件作为我们的报表计算引擎后续问题会越来越多。因此我们尝试使用新的报表引擎这个报表引擎对我们一定不是一个黑盒。二、 报表计算引擎的选择(kylin)基于以上几个问题在对tidbdruidkylinmdrill等各种开源系统进行调研以后最终选择了kylin作为我们的报表计算引擎一方面是sql支持度相对来说比其他系统好比如精确distinct功能一方面是和hadoop的几个组件集成得非常好tidb和已有hadoop组件集成得不大好需要重新搭建集群代价很大。还有就是基于java开发很符合团队的技能特点可以根据业务特点定制我们自己的版本。三、 数据分钟级延迟问题解决(canalflumekafka)选好了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的灵活性扩展性高可用负载均衡和容错等特性同时也可以和已有的sourcechannel和sink组件随意组合。这样通过canalflumekafka和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.1hadoop3.0hbase2.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 TruePublic 角色的permissions里把以下三个加上can explore on Supersetcan explore json on Supersetall database access on all_database_access。8.负载均衡模式下kylinserver session要共享安全验证用默认的会有多线程更新冲突要修改。九、 写在后面时间仓促整体方案写出来了具体细节和遇到的问题写得不够详细有需要进一步了解的可以留言交流。后续报表这一块我们会进一步做到自定义报表到时的维度挑战是一个更大的问题肯定需要进一步的优化当前方案。
