实时决策系统中的核心组件——实时指标计算

无奈何杨
172 阅读8分钟

参考

《风控要略：互联网业务反欺诈之路 (马传雷,孙奇,高岳)》第8章

image.png

一、核心概念

  1. 指标定义：在风控反欺诈业务中，无论是基于专家规则还是风控模型，都需要依赖对一定时间范围数据进行回溯加工的变量，这些变量被称为指标。例如“1天内设备上登录的账户过多”这一规则，就需要回溯24小时的历史数据，计算该设备在这段时间内登录的账户个数，并与配置的阈值进行比较判断。

  2. 指标类型：

    • 频度-出现次数统计：如IP最近5分钟注册次数、手机号最近1小时接收短信次数，次数过多可能对应垃圾注册、短信轰炸等风险。
    • 频度-关联个数统计：像1天内同一设备接收短信的手机号个数、7天内同一设备充值的账户个数，个数过多可能涉及群控设备、群控账号等风险。
    • 活跃天数：例如账户最近7天活跃次数、设备最近1个月活跃次数，活跃次数过少可能意味着是僵尸用户。
    • 移动距离：如设备最近1小时移动距离、设备最近24小时移动距离，移动距离过远可能存在虚假定位的风险。
    • 常用习惯：包括账户最近7天常用设备型号、账户最近30天常用登录城市，常用型号或城市不一致可能暗示账户被盗等情况。
    • 趋势计算：如账户最近1天多笔交易支付金额递增、账户最近1天先小额后大额支付，支付趋势异常可能与盗卡试探等风险相关。
    • 其他：例如账号最近5分钟密码连续错误次数，连续错误可能是账户遭受暴力破解的迹象。

  3. 指标特征：

    • 时间窗口：指标计算所针对的特定时间段，如5分钟、1小时、1天等。
    • 事件：与指标相关的业务活动，如注册、登录、交易等。
    • 主属性：指标计算所围绕的主要对象，如IP、手机号、设备、账户等。
    • 副属性：辅助主属性进行指标计算的属性，如在计算设备接收短信的手机号个数时，手机号就是副属性。
    • 计算逻辑：对数据进行处理和计算的方式，如求和、去重求和、统计出现次数最多的设备型号等。

二、实时指标计算方案

  1. 基于数据库SQL的计算方案：

    • 实现方式：利用关系数据库的SQL语句进行统计计算，例如通过SELECT COUNT(1) FROM x WHERE ip = 'x.x.x.x' AND gmt_create > NOW() - INTERVAL 1 HOUR计算最近1小时内某IP注册账号的个数。
    • 优点：实现简单，无需新建数据。
    • 缺点：不够灵活，一般只能解决求和类规则，且无法预计算，在时间跨度大、数据多的情况下，响应时间难以保障。

  2. 基于事件驱动的计算方案：

    • 实现方式：将注册、登录、交易等业务事件转化为消息进入Kafka等消息系统，消费者接收到事件后进行预计算或聚合，将结果存储到数据库或缓存系统中。当决策引擎查询指标时，基于预计算或聚合的中间结果进行再加工并输出。
    • 优点：可以进行预计算，查询性能较好。
    • 缺点：需要针对不同的事件场景进行特殊的逻辑开发，工作量大，每次开发完成后需要应用发布；并且需要大量的预先计算，即使后续该指标未被查询到。

  3. 基于实时计算框架的计算方案：

    • 实现方式：借助实时计算框架（如Storm、Spark Streaming、Flink）来处理数据流、存储中间结果，并保障性能和可靠性。框架提供易用的API，甚至可以通过SQL完成指标上线。
    • 优点：能够统一处理数据流、中间结果存储、性能和可靠性保障等问题，大大减少开发工作量，提高指标上线效率。
    • 缺点：需要熟悉实时计算框架，并且要做好框架的选择和配置。

三、实时计算框架对比

