全文共3468字，预计学习时长9分钟
插图：Alexis Jamet
在过去的几年里，为了克服将机器学习模型应用于生产的挑战，工具数量大幅增长。这些工具似乎有一个共同点，就是将Notebook 并入生产线。
本文旨在解释为什么在生产中使用Notebook是一种反常规的做法，并提出了一些建议。
什么是 Notebook？
对于没有接触过 Notebook ，或者用其他名字来称呼这个工具的读者，我们首先从定义入手，Notebook是允许用户创建包含代码、可视化和文本文档的 Web 界面。如图所示：
Notebook 有什么用？
可能恰恰与你从导言中看到的相反， Notebook并不是一无是处。它们在某些场景中非常有用，下文将进行详细描述。
数据分析
这可能是其最常见的用途。面对新数据集，程序员往往需要挖掘数据，并做某些可视化分析来使其变得有意义。Notebook就能派上用场，有了它，用户可以：
· 快速入门
· 在一个地方查看原始数据和可视化方法
· 访问许多现有的清洁和可视化工具
· 记录用户的进展和发现（可以提取为 HTML 格式）
实验
在机器学习领域，选择解决问题的方法之前，需要进行大量实验。Notebook 可以很好地处理数据和各种模型。用户在处理给定数据时，可以清楚地知道哪些方法可行，哪些不太奏效。
一次性任务
Notebook也是一个好去处。有时某个用户需要执行一次自动化任务，但也许不熟悉或不习惯使用 bash 或其他类似的工具。
教学或技术演示
在进行python教学或者在同行面前进行技术演示时，你可能希望在当时立即显示代码和运行结果。Notebook可以满足这样的诉求，因为它允许你在同一文档中运行代码并显示结果。Notebook还可以展示可视化图表，用标题表示某部分，并给演示者提供可能需要的附加文档。
代码评估
如果你应聘的公司给应聘者发了代码题，Notebook 也是一个有用的工具。当然，这也取决于这家公司用什么工具来进行评估。Notebook 允许程序员将文档、说明及其解决方案组合成一页。如果应聘者知道代码的要求是什么，这个题本身其实也很容易。然而，公司没法通过评估知道的是，应聘者对软件工程原理的理解，下文会详细解释。
Notebook 有什么缺点？
现在很多公司都在努力解决将模型投入生产的难题。这些公司的数据科学家可能来自许多不同的背景，包括：统计学、纯数学、自然科学和工程。他们有一个共同点，那就是他们一般都习惯使用Notebook 进行分析和实验，这个工具简直就是为此而生。正因如此，提供基础设施的大公司一直致力于通过在Notebook 生态系统中提供“一键式部署”工具来缩小“生产差距”，从而鼓励在生产中使用Notebook。不幸的是，由于Notebook 的设计并不是为了实现这个目标，可能会导致生产系统无法维护。
一想到生产中的 Notebook，笔者就会想到一本连环画的实用性——中看不中用。
既然知道什么样的 Notebook 可以做得很好，那么在下面的小节中深入探讨一下它们真正的缺陷。
持续集成 (CI)
Notebooks的设计不是为了通过持续集成管道自动运行或处理，因为这个工具是为探索而构建的，往往涉及文档和可视化，这会给任何持续集成管道增加不必要的工作量。尽管可以将它们提取为普通的python 脚本，然后在持续集成管道上运行，但在大多数情况下，用户希望运行脚本的测试，而不是脚本本身（除非你正在创造一些需要由管道公开的手工艺品）。
测试
Notebook是不可测试的，这是笔者眼中的一个主要痛点。没有围绕这些目标创建的测试框架，因为其设计初衷是作为游乐场，而不是生产系统。与一般看法恰恰相反，数据产品中的测试与其他软件产品中的测试一样重要，也同样可能实现。为了测试Notebook，需要将Notebook 中的代码提取到脚本中，这意味着Notebook 无论如何都是多余的。它需要维护以匹配提取的脚本中的代码，不然就会变成一堆未经测试的混乱代码。
版本控制
如果你曾经在 git 或任何其他版本控制系统上安装了Notebook 并打开一个 pull 请求，那么你可能已经注意到这个 pull 请求是完全不可读的。这是因为Notebook 需要跟踪单元格的状态，因此用它来创建漂亮的 HTML 视图时，在后台会发生很多更改。这些更改还需要进行版本控制，否则会导致视图不可读。
当然，你所在的团队可能使用配对请求，而不是 pull 请求，因此你可能不在乎 pull 请求不可读性。但是，由于可读性降低，你就失去了版本控制的另一个优势：在还原代码或查找旧版本以查找可能引入或修复问题的更改时，你只能完全依赖提交消息并手动还原以检查更改。
这是 Notebook 一个广为人知的诟病，但人们也正努力解决这个问题。至少在版本控制系统的 Web 视图中，可以使用一些插件来缓解这种情况。比如，ReviewNotebook 应用程序。
协作
在 Notebook 上很难和其他人协同工作。你唯一可行的选择就是结对，或者像玩文明（Civilization）游戏一样轮流在 Notebook 上写代码。所以：
· Notebook 有很多状态是在后台管理的，因此在同一个 Notebook上异步工作会导致许多无法管理的合并冲突。对于远程团队来说，简直是个噩梦。
· 所有代码也在同一个位置（导入的包除外），因此对同一代码不断进行更改，使跟踪更改的效果难上加难。由于缺乏测试，这尤其糟糕（如上所述）
· 上面版本控制中已经提到的问题
状态
上述两项都提到了状态，但这一点仍值得反复强调。Notebook 具有 Notebook 范围的状态。每次运行单元格时，此状态都会更改，这可能会导致下列问题：
· 无法管理的合并冲突发生在状态中，而不是代码上；
· 版本控制缺乏可读性；
· 缺乏再现性。你在使用的时候notebook可能处在一个不可再现的状态，因为形成该状态的代码已被更改，但该状态尚未更新。
工程标准
Nootbook的出现也降低了工程标准。笔者在这里强调降低这个词，因为Notebook 用户可以避免很多这样的事情。Notebook中常见的反常规模式有：
· 对状态的依赖：Notebook严重依赖于状态，特别是因为它们通常需要对前几个单元格中的数据执行一些操作，以便将这些数据输入到某个算法中。对状态的依赖可能贯穿整个代码中，导致意外的后果和副作用。
· 复制：用户不能将一个Notebook 导入另一个中，因此在不同的Notebook 上尝试多个实验时，人们倾向于普通的复制粘贴。如果其中一个Notebook 发生了更改，其他的马上就过时了。这可以通过提取代码的公共部分并将它们导入到单独的Notebook 来改进。在Notebook 中也可以看到很多重复的地方，不过只要正确使用一些函数就可以轻易避免重复。
· 缺乏测试：正如在上面的测试部分所看到的，不能测试Notebook。
软件包管理
Notebook中没有软件包管理。Notebook 使用在其运行环境中安装的软件包。需要手动跟踪该特定 Notebook 使用的软件包，因为在同一环境中运行的不同 Notebook 可能需要不同的软件包。笔者建议在一个新的虚拟环境中运行一个新的 Notebook，分别跟踪Notebook 的具体需求。或者，环境中的所有Notebook 都将依赖于单个需求文件。
那我们该怎么办？
很好，现在我们知道为什么在生产中使用Notebook是一个坏主意，为什么我们需要停止把实验工具包装成生产工具。那我们应该怎么办呢？这取决于团队的技能和内部结构。你的团队很可能包括：
· 具有工程技能的数据科学家
· 或者，数据科学家专注于实验，机器学习/数据工程师将模型投入生产
请看下面两个场景。
一支具有工程技术的数据科学家队伍
在这个场景中，数据科学团队负责端到端的模型。也就是说，负责实验和产品化。以下是一些需要记住的事项：
1. 如果这是首选工具，你可以继续使用Notebook 来进行实验，但在以下情况下，请不要使用Notebook：
· 协作
· 把模型带到场地外的任何地方
2. 从现有的软件工程框架和原则中学习
· 测试和验证管道
· 连续交付模型
· 编写可维护代码
· 重构道路
3. 看看这些工具和架构，它们可以帮助你设计基础架构或提供灵感（小心，有时 Notebook选项是可用的——但这是陷阱！）以下内容：
· Kubeflow
· AzureDevOps
· TFX
· 使用AWSlambda部署模型
工程与数据科学技能分开
一些大公司更青睐更专业的技能集，数据科学家从事实验工作，而机器学习/数据工程师将这些技能集投入生产。上述场景中列出的要点仍然与之息息相关，但笔者有一个针对此场景的附加建议：
千万千万千万不要把模型扔掉！坐在一起，交流并配对/移动程序，将管道编入生产。除非模型为最终用户提供了价值，否则将无法工作。
结论
与任何工具一样，有时要使用 Notebook，有时要避免使用。最后做一个总结。
最后，希望大家可以从本篇文章中学到一些东西：
1. 致机器学习“侠”：Notebook是用来实验的，而不是用作产品化的。坚持软件工程的原则和框架，带到生产中，它们是根据我们应该利用的过去经验设计而成的。
2. 对于创建工具“侠”：很感谢你让每个人的工作变得更简单，但是请不要使用 Notebook 非常规模式。专注于创建更易于使用的工具，鼓励积极的软件工程模式。用户更想要：
· 可测试性
· 版本控制
· 协作
· 再现性
· 可扩展性
联系客服
