案例与解决方案汇总页：
阿里云实时计算产品案例&解决方案汇总
本文为您介绍利用实时计算设计准实时（延迟在100ms以内）异常检测系统。
背景介绍
比如一家银行要做一个实时的交易检测，判断每笔交易是否是正常交易：如果用户的用户名和密码被盗取，系统能够在盗取者发起交易的瞬间检测到风险来决定是否冻结这笔交易。这种场景对实时性的要求非常高，否则会阻碍用户正常交易，所以叫做准实时系统。
由于行动者可能会根据系统的结果进行调整，所以规则也会更新，实时计算和离线的处理用来研究规则是否需要更新以及规则如何更新。
准实时异常检测系统架构与模块综述
- 在线系统：完成在线检测功能，可以是Web服务的形式：
- 针对单条事件进行检测。
- 根据全局上下文进行检测，比如全局黑名单。
- 根据用户画像或近期一段时间的信息进行检测，比如最近20次交易时间与地点。
- Kafka：把事件与检测的结果及其原因发送到下游。
- 实时计算近实时处理
- 汇总统计全局的检测状态，并做同期对比，比如某条规则的拦截率突然发生较大变化、全局通过率突然增高或降低等等。
- 近实时的更新用户的属性，比如最近的交易时间和地点。
- Maxcompute/Hadoop存储与离线分析：用于保留历史记录，并由业务&开发人员探索性的研究有没有新的模式。
- HBase：保存用户画像。
关键模板
- 在线检测系统
以Web服务器为例，它的主要任务就是检阅到来的事件并反馈同意或拒绝。
针对每一个进入的事件，可以进行三个层次的检测：
- 事件级检测
只用该事件本身就能完成检测，比如格式判断或基本规则验证（a属性必须大于10小于30，b属性不能为空等等）。
- 全局上下文检测
在全局信息中的上下文中，比如存在一个全局的黑名单，判断该用户是否在黑名单中。或者某属性大于或小雨全局的平均值等。
- 画像内容检测
针对该行动者本身的跨多条记录分析，比如该用户前100次交易都发生在杭州，而本次交易发生在北京且距上次交易只有10分钟，那就有理由发出异常信号。
所以这个系统至少要保存三方面的信息，
- 整个检测的过程
- 进行判断的规则
- 所需的全局数据
除此之外，根据需要决定是否把用户画像在本地做缓存。
- 事件级检测
- Kafka
Kafka主要用来把检测的事件、检测的结果、拒绝或通过的原因等数据发送到下游，供实时计算和离线计算进行处理。
- 实时计算近实时处理
使用Kafka处理后的数据针对当前的策略进行新一轮的防御性检测。
系统应该关注一些宏观指标，比如总量，平均值，某个群体的行为等等。这些指标发生了变化往往表示某些规则已经失效。
举例如下：
- 某条规则之前的拦截率是20%，突然降低到了5%；
- 某天规则上线后，大量的正常用户均被拦截掉了；
- 某个人在电子产品上的花费突然增长了100倍，但同时其他人也有很多类似的行为，这可能具有某种说得通的解释（比如iphone上市）；
- 某人连续几次行为，单次都正常，但不应该有这么多次，比如一天内连续买了100次同一产品；
- 识别某种组合多条正常行为的组合，这种组合是异常的，比如用户买菜刀是正常的，买车票是正常的，买绳子也是正常的，去加油站加油也是正常的，但短时间内同时做这些事情就不是正常的。通过全局分析能够发现这种行为的模式。
业务人员根据实时计算产生的近实时结果能够及时发现规则有没有问题，进而对规则作出调整。
- Maxcompute/Hadoop离线存储于探索性分析
通过脚本、SQL或机器学习算法来进行探索性分析，发现新的模型，比如通过聚类算法把用户进行聚类、对行为打标后进行模型的训练等等。
- HBase用户画像
HBase保存着实时计算&离线计算产生的用户画像，供检测系统使用。之所以选择HBase主要是为了满足实时查询的需求。
总结
上面给出了一个准实时异常检测系统的概念性设计，业务逻辑虽然简单，但整个系统本身是非常完整且具有良好扩展性的，您可以在这个基础上进一步去完善。
