Netflix如何拓展Jupyter notebook使用场景，以及为支持新使用场景进行的基础设施建设

编者按：Michelle Ufford（Netflix大数据工具负责人）、M Pacer（Netflix工程师、Jupyter核心开发者）、Matthew Seal（Netflix工程师）、Kyle Kelley（Netflix工程师）介绍了Netflix如何拓展Jupyter notebook使用场景，以及为支持新使用场景进行的基础设施建设。

Jupyter notebook在数据科学家当中快速流行开来，成为编写快速原型和进行探索性分析的事实标准。在Netflix，我们进一步开疆拓土，重新设想了notebook的形态、适用人群、用途，并且投入很多资源以实现我们的愿景。

本文将分享我们的动机，我们为什么觉得Jupyter notebook这么有竞争力。本文也将介绍我们的notebook基础设施的组成部分，同时探索我们在Netflix的一些创新的使用notebook的方式。

如果你比较匆忙，我们建议你直接从使用案例一节开始阅读。

动机

数据赋能Netflix。数据渗入我们的想法，为我们的决策提供信息，并挑战我们的假设。数据为在前所未有的尺度上的试验和创新提供燃料。数据帮助我们发现美妙的内容并向全世界一亿三千万会员提供个性化的体验。

实现这一切可不是小事一桩；它需要全面的工程支持和基础设施支撑。每天有超过一万亿事件写入摄取信息流的过程，经过处理后，再写入100PB的数据仓库云。同时每天运行150000项数据任务，范围无所不包，从报告分析到机器学习，到推荐算法。为了支撑如此巨大的尺度上的使用案例，我们创建了一个业界领先的灵活、强大、复杂（必要的复杂性）的数据平台。我们同时创建了补充工具及服务的丰富生态系统，比如Genie（联合任务执行服务）和Metacat（联合元存储）。这些工具简化了复杂度，使其可以支持全公司范围广泛的使用需求。

Netflix的数据角色

译者注：上图罗列了Netflix的数据角色，包括商业分析师、数据分析师、量化分析师、算法工程师、分析工程师、数据工程师、数据科学家、机器学习科学家、研究科学家。

多样性的数据使用者很令人兴奋，但它不是没有代价的：数据平台——以及配套的工具、服务生态系统——必须支持更多使用案例、语言、访问模式，等等。为了更好地理解这一问题，考虑3种常见角色：分析工程师、数据科学家、数据工程师。

不同角色（分析工程师、数据科学家、数据工程师）可能选择不同的工具和语言

一般来说，每种角色依赖不同的工具和语言组合。例如，一个数据工程师可能在IntelliJ中使用Scala创建一个包含数万亿音视频流事件的新的聚合数据集。一个分析工程师可能使用SQL和Tableau基于这一聚合创建关于全球音视频流质量的报告。这份报告可能导致一个数据科学家在RStudio下用R编写一个新的音视频流压缩模型。表面上看，这些都是分散的、不存在互补性的工作流程。但是，如果我们深挖一些，我们会发现每个工作流程中都有一些相通的任务：

数据探索—— 发生在项目早期；可能包括查看样本数据，运行查询请求以进行统计分析和探索性分析，以及可视化数据。

数据准备—— 迭代任务；可能包括清理、标准化、转换、逆归一化、聚合数据；通常是整个项目最花时间的任务。

数据校验—— 重复任务；可能包括查看样本数据，运行查询请求以进行统计分析、聚合分析，以及可视化数据；通常作为数据探索、数据准备、开发、部署前、部署后等阶段的一部分。

产品化—— 发生在项目后期；可能包括部署代码至生产环境，装填数据集，训练模型，校验数据，规划工作流程。

为了帮助拓展使用者范围，我们想要让这些任务尽可能地省力。为了帮助拓展我们的平台，我们想要最小化需要支持的工具数量。但是怎么才能做到呢？没有一个工具可以完成所有这些任务；不仅如此，单个任务经常需要多种工具。然而，当我们再加上一层抽象的时候，在这些工具和语言之上涌现出了一种共同模式：运行代码，探索数据，呈现结果。

碰巧有一个开源项目正是为此设计的：Jupyter Notebook

Jupyter Notebook

