【案例】数据量猛增，BI分析效率过低怎么破？

近日，Apache Kylin Innovation Meetup 在上海成功举办，有近200位小伙伴来到了现场。这次会议特别邀请到了金融、互联网等行业的技术伙伴分享了 Kylin 在行业中的实操应用 。今天将首先与你们分享演讲嘉宾王颖卓，中国银联数据服务团队负责人的主讲内容。您将了解到，金融机构基于传统架构的BI分析业务遇到了哪些挑战，以及这些问题如何随着 Kylin 的引入被逐一攻破。

“ Kylin 的引入给咱们带来了切实的好处， 如今整个报表分析的数据准备时间，从过去的8小时减小到2小时。”

——王颖卓， 中国银联数据服务团队负责人，Kylin用户

金融机构在BI分析中遇到了哪些挑战？

首先简单介绍一下咱们公司数据仓库的背景，2008年公司开始建数据仓库，2009年上线。这个数据仓库运转到如今已经有10个年头，采用的是比较传统标准的架构，数据仓库主体用的是IBM DB2。

在 BI这块咱们引入了 Cognos 做为总的 BI 工具，当时，整个金融界都比较流行 Cognos。在这 10年内，包括 Cognos 等一些其余商业版的多维分析工具，确实给企业分析带来了很大的便利。时过境迁，如今到了大数据年代，数据量愈来愈大， Cognos 面临了一些挑战， 咱们数据量的增加， 10年间涨了10倍；在最近两三年，咱们的业务量又更加迅猛地增加，这对数据分析的挑战是巨大的。

Cognos 从整个功能、架构上来说， 都是基于单机版的，效率很低；所以咱们在 Cognos 的基础上研发了一些工具，包括调度、Cube 刷新，Cube 访问等等，这其中申请的专利就有好几个。这些工具核心仍是基于单机的运转，因此说在构建上它的扩展性很差，一个体现是，刷 Cube 的时间愈来愈长。

例如一些每日刷新的 Cube，业务分析用户须要基于这些日 Cube 要出当日报表， 可是鉴于如今的数据量和处理能力，很难在他们预期的时间内达到要求，咱们技术团队的压力很大，作了不少工做，想了各类各样的办法在调优，可是收效仍然低于预期。

以上是咱们用 Cognos 碰到的一些挑战，正是由于这个缘由，咱们在2015年在一个技术分享活动上，咱们和 Apache Kylin 第一次触电。

Apache Kylin的性能和价值

在下图能够看到，Kylin 各方面的性能和 Cognos 相比有了大幅的提升，这些数据都是实际中的一些例子。从使用资源来说，大数据平台的资源仍是比较富裕的，Kylin 整个架构比较强调读写分离，目前咱们在 Kylin 上投了20多台机器进行 Cube 的构建和查询。

首先看一下查询，96%的查询在10秒以内返回；除非是很是大、复杂的条件可能要到20秒左右。 而之前咱们的 Cognos 从打开到展现，拖拉拽创建一个基本的报表要接近一分钟，Kylin 对用户的体验和感觉的提高是很是巨大的。

从整个构建性能上来说， Kylin 相比于 Cognos 也有巨大的提高。由于 Cognos 是单机，没有办法利用分布式集群资源，必须是一个比较独立的 Cognos 在跑，天天跑8个小时以上。Kylin 的构建是在整个大数据平台之上，跟其余的批量计算共享集群资源，这个时候基本上是两个小时左右，就能够把整个 Cube 构建出来。

膨胀率是一个关键点，在测试环境上，效果不是很好，有10倍以上的膨胀。当时我有点犹豫，问题出在什么地方？后来跟 Kylin 团队有一个深刻的交流，发现是模拟的测试数据的特征和实际特征有出入。他们建议咱们用较为真实的数据在测试一下，获得的结果表现要好一些，膨胀率大概是3倍。并且3倍仍是由于后面会讲的高基维的引入引起了这点。

从膨胀率上来说，有几点能够跟你们分享，一个是在测试环境作测试的时候，当时是由于模拟的一些数据的分布状况跟实际不是彻底一致，引起了大量的膨胀率。另一个 Kylin 的模型上确实是有必定的讲究，经过一些模型优化，咱们确实有效地把 Kylin 的膨胀率控制在3倍之内。

从总体上来说，经过对 Kylin 这个产品的引入，对咱们带来的好处是很是多的。

1. 如今整个的报表，之前8小时 Cube 如今2小时就能够出来，给咱们的小伙伴的指标是天天早上9点钟以前，要把昨天全部的数据作完，用户可以访问到，这个指标如今基本上彻底可以达到。
   
2. 从访问来说，基本上96%在10秒以内，彻底出乎用户的意料，用户进来谈笑之间数据就能够出来。
   
3. 一些高基维的引入，进一步下降了咱们开发压力、维护压力。

企业如何落地 Kylin

