background
差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
|
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 的版本规划中,待后续开发完成后,即可实现系统化建模和模型更新功能 | ||
| + | |||
| + | |||
background.1575867873.txt.gz · 最后更改: 2020/07/12 12:07 (外部编辑)