Uber数据科学工作台的演变史

在 2017 年 10 月，我们发表了一篇文章，介绍了 Uber 的数据科学工作台（Data Science Workbench，DSW），这是我们为数据科学、复杂地理空间分析和探索性机器学习定制的一体化工具箱。它可以完成数据准备、特别分析、模型原型设计、工作流调度、仪表盘和协作所需的所有工作，这些工作都集中于一个单窗格、基于 Web 的图形用户界面中。

本文将对近三年来数据科学工作台的发展进行回顾和总结。通过对历史的回顾，我们看到了数据科学工作台的使用是如何演变的，包括并不只是加强数据科学家的工作流，深入了解我们在设计该平台时所作的选择如何有助于我们扩大其规模，并对我们当前的方法和数据科学民主化的未来目标有更深的理解，同时分享了我们在此过程中吸取的一些教训。

意想不到的增长挑战

自从 2017 年数据科学工作台问世以来，使用率直线上升。4000 多名月活跃用户使用数据科学工作台来完成数据科学、复杂分析以及探索式机器学习的任务。随着业务增长，我们也看到越来越多的不同客户需求。团队正利用数据科学工作台进行日益复杂的应用，如定价、安全性、欺诈检测和客户支持，以及其他旅行体验的基本要素。

更令我们吃惊的是，用户中不仅有数据科学家和工程师，还有分析师和运营经理，他们也正在使用我们的工具处理各自领域的具体挑战。图 1 展示了我们这个平台中的典型人物角色。

图 1：各种依赖于数据科学工作台的用户角色

尽管我们并没有明确期望这个平台能够吸引不同领域的用户，但是我们也看到了公平竞争的好处，即确保我们组织中的每一个人都能得到他们需要的数据和高级工具，从而持续地改进客户体验。这清楚地表明，数据科学工作台需要更可靠和更可扩展，才能服务于越来越多的用户，并能处理更复杂和关键的工作。这个平台也应该易于使用，不仅适用于有经验的数据科学家，也适用于有不同背景和技能组合的客户。

下一步，我们将展示在增强可扩展性和可靠性的基础上所做的工作，以及我们为提高平台对每个用户的体验而进行的创新。

巩固我们的基础

随着业务的增长，我们必须重新考虑与基础设施相关的假设。

下面是我们在数据科学工作台上做的重要改进，以及这些改进是如何提高平台基础。

利用 Peloton 改善资源管理

在第一次设计数据科学工作台的时候，我们假设了使用量的增加和基础设置的需求。为了确保每个用户的完全隔离，我们选择了一个模式，每个用户会话运行我们后端服务的整个实例。但是，随着用户数量的增加，我们开始构建新的功能并解决已有的问题，这就带来了一些实际的挑战。很难做到增量修改，因为它需要将修改部署到每个会话中，这会中断工作流。另外，我们的方法并不符合多租户服务的通用建议，这意味着我们必须管理自己的基础设施，并且不能使用 Uber 一流的基础设施管理和 SRE 团队。

通过使用 Peloton，我们可以定制用于集群工作负载的资源调度器，我们已经决定从这种模式中进行艰难突破。作为容器化环境的数据科学工作台，每个用户都可以获得一个完全隔离的会话。但是，每个会话都是一个 Docker 容器，其中带有定制的镜像。这种模式允许我们在需要推送新的更改时轻松更新自定义镜像：这些更改将提供给所有新的会话，并且现有的会话可以继续免受干扰：用户可以根据需要选择进行升级。使用集中管理的资源池，我们就能增加总体正常运行时间，还能依赖集中提供的服务来解决基础设施维护问题。最终，我们认识到，并非所有用户都能 100% 地利用他们需要的计算资源。为进一步优化我们的资源使用，并更好地考虑将来的发展，我们采用超额订购单个计算实例可托管的会话数量这一策略。这样就可以最好地分配有限的计算资源，同时还可以确保我们始终拥有容纳新用户的能力。

让 Spark 更容易地用于数据科学工作台

