【智能金融】恒丰银行——大数据实时流处理平台

2017 年 9 月 19 日 产业智能官 星环科技

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

大数据平台解决了大数据特征中四个V的大数据量（Volume）的处理，我们还需要引入实时处理技术能覆盖数据多样性（Variety），高速处理数据（Velocity），从而挖掘更大的价值（Value）。数据的价值随着时间的流逝而降低，如何在技术上提供支撑，发挥以日志为代表的行内实时数据和付费购买或者免费爬取的海量互联网数据在商业银行业务中的价值是亟待解决的问题。变现，是硬道理！换句话说，我们需要将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.如何对庞大的平台各组件及客户端提供统一的配置和管理。

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

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

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

实施过程/解决方案

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

●平台架构

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

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

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

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

●数据采集

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

在日志收集流程方面，针对不同云环境设计了不同的采集流程，对于部署在openstack云环境和部分物理机上的应用，通过在应用服务器直接部署flume agent实时采集每个节点配置的日志文件、syslog、进程状态信息，实时发送后端的flume 服务端，服务端完成原始数据入库和初步的过滤解析并发送到kafka消息中间件；对于部署在docker容器环境下应用，因为已经做了日志规范化，宿主机上的flume直接利用宿主机提供的接口读取对应镜像所属路径下的日志文件，直接发送到kafka消息中间件。

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

为了解决flume服务端收集数据的性能问题，我们对flume服务端进行微服务化拆分，将原来集中在服务端的接收、解析、入库工作拆分出来，原有的flume服务端用其对loadbalance、failover以及与客户端之间发送接收事务的支持进行数据接收，构建skyline微服务组件集群实现解析和入库的功能，并根据不同级别、不同类型的解析、入库需求分配不同的组件。

除此之外，为了补充采集一些既有系统交易数据和爬取外部网站一些数据，平台提供探针组件和爬虫组件，并基于zookeeper实现了上述客户端程序组件的注册、注销、实时任务分配，实现了高可用和水平扩展。

●异构系统集成

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

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

●规则计算

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

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

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

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

●服务和任务配置、管理

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

第一部分是日志采集、交易探针、爬虫这些客户端程序。恒丰银行目前绝大多数应用采用同城双中心双活，应用在每个中心的部署单元也是集群多活形式，应用从传统物理机环境迁移到云环境后，节点数增多，与之对应的是日志采集客户端的增多。目前，恒丰银行的生产环境已经上线运行了三千多个虚拟机节点，各类测试环境和准生产环境共有六千个节点，对每个虚拟机上的采集客户端的服务状态、资源占用情况进行监控，对采集任务的一些参数进行批量或者单独的更新，如增加/减少路径，增加文件黑白名单。对于不能通过日志获得流数据的既有系统和外部咨询数据，我们分别开发了探针和爬虫客户端程序。这些客户端程序的服务和任务管理都是利用zookeeper实现的。

第二部分是基于Skyline平台开发的流计算组件，这一部分我们利用skyline平台的一致性管理器进行管理，每个组件自带基于raft协议一致性管理的接口，管理集群和各组件集群间通过消息广播机制进行通信。

第三部分是流处理流程的配置，除了之前提到的Streaming Sql和规则引擎组件，我们使用skyline平台开发了一些基础组件，如分类，数据补全，持久化，脱敏、数据转换组件，用户可以使用拖拽方式可视化配置一个流处理过程。

●数据存储、分析和挖掘

在有些业务场景下，流处理平台需要将原始的非结构化和半结构化数据存储起来并提供查询检索，如运维业务需要提供事件发生时的各类资源和日志快照信息；针对解析后的结构化数据，也需要集中存储，用于统计分析和报表。在这方面，我们使用继续使用在数仓迁移时引入的企业级大数据平台，引入企业级的大数据平台免去了对大数据平台的运维压力。

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

结果/效果总结

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

从技术指标方面来看，恒丰银行大数据实时流处理平台具有以下优势：

●数据采集：节点多，部署超过1500个服务器节点；网络结构复杂，横跨多中心所有网段；采集功能覆盖性强，能够满足日志、进程资源信息、接口服务信息、库表信息、外部爬虫数据实时采集，在日志采集方面覆盖所有日志打印方式，最大支持同时维护三百个日志文件；任务调度和监控方便，所有任务统一配置，实时更新，支持客户端自动批量发版，客户端运行状态监控完善。

