机器学习模型部署方案
背景
目前，我们组反欺诈业务已经进行到了较为后期的阶段，初步有了基础的数据平台、计算平台。此时，算法同事也升级了过往基于统计分布的简单算法实现，而采用了更为强大的机器学习模型，目前已知的将会使用以下几类算法：离群点检测算法、树类算法等（笔者仅了解常见算法，描述不准确还望见谅。）
问题
算法同学日常使用sk-learn或者spark ml居多，其中前者使用python后者使用scala作为日常开发语言。笔者目前所做的属于算法工程化，需要对接线上实时数据流、离线数据实现对算法同学产出的模型的上线。
目前，已知的其他团队的方案有：
- 使用python语言实现backend，并对接实时、离线数据
- 使用Java重新实现一遍算法逻辑，然后实现web api，并对接实时、离线数据
分析一下这两种方案：
对于1，他们这么做的理由是算法同学自己的工程能力非常强，可以自己用python一站式搞定模型训练、上线，并且他们的业务离线居多，对实时性的要求不高。
对于2，他们这么做的理由是算法同学工程能力较弱，自己无法搞定一站式。使用线性模型比较多，后端Java同学实现起来还是比较简单的，性能也非常好。
然而，这两种方案目前看来都不能满足我们组的需求。
- 我们的模型比较复杂，用Java实现一遍显的复杂性不可控，验证实现正确性的成本也很高。
- 主要是实时、数据量较少的场景，对实时性要求比较高（查询四五个数据源，加上模型逻辑，需要在1秒内给业务方返回）
- 希望做到模型的部署和训练解耦，算法同学和后端同学各自专注自己的事情
方案
针对如上特征，笔者进行了调查。发现使用模型训练—>导出模型文件—>服务端加载模型文件，对接数据源这种模式比较适合我们。
目前业界使用的比较多的模型文件标准是PMML，以下是对该标准的简单描述：
PMML 是一种事实标准语言，用于呈现数据挖掘模型。PMML 允许您在不同的应用程序之间轻松共享预测分析模型。因此，您可以在一个系统中定型一个模型，在 PMML 中对其进行表达，然后将其移动到另一个系统中。
PMML 是数据挖掘群组的产物，该群组是一个由供应商领导的委员会，由各种商业和开放源码分析公司组成。因此，现在的大部分领先数据挖掘工具都可以导出或导入 PMML。作为一个已发展 10 多年的成熟标准，PMML 既可以呈现用于从数据中了解模型的统计技术（如人工神经网络和决策树），也可以呈现原始输入数据的预处理以及模型输出的后处理。[1]
可以看到，PMML作为一个10几年的标准，在数据挖掘领域是很成熟的。笔者在Github也找到了该标准的Java实现[2]。
可以看到其子项目分类非常清晰：
jpmml-evaluator
java加载jpmml格式文件API，这个也是我们服务端重点关注的jpmml-model
jpmml文件对应的Java类jpmml-sparkml
与sparkml整合以导出jpmml文件jpmml-sklearn
与sklearn整合以导出jpmml文件
jpmml-r
jpmml-xgboost
如果使用这种方案，改动量：
- 算法同学需要整合jpmml-sparkml、jpmml-sklearn
- 后端工程同学需要整合jpmml-evaluator、jpmml-model
改动量还是比较大的，目前也主要是笔者自己进行相关的调研，接下来笔者尝试跑通模型训练—>导出模型文件—>服务端加载模型文件，对接数据源这个流程。
实现
算法侧
工程侧
总结
该方案的优势
- 解耦
使用PMML作为中间层，解耦了模型训练、部署这两个环节，使得算法同学专注效果、后端同学专注性能 - 成熟度很高
已经有10几年的历史
该方案的缺点
故障追踪相对困难
增加了一层模型文件，引入了几个子项目，出了问题定位起来相对以前要难上一些。不过，如果满足我们的需求，相信随着对源码的逐步掌握，我们可以在关键节点做埋点日志，结合已有的tracing系统，这个问题也不大
心得
这次总共花了1天多的时间研究更好的模型上线方案，初步确定了JPMML这一生成中间文件的方案。目前，已经跑通了从算法模型训练（覆盖sklearn、spark ml的jpmml文件输出）到使用jpmml模型文件部署的整个流程。
过程中还算比较顺利，github上的文档虽少但足够精炼，已经覆盖了主要流程。但并没有覆盖到算法同学的复杂模型case，因此还需要和算法同学细化使用场景。
如果该方案最终被采用，笔者会撰写更为深入的源码分析系列文章。
Reference