风险控制

导读：依靠于 Fabarta 在金融行业利用图技术解决反洗钱业务畛域问题成功经验，将图智能在反洗钱方向的利用实际进行总结并分享，次要包含以下几个方面： 全文目录： 反洗钱业务业务背景以后反洗钱的业务流程及痛点如何利用图智能进行反洗钱剖析案例介绍总结01 业务背景1.背景 反洗钱的重要性在这里就不赘述了。随着金融技术的疾速倒退，金融机构的体量迅速增长，犯罪分子的洗钱行为、伎俩越来越新，呈现出专业化、团伙化、荫蔽化的特点，为反洗钱工作带来了微小的挑战。在以往的反洗钱工作中，金融机构积攒了很多数据规定，然而因为洗钱伎俩一直翻新，这些积攒的规定或模型并不能齐全、及时地发现新的洗钱伎俩。 因而，在已有零碎预警发现之外，针对须要进一步协查的案例，联合金融机构相干数据构建反洗钱图谱后，进行能够洗钱行为进行发现和举证；在剖析和举证的过程，更多的会是图数据的探查操作。 2.业务流程及痛点 （1）洗钱行为自身是团伙行为 仅针对繁多的客户或者账户进行规定发现，并不能齐全笼罩到团伙行为。所以须要进一步地去对整个团伙进行一些摸索和发现，并辨认进去团伙的行为，只有这样能力更无效地去提供有价值的情报，帮忙金融机构或者经侦机构对反洗钱的案例进行剖析和发现。 （2）现有业务剖析过程 案发后，经侦机构为了进一步针对洗钱行为进行举证，会针对相干账户或者责任人，向相应金融机构发放协查通告。金融机构在承受到协查通告之后，会在本人的数据范畴内进行人工筛查，包含收集相干账户或者相干责任人在本金融机构内的一些金融行为数据。在筛查完之后，将这部分数据中的可疑行为造成报告后，提供给相应的业务部门进行渎职考察，最初整个在机构内造成综合评判，提供一个残缺的案例阐明，进行上报。 （3）现有剖析过程的痛点 在上述业务流程中会有以下几个痛点： 首先是整个流程比拟长，须要数据组进行人工审查，又要业务组进行渎职考察，还要进行研判，最初进行报告整顿，所以一般来说整个的案件解决的均匀工夫会在 20 至 50 分钟。伎俩绝对局限，因为整个过程波及到的数据大多还是通过结构化数据库进行存储的，所以个别采纳 SQL 去筛选、关联数据；针对关联数据的摸索伎俩局限，耗时也比拟长。单个案例自身耗时较长，基本上是每年都会有几万起的案例，因而会耗费金融机构很大的人力工作量去应答。在通过这么多的人力投入和剖析之后，可疑上报之后，发现的可疑行为和数据并没有失去进一步的无效利用，无奈造成一个残缺的闭环。针对这些问题，咱们从技术角度提出了一个整体的剖析思路。 02 剖析过程上面具体地解释一下咱们的剖析过程。剖析过程分成五步。 （1）数据收集 首先是做数据收集，不同机构对于数据收集的能力也不尽相同。例如，经侦机构有权调用所有的数据，包含各金融机构提供的交易数据；而在金融机构外部，则仅能收集相干客户的交易流水数据、客户资料以及采买一些内部数据——包含企业的征信数据、司法的涉诉、刑事案件数据、个人行为等数据。 （2）建设图谱 在收集好各个维度的数据之后，利用这些数据去建设一个图谱，咱们将其分成了两个阶段：第一个阶段是构建一个根底数据的图谱，就是将方才所提到的收集到的这些多维度的关联数据进行图化的组织。把数据组织成图之后提取一些特色信息，次要是对暗藏关系的发现，以及对图内一些行为的形容。在此基础上构建一个新的图特色图谱； （3）模型剖析 在图谱建设之后，能够利用一些伎俩对数据进行剖析，包含一些图的算法，去发现图的一些结构性特色，也会联合一些机器学习伎俩去对整个数据进行建模剖析。 （4）团伙发现 在建模剖析之后，实现整个模型个体的开掘之后，能够依据个体去扩散，找到对应的一个团体性的行为，后针对团体性的行为外部，再进行一些描述性的剖析和发现。进一步找到团伙内的各个成员的分工，并在此基础之上采纳可视化的形式去传递数据价值； （5）数据融通 后面的剖析次要是数据处理、探查工作，但自身还波及到数据的流转，即提供反馈给上家机构，或者最终反馈到经侦。在整个解决的过程中，须要对提供的线索以可视性更强的形式表白，减速案例解决，外部流转。 下面是整体的剖析过程，上面开展介绍建设图谱的两个阶段，第一步是对于根底数据的采集包含个人账户数据，比方个人账户数量、电话、地址、账户睡眠工夫，还有对企业账户数据的采集如注册资金、经营范围、注册地址、股权等，还有对交易行为数据的采集，包含交易金额、交易工夫、交易类型等，如果是网银交易，还需收集对应的 IP 地址和 Mac 地址，线下交易会收集交易机构，在收集到这些根底数据后，会进一步地进行特色加工，再去关联。如能够通过账户的注册地址去发现账户之间是否存在暗藏的关联关系，或者通过股权关系去发现是否具备理论控制关系，这样的话就能够在已知的根底下来进一步开掘暗藏的关系，并在此基础上建设更深的图网络。还有一些特色如交易频率、是否存在会聚性的交易行为，或者是单笔转入多笔转出等等，通过这些进一步去丰盛整个图的内容。以上作为后续剖析的根底，只有在这外面建设了更丰盛、更广大的关系，能力更多地提取整个图相干的数据价值。 在图谱建设之后，又回到了模型剖析局部，其实模型剖析咱们用图的话会扩大剖析维度，在原有的描述性剖析的特色维度之上，还是会通过图的一些结构性特色去剖析。这里列举了一些经典的图的算法，针对不同的场景会须要不同的抉择。如交易的行为或模式，能够用 PageRank，能够看到以后客户/账户是不是整个交易的集中核心。还能够通过一些社区发现相干的算法对数据进行聚类，包含一些行为的辨认；除了利用一些规范的算法，还会通过一些业务人员人工的辨认去发现一些洗钱相干模式，如是否有一些分散型的交易。后续将在案例中进一步再解释模式这一结构性的特色，以及应用动图模式去进行特色的开掘，最初把所有特色送到模型里进行剖析。 03 案例介绍1.案例阐明以上是一个残缺的剖析流程，上面来分享一个具体案例，在分享之前有一些必要的阐明。 后续的整个案例都是基于开源数据集的，因为以往波及金融机构的数据都是窃密的。这个开源数据集来源于 IBM 提供的模仿数据，可见数据外面是一个绝对简单的交易数据网络，并且曾经对每笔交易打了标签，上面通过 Fabarta 提供的图智能剖析平台对数据进行剖析和发现。 2.案例流程 第一步是通过开源数据去进一步模仿客户信息、账户信息、交易流水信息；在数据根底上对交易个体的每一个账户进行特色发现，进一步筛选出可疑个体。在可疑个体的根底上，通过构建交易网络大图，围绕着个体进行一些子图的筛选，在此基础上进行群体特色的发现，进一步去找到其绝对应的交易团伙。发现团伙后，再将数据筛选定义到团伙级别，针对团伙外部的行为特色进行一些形容总结，找到不同成员的分工行为。并在这个过程中，逐渐发现其反洗钱的特色，包含行为型、描述性的特色。最终将特色转化为具体的工作，在逐步积攒的过程中，将发现的特色利用到更广的数据集中，进一步找到是满足特色发现的可疑团伙行为。3.数据探查 数据探查次要是对数据的描述性信息进行剖析，案例里针对交易行为进行了根本的解决，如单日转出金额的比例，咱们通过对整体数据的剖析制订一个标准值。对超出标准值的标记为异样点，而后通过找异样点的形式去发现异常用户。真正的施行过程会有更简单的发现形式，在这里示例次要是为了不便咱们展现整个剖析过程。 具体的，在找到了转入转出金额比例之后，通过剖析统计，剖析出自身的标准值、平均值、标准差等，能够看到在右侧整个异样行为的也会比拟大。转入转出均匀在 4000 左右，然而有一些数据都是几万了，这是个绝对较高的比例。针对这个个体须要逐个地进行剖析是否存在问题。 4.异样点剖析 异样点剖析还是要围绕方才的交易大图，其是一个芜杂的交易网络，数据量也较大。在筛选完子图后，须要先将相干链路的高低三层，即到底通过什么样的链路进行资金的转入和转出，再将筛选出的数据进行可视化的探查，筛选出的图的大小较小，然而能够通过他的结构性的行为去发现交易的分层行为，通过多层的交易账户之间交易，最终将资金汇聚到最上面的账户上。 这其实也是资金的会聚，通过层层交易把资金汇聚到少数几个账户上，在这里通过可视化的探查能够发现他的这种行为，并且在图构造上会有异样行为的佐证，在发现异常行为的子图特色后，再针对子图去进一步剖析，并应用一些图算法去发现它的结构性特色。 5.图结构特征探查 在这边用到了三角计数；在业务上能够这么了解：如上图，账号131在给996转账的同时，也通过中间人811给996转了账，简略来说通过多条链路去达成同一指标人的转账行为。那咱们利用这个结构性的特色对数据进一步剖析，筛选出子图内存在这种交易行为的客户，并对三角计数进行从新统计。统计之后大家能够发现围绕账户 996，它有 26 个结构性的交易，这种三角计数的后果其实就是结构性的交易的行为，最终围绕着 996 把数据再进一步筛查，把所有这种结构性的交易数据全副筛查进去。在左下方这个图外面，存在 26个三角环，三角计数这个后果的一个子图，通过与业务人员剖析，这种行为其实并不是很失常的行为，他一直地通过其余账户转钱。通过上述剖析查证之后，进一步将数据筛查范畴降下来，从方才 996 高低的那个链路推广到整个具备三角计数的交易链路上来。6.图结构特征发现 ...

导读：随着企业数字化转型降级，线上业务出现多场景、多渠道、多元化的特色。数据因素价值的开掘堪称争分夺秒，业务也对数据的时效性和灵活性提出了更高的要求。在宏大扩散、高并发的数据起源背景下，数据的实时处理能力成为企业晋升竞争力的一大因素。明天分享的是众安金融实时特色平台实际。 上面的介绍分为四个局部： 众安金融 MLOps 简介实时特色平台架构设计实时业务特色计算详解反欺诈场景的特色利用分享嘉宾｜郭育波 众安 高级技术专家众安金融 MLOps 简介什么是 MLOps （1）定义 MLOps 是将机器学习、数据工程和 DevOps 交融在一起，从而实现机器学习模型的高效迭代和继续稳固地利用于生产业务的一套办法架构。所以它是一套实际方法论，是一套架构计划。 （2）合作团队 ① 数据产品团队：定义业务指标，掂量业务价值。② 数据工程团队：采集业务数据，而后对数据进行荡涤转换。③ 数据科学家团队：构建 ML 解决方案，开发相应的特色模型。④ 数据利用团队：模型利用，对特色进行继续的监控。 众安金融 MLOps 流程阐明 （1）样本筹备，产品业务团队定义业务范围，确定建模的指标，抉择样本人群筹备训练集。（2）数据处理，须要对数据进行缺失值、异样值、谬误值、数据格式的荡涤，应用连续变量、离散变量、工夫序列等进行数据转换。（3）特色开发，数据处理实现后就能够进行特色衍生，金融特色次要通过审批逻辑衍生，行为总结量化，穷举法，去量纲，分箱，WoE，降维，One-Hot 编码等进行特色衍生，之后根据特色品质，比方特色指标（KS、IV、PSI）或者预计逾期率等进行特色筛选。（4）模型开发，要进行算法的抉择和模型的拟合。（5）模型训练，应用测试数据集进行模型算法的测试验证，进行参数的调优。（6）模型利用，模型开发好之后就须要进行线上化的一个部署。（7）模型监控，上线后须要继续的监控和模型的迭代优化。 众安金融为什么须要建设 MLOps? 众安金融，一方面为普惠人群提供公信征信反对，另一方面也为银行等资金机构来提供危险缓释，助力普惠金融。众安金融为无抵押的纯线上生产贷款平台提供信用保障保险服务，也为其余金融机构提供信用保障保险服务。 众安保险作为保险公司在其中承当理赔的责任，所以就要求咱们须要对危险进行全面辨认、精确计量、紧密监控。咱们搭建了以大数据为根底、以风控规定与模型为策略，以零碎平台为工具的大数据风控体系。通过利用大数据与个人信用的关联挖掘出大量的用户危险特色和危险模型，从而晋升风控的预测能力。 随着风控策略的精细化，模型利用的规模化，特色应用的实时化，对咱们的特色开发和模型利用提出了更疾速更实时的要求，所以咱们就开始尝试进行特色平台体系化的实际。 众安金融 MLOps 体系 （1）大数据平台：数据开发工程师应用大数据平台的能力采集到相干的业务数据，构建基于主题域的离线数据体系，同时把相应的数据回流同步到在线 NoSQL 存储引擎，提供给实时特色平台应用。（2）特色工程：数据科学家在大数据平台进行特色工程的建设，应用离线数仓进行特色的开掘和特色的抉择。（3）机器学习平台：数据科学家借助机器学习平台能够进行一站式的模型开发和利用。（4）实时特色平台：开发好的特色和模型须要在实时特色平台进行注册，在实时特色平台配置好相干的信息后，就能够通过实时特色平台的数据服务能力，提供上游业务的特色查问和模型利用的能力。 实时特色平台架构设计众安金融特色利用场景 众安金融实时特色平台服务于金融业务全流程，蕴含金融线上的外围业务场景如登录，准入，授信，支用，提额等实时前台场景，后盾业务场景更多是批量的特色调用场景，此外还有催收也有对于特色和模型的应用，一开始特色平台的初衷是为风控体系服务，随着业务的倒退，模型也逐步应用到了用户营销场景和一些资源位的用户举荐服务中。这里值得注意的是，对风控业务理解的同学就会晓得，一次风控策略会有多个风控规定，每个风控规定会查问多个特色数据，所以一次业务交易对于实时特色平台来说可能就会放大到几百倍的调用。 众安金融特色数据分类 （1）交易行为数据：蕴含授信，借款申请、还款的数据，调额和逾期数据等业务数据。（2）三方征信数据：须要对接三方征信机构的接口。（3）设施抓取数据：在用户受权容许的状况下获取设施相干信息。（4）用户行为数据：通过用户行为埋点获取。 实时特色平台外围能力 面对泛滥的特色数据源，这就要求咱们实时特色平台具备丰盛的数据接入能力，实时的数据处理能力，对于大量的特色需要也要求特色平台具备高效的特色加工配置化能力，实时的业务调用要求平台有疾速的零碎响应能力，咱们也是围绕这些外围能力的要求进行特色平台的技术选型和架构设计。通过了技术迭代选型，咱们采纳了 Flink 作为实时计算引擎，应用阿里云的 TableStore 作为高性能的存储引擎，而后通过微服务化的架构实现了零碎的服务化和平台化。 实时特色平台的业务架构 这张图是咱们的实时特色平台的业务架构图，能够看到图的底层是特色数据源层，中间层是实时特色平台的外围性能层，下层是整个特色平台体系的业务应用层，特色平台次要有四个数据源： （1）征信数据网关：提供人行征信等征信机构的用户信用数据，须要通过实时的接口对接来查问征信数据。（2）三方数据平台：提供内部数据服务商的数据，通过调用三方数据接口服务实现实时数据对接。（3）实时计算平台：实时接入业务零碎的交易数据，用户行为数据和抓取设施数据，通过实时计算后回流到 NoSQL 在线存储引擎。（4）离线调用平台：离线数据在阿里云的 MaxComputer 计算后同步到 NoSQL 存储，实现历史数据的回流，从而撑持用户全业务工夫序列的特色计算，此外一些非实时指标也须要在离线数仓加工实现后再回流到 NoSQL 存储引擎。 实时特色平台的外围性能： （1）特色网关：特色网关是特色查问的出入口，具备鉴权限流、特色数据编排等性能。（2）特色配置：为了反对特色的疾速上线，特色平台实现了特色的配置化能力，蕴含三方数据特色配置、实时业务特色配置、互斥规定特色配置、模型特色配置能力。（3）特色计算：特色计算是通过微服务化的子系统来实现的，次要有三方特色计算、实时特色计算、反欺诈特色计算、模型特色计算。（4）特色治理：特色治理后盾提供了特色变量生命周期治理能力，模型的元数据管理，还有特色跑批的工作治理。（5）特色监控：具备特色调用全链路查问能力，对于特色计算失败、特征值异样值、模型 PSI 值稳定进行实时告警，此外也提供了特色应用状况等统计分析大盘报表。 三方数据实时接入计划 （1）查问形式：调用三方征信机构的实时接口获取报文数据而后进行数据处理获取特色后果，出于降本思考，咱们还会实现一套缓存机制，对于离线场景缩小调用三方的次数。（2）翻新点：三方数据接入引擎能够通过纯配置化的形式接入三方的数据接口，通过特色加工引擎实现自动化的特色生成，通过可视化界面提供配置化的能力，最初通过接口提供给上游应用三方特色计算服务。（3）解决的难点：三方数据与配置化接入的难点是数据服务商的加密形式、签名机制多样性、复杂性，三方数据接入引擎通过内置一套加解密函数和反对自定义函数的能力，联合函数的链式组合形式，实现了各种简单的三方数据加解密的配置化的实现。 业务数据实时接入 实时业务数据的接入由两局部组成，首先是通过 Flink 实时监听业务数据库的 Binlog 数据写入到实时数仓，还有一部分应用 Spark 实现历史数据的回补，联合离线数据和实时数据就能够反对基于全量时序数据的特色加工能力，为了反对高性能的实时特色查问，实时数据和离线数据都会回流到 NoSQL 存储引擎。对于不同的数据，咱们也会思考不同的存储引擎，业务交易数据次要是用 TableStore 作为存储引擎，用户行为特色数据应用 Redis 为主，用户关系图谱数据用图数据库进行存储，从整个流程来看，当初的数据体系是采纳成熟的 Lambda 架构。 ...

