本文来自于 GOPS 2017 深圳站的演讲“广发银行大数据平台技术体系的演变之道”。
作者简介
廖俊杰
广发银行 数据中心大数据团队负责人
担任广发银行大数据团队负责人。作为银行业科技条线的资深人员，在应用系统与运行维护、信息科技治理与管理、大数据研究及规划等领域具有较为丰富经验。
2011年牵头完成广发银行信用卡核心系统 ACCEND 升级工作，2014年作为项目经理完成广发银行南海数据中心搬迁及海外银行核心系统建设工作，2015年牵头完成广发银行信用卡核心系统 CARDLINK 升级工作，参与完成广发银行国内银行核心系统建设工作。
2015年作为项目负责人主持进行大数据分析平台工程项目建设工作，2016年大数据项目的银行资金关系圈课题研究成果荣获中国银行业监督管理委员会评审认定的《2016年度银行业信息科技风险管理课题一类成果》和《金融电子化》杂志社评选“2016年科技创新突出贡献奖”。
前言
大数据在银行里面听的比较多，而且最近也比较火，同时也是发展的趋势。对于银行来说，大数据能够让客户更加透明。我们大数据系统是2014年开始构建的，目前我们大数据平台基本进入比较成熟的发展期。
我们的八个产品在行内各个客户的全生命周期用起来并且已经直接产生了效益；但是整个过程中我们发现了很多问题，也是欠下的技术债。我将从大数据定位、体系规划、大数据平台架构优化、团队建设以及应用案例等六个方面介绍我们的技术体系的演进。
一、大数据定位
我们的大数据平台自2014年建设以来，在行内投产的已经有八个产品。行内大数据产品的应用能够让客户更加透明，对于银行的风险管控也更加精准。现有的大数据产品已经直接产生效益。
我们将基于大数据和AI技术构建以客户为中心的金融服务。现在我们已完成八大数据产品研发，同时通过现有的大数据产品实现了精准营销和实时的风险识别。
目前的大数据平台基本进入比较成熟度发展期，未来我们将朝着AI方向去发展。我们将以数据为驱动奋力拼搏成为国内一流的商业银行。
二、大数据体系规划
随着业务和需求的不断增长，我们在大数据平台建设过程中遇到了很多问题。归纳起来主要有三个方面：
首当其冲的是业务需求迫切，但是软件交付的时间与业务的预期存在较大差异。
其次，已有的系统架构的逻辑比较复杂，难以快速扩展满足业务高峰期的要求。
还有就是新技术的层出不穷，对团队协作和人员技能的要求越来越高
对于以上问题，我们分别从系统架构、交付模式以及团队建设三个方向上入手。系统架构方面调整优化后，要变成高并发、易扩展、高可用的系统架构。敏捷开发模式实现了高质量的软件交付。
现在的数据人才非常抢手，很多数据做出来还没有做完的时候就被挖走了。因此，我们需要高效率的组织架构和多层次人才体系去助力技术体系的成长和发展。
为了达成上述三个方面的目标，我们分别制定了相应的策略。技术架构的优化方面，系统要做成分布式的架构，前端进行了微服务的改造，后台数据要做成分层的架构。
同时，前后端代码都进行自动化测试和部署，并引入精益管理流程。为了适应开发模式的转变，对团队组织架构进行了调整。打通开发和运维，细化岗位职责，建立相应的能力评估模型。
三、大数据技术体系演进
接下来将从平台架构优化，交付模式改进，团队建设这几个方面详细展开介绍。
3.1 平台架构优化
首先，我们根据数据和应用紧密结合的关系对总体的架构进行了拆分。将其拆分成前端应用架构和后端数据架构。前端应用架构分成数据服务、数据产品，最终提供给业务使用的就是数据产品。
后端数据架构主要是以数据为主体进行加工、数据工厂的模式，处理完之后最终的数据结果直接通过中间层给到应用架构作输入。
这样拆分后数据流 7x24 小时持续被处理，解决了之前每天批量跑数据的时候前端应用就没法跑了。目前我们的数据满足所有渠道全天候实时访问的要求，包括网银、手机银行、微信等。
优化完成之后，前端架构的部分产品会直接对外提供服务。后端架构进行分层后，包括数据采集、数据存储和数据加工。数据存储分为结构化和非结构化存储，存储不同类型的数据。存储之后分别做离线和建模计算对数据进行数据加工。
其次是应用架构改造。对单体应用按微服务拆分，这样拆分后能够忽略环境差异、保证版本统一。我们的客户全景视图模式，分为前面的展示层、中间的服务层和后端的数据。
刚开始的时候能够适应部分业务的发展，但是慢慢的发现性能的优化以及服务拆分其实很困难。
我们进行微服务改造后会把将原有的三层架构按不同的服务做划分。前端的还是统一的UI，中间会用 API Gateway 做前端服务的接口，负责分发所有的请求。
后面的中间层变成组件服务、公共服务和业务服务。公共服务放在构建库中，供大家重复调度。有些比较特殊的服务就会放在自身的业务服务中，这样的业务服务每个都是自身的微服务。
我们把后端数据当做资源进行了一层封装，提供统一的数据接口供外部调用。
微服务拆分后，会将其变成一个容器。容器集群有8台物理机，所有的容器都挂到 F5 上，同时与容器相同功能的服务也会通过传统方式进行部署。
站在银行的角度，容器优点虽然很多，但是相对也是不稳定的工具。在最坏的情况下，容器即使不可用，传统的方式仍然能通过F5转发的流量提供对外服务，降低容器运行风险。
目前容器平台有三类镜像，一个是基础环境镜像，主要包括OS、中间件。开发的同事会根据自己代码的需求选择相应的基础镜像，这样由业务代码和基础镜像合并起来的就应用版本镜像。
应用版本镜像其实就是容器的交付物，在测试的时候将应用版本镜像和测试环境的配置结合起来在测试环境中做测试。要上生产环境时，就将其和生产环境配置结合起来。这样可以根据不同的环境灵活的配置同一版本的业务程序。
以前的数据处理都是从源数据到数据的结合都是用一个口径加工出来的，中间经过了许多不同的中间表没有作其他的复用。我们对后端数据进行分层的架构调整后，中间过程产生的表会按照不同的主题进行规整。
最后用数据的时候，业务可以直接从主题中配置他们需要的维度及运算操作就可以得需要的指标和数据。
数据分层后引入了数据流水线的功能，这样不同的数据口径和数据的批量以及数据整个质量的管控都是一个完整的生产过程。在整个过程中，将所有数据按照不同的表和加工的口径一层一层的加工起来，加工完成后最终会变成一个数据的成品，然后给到前端应用。
这个数据流水线和传统的加工方式最大的差异在于它是从业务口径落实到技术口径的，相对来说可视化和数据加工的准确性会更高一些。
3.2 交付模式改进
平台优化完之后没有解决的问题是我们给业务交付怎么能够更快一些。结合已有的互联网先进的经验我们做了一套持续交付的流程，包括代码管理，基线控制，自动构建审查，自动化测试还有环境部署。
我们的持续交付流程图如下：
从最左边开发人员的代码提交开始，每次代码提交之前都需要通过代码审查。审查通过后的 war 包会成两条路径，其中一个是到传统的开发测试环境进行测试，最终会部署到传统的生产环境。
另一种 war 包会去容器环境，在测试环境的应用容器中进行测试，测试 OK 之后会部署到生产环境中的容器。目前整个持续交付流程兼容传统和容器的部署。这样既保持了原来比较好的自动化部署流程，又利用了容器的方便持续集成的优点。
我们会利用一些工具做集成测试，例如，findbugs、junit、jenkins 做自动化测试。通过自动化测试可以节省一些人力成本，但最终还是需要人工的测试用例来进行测试的。最后我们会通过 sonar qube 出一些报告，这样我们才会知道在低于哪些缺陷率的情况下才可以投产。
以上持续交付的流程都需要精益的理念做管理。我们整个循环从原始需求的提出、需求的设计，都是由整个看板去做需求流动价值的可视化的。通过看板，我们可以知道一个需求所需要的资源和时间进度，同时也可以发现整个交付过程中的问题点。
3.3 团队建设
平台架构优化和交付模式改进，其实都是技术和工具上的优化。组织架构上也要做一些优化，因为如果人员管理上没有一定的优化，可能很多事情就没有办法再做下去了。
在原来的情况下，每个团队都按照需求驱动，需要做的时候是按照开发的想法和业务的沟通，然后不断调整它们的需求实现方式。按照 devops 的思想，我们对组织架构进行了调整。
现在我们是按照产品线的方式，把它转化成不同的产品线，打通包括业务、开发、运维、中间还有大数据团队、模型团队。将消除各个团队壁垒，形成横向管理的团队。
产品经理类似于 DevOps 里面的服务主管，会负责整个产品和需求的管控。以前很多时候是业务提需求，要等开发到一定阶段的时候才过来说验收或讨论。现在我们每两周做一次版本迭代的讨论，这样对整体的业务需求和开发的理解会有很大的帮助。
我们细化了岗位本身的职责。原来有开发、运维和测试，现在变成七种不同的岗位。这会对应之前团队里面由不同的人负责不同的职责。这样对整体人员的发展空间、人员协同以及人和人之间的相互协作是很有帮助的。
同时，我们也为不同工程师做了相应的能力评估模型。每个类型的工程师是需要定期帮助他做一些评估，引导他按照不同的方向去做风险学习和项目实施能力的提升。我们希望每个人的岗位和能力是相互匹配的，这样对于个人的职业发展和对公司的贡献度也能做到双赢。
四、应用案例
上面几个方面的演变对我们来说带来了一些比较正面的影响。现在也给行业里面带来比较多的受益。下面简单介绍几个应用案例：
一个是风控案例，以前信用卡催收比较麻烦，我们要找到人，现在通过大数据分析和数据关系挖掘，我们能找到以前找不到的联系人，最终会把失联的客户找到，也能够顺利的做一些还款。
另外我们也可以做运维分析，我们通过数据分析来发现风险交易、***检测和探测密码等异常。我们也会查看网络包有没有敏感交易、敏感数据进而通过大数据技术来发现风险。
广发银行大数据平台的演变给我们提供了实施大数据平台的经验，大数据平台是运维必须要的服务吗？正方：必须要 反方：不需要，请以（必须要/不需要）开头评论提出您的观点，点赞最多者将获得高效运维社区送出的神秘礼品。