●数据接收和预处理：基于规则引擎和Streaming SQL实现，提供可视化规则配置页面和拖拽式流程配置，业务人员可以直接配置，不需要编程开发，支持复杂规则逻辑，支持弹性扩容，绝大多数基于流数据的逻辑处理时间小于100ms。

●流计算：基于规则引擎和Streaming SQL实现，提供可视化规则配置页面和拖拽式流程配置，业务人员可以直接配置，不需要编程开发，支持复杂规则逻辑，支持弹性扩容，绝大多数基于流数据的逻辑处理时间小于100ms。

●数据存储和检索：接收和存储采取异步处理，在八个存储节点条件下支持接近100M/S写入速度，通过自动分表，当月日志元数据结合全文检索检索皆在3秒以内。

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

从实际应用效果看，恒丰银行大数据实时流处理平台针对一些典型业务的支撑已经验证了当初“将实时数据集中采集、集中计算处理、集中发布订阅”决策的优势和正确性，同一份渠道系统交易数据可以用于运维监控，可以用于用户行为分析，可以用于交易反欺诈核验，可以放在此用户的贷后预警模型里，将数据同源系统解耦，不同的业务只需要响应增加逻辑规则配置即可，而不是像原有模式分别在源系统里面增加业务，增加开发和投产任务。家庭金融是恒丰银行新开展的一项以家庭为单位财富管理业务，业务人员设计了较为复杂成员之间各类交易动账提醒规则，按照以往的模式需要核心增加提醒业务，各渠道交易接口可能需要改造，相关系统要协同上线，如果新增渠道系统后原有模型还得重新开发、上线；基于流处理平台的处理方案，在流处理组件或者规则引擎中配置规则，关联各个渠道数据源，新增数据源和规则更新可以立即配置，即时生效，大大提高了业务灵活性，降低了开发成本。

延展阅读：银行客户行为实时分析系统

星环科技

互联网金融的蓬勃发展对银行带来巨大冲击。但国家战略对互联网+、大数据技术的强调，也让银行意识到这也是改革和创新的新机遇。在这种新形势下，一方面银行开始加速布局大数据技术在银行领域的应用，另一方面相比原来以产品为核心的经营模式，银行开始愈加重视以客户为核心的经营模式。

在客户管理及服务方面，银行以往根据 “二八原则”，往往主要服务那些给银行带来80%收益的20%的客户，但随着利率市场化下银行间竞争的加剧，“长尾”客户也将成为竞争对象，此外单一粗暴的划分原则也忽略了许多客户更深层次的个性化需求。另一方面，受人力极限和技术所限，传统的统计分析方法不仅缺少对客户购买产品前的行为分析，更无法做到实时分析。

如何在保持对高价值客户服务质量的前提下进一步提升个性化的服务体验，如何进一步挖掘长尾客户的价值，如何实现精准营销、如何提升客户粘性、如何优化缩短产品购买路径，如何防范欺诈交易等问题都是大数据时代银行迫切期待解决的问题。

基于上述背景，恒丰银行开始了基于大数据实时流处理技术的全量客户行为实时分析系统的建设。

周期/节奏

在客户行为实时分析系统研发之初，就确立了一切从“用”出发的核心思想，因此整个系统的开发过程一开始即摈弃了传统的“项目管理制”的运行模式，而采用快速迭代，不断完善的开发模式。

2015年10月，客户行为实时分析系统项目建设工作启动。

2016年2月，迅速完成第一版原型——基于手机银行单台服务器客户操作日志的点击流实时分析——投产试运行。

2016年6月，客户行为实时分析系统迭代实现了基于手机银行、个人网银的全量客户操作日志的点击流实时分析功能。

2016年11月，迭代实现了可对单个客户进行客户画像、渠道偏好、交易偏好进行分析的客户价值分析功能，一期项目完成。

客户名称/所属分类

恒丰银行/客户管理

任务/目标

客户行为实时分析系统通过对客户基本信息和行为数据的监测追踪、收集整合、评估分析，为业务人员决策业务策略时提供更全面、更准确、更有价值的信息。从不同的角度出发，客户行为实时分析系统需要达到不同的目标。

