大数据反欺诈技术架构

一年多之前，有朋友让我聊一下大家的大数据反欺诈架构是怎么实现的，以及咱们途中踩了哪些坑，怎么作到从30min延迟优化到1s内完成实时反欺诈。当时呢第一是以为不合适，第二也是以为场景比较局限没什么分享的必要性。

时间也过了好久了，最近看到圈里一些东西，发现当时的这套架构并未落伍，依然具备很大的参考价值，因此今天跟大伙聊聊关于大数据反欺诈体系怎么搭建，主要来源是来自于我工做的时候的实践，以及跟行业里的不少大佬交流的实践，算是集小成的一个比较好的实践。

这套架构我作的时候主要领域是信贷行业的大数据反欺诈，后来也看过电商的架构，也看过金融大数据的架构，发现其实你们使用的其实也差很少是这个套路，只是在各个环节都有不一样的细节。

大佬说的，能用图的，尽可能不要打字，那我就打少点字，多作点图。其实大数据不外乎这么几个步骤。数据源开拓、数据抽取、数据存储、数据清洗和处理、数据应用，且听我一个一个说。

数据源

数据源是一个比较重要的点，毕竟若是连数据源都是垃圾，那么毫无疑问能够预见，最终产出的必定是垃圾，因此挑选数据源和对接数据源的时候都要关注，该机构产出的数据是否是都是质量比较高的数据。

好比人行征信数据就是一个质量很是很是高的数据，主要涉及信用卡、银行流水、老赖、失信、强制执行信息等，都很是核心，任何一个点均可能是一笔坏帐的苗头。以及各类行政机构提供的付费机密数据。

好比运营商通信数据、好比大型电商的行为数据、好比各类保险数据，以及各个机构贷款记录的互相沟通，这些数据源，都很是核心也都很是值钱，是如今反欺诈很是核心的数据。

固然也有更加粗暴更加高效的作法，就是直接购买外部的黑名单数据，这让反欺诈变得更加简单，遇到就直接拒，能够减小很是的人力物力成本去作其余的核查。

数据抽取

有了高质量的数据源后，固然就是怎么抽取的问题了，各个机构所提供的数据格式是多种多样的，其中包括 http 接口的json、xml，内部其余数据源的 etl、定时人工上报的 Excel，以及 sqoop+ozzie 这两个直接数据抽取通道，这个过程只须要保证通道稳定，数据服务幂等便可，没什么特殊的地方。

数据存储

数据存储其实就是创建一个数据仓库和一个实时仓库，数据仓库用于存储来自各大数据源的原始数据，实时仓库用于业务系统的核心做业，数据仓库的数据量通常都以 T 为单位，实时仓库以 M 和 G 为单位。

离线计算&实时计算

数据保证了，那么计算就是这套架构的核心之处，从大的角度来看能够分红离线计算和实时计算。

离线计算主要会作两件事情。Hive 、Spark 数据整合与清洗和离线数据建模。Hive 数据整合主要作的事情就是把各个数据库里面的东西，进行清洗和过滤，最终写到咱们定义的标准表里边，提供给下游的计算使用。若是是很是复杂的数据清洗，咱们会使用 Spark 写程序来作，毕竟有一些操做不是 Hive 这种标准 SQL 能解决的。离线数据建模，就是对于这批数据进行建模，以便后续用于实时计算和应用中，算法嘛，精通两个基本就稳了，LogisticRegression & 决策树，不要问我为何。

实时计算又会作些什么事情？SparkStreaming和Flink用于实时流计算，主要是用于一些统计类的事情，以及多个数据流的 join 操做。在这里咱们但愿作到什么事情呢？就是但愿服务能够准实时，什么叫准实时呢？就是在一个能够接受的范围内，我容许你有必定的延迟，这块咱们一开始的任务延迟是 30 min。

咱们踩过哪些坑呢？

一开始咱们但愿使用流批次计算来实现实时计算，实践下来准实时跟实时仍是区别很大的，一个业务一般是容许不了分钟级别的延迟的，然而 Spark 的 GraphX 必然有分钟级别的延迟，只适合离线计算。

