第一章-聊聊风控-什么是风控?

开篇词:

作为一个母婴电商互联网公司风控从业者,始终觉得要输出一些风控相关东西,分享给大家。不管这篇文章有没有人看哈。打算去做一个系列,从0到1分享整个风控系统搭建的过程,以及风控系统的产品架构,技术架构,所需要的技术栈以及技术挑战。后面的几篇会深度分析风控在传统互联网公司(非金融,非TO C电商)的地位,以及整个风控行业未来的发展。

作为一个风控行业两年从业者,还是不够资深,希望大家有好的建议和想法指出来,大家多多沟通和交流。虽然这个文章不一定有人看哈。

遥想2017年11月份,当时搭建公司的风控系统之时,我也是很懵逼,什么是风控?架构是怎么样的?需要哪些技术栈?以下资料是2017年整理,现在修改精简而成。

第一个话题就是:什么是风控系统?会从几个大的层面进行分析:产品、技术、架构,大厂实践,以及搭建这么一套系统涉及到的技术栈。

1.产品层面

  1. 为业务系统保驾护航,实时发现潜在的风险,及时止损。比较痛点的业务风控场景:登录,注册,营销,支付,金融准入/支用/支付等。
  2. 无论是商业化的风控系统,还是(京东,美团,携程,有赞)等公司内的风控系统,都是基于某些固定的业务场景去做的。(找出有风险的业务场景)
  3. 风控的生命周期分为:事前,事中,事后。事前一般是结合结合实时计算系统(Spark,Flink),利用CEP+规则引擎去提前感知风险事件。事中一般是直接调用风控系统的接口,返回对应的风险等级给到业务系统。事后一般是利用数仓的能力,编写HIVE脚本生成相应的风险类报表。

2.技术层面

  1. 风控系统依赖的数据源比较多,包括实时数据,离线数据,外部数据。依赖的存储介质也比较多,例如:MySQL,Redis,HBase,Hdfs等。

  2. 风控系统严重依赖规则引擎系统,规则引擎系统要能支撑其复杂的决策规则,例如:决策流或者评分卡。

  3. 风控系统内的一次调用,可能其背后会有多个数据源,甚至包括外部数据,由于外部数据RT不容易保证,所以对于风控系统而言,稳定性以及高Qps低Rt是一个不小的挑战。

3.名词解释

  1. 风控事件:可以理解为具体的业务场景,例如登录事件,注册事件等。
  2. 风控策略:一个策略由多个规则组成,策略是规则的集合。规则与规则之间可以灵活配置关系,例如:或关系,且关系。
  3. 风控规则:简单可以理解为一条表达式。规则一般由三部分组成,输入因子,条件,被比较因子,权重分,动作等。例如:IP命中薅羊毛标签,currentIp是一个因子,条件 in,被比较因子riskIpList,即:currentIp in riskIpList,如果给这个规则设置一个权重分,或者设置具体的动作,这类是比较复杂的规则,暂不展开,只说,currentIp in riskIpList这条规则。
  4. 风控因子:根据第四条可知,条件的左侧、右侧变量都可以称之为因子,因子的来源一般由两种:外部系统传入,风控系统加载而来,例如:currentIp即外部系统传入,riskIpList即风控系统内部的风险IP列表。
  5. 风控数据源:根据来源不同,可分为外部数据源,以及内部数据源。外部数据源即需要借助第三方服务,例如查询企业是否失信,可能需要企查查或者天眼查的数据,内部数据源即系统内部沉淀的各类风控数据。例如:ip画像库,设备画像库,内部离线指标,实时日志指标,用户画像库等。复杂一些的系统,对应的不单单是数据库,可能是单独的一个系统,例如用户画像可能就会作为一个系统而存在。
  6. 评分卡:评分卡聚焦了多个规则,每个规则有固定的得分,简单的评分卡是把所有规则的分值sum起来,这也是最常见的。

4.风控产品架构

5.风控技术架构

6.大厂实践

让我们看下大厂在这方面的最佳实践,这里面既包括商业产品也包括自用产品

7.技术栈

整体风控系统涉及的技术栈比较多,如果是小团队风控,那么必须是一人多专。罗列下需要到的技术栈:

  1. 数据分析洞察能力,熟练使用Hive SQL,Linux日志分析能力,对各类shell脚本命令比较熟练。
  2. 策略建模分析能力,这块目前我也不具备,一般大厂有专职角色。
  3. Apache Dubbo
  4. Kafka
  5. Flume 或者阿里云sls
  6. Hbase、Redis
  7. Hive SQL
  8. 在没有流平台的前提下,Flink Job能力,熟悉各类算子,窗口,source,sink等,可开发简单的实时任务Job。
  9. 规则引擎。非常重要,不论是自研还是开源,要改造为能适应自己业务的规则引擎,自研就是坑,除非大厂才这么玩。Drools尽量别用。
  10. 领域分析能力,设计模式,风控系统往往需要多个数据源,N多因子,N多规则,这些在代码内如何组织,必须通过领域分析能力外加一定设计模式,将风控知识包含在核心域中。最终才能呈现出的是一个清晰,干净的系统。
  11. 灰度系统,风控后期需要。如何验证一个规则或者策略是否有效,往往需要借助灰度系统对流量进行一部分copy,在预发布阶段能提前验证,得出具体的数据指标,进行评估。
  12. Flink CEP,事前风控必备。
  13. JVM,代码优化,性能优化等。
  • 5
    点赞
  • 41
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值