在全行的大数据建设规划角度出发，客户行为实时分析系统首先要实现两个目标：一是构建面向全行客户的群体客户行为数据基线。二是可以实时的发现和处理个体客户的差异性行为数据。前者是基础，后者则是价值挖掘对象。没有前者，后者也就无从对比和挖掘。

从业务角度出发，客户行为实时分析系统主要需要达到或支持以下三个角度的业务要求：

1)在营销角度，可以深度了解和分析客户在持有、购买、放弃产品及应用的前、中、后期行为特征，从而为客户偏好、360度画像、数据挖掘提供更精准的数据依据，最终实现精准营销。

2)在风控角度，可以深度了解和分析客户的活动范围、生活轨迹、交易支付习惯等，从而为信贷风控提供有力证据。

3)在客户体验角度，一方面可以深度了解和分析银行现有应用的运行状况、应用中各个功能模块的使用频率、客户访问路径长度等情况，从而为银行应用设计和优化提供数据支持，让银行应用产品更符合客户群体期望和个体期待；另一方面为客服系统、CRM、移动柜员等前端应用提供更加精准的客户信息，方便一线业务人员为客户带来更加个性化、定制化的服务体验，提升银行客户粘性。

从技术角度出发，面对全量客户海量行为数据，客户行为实时分析系统要达到如下目标：

1)数据要能够实时的采集和存储。

2)数据要能够实时计算和分析。

3)实时数据服务能够实时展现和查询。

挑战

客户行为实时分析系统在互联网公司已不鲜见，但在银行领域的建设与应用面临的挑战和需要探索的地方还有很多。

（1）监管挑战

相比互联网领域的客户行为实时分析系统，银行领域将面对更多来自风险管控方面的挑战。银行必须充分保护客户隐私，在监管范围内采集、分析和使用客户行为数据。

（2）性能挑战

银行应用对可用性要求非常高，实时数据采集要在充分保证不影响源系统（例如手机银行、个人网银等7*24小时面向客户提供服务的系统）的服务性能后，再考虑如何提升数据的实时性，绝对不能影响客户的正常使用。

（3）项目研发模式挑战

银行项目一般是项目管理制，这就需要我们与项目管理部门充分沟通项目需求的特殊性和快速迭代的必要性才能争取到与项目相匹配的开发模式。

（4）系统改造挑战

银行应用多是在银行大数据建设之前即已投入使用，在设计和建设之初无法充分考虑未来的大数据应用规划，因此很多应用的客户操作日志提供信息不全，甚至缺少关键信息记录，巧妇难为无米之炊，这为我们的系统建设带来极大困难。对于缺少关键信息的系统，可能涉及到难度较大的系统改造，有的甚至可能牵一发而动全身，不亚于整个系统的重构，这也为我们的系统建设带来非常大的阻力。这时就非常需要来自领导层敢于改革的魄力、业务人员渴望创新的决心和配合系统相关同事的理解。

（5）技术选型挑战

在技术选型方面，所选技术既要满足实时性能高、可扩展性强、稳定性好、高可用、配置灵活易管理等要求，又要考虑与现有的大数据平台无缝整合的问题，需要满足的条件很多、技术选型难度很大。

（6）复杂的日志采集与传输模式挑战

需要采集日志的终端，不仅有实体机，也有部署于OpenStack云平台的虚拟机，针对不同的终端需要研发不同的日志采集功能；数据传输物理上跨数据中心、同中心内跨多个网段，在复杂的网络传输环境下，如何保持数据传输结果一致性也是一个很大的挑战。

实施过程/解决方案

（1）实时流处理平台解决方案

客户行为实时分析系统的核心是对客户行为数据的实时采集、实时计算和实时查询服务。但站在全行大数据建设角度看，需要实时处理的数据并不仅限于客户行为数据，因此首先需要构建基础的大数据实时流处理平台。通过实时流处理平台的建设，构建全行统一的实时数据应用平台，结合恒丰银行基于大数据平台的新数据仓库，实现对行内多项业务的全方位支持。以此平台为基础，可以为各种关注不同业务主题的应用提供实时流处理服务，客户行为实时分析系统也是平台之上的诸多应用之一。

