共计 9373 个字符，预计需要花费 24 分钟才能阅读完成。
导读：随着企业数字化转型降级，线上业务出现多场景、多渠道、多元化的特色。数据因素价值的开掘堪称争分夺秒，业务也对数据的时效性和灵活性提出了更高的要求。在宏大扩散、高并发的数据起源背景下，数据的实时处理能力成为企业晋升竞争力的一大因素。明天分享的是众安金融实时特色平台实际。
上面的介绍分为四个局部：
- 众安金融 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 架构。
实时特色平台的零碎架构
咱们实时特色平台的架构根本如上图，上游业务通过特色网关进行特色的查问，特色网关会进行特色查问权限的验证，限流管制和特色查问工作异步散发，特色网关首先依据特色元数据信息路由到不同的特色数据源，从特色数据源查问到原始数据之后会再路由到不同的特色计算服务进行特色的加工。三方特色是从三方数据平台和征信网关查问到的原始报文数据之后加工成为对应的特色；业务特色计算用于加工外部业务零碎的实时特色。
信贷特色是通过实时业务数据同步后进行特色加工计算，离线特色服务是在离线数仓 MaxComputer 实现的特色加工计算。反欺诈特色计算用于对用户登录设施信息，用户行为数据和用户关系图谱等相干特色的加工。
在根底的三方特色，业务特色计算实现后，就能够间接提供给上游业务应用，此外模型服务也会依赖这些根底特色，模型特色计算是借助机器学习平台的能力来实现的，咱们的机器学习平台提供了模型的训练，测试，公布等一体化性能，特色平台集成了机器学习平台的能力从而实现了模型特色的自动化和配置化。
实时业务特色计算详解
特色实时计算计划选型
我感觉实时特色计算计划有两种，第一种实时同步原始业务数据，而后在实时计算工作同时实现特色的加工，这是传统的 ETL 模式，这种形式的长处是特色查问十分高效、查问性能好，然而实时工作计算简单，须要大量实时计算资源，须要特色衍生的话也是比拟艰难；另外一个形式是实时同步原始业务明细数据，然而特色加工是即时进行，也就是说特色查问时再进行特色的计算，这样形式特色查问计算沉重，须要高速特色查问引擎反对，然而实时工作比较简单，特色衍生也比拟不便，这个较新的 ELT 模式。出于咱们业务对于特色频繁衍生的要求和节俭实时计算资源的思考，咱们抉择了第二种 ELT 的即时加工特色的计划。
实时业务特色数据流
实时特色数据流通过 Kafka+Flink 实现实时数据的同步，同时也应用 Spark 从离线数仓数据回补实现全量时序数据的采集，实时业务数据次要是用 TableStore 作为存储引擎，联合实时特色计算引擎和 ID-Mapping 的多主体查问能力实现了特色的配置化生成。
除了通过 Flink 实时采集的数据外，还有局部数据须要调用业务零碎的接口来获取，这种数据也能够注册为特色数据引擎的元数据，和存储在 TableStore 里的数据一样进行配置化应用。咱们采纳了阿里云的 TableStore 这个比较稳定的高速查问引擎来反对实时特色查问，然而其实云产品的老本也须要思考的，所以大家也须要依据自身的现状抉择适合的计划。
实时数据外围数据设计
因为咱们存在多条产品线，每个产品线的用户主键也都不同，而金融业务场景次要是以用户身份证，用户手机号等维度进行特色的查问，因而咱们形象了一套用户实体关系的 ID-Mapping 表，实现了身份证、手机号等维度到用户主键的关联关系，特色查问时首先会依据特色入参查问 ID-Mapping 表获取用户 ID，而后再依据用户 ID 查问用户业务明细数据，次要的业务明细数据蕴含用户授信数据、支用明细、还款明细、额度明细、逾期明细的用户业务数据。
这里咱们踩过的一个坑是主副表同时更新的场景，咱们把主副表存储为一份特色数据，咱们次要是应用 column family 的形式存储数据，所以在高并发的场景，可能会造成主副表同时更新带来的不统一的状况，咱们当初是通过一个窗口工作实现数据的弥补。
下图是次要的业务数据图：
实时特色计算引擎
晚期的特色加工是通过开发人员写代码来实现的，随着特色需要减少，为了撑持特色的疾速上线，咱们借助表达式语言和 Groovy 实现了一套基于特色计算函数的特色配置化能力，联合 ID-Mapping 实现了一个特色计算引擎，计算过程能够分为如下几步：
（1）创立实时 Flink 工作把用户关系数据同步到 ID-Mapping 表，从而反对用户多维数据查问。
（2）创立实时 Flink 工作把用户业务数据回流到阿里云的 TableStore，实现业务明细数据的实时同步。
（3）在特色平台的实时特色配置页面把上一步同步到 TableStore 的用户业务数据表注册为特色计算引擎逻辑数据。
（4）接下来在特色计算配置页面抉择相干的特色元数据，填写特色根底信息，特色加工的函数，通过测试和上线等过程后这个特色就能够提供在线应用。
（5）特色查问时首先会依据特色查问入参查问 ID-Mapping 表获取用户 ID，而后依据用户 ID 查问 TableStore 外面的用户明细业务数据，特色计算引擎会把依据配置的特色计算表达式进行特色数据查问，计算出来的数据后果就是特征值，就如第四步提到的，会把特色组上面的所有特色都计算出来。
反欺诈场景的特色利用
反欺诈特色分类
随着金融欺诈危险不断扩大，反欺诈局势也越来越严厉，特色平台也不可避免的须要反对反欺诈特色的查问需要，上面是咱们对反欺诈特色分类的总结：
（1）用户行为特色：次要是基于埋点的用户行为数据进行特色的衍生。比方用户启动的 APP 的次数、页面拜访的时长，还有点击的次数和在某个输入框输出的次数等。
（2）地位辨认特色：次要是基于用户的实时地理位置信息，加上 GeoHash 算法能力，实现地位特色的数据计算。
（3）设施关联特色：次要是通过用户关系图谱来实现，通过获取同一个设施下关联到用户的状况，能够疾速地定位羊毛党等欺诈行为。
（4）用户图谱关系特色：通过实时获取用户在登录、注册、授信、支用等要害业务场景的设施信息，联合用户三要素和他的一些联系人信息，构建图谱关系，而后通过查问用户的邻边关系、用户关联的用户是否有黑灰名单的状况，进行危险辨认。
（5）用户社群特色：通过判断社群的大小、社群里用户行为的体现，提炼社群规定特色。
实时反欺诈特色数据流
反欺诈特色计算的数据流程和实时特色计算数据流程相似，除了数据源来源于实时业务数据外，反欺诈场景更关注是埋点的用户行为数据，抓取的用户设施数据，提取的用户关联关系数据，用户行为的数据会通过埋点平台（XFlow）上报到 Kafka，这些数据也会应用 Flink 进行实时加工计算，不过和实时业务特色解决的区别是反欺诈特色是在实时数仓外面间接计算好之后存储到 Redis，图数据库等存储外面，这个是为了满足反欺诈特色查问的高性能要求，此外反欺诈场景也更关注实时的数据变动。从上图能够理解到，反欺诈特色通过 HTTP API 的接口方式为特色网关提供特色计算服务。
关系图谱架构图
用户关系图谱的建设状况，整体设计思路如下：
（1）首先是对于图的数据源的抉择，要想构建比拟有价值的用户关系图谱，肯定要找到精确的数据进行图建模。关系图谱的数据源次要来自用户数据，比方手机号、身份证、设施信息、用户三要素，联系人等相干数据
（2）第二就是图数据存储引擎选型，须要关注的是引擎的稳定性，数据的实时性，集成的方便性，查问的高性能，存储引擎的抉择十分重要，当初市面上有不少图数据库的技术，选型的过程中其实也碰到过不少的坑，一开始咱们抉择的 OrientDB，在大数据量的状况下就呈现了很多不稳固的问题，所以须要重点思考大数据量的解决能力和存储引擎的稳定性，肯定要通过全面的技术调研能力进行生产的实际.
（3）其次就是须要思考图数据相干的算法撑持能力，除了根本的相邻边查问能力，是否有比拟丰盛的图算法反对，比方在反欺诈场景应用到的是社群发现算法
（4）最初须要通过 API 的形式提供图数据服务，反欺诈利用场景提供图数据特色的服务外，还能够赋能给营销举荐场景
通过多方位的选型调研，最终抉择了 NebulaGraph 作为图数据库，它采纳的是 shared-nothing 的分布式存储，可能反对万亿级别的一个大规模的机型的图的计算。NebulaGraph 的相干信息能够从他们的官网理解，这里就不赘述了。
反欺诈图特征提取
通过模型团队对用户关系图谱的数据挖掘，从用户社群的年龄散布，生产预估程度散布等多维度统计数据登程，咱们提取出了一些图特色，这边列举了一批以供大家参考：
（1）第一方欺诈：通过图认为同一个人申请屡次，而且每次提交的联系人等关联信息都不太统一，能够认为它是有第一方欺诈的嫌疑。
（2）疑似中介代办：有局部人的申请人都关联到了雷同一个联系人的手机号。
（3）疑似信息冒用：就是一个人的手机号可能被很多人应用，可能它呈现了信息的泄露。
（4）疑似团伙欺诈：看关系图谱社群节点的规模数量是否超过了肯定的规模。
反欺诈策略规定。通过一两个特色可能没方法准确地对反欺诈行为进行定位，须要来组合多类的特色，造成反欺诈策略规定，从而在多方面晋升对用户反欺诈辨认的准确度。
问答环节
Q1：Flink 的源数据由 Kafka 输出，那平台是否能实现多条 Kafka 音讯之间的关联查问？
A1：整个实时业务的采集咱们是应用 Flink 实现明细数据的荡涤，把 DWD 层的数据回流到 TableStore，而后通过实时特色计算引擎来实现数据的关联，设置多个计算因子，而后通过这种形式把多条数据进行关联，反对最终特色的产生。比拟少在 Flink 外面进行这个数据的关联 Join 查问，也就是当初比拟风行的 ELT 的模式。
Q2：特色实时计算计划，贵公司抉择计划 2，在变量很多的状况下，怎么保障接口响应的效率？
A2：特色计算是基于特色组维度，一个特色组上面可能会有几十上百个特色，咱们当初的这个计算框架次要性能的耗费是在对于特色原始数据的查问，只有把原始数据查问进去，特色口径计算都是在内存外面实现。那么就须要有底层高性能的查问引擎来反对，咱们当初依赖于阿里云的 TableStore 查问引擎来实现疾速的数据查问能力。
Q3：求教一下，应用无监督的异样检测算法，比方孤立森林或者 LOF，应该怎么解决 APP 埋点行为数据，怎么提取特色会比拟有成果？
A3：对于模型的算法不是我在行的，我的了解是能够从特色品质和特色算法指标动手，然而没有通用的一个解决方案，要依据理论的业务数据进行算法的验证和调优，才可能失去答案。
Q4：关系图谱的社区发现算法有什么无效的成果评估办法吗？而后这边个别采纳的社区发现算法是哪种？
A4：当初采纳的是联通重量算法。咱们关系图谱不只是在反欺诈特色计算应用，也给反欺诈团队来做反欺诈考察应用，他们会依据有欺诈嫌疑的用户，对咱们的关系图谱进行反向的验证，通过理论的调研来看算法的成果。
咱们是应用 Spark GraphX 的连通分类算法，通过找到子图顶点 ID，连通重量算法计算每个子图中的每个顶点所连贯的最小顶点值，而后应用同一个顶点 ID 下所有的节点 ID 组合生成一个新的 ID 作为社群 ID。
Q5：贵司大量依赖图性能实时计算反欺诈变量，那目前性能存在瓶颈吗？
A5：次要取决于图社群的图关系数据量，如果是查问一般的用户，整个用户的节点不会有太多，基本上会在十个节点以内。然而如果这个人的确是中介或者说有反欺诈嫌疑的用户，那他的子图会十分大，的确会呈现查问上的性能超时的状况。利用到反欺诈场景，咱们会设置兜底计划，比如说反欺诈的图特色接口响应超过了 100 毫秒，咱们就会默认让这个用户通过，尽量不要去影响用户实时的业务体验。
Q6：反欺诈的特色跟指标的区别是什么？
A6：反欺诈的特色更关注用户的行为特色，更偏差于对用户行为的开掘。
Q7：数据量级是多少？实时特色工作的执行时长大略是多少？离线计算工作的时长是多少？能够介绍一下吗？
A7：当初咱们每天特色的查问量会在八九千万的级别。实时特色的实时工作时长，依赖于 Flink 的实时能力，在几十毫秒之内就能够实现这个数据的同步。咱们的特色查问依赖于阿里云 TableStore 的能力，每次的特色查问也都在 100 毫秒左右，所以性能还是比拟有保障的。
Q8：Flink 计算实现后，实时特色查问可能缺失吗？
A8：是有可能缺失的。因为当初是监听 Binlog 的形式实时写入的，如果在业务高峰期，特地是在有些跑批业务场景的这个状况下，可能 Binlog 的数据量十分大，那咱们整个实时数据的采集耗时可能比平时要更长。比如说这个用户在授信过程后马上进行支用的话，他的一些授信的数据还没有齐全及时地写到在线查问引擎，可能这一次的实时查问就会有缺失的状况。
Q9：特色计时计算场景下长窗口特色进行计算时会不会存在效率问题，而后是如何解决的？
A9：咱们当初的存储其实还是基于用户维度的存储形式，主键是用户的 userID，那咱们会通过 TableStore 的 range 查问的形式，把用户相干的所有数据都查问进去。其实在金融场景，不像电商或者内容查问的业务场景，一个用户的交易数据、业务数据并不太多，其实不会存在有太大的效率问题。
Q10：特色的维度如何界定？会有一些少见的数据作为维度吗？比方优惠券 ID 等。
A10：优惠券 ID 等可能在营销场景有不同的维度和特色。在风控业务场景，特色维度基本上基于人维度的，比方用户身份证、手机号，还有用户这个组件的维度，比拟少见基于这种优惠券 ID 维度的特色。
Q11：有深度网络方面的特征提取吗？
A11：当初还没有这方面的摸索。
Q12：在理论利用中，Flink 最大的计算工夫窗口有多大，是否超过 48 小时？
A12：这个会有超过的，最大窗口的范畴会在 3 天。然而实时特色场景，窗口基本上不会太大，个别是分钟级别。对实时性要求不高的一些特色场景，咱们能够反对在 3 天的窗口。这个比拟消耗资源，这种状况会比拟少。
Q13：请问目前上线的实时模型占比多吗？而后遇到过什么问题吗？
A13：如果绝对于整个特色体系来说的话，是不多的。然而咱们的模型笼罩了整个金融业务畛域，营销场景其实也有，具体数量可能不太好走漏。
当初咱们遇到的问题次要是特色的开发衍生和理论的线上化的特色利用是由两个团队去开发，之间的实现会有些不统一的状况。在模型开发的时候，它依赖的是离线的特色开掘。那在生产时候咱们是用实时特色的来去作为模型的入参变量，数据会有所差别，对于模型的 PSI 稳定性就会有一些影响。
Q14：线上线下的一致性如何解决？
A14：这是个十分大的话题，当初比拟风行的流批一体化的计划也是在尝试解决这个问题。从我的了解来说，首先 Lambda 架构可能要做一些调整，通过数据湖的形式来实现离线实时的同一份存储。引擎方面要对立和存储方面要对立，当然这个老本会比拟大。最初就是特色口径的开发，在特色开掘开发的时候的口径间接利用到生产中，基于对立的口径进行生成利用，那这样能力达到和之前特色开发口径统一。
Q15：实时特色如果获取不到或者返回很慢，线上模型或者决策引擎怎么解决？
A15：这个是会常常碰到的一些问题。比如说模型和决策引擎依赖特色是三方的特色，那在三方不可用的状况下，咱们须要去怎么解决。这种状况要看咱们对这个特色的依赖状况，如果是强依赖，那咱们可能期待这个实时特色可能胜利获取，而后再跑真正的模型和策略。如果是弱依赖，那在模型的开发的时候，就会思考这种状况，会用其余的特色或者其余的形式进行解决。那决策引擎同样也是如此，能够定制不同的决策规定来躲避这种状况。
明天的分享就到这里，谢谢大家。
谢谢你读完本文 (///▽///)
欢送返回 GitHub 来浏览 NebulaGraph 源码，或是尝试用它解决你的业务问题 yo~ GitHub 地址：https://github.com/vesoft-inc/nebula