最近在整顿对于实时风控决策零碎的内容，明天抽空写了一篇如何疾速部署的简略攻略吧。 接入只需4步 具体步骤Step 1：获取AppId、AppSecret；返回顶象治理后盾，在实时危险决策的二级菜单“利用治理”中获取；PS：未开明服务的，须要先申请开明服务。 Step 2：前端接入，即设施指纹埋点；反对Web接入，反对IE8+、Chrome、Firefox、360浏览器、QQ浏览器等支流浏览器及Android、iOS上的内嵌Webview。 PS:提醒：设施指纹token具备时效性，超过肯定工夫会过期，请勿自行缓存重要：因终端用户的设施网络环境和设施版本等因素，设施指纹采集率并不能肯定达到100%，可能会存在极少局部未能失常采集到的状况。所以在集成指纹服务的时候，请尽量避免对指纹信息强依赖。1. web接入1.1 环境要求兼容IE8+，Chrome，Firefox，360浏览器，QQ浏览器等支流浏览器。 1.2 引入JS在页面 HTML 中引入const-id.js，代码如下： <script src="https://cdn.dingxiang-inc.com/ctu-group/constid-js/index.js"></script>1.3 生成token页面加载后，初始应用，须要在 JavaScript 中调用_dx.ConstID(options, callback)办法，生成token，代码形如: var options = { appId: '【这里填写 AppId】', // 惟一标识，必填 server: 'https://constid.dingxiang-inc.com/udid/c1', // ConstId 服务接口，可选 userId: '【这里填写 userID】' // 用户标识，可选};_dx.ConstID(options, function (e, id) {if (e) { // console.log('error: ' + e); return;}// console.log('token is ' + id);// console.log(_dx.constID === id); // true});执行胜利后，页面中将会有一个全局变量_dx，能够通过_dx.constID拜访这个值。也能够持续调用下面的初始化办法，同一个浏览器屡次初始化返回的值雷同。 options 字段阐明 字段类型是否必填阐明AppIdString是以后利用的标识,须要分割工作人员获取serverString否服务接口，可选，如不填，则默认会用云服务接口sceneString否场景标识，例如login、survey等userIdString否业务方的用户惟一标识，例如用户名、用户ID、手机号、Email等2. Android接入2.1 环境要求 条目阐明开发指标Android 4.0+开发环境Android Studio 3.0.1 或者 Eclipse + ADTCPU架构ARM 或者 x86SDK三方依赖无2.2 集成SDK ...

本文整顿自中国移动算法工程师——汪海涛在 NebulaGraph 2022 年度用户大会上的分享，现场视频见 B 站：https://www.bilibili.com/video/BV1Ae4y127a8/各位朋友上午好，我是来自中国移动的算法工程师汪海涛。接下来我次要聊一聊图数据库在中国移动，特地是金融风控场景的落地利用。 为什么中国移动要建设图平台？全国 9 亿用户，每天产生大量数据中国移动有十分多的数据，全国的用户每天都会产生海量的数据。如何从这么大数据量外面挖掘出有用的信息，而后用到金融风控场景？这就是咱们须要做的事件。 之前，咱们是以手机号为维度去提取特色，而后去做一些模型或规定判断一个手机号是否是有守约危险。但仅仅基于手机号很难综合去思考危险状况，因而咱们就想采纳图计算技术去综合看一个手机号以及四周的其余手机号的信息，而后独特评判它的危险。 最开始是基于生产金融的场景，从比如说像蚂蚁金服、微信以及京东白条这样一些产品切入，通过用户通话数据、短信数据、设施等多维度的一些信息，去判断用户危险。但中国移动数据量这么大，不论咱们要做什么，最大的诉求就是须要有一个十分高性能的平台去撑持数据分析。 为什么抉择 NebulaGraph 图数据库？JanusGraph vs TigerGraph vs NebulaGraph咱们最早是采纳了 JanusGraph 加上 Spark 去建设咱们平台，然而通过一些测试，咱们发现 JanusGraph 的查问性能以及导入性能都比拟个别，而后 GraphX 的话，它的计算性能其实也比拟个别，特地是它须要的内存量特地大，因而咱们起初又开始去调研了市场上很多的图产品，并且对一些图产品做了测试，包含国外的产品，像 TigerGraph 之类的等等，然而因为一些非凡起因，中国移动是在美国商务部的实体清单上，所以很多外国的产品咱们是没法去洽购和应用的。 因而最初，咱们是抉择国内的几家厂商进行了一些测试和比拟，最初抉择了以 NebulaGraph 作为图数据库，而后以 Plato 作为图计算引擎这样一个整体的架构。 中国移动是如何搭建图平台的？图平台建设详情 咱们整体的架构大略是这样的—— 最底层是咱们的数据源，中国移动建设有一个全国大数据中心，次要包含通话数据、地位数据、生产数据、设施数据、用户数据和 APP 数据等等，咱们每月把这些数据抽取到 HDFS 外面，而后把其中有用的数据抽取到 NebulaGraph 数据库外面，那么这里用的就是 Nebula 的一个导入工具，这是咱们图数据存储这一层。 再上一层是计算剖析层，这也是咱们建模和业务剖析人员次要应用的一些框架。首先第一个是 Plato，它是腾讯之前开源的一个图计算引擎，然而据我所知腾讯当初曾经不保护这一套引擎了，因而咱们也是专门找一些工程师，而后去保护这外面的一套框架，以及修复一些小 bug 之类的。 那么它蕴含的算法其实很多的，这里我次要是列举了两个社区发现算法：Louvain 算法和 HANP 算法。它外面还蕴含一个 LPA 算法，因为 LPA 算法的话是 HANP 算法一个简化版，所以这里我没有列出来。 而后外面还有一个咱们有可能前面会用到的对于随机游走类的算法，次要是基于随机游走失去一个节点序列，会为咱们前面用于图神经网络训练做一个后期数据预处理的工作。 第三个是 GNN，就是图神经网络。图神经网络是最近几年衰亡的一个畛域，咱们当初次要是基于这些模型做一些简略的产品，看看能不能获得比以往的办法更好的一些成果。最初就是基于 NebulaGraph 查询语言，次要就是 GO 语句和 FETCH 语句做一些简略查问。 再上一层的话就是应用层。首先是关联危险分，关联危险分次要是基于配套的社区发现算法来做的。第二个号码危险分和最初一个催收剖析次要是基于 Nebula 的查问语句来做的，次要就是查问用户跟一度、二度联系人以及一些守约用户，或是催收专用号码进行一些被动或被动的呼叫。第三个信用评分卡是基于图神经网络来做的，次要是用逻辑回归或者决策树之类的模型，心愿通过图神经网络做一些进步。 ...

原文出处：https://discuss.nebula-graph.com.cn/t/topic/11873本文是一个基于图数据库 NebulaGraph 上的图算法、图数据库、图神经网络的 ID-Mapping 办法综述，除了根本办法思维的介绍之外，我还给大家弄了能够跑的 Playground。 基于图数据库的用户 ID 识别方法用户ID 辨认，是一个很常见的图技术利用场景，在不同的语境下它可能还被叫做 Entity Correlation（实体关联）、Entity Linking（实体链接）、ID Mapping（身份映射）等等。ID 辨认解决的问题是找出雷同的用户在同一个零碎或者不同零碎中的不同账号。 因为 ID 辨认人造地是一个关联关系问题，也是一个典型的图、图数据库利用场景。 建设图谱图建模咱们从一个最简略、间接的图谱开始，如下边的图构造示意显示，咱们定义了点： user Prop: [name, email, birthday, address, phone_num]phoneemaildeviceipaddress在他们之间有很天然的边： used_device Prop: timelogged_in_from Prop: timehas_phonehas_addresshas_email 数据集这份数据是开源的，地址在 https://github.com/wey-gu/identity-correlation-datagen 数据写入数据写入咱们用一行部署图数据库服务的 nebula-up：https://github.com/wey-gu/nebula-up/ curl -fsSL nebula-up.siwei.io/install.sh | bash图建模的 Schema 对应的 NebulaGraph DDL 是： # 创立一个叫做 entity_resolution 的图空间CREATE SPACE entity_resolution (vid_type=FIXED_STRING(30));USE entity_resolution;# 创立点的类型 TAGCREATE TAG `user` (`name` string NOT NULL, `email` string NOT NULL, `phone_num` string NOT NULL, `birthday` date NOT NULL, `address` string NOT NULL);CREATE TAG `address` (`address` string NOT NULL);CREATE TAG `device` (`uuid` string NOT NULL);CREATE TAG `email` ();CREATE TAG `ip` ();CREATE TAG `phone` ();# 创立边的类型 Edge TypeCREATE EDGE `used_device` (`time` timestamp NOT NULL);CREATE EDGE `logged_in_from` (`time` timestamp NOT NULL);CREATE EDGE `has_phone` ();CREATE EDGE `has_address` ();CREATE EDGE `has_email` ();对于写入数据的 DML，这里只给出 user ，email 类型点、has_email 类型边的例子： ...

作者：京东科技 刘红申 一、事件总线介绍事件总线，或称其为数据管道，作为整个危险洞察数据流转的重要一环，它承当着危险实时数据对立标准化的重要职责。 在面对简单多样的上游数据，事件总线能够将简单数据进行解析、转换, 富化、散发等操作。底层外围算子形象为source、transform、sink三层架构, 反对各层算子插件式扩大, 并反对groovy、python等脚本语言自定义配置，以及自定义jar包的上传，领有将上游数据单向接入多向输入的能力，在数仓与下层利用的发展中，起着承前启后的作用。 二、事件总线-遇到的技术挑战与解决方案技术难点与挑战危险洞察平台运行初期，业务数据接入齐全采纳定制化代码解决，通过代码配置生产MQ音讯，而后依据业务需要，实现其所需字段的解析，最终数据落入Clickhouse。这种业务接入形式在晚期是能够满足业务所需，然而随着危险洞察平台在风控畛域的一直推动，业务的倒退与数据一直收缩，面对风控数据的简单多样性、音讯平台的差异性，数据接入定制化老本也越来越高，同时数据转化与计算逻辑的强耦合，大促期间吞吐量未然达到瓶颈，呈现出越来越多的痛点： 1. 数据结构差异性: 随着危险洞察平台应用业务方的的一直减少，业务数据音讯体的复杂性也不尽相同，如简单场景以天盾反欺诈场景为例，音讯体构造蕴含对象、对象字符串而且还有数组；简略场景以内容平安为例，音讯体构造就是简略平铺的一层；面对风控数据的简单多样性，定制数据的对立标准化未然火烧眉毛； 2. 代码逻辑重复性: 对音讯体的解决绝大多数逃离不了序列化与反序列化操作，然而随着业务量的增多以及开发人员的不尽相同，业务代码是每日剧增且带有错落性的，逻辑反复，保护老本高； 3. 解析写入低效性: 同一个MQ音讯可能会对应很多的业务方，不同的业务方所需业务数据又千差万别，如以天策MQ为例，实时数据中蕴含着金白条数据，金条与白条数据又辨别着各自的业务线，如果单次订阅MQ音讯，会导致逻辑解决极其简单，不可保护；然而采纳屡次订阅，又无奈复用已有逻辑，且导致数据成倍增长，造成资源节约，同时吞吐能力成为瓶颈； 4. 输入输出多样性: 随着危险洞察平台被应用的越来越广，来自于上游数据的生产方式也呈现了多样性，如JMQ2、FMQ、Kafka以及JMQ4等等，同时又为了给用户更好的平台应用体验，不同业务数据又会被落入不同存储中，如Clickhouse、R2m、Jes以及音讯队列，如何疾速反对这些组件成为了挑战； 5. 业务需要易变性: 上游业务频繁的策略调整与变更，对应到事件总线就意味着解析字段以及底层表字段频繁的增删改，正如字段解析齐全依赖于硬编码且不同业务数据耦合着各自的业务逻辑，导致开发人员保护老本极高，开发周期长、上线影响广； 技术解决方案研发一套数据流转服务，用其贯通数据接入到数仓存储的整个流程，再联合危险洞察平台个性，以数据源组件为根底，作为数据流转的入口与进口，具体计划如下： • 数据对立标准化能力：对立标准化入口与进口。上游数据接入时，无论音讯体构造如何，通过事件总线解决后，都输入为平铺单层key-value构造； • 代码逻辑规范化能力：针对风控策略自身易变的个性，采纳灵便度更高的音讯体解析组件Jsonpath，任何音讯体解决第一步就是生成音讯体上下文对象，后续字段的提取，都从这个上下文中获取； • 高吞吐解析写入能力：一次解析，多路复用。MQ主题实现单次接入，依据不同的业务需要通过过滤下沉不同的业务表，如以天策金白条为例，提取金白条各自的INTERFACE_NAME作为条件，下沉到不同的业务表中；又如以高TPS营销反欺诈场景为例，在下沉表的同时，下沉音讯队列给Flink计算应用；缩小反复解析，同时形象各种算子，针对不同的数仓写入可做对应的频次、批次、大小设置，晋升吞吐量； • 输入输出插件化能力：输入输出插件化，新的业务需要来时，能够疾速扩大相应组件，以应答新需要； • 低代码化热加载能力：针对业务需要的频繁变更，解决硬编码问题，缩小上线频次，那就须要开发一套可配置化零碎，反对脚本开发与热加载，同时内置函数插件化，疾速扩大共性函数； 三、事件总线-整体架构图 事件总线-架构介绍事件总线整体架构形象为三层，source、transform 和sink。 通过连接器扩大机制实现数据引擎扩大, 并采纳责任链模式解决数据链路, 插件化治理函数、脚本，实现实时音讯接入、过滤、富化、转换、散发标准化解决， 并通过分组生产、降级机制保障架构高可用。 • 实时数据: 危险外围场景，目前事件总线业务数据的次要起源； • 事件总线: ◦Source：数据输出层，危险业务数据的次要起源形式，目前大多数来源于JMQ2、JMQ4、FMQ等； ◦ Transform: 事件总线的外围解决层，同时也是自定义函数与自定义脚本的解析层，该层形象了大量的算子，如，数据解析算子、过滤算子、富化算子、转换算子等等当简单音讯体数据通过一系列算子之后，最终会转化为单层key-value规范构造； ◦ Sink: 数据输入层，经Transform组件转换后，此时的数据能够发实时音讯给各个音讯队列，也能够存储到Clickhouse、Es、R2m等数据库； • 数据服务: 基于事件总线标准化后积淀的数据所撑持的平台利用； 事件总线-外围类图介绍 事件总线定义了一个顶层父接口IEventHubExecutor，并定义了一个execute办法，其三个次要子接口，IEventHubParse、IEventHubTransform与IEventHubSink别离对应于事件总线的三个组成部分，source、transform和sink。通过实现这三个子接口，便能够实现对不同中间件的适配问题。比方，目前事件总线仅反对解析的数据写入到Clickhouse，但业务需要须要做检索，那么很显然数据存储在Es要优于存储在Clickhouse，所以此时须要扩大一个JesEventHubSink来实现IEventHubSink即可。 其中Context作为上下文，贯通了整个事件总线的执行过程，上下文中蕴含了解析过程中所须要的一起信息，比方，从哪里来的数据、要解析哪些字段、解析好的数据送到那里去等等。 事件总线-自定义函数介绍 自定义函数的实现，其实借助了开源框架Avaitor表达式，Aviator是一个轻量级、高性能的Java表达式执行引擎, 它动静地将表达式编译成字节码并运行，次要用于各种表达式的动静求值。相比Groovy这样的重量级脚本语言，Aviator是十分轻量级的表达式执行引擎。 • 函数解析器：自定义函数反对脚本编写（脚本采纳groovy，同时为了更加“亲民”，采纳Java语法）与Jar包上传两种形式； • 函数编译器：编译脚本与解析jar包，生成对应的AvaitorFunction实例； • 函数注册器：将生成的AvaitorFunction实例注册到Avaitor的上下文中； ...

本文是一个基于 NebulaGraph 图算法、图数据库、机器学习、GNN 的 Fraud Detection 办法综述。在浏览本文理解欺诈检测的根本实现办法之余，也能够在我给大家筹备的 Playground 上跑下数据。 上面进入本次图数据库的欺诈检测实际： 建设反欺诈图谱欺诈检测实际的第一步，是面向关联关系对现有的历史数据、标注信息进行属性图建模。一般来说，这种原始数据是由多个表构造中的银行、电子商务或者保险行业里的交易事件记录、用户数据和风控标注组成，而建模过程就是形象出咱们关怀的实体、实体间的关联关系及其中有意义的属性。 一般来说，自然人、公司实体、电话号码、地址、设施（比方终端设备、网络地址、终端设备所连贯的 Wi-Fi SSID 等）、订单都是实体。其余信息，比方：危险标注（是否高风险、危险形容等）、自然人和公司实体的信息（职业、支出、学历等）都作为实体的属性来建模。 下图是一个贷款反欺诈的示例建模，你能够拜访 https://github.com/wey-gu/fraud-detection-datagen 获取这份数据生成器代码和示例数据。 图数据库查问辨认危险有了一张囊括了人、公司、历史贷款申请记录、电话、线上申请的网络设备的图谱，咱们能够开掘一些有意思的信息。 事实上，很多被发现且被无效阻止，防止损失的骗保行为都是具备群体汇集性的。比方：欺诈团伙可能是一小批人（比方：3 到 5 人）有组织地收集更大规模的身份证信息（比方：30 张），同时申请多个金融机构的大量贷款。在放款后，团伙抛弃这批留下了守约记录的身份证，再抉择下一批身份证如法炮制。 这种团伙作案的形式因为利用了大量新的身份信息，齐全利用历史记录中的黑名单去躲避危险的形式是有效的。不过，从关联关系的角度登程，这些模式是肯定水平上能够被及时辨认进去的。 这些能够被辨认出的欺诈行为，我把它分成两种： 一种是风控专家能够间接用某种模式来形容的，例如：和曾经被标注为高风险的实体有间接或者间接的关联关系，像是新订单申请人应用了和过往高风险记录雷同的网络设备。这种模式对应到图谱中，通过一个图查问就能够实时给出后果。 另一种是隐含在数据的关联关系背地，须要通过图算法开掘得出的危险提醒，例如：给定的实体与无限的标注高风险实体没有匹配的关联，然而它在图中造成了汇集性。这就提醒咱们，这可能是一个尚未得手、进行中的团伙贷款欺骗贷款申请。这种状况下，能够通过定期在历史数据中批量执行社区发现算法得出，并在高汇集社区中利用核心性算法给出外围实体，一并提醒给危险专家进行后续评估和危险标注。 基于图谱与专家图模式匹配的欺诈检测示例在开始之前，咱们利用 Nebula-UP 来一键部署一套 NebulaGraph 图数据库： curl -fsSL nebula-up.siwei.io/install.sh | bash首先，咱们把后面建模的图谱加载到 NebulaGraph 里： # 克隆数据集代码仓库git clone https://github.com/wey-gu/fraud-detection-datagen.gitcp -r data_sample_numerical_vertex_id data# 去掉表头sed -i '1d' data/*.csvdocker run --rm -ti \ --network=nebula-net \ -v ${PWD}:/root/ \ -v ${PWD}/data/:/data \ vesoft/nebula-importer:v3.1.0 \ --config /root/nebula_graph_importer.yaml有了这样一个图谱，风控专家能够在可视化摸索工具 NebulaGraph Studio 中按需摸索实体之间的关系，绘制相应的危险模式： ...

引言名单服务是风控架构中重要子域，对危险决策的性能、用户体验、老本管控、危险治理积淀都有重要影响，本文将具体介绍名单服务设计思路和实现。 背景什么是名单？名单服务通常有几个局部组成： 危险类型 黑名单：相对会被回绝的用户。大部分是历史数据荡涤进去舞弊或者毁坏业务的用户，这部分用户对企业无价值且放之进入会毁坏生态平衡灰名单：灰名单上的客户须要进一步审核。这部分用户可能存在某些危险，然而没有明确的证据表明他们是“黑”的白名单：这部分客户是失常用户，是企业数分人员基于历史体现荡涤进去的合规高价值用户，能够间接放行名单维度 主键：手机号、用户 ID、身份证号、IP、设施标识、wifi MAC 地址等等业务域：全域、业务子域、细分畛域等等，这边须要字典服务来枚举出须要管控的粒度和场景工夫维度名单是有肯定的失效期的，不同的行为会导致锁定期不一样，失效工夫能够灵便设置 为什么须要名单服务？最易构建的决策能力：风控后期的构建是比拟依赖名单决策的，策略数分人员通过历史数据断定哪些是“坏用户”，间接将其存储到名单库中，后续申请间接在第一道名单决策中踢出，而不须要执行后续策略在断定一次。策略绝对名单来说是十分“重”的，且名单服务构建简略便捷，省时省力。性能思考：名单断定个别是在决策流的第一道，试想，对企业服务来说，大部分用户其实都是失常的，如果每个用户的申请都过一遍策略，对老本是极大的节约，同时对性能来说也是极大的挑战。此时名单服务通过白黑名单，将大部分用户间接决策进来，只对不明确的客户和有危险的客户来做决策，极大地缩小了开销。设计实现名单服务的特点如下： 名单数据起源：能够是实时产生、离线跑批生产、经营人员手动批量导入等等，形式多样性能足够好：属于决策流入口必过服务之一，即最大流量冲击，须要经得起峰值压力，RT 要足够小稳定性：高性能同时还须要高质量保障，如果名单服务出问题，结果不堪设想，流量全副放逐到上游，可能会呈现服务雪崩质量保证：任何名单增加到名单库中都须要器重，随便的增加可能会给企业带来难以想象的损失，所以得有齐备的审核记录及增加起因，最重要的是失效工夫的设定整体名单服务的数据流图如下所示，重要节点会作明确阐明： 实时链路名单查问设计思考到名单有时效性及性能要求，且名单数据结构整体简略（多维度，单个维度存储内容小），抉择 Redis 存储名单数据非常适合疾速查问，数据结构如下：阐明： 采纳 Redis Hash 构造存储数据为何不必 TTL 来存储过期工夫？：一是 expire 最大过期工夫不能超过 Integer.MAXVALUE 不能满足长时间的过期诉求；二来 Redis 自身定位是缓存，不是永恒存储，即数据是可失落的，须要本人保障服务的高可用依赖于 Redis 集群良好的性能，根本能满足线上峰值高 QPS 查问需要，且 RT 能很好的管制在 10 ms 以内。如上所说就是要保障高稳定性需要，如何保障名单数据的高可用是首要问题。 高可用设计Redis 自身定位是缓存，不能永恒保留数据，且集群瘫痪或者数据局部缺失应答业务影响较小（能及时复原的状况下，运维保障集群的可用性），如下是高可用数据设计架构：阐明： T+1 Job 保证数据稳固：每天离线工作全量笼罩，从关系数据库 PG/MySQL 中抽数 push 到 Redis 中即可Redis 集群出问题：不论是老集群重启还是更换到新集群，先用 RDB 复原数据，保障线上可用，再立刻执行离线工作做准确笼罩（T 日的数据失落须要立刻笼罩），思考到读写同时进行可能会有问题，须要分集群切流同时须要关注多线程问题，同一个维度，在同一时间可能存在批量更新状况，尤其是离线工作复原时，历史数据会存在对一个维度屡次更新问题，不思考多线程问题可能会导致数据被篡改。 数据安全审计名单库的危险点在于：随便地增加名单可能导致“坏用户”畅通无阻，“好用户”无奈在进入业务流程 名单的生产起源及定性起因不明确，线上在排查问题时也只能干瞪眼，为了能回溯名单操作，须要做到如下几点： 写日志：任何写动作须要追加日志，且须要做长久换存储，不便做名单时序数据分析黑名单 & 白名单须要审计：尤其是线上独自增加这种，必须指明起因且要对操作负责跑批工作审计：离线工作或者算法推数等须要控量，否则在迭代更新过程中呈现 BUG 问题，导致名单数据猛增，结果不堪设想异动监控监控重中之重。 能第一工夫感知问题，监控的维度如下： 决策层面监控：灰、白、黑名单决策数量监控元数据产出层面监控：任何名单猛增或猛跌都是须要去定性是否失常拉黑踢白：没有永恒犯错的人，也没有永恒的坏蛋，名单之间的流动也须要关注总结名单服务在风控域中是最重要的子域之一，是风控流量的“网关”。名单库对整个风控决策的稳定性，性能晋升起到决定性影响。 同时名单服务也是“高危”的，如果使用不当，可能会给企业良好用户带来困扰，给那些“黑产”敞开门户，须要做好数据审核及异动监控。 往期精彩性能调优——小小的 log 大大的坑性能优化必备——火焰图Flink 在风控场景实时特色落地实战欢送关注公众号：咕咕鸡技术专栏集体技术博客：https://jifuwei.github.io/ > 若有播种，就点个赞吧

引言如果决策引擎是风控的大脑，那么规定引擎则是大脑内的重要形成，其编排了各种反抗黑产的规定，是多年反抗黑产的专家教训的累计，本文将向你介绍规定引擎的形成及实现。 背景什么是规定引擎？规定引擎能够帮忙企业将业务决策从利用程序代码中分离出来，并应用预约义的语义模块编写业务规定。这使得企业能够更灵便地治理和批改业务规定，而无需批改利用程序代码。 规定引擎能够承受数据输出，并依据业务规定解释数据，做出业务决策。这些业务决策能够是主动的，也能够是人工干预的。 规定引擎通常蕴含如下几个局部： 规定库：规定库蕴含了所有可用的规定。这些规定能够是事后定义好的，也能够是动静生成的。策略：用于治理规定，是对规定的条件组装，如评分卡策略、最坏匹配策略等。规定执行引擎：负责规定的执行。读取规定库中所有可用规定，依据规定的条件执行规定。为什么须要规定引擎？规定引擎能够帮忙企业更无效的治理和执行业务规定，进步决策的品质、效率和可靠性。 特点如下： 将业务决策从代码中剥离进去：经营人员能够更灵便无效的治理和批改业务规定，而无需批改业务代码，节俭反抗工夫进步决策品质：规定引擎依照业务规定主动做出决策，无需依赖人为干涉提效：规定配置好后，可永恒主动执行，缩小人力耗费稳定性：缩小发版，缩小测试，缩小人为谬误设计实现技术选型在抉择规定引擎时，须要思考如下几点： 业务需要：应该依据企业的业务需要来抉择规定引擎。如果企业须要疾速执行大量规定，则应抉择性能较高的规定引擎。技术平台：抉择与企业现有技术平台相兼容的规定引擎。如果企业应用的是 Java 技术平台，则应抉择反对 Java 的规定引擎。老本：思考规定引擎的购买老本、施行老本和运行老本。是否开源也是很多技术团队的抉择因素。可维护性：抉择易于保护的规定引擎，在须要时可能疾速批改和更新规定。市场占有率：抉择市场占有率较高的规定引擎，在须要时可能取得较好的技术支持和培训。技术支持：抉择提供较好技术支持的规定引擎，以便在应用过程中可能失去及时的帮忙。当然，如果人力足够，能够思考本人实现规定引擎亦可，自实现版本的规定引擎必定灵活性更高，然而在性能和稳定性上须要较长时间的验证和考验。 如下是市场上热门的开源规定引擎： 规定引擎简介JBoss DroolsJBoss Drools 是一款开源的规定引擎，反对 Java 和其余语言。OpenRulesOpenRules 是一款开源的规定引擎，反对 Java 和其余语言。Hippo Rules EngineHippo Rules Engine 是一款开源的规定引擎，反对 Java 和其余语言Apache FlinkApache Flink 是一款开源的流解决框架，也能够用作规定引擎Easy RulesEasy Rules 是一个基于 Java 的开源规定引擎框架，它提供了简略易用的 API，使得开发人员能够轻松地应用规定引擎。基于 Groovy 实现规定引擎Groovy 是一种动静语言，能够运行在 Java 平台上。因为 Groovy 的语法简略，因而能够通过应用 Groovy 来实现规定引擎。规定引擎术语规定（Rule）：规定是形容业务决策的规定或条件的语句。规定通常由两局部组成：条件和动作。条件是形容规定被触发的判断，动作是形容规定执行的操作。事实（Fact）：事实是形容业务场景的数据。事实能够是一个独自的数据项，也能够是一组数据。规定引擎会依据事实来触发规定。决策表：决策表是一种以表格模式示意规定的数据结构。决策表通常由多个条件列和一个后果列组成。当条件列的值都满足时，决策表就会触发后果列的规定。规定汇合：规定汇合是一种由规定组成的数据结构。规定汇合通常以树形构造存储，每个规定都有一个条件和一个动作。当条件满足时，规定汇合就会执行规定的动作。规定配置解析规定引擎最终是须要交付给经营人员去配置应用的，所以必须能满足灵便的配置编排，且易懂，能力最大施展它的威力。 规定配置阐明： 触发条件：任意一个、满足所有、自定义。其中自定义最灵便，用户能够应用条件表达式配置任意想要的触发与或条件变量（指标）：左值，指标是输出数据衍生、或查问、或计算所得的值比拟符：等于、不等于、蕴含、属于、大于、小于、空 等等阈值：右值，与指标计算所得值相比拟，如果比拟符关系成立，则认为命中以后规定默认值：当指标执行出错或者超时，默认返回的值策略配置阐明： 评分卡模式：根据每条规定命中所得分数之和，断定是否命中相应分数段的决策最坏匹配：只有有一条规定命中，则立刻回绝阈值：如果是评分卡模式，须要设置三个段位并且指定阈值性能调优决策引擎每天承载企业业务全副的危险决策，峰值 QPS 根本过万，然而风控的决策耗时须要足够的短，在不影响业务的状况下，尽可能快的返回决策后果，这是一大挑战。 从以往的调优教训来看，能够从以下几点来优化规定引擎： 并行执行规定：一次决策流中可能蕴含 N 个规定节点，每个规定节点蕴含 M 个规定，充分利用多核 CPU 劣势，施展最大威力，但同时须要思考多线程数据安全问题预加载指标：规定执行都是在内存中的，然而所须要的指标值往往都是须要调用内部零碎失去的，一是网络开销，二是指标计算开销。能够在执行规定集之前，全副预加载一次指标再缓存，这样执行时间接从内存取值就会快很多。然而须要留神老本问题（如付费指标，存储老本，架构复杂度等），废调用问题（前置规定已回绝）等等规定加载预编译：规定首次加载往往比拟耗时，此时最好能 warm up 一下，这样在流量进来后，即可立刻执行，然而应用预编译可能会减少零碎的启动开销工夫，须要做好相应的均衡工作规定执行优化：经营配置规定时可能不会思考规定执行程序问题，然而程序在执行的时候能够智能编排一下，通过退出 与或 及 程序 关系，尽可能的把大耗时和大老本的指标放在最初面执行，优先执行内存指标，万一命中则间接断言，后续指标则不会再执行，节俭了工夫。要做到这一点，须要对指标进行较为具体的归类及元数据管理，须要全域的数据配合，对风控这种须要大数据的接口来说是一大挑战。总结规定引擎在风控整体架构内的重要性毋庸置疑，它的稳定性间接关系到风控决策的性能、数据品质。同时，对经营来说，好的决策引擎是足够灵便，足够智能，满足规定数据编排需要，且能立刻失效上线，这是保障他们反抗黑产的前提，心愿本文对构建高效的规定引擎又较好的启发。 往期精彩●性能优化必备——火焰图●我是怎么入行做风控的●Flink 在风控场景实时特色落地实战 ...

本文首发于 DataFunTalk 公众号，受权 NebulaGraph 社区转发。导读：本文将分享图算法在风控中的利用。 明天的介绍会围绕上面四点开展： 图算法和风控简介图算法在风控的演变相应平台的心得展望未来分享嘉宾｜汪浩然，互联网行业资深风控和图计算专家。 图算法和风控简介什么是图算法——图论算法 图算法最早来源于图论和组合优化相干算法，在风控外面利用比拟多的基本上都是传统的图算法或比拟偏数学实践的算法，如最短门路发现，不同的账号和交易之间存在异样的最短门路，某些账号或设施存在异样的关联。另外，还有图的辨认，比方洗钱，会波及到异样的环路。 晚期图在风控的利用都是基于明确的数学构造定义，如果大家认真钻研这些算法，会发现有的算法是多项式工夫能够解决的，有些是多项式工夫无奈解决的，比方 NP-hard 问题。在团或圈的发现算法中，其实会用到一些近似算法。而且风控中有意思的一点是数学上定义得越严格，黑产绕过就越容易。比方黑产晓得你的目标是发现团，他会成心某几个设施少一两条边，那数学严格的定义就很容易被绕过。 什么是图算法——图机器学习 晚期业内是间接利用这套传统图算法到风控中，随着技术的倒退，图机器学习也开始利用在风控中。比方晚期自己在交易场景中落地了一个标签流传算法，它是一个 Transudative 推演式的算法（非演绎式）。 在事实利用中，很多时候咱们没有方法对黑白灰样本去做齐全准确的定位。那该如何利用相似社交网络的同质性（坏蛋和坏蛋关系近，好人和好人关系近）做团伙辨认？在风控场景，很容易通过强规定产出高准确率的样本，但覆盖率很低（低召回），那么如何裁减这些样本呢？ 此时标签流传算法和半监督技术就开始在风控中应用。图神经网络的半监督学习，其学习能力和鲁棒性高于传统图算法。有别于传统的图算法的自定义 Aggregate 和 Message Passing，随着图神经网络的倒退，也越来越多的利用到风控场景。 什么是图算法——图开掘算法 风控场景中应用到很多图开掘算法，如： 高密度子图，一些异样账号和异样行为对象之间会存在高密度子图。街坊域异样，异样节点、边、网络存在异样的形态（如星形散射状），即该账户的街坊域异样。简单网络，比方异样网络的度散布和失常网络的度散布是不同的。如有时开掘了一些团伙，能够基于 Degree Sequence 构建特色和模型。不同 Degree Sequence 散布的网络存在不同的个性，这能够领导咱们进一步构建拓扑相干特色。什么是风控 上图中的台词很好地概括了风控的工作，“人活一世，有的人成了体面，有的人成了里子，都是时势使然”。从事金融风控、交易风控，风控规定和算法是公司的外围竞争力，都须要窃密。有很多精彩的算法及落地不不便进去交换，可能很少有人晓得，但这都成了里子。风控同学也是甘于寂寞，一直地去进行各种反抗，同时也在钻研技术和业务。 互联网风控干什么 家喻户晓的羊毛党薅羊毛、账户被盗、盗卡、现金贷、“以贷养贷”、猫池、歹意退货、物流空包、各种各样的欺骗、杀猪盘等等，这些场景都属于互联网风控领域。 图算法和风控的相遇 为什么图算法和风控会相遇？黑产作案存在团伙性，一个人不可能靠一个账户就去作案，更多的时候须要多人多账户的协同。 团伙个性就会使黑产之间产生关联，这就引入了图算法。作案有相似性，但案件和作案人之间可能没有物理和空间关联，但在某些角度他们存在相似性（如行为）。风控也能够通过除了间接的关系外的点和点之间的相似性结构边。因为作案有相似性，这也是网络能够存在的一个条件。 还有一个起因是作案须要大量的账号和设施资源的配合，利益的驱动就会让黑产做更多的事件。作案须要老本，如手机、账号等。物以类聚，人以群分（同质性）。 以上这些就是图算法和风控相遇的起因。 图算法在风控的演变几个外围趋势 早年间风控尤其是风控策略，更多的是一个 Rule Writer。通过业务了解写规定，缓缓演化成算法模型。还有从经典一阶的 Velocity 变量变成了 Neutral Net Aggregator（前面会细讲）。传统的风控算法或规定只能看到相邻点的特色，当初能够通过神经网络计算 Aggregator。这也是从数学严格定义的网络结构到图神经网络、Strict Definition 到概率化的推断的演进过程。 自己曾求教过图灵奖得主 John Hopcroft，他在图的匹配还有自动机方面做了很多工作。过后问他，传统的图算法的钻研对当初的人工智能有没有什么帮忙？首先他感觉是没有的（可能是虚心），他谈到一个十分大的趋势，过来大部分都是严格数学的定义，当前会更偏差概率推断。这个趋势也很符合风控，数学上定义得越严格，越容易被黑产攻克。应用机器学习、图神经网络去进行学习，最终就是变成了一个概率的推断。 经典一阶的 Velocity 变量 传统的一阶 Velocity 能看到一个 IP 四周有很多的 Device 。要评估该IP 的危险，能够察看其相邻的 Device 的危险特色，如最近几天的交易登录统计，最近 7 天的交易笔数，一小时内同 IP 的交易用户数等，这些都属于一阶 Velocity。 ...

本文作者：郁昌存 来自京东科技-危险管理中心 一、背景/指标1） 风控智能化体系建设依赖大量深度学习/机器学习模型进行实时在线的危险辨认、智能决策。要求能够将算法模型疾速部署为在线服务，供决策引擎调用。 2） 风控决策引擎涵盖交易、领取、营销等外围链路，业务场景对决策零碎性能要求极高，均匀tp99<50ms。要求算法模型实时服务在高吞吐量下，仍能满足性能要求。 3）精细化经营大背景下，算法模型服务须要反对大促不降级，且不能通过横蛮加机器形式进步吞吐量。要求从技术及架构层进行改良，对算法模型在线推理性能有质的晋升。 二、平台整体概览 三、产品性能 四、在线推理模块设计方案本文次要以在线推理服务模块开展解说： 1. 多引擎反对形象底层，将不同框架实现、自定义脚本语言对立定义为引擎，引擎提供模型load、predict办法。 1）自定义脚本引擎：Python、Groovy。 2）机器学习引擎：Pytorch、Tensorflow、MxNet、XGBoost、PMML、TensorRT。 3）反对引擎动静扩大，接口继承实现load、predict办法即可。 2. 高性能1) 集成native引擎。 2）优化pyhton执行引擎，改变传统REST接口封装形式，躲避python GIL性能限度。 3）除推理操作外，其余流程全副异步化。 4）CPU精细化管制。 5) GPU实时推理反对。 3. 动静部署1）基于服务网关反对模型的动静发现、动静路由。 2）治理端配置模型服务信息，后告诉模型计算节点，节点进行模型文件下载、启动加载及服务注册。节点定时查看，校对须要上线/下线的模型。 3）对外提供对立jsf(公司外部RPC服务)/rest接口，基于业务+场景获取对应模型计算节点列表，进行负载转发。 4. 计算资源动静调整1）对模型计算节点进行资源分组，不同资源组配置不同规格机器资源（基于JDOS可轻松实现）。 2）模型可部署至1到多个分组上，反对单机器多模型混部，通过网关进行路由转发。 5. 灵便输出数据源反对反对实时加工数据，r2m(公司外部redis集群)、hbase数据源等作为模型输出数据。 五、在线推理模块实现1. 在线推理服务模块设计 2. 外围性能及实现1）网关服务注册及路由将单个模型服务形象为一个独立的微服务，因而可套用微服务技术架构。基于SpringCloud，应用nacos做注册核心、ribbon负载、feign做服务间接口调用。 2）模型动静部署▪治理端上传模型文件，配置对应的推理引擎，配置服务相干参数。 ▪定义模型适配器为translator，Translator接口蕴含preProcess和postProcess办法，别离对应模型的前置和后置数据处理。Translator实现类反对动静编译加载（groovy/字节码），治理端配置时，定义对应模型translator代码，模型加载时进行代码动静编译和注册，如此可实现灵便的配置化形式。 ▪服务节点通过事件播送、定时查看机制，更新拉取对应模型文件及适配器代码，执行模型部署。 ▪模型部署胜利后，将相干信息注册的服务网关，业务申请通过网关入口进行路由。 ▪模型调用过程： ▪对于模型输出数据，在translator前置解决（preProcess）中获取对应数据源/实时加工数据，汇总后进行数据对齐、标准化解决。 ▪数据喂给模型，应用对应推理引擎执行推理操作，失去模型输入后果。 ▪对于模型输入后果，在translator后置解决（preProcess）中进行模型输入后果解析提取、线性调整、解释加工等。 3）模型服务网关反对服务动静注册、发现，基于nacos服务发现。 反对模型服务负载、路由，基于feign+ribbon。 反对一键降级/限流，基于nacos配置核心实现。 反对A/BTest、灰度公布，从配置核心获取到服务节点列表后，通过配置规定做对应路由转发即可。 反对实时推理数据回落10K（公司外部大数据集群，反对MQ音讯管道落数），不便算法人员进行模型迭代验证。发送申请出入参数MQ，通过MQ落10K。 4）模型主动迭代提供python sdk，买通KuAI（公司外部一站式AI模型开发平台），模型推理数据通过MQ回落10K，算法同学通过KuAI提取数据加工，对模型进行迭代训练，验证实现后将训练好模型通过python sdk部署至算法服务平台，替换/灰度提供在线服务。 实现实时推理数据回落模型再训练模型版本迭代 流程自动化，基于此实现风控畛域主动反抗能力。 5）打通风控决策体系集成风控特色平台，反对食蚁兽（风控自研流式数据加工平台）、flink数据获取，反对hbase、r2m(公司外部redis集群)等数据源数据获取，解决模型输出数据加工问题。 无缝对接天盾风控引擎，反对模型疾速转换为决策引擎原子规定。 3. 在线推理性能优化1）集成native引擎集成罕用机器学习框架C++ lib库，通过native调用形式应用C++来执行模型的推理，速度飞快。 如何整合各个lib库，及其间接so包依赖？JDOS 容器化（JDOS是公司外部基于k8s的一体化利用部署平台），一遍趟坑，构建根底环境镜像，解决各种环境依赖，在此之上构建利用镜像。 2）优化python引擎调用形式因为python GIL（全局解释锁）的存在，同一时刻一个python过程只能应用一个CPU，传统通过flask封装Rest接口包装模型服务形式在高吞吐量场景存在重大性能瓶颈。 通过应用本地过程通信（基于socket），在计算节点启动多个python过程实例，由计算节点（java过程）对立管控python过程，通过多过程来躲避GIL限度，晋升CPU资源利用率。 3）模型计算资源动静分组因为网关的存在，模型分组就很轻松随便了，建设对应的路由映射关系即可。 能够通过不同模型对CPU/GPU要求不同、计算资源量、IO申请量、内存占用量等进行组合调配，实现机器资源的最大化利用。 4）线程池资源隔离，参数动静配置针对每个模型服务，建设独立的线程池资源和解决队列，这里很要害，后续很多优化都基于线程池和队列，相干配置（queueSize、batchSize、waitTime、workers等）可在治理端进行配置，模型加载时应用动静配置进行加载。 资源混部下，独立的线程池资源可管制每个模型最大资源使用量，避免单个模型服务流量异样对其余模型服务造成影响。 ...

