H2O-大规模机器学习-全-

H2O 大规模机器学习（全）

原文：annas-archive.org/md5/c9ddf18b4e65aa8fb31aa4946487f03c

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

在当前这个时间点，机器学习（ML）几乎无需介绍：它对商业、非营利组织和科学组织都具有普遍性和变革性。机器学习建立在数据之上。我们所有人都意识到每年收集的数据呈指数级增长，以及生成这些数据的来源日益多样化。这本书是关于利用这些海量数据量来进行机器学习的。我们称之为大规模机器学习，并在三个支柱上对其进行定义：在大型到海量数据集上构建高质量模型，在多样化的企业环境中部署它们进行评分，以及在过程中解决多个利益相关者的关注点。在这里，规模考虑了数据量和企业环境、模型构建和模型部署。在这本书中，我们将以实际的方式向你展示 H2O 如何克服执行大规模机器学习的许多挑战。

本书从对大规模执行机器学习挑战的概述开始，以及 H2O 框架如何克服这些挑战，同时产生高质量的模型和企业级部署。然后，它过渡到使用 H2O 在规模上的高级模型构建技术和模型部署模式。接着，我们从多个需要理解、部署和维护该系统的企业利益相关者的角度，探讨其技术基础，并展示这与数据科学家活动和需求的关系。最后，我们展示了如何将 H2O 在规模上独立实施或作为功能丰富的大型 H2O AI 云平台的一部分，在那里它承担着令人兴奋的新水平的机器学习可能性和商业价值。

在阅读完这本书之后，你将获得构建高质量可解释机器学习模型所需的知识，这些模型可以从海量数据集中构建，部署到各种企业系统中，并组装最先进的机器学习解决方案，实现独特的商业价值。

这本书面向谁

这本书是为数据科学家、机器学习工程师、系统管理员、企业架构师以及想要使用 H2O 大规模构建和部署机器学习模型的充满好奇心的技术人员所写的。那些已经熟悉 H2O 的人将学习高级模型构建技术和部署模式，以及 H2O 内部工作原理的细节。对于机器学习有一定了解但工作经验很少或没有的学生，将了解它在大企业世界中的实施方式。建议具备基本的机器学习知识，并且需要理解 Python 以跟随代码示例。

这本书涵盖的内容

第一章，机遇与挑战，为本书设定了背景。我们将首先围绕三个领域定义大规模机器学习（ML）：在大到巨量数据集上构建高质量模型，在多样化的企业环境中部署它们进行评分，以及在过程中解决多个利益相关者的关注点。然后，我们将认识到在这个背景下机器学习的巨大商业机会和执行挑战。在这种情况下，您将了解到 H2O 如何通过其H2O-3、Sparkling Water、Enterprise Steam和MOJO技术克服这些挑战，这些技术构成了 H2O at Scale 框架。

第二章，平台组件和关键概念，通过描述每个组件在机器学习生命周期中的位置、其关键特性和如何克服大规模机器学习的挑战来概述每个 H2O 组件。然后，我们从概述中提炼出几个关键概念。本章的目标是在您学习如何实现它之前，为您提供 H2O at Scale 如何工作的基础知识。

第三章，基本工作流程 – 数据到可部署模型，展示了使用 H2O at Scale 框架构建和部署模型所需的最小步骤。将其视为一个带有每个步骤解释的Hello World示例。您有其他实现这些步骤的替代方案，它们将会被探讨。在本书的这个阶段，我们将结束一般概述并转向高级主题。

第四章，大规模 H2O 模型构建 – 能力阐述，开始了我们的模型构建重点，主要对数据科学家感兴趣。在本章中，我们熟悉了 H2O 广泛的建模能力，从数据摄取和处理到算法、模型训练、评估和可解释性技术。将本章视为 H2O 模型构建的“是什么”，而下一章将深入探讨“如何”和“为什么”。

第五章，高级模型构建 – 第一部分，介绍了数据科学家在构建企业级模型时考虑的高级模型构建主题。我们讨论了数据拆分选项，比较了建模算法，提出了用于超参数优化的两阶段网格搜索策略，介绍了 H2O AutoML，它能够自动将多个算法拟合到数据中，并探讨了用于提高模型性能的特征工程选项。到本章结束时，您应该能够使用 H2O 中可用的一个或多个监督学习算法构建一个企业规模、优化和预测模型。

第六章, 高级模型构建 – 第二部分，通过展示如何在 Apache Spark 管道内构建 H2O 监督学习模型，继续我们的高级模型构建主题。我们回顾了 H2O 的无监督学习方法，讨论了更新 H2O 模型的最佳实践，并介绍了确保 H2O 模型可重复性的要求。

第七章, 理解机器学习模型，概述了 H2O 中用于解释机器学习模型的一组功能。构建一个预测效果好的模型是不够的。在将任何模型投入生产之前，理解它是如何做出决策的至关重要。我们讨论了选择合适的模型度量标准，使用多种诊断方法来建立对模型的信任，以及使用全局和局部解释与模型性能指标相结合来从一组候选模型中选择最佳模型。这包括对模型性能、评分速度和候选模型中满足的假设之间的权衡进行评估。

第八章, 整合一切，以大多数数据科学项目的方式开始：从原始数据和一般业务目标开始。我们精炼数据和问题陈述，使其与业务相关，并且可以用可用数据回答。我们设计各种特征，创建和评估多个候选模型，直到我们得到一个最终模型。我们评估最终模型，并说明了模型部署所需的准备步骤。本章的处理方式准确地反映了企业中数据科学家的职责。

第九章, 生产评分和 H2O MOJO，开始关注模型部署。机器学习工程师、企业架构师、软件开发人员和一般技术人员将特别关注本章。您将熟悉 H2O MOJO 作为评分工件的优势，以及它如何轻松地部署到各种企业系统中。您将通过编写一个批处理文件评分程序来结束，该程序嵌入了一个 MOJO 以展示这种灵活性。

第十章, H2O 模型部署模式，探讨了 MOJO 可以部署的多种方式。您将首先概述各种可能的部署模式，然后深入到每个模式的实现细节。这些模式涵盖了在多种专门的 H2O 评分软件、第三方集成以及您自己的定制系统中进行实时流评分和批处理评分。

第十一章, 管理员和操作视图，以 H2O 在规模上的企业利益相关者的视角开始关注机器学习。尽管专注于企业利益相关者的活动和关注点，但数据科学家将了解它们如何与自己的活动相关。在本章中，系统管理员和操作员将详细了解如何配置企业 Steam，以及如何确保用户的安全和管理，以便数据科学家可以以受控的方式自行提供环境。我们还将确定围绕维护和故障排除 H2O 工作负载和组件的操作活动。

第十二章, 企业架构师和安全视图，涵盖了 H2O at Scale 组件的企业架构师和安全视角。您将详细了解 H2O 的实施替代方案以及组件如何集成、通信和部署。您将看到 H2O at Scale 框架可以独立部署，也可以作为更大规模的H2O AI Cloud的一部分进行部署，我们将在下一章中介绍。

第十三章, 介绍 H2O AI Cloud，概述了 H2O.ai 的全端到端机器学习生命周期平台。H2O at Scale 框架和本书至今所涵盖的一切都是 H2O AI Cloud 的一个较小子集。在本章中，我们将概述 H2O AI 组件及其关键特性，包括四个专门的模型构建引擎、一个功能齐全的MLOps和特征存储，以及一个开源的低代码 SDK，用于构建和集成AI 应用并在应用商店上托管它们。

第十四章, 在大平台环境中的大规模 H2O，通过总结我们所学的一切，展示了当 H2O at Scale 框架作为 H2O AI Cloud 的一部分使用时，获得了全新的和令人兴奋的可能性。我们提供了这些可能性的示例，然后展示了一个使用 H2O 的参考企业集成框架，以便您想象自己的可能性。

附录, 启动 H2O 集群的替代方法，展示了您可以使用不同的方式创建 H2O 环境来运行本书中的代码示例。

要充分利用本书

要运行代码示例，您需要设置一个 H2O 环境。附录展示了三种实现方式，并描述了软件版本。

如果您使用的是本书的数字版，我们建议您亲自输入代码或从本书的 GitHub 仓库（下一节中有一个链接）获取代码。这样做将帮助您避免与代码复制粘贴相关的任何潜在错误。

从概念上讲，我们在介绍广泛的机器学习概念之前，再介绍 H2O 如何实现它们。因此，您应该能够从您对机器学习的更广泛理解框架中理解书中的讨论。

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件，网址为 github.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O。如果代码有更新，它将在 GitHub 仓库中更新。

我们还有其他来自我们丰富图书和视频目录的代码包，可在 github.com/PacktPublishing/ 获取。查看它们吧！

下载彩色图片

我们还提供了一份包含本书中使用的截图和图表的彩色 PDF 文件。您可以从这里下载：packt.link/sDmtM。

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“h2o.explain 和 h2o.explain_row 方法分别捆绑了一组用于全局和局部解释的可解释性函数和可视化。”

代码块设置如下：

from pysparkling import *

import h2o

hc = H2Ocontext.getOrCreate()

hc

任何命令行输入或输出都应如下所示：

PYSPARK_DRIVER_PYTHON="ipython" \
PYSPARK_DRIVER_PYTHON_OPTS="notebook" \
bin/pysparkling

粗体：表示新术语、重要词汇或您在屏幕上看到的词汇。例如，菜单或对话框中的词汇以粗体显示。以下是一个示例：“在 Flow 的管理员菜单下，前三个选项是作业、集群状态和水表。”

小贴士或重要注意事项

看起来是这样的。

联系我们

我们始终欢迎读者的反馈。

customercare@packtpub.com 并在邮件主题中提及书名。

勘误表：尽管我们已经尽最大努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，我们非常感谢您能向我们报告。请访问 www.packtpub.com/support/errata 并填写表格。

copyright@packt.com 并附上材料链接。

如果您有兴趣成为作者：如果您在某个领域有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问 authors.packtpub.com。

分享您的想法

读完 Machine Learning at Scale with H2O 后，我们非常乐意听到您的想法！请点击此处直接进入此书的亚马逊评论页面并分享您的反馈。

您的评论对我们和科技社区非常重要，并将帮助我们确保我们提供高质量的内容。

第一部分 – H2O 机器学习平台介绍，适用于大规模数据

本节提供了使用 H2O 在规模上进行机器学习（ML）的总体背景。我们将定义规模化的机器学习，关注其挑战，然后看看 H2O 如何克服这些挑战。然后我们将概述每个 H2O 组件，以便更好地理解其目的和从技术角度如何工作。然后我们将通过实现最小工作流程来使用这些组件。在本节之后，我们将准备好深入探讨高级主题和技术。

本节包含以下章节：

• 第一章, 机遇与挑战

• 第二章, 平台组件和关键概念

• 第三章, 基本工作流程 – 数据到可部署模型

第一章：机遇与挑战

机器学习（ML）和数据科学正在赢得一场某种程度的受欢迎竞赛，正如其在流行和专业媒体中的头条报道以及技术领域不断扩大的职位空缺所见证的那样。学生通常使用自己的电脑在相对较小的数据集上学习 ML 技术。那些进入这个领域的人通常会发现自己处于一个完全不同的环境中，即一个大型公司，那里有工人执行专业的工作角色，同时与其他分散在全国或世界各地的人合作。数据科学学生和数据科学工作者有一些共同的关键点——他们在一个令人兴奋且不断发展的领域中，这个领域对企业未来的重要性被认为越来越关键，而他们所依赖的数据正以指数级增长和多样化。

企业中 ML 有着巨大的机遇，因为 ML 对商业、客户、患者等产生的变革性影响是多样化的、广泛的、有利可图的，甚至是改变生活的。同时，也存在紧迫的背景，因为所有竞争对手都在尝试同样的事情。因此，企业有动力投资于重大的 ML 转型，并提供必要的数据、工具、生产系统和人员，以实现 ML 成功。但挑战也同样巨大，而且这些挑战通常围绕着规模展开。规模的挑战以许多企业级 ML 固有的形式出现。

在本章中，我们将通过涵盖以下主要主题来定义和探讨扩规模的 ML 挑战：

• 扩规模的 ML

• ML 生命周期和扩规模的 ML 三个挑战领域

• H2O.ai 对这些挑战的回应

扩规模的 ML

本书是关于实施扩规模的 ML 以及如何使用 H2O.ai 技术取得成功的。我们具体指的是什么叫做扩规模的 ML？在 ML 生命周期中，我们可以看到三个扩规模的环境和挑战——从大型数据集中构建模型，在企业生产环境中部署这些模型，以及在企业流程和利益相关者的复杂性中执行 ML 活动的全部范围。这总结在以下图中：

![图 1.1 – 扩规模的 ML 的挑战]

![img/B16721_01_01.jpg]

图 1.1 – 扩规模的 ML 的挑战

让我们进一步深入探讨这些挑战。在这样做之前，我们将概述机器学习（ML）的生命周期的一般概念，这将在整本书中作为参考。

ML 生命周期和扩规模的 ML 三个挑战领域

ML 生命周期是一个数据科学家和企业利益相关者遵循的过程，用于构建 ML 模型并将它们投入生产环境，在那里它们做出预测并实现价值。在本节中，我们将定义一个简化的 ML 生命周期，并详细阐述两个对扩规模的 ML 带来特殊挑战的广泛领域。

简化的 ML 生命周期

我们将使用以下机器学习生命周期表示。目标是实现一个简化的描述，我们都能认识到它是机器学习的核心，同时避免试图给出一个权威的定义。让我们将其作为讨论的工作框架：

![图 1.2 – 简化的机器学习生命周期

![img/B16721_01_02.jpg]

图 1.2 – 简化的机器学习生命周期

以下是一个简要的阐述。

模型构建

模型构建是一个高度迭代的流程，在构建一个值得在商业环境中部署的预测模型的过程中，会有频繁且不可预测的反馈循环。步骤可以总结如下：

• 数据摄取：从数据源或模型构建环境中的存储层中提取数据。通常，在此之后会有大量工作，用于寻找和访问可能有用的数据源，并将数据转换为可用的形式。通常，这作为更大数据管道和架构的一部分来完成。

• 数据探索：探索数据以了解其特性（例如，数据概览、相关性分析、异常检测和数据可视化）。

• 数据处理：数据被清理（例如，缺失数据的插补、分类特征的降维和归一化）并生成新的特征。

• 模型训练：选择一个机器学习算法、评分指标和验证方法，并在一系列超参数范围内调整模型，然后使用测试数据集对其进行测试。

• 模型评估和可解释性：对模型的拟合进行诊断，以评估性能指标、过拟合和其他诊断；使用模型可解释性来验证领域知识，解释模型在个体和全局层面的决策，并防范如对人口群体不公平偏见等机构风险。

• 模型部署：将模型作为评分工件部署到软件系统中，并进行实时评分。

• 模型监控：监控模型以检测输入数据随时间变化是否与训练数据分布不同。这被称为数据漂移，通常会导致模型预测能力的下降。这通常触发需要使用更当前的数据集重新训练模型，然后重新部署更新后的模型。模型也可能被监控以检测其他模式，例如是否对特定人口群体做出偏见决策，以及是否正在尝试通过恶意攻击导致模型故障。

如前所述，工作流程中的一个关键属性是在模型部署之前或项目被认为未能达到该阶段之前，在这些步骤之间采取的未知数量和顺序的迭代路径。

模型构建挑战 – 规模化的最先进模型

现在，让我们定义大数据集为任何超出您在笔记本电脑或本地工作站上构建机器学习模型能力的数据集。这可能是因为您的库直接崩溃，或者因为它们需要不合理的时间来完成。这种情况可能发生在模型训练期间，也可能发生在数据摄入、探索和操作期间。

我们可以看到从大数据量构建机器学习模型时存在的四个单独的挑战，每个挑战都导致了一个更大的问题，我们称之为迭代的摩擦。这在上面的图中表示：

![Figure 1.3 – 大数据量建模的挑战

![img/B16721_01_03.jpg]

图 1.3 – 大数据量建模的挑战

让我们详细说明这一点。

第一大挑战 – 数据大小和位置

企业收集和存储了大量的多样化数据，这对希望构建准确模型的数据科学家来说是一大福音。这些数据集要么存储在许多系统中，要么集中在一个共同的存储层（数据湖）中，例如Hadoop 分布式文件系统（HDFS）或AWS S3。为内部消费者架构和提供数据是一项重大的努力和挑战。然而，数据科学家在开始使用大数据集的机器学习生命周期时，由于安全原因或数据量过大，一旦数据变得可访问，通常无法将其移动到本地环境。结果是，数据科学家必须做以下之一：

• 将数据操作（换句话说，将计算）移动到数据本身。

• 将数据移动到他们有权使用的计算密集型环境。

第二大挑战 – 数据大小和数据操作

操作数据可能非常计算密集，如果尝试在资源不足的情况下进行，可能会导致计算失败（例如，脚本、库或工具会崩溃）或花费不合理的长时间。谁愿意等待 10 小时来连接和过滤表数据，而实际上可以在 10 分钟内完成？您可能认为不合理的时间显然与数据集大小有关；处理数以兆字节计的数据总是比处理几兆字节的数据需要更长的时间。无论如何，您数据处理的速度对于减少迭代总时间至关重要。

第三大挑战 – 数据大小和数据探索

数据探索期间的数据大小挑战与数据操作期间的数据大小挑战相同。数据可能如此之大，以至于在探索模型时，您的处理会崩溃或花费不合理的时间来完成。

第四大挑战 – 数据大小和模型训练

机器学习算法极其计算密集型，因为它们会遍历数据集的每一条记录，并在每次遍历中进行复杂的计算，然后反复对这些计算进行迭代，以优化训练指标，从而在噪声中学习预测数学模式。我们的计算环境在模型训练期间尤其紧张。

迄今为止，我们一直在相对意义上讨论数据集的大小；也就是说，大量数据量是那些在给定计算环境中导致操作失败或需要很长时间才能完成的数据量。

从绝对意义上讲，数据科学家通常会探索尽可能大的数据集来理解它，然后抽样用于模型训练。其他人总是试图使用最大的数据集进行模型训练。然而，从 10 GB 或更少的数据中，无论是抽样还是未抽样，都可以构建出准确模型。

正确使用抽样的关键是，你已经遵循了适当的统计和理论实践，而不是因为你被迫这样做，因为你的机器学习处理会因为大量数据而崩溃或需要很长时间才能完成。后者是一种不良实践，会产生劣质模型，而 H2O.ai 通过允许使用大量数据进行模型构建来克服这一点。

也有这样的情况，数据抽样可能不会导致一个可接受的模型。换句话说，数据科学家可能需要数百 GB 或更多数据来构建一个有价值的模型。在这些情况下，以下适用：

• 数据科学家不相信抽样能产生最佳模型，并认为每次提升的微小收益都值得使用完整的数据集。

• 数据科学家不想将数据分割成单独的数据集，从而进行单独的模型构建练习，或者更大的利益相关者群体希望有一个单一的模型在生产中预测所有细分市场，而不是每个细分市场都预测一个单一的市场。

• 数据具有高度维度、稀疏性，或者两者兼而有之。在这种情况下，需要大量记录来减少训练数据集的方差和过拟合。这种类型的数据库在异常检测、推荐引擎、预测性维护、安全威胁检测、个性化医疗等领域很典型。值得注意的是，未来将带给我们越来越多的数据，因此高度维度和稀疏的数据库将变得更加普遍。

• 数据极度不平衡。目标变量在数据集中非常罕见，需要大量数据集来避免欠拟合、过拟合或从这些不频繁的记录中加权目标变量。

• 数据非常波动。收集到的每个数据子集都不代表其他数据，因此采样或交叉验证折可能不具有代表性。时间序列预测可能特别容易受到这个问题的影响，尤其是在预测类别对单个验证数据集非常细粒度（例如，按年、月、日和小时）时。

迭代的摩擦

模型构建是一个高度迭代的过程，任何减慢其速度的因素我们称之为迭代的摩擦。这些原因可能是由于之前讨论过的处理大量数据时的挑战。它们也可能源于简单的流程模式，例如在每次迭代之间在系统之间切换或在迭代上工作的新环境中启动。

在单个迭代过程中出现的任何缓慢可能看起来是可以接受的，但当从项目开始到失败或成功看似无尽的迭代中乘以时，这种摩擦造成的时间成本变得显著，减少摩擦可能是有价值的。正如我们将在下一节中看到的，缓慢的模型构建延迟了企业在机器学习中的主要目标 – 实现业务价值。

商业挑战 – 将你的模型引入企业生产系统

机器学习项目的裸真相是，直到它们被部署到实际评分环境中，它们实际上并没有实现价值。模型必须满足评估标准并投入生产才能被认为是成功的。直到那时，从商业角度来看，所取得的成就很少。这听起来可能有些苛刻，但在数据科学项目中，成功通常就是这样定义的。以下图表将这种思考映射到机器学习生命周期：

图 1.4 – 机器学习生命周期价值链

从这个角度来看，迭代的摩擦因此是一种成本。用于模型构建的迭代所需的时间是从获得业务结果中抽取的时间。换句话说，较低的摩擦意味着构建和部署模型以实现业务价值所需的时间更少，而有更多的时间来处理其他问题，从而在每季度或每年产生更多的模型。

从同样的角度来看，部署模型的时间被视为一种成本，原因类似。模型部署步骤可能看起来像是一个简单的将模型过渡到 DevOps 的单步序列，但通常并非如此。任何使模型更容易部署、文档化和管理的因素都有助于企业更快地实现价值。

让我们现在继续扩大企业利益相关者的范围，数据科学家必须与他们合作，以构建最终实现业务价值的模型。

导航挑战 – 导航企业利益相关者景观

任何企业中的数据科学家都不是孤立工作的。有多个利益相关者直接参与机器学习生命周期，或者更广泛地说，参与启动和消费机器学习项目的商业周期。这些利益相关者可能包括谁？至少包括资助机器学习项目的商业利益相关者、向数据科学家提供权限和能力的管理员、负责模型部署及其基础设施的 DevOps 或工程团队成员、其职能直接受模型影响的营销或销售合作伙伴，以及模型内部或外部消费者的任何其他代表。在银行、保险或制药等高度监管的行业中，这些可能包括各种审计和风险职能的代表或办公室——数据风险、代码风险、模型风险、法律风险、声誉风险、合规性、外部监管机构等。以下图表展示了一个一般视图：

图 1.5 – 数据科学家与企业利益相关者和流程合作

利益相关者之间的互动因此变得复杂。是什么导致了这种复杂性？显然，职业功能的专门化和隔离使得事情变得复杂，而企业的规模进一步放大了这一点。创建可重复的过程和最小化风险的更大动态也起到了作用。解释这种复杂性是另一本书的任务，但在企业中的现实是无法避免的。对于数据科学家来说，能够识别、影响、协商、交付并最终与这些不同的利益相关者建立信任，对于成功实施规模化的机器学习解决方案至关重要。

现在我们已经了解了机器学习生命周期及其在规模化成功执行中固有的挑战，是时候简要介绍 H2O.ai 如何解决这些挑战了。

H2O.ai 对这些挑战的回应

H2O.ai 提供软件以规模化构建机器学习模型，并克服构建过程中的挑战——规模化模型构建、规模化模型部署，以及在整个过程中处理企业利益相关者的关注点和固有的摩擦。以下图表简要描述了这些组件：

图 1.6 – H2O ML 规模化

本书后续章节详细阐述了如何使用这些组件在企业环境的复杂性中构建和部署最先进的模型。

让我们先尝试对这些组件进行初步了解：

• H2O 核心：这是开源软件，在 Kubernetes、Hadoop 或 Spark 环境中指定数量的服务器上分发最先进的机器学习算法和数据操作。数据在指定的服务器数量之间在内存中分区，并使用它并行运行机器学习算法计算。

这种架构创建了模型构建的水平可扩展性，可以处理数百 GB 或 TB 的数据，并且在数据量较低时通常具有较快的处理时间。数据科学家使用熟悉的 IDE、语言和算法，并且从底层架构中抽象出来。因此，例如，数据科学家可以从 Jupyter 笔记本中在 Python 中运行 XGBoost 模型，针对 Hadoop 中的 500GB 数据，类似于将数据加载到他们的笔记本电脑中。

H2O 核心通常被称为H2O 开源，有两种形式，H2O-3和Sparkling Water，我们将在后续章节中详细说明。H2O 核心可以作为缩小的沙盒在单个服务器或笔记本电脑上运行。

• H2O 企业版蒸汽：这是一个数据科学家可以自助配置和管理他们各自的 H2O 核心环境的 Web UI 或 API。自助配置包括根据用户描述数据的输入自动计算水平扩展。企业版蒸汽也被管理员用来管理用户，包括定义他们资源消耗的边界，以及配置 H2O 核心与 Hadoop、Spark 或 Kubernetes 的集成。

• H2O 魔豆：这是一个易于部署的评分工件，可以从 H2O 核心构建的模型中导出。MOJOs 是低延迟（通常小于 100 毫秒或更快）的 Java 二进制文件，可以在任何Java 虚拟机（JVM）上运行，因此可以在各种软件系统上提供预测，例如 REST 服务器、数据库客户端、Amazon SageMaker、Kafka 队列、Spark 管道、Hive 用户定义函数（UDFs）和物联网（IoT）设备。

• APIs：每个组件都有一套丰富的 API，这样您就可以自动化工作流程，包括持续集成和持续部署（CI/CD）和重新训练管道。

本书重点介绍使用 H2O 核心在帮助企业环境中部署最先进的模型，并使用企业版蒸汽帮助构建这些模型，将这些模型作为 MOJOs 部署。

H2O 大规模和 H2O AI 云

在本书中，我们将大规模的 H2O称为 H2O 企业版蒸汽、H2O 核心和 H2O 魔豆，因为它解决了本章前面描述的大规模机器学习挑战，特别是通过 H2O 核心为模型构建提供的分布式机器学习可扩展性。

注意，H2O.ai 提供了一个更大的端到端 ML 平台，称为H2O AI Cloud。H2O AI Cloud 集成了超先进的 AutoML 工具（称为H2O Driverless AI）和其他模型构建引擎，一个 MLOps 评分、监控和治理环境（称为H2O MLOps），以及一个低代码软件开发工具包（SDK），称为H2O Wave，它具有 H2O API 钩子，用于构建发布到App Store的 AI 应用程序。它还集成了本书中定义的 H2O 大规模。

H2O 大规模可以部署为独立系统或作为 H2O AI Cloud 的一部分。作为一个独立实现，企业蒸汽实际上不是必需的，但正如本书后面详细阐述的原因，企业蒸汽被认为对企业实施是必不可少的。

本书的大部分内容都集中在 H2O 大规模上。本书的最后部分将扩展我们的理解，以涵盖 H2O AI Cloud 以及 H2O 大规模组件如何利用这个更大的集成平台，反之亦然。

摘要

在本章中，我们为使用 H2O.ai 技术理解和实施大规模机器学习（ML）奠定了基础。我们定义了企业环境中多种形式的规模，并从模型构建、模型部署和企业利益相关者的角度阐述了 ML 面临的挑战。我们最终将这些挑战锚定到 ML 的最终目标——提供商业价值。最后，我们简要介绍了企业用于克服这些挑战并实现商业价值的 H2O 大规模组件。

在下一章中，我们将更深入地了解这些组件的技术细节，以便我们可以开始编写代码和进行数据科学。

第二章：平台组件和关键概念

在本章中，我们将对 H2O 大规模机器学习技术的组件有一个基本理解。我们将查看 H2O 机器学习的简单代码示例，了解它做什么，并确定示例在企业管理规模机器学习方面可能存在的问题。这个Hello World代码示例将作为一个简单的表示，以便进一步构建我们的理解。

我们将概述 H2O 机器学习大规模的每个组件，确定每个组件如何实现规模，以及每个组件如何与我们的简单代码片段相关联。然后，我们将使用这些组件将这些组件组合成一个参考机器学习工作流程。最后，我们将关注从这些组件中产生的底层关键概念。在本章中获得的理解将是本书其余部分的基础，其中我们将实现 H2O 技术，在企业环境中构建和部署大规模的先进机器学习模型。

在本章中，我们将涵盖以下主要主题：

• Hello World – H2O 机器学习代码

• H2O 机器学习大规模的组成部分

• 使用这些 H2O 组件的机器学习工作流程

• H2O 关键概念

技术要求

对于本章，您需要在本地安装 H2O-3 以运行一个基本的Hello World工作流程。要实现它，请遵循附录中的说明。请注意，我们将全书使用 Python API，因此请按照说明在 Python 中安装它。

Hello World – H2O 机器学习代码

H2O 核心是为大规模机器学习设计的；然而，它也可以用于用户笔记本电脑上的小数据集。在下一节中，我们将使用 H2O-3 的最小代码示例构建一个机器学习模型，并将其导出为可部署的工件。我们将使用这个示例作为理解 H2O 机器学习代码的最基本单元，就像通过查看人类棍状图开始学习人类生物学一样。

代码示例

查看下面的代码示例。在这里，我们使用 Python 编写，这可能是来自 Jupyter、PyCharm 或其他 Python 客户端。我们将了解到 R 和 Java/Scala 是编写 H2O 代码的替代语言。

让我们先导入 H2O 库：

import h2o

从文档中回忆，这已经从 H2O 下载并安装到客户端或 IDE 环境中。这个h2o包允许我们使用 Python 编写的 H2O API 在 IDE 中运行内存分布式机器学习。

接下来，我们创建一个 H2O 集群：

h2o.init(ip="localhost", port=54323)

上一行代码创建了一个所谓的 H2O 集群。这是 H2O 模型构建技术背后的一个关键概念。它是一个分布式内存架构。在 Hello World 案例中，H2O 集群将在笔记本电脑上作为 localhost 创建，并且不会分布式。我们将在本章的 H2O 关键概念 部分学习更多关于 H2O 集群的内容。

用于启动 H2O 集群的 ip 和 port 配置应提供足够的线索，表明 H2O 代码将通过 API 发送到计算环境，这可能是在数据中心或企业环境中，也可能是云端。然而，在这里，它是在我们的本地主机上。

然后，我们导入一个数据集：

loans = h2o.import_file("https://raw.githubusercontent.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/main/chapt2/loans-lite.csv")

现在我们来探索数据集：

loans.describe()

这是最小限度的数据探索。它只是简单地返回行数和列数。

好的，现在让我们为我们的模型准备数据：

train, validation = loans.split_frame(ratios=[0.75])

label = "bad_loan"

predictors = loans.col_names

predictors.remove(label)

我们已经将数据分为训练集和验证集，其中训练集的比例为 0.75。我们将预测一笔贷款是否会坏账（即是否会违约）并已将该列标识为标签。最后，我们使用数据集中的所有列（除了坏账列）来定义用于预测坏账的列。

现在，我们构建模型：

from h2o.estimators import H2OXGBoostEstimator

param = {"ntrees" : 25, "nfolds" : 10}

xgboost_model = H2OXGBoostEstimator(**param)

xgboost_model.train(x = predictors,

                    y = label,

                    training_frame = train,

                    validation_frame = validation)

我们已经导入了 H2O 的 XGBoost 模块，并为其配置了两个超参数。然后，我们通过输入参考到预测列、标签列、训练数据和测试数据中，开始模型训练。

XGBoost 是 h2o 模块中包装的许多广泛认可和广泛使用的机器学习算法之一。该模块暴露的 H2O API 将在 H2O 的架构上运行 XGBoost 模型，在企业基础设施上，正如我们稍后将要学习的。关于超参数，我们将发现 H2O 为每个模型提供了一套广泛的可配置超参数。

当模型完成时，我们可以使用一行代码导出模型：

xgboost_model.download_mojo(path="~/loans-model", get_genmodel_jar=True)

导出的评分工件现在可以传递给 DevOps 进行部署。get_genmodel_jar=True 参数触发下载以包括 h2o-genmodel.jar。这是一个模型在 H2O 集群之外评分时使用的库，即在生产环境中。我们将在 第三部分 – 将您的模型部署到生产环境 中学习更多关于生产化 H2O 模型的内容。

目前我们已经完成了模型构建。因此，我们将关闭集群：

h2o.cluster().shutdown()

这将释放 H2O 集群所使用的资源。

请记住，这是一个简单的 Hello World H2O 模型构建示例。它的目的是做以下两件事：

• 对 H2O 模型构建提供一个最基本介绍。

• 作为讨论企业中规模问题的基础，我们将在下一节中进行讨论。

在 第二部分 - 使用 H2O 在大量数据上构建最先进的模型 中，我们将探讨构建高度预测性和可解释模型的多种技术。让我们从讨论 Hello World 示例暴露的规模化问题开始我们的旅程。

规模化的一些问题

这段 Hello World 代码在企业环境中扩展性不佳。让我们重新审视代码，以更好地理解这些扩展限制。

我们在我们的 IDE 代码中导入库：

import h2o

大多数企业希望对所使用的库版本有所控制。此外，他们通常希望提供一个中央平台来托管和验证一项技术的所有用户，并让管理员管理该平台。我们将发现，企业 Steam 在集中管理用户和 H2O 环境方面发挥着关键作用。

我们初始化 H2O 集群：

h2o.init(ip="localhost", port=54323)

规模化机器学习需要将计算资源分布在服务器集群中，以实现横向扩展（即在许多服务器之间划分和征服计算资源）。因此，IP 地址和端口应该指向服务器集群的成员，而不是单个计算机，如本例所示。我们将看到 H2O Core 会创建自己的自组织集群，该集群负责分配和横向扩展模型构建。

由于扩展是在企业服务器集群上进行的，通常情况下，许多个人和团体都会使用这个集群，因此企业希望控制用户对这个环境的访问以及用户消耗的资源数量。但是，这又如何阻止用户启动多个 H2O 集群，在每个集群上尽可能多地使用资源，从而阻止其他用户获取资源呢？企业 Steam 管理企业服务器集群上的 H2O 用户和 H2O 资源消耗。

我们导入数据集：

loans = h2o.import_file("https://raw.githubusercontent.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/main/chapt2/loans-lite.csv")

大量数据在网络上的移动需要极长的时间，可能需要数小时或数天才能完成传输，或者可能在传输之前就超时了。在规模化的模型构建过程中，计算应该发生在数据所在的位置，以防止数据移动的瓶颈。我们将发现，在企业系统中启动的 H2O 集群会直接从存储层将数据摄入到服务器内存中。因为数据分布在构成 H2O 集群的各个服务器上，数据摄入与这些分区并行进行。

我们将看到企业 Steam 如何集中用户身份验证，以及用户的身份信息如何传递到企业系统，在那里其原生授权机制得到尊重。

我们训练模型：

xgboost_model.train(x = predictors,

                    y = label,

                    training_frame = train,

                    validation_frame = validation)

当然，这是模型构建过程的核心，也是本书许多内容的焦点：如何使用 H2O 的广泛机器学习算法和模型构建能力，在大量数据上构建世界级的机器学习模型。

我们下载可部署的模型：

xgboost_model.download_mojo(path="~/loans-model", get_genmodel_jar=True)

请记住，从商业角度来看，直到模型导出并部署到生产中，才能实现价值。这样做涉及到多个企业利益相关者的复杂性。我们将学习如何设计导出的MOJO（模型对象，优化）的功能，以简化涉及这些利益相关者的各种软件系统的部署。

我们关闭了 H2O 集群：

h2o.cluster().shutdown()

H2O 集群使用资源，当不使用时应关闭。如果不这样做，其他用户或企业系统上的作业可能会竞争这些资源，从而受到影响。此外，在必须扩展基础设施之前，系统中可以添加的新用户数量会减少。我们将看到企业蒸汽如何管理 H2O 用户在企业系统上消耗资源。这种资源效率的提高使得 H2O 用户及其工作在给定的基础设施分配上能够更有效地扩展。

现在我们已经运行了我们的Hello World示例并探讨了其关于扩展的一些问题，让我们继续了解 H2O 组件，以便在大规模机器学习模型构建和部署中取得理解。

H2O 机器学习大规模组件

如前一章所述，并在整本书中强调，H2O 机器学习克服了扩展问题。以下是对 H2O 大规模机器学习每个组件的简要介绍以及每个组件如何克服这些挑战。

H2O Core – 内存分布式模型构建

H2O Core 允许数据科学家编写代码，使用知名的机器学习算法构建模型。编码体验是通过 Python、R 或 Java/Scala 语言表达的 H2O API 实现的，并在他们喜欢的客户端或 IDE 中编写，例如在 Jupyter 笔记本中的 Python。然而，模型构建的实际计算是在企业服务器集群（而不是 IDE 环境）上进行的，并利用服务器集群的大量内存和 CPU 资源来运行针对大量数据的机器学习算法。

那么，它是如何工作的呢？首先，用于模型构建的数据由 H2O 在服务器集群上分区和内存中分布式。IDE 将 H2O 指令发送到服务器集群。集群中的服务器接收这些指令并将它们分发到集群中的其他服务器。指令在分区内存数据上并行运行。接收指令的服务器收集和合并结果，并将它们发送回 IDE。随着代码通过 IDE 的序列执行，这个过程会重复进行。

这种分而治之的方法是 H2O 大规模模型构建的基础。H2O 分而治之架构的一个单元被称为 H2O 集群，在章节的后面将详细阐述为关键概念。结果是快速在大数据量上构建模型。

H2O Core 的关键特性

H2O Core 的一些关键特性如下：

• 水平扩展：数据操作和机器学习算法在并行和内存中分布，并具有额外的优化，如分布式键/值存储，以在模型构建期间快速访问数据和对象。

• 熟悉的经验：数据科学家使用熟悉的语言和 IDE 编写 H2O API 代码，正如我们刚刚所做的那样。

• 开源：H2O Core 是开源的。

• 广泛的文件格式：H2O 支持广泛的源数据格式。

• 数据处理：H2O API 包含了广泛的数据处理任务，这些任务通常用于准备机器学习所需的数据。Sparkling Water（下一节将介绍）将数据工程技术扩展到 Spark。

• 公认的机器学习算法：H2O 使用了广泛公认的监督和无监督机器学习算法。

• 训练、测试和评估：使用交叉验证、网格搜索、变量重要性和性能指标等广泛的技术来训练、测试和评估模型；这还包括模型检查点功能。

• 自动机器学习 (AutoML): H2O Core 自动机器学习 API 提供了一个简单的包装函数，可以简洁地自动化多个模型的训练和调优，包括堆叠集成，并以排行榜的形式展示结果。

• 模型可解释性：它提供了广泛的局部和全局可解释性方法和可视化，适用于单个模型或参与 AutoML 的模型，所有这些都可以通过单个包装函数实现。

• AutoDoc：它能够自动生成标准化的 Word 文档，详细描述模型构建和可解释性；请注意，AutoDoc 不是一个免费的开源平台。

• 可导出的评分工件 (MOJO)：它使用一行代码将模型导出为可部署的评分工件（模型部署将在第三部分“将您的模型部署到生产环境”中更详细地讨论）。

• H2O 流 Web UI：这是一个可选的基于 Web 的交互式 UI，可以引导用户通过模型构建工作流程，提供简单而丰富的点选体验，这对于 H2O 模型的快速实验和原型设计非常有用。

H2O-3 和 H2O Sparkling Water

H2O Core 有两种版本：H2O-3 和 H2O Sparkling Water。

H2O-3 是 H2O Core，如前所述。H2O Sparkling Water 是 H2O-3 通过 Spark 集成包装的。它与 H2O-3 相同，并具有以下附加功能：

• Spark 和 H2O API 代码的无缝集成：用户在同一个 IDE 中编写 Spark 和 H2O 代码；例如，使用 SparkSQL 代码进行数据处理，使用 H2O 代码构建世界级的模型。

• H2O 和 Spark DataFrame 之间的转换：H2O 和 Spark DataFrame 作为无缝集成的一部分进行相互转换；因此，SparkSQL 数据处理的结果可以用作 H2O 模型构建的输入。

• 火花引擎：Sparkling Water 作为原生 Spark 应用程序在 Spark 框架上运行。

H2O-3 和 Sparkling Water 是更通用的 H2O Core 的模型构建替代方案。在较大的企业服务器集群上启动的 H2O 集群的概念对两种 H2O Core 版本都是相似的，尽管一些实现细节不同，但这些对数据科学家来说是基本不可见的。如前所述，Sparkling Water 特别适用于集成 Spark 数据工程和 H2O 模型构建工作流程。

H2O Enterprise Steam – 一个可管理的、自助配置的门户

企业蒸汽为数据科学家提供了一个集中的 Web UI 和 API，用于初始化和终止他们的 H2O 环境（称为 H2O 集群），以及管理员管理 H2O 用户和 H2O 与企业服务器集群的集成。

企业蒸汽的关键特性

企业蒸汽的关键特性如下：

• 数据科学自助配置：这是一种简单、基于 UI 的方式，让数据科学家管理他们的 H2O 环境。

• 所有 H2O 用户的集中访问点：这简化了 H2O 用户管理，并为 H2O 访问企业服务器集群提供了一个单一的入口点。

• 管理用户资源消耗：管理员为用户或用户组建立资源使用边界配置文件。这限制了用户在企业服务器集群上可以分配的资源数量。

• 无缝安全：用户对企业蒸汽的认证流程会传递到企业服务器集群上的资源授权。企业蒸汽使用与企业服务器集群相同的身份提供者（例如，LDAP）进行认证。

• 配置集成：管理员配置 H2O 与企业服务器集群和身份提供者的集成。

• 管理 H2O Core 版本：管理员管理一个或多个数据科学家用于创建模型构建 H2O 集群的 H2O Core 版本。

H2O MOJO – 一种灵活、低延迟的评分工件

从 H2O Core 构建的模型被导出为可部署的评分工件，称为 H2O MOJOs。MOJOs 可以在任何 JVM 环境中运行（可能，除了非常小的边缘设备之外）。

在第三部分 – 将您的模型部署到生产环境中，我们将了解到 MOJOs 可以直接部署到 H2O 软件以及许多第三方评分解决方案，无需编写代码。然而，如果您希望直接将 MOJOs 嵌入到自己的软件中，有一个 MOJO Java API 来构建 Java 辅助类以公开 MOJO 功能（例如，输出原因代码以及预测）并提供与评分输入和输出的灵活集成。

与所有模型相比，无论用于构建模型的机器学习算法如何，MOJOs 的结构都是相同的。因此，从 DevOps 的角度来看，部署是可重复和可自动化的。

MOJOs 的关键特性

MOJO 的关键特性如下：

• 低延迟：通常，每个评分的延迟小于 100 毫秒。

• 灵活的数据速度：Mojos 可以对批量、实时和流数据（例如，对整个数据库表、作为 REST 端点和 Kafka 主题等）进行预测。

• 灵活的目标系统：这适用于 JVM 运行时，包括 JDBC 客户端、REST 服务器、AWS Lambda、AWS SageMaker、Kafka 队列、Flink 流、包括流处理的 Spark 管道、Hive UDF、Snowflake 的外部函数等。目标系统可以是专门的 H2O 评分软件、第三方评分软件或您自己的软件。一个常见的模式是将 MOJO 部署到 REST 服务器，并通过客户端应用程序（例如 Excel 电子表格）的 REST 调用来消费其预测。

• 可解释性功能：除了预测之外，您还可以在实时评分期间从 MOJO 接收 K-Lime 或 Shapley 原因代码，并且可以将 MOJO 加载到 H2O Core 中进行评分和检查 MOJO 属性。

• 可重复部署：MOJO 很容易集成到组织用于软件部署的现有部署自动化（CI/CD）管道中。

注意，H2O MOJO 有一个替代方案，称为 POJO，用于不常见的边缘情况。这将在 第八章，整合一切 中进一步探讨。

使用 H2O 组件的工作流程

现在我们已经了解了 H2O 的机器学习大规模组件的角色和关键特性，让我们将它们整合成一个高级工作流程，如下面的图所示：

![Figure 2.1 – 使用 H2O 的高级机器学习大规模工作流程

![img/B16721_Figure_2.1.jpg]

图 2.1 – 使用 H2O 的高级机器学习大规模工作流程

工作流程按以下顺序进行：

1. 管理员配置 H2O Enterprise Steam。

2. 数据科学家登录到 H2O Enterprise Steam 并启动 H2O Core 集群（选择 H2O-3 或 H2O Sparkling Water）。

3. 数据科学家使用他们喜欢的客户端，通过 H2O 模型构建 API 的 Python、R 或 Java/Scala 语言版本来构建模型。数据科学家使用 UI 或 IDE 认证到 H2O Enterprise Steam 并连接到在 H2O Enterprise Steam 上启动的 H2O 集群。

4. 数据科学家使用 IDE 通过 H2O 迭代模型构建步骤。

5. 数据科学家确定要部署的模型后，H2O AutoDoc 生成，并且 H2O MOJO 从 IDE 导出。

6. 数据科学家在空闲或绝对运行时间超过后，要么终止H2O 集群，要么等待H2O Enterprise Steam这样做。这些持续时间已由管理员分配给用户的资源配置文件中配置。请注意，已终止的集群检查点仍然在工作，并且可以始终启动一个新的H2O 集群，从终止点继续工作。

7. 该模型以H2O MOJO格式导出，并部署到各种不同的托管目标。模型在业务环境中被使用，业务价值的实现由此开始。

H2O 关键概念

在接下来的章节中，我们将识别和描述 H2O 的关键概念，这些概念是理解前述章节工作流程步骤所必需的。

数据科学家的经验

数据科学家在构建 H2O 模型时具有熟悉的经验，同时抽象出企业服务器集群上基础设施和架构的复杂性。以下图表将进一步详细说明这一点：

图 2.2 – 数据科学家使用 H2O Core 的经验细节

数据科学家使用在企业的分布式基础设施和架构中可扩展的知名无监督和监督机器学习技术。这些技术是用 H2O 模型构建 API 编写的，该 API 用熟悉的语言（如 Python、R 或 Java）编写，并使用熟悉的 IDE（例如 Jupyter 或 RStudio）。

H2O Flow – 一个方便的、可选的 UI

H2O 生成自己的 Web UI，称为 H2O Flow，在模型构建期间使用它是可选的。H2O Flow 的 UI 焦点和功能丰富性可用于完整的模型构建工作流程，或者像我们在第五章中将要展示的，利用它进行一些实用的技巧，高级模型构建 – 第一部分。

因此，数据科学家在一个熟悉的世界中工作，连接到一个复杂的架构，以扩展模型构建到大型或海量数据集。我们将在下一节中探讨这个架构。

H2O 集群

H2O 集群可能是所有利益相关者需要理解的最核心概念。它是 H2O 在企业服务器集群上构建机器学习模型的架构单元。我们可以通过以下图表来理解这个概念：

图 2.3 – H2O 集群的架构

当数据科学家启动一个 H2O 集群时，他们指定要分配工作到多少个服务器（这也就是所谓的节点数），以及每个节点要使用的内存和 CPU 数量。我们将了解到这可以通过手动配置或允许 Enterprise Steam 根据训练数据量自动计算这些规格来实现。

当 H2O 集群启动时，IDE 会将 H2O 软件（一个单一的 JAR 文件）推送到企业服务器集群中指定的每个节点，每个节点分配指定的内存和 CPU。然后，H2O 软件组织成一个自我通信的集群，其中选出一个节点作为领导者，与 IDE 通信并协调 H2O 集群的其他部分。

数据科学家从 IDE 连接到启动的 H2O 集群。然后，数据科学家编写模型构建代码。代码的每一部分都由 IDE 中的 H2O 库翻译成对 H2O 集群的指令。每个指令按顺序发送到 H2O 集群的领导者节点，该节点将其分配给其他 H2O 集群成员，在那里指令并行执行。领导者节点收集和合并结果，并将它们发送回 IDE。

这里有一些重要的注意事项需要记住：

• 数据直接从数据源摄入到 H2O 节点的内存中。源数据在 H2O 节点之间分区，并且不会在它们之间重复。从存储层（例如，S3、HDFS 等）摄入的数据是并行进行的，因此速度快。来自外部源（例如，GitHub 存储库和 JDBC 数据库表）的数据不是并行进行的。在所有情况下，数据都不会通过 IDE 或客户端。

• 每个 H2O 集群都是独立的，并且与其他集群隔离，包括它们所摄入的数据。因此，两个启动集群并使用相同数据源的用户不会共享数据。

• 我们将看到，Enterprise Steam 的管理员为用户可以启动的并发集群数量以及用户在启动集群时可以指定的内存、CPU 和其他资源数量分配了上限。

• H2O 集群是静态的。一旦启动，节点数和每个节点的资源数量不会改变，直到它们被终止，在这种情况下，H2O 集群将被拆解。如果一个节点宕机，H2O 集群必须重新启动，并且从 IDE 开始模型构建步骤。对于更长时间的工作，H2O 的检查点功能可以帮助您从恢复点继续。

让我们看看以下图中 H2O 集群的生命周期：

![Figure 2.4 – H2O 集群的生命周期

Figure 2.4 – H2O 集群的生命周期

让我们逐一查看生命周期的各个阶段，以了解它们是如何工作的：

1. 启动：数据科学家从企业蒸汽 UI 或 API 启动一个 H2O 集群。选择 H2O-3 或 Sparkling Water。H2O 集群的大小和资源（即节点数量、每个节点的内存以及其他配置）是手动输入的，或者由企业蒸汽根据用户输入的数据量自动生成。H2O 集群的形成如前所述。

2. 连接到：数据科学家切换到他们的 IDE，并通过指定其名称来连接到 H2O 集群。

3. 构建模型于：数据科学家使用 H2O 构建模型。在 IDE 中使用的 H2O 库将每个模型构建迭代的 H2O API 代码转换为指令。这些指令被发送到主节点并在 H2O 集群中分发。

4. 停止：H2O 集群被关闭。资源被释放，H2O 软件从 H2O 集群的每个节点中移除。这可以通过用户从 IDE 完成，也可以在空闲时间超过一定时长或当 H2O 集群的绝对运行时间超过（这些时长在 H2O 集群启动时在步骤 1 中指定）后自动发生。尽管没有运行，但用户仍然可以访问有关此集群的信息（例如，名称、H2O 版本和大小）。

停止/保存数据 & 重新启动：这是停止的替代方案，当企业蒸汽管理员为用户或用户组配置此选项时是可能的。在这种情况下，当 H2O 集群停止时，它会将模型构建步骤中的数据保存到存储层（即保存模型构建状态）。当集群重新启动（使用启动时的相同名称）时，集群启动并返回到其之前的状态。

1. 删除：这停止了集群（如果正在运行）并永久删除了所有关于 H2O 集群的引用。如果它已经停止并保存了模型构建状态，这些数据也将被永久删除。

企业蒸汽作为 H2O 网关

所有 H2O 管理活动都在企业蒸汽上发生，用户必须通过 Steam 启动 H2O 集群。这种“条条大路通企业蒸汽”的方法意味着在用户在企业系统中启动之前，Steam 管理用户及其 H2O 集群。这将在以下图中详细说明：

![图 2.5 – 将企业蒸汽视为企业集群的 H2O 网关

图 2.5 – 将企业蒸汽视为企业集群的 H2O 网关

管理员配置设置以管理 H2O 用户并集成企业蒸汽与企业服务器集群。此外，管理员存储将在启动 H2O 集群时推送到服务器集群的 H2O 软件版本，并在集群停止和资源释放时删除。管理员还可以访问用户使用数据。所有这些操作都通过仅管理员 UI 完成。

管理员配置用户和企业环境中用户如何启动 H2O 集群。这些配置定义了用户可以同时启动的并发集群数量、大小（即节点数）以及为每个启动的 H2O 集群分配的资源数量（例如，每个节点的内存）。配置还定义了如果用户没有从 IDE 中的 H2O 模型构建代码手动停止或删除集群，集群将在何时停止或删除。一组此类配置被定义为配置文件，一个或多个配置文件被分配给用户或用户组。因此，管理员可以将一些用户指定为高级用户，而将其他用户指定为普通用户。

用户通过与企业服务器集群环境（例如，S3 存储桶）授权访问资源时实施的相同身份提供者（例如，LDAP）对企业蒸汽进行身份验证。当用户启动集群时，企业蒸汽传递用户身份，并在企业系统上的授权挑战期间使用此身份。在他们的 IDE 中，用户必须对 Enterprise Steam API 进行身份验证，才能连接到他们启动的集群。

H2O 核心需要企业蒸汽吗？

注意，H2O 核心不需要企业蒸汽。企业管理员可以配置他们的企业服务器集群基础设施，以允许在上述基础设施上启动 H2O 集群。

然而，这种方法并不是一个可靠的企业实践。它引入了企业蒸汽作为集中式 H2O 网关所提供的控制和管理损失，如本节所述。此外，企业蒸汽通过在启动 H2O 集群时，使用户免于与 H2O 核心与企业集群集成相关的技术步骤（例如，Kerberos 安全要求）来为用户提供便利。企业蒸汽的好处将在第十一章，“管理员和操作视图”，以及第十二章，“企业架构和安全视图”中更详细地探讨。

此外，请记住，H2O 核心是免费和开源的，而企业蒸汽则不是。

企业蒸汽和 H2O 核心高级架构

既然我们已经了解了 H2O 集群是如何形成的，以及企业蒸汽在管理 H2O 用户和启动 H2O 集群中所起的作用，那么让我们从高级部署的角度来理解企业蒸汽和 H2O 核心架构。以下图表描述了这种部署架构：

![图 2.6 – 企业蒸汽和 H2O 核心高级部署架构

图 2.6 – 企业蒸汽和 H2O 核心高级部署架构

Enterprise Steam 在其专用的服务器上运行，通过 HTTP(S) 与企业服务器集群通信。如前所述，Enterprise Steam 存储了推送到服务器集群的 H2O Core (H2O-3 或 Sparkling Water) JAR 文件，然后该文件在服务器集群中自我组织成一个协调但分布式的 H2O 集群。这个 H2O 集群可以是本地的 YARN 或 Kubernetes 作业，具体取决于实现了哪个后端。请注意，H2O-3 在 Map-Reduce 框架上运行，而 Sparkling Water 在 Spark 框架上运行。

安装了 H2O-3 或 Sparkling Water API 库到数据科学 IDE（例如，在 Jupyter 环境中执行 pip install H2O-3 包）。它必须与从 Enterprise Steam 启动集群所使用的版本相匹配。如前所述，数据科学家使用 IDE 认证到 Enterprise Steam，连接到 H2O 集群，并编写 H2O 模型构建代码。H2O 模型构建代码被 H2O 客户端库转换为发送到 H2O 集群首领节点的 REST 消息。然后，工作在 H2O 集群中分发，并将结果返回到 IDE。

注意，企业集群可以是本地、云基础设施即服务或托管服务实现。例如，可以是本地或云中的 Kubernetes 或 Cloudera CDH，或者云中的 Cloudera CDP 或 Amazon EMR。完整的部署可能性在 第十二章，企业架构师和安全视角 中有更详细的讨论。

H2O 平台选择

本书中的 H2O At Scale 技术被称为包括：H2O Enterprise Steam + H2O Core (H2O-3, H2O Sparkling Water) + H2O MOJO。H2O At Scale 与企业服务器集群集成以进行模型构建，与企业评分环境集成以进行模型部署。

H2O At Scale 可以仅使用前面提到的组件实现。或者，H2O At Scale 可以作为更大的 H2O 机器学习平台和功能集 H2O AI Cloud 的子集实现。H2O AI Cloud 平台在 第五部分 – 扩展视野 – 使用 H2O AI Cloud 平台将数据转换为 AI 应用程序 中有更详细的描述。

Sparkling Water 允许用户在 H2O 和 Spark 中无缝编码

以下代码展示了使用 H2O Sparkling Water 在同一 H2O 代码中集成 Spark 的简单示例：

# import data

loans_spark = spark.read.load("loans.csv", format="csv", sep=",", inferSchema="true", header="true")

# Spark data engineering code

loans_spark = # any Spark SQL or Spark DataFrame code

# Convert Spark DataFrame to H2O Frame

loans = h2oContext.asH2OFrame(loans_spark)

# Continue with H2O model building steps as in previous code example

loans.describe()

代码展示了 Spark 导入数据，这些数据以 Spark DataFrame 的形式保存。使用 Spark SQL 或 Spark DataFrame API 将这些数据工程化为新的 DataFrame，然后将这个 Spark DataFrame 转换为 H2OFrame，从其中执行 H2O 模型构建。因此，用户可以在相同的 API 语言和 IDE 中无缝地从 Spark 迭代到 H2O 代码。

H2O 集群的概念在 Sparkling Water 中仍然根本正确。现在，它将在 Spark 框架内表达 H2O 集群架构。关于这个架构的详细信息在第十二章，“企业架构和安全视图”中进行了阐述。

MOJOs 导出为 DevOps 友好的工件

数据科学家构建模型，但最终目标是将这些模型部署到生产环境中，在商业环境中进行预测。MOJOs 使得部署的最后一步变得简单。MOJOs 可以通过一行代码导出。例如，无论模型是使用 Python、R 还是使用广义线性模型、XGBoost 模型或堆叠集成构建的，从 DevOps 的角度来看，所有 MOJOs 都是相同的。这使得模型部署可重复，因此可以适应组织内部使用的现有自动化 CI/CD 管道。

摘要

在本章中，我们为理解 H2O 机器学习在规模上的应用奠定了基础。我们首先回顾了一个最基础的Hello World代码示例，并讨论了其周围的规模问题。然后，我们介绍了 H2O Core、企业版 Steam 和 MOJO 技术组件，以及这些组件如何克服规模问题。最后，我们从这些技术中提取了一系列关键概念，以加深我们对这些技术的理解。

在下一章中，我们将利用这些理解开始我们的学习之旅，学习如何以规模构建和部署世界级的模型。让我们开始编码吧！

第三章：基本工作流程 - 数据到可部署模型

在本章中，我们将介绍 H2O 在大规模下的最小模型构建工作流程。我们将称之为“基本工作流程”，因为它省略了广泛的功能和用户选择，以构建准确、可信的模型，同时仍然涉及主要步骤。

基本工作流程将作为构建你对 H2O 技术和编码步骤理解的基础，以便在本书的下一部分，你可以深入探讨高级技术以构建最先进的模型。

为了开发基本工作流程，我们将在本章中涵盖以下主要主题：

• 用例和数据概述

• 基本工作流程

• 变异点 - 基本工作流程的替代方案和扩展

技术要求

对于本章，我们将专注于使用企业级蒸汽在企业服务器集群上启动 H2O 集群。从技术上讲，启动 H2O 集群并不需要企业级蒸汽，但企业利益相关者通常将企业级蒸汽视为在企业环境中实施 H2O 的安全、治理和管理要求。

企业级蒸汽需要从 H2O.ai 购买的许可证。如果你的组织没有安装企业级蒸汽的实例，你可以通过更大的 H2O 平台的临时试用许可证访问企业级蒸汽和企业服务器集群。或者，为了方便进行本书中的练习，你可能希望在本地环境中（例如，在你的笔记本电脑或台式工作站上）启动 H2O 集群作为沙盒，并绕过使用企业级蒸汽。

请参阅附录 – 为本书启动 H2O 集群的替代方法，以帮助你决定你希望如何为本书的练习启动 H2O 集群，以及如何设置你的环境以实现这一点。

企业级蒸汽：企业环境与本书中的编码练习

企业利益相关者通常将企业级蒸汽视为在企业环境中实施 H2O 的安全、治理和管理要求。本章展示了数据科学家如何在这个企业环境中使用企业级蒸汽。然而，企业级蒸汽需要 H2O.ai 许可证才能实施，并且不会对所有本书的读者开放。

简单的沙盒（非企业）体验是在你的本地环境（笔记本电脑或工作站）上仅使用 H2O，这不需要企业级蒸汽。后续章节中的编码练习将利用本地沙盒环境，但也可以像本章中展示的那样使用企业级蒸汽进行。

注意，数据科学家工作流程（有或没有企业蒸汽）的区别仅限于工作流程的第一步（启动 H2O 集群），将在本章的后面部分变得更加清晰。另请参阅 附录 – 启动 H2O 集群的替代方法。

用例和数据概述

为了演示基本工作流程，我们将实现一个二元分类问题，其中我们预测贷款是否会违约。本章中使用的数据集可以在 github.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/blob/main/chapt3/loans-lite.csv 找到。（这是 Kaggle Lending Club Loan 数据集的简化版本：www.kaggle.com/imsparsh/lending-club-loan-dataset-2007-2011。）

我们在本章中使用数据集的简化版本来简化工作流程。在 第二部分，大规模构建最先进的模型 中，我们将使用原始贷款数据集上的高级 H2O 模型构建功能来开发此用例。

基本工作流程

我们的基本工作流程将通过以下步骤进行：

1. 启动 H2O 集群（企业蒸汽 UI）

2. 连接到 H2O 集群（从现在起使用你的 IDE）

3. 构建模型

4. 评估和解释模型

5. 导出模型以进行生产部署

6. 关闭 H2O 集群

第 1 步 – 启动 H2O 集群

此步骤是在企业蒸汽 UI 中完成的。您将选择是否要使用 H2O-3 或汽水集群，然后您将配置 H2O 集群的行为，例如在超时并终止之前空闲时间的长度，以及您是否希望在终止时保存状态以便您可以重新启动集群并从上次离开的地方继续（这必须由管理员启用）。此外，企业蒸汽将根据您的数据大小自动调整 H2O 集群的大小（节点数量、每个节点的内存、CPU）。

登录 Steam

打开网页浏览器并访问 https://steam-url:9555/login 登录企业蒸汽，其中 steam-url 是您特定蒸汽实例的 URL。（您的管理员可能已更改端口号，但通常如 URL 所示为 9555。）

选择 H2O-3（与汽水）集群

在这里，我们将启动一个 H2O-3 集群（而不是我们在本书下一部分将执行的汽水，点击左侧面板中的 H2O 链接，然后点击 启动新集群）。

配置 H2O-3 集群

这将带我们到以下表单，您将进行配置：

图 3.1 – 在 Kubernetes 上启动 H2O-3 集群的 UI

目前，我们将忽略大多数配置。这些配置将在第十一章《管理员和操作视图》中更全面地介绍，其中详细概述了企业蒸汽。请注意，配置页面使用术语 H2O 集群 来特别表示 H2O-3 集群，而在这本书中，我们使用术语 H2O 集群来表示 H2O-3 或 Sparkling Water 集群。

关于“配置 H2O-3 集群”截图的说明

在 图 3.1 中显示的屏幕细节将根据 H2O 集群是在 Kubernetes 环境上启动还是在基于 YARN 的 Hadoop 或 Spark 环境上启动而有所不同。细节也会根据 H2O 集群是 H2O-3 集群还是 Sparkling Water 集群而有所不同。然而，在所有情况下，H2O 集群尺寸（节点数量、每个节点的 CPU/GPU 和每个节点的内存）以及最大空闲/运行时间的基本概念是通用的。

给您的集群起一个名字，对于 DATASET PARAMETERS（数据集参数），点击 Set parameters（设置参数）将出现以下弹出窗口：

图 3.2 – 自动调整 H2O-3 集群的弹出窗口

这里输入的参数将由企业蒸汽用于自动调整您的 H2O 集群（即确定 H2O 节点的数量以及每个节点的内存分配和每个节点的 CPU 分配）。回想一下前一章中介绍的 H2O 集群的关键概念。

稍等片刻，等待集群启动

UI 中的 STATUS 字段将显示 Starting，表示 H2O 集群正在企业服务器集群上启动。这需要一分钟左右。当状态变为 Running 时，您的 H2O 集群即可使用。

查看集群详细信息

让我们先通过点击 Actions（操作）然后 Detail（详情）来了解一些关于集群的信息。这将生成一个描述集群的弹出窗口。

注意在本例中，节点数量是 6，每个节点的内存是 48 GB，这是企业蒸汽为 50 GB 的数据集大小自动调整的结果，如 图 3.1 所示。回想一下前一章中 H2O 关键概念 部分的内容，我们的数据集被分割并分布在这企业服务器集群上的 H2O 集群节点内存中，计算在这些 H2O 节点上并行进行。

关于 H2O 集群尺寸的说明

通常，H2O 集群的尺寸是如此调整，即分配给集群的总内存（即 N 个 H2O 节点和每个节点 X GB 内存之积）大约是用于模型构建的未压缩数据集大小的 5 倍。这种计算方式最小化了节点数量（即，每个节点内存更多而节点更少是更好的）。

Enterprise Steam 将根据你对数据集的描述来计算这个大小，但你可以通过 Enterprise Steam UI 自行调整集群大小。当 H2O 集群终止时，分配给 H2O 集群的总内存将被释放。

注意，Enterprise Steam 管理员设置了用户在启动 H2O 集群时可能拥有的最小和最大配置值（见图 3.1），因此用户可能启动的最大 H2O 集群大小。管理员设置的这些边界可以为不同的用户配置不同。

第 2 步 – 连接到 H2O 集群

这些步骤以及所有后续步骤都是在你的 IDE 中进行的。我们将使用 Jupyter 笔记本，并用 Python 编写代码（尽管其他选项包括使用你喜欢的 IDE 编写 R、Java 或 Scala 版本的 H2O）。

打开笔记本，通过编写以下代码连接到你在 Enterprise Steam 中启动的 H2O 集群：

import h2o

import h2osteam

from h2osteam.clients import H2oKubernetesClient

conn = h2osteam.login(url="https://steam-url:9555",

                      username="my-steam-username",

                      password="my-steam-password")

cluster = H2oKubernetesClient().get_cluster("cluster-name")

cluster.connect()

现在，你已经连接到 H2O 集群，可以开始构建模型。请注意，连接后，你会看到与你在启动集群前在 Enterprise Steam UI 中查看的类似的 H2O 集群详细信息。

让我们了解代码正在做什么：

1. 你引用了从 H2O 下载并实现在你 IDE 环境中的h2osteam和h2o Python 库。（h2o库在此代码中未使用，但将在随后的模型构建步骤中使用。）

2. 接着，你通过h2osteam API（库）登录到 Enterprise Steam 服务器。你使用了与登录 Enterprise Steam UI 相同的 URL、用户名和密码。

3. 然后，你通过h2osteam API 从 Enterprise Steam 检索了你的 H2O 集群信息。

4. 注意，你在这里使用H2oKubernetesClient，因为你正在连接到在 Kubernetes 环境中启动的 H2O 集群。如果你所在的企业环境是 Hadoop 或 Spark，你将分别使用H2oClient或SparklingClient。

5. 你使用cluster.connect()连接到你的 H2O 集群，并将集群信息传递给h2o API。请注意，你不需要指定任何 H2O 集群的 URL，因为 Steam 在幕后通过H2oKubernetesClient().get_cluster("cluster-name")返回了它。

   创建 H2O 沙盒环境

   如果你想在本地机器上创建一个小的 H2O 沙盒环境，而不是使用 Enterprise Steam 和你的企业服务器集群，只需在你的 IDE 中实现以下两行代码：

   import h2o

   h2o.init()

   结果与使用 Enterprise Steam 执行步骤 1-2相同，只是它在你本地机器上启动了一个节点的 H2O 集群并连接到它。

   无论是在企业环境中连接到 H2O 集群还是在本地机器上，你现在都可以从你的 IDE 中针对相应的集群以相同的方式编写模型构建步骤。对于沙盒，由于它的集群大小只有一个节点且内存较低，你当然会受到数据量较小的限制。

第 3 步 – 构建模型

现在我们已经连接到我们的 H2O 集群，是时候构建模型了。从这一点开始，你将使用h2o API 与启动并连接到的 H2O 集群进行通信。

在我们的基本工作流程中，我们将采取最小化方法导入数据，清理它，从中提取特征，然后训练模型。

导入数据

从源数据加载到 H2O-3 集群内存中的贷款数据集使用h2o.import_file命令如下：

input_csv = "https://raw.githubusercontent.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/main/chapt3/loans-lite.csv"

loans = h2o.import_file(input_csv)

loans.dim

loans.head()

loans.dim行给出了行数和列数，loans.head()显示了前 10 行。目前来说，这是一个相当简单的数据探索。

注意，现在数据集已经分区并在 H2O 集群的内存中分布。从我们在 IDE 中的编码角度来看，它被视为一个称为H2OFrame的单个二维数据结构，由列和行组成。

清理数据

让我们执行一个简单的数据清理步骤。目标或响应列称为bad_loan，它包含 0 或 1 的值，分别代表良好和坏账。我们需要将此列中的整数转换为分类值，如下所示：

loans["bad_loan"] = loans["bad_loan"].asfactor()

从原始数据中工程化新特征

特征工程通常被认为是构建优秀预测模型的秘密配方。就我们的目的而言，我们将通过从issue_d列中提取年份和月份作为单独的特征来进行基本的特征工程，该列包含作为单个值的日、月和年：

loans["issue_d_year"] = loans["issue_d"].year().asfactor()

loans["issue_d_month"] = loans["issue_d"].month().asfactor()

我们已经在loans数据集中创建了两个新的分类列：issue_d_year和issue_d_month。

模型训练

我们接下来将训练一个模型来预测坏账。我们首先将数据分为train和test：

train, validate, test = loans.split_frame(seed=1, ratios=[0.7, 0.15])

我们现在需要确定我们将使用哪些列来预测贷款是否坏账。我们将通过从当前的贷款 H2OFrame 中移除两列来完成此操作，这些列包含已清理和工程化的数据：

predictors = list(loans.col_names)

predictors.remove("bad_loan)

predictors.remove("issue_d")

注意，我们已从用作特征的列中移除了bad_loan，因为这正是我们正在预测的。我们还移除了issue_d，因为我们从这个列中工程化了新的特征，不希望它作为预测因子。

接下来，让我们创建一个 XGBoost 模型来预测贷款违约：

from h2o.estimators import H2OXGBoostEstimator

param = {

         "ntrees" : 20,

         "nfolds" : 5,

         "seed": 12345

}

model = H2OXGBoostEstimator(**param)

model.train(x = predictors,

            y = "bad_loan",

            training_frame = train,

            validation_frame = validate)

第 4 步 – 评估和解释模型

让我们评估我们刚刚训练的模型性能：

perf = model.model_performance(test)

perf

perf的输出显示了模型性能的详细信息，包括模型度量，如 MSE、Logloss、AUC 等，以及混淆矩阵、最大度量阈值和收益/提升表。

现在，让我们通过从模型结果生成变量重要性来查看模型可解释性的一个简单视图：

explain = model.explain(test,include_explanations="varimp")

explain

explain的输出显示了针对测试数据集运行的训练模型的变量重要性。这是一个列出每个特征对模型贡献强度的表格。

H2O 的模型可解释性能力远不止变量重要性，正如我们将在本书后面看到的那样。

第 5 步 – 导出模型的评分工件

现在，让我们生成并导出模型作为评分工件，该工件可以由 DevOps 团队部署到生产环境：

model.download_mojo("download-destination-path")

在现实世界中，当然，我们会训练许多模型，比较它们的性能和可解释性，以评估哪些（如果有的话）应该进入生产。

第 6 步 – 关闭集群

当你的工作完成时，关闭 H2O-3 集群以释放它所保留的资源：

h2o.cluster().shutdown()

变异点 – 基本工作流程的替代方案和扩展

我们在这里开发的基本工作流程是一个简单的例子。对于我们所执行的每个步骤，都有多个替代方案和扩展，这些方案和扩展超出了所展示的内容。所有第二部分：大规模构建最先进的模型都是致力于理解这些替代方案和扩展，并将它们组合起来构建更高级的模型。

让我们先简要讨论一些关键变异点。

使用企业级 Steam API 与 UI 启动 H2O 集群（步骤 1）

在我们的示例中，我们利用企业级 Steam UI 的便利性来配置和启动一个 H2O 集群。或者，我们也可以使用 IDE 中的 Steam API 来完成这项工作。有关 Python API 的完整 H2O 企业级 Steam API 文档，请参阅docs.h2o.ai/enterprise-steam/latest-stable/docs/python-docs/index.html，有关 R API 的文档，请参阅docs.h2o.ai/enterprise-steam/latest-stable/docs/r-docs/index.html。

因此，通过从我们的 IDE 启动 H2O 集群，我们可以完全从 IDE 完成工作流程的所有步骤 1-6。

启动 H2O-3 集群与 Sparkling Water 集群（步骤 1）

在我们的示例中，我们启动了一个 H2O-3 集群。我们可以选择启动一个 H2O Sparkling Water 集群。正如我们将看到的，Sparkling Water 集群具有与 H2O-3 集群相同的性能集，但增加了与 H2O 代码和 H2O DataFrames 集成的 Spark 代码和 Spark DataFrames 的能力。这在利用 Spark 进行高级数据探索和数据预处理，然后在 H2O 中构建模型时尤其强大。

实施企业级 Steam 或否（步骤 1-2）

请注意，Enterprise Steam 不是启动和连接到企业服务器集群的必要条件：数据科学家可以在 IDE 中仅使用 h2o（而不是 h2osteam）API 来配置、启动和连接到企业服务器集群，但这是一种低级编码和配置，需要详细的集成信息。重要的是，这种方法缺乏健全的企业安全、治理和集成实践。

在企业环境中，Enterprise Steam 被视为集中管理、治理企业服务器集群环境中的 H2O 技术和 H2O 用户的关键。这些功能在第十一章中进行了详细阐述，管理员和操作视图*。

使用个人访问令牌登录到 Enterprise Steam（步骤 2）

在步骤 2 – 连接到 H2O 集群中，我们使用 Enterprise Steam API 从我们的 IDE 认证到 Enterprise Steam。在示例代码中，我们使用了明文密码（这是用于登录 Enterprise Steam UI 的相同密码）。如果你分享了笔记本，这就不安全了。

或者，更安全的方法是，你可以使用个人访问令牌（PAT）作为 API 登录密码连接到 Enterprise Steam。PAT 可以根据需要频繁生成，每个新生成的 PAT 都会吊销之前的令牌。因此，如果你使用 PAT 作为密码与登录凭证共享 Jupyter 笔记本，笔记本的接收者将不知道你的 Enterprise Steam UI 登录密码，并且无法使用你共享笔记本中的吊销密码通过 API 进行认证。你可以进一步将 PAT 实现为 IDE 外部的环境变量。

Enterprise Steam 允许你从 UI 生成一个 Personal Access Token（PAT）。要生成 PAT，请登录到 Enterprise Steam UI，点击配置，然后遵循简短的令牌工作流程。复制结果（一个长字符串）用于当前笔记本或脚本，或将其设置为环境变量。

构建模型（步骤 3）

H2O 提供的模型构建体验比我们基本工作流程中展示的要强大得多。这里简要介绍了这一更大的体验，并在第二部分，大规模构建最先进的模型中进行了全面探讨。

语言和 IDE

我们在 Jupyter 笔记本中使用 Python 编写 H2O 代码。你也可以选择 R 作为 Enterprise Steam API，并使用你选择的 Python 或 R IDE。此外，你可以使用 H2O 的 UI 丰富的 IDE，称为 H2O Flow，以执行完整的工作流程或快速了解从你自己的 IDE 中正在进行的 H2O 集群工作流程的各个方面。

导入数据

数据可以从许多来源导入到 H2O 集群中，包括云对象存储（例如，S3 或 Azure Delta Lake）、数据库表（通过 JDBC）、HDFS 等。此外，源文件可以有多种格式，包括 Parquet、ORC、ARFF 等。

清洗数据和特征工程

H2O-3 具有基本数据操作的能力（例如，更改列类型、合并或切片行或列、按组分组、插补等）。

回想一下，启动 Sparkling Water 集群为我们提供了完整的 H2O-3 功能，并增加了 Spark 更强大的数据探索和工程能力。

模型训练

在我们的基本工作流程中，我们只探索了一种类型的模型（XGBoost），同时只更改了几个默认参数。H2O-3（及其 Sparkling Water 扩展）拥有广泛的监督学习和无监督学习算法列表，以及一系列参数和超参数，可以设置为您的要求。此外，这些算法可以强大地组合到 AutoML 工作流程中，探索多个模型和超参数空间，并在排行榜上排列结果最佳模型。您还可以控制交叉验证技术、检查点、重新训练和可重复性。

评估和解释模型（步骤 4）

H2O 拥有针对局部（个体）和全局（模型级）可解释性的众多解释方法和可视化工具，包括残差分析、变量重要性热图、Shapley 摘要、部分依赖图（PDPs）和个体条件期望（ICE）。

导出模型的评分工件（步骤 5）

一旦导出模型的评分工件（称为 H2O MOJO），它就准备好在实时评分环境中由 DevOps 部署和监控。它很可能会进入组织的 CI/CD 流程。我们将在第三部分，将您的模型部署到生产环境中这一点上继续。

关闭集群（步骤 6）

您可以从您的 IDE 中按照我们的示例工作流程关闭您的集群。然而，如果您注意到，在企业级 Steam 中配置您的集群时，有两个配置可以自动化关闭过程：最大空闲时间和最大运行时间。第一个在配置的时间未使用后关闭集群。第二个在集群运行了配置的时间后关闭集群。关闭集群（手动或自动）可以为使用企业服务器集群的其他人节省资源。

管理员为这些自动终止的配置分配了最小和最大值。请注意，当管理员启用时，企业级 Steam 会在 H2O 集群自动终止时保存所有模型和数据框。您可以在稍后重新启动集群并从集群终止的地方继续。

摘要

在本章中，您学习了如何在您的 IDE 中启动 H2O 集群并在其上构建模型。这个基本工作流程是一个裸骨架，您将在本书的第二部分，大规模构建最先进的模型中，通过一系列高级 H2O 模型构建技术对其进行更全面的完善。

我们将在下一章开始这段高级旅程，在开始使用这些功能之前先概述它们。

第二部分 - 使用 H2O 在大量数据上构建最先进的模型

本节深入探讨了使用 H2O 构建准确且可信的机器学习模型的高级技术，这些模型适用于从大量到巨量数据。我们首先概述了 H2O-3 和 Sparkling Water 在模型构建方面的全部功能集。在此基础上，我们通过工程特征、构建和优化监督学习模型、构建嵌入 Spark 管道的 H2O 模型、使用 H2O 算法构建无监督模型，以及回顾如何更新和确保 H2O 模型的可重复性来展示这些功能。然后，我们深入介绍了解释和理解模型决策过程的各种方法，并在 H2O 中引入了自动文档功能。最后，我们通过从问题陈述和原始数据开始，经过数据清洗、特征工程、模型构建和优化，以及基于性能和可解释性的候选模型选择，进行了广泛的模型构建练习。

本节包括以下章节：

• 第四章，大规模 H2O 模型构建 - 能力阐述

• 第五章，高级模型构建 - 第一部分

• 第六章，高级模型构建 - 第二部分

• 第七章，理解机器学习模型

• 第八章，整合一切

第四章：大规模 H2O 模型构建 – 能力阐述

到目前为止，我们已经学习了如何在大规模上构建 H2O 模型的基本工作流程，但那是在 H2O 最基本的情况下完成的。在本章中，我们将调查 H2O 大规模模型构建的极其广泛的能能力集。然后，我们将利用本章的知识，继续到第二部分，使用 H2O 在大数据量上构建最先进的模型，我们将开始使用高级技术在大规模上构建和解释高度预测性的模型。

为了进行这项调查，我们将本章分为以下主要主题：

• 在模型构建过程中阐述 H2O 数据能力

• 概述 H2O 机器学习算法

• 理解 H2O 建模能力

模型构建期间的 H2O 数据能力

记住，大规模 H2O 模型构建是通过使用 H2O 3 或其扩展 Sparkling Water 来完成的，它将 Spark 能力包装在 H2O 3 中。H2O 3 API 在模型构建过程中使用了广泛的数据能力，Sparkling Water API 继承了这些能力，并从 Spark 中添加了额外的能力。这些能力被分为以下三个广泛类别：

• 从源数据到 H2O 集群的数据摄取

• 在 H2O 集群上操作数据

• 从 H2O 集群导出到外部目的地

如前几章所强调的，H2O 集群架构（H2O 3 或 Sparkling Water）允许无限规模地构建模型，但对使用 IDE 中的 H2O 代码构建模型的科学家来说是抽象的。

H2O 数据能力在以下图中概述，并随后进行详细阐述：

图 4.1 – H2O 数据能力

让我们从数据摄取开始。

从源数据到 H2O 集群的数据摄取

支持以下数据源：

• 本地文件

• 远程文件

• AWS S3

• MinIO 云存储

• Azure Blob 和 Data Lake

• Google Cloud Storage

• HDFS

• 类似 HDFS：Alluxio FS 和 IBM HDFS

• Hive（通过 Metastore/HDFS 或 JDBC）

• JDBC

支持的源数据文件格式如下：

• CSV（任何分隔符的文件，自动检测或指定）

• GZipped CSV

• XLS或XLSX

• ORC

• Parquet

• Avro

• ARFF

• SVMLight

将数据摄取到 H2O 的一些重要特性如下：

• 数据直接从源摄取到 H2O 集群内存中，不通过 IDE 客户端。

• 在所有情况下，数据都在 H2O 集群内部分区存储。

• 除了本地文件、远程文件和 JDBC 源之外，数据是并行摄取到每个分区的。

• H2O 集群上的数据以二维H2OFrame的形式呈现给用户。

现在让我们看看如何操作已经摄取到 H2O 并以 H2OFrame 形式表示的数据。

在 H2O 集群中操作数据

H2O 3 API 提供了广泛的数据操作功能。如前所述，内存中的数据集在 H2O 集群上分布，并在数据加载和后续数据操作后特别表示为 IDE 中的 H2OFrame。

H2OFrames 有一系列方法，可以在值、列、行和整个数据集级别执行数学、逻辑和内省操作。H2OFrame 在体验上类似于pandas DataFrame或R 数据框。

以下是一些在 H2Oframes 上可以进行的几种数据操作示例：

• 数据列上的操作：

  • 改变数据类型（例如，将 0 到 7 的整数作为分类值）。

  • 通过应用数学函数对列（按组）进行聚合。

  • 显示列名并将其用作模型中的特征。

• 数据行上的操作：

  • 将一个或多个数据集的行合并。

  • 通过指定行索引、行范围或逻辑条件来切片（过滤）数据集的行。

• 数据集上的操作：

  • 根据共享列名的公共值合并两个数据集。

  • 通过对列进行旋转来转换数据集。

  • 将数据集拆分为两个或更多数据集（例如，训练、验证和测试）。

• 数据值上的操作：

  • 使用相邻行或列的值向前或向后填充缺失值。

  • 通过使用聚合结果（例如，列的平均值）进行插补来填充缺失值。

  • 根据逻辑条件替换数值。

  • 剪切值、操作字符串、返回数值的符号，并测试值是否为 N/A。

• 特征工程操作：

  • 日期解析，例如，将一个日期列解析为单独的年、月、日列。

  • 从其他列（包括使用 lambda 表达式）数学和条件地派生出一个新列。

  • 执行目标编码（即，用一个目标变量的平均值替换一个分类值）。

  • 对于自然语言处理（NLP）问题，执行字符串分词、词频-逆文档频率（TF-IDF）计算，并将Word2vec模型转换为 H2OFrame 以进行数据操作。

有关 H2O 数据操作功能的详细信息，请参阅 H2O Python 文档(docs.h2o.ai/h2o/latest-stable/h2o-py/docs/frame.html)或 R 文档(docs.h2o.ai/h2o/latest-stable/h2o-r/docs/reference/index.html)。此外，请参阅《使用 Python 和 H2O 进行机器学习》的第四部分(h2o-release.s3.amazonaws.com/h2o/rel-wheeler/2/docs-website/h2o-docs/booklets/PythonBooklet.pdf)，以获取数据操作的示例。

操作数据是将其作为模型构建输入准备的关键。我们可能还希望导出我们的操作数据以供将来使用。下一节列出了 H2O 数据导出功能。

将数据从 H2O 集群导出

内存中的 H2OFrames 可以导出到外部目标。这些目标系统如下：

• 本地客户端内存

• 本地文件系统

• AWS S3

• MinIO 云存储

• Azure Blob 和 Data Lake

• Google Cloud Storage

• HDFS

• 类似 HDFS 的：Alluxio FS 和 IBM HDFS

• Hive 表（通过 JDBC 的 CSV 或 Parquet）

当然，必须考虑导出数据的量。例如，大量数据将无法适应本地客户端内存或文件系统。

现在我们来看看 Sparkling Water 添加了哪些额外的数据功能。

Sparkling Water 提供的附加数据功能

Sparkling Water 继承了 H2O 3 的所有数据功能。重要的是，Sparkling Water 通过利用 Spark DataFrame 和 Spark SQL API 添加了额外的数据功能，因此可以相应地导入、操作和导出数据。有关完整的 Spark DataFrame 和 Spark SQL 功能的参考，请参阅以下链接：spark.apache.org/docs/latest/sql-programming-guide.html。

使用 Sparkling Water 的一个关键模式是利用 Spark 的高级数据处理功能，然后将生成的 Spark DataFrame 转换为 H2Oframe，然后使用 H2O 的机器学习算法构建最先进的模型，如下一节所述。这些算法可以在 H2O 3 或 Sparkling Water 中使用。

H2O 机器学习算法

H2O 拥有广泛的无监督和监督学习算法，具有类似的可重用 API 结构 – 例如，设置超参数或调用可解释性功能的方式相似。从 H2O 3 或 Sparkling Water 的角度来看，这些算法是相同的，并在以下图中概述：

图 4.2 – H2O 算法

每个算法都有广泛的参数和超参数可以设置或利用作为默认值。算法接受 H2OFrames 作为数据输入。请记住，H2OFrame 只是 IDE 客户端对远程 H2O 集群中分布式内存数据的引用，其中算法对其进行处理。

让我们来看看 H2O 的分布式机器学习算法。

H2O 无监督学习算法

无监督算法不进行预测，而是试图在数据中找到簇和异常，或者减少数据集的维度。H2O 有以下无监督学习算法，可以在大规模上运行：

• 聚合器

• 广义低秩模型 (GLRM)

• 隔离森林

• 扩展隔离森林

• K-Means 聚类

• 主成分分析 (PCA)

H2O 监督学习算法

监督学习算法通过从标记有这些结果的训练数据集中学习来预测结果。H2O 有以下监督学习算法，可以在大规模上运行：

• Cox 比例风险（CoxPH）

• 深度学习（人工神经网络，或 ANN）

• 分布式随机森林（DRF）

• 广义线性模型（GLM）

• 最大平方改进（MAXR）

• 广义加性模型（GAM）

• 方差分析广义线性模型（ANOVA GLM）

• 梯度提升机（GBM）

• 朴素贝叶斯分类器

• 规则拟合（RuleFit）

• 支持向量机（SVM）

• XGBoost

参数和超参数

每个算法都有深层次的参数和超参数用于配置和调整。指定大多数参数是可选的；如果没有指定，将使用默认值。参数包括交叉验证参数、学习率、树深度、权重列、忽略列、提前停止参数、响应列的分布（例如，伯努利）、分类编码方案以及许多其他指定。

您可以在 H2O 的文档中深入了解 H2O 的算法及其参数，文档地址为docs.h2o.ai/h2o/latest-stable/h2o-docs/data-science.html#algorithms。H2O 网站还列出了其算法的教程和手册，地址为docs.h2o.ai/#h2o。算法参数的完整列表，每个参数都有描述、是否为超参数的状态以及映射到使用该参数的算法，可以在 H2O 的文档附录中找到，文档地址为docs.h2o.ai/h2o/latest-stable/h2o-docs/parameters.html。

H2O 的监督学习扩展

H2O 通过提供自动机器学习（AutoML）和堆叠集成功能来扩展其监督学习算法。我们将在下一节中更详细地探讨这些内容，其中我们将 H2O 算法置于模型能力的更广泛背景下。

杂项

H2O 提供了一些工具来增强其算法的工作。目标编码帮助您处理分类值，并具有许多可配置的参数以简化此过程。TF-IDF和Word2vec在 NLP 问题中常用，并且它们也具有良好的可配置性。最后，排列变量重要性是一种帮助理解您的特征对模型贡献强度的方法，并有助于评估在最终训练数据集中使用哪些特征。

H2O 建模能力

H2O 的监督学习算法用于在训练数据上训练模型，在验证数据上调整它们，并在测试或实时生产数据上评分或预测。H2O 具有广泛的训练、评估、解释、评分和检查模型的能力。这些能力总结在下述图中：

![图 4.3 – H2O 监督学习能力

图 4.3 – H2O 监督学习能力

让我们更详细地看看模型训练的能力。

H2O 模型训练能力

算法是模型训练的核心，但除了算法本身之外，还有更广泛的考虑能力。H2O 提供了以下模型训练能力：

• AutoML：一个易于使用的界面和参数集，可以自动化训练和调整许多不同模型的过程，使用多个算法在短时间内创建大量模型。

• 交叉验证：使用 K 折验证来生成针对验证分割的折叠的性能指标，可以在算法的训练参数中指定折数等参数。

• 检查点：新模型作为之前训练的、已检查点的模型的延续来构建，而不是从头开始构建模型；这在用新数据重新训练模型时非常有用。

• 提前停止：定义算法何时停止模型构建的参数，取决于指定的许多停止指标中的哪一个。

• 网格搜索：为指定的超参数范围的每个组合构建模型，并按性能指标对结果模型进行排序。

• 正则化：大多数算法都有参数设置，可以指定正则化技术以防止过拟合并提高可解释性。

• 分段训练：训练数据根据相同的列值分成段，并为每个段构建一个单独的模型。

• 堆叠集成：将使用相同或不同算法的多个基础模型的输出组合成一个性能更好的单一模型。

在训练好一个模型后，我们希望评估它，以确定其预测性能是否符合我们的需求。让我们看看 H2O 在这方面提供了什么。

H2O 模型评估能力

H2O 公开了许多模型属性以评估模型性能。以下是对这些属性的总结：

• AutoML 的排行榜：根据配置的性能指标或其他属性（如平均预测速度）对 AutoML 模型结果进行排名，并显示其他指标。

• 分类问题的性能指标：对于分类问题，H2O 计算基尼系数、绝对马修相关系数（MCC）、F1、F0.5、F2、准确率、对数损失、ROC 曲线下面积（AUC）、精确率-召回率曲线下面积（AUCPR）和科尔莫哥洛夫-斯米尔诺夫（KS）指标。

• 回归问题的性能指标：对于回归问题，H2O 计算R 平方（R²）、均方误差（MSE）、均方根误差（RMSE）、均方根对数误差（RMSLE）和平均绝对误差（MAE）指标。

• 预测指标：在构建模型后，H2O 允许你预测叶节点分配（基于树的模型）、特征贡献、每个阶段的类别概率（GBM 模型），以及预测路径上的特征频率（GBM 和 DRF）。

• 学习曲线图：这显示了随着学习的进展，模型性能指标的变化，有助于诊断过拟合或欠拟合。

现在我们来探讨解释 H2O 模型的方法。

H2O 模型可解释性能力

H2O 提供了一个简单且统一的接口来解释单个模型或多个模型，这可以是单独构建的模型列表或是对 AutoML 生成的那些模型的引用。在此基础上，H2O 允许你生成全局（即模型级别）和局部（行或个体级别）的解释。H2O 的可解释性能力可以根据您的规格进行配置。输出可以是表格、图形或两者兼而有之，具体取决于解释。

我们将在第六章，高级模型构建 – 第 II 部分中，将所有内容都用于更详细地探讨这个重要主题，但就目前而言，这里是一个快速的功能列表：

• 回归的残差分析

• 分类混淆矩阵

• 变量重要性表和热图

• 模型相关性热图

• Shapley 值

• 部分依赖图（PDPs）

• 个体条件期望（ICE）

现在我们通过查看模型训练、评估和解释后我们能做什么，来完成对 H2O 大规模建模能力的调查。

H2O 训练模型工件

一旦模型训练完成，就可以将其导出并保存为评分工件。关于将工件部署到生产评分环境的大主题将在第三部分：将模型部署到生产环境中讨论。以下是导出评分工件的基本功能：

• 使用 MOJO 进行预测：模型可以保存为自包含的二进制 Java 对象，称为 MOJO，可以在不同的系统上灵活实现为低延迟的生产评分工件（例如，REST 服务器、批量数据库评分和 Hive UDFs）。MOJO 还可以重新导入到 H2O 集群中，用于下一项所述的目的。

• 使用 MOJO 检查模型：导出的 MOJO 可以重新导入到 H2O 集群中，并用于对数据集进行评分，检查用于训练原始模型的超参数，查看评分历史，并显示特征重要性。

• MOJO 与 POJO 的比较：POJO 是 MOJO 的前身，正在被 H2O 弃用，但对于某些算法仍然是必需的。

摘要

在本章中，我们对 H2O 在规模构建模型方面的能力进行了广泛调查。我们了解了我们可以摄入到 H2O 集群中的数据源和受支持的文件格式。我们学习了这些数据如何从源头移动到 H2O 集群，以及 H2OFrame API 如何提供一个 IDE 中的单一处理程序来表示 H2O 集群上的分布式内存数据作为一个单一的两维数据结构。然后，我们学习了我们可以通过 H2OFrame API 进行数据操作的各种方式，以及如果需要的话，如何将其导出到外部系统。

然后，我们调查了大规模 H2O 模型构建的核心——H2O 的许多最先进的分布式无监督和监督学习算法。接着，我们通过调查围绕这些算法的模型能力，从训练、评估和解释模型，到使用模型工件重新训练、评分和检查模型，来将这些算法置于上下文中。

拿着这幅景观图，我们现在可以卷起袖子，开始大规模构建最先进的 H2O 模型。在下一章中，我们将逐一实现高级模型构建主题，然后再在完全开发的使用案例中将它们全部整合。

第五章：高级模型构建 – 第一部分

在本章中，我们通过介绍数据科学家在构建企业级模型时考虑的细微问题和选择，开始从基本模型构建过渡到高级模型构建。我们将讨论数据分割选项，比较建模算法，提出超参数优化的两阶段网格搜索策略，介绍 H2O AutoML，以自动将多个算法拟合到数据中，并进一步研究特征工程策略，以尽可能从数据中提取信息。我们将介绍 H2O Flow，这是 H2O 附带的一个基于菜单的 UI，它有助于监控 H2O 集群的健康状况，并允许进行交互式数据和模型调查。

在整个过程中，我们将使用在第三章中引入的 Lending Club 问题来阐述这些高级模型构建概念，基本工作流程 – 从数据到可部署模型。到本章结束时，你将能够使用 H2O 中可用的一个或多个监督学习算法构建一个企业级、优化的预测模型。之后，剩下的就是审查模型并将其部署到生产环境中。

在本章中，我们将讨论以下主要主题：

• 将数据分割用于验证或交叉验证和测试

• 算法考虑因素

• 使用网格搜索进行模型优化

• H2O AutoML

• 特征工程选项

• 利用 H2O Flow 增强你的 IDE 工作流程

• 将所有内容整合在一起 – 算法、特征工程、网格搜索和 AutoML

技术要求

我们在本章中首次介绍代码和数据集。到目前为止，如果你还没有设置你的 H2O 环境，请参阅附录 – 启动 H2O 集群的替代方法，以进行设置。

将数据分割用于验证或交叉验证和测试

当数据量足够大时，将数据分割为训练集、验证集和测试集是模型构建的公认标准。验证背后的思想很简单：大多数算法在训练数据上自然会出现过度拟合。在这里，过度拟合意味着正在建模的一些内容是该特定数据集的实际独特性（例如，噪声），而不是整个群体的代表性。那么，如何纠正这一点呢？嗯，你可以通过创建一个保留样本，称为验证集，在模型构建过程中对其进行评分，以确定正在建模的是信号还是噪声。这使超参数调整、模型正则化、早期停止等功能成为可能。

测试数据集是在模型构建结束时使用的额外保留数据，用于确定模型的真正性能。对于任何模型构建来说，拥有保留测试数据都是至关重要的。事实上，它如此重要，以至于你不应该信任或部署没有与测试数据集进行比较的模型。

训练-验证-测试划分的替代方案是在训练数据上使用带有 k 折交叉验证的训练-测试划分。以下是它是如何工作的：

1. 将训练数据划分为 k 折，在我们的例子中，k 是 5。

2. 使用其中一个折作为验证数据，其他四个折合并为训练数据来拟合一个模型。

3. 重复此过程，以便每个折都作为验证数据使用一次。

这样可以得到五个模型，每个模型都在数据的不同子集上进行了验证。

下面的图表很好地说明了这个概念：

![图 5.1 – 5 折交叉验证的示意图

![img/Figure_5.1_B16721.jpg]

图 5.1 – 5 折交叉验证的示意图

k 折交叉验证方法最初是为小数据集开发的，以便模型在训练中看到更多的数据。这以更高的计算成本为代价。对于许多数据科学家来说，无论数据集的大小如何，都会使用 k 折交叉验证。

模型过拟合和数据划分

模型过拟合的概念至关重要。根据定义，过拟合的模型泛化能力较差。如果你使用的是训练-验证-测试方法，并在同一个验证集上构建了许多模型，那么领先的模型很可能会在验证数据上过拟合。随着模型数量的增加，这种可能性会增大。将领先模型与保留测试集进行比较是衡量部署后实际性能的最佳指标。

我们可以通过确保每个模型都是基于其自己的随机选择的训练-验证分区来最小化任何过拟合到验证的问题。在 k 折交叉验证中，如果每个模型都是基于数据的不同分区构建的，这可能会自然发生。

在数据科学竞赛中，如果有多个参赛作品（数百或数千）与盲法保留测试数据集进行测试，会发生一些有趣的事情。已经证明，领先的模型通常会在测试数据上过拟合。那么在这种情况下，你应该怎么做呢？显然的答案是拥有一个额外的保留集，比如元测试集，这样就可以公平地评估这些模型在部署后如何泛化。

在下一节中，我们将使用 Lending Club 数据集演示这两种方法。以下代码从 第三章 的 模型训练 部分 Fundamental Workflow – 数据到可部署模型 开始，具体在 基本工作流程 的 步骤 3 中。

训练、验证和测试集划分

将数据分为三个部分：60% 用于训练，20% 用于验证，20% 用于最终测试，如下面的代码块所示：

train, valid, test = loans.split_frame(

    seed = 25,

    ratios = [0.6, 0.2],

    destination_frames = ["train", "valid", "test"]

) 

上述代码很简单。可选地，我们设置seed以确保数据拆分的可重复性。ratios参数只需要训练和验证的比例，测试拆分通过从 1 中减去获得。destination_frames选项允许我们命名结果数据对象，这不是必需的，但会使在 H2O Flow 中识别它们更容易。

k 折交叉验证的训练和测试拆分

我们也可以将数据分成两部分：80%用于训练，20%用于测试。这可以通过 k 折交叉验证方法完成，如下面的代码所示：

train_cv, test_cv = loans.split_frame(

    seed = 25,

    ratios = [0.8],

    destination_frames = ["train_cv", "test_cv"]

) 

如何设置种子

当前计算中的随机数根本不是随机的，而是确定的。伪随机数生成器（PRNGs）是复杂的数学函数，给定一个特定的种子会返回一个固定的值序列。如果省略了种子，计算机将自动设置种子——通常是从系统时钟中获取。这个种子值通常会在日志中报告。在代码中设置种子允许分析具有明确的可重复性。

接下来，我们将关注选择建模算法。

算法考虑

在本节中，我们将探讨数据科学家应该如何决定选择众多机器学习和统计算法中的哪一个来解决特定问题。我们假设读者对统计和机器学习模型如逻辑回归、决策树、随机森林和梯度提升模型有一定的了解。

如第四章中概述的，“H2O 大规模模型构建 – 能力阐述”H2O 提供了多种监督学习和无监督学习算法，可用于构建模型。例如，在二元分类问题的情况下，数据科学家可以选择参数化的 GLM 模型（逻辑回归）；半参数化的 GAM；非参数的基于树的算法，如随机森林、GBM、XGBoost或RuleFit；来自机器学习社区的模型，如支持向量机（SVMs）或深度学习神经网络；或者简单的朴素贝叶斯分类器。更复杂的是，这些算法的任何子集都可以通过堆叠集成（这是一种将多个高度预测模型组合成一个模型的方法；我们将在H2O AutoML部分讨论此方法）组合成一个预测模型。那么，数据科学家该怎么办呢？

关于 RuleFit 的说明

RuleFit 算法实际上是一个惩罚线性模型。在这里，我们将其与基于树的模型并列，因为规则是从大量随机创建的决策树中提取出来的。规则选择和模型正则化通过 LASSO 进行。目的是结合线性模型的可解释性和显式规则与基于树的方法的灵活性和预测能力。

如果模型选择的唯一标准是纯粹的预测能力，那么数据科学家可以简单地尝试所有方法，并选择在测试数据集上表现最好的模型。我们可以称之为Kaggle 解决方案，这个名字来源于流行的 Kaggle 数据科学竞赛。Kaggle 竞赛导致算法和建模方法在多个问题和数据集上进行了压力测试。在这些竞赛中发现的见解已经融入到现实世界的数据科学实践中。

然而，在企业环境中，预测能力通常是算法选择的唯一考虑因素的情况很少见。模型透明度可能是一个考虑因素。作为一个过度简化的例子，本质上可解释的参数模型（GLM）可能不如非参数模型具有预测性。随机森林、GBM、XGBoost 和深度学习神经网络等非参数模型是难以解释的黑盒，但通常会产生更优越的预测。（注意，GAM 和 RuleFit 算法结合了模型透明度和通常与黑盒方法相媲美的预测。）

除了纯粹的建模标准，在建模和部署决策中还有商业和实施方面的考虑。我们将在后面的章节中更详细地介绍这些内容。

在本节的剩余部分，我们将对决策树、随机森林和梯度提升模型进行高级概述。我们将以 Lending Club 数据为例，专注于两种特定的提升实现：H2O GBM 和 XGBoost。

行业中的算法流行度

我们与多个行业的大量客户合作的经验导致以下一般观察。首先，分类问题比回归问题更为普遍。其次，在选择算法时，可解释分类问题的黄金标准仍然是逻辑回归（GLM）。最常见的选择是非参数算法，通常是某种形式的梯度提升，目前是 GBM、XGBoost 或 LightGBM 实现。梯度提升的流行得益于它在 Kaggle 排行榜上频繁的出现（无论是单独出现还是作为集成的一部分）。

决策树的介绍

每个随机森林或 GBM 实现的核心是决策树的概念。决策树可以用于分类，其中观察被分配到离散的组中，或者用于回归，其中观察是数值结果。

通过条件控制语句进行观察分配，这些语句形成一个树状结构。一般的决策树算法可以描述如下：

1. 在所有候选预测变量中搜索，以确定产生最大预测能力的变量分割。

2. 对于每个新创建的分支，重复从步骤 1开始的变量分割过程。

3. 继续进行，直到满足停止标准。

用于分割的函数包括信息熵和基尼系数。让我们使用熵来阐述它们。在信息论中，随机变量的熵是该变量结果的平均不确定性水平。一个纯或同质的分类树节点将具有零熵。在每个候选分割点，我们计算熵并选择具有最低熵的分割。

从概念上讲，我们可以继续分割，直到所有节点都是纯的，但那样会产生一个过度拟合的树。相反，我们利用以下停止标准：

• 在每次分割后，每个节点所需的观察数的最小值

• 基于所选截止值的熵减少不足

• 树的最大深度

为了说明，让我们假设我们正在构建一个决策树来模拟 1912 年泰坦尼克号沉没的生存概率。我们的数据包括姓名、性别、年龄、预订舱位的等级、票价、船舱或卧铺的位置、乘客登船的城市、任何旅行伴侣等等。结果决策树可以在下面的图中找到。

第一次分割最大限度地增加了预测能力（通过最大限度地减少熵）：

• 主题是男性吗？如果是，则通过年龄 < 18规则创建下一个分割。

• 对于 18 岁以上的男性，此终端或叶节点的生存概率为 17%。

• 对于 18 岁以下的男性，还需要一个额外的分割：3 级。

• 对于 3 级且年龄低于 18 岁的男性，生存概率为 14%。

• 对于 1 级和 2 级且年龄低于 18 岁的男性，生存概率为 44%。

• 树在Male=Yes分支上的这些叶节点停止分割，因为这些节点满足了一个或多个停止标准。

对于Male=No分支也进行类似的过程。请注意，根据此模型，非3 级女性的生存概率为 95%。对于3 级女性乘客，生存概率取决于他们登船的位置，导致 38%或 70%的生存概率叶节点。决策树模型支持海难时的妇女和儿童优先的道德观：

![图 5.2 – 一个模拟泰坦尼克号生存概率的决策树

![图 5.2 – 一个模拟泰坦尼克号生存概率的决策树

图 5.2 – 一个模拟泰坦尼克号生存概率的决策树

决策树有一些明显的优势。它们的布局简单易懂，并且正如我们刚才所展示的，它们的解释是直接的。算法训练和评分速度快。决策树在处理非线性关系、特征分布、相关特征和缺失值时具有鲁棒性。另一方面，它们在建模线性关系方面效率不高。它们具有高方差，这意味着部分原因是树容易过拟合。也许它们最大的缺点是单个决策树的预测能力特别差，这是决策树方法论原始开发者首先提出的问题。

为了纠正决策树预测性能不佳的问题，已经开发出基于单个树集成的方法。一般来说，集成方法的目的是通过结合多个弱学习器（在我们的情况下，是决策树）的信息来创建一个强学习器。将 Bagging 和 Boosting 两种集成方法应用于树，分别产生了随机森林和梯度提升算法。接下来，我们将回顾这些集成方法及其在 H2O 中的实现。

随机森林

Bagging（即自助聚合）是一种集成方法，它将模型拟合到数据的自助样本，并对它们进行平均。自助法是一种重采样方法，它从数据行中进行有放回的抽样。这会在行（或观察）空间中产生随机性。随机森林是决策树的一种 Bagging 方法，它向列（或变量）空间添加随机性。

随机森林算法可以描述如下：

1. 基于随机选择的数据行构建一个深度树。

2. 在每次分割时，仅评估一个随机子集的变量进行分割。

3. 重复此操作多次，创建一个由所有树组成的森林。

4. 获取森林中所有树的平均值。

H2O 包括两种随机森林实现，分布式随机森林（DRF）和极端随机树（XRT）。在接下来的章节中，我们将总结这些算法。

分布式随机森林（DRF）

DRF 是 H2O 中的默认随机森林实现。该算法的亮点如下：

• DRF 中的每一棵树都是并行构建的。

• 通过选择候选特征随机子集中最具判别性的阈值来创建分割规则。

极端随机树（XRT）

XRT 算法在分割规则过程中增加了额外的随机性。这以（略微）增加偏差为代价降低了模型方差。通过设置histogram_type="Random"来启用 XRT：

• XRT 中的每一棵树都是并行构建的。

• 而不是寻找最具判别性的阈值，此算法将为每个候选变量随机创建阈值。从这个集合中选取最佳者作为分割规则。

两种随机森林实现的超参数是共享的。

随机森林超参数

H2O 中的随机森林方法需要以下超参数：

• 要构建的树的数量，ntrees（默认值为 50）。

• 最大树深度，max_depth（默认值为 20）。请注意，过大的值可能导致过拟合。

• 每个叶子节点所需的最小观测数，min_rows（默认值为 1）。

随机森林模型提供了额外的超参数以供调整。您可以在docs.h2o.ai/h2o/latest-stable/h2o-docs/data-science/drf.html找到它们。网格搜索可以协助超参数选择和模型优化过程。

梯度提升

提升是一种结合模型序列的集成方法，每个新模型都是基于前一个模型的残差构建的。提升树基于一系列相对浅的决策树。

提升树算法可以描述如下：

1. 首先构建一个浅决策树。

2. 将浅决策树拟合到前一棵树的残差。

3. 将残差树乘以收缩参数（或学习率）。

4. 重复 步骤 2 和 步骤 3，直到满足停止标准。

在残差上构建有助于算法专注于模型预测不佳的区域。这个过程在以下图中展示：

图 5.3 – H2O GBM 算法

GBM 方法导致高度预测性的模型，但必须小心避免过拟合。H2O 包含两种梯度提升版本：H2O GBM 和 XGBoost。在接下来的章节中，我们将总结这些算法。

H2O GBM

H2O GBM 实现遵循书中描述的原算法，即由 Jerome H. Friedman, Robert Tibshirani, 和 Trevor Hastie 所著的 《统计学习的要素》，并对大型和复杂数据的性能进行了改进。我们可以这样总结：

• GBM 中的每一棵树都是并行构建的。

• 分类别变量可以分成组，而不仅仅是使用布尔分割。

• 使用共享直方图来计算分割点。

• H2O 使用贪婪搜索直方图区间，优化平方误差的改进。

此实现的一个重要优点是 H2O GBM 自然处理高基数类别变量（即具有很多类别的类别变量）。

XGBoost

XGBoost 与经典 GBM 非常相似，主要区别在于包含变量数量的惩罚项。从数学上讲，这意味着它在成本函数中包含正则化项。树是在 宽度 而不是 深度 上生长的。

另一种流行的 GBM 方法是 LightGBM。LightGBM 算法通过重复分割提供最大增益的单个叶子节点来构建必要的深度。与 XGBoost 不同，树是在深度而不是宽度上生长的。理论上，LightGBM 针对稀疏数据进行了优化。虽然 H2O 没有直接实现 LightGBM，但它提供了一种使用 XGBoost（如设置tree_method="hist"和grow_policy="lossguide"）选项来模拟 LightGBM 方法的方法。更多详情请参阅docs.h2o.ai/h2o/latest-stable/h2o-docs/data-science/xgboost.html。

提升超参数

H2O 中的所有提升方法都需要以下超参数：

• 要构建的树的数量，ntrees（默认为 50）。

• 最大树深度，max_depth（默认为 6）。

• 收缩参数或学习率，learn_rate（默认为 0.3）。

简单地将树木添加到提升方法中而不进行进一步限制可能导致过拟合。网格搜索可以在超参数调整过程中提供帮助。在使用网格搜索进行模型优化部分将介绍用于提升的额外超参数。

基线模型训练

回到 Lending Club 数据，我们现在准备为考虑的每个算法构建基线模型。这里的基线是指使用合理或默认值设置拟合的模型。这将是模型优化的起点。

如第三章中所述，基本工作流程 - 从数据到可部署模型，我们以bad_loan响应和所有模型的相同预测集开始：

response = "bad_loan"

omit = ["issue_d", response]

predictors = list(set(loans.columns) - set(omit)) 

在前面的代码中，我们从预测集中移除了bad_loan响应变量和issue_d原始日期变量。回想一下，issue_d被用来创建两个特征，issue_d_month和issue_d_year，这些特征包含在预测集中。

接下来，我们使用训练-验证-测试拆分拟合一个基线 H2O GBM 模型，然后使用 5 折交叉验证拟合一个基线 XGBoost 模型。

基线 GBM 训练-验证-测试模型

我们首先拟合的是默认的 H2O GBM 模型，它在 60%–20%的训练-验证拆分上训练，以下为默认设置：

from h2o.estimators.gbm import H2OGradientBoostingEstimator

gbm = H2OGradientBoostingEstimator(seed = 25)

gbm.train(x = predictors,

          y = response,

          training_frame = train,

          validation_frame = valid,

          model_id = "gbm_baseline")

在这里，gbm.train命令中的model_id参数是可选的，用于在 H2O Flow 中标识模型对象。

我们将在第七章中更深入地研究模型诊断和可解释性，理解机器学习模型。在这里，我们只使用其中的一些命令来帮助比较梯度提升算法。首先，我们使用model_performance方法可视化基线 GBM 模型在所有拆分上的性能：

%matplotlib inline

gbm.model_performance(train).plot()

%matplotlib 命令允许在 Jupyter 笔记本中显示图形。这只需要执行一次，并且在不使用 Jupyter 的情况下不需要。

图 5.4 – GBM 训练分割的 ROC 曲线

验证分割的第二个 ROC 曲线使用类似的代码：

gbm.model_performance(valid).plot()

这将产生以下输出：

图 5.5 – GBM 验证分割的 ROC 曲线

测试分割的 ROC 曲线使用类似的代码：

gbm.model_performance(test).plot()

这将产生以下输出：

图 5.6 – GBM 测试分割的 ROC 曲线

要提取这些分割的 AUC，我们输入以下内容：

print(gbm.model_performance(train).auc(),

      gbm.model_performance(valid).auc(),

      gbm.model_performance(test).auc())

代码块和结果，如 Jupyter 笔记本中产生的，在此处显示：

图 5.7 – 来自 Jupyter 笔记本的 GBM 模型性能结果

此外，训练和验证性能值存储在模型对象中：

gbm.auc(train = True, valid = True)

这将返回一个字典，如下所示：

图 5.8 – 来自 Jupyter 笔记本的 GBM 模型对象的 AUC

这些结果表明，基线 GBM 模型在训练数据上过度拟合。这并不令人惊讶。

让我们快速看一下模型解释，我们将在第七章中更深入地探讨，理解机器学习模型。变量重要性图按相对重要性对变量进行排序，以预测不良贷款。一个变量的相对重要性是通过检查该变量是否用于分割，并计算所有树上的平方误差的减少来确定的。

以下代码用于生成变量重要性图：

gbm.varimp_plot(20)

生成的图表如下：

图 5.9 – 基线 GBM 变量重要性图

如图 5.9所示的结果变量重要性图显示，地址州，这是一个具有 50 个级别的高基数分类变量，对应于美国的各州，是迄今为止最重要的变量。

基线 XGBoost 交叉验证模型

让我们使用 5 折交叉验证和训练-测试分割来构建我们的基线 XGBoost 模型：

from h2o.estimators import H2OXGBoostEstimator

xgb = H2OXGBoostEstimator(nfolds = 5, seed = 25)

xgb.train(x = predictors,

          y = response,

          training_frame = train_cv,

          model_id = "xgb")

在前面的代码中，nfolds 设置折叠数，seed 是可选的，这里包含它是为了教学目的，而 model_id 是 H2O Flow 中使用的可选标识符。

我们可以直接从模型对象中获取训练和交叉验证集的 AUC：

xgb.auc(train = True, xval = True)

这会产生以下结果：

图 5.10 – XGBoost 模型训练和交叉验证性能结果

测试集 AUC 要求我们包括要评分的测试数据：

xgb.model_performance(test_cv).auc()

这将产生以下输出：

![Figure 5.11 – The XGBoost model test performance results from the Jupyter notebook

图 5.11 – The XGBoost 模型测试性能结果来自 Jupyter 笔记本

我们可以很容易地使用一点 Python 代码将这些结果合并到一个字典中：

perf = xgb.auc(train = True, xval = True)

perf["test"] = xgb.model_performance(test_cv).auc()

perf

这个 Python 代码块生成了以下结果：

![Figure 5.12 – XGBoost 模型性能作为字典

图 5.12 – XGBoost 模型性能作为字典

再次，AUC 值证实了基线模型在训练数据上过拟合，并且过于乐观。交叉验证和测试 AUC 值处于同一水平，这令人欣慰，因为它意味着交叉验证过程更准确地反映了你可能在样本外测试数据中看到的情况。这是一个重要的检查，并不总是如此，尤其是在训练和测试分割覆盖不同的时间段时。接下来，让我们考虑基线 XGBoost 模型的变量重要性图：

xgb.varimp_plot(20)

结果如下：

![Figure 5.13 – A baseline XGBoost variable importance plot

图 5.13 – 基线 XGBoost 变量重要性图

GBM 和 XGBoost 基线模型的变量重要性图比较展示了这两种提升算法之间的差异。此外，它还引出了在考虑多个选项时如何选择算法的更深入讨论。

注意，在 H2O GBM 模型中最重要的变量是addr_state，这是一个高基数分类变量（大约有 50 个级别，对应于美国的各个州）。XGBoost 默认将分类变量级别进行独热编码。独热编码将分类变量的每个级别用一个包含 1 的数值变量表示，该变量对应于该级别的行，否则为 0。例如，addr_state这样的 50 个级别的分类变量的独热编码会产生 50 个新的、相对稀疏的变量，对应于每个州。在 XGBoost 变量重要性图中，各州单独出现，重要性远低于其他变量，如前图中addr_state_FL、addr_state_CA和addr_state_NV所示。

数据科学家可以通过特征工程方法，如目标编码来解决这个问题。目标编码，我们将在稍后更详细地回顾，是一种用代表性的数值值替换分类变量级别的的方法。如果实现了目标编码，那么 XGBoost 和 H2O GBM 之间的选择可能就取决于纯性能。另一方面，如果目标编码不是一个选项，那么 H2O GBM 应该是提升算法的选择。

换句话说，XGBoost 需要目标编码，而 H2O GBM 则给数据科学家提供了直接对高基数分类变量建模或使用这些变量的目标编码版本的选项。这是算法、特征工程选择以及可能的其他因素（如业务、合规性或监管考虑）之间相互作用的良好示例。

接下来，我们将关注通过使用网格搜索来找到模型优化的超参数设置，以改进我们的基线模型。

使用网格搜索进行模型优化

选择一个算法来构建预测模型是不够的。许多算法都有超参数，其值对模型的预测能力有直接影响。那么，你该如何选择超参数的值呢？

暴力方法会创建一个包含所有可能值的网格，并对其进行搜索。这种方法计算成本高昂，耗时过长，最终得到的结果与我们通过其他方式所能达到的结果相差无几。我们已经概述了一种网格搜索策略，该策略在构建优化模型的同时，在合理的时间内运行。

一般策略包括首先使用笛卡尔网格搜索调整几个关键参数。这些关键参数是我们预期将对结果影响最大的参数。然后，我们使用随机网格搜索微调其他参数。这种两阶段方法使我们能够首先专注于计算成本较高的参数。

从我们在多个领域的大量数据集上使用梯度提升方法的经验来看，我们的策略遵循以下原则：

1. 最大允许树深度（max_depth）的最佳值高度依赖于数据和问题。深度更大的树，尤其是在深度大于 10 的情况下，训练时间会显著增加。为了节省时间，首先将大致深度缩小到一个小范围值是一个好主意。

2. 我们增加树的数量（ntrees），直到验证集错误开始增加。

3. 极低的学习率（learn_rate）普遍推荐。这通常会产生更好的精度，但需要更多的树和额外的计算时间。一个巧妙的替代方案是从相对较高的学习率（例如 0.05 或 0.02）开始，并通过使用learn_rate_annealing迭代地缩小它。例如，将learn_rate=0.02和learn_rate_annealing=0.995设置可以显著加快收敛速度，同时不会牺牲太多精度。这对于超参数搜索非常有用。为了更快地扫描，可以尝试 0.05 和 0.99 的值。

4. 使用 sample_rate 和 col_sample_rate 分别采样行和列，可以降低验证集和测试集的错误率，并提高泛化能力。对于大多数数据集来说，行和列的采样率（介于 0.7 和 0.8 之间）在 70% 到 80% 之间是一个好的起点。可选地，可以设置每个树的列采样率参数（col_sample_rate_per_tree）。它与 col_sample_rate 是乘法关系。例如，将这两个参数都设置为 0.9，则总共考虑 81% 的列进行分割。

5. 使用 stopping_rounds、stopping_metric 和 stopping_tolerance 进行早期停止可以使网格搜索更高效。针对我们的需求，可以使用 5、AUC 和 1e-4 作为良好的起点。这意味着如果在 5 次迭代后验证集 AUC 没有超过 0.0001 的提升，计算将结束。

6. 为了提高高度不平衡的分类数据集的预测准确性，可以设置 sample_rate_per_class 参数。这实现了基于特定响应类的分层行采样。参数值以字典序排列的比率数组形式输入，每个响应类一个。

7. 大多数其他选项对模型性能的影响相对较小。尽管如此，它们可能值得通过随机超参数搜索进行调整。

接下来，我们将为 Lending Club 数据构建一个优化的 H2O GBM 模型，并将结果与基线模型进行比较。

第 1 步 – 一个笛卡尔网格搜索来关注最佳树深度

最佳 max_depth 参数值非常具体于使用案例和建模的数据。此外，它对模型训练时间有深远的影响。换句话说，较大的树深度值需要比较小的值显著更多的计算。首先，我们将使用快速笛卡尔网格搜索来关注好的候选 max_depth 值。

在这里，我们结合使用早期停止和学习率退火来加速收敛并有效地调整 max_depth 参数：

1. 我们首先定义超参数：

   from h2o.grid.grid_search import H2OGridSearch
   hyperparams = {
       "max_depth": list(range(2, 14, 2)) 
   }
   

2. 我们通过定义大量启用早期停止的树来遵循我们的策略。我们使用学习率退火，如以下代码块所示，来缩小 learn_rate 并采样 80% 的行和列。我们还每 10 棵树评分一次，以便使早期停止可重复。对于大量数据的模型构建，我们可能希望每 100 或 1,000 棵树评分一次：

   gbm_grid = H2OGradientBoostingEstimator(
       ntrees = 10000,
       stopping_metric = "AUC",
       stopping_rounds = 5,
       stopping_tolerance = 1e-4,
       learn_rate = 0.05,
       learn_rate_annealing = 0.99,
       sample_rate = 0.8,
       col_sample_rate = 0.8,
       score_tree_interval = 10,
       seed = 25
   )
   

   设置 score_tree_interval 参数

   在模型网格搜索期间评分树基本上是浪费计算资源，因为它需要更多的时间才能达到最佳解决方案。然而，它是使早期停止过程可重复所必需的。我们希望设置一个足够高的值以确保可重复性，但又不浪费计算周期。这在很大程度上是数据和相关问题的特定。我们之前使用的 10 的值可能对这个问题来说过于激进；100 可能更合适。

3. 现在我们定义网格并设置搜索标准为笛卡尔：

   grid = H2OGridSearch(
       gbm_grid,
       hyperparams,
       grid_id = "gbm_depth_grid",
       search_criteria = {"strategy": "Cartesian"}
   )
   

4. 然后，我们拟合网格，如下面的代码块所示：

   grid.train(x = predictors,
              y = response,
              training_frame = train,
              validation_frame = valid)
   

5. 要根据 AUC 的降序值显示网格搜索结果，我们使用以下代码：

   sorted_grid = grid.get_grid(
       sort_by = "auc", decreasing = True)
   print(sorted_grid)
   

这导致了以下结果：

![Figure 5.14 – 调整最大树深度参数值

图 5.14 – 调整最大树深度参数值

对于这个数据和 H2O GBM 算法，max_depth的值为 2 到 6 似乎给出了最佳结果。接下来，我们将在 2 到 6 的范围内进行搜索并调整任何其他参数。

第 2 步 – 随机网格搜索以调整其他参数

现在我们已经关注了最大树深度的良好范围，我们可以设置以下调整超参数：

hyperparams_tune = {

    "max_depth" : list(range(2, 6, 1)),

    "sample_rate" : [x/100\. for x in range(20,101)],

    "col_sample_rate" : [x/100\. for x in range(20,101)],

    "min_split_improvement": [0, 1e-8, 1e-6, 1e-4]

}

min_split_improvement参数试图通过要求每个分割不会导致更差的误差度量来减少 GBM 和 XGBoost 模型中的过拟合。我们将尝试该参数的四种不同设置。

在以下搜索标准中，我们为了说明目的将运行时间限制为 5 分钟。此外，我们将构建的模型数量限制为 10 个。根据您的用例，您可能希望显著增加运行时间或完全排除这些选项：

search_criteria_tune = {

    "strategy" : "RandomDiscrete",

    "max_runtime_secs" : 300,

    "max_models" : 10, 

    "stopping_rounds" : 5,

    "stopping_metric" : "AUC",

    "stopping_tolerance" : 1e-3

}

此外，我们设置了最终的网格参数：

gbm_final_grid = H2OGradientBoostingEstimator(

    ntrees = 10000,

    learn_rate = 0.05,

    learn_rate_annealing = 0.99,

    score_tree_interval = 10,

    seed = 12345

)

然后我们拟合最终的网格，如下面的代码块所示：

final_grid = H2OGridSearch(

    gbm_final_grid,

    hyper_params = hyperparams_tune,

    grid_id = "gbm_final_grid",

    search_criteria = search_criteria_tune)

更多文档

有几个额外的超参数可用，在 H2O 文档docs.h2o.ai/h2o/latest-stable/h2o-docs/parameters.html中列出。

关于网格搜索的更多详细信息，请参阅docs.h2o.ai/h2o/latest-stable/h2o-docs/grid-search.html#grid-search-in-python。

现在我们训练模型。请注意，以下max_runtime_secs设置覆盖了在search_criteria_tune中设置的值：

final_grid.train(

    x = predictors,

    y = response,

    max_runtime_secs = 180,

    training_frame = train,

    validation_frame = valid

)

在 3 分钟或更短的时间内，我们查看按AUC排序的网格搜索结果：

grid = final_grid.get_grid(sort_by = "auc", 

                           decreasing = True)

grid

输出如下：

![Figure 5.15 – GBM 模型优化的网格搜索结果

图 5.15 – GBM 模型优化网格搜索结果

优化策略结果

这个练习展示了超参数调整的重要性。尽管我们通过仅搜索 3 分钟并生成 10 个模型来限制了这个优化，但其中 9 个模型的表现优于具有默认值的基线 GBM 模型。

我们可以很容易地根据之前的排行榜选择最佳模型，并提取其 AUC 性能值：

best_gbm = grid.models[0]

perf = best_gbm.auc(train = True, valid = True)

perf["test"] = best_gbm.model_performance(test).auc()

perf

以下 Python 代码块生成了以下结果：

![Figure 5.16 – 网格搜索中最佳优化 GBM 模型的表现

图 5.16 – 网格搜索中最佳优化 GBM 模型的表现

我们的网格搜索策略是微调机器学习模型超参数的绝佳方式。接下来，我们将探讨 H2O 中的 AutoML。

H2O AutoML

构建和调整模型的最有效方法是使用 H2O AutoML。AutoML 从多个算法中构建模型，同时根据模型类型实施适当的网格搜索和模型优化。用户可以指定约束条件，例如计算时间限制或创建模型数量的限制。

AutoML 的一些功能包括以下内容：

• AutoML 使用精心选择的超参数空间训练 GLM、GBM 和 DNN 的随机网格。

• 使用验证集或交叉验证对单个模型进行调整。

• 默认训练两个堆叠集成模型：所有模型和轻量级的家族最佳集成。

• AutoML 返回所有模型的排序排行榜。

• 任何模型都可以轻松推广到生产环境中。

堆叠集成是高度预测性的模型，通常出现在排行榜的顶部。类似于我们之前介绍的其他集成方法（如 bagging 和 boosting），堆叠通过将多个预测模型的信息组合在一起来工作。与依赖于弱学习者的组件模型不同，堆叠通过最优地组合一组多样化的强预测模型来工作。所有模型堆叠集成是通过结合 AutoML 运行中调查的整个模型列表创建的。家族最佳集成最多包含六个组件模型。其性能通常与所有模型集成相当，但由于其复杂性较低，通常更适合生产。（有关堆叠集成的更多信息，请参阅docs.h2o.ai/h2o/latest-stable/h2o-docs/data-science/stacked-ensembles.html）。

使用 AutoML 训练模型相对简单：

from h2o.automl import H2OAutoML

aml = H2OAutoML(max_models = 10,

                max_runtime_secs_per_model = 60,

                exclude_algos = ["DeepLearning"],

                seed = 25)

aml.train(x = predictors, 

          y = response, 

          training_frame = train_cv)

AutoML 运行时参数选择

我们为max_runtime_secs_per_model和max_models参数设定的值使我们能够快速筛选多种模型类型，同时限制总体运行时间。这既不是最优的，也不是推荐的，通常在教程或课堂设置中使用以演示 AutoML。相反，您可以将总体max_runtime_secs参数设置为显式值。默认值为 3,600（即 1 小时）。

H2O AutoML 按以下顺序训练以下算法：

• 三个 XGBoost GBM

• 一组 GLM 网格

• 一个 DRF

• 五个 H2O GBM

• 一个深度神经网络

• 一个极端随机森林

• 随机网格的 XGBoost GBM、H2O GBM 和深度神经网络

• 两个堆叠集成模型

如果没有足够的时间完成所有这些算法，一些算法可以从不包含在排行榜中。

AutoML 排行榜

AutoML 对象包含一个包含模型及其交叉验证模型性能的排行榜。您可以通过指定leaderboard_frame参数为特定数据集创建排行榜。

模型是根据一个默认基于问题类型的指标进行排名的：

• 对于回归，这是偏差。

• 对于二元分类，AUC 是默认指标。

• 对于多类分类，我们使用每类的平均误差。

• 为了方便起见，还提供了额外的指标，如 Logloss。

接下来，我们打印出排行榜：

print(aml.leaderboard)

图 5.17 – AutoML 排行榜

如预期的那样，堆叠集成模型在排行榜上的所有单个模型中表现最佳。这些模型中的任何一个都可以被选中进行进一步调查和潜在部署。接下来，我们将向您展示如何选择顶级模型。

检查顶级模型

aml.leader对象包含排行榜中的最佳模型，包括训练和交叉验证数据的详细信息。我们使用以下代码打印最佳模型的训练、交叉验证和测试数据的 AUC 值：

best = aml.leader

perf = best.auc(train = True, xval = True)

perf["test"] = best.model_performance(test_cv).auc()

perf

结果值如下：

图 5.18 – AutoML 排行榜中最佳模型的性能

检查所选模型

在实践中，领先的模型可能不是你最终投入生产的模型。如前所述，其他考虑因素，如建模类型、监管或合规要求、内部业务偏好以及模型批准的可能性，可能在确定使用哪个模型时发挥作用。

使用排行榜的其他原因

使用 AutoML 和探索其排行榜的最明显原因是为了找到顶级模型并将其投入生产。如前所述，这可能不被允许。让我们考虑一个场景，即我只能将 GLM 投入生产。那么，为什么还要使用 AutoML 拟合其他模型呢？一个答案是，最佳模型给了我一个我可以报告的实际上限。GLM 的 AUC 为 0.69905，而最佳可能模型的 AUC 为 0.71336。

在商业环境中，我应该始终能够将性能差异转化为成本降低或利润增加的术语。换句话说，将 AUC 差异转化为美元和美分是“业务成本”或“使用所选模型而不是最佳模型所留下的钱”。

在这里，我们演示如何从排行榜中选择任何模型。顶级单个（非集成）模型位于第三位。我们使用以下代码选择此模型，并检查其 AUC 性能：

select = h2o.get_model(aml.leaderboard[2, "model_id"])

perf = select.auc(train = True, xval = True)

perf["test"] = select.model_performance(test_cv).auc()

perf

这导致以下结果：

图 5.19 – AutoML 排行榜中选定模型的性能

一旦通过 AutoML 选择了模型对象，所有模型诊断和可解释性流程，我们将在第七章“理解机器学习模型”中介绍，都将可用。

特征工程选项

在本节中，我们将演示特征工程如何导致更好的预测模型。通常，特征工程仅次于数据清洗，是建模过程中所有任务中最耗时的。它也可以是使预测模型出色的“秘密配方”。

那么，特征工程是什么意思呢？简单来说，它是指如何从原始数据中提取信息，使其既能被建模算法使用，又能对当前问题进行解释。例如，日期或日期时间对象在数据中可能以字符串或数字（例如，Unix 时间是从 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数）的形式表示。面对这样的特征，算法可能会将日期视为分类变量的级别或连续数值。这两种形式都不太有用。然而，这些原始数据中不仅包含了关于日、月、年的信息，还包括了星期几、周末或工作日、季节、节假日等等。如果对象包含时间，那么还可以产生一天中的小时数、一天中的时间（例如，上午、下午、傍晚或夜间）等等。

要创建哪些特征在很大程度上取决于用例。即使在最佳情况下，大多数工程特征也可能不会被模型算法选中。专业知识和对问题背景的理解在构建良好特征中起着重要作用。例如，在贷款中使用的债务收入比将客户每月欠款除以他们的月收入。这个工程特征在风险建模中已被证明具有很高的预测性，以至于它已经得到了自己的名称和缩写，DTI。

专业知识与特征工程

我们的一位同事，一位杰出的数据科学家、多次 Kaggle 大师，以及一位博士，曾评论说，他不喜欢参加 FinTech 数据科学竞赛，因为“其中 Fin 比 Tech 多。”通过这句话，他至少部分地意思是，那些问题高度重视他缺乏经验的领域专业知识。

另一个特征工程的好例子是在预测建模的上下文中进行自然语言处理（NLP）。NLP 试图将单词、单词含义和句子表示为可以自然地纳入机器学习算法的数值。TF-IDF 和词嵌入（word2vec）是两种这样的方法。我们将在第六章的Sparkling Water 建模部分、高级模型构建 – 第二部分和第八章的详细 Lending Club 分析中进行更详细的介绍，整合一切。

在本节的剩余部分，我们将深入探讨目标编码。目标编码是可用的最常见和最有影响力的特征工程选项之一。我们将通过在Lending Club 模型中展示其使用来阐述。在第八章的整合一切中，我们将实现额外的特征工程配方来提高预测模型。

目标编码

目标编码将分类级别替换为表示目标变量某些函数的数值，例如平均值。以下图表说明了平均目标编码：

![Figure 5.20 – 平均目标编码

![img/Figure_5.20_B16721.jpg]

图 5.20 – 平均目标编码

该方法很简单：将分类特征级别（A、B和C）替换为其相应的平均值（0.75、0.66和1.00）。

目标编码是一个巧妙的想法，在精神上与统计随机和混合效应模型中发现的随机效应类似。实际上，对于某些简单的情况，你可以证明平均目标编码实际上产生了随机效应的经验贝叶斯估计。这意味着目标编码背后的意图是基于正确的原则。

然而，目标编码使用目标的函数作为预测目标的输入。这正是数据泄露的定义。数据泄露会导致过度乐观的模型，这些模型泛化能力差，在实践中至多只是误导。H2O 通过精心构建的交叉验证程序实现目标编码。本质上，这是通过基于其他数据折叠计算每行的目标编码值来消除数据泄露。

随机效应

统计模型中随机效应估计的数学结构不会像目标编码那样受到数据泄露问题的困扰。这是因为目标变量中的信息被分割，用于估计随机效应的部分与用于估计其他模型参数的部分是分开的。

我们使用H2O-3 目标编码估计器将分类值替换为目标变量的平均值。我们通过以下方式调整目标编码：

• 将data_leakage_handling设置为k-fold可以控制数据泄露。

• 向目标平均值添加随机noise有助于防止过拟合。

• 我们通过blending调整小群体大小的类别。

任何观测值较少的分类层级将导致目标编码的平均值不可靠（高方差）。由组的目标值和全局目标值的加权平均值组成的混合平均可以改善这个估计。通过设置blending=True，目标平均值将根据分类层级的样本大小进行加权。

当启用混合时，smoothing参数控制层级后验概率与先验概率（默认值为 20）之间的过渡速率。inflection_point参数代表我们完全信任估计的样本大小的一半。默认值是 10。

对 Lending Club 数据进行目标编码

要确定一个分类变量是否可以从目标编码中受益，首先，为该变量创建一个从最频繁到最不频繁排序的表格。为此，我们将定义一个 Python 函数：

import numpy as npdef sorted_table(colname, data = train_cv):

    tbl = data[colname].table().as_data_frame()

    tbl["Percent"] = np.round((100 * tbl["Count"]/data.nrows), 2)

    tbl = tbl.sort_values(by = "Count", ascending = 0)

    tbl = tbl.reset_index(drop = True)

    return(tbl) 

注意，前面的代码需要 Python pandas 包可用，因为as_data_frame调用以 pandas 格式输出表格。

首先，考虑记录贷款目的的purpose变量：

sorted_table("purpose")

这将返回以下内容：

![图 5.21 – purpose 变量的层级

![img/Figure_5.21_B16721.jpg]

图 5.21 – purpose 变量的层级

注意债务重组贷款（46%）的高度集中，以及信用卡（13%）和其他（11%）的相当数量，剩余的 30%分布在 11 个其他贷款用途中。对于这些数据的一个选项是将类别合并成更少的层级，并将purpose变量保留为分类变量。如果类别可以以连贯的方式合并，这可能是有意义的。更好的选项是使用平均目标编码来表示所有层级，而不会过度拟合尾部的小百分比。在这里也将启用混合，尽管它提供的平滑量可能不会产生重大影响。renewable_energy类别有 75 个观测值，在大多数情况下，即使百分比非常小，这也足以可靠地估计平均值。

考虑的第二个变量是addr_state：

sorted_table("addr_state")

前几行如下所示：

图 5.22 – 按计数排名前十的州

最后几行如下所示：

![图 5.23 – 按计数排名最后七个州

![图 5.23 – 按计数排名最后七个州

图 5.23 – 按计数排名最后七个州

高基数分类变量，如addr_state，是目标编码的理想候选者。记录的分布也非常倾斜，前四个层级大约占 40%的数据。混合在这里特别重要，因为尾部州的原始计数非常小：

1. 首先导入目标编码估计器并指定要编码的列：

   from h2o.estimators import H2OTargetEncoderEstimator
   encoded_columns = ["purpose", "addr_state"]
   

2. k_fold策略需要一个折叠列，它如下创建：

   train_cv["fold"] = train_cv.kfold_column(
       n_folds=5, seed=25)
   

3. 通过设置以下参数来训练目标编码模型：

   te = H2OTargetEncoderEstimator(
       data_leakage_handling = "k_fold",
       fold_column = "fold",
       noise = 0.05,
       blending = True,
       inflection_point = 10,
       smoothing = 20
   )
   

这里是训练过程：

te.train = (x = encoded_columns, y = response,
    training_frame = train_cv)

1. 现在，创建一个新的目标编码训练集和测试集，明确地将测试集的噪声水平设置为0：

   train_te = te.transform(frame = train_cv)
   test_te = te.transform(frame = test_cv, noise = 0.0)
   

2. 接下来，通过查看目标编码变量的直方图来检查目标编码的结果：

   train_te["purpose_te"].hist()
   

这产生了以下图表：

图 5.24 – 目标编码的贷款用途变量

以下代码为addr_state_te变量生成直方图：

train_te["addr_state_te"].hist()

输出如下：

图 5.25 – 目标编码的地址状态变量

1. 将目标编码变量添加到预测器列表中：

   predictors.extend(["addr_state_te", "purpose_te"])
   

2. 然后，使用列表推导式以提高效率来删除源列：

   drop = ["addr_state", "purpose"]
   predictors = [x for x in predictors if x not in drop]
   

3. 在创建其他特征时，我们的预测器列表将发生变化。为了跟踪这些步骤，更新predictors列表的副本而不是原始列表是明智的：

   transformed = predictors.copy()
   

4. 此外，为了方便，我们使用目标编码的值来重命名我们的数据集：

   train = train_te
   test = test_te
   

   你应该调整目标编码模型多少？

   注意，我们使用了相同的目标编码参数来转换两个不同的变量。那么，为什么不为每个变量单独编码并使用自定义参数设置呢？在我们的情况下，我们并不需要这样做。唯一需要变化的参数值是那些确定混合量的值：inflection_point和smoothing。对于purpose变量，混合实际上并不需要，因为样本量足够大，可以产生准确的中值。另一方面，addr_state变量将极大地受益于混合。因此，我们将参数设置为对addr_state合理的值。这些值基本上会被purpose忽略。

   在一种模型输出是另一个模型输入的情况下，始终牢记，重要的是输入模型中参数设置变化对最终模型预测的影响。

5. 让我们使用 AutoML 用这些新特征重新拟合我们的模型并打印排行榜：

   check = H2OAutoML(max_models = 10,
                     max_runtime_secs_per_model = 60,
                     exclude_algos = ["DeepLearning"],
                     seed = 25)
   check.train(x = transformed, 
               y = response, 
               training_frame = train)
   check.leaderboard
   

这导致了以下输出：

图 5.26 – 目标编码后的 AutoML 排行榜

最佳个体（非集成）模型是 GBM，其性能（0.704491）仅略优于目标编码前的最佳 GBM（0.703838）。人们经常问，这个微小的性能提升是否值得目标编码的努力？这个问题完全忽略了重点。回想一下，H2O GBM 自然能很好地处理高基数分类变量，所以性能相当的事实并不令人惊讶。

1. 应该问什么正确的问题？让我们看看变量重要性，并比较目标编码前后的变量：

   check_gbm = h2o.get_model(check.leaderboard[2, "model_id"])
   check_gbm.varimp_plot(15)
   

在目标编码之前，高基数变量是最重要的：

图 5.27 – 目标编码前的 H2O GBM 模型变量重要性

在目标编码之后，这些分类变量的重要性发生了变化：

图 5.28 – 目标编码后的 H2O GBM 模型变量重要性

目标编码对 GBM 模型的影响与整体模型性能的关系不大，而与这些变量的影响和解释有关。目标编码purpose的重要性略有变化，从第三位上升到第五位。目标编码addr_state的影响大幅下降，从第一位下降到第七位。这种影响差异也导致了可解释性的差异。前一个模型主要按州进行分割，本质上意味着每个州都有一个不同的贷款违约模型（可能需要向监管机构解释的后果）。在后一个模型中，州的影响以非常类似于统计模型中随机效应的方式进行调整。

数据科学家可以选择对他们情况最有意义的场景。目标编码addr_state的另一个好处是混合功能，在生产中，它将更好地泛化低计数州的变量。

从排行榜中选择最佳的 XGBoost 目标编码模型：

check_xgb = h2o.get_model(check.leaderboard[5, "model_id"])

check_xgb.varimp_plot(15)

这产生了以下图表：

图 5.29 – 目标编码后的 XGBoost 模型变量重要性图

purpose和address_state几乎以与 GBM 模型相同的位置进入了前 10 名。在 XGBoost 模型中，对目标编码分类变量的重要性比在 GBM 模型中更重要。在其他条件相同的情况下，一些特征工程步骤可能会受到所选算法的影响。

其他特征工程选项

特征工程选项的分类方法有多种，根据问题的不同，你可以采取几乎无限的方法。对于一些高级分类，我们可以考虑以下大致层次结构：

• 代数转换器：

  1. 通过添加、减去、乘以或除以数值列来创建新的交互特征。

  2. 使用简单的数学函数，如对数、指数、幂、根和三角函数

• 基于聚类的转换器：使用 k-means 或其他无监督算法创建聚类。然后，执行以下操作：

  1. 测量数值观测值到指定聚类的距离。

  2. 将每个集群视为分类变量的一个级别，并对集群进行目标编码。

• 数值到分类变换：通常，将数据分箱到十分位或使用直方图，然后在每个箱内取平均值可以产生好的预测特征。

• 分类到数值变换：

  1. 单热或指示值编码。

  2. 目标编码。

  3. 数值摘要编码：这与目标编码类似，但你是在总结一个数值预测列而不是目标变量；例如，每个州的平均温度。

  4. 证据权重：这仅用于二元分类问题。证据权重是成功与失败（好与坏、一与零）比率的自然对数：

• 维度缩减变换：截断特征值或奇异值分解。

作为数据科学家，你可以将这些组件的多个组合用于特定问题的合理特征。我们将在对 Lending Club 数据的完整分析中重新审视一些这些配方，这些配方可以在第八章，“整合一切”中找到。

利用 H2O Flow 增强你的 IDE 工作流程

H2O Flow 是一个基于 Web 的 UI，在 H2O 集群运行的地方都可以使用。Flow 是交互式的，允许用户执行所有操作，包括导入数据、构建模型、调查模型以及将模型投入生产。虽然使用起来非常简单，但我们的经验是，大多数数据科学家（包括作者）更喜欢使用 Python 或 R 进行编码，而不是菜单驱动的交互式界面。本节是为这些数据科学家编写的：为什么我作为程序员还要使用 Flow？

有两个主要原因：

• 监控H2O 集群的状态和正在运行的作业

• 交互式调查数据、模型、模型诊断等，其中交互性是资产而非烦恼。

连接到 Flow

默认情况下，当集群启动时，Flow 在 H2O 服务器的 54321 端口启动（此端口在启动时可配置）。在浏览器中输入Error! Hyperlink reference not valid.以打开 Flow。Flow UI 简单直观，有有用的说明和视频：

图 5.30 – H2O Flow UI

首先，让我们考虑 Flow 的监控能力。

使用 Flow 进行监控

在 Flow 的管理员菜单下，前三项选项是作业、集群状态和水表。这些都是 Flow 监控能力的核心，我们将逐一回顾它们。

这里显示了 Flow 的管理员菜单：

图 5.31 – 使用 Flow 管理员菜单进行监控选项

我们首先从监控作业开始。

监控作业

Flow 命令行中的getJobs：

图 5.32 – 使用 Flow 管理菜单列出作业选项

我们继续监控健康状况。

监控 H2O 集群健康

getCloud 命令。此命令监控集群的健康状况，是检查 H2O 是否看起来工作不正确的第一个地方：

图 5.33 – 使用 Flow 管理菜单监控集群状态

接下来，我们将监控 CPU 使用情况。

实时监控 CPU 使用情况

Water Meter 工具是 CPU 使用情况的实用监控工具。它为每个 CPU 显示一个条形图，颜色对应于每个 CPU 的活动状态。与监视 Jupyter 笔记本单元格中的黑色进度条增长相比，Water Meter 提供了更多信息。它还实时展示了特定计算在可用计算资源中的分布情况：

图 5.34 – H2O Flow Water Meter

我们还可以监控网格搜索。

监控网格搜索

H2O Flow 允许您交互式地监控单个模型构建，但在执行网格搜索或 AutoML 创建等多个作业时特别有用。这些作业可以在启动时实时监控，并在运行期间和完成后进行审查。

我们网格搜索策略的第一步是评估模型深度。当模型运行时，我们可以打开 Flow 并列出作业。名为 gbm_depth_grid 的作业正在运行。点击名称会打开正在运行的作业，允许我们查看更多详细信息或取消作业。这些操作在 Python 中并不容易获得：

图 5.35 – 在 Flow 中监控网格搜索作业

在任何时候选择查看按钮都会打开网格：

图 5.36 – 在 Flow 中查看网格搜索结果

选择任何单个网格模型后，将打开一个交互式模型视图，我们将在下一节和 第七章，理解机器学习模型中更详细地讨论。

监控 AutoML

监控 AutoML 作业类似。首先，在作业列表中搜索 AutoML 构建作业并选择模型的名称链接：

图 5.37 – 选择 AutoML 构建作业

一旦 AutoML 构建过程开始，您可以实时监控进度或点击查看以观看排行榜，当模型构建时：

图 5.38 – 查看 AutoML 构建作业

注意：Flow 非常适合监控排行榜

交互式排行榜是实时监控 AutoML 作业的好方法。这对于那些不急于完成但计划运行数小时以构建模型的 AutoML 运行尤其如此。再次强调，Python 中可用的只是进度条，如果你看不到服务器上的实际工作，进度条可能会显得非常慢（图 5.39）。

图 5.39 – 流中的 AutoML 排行榜

选择任何单个 AutoML 模型将打开一个交互式模型视图。

流的交互式调查

如我们之前提到的，流中的交互性对于实时监控运行中的作业非常有用。此外，流使得在建模之前探索数据和在模型构建后评估候选模型比在 Python 中编码更方便。唯一可能的缺点是在可重复性和整个建模过程的文档化非常重要时，通过菜单驱动的探索。我们将在讨论 H2O AutoDoc 功能时更详细地探讨这个话题，见第七章，理解机器学习模型。

流中的交互式数据探索

执行以下步骤：

1. 在数据菜单中，选择列出所有框架：

图 5.40 – 流中列出数据框

1. 点击LendingClubClean.hex链接以拉起数据摘要：

图 5.41 – 流中的 Lending Club 数据

点击目的列的链接会生成一个摘要图：

图 5.42 – 流中贷款目的数据列

1. 接下来，点击检查然后域将生成一个类似于我们在 Python 中创建的摘要表：

图 5.43 – 流中贷款目的数据表

流中的模型探索

在流中选择任何模型，无论是通过模型菜单项中的列出所有模型选项，还是从网格搜索或 AutoML 排行榜，都会得到一个模型摘要：

图 5.44 – 流中 AutoML 的 GBM 模型摘要

模型摘要的布局使其非常容易探索。默认情况下显示训练集和验证集的 ROC 曲线和 AUC 值。变量重要性图也易于获取：

图 5.45 – 流中的 GBM 变量重要性

通常，通过模型摘要立即获取结果比从 Python 客户端执行等效操作更方便。

流的最佳实践

如果你使用 Python 进行编码，我们强烈建议仅将 Flow 用作监控平台和只读工具。这是我们自己的工作所采用的方法。代码应包含所有导入数据、创建特征、拟合模型、部署模型等步骤。这允许你重复任何分析，并且是可重复性的先决条件。代码在调查和交互式步骤中通常不太方便。将这些步骤留给 Flow。

将所有这些放在一起——算法、特征工程、网格搜索和 AutoML

H2O AutoML 实现简单而强大，那么我们为什么还需要网格搜索呢？实际上，对于许多现实世界的企业用例，AutoML 排行榜上的任何顶级候选模型都可以是投入生产的优秀模型。这尤其适用于 AutoML 产生的堆叠集成模型。

然而，我们对网格搜索的覆盖并不仅仅是为了满足知识上的好奇心。接下来我们将概述的一个更复杂的过程，它使用 AutoML，然后是定制的网格搜索来发现和微调模型性能。

增强的 AutoML 程序

下面是步骤：

1. 首先，在你的数据上运行 AutoML 以创建一个基准排行榜。你可以调查领先模型，了解拟合算法到你的数据所需的运行时间，等等，这些都可能为未来的 AutoML 参数选择和预期提供信息。

2. 第二阶段是特征工程。在开发新特征的同时，根据需要重复 AutoML 运行，以检查工程的影响，并查看从诊断中可能获得的其他见解。

3. 在完成特征工程阶段后，使用 AutoML 创建一个最终的排行榜。

4. 从排行榜中选择一个模型作为生产候选。如果你选择了一个集成模型，那么你就完成了。对于堆叠集成模型的表现，你几乎没有什么可以改进的。

5. 如果你选择一个单独的模型，比如 GBM 或 DRF，那么使用该模型的参数作为进一步网格搜索的指南，采用本章概述的一般策略。使用额外的网格搜索进一步微调候选模型是可能的。

这种增强的 AutoML 程序对于许多问题来说可能过于复杂。如果你所在的企业有快速构建和部署模型的实践，尤其是经常更新或替换模型的，那么这种方法可能实际上付出的努力超过了它的价值。基于最近数据的模型构建的优势往往超过了使用这些额外建模步骤所获得的收益。

然而，如果你所在的行业模型审查和尽职调查过程漫长且复杂，或者投入生产的模型往往长时间留在生产中，或者你正在处理一个风险很高的模型（例如，直接影响人们生活的模型，而不仅仅是网站上他们会看到的广告），那么这个更复杂的程序可能确实值得额外的努力。我们已经在多个实际案例中成功使用了它。

摘要

在本章中，我们考虑了不同的数据拆分选项，深入探讨了梯度提升和随机森林等强大且流行的算法，学习了如何使用两阶段网格搜索策略优化模型超参数，利用 AutoML 高效地拟合多个模型，并进一步研究了特征工程选项，包括对目标编码的深入研究。此外，我们还看到了如何使用 Flow 来监控 H2O 系统并交互式地调查数据和模型。你现在拥有了使用 H2O 平台构建有效企业级预测模型所需的大部分工具。

然而，我们还没有结束对高级建模主题的探讨。在第六章，“高级模型构建 – 第二部分”，我们将讨论数据获取的最佳实践，更深入地探讨模型检查点和重新拟合，并展示如何确保可重复性。此外，我们还将详细考虑两个更实用的示例：第一个展示了 Sparkling Water 管道如何高效地将 Spark 功能与 H2O 建模集成，第二个介绍了隔离森林，这是一种用于 H2O 中异常检测的无监督学习算法。

第六章：高级建模 – 第二部分

在上一章第五章，高级建模 – 第一部分中，我们详细介绍了在 H2O 平台上构建企业级监督学习模型的过程。在本章中，我们通过以下方式完成我们的高级建模主题：

• 展示如何在 Apache Spark 管道内构建 H2O 监督学习模型

• 介绍 H2O 的无监督学习方法

• 讨论更新 H2O 模型的最佳实践

• 记录需求以确保 H2O 模型的可重复性

我们在本章开始时介绍 Sparkling Water 管道，这是一种将 H2O 模型原生嵌入 Spark 管道的方法。在企业环境中，Spark 被广泛使用，我们发现这是一种构建和部署 H2O 模型的流行方法。我们通过构建一个用于情感分析的 Sparkling Water 管道来演示，该管道使用亚马逊食品产品的在线评论数据。

然后我们介绍 H2O 中可用的无监督学习方法。使用信用卡交易数据，我们使用隔离森林构建了一个异常检测模型。在这种情况下，无监督模型将被用于在金融欺诈预防工作中标记可疑的信用卡交易。

我们在本章结束时解决与本章以及第五章**高级建模 – 第一部分中构建的模型相关的问题。这些是更新 H2O 模型的最佳实践，以及确保 H2O 模型结果的可重复性。

本章将涵盖以下主题：

• Sparkling Water 中的建模

• H2O 中的 UL 方法

• 更新 H2O 模型的最佳实践

• 确保 H2O 模型的可重复性

技术要求

本章中介绍的代码和数据集可以在 GitHub 仓库github.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O中找到。如果您在此阶段尚未设置 H2O 环境，请参阅附录 – 为本书启动 H2O 集群的替代方法以进行设置。

Sparkling Water 中的建模

在第二章，平台组件和关键概念中，我们了解到 Sparkling Water 在 Apache Spark 环境中仅仅是 H2O-3。从 Python 开发者的角度来看，H2O-3 代码与 Sparkling Water 代码几乎相同。如果代码相同，为什么 Sparkling Water 中还要有单独的建模部分？这里有两个重要的原因，如下所述：

• Sparkling Water 使数据科学家能够利用 Spark 的广泛数据处理能力。

• Sparkling Water 提供了对生产 Spark 管道的访问。我们将在下面进一步阐述这些原因。

Spark 因其数据操作能够随着数据量的增加而轻松扩展而闻名。由于 Spark 在企业环境中的存在现在几乎是一个既定的事实，数据科学家应该将 Spark 添加到他们的技能工具箱中。这并不像看起来那么困难，因为 Spark 可以通过 Python（使用 PySpark）操作，数据操作主要使用 Spark SQL 编写。对于经验丰富的 Python 和结构化查询语言（SQL）编码者来说，这确实是一个非常容易的过渡。

在第五章“高级模型构建 – 第一部分”中的 Lending Club 示例中，使用 H2O 集群上的原生 H2O 命令执行了数据整理和特征工程任务。这些 H2O 数据命令在 Sparkling Water 中同样适用。然而，在一个已经投资 Spark 数据基础设施的企业中，用 Spark 的等效命令替换 H2O 数据命令是非常有意义的。然后，将清洗后的数据集传递给 H2O 以处理后续的建模步骤。这是我们推荐在 Sparkling Water 中的工作流程。

此外，Spark 流水线在企业生产环境中经常用于提取、转换和加载（ETL）以及其他数据处理任务。Sparkling Water 将 H2O 算法集成到 Spark 流水线中，使得在 Spark 环境中无缝训练和部署 H2O 模型成为可能。在本节的剩余部分，我们将展示如何将 Spark 流水线与 H2O 建模相结合，创建一个 Sparkling Water 流水线。这个流水线可以轻松地推广到生产环境中，我们将在第十章“H2O 模型部署模式”中详细讨论这个话题。

介绍 Sparkling Water 流水线

图 6.1展示了 Sparkling Water 流水线的训练和部署过程。流水线从模型训练的输入数据源开始。数据清洗和特征工程步骤通过 Spark 转换器依次构建，一个转换器的输出成为后续转换器的输入。一旦数据集以建模准备好的格式存在，H2O 将接管以指定和构建模型。我们将所有转换器和模型步骤封装到一个流水线中，该流水线经过训练然后导出用于生产。

在生产环境中，我们导入流水线并向其中引入新的数据（在以下图中，我们假设这是通过数据流完成的，但数据也可以批量到达）。流水线输出 H2O 模型预测：

图 6.1 – Sparkling Water 流水线训练和部署示意图

接下来，让我们创建一个流水线来实现情感分析。

实现情感分析流水线

接下来，我们为情感分析分类问题创建一个 Sparkling Water 流水线。情感分析用于建模客户对产品或公司的正面或负面感受。它通常需要自然语言处理（NLP）从文本中创建预测器。在我们的例子中，我们使用斯坦福网络分析平台（SNAP）存储库中预处理的亚马逊美食评论数据集。有关原始数据，请参阅snap.stanford.edu/data/web-FineFoods.html。

让我们先验证 Spark 是否在我们的系统上可用。

spark

以下屏幕截图显示了输出：

图 6.2 – 使用 PySparkling 内核在 Jupyter 笔记本中启动 Spark

你可以在 Spark 输出中看到SparkSession已经启动，并且SparkContext已经初始化。

PySpark 和 PySparkling

PySpark是 Apache 的 Spark 的 Python 接口。它提供了一个交互式 Spark 会话的 shell，并可以访问 Spark 组件，如 Spark SQL、DataFrames 和 Streaming。PySparkling是PySpark的 H2O 扩展，允许从 Python 在 Spark 集群上启动 H2O 服务。我们的 Jupyter 笔记本使用 PySpark shell。

在 Sparkling Water 的内部后端模式下，H2O 资源在其 Spark 对应物上运行，所有这些都在同一个Java 虚拟机（JVM）中。如图所示，在SparkContext之上启动了一个H2OContext，并在 Spark 集群的每个工作节点上初始化了 H2O：

图 6.3 – Sparkling Water 内部后端模式

PySparkling 用于创建 H2OContext 并初始化工作节点，如下所示：

from pysparkling import *

hc = H2OContext.getOrCreate()

这会产生以下输出：

图 6.4 – Sparkling Water 集群启动后立即

在 H2O 服务器启动后，我们使用 Python 命令与之交互。我们首先导入原始数据。

导入原始的亚马逊数据

我们将亚马逊训练数据导入到reviews_spark Spark DataFrame 中，如下所示：

datafile = "AmazonReviews_Train.csv"

reviews_spark = spark.read.load(datafile, format="csv",

    sep=",", inferSchema="true", header="true")

作为替代方案，我们本可以使用 H2O 导入数据，然后将reviews_h2o H2O 框架转换为reviews_spark Spark DataFrame，如下所示：

import h2o

reviews_h2o = h2o.upload_file(datafile)

reviews_spark = hc.as_spark_frame(reviews_h2o)

这种方法的优势在于，它允许我们使用 H2O Flow 进行交互式数据探索，如第五章中所示，高级模型构建 – 第一部分，然后再将其转换为 Spark DataFrame。

接下来，我们打印数据模式以显示输入变量和变量类型。这是通过以下代码完成的：

reviews_spark.printSchema()

结果数据模式在以下屏幕截图中显示：

图 6.5 – 亚马逊美食原始数据的模式

为了简化，我们在这个分析中只使用了Time、Summary和整体的Score列。Time是一个日期时间字符串，Score是一个介于 1 到 5 之间的整数，从它可以导出情感，而Summary是产品评论的简短文本摘要。请注意，Text列包含实际的产品评论。更好的模型选择将包括Text，而不是或可能还包括Summary。

使用以下代码将输入数据模式保存到schema.json文件中：

with open('schema.json','w') as f:

    f.write(str(reviews_spark.schema.json()))

保存输入数据模式将使 Sparkling Water 管道的部署变得非常简单。

输入数据和生产数据结构

保存数据模式以供部署假定生产数据将使用相同的模式。作为构建 Sparkling Water 管道的数据科学家，我们强烈建议您的训练输入数据与生产数据模式完全一致。在模型构建之前追踪这些信息是值得的，而不是在部署阶段重新设计某些内容。

定义 Spark 管道阶段

Spark 管道是通过将单个数据操作或转换器连接在一起来创建的。每个转换器将其输入数据作为前一阶段的输出数据，这使得数据科学家的开发变得非常简单。一个大型作业可以被分解成一系列相互连接的单独任务。

Apache Spark 通过延迟评估来操作。这意味着计算不会立即执行；相反，操作被缓存，当触发某种操作的动作时才会执行。这种方法具有许多优点，包括允许 Spark 优化其计算。

在我们的示例中，所有数据清洗和特征工程步骤将通过 Spark 转换器创建。通过训练一个 H2O XGBoost 模型来最终确定管道。为了清晰起见，我们在构建管道的过程中将为每个转换器定义一个阶段编号。

第 1 阶段 – 创建一个转换器以选择所需的列

Spark 的SQLTransformer类允许我们使用 SQL 来处理数据。由于大多数数据科学家已经熟悉 SQL，这使得 Spark 在数据操作方面的采用变得顺利。SQLTransformer将在本管道中得到广泛使用。运行以下代码以导入该类：

from pyspark.ml.feature import SQLTransformer

定义一个colSelect转换器，如下所示：

colSelect = SQLTransformer(

    statement="""

    SELECT Score, 

           from_unixtime(Time) as Time, 

           Summary 

    FROM __THIS__""")

在前面的代码中，我们选择了Score、Time和Summary列，将时间戳转换为可读的日期时间字符串。FROM语句中的__THIS__引用了前一转换器阶段的输出。由于这是第一个阶段，__THIS__指的是输入数据。

在开发过程中，通过直接调用转换器来检查每个阶段的结果是有帮助的。这使得调试转换器代码和理解下一阶段可用的输入变得容易。调用转换器将导致 Spark 执行它以及所有未评估的上游代码。以下代码片段说明了如何调用转换器：

selected = colSelect.transform(reviews_spark)

selected.show(n=10, truncate=False)

下面的屏幕截图显示了前几行：

图 6.6 – colSelect 阶段 1 转换器的结果

这个第一个转换器已经将原始数据简化为三列。我们将分别对每一列进行操作，以创建我们的建模准备数据集。让我们从时间列开始。

阶段 2 – 定义一个转换器以创建多个时间特征

这个模型的目标是预测情感：评论是正面还是负面？日期和时间可能是影响情感的因素。也许人们在周五晚上给出更好的评论，因为周末即将到来。

时间列以时间戳的形式内部存储。为了在建模中变得有用，我们需要以预测算法可以理解的形式提取日期和时间信息。我们定义了一个expandTime转换器，使用 SparkSQL 数据方法（如hour、month和year）从原始时间戳信息中构建多个新特征，如下所示：

expandTime = SQLTransformer(

    statement="""

    SELECT Score,

           Summary, 

           dayofmonth(Time) as Day, 

           month(Time) as Month, 

           year(Time) as Year, 

           weekofyear(Time) as WeekNum, 

           date_format(Time, 'EEE') as Weekday, 

           hour(Time) as HourOfDay, 

           IF(date_format(Time, 'EEE')='Sat' OR

              date_format(Time, 'EEE')='Sun', 1, 0) as

              Weekend, 

        CASE 

          WHEN month(TIME)=12 OR month(Time)<=2 THEN 'Winter' 

          WHEN month(TIME)>=3 OR month(Time)<=5 THEN 'Spring' 

          WHEN month(TIME)>=6 AND month(Time)<=9 THEN 'Summer' 

          ELSE 'Fall' 

        END as Season 

    FROM __THIS__""")

注意，在expandTime代码中选择了评分和摘要，但我们没有对它们进行操作。这仅仅是将这些列传递给后续的转换器。我们从时间列中构建了几个特征：日、月、年、周数、星期几、小时、周末和季节。而且，__THIS__再次指的是colSelect阶段 1 转换器的输出。

为了检查我们的开发进度并可能调试我们的代码，我们检查第二阶段的输出，该阶段使用存储在selected中的第一阶段结果作为输入，如下面的代码片段所示：

expanded = expandTime.transform(selected)

expanded.show(n=10)

下面的屏幕截图显示了输出。

图 6.7 – expandTime 阶段 2 转换器的结果

输出确认我们已经成功将时间列替换为一系列新创建的特征。

阶段 3 – 从评分创建响应，同时移除中性评论

在这个阶段，我们使用评分列的值创建我们的情感响应变量。我们可以将正面与非正面建模为响应，但选择移除中性评论（评分=3），并将正面与负面进行比较。这是净推荐者得分（NPS）分析中的标准方法，并且在情感分析中也很常见。这样做是有道理的，因为我们假设具有中性响应的记录包含的信息很少，模型难以从中学习。

我们创建createResponse转换器的方式如下：

createResponse = SQLTransformer(

    statement="""

    SELECT IF(Score < 3,'Negative', 'Positive') as Sentiment,

           Day, Month, Year, WeekNum, Weekday, HourOfDay, 

           Weekend, Season, Summary

    FROM __THIS__ WHERE Score != 3""")

IF语句将 1 或 2 分给Negative情感，并将所有其他情感归为Positive，通过WHERE子句过滤掉中性的评论。现在，通过运行以下代码来检查这个中间步骤的结果：

created = createResponse.transform(expanded)

created.show(n=10)

这将产生以下输出：

图 6.8 – createResponse 阶段 3 的输出结果

剩下的唯一特征工程步骤是将Summary列中的文本替换为适当的代表性数值。第 4 到第 8 阶段将利用 Spark 内置的 NLP 数据转换功能，根据Summary中的文本创建特征。虽然这不是一个正式的深度 NLP 研究，但我们将详细描述每个转换步骤，以便使我们的模型易于理解。

第 4 阶段 – 分词摘要

分词将文本序列分解成单个术语。Spark 提供了一个简单的Tokenizer类和一个更灵活的RegexTokenizer类，我们在这里使用后者。pattern参数指定了一个正则表达式中的转义引号"[!,\" ]"，并且我们指定This和this在后续处理中将被视为相同的术语。代码在下面的代码片段中展示：

from pyspark.ml.feature import RegexTokenizer

regexTokenizer = RegexTokenizer(inputCol = "Summary",

                                outputCol = "Tokenized",

                                pattern = "[!,\"]",

                                toLowercase = True)

检查Summary中的分词值，如下所示：

tokenized = regexTokenizer.transform(created)

tokenized.select(["Tokenized"]).show(n = 10, 

    truncate = False)

输出在下面的屏幕截图中显示：

图 6.9 – regexTokenizer 阶段 4 的输出结果

现在短语已经被分解成单个术语或标记的列表。由于我们的目标是提取这些标记中的信息，我们接下来过滤掉那些信息量较小的单词。

第 5 阶段 – 去除停用词

有些单词在语言中出现的频率很高，它们几乎没有预测价值。这些被称为停用词，我们使用 Spark 的StopWordsRemover转换器来删除它们，如下面的截图所示：

removeStopWords = StopWordsRemover(

    inputCol = regexTokenizer.getOutputCol(),

    outputCol = "CleanedSummary", 

    caseSensitive = False)

让我们比较去除停用词前后的分词结果，如下所示：

stopWordsRemoved = removeStopWords.transform(tokenized)

stopWordsRemoved.select(["Tokenized", 

                         "CleanedSummary"]).show(

    n = 10, truncate = False)

结果在下面的屏幕截图中显示：

图 6.10 – removeStopWords 阶段 5 的输出结果

检查图 6.10的结果是很有说明性的。就大部分而言，移除诸如as、it或the之类的停用词对意义的影响很小：将Great! Just as good as the expensive brands!的陈述缩减为标记[great, good, expensive, brands]似乎是合理的。但Not as advertised!缩减为[advertised]呢？陈述中的not似乎承载着重要信息，而移除它会导致信息丢失。这是一个有效的问题，可以通过 NLP 概念如 n-gram（双词组、三词组等）来解决。为了演示 Sparkling Water 管道的例子，我们将承认这是一个潜在问题，但为了简单起见，我们将继续前进。

在预测建模中，自然语言处理（NLP）将文本信息表示为数字。一种流行的方法是词频-逆文档频率（TF-IDF）。TF 简单地是指一个词在文档中出现的次数除以文档中的单词数。在一个语料库（文档集合）中，IDF 衡量一个词在其构成文档中的稀有程度。例如，线性这样的词可能频率很高，但随着它在文档中出现的次数增加，其信息价值会降低。另一方面，像摩托车这样的词可能频率较低，但在语料库中出现的文档较少，使其信息含量更高。将 TF 乘以 IDF 得到一个经过缩放的 TF 值，这已被证明非常有用。当一个词频繁出现在一个文档中但只在一个文档中出现时，TF-IDF 值达到最大（哪篇文章回顾了摩托车？）。

TF-IDF 在信息检索、文本挖掘、推荐系统和搜索引擎以及预测建模中得到广泛应用。接下来的两个管道阶段将分别计算 TF 和 IDF 值。

第 6 阶段 – 为 TF 哈希单词

我们在 Spark 中计算 TF 的首选方法是CountVectorizer，它使用内部词汇表将索引映射回单词。也就是说，countVectorizerModel.vocabulary[5]查找存储在索引 5 中的单词。

构建更好的 TF-IDF 模型的一个技巧是通过将minDF参数设置为整数或比例来移除过于罕见的词，如下所示：

• minDF = 100：省略在不到 100 个文档中出现的词

• minDF = 0.05：省略在不到 5%的文档中出现的词

还有一个maxDF参数可以用来移除在语料库中过于频繁出现的词。例如，在 NLP 文档检索中设置maxDF = 0.95可能会提高模型性能。

我们创建一个countVectorizer转换器，如下所示：

from pyspark.ml.feature import CountVectorizer 

countVectorizer = CountVectorizer(

    inputCol = removeStopWords.getOutputCol(),

    outputCol = "frequencies",

    minDF = 100 )

注意，我们的语料库是removeStopWords转换器的输出列，每行作为一个文档。我们输出频率并设置minDF为 100。因为countVectorizer是一个模型，所以在执行管道之前手动训练它是好主意。这对于任何作为管道组件的模型来说都是一种好习惯，因为它允许我们在管道执行开始之前确定其行为，并可能对其进行微调。以下代码片段展示了这一点：

countVecModel = countVectorizer.fit(stopWordsRemoved)

我们可以通过检查其词汇表大小和单个术语，以及任何其他适当的尽职调查来探索这个模型。以下是完成此操作所需的代码：

print("Vocabulary size is " +

   str(len(countVecModel.vocabulary)))

print(countVecModel.vocabulary[:7])

词汇表结果如下所示：

![图 6.11 – countVecModel 转换器的词汇表大小和词汇]

![图 B16721_06_11.jpg]

图 6.11 – countVecModel 转换器的词汇表大小和词汇

在图 6.11中显示的总词汇表大小是 1,431 个术语。使用以下代码检查数据：

vectorized = countVecModel.transform(stopWordsRemoved)

vectorized.select(["CleanedSummary", "frequencies"]).show(

                  n = 10, truncate = False)

向量化结果如下截图所示：

![图 6.12 – countVecModel 转换器的中间结果]

![图 B16721_06_12.jpg]

图 6.12 – countVecModel 转换器的中间结果

图 6.12 展示了每行旁边带有 TF 向量的清洗后的摘要标记。为了描述第一行的输出，1431 的值是词汇表大小。接下来的值序列——[1,10,11,38]——指的是词汇向量中[good, quality, dog, food]术语的索引。最后的值序列——[1.0,1.0,1.0,1.0]——是它们各自术语的 TF 值。因此，dog通过索引11引用，并在CleanedSummary列中出现了 1 次。

第 7 阶段 – 创建 IDF 模型

我们使用 Spark 的IDF估计器从countVectorizer缩放频率，得到 TF-IDF 值。我们执行以下代码来完成此操作：

from pyspark.ml.feature import IDF

idf = IDF(inputCol = countVectorizer.getOutputCol(),

          outputCol = "TFIDF",

          minDocFreq = 1)

在我们执行管道之前，手动训练 IDF 模型以查看结果，如下所示：

idfModel = idf.fit(vectorized)

再次检查数据，特别注意缩放的 TF-IDF 频率，如下所示：

afterIdf = idfModel.transform(vectorized)

afterIdf.select(["Sentiment", "CleanedSummary",

    "TFIDF"]).show(n = 5, truncate = False, vertical = True)

以下截图显示了结果 TF-IDF 模型的头五行：

![图 6.13 – 来自 Spark 转换器的 TF-IDF 频率]

![图 B16721_06_13.jpg]

图 6.13 – 来自 Spark 转换器的 TF-IDF 频率

第 8 阶段 – 选择建模数据集列

除了Sentiment响应变量以及从Time变量中构建的所有特征之外，idf的输出还包括原始的Summary列以及Tokenized、CleanedSummary、frequencies和TFIDF。在这些中，我们只想保留TFIDF。以下代码选择了所需的列：

finalSelect = SQLTransformer(

    statement="""

    SELECT Sentiment, Day, Month, Year, WeekNum, Weekday,

           HourOfDay, Weekend, Season, TFIDF

    FROM __THIS__ """)

现在我们已经完成了模型准备数据的构建，下一步是使用 H2O 的监督学习算法之一构建一个预测模型。

第 9 阶段 – 使用 H2O 创建 XGBoost 模型

到目前为止，我们所有的数据处理和特征工程工作都仅使用了 Spark 方法。现在，我们转向 H2O 在Sentiment列上训练 XGBoost 模型。为了简单起见，我们使用默认设置进行训练。代码如下所示：

import h2o

from pysparkling.ml import ColumnPruner, H2OXGBoost

xgboost = H2OXGBoost(splitRatio = 0.8, labelCol = "Sentiment")

注意——在 Sparkling Water 中训练模型

在第五章《高级模型构建——第一部分》中，我们详细演示了构建和调整高质量 XGBoost 模型的过程。在这里，我们停留在简单的基线模型上，以强调整体管道的实用性。在实际应用中，应该在这条管道的建模组件上投入更多的努力。

创建 Sparkling Water 管道

现在我们已经定义了所有转换器，我们准备创建一个管道。这样做很简单——我们只需按照顺序在Pipeline的stages列表参数中命名每个转换器，如下所示：

from pyspark.ml import Pipeline

pipeline = Pipeline(stages = [

    colSelect, expandTime, createResponse, regexTokenizer,

    removeStopWords, countVectorizer, idf, finalSelect,

    xgboost])

使用fit方法简化了管道模型的训练。我们传递一个包含原始数据的 Spark DataFrame 作为参数，如下所示：

model = pipeline.fit(reviews_spark)

在pipeline.fit过程中，数据预处理和特征工程阶段按照在 XGBoost 模型拟合之前定义的顺序应用于原始数据。这些管道阶段在生产部署后与 XGBoost 阶段操作相同，生成预测。

展望未来——生产预览

将 Sparkling Water 管道投入生产只是简单地保存pipeline模型，将其加载到生产系统中，然后调用以下操作：

predictions = model.transform(input_data)

在第十章《H2O 模型部署模式》中，我们展示了如何将此管道作为 Spark 流应用程序部署，该管道接收原始流数据并在实时输出预测。

H2O 中的 UL 方法

H2O 包括几个无监督学习算法，包括广义低秩模型（GLRM）、主成分分析（PCA）以及用于降维的聚合器。聚类用例可以利用 k-means 聚类、H2O 聚合器、GLRM 或 PCA。无监督学习还基于一组在预测建模应用中使用的有用特征转换器——例如，一个观测点到由无监督方法识别的特定数据簇的距离。此外，H2O 还提供了一种用于异常检测的隔离森林算法。

什么是异常检测？

大多数机器学习（ML）算法以某种方式试图在数据中找到模式。这些模式被用于监督学习模型中的预测。许多无监督学习算法试图通过聚类相似数据或估计数据段之间的边界来揭示模式。无监督异常检测算法采取相反的方法：不遵循已知模式的数据点是我们要发现的。

在这个背景下，术语“异常”是中性的。它可能指的是一种不寻常的观察，因为它是最先出现的；更多的数据可能会产生更多类似的观察。异常可能表明意外事件，并可作为诊断工具。例如，在制造数据收集应用中，一个失败的传感器可能会产生不典型的测量值。异常也可能表明恶意行为者或行为：安全漏洞和欺诈是导致异常数据点的两个经典例子。

异常检测方法可能包括监督的、半监督的或无监督的方法。监督模型在欺诈检测中是金标准。然而，为每个观察结果获取标签可能成本高昂，并且通常不可行。当没有标签时，需要无监督方法。半监督方法指的是只有一些数据记录被标记的情况，通常是一小部分记录。

隔离森林是一种无监督学习算法，用于异常检测——我们将在下一节介绍。

H2O 中的隔离森林

隔离森林算法基于决策树和一个巧妙的观察：异常值往往在决策树构建的早期就被分割出来。但是决策树是一种监督方法，那么如何实现无监督呢？诀窍是创建一个随机值的标签列，并在其上训练一个决策树。我们重复多次，并记录观察结果被分割到其自己的叶节点中的平均深度。观察结果越早被隔离，它就越可能是异常的。根据用例，这些异常点可能被过滤掉或升级以进行进一步调查。

你可以在下面的屏幕截图中看到隔离森林的表示：

图 6.14 – 一个隔离森林

我们展示了如何在 H2O 中使用 Kaggle 信用卡交易数据（www.kaggle.com/mlg-ulb/creditcardfraud）构建隔离森林。在这个数据集中有 492 起欺诈交易和 284,807 起非欺诈交易，这使得目标类高度不平衡。因为我们正在演示无监督异常检测方法，所以在模型构建过程中我们将丢弃标记的目标。

加载数据的 H2O 代码如下所示：

df = h2o.import_file("creditcardfraud.csv")

我们使用H2OIsolationForestEstimator方法来拟合我们的隔离森林。我们将树的数量设置为100，并省略了最后一列，该列包含目标类标签，如下面的代码片段所示：

iso = h2o.estimators.H2OIsolationForestEstimator(

    ntrees = 100, seed = 12345)

iso.train(x = df.col_names[0:31], training_frame = df)

一旦模型训练完成，预测就很简单，正如我们在这里可以看到的：

predictions = iso.predict(df)

predictions

输出如下所示：

图 6.15 – 隔离森林预测

图 6.15 中的预测结果包含两列：归一化的异常分数和所有树中隔离观察的平均分割数。请注意，异常分数与平均长度完全相关，随着平均长度的减小而增加。

我们如何从异常分数或平均长度到一个实际的预测？最好的方法之一是通过基于分位数的阈值。如果我们对欺诈的普遍性有所了解，我们可以找到相应的分数分位数值并将其用作预测的阈值。假设我们知道我们 5% 的交易是欺诈的。然后，我们使用以下 H2O 代码估计正确的分位数：

quantile = 0.95

quantile_frame = predictions.quantile([quantile])

quantile_frame

生成的分位数输出如下截图所示：

图 6.16 – 选择基于分位数阈值的阈值

我们现在可以使用以下代码使用阈值来预测异常类别：

threshold = quantile_frame[0, "predictQuantiles"]

predictions["predicted_class"] = \

    predictions["predict"] > threshold

predictions["class"] = df["class"]

predictions

以下截图显示了 predictions 帧的前 10 个观察值：

图 6.17 – 识别异常值

图 6.17 中的 predict 列只有一条观察值大于 0.198324，这是 图 6.16 中显示的 95 百分位数的阈值。predicted_class 列用 1 的值表示这一点。此外，请注意，该观察值的 mean_length 值为 6.14，小于其他九个观察值的平均长度值。

class 列包含我们在构建无监督隔离森林模型时省略的交易欺诈指示符。对于异常观察值，0 类值表示交易不是欺诈的。当我们像在这个例子中一样能够访问实际的目标值时，我们可以使用 predicted_class 和 class 列来研究异常检测算法在检测欺诈方面的有效性。我们应该注意，在这个上下文中，欺诈和异常的定义并不相同。换句话说，并非所有欺诈都是异常的，并非所有异常都会表明欺诈。这两个模型有各自的目的，尽管是互补的。

我们现在将注意力转向更新模型。

更新 H2O 模型的最佳实践

正如著名的英国统计学家乔治·博克斯所说，所有模型都是错误的，但有些是有用的。好的模型构建者了解他们模型的目的以及局限性。这对于那些构建投入生产的企业的模型的人来说尤其如此。

这样一种限制是，预测模型通常随着时间的推移而退化。这主要是因为在现实世界中，事物是不断变化的。也许我们所建模的——比如客户行为——本身也在变化，而我们收集的数据反映了这种变化。即使客户行为是静态的，但我们的业务组合发生了变化（比如更多的青少年和更少的退休人员），我们的模型预测很可能会退化。在这两种情况下，尽管原因不同，但用于创建我们的预测模型的样本人群现在与之前不同。

诊断模型退化并寻找其根本原因是诊断和模型监控的主题，这里我们不涉及。相反，一旦模型不再令人满意，数据科学家应该做什么？我们在以下章节中讨论了模型的重新训练和检查点。

重新训练模型

开发参数模型包括：

1. 找到正在建模的过程的正确结构形式，然后

2. 使用数据来估计该结构的参数。随着时间的推移，如果模型的架构保持不变但数据发生变化，那么我们可以重新拟合（或重新训练、重新估计或更新）模型的参数估计。这是一个简单且相对直接的程序。

然而，如果底层过程发生变化，以至于模型的架构形式不再有效，那么建模包括发现模型的正确形式和估计参数。这几乎，但并不完全，等同于从头开始。重建或更新模型（与更新参数估计相对）是描述这一更大活动的更好术语。

在机器学习或其他非参数模型的情况下，模型的架构形式由数据以及任何参数估计决定。这是非参数模型的一个卖点：它们非常数据驱动，几乎无假设。在这个背景下，重新拟合或重新训练与重建之间的差异几乎没有意义；这些术语实际上变成了同义词。

检查点模型

H2O 中的检查点选项允许您保存模型构建的状态，使得新的模型可以作为先前生成的模型的延续而不是从头开始构建。这可以用于使用额外的、更当前的数据更新生产中的模型。

检查点选项适用于分布式随机森林（DRF）、梯度提升机（GBM）、XGBoost 和深度学习（DL）算法。对于基于树的算法，指定的树的数量必须大于引用模型中的树的数量。也就是说，如果原始模型包含 20 棵树，而你指定了 30 棵树，那么将构建 10 棵新树。对于使用 epoch 而不是树的深度学习，这个概念同样适用。

只有在以下条件与检查点模型相同的情况下，这些算法的检查点才是可行的：

• 训练数据模型类型、响应类型、列、分类因素水平以及预测因子总数

• 如果在检查点模型中使用了，则使用相同的验证数据集（目前不支持检查点的交叉验证）。

您可以使用检查点指定的附加参数取决于用于模型训练的算法。

检查点注意事项

虽然在技术上可行，但我们不建议对 GBM 或 XGBoost 算法的新数据进行检查点。回想一下，提升是通过拟合先前模型的残差来工作的。因此，早期的分割是最重要的。在新数据被引入之前，模型的结构在很大程度上已经确定。

由于提升和袋装之间的差异，检查点随机森林模型不受这些问题的困扰。

确保 H2O 模型的可重复性

在实验室或实验环境中，在相同的协议和条件下重复一个过程应该导致类似的结果。当然，自然变异性可能发生，但这可以被测量并归因于适当的因素。这被称为可重复性。企业数据科学家应确保他们的模型构建具有良好的编码和充分的文档，以便使过程可重复。

在模型构建的上下文中，可重复性是一个更强的条件：重复一个过程时，结果必须相同。从监管或合规的角度来看，可能需要可重复性。

从高层次来看，可重复性需要相同的硬件、软件、数据和设置。让我们具体回顾 H2O 设置。我们开始于根据 H2O 集群类型的不同，考虑两个案例。

案例一 – 单节点集群中的可重复性

单节点集群是 H2O 硬件配置中最简单的配置。如果满足以下条件，可以实现可重复性：

• 软件要求：使用相同的 H2O-3 或 Sparkling Water 版本。

• 数据要求：使用相同的训练数据（请注意，H2O 需要单独导入文件而不是整个目录，以确保可重复性）。

• sample_rate、sample_rate_per_class、col_sample_rate、col_sample_rate_per_level、col_sample_rate_per_tree。

• 如果启用了早期停止，只有当显式设置了score_tree_interval参数并且使用了相同的验证数据集时，才能保证可重复性。

案例二 – 多节点集群中的可重复性

向集群添加节点会创建额外的硬件条件，这些条件必须满足才能实现可重复性。软件、数据和设置的要求与之前在案例 1中详细说明的单节点集群相同。这些要求在此概述：

• 硬件集群必须配置相同。具体来说，集群必须具有相同数量的节点，每个节点具有相同数量的 CPU 核心，或者——作为替代方案——对线程数量的相同限制。

• 集群的领导者节点必须启动模型训练。在 Hadoop 中，领导者节点会自动返回给用户。在独立部署中，必须手动识别领导者节点。请参阅 H2O 文档以获取更多详细信息。

为了确保可重复性，你必须确保集群配置是相同的。并行化级别（节点数和每个节点的 CPU 核心/线程数）控制着数据集在内存中的分区方式。H2O 在这些分区上以可预测的顺序运行其任务。如果分区数不同，结果将不可重复。

在集群配置不相同的情况下，可能可以限制正在复制的计算资源。这个过程涉及在原始环境中复制数据分区。我们建议您查阅 H2O 文档以获取更多信息。

特定算法的可重复性

深度学习（DL）、梯度提升机（GBM）和自动机器学习（AutoML）算法的复杂性引入了额外的约束，这些约束必须满足以确保可重复性。我们将在本节中回顾这些要求。

DL

由于性能原因，H2O DL 模型默认情况下不可重复。有一个可以启用的reproducible选项，但我们建议只在小型数据上这样做。由于仅使用一个线程进行计算，模型生成所需的时间会显著增加。

GBM

当满足单节点或多节点集群的可重复性标准时，GBM 在浮点数舍入误差范围内是确定的。

AutoML

为了确保 AutoML 中的可重复性，必须满足以下标准：

• DL 必须排除。

• 应使用max_models约束而不是max_runtime_secs。

通常，基于时间的约束是资源受限的。这意味着如果运行之间的可用计算资源不同，AutoML 可能在一次运行中训练比另一次运行更多的模型。指定要构建的模型数量将确保可重复性。

可重复性的最佳实践

为了确保可重复性，考虑之前强调的四个要求类别：硬件、软件、数据和设置。这些类别在此处有更详细的解释：

• 硬件：你应该始终记录 H2O 集群运行的硬件资源——这包括节点数、CPU 核心和线程数。（此信息可以在日志文件中找到。）

• 软件：你应该记录使用的 H2O-3 或 Sparkling Water 的版本。（此信息可以在日志文件中找到。）

• 数据：显然，你必须使用相同的输入数据。你应该保存所有在模型训练之前用于处理数据的脚本。所有数据列的修改都应记录在案（例如，如果你将数值列转换为分类列）。

• 设置: 保存 H2O 的日志和二进制模型。日志包含大量信息。更重要的是，二进制模型包含了 H2O 版本（软件）以及用于训练模型（设置）的参数。

摘要

在本章中，我们通过展示如何在 Spark 管道中使用 H2O 模型以及一个实际的情感分析建模示例，完善了我们的高级建模主题。我们总结了 H2O 中可用的无监督学习方法，并展示了如何使用隔离森林算法构建一个用于信用卡欺诈交易用例的异常检测模型。我们还回顾了如何更新模型，包括重新拟合与检查点之间的区别，并展示了确保模型可复现性的要求。

在 第七章，“理解机器学习模型”，我们讨论了理解和审查我们机器学习模型的方法。

第七章: 理解机器学习模型

现在我们已经使用 H2O 软件构建了一些模型，下一步在生产之前是理解模型是如何做出决策的。这被称作机器学习可解释性（MLI）、可解释人工智能（XAI）、模型可解释性等等。所有这些术语的核心是，仅仅构建一个预测效果好的模型是不够的。在完全信任模型之前部署任何模型都存在固有的风险。在本章中，我们概述了 H2O 中用于解释机器学习模型的一组功能。

到本章结束时，你将能够做到以下几件事情：

• 选择一个合适的模型度量标准来评估你的模型。

• 解释 Shapley 值是什么以及如何使用它们。

• 描述全局和局部可解释性的区别。

• 使用多种诊断工具来建立对模型的了解和信任。

• 使用全局和局部解释以及模型性能指标来从一组候选模型中选择最佳模型。

• 评估单个候选模型在预测性能、评分速度和满足的假设之间的权衡。

在本章中，我们将涵盖以下主要主题：

• 选择模型性能指标

• 解释在 H2O 中构建的模型（全局和局部）

• 通过 H2O AutoDoc 进行自动化的模型文档

选择模型性能指标

任何模型最相关的问题是，它的预测效果如何？ 无论模型可能拥有的其他积极属性如何，预测效果不佳的模型只是不太有用。如何最好地衡量预测性能既取决于要解决的问题的具体情况，也取决于数据科学家可用的选择。H2O 提供了多种测量模型性能的选项。

对于回归问题中的预测模型性能测量，H2O 提供了 R2、均方误差（MSE）、均方根误差（RMSE）、均方根对数误差（RMSLE）和平均绝对误差（MAE）作为指标。MSE 和 RMSE 是良好的默认选项，其中 RMSE 是我们的首选，因为该指标与预测的单位相同（而不是平方单位，如 MSE 的情况）。所有基于平方误差的指标通常对异常值敏感。如果需要鲁棒性以抵抗异常值，那么 MAE 是一个更好的选择。最后，RMSLE 在预测不足比预测过度更糟糕的特殊情况下是有用的。

对于分类模型，H2O 添加了基尼系数、绝对马修斯相关系数（MCC）、F1、F0.5、F2、准确率、Logloss、ROC 曲线下面积（AUC）、精确率-召回率曲线下面积（AUCPR）和科尔莫哥洛夫-斯米尔诺夫（KS）指标。根据我们的经验，AUC 是商业中最常用的指标。由于与商业伙伴和高级管理人员的沟通对数据科学家至关重要，我们建议在适用的情况下使用公认的指标。在 AUC 的情况下，当数据相对平衡时，它对二分类模型做得很好。对于不平衡数据，AUCPR 是更好的选择。

Logloss 指标基于信息理论，具有一些数学优势。特别是，如果你对类成员的预测概率本身感兴趣，而不仅仅是预测分类，那么 Logloss 是更好的指标选择。有关这些评分选项的更多文档可以在docs.h2o.ai/h2o/latest-stable/h2o-docs/performance-and-prediction.html找到。

为分类问题创建的 AutoML 排行榜包括 AUC、Logloss、AUCPR、每类平均误差、RMSE 和 MSE 作为性能指标。在第五章，高级模型构建 – 第一部分中创建的check AutoML 对象的排行榜如图 7.1 所示：

![Figure 7.1 – An AutoML leaderboard for the check object]

![img/B16721_07_01.jpg]

![Figure 7.1 – An AutoML leaderboard for the check object]

除了预测性能外，在企业环境中，模型性能的额外指标可能也很重要。在 AutoML 排行榜中默认包含的两个指标是拟合模型所需的时间（training_time_ms）和预测数据单行所需的时间（predict_time_per_row_ms）。

在图 7.1中，根据 AUC 和 Logloss 两个指标，最佳模型是所有模型的堆叠集成（顶部行中的模型）。这个模型在评分速度上比任何单个模型都要慢一个数量级。对于流式或实时应用来说，一个评分不够快的模型可能会自动被排除，无论其预测性能如何。

我们接下来讨论模型可解释性，以便理解和评估我们的机器学习模型。

解释 H2O 中构建的模型

在我们的测试数据上测量的模型性能指标可以告诉我们模型预测得有多好以及预测有多快。如章节引言中提到的，知道模型预测得很好并不是将其投入生产的充分理由。仅凭性能指标本身无法提供任何关于“为什么”模型会这样预测的见解。如果我们不理解模型预测得好的原因，我们几乎没有希望预测出会使模型表现不佳的条件。解释模型推理的能力是在将其推广到生产之前的一个关键步骤。这个过程可以描述为对模型建立信任。

可解释性通常分为全局和局部两个部分。全局可解释性描述了模型对整个种群的工作方式。对模型建立信任主要取决于确定其全局工作方式。局部解释则作用于单个行。它们解决的问题是，例如，一个个体预测是如何产生的。《h2o.explain》和《h2o.explain_row》方法分别捆绑了一组用于全局和局部解释的可解释性函数和可视化。

我们从沙普利值的简单介绍开始，这是模型可解释性中的基石方法之一，初次接触时可能会感到困惑。我们使用《h2o.explain》覆盖单个模型的全局解释，并使用《h2o.explain_row》进行局部可解释性。然后，我们使用《h2o.explain》处理 AutoML 的全局解释，我们用它来展示可解释性在模型选择中的作用。我们使用在第五章“高级模型构建 – 第一部分”中开发的两个模型来说明这些方法的输出，Advanced Model Building – Part 1。第一个，gbm，是一个使用默认值和 H2O check构建的个体基线模型。这些模型仅作为示例选择，承认原始基线模型通过多个特征工程和模型优化步骤得到了改进。

沙普利值的简单介绍

沙普利值已成为机器学习可解释性中的一个重要部分，作为将每个特征的贡献归因于整体或个体预测的手段。沙普利值在数学上优雅，非常适合归因任务。在本节中，我们提供了沙普利值的描述：它们的起源、计算以及如何用于解释。

洛伊德·沙普利（1923-2016），2012 年诺贝尔经济学奖获得者，于 1953 年推导出沙普利值，作为博弈论中特定问题的解决方案。假设一组玩家共同获得一项奖金。应该如何在玩家之间公平地分配这笔奖金？

Shapley 从定义公平性的数学公理开始：对称性（贡献相同数量的玩家获得相同的支付），虚拟玩家（没有贡献的玩家什么也得不到），和可加性（如果游戏可以分解为可加的部分，那么可以分解支付）。Shapley 值是满足这些公理的唯一数学解。简而言之，Shapley 值方法按玩家的边际贡献比例支付玩家。

我们接下来演示几个简单场景的 Shapley 值的计算。

Shapley 计算示例 – 两位玩家

为了说明 Shapley 值的计算，考虑以下简单的例子。两位音乐家约翰和保罗，各自单独表演可以赚得£4 和£3，分别。约翰和保罗一起表演可以赚得£10。他们应该如何分配这£10？

要计算他们的边际贡献，考虑这些玩家可以按何种方式排序。对于两位玩家，只有两种独特的排序：约翰先演奏，然后保罗加入，或者保罗先演奏，然后约翰加入。这已在图 7.2中展示：

![图 7.2 – 约翰和保罗的独特玩家序列

图 7.2 – 约翰和保罗的独特玩家序列

将其表示为独特玩家序列使我们能够计算每个玩家的 Shapley 值。我们在图 7.3中展示了约翰的 Shapley 值的计算：

![图 7.3 – 约翰的序列值

图 7.3 – 约翰的序列值

在序列 1 中，约翰是第一个出现的玩家，因此 Shapley 贡献只是边际价值v(J) = 4。在第二个序列中，约翰在保罗之后加入。约翰的边际价值是约翰和保罗的联合价值v(JP)减去保罗的边际价值v(P)。换句话说，10 – 3 = 7。约翰的 Shapley 值是每个序列值的平均值：S(J) = 11/2 = 5.5。因此，约翰应该从£10 的支付中获得£5.50。

保罗的 Shapley 值以类似的方式计算（显然，也可以通过减法计算）。序列计算在图 7.4中展示：

![图 7.4 – 保罗的序列值

图 7.4 – 保罗的序列值

在图 7.4的第一个序列中，保罗在约翰之后加入，因此序列值是联合的v(JP) = 10减去约翰的边际价值v(J) = 4。第二个序列只是保罗的边际价值：v(P)=3。保罗的 Shapley 值是S(P) = 9/2 = 4.5。

这些计算简单且合理，适用于两位玩家。让我们看看当我们添加第三位玩家时会发生什么。

Shapley 计算示例 – 三位玩家

假设第三位音乐家乔治加入约翰和保罗。乔治自己赚得£2，与约翰合作表演赚得£7，与保罗合作表演赚得£9，当三人一起表演时赚得£20。为了清晰起见，我们在图 7.5中总结了收入：

图 7.5 – 约翰、保罗和乔治的收益

因为有三个玩家，所以约翰、保罗和乔治可以到达的 6 个独特的序列中，有 3! = 6 个。在这个三玩家场景中，计算约翰 Shapley 值的计算总结在图 7.6中：

图 7.6 – 计算约翰 Shapley 值的到达序列和值

在图 7.6中，序列 1 和 2 很简单：约翰是第一个玩家，所以只需要v(J)值。在序列 3 和 5 中，约翰是第二个玩家。序列值是通过计算约翰和第一个玩家的联合值，然后减去该玩家的边际值来计算的。序列 4 和 6 是相同的：约翰是最后一个玩家。他的边际贡献是通过计算三方交互v(JPG)，然后减去保罗和乔治的联合值v(PG)来计算的。Shapley 值为S(J) = 42/6 = 7。

我们可以继续以同样的方式找到保罗和乔治的 Shapley 值。

计算 N 个玩家的 Shapley 值

如您所见，随着玩家数量 N 的增加，Shapley 值计算可以迅速变得令人难以承受。Shapley 序列计算依赖于知道主要效应和从双向到 N 向的所有交互的值，如图 7.5 所示。此外，还有N!个序列需要解决。随着玩家数量的增加，计算任务显著增加。

在预测模型的背景下，每个特征都是一个玩家，预测是共享的奖品。我们可以使用 Shapley 值来分配每个特征对最终预测的影响。一些模型可能有数十个、数百个甚至更多的特征，因此在现实世界中计算 Shapley 值并非易事。幸运的是，现代计算和计算某些模型族 Shapley 值的数学捷径的组合使得 Shapley 计算可行。

不论是我们在示例中展示的简单例子，还是大型复杂的机器学习模型，Shapley 值的解释都是相同的。

我们接下来关注单个模型的全球解释。

单个模型的全球解释

我们使用第五章中构建的基线 GBM 模型来说明单个模型解释，该模型在第五章（B16721_05_Final_SK_ePub.xhtml#_idTextAnchor082）中介绍，高级模型构建 – 第一部分。我们将其标记为gbm，并在图 5.5至图 5.10中记录了其性能。

全局解释的基本命令如下：

model_object.explain(test)

在这里，test 是用于模型评估的保留测试数据集。其他可选参数包括以下内容：

• top_n_features：一个整数，表示在基于列的方法（如5）中要使用多少列。

• columns：一个列名向量，用于基于列的方法，作为 top_n_features 的替代。

• include_explanations 或 exclude_explanations：分别表示包含或排除如 confusion_matrix、varimp、shap_summary 或 pdp 等方法。

对于单个分类模型如 gbm，此命令将显示混淆矩阵、变量重要性图、SHAP 概述图和部分依赖图，按重要性顺序显示前五个变量。

我们使用 gbm 模型和 gbm.explain(test) 命令来演示这一点，并依次讨论每个显示结果。

混淆矩阵

第一个输出结果是混淆矩阵，如图 7.7 所示：

图 7.7 – GBM 基线模型的混淆矩阵

explain 方法的优点之一是每个显示都提供了简单的总结描述：gbm 显示真实负例（17,616），假阳性（2,087），假阴性（1,716），和真实正例（2,057），以及假阳性率（10.59%）和假阴性率（45.48%）。

变量重要性图

explain 方法的第二个可视化结果是变量重要性图，如图 7.8 所示：

图 7.8 – GBM 基线模型的变量重要性图

注意，图 7.8 中的变量重要性图与我们在图 5.10 中手动使用 varimp_plot 命令创建的图表相同。它的包含是使用 explain 方法的一个好处。

SHAP 概述图

explain 方法输出的第三个可视化结果是 SHAP 概述图。SHAP，基于 Shapley 值，为黑盒模型提供了一个信息丰富的视角。GBM 基线模型的 SHAP 概述图如图 7.9 所示：

图 7.9 – GBM 基线模型的 SHAP 概述图

让我们更详细地解释图 7.9 中的 SHAP 概述图。在这个信息丰富的图表中有很多内容：

• 在左侧，我们按 Shapley 值递减的顺序列出了特征（数据列）。(注意，Shapley 特征重要性排名不一定与图 7.8 中的特征重要性相同。)

• 在右侧，我们有一个从 0.0 到 1.0（蓝色到红色，由 H2O 输出）的归一化特征值刻度。换句话说，对于每个特征，我们通过颜色编码原始数据值：低原始值用蓝色表示，过渡到紫色表示中等值，最后用红色表示高原始值（在本图中它们显示为不同灰度的阴影）。

• 每个观察值的水平位置由其 SHAP 值决定。SHAP 值衡量每个特征对预测的贡献。较低的 SHAP 值与较低的预测相关联，而较高的值与较高的预测相关联。

在有了这个初步理解之后，我们可以做出以下观察：

• 具有右侧红色值和左侧蓝色值的特征与响应呈正相关。由于我们正在建模不良贷款的概率，因此像较长期限（term）或较高循环利用率（revol_util）这样的特征与贷款违约呈正相关。（循环信用利用率基本上是客户每月信用卡余额的大小。）

• 左侧红色值和右侧蓝色值的特征与响应呈负相关。因此，例如，更高的年收入（annual_inc）与贷款违约呈负相关。

这些来自 SHAP 摘要图模型的观察结果具有直观的意义。你可能会预期，持有更大信用卡余额或年收入较低的人有更高的贷款违约概率。

注意，我们可以使用gbm.shap_summary_plot(test)命令得到相同的图。

部分依赖性图

explain输出的第四个可视化结果是部分依赖性图的一组。具体显示的图取决于top_n_features或columns可选参数。默认情况下，按变量重要性递减的顺序显示前五个特征。图 7.10显示了地址状态的部分依赖性图：

![图 7.10 – 地址状态的部分依赖性图]

![img/B16721_07_10.jpg]

图 7.10 – 地址状态的部分依赖性图

图 7.11显示了循环利用率变量的部分依赖性图：

![图 7.11 – 循环利用率的部分依赖性图]

![img/B16721_07_11.jpg]

图 7.11 – 循环利用率的部分依赖性图

explain生成的部分依赖性图包括样本大小（从图表底部开始的阴影区域）的表示，以及均值响应及其变异性（被阴影区域包围的线）。在分类变量的情况下，均值响应是一个带有表示变异性的条形图的点，如图7.10所示。在数值变量的情况下，均值响应是一条深色线，较浅的阴影表示变异性，如图7.11所示。

注意，我们可以使用以下方法为任何单个列创建部分依赖性图：

gbm.pd_plot(test, column='revol_util')

全局个体条件期望（ICE）图

ICE 图将在“单个模型的局部解释”部分后面介绍。然而，为了完整性，我们在此包括一个全局版本的 ICE 图。请注意，此图不是由explain生成的。gbm.ice_plot(test, column='revol_util')命令返回一个全局 ICE 图，如图7.12所示：

图 7.12 – 全球 ICE 利用率图

变量的全局 ICE 图是该变量的部分依赖图的扩展。部分依赖图显示均值响应与特定变量的值之间的关系。阴影，如 图 7.11 所示，表示部分依赖线的可变性。全局 ICE 图通过使用多条线来表示总体来放大这一点。（在分类变量的情况下，线被点替换，阴影被条形图替换。）

如 图 7.12 所示，全局 ICE 图包括最小值（0 百分位）、十分位数（10 百分位至 90 百分位，每 10 个百分位一个），最大值（100 百分位）以及部分依赖本身。这比单独的部分依赖图更准确地描绘了总体。与部分依赖线平行的百分位数对应于部分依赖是良好代表的总体部分。通常情况下，总体最小值和最大值的行为可能与部分依赖线描述的均值行为大不相同。在 图 7.12 中，有三条与其他不同的线：最小值、最大值和 10 百分位。

我们接下来关注单个模型的局部解释。

单个模型的局部解释

h2o.explain_row 方法允许数据科学家调查模型的局部解释。虽然全局解释用于理解模型如何代表总体，但局部解释使我们能够逐行询问模型。这在业务中尤为重要，因为行代表客户，正如我们在 Lending Club 分析中所做的那样。

当预测模型被用来做出直接影响客户决策（例如，不批准贷款申请或提高客户的保险费率）时，全局解释不足以满足业务、法律或监管要求。这正是局部解释至关重要的地方。

explain_row 方法返回指定 row_index 值的这些局部解释。gbm.explain_row(test, row_index=10) 命令提供了一个基于变量重要性的 SHAP 解释图和多个 ICE 图。与部分依赖图一样，可以提供可选的 top_n_features 或 columns 参数。

结果的 SHAP 解释图显示在 图 7.13 中：

图 7.13 – 指数 = 10 的 SHAP 解释

SHAP 解释显示了每个变量对基于 Shapley 值的整体预测的贡献。对于 图 7.13 中显示的客户，正的 SHAP 值可以被认为是增加了贷款违约的概率，而负的 SHAP 值是那些降低违约概率的值。对于这位客户，78.5% 的循环利用率是预测概率的最大正贡献者。最大的负贡献者是年收入 90,000，它比其他任何变量都更能降低贷款违约的概率。SHAP 解释可以用来提供 原因代码，这有助于解释模型。原因代码还可以作为与客户直接分享信息的基础，例如，在适用于某些金融和保险相关监管模型的负面行动代码中。

我们接下来查看 explain_row 方法输出的某些 ICE 图。

ICE 图的局部解释

ICE 图是部分依赖图的个体或每行对应图。就像特征的部分依赖图显示目标变量的平均响应，同时改变特征值一样，ICE 图在改变单行特征值的同时测量目标变量的响应。以 图 7.14 中显示的地址状态的 ICE 图为例，这是 gbm.explain_row 调用的结果：

图 7.14 – 地址状态的 ICE 图

图 7.14 中的垂直暗虚线代表所讨论行的实际响应。在这种情况下，状态是 NJ（新泽西州）响应约为 0.10。如果这一行的状态是 VA（弗吉尼亚州），响应会较低（大约 0.07）。如果这一行的状态是 NV（内华达州），响应会更高，大约 0.16。

考虑下一个 图 7.15，贷款期限的 ICE 图：

图 7.15 – 贷款期限的 ICE 图

图 7.13 中对于 36 个月期限的 SHAP 解释值是第二大负因素（它在年收入之后，年收入是最大的，它降低了贷款违约的概率）。根据 图 7.15，60 个月的贷款期限会导致略高于 0.35 的违约概率，这比 36 个月期限的大约 0.10 的违约概率显著更高。虽然 SHAP 解释和 ICE 图测量的是两件不同的事情，但它们的解释可以联合使用来理解特定预测的行为。

我们考虑的最后一张 ICE 图是关于旋转利用率的，这是一个数值特征而不是分类特征。这张图显示在 图 7.16 中：

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/ml-scl-h2o/img/B16721_07_14.jpg)

图 7.16 – 旋转利用率的 ICE 图

根据图 7.13 中的 SHAP 解释，循环利用率是影响最大的积极因素（增加贷款违约的概率）。图 7.16 中的 ICE 图显示了响应与循环利用率值之间的关系。如果revol_util为 50%，贷款违约的概率将降低到大约 0.08。如果为 20%，违约概率将约为 0.05。如果这位客户被拒绝贷款，循环利用率的高值将是一个可辩护的理由。相应的 ICE 图的结果可以用来告知客户他们可以采取哪些步骤来获得贷款资格。

多个模型的全球解释

在确定要将哪个模型推广到生产中时，例如从 AutoML 运行中，数据科学家可以完全依赖预测模型指标。这可能意味着简单地推广 AUC 值最好的模型。然而，有很多信息可以帮助做出这个决定，其中预测能力只是多个标准中的一个。

H2O 的全局和局部解释特征提供了额外的信息，这些信息对于与预测属性一起评估模型非常有用。我们使用来自第五章，“高级模型构建 – 第一部分”的check AutoML 对象来演示它。

启动多个模型的全球解释的代码非常简单，如下所示：

check.explain(test)

这将产生变量重要性热图、模型相关性热图和多个模型的局部依赖性图。我们将依次回顾这些内容。

变量重要性热图

变量重要性热图通过添加颜色作为维度，将多个模型的变量重要性图进行视觉组合，以便与变量（作为行）和模型（作为列）一起查看。check.explain生成的变量重要性热图如图 7.17 所示：

![Figure 7.17 – AutoML 对象的变量重要性热图

Figure 7.17 – AutoML 对象的变量重要性热图

变量重要性值被编码为从蓝色（冷色）到红色（暖色）的颜色连续体，代表低值到高值。生成的图形具有视觉意义。在图 7.17 中，垂直带对应于每个模型，水平带对应于单个特征。相似的垂直带表明模型使用其特征的方式之间存在高度相关性。例如，XGBoost_1和XGBoost_2模型（最后两列）显示出相似的图案。

你还可以看到类似颜色的水平带，例如delinq_2yrs、verification_status或在一定程度上，annual_inc。这表明所有候选模型都对这些变量给予了相当的重要性。最后一行的term变量在视觉上最为突出，因为其在不同模型中是异质的。这些模型对其绝对重要性的看法并不一致。然而，你必须小心不要过度解读这一点。注意，对于term，六个模型中的十个模型（除了蓝色方块：DRF_1、GBM_4、XGBoost_2和XGBoost_1）的相对重要性是相同的。对于这六个模型，term是最重要的特征，尽管其确切值变化很大。

创建此显示的直接代码如下：

check.varimp_heatmap()

接下来，让我们考虑模型相关性热图。

模型相关性热图

变量重要性热图使我们能够比较多个模型在如何查看和使用其组件变量方面的差异。模型相关性热图则回答了不同的问题：这些不同模型的预测结果之间有多少相关性？ 为了回答这个问题，我们转向图 7.18中的模型相关性热图：

![图 7.18 – AutoML 对象的模型相关性热图

图 7.18 – AutoML 对象的模型相关性热图

图 7.18对角线上的最深色块显示了一个模型与其自身之间的完美相关性。依次变浅的阴影描述了模型之间的相关性逐渐降低。你如何使用这种显示来确定哪个模型可以提升到生产环境？

这就是商业或监管约束可能发挥作用的地方。在我们的例子中，StackedEnsemble_AllModels在 AUC 方面表现最佳。假设我们因任何原因不允许将集成模型提升到生产环境。与我们最佳模型高度相关的单个模型包括XGBoost_3、GBM_5和GLM_1。这些可以成为提升到生产环境的候选者，最终决定基于额外的标准（可能是测试集上的 AUC 值）。

如果这些额外标准之一是原生可解释性，那么对于这个 AutoML 对象，GLM_1是唯一的选择。请注意，在模型相关性热图中，可解释的模型用红色字体表示。

我们可以直接使用以下代码创建此显示：

check.model_correlation_heatmap(test)

让我们继续介绍下一小节中多个模型的部分依赖图。

多模型部分依赖图

多模型explain方法的第三个输出是部分依赖图的扩展。对于分类变量，每个图上显示与不同模型对应的符号和颜色。图 7.19是使用term变量的一个示例：

![图 7.19 – 贷款期限的多模型部分依赖图

图 7.19 – 贷款期限的多模型部分依赖图

对于数值变量，多个模型在同一部分依赖图上用不同颜色的线条表示。图 7.20是使用revol_util变量示例：

![图 7.20 – 旋转利用率的多模型部分依赖图]

![img/B16721_07_20.jpg]

图 7.20 – 多模型旋转利用率的部分依赖图

在图 7.19和图 7.20中，竞争模型产生了非常相似的结果。这并不总是如此。例如，图 7.21显示了年收入的多模型部分依赖图：

![图 7.21 – 年收入的多模型部分依赖图]

![img/B16721_07_21.jpg]

图 7.21 – 多模型年收入的部分依赖图

尽管图 7.21中的大多数模型在低收入时相似，但随着收入的增加，它们差异很大。这部分是由于年收入分布尾部的样本量非常小。数据科学家也可能基于不切实际或不合理的尾部行为决定取消某些模型的资格。例如，根据我们的经验，随着年收入增加，贷款违约风险增加是没有意义的。最坏的情况是，我们预计收入和违约之间在某个点之后没有关系。我们更有可能预计随着收入的增加，贷款违约将单调递减。基于这个推理，我们会从考虑中移除顶部两条线（DRF_1和GBM_1）的模型。

与其他explain方法一样，我们可以直接使用以下命令创建此图：

check.pd_multi_plot(test, column='annual_inc')

我们接下来访问模型文档。

自动化模型文档（H2O AutoDoc）

在企业环境中，数据科学团队的一个重要角色是记录投入生产的模型的历史、属性和性能。至少，模型文档应该是数据科学团队最佳实践的一部分。在企业环境中，通常需要详尽的模型文档或白皮书，以满足内部和外部控制以及监管或合规要求。

通常，模型文档应该足够全面，以便能够重新创建所记录的模型。这包括识别所有数据源，包括训练和测试数据特征，指定硬件系统组件，记录软件版本，建模代码，软件设置和种子，采用的建模假设，考虑的替代模型，性能指标和适当的诊断，以及基于业务或监管条件所需的其他任何内容。虽然这个过程至关重要，但耗时且可能繁琐。

H2O AutoDoc 是一款商业软件产品，可以自动为在 H2O-3 和 scikit-learn 中构建的模型创建全面的文档。在 H2O.ai 的Driverless AI中，也存在类似的功能，这是一款结合了自动特征工程和增强 AutoML 的商业产品，用于构建和部署监督学习模型。AutoDoc 已被成功用于记录现在投入生产的模型。在此，我们简要介绍了使用 AutoDoc 自动创建文档的方法：

1. 在创建模型对象之后，我们将Config和render_autodoc模块导入 Python：

   from h2o_autodoc import Config
   from h2o_autodoc import render_autodoc
   

2. 接下来，我们将指定输出文件路径：

   config = Config(output_path = "autodoc_report.docx")
   

3. 然后，我们将通过传递配置信息和模型对象来渲染报告：

   doc_path = render_autodoc(h2o=h2o, config=config,
                             model=gbm)
   

4. 报告创建后，可以使用以下方式指示报告的位置：

   print(doc_path)
   

图 7.22 展示了由 H2O AutoDoc 在 Microsoft Word 中创建的 44 页报告的目录：

图 7.22 – 由 H2O AutoDoc 创建的模型文档目录

以最少的手动努力以一致的方式生成的详尽文档的优势是显而易见的。输出可以是 Microsoft Word 文档或 Markdown 格式，报告可以单独编辑和进一步定制。报告模板也易于编辑，允许数据科学团队根据不同的用途拥有不同的报告结构：例如，内部白皮书或用于监管审查的报告。AutoDoc 功能一直是 H2O 企业软件最受欢迎的功能之一。

摘要

在本章中，我们回顾了多个模型性能指标，并学习了如何选择一个用于评估模型预测性能的指标。我们通过一些简单的例子介绍了 Shapley 值，以进一步了解它们在预测模型评估中的目的和使用。在 H2O 中，我们使用了explain和explain_row命令为单个模型创建全局和局部解释。我们学习了如何解释生成的诊断和可视化结果，以增强对模型的信任。对于 AutoML 对象和其他模型列表，我们生成了全局和局部解释，并展示了如何将它们与模型性能指标一起使用，以筛选掉不合适的候选模型。综合以上内容，我们现在可以评估模型性能、评分速度和解释之间的权衡，以确定哪个模型可以投入生产。最后，我们讨论了模型文档的重要性，并展示了 H2O AutoDoc 如何自动为在 H2O（或 scikit-learn）中构建的任何模型生成详细的文档。

在下一章中，我们将把我们在 H2O 中构建和评估模型所学的所有内容结合起来，为 Lending Club 数据预测不良贷款创建一个部署就绪的模型。

第八章：整合一切

在本章中，我们将回顾我们在第三章和基本工作流程 – 数据到可部署模型中首次介绍的Lending Club 贷款申请数据。这次，我们以大多数数据科学项目的方式开始，即从一个原始数据文件和一个一般目标或问题开始。在这个过程中，我们将细化数据和问题陈述，使其与业务相关，并且可以用可用数据回答。数据科学家很少从建模准备好的数据开始；因此，本章的处理更准确地反映了企业中数据科学家的工作。然后我们将对数据进行建模，评估各种候选模型，并根据需要更新它们，直到我们得到一个最终模型。我们将评估最终模型并说明模型部署所需的准备步骤。这加强了我们从第五章到第七章中介绍的内容。

到本章结束时，您将能够处理一个具有原始数据源的未结构化问题，并创建一个可部署的模型来回答一个精细的预测问题。为了完整性，我们将包括完成每个步骤（数据准备、特征工程、模型构建和评估）所需的全部代码。一般来说，任何在第五章到第七章中已经介绍过的代码都将保留注释。

本章分为四个部分，每个部分都有单独的步骤。部分列表如下：

• 数据整理

• 特征工程

• 模型构建和评估

• 模型管道部署准备

技术要求

如果您在此阶段尚未设置您的 H2O 环境，请参阅附录 – 启动 H2O 集群的替代方法。

数据整理

经常有人说，数据科学家的工作中有 80-90%是处理数据。至少，您应该了解数据的粒度（即行代表什么）以及了解数据集中每一列的含义。面对原始数据源时，需要多个步骤来清理、组织和转换您的数据，使其成为建模准备好的数据集格式。

在第三章、第五章和第七章中使用的Lending Club示例数据集是从我们在这里开始的原始数据文件中派生出来的。在本节中，我们将说明以下步骤：

1. 导入原始数据并确定要保留的列。

2. 定义问题，并创建响应变量。

3. 将字符串中的隐含数值数据转换为数值。

4. 清理任何混乱的分类列。

让我们从第一步开始：导入数据。

导入原始数据

我们使用以下代码导入原始数据文件：

input_csv = "rawloans.csv"

loans = h2o.import_file(input_csv,

             col_types = {"int_rate": "string",

                          "revol_util": "string",

                          "emp_length": "string",

                          "verification_status": "string"})

在h2o.import_file代码中的字典指定了四个输入变量的输入列类型为string：int_rate、revol_util、emp_length和verification_status。明确指定列类型可以确保列以建模者期望的方式读取。如果没有此代码，这些字符串变量可能被读取为具有多个级别的分类列。

数据集的维度是通过以下命令获得的：

loans.dim

这返回了 42,536 行（对应 42,536 个客户信用申请）和 52 列。接下来，我们指定我们希望保留用于分析的 22 列：

keep = ['addr_state', 'annual_inc', 'delinq_2yrs',

        'dti', 'earliest_cr_line', 'emp_length', 'grade',

        'home_ownership', 'inq_last_6mths', 'installment',

        'issue_d', 'loan_amnt', 'loan_status',

        'mths_since_last_delinq', 'open_acc', 'pub_rec',

        'purpose', 'revol_bal', 'revol_util', 'term',

        'total_acc', 'verification_status']

我们想使用drop方法删除剩余的列：

remove = list(set(loans.columns) - set(keep))

loans = loans.drop(remove)

但是，我们删除的 30 列包含了一些内容，例如贷款目的的文本描述、地址或邮编等额外客户信息、几乎完全缺失信息的列或其他数据质量问题等。从原始数据源中选择适当的列是数据科学家需要花费大量时间和精力的重要任务。

我们保留的列是我们认为最有可能是预测性的列。每个列的解释如下：

• addr_state: 这是借款人居住的美国州。

• annual_inc: 这是借款人自行报告的年收入。

• delinq_2yrs: 这是借款人在过去两年内超过 30 天未付款的次数。

• dti: 这是债务收入比（当前债务除以收入）。

• earliest_cr_line: 这是最早信用额度的日期（通常，较长的信用历史与更好的信用风险相关）。

• emp_length: 这是就业年限。

• grade: 这是贷款人根据 A 到 G 的风险评级分配给贷款的评级。

• home_ownership: 借款人拥有房产还是租房？

• inq_last_6mths: 这是过去 6 个月内的信用查询次数。

• installment: 这是借款人每月应还的金额。

• issue_d: 这是贷款发放的日期。

• loan_amnt: 这是借给借款人的总金额。

• loan_status: 这是一个类别。

• mths_since_last_delinq: 这是自上次违约以来月份的数量。

• open_acc: 这是开放的信用额度数量。

• pub_rec: 这是负面公共记录（破产、税收留置权和判决）的数量。

• purpose: 这是借款人声明的贷款目的。

• revol_bal: 这是循环余额（即在账单周期结束时信用卡上的欠款金额）。

• revol_util: 这是循环利用率（即使用的信用额度除以借款人可用的总信用额度）。

• term: 这是贷款在月份中的付款次数（要么是 36 个月，要么是 60 个月）。

• total_acct: 这是借款人的总信用额度数量。

• verification_status：这告诉我们收入是否经过验证。

假设我们的数据列已经被正确选择，我们可以继续下一步：创建响应变量。

定义问题和创建响应变量

响应变量的创建取决于问题定义。本用例的目标是预测哪些客户会违约。预测贷款违约的模型需要一个区分良好和不良贷款的响应变量。让我们首先使用以下代码调查loan_status变量：

loans["loan_status"].table().head(20)

这将生成一个表格，其中存储了我们数据中贷款状态的所有可能值：

![图 8.1 – 从原始 Lending Club 贷款违约数据集中提取的贷款状态类别]

![img/B16721_08_001.jpg]

图 8.1 – 从原始 Lending Club 贷款违约数据集中提取的贷款状态类别

如图 8.1所示，loan_status变量相对复杂，包含 11 个类别，有些是重复的或重叠的。例如，Charged Off表示有 5,435 笔贷款是坏账。Default包含另外 7 笔。Fully Paid表明有 30,843 笔贷款是好的。一些贷款，例如由Current或Late类别指示的贷款，仍然是持续的，因此尚未是好或坏。

提供了多个不符合信贷政策的贷款。为什么允许这种情况尚不清楚，值得与数据源核实。信贷政策是否改变，使得这些贷款属于更早的批次？这些是正式的覆盖还是意外的？无论情况如何，这些类别都暗示了一个可能需要我们关注的潜在不同群体。我们应该完全删除这些贷款，将问题忽略并合并到相应的类别中，还是创建一个符合信贷政策的指标变量并直接对它们进行建模？对数据的更好理解将允许数据科学家做出明智的决定。

最后，我们需要一个基于已偿还或违约的贷款群体的二元响应变量。首先，过滤掉任何持续贷款。

移除持续贷款

我们需要构建一个只包含已违约或已全额偿还的贷款的模型。持续贷款的loan_status有如Current或In Grace Period等状态。以下代码捕获了那些状态指示持续贷款的行：

ongoing_status = [

    "Current",

    "In Grace Period",

    "Late (16-30 days)",

    "Late (31-120 days)",

    "Does not meet the credit policy.  Status:Current",

    "Does not meet the credit policy.  Status:In Grace Period"

]

我们使用以下代码来移除这些持续贷款并显示剩余贷款的状态：

loans = loans[~loans["loan_status"].isin(ongoing_status)]

loans["loan_status"].table()

结果状态类别显示在图 8.2中：

![图 8.2 – 过滤后的持续贷款的贷款状态类别]

![img/B16721_08_002.jpg]

图 8.2 – 过滤后的持续贷款的贷款状态类别

注意，在图 8.2中，现在需要将五个贷款状态类别总结成一个二元响应变量。这将在下一步中详细说明。

定义二元响应变量

我们首先创建一个fully_paid列表来总结贷款状态类别：

fully_paid = [

    "Fully Paid",

    "Does not meet the credit policy.  Status:Fully Paid"

]

接下来，让我们创建一个二进制响应列，bad_loan，作为任何未完全偿还的贷款的指示符：

response = "bad_loan"

loans[response] = ~(loans["loan_status"].isin(fully_paid))

loans[response] = loans[response].asfactor()

最后，移除原始贷款状态列：

loans = loans.drop("loan_status")

我们移除了原始的贷款状态列，因为构建我们的预测模型所需的信息现在包含在bad_loan响应变量中。

接下来，我们将字符串数据转换为数值。

将字符串中的隐含数值数据转换为数值

数据可能以各种方式变得混乱。在上一个步骤中，我们看到了变量有时可能包含冗余类别，这些类别可能从汇总中受益。数据值显示和存储的格式也可能引起问题。因此，我们自然解释为数字的 28%，通常是由计算机以字符字符串的形式输入的。将隐含的数值数据转换为实际数值数据是一个非常典型的数据质量任务。

考虑revol_util和emp_length列：

loans[["revol_util", "emp_length"]].head()

输出显示在下图中：

![图 8.3 – 存储为字符串并需要转换为数值的变量]

![图片 B16721_08_003.jpg]

图 8.3 – 存储为字符串并需要转换为数值的变量

如图 8.3所示，revol_util变量本质上是数值型的，但有一个尾随的百分号。在这种情况下，解决方案很简单：移除%符号并将字符串转换为数值。这可以通过以下代码完成：

x = "revol_util"

loans[x] = loans[x].gsub(pattern="%", replacement="")

loans[x] = loans[x].trim()

loans[x] = loans[x].asnumeric()

gsub方法将%替换为空格。trim方法移除字符串中的任何空白字符。asnumeric方法将字符串值转换为数字。

emp_length列稍微复杂一些。首先，我们需要移除year或years术语。此外，我们必须处理<和+符号。如果我们定义< 1为0和10+为10，那么emp_length也可以转换为数值。这可以通过以下代码完成：

x = "emp_length"

loans[x] = loans[x].gsub(pattern="([ ]*+[a-zA-Z].*)|(n/a)", 

                         replacement="") 

loans[x] = loans[x].trim()

loans[x] = loans[x].gsub(pattern="< 1", replacement="0")

loans[x] = loans[x].gsub(pattern="10\\+", replacement="10") 

loans[x] = loans[x].asnumeric()

接下来，我们将通过清理任何混乱的分类列来完成我们的数据整理步骤。

清理混乱的分类列

准备特征工程和建模的最后一步是明确通常混乱的分类列中的选项或级别。这个标准化任务通过verification_status变量来说明。使用以下代码查找verification_status的级别：

loans["verification_status"].head()

结果显示在图 8.4中：

![图 8.4 – 原始数据中的验证状态类别]

![图片 B16721_08_004.jpg]

图 8.4 – 原始数据中的验证状态类别

因为图 8.4中有多个值表示已验证（VERIFIED - income和VERIFIED - income source），我们只需将它们替换为verified。以下代码使用sub方法进行简单替换：

x = "verification_status"

loans[x] = loans[x].sub(pattern = "VERIFIED - income source",

                        replacement = "verified")

loans[x] = loans[x].sub(pattern = "VERIFIED - income",

                        replacement = "verified")

loans[x] = loans[x].asfactor()

在完成所有数据整理步骤后，我们将继续进行特征工程。

特征工程

在 第五章，高级模型构建 – 第一部分 中，我们介绍了一些特征工程概念，并详细讨论了目标编码。在本节中，我们将更深入地探讨特征工程。我们可以这样组织特征工程：

• 代数变换

• 从日期中构建的特征

• 通过合并类别简化分类变量

• 缺失值指示函数

• 目标编码分类列

这些变换的顺序并不重要，除了最后一个。目标编码是唯一需要将数据分为训练集和测试集的变换。通过将其留到最后，我们可以一次性将其他变换应用于整个数据集，而不是分别应用于训练集和测试集。此外，我们在 H2O-3 中引入了分层抽样来分割数据。这对我们当前的使用案例影响很小，但在数据高度不平衡的情况下，例如在欺诈建模中，这很重要。

在以下章节中，我们将为了完整性包括所有我们的特征工程代码。之前引入的代码将仅被引用，而新的特征工程任务将值得讨论。让我们从代数变换开始。

代数变换

最直接的特征工程形式是对原始数据列进行简单的变换：对数、平方、平方根、列之间的差异、列之间的比率等等。通常，这些变换的灵感来自于底层理论或基于主题领域专业知识。

在 第五章，高级模型构建 – 第一部分 中定义的 credit_length 变量就是这样一种变换。回想一下，这是通过以下代码创建的：

loans["credit_length"] = loans["issue_d"].year() - \

    loans["earliest_cr_line"].year()

这个变量的合理性基于一个业务观察：信用历史较长的客户往往违约风险较低。此外，我们删除了 earliest_cr_line 变量，因为它不再需要：

loans = loans.drop(["earliest_cr_line"])

另一个我们可以尝试的简单特征是 (年收入)/(信用额度数量)，取对数以实现分布和数值的稳定性。让我们称它为 log_inc_per_acct。这个比率具有直观的意义：收入更高的应该能够支持更多的信用额度。这与债务收入比在意图上相似，但捕捉到略微不同的信息。我们可以这样编码：

x = "log_inc_per_acct"

loans[x] = loans['annual_inc'].log() - \

    loans['total_acc'].log()

接下来，我们将考虑第二个特征工程任务：从日期中编码信息。

从日期中构建的特征

如第五章中所述，高级模型构建 – 第一部分，日期值中包含大量潜在预测信息。在我们之前创建的issue_d_year和issue_d_month特征基础上，我们添加了issue_d_dayOfWeek和issue_d_weekend作为新的因素。执行此操作的代码如下：

x = "issue_d"

loans[x + "_year"] = loans[x].year()

loans[x + "_month"] = loans[x].month().asfactor()

loans[x + "_dayOfWeek"] = loans[x].dayOfWeek().asfactor()

weekend = ["Sat", "Sun"]

loans[x + "_weekend"] = loans[x + "_dayOfWeek"].isin(weekend)

loans[x + "_weekend"] = loans[x + "_weekend"].asfactor()

最后，我们删除原始日期变量：

loans = loans.drop(x)

接下来，我们将讨论如何在特征工程阶段简化分类变量。

通过合并类别简化分类变量

在数据整理阶段，我们对verification_status列的混乱分类级别进行了清理，删除了冗余或重叠的级别定义，并使类别相互排斥。另一方面，在特征工程阶段，类别级别已经是非重叠且仔细定义的。数据值本身，例如某些类别的计数较小，可能表明一些工程方法来改进预测建模。

使用以下代码总结home_ownership分类变量：

x = "home_ownership"

loans[x].table()

表格结果如下所示：

![图 8.5 – 原始 homeownership 变量的级别

![img/B16721_08_005.jpg]

图 8.5 – 原始 homeownership 变量的级别

在图 8.5中，尽管在 home ownership 中有五个记录的类别，但最大的三个类别有数千个观测值：MORTGAGE、OWN和RENT。其余两个，NONE和OTHER，非常罕见（分别为 8 和 135），因此我们将它们与OWN合并，以创建一个扩展的OTHER类别。

合并数据类别

根据我们想要进行的推断或对问题的理解，将NONE和OTHER合并到RENT或MORTGAGE类别中可能更有意义。

合并分类级别的过程如下所示：

loans[x].levels()

这通过用OTHER替换NONE和OWN级别描述，并将其分配给一个新的变量home_3cat来实现，如下面的代码所示：

lvls = ["MORTGAGE", "OTHER", "OTHER", "OTHER", "RENT"]

loans["home_3cat"] = \

    loans[x].set_levels(lvls).ascharacter().asfactor()

然后，我们删除原始的home_ownership列：

loans = loans.drop(x)

接下来，我们将探讨如何创建有用的缺失数据指示函数。

缺失值指示函数

当数据不是随机缺失时，缺失模式的模式可能是一个预测信息的来源。换句话说，有时，一个值缺失的事实与实际值本身一样重要，甚至更重要。特别是在缺失值大量存在的情况下，创建一个缺失值指示函数可能很有帮助。

就业长度emp_length最有趣的特征是客户的值是否缺失。简单的交叉表显示，对于缺失emp_length值的客户，不良贷款的比例为 26.3%，而对于非缺失值，比例为 18.0%。这种违约率差异表明使用缺失值指示函数作为预测因子是有用的。

为emp_length变量创建缺失指示函数的代码很简单：

loans["emp_length_missing"] = loans["emp_length"] == None

在这里，新的emp_length_missing列包含指示函数。与之前我们构建的其他特征不同，原始的emp_length列不需要作为可能的预测因子而被删除。

接下来，我们将转向对分类列进行目标编码。

对分类列进行目标编码

在第五章，高级模型构建 – 第一部分中，我们详细介绍了 H2O-3 中的目标编码。作为目标编码的先决条件，请记住需要一个训练集和测试集。我们使用与以下类似的代码使用split_frame方法分割数据：

train, test = loans.split_frame(ratios = [0.8], seed = 12345)

split_frame方法创建一个完全随机的样本分割。这种方法对所有回归模型都是必需的，并且对于相对平衡的分类问题效果良好。然而，当二分类高度不平衡时，应使用分层抽样。

对二分类数据分割进行分层抽样

对二分类进行分层抽样是通过分别抽样好的贷款和坏的贷款来实现的。换句话说，请记住，我们 Lending Club 数据集中的 16%的贷款是坏的。我们希望将数据分割成 80%的训练集和 20%的测试集。如果我们分别抽样 20%的坏贷款和 20%的好贷款然后合并它们，我们将得到一个测试集，它保留了 16%的坏贷款百分比。将剩余的数据合并在一起，我们的训练数据中将有 16%的坏贷款百分比。因此，分层抽样保留了原始类别比率。

我们在响应列上使用stratified_split方法创建一个名为split的新变量，它包含train和test值，如下面的代码所示：

loans["split"] = loans[response].stratified_split(\

    test_frac = 0.2, seed = 12345)

loans[[response,"split"]].table()

分层分割的结果如下所示：

![Figure 8.6 – The stratified split of loan data into train and test

图 8.6 – 贷款数据分层分割为训练集和测试集

我们使用split列创建一个布尔掩码，以推导出train和test数据集，如下面的代码所示：

mask = loans["split"] == "train"

train = loans[mask, :].drop("split")

test = loans[~mask, :].drop("split")

注意，在创建这两个数据集之后，我们删除了split列。现在我们准备使用这些训练集和测试集进行目标编码。

对 Lending Club 数据进行目标编码

以下用于对purpose和addr_state变量进行目标编码的代码与第五章中的代码类似，即高级模型构建 – 第一部分，我们在此处未进行讨论：

from h2o.estimators import H2OTargetEncoderEstimator

encoded_columns = ["purpose", "addr_state"]

train["fold"] = train.kfold_column(n_folds = 5, seed = 25)

te = H2OTargetEncoderEstimator(

    data_leakage_handling = "k_fold",

    fold_column = "fold",

    noise = 0.05,

    blending = True,

    inflection_point = 10,

    smoothing = 20)

te.train(x = encoded_columns,

         y = response,

         training_frame = train)

train_te = te.transform(frame = train)

test_te = te.transform(frame = test, noise = 0.0)

接下来，我们重新定义train和test数据集，从目标编码的train_te和test_te分割中删除编码列。同时，我们也从train_te数据集中删除fold列（注意它不存在于test_te数据集中）。代码如下：

train = train_te.drop(encoded_columns).drop("fold")

test = test_te.drop(encoded_columns)

使用我们更新的train和test数据集，我们准备着手进行模型构建和评估过程。

模型构建和评估

我们的模型构建方法从 AutoML 开始。将全局可解释性应用于 AutoML 排行榜要么选择一个候选模型，要么提供反馈到新一轮修改后的 AutoML 模型中的见解。如果模型或可解释性有改进，这个过程可以重复。如果选择的是单个模型而不是堆叠集成，我们可以展示如何通过额外的随机网格搜索产生更好的模型。然后，评估最终的候选模型。

在 H2O-3 中，这种方法的美妙之处在于模型构建的重活由 AutoML 自动完成。迭代这个过程很简单，改进周期可以根据需要重复，直到我们得到一个令人满意的最终模型。

我们将建模步骤组织如下：

1. 使用 AutoML 进行模型搜索和优化。

2. 使用 AutoML 排行榜模型研究全局可解释性。

3. 从 AutoML 候选模型中选择一个模型，可选的附加网格搜索。

4. 最终模型评估。

使用 AutoML 进行模型搜索和优化

在第五章中，高级模型构建 – 第一部分中，对使用 H2O-3 AutoML 的模型构建过程进行了详细介绍。在这里，我们将遵循几乎相同的过程来创建由 AutoML 拟合的模型排行榜。为了清晰起见，我们在从predictors集中移除bad_loan响应变量之前重新定义了我们的response列和predictors：

response = "bad_loan"

predictors = train.columns

predictors.remove(response)

我们的 AutoML 参数仅排除深度学习模型，允许过程运行长达 30 分钟，如下代码片段所示：

from h2o.automl import H2OAutoML

aml = H2OAutoML(max_runtime_secs = 1800,

                exclude_algos = ['DeepLearning'],

                seed = 12345)

aml.train(x = predictors, 

          y = response, 

          training_frame = train)

如第五章中所示，高级模型构建 – 第一部分，我们可以访问 H2O Flow 以更详细地监控模型构建过程。一旦对aml对象的训练完成，我们就开始调查生成的模型的全局可解释性。

使用 AutoML 模型研究全局可解释性

在第七章中，理解机器学习模型，我们概述了使用全局可解释性来分析 AutoML 生成的一系列模型。在这里，我们将通过调用带有test数据分割的explain方法遵循相同的程序：

aml.explain(test)

生成的 AutoML 排行榜如下截图所示：

图 8.7 – AutoML 排行榜的前 10 个模型

在图 8.7中，堆叠集成AllModels和BestOfFamily模型占据了排行榜的前两位。最佳单个模型由一个绿色方框包围，并标记为model_6来自XGBoost_grid__1。我们将进一步研究这个模型，作为可能的候选模型。

图 8.8中的模型相关性图显示了。绿色框表示我们的候选 XGBoost 模型与两个堆叠集成之间的相关性。它证实了候选模型与集成之间具有最高的相关性：

图 8.8 – AutoML 排行榜模型的模型相关性图

图 8.9中的变量重要性热图图表告诉我们更多关于单个特征稳定性的信息，而不是关于模型之间的关系。1、2、3 和 7 的 GBM 网格模型聚集在一起，6、7 和 9 的 XGBoost 网格模型在变量在这些模型中的重要性方面看起来非常相似：

图 8.9 – AutoML 模型的变量重要性热图

多个模型等级，一个具有从 A 到 G 的值且似乎随着违约风险增加的特征。换句话说，A 的平均响应低于 B，B 本身又低于 C，以此类推。这种诊断似乎证实了商业评级实践：

图 8.10 – 等级多个模型的 PDP

在图 8.11中，年度收入的 PDP（预测性诊断图）充当诊断工具。直观上，年度收入的增加应该对应不良贷款率的降低。我们可以通过向我们的模型构建代码中添加单调性约束来正式强制（而不是仅仅希望）年度收入和违约率之间保持单调递减关系：

图 8.11 – 年度收入多个模型的 PDP

单调性约束可以应用于 H2O-3 中的 GBM、XGBoost 和 AutoML 模型中的一个或多个数值变量。为此，提供一个monotone_constraints参数，该参数是一个包含变量名称和单调性方向的字典：1表示单调递增关系，-1表示单调递减。以下代码显示了如何添加单调递减的annual_inc约束：

maml = H2OAutoML(

         max_runtime_secs = 1800,

         exclude_algos = ['DeepLearning'],

         monotone_constraints = {"annual_inc": -1}, 

         seed = 12345)

单调递增和递减约束

形式上，单调递增约束是一个单调非递减约束，意味着函数必须要么是递增的，要么是平的。同样，单调递减约束更准确地称为单调非递增约束。

将约束模型拟合的过程与通常一样：

maml.train(x = predictors, 

           y = response, 

           training_frame = train)

这里是explain方法：

maml.explain(test)

这产生了以下截图所示的排行榜：

图 8.12 – 带有单调约束的 AutoML 排行榜

更新后的 AutoML 排行榜的前 10 个模型在 图 8.12 中显示。注意，已经添加了一个新模型，单调堆叠集成（用红色框出）。这个堆叠集成只使用单调的模型作为组成部分。在我们的案例中，这意味着任何由 AutoML 调整的 DRF 和 XRT 随机森林模型将被排除。此外，注意 XGBoost 模型 6 的单调版本再次成为领先的单一模型，用绿色框出。

图 8.13 展示了年收入的单调多模型 PDP：

图 8.13 – 年收入的多模型 PDP

注意，图 8.13 中包含的模型中只有两个不是单调的：DRF 和 XRT 模型。它们都是没有单调选项的随机森林版本。这个图证实了年收入上的单调约束按预期工作。（注意，图 8.11 中的 PDP 非常相似。那里的模型可能表现出单调性，但并未强制执行。）

接下来，我们将考虑如何从 AutoML 排行榜中选择一个模型。

从 AutoML 候选模型中选择模型

一旦 AutoML 创建了一类模型，数据科学家就需要决定哪个模型可以投入生产。如果只有纯预测准确率是唯一要求，那么选择相当简单：选择排行榜上的顶级模型（通常，这是 所有模型 堆叠集成）。在需要单调约束的情况下，单调堆叠集成通常是预测性最强的。

如果业务或监管约束只允许部署单个模型，那么我们可以根据预测性能和其他考虑因素（如建模类型）的组合来选择一个模型。让我们选择 XGBoost 模型 6 作为我们的候选模型：

candidate = h2o.get_model(maml.leaderboard[3, 'model_id'])

H2O-3 AutoML 在构建和调整多个建模类型的模型方面做得非常出色。对于单个模型，有时通过额外的随机网格搜索可以获得性能提升。我们将在下一节中探讨这一点。

随机网格搜索以改进所选模型（可选）

我们将候选模型的参数作为随机网格搜索的起点。想法是在候选模型附近搜索表现略好的模型，需要注意的是，找到的任何改进可能都是微小的。堆叠集成模型为我们设定了单个模型可以表现多好的上限。数据科学家必须判断候选模型性能与堆叠集成性能之间的差异是否值得额外努力去寻找可能更好的模型。

我们可以使用以下代码列出模型参数：

candidate.actual_params

首先导入 H2OGridSearch 和候选模型估计器；在我们的案例中，那就是 H2OXGBoostEstimator：

from h2o.grid.grid_search import H2OGridSearch

from h2o.estimators import H2OXGBoostEstimator

超参数是通过观察候选模型的实际参数并在这些值的邻域内搜索来选择的。例如，候选模型的采样率报告为 80%，在我们的超参数调整中，我们选择了一个介于 60%和 100%之间的范围。同样，60%的列采样率导致我们在网格搜索中实施了一个介于 40%和 80%之间的范围。超参数调整的代码如下：

hyperparams_tune = {

    'max_depth' : list(range(2, 6, 1)),

    'sample_rate' : [x/100\. for x in range(60,101)],

    'col_sample_rate' : [x/100\. for x in range(40,80)],

    'col_sample_rate_per_tree': [x/100\. for x in

         range(80,101)],

    'learn_rate' : [x/100\. for x in range(5,31)]

}

我们将随机网格搜索的总运行时间限制为 30 分钟，如下所示：

search_criteria_tune = {

    'strategy' : "RandomDiscrete",

    'max_runtime_secs' : 1800,

    'stopping_rounds' : 5,

    'stopping_metric' : "AUC",

    'stopping_tolerance': 5e-4

}

我们将单调约束添加到模型中，并定义我们的网格搜索：

monotone_xgb_grid = H2OXGBoostEstimator(

    ntrees = 90,

    nfolds = 5,

    score_tree_interval = 10,

    monotone_constraints = {"annual_inc": -1},

    seed = 25)

monotone_grid = H2OGridSearch(

    monotone_xgb_grid,

    hyper_params = hyperparams_tune,

    grid_id = 'monotone_grid',

    search_criteria = search_criteria_tune)

然后，我们训练模型：

monotone_grid.train(

    x = predictors,

    y = response,

    training_frame = train)

在经过这么长时间的训练后，我们提取了前两个模型来与我们的初始候选模型进行比较。请注意，我们按logloss排序：

monotone_sorted = monotone_grid.get_grid(sort_by = 'logloss',

                                         decreasing = False)

best1 = monotone_sorted.models[0]

best2 = monotone_sorted.models[1]

确定这些模型在测试数据分割上的性能：

candidate.model_performance(test).logloss()

best1.model_performance(test).logloss()

best2.model_performance(test).logloss()

在测试样本上，candidate模型的 logloss 为 0.3951，best1为 0.3945，而best2为 0.3937。仅根据这一标准，best2模型是我们的更新后的候选模型。下一步是对这个最终模型进行评估。

最终模型评估

在选择best2作为我们的最终候选模型后，接下来，我们使用explain方法评估这个单独的模型：

final = best2

final.explain(test)

我们将结合图 8.14中的变量重要性图和单个 PDP 来了解输入变量对模型的影响：

![img/B16721_08_014.jpg]

![img/B16721_08_014.jpg]

图 8.14 – 最终模型的变量重要性

在最终模型中，term变量是最重要的变量。查看图 8.15中term的 PDP 可以解释原因。

![图 8.15 – 术语的 PDP

![img/B16721_08_015.jpg]

图 8.15 – 术语的 PDP

36 个月的贷款违约率约为 12%，而 60 个月的贷款违约率则跳升至超过 25%。请注意，因为这是一个 XGBoost 模型，term被参数化为term 36 months。

下一个重要变量是grade A。这是分类变量grade的一个指示函数。查看图 8.16中grade的 PDP，我们发现只有 A 级别的贷款有 10%的违约率，而下一个最低风险等级 B 的违约率大约增加了 5%：

![图 8.16 – 等级的 PDP

![img/B16721_08_016.jpg]

图 8.16 – 等级的 PDP

下两个变量是数值型，重要性大致相当：过去 6 个月的信用查询（inq_last_6mths）和年收入。它们的 PDP 分别显示在图 8.17和图 8.18中。信用查询的 PDP 似乎是单调的，除了右尾部分。这可能是由于这个高查询数量区域的数据稀薄。我们可能需要像在图 8.18中对年收入所做的那样，为这个变量添加单调约束：

![图 8.17 – 最后 6 个月的查询次数的 PDP

![img/B16721_08_017.jpg]

![图 8.17 – 最后 6 个月内的查询次数 PDP]

![图 8.18 – 单调年度收入的 PDP]

![图片 B16721_08_018.jpg]

![图 8.18 – 单调年度收入的 PDP]

图 8.19显示了循环信用利用率的 PDP。与早期的数值图不同，revol_util变量并不明显是单调的。一般来说，利用率越高，违约率就越高。然而，在零利用率时，违约率相对较高。有时，这种效应是由不同人群的混合引起的。例如，这可能是由没有信用额度但没有任何余额的客户（通常风险较好）与完全没有信用额度的客户（通常风险较差）的组合。在不重新参数化的情况下，revol_util不应该被限制为单调：

![图 8.19 – 循环利用率的 PDP]

![图片 B16721_08_019.jpg]

![图 8.19 – 循环利用率的 PDP]

最后，图 8.20显示了最终模型的 SHAP 摘要。从 SHAP 值的角度来看，相对重要性与我们特征重要性和 PDP 视图略有不同：

![图 8.20 – 最终模型的 SHAP 摘要图]

![图片 B16721_08_020.jpg]

![图 8.20 – 最终模型的 SHAP 摘要图]

这只是一个最终模型审查或白皮书的预览。其中一些内容可能长达多页。

模型管道部署准备

将模型作为 MOJO 导出以进行最终模型部署是微不足道的，例如，考虑以下内容：

final.download_MOJO("final_MOJO.zip")

在第九章中详细介绍了通过多个配方在多种架构中部署 MOJO，生产评分和 H2O MOJO。一般来说，必须分配大量努力以将数据用于模型评分。关键是生产中使用的必须具有与建模中使用的训练数据相同的模式。在我们的案例中，这意味着所有数据整理和特征工程任务必须在生产评分之前进行生产化。换句话说，这个过程很简单：

1. 将原始数据转换为训练数据格式。

2. 使用 MOJO 在转换后的数据上评分模型。

在模型交付之前与您的 DevOps 或等效生产团队合作是一项最佳实践，以便了解部署所需的数据要求。这包括指定角色和责任，例如谁负责生成数据转换代码，代码如何进行测试，谁负责实施，等等。通常，对于数据科学领导者来说，MOJO 的交付并不是努力的终点。我们将在第九章中更详细地讨论这一伙伴关系的重要性，生产评分和 H2O MOJO。

摘要

在本章中，我们回顾了整个数据科学模型构建过程。我们从原始数据和一个定义得相当模糊的使用案例开始。对数据的进一步检查使我们能够将问题陈述细化到一个与业务相关且可以使用现有数据进行解决的问题。我们进行了广泛的特征工程，希望某些特征可能是我们模型中的重要预测因子。我们引入了一种高效且强大的模型构建方法，使用 H2O AutoML 通过多种算法构建了一系列不同的模型。选择其中之一后，我们展示了如何通过网格搜索进行额外的超参数调整来进一步细化模型。在整个模型构建过程中，我们使用了在第七章“理解机器学习模型”中引入的诊断和模型解释来评估我们的机器学习模型。在得到一个合适的模型后，我们展示了在 H2O 中构建的模型管道的企业部署所需的简单步骤。

下一章介绍了如何使用 H2O MOJO 进行评分，将这些模型部署到生产过程中的步骤。

第三部分 – 将您的模型部署到生产环境

在本节中，我们学习如何将模型构建导出的模型部署到企业系统中进行评分。我们首先关注 H2O MOJO 模型评分实体的企业级质量和技术特性。我们通过编写一个批处理文件评分程序来亲身体验，该程序将 MOJO 嵌入到程序中。然后，我们通过详细说明 H2O 软件、第三方集成和定制构建系统上实时、流式和批处理评分的十几种部署模式，展示如何部署 MOJO 到各种企业系统。

本节包括以下章节：

• 第九章，生产评分和 H2O MOJO

• 第十章，H2O 模型部署模式

第九章：生产评分和 H2O MOJO

我们在前一节中学习了如何使用 H2O 在规模数据上构建世界级模型。在本章中，我们将学习如何部署这些模型并从中进行预测。首先，我们将介绍将模型投入生产评分系统的背景。然后，我们将学习 H2O 如何使这一过程变得简单和灵活。这个故事的核心是 H2O MOJO（代表Model Object, Optimized），这是一个准备就绪的可部署评分工件，您可以从模型构建环境中导出它。我们将从技术上了解什么是 MOJO 以及如何部署它。然后我们将编写一个简单的批文件评分程序并在其中嵌入一个 MOJO。最后，我们将对 MOJO 进行一些总结。总之，在本章中，您将获得部署 H2O 模型的不同方式的知识，并开始从实时预测中获得价值。

这些是我们将在本章中涵盖的主要主题：

• 将 H2O 模型的建模上下文与评分上下文相关联

• 认识到 H2O 模型的目标生产系统的多样性

• 检查 H2O 可部署工件的技术设计，即 H2O MOJO

• 编写自己的 H2O MOJO 批文件评分器以展示如何在您的软件中嵌入 MOJOs

技术要求

在本章中，您需要一个 Java SE 8 或更高版本的环境。Java IDE，如 Eclipse，是可选的但很有用。您将在以下 GitHub 仓库中获取一个 MOJO、一个评分数据集以及批文件评分程序的 Java 代码：github.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/tree/main/chapt9。这些工件是从第八章中构建的模型生成的，整合一切。

注意，到目前为止我们已经完成了模型构建，因此您不需要一个指向运行中的 H2O 集群的模型构建环境。

模型构建和模型评分上下文

在第二部分，使用 H2O 在大数据量上构建世界级模型中，我们投入了大量精力使用 H2O 在规模上构建世界级模型。针对大规模数据集构建高度准确和可信的模型可能为一家企业带来数百万美元的收入，挽救生命，并定义新产品领域，但这只有在模型部署到生产系统，在那里进行预测并采取行动的情况下才可能。

最后这一步，在生产系统中部署和预测（或评分），通常可能耗时、有风险，原因将在下面简要讨论。H2O 使从构建（训练）模型到部署模型这一过渡变得简单。它还提供了广泛的灵活性，关于评分的位置（设备、Web 应用程序、数据库、微服务端点或 Kafka 队列）以及数据的速度（实时、批量、流式）。而且，无论生产环境如何，H2O 部署的模型评分都非常快。

在这个易于、灵活和低延迟的生产评分的中心是 H2O MOJO。H2O MOJO 是一个准备就绪的评分工件，它是在模型构建代码的末尾通过简单的导出命令生成的。无论生成它们的模型构建算法是什么，H2O MOJO 都是相似的。因此，所有 H2O 模型都是以相同的方式部署的。在深入探讨 MOJO 并学习如何部署它之前，让我们首先一般地看看从模型训练到模型评分的过程。

模型训练到生产模型评分

我们首先将一般地了解模型如何从模型训练过渡到生产评分，然后看看 H2O 是如何做到这一点的。

通用训练到评分流程

训练到部署模型的通用流程可以表示如下：

![Figure 9.1 – Generalized pipeline from model training to scoring

![img/Figure_9.1_B16721.jpg]

图 9.1 – 从模型训练到评分的通用流程

请注意，这个流程更正式地由称为机器学习操作（MLOps）的实践来表示和阐述，它涉及更广泛的关注领域，但就部署模型到生产而言，这里的表示应该对我们适用。

每个步骤总结如下：

1. 软件代码中的if-else逻辑。这是因为训练模型的逻辑必须由数据科学家准确传达给软件开发者，软件开发者必须正确实现逻辑，然后对其进行彻底测试以验证其准确性。这也很容易出错，因此具有风险，而且耗时。

最佳情况是转换工具将训练模型转换为可部署的工件。这可以是一个格式（例如，用于 PMML、PFA 或 ONNX 的 XML），它声明了准备就绪的生产系统的逻辑，该系统可以针对声明性结构进行计算，或者它可以是可运行的软件工件（例如，Python wheel 或 Java JAR 文件），它可以嵌入到软件程序或框架中。

1. 可部署模型：转换后的模型被部署到生产系统中。这段代码或转换后的工件被集成到软件应用程序或框架中，在某个时刻，将数据输入到它持有的评分逻辑中，并输出评分结果。例如，客户的数据输入，然后输出客户流失的概率。

模型部署应在测试和生产（PROD）环境中进行，通过使用持续集成和持续部署（CI/CD）管道进行正式的治理流程，就像一般软件的部署一样。在所有构建的模型（例如，不同的机器学习算法之间）中可识别和标准化的可部署工件，在部署过程中比不可识别的工件更容易自动化。

1. 生产系统：在生产环境中进行评分。评分需求可能多种多样。例如，可能需要批量对整个数据库表进行评分，对通过网络发送的每个实时 ATM 交易进行评分，在 Web 应用程序中对每个客户的网页点击进行评分，或者对从边缘设备发送的传感器数据流进行评分。评分可以在设备上进行，也可以在云中的大型服务器上进行。通常，评分越快越好（每评分少于 50 微秒或更快的需求并不罕见），评分器的大小和资源消耗越小，它就可以部署得越接近边缘。

2. 预测：评分输出。模型在评分过程中输出预测结果。请注意，预测需要业务背景和行动来实现目的或价值。例如，预测会流失的客户会接到电话或特别优惠，以确保他们继续成为客户。通常，评分输出不仅需要预测，还需要以原因代码形式提供对这些预测的解释。模型在为特定客户生成预测时是如何权衡评分器输入的？换句话说，哪些因素在特定预测中最为重要。这些决策权重以原因代码的形式表示，并有助于在流失案例中个性化电话或特别优惠。

让我们看看 H2O 是如何实现训练到评分流程的。

H2O 流程及其优势

训练好的 H2O 模型参与与之前讨论的类似流程，但具有使它们易于部署到各种软件系统目标的重要属性，并且在评分时也非常快。H2O 的可部署工件称为 MOJO，它架起了模型训练和模型评分之间的桥梁，因此是故事中的核心角色。H2O 流程的属性总结如下：

![图 9.2 – H2O 的模型训练到评分流程

![img/Figure_9.2_B16721.jpg]

图 9.2 – H2O 的模型训练到评分流程

让我们详细说明 H2O 部署模型的优势：

1. H2O 训练模型：从模型构建 IDE 导出的 H2O MOJOs，已准备好部署。数据科学家通过在 IDE 中编写一行代码，将训练好的模型转换为导出并准备就绪的 MOJO。

2. H2O MOJO: H2O MOJOs 是标准化的低延迟评分工件，并已准备好部署。MOJO 构造是标准化的，并由所有模型类型共享，并且拥有自己的运行时，该运行时嵌入在任何 Java 运行时中。这意味着所有 MOJOS（模型）都相同地嵌入在任何 Java 虚拟机（JVM）中，独立于更大的软件和硬件环境。MOJOs 轻量级，可以部署到几乎所有基础设施（除了最小的边缘设备）。MOJOs 在评分方面非常快，可以处理任何数据速度（实时评分、批量评分和流式评分）。

3. 生产系统: H2O MOJOs 可以灵活地部署到各种生产系统中。MOJOs 可以部署到广泛的生产系统。这些系统的概述以及 MOJOS 如何部署到这些系统的详细信息将在本章稍后提供。

4. 预测: MOJOs 在评分时可以输出大量信息。输入到 MOJO 的数据返回分类的概率预测、回归的预测数值以及无监督问题的模型特定结果。此外，可选地，MOJOs 可以返回以 Shapley 或 K-LIME 值或其他属性（如预测的叶节点分配）形式的原因代码。

在下一节中，我们将更专注于 H2O 的生产评分。

H2O 生产评分

当模型投入生产以进行预测（或为无监督问题类生成无监督结果）时，它们实现了其商业价值。在本节中，我们讨论了从模型构建到生产评分的 H2O 管道的更详细视图。

使用 H2O 的端到端生产评分管道

查看以下图表，展示从模型训练到模型部署和生产的 H2O 端到端管道：

图 9.3 – 使用 H2O 的完整评分管道的高级视图

通常，模型构建被认为是 开发（DEV）环境，而模型评分是一个 PROD 环境，其源数据来自各自的环境。

对于开发（DEV），我们在 第二部分，使用 H2O 在大型数据量上构建最先进的模型 中广泛讨论了特征工程和模型训练（以及许多相关步骤，如模型可解释性和评估）。我们也在本章早期简要讨论了可导出并准备好部署的 H2O MOJO 评分工件以及将其部署到 PROD 系统中。

让我们确定在管道中需要注意的一些关键点：

• 您需要在开发和生产环境中保持特征工程的一致性：这意味着为了创建训练数据集而进行的任何特征工程都必须在测试/生产中的评分输入中得到匹配。换句话说，训练数据集中的特征必须与输入到模型评分中的特征相同。如果在开发中在构建训练数据集之前有多个特征工程步骤（例如，从数据源中进行的提取、转换和加载（ETL）以及 H2O Sparkling Water 中的特征工程），则测试/生产中的评分输入必须具有相同的工程特征。

话虽如此，根据 MOJO 的部署方式（H2O Scorer、第三方集成或您自己的评分器），您可能只需要输入训练数据集中的一小部分特征到测试/生产中。这反映了训练模型通常只选择对最终模型有贡献的数据特征子集的事实。然而，这种子集化不是必需的；MOJO 可以根据您的设计接受完整的特征集或特征子集（与训练数据集相比）。这种灵活性将在本章稍后当我们更仔细地查看部署 MOJO 时变得更加清晰。

• 您可能需要在您的 MOJO 周围添加一个包装器（但不是与 H2O Scorers 和大多数第三方集成一起使用）：MOJO 已准备好部署到 Java 环境。这意味着 MOJO 可以准备好使用从模型训练中推导出的数学逻辑并将输入数据转换为预测输出，并且 MOJO 本身不需要以任何方式进行编译或修改。但是，您必须确保输入（例如，CSV、JSON、批处理等）以 MOJO 可以接受的方式输入。另一方面，您可能希望从 MOJO 评分结果中提取比仅预测更多的信息，并且您需要将 MOJO 输出转换为应用程序下游期望的格式。您可以通过编写一个简单的 Java 包装器类并使用名为h2o-genmodel的 MOJO API 与 MOJO 交互来完成此操作。这些包装器类并不复杂。我们将在本章稍后通过一个示例来学习如何包装 MOJO。

  重要提示

  H2O Scorers 和许多 MOJO 的第三方集成不需要包装器，因为它们内部处理这些操作。在这些情况下，您只需要导出的 MOJO。此外，许多集成是通过 REST API 与部署在 REST 服务器上的 MOJO 端点进行的。

• 您可能希望与预测一起返回原因代码或其他信息：MOJO 为监督模型返回预测，为无监督模型返回模型特定的输出（例如，对于使用H2OIsolationForestEstimator训练的模型，返回异常分数）。但是，从 MOJO 中还可以检索更多内容；您还可以返回原因代码作为 K-LIME 或 Shapley 值，通过基于树的模型所采取的决策路径，或者分类问题的预测中的类别标签。这些额外的输出是通过使用h2o-genmodel API 在构建评分器时实现的包装代码。这些可能或可能不会集成到 H2O 评分器的功能中，或者集成到现成的第三方集成中。您需要检查这些评分器的规范。

• 您需要一个正式的过程来部署和治理您的模型：将模型投入生产涉及风险：通常，部署过程中出现错误导致失败或延迟的风险，以及模型决策的不利后果对收入或声誉的风险。我们将在第十四章，在大平台环境中的 H2O 扩展规模中更详细地探讨这个主题。

• 您需要 MLOps 来监控您的模型：PROD 中的模型通常需要监控，以查看输入数据的值是否随时间变化，与训练数据中的值相比（这种结果称为数据漂移）。在这种情况下，模型可能需要重新训练，因为训练时对抗的信号已经改变，这可能导致模型的预测准确性下降。评分的偏差、预测分布和其他方面也可能被监控。

模型监控超出了 MOJO 的能力。MOJO 关注的是单个评分。监控本质上跟踪 MOJO 输入和输出的聚合趋势，这是一个独立的技术和关注领域，这里不会涉及。但是请注意，H2O 有一个执行模型监控和治理的 MLOps 平台。它在第十六章，机器学习生命周期、AI 应用和 H2O AI 混合云中概述。

我们刚刚概述了从 H2O 模型构建到生产评分的完整流程，并确定了关于此流程的关键点。此流程的一部分根据您的需求有很大差异：部署您的 MOJO 的目标系统。让我们更详细地探讨这一点。

H2O MOJO 的目标生产系统

MOJO 的一个大优势是它们可以被部署到广泛的生产系统中。让我们使用以下图表来深入挖掘，以总结：

图 9.4 – MOJO 评分的生产系统分类

商业需求主要决定了评分是否需要实时、批量或流式处理，而 MOJO 可以处理这些数据速度的全范围。

对于 MOJO 部署，将生产目标系统划分为以下三个类别是有用的：

• H2O 评分系统：这代表了从 H2O 提供的 H2O 评分软件。这些评分器包括一个带有 MLOps 和丰富的模型监控和管理能力的 REST 服务器（以及包括批量评分、冠军/挑战者测试、A/B 测试等在内的活跃路线图），一个用于批量数据库表评分的数据库评分器，它输出到表或文件，一个文件批量评分器，以及用于流式事件的 AMQ 和 Kafka 评分器。H2O 正在积极添加更多评分器，请访问他们的网站以保持最新。MLOps 评分器在第十六章，机器学习生命周期、AI 应用和 H2O AI 混合云中进行了更详细的讨论。

• 第三方集成：许多第三方将 MOJOs 直接集成到他们的框架或软件中进行评分。其他一些则需要构建一些粘合剂来创建自定义集成。

• 您自己的 DIY 系统：您可以将 MOJO 嵌入到运行 Java 环境的软件或框架集成中。集成将需要一个简单的 Java 包装类来将您的应用程序或框架与 MOJO 的数据输入和输出能力接口（例如，您的 REST 服务器需要将 JSON 转换为 MOJO 数据对象）。H2O 通过其MOJO API使这变得简单。本章后面将更详细地讨论使用 MOJO API 进行包装，并附有代码示例。

注意，本章提供了将 MOJO 部署到目标系统的简介。整个第十章，H2O 模型部署模式，将致力于展示多个 MOJO 部署到目标系统的示例。

现在我们已经了解了从模型构建到在多样化的生产系统上实时评分的端到端 H2O 管道，让我们更深入地了解一下其核心角色：MOJO。

H2O MOJO 深度解析

从部署和评分的角度来看，所有 MOJOs 在本质上都是相似的。这一点无论从上游模型构建的角度来看 MOJO 的来源如何，也就是说，无论使用了 H2O 广泛多样的模型构建算法（例如，广义线性模型和 XGBoost）和技巧（例如，堆叠集成和 AutoML），以及训练数据集的大小（从 GB 到 TB），构建最终模型都是如此。

让我们更详细地了解 MOJO。

什么是 MOJO？

MOJO代表模型对象，优化。它是通过运行以下代码行从您的模型构建 IDE 导出的：

model.download_mojo(path="path/for/my/mojo")

这将在您的 IDE 文件系统中下载一个具有唯一名称的.zip文件，到您指定的路径。这个.zip文件就是 MOJO，这就是部署的内容。您不需要解压缩它，但如果您好奇，它包含一个model.ini文件，该文件描述了 MOJO，以及多个.bin文件，所有这些文件都由MOJO 运行时使用。

什么是 MOJO 运行时？这是一个名为h2o-genmodel.jar的 Java .jar文件，是所有 H2O Core MOJOs 的通用运行时。换句话说，MOJO 是特定于它们从中派生的训练模型的，所有 MOJO 都以相同的方式加载到 MOJO 运行时中。MOJO 运行时与 Java 运行时（在 H2O 软件、第三方软件或你的软件中）集成。以下图表展示了 MOJO 与 MOJO 运行时的关系。

![Figure 9.5 – MOJOs and the MOJO runtime

图 9.5 – MOJOs 和 MOJO 运行时

如前所述，MOJO 被部署到 Java 运行时，更正式地称为h2o-genmodel.jar，作为依赖库来执行。软件使用h2o-genmodel API 将特定模型的 MOJO 加载到通用的h2o-genmodel.jar运行时中。应用程序代码中的实际评分逻辑也使用h2o-genmodel.jar及其 API 来实现评分和从嵌入的 MOJO 中提取结果。

让我们在下一节深入探讨并详细阐述。

部署 MOJO

如果你将 MOJO 部署到 H2O 评分器或直接集成 MOJO 的第三方软件中，你只需要 MOJO。在这些情况下，你不需要考虑 MOJO 运行时和 API。这是因为这些软件系统已经在幕后实现了h2o-genmodel.jar（使用h2o-genmodel API），换句话说，在已部署和运行的 H2O 评分器或第三方软件中。

在其他情况下，你需要编写嵌入 MOJO 并提取其评分结果的代码。这种代码通常是使用h2o-genmodel API 的单个 Java 包装类。我们将在稍后通过代码示例来探讨这一点。

这种区别很重要，值得特别强调。

MOJO 部署中的关键区别

当部署到 H2O 评分软件或直接集成 MOJO 的第三方软件（基于配置）时，你只需要 MOJO。

当将 MOJO 集成到自己的软件或未直接集成 MOJO 的第三方软件中时，你需要编写一个简单的 Java 包装类，使用h2o-genmodel API。这个包装器需要h2o-genmodel.jar，这是h2o-genmodel API 所代表的库。

（如果你在第三方软件或自己的软件中从 REST 服务器消费 MOJO 预测，你当然不需要 MOJO 或 MOJO 运行时。你只需要遵守 MOJO 的 REST 端点 API。）

让我们看看你需要编写包装器的情况。

使用 H2O MOJO API 包装 MOJO

在学习如何在大型软件程序中包装 MOJO 之前，让我们先简要介绍一些先决条件。

获取 MOJO 运行时

在模型构建后从 IDE 下载 MOJO 时，你可以下载h2o-genmodel.jar。这仅仅是在你的下载语句中添加一个新参数的问题，如下所示：

Model.download_mojo(path="path/for/my/mojo", 

                    get_genmodel_jar=True)

获取 h2o-genmodel.jar 的这种方法通常不会在受控的生产部署中执行。这是因为 h2o-genmodel.jar 对所有 MOJO 都是通用的，并且是软件开发人员的问题，而不是数据科学家的问题。

软件开发人员可以从 Maven 仓库的 mvnrepository.com/artifact/ai.h2o/h2o-genmodel 下载 MOJO 运行时。h2o-genmodel.jar 兼容向下；它应该适用于由 H2O-3（或 Sparkling Water）版本生成的 MOJO，该版本等于或低于 h2o-genmodel.jar 版本。

获取 MOJO 运行时（h2o-genmodel.jar）的技巧

数据科学家不必每次从他们的模型构建 IDE 下载 MOJO 时都下载 MOJO 运行时。这是因为 MOJO 运行时对所有 MOJO 都是通用的。最佳实践是让您的开发人员（而不是数据科学家）在需要时关注获取和使用 MOJO 运行时以进行生产部署。这可以通过前面提到的 Maven 仓库来完成。

h2o-genmodel API

h2o-genmodel API 的 Javadocs 位于 docs.h2o.ai/h2o/latest-stable/h2o-genmodel/javadoc/index.html。请注意，这是针对最新的 H2O-3（或 Sparkling Water）。要获取不同版本，请访问 docs.h2o.ai/prior_h2o/index.html。

总结来说，h2o-genmodel API 用于在 MOJO 周围构建包装器，以便您的应用程序可以将数据输入到 MOJO 中，从中提取预测和决策信息，并将这些结果转换为包装器中的代码。包装器通常是您更大应用程序的一部分，可以被视为您的应用程序和 MOJO 之间的粘合剂。

让我们深入探讨。

包装您的 MOJO 的一般方法

在编写代码之前首先查看您开发的 MOJO 包装器的应用程序代码的逻辑流程将是有用的。这可以在以下图中看到：

图 9.6 – MOJO 包装的逻辑视图

Java 包装器通常是它自己的类（或类的一部分）并导入 h2o-genmodel.jar，遵循以下一般逻辑步骤：

1. 将 yourMOJO.zip 加载到 MOJO 运行时中。回想一下，h2o-genmodel.jar 是包含用于在特定 MOJO 上工作的通用逻辑的运行时。现在这个运行时已经准备好对您的特定模型进行操作了。

2. 将数据输入到 MOJO 中。为此，使用 h2o-genmodel 代码将您的输入的 Java 数据结构转换为 MOJO 数据结构。

3. 对 MOJO 进行评分。这是一行 h2o-genmodel 代码。

4. 从 MOJO 评分结果中提取所需的信息子集。回想一下，预测结果（或无监督结果）表示预测的各个方面（标签和预测）以及评分决策的各个方面（理由代码、决策路径到叶节点结果和其他）。

5. 将提取的结果转换为应用程序下游所需的数据结构。

让我们编写一个包装器。

包装示例 – 使用 Java 构建批量文件评分器

我们编写的包装器的目标是批量评分来自文件的新数据。评分的输出将是输入记录、预测和格式化为 CSV 行格式的理由代码。理由代码将是一个单独的 CSV 字段，但理由代码将以管道分隔。

我们将编译这个包装器类为一个可运行的程序，该程序接受三个输入参数：

• 输入参数 1：path/of/batch/file/to/score

• 输入参数 2：path/to/yourMOJO.zip

• 输入参数 3（可选）：—shap标志以触发返回文件中每行的评分预测和 Shapley 理由代码

  Shapley 值增加延迟

  请记住，返回 Shapley 值会增加额外的计算，因此会增加每个评分的延迟。你可能想在结果中比较带有和不带有 Shapley 理由代码的延迟，以评估是否在评分中包含它们，如果延迟是关键的话。

我们将使用你在第八章，“整合一切”的模型构建练习结束时导出的 MOJO。

代码

我们的批量文件评分程序将涉及一个 Java 类，并且不会包括错误处理和其他生产质量软件设计。我们在这里的目的只是展示将 MOJO 集成到你的软件中的基础知识。

注意以下代码示例是逐步详细阐述的。要访问从开始到结束的完整 Java 代码，请访问 GitHub 仓库github.com/PacktPublishing/Machine-Learning-at-Scale-with-H2O/tree/main/chapt9。

让我们开始吧：

1. BatchFileScorer。由于这也是一个可执行程序，我们将创建一个main方法来启动代码执行。注意import语句用于h2o-genmodel库包：

   Import java.io.*;
   import hex.genmodel.easy.RowData;
   import hex.genmodel.easy.EasyPredictModelWrapper;
   import hex.genmodel.easy.prediction.*;
   import hex.genmodel.MojoModel; 
   public class BatchFileScorer {
     public static void main(String[] args) throws Exception{
     // we will fill with steps 2 to 4 that follows
     }
   }
   

现在，让我们按照以下步骤在main方法中填充代码。

1. 检索输入参数：我们从程序的参数中检索输入参数：

   // get input parameters
   File fileToScore = new File(args[0]);
   String pathToMojo = args[1];
   boolean doShapley = args.length == 3
     && args[2].equals("--shap"); 
   

2. 加载 MOJO 并配置它以可选地返回理由代码：我们将 MOJO 加载到 MOJO 运行时中，并配置它返回 Shapley 值：

   // Load the mojo (only once) and configure
   EasyPredictModelWrapper.Config config = 
     new EasyPredictModelWrapper.Config();
   config.setModel(MojoModel.load(pathToMojo);
   if (doShapley) config.setEnableContributions(true);
   EasyPredictModelWrapper model = 
     new EasyPredictModelWrapper(config);
   

MOJO 在这里只加载一次，然后在代码中稍后的所有评分之前。

重要设计点 – 只加载一次 MOJO

加载 MOJO 可能需要几秒钟，但只需要在你的程序中加载一次。

在进行所有评分请求之前，在你的包装类中（例如，当它初始化时）一次性加载 MOJO。你不想让每个评分（每个评分的子百或子十毫秒）都由多个秒的加载时间 precede。

现在进入魔法：生成预测。

1. 步骤 1 中显示的 import 语句：

   // get each record from the file
   BufferedReader br = new BufferedReader(new
     FileReader(fileToScore));
   // we are skipping the first line (header line)
   br.readLine();
   String record = null;
   while ((record = br.readLine()) != null) {
     // Convert input record to type required by mojo api
     RowData mojoRow = convertInput(record);
     // make the prediction
     BinomialModelPrediction p = model.predictBinomial(mojoRow);
     // get results from p and format it to your needs
     // in this case, format is csv to write to file
     String outputString = formatOutput(record, p, doShapley);
     // can write this to file 
     // but printing to screen for ease of code explanation
     System.out.println(outputString);
     }
   

就这样！你已经加载了 MOJO 并配置了评分，并对文件的每一行进行了评分。为了评分，你将每条记录从其应用程序表示（CSV 字符串）转换为 h2o-genmodel 表示（DataRow 对象）。你只需写一行代码来评分记录。然后，你从评分结果中检索了预测结果，以及可选的 Shapley 原因代码。然后你将其格式化为应用程序使用的表示形式。

深入挖掘到代码中

让我们深入探讨之前代码中的方法。

方法深入挖掘 – 将你的应用程序数据对象转换为 h2o-genmodel 数据对象

注意，RowData mojoRow 是程序代码转换为 h2o-genmodel API 数据对象的地方。在下面的例子中，这是通过 convertInput(record) 方法完成的，如下所示：

private static RowData convertInput(String record) {

  String[] featureValues = record.split(",");

  RowData row = new RowData();

  row.put("purpose_te", featureValues[0]);

  row.put("addr_state_te", featureValues[1]);

  row.put("loan_amnt", featureValues[2]);

  row.put("term", featureValues[3]);

  row.put("installment", featureValues[4]);

  row.put("grade", featureValues[5]);

  // omitting features 6 to 24, see code in github repo 

  row.put("emp_length_missing", featureValues[25]);

  return row;

}

我们只是使用逗号作为分隔符将输入拆分，并将每个值分配给 H2O RowData 对象，这本质上是一个键值对的映射，键代表特征名称（即列标题）。使用 RowData 有其他替代方案。

设计决策 – 将你的数据对象转换为 MOJO API 数据对象的选择

使用 h2o-genmodel API 的 RowData 类，就像我们在这里做的那样，只是将你的应用程序数据对象转换为 h2o-genmodel 对象以供 MOJO 评分的一种方式。检查 API 以获取可能为你的实现提供更好代码设计的其他方法。

方法深入挖掘 – 单行得分

评分 MOJO 并检索结果只需要一行代码：

BinomialModelPrediction p = model.predictBinomial(mojoRow); 

注意，根据你构建的模型类型，你可能需要一个不同于 BinomialModelPrediction 的类。检查 h2o-genmodel Javadocs 以获取有关要使用哪个 Java 类以及返回哪些评分信息的详细信息。

方法深入挖掘 – 收集结果并格式化为输出

我们最终使用 formatOutput(record, p, doShapley) 方法从评分结果中构建了一个字符串。下面是这个方法是如何实现的：

private static String formatOutput(String record,

  BinomialModelPrediction p, boolean doShapley) {

  // start the ouput string with the record being scored

  String outputString = record;

  // add prediction to output string

  outputString += "   PREDICTION (good=0, bad=1): " + p.label

  + " " + p.classProbabilities[0];

  // add Shapley values (bar-delimited) to output string

  if(doShapley) {

    outputString += "  SHAP VALUES > 0.01: ";

    for (int i=0; i < p.contributions.length; i++) {

        // retrieving only Shap values over 0.01

        if (p.contributions[i] <  0.01) continue;

        outputString += model.getContributionNames()[i] + ": "

        + p.contributions[i] + "|" ;

    }

    return outputString;

}

这里的主要点是预测结果存储在评分返回的 h2o-genmodel API 的 BinomialModelPrediction p 对象中。我们可以从这个对象中检索大量信息。在我们的例子中，我们检索了由 p.label 标识的预测类别及其概率 p.classProbabilities[0]。由于这是一个 BinomialModelPrediction，其他类别的概率可以通过 p.classProbabilities[1] 获取。

然后，我们遍历 Shapley 原因贡献名称数组（model.getContributionNames()[i]）和值（p.contributions[i]）。在我们的例子中，我们只检索值超过0.01的原因代码。例如，我们还可以按值排序原因并返回前五个。当返回所有原因时，偏差作为数组中的最后一个返回，所有特征和偏差的总和将等于模型的原始预测。

总体来说，我们使用了一堆代码将所有这些格式化为以原始记录开始的 CSV 字符串，然后附加预测类别及其概率，然后是一个以竖线分隔的原因代码列表。

运行代码

要运行应用程序，请使用h2o-genmodel.jar将BatchFileScorer.java编译成名为BatchFileScorer.jar的可执行 JAR 文件。然后，在BatchFileScorer.jar相同的目录下运行以下命令：

java -jar BatchFileScorer.jar \  
path/to/file/to/score \
path/to/mojo

要检索 Shapley 原因代码，请在语句中添加--shap。

关于 MOJOs 的其他事项

您现在可以像前一个章节中阐述的那样部署 MOJOs，无论是否需要包装器。让我们通过解决以下次要主题来总结我们对 MOJOs 的了解。

检查 MOJO 决策逻辑

对于基于树的模型，您可以使用h2o-genmodel.jar中内置的实用工具生成 MOJO 中树逻辑的图形表示。以下是方法。

让我们使用之前在构建包装类编码示例中使用的相同的 MOJO。在您的h2o-genmodel.jar所在的命令行中，运行以下命令：

java -cp h2o-genmodel.jar hex.genmodel.tools.PrintMojo \ 
-i "path/to/mojo" \
-o tree.png \
--format png \
--tree 0

这将创建一个看起来像这样的.png文件：

图 9.7 – PrintMojo 实用工具的输出

注意，如果您省略了--tree 0，您将生成一个包含所有树的森林的文件夹。我们指定只返回第一个。

您也可以使用dot作为--format。这将产生一种可以被第三方Graphviz实用工具消费的格式，使图形表示比图 9.7中显示的更美观。

或者，如果您希望将此输出用于程序性使用，对于--format，指定.json，这将输出 JSON 格式的文件。

有关更多详细信息和其他配置选项，请参阅 H2O 文档：docs.h2o.ai/h2o/latest-stable/h2o-docs/productionizing.html#viewing-a-mojo-model。

MOJO 和 POJO

好吧，让我们明确地说：MOJOs 不是唯一的 H2O 可部署工件。在 MOJOs 之前，我们只有h2o-genmodel API 来构建包装类，正如我们之前讨论的那样。它们也有一些不同。让我们比较、对比并得出结论。

MOJO 和 POJO 相似之处

以下为 MOJOs 和 POJOs 之间的相似之处：

• 它们在模型构建后（或从 H2O Flow UI）都从 IDE 导出。

• 它们的部署方式相同：它们都在 JVM 中运行，是否有封装器取决于目标评分系统（H2O 评分器、第三方或您自己的软件程序），并且它们都使用 MOJO 运行时（h2o-genmodel.jar）以及相同的 API 和 Javadoc。

MOJO 和 POJO 的区别

这些是 MOJO 和 POJO 之间的区别：

• POJO 以单个.java文件的形式导出，需要编译，而 MOJO 以单个.zip文件的形式导出，如前所述。

• POJO 包含用于导航模型的整个树，而 MOJO 包含树元数据，并使用h2o-genmodel.zip中的通用树遍历代码来导航模型。树结构越大，POJO 就越大。

• POJO 比 MOJO 大得多（通常是 20-25 倍）且在评分时比 MOJO 慢（慢 2-3 倍）。一般来说，POJO 越大，与从同一模型构建的任何 MOJO 相比，它就越慢。

• 大型 POJO 可能难以编译。H2O 不支持超过 1 GB 的 POJO。

何时使用 MOJO 或 POJO

您应将 POJO 视为已弃用但仍受支持（除> 1GB 外），并且在某些边缘情况下有时需要。了解 MOJO 并非在所有算法中都完全受支持，因此在这些情况下，您被迫使用 POJO。因此，在可能的情况下使用 MOJO，在无法使用时才偶尔使用 POJO。

部署决策 - MOJO 或 POJO？

将 MOJO 视为您当前的首选技术，将 POJO 视为类似部署但已弃用但仍受支持（除> 1 GB 外）。MOJO 的主要优势在于评分速度和大小占用。

一些算法不支持 MOJO。请查阅 H2O 文档了解当前对 MOJO 和 POJO 的支持考虑因素。

我们现在准备总结。

总结

我们以从模型构建到模型部署的过渡的高级视角开始本章。我们了解到，H2O 通过 MOJO 实现了这一过渡，MOJO 是训练模型的可部署表示，易于从模型构建生成，也易于部署以实现快速模型评分。

然后，我们更详细地研究了 MOJO 可以部署的目标系统范围，并看到这些系统必须在 Java 运行时中运行，但除此之外，它们相当多样化。MOJO 可以在实时、批处理和流系统中进行评分，这些系统被有用地分类为 H2O 评分器（由 H2O 提供和支持的评分软件）、第三方集成（由 H2O 以外的公司提供和支持的软件）以及您的软件集成（您构建和维护的软件）。

这种对目标系统的分类有助于我们确定您是否可以直接部署导出的 MOJO，或者是否需要使用h2o-genmodel API 将其封装在 Java 类中以便嵌入评分软件。H2O 评分器和一些第三方评分器只需要导出的 MOJO，无需实现封装器。

我们随后详细研究了 MOJO 及其运行时，以及这些如何与需要或不需包装器的部署相关联。我们描述了 MOJO 包装器的一般结构，并编写了一个包装器以批量从文件评分记录。我们的编码让我们对用于与应用程序中的 MOJO 交互的 MOJO API 有更深入的理解。这种理解包括如何使用 API 加载 MOJO、将数据结构化为 MOJO 可以使用的类型、使用 MOJO 进行评分，以及从评分结果中检索预测和原因代码。

我们随后学习了如何使用 MOJO API 中的一个实用工具来获取模型中 MOJO 决策逻辑的视觉、JSON 或点表示。

最后，我们介绍了 MOJO 的前身 POJO，并描述它类似于 MOJO 在部署和使用 MOJO API 方面，但已弃用但仍受支持，因此仅在 MOJO 无法使用的情况下使用少数情况。

现在，我们详细了解了 MOJO 及其如何灵活地部署到各种生产评分系统中。让我们进入下一章，我们将通过描述这些系统中的具体 MOJO 部署来展示这种灵活性和多样性。

第十章：H2O 模型部署模式

在上一章中，我们学习了如何轻松地从我们的模型构建步骤生成一个可用于部署的评分工件，以及这个称为 MOJO 的工件是如何设计成灵活地部署到广泛的生产系统的。

在本章中，我们通过调查广泛的 MOJO 部署模式并深入了解每个部署模式的细节来探索 MOJO 部署的这种灵活性。我们将看到 MOJO 是如何实现用于在 H2O 软件、第三方软件（包括商业智能 BI 工具）以及您自己的软件上进行评分的。这些实现将包括实时、批量和流数据的评分。

回顾 第一章，机遇与挑战，了解当机器学习（ML）模型部署到生产系统时如何实现商业价值。您在本章中获得的知识将使您能够为特定业务案例找到合适的 MOJO 部署模式。例如，它将允许分析师从 Microsoft Excel 电子表格中进行时间序列预测，技术人员对从制造过程数据流中做出的产品缺陷预测做出响应，或业务利益相关者对直接在 Snowflake 表上评分的欺诈预测做出响应。

本章的目标是让您实现自己的 H2O 模型评分，无论是从这些示例、您的网络搜索还是您的想象中，都受到这些示例的启发。

因此，在本章中，我们将涵盖以下主要主题：

• 调查 MOJO 部署模式的样本

• 探索在 H2O 软件上 MOJO 评分的示例

• 探索在第三方软件上 MOJO 评分的示例

• 探索在您的目标系统软件上 MOJO 评分的示例

• 探索基于 H2O Driverless AI 集成的加速器示例

技术要求

本章没有技术要求，尽管我们将突出展示实现和执行 MOJO 部署模式的技术步骤。

调查 MOJO 部署模式的样本

本章的目的是概述 MOJO 部署以进行预测的多种方式。提供了足够的细节，以便理解 MOJO 部署和评分的背景。提供了链接以查找低级细节。

首先，让我们以表格形式总结我们的 MOJO 评分模式样本，以了解您可以部署 MOJO 的多种不同方式。在概述这个样本之后，我们将更详细地阐述每个表格条目。

注意，我们的部署模式总结的表格列表示如下：

• 数据速度：这指的是评分数据的规模和速度，分为 实时（单条记录评分，通常在 100 毫秒以下）、批量（一次评分大量记录）和 流式（连续的记录流，这些记录被评分）。

• 评分通信：这指的是评分是如何被触发和通信的——例如，通过 REpresentational State Transfer (REST) 调用或 Structured Query Language (SQL) 语句。

• MOJO 部署：这是关于 MOJO 在评分系统上部署的简要描述。

让我们来看看一些部署模式。我们将把这些模式分为四个类别。

H2O 软件

这是您可以在 H2O.ai 提供和支持的软件上部署和评分 MOJO 的示例方法。以下表格提供了这一点的总结：

我们将看到部署到 H2O 软件非常简单，因为你只需上传 MOJO（手动或通过程序）即可。

第三方软件集成

这里有一些使用第三方软件进行 MOJO 评分的示例：

注意，一些第三方集成是通过从部署到 REST 服务器的 MOJO 中消费评分来完成的。这有一个优点，就是可以将您的部署集中在一个地方（REST 服务器），并从许多地方消费（例如，在员工个人电脑上部署的数十个 Tableau 或 MS Excel 实例）。

其他第三方集成是通过在第三方软件系统上直接部署 MOJO 来完成的。例如，Snowflake 集成是在 Snowflake 架构上实现的，允许以 Snowflake 规模进行批量评分（每秒可以评分数十万行）。

您的软件集成

我们将探讨以下将 MOJO 直接集成到您自己的软件中的模式：

将 MOJO 集成到您的软件中需要一个 MOJO 包装类。我们已经在 第九章，生产评分和 H2O MOJO 中学习了如何做这件事。当然，您也可以采取替代方法，将您的软件与从 REST 端点消费的 MOJO 评分集成。

基于 H2O Driverless AI 集成的加速器

本书专注于 H2O Core（H2O-3 和 Sparkling Water）模型构建技术，用于构建针对大量数据的模型。H2O 提供了一种名为 Driverless AI 的替代模型构建技术。Driverless AI 是一个专门的、自动化机器学习（AutoML）引擎，允许用户在极短的时间内找到高度准确和可信的模型。尽管 Driverless AI 无法在 H2O Core 可以处理的巨大数据集上进行训练。然而，Driverless AI 也会生成一个 MOJO，其 MOJO 风格的部署与 H2O Core MOJO 类似。这些相似性已在 第九章 中介绍，生产评分和 H2O MOJO。

在线有许多部署 Driverless AI MOJO 的示例。这些示例可以作为部署 H2O Core MOJO 的指南。因此，以下 Driverless AI 示例可以作为加速器，帮助你快速部署你的 H2O Core MOJO，但某些实现细节可能会有所不同：

这四个表格中显示的图案应该能给你一个很好的感觉，了解你可以以多种方式部署 MOJO。然而，它们并不代表所有可能性的全集。

关于可能性的说明

这里显示的图案仅仅是 H2O MOJO 分数评分模式的一个样本，这些模式存在或可能存在。其他 MOJO 分数模式可以通过网络搜索找到，并且你可以发挥想象力，以多种方式将 MOJO 分数集成到自己的软件中。此外，H2O.ai 正在快速扩展其第三方合作伙伴的评分集成，以及扩展其自身的 MOJO 部署、监控和管理能力。这是一个快速发展的领域。

现在我们已经调查了 MOJO 部署模式的格局，让我们深入探讨每个示例的细节。

探索使用 H2O 软件进行 MOJO 分数评分的示例

本节中的模式代表部署到 H2O 软件的 MOJO。部署到 H2O 软件有许多优点。首先，该软件由 H2O 和他们的机器学习专家团队支持。其次，由于所有你需要的只是提供 MOJO（通过用户界面（UI）、API 或远程复制等传输方式）进行简单上传，因此该部署工作流程对 H2O 软件进行了大幅简化。第三，H2O 评分软件具有额外的功能——例如，对预测和数据漂移进行监控——这对于部署到生产系统的模型非常重要。

让我们从查看 H2O 的旗舰模型评分平台开始。

H2O MLOps

H2O MLOps 是一个功能齐全的平台，用于部署、监控、管理和治理机器学习模型。H2O MLOps 致力于大规模部署模型（许多模型和模型版本、企业级吞吐量和性能、高可用性等），并解决生产中模型周围的监控、管理和治理问题。

H2O MLOps 及其与 H2O 更大 端到端 机器学习平台的关系将在 第十三章，“介绍 H2O AI Cloud” 中进行回顾。有关 MLOps 用户指南，请参阅 docs.h2o.ai/mlops-release/latest-stable/docs/userguide/index.html 以更好地了解 H2O MLOps。

模式概述

下图展示了 H2O MLOps 的评分模式：

图 10.1 – H2O MLOps 的模型评分模式

我们将在下一部分详细阐述。

评分上下文

这是 H2O.ai 的旗舰模型部署、模型监控和模型治理平台。它可以用来托管和评分 H2O 和第三方（非 H2O）模型。

H2O MLOps 实时和批量评分模型。预测可选地返回原因代码。模型以单个模型、冠军/挑战者和 A/B 的形式部署。有关其功能的完整描述，请参阅 其他注意事项 部分。

实现

H2O MLOps 是一个基于 Kubernetes 的现代实现，使用 Terraform 脚本和 Helm 图表进行部署。

评分示例

以下代码片段显示了使用 curl 命令发送的实时评分请求：

curl -X POST -H "Content-Type: application/json" -d @- https://model.prod.xyz.com/9c5c3042-1f9a-42b5-ac1a-9dca19414fbb/model/score << EOF
{"fields":["loan_amnt","term","int_rate","emp_length","home_ownership","annual_inc","purpose","addr_state","dti","delinq_2yrs","revol_util","total_acc","longest_credit_length","verification_status"rows":[["5000","36months","10.65","10",24000.0","RENT","AZ","27.650","0","83.7","9","26","verified"]]}EOF

下面是结果：

{"fields":["bad_loan.0","bad_loan.1"],"id":"45d0677a-9327-11ec-b656-2e37808d3384","score":[["0.7730158252427003","0.2269841747572997"]]} 

从这里，我们看到贷款违约的概率（bad_loan 值为 1）为 0.2269841747572997。id 字段用于标识 REST 端点，当模型以冠军/挑战者或 A/B 测试模式部署时，这很有用。

其他注意事项

这里是 H2O MLOps 关键功能的简要总结：

• 多种部署模型：独立；冠军/挑战者；A/B 模型

• 多种模型问题：表格；时间序列；图像；语言模型

• Shapley 值：在部署时，指定是否与预测一起返回 Shapley 值（原因代码）

• 第三方模型：评分和监控非 H2O 模型——例如，scikit-learn 模型

• 模型管理：模型注册；版本控制；模型元数据；晋升和审批工作流程

• APIs：API 和 持续集成和持续交付（CI/CD）集成

• 分析：可选地将评分数据推送到您的系统进行自己的分析

• 血缘：了解数据、实验和模型的血缘关系

• 模型监控：数据漂移和预测监控，带有警报管理（偏差和其他类型的监控在 MLOps 路线上）

  H2O MLOps 与其他 H2O 模型评分软件的比较

  MLOps 是 H2O 的旗舰全功能平台，用于部署、监控和管理评分模型。H2O 提供其他软件（将在下一部分概述），这些软件专门用于解决 MLOps 可能不适用的情况。

接下来，让我们看看 H2O REST 评分器。

H2O eScorer

H2O 有一个轻量级但功能强大的 REST 服务器来评分 MOJOs，称为 H2O eScorer。这是一个很好的替代方案，用于作为 REST 端点提供服务 MOJOs，而不必承诺更大的 H2O MLOps 平台的基础设施要求，因此可以自由选择本地和轻量级部署。  回想一下，第三方软件通常通过 REST 端点集成与 MOJOs 集成，因此这是一种有效的方法。

模式概述

H2O REST 评分器的评分模式如下所示：

图 10.2 – H2O REST 评分器的 MOJO 评分模式

这里有一些详细说明。

评分上下文

H2O REST 评分器对 REST 端点进行实时和批量预测。预测可选地包括原因代码。

实现

H2O Rest 评分器是一个包含 Apache Tomcat 服务器的单个Java ARchive（JAR）文件，该服务器托管一个 Spring REST 服务框架。一个属性文件配置应用程序以托管多个 REST 评分端点。MOJOs 可以通过 REST 本身或其他方式将 MOJO 传输到服务器加载。

通过将多个 H2O REST 评分器放置在负载均衡器后面，可以实现高吞吐量。

评分示例

这里有一些实时评分的 REST 端点示例：

http://192.1.1.1:8080/model?name=riskmodel.mojo &row=5000,36months,10.65,162.87,10,RENT,24000,VERIFIED-income,AZ,27.65,0,1,0,13648,83.7,0"

REST 评分器的 REST API 非常灵活。例如，它包括多种结构有效载荷的方式（例如，观测输入可以发送为逗号分隔值（CSV）、JavaScript 对象表示法（JSON）或其他结构，评分输出以相同格式返回，这对于与 BI 工具集成来说很方便）。

其他注意事项

这里是 H2O REST 评分器功能集的总结：

• 每个 H2O Rest 评分器可以评分多个模型（即 MOJOs），每个模型都有自己的 REST 端点。

• 通常，每个 H2O REST 评分器服务器上的每个 CPU 每秒可以完成 1,000 个评分。

• 安全、监控和日志设置可以在属性文件中配置。

• Java 监控 Bean（JMX）可以配置，以便您的监控工具可以收集和分析运行时统计信息。监控包括评分错误、评分延迟和数据漂移。

• 安全功能包括HTTPS、管理员身份验证、经过身份验证的端点URI和来自 IP 前缀的有限访问。

• 有大量的日志记录。

• 通过 REST API 提供了广泛的功能，包括获取模型元数据、定义预测输出格式、定义日志详细程度以及管理服务器上的 MOJOs。

• REST API 可以生成来自不同 BI 工具发送到 H2O REST 评分器评分模型的示例请求——例如，用于调用 Power BI 模型的 Python 代码示例。

接下来，我们将查看 H2O 批处理数据库评分器。

H2O 批处理数据库评分器

H2O 批处理数据库评分器是一个客户端应用程序，它可以通过 Java 数据库连接 (JDBC) 连接对表执行批量预测。

模式概述

H2O 批处理数据库评分器模式如图所示：

图 10.3 – H2O 批处理数据库评分器的 MOJO 评分模式

我们将在下面详细说明。

评分上下文

H2O 批处理数据库评分器对数据库表执行批量预测。预测可以包含原因代码。根据配置方式的不同，对表行的预测可以插入到新的表中，或者更新到正在评分的同一表中。或者，它可以生成预测结果的 CSV 文件。此 CSV 输出可用于手动更新表或其他下游处理。

H2O 批处理数据库评分处理的详细序列显示在 图 10.3 中。

实现

H2O 批处理数据库评分器是一个单独的 JAR 文件，可以从 H2O.ai 获取。该 JAR 文件使用属性文件来配置数据库工作流程的各个方面。

更具体地说，属性文件包含以下内容：

• SQL 连接字符串

• 批量评分的 SQL SELECT 语句

• 写入预测结果的 SQL INSERT 或 UPDATE 语句

• 批量评分时的线程数

• MOJO 路径

• 标志以写入 CSV 或不写入

• 安全设置

• 其他设置

评分示例

以下命令显示了如何从命令行运行批量作业：

java -cp /PostgresData/postgresql-42.2.5.jar:H2OBatchDB.jar \ ai.h2o.H2OBatchDB

当然，这可以集成到调度器或脚本中，以安排和自动化批量评分。

注意，此命令不包含有关数据库或表的信息。从该命令启动的程序会找到属性文件，如前一个 实现 小节所述，并使用那里的信息来驱动批量评分。

其他注意事项

单个属性文件包含运行单个批量评分作业所需的所有信息（属性文件映射到将要评分的表的 SQL 语句）。

如果在评分的 Java 命令中没有指定属性文件（请参阅 评分示例 部分），则使用默认的属性文件。或者，可以在 Java 命令行中指定特定的属性文件以运行非默认评分作业。

接下来，让我们看看 H2O 批处理文件评分器。

H2O 批处理文件评分器

H2O 批处理文件评分器是一个可以对文件中的记录执行批量预测的应用程序。

模式概述

H2O 批处理文件评分模式如图所示：

图 10.4 – H2O 批处理文件评分器的 MOJO 评分模式

这就是它的使用方法。

评分上下文

评分是对文件中的记录进行批处理，输出将是一个与输入文件相同的文件，但每个记录都附加了一个评分字段。输出文件保留在 H2O 批处理评分器系统中，直到由另一个系统（例如，复制到下游系统进行处理）处理。

实现

H2O 批处理文件评分器是一个单 JAR 文件，由 H2O.ai 提供。使用命令行参数指定模型的存储位置和输入文件，以及任何运行时参数，例如跳过文件中存在的列标题。

评分示例

以下命令显示了如何从命令行运行批处理文件作业：

java -Xms10g -Xmx10g -Dskipheader=true -Dautocolumns=true -classpath mojo2-runtime.jar:DAIMojoRunner_TQ.jar daimojorunner_tq.DAIMojoRunner_TQ pipeline.mojo LoanStats4.csv

有几点值得注意。

其他注意事项

此评分器非常适合作为单个任务处理极大的文件（> GB），使其在传统批处理工作流程中易于使用。如果输入文件包含标题，则评分器将选择正确的列传递给模型；如果没有标题，则可以将列作为命令行参数传递。

现在让我们看看 H2O Kafka 评分器。

H2O Kafka 评分器

H2O Kafka 评分器是一个与 Kafka 流评分集成的应用程序。

模式概述

H2O Kafka 评分器模式如图所示：

![图 10.5 – H2O Kafka 评分器的 MOJO 评分模式

图 10.5 – H2O Kafka 评分器的 MOJO 评分模式

评分上下文

评分对流的展示如图10.5所示。具体来说，H2O Kafka 评分器从主题队列中拉取消息并将评分结果发布到另一个主题。

实现

H2O Kafka 评分器是一个在 Kafka 系统上实现的 JAR 文件。使用属性文件配置要消费的主题（因此要评分的消息）以及要发布到哪个主题（将结果发送到何处）。当 H2O Kafka 评分器 JAR 文件启动时，它加载 MOJO 并监听来自该主题的传入消息。

评分示例

当消息到达上游主题时进行评分。将预测附加到原始消息的最后一个字段。然后将这个新消息发送到另一个主题进行下游处理。

其他注意事项

通过使用其分布式并行化架构中固有的原生 Kafka 扩展技术来实现扩展吞吐量。

最后，让我们看看 Spark 上的 H2O 批处理评分。

Spark 上的 H2O 批处理评分

H2O MOJO 可以作为原生 Spark 作业部署。

模式概述

Spark 上的 H2O 批处理评分模式如图所示：

![图 10.6 – Spark 上 H2O 批处理评分的 MOJO 评分模式

图 10.6 – Spark 上 H2O 批处理评分的 MOJO 评分模式

评分上下文

评分是批处理并在 Spark 集群上进行的。因此，批处理评分是分布式的，因此可以很好地扩展到巨大的批处理大小。

实现

在 Spark 集群上评分 MOJO 所需的依赖项与以下部分中显示的 spark-submit 命令一起分发。

评分示例

首先，我们将创建一个 myRiskScoring.py。代码如下所示：

from pysparkling.ml import *

settings = H2OMOJOSettings(convertUnknownCategoricalLevelsToNa = True, convertInvalidNumbersToNa = True)

model_location="hdfs:///models/risk/v2/riskmodel.zip"

model = H2OMOJOModel.createFromMojo(model_location, settings")

predictions = model.transform(dataset)

// do something with predictions, e.g. write to hdfs

然后，使用 H2O 评分库提交您的 Spark 作业，如下所示：

./bin/spark-submit \
    --py-files py/h2o_pysparkling_scoring.zip \
    myRiskScoring.py

注意，h2o_pysparkling_scoring.zip 依赖项将与作业一起分发到集群中。此库由 H2O.ai 提供。

补充说明

除了之前代码示例中显示的评分设置外，还有其他评分设置可用。以下链接将提供更多详细信息：docs.h2o.ai/sparkling-water/3.1/latest-stable/doc/deployment/load_mojo.html。

我们已经完成了对 H2O 软件上一些评分模式的审查。现在让我们过渡到第三方软件上的评分模式。

探索使用第三方软件的 MOJO 评分示例

现在我们来看一些涉及第三方软件的评分示例。

Snowflake 集成

H2O.ai 与 Snowflake 合作，将 MOJO 评分集成到 Snowflake 表中。需要注意的是，在此集成中部署的 MOJO 是在 Snowflake 架构上，因此实现了 Snowflake 的原生可扩展性优势。结合 MOJO 评分的低延迟，可以在几秒钟内对大量 Snowflake 表进行批量评分，尽管对少量记录的实时评分也是可行的。

模式概述

Snowflake 集成模式在以下图中显示：

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/ml-scl-h2o/img/B16721_10_007.jpg)

图 10.7 – Snowflake Java 用户自定义函数 (UDF) 集成的 MOJO 评分模式

让我们详细说明。

评分上下文

评分是针对 Snowflake 表的批量操作，并利用 Snowflake 平台的扩展性。因此，评分可以对任何 Snowflake 表进行，包括那些包含大量数据集的表。

评分是通过从 Snowflake 客户端运行 SQL 语句来完成的。这可以是本机 Snowflake 工作表、SnowSQL 或具有 Snowflake 连接器的 SQL 客户端。或者，评分可以通过使用 Snowflake 的 Snowpark API 编程来完成。

实现

要实现评分，创建一个临时表并对其授予权限。然后，将您的 MOJO 和 H2O JAR 文件依赖项复制到临时表中。

然后，您可以使用 SQL 创建一个 Java UDF，导入这些依赖项并将处理评分的 H2O 依赖项分配给处理器。然后，在创建 SQL 评分语句时引用此 UDF，如下所示。

你可以在这里找到 H2O 依赖项和说明：s3.amazonaws.com/artifacts.h2o.ai/releases/ai/h2o/dai-snowflake-integration/java-udf/download/index.html。

使用 UDF 与 Snowflake 集成的集成体验也在线上提供，请访问 cloud.h2o.ai/v1/latestapp/wave-snowflake。

评分示例

这是一个执行批量评分的 SQL 语句的示例：

select ID, H2OScore_Java('Modelname=riskmodel.zip', ARRAY_CONSTRUCT(loan_amnt, term, int_rate, installment, emp_length, annual_inc, verification_status, addr_state, dti, inq_last_6mths, revol_bal, revol_util, total_acc)) as H2OPrediction from RiskTable;

注意，H2O 评分 UDF（如实现部分所示加载）正在运行，并且引用了模型名称（MOJO 名称）。

其他注意事项

为了更程序化的方法，你可以使用 Snowpark API 而不是 SQL 语句来进行批量评分。

替代实现 – 通过 Snowflake 外部函数进行评分

对于你不想直接将 MOJO 部署到 Snowflake 环境的情况，你可以在 Snowflake 上实现一个外部函数，然后将评分传递给 H2O eScorer 实现。请注意，评分本身是外部于 Snowflake 的，批处理吞吐量由 H2O eScorer 决定，而不是 Snowflake 架构。这在下图中显示：

![图 10.8 – MOJO 评分模式用于 Snowflake 外部函数集成

![图片 B16721_10_008.jpg]

图 10.8 – MOJO 评分模式用于 Snowflake 外部函数集成

为了实现这一点，我们将以 AWS 上的 Snowflake 为例。请按照以下步骤操作：

1. 首先，使用 Snowflake 客户端将 api_integration 创建为 aws_api_gateway。需要一个网关来在向 H2O eScorer（它将位于 Snowflake 之外）通信时保护外部函数。你需要有正确的角色来创建此网关。

2. 然后，使用 SQL 在 Snowflake 上创建一个外部函数，例如命名为 H2OPredict。外部函数将引用 api_integration。

3. 现在，你已经准备好通过外部函数传递到 H2O eScorer 来批量评分 Snowflake 表。以下是一个示例 SQL 语句：

   select ID, H2OPredict('Modelname=riskmodel.zip', loan_amnt, term, int_rate, installment, emp_length, annual_inc, verification_status, addr_state, dti, inq_last_6mths, revol_bal, revol_util, total_acc) as H2OPrediction from RiskTable;
   

让我们看看 Teradata 集成。

Teradata 集成

H2O.ai 与 Teradata 合作，直接针对 Teradata 表实现批量或实时评分。这如下所示：

![图 10.9 – MOJO 评分模式用于 Teradata 集成

![图片 B16721_10_009.jpg]

图 10.9 – 与 Teradata 集成的 MOJO 评分模式

评分上下文

评分是针对 Teradata 表进行批处理，并利用了 Teradata 平台的扩展性。因此，可以对任何 Teradata 表进行评分，包括那些包含大量数据集的表。在概念上与 Snowflake UDF 集成相似，但仅在概念上：底层架构和实现是根本不同的。

通过 Teradata 客户端运行 SQL 语句来对 Teradata 表进行评分。这可以是本机 Teradata Studio 客户端或具有 Teradata 连接器的 SQL 客户端。

实现

要实现，您首先必须安装 Teradata Vantage Bring Your Own Model (BYOM)。然后，您使用 SQL 创建一个 Vantage 表来存储 H2O MOJOs。然后，您使用 SQL 将 MOJOs 加载到 Vantage 表中。详细信息请参阅docs.teradata.com/r/CYNuZkahMT3u2Q~mX35YxA/WC6Ku8fmrVnx4cmPEqYoXA。

评分示例

下面是一个用于批量评分 Teradata 表的 SQL 语句示例：

select * from H2OPredict(

on risk_table

on (select * from mojo_models where model_id=riskmodel) dimension

using Accumulate('id')

) as td_alias;

在这种情况下，代码假设所有risk_table字段都作为输入传递给 MOJO。

其他注意事项

您的批量评分 SQL 语句可能包括返回原因代码、阶段概率和叶节点分配的选项。

BI 工具集成

MOJO 评分的一个强大用途是集成到 BI 工具中。最常见的方法是在 REST 服务器或数据库上实现 MOJO 评分，如下面的图所示。请注意，在此模式中，MOJO 没有部署在 BI 工具本身上，而是工具与外部评分系统集成。MOJO 评分的低延迟特性允许用户通过此模式实时与 MOJO 预测进行交互：

图 10.10 – MOJO 评分模式用于 BI 工具集成

评分上下文

BI 工具集成了外部评分器的实时预测。

实现

实现外部 REST 或数据库 MOJO 评分系统。在 BI 工具中实现与外部评分器的集成。这些集成针对每个 BI 工具都是特定的，通常，单个 BI 工具有多种方法来实现这种集成。

评分示例 – Excel

下面的代码块显示了在 Excel 电子表格的单元格中创建的公式：

=WEBSERVICE(CONCAT("http://192.1.1.1:8080/modeltext?name=riskmodel.mojo&row=",TEXTJOIN(","FALSE, $A4:$M4))))

当公式应用于目标单元格，或者公式中引用的任何单元格的值发生变化时，都会调用此网络服务。然后，用户可以将公式向下拖动到列中，让预测填充该列。

注意在先前的公式中，REST 调用将待评分的观察结果组成 CSV 而不是 JSON。此有效负载的结构特定于 REST API 及其端点。

我们可以使用类似的方式将 MOJO 评分集成到其他第三方软件中，尽管端点构造的语义不同。让我们看看如何在 Tableau 中实现它。

评分示例 – Tableau

Tableau 是企业内部常用的仪表板工具，用于向组织内的各种不同用户展示信息。

使用 Tableau 脚本语法，可以从仪表板调用模型。这非常强大，因为现在，业务用户可以直接在仪表板上按需获取当前的预测结果。您可以在以下示例脚本中看到示例：

SCRIPT_STR(

'name'='riskmodel.mojo',

ATTR([./riskmodel.mojo]),

ATTR([0a4bbd12-dcad-11ea-ab05-024200eg007]),

ATTR([loan_amnt]),

ATTR([term]),

ATTR([int_rate]),

ATTR([installment]),

ATTR([emp_length]),

ATTR([annual_inc]),

ATTR([verification_status]),

ATTR([addr_state]),

ATTR([dti]),

ATTR([inq_last_6mths]),

ATTR([revol_bal]),

ATTR([revol_util]),

ATTR([total_acc]))

脚本将值作为属性（ATTR 关键字）读取，并在对模型进行 REST 调用时将它们传递到 Tableau 环境中的脚本。使用 REST 调用允许集中部署和管理模型，但不同的应用程序和消费者根据其特定需求调用模型。

现在，让我们看看如何在 Power BI 中构建 REST 端点。

评分示例 – Power BI

这里是一个 Power BI 的评分示例。在这种情况下，我们使用了一个 Web.Contents Power Query M 函数。此函数粘贴到您 Power BI 仪表板中的所需元素：

Web.Contents(

    "http://192.1.1.1:8080",

    [

        RelativePath="modeltext",

        Query=

        [

            name="riskmodel.mojo",

            loan_amnt=Loan_Ammt,

            term=Term,

            int_rate=Int_Rate,

            installment=Installments,

            emp_length=Emp_Length,

            annual_inc=Annual_Inc,

            verification_status=Verification_Status,

            addr_state=Addr_State,

            dti=DTI,

            inq_last_6mths= Inq_Last_6mths,

            revol_bal=Revol_Bal,

            revol_util=Revol_Util,

            total_acc=Total_Acc

        ]

    ]

)

让我们从这些具体示例中概括一下。

其他注意事项

每个 BI 工具都以自己的方式与 REST 端点或数据库集成，并且通常提供多种集成方式。有关详细信息，请参阅您的 BI 工具文档。

UiPath 集成

UiPath 是一个基于人类行为的自动化工作流的 RPA 平台。做出预测并对这些预测做出响应是这一自动化的重要组成部分，因此在这些工作流步骤中进行评分模型是一个完美的选择。您可以在以下图中看到这个示例：

图 10.11 – UiPath 集成 MOJO 评分模式

评分上下文

UiPath 与外部 MOJO 评分的集成方式与上一节中展示的 BI 工具类似。在 UiPath 的情况下，配置了一个工作流步骤来执行 REST 调用，接收预测，并对该预测做出响应。

实现

MOJO 评分在外部 REST 服务器上实现，并使用 UiPath Request Builder 向导配置 REST 端点以返回预测。详细信息请见此处：www.uipath.com/learning/video-tutorials/application-integration-rest-web-service-json。

评分示例

这段视频展示了如何使用 H2O MOJO 评分自动化工作流：www.youtube.com/watch?v=LRlGjphraTY。

我们刚刚完成了一些第三方软件 MOJO 评分模式的调查。让我们看看一些您组织自行构建的软件的评分模式。

使用目标系统软件探索 MOJO 评分示例

除了在 H2O 和第三方软件上部署 MOJO 进行评分外，您还可以采取DIY（DIY）方法，在自己的软件中部署评分。让我们看看如何做这件事。

您的软件应用程序

从您的软件中评分有两种方式：集成外部评分系统或直接在软件系统中嵌入评分。

以下图显示了与外部评分系统集成模式的示例：

图 10.12 – 外部评分的 MOJO 应用评分模式

这种模式应该看起来很熟悉，因为它与我们之前在 BI 工具中看到的评分方式在本质上是一样的：您的软件作为客户端来消费另一个系统生成的 MOJO 预测。外部预测系统可以是部署在 REST 服务器上的 MOJO（例如，H2O REST 评分器）或批量数据库评分器（例如，Snowflake Java UDF 或 H2O 批量数据库评分器）或另一个外部系统，而您的应用程序需要实现连接到该系统的库。

与此相反，以下图表显示了将 MOJO 评分直接嵌入到您应用程序本身的模式：

图 10.13 – 嵌入式评分的 MOJO 应用评分模式

这样做需要您的应用程序实现一个使用 H2O MOJO API 加载 MOJO 并用其评分数据的 Java 包装类。这在第九章中详细展示，生产评分和 H2O MOJO。

您应该在何时使用外部评分模式与嵌入式评分模式？当然，每种模式都有其优点和缺点。

外部评分模式将评分与应用程序解耦，因此允许每个组件及其相关角色专注于其最擅长的事情。例如，应用程序开发者可以专注于开发应用程序，而不是部署和监控模型。此外，外部评分组件可以重用，以便许多应用程序和客户端可以连接到同一部署的模型。最后，尤其是在数据库端评分（例如，Java UDF 和 Teradata 集成）以及具有极端批量大小或吞吐量的流评分的情况下，尝试自行构建这将是困难的或愚蠢的。

嵌入式评分模式的优势在于消除了发送观察和预测到网络的时间成本。这取决于您的服务级别协议（SLA）是否重要。它确实简化了执行评分的基础设施需求，尤其是在网络基础设施不可用或不稳定的情况下。最后，出于监管原因，可能希望或有必要将模型部署和应用程序作为一个单一实体来管理，从而要求两者耦合。

设备端评分

MOJO 可以部署到设备上，无论是办公室扫描仪/打印机、医疗设备还是传感器。这些可以被视为小型应用程序，对于外部或嵌入式评分的决定，设备与应用程序一样，如前所述。然而，在设备的情况下，外部与嵌入式评分的优缺点可能会被放大很多。例如，物联网（IoT）传感器可能成千上万，在这些设备上部署和管理模型的开销可能超过由于网络通信到中央外部评分器的延迟增加所带来的成本。

重要提示

一个经验法则是可用设备内存需要超过 MOJO 大小的两倍。

探索基于 H2O Driverless AI 集成的加速器示例

到目前为止，本书主要关注使用 H2O 构建大规模模型。我们一直使用 H2O Core（通常称为 H2O 开源版），这是一个可以扩展到海量数据集的分布式机器学习框架。在第十三章介绍 H2O AI Cloud中，我们将看到 H2O 提供了一个更广泛的由端到端平台 H2O AI Cloud 表示的功能集。其中一项功能是一个高度专注的基于 AI 的 AutoML 组件，称为 Driverless AI，我们将在第十三章**介绍 H2O AI Cloud中区分这一点。

Driverless AI 与 H2O Core 类似，因为它也使用通用的 MOJO 运行时和 API 生成可部署的 MOJO，尽管对于 Driverless AI，MOJO 部署需要许可证文件，并且 MOJO 和运行时命名与 H2O Core 不同。

提及这一点的原因是，已经构建了几个 Driverless AI 的集成，并且有很好的文档记录，但并没有为 H2O Core 建立类似的集成。这些集成及其文档可以用作加速器，以对 H2O Core 执行相同的操作。请记住，部署 H2O Core MOJO 不需要许可证要求，并且 MOJO 和运行时命名不同。

描述加速器的方法

这里概述了加速器，并提供了链接，以便您了解其实施细节。正如所提到的，这些加速器代表了从 H2O Driverless AI AutoML 工具生成的 MOJO 的部署。请参阅第九章**生产评分和 H2O MOJO，了解从 H2O Core（H2O-3 或 Sparkling Water）生成的 MOJO 与从 Driverless AI 生成的 MOJO 基本相同，但在命名和 MOJO API 方面有所不同。这些知识将使您能够实现链接中显示的 H2O Core MOJO 的 Driverless AI MOJO 细节。

让我们看看一些示例。

Apache NiFi

Apache NiFi 是一种 开源软件（OSS），旨在以 UI 和拖放方式编程数据的流动。它围绕通过不同可配置的处理器移动数据的概念构建，这些处理器以特殊的方式处理数据。结果数据流允许处理器序列的子流分支、合并和嵌套，通常类似于复杂的 有向无环图（DAGs）。项目主页可在此处找到：nifi.apache.org/index.html。

NiFi 处理器可以用于与外部的 REST、JDBC 和 Kafka 系统进行通信，从而可以利用来自外部系统的评分 MOJOs 模式。

然而，您可以为处理器构建自己的处理器，将 MOJO 嵌入其中以进行实时或批量评分。此处理器只需要配置以指向 MOJO 及其依赖项。以下链接展示了如何为 Driverless AI 做这件事，并可作为使用 H2O Core 进行相同操作的加速器：github.com/h2oai/dai-deployment-examples/tree/master/mojo-nifi。

Apache Flink

Apache Flink 是一个高吞吐量的分布式流和批量处理引擎，具有丰富的功能集，可以以容错的方式运行事件驱动、数据分析和数据管道应用程序。

以下链接展示了如何将 Driverless AI MOJOs 嵌入以直接对 Flink 数据流进行评分，并可作为使用 H2O Core 进行相同操作的加速器：github.com/h2oai/dai-deployment-examples/tree/master/mojo-flink。

AWS Lambda

AWS Lambda 是一种无服务器计算服务，允许您在不建立、管理和支付底层服务器基础设施的情况下运行代码。它可以执行任何短暂且无状态的计算任务，因此非常适合处理评分请求。以下加速器展示了如何实现 AWS Lambda 作为 REST 端点进行实时或批量 MOJO 评分：h2oai.github.io/dai-deployment-templates/aws_lambda_scorer/。

AWS SageMaker

AWS SageMaker 可以用于托管和监控模型评分。以下加速器展示了如何实现 REST 端点进行实时 MOJO 评分：h2oai.github.io/dai-deployment-templates/aws-sagemaker-hosted-scorer/。

现在，我们已经完成了对 H2O MOJOs 评分和部署模式的调查。当您的 H2O-at-scale 模型部署到生产系统时，它们实现了业务价值。这里展示的例子只是几种可能性，但它们应该能给您一个关于 MOJO 部署和评分多样性的概念。

让我们总结一下本章所学的内容。

摘要

在本章中，我们探讨了多种部署 MOJOs 和消费预测的方法。这包括对实时、批量以及流式数据进行评分，以及使用 H2O 软件、第三方软件（例如 BI 工具和 Snowflake 表）以及您自己的软件和设备进行评分。从这些示例中可以明显看出，H2O 模型部署的可能性极为多样，因此能够满足您特定的评分需求。

现在我们已经学会了如何将 H2O 模型部署到生产评分环境中，让我们退后一步，以参与实现 H2O 在大规模机器学习成功所需的全部步骤的企业利益相关者的视角来看待问题。在下一节中，我们将从这些利益相关者的需求和关注点出发，来观察大规模的 H2O。

第四部分 – 企业利益相关者视角

在本节中，我们戴上企业利益相关者的帽子，学习如何规划、部署、管理、维护和确保 H2O 大规模平台的安全性。您将首先了解企业 Steam 如何与企业服务器集群和安全环境集成 H2O。然后，您将学习如何配置企业 Steam 来管理用户并定义他们 H2O 模型构建环境的大小，从而控制企业集群的资源消耗和成本。从那里，我们学习支持使用 H2O 进行模型构建和部署的关键操作领域。最后，我们从多个架构视角了解 H2O 架构和安全的细节。数据科学家将了解这些活动如何与他们的自身需求相关联。

本节包含以下章节：

• 第十一章, 管理员和操作视图

• 第十二章, 企业架构师和安全视图

第十一章：管理员和运维视图

到目前为止，我们在本书中花费了大量时间了解 H2O 大规模机器学习框架的组件，并深入挖掘以开发在企业系统中实施模型构建和模型部署框架的技能。

机器学习的成功需要代码和技术技能，但在企业中，还需要在人员和流程方面的成功。从另一个角度来看，那句“成功是团队运动”的谚语非常真实。现在，让我们开始查看参与将 H2O 大规模机器学习成功带到现实中的角色或利益相关者。

在本章中，我们将首先解决直接参与这一成功的人物：H2O 管理员、运维团队和数据科学家。我们将了解关键利益相关者如何在大规模模型构建和模型部署中与 H2O 互动。我们将查看 H2O 管理员在大规模 H2O 中的视图，并了解企业蒸汽如何成为这一视图的核心。我们还将查看运维团队在大规模模型构建和模型部署中的 H2O 视图。最后，我们将了解数据科学家如何受到 H2O 管理员和运维团队视图的影响。

在本章中，我们将涵盖以下主要主题：

• 模型构建和部署视图：地面角色

• 视图 1：企业蒸汽管理员

• 视图 2：运维团队

• 视图 3：数据科学家

模型构建和部署视图 – 地面角色

许多角色或利益相关者参与了机器学习生命周期。在大规模 H2O 模型构建和部署中涉及的关键角色是数据科学家、企业蒸汽管理员和运维团队。本章的重点是这些角色。让我们从以下图表中获得他们活动的概述：

图 11.1 – 在大规模构建和部署 H2O 模型中涉及的关键角色

这些利益相关者和他们的高级关注点的总结如下：

• 企业蒸汽管理员：管理谁在企业服务器集群上启动 H2O 集群以及他们被允许消耗多少资源，并在服务器集群上集中管理 H2O 集成

• H2O 集群操作：在企业服务器集群（无论是 Kubernetes 还是 Hadoop 集群）上调试 H2O 作业

• 模型运维：部署、管理和监控部署到评分环境中的模型

• 数据科学家：在本章中，了解如何以及为什么与上述角色互动

本章的其余部分将致力于深入探讨这些角色在 H2O 大规模机器学习工作中的视图和活动。

让我们开始吧。

视图 1 – 企业蒸汽管理员

在了解他们的活动之前，让我们首先看看企业蒸汽管理员的关注点。

企业蒸汽管理员关注点

企业蒸汽管理员有两个主要关注点，如下所示图表所示：

![图 11.2 – 企业蒸汽管理员关注点

图 11.2 – 企业蒸汽管理员关注点

以下是对前述图表的总结：

• H2O 用户治理：这些关注点集中在治理数据科学家，他们在企业服务器集群上启动 H2O 模型构建作业。这包括将这些 H2O 用户与企业身份提供者进行身份验证、为 H2O 用户定义角色以及在企业服务器集群环境中治理 H2O 用户的资源消耗。

• H2O 系统管理：这些关注点围绕着将 H2O 技术与企业服务器集群的集成进行集中，并管理 H2O 软件版本。这创造了一个角色分离，现在数据科学家不需要了解这种集成的复杂性（如果实施了企业蒸汽，他们就会了解）。

企业蒸汽可以被视为处理企业关注点的必需品。

企业蒸汽对企业的价值

企业在管理谁使用企业系统、用户如何与企业系统集成以及用户如何使用系统上的资源方面往往非常谨慎。管理员使用企业蒸汽来构建集中的安全措施来处理这些关注点，并创建 H2O 使用的统一性和可预测性。企业蒸汽还使数据科学家更容易，因为他们不需要了解将 H2O 与企业系统集成的技术复杂性。

要欣赏企业蒸汽的好处，看看它在数据科学家使用 H2O 构建大规模模型的工作流程中所扮演的角色是有用的。这总结在下述图表中：

![图 11.3 – 通过企业蒸汽的数据科学和管理员工作流程

图 11.3 – 通过企业蒸汽的数据科学和管理员工作流程

基本上，企业蒸汽位于所有数据科学家对企业服务器集群上 H2O 访问的前端。让我们一步一步地了解这种设计的优势：

1. 数据科学家通过企业蒸汽进行身份验证：所有使用 H2O 的数据科学家都通过企业身份提供者进行身份验证，例如 LDAP。我们将在本章后面看到，从身份提供者返回的组成员资格用于配置特定于组的用户能力。

2. 启动 H2O 集群：数据科学家必须通过企业蒸汽在企业管理服务器集群上启动 H2O 集群。在这个过程中，数据科学家将获得有关可以启动的 H2O 集群大小（服务器节点数量、每个节点的内存和 CPU）以及运行多长时间后关闭的限制。我们将在本章后面看到企业蒸汽管理员如何使用 配置文件 来定义这些限制。

注意，配置 H2O 以与企业服务器集群的具体细节集成涉及很多复杂性。这由企业蒸汽管理员通过企业蒸汽的配置工作流程来处理。数据科学家免于这项任务，只需使用企业蒸汽 UI（或从模型构建 IDE 的 API）快速启动 H2O 集群。

1. 构建模型：从模型构建 IDE，数据科学家必须使用企业蒸汽 API 进行身份验证，然后才能与已启动的 H2O 集群交互。通过企业蒸汽进行身份验证后，数据科学家将能够连接到他们的 H2O 集群并编写代码在其上构建模型。

注意，上述工作流程中的所有步骤都可以从数据科学家的 IDE 中以编程方式完成，无需与企业蒸汽 UI 交互。

企业蒸汽 UI 与 API 的比较

从企业蒸汽 UI 管理一个或多个 H2O 集群（启动、停止、重新启动、终止）非常方便。或者，您也可以通过使用相同的 Enterprise Steam API（当您从 IDE 连接到集群以构建模型时用于验证企业蒸汽）在您的 IDE 中完成此操作。因此，如果您愿意，您可以从 IDE 完成所有工作。

现在我们回到企业蒸汽管理员在管理 H2O 用户和管理 H2O 系统及集成中的角色。

企业蒸汽配置

让我们直接进入企业蒸汽的主配置屏幕。这将帮助我们在大致了解 H2O 用户治理和 H2O 系统管理之前，专注于这些内容。以下截图展示了这一点。请记住，只有企业蒸汽管理员才能查看和访问这些配置：

图 11.4 – 企业蒸汽配置主页（仅管理员可见）

让我们逻辑地组织这些内容：

• H2O 用户治理：这是使用 访问控制 配置集来完成的。请注意，这些配置还包括用户资源消耗治理和其他安全措施。

• H2O 系统管理 – 集成：使用 BACKENDS 和 PRODUCTS 配置集来完成与企业集群环境的集成配置。这还包括管理 H2O 版本。

• H2O 系统管理 – Steam：配置企业 Steam 本身是通过使用 STEAM CONFIGURATION 配置集来完成的。

  无需人工干预的 AI 可以在 Enterprise Steam 中配置（等等，是什么意思？）

  本书重点关注使用 H2O 的规模机器学习。从模型构建的角度来看，这侧重于通过这些创建的水平扩展架构在大量数据集上训练的 H2O-3 或 Sparkling Water 集群。

  无需人工干预的 AI 是一个针对极端 AutoML（通常在小于 100-200 GB 的数据集上）专门设计的 H2O 产品，它利用广泛的自动化、遗传算法来寻找最佳模型以及高度自动化和详尽的特征工程。当我们在 第十三章 中介绍 H2O.ai 的端到端机器学习平台 Introducing H2O AI Cloud 时，我们将更详细地介绍无需人工干预的 AI。我们将看到在该章中，无需人工干预的 AI 如何增强 H2O-3 和 Sparkling Water 的规模使用。现在，请了解无需人工干预的 AI 也可以通过 Steam（在 Kubernetes 集群上）启动和管理。

让我们逐一详细说明前面的要点。

企业 Steam 从 H2O 用户治理

企业 Steam 管理员使用 GENERAL > ACCESS CONTROL 配置集来管理 H2O 集群的用户。以下是对这些配置的概述。

认证

可以配置以下企业身份提供者以对 Enterprise Steam 和因此启动的 H2O 集群进行用户认证：

• OpenID

• LDAP

• SAML

• PAM

根据所选提供者配置详细的熟悉设置。

令牌

在使用企业 Steam API 时，令牌是使用密码的替代方案。此处为已登录用户颁发令牌。每次生成令牌时，之前颁发的令牌将被撤销。在 OIDC 认证的情况下，用户必须获取令牌才能使用 API（不能使用单点登录（SSO）密码）。

用户

通过企业 Steam 认证的用户列在此页上。用户按用户名、角色和认证方法列出。用户可以从这里停用和重新激活。

可以在此处执行对单个用户角色的覆盖、认证方法和配置文件分配。请注意，用户的角色、认证方法和配置通常是通过映射到他们所属的组并由此身份提供者返回的组来分配的。另外请注意，当用户存在于多个启用的身份提供者系统中时，可以在此处覆盖启用的身份提供者的用户配置。

角色

企业 Steam 中有两种角色：

• 管理员：具有管理员角色的登录用户可以按照本章所述进行配置更改。

• 标准用户：登录并具有标准用户角色的用户是数据科学家，他们可以从企业 Steam 启动集群，如图 11.3所示。这种用户体验在第三章中描述得更为详细，基本工作流程 - 数据到可部署模型。

注意，可以通过组名（从身份提供者进行身份验证返回）分配角色。您还可以提供带有通配符字符 * 的组名，以将角色分配给所有经过身份验证的用户。

配置文件

这就是用户在他们的 H2O 集群资源消耗上被给予边界的地方。这些边界分配给一个具有名称的配置文件，并且配置文件映射到一个或多个用户组或单个用户。通配符字符 * 将配置文件映射到所有用户。

用户在启动 H2O 集群时受到这些边界的约束。例如，实习生可能只能被允许一个并发 H2O 集群，每个集群不超过 2 个节点，每个节点 1 GB 内存，而高级用户可能被允许 3 个并发集群，每个集群最多有 20 个节点，每个节点 50 GB 内存。

配置文件管理用户资源消耗

配置文件为每个用户在共享服务器集群上的资源消耗划定了边界。这是通过限制用户可以同时管理的 H2O 集群数量、每个集群的大小（总服务器节点数、每个节点的内存、每个节点的 CPU）以及集群可以运行的时间来实现的。

配置文件不应限制用户，但另一方面，它们应该为他们适当的大小。没有配置文件，用户倾向于消耗最大可能资源，而实际上需要的资源要少得多。乘以所有用户，这通常会导致对扩展服务器集群（成本高昂）或限制使用它的租户产生不必要的压力。

对于 H2O Core，有三种配置文件类型可以配置并分配给用户：

• H2O：H2O-3 集群在 Hadoop 上。

• Sparkling Water – 内部后端：Sparkling Water 集群在 Hadoop 上，其中 H2O 和 Spark DataFrames 占用相同的内存空间（即同一服务器节点上的内存）。

• Hadoop：Sparkling Water – 外部后端：Sparkling Water 集群在 Hadoop 上，其中 H2O 和 Spark DataFrames 占用不同的内存空间（即不同服务器节点上的内存）。请注意，此配置文件使用频率不高，通常仅用于持续时间极长的 Sparkling Water 处理（通常超过 24 小时）。外部后端的优势在于隔离 H2O Sparkling Water 集群，以避免 Spark 节点终止或重新分配造成的干扰，但缺点是需要在网络（而非内存空间）之间传输数据。

• H2O – Kubernetes：在 Kubernetes 集群框架上的 H2O-3 集群。

参见第二章，平台组件和关键概念，以重新审视 H2O-3 和 Sparkling Water 集群之间的区别。同时回忆，H2O 集群指的是H2O-3 集群或Sparkling Water 集群。

Hadoop Spark 与纯 Spark 集群

Hadoop 系统通常将 MapReduce 和 Spark 框架作为分布式计算系统实现，并且在这些框架上的作业通常由 YARN 资源管理器管理。Enterprise Steam 在 Hadoop/YARN 的 MapReduce 框架上管理 H2O-3 集群，在 Hadoop/YARN 的 Spark 框架上管理 Sparkling Water 集群。

注意，Spark 也可以在 Hadoop 和 YARN 之外独立运行。H2O Sparkling Water 集群可以运行在这种类型的 Spark 实现上，但当前，H2O 不将这些环境与企业 Steam 集成。

Kubernetes 是实现分布式计算的另一种框架。Enterprise Steam 也集成了 Kubernetes 以启动和运行 H2O-3 集群。目前，Enterprise Steam 和 Kubernetes 对 Sparkling Water 的支持正在进行中。

之前列出的四种配置文件类型的具体细节不同，但它们都共享以下关键配置：

• 配置文件名称: 分配给用户组。

• 用户组: 将配置文件分配给谁。

• 每个用户的集群限制: 用户可以同时运行的 H2O 集群数量。

• 节点数量: 组成分布式 H2O 集群的服务器节点数量。

• 内存和 CPU: 每个节点分配给 H2O 集群的内存和 CPU 数量。

• 最大空闲时间（小时）: 当 H2O 集群空闲时间超过这个时长时，H2O 集群将自动关闭。

• 最大运行时间（小时）: 当 H2O 集群运行时间超过这个时长时，无论是否空闲，H2O 集群将自动关闭。

• 启用集群保存: 当集群关闭时（无论是用户手动关闭还是超过最大空闲时间或运行时间）保存集群数据，以便集群可以重新启动并恢复到关闭时的相同状态。

注意，上述内容不是详尽的列表，而只是列出管理 H2O 集群上用户资源使用的关键配置。

Enterprise Steam 配置

在通用 > Steam 配置处制作管理 Enterprise Steam 服务器的配置。执行此操作的配置设置如下。

许可证

Enterprise Steam 需要从 H2O.ai 获取许可证。此配置页面标识了当前许可证剩余的天数，并提供管理许可证的方法。

安全性

此配置页面提供了设置以加强 Enterprise Steam 的安全性。Enterprise Steam 默认只运行在 HTTPS 上，并且 Steam 默认生成自签名证书。此页面允许您配置自己的 TLS 证书路径，以及其他安全设置。

日志

企业级 Steam 对用户身份验证和 H2O 集群使用进行了广泛的日志记录。此页面允许您配置日志级别和日志目录路径。这也是您可以下载日志的地方。

您还可以按用户级别粒度下载 H2O 集群的使用报告。

导入/导出

此页面通过允许将企业级 Steam 配置导出以及从另一个实例导入和加载配置，促进了配置的重用。

服务器集群（后端）集成

本书的一个主题是使用 H2O Core（H2O-3 和 Sparkling Water）在大量数据上构建模型。为此，用户启动 H2O 集群，这些集群在多个单独的服务器上并行分配数据和计算。这使得例如 XGBoost 或广义线性模型（GLM）算法能够针对 TB 级的数据进行训练。

企业级 Steam 允许管理员配置这些服务器集群环境中 H2O 集群的集成。这可以在配置页面的后端部分完成。

H2O 集群可以在两种类型的服务器集群后端上启动并由企业级 Steam 管理：

• Hadoop：这些是基于 YARN 的分布式系统，例如 Cloudera CDH 或 CDP，或 Amazon EMR。

• Kubernetes：这是一个围绕编排容器池而构建的分布式框架，它是供应商无关的，尽管有供应商特定的产品。

对于任一后端，配置项都详细且广泛，以便 H2O 集群可以安全地在这些企业环境中运行。有关完整详细信息，请参阅 H2O 文档中的docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/backends.html。

H2O-3 和 Sparkling Water 管理

现在集群后端已经配置好了，管理员可以管理和配置H2O-3或Sparkling Water，用户在这些后端上运行这些应用。这可以在配置页面的产品部分完成。

H2O-3 和 Sparkling Water 都有以下页面：

• 配置：这部分展示了所有用户和配置文件中 H2O-3 或 Sparkling Water 集群的高级别配置，这些配置对于所有集群都是恒定的。例如，您可以将配置的 YARN 前缀追加到 Hadoop 系统上 YARN 资源管理器 UI 中列出的所有 H2O 集群的作业名称中。

• 在此配置页面上可以添加和删除库版本。

  关于升级 H2O 版本的说明

  升级 H2O 版本很简单：用户只需通过选择新的库版本（管理员已上传或如上所述复制到企业级 Steam）来启动新的 H2O 集群。这种简单的升级方法之所以有效，是因为（a）H2O 集群架构在启动 H2O 集群时将库从企业级 Steam 推送到服务器集群的节点，并在 H2O 集群终止时删除库，以及（b）每个 H2O 集群都是一个独立的实体。因此，用户 A可以使用一个 H2O 版本启动 H2O 集群，而用户 B可以使用另一个版本（或者用户 A可以启动多个具有不同版本的 H2O 集群）。

  所有情况下都需要满足的要求是，您 IDE 环境中安装的库版本与启动 H2O 集群时使用的版本相匹配。

请参阅 H2O.ai 文档以获取有关在 Hadoop 上使用 H2O-3 的更深入细节：docs.h2o.ai/h2o/latest-stable/h2o-docs/welcome.html#hadoop-users。请注意，此链接中列出的 Hadoop 启动参数可用于配置所有 H2O-3 集群的企业级 Steam。

重新启动企业级 Steam

对于某些配置更改，您将收到一条消息提示您需要重新启动企业级 Steam 以应用这些更改。

通过从企业级 Steam 服务器命令行运行以下命令来重新启动企业级 Steam：

sudo systemctl restart steam

通过运行以下命令验证重启后企业级 Steam 是否正在运行：

sudo systemctl status steam

企业级 Steam 服务器上用于故障排除的日志位于以下路径：/opt/h2oai/steam/logs/steam.log。

现在我们已经了解了企业级 Steam 管理员对 H2O 规模扩展中机器学习的看法，让我们看看这对运维团队意味着什么。

视图 2 – 运维团队

运维团队维护企业级系统并监控其上运行的工作负载。对于 H2O 规模扩展，这些运维工作集中在以下三个领域：

• 企业级 Steam 服务器

• 在企业集群上运行的 H2O 模型构建作业

• 部署到生产评分环境中的模型

这些领域的特定操作角色及其关注点总结在下述图中：

图 11.5 – H2O 规模扩展的运维和角色关注点

让我们更仔细地看看每个操作角色及其在 H2O 规模扩展方面的关注点。

企业级 Steam 服务器运维

企业级 Steam 服务器周围的运维工作集中在部署和维护服务器以及在其上运行的 Steam 服务。

企业级服务是一个轻量级服务，主要是一个带有嵌入式数据库的 Web 应用程序，用于维护状态。没有数据科学工作负载在 Enterprise Steam 上运行，也没有数据科学数据通过或驻留在其上。如前所述并在图 11.3中总结，Enterprise Steam 在后端 Hadoop 或 Kubernetes 基础设施上启动 H2O 集群形成，H2O 工作负载由数据科学家的 IDE 驱动。

H2O 集群操作

H2O 集群操作通常由 Hadoop 或 Kubernetes 管理员执行。在 Hadoop 上，H2O 集群作为原生 YARN MapReduce（用于 H2O-3 集群）或 Spark（用于 Sparkling Water 集群）作业运行，并在 YARN 资源管理 UI 中可见。如第二章“平台组件和关键概念”中所述，每个 YARN 作业映射到单个 H2O 集群，并且集群运行多长时间，作业就运行多长时间。

MLOps

MLOps 有时指的是整个机器学习生命周期的操作，但我们将专注于围绕在生产系统中部署和维护模型进行评分的操作。这些操作通常关注以下方面：

• 模型部署：这涉及将模型部署到其评分环境，通常通过自动化的持续集成和持续交付（CI/CD）管道执行。

• 模型监控（软件重点）：这是一个从运行软件的角度询问模型健康状况的传统关注点。通常，模型被监控以确保其运行无错误，并且其评分延迟符合服务级别协议（SLA）的期望。

• 模型监控（机器学习重点）：这是一个针对模型评分结果的具体关注点集合。它通常涉及是否发生了数据漂移（评分时间的数据分布是否已从训练数据中偏移），这用于确定模型是否需要重新训练。其他关注点可能包括监控预测衰减（评分的预测分布是否向更不具预测性的方向移动），监控偏差（模型是否以不公平或偏见的方式为特定子集或人口统计群体进行预测），以及监控对抗性攻击（使用人工数据欺骗模型以产生错误预测或恶意损害模型评分的尝试）。

• 模型治理：这是一个包括管理模型版本和将部署的模型追溯到模型构建细节（例如，用于构建模型的训练和测试数据集，训练模型的配置细节，训练模型的数据科学负责人等）的一系列关注点。它还包括回滚或重新生成模型以及其他可能特定于组织的问题的能力。请注意，在模型构建阶段生成的模型文档是模型治理中使用的宝贵资产。（有关生成 H2O AutoDoc 的详细信息，请参阅第七章，理解机器学习模型。）

注意，MLOps 是一套快速发展的实践和实施。自己构建 MLOps 框架可能会在跟上软件供应商提供的 MLOps 平台的功能和易用性方面遇到很大困难。我们将在第十三章，介绍 H2O AI Cloud中看到，H2O.ai 提供了一个完全具备功能的 MLOps 组件，作为其端到端平台的一部分。

现在我们已经了解了使用 H2O 进行大规模操作时企业级管理员和运营对机器学习的看法，让我们看看这对数据科学家意味着什么。

视图 3 – 数据科学家

使用 H2O 进行大规模操作的数据科学家与企业级管理员和运营团队互动的主要方式如下所示：

![图 11.6 – 使用 H2O 进行大规模操作时，数据科学家与管理员和运营利益相关者的互动

图 11.6 – 使用 H2O 进行大规模操作时，数据科学家与管理员和运营利益相关者的互动

让我们深入探讨数据科学家与企业级管理员和运营团队的关键互动。

与企业级管理员互动

回想一下，数据科学家通过企业级进行身份验证并启动企业级配置文件定义的 H2O 集群大小。数据科学家有时会与企业级管理员互动以解决身份验证问题或请求更符合他们需求的 H2O 集群配置文件。他们还可能请求访问他们配置文件中不允许的不同 YARN 队列，请求他们配置文件更长的配置空闲时间，或请求启动 H2O 集群的新版本 H2O。当然，还可能有其他 H2O 配置和配置文件请求。查看视图 1 – 企业级管理员部分将帮助数据科学家了解企业级配置如何影响他们，也许应该进行更改。

与 H2O 集群（Hadoop 或 Kubernetes）运营团队互动

数据科学家很少与 H2O 集群运维团队互动。这些团队通常是 Hadoop 或 Kubernetes 运维团队，具体取决于 H2O 集群在哪个服务器集群后端启动。

当数据科学家与这些团队互动时，通常是为了帮助调试失败的或表现不佳的 H2O 作业。这种互动可能涉及请求发送到H2O 支持门户的 Hadoop 或 Kubernetes 日志，以便在 H2O 方面进行故障排除。

与 MLOps 团队的互动

数据科学家通常与 MLOps 团队互动，以在模型部署过程的开始阶段进行参与。这通常涉及部署模型评分工件，即 H2O MOJO（从模型构建生成），以及可能部署其他资产以与模型一起存档，用于治理目的（例如，H2O AutoDoc）。

数据科学家还可能与 MLOps 团队互动，以确定是否发生数据漂移，从而决定是否使用更新的训练数据重新训练模型。根据 MLOps 系统，此过程可能被自动化，以便向数据科学家和其他利益相关者发送包含识别和描述漂移内容的警报。

摘要

在本章中，我们了解到 H2O 管理员（通过企业蒸汽工作）和运维团队（管理执行 H2O 模型构建的企业服务器集群环境，并在模型部署到评分环境后管理、监控和治理模型）是参与大规模 H2O 机器学习的关键角色。我们还学习了构建模型的科学家如何受到这些角色的影响，以及为什么他们可能需要与他们互动。

让我们继续探讨两个在 H2O 大规模机器学习中扮演角色并可能影响数据科学家的额外角色：企业架构师和安全利益相关者。

第十二章：企业架构师和安全视图

H2O at Scale 用于在企业系统中构建针对大量到巨量数据的尖端 机器学习 （ML） 模型。企业系统是各种组件的复杂集成，这些组件在共同的架构和安全原则下协同工作。H2O at Scale 需要以预期、安全和一致的方式融入这个生态系统。在本章中，我们将详细检查 H2O at Scale 架构和安全属性，以了解 H2O 软件如何在企业中部署，如何与知名框架集成，如何实现广泛的安全功能，以及通常如何在企业系统中良好地运行。

在本章中，我们将涵盖以下主要主题：

• 企业和安全架构师视图

• H2O at Scale 企业架构

• H2O at Scale 安全性

• 数据科学家对企业和安全架构的看法

技术要求

本章没有技术要求。

企业和安全架构师视图

企业和安全架构师的角色很广泛，但在此处，我们将关注他们对软件架构如何集成到现有企业软件生态系统以及如何满足安全需求的关注。

以下图表展示了此视图的摘要。企业可能会有他们自己的特定需求和关注点，但我们的讨论将是一个共同的起点：

图 12.1 – H2O at Scale 的架构和安全视图

在我们深入了解详细视图之前，让我们先看看概述，如下所示：

• H2O 企业架构：这里的需要和关注点与软件组件的部署、集成以及可能对整个技术生态系统产生的影响有关。在我们的案例中，架构主要在组件级别——即在大块独立的零件级别——而不是更低，例如类设计。

• H2O 安全性：企业会采取极端措施来保护他们的系统免受内部和外部威胁。H2O at Scale 技术被众多 《财富》100 强 和 《财富》500 强 公司在各个行业垂直领域使用，并且已经经过并通过了广泛的安全审查。我们将触及最受审查的安全领域。

让我们先深入了解企业架构视图。

H2O at Scale 企业架构

我们将通过多个视角来查看 H2O at Scale 模型构建架构，以便让架构利益相关者了解这项技术如何解决他们的常见需求和关注点。

H2O at Scale 组件在实现方式上具有灵活性，因此首先，我们需要了解这些替代方案及其影响，如下文所述。

H2O at Scale 实现模式

H2O at Scale 的实现有三种模式，如下图中所示：

图 12.2 – H2O at Scale 的实现模式

这些模式的核心概念是我们将 H2O at Scale 组件定义为企业级蒸汽、H2O 核心（H2O-3 或 Sparkling Water 或两者兼而有之，带有可导出的 H2O MOJO（即模型对象，优化）），以及一个企业级服务器集群（H2O 可以利用但未安装）。这种组件定义的原因已在本书的许多地方阐述，此处将简要回顾如下：

• H2O at Scale（最小化）：最小化地，H2O at Scale 组件包括企业级蒸汽、H2O 核心（H2O-3、Sparkling Water）以及基于 Kubernetes 或另一个资源协调器（YARN）的 Hadoop 或 Spark 服务器集群。H2O MOJO 是从 H2O 核心生成的。它在第十章 H2O 模型部署模式中进行了详细说明。

• H2O AI 云平台：H2O at Scale 可以作为更大 H2O AI 云平台的一个子集来实现。这个更大的平台将在第十三章 介绍 H2O AI 云中概述。在这种情况下，H2O at Scale 保留了其功能和架构，并被视为更大集成 H2O 平台上的多个专业模型构建引擎之一。

• 非企业级 H2O：H2O 核心可以以两种其他模式实现，这两种模式通常不被视为企业级实现。H2O 核心可以在用户的本地机器上运行。这对于个人工作很有用，但在此情况下，H2O at Scale（内存中的数据和其在服务器集群中水平分布的计算）的真正力量是不可用的。因此，无法在大数据量上进行模型构建。

H2O 核心也可以直接针对 Hadoop、Spark 或 Kubernetes 集群运行，而无需实现企业级蒸汽。这给企业带来了重大的用户管理和治理风险，并迫使数据科学家掌握技术集成知识。这一主题已在第十一章 管理员和操作视图中详细说明，并将在本章中简要提及。

哪个 H2O at Scale？

本章的架构和安全讨论重点在于最小化实现的 H2O at Scale 组件（图 12.2中的中间图）。对于作为更大 H2O AI 云平台子集的 H2O at Scale，架构类似但不相同。这些差异将在第十三章 介绍 H2O AI 云中概述。

无论 H2O at Scale 是独立实施还是作为更大 H2O AI Cloud 的一部分实施，从模型构建到模型部署再到企业级 Steam 管理，所有关于 H2O at Scale 功能的讨论都是相同的。

让我们开始探讨用户客户端、Enterprise Steam 和 H2O Core 组件如何融入企业环境。

组件集成架构

以下组件涉及 H2O at Scale 模型构建：

• 一个网页浏览器

• 一个数据科学 集成开发环境 (IDE)（例如，Jupyter Notebook），其中已安装 H2O 客户端库

• H2O Enterprise Steam，加载了 H2O-3 和/或 Sparkling Water Java ARchive (JAR)文件，以便作为作业分发到企业服务器集群

• 一个企业 身份提供者 (IdP)

• 一个企业服务器集群

这些组件集成在以下图中展示得更加详细：

![图 12.3 – H2O at Scale 的组件集成架构

![img/B16721_12_03.jpg]

图 12.3 – H2O at Scale 的组件集成架构

注意，唯一安装的 H2O 组件是在数据科学家 IDE 中的 H2O 和 Enterprise Steam 客户端库，以及安装在小型服务器上的 H2O Enterprise Steam。Enterprise Steam 管理一个 Java JAR 文件，将其推送到企业服务器集群以形成每个用户的自组装 H2O 集群。重要的是，当 H2O 集群停止时，此 JAR 文件将从企业服务器集群中删除。因此，不会在企业服务器集群上安装任何 H2O 组件。

H2O at Scale 在企业系统中具有较小的组件占用空间

尽管 H2O at Scale 能够针对大规模数据集构建模型，但从安装组件的角度来看，它在企业系统中的实际占用空间相当小。

企业级 Steam 是企业环境中唯一安装的组件，它只需要一个小型单服务器（在 Hadoop 上时为边缘节点）。创建 H2O 集群（分布式模型构建）的软件在 Enterprise Steam 上管理，并临时推送到企业服务器集群，而不是安装在那里。Enterprise Steam 利用 Kubernetes 或 YARN 以原生方式在这些框架上启动 H2O 集群（即，H2O 集群是原生的 Kubernetes 或 YARN 作业）。

除了这些，数据科学家在其 IDE 环境中安装 H2O 客户端库，以与企业 Steam 和用户的 H2O 集群进行通信。

还要注意，所有数据科学家和管理员与企业环境的交互都通过 Enterprise Steam 集中进行。这包括所有用户身份验证和 H2O 集群的创建（以及停止或终止）以及管理员配置，以将 H2O at Scale 活动与企业服务器环境集成和保障安全。

企业级 Steam 作为 H2O at Scale 的集中式组件

Enterprise Steam 作为企业系统中所有用户交互的中心网关，包括通过企业 IdP 进行用户身份验证、管理 H2O 集群的生命周期、管理 H2O 软件以及管理员配置以在企业服务器集群上集成和保障 H2O 的安全。

通信架构

H2O at Scale 组件之间的通信协议如下所示：

图 12.4 – H2O at Scale 的通信架构

注意，H2O 使用众所周知的通信协议。此外，请注意（除了用户客户端上的数据外），数据直接从数据源传输到用户的 H2O 集群（在那里它被分配到内存中）。

数据摄入直接从源（最好是存储层）到 H2O 集群

用于模型构建的数据被摄入到 H2O 集群中，不通过 Enterprise Steam 或用户的客户端（除非从客户端上传）：它直接从数据源传输到企业服务器集群上 H2O 的内存计算。在处理大规模数据集时，最好使用服务器集群存储层（例如，简单存储服务（S3）、Azure Blob 或Hadoop 分布式文件系统（HDFS））作为数据源，而不是其他数据源，如Java 数据库连接（JDBC）。H2O 集群将源数据在集群的节点之间分配到内存中。这种分区加载是从存储层并行化的，而不是从其他数据源（例如，JDBC 数据库或 Hive）。

部署架构

H2O at Scale 有两种部署模式：基于 Kubernetes 或 YARN 的服务器集群。在两种情况下（如前所述），仅在企业环境中安装 Enterprise Steam。这种基于 Kubernetes 与基于 YARN 的区别——以及随后的架构和基础设施细节——对数据科学家来说是隐藏的。正如本书所强调的，数据科学家使用熟悉的语言和 IDE 来构建大规模的 H2O 模型，对在服务器集群后台进行的扩展技术实现知之甚少或一无所知。

在 Kubernetes 集群上的部署

Kubernetes 是一个用于扩展和管理容器化应用的现代框架。H2O at Scale 可以部署以利用这个框架。如何实现的细节如下所示：

图 12.5 – H2O at Scale 在 Kubernetes 上的部署图

关键点如下：

• Enterprise Steam 使用 Helm 图表在 Kubernetes 集群上安装和运行。Helm 是 Kubernetes 的包管理器，Helm 图表是用于定义、安装和升级 Kubernetes 框架上组件的模板化文件集合。Helm 图表使 Kubernetes 上的安装和升级变得简单且可重复。

• Enterprise Steam 基本上是一个 Web 服务器应用程序，它将工作负载作为编排的 Kubernetes Pod 推送到企业集群。因此，Enterprise Steam 需要非常低的资源。

• Enterprise Steam 以具有 服务标识符（服务 ID）的服务运行。

• 使用 Enterprise Steam 需要一个从 H2O.ai 获得的 许可证密钥。许可证密钥在 1 年后到期，需要在此时间之前更新。

• Kubernetes 配置在 Enterprise Steam 中进行。这包括 卷挂载、HDFS 和 Hive 访问，以及 MinIO 访问（这打开了访问云对象存储——具体来说，是 Amazon Web Services（AWS） S3、Azure Blob 和 Google Cloud Storage（GCS））。

• H2O-3 Docker 镜像按版本存储在任何公共（例如，Docker Hub）或私有（例如，AWS Elastic Container Registry（ECR）镜像仓库中，并在集群启动时由 Kubernetes 从此处拉取。

  注意

  H2O Sparkling Water 目前在 Kubernetes 上的 Enterprise Steam 中不可用。

• 有关安装企业级 Steam 的详细信息，请参阅 H2O 文档中的docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/installation.html。

  升级 H2O-3 很简单

  请记住，H2O-3 没有安装在企业服务器集群上：在这里，它作为 Kubernetes 集群上的 Pods 进行编排和分发，然后在用户完成使用生成的 H2O 集群后进行拆解。这使得升级变得简单：管理员只需在 Enterprise Steam 中配置新的 H2O 版本（并将其 Docker 镜像存储在配置的仓库中），然后用户使用较新版本启动他们的下一个 H2O 集群。（在 Enterprise Steam 上可以共存多个版本，因此用户在启动 H2O 集群时可以从它们中选择。）

对于 高可用性，Enterprise Steam 可以作为主动-被动设置安装，由 Kubernetes 处理自动故障转移。这已在 H2O 文档中描述，请参阅docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/ha.html。

让我们看看 H2O 在 YARN 基于的集群上的部署方式。基本上，忽略底层框架的具体细节时，这些模式是相似的。

基于 YARN 的服务器集群部署

YARN 是一个开源框架，用于在水平可扩展的架构中启动和管理分布式处理。它通常针对 Hadoop 或 Spark 集群（或 Spark 在 Hadoop 上）实现。以下图表和讨论与 Hadoop 上的部署相关：

![图 12.6 – H2O 在 Hadoop 上的大规模部署图]

图 12.6 – H2O 在 Hadoop 上的大规模部署图

关键点类似于基于 Kubernetes 的实现。以下列出 Hadoop 的差异：

• Enterprise Steam 部署在 Hadoop 的边缘节点上。

• Enterprise Steam 将工作负载作为原生YARN作业推送到企业集群。

• Enterprise Steam 以软件包的形式安装在Linux 操作系统（无论是Debian/Ubuntu还是Red Hat Enterprise Linux（RHEL）/CentOS）上（Debian（DEB）或RPM 软件包管理器（RPM）或GNU zip 磁带存档（TAR GZ）安装）。

• 配置是在 Hadoop 的core-site.xml和kms-site.xml配置文件上进行的。这些 Hadoop 配置是为了将 Steam 与 YARN 集成并实现用户伪装。因为 Enterprise Steam 在边缘节点上，所以在管理节点上对 Hadoop 配置的更改会立即在 Enterprise Steam 上复制。

• H2O-3 或 Sparkling Water JAR 文件由 Enterprise Steam 的YARN 应用程序打包，并作为每个启动 H2O 集群的用户的一个单独的 YARN 作业运行在 Hadoop 集群上。YARN 作业（或等价地，H2O 集群）运行直到用户停止 H2O 集群，或者 Enterprise Steam 在达到空闲或绝对时间阈值后自动停止集群。H2O-3 JAR 和 Sparkling Water JAR 文件从 H2O.ai 获取，并且针对 Hadoop 发行版特定。管理员通过 UI 上传 JAR 文件或执行安全复制（SCP）到 Enterprise Steam 文件系统。

• 关于安装 Enterprise Steam 的详细说明，包括对 Linux 操作系统、Java 和 Hadoop 发行版的要求，请参阅 H2O Enterprise Steam 文档，网址为docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/installation.html。

  升级 H2O-3 或 Sparkling Water 非常简单（再次）

  H2O-3 和 Sparkling Water 没有安装在 Hadoop 集群上：在这里，它们被封装成 YARN 作业，并在集群上分布式运行。这使得升级变得简单：管理员只需将 JAR 文件的新版本上传到 Enterprise Steam，用户就可以使用新版本启动下一个 H2O 集群。（可以共存多个版本，因此用户在启动 H2O 集群时可以选择它们。）

对于 Hadoop 的高可用性，企业 Steam 以手动故障转移的主动-被动设置安装。这在 H2O 文档的docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/ha.html中描述。

作为 H2O AI Cloud 部署的一部分

企业 Steam、H2O Core（H2O-3 和 Sparkling Water）可以作为更大的 H2O AI Cloud 平台的一部分进行部署（见图 12.2）。因此，它具有与前面显示的两个模型类似的架构，但现在作为更大 H2O AI Cloud 实施的一部分集成和安装。这将在第十三章中进一步讨论，介绍 H2O AI Cloud。

现在我们已经探讨了 H2O at Scale 的企业架构视图，让我们来看看安全性视图。

H2O at Scale 安全性

H2O at Scale 已部署到金融服务、保险、医疗保健和其他行业的众多高度监管的企业。这通常涉及广泛的彻底的架构和安全审查，这些审查因组织而异。以下各节将讨论从架构角度的关键领域。

数据移动和隐私

这里记录了数据移动和隐私的主要安全要点：

• 数据直接从企业数据源移动到企业集群中用户 H2O 集群的内存中，不通过 H2O Enterprise Steam 或数据科学家的客户端。

• 在并发 H2O 集群中的数据与其他数据隔离：在模型构建期间，用户无法看到或访问彼此的数据。

• 当 H2O 集群停止时，用户 H2O 集群中的数据将被删除。请记住，数据在用户运行的 H2O 集群节点之间在内存中分区。

• 用户可以将数据下载到由管理员配置的企业存储层主目录中（例如，在 AWS S3 或 HDFS 中）。

• 用户无法从 H2O 集群下载数据到本地磁盘。

用户身份验证和访问控制

这里概述了需要注意的主要要点：

• 用户身份验证通过企业 Steam 中心完成，该服务与企业身份提供者（IdP）进行身份验证。企业 Steam 支持以下身份验证方式：OpenID、轻量级目录访问协议（LDAP）、安全断言标记语言（SAML）和可插拔身份验证模块（PAM）。

• 用户可以通过 H2O Steam 应用程序编程接口（API）进行用户身份验证。用户可以生成个人访问令牌（PATs），并将它们用作程序中的环境变量（而不是硬编码它们）。生成新的 PAT 会撤销之前的 PAT。PAT 在用户登录后从企业 Steam UI 生成。

• 企业 Steam 支持在 Kerberos 保护的 Hadoop 集群上运行。

• 要访问 HDFS 或 Hive，可以配置 Hadoop 伪装。这允许企业级 Steam 在这些数据源中看起来像是已登录用户，而不是企业级 Steam 服务 ID。这反过来又允许 H2O 用户通过登录企业级 Steam（而不是明确传递授权凭证）来对这些资源进行身份验证。

• 对于 JDBC 和其他数据源访问，数据科学家将访问凭证（例如，JDBC 连接统一资源定位符（URL）、用户名和密码）作为参数传递给客户端 IDE 中 H2O API 的数据导入语句。

企业级 Steam 管理员配置的用户身份验证和访问控制已在第十一章，管理员和操作视图中介绍。

网络和防火墙

假设 H2O at Scale 在企业网络内部署安全，无论是在本地还是在云端。这里记录了 H2O 网络安全的一些方面：

• 用户对企业级 Steam 和在企业服务器集群上的 H2O 集群的访问是通过超文本传输安全协议（HTTPS）进行的。企业级 Steam 在安装时自动生成自签名的传输层安全性（TLS）证书，但在首次登录后，您将有机会安装自己的证书。此外，还可以为 LDAP、Kubernetes Ingress 以及 Kubernetes 连接到 MinIO 和 H2O.ai 存储层安装证书。

• 企业级 Steam 默认将用户暴露在端口9555上，但这可以更改。企业级 Steam 运行在反向代理后面，用户永远不会直接与 H2O 集群本身通信。

H2O Enterprise Steam 安全性的详细信息可以在 H2O 文档中找到，网址为docs.h2o.ai/enterprise-steam/latest-stable/docs/install-docs/index.html。

我们现在已经从各自的利益相关者的角度探讨了 H2O at Scale 的企业和安全管理架构。现在让我们看看这如何与数据科学家相关。

数据科学家对企业和管理架构的看法

尽管数据科学家通常不会直接或频繁地与企业和安全管理架构师互动，但他们可能会受到以下图中所示的利益相关者的影响：

![图 12.7 – 企业和安全管理架构的数据科学视图

图 12.7 – 企业和安全管理架构的数据科学视图

在企业中首次实施 H2O at Scale 通常需要对该技术的正式架构和安全审查。企业系统是由多种技术集成到一个统一整体的大型生态系统。架构和安全审查员将决定 H2O at Scale 是否可以在这个生态系统中实施，同时符合定义统一整体的原则。这些原则是由企业利益相关者定义的规则和指南，可能包括确保新技术与业务需求一致，确保技术满足广泛的网络安全要求，以及确保架构在发生中断后能够实现业务连续性（BC）。这只是几个例子。

H2O at Scale 技术已经通过了财富 100 强和财富 500 强企业的架构和安全审查，原因已在本章中概述。H2O at Scale 可以总结如下：

• 安装占用空间小，易于升级

• 本地集成到现有框架（Kubernetes；YARN）

• 通过 Enterprise Steam 集中管理 H2O 用户和 H2O 软件管理

• 为业务连续性提供高可用性

• 使用常见的通信协议

• 实施广泛且广为人知的网络安全机制

• 确保数据隐私

• 提供已知的服务级别协议（SLAs）支持

让我们总结一下本章所学的内容。

摘要

在本章中，我们检查了 H2O at Scale 模型构建技术的架构和安全基础。这种检查为架构和安全利益相关者提供了一个可靠的起点，以评估 H2O 是否符合企业系统定义的技术要求和架构原则。一般来说，H2O at Scale 在集成和运行时很好地融入企业生态系统，并且在此过程中具有较小的软件占用空间。H2O 还拥有广泛的安全功能，满足企业的高安全需求。

在下一章中，我们将把到目前为止所学的一切放入 H2O.ai 令人兴奋的新端到端机器学习平台 H2O AI Cloud 的更大背景中。

第五部分 – 扩展视野 – 使用 H2O AI 云平台将数据应用到 AI 应用

在本节中，我们将介绍功能齐全的 H2O AI 云平台。重要的是，我们将认识到在这本书中学到的内容（使用 H2O 的规模化机器学习）可以独立实现，或者作为更大 H2O AI 云的一部分直接使用。我们将首先熟悉 H2O AI 云的组件以及 H2O-3、Sparkling Water、企业级 Steam 和 MOJO 的位置。我们将利用这些新知识，迭代展示使用 H2O AI 云构建 ML 工作流程和解决方案的令人兴奋的新方法。

本节包括以下章节：

• 第十三章, 介绍 H2O AI 云

• 第十四章, 在更大平台环境中 H2O 的规模化应用

第十三章：介绍 H2O AI Cloud

在本书的前几节中，我们详细探讨了如何使用 H2O 技术在大数据量上构建准确和可靠的机器学习（ML）模型，以及如何部署这些模型在多样化的企业系统中进行评分。在这个过程中，我们熟悉了 H2O Core（H2O-3 和 H2O Sparkling Water）的技术及其分布式内存架构，以水平可扩展的方式执行模型构建步骤，使用熟悉的 IDE 和语言。我们了解了 H2O Enterprise Steam 作为数据科学家轻松配置 H2O 环境和管理员管理用户的工具。我们学习了 H2O MOJO 的技术性质，即从构建的模型生成和导出的即用型评分工件，以及我们学习了在多样化的目标系统上评分 MOJO 的多种模式，无论是实时、批量还是流式。我们还学习了企业利益相关者如何以规模技术的方式看待和交互 H2O。

在本章中，我们将通过学习 H2O 提供的一个更大的端到端机器学习平台，即 H2O AI Cloud 来扩展我们的知识。该平台包括多个专业的模型构建引擎、一个 MLOps 平台用于部署和监控模型、一个特征存储库用于共享模型构建和评分的特征，以及通常在机器学习平台背景下不会考虑的技术层——一个低代码 SDK，可以轻松地在平台的其他部分之上构建 AI 应用程序，以及一个应用商店来托管它们。

重要的是，我们将看到我们迄今为止所学的技术和技能实际上是更大范围的 H2O AI Cloud 的一个子集。

在本章中，我们将涵盖以下主要主题：

• H2O AI Cloud 概述

• H2O AI Cloud 组件分解

• H2O AI Cloud 架构

技术要求

您可以通过访问h2o.ai/freetrial注册 90 天的 H2O AI Cloud 试用。这将允许您使用平台组件与您自己的数据或与 H2O 提供的试用数据进行交互。

我们将看到 H2O AI Cloud 的一部分是数据科学家使用一个名为 H2O Wave 的开源低代码 SDK 构建 AI 应用程序的能力。您可以通过访问以下链接在本地机器上开始构建自己的 H2O Wave AI 应用程序：wave.h2o.ai/docs/installation。

H2O AI Cloud 概述

H2O AI 云是一个端到端的机器学习平台，旨在使团队能够无缝地通过构建模型、信任模型以及部署、监控和管理模型进行工作。此外，H2O AI 云还包括一个 AI 应用程序开发和托管层，允许各种角色与机器学习生命周期中的所有步骤进行交互——从表达复杂可视化的应用程序到用户交互和工作流程。应用程序软件开发工具包允许数据科学家和机器学习工程师（以及传统软件开发人员）以专门构建的方式快速原型设计、最终确定并发布 AI 应用程序。例如，可以为商业用户构建应用程序，让他们查看客户流失预测仪表板，并基于原因代码进行数据分析，然后对高流失风险候选人做出响应。另一方面，数据科学家可以使用 AI 应用程序交互式验证模型预测与后续地面真实情况，并跟踪相关分析。此外，数据科学家和机器学习工程师可以使用 AI 应用程序通过编排数据漂移警报与模型重新训练和重新部署，同时跟踪分析和审计来自动化重新训练流程。

下图展示了带有 AI 应用程序层的简化机器学习生命周期，H2O AI 云围绕这些层进行组织：

图 13.1 – 带有 AI 应用程序层的简化机器学习生命周期

H2O 围绕这个表示构建了一个模块化、灵活且功能齐全的端到端机器学习平台。以下图解了映射到这个生命周期的 H2O AI 云组件：

图 13.2 – H2O 混合云端到端机器学习平台（灰色显示的 H2O 规模组件）

在深入探讨每个组件及其功能之前，让我们首先获得一个高级别的理解：

• 模型构建：有四个独立且专业的模型构建引擎，以及一个数据科学家自助提供环境和管理员管理和治理用户的工具。每个模型构建引擎为构建的模型生成一个可部署的评分工件。

• 模型部署：使用 MLOps 组件来部署、监控、管理和治理模型。

• 特征存储：特征存储可用于在模型构建期间跨团队以及在评分期间跨模型重用特征。

• AI 应用程序：提供了一个低代码软件开发工具包，用于快速构建、原型设计和发布 AI 应用程序。该 SDK 包含小部件和模板，用于构建复杂和交互式可视化和工作流程。数据科学家和机器学习工程师以熟悉的基于代码的方式构建应用程序，主要关注组织和向模板和小部件提供数据，同时忽略网络应用程序的复杂性。

• AI 应用商店：AI 应用是在本地开发的，然后发布到 AI 应用商店组件，供商业、数据科学和其他企业利益相关者消费。例如，医疗保健中的临床医生可能使用一个应用程序来防止患者过早出院，而商业分析师则使用应用程序的另一个部分来了解这种情况预测发生的频率以及原因。

• 组件的 UI 和 API 访问：用户可以通过 UI 和 API 与 H2O AI 组件进行交互。组件 API 允许以编程和自动化的方式与平台交互，并以独特的方式将组件拼接在一起。

在下一节中，我们将更全面地了解每个 H2O AI 云组件。在这样做之前，让我们通过一个表格概述来介绍这些组件，以便我们找到方向：

图 13.3 – 总结 H2O AI 云组件的表格

最后，我们需要将 H2O AI 云组件与本书的重点联系起来，我们将在以下注释中这样做。

本书重点与 H2O AI 云的关系

本书重点是使用 H2O 进行大规模机器学习，这也可以被称为大规模 H2O。我们专注于在大型数据集上构建机器学习模型并将模型部署到各种企业评分环境中。

从组件的角度来看，重点是 H2O Core（H2O-3 和 H2O Sparkling Water）、H2O 企业版和 H2O MOJO。这些组件可以部署为（a）与 H2O AI 云分开，或（b）作为 H2O AI 云的成员，如图图 13.2所示。参见第十二章，企业架构和安全视图，以了解这一点的详细阐述。

现在我们已经了解了 H2O AI 云的基本原理、其组件以及它们与本书重点的关系，让我们通过进一步阐述每个组件来扩展我们的视野和机器学习能力。

H2O AI 云组件分解

让我们深入了解每个组件。

分布式机器学习（H2O-3 和 H2O Sparkling Water）

分布式机器学习（DistributedML）一直是本书模型构建的重点，在该上下文中被称为 H2O Core，以代表 H2O-3 或 Sparkling Water。从根本上讲，您使用 H2O Core 在大型数据集上构建模型。

为了本章的目的，主要特性和能力将在接下来的子节中介绍。更多详情，请参阅第二章，平台组件和关键概念，以回顾支持大规模模型构建的分布式内存架构。参见第四章，大规模 H2O 模型构建 – 能力阐述，以更详细地了解其主要能力。

关键特性和能力

H2O Core（H2O-3 和 Sparkling Water）的关键功能和能力如下：

• 大规模数据量的模型构建：H2O Core 具有将数据分区和分布到多个服务器内存中的架构。模型构建计算是在此架构上并行进行的，从而满足大规模数据集的扩展需求。数据集越大，架构的水平扩展性就越高。

• 熟悉的数据科学体验：数据科学家使用熟悉的环境和语言（例如，在 Jupyter 笔记本中的 Python）构建 H2O 模型，以表达 H2O 模型构建 API。API 隐藏了 H2O 可扩展架构的复杂性，对数据科学家来说，这种体验本质上是对数据框编写代码。

• 灵活的数据摄取：H2O Core 具有连接器，可以访问不同的数据源和数据格式。数据直接从源传输到 H2O Core 分布式内存。

• 可扩展的数据操作：数据在分布式架构中进行操作，因此是按比例进行的。H2O API 使数据操作步骤简洁。Sparkling Water 特别允许使用 Spark API（例如 Spark SQL）进行数据操作，并在相同的编码工作流程中将 Spark DataFrames 转换为 H2OFrames。

• 最先进的算法：H2O Core 实现了针对监督和非监督问题的最先进机器学习算法，包括例如 XGBoost，一种梯度提升机（GBM），广义线性模型（GLM），以及Cox 比例风险（CoxPH）等，仅举几例。这些算法在分布式架构上运行，以扩展到大规模数据集。

• AutoML：H2O 可以使用探索算法和超参数空间的 AutoML 框架来构建模型，从而构建最佳模型的排行榜。AutoML 框架可以通过众多设置进行控制。

• 可解释性和自动文档：H2O Core 实现了广泛的可解释性功能，并可以生成自动文档，全面描述模型构建并解释生成的模型。

• MOJO：在 H2O Core 上构建的模型生成一个称为 MOJO 的即用型低延迟评分工件，可以灵活部署到各种目标环境中。这在第九章中进行了详细讨论，生产评分和 H2O MOJO。

让我们继续了解 H2O AI Cloud 的下一个模型构建引擎。

H2O AutoML（H2O Driverless AI）

H2O Driverless AI 是一个高度自动化的 AutoML 工具，部分由 Kaggle 大师级数据科学家构建，旨在结合数据科学最佳实践和 AI 启发式方法，在短时间内找到高度准确模型。其关键功能包括丰富的可解释性功能、一种遗传算法来迭代最佳模型，以及详尽的特征工程和选择，以推导和使用新特征。让我们调查这些关键功能和能力。

关键特性和功能

H2O Driverless AI 的关键特性和功能如下：

• 问题类型：H2O Driverless AI 构建了监督学习和无监督学习模型：

  • 监督学习：对于表格数据的监督学习，H2O Driverless AI 解决回归、二分类和多分类分类以及时间序列预测问题。对于图像的监督学习，Driverless AI 解决图像分类问题，对于自然语言处理（NLP），它解决文本分类和上下文标记问题。

  • 无监督学习：对于无监督学习，Driverless AI 解决异常检测、聚类和降维问题。

• GPU 支持：Driverless AI 可以利用 GPU 来处理图像和 NLP 问题，这些算法运行 TensorFlow 和 PyTorch。

• 遗传算法：Driverless AI 使用专有的遗传算法在数十个模型之间迭代，每个模型的算法（例如，XGBoost、广义线性模型和 LightGBM）不同，其探索超参数空间的方式不同，其探索特征工程空间的方式也不同。最佳模型被提升到下一轮迭代，并在每一轮迭代中引入新的模型变体。这会一直持续到它无法根据用户设置的设置找到更好的模型为止。

• 特征工程：在遗传算法过程中，Driverless AI 以详尽的方式应用数十个转换器，从原始数据集中的特征中构建新的特征，并确定哪些特征应包含在最终模型中。这些转换器被分类如下：

  • 数值：这些是在两个或多个原始特征之间的数学运算 – 例如，减去两个特征或对数据集中的多个特征进行聚类，并测量每个观察值到特定聚类的距离。

  • 分类：这些是将类别标签转换为数字的转换 – 例如，对每个类别的目标变量的平均值或频率进行计算，并将其分配给每个观察值所代表的类别。

  • 时间和日期：这些是将时间和日期字段转换为替代时间日期表示的转换 – 例如，将日期转换为星期几。

  • 时间序列：这些转换推导出对时间序列问题有用的新特征 – 例如，使用特征值的滞后时间。

  • 文本：这些转换将字符串转换为替代表示 – 例如，使用预训练的双向编码器表示从转换器（BERT）模型生成新的语言表示。

• 自带配方：除了访问广泛的专家设置外，数据科学家可以通过导入自己的代码来控制自动化的机器学习过程，这些代码 H2O 称为配方。这些自定义配方可以采取以下形式 - scorer（用于在遗传算法中优化模型的您自己的性能指标）、特征工程（您自己设计的特点）或 算法（您选择的机器学习算法，以补充熟悉的 Driverless AI 即插即用算法）。

• 可解释性（可解释性）：用户可以使用各种全面的功能来与可解释性技术交互，以解释生成的模型。这些技术可以在 全局（整个模型）或 局部（单个记录）级别应用。这些技术包括 代理 和 实际模型 技术，包括 K-Lime 和 Shapley，决策树，差异影响分析，敏感性分析和部分依赖图。还有针对时间序列和 NLP 问题的特定解释器。

• 自动文档：遗传算法生成的每个最终模型都创建大量标准化的自动文档（通常超过 60 页），详细描述实验概述、数据概述、方法、验证策略、模型调优、特征转换和演变、最终模型和可解释性。文档以段落、表格和图形形式呈现。

• MOJO：遗传算法生成的每个最终模型都创建一个可部署且低延迟的 MOJO，可以灵活部署到各种目标环境中。这与在第 第九章 中讨论的类似技术相同，生产评分和 H2O MOJO，用于 H2O 规模（H2O-3 和 Sparkling Water）。

  重要提示

  Driverless AI 的 MOJO 在自动化模型构建过程中执行特征工程。

现在让我们继续介绍 DeepLearningML 引擎。

DeepLearningML（H2O 氢火炬）

H2O 氢火炬是一个基于 UI 的深度学习引擎，它赋予所有技能水平的科学家（以及在某些用例中可能的分析师）轻松构建最先进的计算机视觉和 NLP 模型的能力。其关键特性和功能如下。

关键特性和功能

H2O 氢火炬的功能和特性如下：

• 问题类型：目前，氢火炬解决六个 计算机视觉（CV）和五个 NLP 问题类型，简要描述如下：

  • 图像分类（CV）：图像被分类为一组或多组类别 - 例如，图像被分类为汽车与卡车。

  • 图像回归（CV）：从图像预测一个连续值 - 例如，从自动驾驶汽车图像中预测的转向角度是从中心线正 20 度。

  • 目标检测（CV）：从图像中分类一个（或多个）对象，并识别其位置坐标作为边界框——例如，识别多个汽车，每个汽车周围都有一个矩形定义。

  • 语义分割（CV）：对象（或多个对象）不仅被分类，而且其精确形状也被定义，形状由像素位置确定——例如，一个人的精确轮廓或图像中所有人的轮廓。

  • 实例分割（CV）：这与语义分割相同，但在实例分割中，当识别出同一类别的多个对象时，它们被单独处理，而在语义分割中，它们被视为一个对象。

  • 图像度量学习（CV）：预测图像之间的相似性——例如，对于零售产品的图片，它会找到新图片是同一产品的可能性。

  • 文本分类（NLP）：将文本（文档、页面和片段）分类到一类——例如，对文本的情感或意图进行分类。

  • 文本回归（NLP）：从文本中预测一个连续值——例如，从简历中预测一个人的薪水。

  • 文本序列到序列（NLP）：将一个上下文中的文本序列转换为另一个上下文中的文本序列——例如，将文档转换为摘要。

  • 文本标记分类（NLP）：将文本中的每个词分类到标签——例如，识别联合国为组织（命名实体识别（NER）的例子）或识别一个词为名词或动词（词性标注（POS）的例子）。

  • 文本度量学习（NLP）：预测两组文本之间的相似性——例如，识别重复信息或相似文档。

• 构建深度学习模型的便捷性：Hydrogen Torch 是一种无代码方法，用于构建深度学习模型。用户与一个具有广泛的超参数调整控制和丰富界面的 UI 进行交互，以快速迭代、理解和评估模型结果。模型可以导出部署到 Python 或 H2O MLOps 环境。

• 用户技能集模式：Hydrogen Torch 训练用户界面通过显示较少或更多的模型构建设置来适应用户的技能水平，根据用户是新手、熟练、专家还是大师。

现在，让我们继续介绍一个专注于文档的模型构建引擎。

DocumentML（H2O 文档 AI）

文档通常是企业应用机器学习技术以自动化处理步骤、从而节省大量时间和金钱的巨大未开发数据源。H2O 的文档 AI 引擎从文档中学习以实现这一自动化。

文档 AI 超越了简单的光学字符识别（OCR）和 NLP，通过学习识别文档的信息结构，如表格、表单、标志和部分。文档 AI 模型经过训练，使用这些能力从文档中提取文本实体。因此，文档可以处理以提取特定信息，例如医疗实验室结果、财务报表、贷款申请等。然后，这些输出可以驱动来自这些文档的分析和工作流程，随着文档处理量的增加，这些文档的价值也越来越大。文档 AI 还可以对整个文档进行分类，以进一步自动化文档处理流程。

关键功能和能力

让我们进一步分解这些功能：

• 文档摄取：摄取诸如 PDF、图像、Word、HTML、CSV 文件、文本文件、电子邮件等文档。

• 预处理：文档 AI 使用 OCR 和 NLP 能力执行多个预处理步骤，例如处理嵌入式文本（例如，PDF 元数据）和标志，以及定位、去倾斜和裁剪页面。

• 应用文档标签：用户通过 UI 访问界面以将标签应用于文档文本。模型将训练以识别这些标记实体。例如，在一份医疗实验室文档中，用户将标签应用于患者姓名、实验室名称、实验室地址、测试名称、测试结果值、测试结果单位、测试结果正常范围等。

• 训练模型：文档 AI 针对标记文档集进行训练。它学会在文档结构的更大背景下将文本与标签关联起来——例如，实验室结果是从表格的行中报告的。请注意，模型是在已知的文档集上训练的，之后将能够从他们以前从未见过的文档中提取信息。例如，每个实验室都产生自己的报告（自己的设计、表格的样式、页数、文档中患者姓名的位置等）。即使模型是在一小套实验室报告（通常是大约 100 份）上训练的，它也可以从它没有训练过的实验室发送的文档中提取信息。

• 后处理：文档 AI 允许用户自定义和标准化输出结果的方式。例如，用户可以定义一个具有标准化的日期输出格式的输出 JSON 结构。

• 模型部署：模型可以导出并部署到 H2O MLOps 或您选择的 Python 环境中。

现在我们已经探索了 H2O AI Cloud 上的四个专业模型构建引擎，让我们看看这些引擎的功能如何共享和实施。

自助服务（H2O 企业版 Steam）

H2O 企业级蒸汽允许用户自行配置模型构建环境，管理员则可以管理用户及其资源消耗。与 H2O 核心及其生成的评分工件 MOJO 一样，企业级蒸汽被视为 H2O ML 扩展的关键组件，并在第二章，平台组件和关键概念中介绍，然后在第十一章，管理员和操作视图中进行了详细探讨。

注意，在这种情况下，企业级蒸汽仅用于自行配置和管理 H2O 核心环境，但在 H2O AI 云的上下文中，它用于管理所有 H2O 模型构建引擎。让我们回顾其关键能力。

关键功能和能力

H2O 企业级蒸汽的关键能力简要列出如下：

• 轻松自行配置 H2O 模型构建环境：数据科学家可以从企业级蒸汽 UI 或 API 定义、启动和管理他们的 H2O 模型构建环境。请注意，目前这适用于 DistributedML（H2O 核心）和 AutoML（Driverless AI）环境。Hydrogen Torch 和 Document AI 环境目前作为应用程序启动，但它们计划整合到企业级蒸汽的自配置框架中。

• 管理员对用户的管理和治理：管理员管理用户，并定义他们在配置环境时可以使用的资源量（CPU 和内存），包括这些环境在关闭之前闲置了多长时间。

让我们继续到特征存储组件。

特征存储库（H2O AI 特征存储库）

H2O AI 特征存储库是一个系统，用于在模型构建和实时评分环境中组织、管理、共享和操作化预测性 ML 特征。这为数据科学家节省了大量时间来发现特征，并且对于数据科学家和 ML 工程师将原始数据转换为这些特征也节省了时间。让我们进一步探讨其能力。

关键功能和能力

这里是 H2O AI 特征存储库的一些关键功能：

• 灵活的特征发布和搜索工作流程：数据科学家和工程师使用预构建的集成到 Snowflake、Databricks、H2O Sparkling Water 和其他技术中的特征管道。生成的特征输出到 H2O AI 特征存储库，与特征相关的 40 多个元数据属性。这种对特征及其属性的编目允许其他数据科学家搜索相关特征，并且特征存储库内置的 AI 可以推荐特征。

• 可扩展和及时的特征消费：特征存储库中的每个特征都有一个定义的持续时间，直到它被刷新。特征可以离线存储以进行训练和批量评分，或在线存储以进行低延迟实时评分。

• 自动特征漂移和偏差检测：特征会自动检查数据漂移，并在检测到漂移时提醒用户。这可能在决定使用更近期的数据进行模型重新训练时至关重要。特征也会自动检查偏差，并在检测到偏差时提醒用户。这可能在重新训练模型以消除偏差时至关重要。

• 访问管理和治理：H2O AI Feature Store 与企业身份提供者集成，以验证用户身份并授权对特征的访问。特征及其元数据进行了版本控制，以符合监管要求，并可以对基准数据进行回测。

H2O AI Cloud 拥有一个功能齐全的模型操作组件。让我们接下来了解更多关于它的信息。

MLOps（H2O MLOps）

H2O MLOps 是一个用于部署、管理、监控和治理模型的平台。这些可以是来自任何 H2O 模型构建引擎（DistributedML、AutoML、DeepLearningML 或 DocumentML）的模型，或者来自非 H2O 软件（例如 scikit-learn 或 MLflow）的模型。请注意，H2O MLOps 工作流程可以使用 UI 或 API 完成，后者对于集成到持续集成和持续部署（CI/CD）工作流程至关重要。主要功能如下所述。

关键特性和功能

这里是 H2O MLOps 的关键特性：

• 模型部署：轻松部署 H2O 和非 H2O 模型。评分作为 REST 端点提供，适用于实时和批量评分。模型可以部署为单个模型（简单部署）、冠军/挑战者（比较新模型与当前模型，其中只有当前模型是活跃的）或 A/B 测试（多个活跃模型和实时数据在配置的比例中路由）。模型部署到定义的环境，通常是开发和生产环境，但你可以添加更多。

• 模型监控：监控模型的健康状况、评分延迟、数据漂移、公平性（偏差）降级和性能降级。警报在监控仪表板上显示，并发送到配置的收件人。警报可用于触发模型重新训练和部署。

• 模型管理：模型可以进行比较和评估，提升到注册表中，然后部署。模型与广泛的元数据相关联，允许对模型构建细节进行可追溯性，并与其他模型进行评估。注册表中的模型（以及随后的部署）是版本化的。已部署的模型可以回滚到以前的版本。

• 模型治理：通过模型管理实现的版本控制和可追溯性创建了一个模型历史记录的谱系。用户具有基于角色的访问权限，并且对操作进行审计。管理员有一个专门的仪表板，可以提供对所有用户、模型和审计日志的可见性。这些功能结合在一起，在整体治理过程中最大限度地减少模型风险并促进合规性。

我们从识别一个集成了 H2O AI Cloud 平台其他部分的 应用层开始本章。让我们更深入地了解这一点。

AI 应用程序的低代码 SDK（H2O Wave）

H2O Wave 是一个开源且低代码的 Python SDK，用于构建具有复杂可视化的实时 AI 应用程序。通过将网络应用程序编码的复杂性抽象化，从应用程序开发者那里移除，同时将高级 UI 组件作为模板、主题和小部件公开，实现了低代码。数据科学家和机器学习工程师被视为开发者（以及软件开发者本身）。

H2O 数据科学家构建了 H2O Wave 应用程序的示例，作为功能演示。这些可以在 H2O AI Cloud 90 天评估网站上找到h2o.ai/freetrial。更多示例可以在 H2O 公共 GitHub 存储库github.com/h2oai/wave-apps找到。

我该如何尝试构建 Wave 应用程序？

有关下载 Wave 服务器和 SDK 以构建您自己的应用程序的说明，请参阅wave.h2o.ai/docs/installation。

关键特性和功能

以下为 H2O Wave 的关键特性和功能：

• 低代码 SDK：数据科学家和机器学习工程师专注于指定模板和小部件，并将数据输入其中以创建复杂的可视化、仪表板和工作流程。将网络应用程序代码的复杂性从开发者那里抽象出来。

• 广泛的本地数据连接器：您可以通过 SDK 访问超过 160 个数据源和接收器的连接器。

• 本地 H2O API：SDK 包括 H2O API，这些 API 集成了其他 H2O AI Cloud 组件。这使得数据科学家和机器学习工程师可以将机器生命周期的一些方面作为应用程序可视化和工作流程的后端进行集成。

• 使用任何 Python 包：应用程序作为容器隔离，因此允许应用程序使用任何 Python 包 – 例如，NumPy 和 pandas 用于数据处理，Bokeh 和 Matplotlib 用于数据可视化，仅举几个例子。

• 集成非 H2O 技术：当您的应用程序中的 Python 包代表公共 API，如 Twitter API、AWS 服务 API 或您自己的私有 Python API 时，Wave 应用程序可以将非 H2O 技术集成到其可视化和工作流程中。因此，Wave 应用程序可以作为跨越多种技术的单一玻璃窗构建。

• 发布到 H2O 应用商店：Wave 应用程序在本地开发后，发布到 H2O AI Cloud 应用商店供企业使用。

现在我们来看看 H2O 应用商店。

应用商店（H2O AI 应用商店）

H2O AI 应用商店在您的 H2O AI 云实例中托管您的 H2O Wave 应用程序。H2O Wave 应用程序以可搜索和基于角色的方式托管。登录到应用商店的用户只能看到他们有权使用的应用程序，并且可以通过自定义分类或搜索来找到它们。Wave 应用程序开发者向应用商店发布，管理员管理应用商店。

因此，应用程序消费者通过应用商店访问和使用 Wave 应用程序，尽管数据科学家和 ML 工程师开发者可以在发布到应用商店之前在本地与消费者进行原型设计。

现在我们来对 H2O AI 云架构有一个高层次的理解。

H2O AI 云架构

我们不会深入探讨 H2O AI 云架构，但将回顾三个重要的架构点：

• 组件模块化和开放：平台的模块化架构允许企业或组使用他们需要的组件，并隐藏和忽略他们不需要的组件。H2O AI 云也是开放的——其组件可以与更大的企业生态系统共存并交互，包括非 H2O AI/ML 组件。例如，MLOps 组件可以托管非 H2O 模型，如 scikit-learn 模型，AI 应用程序 Wave SDK 可以将其自己的 API 与非 H2O API 集成。

• 云原生架构：H2O AI 云建立在现代 Kubernetes 架构之上，实现了云服务器之间的高效资源消耗。此外，AI 云上的 H2O 工作负载是短暂的——需要时启动，不使用时关闭，再次启动时保留状态。H2O AI 云还利用云服务提供商的管理服务——例如，使用云管理的 Kubernetes 服务，并在管理 PostgreSQL 数据库中维护状态。

• 灵活部署：H2O AI 云可以在企业的云中、本地或混合环境中部署。或者，它也可以作为托管服务消费，其中 H2O 在 H2O 的云环境中托管和管理企业的 H2O AI 云平台。

这些架构点与每个组件的能力相结合，意味着企业可以将 H2O AI 云适应其特定的环境、用例需求以及其 AI 转型旅程的阶段。

让我们总结一下本章所学的内容。

摘要

在本章中，我们将视野扩展到H2O ML at scale之外，这是本书迄今为止的重点。我们通过引入 H2O 的端到端机器学习平台 H2O AI Cloud 来实现这一点。该平台在机器学习生命周期的模型构建和模型部署步骤中具有一系列广泛的组件，并引入了这一流程中较少考虑的一层——易于构建的 AI 应用程序和为它们服务的应用商店。我们了解到，H2O AI Cloud 有四个用于构建机器学习模型的专用引擎——DistributedML、AutoML、DeepLearningML 和 DocumentML。我们还了解到，MLOps 围绕部署、监控、管理和治理评分模型具有完整的功能集。我们还了解到，特征存储可用于集中和重用模型构建和模型评分的特征。

重要的是，我们了解到本书的重点，即在大型数据集上构建机器学习模型并将其部署到企业系统进行评分（我们称之为 H2O at scale），实际上使用的是 H2O AI Cloud 更大平台的一个子集的技术（H2O Core、H2O Enterprise Steam 和 H2O MOJO）。

我们指出，H2O at scale 技术可以独立于 H2O AI Cloud 部署，或者作为更大平台的一部分。在下一章中，我们将看到 H2O at scale 作为 H2O AI Cloud 的成员所承担的额外功能。

第十四章：在更大平台环境下的 H2O 规模化

在上一章中，我们通过介绍 H2O AI 云，一个由多个模型构建引擎、模型部署、监控和管理平台 MLOps、用于重用和操作模型特征的特性存储以及构建在上述组件之上并在企业应用商店中托管的人工智能应用的低代码软件开发工具包（SDK）组成的端到端机器学习（ML）平台，扩展了我们对 H2O ML 技术的视野。本书的重点是我们所说的H2O 规模化，即使用 H2O Core（H2O-3 和 Sparkling Water）在大量数据集上构建准确和可信的模型，使用 H2O Enterprise Steam 来管理 H2O Core 用户及其环境，以及使用 H2O MOJO 轻松灵活地将模型部署到各种目标环境中。我们了解到，这些 H2O 规模化的组件是 H2O AI 云平台的原生部分，尽管它们可以独立于它部署。

在本章中，我们将探讨 H2O 规模化作为 H2O AI 云平台的一员如何获得更大的能力。更具体地说，我们将涵盖以下主题：

• 快速回顾 H2O AI 云

• 探索 H2O 规模化的基线参考解决方案

• 探索 H2O 规模化的新可能性

• 作为企业 AI 集成织物的参考 H2O Wave 应用

技术要求

此链接将帮助您开始开发 H2O Wave 应用：wave.h2o.ai/docs/installation。H2O Wave 是开源的，可以在您的本地机器上开发。为了全面熟悉 H2O AI 云平台，您可以在h2o.ai/freetrial注册 90 天的 H2O AI 云试用。

快速回顾 H2O AI 云

本章的目标是探讨 H2O 规模化，本书的重点，作为 H2O AI 云平台的一部分时，如何获得新的功能。让我们首先快速回顾 H2O AI 云，通过重新审视我们在上一章中遇到的以下图表：

图 14.1 – H2O AI 云平台组件

简要总结一下，我们看到 H2O AI 云有四个专门的模型构建引擎。H2O Core（H2O-3，H2O Sparkling Water）代表 H2O DistributedML，用于在大量数据集上水平扩展模型构建。在这个背景下，H2O Enterprise Steam 代表一个更通用的工具，用于管理和提供模型构建引擎。

我们看到，从 H2O Core 模型构建导出的 H2O MOJO 可以直接部署到 H2O MLOps 模型部署、监控和管理平台（尽管，如第十章，H2O 模型部署模式中所示，MOJO 也可以公开部署到其他目标）。请注意，H2O 的专用自动化机器学习（AutoML）引擎 Driverless AI 也生成 MOJO，并可以按照第十章，H2O 模型部署模式中所示的方式进行部署。我们还看到，H2O AI 特征存储可用于在模型构建和模型部署环境中共享和操作特征。

最后，我们看到 H2O Wave SDK 可用于在 H2O AI Cloud 平台的其他组件之上构建 AI 应用，并将其作为平台的一部分发布到 H2O App Store。

现在让我们开始将这些组件组合成各种 H2O-at-scale 解决方案。

探索 H2O 在规模上的基线参考解决方案

因此，现在让我们探索 H2O-at-scale 组件如何从参与 H2O AI Cloud 平台中受益。为此，让我们首先从 H2O AI Cloud 之外的 H2O at scale 的基线解决方案开始。基线解决方案如下所示。我们将使用这个基线来比较 H2O at scale 与 AI Cloud 组件集成的解决方案：

![Figure 14.2 – H2O 在规模上的基线解决方案

图 14.2 – H2O 在规模上的基线解决方案

重要提示

对于本章中的所有解决方案，假设数据科学家使用 H2O Enterprise Steam 启动了 H2O-3 或 H2O Sparkling Water 环境。请参阅第三章，基本工作流程 – 从数据到可部署模型，以了解这一步骤的概述。

其解决方案流程的快速概述如下：

1. 数据科学家导入一个大型数据集，并使用它来构建大规模的 ML 模型。请参阅第二部分，使用 H2O 在大型数据量上构建最先进的模型，以深入了解这一主题。

2. 运作组将模型工件（称为 H2O MOJO）部署到评分环境中。请参阅第十章，H2O 模型部署模式，以探索 H2O 模型部署的各种目标系统。

3. 预测被业务环境中的软件或工具消费并采取行动。（在这里，我们假设部署的模型是一个监督学习模型，尽管它可能是一个未监督模型，生成了不是预测的输出；例如，输入的聚类成员资格）。

让我们使用这个基线解决方案来开始添加 H2O AI Cloud 组件，从而了解 H2O 在规模上的能力如何通过加入这个更大的平台而获得额外的功能。

探索 H2O 在规模上的新可能性

现在，让我们逐步了解如何将 H2O（本书的重点）与其他 H2O AI Cloud 平台集成，从而实现更大的能力和价值。

利用 H2O Driverless AI 进行原型化和特征发现

H2O 的 AutoML Driverless AI 组件是一个高度自动化的模型构建工具，它使用（包括其他功能）遗传算法、AI 启发式方法和详尽的自动化特征工程来构建准确且可解释的模型——通常在几小时内完成——然后部署到生产系统。然而，Driverless AI 无法扩展到在 H2O-3 和 Sparkling Water 处理的数百 GB 到 TB 大小的数据集上进行训练。

然而，对于数据科学家来说，将这些大规模数据集的采样数据输入到 Driverless AI，然后使用 AutoML 工具（a）快速原型化模型以获得早期理解，以及（b）发现有助于准确模型的自动工程特征，但通过纯手动和领域知识手段难以找到，这非常有用。在此工作流程中，Driverless AI 产生的知识随后用作起点，使用 H2O-3 或 Sparkling Water 在原始未采样的数据上构建大规模模型。

这在以下图表中显示，然后进行总结：

![图 14.3 – 利用 H2O Driverless AI 进行原型化和特征发现]

![图片 B16721_14_003.jpg]

图 14.3 – 利用 H2O Driverless AI 进行原型化和特征发现

这里提供了利用 Driverless AI 快速原型化和发现用于大规模模型构建的特征的工作流程步骤：

1. 将大量数据集导入到 H2O-at-scale 环境固有的分布式内存架构中。使用 H2O-3 的split_frame方法（此处为 Python）对导入的数据进行采样，形成一个较小的子集（通常为 10 到 100 GB），并定义一个合适的比例作为输入参数以实现所需的样本大小。将输出写入 Driverless AI 可以访问的临时存储位置。

2. 将采样数据集导入 Driverless AI。使用默认设置快速原型化一个准确的模型。根据您的领域和数据科学经验使用不同的设置继续原型化。探索模型的可解释性技术。探索对模型贡献最大的工程特征。使用自动化模型文档（AutoDoc）深入了解模型，并将工程特征的名称转换为它们背后的数学和逻辑表示。

3. 使用步骤 2中的知识来指导您在 H2O-3 或 Sparkling Water 上对完整的大量数据集进行模型构建。

在第十三章“介绍 H2O AI Cloud”中概述了 Driverless AI。以下截图显示了一个实验迭代以获得最终准确模型：

![图 14.4 – Driverless AI 找到一个准确模型]

![图片 B16721_14_004.jpg]

图 14.4 – 无人驾驶 AI 找到一个准确的模型

注意图 14.4 的左下角面板，它显示了遗传算法在模型间迭代的进度。每个方块是一个单独构建的 ML 模型。这些模型中每一个都使用自动选择的算法之一（例如，XGBoost；轻梯度提升模型（LightGBM）；广义线性模型（GLM）），这些算法探索了极其广泛的超参数空间（例如，学习率、树深度、树的数量等组合）。

重要的是，遗传算法构建的每个模型也探索了从原始导入的数据集中工程化出的极其广泛的特征空间。实验将在最终的最佳模型结束时停止，通常是一个先前顶级模型的堆叠集成。用户可以在短时间内运行许多实验，目的是通过改变许多高级和低级设置并评估结果来探索。

从这些快速探索中获得的知识，包括对最终模型重要的特征工程，可以用作使用 H2O-3 或 Sparkling Water 构建大规模模型的起点。

注意，对于较小的数据集，无人驾驶 AI 在短时间内发现高度预测性模型非常有效。然而，对于扩展到大量数据集或采用更受控的基于代码的方法来构建模型，则需要 H2O-3 和 Sparkling Water。正如这里所示，对于基于代码的方法，首先使用无人驾驶 AI 原型化一个问题，然后利用产生的洞察力和工程化特征作为基于代码方法的指南，这是很有价值的。

无人驾驶 AI（AutoML）与 H2O-3（分布式 ML）对比：何时使用哪一个？

无人驾驶 AI 是 H2O AI 云的一个高度自动化的基于用户界面（UI）或基于应用程序编程接口（API）的 AutoML 组件，旨在快速找到准确且值得信赖的模型用于生产评分。当你想要一个高度自动化的方法（具有广泛的用户控制）来构建模型，并且数据集大小小于 100 GB 时（尽管更重的服务器实例可以处理更大的数据集）请使用它。

当你的数据集大于 100 GB（甚至达到 TB 级别）或当你想要对模型构建过程有更多控制时，请使用 H2O-3 或 Sparkling Water。请注意，H2O-3 和 Sparkling Water 具有 AutoML 功能，如第五章中所述，高级模型构建 – 第一部分，但无人驾驶 AI 中的功能更为复杂、广泛和自动化。

使用无人驾驶 AI 原型化一个问题，并将产生的洞察力和工程化特征的发现用于指导你在 H2O-3 或 Sparkling Water 上的模型构建。

我们已经看到了第一个例子，通过与 H2O AI 云平台的一个组件交互，H2O-at-scale 模型构建获得了能力。现在让我们看看下一个例子。

集成 H2O MLOps 以进行模型监控、管理和治理

使用 H2O-3 和 Sparkling Water 构建的模型会生成自己的低延迟评分工件，称为 H2O MOJO。正如我们在第十章，“*H2O 模型部署模式”中所示，这种评分工件可以部署到各种生产系统，从 REpresentational State Transfer (REST) 服务器上的实时评分到数据库上的批量评分，以及从流队列中的评分（仅举几例）。我们还展示了在该章节中，将数据部署到 REST 服务器为将评分预测集成到常见的 商业智能 (BI) 工具（如 Microsoft Excel 或 Tableau）提供了一个有用的集成模式。

H2O AI Cloud 的 H2O MLOps 组件是部署 H2O-3 或 Sparkling Water 模型（或 Driverless AI 模型和非 H2O 模型，例如 scikit-learn 模型）的一个很好的选择。集成非常简单，如下面的图所示：

![Figure 14.5 – Deployment of H2O-at-scale models to the H2O MLOps platform

![img/B16721_14_005.jpg]

图 14.5 – 将 H2O-at-scale 模型部署到 H2O MLOps 平台

集成这些模型的步骤非常简单，如下所述：

1. 使用 H2O-3 或 Sparkling Water 构建您的模型，并导出 MOJO 以进行部署。

2. 从 H2O MLOps，您可以从 UI 或 MLOps API 中部署预制的 MOJO。回想一下第十三章，“*介绍 H2O AI Cloud”，那里有许多部署选项，包括实时与批量、单个模型与冠军/挑战者，或 A/B 测试。

3. 模型现在可以从一个独特的 REST 端点进行评分。带有可选原因代码的预测准备就绪，可供您的系统消费，无论该系统是 Web 应用程序、BI 工具等。

在此流程期间和之后的所有模型中，MLOps 执行与监控、管理和治理模型相关的重要任务。例如，以下截图显示了 H2O MLOps 的数据漂移监控屏幕：

![Figure 14.6 – Model-monitoring screen for H2O MLOps

![img/B16721_14_006.jpg]

图 14.6 – H2O MLOps 的模型监控屏幕

监控数据漂移的目的是检测实时评分数据中特征值的分布是否与构建模型时所用的训练数据中的分布存在差异。数据漂移的存在表明或暗示模型应该使用更近期的数据进行重新训练，然后重新部署以与当前的评分数据对齐。

在图 14.6的左下角面板中，所有模型特征的数据漂移以两个维度表示：垂直轴上的漂移和水平轴上的特征重要性。这种视图允许将漂移分为漂移重要性的四个象限，其中高漂移和高特征重要性是最重要的漂移。有多个设置可以定义漂移统计量、测量的时间框架和其他查看漂移的方面。还有一个工作流程来配置漂移的自动警报消息。这些可以用于数据科学家手动决定是否重新训练模型，或者通过 H2O API 完全自动地重新训练和部署模型。

漂移检测只是 H2O MLOps 功能之一。有关 H2O MLOps 模型部署、监控、管理和治理功能的完整描述，请参阅 H2O 文档docs.h2o.ai/mlops/。

现在我们来看一下 H2O-3 和 Sparkling Water 如何集成到 H2O AI 特征存储中。

利用 H2O AI 特征存储进行特征操作化和复用

企业通常通过在组织内部集中和共享环境或资产来实现规模经济。H2O AI 特征存储通过集中模型特征及其通过工程管道进行操作化的实现，在整个组织内进行复用，从而实现规模经济。

通过特征存储的复用发生在模型构建和模型评分的上下文中。例如，假设在整个组织中的一个有价值特征是资产价格相对于前一天的百分比变化。然而，想象一下，资产价格以每日价格存储，并且资产价格存储在多个源系统中。特征存储处理从源系统中检索特征，从原始数据（即特征工程管道）计算新值，并将结果（即工程化特征）缓存以供模型训练和模型评分共享。模型构建使用离线模式——即批量历史数据——并使用在线模式进行模型评分——即最近的数据。这在下图中显示：

图 14.7 – H2O AI 特征存储与 H2O-3 或 Sparkling Water 的集成

下面是图 14.7中的工作流程总结：

1. 数据科学家构建一个模型。

2. 在模型构建阶段，数据科学家可能以两种不同的方式与特征存储进行交互，如下所述：

   • 数据科学家可能将特征发布到特征存储库，并包括相关的元数据以帮助他人进行搜索和操作。机器学习工程师将特征从数据源（源）的操作工程化，以向特征存储库中的特征值提供数据。每个特征都配置了在更新之前存活的时间——例如，每分钟、每天或每月更新一次。

   • 在模型构建期间，数据科学家可以在特征存储库中搜索特征。他们使用特征存储库 API 将特征及其值导入由 H2O-3 或 Sparkling Water 加载的培训数据（更具体地说，导入内存中的 H2OFrame，它与 DataFrame 类似）。

3. 模型部署到 H2O MLOps，该系统配置为从特征存储库中消耗特征。特征在其配置的间隔内更新。

4. 消耗预测和（可选）原因代码。

我们的工作流程以预测被消耗结束。现在让我们展示 H2O Wave SDK 如何被数据科学家和机器学习工程师快速构建具有复杂可视化和工作流程的 AI 应用，这些工作流程围绕模型预测。

从 Wave AI 应用中在业务环境中消耗预测

机器学习模型只有在它们的输出被用于执行工作流程的个人或自动化系统消费时才能获得价值。这些工作流程可以基于单个预测及其背后的原因代码，或者从它们中获得的洞察和智能。例如，客户服务代表识别出有高概率离开业务的客户，并主动与他们联系，提供改进或激励措施以保持业务，基于模型对其可能流失的预测的原因。或者，分析师探索过去 6 个月内做出的多个流失预测交互式仪表板，以了解流失的原因，并确定业务可以在哪些方面改进以防止流失。

如我们在第十三章中学习的，介绍 H2O AI Cloud，H2O Wave 是一个低代码 SDK，数据科学家和机器学习工程师使用它来轻松构建 AI 应用并将它们发布到企业或外部使用的 App Store。我们所说的 AI 应用是什么意思？这里的 AI 应用是一个展示机器学习生命周期一个或多个阶段的富可视化、用户交互和工作流程序列的 Web 应用。H2O Wave SDK 通过将 UI 元素（仪表板模板、对话框和小部件）作为基于属性的 Python 代码暴露出来，同时抽象出构建 Web 应用的复杂性，使得这些应用易于构建。

在我们的示例中，Wave 应用被特定地用于由业务角色消耗预测，如下面的图所示。请注意，我们的下一个示例将是一个由数据科学家使用的 Wave 应用，用于管理模型重新训练，而不是消耗预测：

图 14.8 – Wave AI 应用中的预测消费

图 14.8中的 ML 工作流程是熟悉的，但 Wave 应用消耗预测。Wave 的低代码 SDK 支持多种集成协议，因此允许从 REST 端点实时消耗预测和原因代码，或者从文件上传或数据仓库连接批量消耗，例如。如图所示，从业务角度来看，消耗预测的 Wave 应用可以执行以下操作：

• 从历史和个体预测视图可视化预测

• 从全局（模型级）和个体（单个模型评分）视图，可视化来自底层预测原因代码的洞察

• 对预测和洞察进行 BI 分析

• 执行人类在循环中的工作流程，以对可视化和分析采取行动

让我们来看一个具体的例子。下面的截图显示了 Wave 应用消耗并显示员工流失预测可视化的一页——换句话说，就是员工离职的预测可能性：

![图 14.9 – 一个可视化员工流失的 Wave 应用

图 14.9 – 一个可视化员工流失的 Wave 应用

本页显示了最新一批员工流失预测的视图。左上角的面板显示了这些预测的概率分布。我们可以看到，大多数被模型评分的员工离职概率较低，尽管有较高概率的员工的长尾。右上角的面板提供了关于员工离职原因的洞察：它显示了 Shapley 值或特征贡献（原因代码）对预测的影响。我们看到，加班、工作角色和班次安排是导致模型预测流失的前三大因素。底部面板显示了可视化，有助于更好地理解这些预测：左面板显示了流失可能性的地理分布，右面板显示了按工作角色的分解。地图上方的细面板允许用户交互，其中滑块定义了将员工分类为流失或非流失的概率阈值：底部两个面板相应刷新。

Wave 应用的上一张截图展示了批量级别的预测可视化——即在一个时间段内所有员工的评分。该应用还有一个页面，可以显示个体级别的预测可视化。当用户点击某个个体员工（显示相关的流失概率和其他员工数据）时，会显示 Shapley 值，显示对那个个体流失可能性贡献最大的特征。例如，某个个体可能显示月收入是预测的主要贡献因素，而加班实际上有助于该个体不流失。这个洞察表明，员工可能因为收入不足而试图赚更多钱，从而离开公司。这允许员工的经理评估加薪，以确保他们留在组织中。

图 14.9中的 UI 显示了将预测置于业务背景中的情况，个人可以据此采取行动。请记住，H2O Wave 非常易于扩展，可以将其喜欢的 Python 包（包括 Python API）纳入非 H2O 组件。此外，请记住，这里展示的示例 Wave 应用旨在作为一个能力演示器：它不是一个现成的点解决方案来管理员工流失，而是一个数据科学家和 ML 工程师如何使用 Wave SDK 轻松构建 AI 应用的示例。

H2O Wave SDK 非常易于扩展

图 14.9中的 UI 相对简单，但仍然有效地将预测置于业务和数据分析的背景中。H2O Wave SDK 非常易于扩展，因此允许在基于其构建的应用中包含更复杂的层次结构。

例如，你可以实现 HTML层叠样式表（CSS）来给用户体验（UX）带来更现代或公司特定的外观。由于 Wave 应用是容器化和相互隔离的，你可以安装任何 Python 包并在应用中使用它。例如，你可以实现Bokeh进行强大的交互式可视化或pandas进行数据处理，或者供应商或自建的 Python API 来与你的技术生态系统的一部分进行交互。

注意，H2O Wave 的主要目的是让你使用其 SDK 构建自己的 AI 应用，并使其针对你的需求量身定制。应用是在本地开发的，可以快速为预期用户进行原型设计，然后最终完成、润色并发布到 H2O App Store，供企业基于角色的消费。然而，H2O 将提供示例应用给你作为代码加速器。

你可以通过注册 H2O AI Cloud 的 90 天免费试用版来探索实时 Wave 应用，h2o.ai/freetrial/。你还可以通过访问wave.h2o.ai/来探索和使用开源的 H2O Wave SDK。

我们刚刚探讨了如何构建 Wave 应用程序以作为业务分析和决策工作流程的一部分来消耗预测。业务用户不一定是唯一的 Wave 应用程序用户。现在让我们看看一个由数据科学家使用并构建的 Wave 应用程序，用于驱动 ML 生命周期的模型构建和模型部署阶段。

在 Wave AI 应用程序中集成自动重新训练管道

H2O Wave SDK 包括对其他 H2O AI Cloud 组件的原生 API。这使得数据科学家能够构建 Wave 应用程序以完成数据科学工作流程（与在业务用户环境中构建应用程序相比，如前一个示例所示）。

数据科学中的一个常见需求，例如，是识别已部署模型中的数据漂移，然后使用最近的数据重新训练模型，并重新部署更新后的模型。以下图表显示了如何使用 Wave 应用程序作为自动化编排器和跟踪重新训练历史以及围绕历史进行分析的 UI 来完成此操作。这是一个应用程序想法，可以有不同的定义，但一般想法应该是有帮助的。

在这里，您可以查看整个 ML 工作流程的概述：

![图 14.10 – 自动模型重新训练的 Wave 应用程序]

![img/B16721_14_010.jpg]

图 14.10 – 自动模型重新训练的 Wave 应用程序

工作流程总结如下：

1. 模型在 H2O-3 或 Sparkling Water（或其他 H2O 模型构建引擎，如 Driverless AI）中构建和评估。

2. 该模型已部署到 H2O MLOps，并消耗了预测结果。MLOps 已配置为检测模型上的数据漂移。

3. 在某个时间点，模型的漂移超过了配置的阈值，并向您构建的模型重新训练 Wave 应用程序发送警报。

4. 模型重新训练 Wave 应用程序触发在 H2O 模型构建引擎（在我们的案例中，H2O-3 或 Sparkling Water）上重新训练模型。Wave 应用程序将重新训练的模型作为挑战者部署到 H2O MLOps（使用 MLOps API），经过一段时间后，Wave 应用程序评估新重新训练的挑战者与现有冠军模型的性能。如果前者优于后者，挑战者将被提升以取代冠军。从这个点开始，周期（步骤 3 和 4）继续进行。

模型重新训练 Wave 应用程序可以提供关于模型重新训练的报告、可视化和分析。例如，可能有一个包括重新训练时间、漂移测量、当前状态（例如，训练进行中、模型已部署、处于挑战者状态或冠军状态）等的重新训练历史记录表。可以提供提供更多数据漂移和模型重新训练及部署管道洞察力的可视化。作为替代，可以通过人工流程代替自动化，其中管道中的步骤根据数据科学家的评估手动完成。

H2O Wave 作为应用构建框架的目标是让您能够轻松地根据自己的规格构建应用，并将您生态系统中的其他组件集成到应用中。因此，您可能对模型重新训练应用的想法与这里展示的不同。H2O Wave SDK 允许您构建您所设想的应用。

在我们的示例模型重新训练应用中，我们将多个 H2O 组件集成到 Wave 应用工作流程中，包括可视化和分析。在下一节中，我们将扩展集成到您生态系统中的非 H2O 组件，从而展示一个强大的框架，用于构建作为您 AI 生态系统单一视窗的 Wave 应用。

作为企业 AI 集成织物的参考 H2O Wave 应用

低代码 Wave SDK 允许数据科学家、机器学习工程师和软件开发者构建将一个或多个参与机器学习生命周期的 H2O 组件集成到单个应用中的应用。因此，H2O Wave 是一个强大的集成故事。

然而，有两个 Wave 设计事实需要重新审视，因为它们使这个集成故事更加强大。首先，Wave 应用在容器中部署，因此与其他 Wave 应用隔离。其次，开发者可以将公开可用的或专有 Python 包和 API 安装并集成到应用中。这意味着 H2O Wave 应用可以将 H2O 和非 H2O 组件集成到单个应用中。这可以重新表述如下：H2O 应用可以作为整个 AI 相关企业生态系统的单一视窗构建。以下图表展示了这一点：

![图 14.11 – H2O Wave AI 应用作为企业生态系统的一层]

![img/B16721_14_011.jpg]

图 14.11 – H2O Wave AI 应用作为企业生态系统的一层

数据科学家、工程师和软件开发者可以构建 Wave 应用，将 H2O AI Cloud 的端到端机器学习平台与企业生态系统及其底层云服务中的 AI 相关和非 AI 相关组件结合起来。这些多样化的应用托管在 H2O 应用商店中，具有基于角色的访问权限，因此可供多样化的企业利益相关者消费者使用。让我们通过以下图表进一步分解这一点。

![图 14.12 – 参考 H2O Wave AI 应用在企业生态系统中的分层]

![img/B16721_14_012.jpg]

![图 14.12 – 参考 H2O Wave AI 应用在企业生态系统中的分层]

这是一个参考的 H2O Wave AI 应用，展示了其作为 UI 集成层在整个 AI 相关生态系统中的全部潜力。目标是展示这方面的全部功能，并激发您的想象力，将这个通用参考实例化到符合您特定 AI 需求的具体应用中。

让我们按照以下方式回顾这些功能：

• 低代码 Python SDK: Wave 的低代码 Python SDK 允许数据科学家、ML 工程师和软件开发人员以熟悉的 Python 风格开发 AI 应用程序，专注于在控件和模板中填充数据，并忽略 Web 应用程序的复杂性。如果需要，SDK 可以通过 CSS 样式表进行扩展，以实现特定的外观和感觉。

• 数据连接器: Wave SDK 拥有超过 140 个连接器，可以连接到各种数据源和目标，这使得将 Wave 应用程序集成到您的数据生态系统中变得非常容易。

• H2O AI Cloud API: Wave SDK 为 H2O AI Cloud 平台的所有组件提供了 API：四个模型构建引擎及其配置工具，以及 MLOps 和特征存储组件。这些集成提供了强大的方式，从应用程序的角度与 ML 生命周期的各个方面进行交互。我们已经在之前讨论的评分消费和模型重训练 Wave 应用程序中快速浏览了这些可能性。

• 已安装的 Python 包: Wave SDK 可以扩展到您想要安装的任何 Python 包。这允许您，例如，使用更专业的绘图或交互式可视化功能扩展本地的 Wave UI 组件，或者使用熟悉的包来操作数据。

• 已安装的 Python API: 您还可以安装作为您企业生态系统其他部分 API 的 Python 库，无论是您自己的组件、非 H2O 供应商组件，还是应用程序和本地云服务。这是一种非常强大的方式，可以通过连接到 H2O AI Cloud 组件的 API 来编排整个企业生态系统中驱动的 ML 工作流程。

正如刚刚概述的能力和集成，为 Wave 应用程序提供了几乎无限的方式来实现企业-AI 分析和工作流程。例如，您可以将模型部署和监控集成到现有的多步骤治理流程工作流程中。您可以构建 UI 工作流程，用户可以在数据目录中搜索授权的数据源，选择数据源，然后启动并访问带有数据源加载的 H2O 模型构建环境。这些只是两个例子，以激发您的思维。如图 14.11 所示，您可以根据自己的特定和创造性的方式将许多组件结合起来，以扩展 ML 的功能，使其超越模型构建和评分，并扩展到工作流程和多方商业价值的更大背景中。

摘要

在本章中，我们探讨了 H2O-at-scale 技术（H2O-3、H2O Sparkling Water、H2O Enterprise Steam 和 H2O MOJO）如何通过参与更大的 H2O AI Cloud 端到端机器学习 ML 平台来扩展其功能。例如，我们看到了 H2O-3 和 Sparkling Water 如何从初始快速原型设计和自动化特征发现中获益。同样，我们也看到了 H2O-3 和 Sparkling Water 模型如何轻松部署到 H2O MLOps 平台，在那里它们从其模型评分、监控和管理能力中获得价值。我们还看到了 H2O AI Feature Store 如何将特征操作化为共享，无论是在 H2O-3 或 Sparkling Water 中构建模型，还是在 H2O MLOps 上进行模型评分。

我们开始探索 H2O 开源低代码 Wave SDK 的力量，以及数据科学家、机器学习工程师和软件开发人员如何利用它轻松地在 H2O 组件和整个机器学习生命周期中创建可视化、分析和工作流程。这些应用发布到 H2O 平台的 App Store 组件中，在那里它们被企业利益相关者、外部合作伙伴或企业的客户所使用。我们探索的一个 Wave 应用示例是一个员工流失应用，用于消费、理解和响应关于个人离职可能性的预测。另一个是模型重新训练应用，数据科学家通过利用 Wave 应用底层与 H2O-3 和 H2O MLOps 的 SDK 集成来管理和跟踪自动化的模型重新训练工作负载。

最后，我们介绍了一个参考 Wave AI 应用，用于构建跨越 H2O 和非 H2O 企业-AI 生态系统的应用，从而形成一个企业-AI 集成框架。

因此，我们通过使用 H2O 进行大规模机器学习并将其置于 H2O 更大的端到端机器学习 ML 平台 H2O AI Cloud 的背景下，完成了这本书。通过将成熟的、经过验证的 H2O at scale 技术与新的、快速创新的 H2O AI Cloud 平台相结合，H2O.ai 正在继续证明自己在定义和创造新的机器学习可能性以及为企业创造价值方面是一个前沿的参与者。

第十五章：附录：启动 H2O 集群的替代方法

本附录将向您展示如何在您的本地机器上启动 H2O-3 和 Sparkling Water 集群，以便您可以在本书中运行代码示例。我们还将向您展示如何在 H2O AI Cloud 的 90 天免费试用环境中启动 H2O 集群。此试用环境包括 Enterprise Steam，用于在 Kubernetes 基础设施上启动和管理 H2O 集群。

环境注意事项

架构：如第二章中介绍，平台组件和关键概念，您将使用客户端环境（实现了 H2O-3 或 Sparkling Water 库）来运行针对远程 H2O-3 或 Sparkling Water 架构的命令，该架构分布在 Kubernetes 或 Hadoop 集群的多台服务器节点上。然而，对于小型数据集，架构可以在与客户端相同的机器上作为单个进程本地启动。

版本：本书中的功能和使用代码示例使用以下版本：H2O-3 版本 3.34.0.7，以及 Sparkling Water 版本 3.34.0.7-1-3.2 以在 Spark 3.2 上运行。您将使用最新的（最新）稳定版本来设置您的环境，这将允许您运行本书中的相同代码示例，但也将包括在本书编写后添加到 H2O-3 和 Sparkling Water 中的功能。

语言：您可以在 Python、R 或 Java/Scala 中设置客户端环境。本书我们将使用 Python。您的 Python 客户端可以是 Jupyter notebook、PyCharm 或其他。

让我们学习如何在本地环境中完全运行 H2O-3。

本地 H2O-3 集群

这是运行 H2O-3 的一种最简单的方法，适用于本书代码示例中使用的较小数据集。它将在您的本地机器上启动 H2O-3（与企业集群环境相对），并且不涉及 H2O Enterprise Steam。

首先，我们将一次性设置我们的 H2O-3 Python 环境。

第 1 步 – 在 Python 中安装 H2O-3

要设置您的 H2O-3 Python 客户端，只需在您的 Python 环境中安装三个模块依赖项，然后安装 h2o-3 Python 模块。您必须使用 Python 2.7.x、3.5.x、3.6.x 或 3.7.x。

更具体地说，请执行以下操作：

1. 在您的 Python 环境中安装依赖项：

   pip install requests
   pip install tabulate
   pip install future 
   

2. 在您的 Python 环境中安装 H2O-3 库：

   pip install h2o
   

请参阅h2o-release.s3.amazonaws.com/h2o/rel-zumbo/1/index.html（在 Python 中安装选项卡）以在 Conda 中安装 H2O-3。

您现在可以本地运行 H2O-3 了。让我们看看如何做到这一点。

第 2 步 – 启动您的 H2O-3 集群并编写代码

要启动本地单节点 H2O-3 集群，只需在您的 Python IDE 中运行以下命令：

import h2o

h2o.init()

# write h2o-3 code, including code samples in this book

您现在可以编写您的 H2O-3 代码，包括本书中的所有示例。请参阅第二章，平台组件和关键概念，以获取Hello World代码示例及其底层解释。

Java 依赖项 - 仅当本地运行时

H2O-3 集群（不是 Python 客户端）在 Java 上运行。因为您在这里在本地机器上运行集群（代表单节点集群），您必须安装 Java。当您使用 Python 客户端连接到您的企业 Kubernetes 或 Hadoop 环境中的远程 H2O 集群时，不需要 Java。

现在，让我们看看如何设置我们的环境，以便在我们的本地机器上编写 Sparkling Water 代码。

本地 Sparkling Water 集群

在本地运行 Sparkling Water 与在本地运行 H2O-3 类似，但需要 Spark 依赖项。有关 Spark、Python 和 H2O 组件的完整解释，请参阅此链接：docs.h2o.ai/sparkling-water/3.2/latest-stable/doc/pysparkling.html。

我们在这里将使用 Spark 3.2。要使用不同版本的 Spark，请访问以下链接的 H2O 下载页面中的Sparkling Water部分：h2o.ai/resources/download/。

对于您的 Sparkling Water Python 客户端，您必须使用 Python 2.7.x、3.5.x、3.6.x 或 3.7.x。我们在这里将从 Jupyter 笔记本中运行 Sparkling Water。

第 1 步 - 在本地安装 Spark

按照以下步骤在本地安装 Spark：

1. 前往spark.apache.org/downloads.html下载 Spark。进行以下选择，然后下载：

   • Spark 版本：3.2.x

   • 包类型：为 Hadoop 3.3 及更高版本预构建

2. 解压下载的文件。

3. 设置以下环境变量（以下为 macOS 示例）：

   export SPARK_HOME="/path/to/spark/folder"
   export MASTER="local[*]"
   

现在，让我们在我们的 Python 环境中安装 Sparkling Water 库。

第 2 步 - 在 Python 中安装 Sparkling Water

安装以下模块：

1. 在您的 Python 环境中安装依赖项：

   pip install requests
   pip install tabulate
   pip install future 
   

2. 安装 Sparkling Water Python 模块（称为PySparkling）。请注意，此处模块引用 Spark 3.2：

   pip install h2o_pysparkling_3.2
   

接下来，让我们安装一个交互式 Shell。

第 3 步 - 安装 Sparkling Water Python 交互式 Shell

要在本地运行 Sparkling Water，我们需要安装一个交互式 Shell 来在 Spark 上启动 Sparkling Water 集群。（这仅在本地运行 Sparkling Water 时需要；Enterprise Steam 在您的企业集群上运行时负责此操作。）为此，请执行以下步骤：

1. 通过导航到h2o.ai/resources/download/的Sparkling Water部分，点击Sparkling Water For Spark 3.2，然后最终点击下载 Sparkling Water按钮来下载交互式 Shell。

2. 解压下载的文件。

现在，让我们启动一个 Sparkling Water 集群，并从 Jupyter 笔记本中访问它。

第 4 步 – 在 Sparkling Water 外壳上启动 Jupyter 笔记本

我们假设您已经在与步骤2中安装的相同 Python 环境中安装了 Jupyter Notebook。执行以下步骤以启动一个 Jupyter 笔记本：

1. 在命令行中，导航到您在第3步中解压缩下载的目录。

2. 启动 Sparkling Water 交互式外壳和其中的 Jupyter 笔记本：

   • 对于 macOS，请使用以下命令：

     PYSPARK_DRIVER_PYTHON="ipython" \
     PYSPARK_DRIVER_PYTHON_OPTS="notebook" \
     bin/pysparkling
     

   • 对于 Windows，请使用以下命令：

     SET PYSPARK_DRIVER_PYTHON=ipython
     SET PYSPARK_DRIVER_PYTHON_OPTS=notebook
     bin/pysparkling
     

您的 Jupyter 笔记本应该在浏览器中启动。

现在，让我们编写 Sparkling Water 代码。

第 5 步 – 启动您的 Sparkling Water 集群并编写代码

在您的 Jupyter 笔记本中，输入以下代码以开始：

1. 启动您的 Sparkling Water 集群：

   from pysparkling import *
   import h2o
   hc = H2OContext.getOrCreate()
   hc
   

2. 测试安装：

   localdata = "/path/to/my/csv"
   mysparkdata = spark.read.load(localdata, format="csv")
   myH2Odata = hc.asH2OFrame(mysparkdata)
   

您现在可以使用 H2O 和 Spark 代码构建模型，准备就绪。

H2O-3 集群在 H2O AI Cloud 的 90 天免费试用环境中

在这里，您必须与企业 Steam 交互以运行 H2O-3。在这种情况下，您需要在 Python 客户端环境中安装h2osteam模块，就像我们在本地运行 H2O-3 时做的那样，除了安装h2o模块。

第 1 步 – 获取 H2O AI Cloud 的 90 天试用期

在这里获取 H2O AI Cloud 的试用访问权限：h2o.ai/freetrial。

当您完成所有步骤并可以登录到 H2O AI Cloud 时，我们就可以开始运行作为 H2O AI Cloud 平台一部分的 H2O-3 集群。以下是下一步。

第 2 步 – 设置您的 Python 环境

要设置您的 Python 客户端环境，请执行以下步骤：

1. 登录到 H2O AI Cloud，然后从侧边栏点击Python 客户端选项，点击h2osteam库：

![图 15.1 – 企业 Steam]

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/ml-scl-h2o/img/B16721_15_001.jpg)

![图 15.1 – 企业 Steam]

1. 通过运行以下命令在您的 Python 环境中安装h2osteam库：

   pip install /path/to/download.whl
   

这里，/path/to/download.whl被替换为您实际的路径。

1. 您还需要安装h2o库。为此，执行以下操作：

   pip install requests
   pip install tabulate
   pip install future 
   pip install h2o
   

现在，让我们使用 Steam 启动一个 H2O 集群，然后在 Python 中编写 H2O 代码。

第 3 步 – 启动您的集群

按照以下步骤启动您的 H2O 集群，该集群在 Kubernetes 服务器集群上完成：

1. 在企业 Steam 中，点击侧边栏上的H2O，然后点击启动新集群按钮。

2. 您现在可以配置您的 H2O 集群并给它命名。请确保从下拉菜单中选择最新的 H2O 版本，它应该与您在上一步骤中安装的库相匹配。

3. 配置完成后，点击启动集群按钮，等待集群启动完成。

4. 您需要企业 Steam 的 URL 来从 Jupyter 笔记本或其他 Python 客户端连接到它。在 Steam 中，将 URL 从https复制到h2o.ai，包括在内。

第 4 步 – 编写 H2O-3 代码

我们现在可以开始编写代码（例如在 Jupyter 中）来构建我们刚刚启动的 H2O-3 集群上的模型。在打开 Python 客户端后执行以下步骤：

1. 导入您的库并连接到 Enterprise Steam：

   import h2o
   import h2osteam
   from h2osteam.clients import H2oKubernetesClient
   conn = h2osteam.login(
       url="https://SteamURL, 
   verify_ssl=False,
       username="yourH2OAICloudUserName", 
       password=" yourH2OAICloudPassword")
   

   重要提示

   在撰写本文时，90 天 H2O AI Cloud 试用版的 URL 为steam.cloud.h2o.ai。

   对于密码，您可以使用您登录 H2O AI Cloud 试用环境的登录密码，或者您可以使用从 Enterprise Steam 配置页面生成的临时个人访问令牌。

2. 连接到您在 Enterprise Steam 中启动的 H2O 集群：

   cluster = H2oKubernetesClient().get_cluster(
       name="yourClusterName", 
       created_by="yourH2OAICloudUserName")
   cluster.connect()
   # you are now ready to write code to run on this H2O cluster
   

您现在可以编写您的 H2O-3 代码，包括本书中的所有示例。