51 信用卡金融风控场景下实时计算引擎的设计与实践的总结

51 信用卡金融风控场景遇见的痛点:

场景:

风控模型计算（实时的授信出额、信用卡评分准入、反欺诈审核流程）

以前的流程

以前的研发主要存在两个问题 严重影响模型的交付速度和质量

hivesql挖掘变量 然后再核对数据源和变量,生成grovy实现 和在线灰度运行 与hive产出的变量和模型分数对比，然后上线

存在的两个问题
1、在线和离线数据源不一致 2、在线和离线变量实现逻辑不一致

解决问题的过程

光锥首先完成了在线 / 离线数据源的统一,做数据快照,基于快照做离线挖掘
在变量计算方面，为了复用模型人员提供的 HiveSQL，减少代码翻译,引入sparksql，
但是对实时性要求较高的授信及订单准入场景,spark不适合。
需要一个高性能 SQL 计算引擎，而且最好能在一定程度上兼容 HiveSQL
主要的风控变量计算任务并不是一个典型的 Streaming 场景、sparkStreaming 和 flink 被pass

使用Calcite支持异构数据源查询

Calcite支持异构数据源查询，比如数据存在es和mysql，可以通过写sql join之类的操作，
让calcite分别先从不同的数据源查询数据，然后再在内存里进行合并计算,
Calcite 并不兼容 HiveSQL, 但它对工业级的 SQL 高级特性有较好的支持,

计算引擎要在业务上兼容 HiveSQL, 不管是选择 Flink 还是 Beam 都需要对 Calcite 做二次改造和扩展，
考虑到 Calcite 本身的简洁设计以及较强的扩展性，
我们决定直接基于 Calcite 二次开发，实现一套在业务上兼容 HiveSQL 的本地实时 SQL 计算引擎

改造 为了支持 HiveSQL 的语法和操作符  

    1、使用 JavaCC 来做语法解析 支持部分的 Hive 语法 如 rlike、regexp 
    2、优先使用我们自定义的操作符注册表来查找函数
    3、支持操作符类型动态推导与验证
    4、为 Hive 操作符实现执行代码
    5、隐式类型转换增强

在真实的业务系统里，利用这个内存 SQL 计算引擎的场景

在金融风控场景，大多数用户的单数据域的数据量一般在千到万级，所以单条查询的性能基本在百毫秒级或者以内，
但是有两类典型场景无法使用纯内存计算: 1、黑名单匹配 2、关系图谱场景下的关联查询

新的计算平台的性能

在性能表现上，除开数据源拉取，完成一次订单请求的所有变量的计算平均耗时稳定在在性能表现上，除开数据源拉取，
完成一次订单请求的所有变量的计算平均耗时稳定在 1s 以内，而在线 / 离线数据的一致率达到 99% 以上。
过去长达 2 个月的一版主模型的迭代周期，现在能缩短到 2 周以内