大数据处理平台 案例：恒丰银行——大数据实时流处理平台

本案例是Data推出的大型“金融大数据主题策划”第一部分的一系列案例/随笔；感谢恒丰银行的发货

作为整体活动的第二部分，2017年6月29日，由Data Ape主办，上海金融产业信息协会和互联网普惠金融研究院、中国信息通信研究院、大数据发展促进委员会、上海大数据联盟、首席数据官联盟、中国大数据技术与应用联盟联合主办。“数据猿超声金融技术与商业价值探索高峰论坛”也将在上海举行【论坛详情

在论坛现场，还将颁发四类案例奖:“技术创新奖”、“应用创新奖”、“最佳实践奖”和“优秀案例奖”

恒丰银行于2016年1月完成了从传统数据仓库向大数据平台数据仓库的迁移。基于新的数据仓库平台，结合银行通用文件传输平台和统一调度平台，规范了源数据系统的数据提交，梳理构建了新的数据模型。大数据平台解决了传统数据仓库批量数据处理能力的不足，相关任务经历了从数小时到十分钟的提升。

大数据平台解决了大数据特征中大数据量的四个V的处理。我们还需要引入实时处理技术来覆盖数据多样性，高速处理数据，从而挖掘更大的价值。数据的价值随着时间的推移而降低。如何提供技术支持，充分发挥以日志为代表的银行实时数据，以及免费购买或抓取的海量互联网数据的价值，是一个亟待解决的问题。现金是硬道理！换句话说，我们需要将ETL、业务建模、机器学习和可视化扩展到实时数据，并将风险管理和客户营销相关的数据和计算规则从银行的关键业务系统中分离出来，为相关业务应用提供完整的支持。

周期/节奏

2015年9-11月，大数据实时流处理平台可行性分析及技术组件选型。

2015年11月，项目启动。

2015年12月完成整体需求分析，确定平台主要业务目标为运营监控、反欺诈、客户行为分析、风险预警等方面提供实时数据支持。

2015年12月至2016年8月，完成平台设计实施和基础组件生产。

2016年8月至今，优化补充基础组件，为业务应用开发提供支持，配合建设IT运营实时监控、客户点击流、交易反欺诈、贷后预警等实时数据相关应用。

客户名称/分类

恒丰银行/大数据技术服务

任务/目标

与互联网公司相比，传统商业银行在业务类型、交易模式和监管要求上有很大不同。我们根据行内业务需求设计了以下功能架构:流程处理平台提供数据采集、接收、过滤分析、实时规则计算、存储和分析挖掘等基本功能，在此基础上构建实时营销平台和实时风险预警平台进行业务逻辑处理。我行所有渠道系统、信用系统、it运营监控系统、操作风险监控均通过订阅获取实时处理数据，满足IT运营实时监控、客户行为分析、交易反欺诈、授信审核及贷后预警、操作风险监控等业务需求。

目前的实时数据源主要包括业务系统的应用日志、企业消息总线的关联交易日志、第三方数据公司的实时推送数据、网络设备、操作系统、中间件的日志、数据库日志以及外部网站的爬虫信息。流处理平台应负责实现以下目标:

●实时采集、过滤和分析各种基础数据；

●根据业务应用需求，提供基础数据实时处理功能；

●支持简单和复杂的业务逻辑规则模型，支持基于流数据的实时分析；

●易于与异构系统集成，实现数据共享，包括主流流量计算框架、各种数据库、前端框架、消息中间件设施、主流接口协议；

●海量数据的持久存储和快速检索；

●提供平台级数据管理功能，包括数据脱敏、用户权限、数据老化管理、分级存储。

挑战

大数据实时流处理平台在实际实施过程中主要面临以下技术难点:

1.如何满足可扩展性、系统容错性、高可用性、灵活部署、差异化服务管理、吞吐量性能的要求。

●平台资源:使用物理机服务器和传统虚拟机技术无法实现根据数据流量和计算任务快速扩展资源；计算、存储、网络等资源管理不够精细，资源应用周期长，资源可用性低。

