EPPDEV-MLIB

本页面只读。您可以查看源文件，但不能更改它。如果您觉得这是系统错误，请联系管理员。
====== EPPDEV-MLIB平台背景说明 ======

===== 问题的提出 =====

==== 模型工程师与软件工程师的技术与思维鸿沟 ====

{{ :soft_model_gap.jpg?600 |}} 

在机器学习项目实施过程中,软件工程和模型工程的衔接上,存在巨大的技术和思维鸿沟：

  * 软件工程师熟悉的主要为软件工程相关技术和架构,对模型工程师的机器学习模型则知之甚少
  * 模型工程师熟悉的主要为相关机器学习模型算法,但是对软件工程相关技术则不甚了解

正式因为上述的技术和思维鸿沟,导致了模型工程师建模完成后,系统化落地比较困难。

==== 模型落地困难,工作量大 ====

模型工程师完成数据建模以后,后续模型计算的工作环节如下图所示:

{{ :model_deploy_process.jpg?600 |}}

主要流程包括以下四个环节:


  * 宽表构建:根据基础数据,准备模型计算所需的基础宽表数据
  * 基础预处理:对数据中的缺失值、极值进行基础处理
  * 特征工程:原始数据中提取特征以供算法和模型使用
  * 模型计算:采用特定的模型算法,根据模型计算结果和特征工程处理后的特征进行模型计算

上述四个环节中,越往后对于软件工程师来讲难度越大,为此很多时候模型部署落地的工作就落到了模型工程师手里,导致模型部署的实现方案各不相同。目前业内常用的落地方案包括:

  * SQL 模式:目前最简单的方式,仅支持最简单的逻辑回归、决策树等简单模型,但是对于复杂的特征工程和复杂的模型算法支持极其困难
  * Java 模式:通过 Java 代码完成特征工程和模型算法,可以支持绝大多数的模型算法和特征工程,缺点是代码开发工作量非常大,后续复杂的模型更新都需要进行额外的开发
  * Python 模式:一般直接由模型工程师直接负责核心代码的编制,由软件工程师进行封装,完成模型的部署,缺点在于软件工程化程度不够,未来的运维、监控比较困难,且很多时候模型落地代码质量比较差
  * R 模式:通过 R 服务监听的方式完成模型部署,一般由模型工程师完成模型的部署,需要模型工程师具备良好的软件工程思维



 
===== 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 的版本规划中,待后续开发完成后,即可实现系统化建模和模型更新功能
EPPDEV-MLIB

用户工具

站点工具

页面工具