nteract下的Jupyter notebook，其中使用了Vega和Altair可视化

始于2014年的Jupyter项目的目标是创建一组一致的工具，用于科研、可重现工作流程、计算叙述、数据分析。这些工具迁移到业界的效果很不错，今天Jupyter notebook已经成为数据科学家工具箱的必备之物。Jupyter曾被授予2017年度ACM软件系统奖，该奖授予对技术概念和商业接受度方面产生了持久影响的软件系统，历史上Java、Unix、Web曾获此奖。

在我们看来，Jupyter notebook极具竞争力，它提供了这些核心功能：

语言无关的内省和执行代码的消息传递协议

描述代码、代码输出、markdown笔记的可编辑文件格式

基于web的用户界面，以供编写、运行代码，以及可视化输出

Jupyter使用核作为计算引擎，Jupyter协议提供了与核通讯的标准消息传递API。这一协议使分离内容编写（用户界面）和代码执行（核）的可组合架构成为可能。通过将运行时从界面中隔离出去，notebook可以在保持配置执行环境的灵活性的同时，跨多语言。如果存在知道如何基于Jupyter协议通讯的语言核，notebook就可以通过与核收发消息来运行代码。

支撑这一切的是将代码和结果保存在一起的文件格式。这意味着，无需重新运行代码，就可以在之后访问结果。此外，notebook保存了给出上下文的丰富文本。这使notebook成为沟通业务上下文，文档化假设，注释代码，描述结论等的理想格式。

使用案例

在众多使用案例中，我们现在最常用的用途有三种：数据访问、notebook模板、计划notebook。

数据访问

Netflix最早引入notebook是为了支持数据科学工作流程。随着越来越多的数据科学家开始使用notebook，我们看到了扩张其工具效应的机会。我们意识到，我们可以利用Jupyter notebook的多功能和架构，拓展其使用范围为通用的数据访问。我们从2017年第三季度开始认真对待这一想法，将notebook从小众工具提升为数据平台的一等公民。

从使用者的角度来说，notebook提供了一个交互式地运行代码、探索输出、可视化数据的易用界面——全都可以通过云端开发环境达成。我们同时维护了一个Python库，加强了对平台API的访问。这意味着使用者基本上可以在notebook中编程访问整个平台。由于notebook的用途广泛、功能强大、使用方便，我们发现notebook在整个数据平台的各种使用者中间自然而然地快速流行开来。

现在，notebook是Netflix内处理数据最流行的工具。

notebook模板

随着我们为notebook扩展平台支持，我们开始引入新功能以满足新使用案例的需求。由此涌现出了参数化notebook。顾名思义，参数化notebook让你可以指定代码中的参数，并在运行时输入数值。这提供了出色的机制，让使用者可以将notebook定义为可重用的模板。

使用者为这些模板找到的用途出乎意料地多。其中一部分最常见的用途是：

数据科学家：以不同的系数运行试验，并总结结果

数据工程师：作为部署流程的一部分，执行一组数据质量审计

数据分析师：分享预备好的查询和可视化，让股东以比Tableau更深入的方式探索数据

软件工程师：每次遇到错误，发送排错脚本的结果到邮箱

计划notebook

我们利用notebook比较新颖的一种方式是将其作为计划工作流程的统一层。

由于每个notebook可以运行任意核，我们可以支持使用者定义的任何执行环境。同时因为notebook描述的是分割为单元的线性执行流，我们可以将错误映射到具体的单元。这让使用者可以简要地描述执行和可视化，以后运行时可以精确地报告结果。

这一范式意味着我们可以用notebook处理交互式工作，之后平滑地迁移到计划重复运行的工作。这对使用者来说非常方便。许多使用者在单本notebook中构造整个工作流程，当他们准备就绪，可以部署的时候，只需复制/粘贴进一些单独文件以便计划执行。将notebook视作逻辑工作流程，让我们很容易就可以像其他工作流程一样做计划。

我们也可以计划其他种类的工作。执行一项Spark或Presto工作时，插入源代码至新创建的notebook，然后执行。那本notebook便成为不可更改的历史纪录，包含所有东西——源代码、参数、运行时配置、执行日志、错误信息，等等。调错时，这提供了一个探查的快捷入口，因为所有相关的信息都在一处，同时notebook可供运行，以便进行交互式调试。