●应用架构:如果采用传统的单一应用架构，由于Socket连接方式、线程服务模型、锁冲突、同步IO阻塞等原因，并发处理能力先天不足；大数据微服务架构将面临编程学习和开发成本高、异步并行调度和服务质量管理支持不足的问题。

●开发系统和工具:流处理平台组件多，迭代频率高，服务质量管理更精细，现有的开发系统和工具无法在实现的各个阶段实现强有力的支持。

2.如何构建覆盖所有业务需求的高性能、高可用性、实时数据采集和传输组件。

商业银行最有价值的流数据是应用系统和各种设备每天生成的日志数据。与互联网公司相比，银行的系统类型多、来源广、架构平台异构。主要交易系统产品化程度高，转换风险高，日志标准化差。不同的应用程序有不同的日志路径、文件编号、内容和回滚规则。例如，一个重要的系统应用程序同时打印数百个事务日志文件；除了应用日志文件之外，用于运维监控的系统实时资源信息、舆情以及需要从外部获取的信息，都需要数据采集组件提供高性能、高可用性、高安全性、高可靠性的实时采集和传输功能。

3.如何提供易于集成异构系统的软件服务能力？

流量数据和计算处理后的数据最终提供给其他应用，这就要求流量处理平台提供统一的消息服务能力，以满足异构系统各种集成方式的需求。这些需求可以由前端直接访问，远程调用RPC，或者通过主流消息中间件、内存数据库、传统数据库，或者通过与其他流程处理框架的集成。

4.如何应对灵活的业务逻辑变化，减少开发工作量？

基于流数据的业务应用要求流处理平台在数据处理和计算方面具有较高的灵活性。例如，在数据解析和结构化方面，日志或信息中的一些字段在当前的监控业务模型中没有特定的用途，并且没有进行预处理。突然，有一天，业务人员发现他们可以用于实时交易欺诈模型。在计算规则上，如果银行新开了信用卡业务，那么在分析客户的全渠道行为时，应该加入信用卡数据。业务人员都希望根据提出的规则立即实现，并处理复杂的规则逻辑。平台应该支持这方面，减少上层应用开发的工作量。

5.如何为庞大平台的各种组件和客户端提供统一的配置和管理？

云平台下，对应用的计算资源和存储资源进行精细化管理，增加了应用的节点数量，提高了可用性，大大增加了日志收集客户端的数量。与中间件、数据库和系统日志相比，收集任务中应用日志的配置要复杂得多。如何高效管理数千个日志收集客户端和爬虫客户端，并实时配置和更新其运行状态和收集任务？大规模集中部署和升级，如何配置和管理其他流量计算组件集群的状态一致性，提供便捷的流量数据处理流量配置功能，也是流量处理平台需要解决的问题。

6.如何满足海量数据的高速存储、检索和分析挖掘的需求？

流处理平台应满足原始数据和分析计算后的数据的高速存储和查询检索要求，满足银行对客户数据脱敏、用户权限管理和数据分层存储的要求，并提供集成的数据分析和机器学习工具，更好地挖掘数据价值。

实施流程/解决方案

在实际实施过程中，根据发布应用日志和应用监控输出的规范，将日志输出的需求纳入到项目管理从招投标到验收的全过程，对新系统提出了明确的要求，极大地方便了日志的收集，提高了流处理的效率。下面主要描述如何从技术上解决前一章提到的六个难点。

●平台架构

通过分析传统单一应用在并发服务能力、服务质量和运营部署方面的不足，最终选择成熟的akka微服务架构+docker容器云技术作为平台流计算和数据服务组件的基本技术架构。

响应型微服务架构通过消息机制避免了共享资源的锁冲突，降低了线程资源需求。同时，将故障作为一种消息，实现服务自治，实现各级故障的快速恢复，实现功能和服务的灵活封装和部署，构建位置透明的集群服务系统，实现灵活扩展和差异化硬件资源分配；除了以上优点，akka还嵌入了基于netty技术的NIO框架，不需要配置额外的Weblogic或WebSphere等中间件服务器，降低了使用成本，支持更多的客户端连接，单个节点每秒处理5000万条消息；1GB内存为250万Actor，消息机制实现分布式微服务协作和数据共享，无需资源锁；Actor模型实现多级自主监管机制，构建安全防火墙和沙盒，恢复微秒级故障，支持灵活部署多种集群部署模式，透明访问远程服务，多种可配置负载均衡策略。

