关于后端:0-0-0-0

摘要：本文整顿自京东风控数据产品组架构师周文跃，在 FFA 实时风控专场的分享。本篇内容次要分为六个局部：

1. 京东物流业务介绍
2. 物流风控场景概括
3. 物流风控平台建设
4. Flink 赋能
5. 技术挑战
6. 将来布局

点击查看直播回放和演讲 PPT

一、京东物流业务介绍

京东团体在 2007 年开始自建物流，是国内当先的以技术驱动的供应链解决方案及物流供应商，一体化的供应链物流是咱们的外围赛道。

二、物流风控场景概括

京东物流风控场景次要概括为两种，一种是货品平安，如货物失落、破损等。另一种是交易危险，次要包含财务收入的一些风控场景。这两种场景次要体现在销售、仓储、运力、计重和终端。最初的防损风控属于预先风控，任何有防损诉求的风控都会被归纳到防损风控中。

其中销售风控的主体是商家。从准入、经营、财务、理赔各个环节进行危险管控。为了解决长期以来受不良客户扰乱市场的困扰，咱们整合外部资源，通过危险商家模型和企业、法人常识图谱的搭建，对危险行为进行精准辨认、剖析、预警及处理。

仓储风控的主体是 sku。从繁多人工举报发现渠道，减少了利用数据发现渠道，裁减了发现危险线索的范畴，继续输入危险线索，反对经营人员日常发现危险，及时核查并躲避危险。

运力风控的主体是车辆。通过事先供应商招采，事中经营结算，事后防损稽核的形式，将曾经完结的工作中可能存在的危险进行辨认，及时扣减不合理的费用，升高公司的损失。

计重风控次要是指运单称重量方。通过预约的规定，针对特定的运单从新进行称重量方。这么做是为了防止某些主观上的偷重漏重，或者因为作业标准、设施等问题导致的支出损失。

终端风控防控的对象是人。通过预测画像优化业务流程，从下单到配送针对性的进行危险躲避。

防损风控是利用大数据分析、算法策略构建的大量损耗模型，并通过考察预审、案件平台等业务零碎辨认出应收、丢损、异样等危险信息造成案件。督导防损考察人员及时考察处理。

三、物流风控平台建设

整个风控技术架构次要蕴含起源层、采集层、解决层、存储层、应用层。数据来源于业务数据、财务数据、物联网数据、内部数据。通过批、流、数据导入的形式，通过数据挖掘、机器学习、搜索引擎、算法服务，最终对外提供服务，服务包含数据服务、特色服务、标签服务、画像服务。

在进行具体的风控平台搭建之前，咱们先理解一下风控的定义。危险管制存在四个根本办法，危险回避、损失管制、危险转移、危险保留。

京东物流次要集中在损失管制上，蕴含事先、事中、预先三个方面。

• 事先：预防性风控，通过内部数据、历史法则、算法预测来开掘呈现危险的概率，并依照预约的预防措施和保护性措施，升高损失的概率。
• 事中：阻断性风控，次要是在流程进行中，零碎依据相干规定监控，在呈现理论损失前启动拦挡流程，升高损失的金额。
• 预先：处理性风控，次要围绕危险处理及复盘来做的，属于挽损性质。

理解了风控的定义，咱们再来分享一下平台的建设思路。

• 第一，中台服务，对外提供能力，尽量不间接操作生产流程。过多的嵌入到生产流程，会影响到生产的效率。
• 第二，风控平台接管各方数据源，对各场景进行危险辨认、打标并落库，建设危险库。风控模型的搭建是一个长期的一直迭代优化的过程。
• 第三，风控平台提供可配置的风控辨认能力，用户能够本人抉择危险辨认类型，依据本身需要配置参数。这样做是为了扩充风控模型的利用范畴，晋升投入产出比。
• 第四，风控平台提供标准化接入形式，无论音讯还是查问接口，只有满足需要，都能够接入并应用。一个成熟的平台必然是标准化的，通过接入流程化，风控平台的技术人员只需专一于模型的辨认效率晋升即可。
• 第五，风控平台尽量少的依据特定场景进行逻辑加工，不间接嵌入用户的代码。这么做也是为了扩充风控模型的利用范畴，做到以点破面。