Apache Spark® 是数据设施的基础部分，它在我们业务的一些关键方面提供了支持。Spark 的多功能使用户可以开发应用程序，并在任何位置运行它们。在工作流中，数据科学工作台的用户普遍依赖于 Spark。早期，我们赌了一把，让用户可以方便地使用 Spark 工具，让用户可以在 Notebook 中本地运行 PySpark，并将 PySpark 作业提交到具有更大计算需求的应用程序集群。但是，通信环境的变化、确保可靠性和规范 Spark 的使用开始成为一大挑战。为实现这一过程的无缝衔接，我们决定紧密结合 Uber 的 Spark 计算即服务解决方案 uSCS（Uber’s Spark-compute-as-a-service solution），向用户提供一种透明的方式来提交 Spark 作业，而不必担心特定的配置设置。这些任务比以前更稳定，因为驱动程序和执行程序可以有效地远程分配。在 R 用户方面，我们使用 sparklyr 包 实现基于 sparkSQL 内核的分布式计算。

创新差异化

在过去三年里，除了专注于确保平台的可靠性之外，我们一直仔细观察，以便发现我们能做的一些小事情，让我们用户的工作流更加无缝。

我们想出了一些创新，并进行了战略押注，详情如下：

用“Bundle”服务实现无忧任务调度

在发布数据科学工作台时，我们提供了对简单工作调度器的支持，使得 Notebook 可以在预定时间内触发。过去几年，我们已经观察到用户如何利用这个功能来实现关键且具有影响力的业务流程自动化，而这些流程不幸地与用户会话的临时性有关。数据科学工作台上的会话并非长期存在；会话终止时，无论是选择还是意外，用户的工作都会中断，从而导致服务中断。之后，用户必须手工创建一个新会话，并重新分配以前的工作。另外，通过与用户的交流，我们也意识到用户对使用在数据科学工作台会话中运行的 Notebook 作为与其他作业一起运行的工作流程的阶段能力的需求。他们想要导出数据科学工作台会话中的任务，以便运行其他一些数据工具，如统一工作流管理系统（Piper）和 Michelangelo ML Explorer（MLE）。

为了弥合这一差距，我们对数据科学工作台进行了两项关键补充：

1. 在计算资源上托管自动化的、计划的作业功能，这些作业与数据科学工作台中的用户会话无关，不受定期操作变更的影响，这些变更用于实现可靠执行 Notebook 所需的所有定制。
2. 通过 API 触发数据科学工作台 Notebook 的功能，可从其他内部工程系统访问。

这两项创新使得我们可以实现日益复杂且对公司来说至关重要的自动化设备。

下面的图 2 展示了一个典型的工作流，即一键式解决方案如何将用户的代码 / 数据和环境封存到一个独立的 Bundle 中，然后从其他系统如 Piper 和 MLE 中启动它。数据科学工作台用户界面提供了一个 Bundle 管理选项卡，用户可以根据他们在数据科学工作台中创建的成熟作业来注册自己的 Bundle。Bundle 注册之后，与之相关的代码和环境都会被自动推送到永久存储中。结合之前建立的一些基本 Docker 镜像，我们可以重现确切的环境，以便以后可以独立启动这个 Bundle。这种解决方案相对于构建单独的 Docker 镜像，可以节省大量时间和计算资源。

为了从任何服务或系统注册和启动 Bundle 服务，我们还在数据科学工作台中提供开放 API。另外，我们与 Piper 团队合作，添加了一个新的数据科学工作台任务类型，这使得 Bundle 服务在 Piper 中作为标准阶段使用。

图 2：数据科学工作台 Bundle 的架构图

使用“Snapshot”智能管理包依赖关系

数据科学工作台用户被分配到单独的会话，会话中预装了最常用的 Python 或 R 包，并且可以通过安装任何他们可能需要的额外包来进行定制。平均而言，用户会话包含 100 到 150 个包。但是，当会话终止时，不管是有意的还是无意的，用户都将失去他们的定制，需要手动安装每一个包。这样做令人难以置信的耗时（安装 100 个包差不多要花 30 分钟），而且很难分享工作或复制已有的分析。已有的获取包依赖关系的解决方案存在许多局限性，而且对于不同的用户群并不实用。使用 Snapshot，我们建立了一个简单的、一键式的解决方案，它可以让用户捕捉到所有已安装包的全部依赖关系图。该快照随后可用于创建新的会话，与先前安装的包相同，还可与其他希望复制特定分析的用户分享，或与希望使用一套通用安装的包的团队共享。

