京东实时风险洞察的架构演迸与思考
导读 今天分享的主题是实时风险洞察的架构演进与思考。
全文目录：
1. 实时风险洞察面临的挑战2. 实时风险洞察的架构演进3. 未来的思考与展望4. Q&A
分享嘉宾｜孟祥涛 京东科技 架构师
编辑整理｜洪佳胤 北银消费金融有限公司
文字校对｜李瑶
出品社区｜DataFun
01
实时风险洞察面临的挑战
首先，第一部分介绍实时风险洞察面临的挑战。
风险管理的过程分为四个阶段，第一个阶段是风险识别，需要用决策引擎去做前置化处理；第二阶段是风险分析，需要分析要上线哪些策略、策略的阈值是什么；第三阶段是风险监控，分析线上真实的业务有哪些方向是有风险的，针对这些方向去配置一些预警；最后是风险预警之后的处置方式，一般分为两方面，一是在识别过程中的处置，二是在风险监控后的处置。
今天的主题主要是风险分析和风险监控的实时化，促进业务在实时方向的发展。目前面临的问题有三个。一是数据孤岛，风险其实要用到很多的数据，比如交易、营销、订单、注册、登录、实名等，但数据又在各自的系统里存放，如果分析师想用的话，就需要先聚合加工。第二个问题是海量的数据，如果需要实时处理海量数据，提升分析效率是一个挑战。第三是实时地挖掘数据价值，辅助业务做更好的决策。
基于前面的想法，京东在设计这个系统的过程中也面临了一些挑战。
第一个挑战是数据源非常多，不同业务的数据格式通用性非常差，需要考虑如何设计通用的方式去解决这个问题。
第二是海量数据场景下的实时性与性能保证。首先是要保证实时预警的稳定和准确；其次，实时分析、多维分析的 OLAP如何实现；再者，面临大促时百万级乃至几百万级的TPS，如何保证能够入库，并准确地预警和分析；最后是用什么存储，资源成本如何考量。
第三是在做常规的分析预警时，一般是策略专家配置阈值，这就会面临以下问题：
①风险场景非常多，枚举成本非常高，但专家阈值是完全基于专家经验的；
②分析效率很低，预警触发后如何研判风险；
③预警治理和优化；
④实时对抗性。因为风控一直是在和黑产进行对抗的，仅靠专家经验很难增加对抗的实时性。
所以，我们希望用智能算法赋能。
第四是如何构建通用的风险架构，提升通用性、扩展性和高性能。这里也会面临一系列问题，比如组件化方面设计多少组件合适，通用的扩展性在哪些方向需要扩展，如何做扩展，如何保证性能和稳定，包括后台可能涉及到的分析和预警的查询性能，以及前端页面的渲染性能等等。
京东设计这个平台的目标是提供一个监控与智能分析的产品。首先，它能够提供快速的接入数据、助力业务能够构建全面的风险监控运营体系。再者，我们提供异常检测算法和自动感知业务，能够自动感知业务的指标波动异常，并能够通过归因算法快速定位异常波动的原因。
02
实时风险的架构演进
接下来介绍一下系统架构的演进过程。主要有以下三个原则。
一是合适原则，一切不按实际场景出发的架构设计都是耍流氓。任何架构的发展一定要匹配当前所处的阶段，要充分考虑结合业务实际的应用场景，并且要考虑一到两年的发展规模。不能是前期用大炮去打苍蝇，虽然架构设计得非常好，但设计搭建的周期非常长，也没法满足业务快速发展的需要。
二是简单原则。大道至简，用简单的方案去解决复杂的问题。将复杂的逻辑单元拆分成多个单一的执行单元；控制单元边界，能够控制最小的执行单元粒度；不做过度的设计。
三是演化原则。优秀的架构一定是演化来的，而不是设计来的。我们在架构的迭代过程中会明显地发现这一点。代码的可扩展性和设计模式是如何使用的？架构的可扩展性以及我们如何在不断地实践过程中迭代这些系统？
基于平台目标，如何去拆解要实现的内容？
第一是技术选型。需要满足Ad Hoc即席查询的能力，用什么OLAP引擎，实时计算是用什么处理，以及效率、成本和质量如何考量。
第二是数据标准化。针对前文的第一个挑战——数据多、杂、不标准，如何用低代码的方式去实现高扩展、高并发、高性能的数据处理组件。
第三是智能分析，可以类比为实时BI。低代码与拖拉拽时最基础的能力，更进一步要考虑，前端组件要如何设计以及如何去扩展。
第四是智能预警。如何保证它的准确、及时和稳定。
第五是算法模型。主要考虑异常检测和归因分析，如何通过较小的投入实现较高的回报。
其实，我们最原始的架构为了满足当时业务的快速发展，做的简单、灵活有余，但扩展性不足。它简单分为四层，数据接入（即底层存储）后，直接选了 ES 集群，往上是指标、调度、看板以及决策明细；最上面对应了风险分析和风险监控预警。
它面临的第一个问题是通用性与扩展性不够，数据处理和数据加工过程基本上都需要硬编码；第二个是计算与存储架构单一，强依赖ES集群，面临比较严峻的性能问题：ES 的性能是有瓶颈的，尤其一开始还是用机械版的ES，性能就更差了，虽然后来升级成 SSD 的ES，但是性能也没办法和主流的ClickHouse 这种单表查询特别快的引擎相比。所以就有了架构2.0 的演化。
其实，2.0 架构的主要目标是实现平台化、组件化和插件化。整体的逻辑分层分为四层，最下面是数据层，可以理解为数仓管理；中间层是计算引擎层；再上一层是数据建模层；最上层是分析和预警层。数仓层基于核心组件事件总线构建。事件总线是实现数据的转化、标准化以及分发，基于SPI机制设计了可插拔扩展的数据源连接器。再上一层是计算引擎层，当前主流计算引擎百花齐放，不同引擎适用不同场景，基于业务诉求，我们采用Flink。再往上一层是数据建模层。核心是数据集这个模块，用户可以手工写SQL，也可以通过拖拉拽生成。这里的建模指的是SQL取数逻辑的构建过程，与常规的算法模型要区分开。用户写完 SQL 后，针对它是什么样的数据存储源、存储类型，直接可以推到对应的存储集群去进行查询。最上层是增强分析，可分为预警和分析。预警分析就是常规的 BI 报表，预警里兼容了异常检测、动态阈值、阈值自动推荐，是基于开源的分布式调度，针对预警做了主备集群等高可用的设计。
整体来看，我们在平台化方面全部都是水平分层的架构，核心的地方都实现了组件化、插件化以及低代码，例如事件总线、数据建模以及BI分析。计算架构实现了存算分离。在2.0 架构突破了1.0面临的一些比较重大的问题，比如存储结构比较单一、查询效率比较低，以及很多地方需要硬解码等等。
在架构 2.0里，我们通过平台化、组件化和插件化去解决上述问题。但任何架构都不是完美的，2.0 的架构也面临着一些问题。第一个是数据架构，我们把明细数据写入ClickHouse，用户再自主写 SQL 进行分析和预警，基于明细的查询，分析效率和复用率低。第二个是百万级TPS入库，性能稳定性如何保证。第三个问题是计算性能如何保障。第四个是随着数据规模越来越大，假如达到几百个数据源，需要考虑如何治理。第五个是预面临的问题，其一，因为风险场景非常多，比如风险里有登录、注册和营销，其中每个场景都可能有不同的小场景，每个小场景里可能的阈值都不一样。如果每个场景都配一个阈值，比如拦截率或者请求量，每个都不一样。如果遍历比较的话，成本是非常高的；其二，非常依赖专家经验，如果没有相关方面的经验，可能根本无法下手；其三，预警后，分析、调整阈值的成本也是非常高的。
再来介绍架构3.0。架构3.0是把智能算法和实时数仓进行了更高维度的整合。首先，从架构层面上，要保证百万TPS数据入库的稳定性，就要在解析、计算、存储时先进行链路拆分，不像之前解析、计算、存储都在同一条链路上。其次是分而治之，我们可以理解为在一个数据管道中，事件总线就是数据从实时数据进入实时数仓里的核心组件，因为MQ可能有几百个，要通过动态调整事件总线的实例，来实现它的资源划分，最终实现机器资源的合理利用。第三是垂直拆分，我们会把相似的业务放在同一个CK集群里，大促相关的业务也会放在单独的集群里，这样可以避免流量特别高的场景对流量低但也很重要的场景产生影响。第四是实时入仓，我们定义了一些实时的公共数据模型的标准与架构。主要分三层，第一层是RODS 层，即之前提到的明细层，将上游的数据落到明细层之后，进行结构化解析，再落在 RODS 层；再上一层是 RDWM 层，它是一个轻度聚合层，是横向的聚合。比如要分析用户的行为序列，我们可能把下面所有 ODS 层里涉及到用户相关的场景，都汇总到DWM层来做用户行为的分析。再上一层是 RDWS 层(聚合层)，它存在的意义是为了解决之前提到用明细进行分析对CK的请求量压力过大的问题，因为不仅A场景需要计算请求量，B场景也需要计算请求量。所以聚合层的意义，就是把通用的指标进行加工，提高数据的通用性与复用性。通过Flink把相关的指标和维度抽取出来，加工成分钟级粒度的数据，再落在 RDWS 层，应用的时候就可以通过分钟级汇总成5分钟、10分钟、一小时来使用。再上层是建模层和数据服务，我们扩展了指标平台和数据API，能够对外提供数据查询的服务。算法服务层，设计了算法网关，支持不同团队的算法能力接入。最上一层是应用场景，例如预警分析、行为分析、针对行为分析的策略分析以及群体分析和风险感知。风险感知区别于常规的风险识别，涉及到的上下游链路非常多，本处只做简单介绍。正常的风险识别是通过具体的模型或者指标的值的组合去判断这个人是不是有风险。风险感知其实是另一个维度的，通过一个人的行为数据去分析预测他是否有风险，所需要要的指标维度会更多一些，算法模型也会更复杂。
接下来是一些产品展示。包括我们支持的数据源、事件总线的核心能力和拖拉拽生成SQL及其效果。
这是生成的效果。如上图中左侧是双十一的大屏，它是基于我们内部扩展的 Redis SQL，通过写 SQL去查询缓存数据，直接配置成了秒级的看板。右侧是异常检测算法，底层支持PC 端和移动端双端。
核心组件是事件总线，定位是统一风险数据标准化处理的流程，包括抽象数据的接入、过滤、孵化、转换、分发和输入输出的过程，并且在这些算子上能够提供一些可扩展性的架构。左边可以理解为数据源，中间是事件总线，右边是输出。比如，想往Flink 、Kafka、数仓、数据库里放，都是可以兼容扩展的。
事件总线的核心之一是插件化，其二是算子的抽象、脚本语言以及函数扩容点。事件总线可以分为三层，分别是source、transform 和sink。该设计参考了Flink 的核心原理：每一层都是可扩展的。比如，扩展一个sink的组件，就可以往任意一个存储里写；transform 里支持脚本语言和函数扩展点，解析引擎支持jsonpath和snack，脚本引擎基于Groovy和avitor实现脚本化的解析，过滤引擎支持规则表达式和降级，函数引擎支持代码和jar包上传，把通用性的函数提取出来，再注册到平台里，作为通用性的函数让其他人可以直接使用。
插件化体现在整体的数据链路分为五层。第一层是事件总线，第二层是存储集群，第三层是SQL引擎，再往上就是数据源引擎，最上层是智能分析和预警引擎。事件总线的连接器、算子和函数都是可以扩展的。存储引擎相当于事件总线sink端，像CK、ES、Hbase、MQ 都是可以扩展的。SQ引擎里比较有特色的地方是我们自己做了Redis SQL，可以通过写 SQL 的方式去查 Redis 的数据。
再就是数据源引擎，包括JDBC连接器，如果选择的数据源是CK，JDBC连接器会有自适配CK的一个driver；如果选择的数据源是MySQL，那就适配MySQL 的 driver。再说Cache连接器，如果选的数据源是 Redis 的话，那我们可以直接适配 Redis 的连接器。
最上层是智能分析和智能预警引擎，组件定义偏向于前端。我们设计了很多BI 类展示的组件，后期想做的是前端组件的解析和注册，能够由三方实现一些组件的扩展。
接下来是异常检测服务，作为我们探索的一个方向，目前投入并不大，但产出效果很好；最上层是网关，是定义异常检测服务的准入标准，我们可以对接不同团队做的异常检测服务。它的内核首先是数据的预处理，然后把处理好的数据放在历史指标数据里，模型的异步更新会拿到历史指标数据，根据机制有条件地去定时地、自动地迭代这个模型
右边蓝色的模块也是目前在做的，目的是把多个异常的指标关联起来，进行多维事件分析，是风险感知场景里的应用。我们用异常检测服务是为了解决专家经验局限性的问题。举个例子，营销每天可能都有上万个乃至几十万个活动，每个活动都会去考虑拦截或请求，每个活动的请求量和拦截率不尽相同，按照一万多个活动匹配一万多个预警是不现实的。我们通过异常检测服务自动地为每个预警的每个指标分别生成一个模型，我们在预测的时候直接调取模型进行预测，例如前面展示的波形图，有趋势的话就会直接按照趋势进行预测；如果跳出这个趋势的话，它会根据偏离的程度计算异常得分。我们只需要根据这个得分研判预警的阈值。
03
未来的思考与展望
最后来分享一下对未来的思考和展望。
首先是场景化分析，因为这一版还是相对通用化、实质化的平台。通用化一般能够解决80%-90%的问题，但对于一些特殊场景的问题，一是业务配置会特别复杂，二是计算逻辑也相对复杂，所以，我们后面也会着力发展一些场景化分析的能力。比如，营销活动的分析、订单的分析。目前相对成熟的是对行为序列的分析，我们会把各个场景的用户行为数据做一层聚合、展示，再去分析用户在一段时间内的行为序列，例如什么时候登录，什么时候下单等。
第二是智能化。目前还是偏向于单指标的异常检测，我们可能会给营销活动生成几万个乃至十几万个模型，但目前单指标的较多，后续如何通过单指标的预警扩展到多指标的预警。再一个就是分析模式的转变，从个体到群体。
第三个场景是湖仓一体。湖仓一体是目前比较热门的概念，它本质上解决的问题是离线和流式能够归一。这是我们之前做模型经常遇到的一个痛点，做完离线之后（SQL 、指标等），因为离线和实时的数据结构不一样，字段也都不一样。离线做的就很难搬到实时上去，后续用湖仓一体能够很好地解决这个问题。并且，架构相对更容易理解一些，存储成本也相对低一些。
04
Q&A
A1比如营销场景，我们可能有几万乃至10多万个活动，这些活动都要考虑请求量、拦截量的拦截率，不同活动的量级其实是完全不一样的。如果想让策略人员或业务人员把所有场景枚举出来，是不现实的。其实，我们做的就是用异常检测去学习每个活动日常的波动趋势，我们就可以给每个活动、每个指标生成一个模型，后续数据再来的时候，它就会去判断与原趋势合不合。如果不合，就会去计算一个异常得分，偏离程度越高，这个点可能就会越黑。这时业务人员只需要去配置偏离程度，再进行预警。所以就不再去依赖专家经验。比如，之前不了解某个活动，我们只要分析一下它的历史趋势，就知道可能偏离50%或30%就会是有风险的。归因分析这块我们会根据不同的指标，自动去钻取一些多维度的数据，然后通过不同维度对于指标波动的贡献度来做分析。
A：这套架构确实是比较偏事后分析以及实时预警的，但是我们在预警的模块里会增加预警处理的能力。比方说，线上发生了一个预警之后，业务人员可以在PC端或者移动端分析这个预警，如果发现有风险，比如是PIN或者活动有风险，我们会把这个PIN 或活动通过接口放到拦截风险决策的名单库里，这样就实现了整个链路的闭环。
A：在我们测完之后发现，误报率和容忍程度相关。比方说，我们会算一个异常得分，它的本质含义是在预测数据的时候，有上界和下界，如果真实的数据偏离上界或下界幅度很大的话，就会根据一个相对常用的公式去算异常得分。比如，一开始配是0.7，如果发现误报率很高，我们可以逐步地调整异常得分的分值，让它达到一个相对的平衡点。异常检测模型比较轻量级，所用到的数据范围大概就几个周期的数据，计算量与计算成本不是很高。
今天的分享就到这里，谢谢大家。
分享嘉宾
INTRODUCTION
孟祥涛
京东科技
架构师
山东大学计算机技术与科学专业毕业，2015年加入京东商城，负责预约、预售、秒杀等黄金链路系统的建设及架构设计。2019年底加入风险研发部先后负责欺诈风险、信用风险、内容风险、智能外呼机器人、实时风险洞察、智能催收平台等相关系统建设与架构设计
峰会推荐
往期推荐