使用Spark和Kafka设计类似于人脑的欺诈检测架构

首页 > 娱乐前沿 > 热点

2015-12-29 10:05:06 | 来源：玩转帮会 | 投稿：佚名 | 编辑：小柯

原标题：使用Spark和Kafka设计类似于人脑的欺诈检测架构

使用Spark和Kafka设计类似于人脑的欺诈检测架构

2015-12-25 23:29

架构师（WanZhuanBangHui）我们都是架构师！

下面是Cloudera软件工程师Gwen Shapira的博客《使用Spark和Kafka设计类似于人脑的欺诈检测架构》的译文，这篇文章深入浅出地描绘了使用Spark和Kafka来进行欺诈检测的方法。

原文链接：http://blog.cloudera.com/blog/2015/07/designing-fraud-detection-architecture-that-works-like-your-brain-does/

本文由北邮数据科学中心林澍荣王蒙常思源（2014级硕士）翻译

1即使在Spark Sreaming和Apache Kafka的帮助下，在反欺诈检测方面也没有什么架构比人类大脑更有效了

欺诈检测的核心就是检测人们的行为是否正常，如果不是，就会通过事件流来捕获这些异常的地方。欺诈检测在不同的领域都有广泛应用，比如信用卡欺诈检测、病人是否通过欺骗医生来获取处方药、或者识别在线游戏社区的恶霸等等。

为了设计一个有效的欺诈检测架构，我们需要去了解人类的大脑是如何发现异常并如何这些异常进行处理的。事实证明，我们的大脑有多个信息分析的处理系统。（如果你对人类如何处理信息感兴趣，我们推荐这本书《Thinking Fast and Slow》，丹尼尔·卡尼曼）。

现在我们考虑打网球的过程，玩家必须要迅速地发现马上到来的球，并立即做出作出反应。在这个过程中，玩家要一直以非常快的速度重复这些动作，而且没有时间去思考，玩家的反应是基于本能和快速的检测模式。在每盘之间，玩家可能有片刻的时间思考一下比赛的进程、判断一下对手使用的战术或策略，然后自己相应地做一下调整。在每局之间，玩家就会有足够的时间来找到自己在比赛中薄弱的地方，然后去提高自己以便在接下来的比赛的中有更好的表现。（要注意这种反应可能是有意识的也可能是无意识的，比如，有时我们可能会花几个小时来解决一个有挑战性的问题，但最后可能问题的解决方案是在我们早晨沐浴时突然想到的。）

2系统的连接

有效的欺诈检测架构是以一种相似的模式模拟人类大脑，它是由三个子系统一起协同工作来检测事件流的异常。

3近实时处理系统

该系统的任务是尽可能快的接收事件和做出反应，一般时延在100ms以内。该系统主要用模式匹配和预定义的规则来进行数据处理。架构的设计应侧重于用非常低的延迟尽可能达到非常高的吞吐量，为了达到这个目的，可以采取诸如在本机内存中缓存用户配置文等措施。

4流处理系统

该系统可能需要一点时间来处理输入数据，但仍应在几秒钟之内或数据到来的几分钟内将数据处理完毕。本系统的目标是使用所有的用户的活动聚集数据（例如，标记的可疑的厂商或区域中）来调整近实时欺诈检测模型的参数。

5线下处理系统

该系统能够连续运行几个月的时间，并且提高模型的准确度。这一过程包括用新的数据训练模型、探索数据的新功能、开发新的模型等。此外，数据分析和研究人员应当会使用BI工具来处理这些数据。

在以前的一篇博客文章中，我们探讨了第一种系统类型“近实时”的不同实现模式，并列出了Cloudera推荐在流处理系统中使用Spark Streaming的一些原因。总的来说，被推荐作为实时反应系统架构的是这样一种服务，它作为一个consumer订阅了Apache Kafka的一个topic，topic中存放着反应所需的事件。服务使用缓存状态和规则来快速地对这些事件做出反应，并使用Apache HBase作为一个外部上下文。Kafka分区可用于分发服务，并确保每个实例只需要缓存一个用户子集的信息。

该设计的美妙之处在于，这个分布式应用是独立的，并可以通过很多方式进行管理，它可以作为一个Apache Flume过滤器，YARN 的一个Container，或是Mesos、Docker、Kubernetes等许多其他分布式系统Container框架的一个Container。因为kafka会做数据持久化和分区的工作，所以你可以选择任何你所喜欢的框架。