大数据实时流处理平台的整体逻辑架构如下图所示：

大数据实时流处理平台的整体逻辑框架

平台整体逻辑架构划分为：数据源层、平台层、流计算层、分布式实时数据总线服务层、应用层五个逻辑层次。其中：

数据源层:提供多种形式的数据实时采集功能，向平台推送数据。

平台层:一方面对所有组件做了模板化封装，以方便灵活部署在Docker容器或VM虚拟机上，使平台具备弹性扩展能力，另一方面实现与恒丰银行大数据平台无缝对接，将结果数据写入大数据平台或者从大数据平台实时获取数据。

流计算层:是整个平台的核心层, 底层基于恒丰银行自主研发的Skyline开发框架构建，除实现了基本的流处理计算功能外，还构建了Streaming SQL模块，分析人员可以通过该模块直接在流上执行SQL语句，进行流上的数据关联查询；Streaming MLlib模块提供了机器学习模型在流上的植入功能，可以将构建的数据挖掘模型随时运行在流平台之上；Streaming Cube模块可以通过流实时构建多维度数据分析的数据立方体，进而在Cube上进行数据下钻、上卷等多维度切片分析。综上所述，流处理平台即支持OLTP的实时类业务应用，也支持近实时OLAP分析类业务应用，且支持数据挖掘类业务应用。

分布式实时数据总线服务层：为流处理平台对外提供基础服务层，每个服务均以微服务的方式部署发布，具有弹性扩展和高可用特性。

应用层：该层主要体现流处理平台在恒丰银行现阶段支撑的业务应用。

流处理平台主要技术组件及部署架构图

流处理平台使用的主要技术组件及其在两个数据中心部署的架构如上图所示。其中：Zookeeper集群，主要负责配置流处理平台管理和任务队列管理功能；Flume Collector集群，主要负责流处理平台文件类数据的接入工作；Streaming集群，为流处理平台的核心组件集群，主要负责数据流处理功能；Kafka集群，主要负责消息订阅与消息传输缓存功能；Redis集群，主要负责消息订阅，数据分析及数据查询功能；大数据平台集群，主要负责数据的存储、同步和数据分析挖掘等功能。

（2）客户行为实时分析系统架构

前端应用（如手机银行系统、网银系统等）客户操作日志是文件类数据，对于这类文件类数据流处理平台主要采用Flume client & server 模式，因此前端业务系统需要部署agent实时采集数据，Flume Collector 负责收集各agent数据，再将数据发送至流处理平台，随后由流处理平台负责数据过滤、数据解析、数据补全等实时处理工作，最后应用层的客户行为实时分析系统负责对实时性指标进行实时分析，对于非实时性指标则进行离线分析，并最终将分析结果以图表形式展现给。

客户行为实时分析系统整体逻辑架构如下图所示：

用户行为实时分析系统的整体逻辑架构

（3）微服务化和Docker容器化

客户行为实时分析系统还做到了微服务化和Docker容器化。我们将Akka微服务架构的集群负载，服务监控、故障恢复与弹性部署能力结合恒丰银行数据中心PAAS云平台采用的Docker容器技术对应用级负载、监控、弹性资源分配以及快速部署能力相结合，对客户行为实时分析系统的Xitrum、JDBC、 Redis 等功能组件进行了拆分，实现了整个应用的Docker容器化。

除了客户行为实时分析系统，流处理平台使用的flume、kafka、zookeeper等开源组件也实现Docker容器化并使用恒丰银行DevOps工具服务，从开发、构建、测试到版本发布的全流程自动化，中间提供包括计划、任务分配跟踪、问题跟踪、文档管理、版本发布全过程的项目协作支持

（4）数据应用

通过深入了解业务需求，从营销角度、风控角度、客户体验角度三个主要业务视角，我们主要设计了以下功能模块：

营销角度，既有为当前业务运营发展提供数据支持的客户规模和质量、渠道运营分析模块、实时状态跟踪、分析中心等功能模块，也有为未来业务营销发展打下数据基础的个体行为分析、客户属性分析等功能模块。具体介绍如下：

客户规模与质量：通过分析某些功能模块的客户使用情况，了解客户产品偏好，分析客户结构和质量信息，从而为银行业务决策打下数据基础。