我们将akka微服务架构的集群负载、服务监控、故障恢复和灵活部署能力与恒丰银行PAAS云平台采用的docker container技术相结合，实现了应用级负载、监控、灵活的资源分配和快速部署能力，满足了本节开头对流媒体计算组件的要求。除了流计算组件之外，平台使用的flume、kafka、zookeeper、redis等开源组件也实现了docker集装箱化，并使用DevOps工具服务实现了从开发、构建、测试到版本发布的全过程自动化，提供了包括规划、任务分配跟踪、问题跟踪、文档管理、版本发布在内的项目协作支持。

我们使用Skyline这个自主开发的微服务架构平台来开发相关组件。Skyline基于akka，通过提供zebra脚本语言降低了并行编程开发的难度，可以监控和调度异步并行任务，从而实现集群的分布式一致性和分布式事务的支持。

●数据采集

在比较了当前主流的开源日志收集组件flute、scribe和logstash之后，我们选择了用Java语言开发的在高可用性、资源隔离和二次开发方面具有优势的flute作为我们的日志收集组件。

在日志收集流程方面，针对不同的云环境设计了不同的收集流程。对于部署在openstack云环境下的应用和一些物理机，水槽代理直接部署在应用服务器上，实时采集各节点配置的日志文件、syslog和进程状态信息，并实时发送到后端水槽服务器。服务器完成原始数据入库和初步过滤分析，并发送给卡夫卡消息中间件。对于部署在docker容器环境中的应用，由于日志已经归一化，主机上的flume直接使用主机提供的接口读取对应镜像所属路径中的日志文件，并直接发送到kafka Message中间件。

此外，根据实际需求，开发了水槽客户端，增加了源的类型，覆盖了当前所有应用系统的日志打印类型，修改了客户端软件的一些缺陷，设计并实现了不同的策略，控制了异常情况下系统资源的占用，修改了代理和zookeeper之间的更新配置方式，通过心跳机制监控水槽代理的状态，并通过Jenkins和puppet等工具支持大规模的客户端推送和部署。

为了解决水槽服务器的数据采集性能问题，我们将水槽服务器拆分为微服务，并将原本集中在服务器上的接收、解析和入库工作拆分开来。原水槽服务器利用其对负载均衡、故障转移和与客户端收发事务的支持来接收数据，并构建skyline微服务组件集群来实现解析和仓储功能，并根据不同级别和类型的解析和仓储需求分发不同的组件。

此外，为了从现有系统收集一些交易数据，从外部网站抓取一些数据，平台提供了探测组件和爬虫组件，并基于zookeeper实现了客户端程序组件的注册、注销和实时任务分配，从而实现了高可用性和横向扩展。

●异构系统集成

流处理平台通过建立自己的分布式实时消息总线，与外围系统集成，以Akka的消息处理框架为核心枢纽。

如上，一方面通过SockJs、WebSocket、HTTP协议将流媒体数据打包成各种服务，构建与移动应用和其他外部系统的前后端的消息通道，对应用开发程序员屏蔽各种消息编解码算法的细节；另一方面，通过代理组件和统一元消息语义的编译，异构系统的kafka、MQ等消息中间件设施和主流的spark流处理框架可以作为流处理平台的消息总线设施的一部分，实现与上述设施和流计算框架的无缝集成；此外，用户可以为特定数据定制自己的持久化方案，支持将数据实时写入主流数据库。

●规则计算

为了应对业务各方面流程处理规则的变化，减少硬编码实现流程计算组件的工作量，我们引入了开源drools规则引擎。Drools规则引擎速度快，效率高，处理规则冲突的能力强。完全开源，用Java编写，方便基于它的开发。