Notebook基础设施

在Netflix的规模上支持这些使用案例需要全面的基础设施。我们将简要介绍其中一些项目。

nteract是基于React的Jupyter notebook用户界面。它提供了一个简洁直观的界面，以及一些改进，例如单元内的工具栏，拖放单元，内建的数据探索工具。

Papermill是用来支持我们之前提到的参数化notebook的工具。Papermill让我们可以并行执行使用不同参数组合的多本notebook。Papermill还可以收集、总结一组notebook中的指标。

Commuter是一个轻量级的查看、分享notebook的服务。它提供了一个兼容Jupyter的内容API，使得读取本地或远程（Amazon S3）的notebook一样方便。它同时提供了一个目录浏览器，以供查找和分享notebook。

Titus是一个容器管理平台，支持可伸缩、可靠的容器执行，同时集成了Amazon AWS服务。Titus是Netflix内部创建的工具，并用于生产环境（串流、推荐、内容系统）。

我们将在后续的文章中更深入地探索这些基础设施。现在，让我们重点关注三个基础组件：存储、计算、界面。

Netflix的notebook基础设施

存储

Netflix数据平台使用Amazon S3和EFS作为云存储，notebook视为虚拟文件系统。这意味着每个使用者在EFS上有一个家目录，其中包含了notebook工作区。这个工作区中存放了所有用户创建、上传的notebook。当使用者交互式地运行notebook时，所有的读写活动发生在工作区中。[workspace + filename]的组合构成notebook的命名空间，例如/efs/users/kylek/notebooks/MySparkJob.ipynb。这一命名空间用于查看、分享、计划notebook。这一惯例可以防止名称冲突，同时从中了解使用者是谁以及notebook在EFS卷中的位置也很容易。

工作区路径可以为使用者抽象掉云存储的复杂性。例如，在列出目录的时候，只显示notebook的文件名，如MySparkJob.ipynb。在终端下则可以通过~/notebooks/MySparkJob.ipynb访问这一文件。

notebook存储和访问

当使用者计划一本notebook时，调度程序会从EFS复制使用者的notebook到S3的共享目录。S3上的notebook成为调度程序信任的源notebook。调度程序每次运行notebook时，基于源notebook初始化一本新notebook。新notebook是实际执行的notebook，并成为这次执行的不可更改的记录，包括代码、输出、日志。我们称之为输出notebook。

Netflix的工作以协作为基础。因此使用者开始分享notebook的URL一点也不让人吃惊。随着这一做法的流行，我们经常碰到因为多人同时访问同一notebook而导致的意外覆盖。使用者希望能以只读的方式分享活跃的notebook。这导致我们创建了commuter。commuter在幕后提供了Jupyter兼容的/files和/api/contensAPI，以列出目录内容，查看文件内容，访问文件元数据。这意味着使用者可以安全地查看notebook，无需担心影响生产环境的工作或正在运行的notebook。

计算

管理计算资源是处理数据最有挑战性的部分之一。在Netflix尤其如此，因为我们在AWS上部署了一个高伸缩性的容器化架构。数据平台的所有工作运行在容器中——包括查询、数据流、notebook。因此我们很自然地想要抽象掉尽可能多的复杂性。

使用者运行notebook服务时会配备一个容器。我们默认分配的容器资源可以满足大约87.3%的执行模式。资源不够用的时候，使用者可以通过简单的界面请求更多资源。

我们同时也通过预先准备好的容器镜像提供统一的执行环境。镜像预装了常用库和一组默认核。并不是镜像中的一切都是静态的——我们的核会拉取最新版本的Spack以及最新的平台集群配置。预先准备好的镜像减少了新建notebook所需的配置时间和麻烦，并且在一般情况下保持了单一的执行环境。

这一切背后的功臣是我们的Docker容器服务Titus。我们进一步在服务中封装了用户特定的服务配置和镜像。镜像种同时包括用户的安全组和角色，以及所包含的库常用的环境变量。这意味着使用者可以在基础设施上花更少的时间，在数据上花更多的时间。

界面

