设计一个高效的欺诈侦测体系架构，其实和设计一个人脑差不多。（当然你还需要Sparkstreaming 和 Apache Kafka的帮助）欺诈侦测的目标是在事件流中监测人们是不是表现出了他们”应该的”的行为方式，或者说是捕捉他们的异常行为。诸如信用卡欺诈侦测、医生控制病人对处方药物依赖、鉴别在线游戏中的作弊行为等应用都反应了这个目标。

在了解怎样设计高效的欺诈侦测体系架构之前，我们先要搞清楚自己的大脑是怎样识别异常行为并对它们做出反应的。结论是我们的大脑使用多个系统对信息进行分析和处理。

想象在一场网球比赛中，选手必须对来球进行推测并采取合适的回击手段。在比赛进行时，选手必须在很短的时间内完成推测和回击，由于没有任何思考时间，他们所做出的回击都是基于对来球本能的、迅速的模式侦测。在两局比赛间隙，选手可能会有几分钟回顾刚才的比赛，弄清楚对手使用的战术和策略，从而做出有效的调整。在比赛结束后，选手对比赛的反思会持续很长一段时间，他们可能会注意到比赛中自己发挥不好的方面进而对其进行改进。当下场比赛来临时，他就能表现得更好。（需要注意的是这种反思可能是有意识的，也可能是无意识的。我们都有曾对一个问题绞尽脑汁，但答案往往在早上洗澡的时候自己跳了出来的经历。）

系统集成

同样的，高效欺诈侦测系统架构模仿了人脑的运作方式，使用三个子系统协同工作来侦测事件流中的异常行为。

实时系统：

该子系统的工作就是以最快的速度接收事件并做出应答，这个过程通常在100毫秒内完成。它负责很少的计算处理工作，而且基本都是基于模式匹配和对既定规则的应用。实时系统的核心是如何在低延时的要求下尽可能地扩大吞吐量，本地缓存用户属性文件是一个不错的选择。

流式处理系统：

该系统可以对数据做稍微长时间的处理，但还是应该将应答时间控制到几秒钟到几分钟之间。流失处理系统的作用是调整实时系统中欺诈侦测模型的参数，依据来源于对所用用户行为的聚合操作。（比如被标记公司和地区的行为就更值得怀疑）

离线处理系统：

该系统可以运行时间延迟在几个小时到几个月之间的任务，旨在改进欺诈模型本身。改进过程包括用新的数据训练模型，发掘新数据的特征，开发新的模型等。同时还需要数据分析人员使用BI工具来对数据分析挖掘工作。

在此前的博客中，我们已经讨论过实时系统的几种实现方式。基于某些原因，Cloudera推荐使用Spark Streaming来实现流式处理系统。强调一下，推荐的实时系统架构更像是一项服务，作为消息消费者它订阅了Kafka中包含需要它做出反应事件的消息队列。它使用缓存的状态和规则来对事件做出快速反应，并使用HBase作为外部存储环境。Kafka分区能够被用来分发这项服务，并保证每一实例只需要缓存一部分用户的数据。

这样做带来的好处是分发出去的应用都是独立的，可以以多种方式管理起来。比如作为Flume拦截器、YARN容器或者是Mesos、Docker、Kubernetes，当然还有很多分布式系统容器管理框架可以使用。你可以选择自己喜欢的，然后让Kafka负责数据持久化和分区工作就行。

现在，让我们看看怎么把实时系统和流式系统、离线系统整合起来。

整合实时侦测处理系统

整合的关键是使用Kafka作为可扩展的、有序的事件存储介质。当你在Kafka中注册一个信息消费者时，你可以把他指定到一个消费者组中或者单独作为一个组。如果两个消费者来自于同一个组，他们会拥有自己独立的分区子集，并只接受来自自己分区中的事件。如果组中的一个消费者进程崩溃，它的分区会被分发给组中的其他人。这样做同时保证了消费者的负载均衡和高可用性，也让数据处理应用获得了可扩展性（在负载上升时往同一个组中增加消费者就行了）。

但是我们也想多个应用读取同一份数据，比如实时系统和流式系统都需要从Kafka中读取同样的数据。在这种情况下，每一个应用会有自己的消费者组，并独立地从Kafka中接受消息。

为了使得离线系统处理批量分析作业，数据需要存储到HDFS中。使用Flume就能轻松做到这一点，只需要把Kafka作为数据源，并指定HDFS为接受点。然后Flume会读取Kafka中的事件流，然后写入到HDFS、HBase、Solr等能够被Spark、Impala、Hive和其他BI工具访问的地方。

既然每个子系统在Kafka中拥有自己的消费者组，它们就能以自己的速率来读取事件流。因此就算流式系统花了较长的时间处理数据，对实时系统也不会产生任何影响。Kafka另一个美妙之处在于它能存储一定时间内的所有事件，无论消费者的多少以及他们对数据进行何种处理，所以即便添加更多的处理系统Kafka依然有稳定的性能表现。

集成的最后一个步骤是将流式处理和批量处理对模型产生的更新传递到实时系统中。这个过程类似通过训练来加强人的本能反应。（比如为一个特定的公司调整批准交易的阈值）

一个办法是让这些系统将模型更新到HBase中，实时系统通过异步检查HBase来定期更新。更好的办法是把模型更新到Kafka的另一个消息队列中，让实时系统订阅此消息队列。一旦更新出现，它就能应用到自己的规则缓存中并调整反应行为。

另外一个有趣的设计思路是把整个模型都存储在Kafka中，因为它的精密特性不论你把原始数据存储多久都不会丢失。每一个模型的最新数据会被永久存储并被能够实时系统查询、缓存以及使用。

译作者简介：

刘磊，2011年硕士毕业于西华大学。现任明略数据软件公司大数据解决方案咨询师。任职中国银联电子支付研究院时期，负责银联大数据平台的架构设计、平台搭建、运维优化等工作。同时申请国家云计算和大数据相关专利7项，并获得上海市科技进步奖一等奖。对Hadoop生态系统中各个组件的原理和架构有较深入的研究，目前专注于大数据行业解决方案的架构设计研究工作。