风控数据库蕴含规定库、模型库、常识图谱，使用的数据库类型也是市面上常见的关系数据库、NoSQL 数据库、搜索引擎、图数据库等。现行的计划是 Flink 实时更新，实时模型和常识图谱，Flink SQL 或者 Hive SQL 更新离线模型，同时兼顾数据回算。

从上图能够看出实时和离线是互相独立的。左上局部是实时风控，它蕴含事中和预先风控流程，次要依据生产流动所产生的日志信息、维度接口、事后设定的规定模型，进行危险指标计算。通过危险预警将危险后果反馈给生产方，同时对接风控大盘供领导决策。

两头局部是事中风控模型，使用的技术有实时也有离线。次要流程是生产零碎被动发动是否须要风控、是否黑白名单、依据规定判断是否命中风控。如果命中，生产零碎会有相应的管控流程，会将管控的后果同步给财务零碎，财务零碎在闭环入仓造成一个循环。

最下局部是预先和事先风控流程，次要根据历史数据和过往危险判断的后果，依据一系列大数据伎俩对风控模型进行迭代优化，从数据中发现问题并造成案件，推送给考察预审、案件平台等经营零碎，同时督导防损考察人员进行防损考察。考察的后果，除了反馈给模型，还会同步给财务，从而挽回损失。

Flink 作为实时计算引擎，对接两局部数据，别离是业务数据和规定数据。规定利用将变动的规定数据通过音讯的模式流入到计算引擎中。当 Flink 接管到实时生产音讯时，通过数据荡涤、数据压缩、数据封装，和事后流入的规定信息相结合，进行危险指标计算。计算结果保留进实时模型中，并通过音讯或者接口的模式反馈给风控预警以及风控大盘。

四、Flink 赋能

咱们最开始没有事先和事中风控，属于大数据风控，危险的断定比拟滞后，重大影响到物流风控工作的推动。之后在咱们初步波及实时风控时，并没有抉择实时计算引擎，而是采取 docker+ 多线程的形式，这就使得各个场景割裂，无奈对立治理，且生产速度较慢。在数据洪峰达到时，资源利用率较低、扩容艰难；在一些重视时效的事中风控中，命中率较低。

当初物流风控各环节，大规模推动事中风控，原有架构就曾经无奈满足了。从运力事中风控开始逐渐迁往 Flink 流式计算引擎，并开始搭建风控实时中台模型，满足业务场景对高吞吐、低提早、高性能的要求，同时积极探索流批一体在风控场景下的利用。

先来简略理解一下批处理和流解决的概念，流解决是通过 SDK、Storm、Flink 等流式计算引擎对数据进行逐条解决，并将处理结果保留到数据库中。批处理则是通过 Hive、Spark 对数据进行分层，按批处理，从 ODS 到 DWS，最终输入后果对外服务。

咱们现实的计算引擎应该是对立的，对立的数据源、计算过程和服务。而 Flink 正是将来的对立计算引擎，它有着以下几个特点：

• 成熟的流批一体概念：对立的 shuffle 架构设计，并专门对序列化和内存拷贝进行了优化。
• 生态兼容：与 Hadoop yarn /Kubernetes 集成，并且反对单机模式运行。
• 性能卓越：性能卓越的批处理和流解决反对。
• 规模计算：作业可被合成成为上千的工作，散布在集群中并发执行。满足咱们对高性能、高时效的需要。

五、技术挑战

这是计重风控、终端风控相干的局部数据链路，从仓到分拣再到配送，整个数据链路长，危险规定繁多。

往年双十一大促时，单个拓扑的音讯总量达到百亿级以上，因而咱们面临诸多的挑战。

