目前存在的几种模型上线的方式
1、R+pmml+spark+airflow调度
其他团队用R语言训练模型并转为pmml文件，然后我们使用spark将这个pmml文件封装为jar，使用airflow提交到yarn。 val is: InputStream = fs.open(path)
val pmml: PMML = PMMLUtil.unmarshal(is)
modelEvaluator = ModelEvaluatorFactory.newInstance.newModelEvaluator(pmml)
2、python+sklearn+airflow调度
其他团队使用python训练好sklearn模型，并joblib.dumps()保存，然后我们在python文件中joblib.load()加载改文件，使用airflow离线调度。
3、xgboost+spark+xgb4j
我们使用的是分布式的spark版的xgboost，训练好的模型直接保存为二进制文件model.booster.saveModel(hdfsOutStream)，然后xgboost4j加载该文件XGBoost.loadModel(is)实现线上实时预测。
4、tensorflow+tensorflow的java库
ft模型先转为protobuf协议的模型，
frozen_graph = freeze_session(get_session(), output_names=["output"])
tf.train.write_graph(frozen_graph, "./", "model.pb", as_text=False)
然后使用tf的java库加载改pb模型，在线预测 try (Graph graph = new Graph()) {
graph.importGraphDef(Files.readAllBytes(Paths.get("xxx/model.pb"))); try (Session sess = new Session(graph)) { float[][] input = xxx; try (Tensor x = Tensor.create(input); Tensor y = sess.runner().feed("input", x).fetch("output").run().get(0)) { float[][] result = new float[1][y.shape[1]]; y.copyTo(result); System.out.println(Arrays.toString(y.shape())); System.out.println(Arrays.toString(result[0])); } }}...
5、keras+Flask
python环境先将keras模型保存为hdf5文件model.save(model.h5)，然后在轻量级的web框架flask中加载实现线上预测。
总结分类为
1、离线预测+不跨语言
这种最简单，就是用什么语言训练的就用什么语言预测，而且不用考虑多并发和响应时间等问题，例如方式2。
2、离线预测+跨语言
用一种语言训练，另一种语言预测，但是不用考虑多并发和响应时间等问题，例如方式1。
3、在线预测+不跨语言
用同一种语言训练和预测，同时要考虑多并发和响应时间等问题，例如方式3、4、5。像scala和java这种都是跑在jvm上的，以及tf自己实现了java库的，我们这里认为是同一种语言，
4、在线预测+跨语言
用不同的语言训练和预测，同时要考虑多并发和响应时间等问题，我们目前还没有这种。但是类型2和3变一下就是在线+跨语言。
不跨平台的，即当训练和预测使用同一种开发语言的时候，PMML 就没有必要使用了，因为任何中间格式都会牺牲掉独有的优化。 而其他跨平台的模型要转为java能使用的类（因为我们的业务大部分是java实现的），这个工具就是jpmml-evaluator。
一个离线模型 打比赛，预测数据 和提供线上服务，是两个情况；线上的框架目前多数基于java来写的
而离线的算法模型很多都是c++实现，这样能够保证模型的训练速度和效率；
此外，python里面，sklearn里面提供了很多的算法模型， 包括一些c++实现的模型也都有python的包，
但线上的服务很少会用python来做，性能不行；所以，跨语言调用模型是一个问题。
目前python的跨语言模型调用，其官方给了一个pmml的官方方式，也在很多人的博客里面有提到过，
但实际线上服务应用的时候，效率不行，且pipeline做特征工程的时候， 有些函数不支持，
因而很多人也都不用。
目前这种模型上线的一个解决方式是，将模型python或者c++中 predict的部分转成java版本 ，然后加载模型来提供服务，我是用这种方式来实现的线上服务的提供；（当然有人说，直接用c++接口来做服务是性能最好的，这一部分，也是我接下来要摸索的方向），这里先介绍我目前的解决方法：
对于排序问题的第一个版本，我用的是lightgbm模型，使用的线上代码，来自于github上predict4j 的接口，该接口实际数据处理速度很快，虽然不支持批预测，但是6w的数据量，50ms一般能够返回结果，如果用多线程的话，就更快了，在访问量不是特别高的情况下，能够满足需求！
然后由于lightgbm版本更新的问题，该接口不支持2.0.4版本以上的模型， 数据参数格式有点不一样
所以只能用老版本的， 且存在预测的数据和离线模型算出来的数据有一些误差偏离的地方。
这是xgboost用速度换性能的一个bug；
另外，线上的实时数据，接入模型是另外一个问题，我这块了解比较少，还希望有人在这块多交流一些；
接下来打算做一个ffm的线上调用服务 以及做一个deep& wide的模型来对比下效果