作者：梁冬冬 危险零碎简单且又宏大，品质如何保障须要咱们付出一点一滴的致力来浇灌零碎之花 一、大促备战，求有序，求稳固： 大促是每年例行高考，把人和零碎的各项能力激发，掂量零碎强壮，容错性；凌晨3点的身影就像一束光，炫目夺目；往年的大促与今年不同，提倡绿色，节能减排，降本增效，把各种资源做到利用最大化，产生更大的价值，让大促备战产生了一丝温度 1）压测备战时间表（兼顾整体，从4.21-6.23咱们把剧本编制到细枝末节，是一条生命线） 2）服务器扩容缩容打算（节能减排，把资源利用合理化，让价值体现最佳） 3）系统优化清单（危险策略的一直减少、迭代，对系统是实时的挑战，通过一直优化零碎，让零碎轻松应答大促） 3）压测指标与评估（精准预估流量，通过流量复制模式生成相干压测数据，保证数据的还原水平，压测轮次缩小，压测品质不减，反而加强） 4）压测接口清单表（打算压测接口，压测轮次，分层分次，仅仅有条） 5）大促备战准则与标准（备战标准是咱们的方向标，原则，像大海中的指南针指引方向不能偏航） 6）备战注意事项（把惯例事项列举清晰，把事件做到最佳） 7）监控与看板（零碎危险的兜底计划，咱们监控的无力保障，最短的工夫发现、定位、解决问题） 8）备战待办事项清单（把大促工作相干待办项列举清晰，井井有条的进行开展） 9）备战会议室与经营（因为疫情，咱们把战场分成线上，线下相结合，提前做好筹备工作，打一场胜仗） 二、预警监控，求全面，求精准： 预警监控是品质的最初一道关卡，同时也是品质的兜底计划，咱们分外器重建设这块的能力。 预警全面性：预警分为业务预警、零碎预警、资源预警三大类，业务预警在三层最上端，也是对业务后果的测验检测，通过咱们长期对业务数据分析，对预警的阈值一直调优，对预警的等级分层等，业务预警的覆盖度一直显著晋升；整体配置预警1000+，业务预警的覆盖度稳步晋升，同比去年晋升56%左右，整体笼罩了外围场景。 1）梳理业务后果数据（对业务细化，业务相熟度更高） 2）接入危险洞察零碎（通过数据源接入到实时危险洞察实时计算平台） 3）配置数据集（通过sql配置不同的数据加工逻辑） 4）设置相干告警阈值（通过线上数据分析，得出精准的阈值论断） 5）手机相干承受人，预警等级，预警形式，预警信息等（把相干的干系人，预警的等级形式对立配置齐全） 6）测试预警触达（验证预警的有效性） 7）预警启用（启用后，正式经营告警） 8）通过设置预警机器人相干外围预警项，加强预警的监督与及时性（通过机器人经营，把利用负责人跟预警强关联起来，力保发现的线上问题，在最短的工夫内告诉到干系人，解决以及监督解决） 预警的精准度：晋升预警的精准度，是为了及时发现以及精准定位线上问题 以及 升高预警经营老本最无效的计划；通过咱们一年多来钻研业务预警，把危险零碎的业务预警拆分成多层，通过四分算法等机制曾经造成了一套标准化、统一化、流程化的预警经营的计划，至今事变级别预警精准度达到100%，准事变级别预警达到99.6%左右，高危级别预警在76%左右。 1）事变级别预警（精准度缺失无奈容忍block级别） 2）准事变级别预警（精准度容忍稍微缺失，精准度至多在99%以上） 3）高危级别预警（高危级别预警类比零碎精细化预警，容忍精准度缺失，考究覆盖度与精准度的均衡，精准度要求在80%以上） 3）高危级别预警（精细化经营类的告警，容忍有精准度缺失，80%以上） 三、自动化覆盖度，求效率，求变动 在不变中求变，在变动中不变；交付的品质与交付的效率自身是一件抵触的事，能够把抵触的事做成不抵触，要客服种种的艰难，不达目标不放弃的精力 挪动端篇：设施指纹是危险侧技术能力建设的重要工具以及伎俩，设施指纹会以SDK或者JS的形式嵌入到业务的app或者页面里，获取相干的危险信息，达成危险辨认的能力；设施指纹的自动化波及到两个方面： 1）设施指纹的稳定性：通过调研线上解体的区域，容易产生解体orANR的局部少数是来自于数据接口的交互导致解体，后期通过对业务的调用链路梳理，把相干解体危险的区域，做成了UI自动化，通过脚本管制手机，执行相干的业务逻辑操作，通过循环次数 以及 运行工夫管制反复操作来模仿操作，校验是否会呈现解体等异常情况；这块咱们曾经通过封装开源的工具，把执行脚本，采集相干logcat相干的解体或ANR信息打印到测试报告内，通过发邮件的形式，最终收集相干的报告后果，大大晋升了测试的效率的同时晋升了设施指纹的稳定性； 2）设施指纹的自动化：设施指纹自动化采纳UI模仿形式进行自动化，自动化有主控master通过散发的模式，把测试工作下达给每一台设施，最终造成分布式的执行自动化的成果，大大晋升了自动化的执行效率，同时也晋升了设施指纹的设施兼容性； 3）接口测试篇：危险零碎偏底层服务居多，决策业务的是否有危险之本。在危险侧开展接口自动化是为了更好的撑持业务，同时也是为了保障品质。为了响应公司的号召，为了达成反对业务最大化，往年开始陆续把自建的平台敞开，关停了一些ROI低的工作，把相干的业务自动化测试用例，陆续井井有条的迁徙到更佳优良的接口测试平台上，把自研开发平台的人力加到业务撑持，接口的自动化往年覆盖度从年初的18%到年中的40%左右，实现了主流程链路的笼罩，业务使用率达到32%左右，从行云里的数据来看，上半年无论是从测试交付的周期还是吞吐量都有较大的改善，真正的做到了自动化赋能业务，业务交付显著增长的后果； 4）精准评估需要影响范畴：需要评审、以及测试用例的评审是拉齐研发，测试，产品对需要认知的一场不错的会议，所以往年P0P1级别需要都要求强制用例评审，评审用例的同时，把大家的信息拉通，达成统一；往年，在需要评审会里，减少了一个环节，就是通过咱们自研的针对增量代码的（本次需要）链路剖析，以及影响的办法范畴，产出一份血缘关系图，在需要评审的同时，能够精准的圈定影响的范畴，让影响范畴更加量化，可度量； 5）度量测试品质：作为品质负责人，更关怀的是如何治理好品质，那么品质团队每个人测试品质的好与坏，或者也是须要度量，可把控；往年推动测试代码覆盖率的执行，通过字节码的形式，在测试人员执行用例的同时，能够精准的定位进去，测试用例笼罩代码的行数，来评估测试是否都笼罩全面，预先晓得可度量，可追溯； 6）策略测试自动化：策略测试是危险侧独有的一种测试场景，策略是分析师长期积攒的结晶，精髓，是危险人的智慧，策略品质的好与坏是对系统有牵绊的。往年通过与策略效力组共建测试平台，达成了从策略包测试，主动生成案例，再到策略包接口的流量复制，通过线上人造的流量验证策略配置的准确性，曾经造成了一套方法论并落地，往年会加大推广力度实现策略测试一体化，平台化，智能化； 7）混沌工程：混沌工程为大促而生，往年618非同寻常，主战场为线上线下相结合，在各种的不确定性中咱们寻求零碎的更加的稳固，强壮。往年引入了混沌工程，把一些外围依赖接口的超时，缓存异样，DB宕机，服务器资源各种异样模仿复现，预知了零碎危险，大促稳中求稳，一直求新； 8）UI自动化测试篇：UI自动化历经数年，UI自动化曾经绝对稳固，但业务的突飞猛进，对前端的一直变更，对UI自动化经营是个不小的难题。综合看，危险测的UI自动化达成的次要是不频繁批改的，主流程的，达成覆盖度100%。非核心场景的，常常变更的，由手工执行，做好UI的使劲分层，分类至关重要； 四、品质卡点与危险辨认，求全面，求品质 设置品质卡点，是质量体系的线上化的一种形式，说的直白点就是把危险侧质量体系相干的标准准则，通过线上化的模式，设置卡点或者实时预警，通过卡点或及时触达来躲避流程、操作危险等 品质卡点是咱们重中之重，组之大器，红线，底线，不可逾越。往年咱们优化了多处准则标准，为了加强大家的品质意识，造成无效的标准规定，无效的保障品质。 1）上线监控：无论是Jone、jdos、JCI上线都须要走严格的审批上线，杜绝逆风车，AB异样审批，不通过测试等等上线审批异样行为，通过把JDOS审批流信息接入危险洞察零碎，配置了相干的实时监控，把异样行为监控和盘托出，杜绝踩踏品质红线 2) 效率监控：测试交付的效率，交付的吞吐量是度量测试效率的重要指标之一，须要实时的发现问题，解决问题，做到每一个需要，每个人数据透明化，往年也是把效力交付周期配置了相干预警，当交付周期长时，相干的预警会触达效力小组的相干人，告知效率危险，有人对应跟进剖析，给出后果； 3）缺点与用例监控：测试用例，缺点都是测试人员的产出物，通过监控剖析这些数据，对当前识别系统好与坏，以及测试人员执行的状况最无利的撑持。 4）外围零碎上线评审：外围零碎上线评审是对系统上线的敬畏，往年外围零碎上线，咱们都会组织架构师、负责人等相干干系人一起评审业务，代码，以及影响范畴；减少一道上线评审，躲避品质危险产生； 5）测试用例强制评审：需要评审、以及测试用例的评审是拉齐研发，测试，产品对需要认知的一场不错的会议，所以往年P0P1级别需要都要求强制用例评审； 6）配置相干危险：配置变更、迁徙变更、规定批改、策略变更等等，配置类的公布是最容易漠视的区域，也是往年要纳入测试的领域的点，配置要通过测试并通过审批流程前方可上线； 7）排期危险：资源投入、倒排期、内部依赖、缺点解决工夫等等，都须要咱们关注，要保障我的项目需要进度无风险，按时交付，力保业务； 8）平安合规危险：数据泄露、泄露用户信息、诱导用户、敏感数据等等都是危险合规的重中之重，须要咱们在测试业务的过程中辨认进去这种危险，提出危险，躲避危险； 9）客户自损类危险：危险策略拦挡、企业授信放款、AB零碎连接、规定破绽等等都会产生相干的危险，在零碎层面把控危险尤为重要 10）零碎危险：零碎上线危险、零碎不稳固、性能不达标、依赖接口异样等等，在功能测试后，要全面评估零碎的影响面影响 的品种，提前做好预发预案； 还有未思考到的方面，欢送大家补充交换

