「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？全文共3468字

全文共3468字，预计学习时长9分钟

----「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？ //----[ http://www.caoding.cn]

插图：Alexis Jamet

在过去的几年里，为了克服将机器学习模型应用于生产的挑战，工具数量大幅增长。这些工具似乎有一个共同点，就是将Notebook 并入生产线。

本文旨在解释为什么在生产中使用Notebook是一种反常规的做法，并提出了一些建议。

----「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？ //----[ http://www.caoding.cn]

什么是 Notebook？

对于没有接触过 Notebook ，或者用其他名字来称呼这个工具的读者，我们首先从定义入手， Notebook是允许用户创建包含代码、可视化和文本文档的 Web 界面。如图所示：

----「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？ //----[ http://www.caoding.cn]

Notebook 有什么用？

可能恰恰与你从导言中看到的相反， Notebook并不是一无是处。它们在某些场景中非常有用，下文将进行详细描述。

数据分析

这可能是其最常见的用途。面对新数据集，程序员往往需要挖掘数据，并做某些可视化分析来使其变得有意义。 Notebook就能派上用场，有了它，用户可以：

· 快速入门

· 在一个地方查看原始数据和可视化方法

· 访问许多现有的清洁和可视化工具

· 记录用户的进展和发现（可以提取为 HTML 格式）

实验

在机器学习领域，选择解决问题的方法之前，需要进行大量实验。 Notebook 可以很好地处理数据和各种模型。用户在处理给定数据时，可以清楚地知道哪些方法可行，哪些不太奏效。

一次性任务

Notebook也是一个好去处。有时某个用户需要执行一次自动化任务，但也许不熟悉或不习惯使用 bash 或其他类似的工具。

教学或技术演示

在进行python教学或者在同行面前进行技术演示时，你可能希望在当时立即显示代码和运行结果。 Notebook可以满足这样的诉求，因为它允许你在同一文档中运行代码并显示结果。 Notebook还可以展示可视化图表，用标题表示某部分，并给演示者提供可能需要的附加文档。

代码评估

如果你应聘的公司给应聘者发了代码题， Notebook 也是一个有用的工具。当然，这也取决于这家公司用什么工具来进行评估。 Notebook 允许程序员将文档、说明及其解决方案组合成一页。如果应聘者知道代码的要求是什么，这个题本身其实也很容易。然而，公司没法通过评估知道的是，应聘者对软件工程原理的理解，下文会详细解释。

----「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？ //----[ http://www.caoding.cn]

Notebook 有什么缺点？

现在很多公司都在努力解决将模型投入生产的难题。这些公司的数据科学家可能来自许多不同的背景，包括：统计学、纯数学、自然科学和工程。他们有一个共同点，那就是他们一般都习惯使用Notebook 进行分析和实验，这个工具简直就是为此而生。正因如此，提供基础设施的大公司一直致力于通过在Notebook 生态系统中提供“一键式部署”工具来缩小“生产差距” ，从而鼓励在生产中使用Notebook 。不幸的是，由于Notebook 的设计并不是为了实现这个目标，可能会导致生产系统无法维护。

一想到生产中的 Notebook ，笔者就会想到一本连环画的实用性——中看不中用。

----「读芯术」知识扫盲，生产中使用Notebook是一种反常规做法？ //----[ http://www.caoding.cn]

既然知道什么样的 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是一种反常规做法？ //----[ http://www.caoding.cn]

那我们该怎么办？