前言
中午的时候看到了Spark团队新作MLFlow，因为我本身也在做类似的解决方案MLSQL,自然要看看Meitai是怎么做的。所以第一时间把MLFlow相关文档 浏览了一遍，并且将MLFlow源码 clone下来大致也看了一遍。
看完之后，发现工程项目和文档非常干净利落，体现了Spark团队一如既往的工程能力以及对事物分析高超的抽象能力。 这里先说说我看完后的一个总结：
MLFlow至少现阶段还是一款Python ML pipeline的辅助工具
MLFlow要解决的问题以及相应的方案
MLFlow解决了如下几个问题：
- 算法训练实验难于追踪，所以我们需要有一个实验管理工具Tracking。这个工具能够记录算法，算法参数，模型结果，效果等数据。
- 算法脚本难于重复运行，原因很多，比如代码版本，以来的参数，还有运行环境。解决办法就是所有的算法项目应该都有一套标准的Projects概念,记录下来这些东西。并且这个Projects是可以拟合所有算法框架的。
- 部署模型是一个艰难的过程，在ML界，目前还没有一个标准的打包和部署模型的机制。解决的办法是Models概念，Models提供了工具和标准帮助你部署各种算法框架的模型
我想这几个问题带来的痛楚也是做ML的感同身受的。其实这三个点，每个点都有很多软件和工具在解决，核心问题在于，他们都没有成为事实的标准。
如何和亲儿子Spark做集成
在现阶段版本里，MLFlow 做算法训练是基于单机运行的，不过利用Pyspark可以很方便的实现多机同时运行。从而可以给定不同的参数，然后让Pyspark进行调度，最后把所有实验结果汇报给Tracking Server.
在预测方面，对于一些标准的库比如SKLearn,因为一般而言都有predict方法，所以无需开发即可通过MLFlow进行部署，如果是自定义的一些算法，则需要提供一个模块，实现里面定义方法签名（比如predict）,然后可以动态import到API Server里或者转化一个Spark UDF函数部署到PySpark里。
和MLSQL对比
相比较而言，MLFLow更像一个辅助工具和标准，你只要按这个标准写ML程序（选用你喜欢的算法框架），就能实现实验记录的追踪，多环境的部署（比如可以很容易从我的笔记本移植到你的笔记本上跑），以及通过写一个规范的预测脚本，就能把模型部署成API服务，或者Spark里。
但其实MLFlow还有几个问题没有解决：
- 数据预处理在两个环节存在，一个训练，一个是预测，并且很多场景预测的时候的数据预处理是需要依赖训练时数据预处理产生的元信息的。 而且按MLFlow的架构，整个流程都是算法工程师来完成的，这样就无法保证数据预处理的性能（算法可以用任何库来完成数据的处理），研发只会负责后面模型的部署或者嵌入到spark中（而且必须用pyspark了）。
- 完全基于python完成数据处理和训练，显然会有性能上的损耗。最好的方式还是把数据预处理和训练剥离开了。
- 没有解决Spark和MLFlow的数据衔接问题，也就是说，MLFlow单个实例如何全量或者按批次获取数据？
而MLSQL 除了没有解决Tracking问题以外，已经解决了MLFlow解决的其他的两个问题，当然还有MLFlow没有解决的几个问题。
MLSQL核心在于
- 提供了一个7*24小时的运行平台，算法的工作在IDE中完成调试，Web界面上完成开发和部署，共享CPU/GPU/内存资源。
- MLSQL提供了一套统一的DSL语言完成算法训练和模型部署的功能。
- MLSQL在允许用户自定义脚本进行训练和预测的过程中，制定更为严格的规范，虽然允许你用自己喜欢的任何算法框架完成训练脚本和预测脚本的开发，但是需要符合响应的规范从而嵌入到MLSQL语法里使用。MLSQL要求你大部分训练参数都需要通过SQL语法进行暴露从而使得你的训练脚本具有更好的封装和通用性。
1，2 解决了算法脚本难于重复运行的问题，以及模型部署的问题，同时还解决了数据预处理复用的问题。
- 允许算法嵌入任何算法框架完成训练和预测，给了算法工程师足够的灵活性。
总结
当然，MLFlow目前的模式没有强行绑定到Spark上，而是作为ML的一个辅助工具和标准，最大程度的减少算法同学的学习和使用成本，减少对现有流程干扰，可以使得MLFlow更容易被算法同学接受，从而享受到它的好处，这是MLSQL无法比拟的。所以我前面说了,MLFlow更像一个Pipeline工具和标准，MLSQL则更像一个AI平台。