本文作者：梁冬冬 前言： 明天你撸茅台了么？ 撸茅台曾经成为社会景象，茶余饭后探讨的最佳实际2022年双十一大促曾经完满收官，兄弟姐妹克服种种艰难与挑战.. 备战的会议室繁忙中带着缓和，当峰值过后的喜悦显而易见，往年备战室里听着对面的兄弟讲述了他抢茅台的通过，以及对马上降临的整点茅台流动期待，我也立马参加进去，然而....没抢到， 带着种种的疑难，百度了下网上抢茅台的种种伎俩与办法，发现外面的猫腻还真不少，同时作为危险人也想一直的通过各种技术手段辨认发现危险，让羊毛党无处藏匿；兴许，竞争对手比你设想中要更加的弱小， 明天就带你走近抢茅台的脚本，领略下TA们乏味的灵魂； 上面的列表是我总结网络上普遍存在的一些抢购的形式，这些形式的共性是：模仿单人或多人的操作行为，在最短的工夫内实现抢购流程； 类型形式热度先进性后端接口脚本http协定webUI脚本webdriverappUI脚本webdriver and 无障碍模式adb命令脚本adb协定一、webUI脚本解析:上面是一段网络上比拟常见的某宝的一种抢茅台的脚本，底层逻辑是： 模仿人点击操作门路，通过脚本重放，循环实现定时、自动化、多并发等操作，最终实现代码代替人工操作抢走商品；• 像人一样管制浏览器：脚本里是基于webdriver的一种浏览器驱动形式，能够通过驱动来管制浏览器施行管制页面操作，例如外面应用频繁的find\_elemnt\_by_id是通过页面ID辨认的（ID能够通过控制台元素定位获取到），find\_element\_by\_link\_text通过精准匹配页面上的文案，是辨识元素的一种形式；click（）是辨认元素后的鼠标点击动作； • 像人一样进入登录：脚本外面的run\_driver办法，外面调用了login\_in办法，外面的逻辑大略是模仿用户输出用户名+明码，点击登录按钮后，实现登录； • 像人一样的循环抢购商品：抢购茅台会有对应的抢购工夫，这里的times就是作者设定的抢购工夫，循环体外面会判断以后工夫是否大于等于times工夫，如果呈现大于等于后，会进入到第二个循环体，寻找下单的按钮而后进行点击操作；在点击胜利后持续进入到提交订单页面，通过link_text辨认文案，进行点击操作，最终胜利抢购商品胜利，进入到待付款页面；else，如果抢购后无奈结算，脚本会通过驱动从新关上商品页面，而后抉择商品，从新走判断工夫的逻辑，以上； 二、后端接口脚本解析上面的代码是之前GitHub很火的抢购京东飞天茅台jd_seckill脚本，一度被很多人应用（现我的项目曾经进行），底层逻辑：绕过前端UI，整体流程通过协定接口层串联，能够通过自定义管制抢购的速度，最终实现代码代替人工操作抢走商品； • 后端接口串联整体流程实现登录：通过登录拜访二维码页面、获取Token票据、校验票据，获取cookies • 串联接口实现抢购流程：点击“抢购”按钮后，会有两次跳转302，最初达到订单结算页面，这里返回第一次跳转后的URL，作为商品的抢购链接； 三、APPUI脚本 以及 adb命令形式 解析APPUI脚本形式 底层逻辑是：通过手机端（安卓、IOS或模拟器等）通过UI自动化工具或adb命令的形式管制app以及webview来模仿人操作，施行抢购的过程; • 间接进入商品抢购页面，通过adb命令操作抢购：os.system是py调用shell的一种形式，adb的全称为Android Debug Bridge，就是起到调试桥的作用； 通过adb shell input tap命令，能够管制手机操作点击手机区域（注：区域为传递的X，Y轴的坐标），通过这种形式能够间断操作手机进行抢购流动 appUI脚本攻击方式，是通过工具化的伎俩，例如Uiauto.js、uiautomator、appium等等，实现的手机管制app（内置的webviewH5须要联合webdriver）实现模仿人为操作，施行抢购； • setup办法：封装了驱动的一些必要参数，零碎的类型、设施名称、app包名、首页面流动页、应用的浏览器驱动的地址（H5）等等要害外围驱动阐明 • appium：此案例外面应用了appium工具操作，所以remote形式链接appium-server • 外围模仿门路：所有的操作门路，业务逻辑封装在test_search里，通过坐标点击 以及 H5页面的操作，在while True外面有限循环进行抢购商品 四、危险防守、辨认篇: 再高超的攻打伎俩，在智能风控背后下，都会毕露无遗，危险侧通过关联黑名单、设施指纹、生物探针、危险标签（群控、设施汇集性、陀螺仪、云手机等等）能够辨认进去人的操作轨迹，按压行为等等，可疾速辨认危险，锁定危险，打消危险；（注：因为机密性比拟强，此处不做过多具体阐明）

