原文：
annas-archive.org/md5/daa8f16fb595e16a266512112b9ef347译者：飞龙
前言
Pachyderm 是一个分布式版本控制平台，用于构建端到端的数据科学工作流。自 2016 年创建以来，Pachyderm 已经成为大小组织的首选解决方案。Pachyderm 的核心功能是开源的，并且围绕它有一个活跃的工程师社区。本书带你走过 Pachyderm 使用的基础和高级示例，帮助你快速上手并将可靠的数据科学解决方案集成到你的基础设施中。
使用 Pachyderm 实现可重复的数据科学 提供了对 Pachyderm 的清晰概述，以及如何在云中安装和运行 Pachyderm 的说明，还介绍了如何使用 Pachyderm 的软件即服务（SaaS）版本——Pachyderm Hub。本书包含了在 Pachyderm 集群上运行的数据科学技术的实际示例。
这本书的适用人群
本书适用于希望为数据科学项目构建可扩展基础设施的初学者和有经验的数据科学家及机器学习工程师。具备基本的 Python 编程和 Kubernetes 知识将有所帮助，熟悉 GoLang 者优先。
本书涵盖内容
第一章，数据可重复性问题，讨论了现代科学和数据科学中可重复性的问题，以及它如何与 Pachyderm 的使命相一致。
第二章，Pachyderm 基础，介绍了 Pachyderm 的基本概念和原语。
第三章，Pachyderm 管道规范，提供了 Pachyderm 规范文件的详细概述，这是 Pachyderm 管道的主要配置文件。
第四章，在本地安装 Pachyderm，带你了解如何在本地计算机上安装 Pachyderm。
第五章，在云平台上安装 Pachyderm，介绍了如何在三个主要的云平台上安装 Pachyderm：Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）和 Microsoft Azure Kubernetes Service（AKS）。
第六章，创建您的第一个管道，介绍了如何创建一个简单的处理图像的管道。
第七章，Pachyderm 操作，介绍了最常用的操作。
第八章，创建端到端的机器学习工作流，展示了如何在一个示例自然语言处理（NLP）管道上部署端到端的机器学习工作流。
第九章，使用 Pachyderm 进行分布式超参数调优，介绍了如何使用命名实体识别（NER）管道进行分布式超参数调优。
第十章，巨兽语言客户端，带你了解使用 Pachyderm Python 和 Golang 客户端的最常见示例。
第十一章，使用 Pachyderm 笔记本，讨论了 Pachyderm Hub，Pachyderm 的软件即服务（SaaS）平台，并且你将了解 Pachyderm 笔记本，这是一个为数据科学家设计的集成开发环境（IDE）。
为了最大限度地发挥本书的效果
你需要在电脑上安装最新版本的 Pachyderm。本书中的所有操作均在 macOS 的 Pachyderm 2.0 版本上进行测试。不过，这些操作也应该适用于未来版本的发布。如果你使用的是 Windows，所有操作必须在Windows 子系统 Linux（WSL）中执行。
你需要申请 Pachyderm 的企业版才能使用 Pachyderm 控制台。Pachyderm 为首次用户提供免费的试用许可。然而，大多数示例在没有企业许可的情况下也可以正常工作。为了测试第十一章，使用 Pachyderm 笔记本，你需要创建一个 Pachyderm Hub 账户。
如果你正在使用本书的电子版，我们建议你自己输入代码，或访问本书 GitHub 仓库中的代码（下一节会提供链接）。这样做可以帮助你避免因复制粘贴代码而可能出现的错误。
下载示例代码文件
你可以从 GitHub 下载本书的示例代码文件，链接：github.com/PacktPublishing/Reproducible-Data-Science-with-Pachyderm。如果代码有更新，GitHub 仓库中的代码也会随之更新。
我们还提供了其他来自我们丰富书籍和视频目录的代码包，网址：github.com/PacktPublishing/。快来看看吧！
下载彩色图像
我们还提供了一份 PDF 文件，包含本书中使用的截图和图表的彩色图像。你可以在此下载：static.packt-cdn.com/downloads/9781801074483_ColorImages.pdf。
使用的约定
本书中使用了一些文本约定。
文本中的代码：表示文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。示例如下：“将下载的WebStorm-10*.dmg磁盘映像文件挂载为系统中的另一个磁盘。”
代码块如下所示：
image = displacy.render(textfile, style='dep', options={"compact": True, "distance": 70})
f = open('/pfs/out/pos-tag-dependency.svg', "w")
f.write(image)
f.close()
任何命令行输入或输出均以以下形式呈现：
$ minikube start
粗体：表示一个新术语、一个重要的词，或者你在屏幕上看到的词。例如，菜单或对话框中的文字通常以粗体显示。示例如下：“从管理面板中选择系统信息。”
提示或重要说明
如下所示。
联系我们
我们始终欢迎读者的反馈。
一般反馈：如果你对本书的任何方面有疑问，请发送电子邮件至 customercare@packtpub.com，并在邮件主题中注明书名。
勘误：虽然我们已尽力确保内容的准确性，但错误仍然可能发生。如果你在本书中发现错误，我们将不胜感激你能向我们报告。请访问 www.packtpub.com/support/errata 并填写表格。
盗版：如果你在互联网上发现任何形式的非法复制我们的作品，我们将非常感激你能提供该材料的位置地址或网站名称。请通过电子邮件联系我们，邮箱地址为 copyright@packt.com，并附上相关链接。
如果你有兴趣成为作者：如果你在某个领域有专业知识，并且有意撰写或参与编写书籍，请访问 authors.packtpub.com。
分享你的想法
一旦你读完了 Reproducible Data Science with Pachyderm，我们非常希望听到你的想法！请 点击这里直接前往亚马逊评论页面 分享你的反馈。
你的评价对我们和技术社区都非常重要，能帮助我们确保提供高质量的内容。
第一部分：Pachyderm 简介与可重现的数据科学
本节介绍了 Pachyderm 的基础知识，并描述了数据可重现性对企业级数据科学平台的重要性。你将了解 Pachyderm 解决方案的主要支柱，包括仓库、数据单元、任务，以及其中最重要的——管道。本章还简要讨论了 AI 的伦理问题，特别是在可重现性方面。
本节包含以下章节：
-
第一章，数据可重现性的问题
-
第二章，Pachyderm 基础
-
第三章，Pachyderm 管道规范
第一章：第一章：数据可复现性问题
如今，机器学习算法无处不在。它们已融入我们的日常生活中，我们使用它们时往往没有察觉。当我们匆忙赶去工作、规划假期或去看医生时，模型正在运行，甚至有时在为我们做出重要决策。如果我们不清楚模型在做什么以及它如何做出决策，我们如何能确保它的决策是公平公正的呢？Pachyderm 深刻关注数据科学实验的可复现性，并将数据血统、可复现性和版本控制作为核心。 但在继续之前，让我们先讨论一下为什么可复现性如此重要。
本章解释了可复现性、伦理人工智能（AI）和机器学习操作（MLOps）的概念，并概述了现有的数据科学平台以及它们与Pachyderm的比较。
在这一章中，我们将讨论以下主要话题：
-
为什么可复现性如此重要？
-
科学中的可复现性危机
-
解密 MLOps
-
数据科学平台的类型
-
解释伦理 AI
为什么可复现性如此重要？
首先，让我们定义一下 AI、ML 和数据科学。
数据科学是一个研究领域，涉及收集和准备大量数据，以提取知识并生成洞察。
**人工智能（AI）**是一个总括性的术语，指的是使机器能够模仿人类行为的技术。**机器学习（ML）**是 AI 的一个子集，基于这样的理念：算法可以通过过去的经验进行学习。
现在，让我们来定义一下可复现性。如果其他数据科学家能够在类似的数据集和问题上重复实验并得到类似的结果，那么这个数据科学实验就被认为是可复现的。虽然可复现性几十年来一直是科学研究的支柱，但它直到最近才成为数据科学领域的重要话题。
一个可复现的实验不仅更可能没有错误，而且还可以推动实验进一步发展，并允许其他人基于该实验进行构建，促进知识的转移并加速未来的发现。
数据科学已成为过去十年里最热门的话题之一，这一点毫不意外。许多大型科技公司开设了数十个高薪的数据科学家、数据工程师和数据分析师职位。因此，加入这个行业的需求正在迅速增加。根据斯坦福大学人类中心人工智能研究院（HAI）发布的《AI 指数 2019 年年报》，过去 20 年中，AI 论文数量增长了三倍。你可以在斯坦福大学 HAI 网站上阅读更多关于该报告的内容：hai.stanford.edu/blog/introducing-ai-index-2019-report。
图 1.1 – AI 出版物趋势，来自 AI 指数 2019 年年度报告（第 5 页）
几乎每个平台和大学现在都提供数据科学或 AI 课程，这些课程从不缺少学生。成千上万来自各行各业的人，从软件开发者到 CEO，都在参加机器学习（ML）课程，以跟上迅速发展的行业。
AI 会议的数量也在稳步增长。即使在疫情期间，面对面活动变得不可能，AI 社区依然以虚拟形式继续举行会议。像神经信息处理系统（NeurIPS）和国际机器学习会议（ICML）等旗舰会议，通常吸引超过 10,000 名参会者，仍然在线举行，并有大量参与者。
根据一些预测，到 2025 年，AI 市场规模将超过 3500 亿美元。仅在 2020 年至 2021 年间，市场从 120 亿美元增长到 580 亿美元。硅谷的科技巨头们正在激烈争夺在这一领域的主导地位，而较小的公司也在崭露头角，争取市场份额。全球 AI 初创企业的数量稳步增长，每年都有数十亿资金注入其中。
以下图表展示了近年来 AI 相关初创企业的增长：
图 1.2 – 全球 AI 相关初创企业的总私人投资，来自 AI 指数 2019 年年度报告（第 88 页）
AI 初创企业的总私人投资在过去 10 年中增长了超过 30 倍。
同一来源的另一个有趣指标是 2015 至 2018 年间发布的 AI 专利数量：
](https://github.com/OpenDocCN/freelearn-ds-pt4-zh/raw/master/docs/reprod-ds-pachyderu/img/B17085_01_003.jpg)
图 1.3 – AI 专利总数（2015-2018 年），来自 AI 指数 2019 年年度报告（第 32 页）
美国在专利发布数量上领先于其他国家。
这些趋势促进了经济和产业的发展，但不可避免地影响了提交的 AI 论文、流程、实践和实验的质量。这就是为什么需要一个适当的过程来确保数据科学模型的验证。实验的重复性是数据科学模型质量控制的重要组成部分。
接下来，让我们了解什么是模型。
什么是模型？
让我们定义一下什么是模型。数据科学或人工智能模型是对一个过程的简化表示，并且可以预测可能的结果。无论是天气预测算法还是网站访问量计算器，模型都会提供最可能的结果，并帮助我们做出明智的决策。当数据科学家创建模型时，他们需要决定模型中必须包含哪些关键参数，因为他们不可能涵盖所有内容。因此，模型是一个简化的过程版本。而在这过程中，数据科学家或组织会根据成功的定义做出一些取舍。
以下图表展示了一个数据模型：
图 1.4 – 数据科学模型
每个模型都需要持续的数据流来进行改进并确保正确执行。以亚马逊 Go 商店为例，商店内通过多台摄像头分析顾客的行为。确保商店安全的模型会不断基于现实中的顾客行为进行训练。这些模型必须学习到顾客有时会拿起某个商品然后改变主意再放回去；有时顾客可能会把商品掉到地上，导致产品损坏，等等。亚马逊 Go 商店的模型之所以优秀，是因为它能访问大量的真实数据，并且随着时间的推移不断改进。然而，并非所有模型都能访问真实数据，这时候可以使用合成数据集。
合成数据集是由计算机人工生成的数据集。合成数据的问题在于，它的质量仅与生成它的算法相关。通常，这种数据无法准确反映现实世界。在某些情况下，比如当用户隐私问题阻止数据科学家使用真实数据时，使用合成数据集是合理的；而在其他情况下，它可能会导致负面结果。
IBM 的 Watson 是一个雄心勃勃的项目，承诺通过在几秒钟内根据提供的症状列表诊断患者，从而革新医疗保健。这项发明能够极大地加快诊断过程。在地球上一些无法获得医疗服务的地方，像这样的系统能够挽救许多生命。不幸的是，由于最初的承诺是取代医生，Watson 只不过是一个能够辅助诊断的推荐系统，仅此而已。原因之一是 Watson 使用了合成数据集进行训练，而非真实数据。
有些情况下，检测训练模型中的问题尤其困难。以华盛顿大学开发的一个图像识别算法为例，该算法用于识别图像中是否出现了哈士奇或狼。该模型看似运行得很好，预测的准确率接近 90%。然而，当科学家们深入研究算法和数据时，他们发现模型是基于背景进行预测的。大多数包含哈士奇的图像背景是草地，而大多数包含狼的图像背景则是雪地。
可重复性的主要原则
如何确保你公司中的数据科学流程遵循可重复性原则？以下是可重复性原则的主要内容：
-
**使用开放数据：**用于训练模型的数据不应是一个黑箱。它必须以未修改的状态对其他数据科学家开放。
-
**对大量样本进行训练：**关于实验和训练样本数量的信息必须可以供审查。
-
**严格记录过程：**数据修改、统计失败和实验表现的过程必须彻底记录，以便作者和其他数据科学家可以在未来复现该实验。
让我们考虑一些例子，其中可重复性、协作和开放数据原则并未融入实验过程中。
几年前，一组来自杜克大学的科学家因提出了一个雄心勃勃的预测肺癌发展趋势的研究而广受关注。该研究基于从患者身上收集的数据，预测了肺癌的进程，医学界对这一发现充满了期待。然而，来自休斯顿MD 安德森癌症中心的另一组科学家在尝试复现原始结果时发现了该研究中的严重错误。他们发现化疗预测模型中存在标签错误、基因与基因表达数据的不匹配等问题，这些问题使得基于模型计算得出的正确治疗建议的可能性大大降低。尽管这些缺陷最终被揭示出来，但研究人员花费了近三年的时间和超过 2000 个工作小时才揭开真相，而这些问题本可以通过最初就建立适当的研究实践来避免。
现在让我们通过一个聊天机器人例子来看一下AI是如何出错的。你可能还记得微软那个臭名昭著的聊天机器人泰（Tay）。泰是一个可以从与互联网用户的对话中学习的机器人。当泰上线时，最初的对话是友好的，但一夜之间他的语言发生了变化，开始发布有害、种族歧视和不当的回应。他从教他粗鲁语言的用户那里学习，而由于该机器人被设计成模仿人类行为，他做了他被创造的事情。你可能会问，为什么他一开始不是种族歧视的？答案是他是在清洁、精挑细选的数据上进行训练的，这些数据没有包含粗俗和侮辱性语言。但我们无法控制互联网和人们发布的内容，而且这个机器人没有被编程任何道德感。这个实验引发了许多关于 AI 伦理的问题，以及我们如何确保我们构建的 AI 不会有一天反过来伤害我们。
新一代聊天机器人基于最近发布的GPT-3库。这些聊天机器人通过神经网络进行训练，在训练过程中创建了无法打破的关联。尽管这些聊天机器人背后使用了比其前身看似更先进的技术，但它们仍然可能根据训练数据的不同而变得种族歧视和充满仇恨。如果一个机器人在性别歧视和仇恨的对话中进行训练，它会变得冒犯性，并且可能会做出不当回应。
正如你所看到的，数据科学、AI 和机器学习是帮助我们解决许多困难问题的强大技术，但与此同时，它们也可能危害用户，并产生毁灭性后果。数据科学界需要努力制定更好的方法，减少不良后果，通过建立适当的标准和流程来确保数据科学实验和 AI 软件的质量。
既然我们已经了解了可重复性为何如此重要，那么让我们看看它对科学界和数据科学带来了哪些后果。
科学中的可重复性危机
可重复性危机是一个存在了十多年之久的问题。由于数据科学与科学学科关系密切，回顾过去许多科学家提出的问题，并将其与数据科学领域今天面临的类似问题联系起来是非常重要的。
最重要的问题之一是可重复性——复制科学实验结果的能力一直是良好研究的基石。换句话说，如果一个实验可以被重复，那么它是有效的；如果不能，那么它可能只是一次性的事件，不代表真实现象。不幸的是，近年来，越来越多的社会学、医学、生物学及其他领域的研究论文无法经受住对更多样本进行重测的考验，即便这些论文已发表在知名且可信的科学杂志上，例如Nature。这种趋势可能导致公众对科学及其分支 AI 产生不信任。
如前所述，由于 AI 行业的流行和发展，AI 论文的数量增加了数倍。不幸的是，这些论文的质量并未随着数量的增加而提升。
Nature杂志最近对科学家进行了一项调查，询问他们是否认为科学界存在可重复性危机。大多数科学家认为，由于频繁发表结果的压力，假阳性结果确实存在。研究人员需要资助，赞助商需要看到结果以便进一步投资研究，这导致许多已发表的论文信誉度下降。最终，争夺资助和官僚主义常常被认为是实验室中缺乏可重复性过程的主要原因。
被质疑完整性的研究论文具有以下共同特点：
-
没有公开共享代码或数据供其他研究人员尝试复制结果。
-
尝试复制结果的科学家未能完全或部分地按照提供的说明进行实验。
即使是诺贝尔奖得主发布的论文，有时也会因无法复制结果而受到质疑。例如，2014 年，Science杂志撤回了诺贝尔奖得主、免疫学家布鲁斯·贝特勒（Bruce Beutler）发表的一篇论文。这篇论文讲述了人类基因组中病毒样生物体对病原体的反应。在撤回前，这篇论文已被引用超过 50 次。
当 COVID-19 成为 2020 年的主要话题时，发布了多篇相关论文。根据Retraction Watch，一个追踪撤回科研论文的在线博客，截至 2021 年 3 月，已有超过 86 篇论文被撤回。
2019 年，超过 1400 篇科学论文被多个出版商撤回。这个数字非常庞大，且稳步增长，而 2000 年初仅有 50 篇论文被撤回。这引起了人们对所谓科学可重复性危机的关注。虽然并非所有被撤回的论文都是因为这个原因，但很多时候确实是由于此原因。
数据钓鱼
数据钓鱼或数据开采是一种通过多次运行计算来达到统计学上显著的实验结果的方法，直到得到预期结果，然后只报告这些结果，忽略那些不便的结果。有时，科学家无意中进行数据开采，以获得他们认为最可能的结果并确认假设。也有可能发生更为险恶的情况——科学家可能故意篡改实验结果，以达成预定结论。
这种数据分析误用的一个例子是，如果你决定证明香蕉消费与 10 岁及以上儿童智商水平提高之间的相关性。这是一个完全虚构的例子，但假设你想要建立这种联系。你需要获取一个足够大的样本群体中，孩子们的智商水平和香蕉消费情况——假设是 5,000 名孩子。
然后，你可以进行一些测试，例如：吃香蕉并锻炼的孩子是否比仅仅锻炼的孩子拥有更高的智商？看电视并吃香蕉的孩子是否比不看电视的孩子智商更高？ 在进行了足够多次测试后，你很可能会得到某种相关性。然而，这个结果并不显著，且使用数据开采技术被科学界认为是极不道德的。在数据科学领域，类似的问题也时有发生。
在没有进行全面调查的情况下，检测数据开采可能会很困难。可以考虑以下几个可能的因素：
-
这项研究是由一个声誉良好的机构或科学家小组进行的吗？
-
其他类似领域的研究有什么建议？
-
是否涉及财务利益？
-
该声明是否耸人听闻？
没有适当流程的情况下，数据开采和不可靠的研究者将继续被发表。最近，自然杂志对约 1,500 名来自不同领域的研究人员进行了调查，超过 50%的受访者表示他们曾尝试并未能成功复制过去研究的结果。更令人震惊的是，在许多情况下，他们未能复制自己实验的结果。
在所有受访者中，只有 24%的人能够成功发布他们的复制尝试，而大多数人从未接到要求复制他人研究的请求。
当然，提高实验的可重复性是一个高成本的问题，可能会使实验所需的时间翻倍，这对于许多研究实验室来说可能是无法承受的。但如果将其加入到原本计划中的研究时间，并且有合适的流程，它就不应该像在研究生命周期中途加入那么困难或严格。
更糟的是，在论文发布后撤回论文可能是一项繁琐的任务。有些出版商甚至会在论文被撤回时向研究人员收取大量费用。这种做法实在令人沮丧。
所有这些都会对全球研究产生负面影响，导致对科学的信任度下降。各组织必须采取措施改善其科学部门的流程，科学期刊必须提高发布研究的标准。
既然我们已经了解了数据捕捞，接下来让我们回顾更好的可重复性指南。
更好的科学研究可重复性指南
开放科学中心（COS），一个专注于支持和促进开放科学倡议、可重复性和科学研究诚信的非营利组织，发布了《期刊政策和实践中的透明性和开放性推广指南（TOP）》，或称为TOP 指南。这些指南强调了已发表研究论文中透明性的重要性。研究人员可以利用这些指南为公开共享研究成果的必要性提供依据，以避免关于其研究完整性的任何质疑。
TOP 指南的主要原则包括以下几点：
-
正确引用和给予原作者信用：所有属于其他作者的文本、代码和数据成果，必须在论文中明确列出，并根据需要给予适当的信用。
-
数据、方法论和研究材料透明性：论文的作者必须在一个公开可访问的位置共享已编写的代码、方法论和研究材料，并提供如何访问和使用它们的说明。
-
设计和分析透明性：作者应尽可能透明地展示其方法论，尽管这可能会根据行业不同而有所不同。至少，他们必须披露在研究过程中应用的标准。
-
研究和分析计划的预注册：即使研究未发表，预注册也能使其更容易被发现。
-
获得结果的可重复性：作者必须包括足够的细节，说明如何重复原始结果。
这些指标应用于所有这三种级别：
-
未实施—报告中未包含相关信息
-
1 级—按需提供
-
2 级—发布前可访问
-
3 级—发布前验证
3 级是透明度可以达到的最高水平。拥有这种透明度就能为提交的研究质量提供充分的证明。COS 通过TOP 因子来评定期刊在确保透明度方面的努力，最终评定所发布研究的质量。
除了数据和代码的可复现性外，研究过程中使用的环境和软件往往起着重要作用。新技术，如容器、虚拟环境和云环境，使得在研究中实现统一变得更加容易。当然，如果我们考虑到生物化学或其他需要更精确实验室条件的行业，达到统一性可能会更加复杂。
现在让我们了解一些有助于提高复现性的常见做法。
提高复现性的常见做法
得益于复现性倡导者的努力，以及近年来该问题在科学社区的广泛讨论，似乎有一些提高复现性的积极趋势正在出现。这些实践包括以下内容：
-
请求同事再现你的工作。
-
开发详尽的文档。
-
标准化研究方法。
-
在发表前预注册你的研究，以避免数据挑选。
有些科学小组将复现并通知研究人员论文中的错误作为他们的使命。他们的典型流程是尝试再现论文中的结果，并向研究人员或实验室发信请求更正或撤回。有些研究人员愿意合作并纠正论文中的错误，但在其他情况下，情况不明确且困难。某些小组已识别出他们分析的 25 篇论文中的以下问题：
-
缺乏有关应将反馈意见提交给谁的流程或联系人。科学期刊并未明确说明是否可以将反馈提交给主编，或者是否有某种反馈提交表格。
-
科学期刊编辑通常不愿意接受并处理提交的意见。在某些情况下，即便是来自知名机构的批评性反馈，也可能需要长达一年的时间才能在论文上发布警告。
-
一些出版商要求你支付费用，如果你想发表更正信函，并且会延迟撤回。
-
原始数据并不总是公开可用。在许多情况下，出版商没有围绕研究中使用的原始数据设立统一的流程或共享位置。如果你必须直接联系作者，你可能无法获得所请求的信息，而且这可能会显著延迟进程。此外，他们还可以简单地拒绝此类请求。
提交更正和研究论文撤回缺乏标准化，导致整体复现性危机和知识共享的困境。那些利用数据挖掘和其他手段操控结果的论文，将成为未来研究者的信息来源，进一步加剧整体的错误信息和混乱。研究人员、出版商和编辑应共同努力，建立统一的出版后审查指南，鼓励其他科学家参与测试并提供反馈。
我们已经了解了可重复性如何影响研究质量。现在，让我们回顾一下组织如何建立一个流程，以确保他们的数据科学实验遵循最佳行业实践，以确保高标准。
解密 MLOps
本节定义了机器学习操作（MLOps），并描述了为什么在数据科学部门内建立一个可靠的 MLOps 过程至关重要。
在许多组织中，数据科学部门是最近几年才成立的。数据科学家这一职业也相对较新。因此，许多部门必须找到一种方法将其融入现有的企业流程，并制定确保数据科学成果的可靠性和可扩展性的方法。
在许多情况下，构建合适的基础设施的责任落在数据科学家身上，而他们往往对最新的基础设施趋势不太熟悉。另一个问题是如何在不同的语言、平台和环境中使其正常运行。最终，数据科学家在构建基础设施上花费的时间远多于在模型本身上工作。这就是新兴学科的出现，它帮助弥合数据科学与基础设施之间的差距。
MLOps 是一个生命周期过程，它识别机器学习操作的各个阶段，确保数据科学过程的可靠性。MLOps 是一套定义机器学习开发过程的实践。尽管这一术语是最近才提出的，但大多数数据科学家一致认为，成功的 MLOps 过程应该遵循以下原则：
-
协作： 这一原则意味着开发机器学习模型的所有内容必须在数据科学家之间共享，以保留知识。
-
可重复性： 这一原则意味着不仅代码，数据集、元数据和参数也应该版本化，并且对于所有生产模型都应具有可重复性。
-
连续性： 这一原则意味着模型的生命周期是一个持续的过程，意味着生命周期阶段的重复和每次迭代时模型的改进。
-
可测试性： 这一原则意味着组织实施机器学习测试和监控实践，以确保模型的质量。
在我们深入了解 MLOps 过程阶段之前，让我们先来看一下更为成熟的软件开发实践。DevOps 是一种在许多企业级软件项目中使用的软件开发实践。一个典型的 DevOps 生命周期包括以下几个阶段，这些阶段会不断重复，以确保产品的改进：
-
规划： 在这一阶段，会制定软件的总体愿景，并设计更为详细的方案。
-
开发： 在这一阶段，编写代码并实现计划的功能。代码通过版本控制系统（如 Git）进行共享，从而确保软件开发人员之间的协作。
-
测试： 在这个阶段，开发的代码通过自动化或手动过程进行缺陷测试。
-
部署： 在这个阶段，代码被发布到生产服务器，用户有机会进行测试并提供反馈。
-
监控： 在这个阶段，DevOps 工程师专注于软件性能和故障原因，识别可能的改进领域。
-
运维： 这个阶段确保软件更新的自动发布。
以下图示展示了 DevOps 生命周期：
图 1.5 – DevOps 生命周期
所有这些阶段都会不断重复，从而实现部门之间的沟通和客户反馈循环。这一做法为企业带来了更快的开发周期、更好的产品和持续的创新等好处。部门之间密切关系促进了更好的团队合作，而这正是这一过程高效的关键因素之一。
数据科学家应当拥有一个同样具有可靠性的过程。企业数据科学面临的最大问题之一是，极少有机器学习模型能够投入生产。许多公司刚刚开始采用数据科学，而新设立的部门面临前所未有的挑战。团队通常缺乏对需要实施的工作流程的理解，而这些工作流程是确保企业级数据科学正常运作的关键。
另一个重要的挑战是，与传统的软件开发不同，数据科学家不仅操作代码，还需要操作数据和参数。数据来自现实世界，而代码则在办公室中精确开发。两者唯一的交集是在数据模型中结合时。
所有数据科学部门面临的挑战包括以下几点：
-
不一致或完全缺失的数据科学过程
-
无法跟踪数据变化并重现过去的结果
-
性能缓慢
在许多企业中，数据科学部门仍然较小，并且在创建可靠的工作流程方面面临困难。构建这样的过程需要一定的专业知识，例如理解传统的软件实践（如 DevOps），并与理解数据科学挑战相结合。这就是 MLOps 开始出现的地方，它将数据科学与最佳软件开发实践相结合。
如果我们尝试将类似的 DevOps 实践应用于数据科学，可能会看到以下情况：
-
设计： 在这一阶段，数据科学家负责获取数据并设计数据管道，也叫做提取、转换、加载（ETL）管道。数据管道是数据经过的一系列转化步骤，最终产生输出结果。
-
开发： 在这个阶段，数据科学家负责编写先前开发的数据管道的算法代码。
-
训练：在此阶段，模型使用选择的或自动生成的数据进行训练。在此阶段，可以使用超参数调优等技术。
-
验证：在此阶段，经过训练的数据会经过验证，以确保它能够与其余的数据管道兼容。
-
部署：在此阶段，经过训练和验证的模型会被部署到生产环境中。
-
监控：在此阶段，模型会持续监控其性能和可能存在的缺陷，并将反馈直接传递给数据科学家进行进一步改进。
与 DevOps 类似，MLOps 的各个阶段会不断重复。以下图表展示了 MLOps 的各个阶段：
图 1.6 – MLOps 生命周期
正如你所看到的，这两种实践非常相似，后者借鉴了前者的主要概念。将 MLOps 应用于实践为企业级数据科学带来了以下优势：
-
更快的市场交付：数据科学模型只有在成功部署到生产环境中时才具有价值。由于许多公司在其数据科学部门中实施正确流程时遇到困难，MLOps 解决方案确实能够带来改变。
-
跨团队协作与沟通：将软件开发实践应用于数据科学为开发人员、数据科学家和 IT 运维人员提供了一个共同的基础，促使他们能够一起合作并使用相同的语言。
-
可重复性和知识转移：保持代码、数据集和变更历史对于提高整体模型质量起着重要作用，并使数据科学家能够从彼此的示例中学习，从而促进创新和功能开发。
-
自动化：自动化数据管道有助于在多个发布版本中保持流程一致，并加速 概念验证（POC）模型向生产级管道的推广。
在本节中，我们了解了 MLOps 流程中的重要阶段。在下一节中，我们将学习更多关于数据科学平台的种类，这些平台可以帮助你在组织中实施 MLOps。
数据科学平台的种类
本节将带你了解当前开放源代码世界和市场上可用的数据科学平台，并帮助你理解它们之间的区别。
随着 AI 和机器学习领域的不断发展，越来越多的工程师在寻找解决数据科学问题的新方法，并为更好、更快速的 AI 采用构建基础设施。有些平台提供从数据仓库到生产环境的端到端能力，而其他平台则提供部分功能并与其他工具结合使用。通常，没有一种解决方案适用于所有用例，当然也不是每个预算都能承受。
然而，所有这些解决方案都完全或部分地促进了数据科学生命周期的以下阶段：
-
数据工程
-
数据获取与转换
-
数据训练
-
模型部署
-
监控与改进
以下图示展示了数据科学工具的类型：
](https://github.com/OpenDocCN/freelearn-ds-pt4-zh/raw/master/docs/reprod-ds-pachyderu/img/B17085_01_007.jpg)
图 1.7 – 数据科学工具的类型
让我们来看一看现有的可以帮助你构建大规模数据科学工作流的数据科学平台。
端到端平台
一个端到端的数据科学解决方案应该能够提供所有机器学习生命周期阶段所需的工具，如前一节所列。然而，在某些使用场景中，端到端工作流的定义可能会有所不同，可能主要集中在机器学习流程和项目上，排除了数据工程部分。由于定义可能仍在变化，随着领域的发展，端到端工具可能会继续提供不同的功能。
如果存在这样的平台，它应当带来以下好处：
-
一个统一的用户界面，消除了将多个界面拼接在一起的需求
-
为所有相关人员（包括数据科学家、数据工程师和 IT 运维人员）提供协作
-
将基础设施支持的便利性交由解决方案提供商，能够为团队提供额外的时间，专注于数据模型而非基础设施问题
然而，你可能会发现端到端平台的以下缺点与你组织的目标不一致：
-
可移植性：这样的平台可能是专有的，迁移到其他平台将会很困难。
-
价格：端到端平台可能是基于订阅的，许多数据科学部门可能负担不起。如果涉及到基于 GPU 的工作流，价格会进一步上涨。
-
偏差：当你使用提供内置流程的专有解决方案时，你的模型必然会从这些自动化工具中继承偏差。问题在于，偏差可能在自动化机器学习解决方案中难以识别和解决，这可能对你的业务产生负面影响。
既然我们已经了解了端到端数据科学平台的优缺点，让我们来看看目前市场上有哪些平台。由于人工智能领域发展迅速，每年都会有新平台出现。我们将研究其中排名前五的平台。
大型科技巨头，如微软、谷歌和亚马逊，都提供自动化机器学习功能，许多用户可能会觉得这些功能非常有用。谷歌的 AI 平台提供Kubeflow流水线来帮助管理机器学习工作流。亚马逊提供辅助超参数调优和标注的工具。微软提供支持GPU工作流的Azure 机器学习服务，其功能类似于亚马逊的服务。
然而，正如之前所提到的，所有这些**可解释人工智能（XAI）**功能都容易受到偏见的影响，需要数据科学团队构建额外的工具来验证模型的性能和可靠性。对于许多组织来说，自动化机器学习并不是正确的答案。另一个问题是供应商锁定，因为你将不得不将所有数据保存在底层的云存储中。
Databricks解决方案提供了更灵活的方式，因为它可以部署在任何云平台上。Databricks 基于 Apache Spark，这是人工智能和机器学习工作流中最受欢迎的工具之一，并通过名为MLflow的平台提供端到端的机器学习管道管理。MLflow 使数据科学家能够跟踪从模型开发到部署再到生产的管道进展。许多用户喜欢其内建的笔记本界面。一个缺点是缺乏数据可视化工具，未来可能会添加该功能。
Algorithmia是另一种专有解决方案，可以部署在任何云平台上，提供端到端的机器学习工作流，涵盖模型训练、部署、版本管理和其他内建功能。它支持批量处理并且可以与 GitHub Actions 集成。虽然 Algorithmia 是一个很棒的工具，但它内建了一些传统的软件开发工具，可能会让某些工程团队觉得冗余。
可插拔解决方案
尽管端到端平台听起来像是数据科学部门的理想解决方案，但实际上并非总是如此。大公司通常有一些端到端平台无法满足的需求。这些需求可能包括以下内容：
-
数据安全：一些公司可能对将数据存储在云端有隐私限制。这些限制也适用于自动化机器学习功能的使用。
-
管道输出：通常，管道的最终产物是一个库，这个库被打包并用于组织内其他项目中。
-
现有基础设施约束：一些现有的基础设施组件可能会阻碍端到端平台的集成。某些基础设施部分可能已经存在并满足用户需求。
可插拔解决方案为数据基础设施团队提供了构建自定义解决方案的灵活性，但这也带来了支持该解决方案的需求。然而，大多数大公司最终都会这样做。
可插拔解决方案可以分为以下几类：
-
数据摄取工具
-
数据转换工具
-
数据服务工具
-
数据可视化与监控工具
让我们考虑一些这些工具，它们可以组合在一起构建数据科学解决方案。
数据摄取工具
数据摄取是从公司所有来源收集数据的过程，例如数据库、社交媒体和其他平台，将其集中到一个位置，供机器学习管道和其他人工智能过程进一步使用。
最流行的开源数据摄取工具之一是Apache NiFi，它可以将数据摄取到Apache Kafka，这是一个开源流媒体平台。从那里，数据管道可以消耗这些数据进行处理。
在商业云托管平台中，我们可以提到 Wavefront，它不仅支持数据的摄取，还支持数据处理。Wavefront 因其可扩展性和支持高查询负载的能力而著名。
数据转换工具
数据转换是将代码应用于你拥有的数据的过程。这包括将数据作为数据管道的一部分进行训练和测试。该工具应能够从一个集中的位置消耗数据。像TensorFlow和Keras这样的工具为这类操作提供了扩展功能。
Pachyderm也是一个数据转换和管道工具，尽管它的主要价值在于大型数据集的版本控制。与其他转换工具不同，Pachyderm 让数据科学家有自由定义自己管道的空间，并支持任何语言和库。
如果你参加过数据科学课程，那么很可能你已经使用过MATLAB或Octave来进行模型训练。这些工具为你提供了一个很好的起点来探索机器学习。然而，当涉及到需要持续训练、协作、版本控制和模型产品化的生产级数据科学时，这些工具可能并不是最佳选择。MATLAB 和 Octave 主要用于学术目的的数值计算。MATLAB 等平台的另一个问题是，它们通常使用专有语言，而像 Pachyderm 这样的工具支持任何语言，包括数据科学社区中最流行的语言。
模型服务工具
在你训练好模型并且获得令人满意的结果后，你需要考虑将该模型投入生产，通常可以通过 REST API 的形式或将其数据表导入到数据库中来实现这一目标。根据你在模型中使用的语言，提供REST API可能和使用 Flask 等 Web 框架一样简单。
然而，还有一些更高级的工具可以为数据科学家提供端到端的机器学习过程控制。一个这样的开源工具是Seldon。Seldon 将 REST API 端点转化为生产级微服务，在这里你可以轻松地将每个模型版本从开发环境推广到生产环境。
另一个提供类似功能的工具是KFServing。这两种解决方案都使用 Kubernetes 的自定义资源定义（CRD）来定义模型服务的部署类。
在大公司中，通常不同的团队负责模型训练和模型服务，因此，决策可能会根据团队对某一解决方案的熟悉度和偏好做出。
数据监控工具
在模型部署到生产环境后，数据科学家需要继续获取关于模型性能、潜在偏差和其他指标的反馈。例如，如果您拥有一个电商网站，并且推荐系统根据用户的历史选择推荐当前订单的购买商品，您需要确保该系统仍然紧跟最新的时尚潮流。您可能不了解潮流趋势，但反馈循环应能在模型性能下降时发出信号。
企业往往未能为机器学习工作流实施有效的监控解决方案，这可能对您的业务产生潜在的毁灭性后果。Seldon Alibi 是其中一种提供模型检查功能的工具，使数据科学家能够监控在生产环境中运行的模型，并识别需要改进的地方。Seldon Alibi 提供了异常值检测，帮助发现异常；漂移检测，帮助监控输入数据与输出数据之间的相关性变化；以及对抗性检测，揭示原始数据输入中的恶意变化。
Fiddler 是另一个流行的工具，用于监控生产模型的完整性、偏差、性能和异常值。
汇总全部内容
如您所见，创建一个生产级数据科学解决方案有多种方法，并且可能没有“一刀切”的解决方案。虽然端到端的解决方案提供了使用单一供应商的便利，但它们也有多重缺点，并且相比可插拔工具，通常配备的领域功能较弱。另一方面，可插拔工具需要您的组织具备一定的专业知识和文化，这将使得不同部门（如 DevOps 工程师）能够与数据科学家合作，共同构建最佳的解决方案和工作流。
下一节将带我们了解困扰现代人工智能应用的伦理问题，这些问题如何影响您的业务，以及您可以采取的应对措施。
解释伦理 AI
本节描述了人工智能中的伦理问题以及组织在构建人工智能应用时需要注意的事项。
随着 AI 和机器学习技术变得越来越普及和被接受，我们很容易忽视数据及决策过程的来源。当 AI 算法根据你最近的搜索建议购买哪一双鞋时，这可能并不是什么大事。但假设 AI 算法被用来决定你是否符合某个工作岗位的要求，你是否有犯罪倾向，或者你是否符合房贷批准标准。那么，了解这个算法是如何创建的、使用了哪些数据进行训练、数据集中包含了什么，更重要的是，数据集中没有包含什么，将变得至关重要。至少，我们需要质疑是否存在一个适当的过程来验证用于生成模型的数据。这不仅是正确的做法，而且还可以帮助你的组织避免不必要的法律后果。
虽然 AI 应用带来了一定的优势并提升了我们的生活质量，但它们有时也会犯错，这些错误有时会对人们的生活产生不利甚至毁灭性的影响。这些趋势促使领先的 AI 公司和大型科技公司出现了伦理 AI 团队和伦理 AI 倡导者。
伦理 AI 在过去几年中已成为数据科学社区中越来越多讨论的话题。根据《人工智能指数报告 2019》，伦理已成为 AI 会议中 AI 论文数量的一个持续增长的关键词。
图 1.8 – 自 1970 年以来提及伦理的 AI 会议论文数量，摘自《AI Index 2019 年度报告》（第 44 页）
让我们考虑一下最广受批评的 AI 技术之一——面部识别。面部识别应用可以识别图像或视频中的一个人。近年来，这项技术已经广泛应用，现在被用于家庭安全、身份验证和其他领域。在 2018 至 2019 年，全球超过 1000 篇新闻文章提到了面部识别和数据隐私。亚马逊开发的一种名为Rekognition的基于云的面部识别技术，被一些州的警察部门使用。执法部门使用该软件在数据库中搜寻嫌疑人，在视频监控分析中，包括警察佩戴的身体摄像头画面。独立研究显示，当从 120 名国会议员中识别时，软件将其中 28 人识别为潜在罪犯。所有这些人都有较深的肤色。该工具在识别有色人种女性时尤其表现不佳。
这个以及其他面部识别技术的问题在于，它是基于一个不具包容性的数据库进行训练的，该数据库主要包含白人男性的照片。此类结果很难预测，但这正是伦理 AI 正在努力解决的问题。在公共场所实施这样的监控系统会对成千上万的人产生负面影响。AI 的进步使得面部识别技术能够在几乎不需要人工干预的情况下进行身份识别。这就引发了完全控制和隐私的问题。虽然这样的系统可以帮助识别罪犯、预防犯罪并使我们的社会更安全，但它需要经过彻底审计，以防止潜在的错误和滥用。能力越大，责任越大。
另一个有趣的例子是使用自然语言处理（NLP）应用。NLP 是一种机器学习技术，使得机器能够自动解读和翻译一种人类语言所写的文本为另一种语言。近年来，NLP 应用取得了重大进展。像 Google Translate 这样的工具解决了 20 年前仍无法解决的问题。NLP 将句子分解为若干部分，并尝试在这些部分之间建立联系，以提供有意义的解释。NLP 应用不仅仅处理翻译，还能总结长篇研究论文中的内容或将文本转换为语音。
但这些应用也可能会犯错。一个例子是在土耳其语到英语的翻译中发现的。在土耳其语中，只有一个人称代词 o，可以表示 她/她的 或 他/他的。人们发现 Google Translate 存在基于性别的歧视，降低了女性的角色，这种歧视通常来源于常见的刻板印象。例如，它会将 She is a secretary 翻译为 她是秘书，而 He is a doctor 翻译为 他是医生，尽管在土耳其语中，这两句话都可以描述男性或女性。
从这些例子中可以看出，偏见是 AI 应用中的最大问题之一。偏见数据集是指没有包含足够样本的研究现象数据集，从而导致无法输出客观结果。例如在面部识别的例子中，数据集没有足够的有色人种代表，无法做出正确的预测。
虽然许多公司已经意识到数据集中的偏见可能带来的负面影响和风险，但很少有公司采取措施来减轻这些潜在的负面后果。根据《人工智能指数报告 2019》，只有 13% 的受访组织正在努力改善所使用数据集的公平性和公正性：
图 1.9 – 采取措施减轻 AI 风险的组织类型，来自《AI Index 2019 年度报告》（第 102 页）
另一个偏见的方面是财务不平等。众所周知，来自经济条件不利的背景的人们比那些来自更有利条件背景的人们更难获得信贷交易。信用报告已知存在错误，导致借款利率更高。
其业务是创建客户画像或个性化的公司更进一步，从公共记录、信用卡交易、抽奖活动及其他来源收集用户行为的详细信息。这些报告可以出售给营销人员甚至执法机构。个人会根据其性别、年龄、婚姻状况、财富、健康状况和其他因素进行分类。有时这些报告会包含关于犯罪记录等过时信息。曾经有一个案例，一位老太太因为被逮捕而无法进入养老院。然而，尽管她被逮捕，但那是她的伴侣家庭暴力的案件，她从未被起诉过。她能够纠正她的警方记录，但无法更正由画像公司创建的报告。纠正这些公司报告中的错误极为困难，它们可能会影响人们的生活数十年。
有时候，人们因为误认的档案被标记。想象一下，你申请工作被拒绝，因为你过去曾因盗窃或入室盗窃而受到起诉。这可能会让人震惊，可能一点也不合理，但是像这样的情况在一些常见姓名的人中并非没有。要纠正这样的错误，你需要一个愿意花时间为你纠正这些错误的人的干预。但你经常遇到这样的人吗？
现在机器学习被用于客户画像，许多数据隐私倡导者对这些算法中使用的方法提出了质疑。因为这些算法从过去的经验中学习，根据它们的说法，你过去做过的任何事情未来可能会重复。根据这些算法，罪犯将会再犯，穷人将会更穷。在他们的现实中没有错误的余地。这意味着有前科的人很可能会再次被逮捕，这为法律执行提供了歧视的基础。相反的情况也成立：那些来自良好社区的无犯罪记录者不太可能犯罪。这听起来并不公平。
关于累犯模型的问题在于大多数模型都是专有的黑盒子。黑盒模型是一种端到端模型，由算法直接根据提供的数据创建，即使数据科学家也无法解释它如何做出决策。由于人工智能算法的学习方式与人类类似，随着时间的推移，它们学习与我们相同的偏见。
图 1.10 - 黑盒模型
让我们继续下一节！
可信的人工智能
几年前，道德人工智能只是一些独立倡导者和学者的工作领域，而如今越来越多的大型科技公司已建立道德人工智能部门，以保护公司免受声誉和法律风险。
建立可信赖的人工智能模型标准是一项雄心勃勃的任务，且没有“通用法则”。然而，以下原则适用于大多数情况：
-
创建一个道德人工智能委员会，负责讨论与人工智能相关的风险，并与公司整体战略保持一致。
-
提高对非透明机器学习算法及其可能对社会和组织带来的潜在风险的认识。
-
创建识别、沟通和评估偏见模型及隐私问题的流程。例如，在医疗领域，保护患者个人信息至关重要。围绕产品管理部门的道德风险创建责任制。
-
建立一个通知用户其数据使用方式的流程，并用通俗易懂的语言解释偏见风险及其他概念。用户越早意识到使用你的应用程序可能带来的影响，未来的法律风险就会越小。
-
在公司内部建立一种文化，表彰促进道德项目和倡议的努力，以激励员工为这些努力做出贡献。鼓励来自不同部门的员工，包括工程、数据科学、产品管理等，参与这些工作。
根据《2019 年人工智能指数报告》，人工智能伦理的主要挑战包括公平性、可解释性和透明性。
下图展示了道德人工智能领域中存在的更完整的挑战清单：
图 1.11 - 道德人工智能挑战，摘自《人工智能指数 2019 年年报》（第 149 页）
以下是非透明机器学习算法可能引发的一些问题：
-
经济和金融机会的不均衡传播，包括信贷歧视以及基于预定购买习惯的不平等折扣和促销机会。
-
信息和社交圈的访问，例如基于社会经济群体推荐新闻，或建议加入特定群体或社交圈的算法。
-
就业歧视，包括根据候选人的种族、宗教或性别筛选候选人的算法。
-
不平等使用警力和处罚，包括基于社会地位和种族预测个人未来犯罪可能性的算法。
-
住房歧视，包括拒绝为有色人种、LGBT 群体和其他少数群体提供平等的租赁和按揭机会。
AI 给我们的社会带来了前所未有的好处，类似于工业革命带来的影响。但是，尽管有这些好处，我们也应该意识到这些好处所带来的社会变革。如果未来的交通方式是自动驾驶汽车，这意味着作为职业的驾驶工作将在可预见的未来消失。许多其他行业将受到影响并消失。这并不意味着进步不应该发生，但它需要以受控的方式进行。
软件的完美程度与其创造者一样，新的 AI 驱动产品中的缺陷是不可避免的。但如果这些新应用是关于人类生命和命运决策过程中的第一道关卡，就必须确保我们尽量减少潜在的有害后果。因此，深入理解我们的模型至关重要。部分原因就在于可复制性，这是最小化 AI 负面后果的关键因素之一。
总结
在本章中，我们讨论了许多重要概念，帮助我们明确了为什么可复制性很重要，以及为什么它应该成为成功的数据科学流程的一部分。
我们已经了解到，数据科学模型用于分析历史数据作为输入，目标是计算出最可能和最成功的结果。我们还确认了复制性，即能够重现科学实验结果的能力，是良好研究的基本原则之一，并且它是确保团队减少模型偏差的最佳方法之一。偏差可能会从训练数据集中由于数据的不准确呈现而渗入计算中。这种偏差通常反映了历史和社会现实以及社会中被接受的规范。减少训练数据中偏差的另一种方法是拥有一个多元化的团队，团队成员包括各种性别、种族和背景的代表。
我们了解到，数据挖掘（也叫钓鱼）是一种不道德的技术，一些数据科学家通过挑选实验结果中的某些结果来证明预先定义的假设，只选择能够证明预期结果的结果，忽略任何不符合的趋势。
我们还了解了 MLOps 方法论，它是机器学习应用程序的生命周期，原理上类似于 DevOps 软件生命周期技术。MLOps 包括以下主要阶段：规划、开发、训练、验证、部署和监控。所有这些阶段都被持续重复，从规划到开发、测试、生产再到后期生产阶段，形成一个确保实验管理无缝衔接的反馈循环。
我们还回顾了一些道德 AI 的最重要方面，道德 AI 是数据科学的一个分支，专注于人工智能、机器人学和数据科学的伦理问题。如果在组织中未能实施道德 AI 流程，可能会导致不良的法律后果，尤其是当部署的生产模型被发现具有歧视性时。
在下一章，我们将学习 Pachyderm 版本控制系统的主要概念，它能帮助你解决本章中提到的许多问题。
进一步阅读
- Raymond Perrault, Yoav Shoham, Erik Brynjolfsson, Jack Clark, John Etchemendy, Barbara Grosz, Terah Lyons, James Manyika, Saurabh Mishra 和 Juan Carlos Niebles，AI Index 2019 年年报，AI Index 指导委员会，Stanford 大学人类中心人工智能研究所，斯坦福，加利福尼亚州，2019 年 12 月：
hai.stanford.edu/sites/default/files/ai_index_2019_report.pdf
图 1.1，1.2，1.3，1.8，1.9 和 1.11 来自 AI Index 2019 年年报。
-
Liu, D., & Salganik, M. (2019 年 3 月 15 日)。计算可重复性中的成功与挑战：来自脆弱家庭挑战的经验教训。
doi.org/10.1177/2378023119849803 -
透明度与开放性推广（TOP）指南 v1.0.1：
osf.io/ud578/ -
可重复性：一场错误的悲剧：
www.nature.com/news/reproducibility-a-tragedy-of-errors-1.19264 -
神经信息处理系统（NeurIPS）会议：
nips.cc -
国际机器学习会议（ICML）：
icml.cc
第二章：第二章：Pachyderm 基础
Pachyderm是一个数据科学平台，使数据科学家能够创建端到端的机器学习工作流，涵盖机器学习生命周期中最重要的阶段，从数据摄取到生产部署。
如果你熟悉Git，一个用于代码的版本控制和生命周期管理系统，你会发现 Git 和 Pachyderm 的最重要概念之间有许多相似之处。像 Git 及其托管版本GitHub这样的版本控制系统，已成为全球成千上万开发者的行业标准。Git 使你能够保存代码更改的历史，并在需要时回溯。数据科学家需要一个平台，能够跟踪实验的版本，必要时重现结果，并调查和纠正可能在数据科学生命周期的某一阶段出现的偏差。Pachyderm 提供了类似于 Git 的好处，使数据科学家能够重现实验并轻松管理数据科学工作流的完整生命周期。
本章旨在描述 Pachyderm 架构的基础知识及其主要概念。我们将涵盖以下主题：
-
回顾 Pachyderm 架构
-
学习版本控制原语
-
发现管道元素
回顾 Pachyderm 架构
本节将带你了解分布式 Pachyderm 架构以及 Pachyderm 解决方案的内部原理。但在深入探讨 Pachyderm 基础设施的细节之前，让我们先回答你们在阅读简介后可能会有的问题——为什么我不能使用 Git 或任何其他版本控制系统？ 我们将以 Git 为例来回答这个问题，因为它是最流行和广泛使用的软件版本控制系统，但所有的论点都适用于任何其他类似的源代码版本控制系统。在回顾 Pachyderm 如何与 Git 不同及相似之后，我们将回顾 Pachyderm 的内部原理、Kubernetes 和容器运行时。
为什么我不能使用 Git 来管理我的数据管道？
那么，如果 Pachyderm 与 Git 类似，为什么我不能将所有内容都存储在 Git 中，而 是要使用我需要学习和支持的多个工具呢？，你可能会问。
虽然 Git 是软件工程师常用的开源技术，但它并不专门解决数据科学中的可重现性问题。这主要是因为 Git 被设计用来跟踪文件版本，而不是建立数据、代码和参数之间的联系——这些是每个数据模型的核心部分。
虽然你可以将代码文件保存在 Git 中，但由于以下原因，将训练数据保存在 Git 中是不可能的：
-
文件格式支持：Git 非常适合源代码管理，例如文本文件、脚本等，但它不支持非二进制文件的版本控制，如图片或视频文件。Git 会检测到二进制文件的变化，但不会像文本文件那样提供详细的变更信息。此外，Git 会替换整个二进制文件，这使得在更新时你的仓库体积剧增。
-
文件大小支持：通常，图片和视频文件非常大，而 Git 对每个文件有 100MB 的大小限制。为了获得最佳性能，Git 建议将仓库大小保持在 1GB 以下，而这对于某些机器学习和深度学习项目可能并不足够。
-
克隆一个大型 Git 仓库以及每个文件的所有历史记录可能会成为问题，并且需要较长的时间。
在计划机器学习项目的工具时，请考虑这些限制。
除了标准的 Git 仓库，Git 还提供了大型文件存储功能，称为Git 大型文件存储（LFS）。然而，这个选项可能也无法提供所需的功能。Git LFS 在机器学习项目中有以下缺点：
-
Git LFS 需要一个服务器。你需要设置并维护自己的 Git LFS 服务器，或者将其存储在第三方在线平台上。托管自己的服务器存在问题，需要额外的支持，并且你的首选云服务提供商可能不被支持。
-
在线 Git LFS 服务器有一个有限的免费版。对于使用高分辨率图片或视频的项目，这通常意味着很快就会达到限制，需要升级到付费版。
-
Git LFS 设计初衷是面向营销部门的用途，似乎是一个不错的解决方案，适合营销部门存储资产。其他人则更倾向于在非机器学习项目中使用标准 Git。
现在你已经知道为什么源代码版本控制系统并不是处理数据的最佳解决方案，让我们来回顾一下 Pachyderm 架构。
Pachyderm 架构图
下图展示了 Pachyderm 架构：
图 2.1 – Pachyderm 架构
让我们逐一回顾一下这个图中的所有组件。
Kubernetes
Kubernetes，一个开源分布式工作流调度系统，是 Pachyderm 的核心。如果你不熟悉 Kubernetes，下面是一个简要概述。
Kubernetes 是基础设施演进的最新阶段，最早起源于传统硬件部署，在那里数据中心操作员将所有应用程序部署在一台物理服务器上。这些应用程序会争夺资源，导致某些应用程序性能差。这种方式扩展性差，且管理困难。后来，我们看到了虚拟机技术的兴起，它使得物理服务器的管理变得更容易，并允许我们在一台物理服务器上运行多个应用程序，且具备更好的可扩展性。许多数据中心至今仍在运行大量虚拟机。容器，Kubernetes 所基于的技术，通过允许容器共享操作系统组件并去除相同软件部分的冗余副本，使得基础设施变得更加精简。容器可以轻松地从一个云平台迁移到另一个平台，提供更好的资源分配，并且整体上更易于管理和支持。
Kubernetes 的功能是管理容器及其集合，称为Pods。如今，Kubernetes 已成为开源世界中主导的容器技术。大科技公司可能有自己的调度程序类型——例如，谷歌有一个叫做 Borg 的项目，但大多数其他公司都在使用某一版本的 Kubernetes。
亚马逊、微软和谷歌等公司提供了分别被称为AWS 弹性 Kubernetes 服务（EKS）、微软 Azure Kubernetes 服务（AKS）和谷歌 Kubernetes 引擎（GKE）的托管 Kubernetes 版本。
一些公司，如 DigitalOcean，提供一个 Kubernetes 安装和管理系统，可以将 Kubernetes 部署到您选择的云平台上。
现在我们知道了 Kubernetes 的基本概念，接下来让我们回顾一下 Pachyderm 如何利用 Kubernetes 提供可扩展、可重复的数据科学解决方案。
Helm
部署 Pachyderm 的工具是 values.yaml，您可以使用它与 Pachyderm Helm Chart 一起进行本地 Pachyderm 安装，详情请见 github.com/pachyderm/pachyderm/blob/master/doc/docs/master/reference/helm_values.md。
在 values.yaml 文件中，您可以定义所有希望与 Pachyderm 集群一起部署的内容。例如，您可以选择部署名为 Console 的 Pachyderm 用户界面，也可以不部署；您可以在云服务提供商中配置存储桶；您可以指定要安装的 Pachyderm 版本，等等。
Helm Charts 存储在 Artifact Hub，网址为 artifacthub.io/。你可以在 artifacthub.io/packages/helm/pachyderm/pachyderm 找到 Pachyderm。我们将在 第五章 中更详细地讨论 Pachyderm Helm Chart，在云平台上安装 Pachyderm。
Pachyderm 内部结构
当你在本地或所选云平台上部署 Pachyderm 时，底层的 Kubernetes 调度器会部署以下组件：
-
Pachyderm Console（UI）：Pachyderm 浏览器内的 用户界面（UI），提供基本的 Pachyderm 功能。 -
Pachd：Pachyderm 守护进程容器，负责管理所有主要的 Pachyderm 逻辑操作。 -
postgress：Pachyderm 需要一个 PostgreSQL 实例来存储元数据。PostgreSQL 是一个广泛应用于许多开源和商业解决方案的关系型数据库。虽然在测试时，Pachyderm 构建中自带了一个 PostgreSQL 实例，但对于生产部署和工作负载，强烈建议使用单独的基于云的实例。 -
etcd：在旧版本的 Pachyderm 中，etcd是存储节点信息和管理元数据的键值存储。在 Pachyderm 2.0.0 及更高版本中，etcd只存储一小部分元数据，其余的元数据存储在 PostgreSQL 中。
这些组件中的每一个都作为 Kubernetes Pod 部署——Kubernetes 的最小部署单元，可以包含一个或多个容器。与其他应用程序不同，在 Pachyderm 中，每个 Pod 只有一个容器。
除了在安装过程中部署的这些容器外，每个 Pachyderm 管道（一个训练模型的计算组件）都作为单独的 Kubernetes Pod 部署。这些 Pod 被称为 工作节点（workers）。你可以在 Pachyderm 集群中部署无限数量的管道，并为每个 Pod 分配自定义数量的资源。Pod 彼此完全隔离。
其他组件
图 2.1 包含以下我们尚未列出的组件：
-
负载均衡器或入口控制器：Kubernetes 的网络组件，负责将 HTTP/HTTPS 路由从集群暴露到外部世界。默认情况下，Kubernetes 提供ClusterIP 服务，使集群内部的服务可以相互通信，但无法从外部世界访问集群服务。在生产环境中，如云平台上，你需要部署入口控制器或负载均衡器才能通过互联网访问你的 Pachyderm 集群。在本地测试部署中，Pachyderm 使用端口转发。NodePort 是另一种配置外部访问的方式，但不推荐用于生产环境，因此在当前描述中已被省略。Pachyderm 提供了一种通过 Helm Chart 安装的 Traefik 入口选项。
-
pachctl是 Pachyderm 的命令行界面（CLI），使用户能够执行与 Pachyderm 管道相关的高级操作，并根据需要配置基础设施。 -
API：Pachyderm 支持通过多种语言客户端进行编程访问，包括 Python、Go 等。许多用户会发现，使用支持的客户端之一或甚至构建自己的客户端非常有用。
-
元数据存储：etcd 收集管理元数据，这些元数据必须存储在本地磁盘或 Kubernetes 的持久化卷（PV）中，可以存储在云平台或任何其他平台上。
-
对象存储：用于存储Pachyderm 文件系统（PFS）和与管道相关的文件。Pachyderm 支持 S3 对象存储，如 MinIO、Google S3、Azure Blob 存储和 Amazon S3。
在图 2.1中，用户通过负载均衡器或入口控制器访问 Pachyderm 集群，可以使用 Pachyderm 仪表板、pachctl，或通过 API 使用语言客户端进行访问。用户的请求被发送到 pachd，pachd 处理请求并相应地更新管道和 etcd 的状态。管道运行后，将结果输出到配置的存储位置，其他第三方应用程序可以从该位置访问该结果。
容器运行时
容器运行时是执行容器内代码的软件。有许多开源容器运行时，如 Docker、container、CRI-O 等。Pachyderm 支持最流行的容器运行时——Docker。Pachyderm 仅支持一种容器运行时，并不意味着功能有限。大多数用户会发现，Docker 容器已足够满足他们的所有需求。
要运行容器，你需要有一个容器镜像以及一个存储它的地方。容器镜像是一个包含程序不可变代码的文件，可以由容器运行时执行。容器镜像存储在容器注册表中，这些是存储或托管容器镜像的库或仓库。部分容器注册表是公开的，另一些则是私有的。所有 Pachyderm 组件都打包为容器镜像，并存储在Docker Hub中，这是一种公共容器注册表，任何人都可以免费下载这些镜像。
所有的 Pachyderm 管道都需要打包成 Docker 容器并存储在容器注册表中。你的组织可能要求你将包存储在私有容器注册表中，以保护管道的知识产权。但如果你是在做开源或学生项目，你可以免费将容器镜像存储在 Docker Hub 中。
现在我们已经回顾了 Pachyderm 架构，让我们来看看 Pachyderm 版本控制的基本原理，这对于理解 Pachyderm 的工作原理至关重要。
学习版本控制原语
正如我们在前面的章节中看到的，Pachyderm 与名为 Git 的代码版本控制软件有相似之处。如果你曾参与过开源项目的开发，你可能通过使用托管的 Git 版本（如 GitHub、GitLab 或 Gerrit）而熟悉 Git。
像使用 Git 一样，你将数据存储在仓库中，通过提交上传数据，并且可以在仓库中拥有多个分支。Pachyderm 存储了你的提交历史，并允许你追溯数据的变化或历史，直至其最初的状态。
Pachyderm 版本控制原语使你能够回溯到过去，并使用管道对先前版本的更改进行处理。这在跟踪偏差和错误（这些可能会悄然进入你的管道更改中）时非常有用。
让我们更详细地了解这些概念。
仓库
Pachyderm 的仓库是一个文件系统，你在其中存储数据并保存数据的不同版本。Pachyderm 区分了输入仓库和输出仓库。
输入仓库是你创建的文件系统，用于上传数据以供进一步处理，可以通过 CLI、UI 或通过 API 自动上传。
输出仓库是 Pachyderm 自动创建的文件系统，其名称与管道相同。这里是 Pachyderm 输出计算结果的地方，也是可以从这里导出结果以供作为模型使用的地方。
与 Git 仓库的一个重要区别是，Pachyderm 仓库历史被存储在一个集中位置，这消除了合并冲突的风险。因此，Pachyderm 没有类似.git历史文件的东西。
以下图示展示了内部和外部仓库在管道中的工作方式：
图 2.2 – Pachyderm 输入和输出仓库
上述图示展示了一个仅包含一个管道的简单用例。然而，您的工作流可能会更加复杂，多个管道可能会交织在一起共同工作，以实现所需的结果。
分支
分支是 Pachyderm 中的一个开发线，用于跟踪仓库中的一组变更。默认情况下，仓库没有分支。我们在本书中使用的主分支只是一个示例，用于说明如何在 Pachyderm 中命名您的主分支，并不强制要求。通常，在向仓库上传初始数据时，您会在仓库上创建一个分支。您可以创建多个分支来组织您的工作，但通常不会像在 Git 中那样广泛使用它们。通常，只用一个分支就足够完成所有工作了。您也可以为不同的实验创建一个单独的分支。所有分支对所有用户可见，因此您不能像在 Git 中那样拥有一个本地分支，在其中进行实验，再与主分支合并。
要创建分支，请运行以下命令：
pachctl create branch <repo>@<branch>
必须在创建分支之前先存在仓库。
要确认分支是否已创建，请运行以下命令：
pachctl list branch <repo>
本节的最后部分将讨论提交概念。
提交
提交是您数据的一个不可更改的变更集。例如，当从流媒体平台（如Kafka）接收新数据时，它会作为一个新提交写入到 Pachyderm 仓库，并附带一个唯一的哈希标识符。
下图展示了 Pachyderm 中分支提交概念的示意图：
图 2.3 – 显示 Pachyderm 提交的示意图
数据变更会存储在仓库历史记录中。每当向仓库提交新提交时，分支的HEAD提交会移动。一旦新数据提交，管道会根据这些最新的更改运行代码，除非明确配置了不同的行为。
现在我们已经了解了最重要的 Pachyderm 版本控制原语，接下来让我们更详细地了解 Pachyderm 管道。
探索管道元素
本节将引导您了解 Pachyderm 管道的主要概念。Pachyderm 管道系统（PPS）是 Pachyderm 功能的核心。
Pachyderm 管道是数据在输出最终结果之前经过的一系列计算任务。例如，它可以是一系列图像处理任务，如为每个图像加标签或应用滤镜。也可以是两个数据集的比较或查找相似性任务。
一个管道执行以下三个步骤：
-
从指定位置下载数据。
-
应用您代码中指定的转换步骤。
-
将结果输出到指定位置。
下图展示了 Pachyderm 管道的工作原理：
图 2.4 – Pachyderm 管道
每个 Pachyderm 管道都有输入和输出仓库。输入仓库是一个文件系统，数据从外部源传入 Pachyderm。它位于管道 Pod 内的 /pfs 目录下。数据可以通过管道拉取，也可以由数据源系统推送到输入仓库。数据经过转换处理后，会被放入输出 Pachyderm 仓库，该仓库位于 /pfs/out 目录下。之后，输出仓库中的结果可以被第三方应用或其他管道进一步使用。
每次新数据到达输入仓库时，Pachyderm 会启动一个管道任务。该任务处理新到的数据并将结果放入输出仓库。
管道类型
机器学习管道持续执行数据科学家对新数据编写的任务。例如，您可能希望比较或合并两种类型的文件，或对它们应用特定的参数。为了简化这些任务，Pachyderm 提供了预定义的管道，可以自动完成这些工作。
Pachyderm 提供以下类型的管道：
-
标准管道
-
Cron 管道
-
Spout 管道
-
服务管道
要创建管道，您需要编写一个管道规范。管道规范是一个文件，采用YAML 不是标记语言（YAML）或JavaScript 对象表示法（JSON）格式，描述管道需要执行的任务。我们将在下一章详细讨论管道规范。
标准管道
标准管道，简称管道，是在 Pachyderm 集群中调度工作的最直接方式。此类管道在新数据进入 Pachyderm 输入仓库时触发。管道启动或恢复一个 Kubernetes Pod 来运行您的代码，并针对新到的数据生成输出结果，结果将存放在输出仓库中。输出仓库会自动创建，并与管道同名。
最简单的标准管道必须包含以下组件：
-
name：管道的描述性名称。为管道命名时，最好选择一个能反映其完成任务的名称。例如，如果您的代码分析社交媒体上用户的情感，您可能希望将其命名为sentiment-analysis或类似名称。 -
transform：管道的转换部分包含有关管道需要拉取和使用的 Docker 镜像以及在管道容器中运行的代码的信息。例如，如果您正在进行情感分析，您可能会使用自然语言处理（NLP）工具，如自然语言工具包（NLTK）或斯坦福 CoreNLP。因此，您可以使用已有的 Docker 镜像，或者构建自己的定制镜像。 -
input：一个输入存储库，管道从中获取数据进行处理。您需要通过 CLI、UI 或 API 将数据上传到输入存储库。
下面的文本是执行情感分析的管道规范示例。该管道称为sentiment-analyzer，使用名为ntlk-image的 Docker 镜像，从名为feed的输入存储库下载数据，然后运行存储在名为transform_code.py的文件中的代码：
# sentiment-analyzer.yml
---
pipeline:
name: sentiment-analyzer
transform:
image: nltk-image
cmd:
- python3
- "/transform_code.py"
input:
pfs:
repo: feed
glob: "/"
glob参数定义如何将数据分解为可在多个 Pachyderm 工作节点上处理的可处理块，以提高性能。我们将在下一节详细讨论此参数。
重要提示
您可以像上面的示例中那样将转换代码放在文件中，也可以直接在cmd字段中指定。有关更多信息，请参阅第三章，Pachyderm 管道规范。
Cron 管道
Cron管道或 cron 是定期运行特定任务的管道。如果您熟悉 UNIX 软件实用程序 cron，则 Cron 管道使用类似的逻辑——它按照指定的时间表定期运行，并每次执行相同的任务。与标准管道不同，标准管道在输入存储库中有新数据到达时运行，Cron 管道则按照时间表运行。您可能希望使用此管道定期抓取网站或表。
Cron 管道规范看起来与标准管道非常相似，除了输入部分。您需要在管道的输入部分指定时间间隔。
下面的文本是以 YAML 格式呈现的 Cron 管道示例，每天午夜定时抓取名为my-website的网站：
# scrape-my-website.yml
---
pipeline:
name: scrape-my-website
transform:
image: web-scraper
cmd:
- python3
- "/scraper.py"
input:
cron:
repo: mywebsite
spec: "@daily"
所有有关网站 URL 的信息将放入您的scraper.py文件中。
喷口管道
s****pout管道或 spout 顾名思义，旨在从外部源（例如发布/订阅消息系统）流式传输数据。在您的基础设施中，您可能有多个消息队列系统。通过 Pachyderm 喷口，您可以将所有这些系统的输入整合到 Pachyderm 喷口管道中。喷口代码不受任何事件触发；相反，它连续运行，监听新消息的到来。
与标准管道或 Cron 管道不同，喷口没有输入存储库，而是在指定地址上侦听。端口和主机可以在管道规范的env变量中或容器内部指定。
常见情况下，一个喷口与 Pachyderm 服务管道一起使用，用于暴露管道的结果，因为喷口输出存储库中的数据无法通过标准的 Pachyderm 命令访问。
下面的文本是以 YAML 格式呈现的喷口管道示例，连接到 Amazon myscript.py，用于处理消息：
---
pipeline:
name: spout-pipeline
spout: {}
transform:
cmd:
- python3
- myscript.py
image: 'myimage'
env:
HOST: sqs-host
TOPIC: mytopic
PORT: '1111'
spout部分为空，但这是你可以将喷口与服务管道结合，向外界暴露管道结果的地方。
服务管道
服务管道，或称服务，是一种可以将输出仓库暴露给外部世界的管道。与其他管道不同，它不会对数据进行任何修改。此管道的唯一功能是通过 API 为你的管道结果提供服务，例如以仪表板的形式。服务管道通常与喷口管道结合使用，有时被称为喷口服务。然而，它可以使用来自任何其他管道输出仓库的结果作为其输入仓库来暴露这些结果。
该管道的管道规范缺少转换部分。以下文本是一个服务管道的 YAML 格式示例：
---
pipeline:
name: expose-service
input:
pfs:
glob: "/"
repo: final-results
service:
external_port: 31111
internal_port: 8888
接下来，我们将看看 Pachyderm 如何处理数据项。
数据项
管道规范中的glob参数。Pachyderm 会独立处理每个数据项。如果你有多个工作节点运行管道，Pachyderm 可以将数据项调度到不同的工作节点上进行更快速的处理，最终所有数据项将在输出仓库中合并。
数据项
这是 Pachyderm 团队使用的术语。是的，通常复数形式是 data，但数据项在 Pachyderm 的文档中是这样出现的！
将数据拆分成多个数据项带来以下优势：
-
通过将管道扩展到多个 Pachyderm 工作节点来提高性能
-
使你能够仅处理特定的文件和文件夹
例如，假设你有一个具有以下文件夹结构的仓库：
data
├── folder1
│ ├── file1
│ ├── file2
│ └── file3
├── folder2
│ ├── file1
│ └── subfolder1
│ └── file1
└── folder3
├── subfolder1
│ ├── file1
│ └── file2
└── subfolder2
├── file1
└── file2
对于此文件夹结构，你可以设置以下几种类型的 glob 模式：
-
/：将所有文件和文件夹作为单一的数据项进行处理。这个单一的数据项包括/目录中的所有文件和文件夹。 -
/*：将每个文件夹作为单独的数据项进行处理。结果的数据项数为三个，包括以下内容：/folder1 /folder2 /folder3 -
/*/*：将/*/*级别上的每个文件系统对象作为单独的数据项进行处理。结果的数据项数为七个，包括以下内容：/folder1/file1 /folder1/file2 /folder1/file3 /folder2/file1 /folder2/subfolder1 /folder3/subfolder1 /folder3/subfolder2 -
/*/*/*：将第三级的每个文件系统对象作为单独的数据项进行处理。结果的数据项数为五个，包括以下内容：/folder2/subfolder1/file1 /folder3/subfolder1/file1 /folder3/subfolder1/file2 /folder3/subfolder2/file1 /folder3/subfolder2/file2 -
/**：将每个文件、文件夹和子文件夹作为单独的数据项进行处理。结果是 15，包括以下代码提取中的所有文件和文件夹：/folder1/ /folder1/file1 /folder1/file2 /folder1/file3 /folder2/ /folder2/file1/ /folder2/subfolder1/ ... -
/<filesystem>/*：仅处理与命名模式匹配的文件和文件夹。例如，如果你只想处理folder1中的数据，你将设置 glob 模式为/folder1/*。类似地，你可以仅将目录名的前几个字母作为 glob 模式。
这些是最常用的 glob 模式。Pachyderm 的 ohmyglob 库提供了扩展的 glob 模式。更多信息请参见 github.com/pachyderm/ohmyglob。
通过数据项扩展管道
将数据分成多个数据项的最大优势之一是可以将工作扩展到多个管道工作节点，从而显著提高管道的性能和处理时间。默认情况下，Pachyderm 为每个管道部署一个工作节点，但你可以根据需要通过在管道规范中指定 parallelism_spec 参数来增加节点数量。
以下图示展示了数据项如何在多个工作节点之间扩展：
图 2.5 – 扩展管道
在前面的图示中，输入数据被拆分到三个工作节点上，它们同时开始处理。在所有数据项处理完成后，它们会合并为最终的输出结果。需要强调的是，数据项仅存在于 Pachyderm 管道内部，不能以任何方式访问、挂载或修改。
Pachyderm 输入
在 Pachyderm 中，你可能会创建多个仓库来存储训练数据、测试数据和参数。Pachyderm 提供了一种自动化的方法，通过使用 输入 将不同仓库中的文件结合在一起，在管道中一起处理。如果你以前使用过 SQL，可能会发现这些输入类似于 SQL 操作符。然而，有一个主要的区别将 SQL 操作符与 Pachyderm 输入区分开来。在 SQL 中，你可以在每个表中创建匹配的行对，而 Pachyderm 输入仅在文件级别上工作。这意味着你只能根据文件的名称而不是文件的内容，将 Pachyderm 仓库中的文件或目录结合在一起。
重要提示
本节提供了如何创建各种 Pachyderm 输入的示例。这些示例仅供参考，你可能会在安装和配置 Pachyderm 后在未来的工作中使用其中的一些。我们将在 第三章的 本地安装 Pachyderm 和 在云平台上部署 Pachyderm 部分中介绍安装和配置。
交叉输入
cross 输入，或称交叉输入，是一种将一个仓库中的每个文件与另一个仓库中的文件进行结合的输入。匹配文件的集合由全局模式决定，在管道运行时，所有数据都对管道代码可见。
你的管道文件中的输入部分（YAML 格式）可能如下所示：
…
input:
cross:
- pfs:
glob: "/*"
repo: data
- pfs:
glob: "/"
repo: parameters
…
例如，你有两个 Pachyderm 仓库，data 和 parameters，其结构和文件如下：
data
├── image1.png
├── image2.png
├── image3.png
└── image4.png
parameters
├── param1.csv
└── param2.csv
如果你创建一个管道，该管道通过设置全局模式 /* 来创建这些仓库的笛卡尔积，你将总共得到八个数据项——data 仓库中的每个文件将与 parameters 仓库中的每个文件结合。这些文件将按以下方式处理：
data@4e5897...:/image1.png, parameters@d1a0da...:/param1.csv
data@4e5897...:/image2.png, parameters@d1a0da...:/param1.csv
data@4e5897...:/image3.png, parameters@d1a0da...:/param1.csv
data@4e5897...:/image4.png, parameters@d1a0da...:/param1.csv
data@4e5897...:/image1.png, parameters@d1a0da...:/param2.csv
data@4e5897...:/image2.png, parameters@d1a0da...:/param2.csv
data@4e5897...:/image3.png, parameters@d1a0da...:/param2.csv
data@4e5897...:/image4.png, parameters@d1a0da...:/param2.csv
在前面的输出中，每对文件和每一行代表一个数据项。
联合输入
一个联合输入（或称为 union）是一个允许你将一个仓库中的数据项与另一个仓库中的数据项合并的输入。数据项的总数是所有仓库中数据项的总和。如果我们采用与交叉输入部分描述相同的仓库结构，并且不是生成交叉积，而是使用 union 输入将它们相加，我们将得到五个数据项的总数。
您的管道文件中的 input 部分在 YAML 格式中可能如下所示：
…
input:
union:
- pfs:
glob: "/*"
repo: data
- pfs:
glob: "/"
repo: parameters
…
以下输出演示了设置了 /* 通配符模式的两个仓库的管道数据项列表：
data@4e58978ca1304f16a0a5dfe3715363b4:/image1.png
data@4e58978ca1304f16a0a5dfe3715363b4:/image2.png
data@4e58978ca1304f16a0a5dfe3715363b4:/image3.png
data@4e58978ca1304f16a0a5dfe3715363b4:/image4.png
model@1de402b7be004a289f6d7185b2329b21:/
您的代码会单独处理每个文件，并且每次运行时只会识别一个文件，忽略其他所有文件。
连接输入
您的 Pachyderm 管道中的 join_on 参数。
Pachyderm 区分 内部连接 和 外部连接。它们之间的区别在于，内部连接匹配文件对，跳过不符合指定模式的文件。外部连接与内部连接的行为相同，但还包括那些不符合模式的文件在管道运行中。如果这听起来有些混淆，下面的示例应该可以帮助澄清管道的工作方式。
假设您有两个仓库，data 和 parameters，并且 parameters 仓库具有以下结构：
NAME TYPE SIZE
/param-0101-2021.txt file 4B
/param-0102-2021.txt file 4B
/param-0103-2021.txt file 4B
/param-0104-2021.txt file 4B
/param-0105-2021.txt file 4B
data 仓库具有以下结构：
NAME TYPE SIZE
/data-0101-2021.txt file 2B
/data-0102-2021.txt file 2B
/data-0103-2021.txt file 2B
/data-0104-2021.txt file 2B
/data-0105-2021.txt file 2B
/data-0106-2021.txt file 2B
/data-0107-2021.txt file 2B
在您的管道中，您可能希望按日期匹配文件。为此，您需要指定捕获组 $1 和通配符模式 /。以下是一个在 YAML 格式中匹配这些文件路径的管道规范示例：
---
pipeline:
name: describe
input:
join:
- pfs:
glob: "/data-(*).txt"
repo: data
join_on: "$1"
- pfs:
glob: "/param-(*).txt"
repo: parameters
join_on: "$1"
transform:
image: mydockerhub/describe
cmd:
- python3
- "/describe.py"
这个捕获组结合 / 通配符模式匹配了五对文件：
data@2c95b1...:/data-0101-2021.txt, parameters@b7acec...:/param-0101-2021.txt
data@2c95b1...:/data-0102-2021.txt, parameters@b7acec...:/param-0102-2021.txt
data@2c95b1...:/data-0103-2021.txt, parameters@b7acec...:/param-0103-2021.txt
data@2c95b1...:/data-0104-2021.txt, parameters@b7acec...:/param-0104-2021.txt
data@2c95b1...:/data-0105-2021.txt, parameters@b7acec...:/param-0105-2021.txt
/data-0106-2021.txt 和 /data-0107-2021.txt 没有匹配的配对，因此 Pachyderm 会在此运行中跳过它们。但是，如果您希望将这些文件包含在管道运行中，可以在 data 仓库输入中指定 outer_join: true，以在没有配对的情况下将这些文件包括在管道运行中。以下抽象展示了如何添加此参数：
…
input:
join:
- pfs:
glob: "/data-(*).txt"
repo: data
join_on: "$1"
outer_join: true
…
然后，您的管道中的数据项列表将如下所示：
data@2c95b1...:/data-0101-2021.txt, parameters@b7acec...:/param-0101-2021.txt
data@2c95b1...:/data-0102-2021.txt, parameters@b7acec...:/param-0102-2021.txt
data@2c95b1...:/data-0103-2021.txt, parameters@b7acec...:/param-0103-2021.txt
data@2c95b1...:/data-0104-2021.txt, parameters@b7acec...:/param-0104-2021.txt
data@2c95b1...:/data-0105-2021.txt, parameters@b7acec...:/param-0105-2021.txt
data@2c95b1...:/data-0106-2021.txt
data@2c95b1...:/data-0107-2021.txt
data-0106-2021.txt 和 data-0107-2021 在管道运行中被包含，但没有配对。
组输入
一个 group_by 管道参数。如果我们采用与内部连接输入示例中相同的管道，并将 join 替换为 group，将 join_on 替换为 group_by，我们将得到与内部连接输入相同的结果。
与连接输入的主要区别包括以下几点：
-
一个组输入会生成一个包含符合命名模式的文件的大数据项，而连接则会交叉匹配两个符合模式的文件，通常会生成更多的数据项。
-
组输入使您能够在单一仓库中匹配文件对，而连接则需要至少两个仓库。
-
组输入在时间序列场景中尤其有用，尤其是在您需要根据时间戳对文件进行分组时。
因此，你可以创建一个带有替换组的 cron 流水线，该替换组匹配特定的时间戳。
例如，假设你有一个数据仓库，其结构如下：
/data-0101-2020.txt file 2B
/data-0101-2021.txt file 2B
/data-0102-2020.txt file 2B
/data-0102-2021.txt file 2B
/data-0103-2020.txt file 2B
/data-0103-2021.txt file 2B
/data-0104-2021.txt file 2B
/data-0105-2021.txt file 2B
/data-0106-2021.txt file 2B
/data-0107-2021.txt file 2B
你可以使用 YAML 格式创建如下的流水线：
---
pipeline:
name: test-group
transform:
cmd:
- python3
- "/test.py"
input:
group:
- pfs:
repo: data
glob: "/data-(*)-(*).txt"
group_by: "$1"
你的流水线中列出了两个替换组。第一个替换组匹配文本文件名称中的月日。例如，在文件 /data-0104-2021.txt 中，它是 0104。第二个替换组匹配时间戳中的年份。在同一个文件中，它是 2021。
如果你在流水线中指定了第一个匹配组，最终的数据列表将包含三对数据，总共七个数据项：
data@...:/data-0101-2020.txt, data@..:/data-0101-2021.txt
data@...:/data-0102-2020.txt, data@...:/data-0102-2021.txt
data@...:/data-0103-2020.txt, data@...:/data-0103-2021.txt
data@...:/data-0104-2021.txt
data@...:/data-0105-2021.txt
data@...:/data-0106-2021.txt
data@...:/data-0107-2021.txt
在前面的输出中，匹配的日期和月份的文件，如 0101，被分组为一个数据项。如果你将 group_by 参数更改为使用第二个替换组，即按年份分组，则数据列表将包含两个数据项，将文件按年份分组：
- data@ecbf241489bf452dbb4531f59d0948ea:/data-0101-2020.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0102-2020.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0103-2020.txt
- data@ecbf241489bf452dbb4531f59d0948ea:/data-0101-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0102-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0103-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0104-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0105-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0106-2021.txt, data@ecbf241489bf452dbb4531f59d0948ea:/data-0107-2021.txt
在本节中，我们了解了最重要的 Pachyderm 流水线原语及其相互之间的区别。
摘要
在这一章中，我们了解了最重要的 Pachyderm 版本控制原语，包括仓库、分支和提交。我们回顾了这些与 Git 版本控制系统相似，但也存在一些非常重要的区别。
我们已经了解了 Pachyderm 流水线和输入的类型，以及如何通过使用通配符模式和数据项来扩展和优化流水线。
在下一章中，我们将更详细地回顾 Pachyderm 流水线规范，并学习如何使用各种流水线设置以最有效的方式运行流水线。
进一步阅读
-
Git 文档:
git-scm.com/ -
Kubernetes 文档:
kubernetes.io/docs/home -
Helm 文档:
helm.sh/docs/
第三章：第三章：象皮管道规范
机器学习（ML）管道是一个自动化工作流，它使你能够对不同的数据和参数组合持续执行相同的代码。管道确保每个周期都是自动化的，并且按照相同的步骤顺序执行。在许多其他技术中，像在 Pachyderm 中，机器学习管道是通过一个叫做管道规范（pipeline spec）的配置文件定义的。
Pachyderm 管道规范是 Pachyderm 中最重要的配置，因为它定义了你的管道执行的任务、执行频率、工作如何分配给 Pachyderm 工作节点，以及结果输出的地点。
本章旨在作为管道规范参考，并将带你了解你可以为管道指定的所有参数。为此，我们将讨论以下主题：
-
管道规范概述
-
理解输入
-
探索信息参数
-
探索转换
-
优化你的管道
-
探索服务参数
-
探索输出参数
管道规范概述
通常，当你进行机器学习实验时，涉及多个顺序步骤。在最简单的场景下，你的管道从输入仓库获取输入，应用你的转换代码，并将结果输出到输出仓库。例如，你可能有一组图片，要应用单色滤镜，然后将结果输出到一个与管道同名的输出仓库。这个工作流仅执行一个操作，可以称为单步管道，或者单步工作流。这样管道的图示可能如下所示：
图 3.1 – 单步工作流
这个简单管道的规范，采用 YAML 格式，看起来会像这样：
---
pipeline:
name: apply-photo-filter
transform:
cmd:
- python3
- "/photo-filter.py"
image: myregistry/filter
input:
pfs:
repo: photos
glob: "/"
这是你可以创建的最简单的管道规范。它必须包含以下参数：
-
name：为你的管道指定一个描述性的名称。通常，管道的名称描述了机器学习工作流中的某个步骤。例如，如果这个管道对你的图片应用滤镜，你可以称它为apply-photo-filter。或者，如果它进行模型验证，你可以称它为cross-validation。 -
transform：此参数包括你的转换代码，可以作为对文件的引用或直接内联指定。我们将在下一节详细讨论这个参数。 -
input：该参数指的是一个现有的输入仓库，文件位于该仓库中以供流水线使用。input是你流水线工作节点下的一个文件系统，位于pfs/目录下。例如，如果你的仓库名为photos，它会存储在工作节点的pfs/photos下。输出仓库由流水线自动创建，并存储在pfs/out下。所有输出仓库的名称与流水线名称相同。例如，如果你的流水线名为apply-photo-filter，那么输出仓库会存储为apply-photo-filter，位置在pfs/out/。
这是一个非常简单的流水线示例。在更现实的应用场景中，通常会有多个流水线步骤。在典型的机器学习流水线中，你需要执行数据预处理、训练、交叉验证等步骤。当多个流水线串联在一起时，这被称为 多步骤工作流。例如，如果你正在创建一个自然语言处理（NLP）流水线，可能会有如下结构：
图 3.2 – 多步骤工作流
在前面的示意图中，每个流水线都有一个流水线规范，定义了名称、输入仓库、转换代码以及其他参数。
所有流水线规范必须以 YAML Ain’t Markup Language（YAML）或 JavaScript Object Notation（JSON）格式编写。这些格式便于人类阅读和编写，并广泛应用于各类行业中的配置文件中。它比 可扩展标记语言（XML）或其他类似格式更容易编写。
现在我们已经回顾了最基本的流水线规范，并查看了一个更现实的示例，让我们来回顾一下你可以指定的其他参数。
理解输入
我们在第二章《Pachyderm 基础》一章中详细描述了输入，并提供了示例。因此，在本节中，我们只会提到输入定义了流水线的类型。你可以指定以下几种类型的 Pachyderm 输入：
-
PFS 是一个通用参数，用于定义所有多输入流水线中的标准流水线和输入。
-
Cross 是一种输入，它创建两个输入仓库中数据项的笛卡尔积。生成的输出将包含来自输入仓库的所有数据项的所有可能组合。
-
Union 是一种输入，它将一个仓库中的数据项添加到另一个仓库的数据项中。
-
Join 是一种输入，它将具有特定命名模式的数据项匹配起来。
-
Spout 是一种输入，它从第三方来源获取数据，并将数据添加到 Pachyderm 文件系统中以供进一步处理。
-
Group 是一种输入，它根据配置的命名模式将来自多个仓库的数据项组合在一起。
-
Cron 是一种根据指定时间间隔运行的流水线。
-
Git 是一种输入，可以让你从 Git 仓库中导入数据。
对于除 Cron 和 Git 外的所有输入，你可以定义一个 pfs 参数来定义输入。
pfs
pfs 参数，代表 pfs 输入。你需要为所有管道定义一个或多个 pfs 输入，除了 Cron 和 Git。
以下是 pfs 输入的子参数：
-
name：管道的名称。 -
repo：一个 Pachyderm 输入库，数据存储在此处。 -
branch：Pachyderm 输入库中的一个分支，数据存储在此分支中。通常，这将是master分支。 -
glob：一个定义如何将数据分块进行处理的参数。你可以在 第二章，Pachyderm 基础知识 中的 Datums 部分阅读更多关于glob参数的内容。 -
lazy：一个启用较慢、较不激进数据下载的参数。lazy参数在你需要查看数据的一个子集时非常有用。 -
s3：这个参数定义是否在管道中包含 S3 网关 sidecar。当你通过 S3 网关与第三方应用集成时，它确保管道的来源信息被保留。
你可以在 第二章，Pachyderm 基础知识 中阅读更多关于管道和输入类型的信息，并查看示例管道。接下来的部分描述了可以为管道定义的信息性参数。
探索信息性参数
管道信息性参数定义了管道的基本信息。在所有这些参数中，只有 name 参数是任何管道规范中必需的。其他所有参数都是可选的，可以省略。让我们更详细地了解这些参数。
name
name 参数是管道的描述性名称。通常，你会根据管道执行的变换类型来命名管道。例如，如果你的管道执行图像分类，你可能想将其命名为 image-classification。管道名称必须由字母数字字符、短横线和下划线组成，并且不能超过 63 个符号。
以下是 name 参数的 YAML 格式示例：
---
pipeline:
name: image-classification
以下是 name 参数的 JSON 格式示例：
{
"pipeline": {
"name": "image-classification"
},
接下来，我们来看看 description 参数。
description
description 参数提供关于管道的附加信息。虽然它是一个可选参数，但最好为你的管道添加一个简短的描述。例如，如果你的管道执行图像分类，你可以添加以下描述：一个使用 scikit-learn 进行图像分类的管道。
以下是 description 参数的 YAML 格式示例：
description: A pipeline that performs image classification by using scikit-learn.
以下是 description 参数的 JSON 格式示例：
"description": "A pipeline that performs image classification by using scikit-learn.",
接下来，我们了解一下 metadata。
metadata
metadata 参数使您能够指定 Kubernetes 标签或注释。标签通常用于将 Kubernetes 对象分组到某种类别中，帮助简化这些对象的管理。标签可以查询以显示相同类型的对象。
注释则可以用来指定 Kubernetes 中未定义的任何随机键值对，这些键值对可以供外部应用程序使用。您可以使用注释来定义服务的类型，例如 pach_patch 或 pach_spec。在每个流水线规范中，可以指定多个标签和注释。
这是一个如何在 YAML 格式中指定注释的示例：
metadata:
annotations:
annotation: data
以下示例展示了如何在 JSON 格式中指定注释：
"metadata": {
"annotations": {
"annotation": "data"
}
},
以下示例展示了如何在 YAML 格式中指定标签：
metadata:
labels:
label: object
最后，以下示例展示了如何在 JSON 格式中指定标签：
"metadata": {
"labels": {
"label": "object"
}
},
现在我们已经了解了信息性参数，让我们看看 Pachyderm 流水线中的 transformation 部分。
探索转换
transformation 部分是您定义流水线转换代码的地方。它是流水线功能的核心。除非是两个流水线之间的连接器，或者是将结果导出到 Pachyderm 外部的流水线，大多数流水线都必须具有 transformation 部分。
transformation 部分最重要的参数——也是最常用的——是 image 和 cmd 或 stdin、env 和 secrets。
让我们更详细地看看这些参数。
image
image 参数定义了一个 Docker 镜像，您的流水线将在其中运行。一个 Docker 镜像包含了流水线容器中环境的相关信息。例如，如果您运行 Python 代码，您需要在流水线镜像中包含某个版本的 Python。您可以使用许多公开可用的容器来构建您的流水线。
您还可以在该容器中包含您的脚本。除非您的代码只是一个可以通过 stdin 参数内联指定的 Bash 脚本，否则您可能需要构建自己的 Docker 镜像，将代码包含在镜像中，并将其存储在公共或私有容器注册表中。Docker 镜像是通过 Dockerfile 构建的，Dockerfile 描述了容器环境以及您可以在容器中运行的内容。您可以在 docs.docker.com/ 阅读更多关于 Docker 镜像的信息。
重要提示
不要使用 Docker 的 CMD 指令；请改用 RUN。CMD 指令会失败。
以下代码展示了如何在 YAML 格式中指定 Docker image：
metadata:
labels:
label: object
以下代码展示了如何在 JSON 格式中指定 Docker image：
"transform": {
"image": "my-image",
然而，仅仅指定 Docker 镜像是不够的。您必须定义要运行的内容，可以通过 cmd 或 stdin 参数来实现。
cmd
cmd参数定义了管道将对数据运行的代码。你可以在cmd行中做很多灵活的配置。通常，你会指定要运行的命令类型，例如python，或者设置它运行命令行 shell，例如sh或bash，然后在stdin参数中指定你想要运行的命令列表。
这两种方法没有区别或优先之分。唯一的区别是，如果你在cmd参数中指定了文件，你需要构建一个 Docker 镜像并将该文件包含在镜像中。
例如，如果你有一个 Python 3 文件，包含你希望在数据上运行的代码，你可以在 YAML 格式中像这样指定它：
cmd:
- python3
- "/test.py"
另外，你可以在 JSON 格式中指定标签：
"transform": {
"cmd": [ "python3", "/test.py" ],
然而，如果你想在stdin参数中内联指定命令，只需按照cmd参数中指定的格式，如此，在 YAML 格式中：
cmd:
- python3
你也可以使用 JSON 格式来实现相同的功能：
"transform": {
"cmd": [ "python3" ],
请参阅stdin部分，了解如何指定内联代码的示例。
然而，你的cmd字段可能会更复杂。例如，你可以在cmd参数中指定一个脚本。
以下文本是你可以在 YAML 格式的cmd字段中使用的语法示例：
transform:
image: my-image
cmd:
- tree
- "/pfs"
- "&&"
- python
- my-script.py
- "--outdir"
- "/pfs/out"
- "--input"
- "/pfs/data "
以下文本是你可以在 JSON 格式的cmd字段中使用的语法示例：
"transform": {
"image": "my-image",
"cmd": ["tree",
"/pfs",
"&&",
"python",
"my-script.py",
"--outdir", "/pfs/out",
"--input", "/pfs/data "]
},
接下来，让我们回顾一下stdin参数。
stdin
stdin参数类似于 UNIX 标准输入（stdin），它使 Pachyderm 环境与管道工作者之间能够进行通信。这意味着你可以在stdin字段中按cmd命令指定的格式插入代码。你也可以像cmd参数一样指定代码文件的路径。
这种方法不需要你构建 Docker 镜像，允许你通过管道规范完全配置管道。如果你对 Docker 镜像构建过程不熟悉，这种方法可能更具吸引力。然而，对于更复杂的管道，你可能希望将脚本保存为文件，构建 Docker 镜像，并在管道中使用它们。
以下代码展示了你可以在 YAML 格式的stdin字段中使用的语法：
transform:
cmd:
- bash
stdin:
- for f in /pfs/data/*
- do
- filename=$(basename "$f")
- cp /pfs/data/* pfs/out/mypipeline/*
- done
以下是你可以在 JSON 格式的stdin字段中使用的语法示例：
"transform": {
"cmd": ["bash"],
"stdin": [
"for f in /pfs/data/*",
"do",
"filename=$(basename \"$f\")",
"cp /pfs/data/* pfs/out/mypipeline/*",
"done"]
},
由于前面的示例没有引用任何文件，你不需要为它们构建特定的 Docker 镜像并将文件包含在内。
然而，如果你引用了任何文件或任何比 Bash 稍微复杂的环境先决条件，你可能需要一个 Docker 镜像。例如，如果你有一个包含代码的my-script.py文件，你需要构建一个 Docker 镜像，包含该脚本，并且你必须在管道规范中引用它。
err_cmd
err_cmd参数使您能够定义 Pachyderm 如何处理失败的数据项，并最终允许您将失败的数据项视为非关键错误，从而允许包含失败数据项的作业成功，并仅使用健康数据项触发下一个作业。err_cmd不会将任何数据写入输出仓库。err_cmd字段通常与err_stdin字段结合使用，您可以在其中指定实际的错误代码，尽管您也可以引用包含错误代码的文件。如果您希望即使作业包含失败的数据项，您的管道仍然成功，您只需设置"err_cmd": true。
以下是您可以在err_cmd字段中使用的语法，格式为 YAML：
transform:
...
err_cmd:
- bash
- "/my-error-code.sh"
以下是您可以在err_cmd字段中使用的语法，格式为 JSON：
"transform": {
...
"err_cmd": [ "bash", "/my-error-code.sh"],
在下一节中，我们将查看如何将err_cmd与err_stdin结合使用的示例。
err_stdin
err_stdin参数与err_cmd参数结合使用，用于指定针对失败数据项运行的错误代码。类似于stdin参数，您可以指定内联代码来处理失败的数据项。例如，您可能希望检查数据项是否位于特定目录中，如果是，则将该数据项标记为失败。通常，您可以编写一个简单的 Bash 脚本，使用if… then条件来处理此问题。
以下代码显示了您可以在err_stdin与err_cmd字段中结合使用的语法，格式为 YAML：
transform:
...
err_cmd:
- bash
err_stdin:
- if
- "[-a /pfs/repo1]"
- then
- exit 0
- fi
- exit 1
以下代码显示了您可以在err_stdin与err_cmd字段中结合使用的语法，格式为 JSON：
"transform": {
...
"err_cmd": [
"bash"
],
"err_stdin": [
"if",
"[-a /pfs/repo1]",
"then",
"exit 0",
"fi",
"exit 1"
]
接下来，让我们了解env参数。
env
env参数使您能够指定 Pachyderm 环境变量和您需要与其他第三方工具通信的任意变量。这些参数可以包括目录和文件路径、主机名和端口、密钥访问、各种标识符等。
也可以包含 Pachyderm 变量。例如，您可以使用LOG_LEVEL环境变量来指定pachd的日志消息详细程度。另一个例子是，您还可以在env字段中指定 AWS 区域和桶。
以下代码显示了您可以在env字段中使用的语法，格式为 YAML：
transform:
...
env:
AWS_REGION: us-west-2
S3_BUCKET: s3://my-bucket/
以下代码显示了您可以在env字段中使用的语法，格式为 JSON：
"transform": {
...
"env": {
"AWS_REGION": "us-west-2",
"S3_BUCKET": "s3://my-bucket/"
}
},
有关 Pachyderm 变量的完整列表，请参阅 Pachyderm 文档：docs.pachyderm.com/latest/deploy-manage/deploy/environment-variables/。
secrets
secrets字段使您能够指定 Kubernetes 密钥，这些密钥包含敏感信息，如密码或 SSH 公钥。您需要通过使用env_var和key参数或mount_point参数来定义一个密钥。
以下代码显示了您可以在name和mount_path字段中使用的语法，以设置secrets文件的路径，格式为 YAML：
transform:
...
secrets:
name: my-ssh-key
mount_path: "/path/to/file"
以下代码展示了如何以 JSON 格式指定这些参数：
transform:
...
"secrets": {
"name": "my-ssh-key",
"mount_path": "/path/to/file"
}
以下代码展示了你可以在env_var和key参数中使用的语法，用于以 YAML 格式设置秘密：
transform:
...
secrets:
name: my-ssh-key
env_var: MY_KEY
key: "mykey"
以下是如何以 JSON 格式执行相同操作：
"transform": {
...
"secrets": {
"name": "my-ssh-key",
"env_var": "MY_KEY",
"key": "my_key"
}
接下来，我们来了解一下image_pull_secrets。
image_pull_secrets
image_pull_secrets参数使你能够配置 Pachyderm 管道，从私人 Docker 注册表拉取镜像。要指定此参数，你需要创建一个带有 Docker 配置的 Kubernetes 秘密，具体描述请参见 Kubernetes 文档：https://kubernetes.io/docs/concepts/containers/images/#creating-a-secret-with-a-docker-config，然后在管道规范中的image_pull_secrets参数下指定该秘密。你需要使用 Docker 镜像的完整路径，以确保管道能够正确拉取镜像。
以下代码展示了你可以在image_pull_secrets参数中使用的语法，用于启用管道从私人 Docker 注册表拉取镜像的 YAML 格式：
transform:
...
image: my-private-docker-registry.com/my-project/my-image:latest
image_pull_secrets:
- my-secret
这是如何以 JSON 格式编写相同内容：
"transform": {
...
"image": "my-private-docker-registry.com/my-project/my-image",
"image_pull_secrets": ["my-secret"]
接下来，我们将审查的参数是accept_return_code。
accept_return_code
accept_return_code参数使你能够指定一个整数数组，定义管道仍然被视为成功的错误代码。你可以在希望即使某部分失败，代码仍然成功的情况下使用此功能。这个参数类似于err_cmd功能。
以下代码展示了你可以在accept_return_code参数中使用的语法，用于以 YAML 格式指定错误代码：
transform:
...
accept_return_code:
- 256
以下是以 JSON 格式的相同示例：
"transform": {
...
"accept_return_code": [256]
接下来，我们将查看的参数是debug。
debug
debug参数使你能够设置管道日志输出的详细程度。默认启用基本日志记录，但如果你希望包含更多详细的消息，可以将此参数设置为true。默认情况下，此参数为false。
以下是如何在 YAML 格式中启用管道的调试日志记录：
transform:
...
debug: true
这是如何以 JSON 格式启用管道的调试日志记录：
"transform": {
...
"debug": true
接下来，我们来了解如何使用user参数。
user
user参数使你能够定义一个用户和一个组，用来运行容器的代码。这个参数类似于 Docker 的USER指令，你也可以通过Dockerfile来定义它。默认情况下，Pachyderm 首先检查Dockerfile中的内容，并为管道规范中的user参数设置该值。如果在Dockerfile和管道规范中都没有指定，默认使用的参数值是root。只有在使用--no-expose-docker-socket参数部署 Pachyderm 时，必须在管道规范中显式指定用户。
你可以在docs.docker.com/engine/reference/builder/#user上阅读更多关于 Docker USER参数的信息。
以下是如何在 YAML 格式中指定 user 的方式：
transform:
...
user: test-user
以下是如何在 JSON 格式中指定 user 的方式：
"transform": {
...
"user": "test-user"
现在，让我们了解 working_dir 参数。
working_dir
working_dir 参数使您能够为管道容器指定工作目录。此参数类似于 Docker 的 WORKDIR 指令，您也可以通过 Dockerfile 定义它。默认情况下，Pachyderm 会首先检查 Dockerfile 中的内容，并将其值设置为管道规范中的 working_dir 参数。如果 Dockerfile 和管道规范中都没有指定，则使用默认参数，即根目录（/）或 Docker 镜像从基础镜像继承的目录。只有在使用 --no-expose-docker-socket 参数部署 Pachyderm 时，您才需要在管道规范中明确指定工作目录。
您可以在 docs.docker.com/engine/reference/builder/#workdir 阅读更多关于 Docker Workdir 参数的信息。
以下是如何在 YAML 格式中指定 workdir 的方式：
transform:
...
working_dir: /usr/src/test
在 JSON 格式中，相同的参数如下所示：
"transform": {
...
"working_dir": "/usr/src/test"
接下来，我们将了解 dockerfile 参数。
dockerfile
dockerfile 参数使您能够指定 Dockerfile 的路径，用于您的管道。当您使用 Pachyderm 的 pachctl update-pipeline –build -f <pipeline-spec> 来为管道构建新的 Docker 镜像时，这非常有用。默认情况下，Pachyderm 会在与管道规范相同的目录中查找 Dockerfile。但通过 dockerfile 参数，您可以设置任何路径。
以下是如何在 YAML 格式中指定 Dockerfile 路径的方式：
transform:
...
dockerfile: /path/to/dockerfile
您也可以像这样在 JSON 格式中执行相同操作：
"transform": {
...
"dockerfile": "/path/to/dockerfile "
在本节中，我们了解了可以为转换代码指定的所有参数。在下一节中，我们将回顾如何控制管道工作者的性能，并分配资源限制来优化管道。
优化您的管道
本节将带您了解可能帮助您优化管道以提高性能的管道规范参数。由于 Pachyderm 运行在 Kubernetes 上，它是一个高度可扩展的系统，可以帮助您明智地使用底层硬件资源。
Pachyderm 的最大优势之一是您可以为每个管道单独指定资源，以及定义每次运行时管道将生成多少个工作者，以及它们在空闲等待新工作时的行为。
如果您只是测试 Pachyderm，以了解它是否适合您的用例，那么优化参数可能不那么重要。但如果您正在实施一个包含多个管道且大量数据被注入到 Pachyderm 中的企业级数据科学平台，了解如何优化管道将变得至关重要。
在继续之前，您必须理解 Pachyderm 数据项的概念。数据项在管道可扩展性中起着重要作用。如果您还没有阅读第二章，《Pachyderm 基础》一章，建议在继续之前先阅读它。
parallelism_spec
parallelism_spec定义了为您的管道启动的工作节点数量。您可以指定coefficient或constant策略。默认情况下，Pachyderm 会为每个管道部署一个工作节点，使用constant策略，值为1。
coefficient策略意味着 Pachyderm 将根据指定的系数创建多个工作节点。例如，如果您在 Kubernetes 集群中有 50 个节点，并将coefficient策略设置为1，Pachyderm 将使用该集群的所有 50 个节点。如果您使用coefficient策略，您的管道需要访问 Kubernetes 的管理节点。如果您在托管版本的 Kubernetes 上运行 Pachyderm，例如在 AWS 或 GKE 平台上，您可能无法访问这些节点，管道将不断重启。在这种情况下，您将必须使用constant策略。
constant策略使您能够为管道指定确切数量的工作节点，如 3、25 或 100。这些工作节点将在该管道中无限期运行。然而，如果您希望在空闲时动态调整集群规模，您可以设置standby:true参数，以便集群根据工作负载动态调整大小。
以下代码展示了您可以在parallelism_spec参数中使用的语法，用于指定coefficient策略的 YAML 格式：
parallelism_spec:
coefficient: '1'
以下代码展示了您可以在parallelism_spec参数中使用的语法，用于指定coefficient策略的 JSON 格式：
"parallelism_spec": {
"coefficient": "1"
},
这是您可以在 YAML 格式中定义parallelism_spec参数以指定constant策略的方式：
parallelism_spec: until_success
以下代码展示了如何在parallelism_spec参数中使用constant策略的 JSON 格式：
"parallelism_spec": "until_success"
接下来，让我们学习如何使用reprocess_spec。
reprocess_spec
reprocess_spec使您能够强制管道重新处理所有数据项。默认情况下，Pachyderm 会跳过重新处理成功的数据项，但如果您的管道与外部应用程序或系统进行交互，您可能希望重新处理所有数据项。这种行为可以保护管道免受连接和其他错误的影响。
以下是您可以在reprocess_spec中使用的 YAML 格式语法：
reprocess_spec:
constant: '1'
以下是您可以在reprocess_spec中使用的 JSON 格式语法：
"parallelism_spec": {
"constant": "1"
}
接下来，我们将学习如何使用cache_size。
cache_size
cache_size 参数使您能够定义用户和存储容器的缓存内存大小。Pachyderm 会在处理数据之前预先下载数据，增加 cache_size 可以帮助提高下载速度。默认值为 64M，您可以根据需要增加该值来缓存您的数据。这个参数是微调参数，只有在通过 glob 和 parallelism_spec 优化了管道之后才应该使用。
以下是您可以在 cache_size 参数中使用的语法示例，用于以 YAML 格式增加缓存大小：
cache_size: 1G
在 JSON 格式中，相同的参数将如下所示：
"cache_size": "1G",
现在，让我们回顾一下 max_queue_size 参数。
max_queue_size
max_queue_size 参数定义了管道可以同时下载多少数据项。您可以使用 max_queue_size 使管道在处理其他数据项时预先下载下一个数据项。默认情况下，Pachyderm 将 max_queue_size 设置为 1，意味着一次只能下载一个数据项。这是一个微调参数，如果下载时间显著长于处理时间，调整此参数可以提高数据项下载到工作节点的速度。然而，只有在正确配置了 glob 和 parallelism_spec 后，您才应该调整此参数。
以下代码展示了如何使用 max_queue_size 参数以 YAML 格式增加缓存大小：
max_queue_size: 5
在 JSON 格式中，相同的键值对如下所示：
"max_queue_size": "5",
接下来，我们将学习 chunk_spec。
chunk_spec
chunk_spec 参数定义了每个工作节点处理的数据项数量。默认情况下，此参数设置为 1。数据块可以通过 number（数据项数量）或 size_bytes（字节大小）来设置。例如，如果您将 chunk_spec 中的 number 设置为 3，则每个工作节点一次会处理三个数据项。
使用 size_bytes，如果数据项的运行时间与其大小成正比，您可以使数据项大小均匀。如果不是这种情况，请改用 number 参数。
以下代码展示了如何在 chunk_spec 参数中设置 number，以使工作节点一次处理指定数量的数据项，并以 YAML 格式呈现：
chunk_spec:
number: '10'
这是您可以在 chunk_spec 参数中设置 number，使得工作节点一次处理指定数量数据项的 JSON 格式：
"chunk_spec": {
"number": "10"
},
以下代码展示了如何在 chunk_spec 参数中设置 size_bytes（数据项的字节数），使得工作节点一次处理指定数量的数据项，并以 YAML 格式呈现：
chunk_spec:
size_bytes: '1210'
如果您更喜欢使用 JSON 格式，设置 chunk_spec 参数中的 size_bytes，使工作节点一次处理指定数量的数据项，将是如下所示：
"chunk_spec": {
"size_bytes": "1210"
},
接下来，我们将学习如何设置资源限制。
resource_limits
resource_limits 参数使你能够限制 GPU 资源的 type 数量。管道工作者不能使用超过你指定的资源限制。resource_request 参数类似，但如果有足够的资源，工作者可以使用超过请求的资源。你可以在 Kubernetes 文档中阅读更多关于 resource_limits 和 resource_requests 的内容，链接：kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits。
以下代码展示了如何在 YAML 格式中设置 resource_limits 参数以限制 Pachyderm 工作者资源：
resource_limits:
cpu: 1
gpu:
type: nvidia.com/gpu
number: 1
memory: 16G
以下代码展示了如何在 JSON 格式中设置 resource_limits 参数以限制 Pachyderm 工作者资源：
"resource_limits": {
"cpu": 1,
"gpu": {
"type": "nvidia.com/gpu",
"number": 1,
"memory": "16G"
}
},
如果你需要设置特定的云资源类型，例如 Google Kubernetes Engine 中的 TPU，你可以通过配置 pod_patch 来实现。有关更多信息，请参见接下来的 pod_patch 部分。
resource_requests
resource_requests 参数指定管道工作者请求处理一个工作单元所需的资源数量。与 resource_limits 参数不同，如果有更多资源可用，工作者可以使用这些资源。该参数的语法与 resource_limits 相同。
sidecar_resource_limits
该参数类似于 resource_limits，并定义了管道 sidecar 容器的资源。有关一些示例语法，请参见 resource_limits 部分。
scheduling_spec
scheduling_spec 参数使你能够根据指定的 node_selector 或 priority_class 来指定运行管道代码的 Pods。node_selector 允许你指定一组具有相同标签的节点，称为 nodeSelector，而 priority_class 允许你将管道调度到匹配 Kubernetes PriorityClass 的节点组上。scheduling_spec 参数通常用于根据资源调度管道到特定的工作节点。有关这些属性的更多信息，请参见 kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector 和 kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass。
以下代码展示了如何在 YAML 格式中定义 nodeSelector：
scheduling_spec:
node_selector:
kubernetes.io/my-hostname: my-node
以下代码展示了如何在 JSON 格式中定义 nodeSelector：
"scheduling_spec": {
"node_selector": {"kubernetes.io/my-hostname": "my-node"
}
},
要在 YAML 格式中定义 PriorityClass 参数，请使用以下代码：
scheduling_spec:
priority_class: high-priority
kubernetes.io/my-hostname: my-node
或者，如果你更喜欢使用 JSON 格式，请按以下方式设置 PriorityClass：
"scheduling_spec": {
"priority_class": "high-priority"
}
接下来，我们将学习如何为一个作业设置超时。
job_timeout
job_timeout 参数使你能够为 Pachyderm 作业运行设置超时。这意味着如果作业在指定时间内未完成，它将失败。默认情况下，该参数是禁用的，你可以将其设置为你希望的时间值。
以下代码展示了如何在 YAML 格式中定义 job_timeout 参数：
job_timeout: 10m
这是相同示例的 JSON 格式：
"job_timeout": "10m"
接下来，我们将了解 datum_timeout。
datum_timeout
datum_timeout 超时与 job_timeout 类似，唯一的区别是超时设置在数据粒度级别。语法相同。
datum_tries
datum_tries 参数定义了 Pachyderm 在数据失败时重试管道的次数。默认情况下，该参数设置为 3。如果你只希望管道运行一次，不再尝试处理失败的数据，请将此值设置为 1。
以下代码展示了如何在 YAML 格式中定义 job_tries 参数：
datum_tries: 1
如果你更倾向于使用 JSON 格式编写，可以使用以下代码：
"datum_tries": "1"
在本节中，我们学习了如何通过微调管道规范来实现最佳性能。下一节，你将学习如何配置一些辅助管道操作的服务参数。
探索服务参数
现在，让我们来看一下服务参数。服务参数包括那些让你收集数据统计信息以及修补管道 Kubernetes 配置的参数。
enable_stats
enable_stats 参数顾名思义，用于启用管道统计日志记录。默认情况下，该参数是禁用的。为了调试，建议将此参数设置为true。启用统计数据收集后，统计信息将保存在 stats 文件夹中，且无法禁用统计数据收集。
以下代码展示了如何在 YAML 格式中定义 enable_stats 参数：
enable_stats: true
以下代码展示了如何在 JSON 格式中定义 enable_stats 参数：
"enable_stats": true,
接下来，我们将了解pod_patch。
pod_patch
pod_patch 参数使你能够重写管道 Pods 中的任何字段。这对许多场景有用，一个例子是将卷挂载到你的管道中。为了创建 pod_patch，你通常需要使用 JSON patch 构建器，将其转换为一行格式，并添加到管道规范中。
以下代码展示了如何在 YAML 格式中定义 pod_patch 参数：
pod_patch: '[{"op": "add","path": "spec/initContainers/0/resources/limits/my-volume"}]'
以下是相同内容的 JSON 格式：
"pod_patch": "[{\"op\": \"add\",\"path\": \"spec/initContainers/0/resources/limits/my-volume\"}]"
这就是你需要了解的所有服务参数。接下来的章节，我们将介绍一些使你能够配置输出分支并将管道结果写入外部存储的参数。
探索输出参数
输出参数使你能够配置处理后的数据在结果落入输出库后发生的事情。你可以设置它将数据放置在外部 S3 存储库中或配置出口。
s3_out
s3_out参数使您的 Pachyderm 管道能够将输出写入 S3 存储库，而不是标准的pfs/out。此参数需要一个布尔值。要访问输出存储库，您需要使用 S3 协议地址，如s3://<output-repo>。输出存储库仍将与您的管道名称同名。
以下代码展示了如何在 YAML 格式中定义s3_out参数：
s3_out: true
这里是如何在 JSON 格式中做同样的操作：
"s3_out": true
现在，让我们了解一下egress。
egress
egress参数使您能够指定输出数据的外部位置。Pachyderm 支持 Amazon S3（s3://协议）、Google Cloud Storage（gs://协议）和 Azure Blob Storage（wasb://协议）。
以下代码展示了如何在 YAML 格式中定义egress参数：
egress:
URL: gs://mystorage/mydir
这里是相同的示例，但使用的是 JSON 格式：
"egress": {
"URL": "gs://mystorage/mydir"
},
接下来，让我们了解如何在 Pachyderm 中配置输出分支。
output_branch
output_branch参数使您能够将结果写入输出存储库中的一个不同于默认master分支的分支。如果您希望创建一个实验或开发输出，而不希望下游管道拾取它，您可能需要这样做。
以下代码展示了如何在 YAML 格式中定义output_branch参数：
output_branch: test
以下代码展示了如何在 JSON 格式中定义output_branch参数：
"output_branch": "test",
本章概述了 Pachyderm 管道规范的内容。
总结
在本章中，我们了解了您可以在 Pachyderm 管道中指定的所有参数、如何优化管道以及如何配置转换部分。管道规范是您管道中最重要的配置属性，因为您将使用它来创建您的管道。如您所见，管道规范在性能优化方面提供了很大的灵活性。虽然一开始可能很难为您的数据类型找到合适的参数，但 Pachyderm 提供了许多微调选项，帮助您为您的机器学习工作流实现最佳性能。
在下一章中，您将学习如何在本地计算机上安装 Pachyderm。
深入阅读
要了解更多关于本章中所涵盖的主题，请查看以下资源：
-
Pachyderm 环境变量：
docs.pachyderm.com/latest/deploy-manage/deploy/environment-variables/ -
Kubernetes 概念：
kubernetes.io/docs/concepts/ -
Pachyderm 管道规范：
docs.pachyderm.com/latest/reference/pipeline_spec/
第二部分：开始使用 Pachyderm
本节将引导您完成在本地计算机或云环境中安装和配置 Pachyderm 的过程，并介绍如何创建您的第一个数据管道，随后解释如何配置端到端的机器学习工作流。
本节包含以下章节：
-
第四章，本地安装 Pachyderm
-
第五章，在云平台上安装 Pachyderm
-
第六章，创建您的第一个数据管道
-
第七章，Pachyderm 操作
-
第八章，创建端到端的机器学习工作流
-
第九章，使用 Pachyderm 进行分布式超参数调优
第四章：第四章：本地安装 Pachyderm
在前几章中，我们了解了 Pachyderm 的架构、Pachyderm 解决方案的内部工作原理，以及版本控制原语，如仓库、分支和提交。我们回顾了为什么可重复性至关重要，以及它为何应成为成功的数据科学流程的一部分。我们还学习了如何在 macOS、Linux 和 Windows 三大平台上进行操作。
有许多方式和平台可以让你使用 Pachyderm 运行端到端的 机器学习（ML）工作流。我们将从最常见和最容易配置的本地部署方法开始，然后在接下来的章节中回顾在云平台上的部署过程。
本章将引导你完成在本地安装 Pachyderm 的过程，让你能够快速开始并测试 Pachyderm。本章将为你运行第一个 pipeline 做好准备。我们将概述系统要求，并指导你安装运行 Pachyderm 所需的所有前置软件。
本章将涵盖以下主要主题：
-
安装所需工具
-
安装 minikube
-
安装 Docker Desktop
-
安装 Pachyderm 命令行界面（CLI）
-
启用 Pachyderm 的自动补全功能
-
准备 Kubernetes 环境
-
部署 Pachyderm
-
访问 Pachyderm 仪表盘
-
删除现有的 Pachyderm 部署
技术要求
无论你使用的是 macOS、Windows 还是 Linux，都需要安装以下工具：
-
Homebrew
-
Kubernetes 的
kubectl -
Helm
-
minikube
-
Docker Desktop（作为 minikube 的替代方案）
-
Pachyderm CLI；即通过
pachctl -
Windows 子系统 for Linux（WSL）用于 Windows 安装
我们将在本章中详细讲解安装和配置这些工具的具体步骤。如果你已经知道如何操作，可以立即开始设置。
安装所需工具
在本节中，我们将介绍如何安装我们将用于准备环境的系统工具，然后再安装 Pachyderm。
安装 Homebrew（仅限 macOS）
尽管 Linux 发行版有许多包管理选项，但 macOS 用户没有默认的包管理器。brew 填补了这个空白，提供了一种很好的解决方案，可以在 macOS 终端和 Linux shell 中轻松安装和管理软件，作为 Linux 发行版中可用的 apt、yum 或 flatpak 的替代方案。
Homebrew 使用 /user/local/Cellar 目录。你常常会听到的另一个术语是 Tap。Tap 是一个 Formulae 的 Git 仓库。
在本章中，我们将经常使用 brew 来安装 macOS 上的各种软件包。因此，如果你使用的是 macOS，则需要先安装它。我们将在本章中使用的相同 brew 命令也可以在 Linux 上运行，但我们会将 Linux 上的 brew 使用保留为可选项：
-
执行以下命令以在你的计算机上安装 Homebrew：
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -
执行以下命令以验证 Homebrew 是否已安装，并列出可用的命令：
$ brew commands
以下屏幕截图显示了系统的输出：
图 4.1 – brew 命令列表
-
让我们了解一些你将来可能需要的有用 Homebrew 命令。你可以通过执行以下命令更新 Homebrew 本身：
$ brew update -
执行以下命令查找任何过时的配方：
$ brew outdated -
执行以下命令以升级所有过时的配方：
$ brew upgrade
现在你已经在计算机上安装了 Homebrew 包管理器，接下来我们来安装 kubectl。
安装 Windows 子系统 Linux（仅限 Windows）
WSL 是一个工具，它使 Windows 用户能够在 Windows 中原生运行 Linux 命令和实用程序。如果你使用的是 Windows，可以通过以下步骤在机器上安装 WSL：
-
打开 PowerShell 或 Windows 命令提示符。
-
通过运行以下命令安装 WSL：
wsl --install重要说明
如果你使用的是 Windows，请从 WSL 运行本书中描述的所有 Linux 和 Pachyderm 命令。
有关更多信息，请参见官方微软 Windows 文档：https://docs.microsoft.com/en-us/windows/wsl/install。
安装 Kubernetes 命令行工具
在创建第一个 Kubernetes 集群之前，你需要安装 Kubernetes 命令行工具 kubectl，以便执行对集群的命令。现在，让我们了解如何在计算机上安装 kubectl。
有关更多信息，请参见官方 Kubernetes 文档：https://kubernetes.io/docs/home/。
按照以下步骤操作：
- 执行以下命令以在你的计算机上下载并安装
kubectl：
如果你正在使用 Linux，请运行以下命令：
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ chmod +x ./kubectl && sudo mv ./kubectl /usr/local/bin/kubectl
如果你使用的是 macOS（Intel），请运行以下命令：
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
$ chmod +x ./kubectl && sudo mv ./kubectl /usr/local/bin/kubectl
如果你使用的是 Windows，以下命令将完成此操作：
curl -LO https://dl.k8s.io/release/v1.22.0/bin/windows/amd64/kubectl.exe
-
通过执行以下命令验证你正在使用的版本，并确保已安装
kubectl：$ kubectl version --short --client
这是系统输出的示例：
Client Version: v1.22.3
为了能够执行以下命令，kubectl 的版本必须为 v1.19 或更高版本。
现在你已在计算机上安装了 kubectl，可以对你的 Kubernetes 集群执行命令，接下来我们来安装 Helm。
安装 Helm v3
Helm 是 Kubernetes 集群的流行包管理器。在使用其 Helm 图表部署 Pachyderm 之前，你需要在环境中安装 Helm 二进制文件，以便能够管理 Helm 图表的生命周期。请按照以下步骤在你的计算机上安装 Helm：
-
执行以下命令以下载并在计算机上安装 Helm：
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/ helm/helm/master/scripts/get-helm-3 $ chmod 700 get_helm.sh $ ./get_helm.sh -
通过执行以下命令验证你正在使用的版本，并确保已安装 Helm：
$ helm version --short
这是系统输出的示例：
V3.7.1+g1d11fcb
接下来，在你部署 Pachyderm 之前，你必须安装必要的工具来准备本地 Kubernetes 集群环境。如果你熟悉 Linux 中的容器，你应该对这些工具也很熟悉。如果你使用 Linux 作为本地计算机，请按照 安装 minikube 部分提供的说明来准备环境。如果你使用的是 macOS，请按照 安装 Docker Desktop 部分提供的说明进行操作。由于简单易用，推荐使用 Docker Desktop。
安装 minikube
Minikube 是一个流行的跨平台且轻量级的 Kubernetes 实现，它帮助用户快速创建单节点的本地 Kubernetes 集群。minikube 支持多种运行时，包括 CRI-O、container 和 Docker。它可以作为 虚拟机（VM）、容器或裸机部署。由于 Pachyderm 仅支持 Docker 运行时，我们将介绍如何使用 Docker 容器运行时并将其部署为容器。有关更多配置细节，你可以参考官方 Docker 文档 minikube.sigs.k8s.io/docs/start/。现在让我们安装最新版本的 minikube：
- 执行以下命令，在你的计算机上安装
minikube。
如果你正在使用 Linux，请运行以下命令：
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ sudo install minikube-linux-amd64 /usr/local/bin/minikube
如果你使用的是 Windows（需要 Chocolatey 包管理器），请运行以下命令：
choco install minikube
-
通过执行以下命令，验证你正在使用的
minikube版本，并确保已安装 minikube：$ minikube version
以下是命令响应的示例：
minikube version: v1.22.0
commit: a03fbcf166e6f74ef224d4a63be4277d017bb62e
现在你已经安装了 minikube，接下来让我们安装 Docker Desktop。
安装 Docker Desktop
Docker 通过将应用程序与基础设施及其依赖关系分离，简化了应用程序的开发、交付和运行。Pachyderm 仅支持 Docker 容器运行时；因此，在部署 Pachyderm 之前必须安装 Docker 工具。
Docker 作为原生应用程序运行，使用 macOS 沙盒安全模型，并在你的 macOS 上安装所有 Docker 工具，包括 Docker 引擎、CLI、Docker Compose、Credential Helper、Notary 和 Kubernetes。
如果你还没有安装 Docker Desktop，可以按照下一节提供的说明进行安装。否则，你可以跳到 准备 Kubernetes 环境 部分。你还可以参考官方 Docker 文档 docs.docker.com/get-docker/。
为 macOS 安装 Docker Desktop
按照以下步骤在 macOS 上安装 Docker Desktop。Docker 的最新版本支持 macOS 的最后三个版本。如果你的 macOS 版本比最新三个版本更旧，你需要将其升级到最新版本的 macOS：
-
访问 Docker Hub 下载链接
hub.docker.com/editions/community/docker-ce-desktop-mac/下载 Docker Desktop 安装程序。 -
点击
Docker.dmg文件以在工作站上安装。 -
下载完成后，双击
Docker.dmg文件以打开镜像，并将 Docker 图标从窗口拖动到应用程序文件夹完成安装：
图 4.2 – macOS 上的 Docker Desktop 安装界面
-
在应用程序文件夹中，双击 Docker 图标以启动 Docker Desktop。
-
确认你拥有安装 Docker 组件的权限。
-
如果你是第一次使用 Docker，请按照快速教程操作。否则，点击跳过教程以启动 Docker：
图 4.3 – Docker Desktop 图形用户界面
在 Windows 上安装 Docker Desktop
按照以下步骤在 Windows 计算机上安装 Docker Desktop：
-
访问 https://docs.docker.com/desktop/windows/install/。
-
点击Docker Desktop for Windows。
-
点击Docker Desktop Installer.exe。
-
按照互动提示安装Docker Desktop。
-
在配置页面，确保选择为 WSL 2 安装所需的 Windows 组件。
-
完成后，点击关闭。
-
通过在 Windows 搜索中找到 Docker Desktop 并接受条款与条件，启动 Docker Desktop。之后，Docker 将自动启动。
现在你已经在机器上安装了 Docker Desktop，让我们安装 Pachyderm CLI，称为 pachctl。
安装 Pachyderm 命令行界面
Pachyderm 的 pachctl 用于部署和与 Pachyderm 集群交互。按照以下步骤安装 pachctl：
-
获取
pachctl的最新版本标签，并将其保存在一个名为PACHYDERMVERSION的变量中：$ PACHYDERMVERSION=$(curl --silent "https://api.github.com/repos/pachyderm/pachyderm/releases/latest" | grep '"tag_name":' | \ sed -E 's/.*"v([^"]+)".*/\1/') -
执行以下命令在计算机上安装
pachctl。
如果你使用的是 macOS，请运行以下命令：
$ brew tap pachyderm/tap && brew install pachyderm/tap/pachctl@${PACHYDERMVERSION}
如果你使用的是 Debian Linux 或 Windows 10 上的 WSL，请运行以下命令：
$ curl -o /tmp/pachctl.deb -L https://github.com/pachyderm/pachyderm/releases/download/v${PACHYDERMVERSION}/pachctl_${PACHYDERMVERSION}_amd64.deb && sudo dpkg -i /tmp/pachctl.deb
-
执行以下命令来验证是否已安装
pachctl：$ pachctl version --client-only
以下是系统输出的示例：
COMPONENT VERSION
pachctl 2.0.1
至此，你已安装了运行 Pachyderm 所需的先决条件。现在，让我们准备集群并在本地 Kubernetes 集群上部署 Pachyderm。
启用 Pachyderm 的自动补全
自动补全是 Unix shell 提供的一项功能，通过命令行界面（CLI）自动填写参数。根据系统中使用的 shell 类型，自动补全功能会在你输入命令时，建议或自动补全部分输入的命令，有时按下Tab键即可。Pachyderm 支持 Bourne Again Shell（bash）和 Z shell（zsh，一种扩展的 Bourne shell）的自动补全功能。bash 和 zsh 是 macOS 和 Linux 上最常用的 Unix 命令行解释器。在本节中，你将学习如何启用 Pachyderm 的自动补全功能，以及 pachctl 命令支持的参数。
如果你不知道自己使用的是哪种 shell，请键入以下命令查看：
$ echo "$SHELL"
如果你使用的是 bash，则前面命令的输出应如下所示：
/bin/bash
如果你使用的是 zsh，则前面命令的输出应如下所示：
/bin/zsh
既然我们已经知道使用的是哪种 shell，接下来可以安装 Pachyderm 自动补全。
启用 bash 的 Pachyderm 自动补全
按照以下步骤在你的计算机上启用 Pachyderm 自动补全：
- 执行以下命令以启用
bash-completion。
如果你使用的是带有 Homebrew 的 macOS 或 Linux，请使用以下命令：
$ brew install bash-completion
如果你使用的是 Ubuntu Linux，请使用以下命令：
$ sudo apt install bash-completion
如果你使用的是 RHEL 或 CentOS Linux，请使用以下命令：
$ sudo yum install bash-completion bash-completion-extras
- 执行以下命令以验证
bash-completion是否已在你的计算机上启用。
如果你使用的是 macOS，请运行以下命令：
$ brew info bash-completion
如果你使用的是 Linux，请运行以下命令：
$ complete -p
- 确认
bash-completion的路径指向正确的目录。然后，执行以下任一命令以启用 Pachydermpachctl自动补全：
如果你使用的是 macOS，请运行以下命令：
$ pachctl completion bash --install --path /usr/local/etc/bash_completion.d/pachctl
如果你使用的是 Linux，请运行以下命令：
$ pachctl completion bash --install --path /usr/share/bash-completion/completions/pachctl
到此为止，Pachyderm 的命令行自动补全已经在你的 bash shell 中启用。
启用 zsh 的 Pachyderm 自动补全
zsh 和 macOS Catalina。按照以下步骤在你的计算机上启用 Pachyderm 自动补全：
重要提示
如果你不希望启用自动补全，你可以尝试使用 pachctl shell。要启用此功能，请键入 pachctl shell。
- 执行以下命令以启用
zsh自动补全。
如果你使用的是带有 Homebrew 的 macOS 或 Linux，请使用以下命令：
$ brew install zsh-completion
如果你在 Linux 上，访问 github.com/zsh-users/zsh-completions 页面，并根据你的 Linux 发行版按照说明启用 zsh 补全。例如，对于 Ubuntu 19.10，应该如下所示：
$ echo 'deb http://download.opensuse.org/repositories/shells:/zsh-users:/zsh-completions/xUbuntu_19.10/ /' | sudo tee /etc/apt/sources.list.d/shells:zsh-users:zsh-completions.list
$ curl -fsSL https://download.opensuse.org/repositories/shells:zsh-users:zsh-completions/xUbuntu_19.10/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/shells_zsh-users_zsh-completions.gpg > /dev/null
$ sudo apt update && sudo apt install zsh-completions
- 执行以下命令以验证
zsh自动补全是否已在你的计算机上启用。
如果你使用的是 macOS，请运行以下命令：
$ brew info zsh-completions
如果你使用的是 Linux，请运行以下命令：
$ complete -p
- 确认
zsh自动补全的路径指向正确的目录。然后，执行以下任一命令以启用 Pachydermpachctl自动补全。
在 macOS 上，运行以下命令：
$ pachctl completion zsh --install --path /usr/local/share/zsh-completions/_pachctl
如果你使用的是 Linux，请运行以下命令：
$ pachctl completion zsh --install --path /home/linuxbrew/.linuxbrew/share/zsh-completions/_pachctl
到此为止，Pachyderm 命令行自动补全现在已在你的 zsh shell 中启用。接下来，我们来准备 Kubernetes 环境。
准备 Kubernetes 环境
在本节中，你将使用在 安装所需工具 部分中部署的首选工具来配置 Kubernetes 集群。
在 Docker Desktop 上启用 Kubernetes
如果你使用 Docker Desktop 作为容器平台来部署 Kubernetes 集群，可以按照以下步骤启用 Kubernetes：
-
打开 Docker 用户界面。
-
在 Docker UI 的右上角，点击 设置 图标。
-
切换到 Kubernetes 设置面板，并点击 启用 Kubernetes 按钮，以在 Docker Desktop 上启动单节点 Kubernetes 集群。通过点击 应用并重启 按钮来应用这些设置：
图 4.4 – 在 Docker Desktop 中启用 Kubernetes
-
打开终端窗口并通过执行以下命令确认 Kubernetes 是否正在运行：
$ kubectl get node
以下是系统响应的示例：
NAME STATUS ROLES AGE VERSION
docker-desktop Ready control-plane,master 7m9s v1.21.5
至此，你已经在 Docker Desktop 上配置了单节点 Kubernetes 集群。现在，我们准备在本地 Kubernetes 环境中部署 Pachyderm。
使用 minikube 启用 Kubernetes
按照以下步骤在使用 minikube 时本地运行 Kubernetes：
-
将 Docker 设置为
minikube的默认驱动程序：$ minikube config set driver docker -
启动 Kubernetes 集群：
$ minikube start -
执行以下命令以验证你的 Kubernetes 集群是否准备好：
$ kubectl get node NAME STATUS ROLES AGE VERSION minikube Ready control-plane,master 29m v1.20.2
至此，你的 Kubernetes 集群已经使用 minikube 配置完成。现在，我们准备在本地 Kubernetes 环境中部署 Pachyderm。
部署 Pachyderm
在生产环境中运行 Pachyderm 时，建议在可以扩展资源以满足较大流水线计算需求的环境中启动。Pachyderm 可以安装在任何 Kubernetes 集群上，包括 AWS、Google Cloud、Microsoft Azure、IBM Cloud 和 OpenShift 提供的托管 Kubernetes 服务，也可以在本地工作站上安装。在本节中，我们将重点介绍一个较小的测试部署，因此，本地集群足以开始。
Pachyderm 提供了示例 Helm 图表，帮助你将 Pachyderm 部署到所有主要云平台。你可以在 第二章 中了解更多关于 Helm 图表的信息，Pachyderm 基础。由于 Helm 图表是灵活的，你可以选择要安装的组件。例如，你可以安装名为控制台的 Pachyderm 浏览器界面。
Pachyderm 控制台是 Pachyderm 的用户界面，并通过 直接有向图（DAG）提供对你的流水线的鸟瞰图，以及其他有用的功能。
一些组件，如 Pachyderm 控制台，要求企业版许可证，但也可以通过免费试用许可证进行测试，试用期为 30 天。你可以在 www.pachyderm.com/trial/ 请求免费试用许可证。
按照以下步骤在本地 Kubernetes 集群中安装 Pachyderm：
-
部署 Pachyderm 包括多个资源。
helm命令帮助管理复杂 Kubernetes 应用的生命周期，并通过一个命令同时创建所有必要的组件。你可以在第五章中了解更多关于 Helm charts 的选项，在云平台上安装 Pachyderm。现在，让我们执行以下命令将 Pachyderm Helm Chart 仓库添加到本地仓库：$ helm repo add pach https://helm.pachyderm.com -
执行以下命令从 Chart 仓库获取最新的 Chart 信息：
$ helm repo update -
执行以下命令将最新版本的 Pachyderm 部署到你的集群中，无需控制台：
$ helm install pachd pach/pachyderm --set deployTarget=LOCAL
如果你有企业密钥并希望通过 Pachyderm 的控制台用户界面进行部署，请创建一个名为 license.txt 的文件，并将你的企业令牌粘贴到该文件中。然后，运行以下命令：
$ helm install pachd pach/pachyderm --set deployTarget=LOCAL --set pachd.enterpriseLicenseKey=$(cat license.txt) --set console.enabled=true
一旦控制台成功部署，请按照访问 Pachyderm 控制台章节中的说明访问控制台。
前面的命令返回以下输出：
图 4.5 – Pachyderm Helm Chart 在 Kubernetes 上部署
-
你可以检查 Helm Chart 仓库中的
values.yaml文件（github.com/pachyderm/pachyderm/tree/master/etc/helm/pachyderm），了解通过部署该 Chart 创建的 Kubernetes 对象。Pachyderm Helm Chart 创建了 Kubernetes 服务账户、服务、部署、PostgreSQL 和 etcd 实例，所有这些都是运行 Pachyderm 所必需的。 -
Kubernetes 部署是一个控制器，它根据你在清单文件中定义的要求推出一组 Pods 的副本集。副本集是一组相同的服务实例。执行以下命令验证在安装过程中创建的部署状态：
$ kubectl get deployments
前面的命令输出应如下所示：
图 4.6 – Pachyderm 部署对象列表
-
执行以下命令验证安装是否成功，并查看作为部署一部分创建的 Pods：
$ kubectl get pods
前面的命令输出应如下所示：
图 4.7 – Pachyderm Pods 列表
-
执行以下命令连接到你的新 Pachyderm 实例：
pachctl config import-kube local –overwrite pachctl config set active-context local pachctl port-forward -
打开浏览器并访问
http://localhost:4000。 -
使用名为
admin的模拟用户进行身份验证，并使用password作为密码。 -
返回终端并启用身份验证：
pachctl auth activate
系统会提示你再次登录 UI。使用名为 admin 的模拟用户登录，并将 password 作为密码。
-
执行以下命令验证 Pachyderm 是否成功安装：
pachctl version
上述命令的输出应如下所示：
COMPONENT VERSION
pachctl 2.0.1
pachd 2.0.1
现在我们已经在集群中安装了 Pachyderm，可以开始创建我们的第一个管道了。
访问 Pachyderm Console
如果你已与 Pachyderm 集群一起安装了 Console，你可以在 UI 中访问它，并查看你的管道、仓库和其他 Pachyderm 对象。Pachyderm Console 提供 30 天的免费试用期。按照以下步骤访问 Pachyderm Console：
-
执行以下命令以验证企业激活的状态：
pachctl enterprise get-state
上述命令的输出应如下所示：
Pachyderm Enterprise token state: ACTIVE
Expiration: 2022-02-02 22:35:21 +0000 UTC
-
如果端口转发未运行，请执行以下命令启动它。此步骤将把 Pachyderm Console 服务的端口
4000转发到本地工作站的端口4000：pachctl port-forward -
在网页浏览器中，打开
localhost:4000。 -
在登录屏幕上使用默认凭据
admin和password，如下所示：
图 4.8 – Pachyderm Console 登录屏幕
- 点击 登录 访问 Pachyderm Console 后，点击 查看项目 按钮以查看你的仓库和管道：
图 4.9 – Pachyderm 仪表板
因为我们尚未创建任何 Pachyderm 对象，所以此页面为空。
现在你已经学会了如何访问 Pachyderm Console，准备好在 Pachyderm 中创建第一个管道了。
删除现有的 Pachyderm 部署
仅当你想删除集群时才执行此部分的步骤。如果你想继续在其他章节中的示例上工作，请跳过此部分。
如果你需要删除部署并重新开始，你需要清除环境并从 准备 Kubernetes 环境 部分提供的步骤重新开始。当你删除现有的 Pachyderm 部署时，所有组件（除了 Helm 仓库和 pachctl）都会从你的机器中移除。
按照以下步骤删除现有的 Pachyderm 部署：
-
如果你为 Helm 实例使用了不同的名称，请执行以下命令查找你通过 Helm 图表部署的 Pachyderm 实例名称：
$ helm ls | grep pachyderm
上述命令的输出应如下所示：
pachd default 1 2021-11-08 21:33:44 deployed Pachyderm-2.0.1 2.0.1
-
使用你的 Pachyderm 实例名称执行以下命令，从集群中删除 Pachyderm 组件：
$ helm uninstall pachd -
如果你使用的是 minikube，请删除整个 Kubernetes 集群并重新部署，然后再重新部署 Pachyderm：
$ minikube stop $ minikube delete
至此，你已完全从计算机中移除了 Pachyderm 和本地 Kubernetes 集群。
总结
在本章中，我们了解了在本地计算机上为测试目的安装和运行 Pachyderm 所需的软件先决条件。
我们了解了 minikube 和 Docker Desktop 的基本知识，并学习了如何在本地机器上安装它们。我们还学习了如何安装 Pachyderm CLI 并在不同操作系统上启用自动补全功能。
然后，我们在系统上安装了 Helm 和 Pachyderm Helm 仓库。我们了解了 Helm Charts 以及如何获取免费的 Pachyderm 试用许可证。
我们使用基于桌面操作系统的最流行选项部署了一个单节点、本地 Kubernetes 集群。最后，我们部署了 Pachyderm，并学习了如何访问 Pachyderm 控制台。
我们还学习了如何在三大主要平台上进行操作——macOS、Linux 和 Windows。
在下一章节中，我们将学习如何通过云端安装 Pachyderm，并解释在生产环境中运行 Pachyderm 集群所需的软件要求。我们还将了解 Pachyderm Hub，即 软件即服务（SaaS）版本的 Pachyderm，适用于测试和生产环境。
进一步阅读
请参考以下链接，了解本章中涉及的主题：
-
官方 Homebrew 文档：
docs.brew.sh/ -
Kubectl 备忘单：
kubernetes.io/docs/reference/kubectl/cheatsheet/ -
Minikube 手册：
minikube.sigs.k8s.io/docs/handbook/ -
官方 Docker Desktop 文档：https://docs.docker.com/desktop/
-
生产环境中的 Kubernetes 最佳实践：
www.packtpub.com/product/kubernetes-in-production-best-practices/9781800202450 -
Kubernetes 和 Docker – 企业指南：
www.packtpub.com/product/kubernetes-and-docker-an-enterprise-guide/9781839213403 -
官方 Pachyderm pachctl 参考指南：
docs.pachyderm.com/latest/reference/pachctl/pachctl/
扫一扫
2544
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
