请上传宽度大于 1200px,高度大于 164px 的封面图片
    调整图片尺寸与位置
    滚轮可以放大缩小图片尺寸,按住图片拖动可调整位置,多余的会自动被裁剪掉
取消
molly(uid:70621)
职业资格认证:尚未取得认证
FineBI5.0基础学习视频可以离线下载啦~
帆软社区在线学习地址见:http://bbs.fanruan.com/course-58.html FineBI官方帮助文档:http://help.finebi.com/ 离线下载地址:http://bbs.fanruan.com/thread-122728-1-1.html{:fange03gif:}
FineBI的Spider引擎对大数据的阐释
最近在看关于大数据、数据仓库 、数据架构的《数据架构:大数据、数据仓库以及Data Vault》一书,关于大数据有些思考,结合FineBI的Spider引擎,可看看Spider引擎对于大数据的阐释,以及在大数据平台架构中,可以处于什么样的位置。 大数据一直被定义为3W(数量大,速度快,多样性),但这些特征用于描述高速公路上运载的各种货物也没有问题。因此数仓之父 Inmon提出大数据的识别特征为: (1) 数据量大毋庸置疑,这条必须有; (2) 在廉价存储器中存放的数据以昂贵存储介质建立海量数据存储所带来的成本,将使得大数据处理无意义。因此大数据的存储介质需要廉价; (3) 以罗马人口统计方法管理的数据 古罗马人想要对罗马帝国的每个居民征税,所以要做一次人口统计。起初视图让罗马帝国的每个公民穿过罗马城门计数。但是古罗马地域辽阔(当时包括北非、西班牙、德国、伊朗、以色列等等),居民分布广,这种方式不现实,需要使用一直集中式处理方法。最终决定组建一个人口统计团,各个人口统计员统一在城门集合,之后被派向各地,在约定的一天进行人口统计,之后在罗马城汇总数据;海量数据处理也是这种方式,将数据处理方式发送给不同区域(分区)的数据,实现分布式数据处理。这样可以实现几乎无限数据量的数据处理; (4) 以非结构化格式存储和管理的数据。 总结下来,大数据就是以非结构化格式存储在廉价介质中的大量数据,需要以分布式处理方式来做数据计算。 而大数据平台的建设,要做的事情可就多了,未来还有更多未知与可能性。之前介绍过的数据平台阶段(数据架构进化简史),各个架构设计等都是底部的一小部分。 http://kms.finedevelop.com/download/attachments/45604360/%E5%A4%A7%E6%95%B0%E6%8D%AE%E5%B9%B3%E5%8F%B0.png?version=1&modificationDate=1543321210000&api=v2 而为了支撑数据分析服务的正常运行,带有敏捷数据集市的BI工具也就要与时俱进了。即使不为长远考虑,当下的快速展示问题也需尽快解决。从多个方面看,FineBI与其自带的Spider引擎,都服务于解决大数据量展示分析的问题。 FineBI是一款自助式分析工具,在功能上将数据准备工作与业务数据分析工作分开。提倡IT部门准备好数据,提供给其他数据部门或业务部门做自助分析或敏捷开发,让各个部门发挥各自长处,做各自最擅长的事情。解放IT部门压力的同时,也能让业务部门快速获得即席分析结果。 http://kms.finedevelop.com/download/attachments/45604360/image2018-11-27%2020%3A27%3A19.png?version=1&modificationDate=1543321640000&api=v2 Spider引擎的详细介绍可以看这里-->10亿数据秒级展示,FineBI5.0的大数据支撑有个“幕后BOSS”! 很多用户本身就有高性能数据查询引擎,或业务的实时性要求特别高,那就可以使用Spider引擎直接对接数据库,常规的大数据平台都可以支持,详细可以看上述文章。 然而,很多时候,BI工具需要一个为灵活自助分析提供的敏捷型数据引擎。也就是需要将数据抽取到中间层中存储下来,以便计算不受数据库影响,并且快速得到分析结果。抽取数据的情况下,FineBI默认的应用与数据引擎可以是一台服务器,数据量在亿级以内的情况下,展示速度十分优秀。由于没有网络传输的限制,本地计算效果会优于分布式扩展后的分布式计算效果。在数据量激增之后,就需要扩展之后的Spider分布式引擎,在功能实现上,依旧是将数据抽取到敏捷型数据集市中做分布式存储,从而对接前端的分析查询,实现快速分析展示。 以上的数据抽取或实时从数据库获取的方式可灵活切换,既数据即可来自数据库,也可以来自中间存储引擎,且这两种方式又可以任意切换,前端分析展示不受影响,从而在BI分析的各种应用场景中更加灵活。 下面回归正题,来看FineBI的Spider引擎对于大数据分析的阐释。 FineBI的Spider引擎基于ALLUXIO 、SPARK、 HDFS等大数据组件,结合自研高性能算法,解决了大数据量分析问题与展示时的性能问题。列式存储、并行内存计算、计算本地化加上高性能算法,保证在FineBI中快速的数据分析展示。可横向扩展节点满足数据增长的需求,从架构上也保证了业务系统全年可正常使用。 【下图来自帆软灵魂画手~】 123672 (1)大数据量存储上,首先面对大量级数据存储,回归前面的定义,需要有廉价的存储方式,能存储非结构化数据,能做分布式计算。那首先就想到Hadoop中的分布式文件系统——HDFS。HDFS的稳定性以及容错性机制都比较完善,Hadoop 2.X版本之后实现对HA的支持,可做到存储数据全年可用。自然,其在大数据领域的生态也比较好的~ 但是HDFS的存储还是基于磁盘的,其I/O性能难以满足流式计算所要求的延时,频繁的网络数据交换进一步拖累了计算处理过程。因此我们引入Alluxio作为分布式存储系统的核心存储系统。Alluxio以内存为中心的存储特性使得上层应用的数据访问速度比现有常规方案快几个数量级。利用Alluxio的分层存储特性,综合使用了内存、SSD和磁盘多种存储资源。通过Alluxio提供的LRU、LFU等缓存策略可以保证热数据一直保留在内存中,冷数据则被持久化到level 2甚至level 3的存储设备上,将HDFS作为长期的文件持久化存储系统。 123673123671 (2)存储上,hadoop的HDFS实现了分布式存储,而其自带的MapReduce计算性能有不足,且无法以标准格式对接外部应用,SQL On Hadoop 应运而生。其种类繁多,impala、Spark SQL、hive等都是大家熟知的。但是呢,选择什么方式不重要,大家的出发点都要能够实现大数据量情况下的并行分布式计算。 FineBI的Spider引擎的核心计算部分,也是SQL On Hadoop技术的实现。列式存储,数据字典压缩,分区与块级索引,数据本地化等SQL On Hadoop技术都得到应用。 类SQL设计与基于BI计算场景的优化,以及结合了内存分布式计算,使得大数据量下的展示速度达到秒级。 123674(3)内存计算:大数据平台中,内存计算服务也是很重要的一个模块。为了实现常用分析数据与计算场景可以快速展示,根据上述数据存储的原则,需要使用到的计算都是在内存中的,从而保证了计算速度最优。同时将不常用数据持久化到HDFS中备份下来,也减少了内存资源的占用。 综上,Spider引擎既可以是联结用户的数据平台与展示的中间层,实际不做数据存储与计算,只将结果进行最终展示。同时也可看作是大数据平台中的一个内存计算应用,将计算结果展示在FineBI前端。 编辑于 2018-11-30 11:57
【企业案例】中国电信呼和浩特分公司的数据分析之道
一、呼和浩特电信简介123657 中国电信内蒙古分公司于2002年11月8日成立,是中国电信集团公司为适应国家电信体制改革,在内蒙古自治区设立的全资国有通信运营企业。2008年,根据工业和信息化、国家发改委、财政部联合发布的《关于深化电信体制改革的通告》,中国电信全面收购C网,从2008年10月1日起,正式运营CDMA网络资产与业务。 目前,中国电信内蒙古分公司丰富完成了宽带服务内容为主的固网建设和以提高网络质量、扩大覆盖范围为主的深度改造CDMA网络建设,3G网络覆盖十二盟市与所属旗县以及重要乡镇,交通干线和旅游景点,给用户呈现一张脱胎换骨、优质高效的综合通信网,为用户带来全新的体验。未来三年,中国电信内蒙古分公司将陆续投资数十亿元资金用于升级、改造、优化为用户提供综合信息服务的精品通信网络。 二、BI项目规划 1、BI系统使用背景 由于公司内部系统繁多,日交易数据量较大,每天都会产生上百万数据,当前的关系型数据库在做数据分析的时本就速度偏慢,在达到亿级以上之后,平均一个查询就是分钟级别。对于需要即时分析查询的业务用户,体验并不友好。 同时由于企业内有很多业务系统,而各个业务部门之间相对独立,各自为阵,导致形成数据孤岛,难以将各个来源的数据整合分析。而不同业务部门之间希望信息互通,将不同维度数据整合分析,便于将财务、销售、套餐、地区宽带等数据进行快速掌握及深度理解。 公司内部各业务部门对报表需求较为灵活和多样化,需要一套便捷、易上手的BI系统实现管理层对数据快速分析及展示的需求,同时将手动管理的数据系统化。 基于以上原因,公司内就开始选型各种BI工具。由于公司一直在使用帆软的FineReport,因此首先就想到了帆软的FineBI工具,又增加了几家其他BI工具的对比。发现最终性能满足将分钟级的分析查询加速到秒级,且能够支撑业务常用复杂场景的BI工具就是FineBI,因此最终定下使用FineBI,开始企业的BI项目之旅。 2、BI系统推进目标 将公司内部散乱的数据进行统一化、规范化、系统化管理,将不同数据来源数据整合,实现公司内部的市场销售类数据分析,从而为信息化时代数据辅助企业经营决策提供支撑。 通过BI系统搭建公司层面各个主题的管理驾驶舱,支持推动各部门高层领导进行数据决策分析。 利用BI工具的自助分析特点,让业务部门可根据需求,灵活、便捷地定义生成所需要的即时分析和快速报表,节省报表和查看分析数据的周期,提升数据的应用的效率,同时减轻IT信息人员支撑业务报表与查看数据需求的压力。 结合FineReport一并使用,FineReport完成数据填报功能,实现数据的收集,并且做固定化复杂报表的展示。而将FineBI用于实现的灵活的自助式数据分析场景,常规性质的数据查看以及即时性质的分析都在FineBI系统中处理。 3、项目分解 首先界定了与系统相关的干系人,将干系人团队分解出来三种类型,分别是IT信息科技部门、数据分析部门、产品部/业务部门,不同的部门对应不同事项内容与项目产出。 IT信息科技部负责对接到数据分析部,主要是做底层数据清洗整理与汇总提供等底层的数据处理工作。 数据分析部联结业务部门与IT信息科技部门,负责将业务常规所需(根据历史经验分析)的表添加到业务包中,覆盖大部分的业务常用分析,同时将其他业务相关的基础表也添加到业务包中以供使用。也会制作复杂分析模板挂出以供业务部门使用,同时常用复杂逻辑计算分析也做成demo形式提供给业务部门作为参考,以便复用。 产品部/业务部门的人员根据提供的业务包以及示例和demo,自行做一些常用分析在系统以及移动端进行查看。 123658 4、项目架构 项目利用FineBI的Spider分布式引擎,来支撑大量级的数据计算与分析展示,并实现多源数据的整合展示。 历史抽取数据与实时数据可以互相切换,从而满足多种业务场景需求。 123659 三、项目实现 1、数据底层及BI应用平台搭建 http://kms.finedevelop.com/download/attachments/45177408/image2018-11-11%2020%3A5%3A15.png?version=1&modificationDate=1541937916000&api=v2 由于公司内部各个部门每天产生的数据量较大(当前阶段已经在亿级别以上),普通的分析型数据库已经不能满足于当前数据分析的一个速度展示要求,而且公司没有大数据平台,因此先对整个数据底层进行了调整,使用Spider引擎分布式架构来搭建,并且在另外一台机器上部署应用平台,使各台机器各司其职,发挥最大的效率。 2、业务包搭建 http://kms.finedevelop.com/download/attachments/45177408/image2018-11-11%2022%3A30%3A52.png?version=1&modificationDate=1541946652000&api=v2 (1)将业务包按照数据功能的不同进行分组,不同用途的数据业务包放在不同的分组下,这样便于管理和使用 。 (2)不同分组下再按照具体业务进行管理,不同的业务数据存放在不同的业务包当中,比如这边的欠费、费用、订单、用户等,同样的也方便了数据表的存放和管理。 (3)将业务包根据用户的角色分配不同权限,不同角色下的用户只能看到自己权限范围内的数据,更提高了数据的保密性。 3、主题分析 http://kms.finedevelop.com/download/attachments/45177408/image2018-11-11%2022%3A32%3A31.png?version=1&modificationDate=1541946750000&api=v2 客户着重于电信行业的市场分析,主要体现在整体业务的综合总览,监控各个主要业务的发展趋势,通过对不同时间段的客户、销售、套餐等业务的数据分析,来汇总市场、预测发展、改善规划。 4、平台用户管理 http://kms.finedevelop.com/download/attachments/45177408/image2018-11-11%2022%3A33%3A26.png?version=1&modificationDate=1541946805000&api=v2 由于平台用户过多,将平台的用户根据其角色进行分类,然后通过用户的角色来给不同的用户分配不同的权限,比如分析类的用户只能看零首付和客户经理发展量这两个模板。 除此之外,客户着重使用自主分析的功能,除了给用户查看权限之外,还给部分用户设置为BI编辑用户,这样大大减轻了信息技术人员做模板的压力,而让其他用户根据自己的需要搭建分析模板,充分发挥了BI平台灵活自主的功能,也省去了业务人员和信息人员沟通需求的繁琐流程,分析更为高效。 四.项目成果展示 1、发展总览 作为整体业务的综合总览看板,监控各个主要业务的 发展趋势,对于综合评估当前市场与用户情况具有重要意义。首先单独看每一种业务发展趋势,可评估当前该业务发展情况。监控造成其非常规趋势的原因。如图分析可知某段时间内移动发展量总量都在警戒线以上,虽然有所波动,但都达到了警戒值,于此可以分析到该段时间内业务发展比较稳定,整体业务情况也比较可观,可根据当前的影响因素来具体分析,制定更好的发展规划。 另外多个业务之间进行对比分析,可以评估业务之间的影响关系,综合制定业务推广方案。从图中从总体上来看不难发现,移动发展总量和宽带发展量总量是正相关的,且通话时长(总时长)和数据流量(总流量)也是正相关的,这样说明了这两者之间互相促进,总体上来看正向影响,而极少数情况下趋势相反或者涨跌幅度有差别,这时就可以将业务之间进行组合销售,将发展良好的业务与发展较缓的业务进行组合推广,例如表中的移动和宽带,这样可带动发展交缓的业务开始回升。或者将那些处于下降的业务进行升级,或考虑由其他业务进行逐步代替等。 123663 123660 2、移动发展 123664 123661 综合对比两年间的移动卡业务发展量、净增量以及之前的预期值,可以对当前移动卡市场趋势形成一个整体评估。移动发展量和净增量主要是两个柱形图之间的对比,可以通过柱子的对比来展示出2017与2018年之间的数据差异,由此可以看出2018年的发展量和净增量都优于2017年,说明2018年的发展速度更快,收益更高,可按照当前的市场规划持续推动;而左下方的组合图主要是对发展量和完成率进行不同地区网点的分析,且对数据进行了降序排列,可以清楚的看到不同地区网点发展量的情况,而且进行了排序,也能清楚的反映出不同分公司完成情况的差异。这样整体的分析可体现当前市场是否还是保持一个高速的增长阶段,市场还有多大的份额。由移动卡业务增长量可细化到每个地区网点,评估网点信息有可对整个城市地区移动业务增长分布进行把控。 五、客户评价 中国电信始终打着开拓、创新,立足市场求发展,优质、高效,用心服务为用户的口号逐年发展,而帆软自始至终以让数据成为生产力为基准,踏踏实实为客户做好服务为根本,两者从宗旨上不谋而合,且FineBI为呼市电信提供了优质的大数据分析平台,整合数据、分析数据、预测市场,让电信行业在发展中“有规可循,有数可查,有图可引”,这也真正的体现出FineBI作为可视化分析的优势所在,让数据说话,让数据真正的成为生产力! 编辑于 2018-11-30 13:42 编辑于 2018-11-30 13:44
FineBI 5.0升级计划公布,参与信息评估就有机会获得免费升级名额
FineBI 5.0 已于2018年10月12日和大家正式见面了,相信使用过FineBI的老客户会发现,从 4.x 到 5.0, 产品功能上做了非常多的优化,比如功能完善度、可视化效果、易用性、美观度的提升都是有目共睹的。(详细客户实例、版本更新说明见文末) 产品大幅度的改进提升,一方面得到了大量番薯的点赞支持,另一方面势必也会有老客户对升级兼容性产生担忧。为了让所有客户都能平滑地过渡到5.0,帆软官方推出升级计划如下: 第一阶段:系统使用信息评估(>>问卷链接戳我),即日起~11月30日 18:00。 此阶段通过升级检测工具,了解您FineBI应用的复杂程度,以及可升级的程度。同时基于您反馈的真实信息,我们会适当调整第二阶段升级工具的设计方案。 第二阶段:兼容升级阶段,最早计划12月开始。 按要求参与第一阶段的信息评估(即上述问卷),不仅可以加速升级方案的上线时间,同时官方还将根据参与者反馈的信息,选择部分客户提供免费升级名额与升级服务。(官方承诺:不少于5个免费名额) 关于问卷中需要上传的升级检测报告说明: 检测报告仅为升级兼容信息说明,不包含企业机密信息,帮助文档有示例,在检测之后也可自行确认; 戳我查看升级检测步骤方法(生成的excel文件即为升级检测报告); 从4.0或4.0.2版本升级到4.1最新版本请联系帆软官方技术支持。 补充说明: 本活动仅限FineBI合作客户参与; 参与第一阶段信息评估(即提交问卷)后2周之内,可以免费获得FineBI 5.0的升级方案与建议; 将从第一阶段参与客户中,选择不少于5家客户,提供免费的升级名额与升级服务; 本活动最终解释权归帆软软件所有。 FineBI 5.0相关资料推荐 5.0版本更新说明:http://www.finebi.com/product/fbi5 (下载版本更新介绍PPT) 用户体验报告:http://bbs.fanruan.com/thread-118469-1-1.html FineBI官网:http://www.finebi.com/ 帮助文档:http://help.finebi.com/ 教学视频:http://bbs.fanruan.com/course-58.html 客户案例:正在整理中,尽快更新 编辑于 2018-11-7 20:56
【课程交流】免费学大数据分析课程,交流想法,最高可获100F币
学习大数据分析课程内容了嘛? 有什么疑问、建议,想要学习的相关内容等,都可以直接回帖哦~ ——回帖提问,有问必答。若问题积累较多,会有大神亲临,开直播答疑哦~ ——提建议、想法,一旦采纳,给予30~100F币奖励
10亿数据秒级展示,FineBI5.0的大数据支撑有个“幕后BOSS”!
随着各个业务系统的不断增加,以及各业务系统数据量不断激增,业务用户的分析诉求越来越多且变化很快,IT数据支撑方的工作变得越来越复杂。 1、数据来自多个不同的系统,存在需要跨数据源分析,需要对接各种不同数据源等问题。 2、需要分析的数据体量越来越大,并且要快速获得分析结果的问题。 3、部分数据还需要二次加工处理的问题。 供数支撑方在业务系统的前端看起来基本没有任何操作,但背后的逻辑十分复杂,实现难度也很大。就像看得到的是冰山一角,看不到的是海水下绝大部分的支撑。为了解决日益激增的大数据量分析诉求,自助式商业智能分析工具FineBI V5.0版本的Spider引擎应运而生。 Spider高性能引擎可以支撑10亿量级数据在BI前端快速的拖拽分析和展示,且有高可用架构设计保证数据引擎全年可支撑业务分析。 117828 Spider引擎的前世今生 为什么叫Spider引擎呢?听起来很像爬虫软件,和数据分析又有什么关系呢? 一则是字面翻译过来的意思——蜘蛛,从蜘蛛就很容易联想到结网。从结网的角度的看,有两个含义,一是将之前已有的引擎功能全部联结在一起,因为5.0引擎实现了实时数据与抽取数据的对接与灵活切换;二是5.0数据引擎比较重要的分布式模式,这种模式是由各个组件组合起来的架构,结网就是将这些组件联结起来的意思。 二则是谐音法拉利的一款敞篷跑车。跑车嘛,速度快。这款跑车做了加长与加宽设计,使其更稳定,保持性能且更安全。恰好与我们的数据引擎理念不谋而合。 因此,就取名Spider引擎。 再来说说它的发展史。 FineBI的数据引擎从起初做数据抽取的cube/FineIndex引擎,发展到后来开发了直连引擎/FineDirect引擎。再到2016年开发,17年到18年迅速扩展到60多家客户使用的分布式引擎。引擎功能与支撑数据量都在伴随着时代的发展不断进步。然而引擎类别繁多,用户理解与使用都是问题。 因此,到v5.0版本,将引擎做了大一统,Spider引擎将之前所有引擎功能全部囊括其中,抽取数据与实时数据可互相切换,本地模式可根据数据量情况扩展为分布式模式,使用与理解上都更加简单了。 117830 定位和亮点 Spider作为数据引擎,在FineBI中扮演着支撑数据分析的角色,强大的数据处理与计算能力为前端的灵活快速应用分析提供强有力的支撑。 117829 Spider引擎的本地模式,利用本地磁盘存储,并行数据计算,在小数据量情况下,展示效果优异,且轻量方便。 在数据量激增之后,可横向扩展机器节点,利用Spider引擎专为支撑海量大数据分析而生的分布式方案。Spider引擎分布式模式,结合Hadoop大数据处理思路,以最轻量级的架构实现大数据量高性能分析。此分布式方案集成了Alluxio 、Spark、 HDFS、zookeerer等大数据组件,结合自研高性能算法,列式存储、并行内存计算、计算本地化加上高性能算法,解决大数据量分析问题以及在FineBI中快速展示的问题。同时从架构上保证了引擎系统全年可正常使用。 Spider引擎的直连模式,可以直接对接数据库做实时大数据分析。将用户在FineBI前端拖拽分析的操作,实时地转化为经过处理的查询语言,实现对企业数据库的数据进行实时分析的效果。 直连模式的实时数据与本地模式以及分布式模式下的抽取数据可以灵活转换,使得分析更加灵活方便。 引擎亮点: (1)引擎支撑前端快速地展示分析,真正实现亿级数据,秒级展示。 (2)用户可以根据数据量、实时性要求、使用频次等,自由选择实时或抽取的方式,灵活满足实时数据分析与大数据量历史数据分析的需求。 (3)抽取数据的高性能增量更新功能,可满足多种数据更新场景,减少数据更新时间,减少数据库服务器压力。 (4)合理的引擎系统架构设计可保证全年无故障,全年可正常使用。 在数据源支持上,常规的数据源都可支持,无需担心数据源支持问题。 117831 在抽取数据时候,异步数据抽取保证效率。列式存储字典压缩可将数据以多倍压缩之后存储过来,不存在数据膨胀的问题,数据量激增之后,硬件成本也不会增加。(如下所示,数据量越大,抽取之后数据压缩情况越好)。 117832 智能位图索引、分页引擎,本地模式下的多线程计算,分布式模式下的内存计算、分布式计算和数据本地化都带来秒速数据展示的效果。(上图是100w大分组的场景,速度是秒;下图是普通操作场景)。 117833 117834 同时,分布式数据存储系统的HA,保证数据计算稳定性,使得数据引擎可以为业务系统全年提供稳定支撑服务。 使用实时数据的时候,设置参数、智能缓存等都能充分发挥数据库的性能。带来最佳性能体验。 117835 详细的功能细节可以看>>>《Spider引擎技术原理》。 申请使用Spider引擎分布式版,请联系技术支持QQ:800049425 客户案例 Spider引擎在v4.1版本是直连引擎与分布式引擎的结合,此版本已经从17年投入使用,目前已有60多家客户在正式投入使用,覆盖了保险银行、证券基金、餐饮零售、畜牧、通信、互联网、能源化工行业等数十个行业。 117837 客户应用实际案例见: 西贝餐饮: http://bbs.fanruan.com/thread-103813-1-1.html 包头百货: http://bbs.fanruan.com/thread-105663-1-1.html 中国电信: http://bbs.fanruan.com/thread-119254-1-1.html 更多案例静待分享... 编辑于 2019-1-22 15:03
揭秘FineBI Spider引擎的技术原理
Spider作为数据引擎,在FineBI5.0中扮演着支撑数据分析的角色,强大的数据处理与计算能力为前端的灵活快速应用分析提供强有力的支撑。 117811 一.引擎的三种模式 数据部分,可以做到抽取数据或实时数据。可以分为三种模式,详细解释如下: 1. 本地模式(Local Mode) Spider引擎的本地模式,可以将数据抽取到本地磁盘中,以二进制文件形式存放,查询计算时候多线程并行计算,完全利用可用CPU资源。从而在小数据量情况下,展示效果优异。与web应用放在一起,十分轻量方便。 2.分布式模式(Distributed Mode) Spider引擎可灵活支撑不同数据量级的分析,在数据量激增之后,可横向扩展机器节点,利用Spider引擎专为支撑海量大数据分析而生的分布式方案。 Spider引擎分布式模式,结合HADOOP大数据处理思路,以最轻量级的架构实现大数据量高性能分析。此分布式方案集成了ALLUXIO 、SPARK、 HDFS、ZOOKEEPER等大数据组件,结合自研高性能算法,列式存储、并行内存计算、计算本地化加上高性能算法,解决大数据量分析问题以及在FineBI中快速展示的问题。同时从架构上保证了引擎系统全年可正常使用。 117812 3.直连模式(Direct Mode) Spider引擎的直连模式,可以直接对接数据库做实时大数据分析。将用户在FineBI前端拖拽分析的操作,实时地转化为经过处理的查询语言,实现对企业数据库的数据进行实时分析的效果,在实时性要求较高,或数据库计算性能优秀的情况下,可以采用这种模式,实现数据的实时查询计算,且充分发挥数据库计算性能。 直连模式的实时数据与本地模式以及分布式模式下的抽取数据可以灵活转换,大量历史数据使用抽取数据,实时性要求较高的数据使用实时数据,两种方式的数据可以在前端同一个DashBoard页展示,便于用户对数据灵活分析。 二.底层技术详解 那底层详细技术细节是怎样的呢,可详细看看下列的介绍: 1.列式数据存储、字典压缩 抽取数据的存储是以列为单位的, 同一列数据连续存储,在查询时可以大幅降低I/O,提高查询效率。并且连续存储的列数据,具有更大的压缩单元和数据相似性,可以大幅提高压缩效率。 117815 列式数据存储的基础上,同一类数据的数据类型一致,相同值比例较高,将相同值取出来作为字典,每个列值直接存储该值映射的索引即可,之后再做压缩。这样,数据压缩比例大幅提升。如下是原始数据与抽取数据之后的大小对比情况(数据备份系数是2份),可以发现,小数据量情况下,数据大小基本无差异;数据量越大,抽取后压缩情况越好,基本可以达到抽取数据:原始数据=1:1.5的效果。 117816 2.智能位图索引 位图索引即Bitmap索引,是处理大数据时加快过滤速度的一种常见技术,并且可以利用位图索引实现大数据量并发计算。 假设有以下的表: 117813 现在进行如下的查询: select 姓名 from table where 性别 = `男` and 教育程度 != `本科` 在没有索引的情况下,只能一行一行地进行扫描,判断是否符合过滤条件,符合的加入结果集 现在我们将性别和教育程度中的值建立位图索引,具体如下: 117813117814 其中的1代表在这一行是对应的值,否则即为0。 由此, 对于性别 = `男`这一过滤条件,我们可以快速取得“男”的位图1010 对于教育程度 != `本科`这一过滤条件,我们可以快速取得“本科”的位图1001,然后进行取反操作0110 最后,将两个位图进行按位AND操作,得到最终位图0010,其中只有第三行为1,因此第三行就是我们过滤出来的结果 位图索引是一种典型的空间换时间的思想,由于其空间占用较大而数据结构简单易压缩,因此做了优化压缩,使得数据的压缩做到上述展示的效果。 3.分页引擎 除上述智能位图索引,我们时常会遇到超大分组(返回结果集百万行以上),虽然在我们的前端分析展示时,一次性的操作不需要看到这么大量级的数据。然而在业务分析时候,虽然不需全量一次性加载展示,然而总是有用户会希望看到一些汇总后内容,之后再做出判断决定下一步的分析操作。因此一款面向各种类别业务分析师的数据分析工具,必须要能支持这种分析场景。 在分页引擎诞生之前,类数据库的流式引擎处理大分组一直是一个难题: 对于select A, B, C, sum(V) group by A, B, C(返回结果行百万以上)的查询 一方面,基于HashMap的分组计算,在分组逐渐变大的同时,HashMap的访问效率也会不断下降。 另一方面,聚合后返回的数据相当大,加大了序列化和reduce的消耗,过大的结果数据集也会增加内存的压力。 引入基于树结构的分页引擎之后,实现父子节点之间的关系可以被快速计算出来,关系维护构建成功之后,每个节点就有各自对应的位图索引,分别遍历即可获得计算结果。使得大分组计算不再是难题。如下图中是100W大分组之下的展示性能(都是首次计算返回时间,排除缓存因素),单位是s,可以看到Spider引擎的计算时间基本都在3s左右。相同场可以看到MPP数据库的效果。再对比某敏捷BI的数据集市情况如下所示,其中没有数据的场景是该产品不支持的功能或者产品崩溃导致无法记录测试时长。 117817 4.异步数据导入 数据抽取导入的过程中,JDBC做数据抽取的时候就开始执行数据压缩工作,压缩工作不会阻碍抽数的动作。压缩的时候,数据的分片处理使得因此压缩量不会太大,资源占用很少。同时独立的压缩线程在抽取的同时进行工作,并行处理减少数据抽取时间。结合数据存储的优化,使得海量数据导入避免了OOM等性能问题。 下图是一个100列,10亿行数据表(其中不重复长字符串表超过1亿行)的导入过程,将内存控制在4G以下,效果显著(使用Jprofile记录资源占用情况的截图)。 117818 5.分布式文件存储系统 Spider引擎比较重要的两大模式(本地模式和分布式模式)是要做数据抽取的,因此数据存储介质就很重要了。小数据量的情况下,为了轻量方便使用,直接使用本地磁盘作为存储介质,数据与应用在一起,没有网络传输时间。 在大数据量存储上,就需要有廉价的存储方式,能存储非结构化数据,能做分布式计算。那首先就想到Hadoop中的分布式文件系统——HDFS。HDFS的稳定性以及容错性机制都比较完善,Hadoop 2.X版本之后实现对HA的支持,可做到存储数据全年可用。自然,其在大数据领域的生态也比较好的,因此我们引入其作为长期冗余备份的存储系统。 但是HDFS的存储还是基于磁盘的,其I/O性能难以满足流式计算所要求的延时,频繁的网络数据交换进一步拖累了计算处理过程。因此我们引入Alluxio作为分布式存储系统的核心存储系统。Alluxio以内存为中心的存储特性使得上层应用的数据访问速度比现有常规方案快几个数量级。利用Alluxio的分层存储特性,综合使用了内存、SSD和磁盘多种存储资源。通过Alluxio提供的LRU、LFU等缓存策略可以保证热数据一直保留在内存中,冷数据则被持久化到level 2甚至level 3的存储设备上,最下层的HDFS作为长期的文件持久化存储系统。 6.数据本地化计算 分布式计算是联合多台机器计算,那多台机器就必然存在机器节点间的数据传输问题。为了减少网络传输的消耗,避免不必要的shuffle,利用Spark的调度机制实现数据本地化计算。就是在知道每个执行任务所需数据位置的前提下,将任务分配到拥有计算数据的节点上,节省了数据传输的消耗,从而使得大量级数据计算速度也能达到秒出的效果。 117820 7.智能缓存 智能缓存更多是为了直连模式(Direct Mode)的情况下,系统也能有效支撑并发查询。由于直接对接数据库,性能自然无可避免受到数据库的限制。同时用户分析查询会存在针对相同数据查询场景,因此引入encache框架做智能缓存,以及针对返回数据之后的操作有多级缓存和智能命中策略,避免重复缓存,从而大幅提升查询性能。 如下是首次查询与二次查询的对比效果。 117821
从数据架构的进化史,谈谈FineBI的分布式引擎
近期看到很多企业在设计自己的数据平台,以及选型一些数据分析工具,正好拜读了数据仓库之父的《数据架构:大数据、数据仓库以及Data Vault》一书,有些许感触,就来聊一下个人思考吧。 首先从企业信息化发展阶段时,数据平台结构的程度来看。个人依照企业信息化,将数据平台阶段划分为:只有业务数据库——>中间库——>完善数据仓库(DW)——>数据集市(Data Mart),顺序与阶段并不绝对正确,可能有组合,可能所在阶段不完全一致。以下先看各个数据平台阶段特点,再看对应阶段数据分析工具选型的考虑吧。 1.业务数据库 一个企业IT信息化建设最初的阶段,业务库中数据量不大,要分析展示下数据情况啦,不慌,问题不大,这时候OLTP结构下也可以写写SQL快速展现,随便玩玩office工具也没问题。 http://www.finedevelop.com/download/attachments/31834685/image2018-8-6%2017%3A41%3A39.png?version=1&modificationDate=1533548499000&api=v2 但是随着时间的推移,各种问题开始出现: (1)查询和写入频率越来越高,高频write和和长时间read冲突越来越严重。而数据分析要耗费大量计算资源,不能动不动挂业务系统吧。 (2)数据量越来越大,历史业务数据啦,新业务数据激增啦,第一要务就是要解决业务应用效率问题了,谁管数据分析里的问题呢。 (3)业务越来越多,表结构越来越复杂。业务系统数量的越来越多,导致数据孤岛开始形成。 这种情况下,企业面临数据展示与数据平台建设的阶段了要怎么处理。这种情况下要做数据分析就麻烦了,要人为去各个系统取数,人力是一个方面。各个系统口径命名啥都有差异,人为的处理出错率高就是另一方面。 2.中间库 由于上述问题,就要引入中间库来处理。左图结构解决了高频write和read冲突问题,以及单数据库服务器性能问题,顺手也搞定了数据备份。这种情况下呢简单查询还是可以的,但是在转换聚合等需要多表关联、以及大数据量等业务复杂度高的情况下,其处理性能就不容乐观了。 此时就开始考虑可以利用空闲时间的服务器性能来做预先处理呢。右图这种T+n的预处理离线计算的架构就出现了,引入独立的任务调度和计算引擎:计算压力可以交给数据库处理,也可交给ETL处理,展现性能初步解决。 http://www.finedevelop.com/download/attachments/31834685/image2018-8-6%2017%3A41%3A59.png?version=1&modificationDate=1533548519000&api=v2 但是这种情况下,数据库表结构实在太过复杂,每做一个分析,就要理一次业务逻辑、写一段sql,还没法进行历史追溯,以及数据整理成果的复用,so sad。 那有没有理一次之后,后续能够省点事的方式呢?这时候数仓的概念就可以使用上了。 3.完善数据仓库(DW) 把业务库数据整理成星型结构,保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算,麻麻再也不用担心每次写sql都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小,解决数据库性能问题,~^o^~。 当然这种架构方式的缺点也很明显,不是企业内一致的数据(多系统,多主题数据不一致),就会产生信息孤岛。当然,如果客户企业就是很小,就一个系统,不用整合,一个数据集市足以的情况下采用这种方式也可以。常见情况是会在各个独立的DW间建立一些对照表,可实现数据交换。如果多个DW间没有物理隔绝,也可以形成EDW。http://www.finedevelop.com/download/attachments/31834685/image2018-8-6%2017%3A42%3A51.png?version=1&modificationDate=1533548571000&api=v2http://www.finedevelop.com/download/attachments/31834685/image2018-8-6%2017%3A49%3A25.png?version=1&modificationDate=1533548965000&api=v2 4.完善数仓+数据集市(Data Mart) 为了实现各个业务系统取数分析,或者做更多操作,就实现中心数据仓库EDW从各个源系统收集数据,再将数据提供给各个数据集市和挖掘仓库使用。这也被称为企业信息工厂架构(CIF),一般情况下,大型企业会花费许多精力实现这类架构。 http://www.finedevelop.com/download/attachments/31834685/image2018-8-6%2017%3A48%3A43.png?version=1&modificationDate=1533548923000&api=v2 业务复杂度的提高与数据量级的增大以及对这些数据的应用,促成了各个大数据平台的繁荣,这个放到另一篇文章陈述。 无论是以什么架构存在,数据展示的需求都必不可少。分析工具选择必不可少,要在以上阶段以一款工具涵盖,那必然需要一款既可以做敏捷数据集市建模,又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合,实现敏捷建模节省时间,并且需要可以大幅提升数据的展示速度。可对接前端的数据分析展示层,实现自由数据展示与OLAP分析。FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。 (1)业务数据库阶段,此阶段已经陈述过,重点问题就是计算性能影响大,以及数据孤岛问题。建立数仓的过程相对敏捷数据集市而言,时间还是久的。这个时候就看看建立个常规意义的数仓和数据展示需求谁更紧急啦,或者可能有的也没建数据平台的意识也说不准。此时快速的数据展示需求,就可以通过将数据放到FineBI的数据引擎中支撑实现。 (2)中间库与完善数仓阶段,此阶段其实主要就是计算性能问题了,用户的数据量级也一定挺大了。正好借助于FineBI的分布式引擎,完成数据加速计算工作。此引擎属hadoop生态,核心计算引擎利用的spark,借助了alluxio作为内存加速计算,处理了大数据计算问题,也很好阐释了【大数据】。这个在另一文章中也会说到,这里不赘述啦哈哈。 此阶段呢,肯定有一些响应时间要求较高的展示需求,多次作业同步可能带来延迟影响。而FineBI的引擎扩展了kettle的插件,实现数据可以直接load到引擎中,倒是将麻烦的作业处理工作解决了。 http://www.finedevelop.com/download/attachments/31834685/image2018-8-7%2011%3A17%3A12.png?version=1&modificationDate=1533611831000&api=v2 (3)完善数仓+数据集市阶段,这种阶段数据平台建设已经很完善了,各业务部门数据量级,业务复杂度都很高。 底层技术上虽然数据集市是建立在集成的中心数据仓库EDW上,但是这些数据集市之间还是不能进行数据交换的,大家建立的方法和ETL程序都会不同,各个数据集市之间的数据不见得的是一致,且平台架构超级复杂,扩展以及再为各业务部门设计计算层结果表之类都相对麻烦。此时可考虑部分需整合数据放到敏捷数据集市处理,可直接对接的再直接对接处理。FineBI的引擎恰好都满足这样的场景需求,前端OLAP分析恰好也有,简单处理整合展示一站式解决。 http://www.finedevelop.com/download/attachments/31834685/image2018-8-7%2010%3A36%3A37.png?version=1&modificationDate=1533609396000&api=v2 编辑于 2018-8-15 17:49 编辑于 2018-8-15 17:51 编辑于 2018-8-15 18:00
方案分享:FineBI基于alluxio实现亿级热数据高性能分析
日常一提数据分析和可视化,就想到这个工具操作要多简单易用,图表要多美多炫,然而总是忽略背后的数据支撑。 excel 几十万行数据就卡死崩,谈何数据透视表、可视化? 近千万行的数据,订单提交数据库,sql sever处理要5分多钟,如果频繁入库/取数的话.....要知道,为了支撑起业务人员的数据分析,以及日常不考虑计算逻辑和技术难度,IT人员也是要花费很大的心血和精力啊(心疼运维人员n秒)。 随着公司业务的发展,数据量变大是必然的事实。那么,数据部门要做分析,业务部门要看报表,要跑数据,要用BI,大数据量(千万级及以上)的分析,性能该如何优化? 这里借某公司的真实案例,来阐述一下方案。----------------------------------作为公司的科技部门人员,经常听到业务部门对自己使用的数据库各种吐槽: 竟然存放在mongoDB中啊,震惊(ΩДΩ)。 数据库慢慢熟悉了还好啊,但是现在每天的数据量越来越大,而且还在增加啊,增加大家很开心,然而数据库并不开心啊,简单的查询统计10多分钟还出不来结果,更不用说有稍微复杂点的统计分析了。 我天天找DBA优化啊,然而并没有什么水花。 数据量还在不断增长,到现在都上亿啦,全量查询统计根本出不来结果啊。 ... ... 最终业务人员找到科技部门提需求要弄个BI系统给处理下。 对mongodb瞄了一大通,这就是个业务库。那直接对接mongodb自然不行,速度慢不说,mongodb挂了,分析系统也瘫了。自然就想到了使用中间库,emm mysql oracle 倒是有,可以跑调度抽过来,但是速度依旧不快呢,还要花功夫优化,性价比不高。公司有自己的hadoop平台,将数据抽过来再对接倒是可以,但是要花很大精力跑调度,而且这个数据库不能随意给这个业务部门提供,万一玩挂了可就得不偿失。假设有个具备离线数据存储功能的BI工具,岂不美哉。 于是将市面上有离线数据存储功能的BI工具翻了个遍。期望找到个性能好,可以支持大数据量数据分析的BI工具。 Tableau的hyper功能看起来OK,经不起实际使用,数据量过了亿,等了好久数据抽不好,pass; 其他某BI工具有mpp离线存储,看起来很棒,还能横向扩展,不错。抱有最大期望的用,结果数据量一上亿,直接崩了,崩了,pass; 另一个BI工具去看了看,咦,数据是放在vertica里面的...... 后来,找到了FineBI的分布式计算引擎方案,拿的『定制的 Alluxio』作为分布式内存存储框架(个人有兴趣可以去翻翻https://www.alluxio.org/),内存存储有数据安全性的担心,所以持久化层存储用了HDFS。为了数据分析嘛,自然是列式存储的。计算核心则以熟知的Spark,加上自研算法来处理的。使用熟知的zookeeper整合框架,并用于调度通信。 分布式嘛,横向扩展自然不在话下。而列式存储、并行内存计算、计算本地化加上高性能算法,在FineBI中数据展示速度超快。有意思的是其计算本地化的操作,能减少不必要的shuffle,节省数据传输的消耗,提升数据计算速度。 108312 以下记录利用FineBI4.1工具的系统建设过程。 一、需求分析 针对以上的需求,可以预估到,18年内,常用分析预计最大数据量会达到4.7kw,不常用分析会达到3亿到4亿(包含淡季),数据总的体量最多会达到100G。后面的情况难以预估,就需要系统可横向扩展节点。 108325 二、方案描述 1.系统架构 根据官方推荐,将FineBI的web应用端与数据存储的分布式引擎放在一个机器上(处于安全考虑,也可以分开。这里不涉及太多部门使用,放一起即可),架构如下所示。 108309 108310 架构图难以理解的话,可以看看灵魂画手的杰作~ 108311 结合分布式引擎说明的技术原理,将各个机器再细分化各个组件的作用。 108327 以上,将系统架构规划完成,即可具体完成系统。 2.完成从MongoDB取数 使用BI工具对接MongoDB的时候,使用MongoDB的BI连接器。感兴趣可以看:MongoDB Download Center 方案原理:mongodb是非结构的数据库,而要想BI来连接,通过建模的方式取表,拆表,建模来分析。通过MONGODB CONNECTOR FOR BI连接器的方式,使用mysql的JDBC驱动来获取数据。 实现过程: 第一步:安装MONGODB CONNECTOR FOR BI从官网选择版本:MongoDB Download Center 第二步:生成DRDL文件mongodrdl是生成该文件的主命令。通过添加monogdb的相关参数来获取其中的表生成drdl文件。从官方文档上我们可以找到生成DRDL文件命令的范式:mongodrdl --host myhost.example.net:27017 \ --username dbUser \ --password myPassword \ --db reports \ --authenticationDatabase admin \ --out schema.drdl范式说明: --host 是mongodb的ip+端口号,通常可为127.0.0.1:27017 --username 是mongodb的用户,需具备相关的数据权限 --password 是username的密码 --db 是要生成DRDL的数据库实例名 --authenticationDatabase 是指定创建用户的数据库。即username创建时被指定到的数据库名。 --out 是DRDL输出文件定义。值使用.drdl的文件即可。 第三步:启动连接器,连接上monogdb启动连接器的主命令服务是mongosqld,由于mongodb开启用户认证了(auth=true)。从官方文档上可知,连接器的启动需要使用-auth参数,再使用auth参数的情况下,mysql驱动来取数就需要SSLl加密认证。 所以第一步需要配置mongosqld的SSL认证;才能启动连接器来取数!!!!!!!!!!这一步神坑,也是踩了多少坑,才找到的解决办法。此处认证关系是FineBi端的mysql连接与mongosqld的连接之间的SSL认证。在认证时,只需要配置单向SSL的认证即可(mongosqld认证FineBI的连接)。 (1)生成SSL认证文件SSL认证文件通常采用openSSL来生成,先看看是否安装了openSSL;执行命令:rpm -qa|grep -i openssl 如安装了会返回信息,未安装需要自行安装OpenSSL。采用以下命令来生成证书:(由于是测试,就直接自己生成证书,密钥)openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key 命令返回会让填写一些值,在后面填写即可。一般情况下,文件会生成到你所使用的linux用户的要根目录下:比如我用的root用户,就到/root下面查找。再使用以下命令,将key合到.pem的文件里。cat mongodb-cert.key mongodb-cert.crt > mongodb.pem 将该文件移动/etc/ssl下面用于验证使用:mv mongodb.pem /etc/ssl (2)启动连接器&SSL再来看官方文档,从所有的参数命令里面,找一找需要的参数;得出以下的范式,在bin目录下启动即可。mongosqld --auth --sslMode --sslPEMKeyFile --sslAllowInvalidCertificates --defaultAuthSource --mongo-uri --mongo-username --mongo-password --mongo-authenticationSource --schema说明: --auth 是开启用户认证的参数,默认值是true --sslMode是开启SSL的标识,如开启可以选择值为“requireSSL” --sslPEMKeyFile是SSL认证文件,一般为.pem结尾的文件;单向认证的时候。 --sslAllowInvalidCertificates --defaultAuthSource是mongosqld使用username指向mongodb的有权限的库,默认值是admin --mongo-uri是mongodb的host,一般为ip+端口号 --mongo-usrname是drdl生成的用户名 --mongo-password是drdl生成的密码 --mongo-authenticationSource指定用户的创建库 --schema是要连接的drdl文件。 注:一般还是要用nohup 的命令来生成,保证shell断掉,连接器依然可用。 第四步:启动FineBI连接到连接器上启动FineBI,打开FineBI>数据配置>数据连接:添加数据连接选择mysql,配置如下: 连接名:mongodb URL:jdbc:mysql://127.0.0.1:3307/test?ssl-key=/etc/ssl/mongodb.pem 用户名: 密码: 注:URL:jdbc:mysql://ip+3307/dbname?ssl-key=xx.pem,后面ssl-key是ssl参数点击测试连接即可。 108329 过程坑点:mongodb的BI连接器神坑,官网文档不多,踩过了几脚坑。(1)mongosqld按ssl认证开启成功,打印也不错,但是BI连接的时候,还是抛错1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR):this server only allows SSL xxxxx该抛错是mysql抛出来的,握手不良的错误。按道理SSL已经开启了,不应该是这样。后来查了mysql的文档,mysql5.5以上的版本才支持SSL;更换新的driver驱动,使用的是5.1.44完全没问题的。(2)BI连接的时候抛错 handshake error: ERROR 1043 (08S01): error performing authentication: unable to authenticate conversation 0: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.该抛错的意思,使用“SCRAM-SHA-1”的认证方式,没有认证成功。SCRAM-SHA-1是指用户名密码的方式,这里看是不是用户名/密码错误,注意mongosqld启动时的使用的用户名/密码(3)一定要开启SSL认证啊!!!(4)期间有设计器无故死掉的情况,发现是由于内存不足导致。记得空闲内存要足够!! 三.系统效果 1.数据更新(1) 单个表先全量抽取,之后每天对单表依据时间戳,做增量增加。其中有错误数据做增量删除即可。(2)有些内部使用的实时性较高的表,设定每2小时更新一次,从上午9点到下午6点。直接从业务库抽取其实是有风险的,当时数据库压力大,抽取比较慢,因此这部分仅作为非重点用户需求场景。 2.数据展示速度做了一个简单的依据时间的group by,时间在1s之内,翻页速度也很快。 108331 至此,对接mongodb完成,一个用户可以随便玩的系统就好了。即使偶尔mongodb发疯修整,有离线数据在,也不担心业务部门来嚷嚷了。而且速度超快,体验很棒~
金融行业案例之江苏银行使用FineBI搭建多维分析平台
1.客户背景江苏银行是在江苏省内无锡、苏州、南通等10家城市商业银行基础上,合并重组而成的现代股份制商业银行,开创了地方法人银行改革的新模式。江苏银行于2007年1月24日正式挂牌开业,是江苏省最大的法人银行。江苏银行秉承“融创美好生活”的使命,以“融合创新、务实担当、精益成长”企业文化为引领,致力于建设“特色化、智慧化、综合化、国际化”的一流商业银行,已成长为一家综合实力和市场竞争力较强的现代股份制银行。截至2016年末,资产总额达15983亿元,各项存款总额达9074亿元,各项贷款总额达6494亿元。江苏银行下辖13家省内分行、4家省外分行,服务网络辐射长三角、珠三角、环渤海三大经济圈,实现了省内县域全覆盖。营业网点541家,员工1.4万人。发起设立了苏银金融租赁公司和丹阳保得村镇银行。2016年8月2日,江苏银行首次公开发行A股在上海证券交易所成功上市,股票代码600919。江苏银行的发展得到了社会各界的肯定,获得江苏省委省政府“江苏省优秀企业”、银监会“全国银行业金融机构小微企业金融服务先进单位”、《金融时报》“最具竞争力中小银行”等多项荣誉称号。在英国《银行家》杂志2016年度全球1000强银行排名中,按一级资本列126位,是中国排名提升最快的银行之一。被美国《环球金融》杂志评为中国最佳城市商业银行。2.项目背景2014年10月17日,夏平董事长确立利用大数据弯道超车的发展战略,2015年上半年开始进行大数据平台选型与建设,8月开始将内外部数据进行整合。整合的整个大平台定位于大数据变成对决策者、管理者乃至一线员工有用的信息和知识,进而提炼成具有指导作用的智慧,因此为平台命名“智多星”平台。传统的取数模式是业务用业务语言提出需求,科技人员和业务部门就业务语言如何转换成科技语言进行口径确认,之后开发报表提供业务测试,测试中常常发现报表实现和业务需求有差距,还要反复沟通,从业务提出报表需求到最终投产,快则三五天,慢则个把月,而且做出的报表,到了分支行,还会有口径上的调整,分支行人员还要导出excel再自行加工。传统方式的缺点显而易见,因此我们希望对于业务口径一次性的加工成主题包,将定制好的主题包以可视化的方式、业务的语言提供给业务部门,业务人员根据自己的需要拖拉拽即可自由地探索数据,不仅总行人员可以探索,分支行的人员都可以自由探索,这就是江苏银行智多星的由来。“智多星”大数据分析云服务平台是智慧化的综合数据查询挖掘平台。银行内部管理人员通过该平台可以方便快速地查询到经营指标、绩效指标、财务指标、风险指标、监管指标等经营现状,业务人员借助其对业务关系的了解在可自主创建、挖掘分析数据,并通过不同的统计维度了解各个方面指标。平台针对不同的对象提供固定报表、快速报表、查询产品和多维分析四大模块,面向不同的应用场景和使用人员。其中多维分析模块嵌入的就是FineBI。3.项目周期2015年9月到12月,针对业务自助分析进行需求探讨,厂商交流,测试,最终定下适合江苏银行当前形势的产品finebi,并且由江苏银行数据团队全权负责自助查询、分析的项目的建设推广;2015年12月到2016年3月,针对业务部门需求,提供出第一批主题分析包,面向计财进行试点,通过沟通、培训等方式完成了ERP多维盈利分析主题,针对ftp、成本分摊进行多维度自助分析,得到计财部领导认同,开始进入小步快跑阶段;2016年3月到2016年6月,逐步完成了计财部理财、中收检测、资产负债等模块,同时针对营运部,设计并完成了电话客服、在线客服、智能语义、集中作业等主题;2016年6月到2016年底,逐步推广总行风险部、公司部、卡部、零售部、网金部、小企业金融部等部门,总行层次业务部门认可参与度不断提高,达到千人千创意的雏形;;2016年底至2017年4月份,针对帆软进行了升级处理,改变以往纯粹index模式,index+direct的方式,协同处理,优化了响应时间,提高业务满意度。同时平台用于辅助串串盈业务的推广分析,并及时发现了恶意刷豆行为,降低了行内的无效损失;2017年4月至今,将智多星逐步推广至分行科技、计财、营运、公司部门,消除以往集中式响应的低效弊端。营运客服部门,计划自助做大屏分析,检测智能客服与人工客服接入现状,到降低人工成本的切入点。科技部门计划将之前老BI系统中的内容,转到多维分析中。4.重点使用部门与场景科技部 总行科技部 运维调度监控、业务系统交易量与批量统计 分行科技部 串串盈项目分析 业务部 业务部门 使用场景 计财部 对标上市银行分析、ERP多维盈利分析、重点客户利润监控与分析、资产负债、理财客户分析等 营运部 网点业务形态分析、客服中心运营分析、95319客户特征分析、集中作业汇兑业务分析等 卡部 网贷客户分析、网贷业务量分析等 网金部 货币基金销售情况分析 公司部 重点客户分析 5.详细案例(1)解决了跨数据源分析的问题下图是配置的业务包,基础数据组的很多表都会作为维度表与各个业务部门的详细业务表做关联。这么多的业务数据,自然不可能存放于一个库里。还有各种各样的外部数据,比如excel文件型数据等等。如何在一个平台的统一使用并分析到数据,并做到数据处理与使用不冗余呢?FineIndex的抽取数据策略与FineDirect引擎的关联模型策略完美实现了多数据源整合的问题。独创的主题型业务包,方便了IT人员配置业务包(公共的主题业务包、不同部门分主题的业务包等)以及业务人员使用相应主题下的数据。69307(2)自主分析1)对标上市银行主题数据上:计财部的对标上市银行主题,将人行每周、旬、月、季度下发的股份制银行存贷款表、共享风险月报、共享中间业务等等共享数据,首次由科技部将这些excel导入到相应业务包之中,之后就由业务人员自主在前端进行更新,免去了每次导入数据由科技部门来做的麻烦。分析上:业务人员根据给的数据,会对给到的主题表进行相应的分析。从而与省内银行数据进行对比,发现差距,为领导的决策提供帮助。693152)串串盈主题 从16年底开展“串串盈”项目起,项目上的各种数据的分析都使用FineBI来进行。实时性的数据使用FineDirect,T+1数据使用FineIndex,搭配起来使用使得资源最大化被利用,同时满足分析上的要求。简单拖拽分析,快速搭建自己想要的分析。如图的历史交易量统计分析(FineIndex),实时的新增注册用户(FineDirect),都是将自己想要查看的字段,拖拽到相应组件中,快速获得主题分析。 69308693093)ERP多维分析主题 这是个比较成熟的分析主题,从总行、分行、支行的各业务条线、PA条线、产品、对公对私用户等,通过不同维度上对利润的分析,为公司领导的决策带来一定帮助。69310 (3)FineIndex+FineDirect搭配使用,实现资源最大化利用 总行计财部门要对资产负债分析做实时分析,同时因为客户的oracle数据库本身做了索引的优化,借助直连的参数可以充分利用到数据库的优化效果,实现更便捷的数据分析。693116.总结FineBI在江苏银行的成功应用,降低了数据挖掘分析的门槛,将数据分析工作下沉到最基层。不需要了解数据库,甚至不需要懂太多数理统计的专业知识,只要了解业务的人员,都可以根据自己的一个关注点自定义分析和挖掘,并可以分享给其他员工。打破了原来总行定制固定报表,分支机构只能查询的集中式管理模式,变为了人人都可以是报表开发员的离散式管理模式,实现千人千创意,让数据发挥最大价值。 编辑于 2017-6-28 17:33
日期控件不绑定字段,指标过滤晚于日期会出错
12345下一页
个人成就
内容被浏览12,002
加入社区7年239天
返回顶部