做为一个传统企业，引入 Apache Kylin 这样的开源软件，该怎么样引入？ 这个是从我我的的角度给你们作一个分享，不必定彻底对， 你们能够一块儿思考和讨论。对于金融机构来讲，去引入开源软件，追求的其实就是核心的四个字：自主可控。其次有三个方面的因素须要考虑。

• 用户体验
  

引入 Kylin 很是大的一点缘由，咱们能够把整个 Cognos 分析报表架在 Apache Kylin 上， 用户仍旧可在 Cognos 上进行拖拉拽，后台使用 Kylin 进行查询，用户习惯获得了100%原汁原味的保留 。咱们服务的是用户，因此用户的体验、感觉是很是关键的。

• 社区支持
  

原来用 IBM Cognos 的售后服务很是好，问题提出后，他们响应会很是快，邮件的方式或者是回访，他们会收集一堆的生产上的状况，一堆的报表。可是，问题仍是没发彻底解决。传统的商业产品，每每会面临这样的状况：态度很是好，但碰到一些具体问题快速解决的效率不高，另外一方面用户间相互交流的途径较少，相互启发式的最优实践经验分享不够。

一个很是 Open 的开源软件，其实对于咱们这样传统的金融机构来讲，可谓是一个美好的毒药。虽然都是开源的，社区也很是活跃，可是若是没有足够的开发人员、技术人员在里面的话，玩不转的。像如今大数据的社区很是活跃，多少企业在这个社区里有很好的主导权呢？从这个角度来说，Kylin 这个社区对咱们的帮助很大。这个社区很开放，同时 Kyligence 公司在这个社区里也起着一个很重要的主导权。咱们提出的问题，社区里的朋友会跟咱们作交流，Kyligence 公司也会以一个主要的代码贡献者的身份，提出很好的建议和意见 。

• 组件化
  

Kylin愈来愈庞大，它能够是一个完整的产品，能够把它拿回来做为一个BI去用。咱们在选 Kylin 的时候，更多的是看重它的组件化的特质。若是熟悉 Kylin 的应该知道，它既是一个产品也是一个计算组件，也有能够是一个存储组件。

咱们没有把Kylin当成一个完整的产品，而是把它当作一个组件。过去咱们讲“Intel inside”，在构建咱们本身的BI产品的时候，我有时候也说，”Kylin inside”，咱们看一下，什么叫作”Kylin inside”。

企业内部的大数据围绕着给用户服务，作BI，和数据提取的体系架构。这一圈基本上是自营的一些组件、安全、任务执行、资源控制，任务监控、访问控制；底层是很是熟悉的一系列的大数据套件包括 MapReduce、Spark、Impala、HBase，包括 EDW，因此整个外围的一圈给包在一块儿，做为一个统一的解决方案提供给用户，用户能够经过各类方式去访问数据、使用数据作本身的分析。

因此说 Kylin inside，包括咱们自营的 Tornado 数据加工服务，中间的 Kylin 做为一个比较核心的组件，是数据分析的支撑；同时还包括 Lightning 实时数据服务产品。

从这个角度来说，咱们并非说简单的把Kylin当一个产品引入而是做为一个组件的形式赋能到咱们产品上。

企业基于Kylin定制化BI开发

前面介绍一下为何从 Cognos 移到 Kylin 上来，在这个过程当中，咱们重点考量的是哪些点。接下来，我会向你们介绍，针对 Kylin 的外围，咱们作了哪些事情。

咱们基于 Kylin 商业版本 Kyligence Enterprise 作了一些二次开发，咱们选择企业版更看重的是商业服务。围绕着Kylin，咱们作了两方面的事情。最开始作数据时，基本上是以 Cognos 的方式在跑报表、数据。用户反馈，Cognos 太难了， 表结构不合理 。所以咱们推出了多维分析，经过拖拉拽方式就能作。拖拉拽几年，用户就又开始抱怨了，每天拖拉拽，开发效率过低。咱们有熟悉 Cognos 的人员，有作数据分析的人员，咱们遇到的新问题是， 能不能开放一些 Cognos 的接口给分析人员去使用？基于这样的状况，咱们两个都作。

在多维分析之上，咱们开发了一些工具，第一个简单的拖拉拽， 这个是仿照 Cognos 作的。后面有单个模型去建立多个分析。若是对这边有了解的话，用它作报表的话，Report打开来，须要同时打开多个Report，里面去搭载多个模型，按照如今的性能，一个模型下载下来，至少要半分钟，有的甚至是1分钟，因此说这个时候，不管对机器的影响，仍是电脑自己，至关于电脑开多个浏览窗口，对电脑的压力都仍是有的。因此说作了一个事情，单个模型，建立多个分析，包括用户自定义维度、参数和SQL之间的转换，在这边都作了一些开发 。

