银行传统数据仓库向大数据平台迁移探索

银行传统数据仓库向大数据平台迁移探索

【摘要】面对业务发展、数据化转型等各方面的需求，基于传统架构的银行数据仓库体系面临极大的挑战。某银行目前既有传统架构的数据仓库，也引入了基于主流Hadoop体系的大数据平台。为优化数据重复加工与存储，促进信息管理应用的数据融合共享，本文在采用大数据技术构建统一的企业级数据管理平台，重构数据仓库方面进行了探索，以论证传统数据仓库往大数据平台迁移的可行性，为某银行在大数据战略上的规划提供一定的支持。探索过程涉及现状调研安排、架构设计、模型迁移与优化、数据迁移、ETL迁移、数据访问接口的迁移、容量规划等多个核心环节，并依照该行的特点进行了一些有意义的尝试。

一、银行大数据平台建设背景在全球经济进入数字化转型时期，数字化转型已成为传统企业必须付诸行动的必选题。当下数字化转型已经渗入人们日常的衣食住行、工作生活、生产服务等方方面面。在消费金融具有极大发展潜力及前景的情况下，银行进行数字化转型更为迫切。而面对数字化转型的需要，银行体系中的传统数据仓库普遍面临极大的挑战：（1）现有数据仓库的数据分析模式，不能有效支撑数据快速分析和价值发现，需要新的交互模式发掘数据的统计相关性、因果关系、关联关系等规律。（2）数据源不断增多，访问和数据同步变得复杂。（3）数据量增大、应用作业不断增加，运行沉重缓慢。（4）难于支撑海量非结构化数据存储与检索需求，如影像数据、音频数据。我行使用传统数据仓库多年，虽然尚未完全触碰到上述问题的极限情况，数据仓库依然稳定的在支撑我行业务的运作，但随着业务的发展，上述传统数仓的困境在我行也有了一定的展现。为提前布局，灵活应对，我们进行了多种尝试，包括继续深挖现有系统潜力、迁移到大数据平台等。经过对业界和同行的调研，我们了解到，相当部分的银行最终选择了将数据仓库迁移到大数据平台，而我行从2017年开始，已经引入了源于Hadoop体系的科技大数据平台，具备迁移的能力。下文是我们结合同业经验，在我行探索环境中实验的，对我行数据仓库进行模拟迁移中所作的一些探索经验。二、软件架构选型Hadoop是一个由Apache基金会所开发的分布式系统基础架构，Hadoop框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算。Hadoop是当前世界企业管理大数据的基础支撑技术。分布式文件系统HDFS：HDFS（HadoopDistributedFileSystem），作为GoogleFileSystem（GFS）的实现，是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（LargeDataSet）的应用处理带来了很多便利。HDFS的架构如下图所示：一般情况下副本系数为3，HDFS的副本放置策略是：将第一个副本放在本地节点，将第二个副本放在本地机架上的另一个节点，而第三个副本放到不同机架上的节点。这种方式减少了机架间的写流量，从而提高了写的性能。机架故障的机率远小于节点故障。这种方式并不影响数据可靠性和可用性的限制，并且它确实减少了读操作的网络聚合带宽，因为文件块仅存在两个不同的机架，而不是三个。文件的副本不是均匀的分布在机架当中，1/3的副本在同一个节点上，1/3副本在同一个机架上，另外1/3个副本均匀地分布在其他机架上。分布式计算框架MapReduce：MapReduce是面向大数据并行处理的计算模型、框架和平台，它隐含了以下三层含义：（1）它是一个基于集群的高性能并行计算平台（ClusterInfrastructure）。它允许用市场上普通的商用服务器构成一个包含数十、数百至数千个节点的分布和并行计算集群。（2）它是一个并行计算与运行软件框架（SoftwareFramework）。它提供了一个庞大但设计精良的并行计算软件框架，能自动完成计算任务的并行化处理，自动划分计算数据和计算任务，在集群节点上自动分配和执行任务以及收集计算结果，将数据分布存储、数据通信、容错处理等并行计算涉及到的很多系统底层的复杂细节交由系统负责处理，大大减少了软件开发人员的负担。（3）它是一个并行程序设计模型与方法（ProgrammingModel&Methodology）。它借助于函数式程序设计语言Lisp的设计思想，提供了一种简便的并行程序设计方法，用Map和Reduce两个函数编程实现基本的并行计算任务，提供了抽象的操作和并行编程接口，以简单方便地完成大规模数据的编程和计算处理。三、服务器架构选型目前市面上主流的服务器有intelX86架构和ARM架构。X86架构于1978年推出的Intel8086中央处理器中首度出现。X86架构（TheX86architecture）是微处理器执行的计算机语言指令集，指一个Intel通用计算机系列的标准编号缩写，也标识一套通用的计算机指令集合。X86架构的强大并不在于它本身，而在于围绕着它所建立起来的：软件生态。而X86架构上面建立了各种各样的基于X86指令架构的程序，这就是它的强大之处。ARM架构过去称作进阶精简指令集机器（AdvancedRISCMachine，更早称作：AcornRISCMachine），是一个32位精简指令集（RISC）处理器架构，其广泛地使用在许多嵌入式系统设计。由于节能的特点，ARM处理器非常适用于移动通讯领域，符合其主要设计目标为低耗电的特性。在性能方面，对于大数据负载来说，英特尔®至强®可扩展处理器为代表的x86处理器性能高于ARM处理器。在生态方面，大数据平台选择得到充分验证和优化的硬件平台尤为重要，大数据工作负载在IntelX86平台上已经适配多年，有着很好的成熟度，也不需要企业对软件（如移植）进行额外投资，对于IT人员来说，也能快速掌握在IntelX86平台上的开发运维。例如Spark、DeepLearning、MongoDB等，英特尔®至强®可扩展处理器都有经过验证的优化指南。在开放性方面，采用英特尔®至强®可扩展处理器为代表的x86服务器脚骨可以实现跨厂商解决方案的兼容性和可持续性。综合性能、生态和开放性等方面，大数据平台选择采用英特尔®至强®可扩展处理器为内核的x86服务器作为计算节点和数据节点。大数据平台很多应用场景属于计算密集型，在计算密集作业下CPU是系统运行效率的关键，CPU性能提升能够大幅度加速整体作业的运行效率。第三代英特尔®至强®可扩展处理器提供了具备多至8路的扩展能力，每个处理器最多可达40个核心，可为大数据平台提供进一步突破性能瓶颈的基础。四、迁移选型要求完全开源的Hadoop项目对中小银行而言有较大的挑战。首先，开源的Hadoop技术在对GB到TB级数据的处理效率较低，需要较深入的底层调优。其次，只有对海量的数据进行高效的分析及利用才能将大数据中存在的巨大潜在价值转换为实际的商业价值，企业亟需完备的解决方案来加速大数据应用的业务创新。最后，中小银行因编制因素，科技人员数量有限，熟练掌握大数据技术的技术人员更是稀少，需要成熟的服务商进行早期的引导和技术支持。因此，我行要从自身应用角度出发，通过对国内外众多主流大数据平台产品的技术能力和实现细节详细了解、对比、筛选，并对候选产品进行严格的POC测试，最终选择更符合我行需求的大数据平台产品。五、迁移策略为降低迁移风险、缩短迁移周期、保证迁移进度，参考同业经验，我们将采用了“原样迁移、重点优化”的策略模式。其中，原样迁移策略表示：（1）参考信息架构基本不变，保持数据仓库现有的分层架构体系。（2）上下游接口基本不变。（3）脚本加工逻辑基本不变。重点优化策略则表示：（1）基于新平台特性进行专项优化。（2）在维持现有的E-RLDM设计模式基础上，重点优化基础模型。（3）基于维度建模构建银行重要业务对象的一致性维度和汇总事实，对应用层重点优化。为贯彻迁移策略，达到良好的迁移效果，结合项目管理经验，我们将整个迁移过程分为：现状调研、架构设计、模型迁移、数据迁移、ETL迁移、接口迁移等多个步骤。每个步骤都是承上启下，前后关联。六、迁移关键步骤探索1.现状调研了解现状是整个迁移工作的基础，我们要对数据仓库现状进行详细调研，确定大数据上的库架构，整理现有数据仓库的数据迁移范围，完善迁移技术需求和项目实施方案。调研内容包括数据仓库架构、各数据表及数据量统计、各数据模型及DDL、库表的作业运行和依赖、库表的下游使用情况、相关设计文档、设计开发规范等等。为更好的做好调研工作，我们制定了如下的文档收集指引：序号文档分类文件收集指引文件收集目的01数据架构类数据架构规划类文档：了解行里数据架构规划指引大数据平台的架构设计和库表规划等。02数据架构说明文档：了解行里现有平台的架构设计、落地说明和功能定位等。与迁移后平台架构做对应。03基础模型类信息调研文档：对现有平台上的业务系统、信息调研分析等。支持数据模型优化04数据模型文件（E-R图）：数据模型的设计、归属主题域等。支持数据模型优化05ETL开发文档：数据模型与业务系统的映射。支持优化后数据模型的开发06标准编码维护文档：基础层代码值支持数据模型的编码07汇总模型类汇总层模型：汇总层模型的设计、归属主题域等支持汇总层模型优化建议08汇总层ETL脚本：汇总层模型的开发逻辑支持汇总层模型优化建议09标准编码维护文档：汇总层代码值支持汇总层代码值的编码10下游应用类应用需求文档：下游应用的业务需求文档支持对下游应用的业务逻辑理解11应用模型设计：应用数据模型的设计、归属主题域等支持应用模型优化12ETL开发文档：应用模型与业务系统的映射支持应用的开发迁移13标准编码维护文档：应用层代码值支持应用的开发迁移相关调研工作，为后续的设计、开发、测试等工作奠定坚实基础，保障了生产数据迁移的可靠性。2.架构设计在架构设计方面，我们即要考虑当前迁移的需求，也要结合行里的规划及场景需求，通盘考虑，相关设计既要立足现在，更能面向未来。为了减少实时类应用与批量类应用之间的相互影响，保证重要系统性能及稳定性，我们优化早期单集群的架构，将重要应用独立到一个集群，称为应用服务区；其余应用部署到另外集群，称为基础数据区，最终逻辑架构设计如下：对于应用服务区，首先从技术上它只能满足小批量数据处理，对数据的查询及加工处理延时要求比较高，一般要求必须在1秒内返回结果，不能接受超过2秒的延时。其次从业务的角度看在应用服务区的应用都是对我行比较重要的，比如我行的生产运营系统-银行柜面客户历史数据查询系统，又比如我行对客系统进行数据支撑-APP应用中的客户收益明细、实时风险等。对于基础数据区定义是大批量数据处理平台，海量数据存储平台，它也可以满足小批量数据处理的需求，不过因为存在大批量数据处理应用资源挤压问题，小批量数据处理可能存在性能波动的风险，我们一般用于承载我行数据湖业务、数据仓库业务、营销分析、报表平台等。采用此架构，两个集群稳定运行，实时查询与批处理等大任务拆分开，实时查询可稳定对外提供服务；基础数据区全天皆可运行批处理等大作业，集群处理能力更强等。3.基础模型层迁移及优化在我行中，模型层模型主要以E-R(实体-属性）构建逻辑数据模型（LDM），来反映银行的业务属性及其关系，其是逻辑性的，与具体承载平台无关。因此在实际迁移中，我们要基本保证了数据模型的不变。但在项目实施过程中，我们也要借机进行成熟度评估，然后根据平台特性构建新的物理模型。我们结合实际情况整理迁移判断逻辑如下：逻辑模型在设计过程中，为保证模型的稳定性，往往采用泛化、子类、抽象、拉链等设计模式。在实际物理化时，往往都是严格遵守了与逻辑模型一致的1:1物理化方式，导致模型的性能问题。针对这些设计模式，可以采用适当的特化、上收下放、还原等优化措施。序号优化方式优化策略说明01子类上收下放例如主表信息下沉，子表冗余主表属性信息02泛化适度还原例如商户、机构从当事人剥离，独立为根节点03抽象按需拉横例如:建立联系方式的横表04属性按需冗余例如：当前表冗余部分缓变历史属性05属性垂直拆分例如：根据属性相关性和变化性对超宽表进行拆分泛化适度还原优化示意如下：属性按需冗余优化示意如下：4.数据迁移在数据的迁移中，为实现迁移的自动化，我们需要使用服务商的数据迁移工具，相关工具要能从现有数据仓库中读取DDL信息，自动转化为大数据平台的DDL。相关工具转化速度取决于大数据平台的资源限制及网络带宽，根据同业的经验，理论上迁移速率可达100-250M/S甚至更高。迁移过程示意如下：5.ETL迁移针对数据仓库的ETL工作，从技术实现角度进行分析，主要包括（1）物理模型设计及DDL生成；（2）平台间数据迁移；（3）基础模型层、汇总层、应用层等ETL开发；（4）迁移数据核对这几个部分。其中伍立模型设计及DDL生成是最核心的部分，本次迁移中，我们实施了如下设计原则，充分保障了存量数据迁移的可靠性。各层模型平台物理化建议：数据分层存储设计存储格式建议设计要点建议临时区TEXT历史区ORCTransaction分区+分桶基础区ORCTransaction分区+分桶汇总区ORCTransaction分区+分桶应用区Holodesk+ORCTransaction分区+分桶平台模型物理化原则建议：分类原则TEXT表Text表不要用作历史数据存储Text原则上仅作为数据入库缓冲层（仅存储当天数据）和临时文本入库后分析用ORC表不需要事务支持的ORC表采用ORC非事务表分区建议分区采用rangepartition建议分区字段选择->日期字段（或地区字段）不要使用二级分区建议分区数控制在200个以下分桶单个桶的数据量大小应小于200M（压缩后）分桶表最小分桶数设置为3单个分区分桶数在500个以内桶的个数为不包含31的质数分桶字段应选取表中的唯一值字段（如果无唯一字段，分桶字段重复率应小于1%）Hyperbase表唯一性原则：rowkey要保证唯一性，不然在插入数据是会覆盖之前的数据，造成数据丢失的风险散列原则：如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率长度原则：建议是越短越好，不要超过16个字节ES表一个shard对应数据不要超过20Gshard数量小于分配（页面设置的盘符）且可用的（磁盘剩余可用空间>50G/10%）磁盘数结合以上原则，我们可以根据现有的ETL脚本，从脚本还原出ETL映射文档，映射文档对脚本中的执行步骤，找出目标表字段与源表、源字段的对应关系，并分离出JOIN、WHERE、GROUPBY,ORDERBY,QUALIFY等子句，然后进行改写，生产大数据平台的存储过程，最终经过核验后落地实施。6.数据访问接口的迁移—ODBC/JDBC大数据平台主配置文件为Server.data，主要配置信息描述如下：连接串变为：jdbc:hive2://gateway地址:6666-nuser-ppasswd7.硬件配置集群27节点采用IntelX86架构物理服务器进行配置，保证各节点的计算性能详细配置如下：硬件配置CPU2xIntel(R)Xeongold5115MEM256GBHDD20x2.5SAS1.2TBHDD,2x2.5SATA960GBSSD集群各节点磁盘配置详情如下：8.角色规划集群各角色均匀分布在集群节点，详细规划如下：9.容量规划整体项目容量只要针对存量和增量两大部分进行，下表是我们结合一些数据，对数据仓库迁移所需容量进行的详细规划模拟计算，实际实施时需再根据情况重新计算。现有数据仓库存储一、基础指标指标1存量数据（T）280指标2每天增量（T）4指标3压缩比4二、吞吐量指标指标1解压后数据大小（T）1120大数据平台存储一、基础指标指标1压缩比3.5指标2副本数3二、吞吐量指标指标1存量数据存储（T）裸磁盘*压缩比*0.7（可用率）960指标2第一年空间（T）(日增量/1024)*300(工作日)1460指标3第二年空间（T）每年数据增幅*20%1750指标4第三年空间（T）每年数据增幅*20%2100指标5所需要总空间（存量+三年增量数据）（T）6270指标6所需要节点数量（按照目前机器配置20T*10*0.7实际存储空间）47（3管理+44数据）七、一些有意义的尝试机架感知调整：HDFS默认情况下虽然有3个副本，理论上能有效的保障数据不丢失，我们为了更有效的提高数据的可用性、可靠性以及更高的网络带宽利用率，可以考虑在实施过程中启用HDFS的机架感知。在默认3副本的情况下，启用机架感知，HDFS的存放策略是将一个副本存放在本地机架节点上，一个副本存放在同一个机架的另一个节点上，最后一个副本放在不同机架的节点上。这样即保证了读写效率，又通过机架的隔离进一步保障了数据安全性。启用机架感知需要配置文件core-site.xml，配置项如下：<property><name></name><value>/etc/hadoop/topology.sh</value></property>value是一个shell脚本，主要的功能是输入DataNode的IP返回对应的机架ID。NameNode启动时会判断是否启用了机架感知，若启用则会根据配置查找配置脚本，并在收到DataNode的心跳时传入其IP获取机架的ID存入内存中的一个map中。一个简单的配置脚本示意如下：#!/bin/bashHADOOP_CONF=etc/hadoop/configwhile[$#-gt0];donodeArg=$1exec<${HADOOP_CONF}/topology.dataresult=""whilereadline;doar=($line)if["${ar[0]}"="$nodeArg"]||["${ar[1]}"="$nodeArg"];thenresult="${ar[2]}"fidoneshiftif[-z"$result"];thenecho-n"/default-rack"elseecho-n"$result"fi

done

其中topology.data的格式为：节点（ip或主机名）/交换机xx/机架xx，一个参考配置样例如下：

xxx.xxx.xxx.91tbe192168147091/dc1/rack1xxx.xxx.xxx.92tbe192168147092/dc1/rack1xxx.xxx.xxx.93tbe192168147093/dc1/rack2xxx.xxx.xxx.94tbe192168147094/dc1/rack3xxx.xxx.xxx.95tbe192168147095/dc1/rack3xxx.xxx.xxx.96

tbe192168147096

/dc1/rack3修改完成后，可以使用./hadoopdfsadmin-printTopology查看机架配置信息。回收站设置：为防止在线数据被误删，我们建议在实施时，开启了HDFS的回收站功能，开启后，HDFS会为每个用户创建一个专属的回收站目录（/user/${}/.Trash），用户删除文件时，实际上是被移动到了回收站目录，在紧急情况下能够及时从回收站恢复这些数据。其主要配置示意如下：<property><name>erval</name><value>4320</value><description>Numberofminutesafterwhichthecheckpointgetsdeleted.Ifzero,thetrashfeatureisdisabled.</description></property>

<property><name>erval</name><value>15</value><description>Numberofminutesbetweentrashcheckpoints.Shouldbesmallerorequaltoerval.Everytimethecheckpointerrunsitcreatesanewcheckpointoutofcurrentandremovescheckpointscreatedmorethanervalminutesago.</description></property>其中，erval表示回收站数据保存周期，单位是分钟，我