渠道运营分析：联动多个应用的使用情况，提供整体的运营分析情况。

实时状态跟踪：通过实施检测当前客户使用应用的情况，可实时发现例如服务异常等突发事件情况，从而做到及时预警，为事件预警和处理赢得时间。

分析中心：为业务定制化输出各类分析报告，满足业务日常运营需求。

个体行为分析：把单个客户的行为分析单独统计分析，从而为反欺诈、精准营销等提供数据基础。

客户属性分析：通过分析客户常用应用终端、客户常用地域等，分析客户基础属性信息，从而为交易反欺诈、精准营销打下数据基础。

风控角度：主要有个体行为分析、客户属性分析等模块，具体上文已描述。

客户体验角度：从提升客户体验角度出发，为行内应用优化方向提供数据证据的有客户参与度分析、功能分析等模块。具体介绍如下：

客户参与度分析：通过获取客户的使用时长、访问深度、应用各功能模块的使用等情况，分析客户应用使用情况信息，从而为应用优化等打下数据基础。

功能分析：分析某个应用的客户最常用路径，了解客户常用行为，从而为优化路径提供数据说明。

结果/效果总结

客户行为实时分析系统填补了恒丰银行在客户行为分析方面的空白。业务人员第一次能够直面感受和了解客户真实的应用使用行为状态。例如：

（1）客户规模与质量——活跃客户指标（部分）

活跃客户指标之基金、理财模块客户每日活跃、每周活跃情况

通过分析理财、基金等功能模块的客户活跃指标，观察银行理财偏好客户在全行占比情况，以及理财、基金产品的关注情况，从而更好的了解银行客户的规模和质量。

（2）客户参与度分析——访问时段统计

客户访问时段分布之按小时分布

该功能呈现选定时间段内的登录客户、匿名客户、客户整体访问时段分布情况。如果按小时统计，通过分析可以明显看出每天都会呈现三个客户活跃高峰，分别对应早、中、晚的某个特定时段，其中每天早间时段客户最为活跃。如果按天观察，可以看出，周一、周二客户最为活跃，周六、周日客户最为不活跃。基于此，我们可以让业务更好的制定或优化营销策略，例如加大周一、周二早间时段的渠道营销力度，可能会获得更佳营销效果。

综上，借助客户行为实时分析系统，从全渠道运营上，渠道业务人员能够随时了解渠道系统客户的地域分布、访问时段分布、交易类型分布、关注产品分布、终端使用分布信息等，从而判断产品运营情况，提高产品运营水平；从精准营销上，渠道业务人员能够随时了解单一客户的理财产品偏好、基金产品偏好、地域偏好、功能偏好、访问时段偏好等行为画像信息，从而为后续精准营销、个性化定制应用、反欺诈等打下坚实数据基础。

基于上述数据积累，我们还在流失预警、客户分群、消费周期模型、理财产品销量预测模型方面也进行了一系列模型挖掘研究。

延展阅读：如何高效开发实时数据分析应用

星环科技

在星环大数据技术峰会深圳站中，星环的流产品研发经理杨俊给大家做《如何高效开发实时数据分析应用》的演讲。实时流处理一直是很多行业特别需要但门槛又特别高的技术，星环的产品可以让用户实现快速应用，易操作。小编特此推出演讲全文，供大家回味。

以下是演讲全文：

首先了解一下为什么使用实时技术。

这里有几张图：

第一张图是风电的应用。那风电应用为什么需要实时技术呢？以前没有这个技术的时候，它的延迟比较高，一旦有发电机组发生问题，它很晚才能反映过来去维修。这样就耽误了最佳维修时间，也会产生资源的浪费。若此时运用分布式的消息队列加上分布式的流处理，就可以使其达到秒级的实时预警效果。

第二张图是代表金融相关的一些问题。没有实时处理技术的时候，它们往往是在每天下班之前跑一下系统，评估公司的资产和风险状况。运用批处理的话，是将所有的市场数据进行估计运算，计算很多风险值。在这里如果有分布式的实时处理系统，它会在每次市场数据变化的时候重新计算一下公司的估值状况和风险情况，所以当下单结束或者市场交易结束的时候，我们拿到的已经是最新的市场数据，只需要进行查询和返回就可以了，不需要额外的计算。对于上层领导和监管部门来说，如果能及时反馈这些信息的话，可以帮助他们达到更好的决策效果。