前言： 明天你撸茅台了么？ 撸茅台曾经成为社会景象，茶余饭后探讨的最佳实际2022年双十一大促曾经完满收官，兄弟姐妹克服种种艰难与挑战.. 备战的会议室繁忙中带着缓和，当峰值过后的喜悦显而易见，往年备战室里听着对面的兄弟讲述了他抢茅台的通过，以及对马上降临的整点茅台流动期待，我也立马参加进去，然而....没抢到， 带着种种的疑难，百度了下网上抢茅台的种种伎俩与办法，发现外面的猫腻还真不少，同时作为危险人也想一直的通过各种技术手段辨认发现危险，让羊毛党无处藏匿；兴许，竞争对手比你设想中要更加的弱小， 明天就带你走近抢茅台的脚本，领略下TA们乏味的灵魂； 上面的列表是我总结网络上普遍存在的一些抢购的形式，这些形式的共性是：模仿单人或多人的操作行为，在最短的工夫内实现抢购流程； 类型形式热度先进性后端接口脚本http协定webUI脚本webdriverappUI脚本webdriver and 无障碍模式adb命令脚本adb协定一、webUI脚本解析:上面是一段网络上比拟常见的某宝的一种抢茅台的脚本，底层逻辑是： 模仿人点击操作门路，通过脚本重放，循环实现定时、自动化、多并发等操作，最终实现代码代替人工操作抢走商品； •像人一样管制浏览器：脚本里是基于webdriver的一种浏览器驱动形式，能够通过驱动来管制浏览器施行管制页面操作，例如外面应用频繁的find\_elemnt\_by_id是通过页面ID辨认的（ID能够通过控制台元素定位获取到），find\_element\_by\_link\_text通过精准匹配页面上的文案，是辨识元素的一种形式；**click（）**是辨认元素后的鼠标点击动作； •像人一样进入登录：脚本外面的run\_driver办法，外面调用了login\_in办法，外面的逻辑大略是模仿用户输出用户名+明码，点击登录按钮后，实现登录； •像人一样的循环抢购商品：抢购茅台会有对应的抢购工夫，这里的times就是作者设定的抢购工夫，循环体外面会判断以后工夫是否大于等于times工夫，如果呈现大于等于后，会进入到第二个循环体，寻找下单的按钮而后进行点击操作；在点击胜利后持续进入到提交订单页面，通过link_text辨认文案，进行点击操作，最终胜利抢购商品胜利，进入到待付款页面；else，如果抢购后无奈结算，脚本会通过驱动从新关上商品页面，而后抉择商品，从新走判断工夫的逻辑，以上； 二、后端接口脚本解析上面的代码是之前GitHub很火的抢购京东飞天茅台jd_seckill脚本，一度被很多人应用（现我的项目曾经进行），底层逻辑：绕过前端UI，整体流程通过协定接口层串联，能够通过自定义管制抢购的速度，最终实现代码代替人工操作抢走商品； •后端接口串联整体流程实现登录：通过登录拜访二维码页面、获取Token票据、校验票据，获取cookies •串联接口实现抢购流程：点击“抢购”按钮后，会有两次跳转302，最初达到订单结算页面，这里返回第一次跳转后的URL，作为商品的抢购链接； 三、APPUI脚本 以及 adb命令形式 解析APPUI脚本形式 底层逻辑是：通过手机端（安卓、IOS或模拟器等）通过UI自动化工具或adb命令的形式管制app以及webview来模仿人操作，施行抢购的过程; •间接进入商品抢购页面，通过adb命令操作抢购：os.system是py调用shell的一种形式，adb的全称为Android Debug Bridge，就是起到调试桥的作用； 通过adb shell input tap命令，能够管制手机操作点击手机区域（注：区域为传递的X，Y轴的坐标），通过这种形式能够间断操作手机进行抢购流动 appUI脚本攻击方式，是通过工具化的伎俩，例如Uiauto.js、uiautomator、appium等等，实现的手机管制app（内置的webviewH5须要联合webdriver）实现模仿人为操作，施行抢购； •**setup办法：**封装了驱动的一些必要参数，零碎的类型、设施名称、app包名、首页面流动页、应用的浏览器驱动的地址（H5）等等要害外围驱动阐明 •**appium：**此案例外面应用了appium工具操作，所以remote形式链接appium-server •外围模仿门路：所有的操作门路，业务逻辑封装在test_search里，通过坐标点击 以及 H5页面的操作，在while True外面有限循环进行抢购商品 四、危险防守、辨认篇: 再高超的攻打伎俩，在智能风控背后下，都会毕露无遗，危险侧通过关联黑名单、设施指纹、生物探针、危险标签（群控、设施汇集性、陀螺仪、云手机等等）能够辨认进去人的操作轨迹，按压行为等等，可疾速辨认危险，锁定危险，打消危险；（注：因为机密性比拟强，此处不做过多具体阐明） 作者：梁冬冬

