返回目录：财经要闻
项目背景及目标
随着我行新一代核心系统建设项目的开展，如何处理海量历史数据，降低新一代核心系统建设中数据迁移的复杂度，如何显著降低核心系统负载，提高核心系统处理能力等问题逐渐提上日程。
目前，我行数据仓库涵盖了全行主要系统的绝大多数数据，已经形成金融机构级数据仓库基础数据体系，主要提供支撑经营管理的各类数据应用，由于数据量的日益增大，数据仓库批后处理时间逐渐变长，其中部分作业在特定日期已经影响到了后续作业；随着业务不断发展，我行对数据的查询、分析急需新的解决方案来解决和规划未来数据的加工策略，同时也对数据如何逐步发挥价值，协助金融机构拓展新业务方向，缺少比较切实可行的规划。
建设“大数据平台”成为既符合技术发展方向，又能解决我行痛点问题的解决方案。基于分布式存储和计算的大数据平台在PC服务器集群进行部署，打破海量数据处理的硬件依赖，以相对低的代价实现大量数据的存储和运算，且能够在非结构化数据处理、实时分析处理等方面有效弥补传统数据仓库的不足。但大数据平台在国内银行业仍处于起步和探索阶段，尚无成熟的理论和经验来管理平台的数据和应用，同业已实施的案例中存在着数据仓库和大数据平台间数据冗余、加工重复，大数据平台的各层组件间数据存放混乱、难以管理，上游系统变化造成数据平台维护量大、成本高等诸多问题。
项目方案
我行大数据平台使用的是Cloudera提供的企业级Hadoop平台，包含了例如HDFS、YARN、HBase、Hive等多种Hadoop生态圈中的常用项目。整个平台的定位是历史数据存储与后台应用平台，通过传输平台获取来自其他业务系统的业务数据，完成批量数据处理并且进行长期存放，并且通过上层开发的应用以服务或者网页的形式开放给对应业务部门，同时也可能将历史数据的分析统计结果接入传输平台，为下游业务提供数据支持。
大数据平台的核心是数据存储平台，需要满足对多个系统数据的统一存储。因此在数据接入区上需要一层贴源层，按照原数据格式将数据保存在平台上，保留原有数据的粒度。大数据平台需要支持多种业务，各自之间有不同的需要处理和保留的数据，需要在贴源层之上，为多种业务建立各自的数据集，即数据集市。另外，随着业务的发展，平台中一般都会出现重复的计算逻辑，可以进行优化和整合，来减少集群任务和负载。出于这种需求，将来还有可能在集市与贴源层之间出现语义层（semantic layer），将贴源层中的各种表和字段使用常用的计算逻辑变换成集市需要的指标，从而减少集市数据需要的计算负载。
• 贴源层：主要作用是集成来自其他系统的数据，以贴近数据的原始存储格式的方式进行存储，保持原有数据的粒度不进行统计与整合。其优点是数据不需要进行复杂的计算, 因此数据的接入过程较为简单。但是也因为数据不进行变换，很多无法应对上层使用的性能要求。因此，该层只为上层的数据服务提供数据基础，而不直接提供业务使用。
• 数据集市（Data Mart）：与传统的数据集市概念相似，为某个特定的服务或者业务准备的处理后的数据。主要作用是为各个业务部门直接提供计算数据与结果。其优点是本身数据结构是为了业务规则特别生成的，在上层处理时能提供较高的效率。但是，这部分数据需要加工，因此直接接入集群的数据无法直接作为数据集市数据使用。因此，数据仓库的数据在这里由下层数据生成，接入集群的数据不直接进入数据集市。
• 语义层（Semantic Layer）：当平台上的业务扩展时，贴源层与数据集市之间的ETL逻辑可能会出现不少重复的过程。为了减少重复任务，需要对这这些常用的指标进行整合。语义层的作用是将下层的表与字段转化成多个业务共同关心的指标，统一的为上层使用提供计算完成之后的数值。其优点是减少了贴源层与数据集市之间直接的重复计算，并且直接为业务人员提供业务相关的数据，业务人员可以不用直接与各个系统复杂的表和字段进行接触。语义层的搭建需要进行统一的规划，并且需要对业务系统有一定经验的项目人员，整理出对整个平台的其他业务系统有价值的数据指标。
数据的存放需要遵循一定的数据存放规则。根据贴源层与数据集市的数据性质定义，不同数据类型需要遵循如下的放置规则：
• 所有从传输平台上上传到Hadoop平台的数据文件，都直接存放在接入区，之后通过ETL任务存放到贴源层中进行存放
• 来自其他平台的业务数据表，都以与原有数据相同的粒度，在贴源层中进行存放。部分数据可能会进行初步加工，例如预关联与拉链加工，但是不会进行整合与统计操作。
• 所有对外提供服务的数据，即业务服务目标用户会访问到的数据，都存放在各自的数据集市中， 按照业务需要的格式进行存放，也可以是以逻辑视图的形式
• 业务自身生成的中间数据，在项目初期只存放在集市的数据空间中，不会进入到贴源层中
• 在业务系统建立时，需要整理业务数据可能包含的与其他系统相同的统计分析结果，为这部分数据存储在语义层中，或者沿用语义层中已经存在的相同结果。
项目创新点
我行从自身数据使用需求出发，搭建分布式的大数据平台，与现有传统的数据仓库有效结合，创新的形成了混合式数据平台架构，在此基础上完善数据平台的管理体系和规范，由数据仓库负责数据模型的维护和整合数据的加工，大数据平台负责贴源数据的存储、检核和供给、半结构化和非结构化数据处理、实时流数据处理。
这种混合式数据平台架构的解决方案，规避了数据平台数据冗余的通病，既降低了成本，又发挥了数据仓库关系型数据库和大数据平台分布式文件存储各自的功能和性能优势。依托建立在数据平台上的数据检核系统、元数据管理系统和指标管理系统，实现对数据质量、数据结构、数据标准、加工规则、生命周期等的管理，提升了我行的数据管理能力。
此外，我行以核心系统为试点，将分散在各业务系统的数据服务，集中到数据平台中，一方面减轻了业务系统的存储、访问压力，实现了业务系统的架构优化，另一方面有效改善用户从多个业务系统获取数据，操作繁琐，且在数据一致性和完整性上存在的问题的情况，并为用户提供灵活查询和数据分析的环境，提升了我行的数据服务能力。
技术实现特点
1.通过历史数据的近线存储实现业务系统减负和贴源数据运用。业务系统每天产生大量的系统日志和业务数据，这些历史数据对于掌握业务发展、IT系统运行状况具有重要价值。传统数据仓库受到成本制约，无法将这些数据全部长期保存，往往采用更倾向于高度抽象、保存结果、忽略过程的策略。这导致商业银行面临或者为了便于使用而将历史数据全部累积在业务系统中，或者为了节省资源采用离线存储，前者对OLTP系统造成很大压力，后者则使数据再利用存在很大障碍。大数据平台采用国产PC Server做集群，设备成本相对较低，易于横向扩展，妥善的解决了贴源历史数据存放和使用的问题，并且平台将查询、计算任务通过分布算法拆分到多台计算节点服务器进行处理，能够快速响应明细类贴源数据查询、贴源数据的统计分析和贴源数据质量检核。
2.高并发访问支持。传统数据仓库提供强大的数据整合功能，但其设计理念是与OLTP互补的OLAP，能够提供海量数据的统计分析，但是若提供高并发访问则成本高昂。而业界一直认可数据运用的发展趋势是将逐渐从战略型转向战术型，这一观点与近几年的实际发展是吻合的，当实时数据分析直接指导执行层面时，高并发访问是不可避免的。大数据平台的分布式架构较好地提供了所需的支持能力，对内能够使得一线工作人员也能快速便捷获得所需的数据，对外能够逐渐将数据用户扩展到广大的客户。
3.半结构化和非结构化数据的处理。银行业目前在业务过程中会产生很多半结构化和非结构化数据，如电话银行录音、监控视频、网银浏览记录、电子商务网站浏览记录等；此外，在大数据环境下，银行也需要将视野扩展到整个数字社会，与银行管理相关的大量有价值的数据是以非结构化的方式存在的，如个人浏览记录、社交媒体、网络舆情等外部信息。这些数据同时具有数据量大和价值密度低的特点，使用传统的关系型数据库在存储和加工上均存在难题。大数据平台的文件式存储更适合半结构化和非结构化数据，而且平台已有发展成熟的文本识别、声音识别和图像识别的组件、算法和分析理论，通过这些工具可对半结构化和非结构化数据进行解读和分析。
4.提升数据管理能力。数据质量是数据运用的基本保障，是数据治理的首要任务。数据质量管理依赖元数据管理、数据标准管理等数据治理组件，是将数据标准落地的重要环节，但长期以来数据质量管理在整个数据生命周期中存在后置问题，只在在数据应用环节进行质量检核倒逼前端进行改进，而面向数据采集源头的数据质量管理由于缺乏足够的空间而难以进行，大数据平台在解决源业务系统数据近线存放的同时，也为数据治理、数据质量管控提供了合适的载体。
优化我行数据架构，完善数据管理和服务的规范。大数据平台的引入优化了我行现有的数据平台架构，与数据仓库优势互补，形成混合式数据平台架构，依托该平台，实现对结构化、半结构化和非结构化的数据处理和运用，提供贴源数据服务或整合加工后的统一数据服务，具有提供实时服务的能力。在建设大数据平台的过程中，完善数据平台接入数据、处理数据和提供数据的管理流程和基于平台数据应用的开发规范，从技术和制度两方面规范数据的使用，提高我行的数据管理和服务能力。
项目过程管理
项目启动 2017.3
召开项目启动会，由行内业务部门、科技部门及东方国信项目组主要领导及业务人员出席，列出了项目风险点，明确了人员分工及项目管理规范，为项目顺利启动打下了良好的开端。
技术培训 2017.4
由Cloudera公司技术专家为我行科技部门员工培训hadoop相关知识及实操训练。
需求确认 2017.5
经过多轮讨论与业务部门确认最终需求。
应用开发 2017.6 – 2017.9
项目组驻场进行应用开发，数据加载脚本开发，集成测试，压力测试，完成性能调优。
应用测试 2017.10
业务人员进行应用测试，验证应用是否满足需求以及业务数据准确性。
集群安装 2017.8
Cloudera公司实施人员到场支持集群安装及各组件功能验证。
数据加工 2017.10 – 2018.1
将历史数据（2012年至今）加载入大数据平台，并完成贴源层及集市层数据加工。
投产试运行 2018.2
数据加工完成，在部分网点开放历史数据查询功能，开始试运行。
推广运行 2018.9
试运行平稳，每日数据加载正常，将应用推广至全辖网点运行。
运营情况
目前大数据平台运行良好，历史数据查询系统、内部审计系统已经接入大数据平台，各系统共计150多张源表，10T左右数据。历史数据查询系统每日对20余张业务报表（包含50余张源表，20余张集市层表）进行加工，并提供查询打印服务。内部审计系统提供包含多个业务系统100余张表的贴源数据查询。
经过半年的试运行不断调整、优化，每日ETL时长已从11小时降低到5小时以内，完全可以满足业务需要。
另外，通过对应用场景分析，形成了《大数据平台管理规范》、《大数据平台系统管理手册》、《大数据平台运维技术手册》等一系列规范和参考文档，对后续应用建设提供指导。
目前还有更多系统、数据计划接入大数据平台。
项目成效
历经1年多的实践，大数据平台的建设初见成效，支撑着我行历史数据查询、日初日终报表、内部审计等业务，同时有效降低了核心系统的查询压力与跑批压力。
历史数据查询系统，有效弥补了核心系统只能查询本年交易流水等数据的不足，将可选择的查询时间提前至2012年。
作为数据支持，与传统数据相比，大数据平台采用国产PC Server做集群，设备成本相对较低，易于横向扩展，妥善的解决了贴源历史数据存放和使用的问题，并且平台将查询、计算任务通过分布算法拆分到多台计算节点服务器进行处理，能够快速响应明细类贴源数据查询、贴源数据的统计分析和贴源数据质量检核。
经济效益层面，初步估计，大数据平台投入的PC Server是传统小机成本的1/5，普通硬盘是存储成本的1/10不到，软件授权费用更是传统数据库的近1/20。
经验总结
在实践过程中，我行为各种数据应用场景找到了符合我行架构的解决方案。对比传统数据应用的实施，有以下总结：
1. 开源技术的应用：
hadoop生态圈中有众多的开源组件，不熟悉每个组件就没办法高效、适当的应用该种大数据技术。区别于成熟的技术，需要我行科技人员更深入地了解实现原理，花费更多的精力进行调优以及更充分的测试。除此之外，大数据平台开源技术错综复杂，迭代迅速，需要我们更默契的分工以及持续的学习。
2. 多个实施公司合作：
我行大数据平台由多家实施公司合作完成，大数据平台项目细节非常复杂，不能像传统银行系统一样只进行进度、质量控制，而是需要我行主导项目实施的每一个阶段，深度参与到选型、开发、配置的工作中，必须做到自主可控。
3. 大数据平台数据的接入规范：
由于大数据平台接入的数据非常驳杂，需要在数据接入之前先行进行数据治理，包括：
a. 来源评估：在数据治理阶段，首先要进行数据来源评估，展开数据梳理相关的工作，及时发现数据来源可能存在的风险并加以处理。
b. 数据预处理：为了更好的、更有效的存储有价值的数据，同时方便系统对数据的使用，部分数据可以做预处理
c. 数据质量：数据质量环节很重要，如何有效保证数据的质量，直接影响着大数据项目的实施效果，在这个环节中，要投入很多的精力去形成标准，并建立相对自动化的数据质量系统。
4. 大数据平台数据应用规范：
数据应用落地的好坏，是否能够真正去形成大数据的应用，关系着能够更好的实现业务价值。数据应用的落地分之前需要先进性以下工作：
a. 场景细分：在这个阶段，对于第一阶段中形成的场景规划，要进行可被实现的场景细分，通过对场景的细分，形成一个个的用例(Use Case)。
b. 功能规划：经过上述Action环节，项目已经进入重要的落地阶段，需要根据已经整理好的用例(Use Case)、数据，形成具体的功能规划。这些功能规划，需要是可被准确识别和实现的，直接对应了大数据应用系统的功能点。
技术选型：完成了功能规划，就需要进行技术选型工作，由于大数据相关的技术非常多，这项工作需要借助专业供应商的力量来一起完成，需要充分考虑非功能性指标，比如：性能要求等等。
本文由2018年度农村金融科技创新优秀案例评选组委会授权发表，转载请注明出处和本文链接。