现在，让我们来看看如何把系统中的实时模块跟流处理模块、离线处理模块结合起来。

6集成实时检测与处理

集成的关键是使用kafka作为一个可扩展的、有序的事件存储容器。当在kafka了注册一个或多个consumer，您可以将这些consumer注册为同一个consumer group，也可以注册为不同的consumer group。如果两个consumer被注册为同一个group，并从同一个topic中读取事件，它们将在group中各自“拥有”topic分区的一个子集，并且每一个consumer将只获取它所拥有的分区中的事件。如果group中的一个consumer挂掉，它所拥有的分区将被分发给相同group中的其他consumer。这种方法提供了一种机制，同时实现了负载均衡和consumer的高可用性，它使得每个数据处理应用都是可扩展的（通过随着负载的增加而增加在同一个group中的consumer数目来实现扩展）。

但是，我们也希望多个应用读取相同数据；实时应用和流处理应用都需要从Kafka读取相同的数据。在这种情况下，每个应用将对应自己的一个consumer group，并能够独立地按照自己的速度从Kafka中消费消息。

为了使批处理作业和分析师们的离线处理能够进行，数据需要被存储在HDFS中。您可以通过Flume很方便实现这一点；仅仅需要定义Kafka为channel，HDFS为sink。在此设置中，Flume将从Kafka读取事件，并将它们写入到HDFS、HBase或者Apache Solr等可以被Apache Spark、Impala、Apache Hive、和其他的BI工具访问到的地方。

请注意，因为每个系统在Kafka中被注册为它自己的consumer group，所以它们可以各自以自己的速度独立地读取事件。因此，如果流处理系统正使用更长的时间来处理事件，实时系统其实是不会受其影响的。Kafka的一个精妙之处在于它不管有多少个consumer存在，也不管consumer在做什么，它只存储一个固定时间段里的事件，因此Kafka将在你添加更多的处理系统之后也保持相同的行为。

集成的最后一部分是拥有将规则和模型的更新从流处理和离线处理系统中发送回实时系统的能力。这个过程和以实践为基础改进人类本能的过程是等价的（例如，改变与一个特定供应商的交易额上限）。

一种方法是使这些系统更新在HBase中的模型，并且让实时系统不定期、异步地检查HBase以获取更新。更好的选择是将模型的更新发送到另一个Kafka topic：我们的实时应用将订阅这个topic，并当有更新出现时，它将会把它们应用到它自己的规则缓存中，并相应地修改它的行为。

这里还有一个有趣的设计选择是将模型完全存储在Kafka中，因为其compaction的特性可以确保不管你在kafka中的原始数据要保存多久，每个模型的最新编号将会被永久保存，并总是可以通过实时应用检索到并缓存起来。

7结论

我们希望这篇文章为读者阐明了一个非常具有挑战性的课题。想了解实践性的指导，请进一步阅读我们的文章《fraud-detection tutorial at Strata – Hadoop World NYC 2015》。

Gwen Shapira是Cloudera的一位软件工程师，她也是Apache Sqoop和Apache kafka项目的一名贡献者。她在与客户一起工作、设计可扩展的数据架构方面拥有15年的经验，同时她还是O’Reilly出版的《Hadoop Application Architectures》一书的合著者。 Ted Malaska是Cloudera的一位解决方案架构师，Spark、Flume、Hbase项目的一名贡献者，同时还是《Hadoop Application Architectures》一书的合著者。

来源：公众号北邮数据科学中心

原文：http://mp.weixin.qq.com/s?__biz=MzA3NDc1NDI3MQ==&mid=402234279&idx=1&sn=8db549fbd2792ee9957ad13d6a5ff661&3rd=MzA3MDU4NTYzMw==&scene=6#rd

转载文章，向原作者致敬！如有侵权或不周之处，敬请劳烦联系若飞（微信：1321113940）马上删除，谢谢！

·END·

架构师

tags：

相关：

阿里分布式数据库服务实践

阿里分布式数据库服务实践2015-12-27 18:41 架构师（WanZhuanBangHui）我们都是架构师！沈询: 阿里巴巴资深

美团生活服务个性化推荐实践

美团生活服务个性化推荐实践张彬·2015-12-26 17:57 架构师（WanZhuanBangHui）我们都是架构师！张彬

实时股票分析系统的架构与算法