流计算引擎在传统金融企业的实践

大数据应用的一个典型特征就是数据应用的时效性要求越来越高。在各类业务应用中，除了以往的实时营销和风险监控需要实时性的数据，管理决策类的应用也不断向时效性更高的层面迈进。在互联网公司中此类业务场景较多，因此大多数互联网公司都有批量计算和实时计算两个大平台来承载不同的业务应用。

　　同样的场景在保险公司业务应用中广泛存在。在各类业务竞赛期间，各种实时报表成为关注重点。在传统的技术手段下，通过微批量的方式以间隔更短的小批量计算来实现报表的准实时化。这种方式无论在资源消耗还是应用效果上都存在较多的局限性。本文介绍了一种采用流计算引擎的技术手段来实现实时性的业务监控和预警类应用，这种方式具备资源消耗小、实施成本低的特点。

一、应用背景

　　随着数据量不断迅速增长以及数据来源的渠道日益多样化，很多场景下都需要实时的技术手段来处理这些数据。以保险公司为例，在开门红、年底收官及各类业务竞赛期间，为了营造竞争的气氛，往往采用排名、擂台赛的方式来鼓舞销售队伍的士气。为了支持这类业务场景，需要将各类业务指标按照不同的机构、不同的产品属性进行实时统计和汇总，催生了实时分析的需求。

　　无论采用传统的关系数据库存储数据，还是采用NOSQL数据库存储数据，都采用批量处理的方式汇总计算并保存和展现结果(如图1所示)。

　　从数据采集端来看，该模式下，可以通过各种数据采集手段将数据实时采集到一个数据平台中，在批处理模式下，各类数据应用需要采用一种计算引擎进行各种运算。举例说明，假定保单表上有如下几个字段：保单号 险种 销售渠道 出单机构 营销员工号 缴费方式 缴费年限 保费。一些场景需要实时看到诸如各分公司各个渠道的保费；个险渠道每个分公司保费销售额最高的前十名业务员；银保渠道保费销售额最高的前十个网点；各个险种的保费收入；趸交、3年期、5年期、l O年期及以上的保费收入等报表的年累计值和当日累计值。采用传统的技术手段，往往通过下述方法实现：①事先计算好T日值批处理作业；②将当日累计值保存在结果表中；③每5分钟／l0分钟执行一个批作业将该批次的结果计算出来；④将②和③的结果合并得到当日累计值；⑤将①与②的结果合并得到当年累计值。

　　前述场景中，5张报表每隔5分钟就需要对到达的新数据通过5个SQL语句分别进行计算，如第一个报表的伪代码为：

　　Select出单机构，渠道，Sum （保费收入）
　　Fj rom保单表
　　Group by出单机构，渠道

　　通过这样的方式，尽管也可以实现准实时报表，但存在两个问题：一是通过批量实现的准实时应用，其时效性无法达到实时，只能不断地缩小时延。二是针对同一批数据的多个不同应用，需要多遍扫描数据，实现不同应用的计算。如上面的例子中，5个不同的报表需要5个不同的SQL语句反复扫描相同数据，消耗资源过多。

　　与传统的批量计算引擎不同，流计算中，由于无法确定数据的到达时刻和顺序，也无法确定数据是否全部到达，因此数据无法全部到达并存储后再进行计算。在这种情况下，流动的数据将直接在内存中进行实时计算，Twitter的Storm，Yahoo的S4就是典型的流式数据计算架构，数据在任务拓扑中被计算并输出结果。图2显示了流计算思路：在数据流不断到达的过程中，不同的数据计算逻辑在内存中得到新的数据后直接进行计算，在需要的时候将计算结果保存和展示。

　　与批量计算不同，流计算方式的特征包括：①实时性，与批量计算先存储数据再计算得到结果不同，流计算不进行数据存储，而是对内存中的数据直接计算。②易失性，数据到达后立即被计算，数据本身和结果是否需要保存完全看后续有没有使用价值，对于计算逻辑本身而言，数据计算过后就已经失效。③无序性，多个数据流之间以及一个数据流内部往往是无序的，因此在计算逻辑中无法考虑数据之间的顺序和关联性。④精确性和一致性，与批量计算所针对的数据是静止状态不同，实时计算的数据针对的是变化的数据，因此计算结果的精确性和一致性是无法衡量的。如前述场景中，5个报表的结果应该是一致的，分支机构的保费汇总与分产品的保费汇总总计应该是相同的，这在批量计算模式下很容易实现，但在实时计算模式下，在某—个时间点结论未必一致。

三、两种计算模式的融合

　　从上文的介绍可以看出，流计算和批量计算之间存在较大的差异，表1从7个角度进行具体分析。

　　不难看出，流计算适合于实时性高、数据之间没有太多关联性、对于分析结果的要求不十分精确的应用场景；批量计算适合于准确性高、数据之间相关性紧密、实时性要求不高的场景。显然，这两种计算模式并不是替代或者对立的，而是在不同的应用场景可以发挥不同的价值，两者的关系如图3所示。

四、基于流计算的实时数据分析系统实践

　　1．基于流计算技术的实时数据分析系统架构的功能图4为基于流计算技术的实时数据分析系统架构，其主要包含的组件及功能如下。

　　①数据采集模块：源系统业务数据变化后，该模块将业务数据以消息的方式发送出去。②消息传输模块：KAFKA在其中主要承担消息缓冲及可靠消息传输的作用。③实时计算模块：基于SPARK的实时计算模块从KAFKA接收到数据后进行实时计算。如果此处有多个不同的报表，可以直接部署多个计算程序，在接收到数据之后直接进行计算。④结果存储：将计算的结果实时更新Redis，确保前端访问的性能和可靠性。⑤前端展现：通过AJAX不断轮询Redis展现最新查询结果。

　　通过该架构，可以实现基于开源软件的实时分析，实时计算能力达到秒级响应，即核心系统录入一条保单信息后，计算结果可秒级展现在前端页面中。

　　 2、流计算实践中需注意的问题

　　流计算作为传统批量计算的补充，为数据实时应用提供了一种非常高效的技术实现手段。在数据应用时效性要求越来越高的今天，对于传统金融企业有非常大的价值。实践过程中，还需要注意以下问题。

　　①数据采集的技术实现方式：在传统金融企业中，源系统的数据采集是较为复杂的问题。通常有两种处理方式，一是在应用层将数据通过应用发送到消息队列；二是基于数据库日志发送。②准确性和数据一致性期望：实时数据分析的准确性以及一致性未必能与批量计算的结果匹配。因此，在系统设计之初就要建立合理的期望值，避免出现理解上的不一致。③跨数据流的应用：跨数据流的应用由于数据流之间的逻辑关系难以保障，因此不建议此类应用采用实时计算的方式来实现。

（文章来源：《中国金融电脑》杂志）

扫码即可手机
阅读转发此文