图 3 展示了用户如何使用 Snapshot 服务。数据科学工作台提供了一个 UI 工具，用于保存会话的当前环境，并在此基础上生成一个快照，然后将其保存到持久化文件系统中。这样，当用户想要创建一个新会话，或者恢复一个崩溃的会话，或者与其他用户共享时，就可以使用该快照。此外，我们还创建了一个快照即缓存服务，该服务为任何其他服务或应用程序提供检索存档包的通用接口。我们为在同一个快照上创建的会话在第一次构建环境时缓存。随后的所有会话都将从缓存中直接提取环境。该设计提供了一种轻量级的策略，相对于构建 Docker 镜像来说，只需要更少的计算和存储资源。

图 3：数据科学工作台 Snapshot 的架构图

为管理 Python 环境而选择的依赖关系管理工具曾经是使用 requirement.txt 的 PIP。但是，requirement.txt 并不能完全锁定包的所有依赖关系的版本。所以，按不同的顺序安装同一组包可能产生不同的环境。为此，我们使用了另一个开源 Python 依赖关系管理工具 Poetry 来解决这个问题。Poetry 解决了依赖关系的冲突，并将所有依赖关系版本锁定。这样，用户可以保持一个稳定的、易克隆的 Python 环境。

通过知识库建立分享和共同学习的社区

在用户数量不多的情况下，分享并发现探索性的见解和技术是很容易的。随着组织的发展，我们的平台已经被 4000 多个每周活跃的用户所采用，跨团队的知识传递不再简单。这样降低了分析和决策的速度。为简化这个过程，我们在 Jupyter 平台上建立了数据科学工作台知识库作为虚拟中心，用户可以在一个社区驱动的学习环境中相互分享他们的知识和使用案例。如今，我们已经有超过 3000 篇文章以 Jupyter Notebook 的形式发表了，并且被浏览过 10000 多次。用户可以通过 Notebook 的标题、描述和代码单元中的关键词进行搜索；根据标签、团队或作者来筛选；为他们喜欢的内容投票；还可以直接克隆他们认为最有用的内容，使它们成为自己分析的起点。

图 4 展示了知识库的高级架构。通过 Qumulo NFS，我们可以存储实际的 Notebook，用于克隆和显示，并使用 MySQL DB 来存储 Notebook 元数据，以供其他管理操作使用。当用户发布 Notebook 时，我们会通过保存额外的副本来将原始 Notebook 与已发布的 Notebook 解耦。之后我们的查看器就会呈现这个副本。用户可以更新或删除 Notebook 已发布的内容和元数据，从而可以修复错误并更改内容。

图 4：知识源架构图

在知识库中的搜索功能上，我们集成了 Uber 的新一代搜索平台 —— Sia，使用户能够在标题、描述和 Notebook 内容中搜索关键词。在发布的 Notebook 中，我们提取了有用的代码单元，并保存在 MySQL 数据库中。然后，触发的 DB 事件数据会发送给 Sia 的实时摄取工具进行处理。在知识库中搜索之后，我们的后端将通过输入数据版本、关键词、分析器名称等参数调用 Sia 的搜索 API，并获取返回的 Notebook ID。最终，前端服务会将这些 Notebook 显示给用户。

这仅仅是我们最近几年增加到数据科学工作台的一些改进和创新。通过对这些功能的设计、构建和发布，我们学到了很多东西。我们相信，它们对于任何一个正在大规模建设或管理类似平台的人来说，都是非常有用的。让我们以共享的精神，在下一节带你了解这些经验。

主要的经验

过去这三年来，我们亲眼目睹了探索性数据科学的重要性，也亲眼目睹了那些授权给整个公司的人利用他们的数据做更多的事情。它能让我们真正加快创新速度，上一节讨论的一些有影响的例子就是证明。

此外，我们还认识到这是一项挑战和它带来的责任。第一，做一个“好公民”很重要：在我们努力实现工具的使用民主化的同时，我们仍将重点放在保护用户隐私、文件安全和尽可能严格地执行访问控制上。第二，规模很难扩大：每天有超过 3000 人使用我们的平台，这一数字每季度都会翻一番，我们必须不断重新评估我们的技术假设，并迅速改进，以便跟上对我们产品日益增长的需求。最终，可靠性至关重要：用户信任我们来托管他们的分析和仪表盘，并且依赖我们在全球 24x7x365 的持续服务，任何低于 99.99% 的可用性都是完全不可接受的。