在实际使用中，我们集成了drools作为skyline平台的计算组件，该组件与我们的卡夫卡消息中间件和redis内存数据库相适应，将drools的监控数据源变为实时数据，并用于处理事件触发的复杂业务逻辑。为了方便业务人员，编辑规则逻辑的方式从开发Java语言风格改为。drl文件来提供可视化编辑页面。用户可以通过在页面上编写简单的逻辑组合条件和标准sql来配置复杂的业务逻辑，并从各个方面完善规则引擎的功能，方便应用。

对于时间触发的流量计算规则，如每日实时交易量统计、并发访问量、客户每日消费金额等，我们使用spark streaming sql函数代替原来为大多数数据源和规则逻辑开发的流量计算组件，将查询结果实时导入内存数据库，并提供给规则引擎进行复杂的逻辑处理。目前大多数实时规则从数据触发到计算结果输出的计算时间控制在100ms以内。

对于流量计算过程中需要的其他组件，如数据分发组件、持久化组件和告警推送组件，我们使用skyline平台构建相应的流量处理集群，并使用zebra脚本语言编写业务逻辑来满足相关的业务需求。

●服务和任务配置和管理

流处理集群的服务和任务配置管理有三个主要部分:

第一部分是日志收集、事务探测、爬虫等客户端程序。目前，恒丰银行绝大多数应用采用同城双中心、双活动，各中心应用的部署单元也是集群、多活动的形式。应用程序从传统的物理机环境迁移到云环境后，节点数量会增加，这与日志收集客户端的增加相对应。目前，恒丰银行生产环境下已有3000多个虚拟机节点投入运行，各种测试环境和准生产环境下有6000个节点。监控每个虚拟机上收集客户端的服务状态和资源占用情况，并批量或单独更新收集任务的一些参数，如增加/减少路径和增加文件的黑白列表。针对现有系统和外部咨询数据无法通过日志获取流数据的问题，我们分别开发了探测和爬虫客户端程序。这些客户端程序的服务和任务管理由zookeeper实现。

第二部分是基于skyline平台的流计算组件。在这一部分中，我们使用Skyline平台的一致性管理器对其进行管理。每个组件都有自己的基于raft协议一致性管理的接口，管理集群通过消息广播机制与每个组件集群进行通信。

第三部分是流程处理流程的配置。除了前面提到的Streaming Sql和Rule Engine组件，我们还使用skyline平台开发了一些基本组件，比如分类、数据完成、持久化、脱敏和数据转换组件。用户可以通过拖放直观地配置流程处理流程。

●数据存储、分析和挖掘

在一些业务场景中，流程处理平台需要存储原始的非结构化和半结构化数据，并提供查询检索。比如运维业务需要在事件发生时提供各种资源和日志快照信息；解析后的结构化数据也需要集中存储，以便进行统计分析和报告。在这方面，我们继续使用几个仓库迁移时引入的企业级大数据平台，引入企业级大数据平台，避免大数据平台的运维压力。

流处理组件可以通过jdbc驱动直接使用标准sql对Hyperbase表进行数据库表相关操作，支持建立全局索引和局部索引，满足各种复杂场景的实时写取需求。Hyperbase支持全文索引，方便用户快速检索自己关心的信息。流处理平台使用平台提供的Scala语言接口开发数据挖掘和深度学习的相关模型，进行分布式挖掘和模型训练。

结果/效果总结

目前市场上大多数商业流处理产品都是基于单一应用目的开发的，使用商业产品限制了数据开发的采集规模、功能覆盖和灵活性。同时，大部分产品的收费模式都是基于节点数或者原始数据流，大部分的流量数据都是低价值密度数据，很难在这种收费模式下充分挖掘数据价值。

就技术指标而言，恒丰银行大数据实时流处理平台具有以下优势:

●数据采集:节点多，部署1500多个服务器节点；网络结构复杂，跨越多中心的所有网段。采集功能覆盖率强，可以满足日志、流程资源信息、界面服务信息、库表信息、外部爬虫数据的实时采集。日志收集方面，涵盖所有日志打印方式，支持同时维护多达300个日志文件；任务调度和监控方便，所有任务统一配置并实时更新，客户端支持自动批量发布，客户端运行状态监控完善。