Hive + Ozzie 处理离线批量处理是一个很是大的利器，不少人都觉得Hive数据清洗不就写写几行 SQL？几百张乃至几千张表背后的复杂的数据清洗规则，任务依赖，任务重跑，数据质量，数据血缘关系维护。相信我，要是没有细心和工具，这些能把你搞崩溃。

ElasticSearch 集群多个机器的负载吞吐量，比单台机器高性能的要高，毕竟网络卡在那。

咱们趟了不少的坑，摸了不少的时候，最终决定把全部的实时操做都架构在 ElasticSearch 和 Neo4j 上，由于咱们不只仅须要实时的全文本全字段社交关系生成，更是须要实时搜索多维度多层社交关系并反欺诈分析，而这个关系多是百万级别的，根据六度理论，决定了咱们选取的层次不能太多，因此最终咱们只抽取其中三层社交关系。最终肯定这个架构，这很核心地肯定了咱们的响应时间，并最终决定了咱们服务的可用性。

不少地方产生的结果数据只是整个决策链上的一个细节，因此咱们还须要 Drools 这类规则引擎帮助作一个最终决策。

业务应用

最终业务系统应该怎么使用，怎么对外提供服务？这也是一个很是核心的问题，由于这部分要求很是很是稳定，以及很是很是高效，通常来讲不容许有过高的延迟，同时还要求很是高的并发量。这就要求了咱们第一要尽可能提升计算效率，第二要求咱们对于系统的架构要有很是高的保障。

计算效率要高效，有什么技巧呢，保证各个系统之间的交互都是聚合、加工、计算后的结果，而不是原始数据，毕竟网络传输是须要很高成本的在目标数据量很是大的场景下。好比一次性要加载几十万条数据，那所有拉回来再从新计算是否是就显得很蠢了？为何不在目标系统里以数据服务的形式提供呢？

技术架构保障，其实大部分都是基础架构的事情了，好比动态负载均衡、一主多从、异地多机房容灾、断网演练、上游服务故障预案等等。

建模之社交网络

好久之前就已经介绍了各类社区发现算法，这里就再也不赘述，有兴趣的本身点进去细致了解一下。

这里聊聊一个知识图谱的标准创建过程。

一、主体确认

二、关系创建。

三、逻辑推理创建。

四、图谱检索

主体确认，从图的角度来看就是确认各个顶点，这些顶点有本身的属性，表明着网络里的一个个个体。

关系创建，从其余资料关系得来，也能够根据第三步的逻辑推理得来，从图的角度来看就是确认各个边，这些边有起点有终点也有本身的属性，表明着网络里各个个体的关联。

逻辑推理创建，这是很是重要的一个部分，好比姚明的老婆的母亲，就是姚明的岳母，这种先验知识的推理能够在图谱的帮助下，为咱们解决不少的实际问题。

图谱检索，有了图谱咱们就开始使用，咱们有四件套，主体属性搜索，关系属性搜索，广度优先搜索，宽度优先搜索。咱们通常的使用策略都是，优先肯定一个顶点好比目标人物，而后向外扩散，直到找到全部符合条件的个体。

这里咱们踩了什么坑作了什么优化呢？咱们一开始是把整个搜索结果拉到本地再进行计算，而图谱搜索后的结果老是很大，毕竟咱们找了不少维的关系，因此老是卡在网络这块。通过探索和咨询，最终确认了 Neo4j 这种图数据库不只仅提供数据查询服务，还作了基于定制化的社交网络分析的插件化开发，把咱们的反欺诈服务以插件化的形式部署到服务器中，这就减小了很是多的网络开销，保障了咱们服务的秒级响应。

完整架构图

从数据来源、获取、存储、加工、应用，一步到位，万一有点帮助那就更好了，若是还心存疑虑，这篇文章从下往上，再看一遍。

欢迎学Java和大数据的朋友们加入java架构交流： 855835163

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！