最后一张图是交通部门秒抓套牌车的例子。以前没有实时处理的时候，很难想象交警会在下一个红绿灯口等着套牌车过来，也就是在实时处理的情况下，我们彻底改变了这个抓套牌车的场景。也就是说很多业务在原来批处理的角度是不可能实现的。以上是我简单举了几个实时处理的例子。其实类似的例子还有很多，星环的很多客户也已经开始运用我们的实时处理技术，效果都不错。

我的标题是如何高效开发实时数据分析应用，我们公司是从13年开始运用spark streaming来做实时应用，当时也遇到很多困难。

首先就是入门门槛是很高的。无论是我们和客户合作来推动应用的实现，还是和合作伙伴共同推动应用的实现，当时都是很困难的，写出来的应用质量不高。因为实时应用对性能要求很高，所以对代码质量的要求也比较苛刻，如果用spark streaming呢，需要对这个编程模型了解的比较清楚才可能写出高效的代码。所以对于程序员来说，这块的开发成本比较高。

另一方面，迁移成本很高。如果有一个公司，它想要把本身批处理的业务往实时处理的方向迁，那对于原来使用SQL的业务分析人员来说，让他们在转到spark streaming上就比较困难了。我们有的客户原来拥有的PL/SQL的代码量已经是几十万行了，让现有业务分析人员全部弄清楚都是很困难了，别说我们再将这些代码改写成spark streaming了，成本可能就高的离谱了。

最后一个问题就是产品化差。原来运维人员可能只需要会看几个常见错误就行了，但是现在这种写代码方式可能出现各种各样的问题，无法区分是框架本身的错误还是他代码的bug，他就需要去找程序员看出错误然后再解决，不仅麻烦，时间周期也比较长。

综上所述，我们认为直接使用编程的方式是不够高效的。所以我们从去年6月开始就想要完全采用SQL来写实时处理。

接下来有一个非常直观的例子。

左边这部分是用spark streaming 写的代码，这里还不是完整版，完整的需要2页ppt才能展示。如果用SQL写，就只需要右边的这几行代码了。这几行主要就是对test表根据一定的排列方式输出查询结果。这个SQL看上去就比较直观，稍微有点SQL经验的人都可以容易的看懂这些代码。如果让分析人员看左边的代码，那就比较困难了。

而且，右边的SQL代码还可能写的比左边的代码更高效，因为我们在框架层做了更多的优化。

接下来是stream SQL的框架图，分为三层。

最下面是存储层，在这一层上，我们的SQL可以对接各种存储层，例如ORC，Hyperbase,holodesk,Oracle等等。

中间层计算层中，我们对它的改动还是比较大的。对输入有一个Sourcemanager来控制，比如有多个表的时候要怎么去共享内存中的数据。然后有一个Application manager来管理过来的SQL是怎么运行的，运行周期是怎么样的，用户需不需要展开运行值或者状态信息。接下来，Distributed Execution Engine是我们集中改造的，这个引擎无论是对SQL还是执行计划的执行都是进行了比较高的优化的。Storage manager从用户的角度来说，比如存了一些东西，它到底是在内存里还是硬盘里面，中间的这些问题用户是不需要考虑的，我们再这里有一个透明层已经帮你解决掉了，而你是感觉不到我们在这里做的透明层的。Sink manager是和存储层和输出打交道的。比如我要输出到Hyperbase，sink manager就会考虑需要用分批存储的方式，因为这个方式性能比较高。

最后上层就是一些接口层，Inceptor这边你可以用SHELL直接打开连接数据库，或者用JDBC和ODBC来做steam SQL的连接操作，然后通过SQL compiler去把执行计划输入到下面的计算层中。我们还支持一些数据挖掘的接口，到目前主要是支持R语言，之后会有一些SQL的对接和图形化的对接。

那接下来支持语法的部分基本上和我们的数据仓库的语法是相同的，因为我们完全是从Inceptor那一套语法过来的。

