备案控制台
文档
产品文档
输入文档关键字查找
首页 图计算服务 GraphCompute 实践教程 打车营销风控解决方案

打车营销风控解决方案

更新时间：
一键部署
提交缺陷
产品详情
我的收藏

本文介绍某打车营销风控场景，通过图计算服务GraphCompute提供解决方案。

业务场景

某打车营销风控场景是需要挖掘司机乘客以及司机之间的联合刷单作弊行为。当一笔打车订单完成后请求风控服务，判责此单是否存在司乘、司司联合刷单行为。该业务场景需要建立司机、乘客、订单等多种关系的图数据，然后提供实时图查询和分析能力。

  • 需求是已知乘客的多个手机号、多个设备号等，和已知司机的多个手机号、多个设备号等，计算司乘之间订单数，如关联订单数 > x，则认为司乘之间有刷单作弊嫌疑。

  • 构图路径：手机号/设备号-乘客ID-订单-司机ID-手机号/设备号。

客户需求

免运维：快速搭建实时风控系统

数据对接：基于大数据平台MaxCompute的对接能力

业务需求：图模型快速构建、发布上线

性能要求：需要保证实时数据更新效率，线上访问延迟低

建模设计

乘客或司机可能更换不同的手机号、设备号和账号（ID）进行刷单。当一笔打车订单完成后，此时拥有乘客的ID、手机号、设备信息，和司机的ID、手机号和设备信息，需要先利用司乘设备或者司乘手机号等等查找出历史所有关联的ID，再把司乘ID之间关联的订单列表找出来。涉及到的查询有：

1. 根据乘客（司机）ID查找乘客（司机）历史所有手机号、设备号集合；

2. 根据乘客（司机）手机号、设备号集合查询到乘客（司机）唯一ID集合；

3. 再根据司乘唯一ID集合，查询关联的订单集合；

具体设计图拓扑：

图拓扑

根据上述关系图构建出1个实体表和8个关系表；

  1. 子订单实体表：kv索引类型

    1. pkey主键：子订单ID

    2. value：其他属性

  2. 关系表：kkv索引类型

    1. 乘客->订单表

      1. pkey：乘客uid

      2. skey：订单ID

      3. value ：其他属性

    2. 订单->乘客表

      1. pkey：订单ID

      2. skey：乘客ID

      3. value ：其他属性

    3. 乘客->identity表

      1. pkey：乘客uid

      2. skey：手机号;设备号;支付账号（由这三个信息组合成键值）

      3. value ：其他属性

    4. identity->乘客表

      1. pkey：手机号;设备号;支付账号（由这三个信息组合成键值）

      2. skey：乘客uid

      3. value ：其他属性

    5. 司机->订单表

      1. pkey：乘客uid；

      2. skey：订单ID

      3. value ：其他属性

    6. 订单->司机表

      1. pkey：订单ID；

      2. skey：司机唯一ID

      3. value ：其他属性

    7. 司机->identity表

      1. pkey：司机唯一ID；

      2. skey：手机号;设备号;支付账号（由这三个信息组合成键值）

      3. value ：其他属性

    8. identity->司机表

      1. pkey：手机号;设备号;支付账号（由这三个信息组合成键值）

      2. skey：司机唯一ID

      3. value ：其他属性

产品解决方案

基于图计算服务GraphCompute支持毫秒级查询风控特征，统一风控特征开发/验证路径，提升百倍特征迭代速度，进而提升了业务风险防控的灵活性。

MaxCompute+Flink作为图计算服务GraphCompute数据源，在提供实时查询数据能力的同时，能够支持长时间周期（周/月/半年）特征聚合，支持秒级新增风控特征。

风控系统架构

业务价值

打车风控系统通过单一图计算服务GraphCompute支持，从而简化系统运维复杂度，产研更加聚焦业务价值。

1、完善实时风控规则防控，提高了风控规则的时效性，避免了延迟带来的资损。

2、新风控规则的生效周期由DAY天级变成MIN分钟级，增加了风控时效性，降低业务作弊情况，更利于正常运营推广。

3、一站式图计算服务的解决方案，大大降低业务研发的过多投入，一人即可完成图实例构建和图接入。

4、基于图计算服务新引擎赋能oneID同人防控业务，搭建风控中台，赋能全局业务。

核心技术点

1）大数据快速迭代能力

  • 强大的离线数据处理能力能够让大数据量（TB）规模的全量更新时效变成MIN分钟级

  • 实时更新链路能够支撑起百万级别的更新消息低延迟

2）智能运维系统

  • 一站式的图计算服务生命周期管理，单人轻松玩转图数据

  • 强大的智能运维会根据业务特点自动进行存储优化，计算节点和存储节点之间的动态资源分配让整个系统的运行效率更高，同时保障高可用

3）计算下沉

  • gremlin 计算逻辑下沉到searcher，提升计算效率

具体场景实现

打车营销方案中需要识别的作弊情况：1）司司联合作弊；2）司乘联合作弊；

针对这两种场景的代码实现如下：

1.司司联合作弊

第一次查询：查询司机mobile，driverId，IDFV，IDFA，IMEI 1天内关联的所有订单。

第二次查询：获取这些订单中，乘客是司机的订单集合。

查询示例：

司机mobile: 138000

司机IDFA: hadsjflkhadlsgfag

司机IMEI: adfladfnahjahjkdf

代码实现及访问方式：

g.E("mobile_138000;idfa_hadsjflkhadlsgfag;imei_adfladfnahjahjkdf").by("driver_identity_union_id")

.outE().by("driver_cp_order") // 司机设备关联订单集合

.inV().by("cp_order") // 订单详情集合

.filter("order_create >=1634221076929") // 过滤1天内订单

.filter(__.outE().by("cp_order_passenger").outE().by("passenger_user_id_identity").outE().by("driver_identity_union_id")) // 过滤乘客是司机的订单

2.司乘联合作弊

查询乘客的mobile，IDFV，IDFA，IMEI 与司机mobile，driverId，IDFV，IDFA，IMEI 1天内关联的订单集合。

查询示例：

乘客mobile: 138000

乘客IDFA: hadsjflkhadlsgfag

乘客IMEI: adfladfnahjahjkdf

司机mobile: 139000

司机IDFA: nmyasdoykk

司机IMEI: pdasfhahkjnlad

代码实现及访问方式：

g.E("mobile_138000;idfa_hadsjflkhadlsgfag;imei_adfladfnahjahjkdf").by("passenger_identity_user_id")

.outE().by("passenger_cp_order") // 乘客设备关联订单号集合

.inV().by("cp_order")// 乘客订单详情集合

.filter("order_create >=1634221076929") // 过滤1天内订单

.where(outE().by("cp_order_driver").outE().by("driver_union_id_identity")

.values("identity").is(P.within("mobile_139000;idfa_nmyasdoykk;imei_pdasfhahkjnlad")))

文档推荐
  • 本页导读 （0）
文档反馈