最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

银行业如何通过Greenplum方案玩转大数据

[复制链接]
发表于 2018-4-22 14:59:04 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
摘要

本文将与大家分享某银行信用卡中心基于Greenplum新一代数据平台的建设情况, 包括三个主题:一是新一代数据平台建设情况介绍。二是数据平台现状和未来的规划, 三是数据平台运维经验。

新一代数据平台建设情况
该银行信用卡中心在2015年之前的数据处理平台是基于老的SAS系统构建,SAS分析系统具备专业的数据分析能力,但是数据规模急剧增长下逐渐暴露出数据存储、安全、治理、性能和BI应用方面的显著弱点,在这种情况下,从2015年开始,卡中心决心通过规划建设新一代的专业数据仓库来解决以上问题。

新一代的数据平台的建设内容,总结为“三个平台加一个工具”,即 “专业数据仓库平台+分布式大数据平台(hadoop)+可视化分析平台+SAS分析挖掘工具”。

其中最主要的是专业的数据仓库,早期根据市场的调研和同行业的经验分享,定位成MPP架构的数据库。除了专用的数据库,还需要建基于Hadoop平台的大数据处理平台,包括可视化的分析平台,即BI平台。

  • 专业的数据仓库平台——银行的一个数据总线,作为数据的汇总积累、加工处理。
  • 分布式的大数据平台——为历史数据进行存储、归档,包括非结构化数据的存储,以及一些外来数据的存储。
  • 可视化的分析平台——一个面向全行的业务人员的数据查询的服务中心,提供灵活查询、自助分析、固定报表的各种功能。
  • SAS工具——专业领域的数据建模和分析的工具。



项目前期准备
从2015年开始,经过一些同业的调研,对产品进行选型和POC测试,最后认为Greenplum产品在性价比和技术架构方面都比较符合需求。于是在2016年6月份的时候,卡中心正式开始了该数据平台项目的建设。在2016年底的时候,完成了数仓的一期的建设。

2.webp.jpg
项目建设过程

整个建设过程分几个阶段。三个平台基本上是齐头并进,同时建设。

3.webp.jpg
整体架构

总体的架构分三块,一个是Hadoop大数据平台, 支持业务系统、客户立体画像和大数据实时服务。二是数据仓库,数仓基于Greenplum的架构三是智能化分析平台。这三者中,最主要的是数据仓库,数据仓库底下对接的是银行各个原系统,包括银行发卡、积分、征信等内部的数据系统。经过统一的ETL处理、数据的清洗加工,汇入到ODS层,再根据内部的数仓脚本进行存储功能处理,加工成业界比较流行的十大主题模型。

大数据平台,该银行卡中心的规划是一个是历史数据的存储,另外是一些外部数据的接入,包括微信的、手机app的外部数据源引到数仓里。在2016年底的时候,卡中心基于kafka、storm的一些流处理的方式,上线了一个实时处理的营销活动的平台 。

在数仓旁边,有一个沙盘演练区,其实是UIT环境跟测试环境。为业务人员做一些数据的探索和应用。

上层正在建设的是智能化分析平台,面向行内的业务用户,提供各种报表发布、自动分析等等。

这几个平台的定位或者说数据流向是什么样的呢?

4.webp (1).jpg
各子系统定位

面对各种数据源,有明确的管理分析价值的数据会进入到数据仓库,特别是所有的内部系统数据,都会放到数据仓库里进行统一的汇总、加工,建立主题模型,保持数据结构的稳定。然后为下游提供统一的接口服务。非结构化的数据、外部的数据源,以及一些历史归档数据,放到大数据平台,因为大数据平台的存储量更大,数仓的超过生命周期的数据,需要归档的数据,也放在大数据平台里存储。

下游的系统,包括BI平台、SAS工具,使用的时候都会在数仓也就是Greenplum的数据库里面供他们来使用。

5.webp.jpg
逻辑架构

上图是一个简单的Greenplum系统里面的逻辑架构。底层是结构化的数据源,中间物理层平台是Greenplum的集群节点,包括统一调度平台、ETL工具平台,还有一些数据管控的服务器和配置库的服务器。使用的支撑平台是由厂商公司的产品进行统一的调度,包括元数据管理和数据质量的管理。