引言性能调优也是有迹可寻的，本文梳理了在理论开发过程中积淀的通用性能优化策略，并且联合风控系统服务内应用场景，帮忙读者了解性能调优相干可行策略，从而建设性能优化 SOP 概念，当前呈现问题即可参照优化流程革新即可。 性能优化策略 时空转换刷过算法题目的都晓得评分条件有：工夫复杂度、空间复杂度，两样耗费都很小的话，评分越高，即优良的算法。 但在理论开发过程中，个别二者不可兼得。要么占用空间小运行工夫长一点，要么谋求效率则占用空间就多一点。咱们要做的就是在特定的需要场景中，竭力优化其中的一方，此时往往须要就义另一方来达到目标。 空间换工夫在以后业务场景下，谋求的是极致性能，即响应速度要足够快，比方开屏页的关上速度，如果每次关上 H5 都去服务端申请页面的渲染数据，再加上用户所在城市不同，从纽约用户拜访北京，比北京本地用户拜访必定慢很多。那此时就有了 CDN 这种工具。运营商的 CDN 节点遍布寰球，页面在开发结束后，间接推送到寰球各地的 CDN 中缓存起来，这样用户拜访时只须要命中最近的 CDN 节点，速度自然而然就下来了，然而付出了空间的老本。 在风控场景内也有相似场景，决策引擎为了极致性能，也须要空间换取工夫： 配置数据缓存：决策流数据关联简单，如果每次都去和 DB 或者数据中心交互，I/O 耗时大，得失相当。本地缓存一道 + 更新触发反而是更好的抉择。短期缓存：热点信息且在一段时间内不会扭转的（或者能容忍一段时间不变的），接入缓存会更利于查问速度。工夫换空间此策略反其道而行，用工夫换取空间。此时，“空间比拟贵重”，比方内存绝对于磁盘来说就很贵重，然而寄存在磁盘内再调度起来应用时，须要肯定的工夫来获取。 在风控场景内，同样存在很多场景： 节俭空间老本：“云上”服务器绝对“云下”自建 IDC 机房是更贵的空间资源，所以风控将大量非实时的数据放在云下服务器计算，云上服务须要用的时候，须要付出肯定的调用工夫即可：跨机房调用（专线带宽争抢占用）须要额定多耗费 5~10 ms设施指纹采集数据压缩上传：风控依赖设施指纹，设施指纹是内嵌在利用 APP 内采集机器自身信息的 SDK，大量的设施信息如果不压缩上传会占用很多带宽，影响占用了失常的用户申请。压缩后，节俭了空间，然而付出的代价就是，每次都须要额定付出压缩/解压的耗时。预处理/后处理提前解决预处理次要是为了提速。比方 CPU 和内存的预取操作，将内存中的指令和数据，提前寄存到缓存中，从而放慢执行的速度。 决策引擎为了保障策略的执行 RT 管制到 200ms 内，须要优化压缩执行策略的工夫，假如一个策略再怎么优化，执行工夫也是超过 200ms 的，那此时能够在上一个事件（场景）提前触发预处理操作。 举例：用户发单时须要断定群组危险，但拜访群组是比拟耗时，那能够在用户进入发单前先触发查问群组信息并缓住，真正发单时间接读取上次后果即可。同样的，咱们能够在用户登录时触发一些操作，利于后续风控事件感知。 延后解决不到必要时刻坚定不执行，节省成本。使用这一策略最有名的例子，就是 COW（Copy On Write，写时复制）。假如多个线程都想操作一份数据，个别状况下，每个线程能够本人拷贝一份，放到本人的空间外面。然而拷贝的操作很费时间。零碎如果采纳惰性解决，就会将拷贝的操作推延。如果多个线程对这份数据只有读的申请，那么同一个数据资源是能够共享的，因为“读”的操作不会扭转这份数据。当某个线程须要批改这一数据时（写操作），零碎就将资源拷贝一份给该线程应用，容许改写，这样就不会影响别的线程。 延后操作在风控中次要为了节省成本，决策引擎为了极致的性能，很多变量（或者叫特色/指标）都是一次性并行加载的，但此时有的变量是第三方免费指标，比方 IP、同盾、蚁盾等，预加载的益处不言而喻，然而也极大的减少了老本：用户有可能还未走到付费变量决策节点时就被拒或者白名单间接通过，此时这部分用户提前申请三方就是极大的节约。只有真正走到付费策略时，才会去申请，此时老本最小。 并行/异步操作并行一个人干不完的活，那就多找几个人一起干！并行操作，解决效率高（前提是机器多外围），工夫大大缩短，极大缩短了 RT 工夫。绝大多数互联网服务器，要么应用多过程，要么应用多线程来解决用户的申请，以充分利用多核 CPU。另外一种状况就是在有 IO 阻塞的中央，也是非常适合应用多线程并行操作的，因为这种状况 CPU 基本上是闲暇状态，多线程能够让 CPU 多干点活。 决策引擎如果执行策略都是同步执行的话，几分钟可能都执行不完，使用并行，充分发挥 CPU 多个外围的性能，那么此时性能瓶颈就是最长的那块木板，只有专攻优化它就好了。 异步异步绝对同步来说，就是是否期待后果还是立刻返回。同步操作在碰到外部有大量 I/O 操作时，性能损耗极大，此时采纳异步操作，零碎的吞吐行会有极大的晋升。然而有利有弊，异步操作也减少了程序的复杂度，须要思考失败弥补等额定的操作。 此类场景在风控系统中也是随处可见： MQ 音讯：人造的异步解决，依靠于音讯生产机制削峰填谷个性，在大耗时操作动作，且业务不须要同步返回状况下，非常适合用音讯来解决，比方离线决策。埋点、监控采样：不在业务关怀的流程内发动的操作，为了不影响 RT，须要将额定的操作异步解决。缓存/批量合并数据缓存缓存的目标就是为了减速，这个咱们从学习程序语言开始就根本达成的共识，基本上各个系统内只有有性能思考的，多少都会用到缓存。咱们罕用的一些工具，也交叉了缓存的影子，比方： ...

