共计 6531 个字符，预计需要花费 17 分钟才能阅读完成。
摘要：本文整顿自众安保险大数据平台开发高级专家郭育波在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含：
- 整体详情
- 智能营销利用
- 实时特色利用
- 反欺诈利用
- 前期布局
点击查看直播回放 & 演讲 PDF
一、整体详情
上图是咱们的实时计算整体架构图，最上层是数据源层，包含了来自于利用零碎的业务数据、利用零碎的音讯数据、用户行为埋点数据以及利用日志数据，这些数据都会通过 Flink 进入实时数仓。
实时数仓分为三层：
- 第一层是 ODS 层，数据通过 Flink 到 ODS 层后会关联一张原始表，这个表是和数据源一一对应的，而后会有一个视图表对原始数据进行简略的荡涤加工；
- 之后，数据通过 Flink 下发到 DWD 层，DWD 层是基于主题域进行划分的，咱们当初划分为用户数据域、营销数据域、信贷数据域和保险数据域等；
- 另外还有一部分是 DIM 层，蕴含用户相干、产品相干和渠道相干等维表数据，DIM 层的数据会保留到 HBase 中。
通过 DWD 层的数据荡涤之后，数据下发到 DWS 层，DWS 层会对数据进行整合汇总，个别会有指标宽表和多维明细宽表。之后这些数据会进入 ADS 层，这一层蕴含多样的 OLAP 数据存储引擎。咱们当初次要应用 ClickHouse 作为大盘实时报表的存储引擎，还有 HBase 和阿里云的 TableStore 为用户标签和特色工程提供数据存储服务，还有 ES 次要用于实时监控场景。
上图是咱们的实时计算平台架构图，整个实时计算平台能够分为三个局部。第一局部是工作治理后盾，在工作治理模块外面编辑和提交工作，工作编辑器同时反对 Flink SQL 和 Flink JAR 工作，提供了比拟便当的 Flink SQL 编辑性能和调试性能，也反对多种工作启动策略，比方基于 checkpoint、offset、工夫点和最早地位等，还反对定时和即时生成 checkpoint 性能。工作提交之后，会通过 Flink 客户端将它提交到咱们自建的 CDH 集群里。工作治理服务也会定时从 Yarn 获取工作的实时状态。
监控方面，Flink 会把指标日志数据推送到 PushGateway，Prometheus 获取 PushGateway 这些指标之后会在 Grafana 进行数据的可视化展现。除了对工作异样的状态监控之外，咱们还会对资源使用率、音讯积压等多种状况进行实时告警。此外 Flink 还反对了比拟多的 connector，比方阿里云的 ODPS、TableStore 和 Hologres，也内置了丰盛的 UDF 并且反对用户自定义 UDF。
上图是咱们实时计算平台的工作编辑器，能够看到它反对 Flink SQL 和 Flink JAR 工作，SQL 工作反对 DML 和 DDL，它们能够一起在编辑器外面进行整体工作提交，工作治理这块同时也反对每一次变更的版本治理。此外，还反对比拟多的高级工作配置性能，有 checkpoint 配置、音讯 Kafka 的并行度和状态治理等。
二、智能营销利用
接下来，重点介绍一下 Flink 在智能营销利用场景的应用状况。
营销平台的架构图的最上层也是数据源层，包含金融业务数据、保险业务数据、用户行为数据、第三方平台的数据和经营后果数据。离线数据通过 ETL 的形式进入离线数仓，实时数据通过 Flink 的形式进入实时数仓。
实时离线数仓之上是标签服务层，平台有对离线 / 实时的标签治理性能，同时咱们也会对这些标签进行治理管控，比方数据权限的管控，此外，还有标签数据的监控，可能及时发现标签数据的异样，精确把握标签应用状况的剖析统计。
标签层之上是标签应用层，咱们有营销 AB 实验室和流量 AB 实验室，它们之间的差别在于，营销 AB 次要居于客群进行营销，无论是基于规定进行客群圈选的动态客群还是通过 Flink 接入的实时客群，都会对这些客群进行流程化的营销和智能的触达。而流量 AB 实验室也是基于标签的数据服务能力，用于 APP 端千人千面的个性化举荐。平台还提供了客群画像的剖析性能，能够疾速找到类似客群和客群的历史营销的数据成果状况，可能更好地帮助经营对于客群的甄选和营销。
通过营销 AB 和流量 AB 试验之后，会有一个成果剖析服务来进行实时成果回收，通过成果剖析能够及时辅助经营团队进行疾速的策略调整。
目前，标签总数曾经达到 500 个以上，营销工作执行数量每天会有 200 万左右，流量 AB 每天会有 2000 万以上的调用量，次要是给前端提供了资源位的个性化显示和千人千面的业务场景。
上图是智能营销平台的数据流图，右边是数据源，有来自于业务零碎的业务数据，也有埋点、事件数据，这些数据通过 Kafka 达到实时数仓，通过实时数仓的加工后，一部分会变成实时标签，被保留在阿里云的 TableStore，还有一部分会被加工成实时客群，同样也会发到 Kafka，而后由营销 AB 实验室对这些实时客群进行智能的营销触达。
另一部分离线数仓加工进去的标签数据，咱们应用 DataX 作为 ETL 的工具，将它们同步到 Hologres，Hologres 可能无缝对接 ODPS，并利用其和 ODPS 关联表面的减速能力，实现了百万级别每秒的数据同步。经营人员能够在营销平台自助的进行客群圈选，利用 Hologres 的交互剖析能力，能够反对简单的客群的秒级生成。
整个营销平台的特色能够总结为三点：
- 第一，实时画像。通过定制标准化的实时事件、数据结构，利用 Flink 实时计算的能力，实现自动化的实时标签接入；
- 第二，反对比拟智能的营销策略。能够让用户间接在营销平台上进行组件化的营销流程的配置，提供丰盛的工夫策略，还有各种智能的营销通道，同时也反对灵便的、多分支的业务流转，应用一致性哈希分流算法进行用户的 AB 试验；
- 第三，实时剖析。对营销功效进行实时剖析，咱们也是应用 Flink 实现实时成果回收。通过漏斗的剖析和业务指标的功效剖析能力，可能更好地赋能给营销业务。
三、实时特色利用
特色工程次要服务于金融风控场景，比方决策引擎、反欺诈、风控模型服务等。特色工程次要的目标是将原始数据转换为更好的表述问题实质的过程。应用这些特色能够进步咱们对一些不可见事物预测的精度，金融业务场景就是应用这个特色来进步对用户危险的辨认能力。
特色工程是整个数据挖掘模型里最耗时也最重要的一步，它为金融业务全流程的风控提供了外围的数据撑持，次要分为三个局部：
- 首先是特色开掘，次要由风控策略和模型开发的团队来实现，他们会依据业务指标进行数据的剖析解决，而后再提取出无效的合规的特色；
- 当特色开掘进去之后会给到开发团队，特色开发团队依据这个特色的起源会对接不同的数据源，有些是来自三方的，有些是离线加工进去的，还有实时加工的，当然还有一些机器学习模型进行再次加工计算出来的特色；
- 开发好的特色会通过特色中台提供给线上的业务应用，同时也要保障整个特色链路的稳定性。
特色工程目前应用的 Flink 实时工作有一百个以上，产生了一万个以上的特色数量，每天会有 3000 万以上的特色调用。
金融风控特色的外围指标，最重要的是合规。所有的特色都是居于合规之上，之外还须要保障特色加工的准确性、特色数字的实时性、特色计算的疾速响应，还有整个平台运行的高可用和稳定性。
基于这样的指标要求，咱们采纳了 Flink 作为实时计算引擎，应用 HBase 和阿里云的 TableStore 作为高性能的存储引擎，而后通过微服务化的架构实现整体的服务化和平台化。
特色平台的架构图总体能够分为 5 大部分。上游零碎有前台零碎、决策零碎和爱护零碎。业务方所有的申请都会通过特色网关，特色网关会依据特色的源数据进行链路编排，有些要调用三方数据，人行征信数据，还有一些来自数据集市的数据。数据接入之后就会进入特色数据的加工层，外面有对三方数据的特色加工服务，也有对金融实时特色数据的计算；还有一些反欺诈的特色计算服务，其中蕴含关系图谱以及一些名单特色的服务。
有些根底的特色通过这一层加工之后，就能够提供给上游的业务零碎应用了，还有一些须要通过特色组合服务进行再次加工。咱们通过一个低代码编辑器来实现特色的组合服务和风控模型服务，通过机器学习平台来进行特色的从新加工。
根底服务层次要是做特色的后盾治理和实时监控。实时特色须要依赖实时计算平台，离线特色依赖离线调度平台。
总结来说，特色平台是以微服务化构建的一个特色服务体系，通过接入三方数据、征信数据、外部数据、实时数据、离线数据进行特色加工和服务，组合成的一套特色计算的风控数据产品。
上图能够很清晰地看到实时金融特色数据的流向。数据次要来源于业务数据库，有前台、中台等各个业务零碎，通过 binlog 的形式发送到 Kafka，数据中间件 blcs 可能把 binlog 转换到 Kafka。用户行为的数据间接发送到 Kafka，通过 Flink 进入到实时数仓，通过实时数仓的数据计算之后，会把多维明细数据写入到 TableStore。
最早咱们应用的是 HBase，前面出于稳定性的思考，咱们应用了 TableStore 进行了一个技术升级。最初思考到特色服务对稳定性的要求比拟高，咱们还是保留了两个存储，HBase 作为降级存储来进行应用。
因为金融特色是要求可能形容用户全生命周期的数据服务，所以不单要求实时的数据，还要求全量的离线数据。离线数据是通过 DataX 回流到 HDFS，再应用 Spark 的离线计算能力回流到在线存储引擎 TableStore 里。
当初，风控对于特色的加工越来越要求精细化了，比方支用金额这样简略的一个特色计算，就可能会要求蕴含半个小时、近 3 个小时、近 6 个小时、近一天、7 天、15 天、30 天等各种业务的窗口。如果应用实时计算会产生十分多的窗口，而且全量数据的计算也会造成 Flink 吞吐能力降落。所以咱们的实时工作次要是做数据的荡涤和简略的整合，之后还是会把这些明细数据回流到存储引擎，而后通过利用零碎的特色计算引擎进行配置化的特色加工。
风控特色的场景还是比拟固定的，基本上是从用户身份证、用户 ID 或者用户手机号等维度来进行计算，所以咱们就形象了一套用户实体关系关联表，蕴含身份证、手机号、设施指纹等用户 ID 的 mapping 关系表，业务数据应用 userID 进行维表关联存储，通过实体关系加业务数据两个维度来进行用户明细数据的查问。得益于 TableStore 提供的高性能点查能力，咱们能够解决高并发的特色计算。有些特色不单应用到了实时数据，还会调用业务零碎的接口来获取数据，须要实时数据，接口数据进行聚合计算来实现，这样导致无奈在 Flink 中实现所有的特色计算。所以 Flink 只是进行明细数据的加工和聚合，再由特色计算引擎来实现特色后果的计算。
当初咱们的实时特色计算次要是居于实时数仓 DWD 的数据联合特色计算引擎实现的，DWD 的数据会回流到阿里云的 Tablestore，而后通过配置化的形式实现特色的加工计算。为了节约查问老本，咱们的计算粒度都是居于特色组的维度，一个特色组只会查问一次数据源，特色组和特色是一对多的关系。
这里简略形容下特色的计算过程：首先会依据特色的查问条件把相干的明细数据都扫描进去，而后依据特色组下的具体的特色配置比方工夫粒度，维度应用自定义的统计函数进行特色计算，而如果是多个数据源须要 join 来计算的话，先把依赖的特色因子计算实现后，再实现下一步的特色计算。此外如果咱们的自定义函数不能满足计算的需要，零碎也提供了居于 Groovy 脚本进行特色加工的形式。另外还有局部的特色起源源是来自业务零碎的接口，这样只须要把第一步数据获取从查问 Tablestore 切换到调用接口即可，如果有其余的特色数据源也能够通过实现规范数据接口就能够实现，特色的计算引擎不须要做任何调整。
四、反欺诈利用
上图是实时反欺诈特色利用的数据流图，它和金融实时特色服务的数据流图有些相似的一面，但也存在一些差别。这里的数据源除了会应用业务数据外，更关注的是用户行为数据和用户设施的数据。当然这些设施数据和行为数据都是在用户许可的前提下进行采集。这些数据通过 Kafka 之后，也会进入 Flink 进行解决。反欺诈的数据次要是用一个图数据库来存储用户关系数据，对于须要历史数据的简单特色计算，咱们会在 Flink 外面用 bitmap 作为状态存储，联合 timerService 进行数据清理，应用 Redis 进行特色计算结果存储。
GPS 的反欺诈特色是应用 TableStore 的多元索引和 lbs 函数的能力来进行地位辨认的特色计算。反欺诈的关系图谱和关系社群会通过数据可视化的能力来提供给反欺诈人员进行个案考察。
咱们把反欺诈特色归为 4 大类：
- 第一类是地位辨认类型，次要是基于用户的地位信息，加上 GeoHash 的算法，实现地位会聚特色的数据计算。举个例子，咱们通过地位会聚特色，发现了一些可疑用户，而后再通过反欺诈考察查看这些用户的人脸识别的照片，发现了他们的背景很类似，都是在同一家公司进行业务申请。所有咱们就能够联合地位类的特色，加上图像识别的 AI 能力来更精准地定位相似的欺诈行为；
- 第二类是设施关联类，次要是通过关系图谱来实现。通过获取同一个设施的关联用户的状况，能够比拟疾速地定位到一些羊毛党和简略的欺诈行为；
- 第三类是图谱关系，比方用户的登录、注册、自用、授信等场景，咱们会实时抓取用户在这些场景的一些设施指纹、手机号、联系人等信息，来结构关系图谱的邻边关系。而后通过这样的邻边关系和用户关联的节点度数判断是否关联到一些黑灰名单用户来进行危险的辨认；
- 第四类是基于社群发现算法实现的统计类的社群特色，通过判断社群的大小、社群外面这用户行为的体现，来提炼统计类的规定特色。
上文提到比拟多的关系图谱特色都是用图计算引擎 (NebulaGraph) 来进行存储的。咱们测试过比拟罕用的是 janusgraph 和 orientdb，然而当数据量达到了肯定数量级以上之后，就会呈现一些不稳固的因素和状况，所以咱们尝试应用了图计算引擎，发现它的稳定性相对来说比拟高，因为它采纳的是 shard-nothing 的分布式引擎存储，可能反对万亿级别的大规模的图的计算。它次要分为三大部分来进行组合服务：
- graph 服务，次要负责图实时计算；
- meta 服务，次要负责数据管理、schema 的操作和用户权限等等；
- storage 服务，次要负责数据存储。
同时 Nubula 还采纳了计算存储拆散的架构，无论是计算层还是存储层都能够独立进行克隆，同时它还反对传递计算，缩小了数据的搬迁。无论是 meta 层还是 storage 层，都是通过 raft 协定来实现数据的最终一致性。
另外 NebulaGraph 也提供了比拟丰盛的客户端的接入形式，反对 Java\Go\Python 等客户端，同时也提供了 Flink connector 和 Spark connector，可能很容易地和当初支流的大计算引擎集成。
关系图谱的实现门路分为 4 局部：首先是图的数据源。要想构建比拟有价值的关系图谱，肯定要找到精确丰盛的数据进行图建模。咱们的数据源次要来自用户数据，比方手机号、身份证、设施信息、联系人等相干数据都会同步到关系图谱外面，除了实时数据，这里也会通过离线 Spark 工作荡涤历史数据。NebulaGraph 提供的查询语言反对了丰盛的图函数，比方相邻边、最大门路、最短门路等。社群发现咱们是通过 Spark Graph-X 来实现的，最初通过 API 的形式提供数据服务，进行图数据库的利用，咱们当初有间接提供给决策引擎来进行图数据特色的服务，也有对反欺诈的一些数据服务，甚至之后能够思考用于营销的基于社群的举荐算法。
五、前期布局
将来，首先咱们要夯实咱们的实时计算平台，实现实时数据的血缘关系的治理，还有尝试 Flink + K8s 的形式实现资源的动静扩缩容。
其次，咱们心愿可能基于 Flink + NubelaGraph 进行图谱平台化的建设，目前实时计算和离线计算是 Lambda 架构实现的，所以咱们想借 Flink + Hologres 实现流批一体来尝试解决这个问题。
最初，咱们会尝试在风控的反欺诈业务场景应用 Flink ML 来实现在线机器学习，晋升模型开发效率，疾速的实现模型的迭代, 赋能智能实时风控。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