数据的集成区,首先会把数据源下发的数据,一般是以一种文本文件的方式,通过Greenplum的内部的爬虫处理进行主题模型的数据的加工汇总,然后再到汇总层,再到接口层,最后再通过ETL工具下发给下游系统,基本上是这样一个逻辑架构。

6.webp.jpg
物理架构

再看看物理架构图。其实也是一样道理,左侧是它对接的数据源,上游系统,一般是一种CIC文件的方式,放到文件服务器上。中间是数据仓库的物理部署图,现在的情况是,Greenplum的集群节点是2个master+30个节点,是2+30的架构。包括ETL服务器、资料库的服务器都是双机备份这种方式。几乎所有的地方都要考虑到高可用的方式。右侧是数仓对接了下游的大数据平台和智能化分析平台。

具体的技术实现就是物理平台上面的ETL工具,该银行卡中心用的Informatica产品,调度工具用的Greenplum厂商的USE、FEX整体的调度工具,资料库用的Oracle数据库。缓冲层,也就是数据的天然层,用的是Greenplum的存储过程的方式,通过Informatica的方式去调用,上层的加工处理也是通过存储过程层层的进行数据的加工处理。好处是它的编写和修改都很方便 。

数仓的基本状况和规划
2016年12月数据仓库平台上线以来,系统运行情况良好,全面提升了卡中心在数据处理方面能力,有效的支撑了快速发展的信用卡业务需求
7.webp.jpg
原来的老SAS系统是共享存储的方式,资源竞争的非常厉害。性能上,之前的批处理经常会有T+2或者T+3才能跑出来的情况,在现在的情况下,基本上T+1完全没有问题,并且可以保证一些实时性要求比较高的数据加工处理,也支撑了很多银行的周年庆活动。随着数据源逐渐丰富,目前的数据量也已经达到了70T以上,给下游的系统也提供了很多的接口服务

对于数仓这块未来的规划,该银行信用卡中心计划把数仓建成Greenplum多集群的方式。当前的数仓有一个主批集群,还有一个测试集群,这个环境也同时给业务员做一些数据查询工作。未来规划的集群包括:测试集群有UAT,查询集群会单建出来,还有一些报表集市,以及Hadoop集群。所有的数据都从数仓通过数据同步的方式给下游的集群。好处是:
第一,各集群隔离互不影响,增加并发响应能力。特别是查询集群,因为面向全行的业务人员,它的查询压力太大。如果放到数仓的主批集群里,它们之间会有一些竞争,而主批集群要保持它的稳定性,这样做可以增加并发响应能力。

第二,查询集群作为数仓的双集群备份系统,数据保持同步,作为灾备并分担查询压力。在数据量比较大的情况下,卡中心目前的灾备系统是通过数据库自带的备份方式,备份到磁盘本地,然后再通过磁带库导出到财务部,然后再备份。每次数据量都非常大,数据文件也非常大,如果出现灾难的问题, 数据恢复周期会非常长。所以这种方案其实不太具有操作性。

该卡中心的想法是,把查询集群做成一个同等的备份集群,如果是单独做一个冷备的话,对资源是非常浪费的。而作为灾备系统,同样的集群可以额外为查询分担压力。

数仓和平台的运维过程中遇到的问题和经验
第一,系统部署要符合最佳实践。Greenplum厂商会提供很多建议,在做架构规划和系统部署安装的时候有很多最佳实践供参考。这方面的建议是需要尽量采取GP厂商的最佳实践 。目前卡中心的硬件部署情况是Greenplum集群是2+30个节点,单机配了24块硬盘,两块做系统的RAID1的备份,22块做数据盘的存储,分成两个组,每个组10+1,1就作为热备的盘,配置RAID5,保证数据流量的高可用。单机可用空间10个T,30个机器的规划是150T。Greenplum有1:1的副本备份,所以当时规划的容量是150T左右,双万兆交换机的配置。