之前提到了我们的愿景，让notebook成为处理数据的标准工具。但这带来了一项有意思的挑战：单一界面如何支持所有使用者？我们仍然不完全清楚这个问题的答案，但已经有了一些想法。

我们需要一个直观的用户界面，极简主义风格的美学，也需要精心斟酌的用户体验，使困难的事情容易做到。nteract遵循这一理念，将简单性和组合性作为核心设计原则。这使得nteract成为我们想要做的工作的理想构件。

我们最常从使用者那里听到的抱怨之一是缺乏跨语言的原生数据可视化，使用Python之外的语言的人特别爱抱怨这一点。nteract的数据探索工具提供了语言无关的迅速探索数据的方式。之前我们说过，要让困难的事情容易做到，这是一个很好的例子。

你可以在MyBinder的样例notebook上直接体验数据探索工具的效果：（注意：加载可能需要花一分钟）

https://mybinder.org/v2/gh/nteract/examples/master?urlpath=%2Fnteract%2Fedit%2Fpython%2Fhappiness.ipynb

使用nteract的数据探索工具可视化世界幸福感报告数据集

我们也引入了参数表示的原生支持，这使得计划notebook和创建可重用模板更加容易了。

nteract原生支持参数化notebook

尽管notebook已经在Netflix提供了大量价值，其实一切才刚刚开始。我们需要在前端和后端投入更多以提升notebook总的体验。我们接下来12个月的工作将聚焦在提升可靠性、可见性和协作性上。上下文环境对使用者来说是第一位的，因此我们正致力于提升可见性，包括集群状态、核状态、工作历史，等等。我们同时致力于自动版本控制，原生应用内计划，更好地支持可视化Spark的DataFrame，更稳定的Scala核。我们将在之后的博客文章中讨论这些工作的细节。

开源项目

Netflix一贯倡导开放源代码。我们高度评价开源协作种涌现的活力、开放标准、想法交流。许多我们为Netflix数据平台开发的应用已经开源。同时，我们不打算创建一次性的解决方案，或屈从于“非我所创”的心态。只要有可能，我们利用现有的开源项目，并向其贡献代码，例如Spark、Jupyter、pandas。

我们之前描述的基础设施重度依赖Jupyter项目的生态系统，但也有一些分歧之处。最主要的是我们选择了nteract作为Netflix的notebook用户界面。我们做出这一决定有很多原因，包括对齐我们的技术栈和设计哲学。随着我们突破notebook可以做什么的限制，我们很可能会创建新工具、库、服务。这些作为nteract生态系统组成部分的项目也将开源。

我们认识到对Netflix有意义的东西不一定对所有人有意义。因此我们在设计这些项目的时候考虑了模块性。这样，你可以只选用对你的环境有意义的组件，例如Papermill，而不用投入整个Netflix的notebook生态系统。

后续

作为一个平台团队，我们的责任是让Netflix人可以在数据上做出令人惊叹的东西。notebook在Netflix已经有了惊人的影响力。随着我们在这一领域的更多投入，我们很兴奋，能看到这一影响的扩大。如果你希望成为我们的一员，可以看看我们的招聘页面。

呀！感谢你耐心读完这篇长文。不过本文只是浮光掠影地介绍了我们在notebook上做的工作。在后续的博客文章中，我们将更深入地探索notebook计划背后的架构。在这篇文章发布之前，你可以通过以下途径了解更多Netflix在数据上做什么，怎么做：

Twitter上的NetflixData账号

YouTube上的Netflix Data频道

Netflix Research网站：research.netflix.com

同时我们也乐不可支地赞助今年的JupyterCon。我们的工程师将在JupyterCon上做5场演讲：

8/22 1:30 PM, How to Build on top of Jupyter’s Protocols, Kyle Kelley

8/23 1:50 PM, Scheduled Notebooks: Manageable and traceable code execution, Matthew Seal

8/23 2:40 PM, Notebooks @ Netflix: From Analytics to Engineering, Michelle Ufford, Kyle Kelley

8/23 5:00 PM, Making beautiful objects with Jupyter, M Pacer

8/24 2:40 PM, Jupyter’s configuration system, M Pacer等

8/25 9AM — 5PM JupyterCon Community Sprint Day