SQL2003除了少数无法支持的语法之外，支持程度达到98%以上。这其中比如流上的数据是持续不断的数据，如果你要对它前一秒的数据在流上做修改其实是没有意义的，所以这块我们是不支持的。此外，我们还有一些额外的语法，主要是为了在流上面做更好的特殊化处理，因为原来的语法集是不能完备的支持流上面的特殊处理的。

另外，我们还支持Oracle的PL/SQL和DB2的PL/SQL，其实，支持PL/SQL的目前在这个地球上只有我们一家 :p

接下来我分享一下我们的一些经典案例场景。

第一个是有关于权限控制。团队来了新人，想基于生产集群的数据额外开发一些新的功能，这时候就需要比较高效的开发。或者现在有用户想查看某些信息，但是一些敏感信息只有管理员才能看到。另外，公司里的多租户环境中，多个租户同时在同一台机器上运行程序，不会相互干扰。

对于以上问题，我们抽象出了一个Application的概念，例如图中这个新用户叫做Emily，刚进公司把她归在一个testapp里面，你可以赋予她各种权限。比如她有权利在testapp里创建流应用，她有权利去看当前正在运行的分析系统，她有权利去启动一些以前存储过的存储过程。类似的，公司里可能还有一群人group1，对应他们有一个应用叫app1。如果现在Emily想去看group1的app1里的东西，不给她赋予一个特殊的权限，她是没办法看到的，所以我们就做到了一个这样的隔离。

具体来说是这样的，首先要去创建一个testapp，就是create application testapp，然后把相应的权限都赋给Emily。这样做了之后，一般来说到对应的testapp里去查相应的权限是可以查到Emily有权限的，但是她到另外一个生产集群上去做相应的操作，是没办法成功的。另外，我们的List命令是可以查询到一般的运行状态的，比如现在跑了多少task，运行了多长时间，在什么状态，有没有什么问题等等。额外的信息我们是不给普通权限的人开放的，需要有管理员信息才可以到4040页面查看。最后，不同租户之间，例如刚才的testapp和production之间做到彻底隔离互不干扰。

接下来的第二个案例是ETL任务的例子，像刚开头说到的风电的例子和交通稽查布控的例子其实就是他们主要用我们的系统做ETL任务。

如果有一些实时数据进来，我可能有需求要把他们存储起来，录入到某个库里面，或者后来需要做现场分析，我们要录入holodesk内存表，之后做查询。这就是一个非常常见的ETL任务，无论在什么行业里，当前这个用到的是比较多的。若这个步骤要用编程实现，工作量还是蛮大的，有很多问题需要考虑，接口怎么处理等等。如果是用我们的产品，你可以用过JDBC或者ODBC对接我们的StreamSQL，通过Stargate导到各个不同的数据库里，比如对Hyperbase做一个实时的检索，Holodesk可以做实时的交互分析，HDFS可以做统计分析和跑批等等。我们甚至可以把结果在写回Kafka，给下一个应用做实时告警。

接下来就是实现过程。首先创建流，然后创建几张表如图，最后启动流的时候只需要图中这几行SQL，你的ETL就完成了。其实就是需要这样几行SQL就可以实现流应用，当然，一开始你也可以加入聚合、复杂计算等，但是这也只是一个SQL的复杂化问题。

最后因为时间关系，我们就不详细介绍剩下两个案例。第三个是网站实时统计的一个场景，需求我列在ppt里，其实我们也只需要下面这张ppt里的几行SQL就可以解决。

最后一个案例是比较复杂的金融期货的案例。简单来说，整个过程就和刚才差不多，就不断的create一些stream表，不停的在stream表上做一些转化，再加上一些窗口函数，最后就可以实现一些很复杂的业务。

新一代技术+商业操作系统：

AI-CPS OS

在新一代技术+商业操作系统（AI-CPS OS：云计算+大数据+物联网+区块链+人工智能）分支用来的今天，企业领导者必须了解如何将“技术”全面渗入整个公司、产品等“商业”场景中，利用AI-CPS OS形成数字化+智能化力量，实现行业的重新布局、企业的重新构建和自我的焕然新生。

AI-CPS OS的真正价值并不来自构成技术或功能，而是要以一种传递独特竞争优势的方式将自动化+信息化、智造+产品+服务和数据+分析一体化，这种整合方式能够释放新的业务和运营模式。如果不能实现跨功能的更大规模融合，没有颠覆现状的意愿，这些将不可能实现。

