这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
background [2019/12/09 13:04] jinlong [问题的提出] |
background [2020/07/12 12:07] (当前版本) |
||
---|---|---|---|
行 1: | 行 1: | ||
- | ====== EPPDEV-MLIB分布式模型部署平台背景说明 ====== | + | ====== EPPDEV-MLIB平台背景说明 ====== |
===== 问题的提出 ===== | ===== 问题的提出 ===== | ||
行 5: | 行 5: | ||
==== 模型工程师与软件工程师的技术与思维鸿沟 ==== | ==== 模型工程师与软件工程师的技术与思维鸿沟 ==== | ||
- | {{ :soft_model_gap.jpg?400 |}} | + | {{ :soft_model_gap.jpg?600 |}} |
在机器学习项目实施过程中,软件工程和模型工程的衔接上,存在巨大的技术和思维鸿沟: | 在机器学习项目实施过程中,软件工程和模型工程的衔接上,存在巨大的技术和思维鸿沟: | ||
- | * 软件工程师熟悉的主要时软件工程相关技术和架构,如 JavaEE、MySQL、React 等软 | + | * 软件工程师熟悉的主要为软件工程相关技术和架构,对模型工程师的机器学习模型则知之甚少 |
- | 件开发相关技术,对模型工程师的机器学习模型则知之甚少 | + | * 模型工程师熟悉的主要为相关机器学习模型算法,但是对软件工程相关技术则不甚了解 |
- | * 模型工程师熟悉的主要为相关机器学习模型算法,如逻辑回归、决策树、SVM 等,但是 | + | |
- | 对软件工程相关技术则不甚了解 | + | |
正式因为上述的技术和思维鸿沟,导致了模型工程师建模完成后,系统化落地比较困难。 | 正式因为上述的技术和思维鸿沟,导致了模型工程师建模完成后,系统化落地比较困难。 | ||
==== 模型落地困难,工作量大 ==== | ==== 模型落地困难,工作量大 ==== | ||
+ | |||
+ | 模型工程师完成数据建模以后,后续模型计算的工作环节如下图所示: | ||
+ | |||
+ | {{ :model_deploy_process.jpg?600 |}} | ||
+ | |||
+ | 主要流程包括以下四个环节: | ||
+ | |||
+ | |||
+ | * 宽表构建:根据基础数据,准备模型计算所需的基础宽表数据 | ||
+ | * 基础预处理:对数据中的缺失值、极值进行基础处理 | ||
+ | * 特征工程:原始数据中提取特征以供算法和模型使用 | ||
+ | * 模型计算:采用特定的模型算法,根据模型计算结果和特征工程处理后的特征进行模型计算 | ||
+ | |||
+ | 上述四个环节中,越往后对于软件工程师来讲难度越大,为此很多时候模型部署落地的工作就落到了模型工程师手里,导致模型部署的实现方案各不相同。目前业内常用的落地方案包括: | ||
+ | |||
+ | * SQL 模式:目前最简单的方式,仅支持最简单的逻辑回归、决策树等简单模型,但是对于复杂的特征工程和复杂的模型算法支持极其困难 | ||
+ | * Java 模式:通过 Java 代码完成特征工程和模型算法,可以支持绝大多数的模型算法和特征工程,缺点是代码开发工作量非常大,后续复杂的模型更新都需要进行额外的开发 | ||
+ | * Python 模式:一般直接由模型工程师直接负责核心代码的编制,由软件工程师进行封装,完成模型的部署,缺点在于软件工程化程度不够,未来的运维、监控比较困难,且很多时候模型落地代码质量比较差 | ||
+ | * R 模式:通过 R 服务监听的方式完成模型部署,一般由模型工程师完成模型的部署,需要模型工程师具备良好的软件工程思维 | ||
+ | |||
+ | |||
+ | |||
+ | |||
===== EPPDEV-MLIB解决方案 ===== | ===== EPPDEV-MLIB解决方案 ===== | ||
+ | |||
+ | |||
+ | 为了更好的划分号模型工程师和软件工程师的分工界面,结合实际业务需要,EPPDEV-MLIB 解决方案应运而生。通过 EPPDEV-MLIB 方案可以很好的区分模型工程师和软件工程师的分工界面,模型工程师负责完成 pmml 文件的构建,软件工程师通过调用 EPPDEV-MLIB 调用网关提供的标准化接口,即可完成模型的计算,具体逻辑如下图所示: | ||
+ | |||
+ | {{ :eppdev_mlib_solution.jpg?600 |}} | ||
+ | |||
+ | |||
+ | ===== 方案优缺点 ===== | ||
+ | |||
+ | ==== 优势1:多种建模工具与算法的支持 ==== | ||
+ | |||
+ | {{ :model_support.jpg?600 |}} | ||
+ | |||
+ | 平台模型计算基于 PMML 标准来完成,支持多种常用的建模工具(如 sklearn, spark mlib, R, tensorflow 等),支持多种机器学习模型算法 | ||
+ | |||
+ | ==== 优势2:方便与各应用系统集成 ==== | ||
+ | |||
+ | {{ :model_call_method.jpg?600 |}} | ||
+ | |||
+ | 平台提供了常用的模型调用工具 SDK,支持批量任务调用、hive sql 调用、实时接口调用等多种模型调用方式,可以满足不同应用场景下的系统对接 | ||
+ | |||
+ | ==== 优势3:全分布式高可用架构 ==== | ||
+ | |||
+ | |||
+ | {{ :eppdev_mlib_logic_arch.jpg?600 |分布式高可用架构}} | ||
+ | |||
+ | 全分布式高可用架构,任意组件的失效均不影响模型运算的正常运转 | ||
+ | |||
+ | ==== 平台不足 ==== | ||
+ | |||
+ | 当然,本平台仍然有一定的不足之处: | ||
+ | |||
+ | - 模型构建必须输出为 pmml 格式,这就要求模型工程师在进行特征工程、模型构建是全部使用 Pipeline 方式,客观上会增加模型工程师的工作量,但是相对于模型部署上节约的工作量,这部分工作量基本上可以忽略不计 | ||
+ | - 目前平台仅支持模型部署,暂不支持基础数据建模和模型的定时更新,上述功能仍需模型工程师手工处理,或者开发相信的程序来完成。上述功能已纳入 V2.0 的版本规划中,待后续开发完成后,即可实现系统化建模和模型更新功能 | ||
+ | |||
+ |