引言本篇次要聚焦介绍风控决策引擎中决策树编排能力的构建。决策引擎是风控的大脑，而决策树的编排能力和体验是构建大脑的伎俩，如何构建高效、丝滑、稳固牢靠的决策树编排能力，是对风控决策引擎的一大挑战，本篇文章和大家分享一下过往构建心得。 背景任何零碎在初期构建必定不是往“一步到位”的方向去构建的，只是架构设计者尽量向前期可扩大、可保护的方向去搭建。好的底层设计，不怕产品前期疯狂迭代，且改变调整不便。蹩脚的“填鸭式”代码，可能在过后为了尽快实现了性能，最终也会逐渐倒退成“屎山”，保护老本越来越高，要么跑路，要么只能重整旗鼓。 MVP 小步迭代 1.0此阶段指标：最小化可行产品（MVP）；小布迭代，疾速上线；一人分饰多角色。 风控部门成立初期，人员少，短少 UED 和 前端，毕竟风控自身对视觉设计和前端不是刚需，次要是后端研发和策略经营反抗黑产即可。此时为了能尽快上线决策树性能，研发人员本着小步快跑的思维，间接在代码层资源目录 resource 下搁置决策树动态配置文件（具体实现在下文合成），每次更改都须要发版。自身引擎的构建也是不欠缺的，须要增加的性能很多，一周发个几版也是粗茶淡饭的事，此阶段大家也是能承受的。 “由静转动”2.0此阶段指标：无需发版，生产疾速变更；稳定性相干思考。 随着部门队伍的逐渐壮大，以及研发流程的标准，风控策略经营人员对于决策编排的响应时效和可视化能力需要越来越迫切，对于研发须要发版能力部署新的决策能力现状不满，黑产是高效的，然而研发发版又是须要编排和工夫的，大家都要发版，且集中在一个发版周期，策略周一提出的批改，待到周三和大家的需要一起上，此时黑产早撸完跑路了。同时发版是有肯定的危险的，出错了须要立刻回滚，此时又延误了策略上线的工夫。 基于上述，咱们思考到是时候凋谢生产环境间接可视化的编排决策树能力了，然而咱们没有前端的同学，找别的部门借可能又不相熟决策引擎这一套流程标准，沟通老本还高。那折中了一个计划：将动态配置文件挪到 DB 存储中去，且配置以文本字符的模式展示在前端即可，不须要简单的前端设计，只须要简略的表单文本框填充即可满足研发批改决策流的诉求。这样让本来动态的配置“动”起来，间接在生产可配置，大大提高了生产部署的效率。 可视化决策流编排 3.0此阶段指标：高效、稳固、智能的可视化决策树编排能力产品构建 接入风控的业务线越来越多，研发人员忙于危险场景对应的变量开发迭代，此时还须要分出一部分精力负责批改决策树。2.0 版本的决策树对经营来说就是一段字符串，不是一棵树，策略经营是没方法批改，也不敢批改，出错的危险太大。思考到整个风控的体量和模式曾经十分稳固了，也有肯定的工夫去思考将决策编排做成一个可视化的产品交付策略人员应用了，毕竟决策树的调整自身也是策略的职责之一，须要将此积淀为一个高可用的产品。 咱们参照了业内 BPMN 工作流的前端款式设计规范，摘取了在风控决策树种须要用到的元素，构建了本人的决策引擎智能编排能力，可视化的拖拽节点，可齐全交付给策略人员自行配置应用。 设计实现技术选型决策树，实际上就是一个变种 DAG（有向无环图），图中的节点在业务层面有不同的属性及性能。那么如何存储这个 DAG 构造呢？用二维数组存储，是不能满足节点属性及边属性要求的，一是边界没法定义，可能这棵树很大，二是假如属性由关联表来实现，就会很割裂，没法直观看失去。其实图能够用链表示意，链表的存储构造第一反馈就是 JSON 或者 XML 来示意。能够设想， 如果用 JSON 来示意的话，层级嵌套关系会十分繁琐，毕竟 JSON 是用来序列化数据用的，展现方面，还是 XML 增加属性更为不便直观。 数据结构举例繁难决策树如下如上决策树用 XML 数据结构示意如下： <?xml version="1.0" encoding="UTF-8" standalone="no"?><flow id="test01" desc="倡议决策流"> <!-- 开始节点 --> <start id="start"> <!-- 链接到下一节点 --> <link to="black01"/> </start> <!-- 名单节点 --> <nameList id="black01" desc="黑名单"> <!-- 名单属性：名单类型：黑/白/灰；畛域类型；适用范围 --> <field key="type" val="black"/> <field key="domain" val="10001,10002"/> <field key="scope" val="deviceHash,phone,uid"/> <link to="split01"/> </nameList> <!-- 分流节点 --> <split id="split01" desc="是否为微信渠道"> <!-- 条件分支 --> <condition order="0" desc="是" expr="system == 'wechat'" to="strategy01"/> <condition order="10" desc="否" to="strategy02"/> </split> <!-- 策略节点 --> <strategy id="strategy01" desc="微信专属策略"> <!-- 关联专属策略元数据 --> <field key="strategyGuid" val="25F7C71A5F834F24A12C478CEE4CB9EB"/> <link to="end"/> </strategy> <strategy id="strategy02" desc="非微信渠道策略"> <field key="strategyGuid" val="0FC8A95A4D6A4F169C77950BB4A98D80"/> <link to="end"/> </strategy> <!-- 完结节点 --> <end id="end" desc="完结"/></flow>上述数据结构十分直观的示意了以后须要绘制的决策树数据结构，相较于 JSON 的数据表现形式，XML 更灵便，扩大更不便，在横向和深度上能够有较好的均衡。 ...

引言互联网时代，万物互联，网络安全局势越来越严厉，平安是企业的基石，风控在企业中扮演着“警察”角色，使用各种技术和伎俩，爱护企业内的用户利益不受侵害。风控决策引是风控中台的入口，提供业务危险场景事件接入，可视化编排简单决策，丰盛的特色变量与场景辨认服务等性能。相较于须要开发背景及算法背景能力应用的传统风控引擎，本文介绍的决策引擎构建实现后无需开发背景甚至无需算法建模背景，作为纯正的策略经营即可配置利用到业务的决策中，实时反抗黑产。 决策引擎合成危险事件危险事件对应一个危险畛域，是针对特定业务事件畛域的具体形象，以不便策略经营人员治理畛域下反抗规定应用的。 举例：假如要对裂变类营销场景防控，如分享以后内容到朋友圈即可取得 88 元精美礼品一份，那么危险畛域能够大抵划分为发动分享（发动频率/舞弊）、承受分享（同人/群组/频率）、分享后领奖（频率/群组/归因群组），每一步对应的被危险特色不同，须要专有的策略部署防控。 决策流如上，风控团队人员和业务团队人员充沛沟通后，大抵曾经晓得了业务玩法的危险点，即能够明确划分出“危险事件”。那么如何高效且稳固的去治理以后畛域下的危险反抗策略，是对风控研发的一大挑战。 策略经营人员为了反抗黑产，每时每刻都须要变更防控伎俩，且时效性要高，即冀望立刻失效。那如何可能让生产改变平安且高效的部署到线上？晚期团队为了疾速迭代，应用 XML 模式更改，益处是扩展性高，害处不言而喻：只能研发代替策略人员批改决策流配置，策略人员不了解或者基本不太敢动 XML “代码”。 <?xml version="1.0" encoding="UTF-8" standalone="no"?><process id="p001" desc="×××"> <start> <condition to="split01"/> </start> ... <split id="split01" desc="×××"> <condition order="0" desc="REJECT" expr="1 != 1" to="end01"/> <condition order="10" desc="ACCEPT" to="split02"/> </split> ... <end id="end01" desc="×××" assemble="×××"/></process>随着团队的扩充，有了业余的 UED 和前端开发小伙伴退出，能够撑持咱们在视觉和操作上下功夫，参照业内的 BPMN 2.0 工作流设计规范，将干燥简单的 XML 代码 转换为决策流编排配置模式，大大增加了策略经营人员的反抗效率，也解放了后端研发人员，不必再去抠 XML 代码了而放心出错了。 1.策略组“策略节点”是决策流程上最重要的一个节点，外部关联了大量的反抗黑产的规定，其中波及了各个规定如何合作，决策后果如何输入等职责。在和黑产的反抗过程中，先辈们总结出了一套模式来疾速部署规定，成果最大化的反抗黑产，同时也不会“误杀”好的用户。 1.1.策略模式策略总共分成两种模式：评分卡、最坏匹配，如下我将具体为你介绍各个模式如何运作以及适宜的场景。 评分卡此处的评分卡并非指数据模型评分卡，而是专家评分卡，艰深一点讲就是根据专家教训，对命中不同规定加权得分，如果最终得分命中了回绝区间分段，则须要回绝。此类模式，对于晚期短少用户“黑标”，间接依赖专家教训，是一个不错的抉择。 评分卡是一个概率学问题，越黑的用户会命中越多的规定，所得的分就越多，即表明危险越高。举例：黑产为了反抗风控，会找大量的代理 IP 或者批改 GPS 定位来扰乱风控系统检测，同时也有“猫池”等设施提供海量手就号。然而当下有不少失常用户都有 2 台手机，且因为工作起因，频繁多地航行，即地理位置不停地变换，那么策略人员制订好的评分规定如下： 序号规定得分1是否异地102是否多设施登录103所有登录设施去重数大于等于 4204切换不同登录设施速度过快305账户提现异动40评分区间如下 通过人审回绝[0, 20](20, 40](40,∞]能够看到，失常的用户只会命中 0，有多个设施的用户（2 到 3 个）基本上得分在 20，也不会造成打搅。切失常的用户就算频繁的出行各城市间接，也不会说上一秒在上海，下一秒在广州了，反抗黑产还是有迹可寻的！ 最坏匹配“最坏匹配”有点相似于流解决概念中的 anyMatch，即只有有任何规定命中，则立刻回绝。此种模式内蕴含的规定属于十分确定，肯定是可解释的，如果命中，根本能够判定回绝本次申请的。如：同一设施既发动邀请又承受邀请，属于同人欺骗，显著不合乎流动规定，则可立刻回绝的。 抉择最坏匹配模式要谨慎，它是专家教训的凝聚，肯定是在生产环境屡次验证，召回和准确率较高，不会呈现“误杀”的状况，否则会遭逢大量被误拒的客户客诉，重大甚至妨碍业务倒退，品牌价值极大损坏。 1.2.策略拆卸策略是以后危险场景下某个危险点的形象，举例：在邀请危险场景下，能够有设施策略、手机号策略、群组策略等，策略包下是一个个规定，负责管理规定的生命周期。 规定规定是风控决策流中最小“原子”单位，规定的形成如下： 左值比拟符右值变量（又叫特色，指标等）>, <, =, >=, <=, 蕴含, 属于...常量/变量举例：在设施策略包中蕴含如下规定：所有登录设施去重数大于等于 4，则对照如下 左值比拟符右值登录设施去重数>=4规定组繁多的规定命中可能对用户的烦扰度比拟大，此时须要联结规定断定，即规定组，规定组能够编排与或计算逻辑：满足所有、满足一条、自定义，其中自定义反对简单的条件表达式 1 || (2 && 3) || 4，满足不同规定组合需要。 ...