框架架构数据处理模型与延迟一致性保障容错性吞吐量易用性成熟度
Storm流计算，主从模式亚秒级别在Trident模式下支持exactly once语义低，基于ACK机制低低，不支持SQL比较稳定
Spark Streaming基于Spark，主从模式，可理解为小颗粒时间维度上的批处理秒级支持exactly once高，基于WAL和RDD机制高高，支持SQL，Batch和Streaming采用统一编程框架比较稳定
Flink流计算，主从模式亚秒级别支持exactly once中，基于snapshots checkpoint机制高高，支持SQL，Batch和Streaming采用统一编程框架新型框架，应用范围广，高速发展中

四、反欺诈实时指标计算实践

  1. 实时指标计算引擎原型：

    • 数据结构：以设备ID为Key，存储业务事件数据。
    • 实现方式：当新的业务事件到来时，不断更新Value数据。在进行风险判断触发规则使用指标时，根据设备ID查询历史所有事件，在内存中进行数据筛选和计算。
    • 优点：速度快，只需一次NoSQL KV查询即可获取计算所需数据；节省NoSQL内存，一份数据可重复用于多个指标计算；同一主属性新指标上线快，无需积累数据。
    • 缺点：每次实时指标计算会返回大量无关数据，对网络带宽和系统内存造成压力。

  2. 数据拆分计算：

    • 数据结构：按不同维度（如设备ID - ip、设备ID - account）拆分存储业务事件数据。
    • 实现方式：当业务风险事件触发规则使用指标时，只需查询相应维度的数据即可完成计算。
    • 优点：按需要存储数据，使用指标查询时不浪费网络带宽和应用内存。
    • 缺点：数据复用性差，占用NoSQL数据库较大的内存；同一主属性新指标上线需要数据积累。

  3. 分片计算：

    • 数据结构：以主属性为Key，二级Key为时间片（如10分钟），Value为统计个数。
    • 实现方式：当查询指标时，查询多个时间分片的数据并进行聚合累加。
    • 优点：按分片存储中间计算数值结果，占用存储空间较少；指标查询数据少，速度快。
    • 缺点：无法做数据去重，只支持“频度-出现次数统计”指标。

  4. 引入Flink：

    • 实现方式：通过代码配置指定计算任务，如聚合KEY、时间窗口、聚合方法、输出等，将计算过程交给Flink框架处理，计算结果存储到NoSQL数据库中。
    • 优点：逻辑简单，只需关注业务主属性、时间窗口、计算方法等，其他由计算框架解决。
    • 缺点：需要引入并熟悉实时计算框架。

  5. Lambda架构：

    • 实现方式：对于跨小时、跨天甚至需要回溯1个月计算的指标，对历史数据使用批计算（如Spark），对实时数据使用流计算（如Flink），最后综合计算结果。
    • 优点：能够快速高效、低成本地完成跨越较长时间窗口的实时指标计算。

五、反欺诈实时指标计算系统

  1. 系统架构：

    • 业务层：包括指标配置、指标管理、指标路由和指标优化等关键要素。
    • 计算层：综合使用Flink和Spark框架，以及定制的计算逻辑。
    • 存储层：采用Redis、Aerospike、Hbase、Mysql等多种存储方式。

  2. 业务层关键要素：

    • 指标配置：风控运营人员通过界面化操作新增、修改和删除指标，根据预定义的指标计算方法转换成计算任务并提交到实时指标计算系统。
    • 指标管理：结合运行情况，定期输出各指标的性能、数据量、成本等信息，指导系统优化方向，及时下线不再使用的指标。
    • 指标路由：当业务事件进入决策引擎后，决策引擎调用实时指标计算系统查询指标结果，实时指标计算系统生成查询路由信息并返回结果。
    • 指标优化：针对不同类型的指标进行针对性优化，如对大量业务场景常用的指标采用定制化计算方法并默认集成到系统中。

六、本章小结

本章深入介绍了反欺诈实时指标计算系统，包括对实时指标的抽象建模、多种计算方法的介绍以及在反欺诈实践中的优化过程和系统设计。实时计算框架凭借其优势已成为实时指标计算系统不可或缺的核心模块。

avatar
文章
阅读
粉丝