H2O 简介
H2O.ai 是初创公司 Oxdata 于 2014 年推出的一个独立开源机器学习平台,它的主要服务对象是数据科学家和数据工程师,主要功能就是为 app 提供快速的机器学习引擎。目前它在全世界服务超过 18,000 家企业,服务用户数超过 20 万。根据 H2O 官网的介绍,它的主要优点包括:
支持大量的无监督式和监督式机器学习算法
支持通过 R 与 Python 进行引入包的方式进行模型的开发
能够提供给用户一个类似于 jupyter notebook 的 UI 界面进行“托拉拽”式的模型开发
支持模型的快速部署(用户可以在训练后下载基于 Java 的 POJO 和 MOJO 文件)
支持自动化建模和自动化参数调优
H2O 实战练习
大家可以使用在 Python 或 R 中引入 H2O 包的形式进行该工具的使用,也可以下载软件在 UI 界面进行托拉拽的操作。
一、基于 H2O Python 包的机器学习实现
首先让我们在 Python 环境中看看如何使用这个工具进行建模(目前支持 Python 版本为 2.7/3.5/3.6)。
1、下载安装包
首先我们在安装包之前先进行依赖包的安装,最后下载并安装 h2o 的 whl 文件,如下(使用 H2O 之前请读者务必在服务器或本地安装 Java):
安装完毕后进入 Python 环境(我们这里使用的是 Jupyter Lab 的交互环境,类似 Jupyter Notebook)。
2、引入包并查看环境
引入 h2o 的包后可以查看到目前集群的状态,如下
现在可以看到集群的内存、cores、python 版本等信息;另外 h2o.ls()命令类似于 Linux 中的 ls 命令,它可以告诉我们目前读取到内存的数据集以及训练好的模型 Object 有哪些,由于还没有引入数据、也没有训练任何模型,因此没有任何 objects。
3、引入、查看、整理数据集
下面通过 h2o 引入并查看一个用来训练的数据集,该数据集为电商场景的二分类数据,特征包括一些用户 RFM、浏览、加购等信息,y 为用户是否会在之后 7 天内下单购物。
在进行导入数据后,发现 user_id(这里叫 pin)依然在数据集中,我们进行列删除操作。
同时,由于要训练的是二分类(classification)模型,所以需要将 y(这里为 buy_tag)的类型从 int 改为 enum 枚举值,这样在模型的训练过程中会默认选择 AUC 作为评价指标。
4、导入模型 module 并建立模型 object
这里选择 GBM 这个基于树的算法进行模型的开发,并设置 100 个树,最大深度设置为 10,并设置 10 折交叉验证。
5、训练模型并展示训练结果
这里 train()的参数非常多,我们找一些重点来举例; x 为特征的名字集合,y 为 label,training_frame 为训练集。
当然用户也可以通过将数据集分为训练集、测试集的方式来获取 out-of-sample AUC 等指标,这里通过交叉验证来获取该指标。训练完毕后可以进行效果展示。
可以看到在模型结果中 H2O 自动帮用户计算了大部分评价指标,在这个二分类任务中我们重点看 AUC,可以发现在 cross-validation 数据集上的 AUC 为 0.824,效果还不错
同时结果中默认给出了能够是 F1 score 达到最大的阈值(在这里为 0.316)以及相应的混淆矩阵。
由于不同模型涉及到不同参数,具体模型参数设定可见 H2O 的官方文档
http://h2o-release.s3.amazonaws.com/h2o/rel-xu/4/docs-website/h2o-py/docs/modeling.html
目前 H2O 支持的监督模型包括:
H2ODeepLearningEstimator(深度神经网络)
H2OGradientBoostingEstimator(梯度提升树)
H2OGeneralizedLinearEstimator(线性回归)
H2ONaiveBayesEstimator(朴素贝叶斯)
H2ORandomForestEstimator(随机森林)
H2OStackedEnsembleEstimator(组合模型)
据官网介绍,之后 H2O 还会引入目前常用的 tensorflow 等组件来支持不同深度学习算法的使用,所以大家敬请期待。
6、H2O 自动建模
在上节展示单模型建立的流程后,来看一下 H2O 最强大的功能,AutoML,自动建模。
读者如果在尝试自动建模的时候,请尽量设置 max_models 或者 max_runtime_secs 这样的参数来设置要训练的模型个数上线或最长训练时间,因为自动建模的底层会尝试对用户所选择的模型的参数进行 GridSearch(网格搜索),以此来进行模型超参的调优。若没有设置好模型个数上线或最长训练时间,可能会出现跑了很久依然没有结束的情况。
同时可以看到一旦开始了自动建模,H2O 很友好地提供了一个进度条来帮助查看建模进度。
训练完成后查看模型基于训练集 AUC 的排名,如下图:
这个排名版展示了所有所训练的 100 个模型中 AUC 前 10 高的模型,在图中可以清晰地看到 最优的模型为组合模型(StackedEnsemble_AllModels),AUC 为 0.825。前 10 名中还包括像 XGBoost 和 GBM 一样的基于树的模型,AUC 也相当不错。
值得一提的是,组合模型中 AllModels 与 BestOfFamily 的区别在于:前者是将所有训练好的模型作为 base model 进行融合,后者是通过各个模型 family 中最好的那个模型作为 base model 进行融合(融合方式默认为 GLM 线性回归)。
然后查看自动建模得到的最优模型在测试集上的效果,发现 out-of-sample AUC 依然高达 0.820,说明没有明显的过拟合,自动建模完成!
7、H2O 模型部署
在训练完模型之后,最后一步便是模型的部署,可能各位读者在平日操作中对于这一步比较苦恼,因为若使用 sklearn 这样的经典机器学习包在训练完模型后,模型本身是不支持在 Hive 集群进行分布式打分的。当需要打分的数据集过大的时候,我们没有办法一次性将其读入内存并进行打分,因此只能通过 batch 读取的方式按批次来进行预测打分,这样一来就需要用户花时间来写一些 python 或者 bash 的脚本。
但是 H2O 提供了一个非常好的模型部署流程,它一方面支持用户像 sklearn 那样将一个模型文件下载到本地,又支持用户进行 POJO 或者 MOJO 文件的下载。而这里所说的 POJO 和 MOJO 文件分别是 Plain Ordinary Java Object 和 Maven plain Old Java Object,作用是优化开发人员的模型部署流程,并且支持在 Hive 上进行模型打分 UDF 的改写。一旦通过 POJO 或者 MOJO 实现了模型打分 UDF 函数的编写,模型的打分在集群上就是分布式的,速度会非常快。
笔者尝试了 batch 打分和分布式打分的两个流程,发现若对 3000 万行的数据进行 非分布式的 batch 打分,总共用时 25 分钟,而分布式的打分则总共用时不到 1 分钟,效率提升很多。
由于具体的改写流程较细,因此大家若对这部分内容感兴趣,可以在 H2O 的官网和他们的 github 中找到相关的现成代码,助力模型部署。
二、可视化建模 UI 工具
除了在 python 或者 R 通过代码实现建模以外,H2O 还为我们提供了一个很用户友好的 UI 界面来实现 “托拉拽式建模”,下图为这个工具的(H2O Flow)主界面:
这个工具相当于一个图形界面,底层依然是我们上面介绍的那些代码,它的好处是可以帮助企业中对于 python 或者 R 语言不太熟悉的业务人员进行快速模型的建立。
由于篇幅问题,我们这里主要讲一下它每个功能点的具体含义,详细操作大家可以参照官网的用户手册进行学习。值得一提的是,这个图形界面非常的用户友好,笔者当时 仅用了 1-2 个小时 就熟悉了基本操作,相信大家一定也能很快的学会使用。功能解释:
importFiles(读取数据集)
importSqlTables(读取 SQL 表)
getFrames(查看已经读取的数据集)
SplitFrame(将一个数据集分成多份数据集)
mergeFrame(将两个数据集进行列组合或行组合)
getModels(查看所有训练好的模型)
getGrids(查看网格搜索的结果)
getPredicitons(查看模型预测结果)
getJobs(查看目前模型训练的任务)
runAutoML(自动建模)
buildModel(手动建立模型)
importModel(从本地读取模型)
predict(使用模型进行预测)
关于自动建模的一些思考
读到这里,读者除了对 H2O 有了一些基本了解之外,也一定和笔者一样思考着同一个更宏大的问题,那就是如何看待自动建模与机器学习的未来。想必大家一定在许多媒体报道或者公众号中读过类似这样的文章:“AI 时代来了,最容易消失的 100 种职位”。对于从事商业分析、数据分析、数据挖掘、数据工程、算法工程的用户,可能多少也想过这样的自动建模技术能在多大程度上代替我们现有的一些日常工作。它会完全取代我们现有的建模过程么?还是说它目前效果不好,我们无需担心?
笔者个人认为,看待“手动建模”和“自动建模”这两者的关系可以参考“有人驾驶车”和“无人驾驶车”这两者的关系。我相信,就算短期内无人驾驶车可以上路,交通部门也一定会要求驾驶人员具有一定的驾驶技术,以确保在无人驾驶发生意外之时能够让用户进行手动操作。同理,在如今各大公司都开始慢慢探索自动建模技术的时候,我们依然需要拥有求知欲和一颗敬畏之心,在尝试自动建模技术之前深入了解一些模型算法本身的技术,这样一来,虽然可以更多地在工作中使用自动建模,但是一旦出了问题,我们也可以从“自动”切换为“手动”来迅速地解决模型部署上的问题,而不至于干着急。
另一方面,读者也许会发现,目前自动建模领域所涉及的领域更多的还是 浅层学习,还没有发展到可以自动建立 CNN 或者 RNN 那样的地步,毕竟后者还是一个新兴的前沿领域,许多算法工程师依然在 图像识别、语音识别、阅读理解领域 不断创新探索新的算法。这方面的工作暂时不太会被自动建模技术所取代(H2O 官网上有写到未来可能会集成 tensorflow 的建模框架,但目前来看暂时还没有开源的资源)。
那么,如果自动建模技术在 5 年内真的渗透到我们工作中的各个领域后,基础的数据挖掘和算法工程师该如何体现自己的价值呢?我认为起码有这两点:
对于业务的深度理解:虽然模型可以进行自动训练,但是前期与业务方的建模需求整合,特征工程,变量清洗等工作还是需要人来参与,因为业务知识是暂时没有办法教给机器的。
对于模型应用场景的选择:如何去应用模型以及选择最优的应用场景也是需要人来判别的,机器本身是没有正负情感的。
如果大家对于自动建模有新的想法,欢迎随时与我们联系,一起交流进步!
评论