除了基本的操作学习，我们的用户已经验证了我们最初的许多目标，但是也有一些东西令我们吃惊。这一发现给了我们三个重要的启示。

为专家打造，为技术含量较低的用户设计

作为一种平台，数据科学工作台最早被设计用于提高数据科学家的工作效率。当我们的许多功能集被设计为可以轻松适应数据科学家的工作流时，我们惊奇地发现，我们的许多运营团队也正在利用这个高级工具来显著改进其流程。他们成了真正的力量倍增者，但常常需要一些手把手的指导。对于我们来说，最重要的是要保证我们在平台上设置了合适的“护栏”。

与此同时，我们注意到数据科学家在机器学习原型设计过程中享受到了生产率的提升，但是在创建机器学习模型时，他们正在与混乱的环境作斗争。这个发现促使我们在 PyML 上进行投资，并与 Michelangelo （我们的生产机器学习平台） 进行更紧密整合。

不要止步于建立已知的东西；要赋予人们寻找未知的能力

我们在开发数据科学工作台时，经历了广泛的用户研究和咨询过程，以确保我们有限的资源能够用来设计一个平台，满足大多数用户的需要。对平台而言，产品市场匹配是一项很大的成就，但重要的是，还要扩大开发范围，以找到可能尚未引起客户注意的途径。跟踪行业发展趋势，我们选择早期专注于为用户提供 GPU 来支持深度学习。我们的赌注得到了回报，我们看到，越来越多的具有影响力的深度学习应用在我们的平台上进行原型设计，而我们的社区正在以我们不能仅靠调查就可以预测的方式来使用这些资源。

与数据科学家和非数据科学家创建社区

整个组织的团队都能利用我们的数据的真正力量，而不是局限于少数几个熟悉数据科学原理和技术的员工，为此要推动整个组织的不同想法的贡献，并为他们提供工具来探索和操作这些想法。利用数据科学工作台的知识库，我们可以在不同的工作部门之间进行知识的交叉传播和共享，同时还能保持灵活地处理不断增长的数据和见解。我们相信，我们的工作不仅仅是建立一种工具，而是为用户提供一种“超能力”。

通过了解我们的平台的特点和功能所带来的好处，我们比以往任何时候都更兴奋地致力于进一步创新，以使之更加完美。

作者介绍：

Peng Du，Uber AI 高级软件工程师，是 Uber 数据科学工作台的创始人，并在技术上领导数据科学工作台经历了多次演变。在 Uber AI 之前，他在数据基础设施团队工作，专注于提高查询引擎，如 Hive、Presto 和地理空间查询。在 Uber 之前，曾在谷歌从事数据 / 机器学习问题的研究。也是 ACM、Google Code Jam 等许多编码竞赛的冠军。

Taikun Liu，Uber AI 高级软件工程师，主要负责 Uber 数据科学工作台的 Bundle 项目、Peloton Migration、Spartk 和安全领域。在 Uber AI 之前，她在数据基础设施团队工作，专注于多数据中心复制、Hadoop 资源监控和管理。

Sophie Wang，Uber AI 二级软件工程师，她主要负责数据科学工作台的 Snapshot 服务、Spartk 和 Knowledge Feed 领域。目前致力于数据科学工作台的 Canvas 会话项目。

Hong Wang，Uber AI 二级软件工程师，主要负责数据科学工作台中的统一 UI 和 Knowledge Feed。目前正在 Michelangelo Studio 项目（合并数据科学工作台、Michelangelo 和 MLE）。他是 Uber AI 团队的可视化专家。

Hongdi Li，Uber AI 高级软件工程师，主要负责数据科学工作台的网络文件系统和其他基础设施方面的工作。在 Uber 之前，曾在 Salesforce 处理基础设施方面的工作。

Jin Sun，最近加入 Uber 数据科学工作台团队，担任技术主管经理。他的主要工作是统一数据科学工作台和 Michelangelo 的产品体验。

原文链接：

https://eng.uber.com/evolution-ds-workbench/