异常检测能够定义为“基于行动者(人或机器)的行为是否正常做出决策”,这项技术能够应用于很是多的行业中,好比金融场景中作交易检测、贷款检测;工业场景中作生产线预警;安防场景作入侵检测等等。web
根据业务要求的不一样,流计算在其中扮演着不一样的角色:既能够作在线的欺诈检测,也能够作决策后近实时的结果分析、全局预警与规则调整等。算法
本文先介绍一种准实时的异常检测系统。sql
所谓准实时,即要求延迟在100ms之内。好比一家银行要作一个实时的交易检测,判断每笔交易是不是正常交易:若是用户的用户名和密码被盗取,系统可以在盗取者发起交易的瞬间检测到风险来决定是否冻结这笔交易。缓存
这种场景对实时性的要求很是高,不然会阻碍用户正常交易,因此叫作准实时系统。服务器
因为行动者可能会根据系统的结果进行调整,因此规则也会更新,流计算和离线的处理用来研究规则是否须要更新以及规则如何更新。架构
为了解决这个问题,咱们设计以下的系统架构:机器学习
近实时的更新用户的属性,好比最近的交易时间&地点;oop
汇总统计全局的检测状态,并作同期对比,好比某条规则的拦截率忽然发生较大变化、全局经过率忽然增高或下降等等;学习
maxcompute/hadoop存储与离线分析,用于保留历史记录,并由业务人员探索性的研究有没有新的模式hbase,保存用户画像spa
3.1 在线检测系统
交易的异常检测在本系统中实现,他能够是一个web服务器,也能够是嵌入到客户端的系统。在本文中,咱们假设它是一个web服务器,其主要任务就是检阅到来的事件并反馈赞成或拒绝。
针对每个进入的事件,能够进行三个层次的检测:
均值等。
画像内容检测
针对该行动者自己的跨多条记录分析,好比该用户前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主要是为了知足实时查询的需求。
上面给出了一个准实时异常检测系统的概念性设计,业务逻辑虽然简单,但整个系统自己是很是完整且具备良好扩展性的,因此能够在这个基础上进一步去完善。