微信小程序开挂方法,广东seo网站设计多少钱,企业官网免费制作,深圳建设网站的公司哪家好2019独角兽企业重金招聘Python工程师标准 近日#xff0c;Apache Kylin Innovation Meetup 在上海成功举办#xff0c;有近200位小伙伴来到了现场。此次会议特别邀请到了金融、互联网等行业的技术伙伴分享了 Kylin 在行业中的实操应用 。今天将首先与大家分享演… 2019独角兽企业重金招聘Python工程师标准 近日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 这个产品的引入对我们带来的好处是非常多的。 现在整个的报表以前8小时 Cube 现在2小时就可以出来给我们的小伙伴的指标是每天早上9点钟之前要把昨天所有的数据做完用户能够访问到这个指标现在基本上完全能够达到。从访问来讲基本上96%在10秒之内完全出乎用户的意料用户进来谈笑之间数据就可以出来。一些高基维的引入进一步降低了我们开发压力、维护压力。 企业如何落地 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 去执行。 怎么能让我们的多维分析相对比较平缓或者说怎么让那些比较熟悉或者是更加接受报表的用户能够接受拖拉拽的这种形式 我们会在上面加自定义集去自定义很多业务的场景比如对于我们来讲从业务上来说定义公司不同的业务线 从数据层面来讲是有多个维度甚至是维度里面不同位置的组合去来代表这些业务场景和业务含义。那么这个时候如果从报表上来看就是反应了公司不同业务条线的各类数据报表。 今天和大家分享了我们为什么开始使用KylinKylin带给我们的价值以及围绕着Kylin我们做了哪些开发集成工作希望对大家有所帮助社区里有面临相同问题、挑战的伙伴也可以跟我们进一步交流 。 QA Q 在使用Kylin不管是企业版还是商业版的过程中有朋友碰到报表经常变换的情况比如说已经构建好的Cube结果却发现指标需要变化或者是维度需要增加这个时候你们是怎么处理的 A 如果说真要变化整个模型要重构这个是没办法的。第一基于多年Cognos的积累我们整个模型相对成熟 。第二Kylin本身的能力值得认可我们尽可能的会把更多的一些数据、维度放在模型里例如把所有商户代码全构建进去几百万、上千万的商户数据放在一起怎么查、改都逃脱不了这个范围所以后面做了自定义数据集等 。所以有了kylin以后 我们对这些业务需求就更加有信心 能够帮助业务人员解决尽可能的把我们能想象到的场景放进去只要Kylin能承担得了性能上的压力我们都尽量做在里面去通过二次自定义的方式去满足用户自定义的场景。 Q总共有多少数据量交给Kylin处理了 A 现在我们一天所有的交易有好几亿我们还有季度的、年度的所有的东西都会用Kylin去做。我们用Kylin去支撑几年的明细交易查询总的数据量有几千亿了。 怎么样用Kylin支撑几千亿级的数据查询我们现在是用Hive跑几百万个出来跑40多个小时整个集群全部被吃满所以现在这也是我们面临的挑战我们也在和Kyligence公司讨论千亿级的数据怎么样通过Kylin的方式去做我们计划在半个小时看看能不能跑出来他们跟我们说很轻松目前还在测试之中。 Q前面展示的报表工具是自研的吗 A我们有一个5人团队基于Kylin然后设计出来这么一个报表工具。 QKylin做的工作主要是对Hive查询的优化工作 AKylin是先把Hive元数据库拉入构建成底层的存储引擎还有自己存储的格式。跟Cognos的机制比较像元数据本身是放在数据库里面或者是放在Hive里面去访问数据库然后把数据生成物理上的Cube文件对Cognos来讲是一些二级文件对于Kylin来讲两种都支持开源社区版的话是基于HBase把数据塞在HBase里面。但是整个数据结构跟你自己原始的数据结构是不一样的是Kylin数据接口。但是那个膨胀率你看一下确实有点高看你的数据量是否能接受这个膨胀率。 Q膨胀率具体指的是什么 A比如说你现在有100个G的数据这个是元数据一条一条原始数据。但是多维分析是很多个维度的交叉和组合。那么每一个维度都有可能作为你的访问这个时候理论上从数据模型上来讲为了提高性能要把每一种组合都计算出来而且存下来。这个时候面临的组合的量就不是几百亿或者是怎么样那么它的存储相对来讲肯定比原始要大但是大多少开源社区用HBase去做的商业版的话有自己的存储引擎而且还有一个增强的减支的功能去判断哪些交叉维度是有效哪些没有效所以说在这上面做了一个处理。其实说白了我觉得能量守恒目的还是空间和时间只是空间、时间能节约多少的问题。 Q如果使用 Tableau 软件Kylin是作为 Tableau 的一种数据源吗 A对可以让 Tableau 把 SQL 发给 KylinKylin做数据计算结果给到 Tableau。 点击查看完整视频 点击获取讲师PPT 联系我们 邮箱infokyligence.io 转载于:https://my.oschina.net/cicixing/blog/3019193