领导者无法依靠某种单一战略方法来应对多维度的数字化变革。面对新一代技术+商业操作系统AI-CPS OS颠覆性的数字化+智能化力量，领导者必须在行业、企业与个人这三个层面都保持领先地位：

重新行业布局：你的世界观要怎样改变才算足够？你必须对行业典范进行怎样的反思？
重新构建企业：你的企业需要做出什么样的变化？你准备如何重新定义你的公司？
重新打造自己：你需要成为怎样的人？要重塑自己并在数字化+智能化时代保有领先地位，你必须如何去做？

AI-CPS OS是数字化智能化创新平台，设计思路是将大数据、物联网、区块链和人工智能等无缝整合在云端，可以帮助企业将创新成果融入自身业务体系，实现各个前沿技术在云端的优势协同。AI-CPS OS形成的数字化+智能化力量与行业、企业及个人三个层面的交叉，形成了领导力模式，使数字化融入到领导者所在企业与领导方式的核心位置：

精细：这种力量能够使人在更加真实、细致的层面观察与感知现实世界和数字化世界正在发生的一切，进而理解和更加精细地进行产品个性化控制、微观业务场景事件和结果控制。
智能：模型随着时间（数据）的变化而变化，整个系统就具备了智能（自学习）的能力。
高效：企业需要建立实时或者准实时的数据采集传输、模型预测和响应决策能力，这样智能就从批量性、阶段性的行为变成一个可以实时触达的行为。
不确定性：数字化变更颠覆和改变了领导者曾经仰仗的思维方式、结构和实践经验，其结果就是形成了复合不确定性这种颠覆性力量。主要的不确定性蕴含于三个领域：技术、文化、制度。
边界模糊：数字世界与现实世界的不断融合成CPS不仅让人们所知行业的核心产品、经济学定理和可能性都产生了变化，还模糊了不同行业间的界限。这种效应正在向生态系统、企业、客户、产品快速蔓延。

AI-CPS OS形成的数字化+智能化力量通过三个方式激发经济增长：

创造虚拟劳动力，承担需要适应性和敏捷性的复杂任务，即“智能自动化”，以区别于传统的自动化解决方案；
对现有劳动力和实物资产进行有利的补充和提升，提高资本效率；
人工智能的普及，将推动多行业的相关创新，开辟崭新的经济增长空间。

给决策制定者和商业领袖的建议：

超越自动化，开启新创新模式：利用具有自主学习和自我控制能力的动态机器智能，为企业创造新商机；
迎接新一代信息技术，迎接人工智能：无缝整合人类智慧与机器智能，重新
评估未来的知识和技能类型；
制定道德规范：切实为人工智能生态系统制定道德准则，并在智能机器的开
发过程中确定更加明晰的标准和最佳实践；
重视再分配效应：对人工智能可能带来的冲击做好准备，制定战略帮助面临
较高失业风险的人群；
开发数字化+智能化企业所需新能力：员工团队需要积极掌握判断、沟通及想象力和创造力等人类所特有的重要能力。对于中国企业来说，创造兼具包容性和多样性的文化也非常重要。

子曰：“君子和而不同，小人同而不和。” 《论语·子路》云计算、大数据、物联网、区块链和人工智能，像君子一般融合，一起体现科技就是生产力。

如果说上一次哥伦布地理大发现，拓展的是人类的物理空间。那么这一次地理大发现，拓展的就是人们的数字空间。在数学空间，建立新的商业文明，从而发现新的创富模式，为人类社会带来新的财富空间。云计算，大数据、物联网和区块链，是进入这个数字空间的船，而人工智能就是那船上的帆，哥伦布之帆！

新一代技术+商业操作系统AI-CPS OS作为新一轮产业变革的核心驱动力，将进一步释放历次科技革命和产业变革积蓄的巨大能量，并创造新的强大引擎。重构生产、分配、交换、消费等经济活动各环节，形成从宏观到微观各领域的智能化新需求，催生新技术、新产品、新产业、新业态、新模式。引发经济结构重大变革，深刻改变人类生产生活方式和思维模式，实现社会生产力的整体跃升。