用户每每会说：我会写SQL，可是不懂大家的模型。对这种状况，咱们作了一个相似于SDK的工具，提示元数据，把表名、字段名弹出来，用户写SQL，而后验证SQL等；怎样的SQL才能跑，是有本身的一些逻辑在里面的，包括自定义一些UDF，有些时候直接把UDF传下去，可能传到 Kylin 里面，也有可能传到 Spark SQL 里面。有种状况也是，经过原生接口或者是SQL接口，或者是其余接口，把数据取过来在内存里，作二次处理加工，最终再给用户展示。像咱们这个SQL，不只基于Kylin，也会基于 Spark SQL或者是 Impala 去执行。

怎么能让咱们的多维分析相对比较平缓？或者说怎么让那些比较熟悉，或者是更加接受报表的用户，可以接受拖拉拽的这种形式？

咱们会在上面加自定义集，去自定义不少业务的场景，好比，对于咱们来说，从业务上来讲，定义公司不一样的业务线， 从数据层面来说，是有多个维度，甚至是维度里面不一样位置的组合，去来表明这些业务场景和业务含义。那么这个时候若是从报表上来看，就是反应了公司不一样业务条线的各种数据报表。

今天和你们分享了咱们为何开始使用Kylin，Kylin带给咱们的价值，以及围绕着Kylin咱们作了哪些开发集成工做，但愿对你们有所帮助；社区里有面临相同问题、挑战的伙伴也能够跟咱们进一步交流 。

Q&A

Q： 在使用Kylin，无论是企业版仍是商业版的过程当中，有朋友碰到报表常常变换的状况，好比说已经构建好的Cube，结果却发现指标须要变化，或者是维度须要增长，这个时候大家是怎么处理的？

A： 若是说真要变化，整个模型要重构，这个是没办法的。第一，基于多年Cognos的积累，咱们整个模型相对成熟 。第二，Kylin自己的能力值得承认，咱们尽量的会把更多的一些数据、维度放在模型里，例如把全部商户代码全构建进去，几百万、上千万的商户数据放在一块儿，怎么查、改，都逃脱不了这个范围，因此后面作了自定义数据集等 。因此有了kylin之后， 咱们对这些业务需求就更加有信心， 可以帮助业务人员解决，尽量的把咱们能想象到的场景放进去，只要Kylin能承担得了性能上的压力，咱们都尽可能作在里面去，经过二次自定义的方式，去知足用户自定义的场景。

Q：总共有多少数据量交给Kylin处理了？

A： 如今咱们一天全部的交易有好几亿，咱们还有季度的、年度的，全部的东西都会用Kylin去作。咱们用Kylin去支撑几年的明细交易查询，总的数据量有几千亿了。 怎么样用Kylin支撑几千亿级的数据查询，咱们如今是用Hive跑，几百万个出来跑40多个小时，整个集群所有被吃满，因此如今这也是咱们面临的挑战，咱们也在和Kyligence公司讨论，千亿级的数据怎么样经过Kylin的方式去作，咱们计划在半个小时看看能不能跑出来，他们跟咱们说很轻松，目前还在测试之中。

Q：前面展现的报表工具是自研的吗？

A：咱们有一个5人团队，基于Kylin而后设计出来这么一个报表工具。

Q：Kylin作的工做主要是对Hive查询的优化工做？

A：Kylin是先把Hive元数据库拉入构建成底层的存储引擎，还有本身存储的格式。跟Cognos的机制比较像，元数据自己是放在数据库里面，或者是放在Hive里面，去访问数据库，而后把数据生成物理上的Cube文件，对Cognos来说，是一些二级文件，对于Kylin来说，两种都支持，开源社区版的话是基于HBase，把数据塞在HBase里面。可是整个数据结构，跟你本身原始的数据结构是不同的，是Kylin数据接口。可是那个膨胀率你看一下，确实有点高，看你的数据量是否能接受这个膨胀率。

Q：膨胀率具体指的是什么？

A：好比说你如今有100个G的数据，这个是元数据，一条一条原始数据。可是多维分析是不少个维度的交叉和组合。那么每个维度都有可能做为你的访问，这个时候，理论上从数据模型上来说，为了提升性能，要把每一种组合都计算出来，并且存下来。这个时候面临的组合的量，就不是几百亿或者是怎么样，那么它的存储相对来说确定比原始要大，可是大多少？开源社区用HBase去作的，商业版的话，有本身的存储引擎，并且还有一个加强的减支的功能，去判断哪些交叉维度是有效，哪些没有效，因此说在这上面作了一个处理。其实说白了，我以为能量守恒，目的仍是空间和时间，只是空间、时间能节约多少的问题。

Q：若是使用 Tableau 软件，Kylin是做为 Tableau 的一种数据源吗？

A：对，可让 Tableau 把 SQL 发给 Kylin，Kylin作数据计算，结果给到 Tableau。

点击查看完整视频

点击获取讲师PPT

联系咱们：

邮箱：info@kyligence.io