●数据接收和预处理:基于规则引擎和Streaming SQL，提供可视化的规则配置页面和拖放流程配置，业务人员无需编程开发即可直接配置，支持复杂的规则逻辑和灵活的扩展。大多数基于流数据的逻辑处理时间小于100毫秒。

●流量计算:基于规则引擎和Streaming SQL，提供可视化的规则配置页面和拖放流程配置，业务人员无需编程开发即可直接配置，支持复杂的规则逻辑和灵活的扩展。大多数基于流量数据的逻辑处理时间小于100毫秒。

●数据存储和检索:接收和存储采用异步处理，在8个存储节点的情况下，写入速度接近100M/S。通过自动表格分类，结合全文检索的当月日志元数据在3秒以内。

以上技术指标完全满足上层监控、反欺诈、贷后预警、客户行为分析、操作风险监控等业务需求的实时数据处理要求。

从实际应用效果来看，恒丰银行大数据实时流处理平台对一些典型服务的支持，验证了“集中采集实时数据，集中处理发布订阅”这一原始决策的优势和正确性。同渠道系统的交易数据可用于运维监控、用户行为分析和交易反欺诈验证。可以放在这个用户的贷后预警模型中，对数据同源系统进行解耦。不同的服务只需要响应和添加逻辑规则配置，而不是家庭理财是恒丰银行一项新的家庭理财业务。业务人员在复杂成员之间设计了各种交易提醒规则。按照以前的模式，需要增加核心的提醒业务，各种渠道的交易接口可能需要改革。相关系统要一起推出。如果增加新渠道系统后，必须重新开发和推出原有模式；根据基于流程处理平台的处理方案，在流程处理组件或规则引擎中配置规则，并关联各种渠道的数据源。新的数据源和规则更新可以立即配置并立即生效，大大提高了业务灵活性，降低了开发成本。

企业简介:

恒丰银行有限公司是在烟台注册的12家全国性股份制商业银行之一。

近年来，恒丰银行稳步快速发展。截至2016年底，恒丰银行资产规模已超过1.2万亿元，是2013年底的1.6倍；各类存款余额7682亿元，各类贷款余额4252亿元，均较2013年底翻了一番。2014-2016年累计利润总额312.17亿元。这三年累计利润总额为过去26年累计利润总额；服务组织结构不断完善，分支机构306家，比2013年底翻了一番。

近年来，恒丰银行赢得了许多荣誉。在英国《银行家》杂志公布的“2016全球银行业1000强”榜单中排名第143位；在香港中文大学出版的《亚洲银行竞争力研究报告》中，在亚洲银行业排名第五；在中国银行业协会发布的《商业银行稳健发展能力陀螺仪评价体系》中，综合能力在全国商业银行中排名第七，在全国股份制商业银行中排名前三；荣获“2016年度最受喜爱的人民股份制商业银行”第二名、“2016年度互联网金融创新银行奖”、“2016年度最佳网上银行安全奖”、“2016年度创新中国特别奖”等多项荣誉。

恒丰银行作为一家起源于孔孟之乡山东的全国性股份制商业银行，坚持“恒比恒德之风”的核心价值观，践行“1112 5556”工程，即愿景和文化、两大战略的被迫战略，“五种力量”的工作原则，五位领导大力实施“12345”行动计划，即“1”是综合理财解决方案的提供者， “2”是金融云平台、大数据平台，“3”是数字银行、交易银行、银行的银行，“4”是领先的金融创新商业模式、平台金融、家庭金融、O2O金融。” “5”是以“一家银行”为核心的投资银行、资产管理、平台、人才库存、绩效考核体系等五大战略落地工具。致力于成为“知识和技术的传播者、渠道和平台的搭建者、综合金融解决方案的提供者”，努力打造一家引人注目、受人尊敬的商业银行，为客户和社会提供最高效、最佳的综合金融服务体验。

欢迎更多大数据公司和大数据爱好者提交数据。请把手稿直接寄到:tougao@datayuan.cn