中午的时候看到了Spark团队新作MLFlow,因为我本身也在做类似的解决方案MLSQL,自然要看看Meitai是怎么做的。所以第一时间把MLFlow相关文档 浏览了一遍,并且将MLFlow源码 clone下来大致也看了一遍。
看完之后,发现工程项目和文档非常干净利落,体现了Spark团队一如既往的工程能力以及对事物分析高超的抽象能力。 这里先说说我看完后的一个总结:
MLFlow至少现阶段还是一款Python ML pipeline的辅助工具
MLFlow解决了如下几个问题:
我想这几个问题带来的痛楚也是做ML的感同身受的。其实这三个点,每个点都有很多软件和工具在解决,核心问题在于,他们都没有成为事实的标准。
在现阶段版本里,MLFlow 做算法训练是基于单机运行的,不过利用Pyspark可以很方便的实现多机同时运行。从而可以给定不同的参数,然后让Pyspark进行调度,最后把所有实验结果汇报给Tracking Server.
在预测方面,对于一些标准的库比如SKLearn,因为一般而言都有predict方法,所以无需开发即可通过MLFlow进行部署,如果是自定义的一些算法,则需要提供一个模块,实现里面定义方法签名(比如predict),然后可以动态import到API Server里或者转化一个Spark UDF函数部署到PySpark里。
相比较而言,MLFLow更像一个辅助工具和标准,你只要按这个标准写ML程序(选用你喜欢的算法框架),就能实现实验记录的追踪,多环境的部署(比如可以很容易从我的笔记本移植到你的笔记本上跑),以及通过写一个规范的预测脚本,就能把模型部署成API服务,或者Spark里。
但其实MLFlow还有几个问题没有解决:
而MLSQL 除了没有解决Tracking问题以外,已经解决了MLFlow解决的其他的两个问题,当然还有MLFlow没有解决的几个问题。
MLSQL核心在于
1,2 解决了算法脚本难于重复运行的问题,以及模型部署的问题,同时还解决了数据预处理复用的问题。
当然,MLFlow目前的模式没有强行绑定到Spark上,而是作为ML的一个辅助工具和标准,最大程度的减少算法同学的学习和使用成本,减少对现有流程干扰,可以使得MLFlow更容易被算法同学接受,从而享受到它的好处,这是MLSQL无法比拟的。所以我前面说了,MLFlow更像一个Pipeline工具和标准,MLSQL则更像一个AI平台。