以实时风控场景为例，阿里云实时计算如何来作异常检测？

内容来源：本文内容由阿里云实时计算，流计算团队提供。IT 大咖说（微信id：itdakashuo）做为独家合做方，经受权发布。

阅读字数：3102 | 8分钟阅读

前言

DT时代，数据是最重要的生产资料。互联网的发展让人们时刻在线，产生着数据，数据在线了，处理天然也应该在线，但传统的离线大数据处理方式面对这一业务需求愈来愈力不从心。因而流计算技术应运而生，以其亚秒级延迟的处理能力迅速解决了大数据实时化的问题，在各个业务场景大放异彩：从实时ETL到实时数据仓库的构建，从实时营销到实时推荐，从互联网到IoT，实时的处理能力渐渐成了大数据系统的标配。

目前实时计算擅长解决的几个领域的应用场景：

• 实时BI：实时的网络点击PV、UV统计。

• 城市交通：统计交通卡口的平均5分钟经过车流量。

• 工业大脑：水利大坝的压力数据统计和展示。

• 实时风控：网络支付涉及金融盗窃固定行为规则的告警。

• 实时推荐：实时提取特征变量，及时跟踪用户关注品类，预测用户消费趋势。

以“实时风控”的场景为例，咱们具体谈谈，阿里云实时计算如何来作异常检测的。

1.背景介绍

异常检测能够定义为“基于行动者（人或机器）的行为是否正常做出决策”，这项技术能够应用于很是多的行业中，好比金融场景中作交易检测、贷款检测；工业场景中作生产线预警；安防场景作入侵检测等等。

根据业务要求的不一样，流计算在其中扮演着不一样的角色：既能够作在线的欺诈检测，也能够作决策后近实时的结果分析、全局预警与规则调整等。

本文先介绍一种准实时的异常检测系统。所谓准实时，即要求延迟在100ms之内。

好比一家银行要作一个实时的交易检测，判断每笔交易是不是正常交易：若是用户的用户名和密码被盗取，系统可以在盗取者发起交易的瞬间检测到风险来决定是否冻结这笔交易。这种场景对实时性的要求很是高，不然会阻碍用户正常交易，因此叫作准实时系统。

因为行动者可能会根据系统的结果进行调整，因此规则也会更新，流计算和离线的处理用来研究规则是否须要更新以及规则如何更新。

2.系统架构与模块综述

为了解决这个问题，咱们设计以下的系统架构：

在线系统，完成在线检测功能，能够是web服务的形式：

• 针对单条事件进行检测

• 根据全局上下文进行检测，好比全局黑名单

• 根据用户画像或近期一段时间的信息进行检测，好比最近20次交易时间与地点

kafka，把事件与检测的结果及其缘由发送到下游。

blink近实时处理：

• 汇总统计全局的检测状态，并作同期对比，好比某条规则的拦截率忽然发生较大变化、全局经过率忽然增高或下降等等；

• 近实时的更新用户的属性，好比最近的交易时间&地点；

maxcompute/hadoop存储与离线分析，用于保留历史记录，并由业务&开发人员探索性的研究有没有新的模式。

hbase，保存用户画像。

3.关键模块

3.1 在线检测系统

交易的异常检测在本系统中实现，他能够是一个web服务器，也能够是嵌入到客户端的系统。在本文中，咱们假设它是一个web服务器，其主要任务就是检阅到来的事件并反馈赞成或拒绝。

针对每个进入的事件，能够进行三个层次的检测：

• 事件级检测

只用该事件自己就能完成检测，好比格式判断或基本规则验证（a属性必须大于10小于30，b属性不能为空等等）

• 全局上下文检测

在全局信息中的上下文中，好比存在一个全局的黑名单，判断该用户是否在黑名单中。或者某属性大于或小雨全局的平均值等。

• 画像内容检测

针对该行动者自己的跨多条记录分析，好比该用户前100次交易都发生在杭州，而本次交易发生在北京且距上次交易只有10分钟，那就有理由发出异常信号。

因此这个系统至少要保存三方面的东西，一方面是整个检测的过程，一方面是进行判断的规则，一方面是所需的全局数据，除此以外，根据须要决定是否把用户画像在本地作缓存。

3.2 kafka

kafka主要用来把检测的事件、检测的结果、拒绝或经过的缘由等数据发送到下游，供流计算和离线计算进行处理。

3.3 实时计算Flink近实时处理

在上面的系统中已经完成了异常检测，并把决策发送到了kafka，接下来咱们须要使用这些数据针对当前的策略进行新一轮的防护性检测。

即便已知的做弊行为已经输入到模型和规则库中进行了标记，但总有“聪明人”尝试欺诈。他们会学习如今的系统，猜想规则并做出调整，这些新的行为极可能超出了咱们当前的理解。因此咱们须要一种系统来检测总体系统的异常，发现新的规则。

也就说，咱们的目标不是检测单个事件是否有问题，而是要检测这些用来检测事件的逻辑自己有没有问题，因此必定要站在比事件更高的层面来看问题，若是在更高的层面发生变化，那么有理由考虑对规则/逻辑进行调整。

具体来讲，系统应该关注一些宏观指标，好比总量，平均值，某个群体的行为等等。这些指标发生了变化每每表示某些规则已经失效。

举几个例子：

• 某条规则以前的拦截率是20%，忽然下降到了5%；

• 某天规则上线后，大量的正经常使用户均被拦截掉了；

• 某我的在电子产品上的花费忽然增加了100倍，但同时其余人也有不少相似的行为，这可能具备某种说得通的解释（好比Iphone上市）；

• 某人连续几回行为，单次都正常，但不该该有这么屡次，好比一天内连续买了100次同一产品【开窗分析】；

• 识别某种组合多条正常行为的组合，这种组合是异常的，好比用户买菜刀是正常的，买车票是正常的，买绳子也是正常的，去加油站加油也是正常的，但短期内同时作这些事情就不是正常的。经过全局分析可以发现这种行为的模式。

业务人员根据流计算产生的近实时结果可以及时发现规则有没有问题，进而对规则做出调整。除此以外，流计算还能进行用户画像的实时更新更新，好比统计用户过去10分钟的几回行为，最近10次的登录地点等等。

3.4 maxcompute/hadoop离线存储于探索性分析

在这个环节中，能够经过脚本、sql、或机器学习算法来进行探索性分析，发现新的模型，好比经过聚类算法把用户进行聚类、对行为打标后进行模型的训练等等，或者周期性的从新计算用户画像。这里和业务关系很大，很少过多描述。

3.5 hbase用户画像

hbase保存着流计算&离线计算产生的用户画像，供检测系统使用。之因此选择hbase主要是为了知足实时查询的需求。

4.总结

上面给出了一个准实时异常检测系统的概念性设计，业务逻辑虽然简单，但整个系统自己是很是完整且具备良好扩展性的，因此能够在这个基础上进一步去完善。

后面我会再介绍近实时的异常检测系统，即实时性要求不那么高，要求在秒级的异常检测系统，在近实时异常检测系统中，流计算会发挥更大的做用。