第二,系统安装部署遵守文档,有一些文档很详细,里面包括操作系统的参数建议,包括硬件的一些配置建议,都会很详细,在做系统安装部署时遵守文档即可。该卡中心遇到的情况是,在操作系统层面,最开始卡中心安装了7.2的系统,但是遇到了一个系统级的bug,导致经常会有进程的问题,较不稳定,就回退到了6.8的系统,问题就解决了。等这个操作系统更完善之后,卡中心表示会陆续更新系统。

第三. Mirror配置这块,GP提供几种方式,一种是group方式、一种是spread方式,主要区别在于将它的副本放在什么节点。group方式就是一台机器的副本完全放到另外一台机器上。spread的方式就是它的一台机器的副本平均要打散到不同的机器上。这两个方式各有优劣。group方式就是一台机器down了,所有的负载都会放在另外一台机器上,性能会下降50%。spread方式会打散,但是机器的可用性会下降。卡中心采用的是自定义的方式,自己定义它的副本的存储方式,卡中心把每一个节点的mirror平均分配到另外两台机器上,每一台机器承载1/2的负载,兼顾它的可用性和性能损失。

遇到机器故障导致的节点宕掉,那另外的节点会接过来,观察它的性能的损耗后发现,对某一种性能几乎没有太大的影响。

有一点需要留意,硬件故障的时候,Greenplum的机制会导致一些正在使用的SQL执行失败,所以在应用层的时候需要考虑脚本的可重跑性,也要考虑一些失败的情况下可以自动的进行重试的机制 。

第四、应用开发要遵守开发规范。厂商也提供了很多详细的开发规范,包括表分区、存储方式、压缩比率是多少,都有很多的建议。开发的时候规范是有的,重要的是要遵守这些规范,而且要不断地检查,不然时间长了的话,就有可能跑偏,慢慢会暴露出一些问题。

第五,Greenplum的统计信息要及时收集,因为它是基于成本的执行规划的方式,统计信息对于执行计划非常重要,所以在每次数据更新的时候,要进行统计信息分析,还有垃圾回收机制,每天在后台都定时运行数据分析整理的脚本。

第六,应用比较多的是数据导入、导出,上游系统归到数仓,数仓给下游系统供数,都会有很多数据导入导出的方式,目前采用的是外部表的方式。在万兆网的环境下,速度是比较快的,卡中心也用了一些Greenplum自带的一些命令的方式,因为其高效率,性能表现也不错。

第七,用户权限的方式。可以利用Greenplum的资源队列,把各种类型的用户区分对待,使用不同队列。跑批与查询环境要分开,保持数据加工、数据仓库的可用性,同时增加并发的处理能力。

第八,是要建立系统监控体系。整个数据仓库的架构建立起来之后,重要的就是运维。该卡中心现在的做法是,应对监控,银行里有统一的监控平台,使用这个系统可以监控硬件的CPU、内存等这些东西。如果出现故障了,可以自动报警。数据库层面,一个是可以使用Greenplum的GPCC的界面去查询单一资源的使用情况,包括历史情况。另外,卡中心也加了一些后台运行的脚本,来监控它的实时状态。一旦有异常的情况,会自动触发平台去追踪。上层的整体的ETL作业监控,也是有应用平台自带的一些监控的界面和程序去实时监控。

数仓运行状态监控体系分为三大块:

8.webp.jpg
数仓运行状态监控体系

一、实时故障监控报警:包括服务器硬件监控、应用系统监控、数据库监控,同时还有一些平台、脚本做一些实时的故障的报警。

二、定期运行报告,监控整体的运行状况:包括容量的使用状况汇总报告,就是每一天的增量情况,还有一些规范性的检查,要有一些定期的脚本的检查,形成报告去改进。还有一些增长趋势的报告,系统监控的报告,事件月度的报告,比如机器有没有问题、报警, 还有一些可视化展示。

三、一些自动优化的处理:包括Greenplum的一些垃圾回收处理、统计信息处理、数据自动清理、分区合并操作。平台搭建起来之后,重在运维,所以整体的监控体系要尽量规范。

1.webp.jpg
通过这篇详尽的案例,您也深入了解了Greenplum在银行IT创新中的核心作用。不难看出,Pivotal Greenplum产品正以其出色的高性能、可维护性和高可用性,越来越多的获得银行、证券和基金等金融行业用户的认可。


楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 16:29

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表