文章目录
2.3.3 需要使用Java API与REST API混用方可支持所有需求
2.3.4 算子参数多、复杂、参数的联动性复杂对于前端开发需求高
一、 前言
传统机器学习模型大致可分为以下四个部分：数据采集、数据预处理、优化、应用；其中数据预处理与模型优化部分往往需要具备专业知识的数据科学家来完成，他们建立起了数据到计算的桥梁。然而，即使是数据科学家，也需要花费大量的精力来进行算法与模型的选择。机器学习在各种应用中的成功，导致对机器学习从业人员的需求不断增长，因此我们希望实现真正意义上的机器学习，让尽可能多的工作也能够被自动化完成，进一步降低机器学习的门槛，让没有该领域专业知识的人也可以使用机器学习来完成相关的工作。
AutoML应运而生，从传统机器学习模型出发，AutoML从特征工程、模型构建、超参优化三方面实现自动化；并且也提出了end-to-end的解决方案。
说明：本文是以开发自动化机器学习平台需求为背景对H2O框架进行预研分析。
二、预研结果分析
2.1 预研结论概述
通过对于AutoML原理理解，对H2O架构，特性，功能，接口，性能，部署等方面的了解和验证测试，初步认为当前技术方案可行，可用于作为自动化机器学习平台的底层框架；但是仍然存在一些二次改造的注意点与难点问题需要解决。
2.2 可行性依据分析
可行性依据分析主要从：“能否满足系统功能需求”、“学习成本及应用能力”、“能否便捷交付与运维”等方面进行分析。
2.2.1 功能需求满足分析
调研目的： 参考《自动化机器学习平台用户需求说明书.doc》分析用户需求，同步分析H2O框架能否有效支撑系统功能需求。
调研结果：H2O框架能够有效支撑数据的输入、数据解析、数据基本分析概览、数据操作转换、丰富算法支持、丰富算法参数配置、模型构建训练、交叉验证建模、模型评估、模型导出等功能。同时无论是在数据管理、算法管理、模型管理、预测分析等方面H2O都提供了丰富的、专业的、高覆盖度的能力支撑。从功能角度看，H2O能够有效满足系统的功能需求。
具体分析依据参考如下调研内容：
- 数据管理：3.6-数据加载 3.7-数据操作
- 算法管理：3.8-算法支持
- 模型训练：3.9-训练模型 3.10-交叉验证建模 3.15-模型管理
- 模型评估：3.14-性能与预测
2.2.2 学习改造能力分析
调研目的：在能够满足功能需求的前提下，我们需要进一步明确该方案的学习使用成本，而学习使用成本的分析主要看H2O框架本身提供的上手与改造的支撑能力了。
调研结果：首选H2O官方网站以及文档介绍较全面，文档内容较丰富，层次结构也清晰；其次H2O提供了R/PYTHON/JAVA/REST API的client对接方式，结合本团队的技术能力可以满足；同时文档中提供了详细的REST API列表以及各接口的输入输出模型说明，对于开发人员来说能够快速测试并使用；H2O中开发最困难的应该是算法、参数、指标的理解与展现部分，虽然开发人员不需要做数据科学家，但是需要对所有这些概念的术语还是需要理解，H2O中提供了丰富的文档已满足开发人员对齐理解并正确在开发过程中进行展示；H2O源码提交活跃，基本每天都有源码提交更新，同时社区活跃度也较可；H2O框架中提供给了丰富的案例与数据资源以供学习和使用操作流程；H2O提供了web flow可视化界面以Notebook方式来支持可视化的分析流程操作，同时提供了大量的日志与监控信息，使得能够更好、更直观的理解流程与原理，接口验证也更方便；等等。
具体分析依据参考如下调研内容：
- 接口文档丰富： 3.16-H2O开发
- 官网文档清晰：http://h2o-release.s3.amazonaws.com/h2o/rel-zeno/2/docs-website/h2o-docs/welcome.
2.2.3 交付运维能力分析
调研目的：本系统最终需要实现其企业级应用，除了对其能力需求外，我们还需要更好的维护好该服务，保持其稳定，提供持续服务能力。
调研结果：H2O可通过jvm和Hadoop两种方式进行单节点或多节点部署。其中通过jvm的部署方式部署流程简单、结构轻量，但其无法实现集群高可用。而通过Hadoop部署，部署流程相对复杂、结构较重，但H2O能依赖Hadoop相关组件实现高可用特性。通过Hadoop方式部署，对持久化文件管理服务的二次开发较为友好。
2.2.4 其他优势分析
调研目的：调研H2O框架本身技术先进性、稳定性、支撑性、活跃度、内涵性等。
调研结果：具体包括以下部分
1. 算法齐全参数完备：相对于现有产品中算子种类较少、可调参数单一的情况，H2O提供了大量监督与无监督学习算法，如深度学习、支持向量机、K-means聚类等，并支持自定义算法。H2O支持对每个算法进行基础、进阶、专家三个级别的参数配置。
2. 功能稳定较为成熟：H2O拥有庞大的国际专业团队，其技术水平在业内处于领先水平，产品稳定，可靠性高。相对于公司现有产品，还有很多功能模块未得到有效测试，系统不够稳定。
3. 改造工作量较低：相较于根据现有产品代码进行工程重构，由于H2O已经实现了各个核心功能模块，以 H2O为基础重新构建的工程量要低很多。
4. 社区文档丰富：H2O版本迭代升级频繁，社区活跃。文档丰富清晰。
2.3 问题风险及注意事项分析
2.3.1 完全基于内存的分析没有考虑过程数据的管理和复用
H2O服务重启后过程数据丢失，没有提供良好的持久化与管理功能。
2.3.2 高可用方案原生支持的并不可观
采用H2O独立组件集群，任意节点挂掉后 整体服务不可访问。并且一个节点挂掉后需要重启所有节点方可恢复服务。
当然：该部分可考虑使用K8S的部署方案，但是会增加部署实施成本。
2.3.3 需要使用Java API与REST API混用方可支持所有需求
REST API覆盖度并不全，数据处理 数据操作处理部分未提供有效REST API，如：列切片、行切片、空值填补等
最低0.47元/天 解锁文章
96
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
