中科技术让白癜风患者早绽笑容 https://m.39.net/pf/a_5962533.html近日，在ApacheKylinInnovationMeetup的大会上，中国银联数据服务团队负责人的王颖卓，分享了在过去十年，伴随业务数据的迅猛增长，大数据平台遇到了哪些挑战？引入Kylin后，大数据平台的整体性能得到了大幅提升，实现了对业务团队的快速响应。“Kylin的引入给我们带来了切实的好处，现在整个报表分析的数据准备时间，从过去的8小时减少到2小时。”——王颖卓，中国银联数据服务团队负责人，Kylin用户业务数据猛增大数据平台遇到哪些挑战首先简单介绍一下我们公司数据仓库的背景，年公司开始建数据仓库，年上线。这个数据仓库运转到现在已经有10个年头，采用的是比较传统标准的架构，数据仓库主体用的是IBMDB2。在BI这块我们引入了Cognos作为总的BI工具，当时，整个金融界都比较流行Cognos。在这10年内，包括Cognos等一些其他商业版的多维分析工具，确实给企业分析带来了很大的便利。时过境迁，现在到了大数据年代，数据量越来越大，Cognos面临了一些挑战，我们数据量的增长，10年间涨了10倍；在最近两三年，我们的业务量又更加迅猛地增长，这对数据分析的挑战是巨大的。Cognos从整个功能、架构上来讲，都是基于单机版的，效率很低；因此我们在Cognos的基础上研发了一些工具，包括调度、Cube刷新，Cube访问等等，这其中申请的专利就有好几个。这些工具核心还是基于单机的运转，所以说在构建上它的扩展性不好，一个体现是，刷Cube的时间越来越长。例如一些每日刷新的Cube，业务分析用户需要基于这些日Cube要出当日报表，但是鉴于现在的数据量和处理能力，很难在他们预期的时间内达到要求，我们技术团队的压力很大，做了很多工作，想了各种各样的办法在调优，但是收效仍然低于预期。以上是我们用Cognos碰到的一些挑战，正是因为这个原因，我们在年在一个技术分享活动上，我们和ApacheKylin第一次触电。Kyligence的性能和价值在下图可以看到，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这个产品的引入，对我们带来的好处是非常多的。现在整个的报表，以前8小时Cube现在2小时就可以出来，给我们的小伙伴的指标是每天早上9点钟之前，要把昨天所有的数据做完，用户能够访问到，这个指标现在基本上完全能够达到。从访问来讲，基本上96%在10秒之内，完全出乎用户的意料，用户进来谈笑之间数据就可以出来。一些高基维的引入，进一步降低了我们开发压力、维护压力。企业如何落地Kylin作为一个传统企业，引入ApacheKylin这样的开源软件，该怎么样引入？这个是从我个人的角度给大家做一个分享，不一定完全对，大家可以一起思考和讨论。对于金融机构来说，去引入开源软件，追求的其实就是核心的四个字：自主可控。其次有三个方面的因素需要考虑。用户体验引入Kylin非常大的一点原因，我们可以把整个Cognos分析报表架在ApacheKylin上，用户仍旧可在Cognos上进行拖拉拽，后台使用Kylin进行查询，用户习惯得到了%原汁原味的保留。我们服务的是用户，所以用户的体验、感受是非常关键的。社区支持原来用IBMCognos的售后服务非常好，问题提出后，他们响应会非常快，邮件的方式或者是回访，他们会收集一堆的生产上的情况，一堆的报表。但是，问题还是没发完全解决。传统的商业产品，往往会面临这样的情况：态度非常好，但碰到一些具体问题快速解决的效率不高，另一方面用户间相互交流的途径较少，相互启发式的最优实践经验分享不够。一个非常Open的开源软件，其实对于我们这样传统的金融机构来说，可谓是一个美好的毒药。虽然都是开源的，社区也非常活跃，但是如果没有足够的开发人员、技术人员在里面的话，玩不转的。像现在大数据的社区非常活跃，多少企业在这个社区里有很好的主导权呢？从这个角度来讲，Kylin这个社区对我们的帮助很大。这个社区很开放，同时Kyligence公司在这个社区里也起着一个很重要的主导权。我们提出的问题，社区里的朋友会跟我们做交流，Kyligence公司也会以一个主要的代码贡献者的身份，提出很好的建议和意见。组件化Kylin越来越庞大，它可以是一个完整的产品，可以把它拿回来作为一个BI去用。我们在选Kylin的时候，更多的是看重它的组件化的特质。如果熟悉Kylin的应该知道，它既是一个产品也是一个计算组件，也有可以是一个存储组件。我们没有把Kylin当成一个完整的产品，而是把它当做一个组件。过去我们讲“Intelinside”，在构建我们自己的BI产品的时候，我有时候也说，Kylininside，我们看一下，什么叫做Kylininside。企业内部的大数据围绕着给用户服务，做BI，和数据提取的体系架构。这一圈基本上是自营的一些组件、安全、任务执行、资源控制，任务监控、访问控制；底层是非常熟悉的一系列的大数据套件包括MapReduce、Spark、Impala、HBase，包括EDW，所以整个外围的一圈给包在一起，作为一个统一的解决方案提供给用户，用户可以通过各种方式去访问数据、使用数据做自己的分析。所以说Kylininside，包括我们自营的Tornado数据加工服务，中间的Kylin作为一个比较核心的组件，是数据分析的支撑；同时还包括Lightning实时数据服务产品。从这个角度来讲，我们并不是说简单的把Kylin当一个产品引入而是作为一个组件的形式赋能到我们产品上。智能OLAP融合解决方案KyligenceIBMCognos当企业数据达到PB级，传统的基于CognosOLAP的多维分析平台面临巨大的挑战，查询延迟从秒到分钟级，甚至小时级；数据构建时间越来越长，报表展现从T+1变成了T+2，严重降低了业务人员的工作效率。Kyligence的融合解决方案能够快速迁移和替换企业原有的CognosPowerCube，无缝集成CognosBI以及其他前端展现工具，完全保留业务原有分析模式；同时，方案可显著降低Cube设计的复杂度，节省大量重复的开发和运维人力成本，助力IT快速响应业务场景需求。大幅提升查询效率和稳定性实时／批量式构建性能，支持T+0报表高基维度多维和明细查询关于Cognos融合解决方案有任何的疑问，请给我们留言。企业基于Kylin定制化BI开发前面介绍一下为什么从Cognos移到Kyklin上来，在这个过程中，我们重点考量的是哪些点。接下来，我会向大家介绍，针对Kylin的外围，我们做了哪些事情。我们基于Kylin商业版本KyligenceEnterprise做了一些二次开发，我们选择企业版更看重的是商业服务。围绕着Kylin，我们做了两方面的事情。最开始做数据时，基本上是以Cognos的方式在跑报表、数据。用户反馈，Cognos太难了，表结构不合理。因此我们推出了多维分析，通过拖拉拽方式就能做。拖拉拽几年，用户就又开始抱怨了，天天拖拉拽，开发效率太低。我们有熟悉Cognos的人员，有做数据分析的人员，我们遇到的新问题是，能不能开放一些Cognos的接口给分析人员去使用？基于这样的情况，我们两个都做。在多维分析之上，我们开发了一些工具，第一个简单的拖拉拽，这个是仿照Cognos做的。后面有单个模型去创建多个分析。如果对这边有了解的话，用它做报表的话，Report打开来，需要同时打开多个Report，里面去搭载多个模型，按照现在的性能，一个模型下载下来，至少要半分钟，有的甚至是1分钟，所以说这个时候，无论对机器的影响，还是电脑本身，相当于电脑开多个浏览窗口，对电脑的压力都还是有的。所以说做了一个事情，单个模型，创建多个分析，包括用户自定义维度、参数和SQL之间的转换，在这边都做了一些开发。用户往往会说：我会写SQL，但是不懂你们的模型。对这种情况，我们做了一个类似于SDK的工具，提示元数据，把表名、字段名弹出来，用户写SQL，然后验证SQL等；怎样的SQL才能跑，是有自己的一些逻辑在里面的，包括自定义一些UDF，有些时候直接把UDF传下去，可能传到Kylin里面，也有可能传到SparkSQL里面。有种情况也是，通过原生接口或者是SQL接口，或者是其他接口，把数据取过来在内存里，做二次处理加工，最终再给用户展现。像我们这个SQL，不仅基于Kylin，也会基于SparkSQL或者是Impala去执行。怎么能让我们的多维分析相对比较平缓？或者说怎么让那些比较熟悉，或者是更加接受报表的用户，能够接受拖拉拽的这种形式？我们会在上面加自定义集，去自定义很多业务的场景，比如，对于我们来讲，从业务上来说，定义公司不同的业务线，从数据层面来讲，是有多个维度，甚至是维度里面不同位置的组合，去来代表这些业务场景和业务含义。那么这个时候如果从报表上来看，就是反应了公司不同业务条线的各类数据报表。今天和大家分享了我们为什么开始使用Kylin，Kylin带给我们的价值，以及围绕着Kylin我们做了哪些开发集成工作，希望对大家有所帮助；社区里有面临相同问题、挑战的伙伴也可以跟我们进一步交流。QAQ：在使用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：比如说你现在有个G的数据，这个是元数据，一条一条原始数据。但是多维分析是很多个维度的交叉和组合。那么每一个维度都有可能作为你的访问，这个时候，理论上从数据模型上来讲，为了提高性能，要把每一种组合都计算出来，而且存下来。这个时候面临的组合的量，就不是几百亿或者是怎么样，那么它的存储相对来讲肯定比原始要大，但是大多少？开源社区用HBase去做的，商业版的话，有自己的存储引擎，而且还有一个增强的剪枝的功能，去判断哪些交叉维度是有效，哪些没有效，所以说在这上面做了一个处理。其实说白了，我觉得能量守恒，目的还是空间和时间，只是空间、时间能节约多少的问题。Q：如果使用Tableau软件，Kylin是作为Tableau的一种数据源吗？A：对，可以让Tableau把SQL发给Kylin，Kylin做数据计算，结果给到Tableau。演讲完整视频34:19在Kyligence
转载请注明：http://www.aierlanlan.com/tzrz/8058.html
