|
案例及解决方案汇总页面： 阿里巴巴云实时计算产品案例及解决方案汇总 对于一款互联网产品，典型的风控场景包括：注册风控、登录风控、交易风控、活动风控等，而风控的最佳效果是防患于未然，所以在三种实施方案，预警和过程控制是最好的。 . 这就要求风控系统必须是实时的。 本文介绍一种实时风控解决方案。 1.整体架构 风险控制是业务场景的产物。风控系统直接服务于业务系统，与处罚系统和分析系统相关。各系统的关系和作用如下：
风控系统和分析系统是本文的重点，为了讨论方便，我们假设业务场景如下： 风险控制实施计划：事件中的风险控制，目标是拦截异常事件； 2.风险控制系统
风控体系有两条技术路线：规则和模型。规则 优点是简单、直观、可解释、灵活，所以在风控系统中活跃了很长时间风控系统方案，缺点是容易被破解，一旦被黑客，它会失败风控系统方案,基于Flink和规则引擎的实时风控解决方案，所以在实际的风控系统中，经常结合基于模型的风控来增加健壮性。但是由于篇幅所限，在本文中，我们只关注基于规则的风控系统架构。当然，如果有模型风控的需求，这个架构也是完全支持的。 规则是对事物的条件判断。我们假设注册、登录、交易和活动的几个规则，例如： 规则可以组合成规则组。为简单起见，我们这里只讨论规则。 规则实际上由三部分组成： 规则可以由有经验的运营专家填写，也可以由数据分析师根据历史数据发现。会被猜到导致失败，所以无一例外都需要动态调整。 基于以上讨论，我们设计了如下风控系统方案：
系统有三个数据流： 本节介绍前两部分，下一节介绍分析系统。
2.1 实时风控 实时风控是整个系统的核心。由业务系统同步调用，完成相应的风控判断。 如前所述，规则往往是人写的，需要动态调整，所以我们将风控判断部分和规则管理部分分开。规则管理后台为操作服务风控系统方案,基于Flink和规则引擎的实时风控解决方案，操作者进行相关操作： 管理后台做完后，规则判断部分的逻辑就很清晰了，包括前置过滤、事实数据准备、规则判断三个方面。 2.1.1个预过滤 触发特定事件（如注册、登录、下单、参与活动等）后，业务系统同步调用风控系统，带有相关上下文，如IP地址、事件标识符等.，规则判断部分会根据管理后台的配置来决定是否判断。 这部分逻辑很简单。 2.1.2 实时数据准备 在做出判断之前，系统必须准备一些事实数据，例如： 我们将在2.2准实时数据流中介绍redis/hbase的数据输出。 2.2.3 规则判断 获取事实数据后，系统会根据规则和阈值进行判断，然后返回结果，整个过程结束。 整个过程逻辑清晰。我们常说的规则引擎主要作用在这部分。一般来说，有两种方式来实现这个过程： 这两种方案都支持动态更新规则。 2.2 准实时数据流 这部分属于后台逻辑，服务于风控系统，准备事实数据。 数据准备和逻辑判断的分离是从系统性能/可扩展性的角度。 如前所述，进行规则判断需要事实的相关指标，例如最近一小时的登录次数、最近一小时的注册账号数等。这些指标通常跨越一段时间，是一个某种状态或聚合。 ，在实时风控过程中很难根据原始数据进行计算，因为风控的规则引擎往往是无状态的，不记录之前的结果。
同时，这部分的原始数据量非常大，因为用户活动的原始数据必须要送过来计算，所以这部分往往由流式大数据系统完成。这里我们选择 Flink。 Flink 是当今流计算领域无可争议的 No.1。无论是性能还是功能，都能很好的完成这部分工作。 这部分数据流很简单： Flink 将汇总后的指标结果写入 Redis 或 Hbase 供实时风控系统查询。两者都不是什么大问题，可以根据场景来选择。 通过将数据计算和逻辑判断分离，引入Flink，我们的风控系统可以应对庞大的用户规模。 3.分析系统 前面的东西从静态的角度看是一个完整的风控体系，但是从动态的角度看是缺失的。这种缺失不体现在功能上，而是体现在进化上。也就是说，如果从动态的角度来看一个风控系统，我们至少需要两部分，一是衡量系统的整体效果，二是为系统升级规则提供依据/逻辑。 在衡量整体效果方面，我们需要： 在为系统提供规则/逻辑升级的基础方面，我们需要： 这是分析系统的角色定位，在他的工作中部分是确定性的，部分是探索性的，为了完成这种工作风控系统方案，系统需要尽可能多的数据支持，比如： 这是一个典型的大数据分析场景，架构比较灵活，我只给出一个建议的方法。
相对来说，这个系统是最开放的，既有固定指标分析，也有机器学习/数据分析技术，可以发现更多新的规则或模式，限于篇幅，这里不再详述。 4.参考文献 1.从 Drools 规则引擎到风控和反洗钱 2.基于 Groovy 的规则脚本引擎实践 3.基于规则的风控体系 4.网易严选风控实战 5.网易考拉规则引擎平台架构设计与实践 6.一个开源的java风控系统 |
|
|