引言常听到四周有人说“风控”这个词，只晓得这是一个神秘的部门，对他们做的事却只知其一;不知其二，只晓得这个风控部门对公司十分重要，任何流动和信息都最好向风控部门报备以评估危险，尤其波及到钱的问题。 到底什么是风控？为什么须要风控？风控到底在干什么？本文将向你解惑。 什么是风控风控，即危险管制（Risk Control），智库·百科定义如下 危险管制是指危险管理者采取各种措施和办法，毁灭或缩小危险事件产生的各种可能性，或者缩小危险事件产生时造成的损失。危险管制的四种根本办法是：危险回避、损失管制、危险转移、危险保留<!--more--> 以上信息是不是有种我如同明确了然而又没全明确的感觉，我将结合实际案例来拆分解说一下。举一个栗子，假如你退职一家规模还算挺大的在线交易电商平台，公司老板发表：咱们也得搞一个像马爸爸那样的“双十一”节日减少销售额，晋升利润，钱凭什么让他一个人赚去，咱们也要造势！那运营部的老大 get 到了老板的要求后，晓得来活了，立刻筹备搞各种形式多样的营销流动，怎么搞？砸钱！没钱没客户，用大优惠大折扣来造势！吸引用户过去，舍不得孩子套不着狼！此时风控的老大也 get 到了老板的要求，并且晓得经营的老大要搞事，连忙组织部门会议，切磋流动计划 危险回避产运部想来个流动：咱有钱，流动节日当天，来了就送现金！一人 3 元，无门槛，且可间接提现，豪横！风控部立马回复：不行，你这个流动不能上（危险回避），晓得这个危险有多大么，无门槛且来就送，万一黑产手上养了一批号，上来就给你薅秃了，而且他们速度十分快，能够间接用机器来代替人工，等真正的用户进来，啥也没了，一地鸡毛，不能上！ 损失管制产品一想也是，咱尽管老板拨钱了，然而好钢不能用在刀把上啊！万一钱被薅没了，平台没啥完单，我不完犊子了。流动降级：先造势，节日当天 3 元送现金只在 9:00 ~ 12:00 期间，且只给前 1w 名客户无脑送（损失管制），这样就算被薅了，流动金额上线就 30 万块，咱也损失不大，毕竟赚了一波人气。 危险转移产品部一个抖伶俐：咱们能够联和各大厂商做流动，在我领取 10 元，即可换购某某平台年卡会员卡（危险转移），当初那么多互联网平台须要拉新，咱们流量大，他们必定配合，而且他们应该也有风控的吧，不会出问题的。就算没有，咱们损失也不大，双赢。 以上的例子举得比拟极其，次要是让读者敌人们有个大抵的了解风控是什么。文言总结：风控是为公司省钱的，防止公司经济上有较大的损失。日常工作中次要是寻找并发现公司的经营流动中存在的破绽，且如果这些破绽不及时修复的话，可能会给公司带来重大经济损失及形象影响。 为什么须要风控如上你已大抵理解什么是风控了，风控对于企业的重要毋庸置疑，但不是所有企业都是须要风控的，目前咱们听到最多雇佣风控从业的公司要么是金融行业，要么是互联网那个行业，归根结底也是和钱相干的。 打个比方：如果企业是一辆行驶的汽车，那么风控就是安全带和安全气囊。车祸随时都能产生，然而产生的那一刻，安全带大概率能保障你的平安，甚至能救你的命。风控不是毁灭危险，而是和危险反抗，防止危险，或者将损失降至最小。风控和企业的业务场景是有摩擦的，有时为了平安，不得不做出肯定的业务斗争，就像安全带尽管能关键时刻保命，然而你就义了舒适性：只有上车你就得戴着。 咱们举理论的、实在的案例来阐明为什么须要风控： 案例一：薅羊毛某多多百元通用优惠券的营销推广呈现重大破绽，无论新老用户，都能够支付 100 元无门槛券，留神是支付，不是抢购。有网友通过接码平台充值了 54 万的 Q 币和 64 万的话费。有黑灰产团伙通过一个过期的优惠券破绽取数千万元平台优惠券，进行不正当牟利。流量时代的到来，越来越多的互联网企业站在风口上随风而起，竞争也变得越来越强烈，各家企业为了“抢人”，不得不发开发各种营销流动来刺激用户对平台的粘性，以期晋升 GMV 。此时，黑产伺机切入流动的玩法破绽，牟取暴利，导致企业损失惨重。 案例二：金融骗贷某头部互联网小贷平台，被黑产骗带金额高达数千万元。黑产通过产业链工具包含但不限于：设施多开、肉鸡、接码平台、通讯录养号等伎俩。胜利骗过平台设置的各种流动限度关卡，贷款后即刻删号，企业想追都没方法追。互联网金融的衰亡，即咱们熟知的小贷行业。暂且不管它对社会的好与坏，黑产就是瞄准了他比银行金融审核更轻，“人的信息”拿的更少的点，用技术冲破了企业设置的门槛，胜利的薅走了企业的资金。 案例三：水军某短视频平台主播点赞和转发翻新高，但都是僵尸粉某宝店铺单量成交笔数及成交额一个月翻新高。互联网催生了一批“刷子”产业，他们唯利是图，抓住平台的根据用户是否喜爱（看得多、买点多）的曝光机制，疯狂造就“爆款”。这严重破坏了竞争协定，对那些认证经营、认真创作的人十分不偏心。 风控在企业中扮演着“警察”的角色，它不会去毁灭危险，也没方法毁灭，然而危险来的时候，能辨认出危险，并且依照处罚级别，从轻到重束缚毁坏企业标准的用户，从而能让企业走的更好走的更远。 风控与黑产洞察黑产黑产群体组织分工明细，并且长于假装。黑产从业者有全职或兼职，在兼职人群中，有各行各业人员，识别难度大。同时黑产群体技术更新迭代迅速，能够在短时间内对厂商的防护伎俩破解并更新多个版本的舞弊工具。据不齐全统计，在这个宏大的彩色产业链条中，黑产从业人员已达数十万余人，每年给互联网公司造成的经济损失超过百亿元。说白了，这些人为了赚快钱，不择手段，通过新型的技术，来冲破传统的进攻伎俩，无往而不利。黑产罕用的武器有：虚构号码、代理 IP、设施伪造等等。每一种工具都对应一种攻打场景。 洞察风控在和黑产反抗的过程中，咱们总结了很多教训和教训，全流程笼罩业务玩法，从事前、事中、预先防控，业务全生命周期风控体系。风控的武器库有：设施指纹、生物探针（UBT）、智能验证码等等。 我是怎么入行的之前有别的部门共事问我：你是怎么入行的？认真思考一下，这是问题同样适宜所有行业，你是怎么入行金融的？医生？区块链？老师？我认真回忆了一下，我入行风控齐全是趣味。然而这个前提是我接触到了风控这个畛域。我刚工作所在的公司是搞金融的，过后我是一个后端开发，你能够了解为就是做产品研发的，那这个过程必定要和风控部门打交道的，对于公司非风控部门的人来说，对他们那帮人的标签都是：“最牛*的团队！外面都是牛人！”、“公司的借贷的逾期率，坏账率能放弃这么低都是依赖风控团队”、“不晓得他们在干嘛，很神秘”...在工作对接的过程中，也逐步晓得了风控是怎么玩的，比方上线一个流动，风控要求在参加流动、分享流动、支付处分、处分发放设置前置卡点，所有信息都调一次风控平台的接口，有风控断定以后用户是否参加流动。然而只能看出其型，不得其解：凭什么断定这笔单子不能过，须要回绝？ 本着进步本人和不服输的精力，咱也想成为最牛逼的人，我就会被动和对接的风控研发打招呼，询问不解的中央，长此以往，也大抵明确了其中的概念，在下一次跳槽时，我在简历中表明有风控教训，并且投给了招聘风控岗位的公司，侥幸的是遇到了违心给造就并有学习机会公司，从此真正算是进入了风控这个畛域。 给想入行的准备风控 er 的一些倡议风控绝对老师、医生、java 后端这种算是小众行业，在你不理解或者齐全没听过的状况下，你齐全是没有概念的，也就基本谈不上入职也说。如果你理解了后，想成为一个风控人的话，如下我是的一些倡议： 尽早进入这个对任何行业无效，尽早指的是应届生~工作 3 内之内，此时企业在招人的时候认为你还是“白的”，是可塑的，此时如果你对风控感兴趣，可间接向感兴趣的公司投简历，此时只管没有任何经验，然而企业是在储备人才，部门是在造就“backup”，成功率十分高。 跨部门转职很多共事都是在公司外部理解了风控这个职业，还真的有一小戳人真的转了过去，这绝对社会招聘更有劣势，最起码你进入公司时考核是过的，合乎企业的人才标注。惟一的要求就是你以后的 TL 违心放和风控的 TL 违心收。 风控所在的公司肯定是有肯定的市场规模的，往往说中大体量的公司才会思考接入风控，小公司个别也养不起风控团队，一是没有用户规模，没那么多钱，黑产瞧不上，二是风控研发的开销的确不是一个小公司能抗住的，老本会超过很多。 总结作为互联网安全从业者，回顾这几年走过的路，黑产的技术倒退和规模收缩给咱们带来了很大的压力，同时也让咱们有了更大的能源去构建更加无效的平安进攻产品体系。黑产也是人，他们也会提高，所以风控面临的挑战十分大，也欢送各位退出风控畛域，共创战争的互联网行业。 作为风控研发，我会在后续从 0 到 1 的分享风控的架构及技术细节，喜爱的欢送关注订阅，第一工夫收到文章更新。 ...

“危险存在于各个业务环节之中，攻打的可能是一个点，但攻破的却是一个面，因而单点的进攻达不到预期成果。”顶象反欺诈专家杜威在CCF TF第18期技术火线研讨会示意，顶象反欺诈计划笼罩了从客户端到业务端的全链路、从交互到到数据的全流程，可能无效保障业务平安的平安。 本期CCF TF的主题是“数据安全与危险防控”，来自顶象、小米、腾讯云以及武汉大学的专家，为近百位到场的企业一线技术研发人员及高校师生分享了数据安全与危险防控的利用前沿。 TF全称是Tech Frontier Committee（技术火线委员会），是CCF（中国计算机学会）2017年5月组织成立。通过多项丰盛的交流活动，搭建常态化的单干和倒退平台，促成企业之间、学术界与企业界之间的技术交换，晋升整体业界技术水平，帮忙企业界业余技术人士的职业倒退。 业务平安面临重大的欺诈危险随着企业的数字化转型的推动，裸露在互联网中的业务成为不法团伙的牟利指标。黑灰产利用自动化、智能化的技术进行盗号、刷单、薅羊毛、虚伪借贷等，给游戏、社交 、购物、金融等各行业企业造成极大威逼。猖狂的黑灰产给企业和社会带来了重大的负面影响，不仅侵害用户合法权益，节约企业资源，影响了业务运行，更给用户和企业数据带来重大平安威逼。 权威部门统计显示，网络黑灰产从业人员就已超过150万，通过上中下游的紧密分工构建起了一个密切协作的网络，市场规模达千亿。IDC认为，中国数字化转型及数字化原生企业将长期面临业务欺诈的严厉挑战。 杜威示意，黑灰产分工很明确。上游次要是技术开发，如制作打码平台、破解软件、伪造代理工具等；中游表演账号提供商和交易交流平台的角色，包含通过建设社群、倒退下线、提供供需平台等；上游则利用这些虚伪账号和工具等进行欺诈、偷盗、钓鱼、刷单、转售等各种类型的歹意行为，最终达到变现目标。 顶象反欺诈计划无效防备业务危险顶象反欺诈解决方案建了一套全链路、纵深入、多节点的业务平安防控体系，可能无效防备各类业务危险，保障业务衰弱运行。该计划是全链路纵深入进攻，多节点平安防护，防止攻打的单点绕过；采纳多维度进攻，无效拦挡各种非法行为；既无效拦截歹意欺诈行为，又不影响失常用户体验。 通过防备业务流程中呈现的交易欺骗、网络欺骗、盗卡盗号等欺诈行为， 顶象帮忙企业免遭各类欺诈威逼或蒙受经济损失，保障企业整体业务逻辑的顺畅。在IDC最新公布寰球首份业务平安技术报告《IDC创新者: 中国业务平安之反欺诈技术，2019》，重点介绍在业务反欺诈的三独创劣势： 1、顶象以业务平安为己任，构建了一整套成熟的业务平安设计理念和技术体系（编者注：顶象风控中台），已胜利在近逾千家企业落地；同时通过一系列市场行为推动业务平安理念的遍及，助力业务平安的倒退。 2、顶象领有全链路的产品体系：笼罩营销、交互、交易、领取、数据全生命周期场景，提供了营销反欺诈、申请反欺诈、交易反欺诈、账户平安和数据反爬等纵深防御能力。 3、基于人工智能的反欺诈技术：基于深度学习的关联网络技术，对操作行为和账户关系图谱的剖析，发现个体体征，开掘群体画像，实现危险门路的可视化，帮忙企业无效防备复杂多变的各类危险。 截止目前，顶象反欺诈解决已在银行、生产金融、基金理财、领取、互联网金融、电商、航旅、O2O、教育、游戏等数十种业务场景的逾千家企业上运行，日进攻数亿业务危险。

近期，针对娱乐内容行业的政策出台，在此前清朗口头的根底上，相干部门对泛娱乐内容产品和平台提出了明确的要求和配套措施。各平台除了认真盘点自家危险，做好凋谢社区的内容风控和违规内容荡涤外，还需搭建起业余、精准、高效的内容平安防护系统，全流程把控内容危险，及时应答“灰犀牛”和“房间里的大象”。 因为各个凋谢内容平台的业务场景不同，平台的抗危险能力高下不齐，行业内风控规范又未造成对立，对于平台方和运营者来说，灵便度高、具备针对性的内容风控解决方案将有助于加重平台内容合规的压力。 一图理解内容风控防护计划

01 背景内容风控，这个词近年来越来越被人们所器重，只有你想做好一款产品，内容风控环节必不可少。无论新闻内容、教学内容、电商图片、社交评论、直播点播、用户头像等，任何带有内容流传，内容公布属性的场景，都应该要有对应的风控形式。 腾讯云对象存储作为互联网数据内容的基石，在内容风控方面也从没有漠视。此前，为帮忙互联网开发者、运营者们打造平安、绿色的网络环境，推出了一站式内容审核能力。对象存储的内容审核能力是蕴含了图片、音频、视频、文字的全方位智能审核服务，一经上线，即冲刺到当今互联网内容风控畛域的领先地位。 随后，腾讯云对象存储在内容审核方面一直深耕，将高精度、高并发、全方位作为主旨，在近期，行业内首发推出了重磅审核性能——文档审核！ 02 文档审核文档蕴含的格局多种多样，如 演示文档：pptx、ppt、pot、potx、pps、ppsx、dps、dpt、pptm、potm、ppsm文字文档：doc、dot、wps、wpt、docx、dotx、docm、dotm表格文档：xls、xlt、et、ett、xlsx、xltx、csv、xlsb、xlsm、xltm、ets其余格局文档：pdf对象存储将文档解决能力与内容审核相结合，造成了一站式的文档审核服务。 通过事后对文档进行解决，将文档转换为可辨认数据，继而进行审核操作。 03 文档审核应用形式文档审核通过规范的 COS API 发动。蕴含发动审核工作和查问审核工作两步。 1、发动审核工作用户只需指定好文档所在的链接地址及须要审核的场景（反对审核色情、暴力暴恐、守法违规等场景），即可发动文档审核工作。 2、查问审核工作通过发动工作时获取到的工作 ID，用户能够间接查问对应工作ID的文档审核后果。 审核后果中蕴含了审核是否胜利、整篇文档审核解决倡议、违规文档页面及页面中的命中的关键词等。 04 文档审核劣势提供高保真的文档预处理能力，免去了用户本地对文档的预处理流程；文档解决后，应用前沿的辨认算法，针对文档中的图片、文字等进行审核；涵盖目前对象存储内容审核所有的审核场景；有最优老本、高性能、秒响应的个性，无效保障用户审核体验。05 结语文档审核的推出既是咱们在内容审核方面的一直冲破，也是咱们以用户为本的证实。咱们始终在您最须要的中央筑牢有形的城墙，用积攒与积淀为数据保驾护航。 未来咱们也会不忘初心，为您提供更平安的云服务！