• 业务复杂性：多业务条线、多生产环节；数据源多，数据异构；数据生命周期长；数据复式波峰；业务迭代快。
• 海量数据：大促多条线数据量暴发，对集群产生了很大的压力。
• 大状态：单次增量 state 达 40G，顶峰是更是达到 100G 以上。
• 高实时性：终端风控场景要求时效管制在 3 秒内（蕴含上下游网络差别）
• 数据歪斜：数据源上数据分布不平均。
• 存储压力：存储无奈抗住 Flink 的写入 QPS。

咱们最先开始的是业务上的优化，对于数据歪斜问题，咱们采纳了感兴趣列过滤，缩小进入拓扑的数据数量，次要依附 kafka 以后变更的值来进行数据过滤。反压监控，优化逻辑或减少资源。依据业务具体条件，变更 keyby 字段。

对于高实时性的问题，咱们采取变更数据源、缩小路径链路、前置计算、增加缓存、剥离外围和非核心业务。缩小数据链路的同时，尽可能升高拓扑的大小。

对于存储的问题，咱们进行压缩合并，升高写入频率。将计算写入拆散，防止因为存储问题影响集群的失常运行。

因为每一个拓扑的数据量、计算逻辑都不雷同，所以每个配置也不尽相同。要进行正当的配置须要理解 TM 的内存模型。从图上所知，如果是容器化部署，那么容器的内存大小就是总解决内存的大小。Flink 总内存的大小等于总解决内存减去元空间和内存超限的大小，这两块个别采纳默认值即可。

Flink 总内存蕴含堆和非堆两局部，框架堆内存和框架非堆内存也是采纳默认值就能够，无需额定配置。工作堆内存等于 Flink 总内存减去其余内存配置的大小得出，也无需独自配置。

这么算下来，咱们只需关注托管内存、工作堆外内存以及网络缓存即可。托管内存如果应用 RocksDB 状态后端，且状态数据量较大或读写较频繁，倡议适当减少托管内存的大小。配置太小对集群性能的影响是十分微小的，能够配合 RocksDB 监控来决定。

工作堆外内存个别流作业很少用到，所以能够优先保障堆内存，升高该内存的大小。网络缓存也是个别容易造成节约的中央，整个拓扑须要的网络缓存大小是由并行度以及上下游交互方式所决定，所以在拓扑启动时，就会确定一个大小，且向上浮动不大。咱们个别保留 50%~70% 来预防后续并行度减少即可，优先保障工作堆内存。

先理解下状态的写入和读取流程。写入操作先写入流动写缓存，写满当前转换为只读写缓存，再 flash 进磁盘造成 SST 索引文件。读取则是顺次从流动写缓存、只读写缓存、块缓存以及 SST 索引文件中寻找指标数据。因而咱们只需关注写缓存、块缓存以及 SST 索引文件这三局部的内存大小即可。

个别状况，这三者的配置无需变更，若作业状态特地重读或重写，能够适当进行调整，但优先保障托管内存的短缺。还有一些其余倡议调整的参数，比方启用增量状态同步、开启压缩清理、调整状态异步的线程数量，这个个别与容器的 CPU 个数保持一致即可。

状态预约配置有四种，默认、机械磁盘、机械磁盘 + 内存、SSD。如果单个槽的状态量达到 GB 级别，且托管内存富余的状况下，设置为机械磁盘 + 内存的性能是最佳的，其余状况设置为机械磁盘即可。

还有一些其余优化，代码层面，应用元组、复用对象、数据去重、异步调用等等。

部署层面上，并行度优化、链合并、拓扑分拆、计算和写入拆散、采纳 child-first 的类加载机制防止版本抵触等等。

六、将来布局

目前流批一体在风控场景上的利用还是比拟单薄的，旧版本的降级也是将来布局中比拟重要的一环。危险库的建设还处于横蛮倒退中，其中的标准制订也是火烧眉毛的事件。

点击查看直播回放和演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc