上一节我们介绍了云计算的基本概念本节中我们来看看其核心的三种服务模式。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_1.png以下是三种主要的云服务模式基础设施即服务提供虚拟化的计算资源如服务器、存储和网络。经典的例子是亚马逊的EC2计算引擎和S3存储服务。平台即服务提供一个平台让开发者可以构建、运行和管理应用程序而无需处理底层基础设施。例如微软的Azure最初就是以此模式起步的。软件即服务通过互联网提供完整的应用程序。例如微软的Office 365。随着服务模式从基础设施向软件演进服务变得更加具体、面向特定领域和任务同时也能引入更多的自动化功能。过去十年间行业的发展正是不断充实这一设计空间的过程。云计算的巨大成功了解了服务模式后我们来看看云计算在实际应用中的巨大成功。云计算的增长是爆炸性的。例如亚马逊全球网站的带宽消耗呈现稳定增长而亚马逊网络服务的带宽消耗则呈爆炸式增长。同样S3中存储的对象数量也经历了指数级增长。这些数据都清晰地展示了云计算的普及和成功。云计算对研究的优势云计算的成功不仅体现在商业领域对于科学研究尤其是数据科学它带来了独特的优势。以下是云计算为研究工作带来的几个关键优势突发性计算能力历史上首次使用1000个处理器运行一天的成本与使用1个处理器运行1000天的成本相同甚至更低。这使得研究人员可以在实验结束后关闭所有资源极大地提高了资源利用的灵活性。支持可重复性研究者可以访问完全相同的工具、数据和计算环境从而让他人能够精确复现实验过程。便于共享与协作将工作环境开放给外部访问通常只需在软件中进行简单设置无需物理移动数据或代码。消除跨部门冗余基础设施无论是在不同大学之间还是在公司内部的不同部门如市场部和分析部集中化的云平台都可以避免重复建设计算集群将资源共享提升到软件操作的层面。对于稳态的数据处理任务云计算的成本优势可能不明显。但对于实验性工作、数据科学和科学研究而言这种突发性计算能力的模式非常适用。公共云与私有云最后我们来谈谈云计算的部署模式。实现上述优势可以通过我们讨论的公共云或者通过某种形式的私有云。在这些情况下集中化程度越高越好因为它能将资源共享从物理硬件层面提升到软件操作层面。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_3.png本节课中我们一起学习了云计算的三种服务模式IaaS PaaS SaaS见证了其巨大的商业成功并重点探讨了它为科学研究带来的核心优势特别是突发计算能力、可重复性以及便捷的协作共享这些特性使其成为现代数据科学不可或缺的工具。106虚拟化对可重复性的优势https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_1.png在本节课中我们将探讨虚拟化技术如虚拟机和容器如何为数据科学工作流中的可重复性问题提供强大的解决方案。我们将分析数据科学实验的“混乱”现实并理解为什么捕获整个计算环境至关重要。上一节我们讨论了数据科学中可重复性面临的挑战本节中我们来看看虚拟化技术如何提供一种优雅的解决方案。数据科学实验的现实数据科学实验常常发生在受控、受监控的环境之外。总会有一些实验和数据存在于某种便于实现可重复性的、受管理的受保护环境之外。以下是数据科学工作流的典型特点自由实验能够随时打开文本编辑器从头开始编写代码并尝试新想法这是软件和数据科学的一个重要特性不应轻易破坏。流程模糊调试、测试和实验之间的界限非常模糊。同一段代码当它成功时是“实验”当它失败时是“调试”。环境异构实验依赖于复杂的、相互关联的网络包括数据库、外部系统、可视化库及其各自的依赖项。因此我们需要一种能够事后捕获实验环境的方法并且这种方法必须能够容忍数据科学实验混乱、异构的现实。虚拟化的核心优势虚拟化技术虚拟机和容器的核心优势在于它们允许我们捕获并复制整个计算环境。我的卡通版理解是你开发了一个回答特定统计问题的工作流管道并想把它交给你的老板。你不仅可以移交代码还能连同其所有依赖一起打包。代码依赖于某个数据库、某个外部系统、某个可视化库而它们各自又有一系列复杂的库和依赖网络。除了获取整个环境没有更好的切割点。这正是虚拟化和容器所提供的。核心概念通过虚拟化可复现的环境可以打包为一个文件如Dockerfile或虚拟机镜像并通过简单的命令如docker build和docker run来重建。# 示例 Dockerfile FROM python:3.9-slim COPY requirements.txt . RUN pip install -r requirements.txt COPY my_analysis_script.py . CMD [python, ./my_analysis_script.py]责任划分问题在传统湿实验室如化学、生物学中可重复性依赖于研究者对实验步骤的描述由他人在自己的环境中复现。这里存在一个责任划分的问题在多大程度上复现者需要自己填补环境配置的空白随着计算科学的普及这个问题变得更加尖锐。想复现你计算生物学实验的生物学家可能不具备操作你提供的软件、以同样方式设置环境的技能。以下是复现者可能面临的挑战列表能否在系统级、R 或 Python 环境中安装软件包能否编译代码以使用你所依赖的快速 C 库能否解决出现的依赖问题如果涉及数据库能否编写 DDL 语句来建立与你相同的模式能否配置运行这些 DDL 语句所需的数据库服务器能否解决文件权限等问题如果对这些问题的答案是“否”那么即使你提供了“潜在可行”的方法也可能并未真正实现“易于复现”。虚拟化方法有助于解决这种责任划分问题它明确表示“这就是我所做的一切你只需运行这些命令就能获得完全相同的环境。”https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_4.png本节课中我们一起学习了虚拟化技术如何应对数据科学中的可重复性挑战。我们认识到数据科学自由、模糊的工作特性需要一种能够事后捕获完整环境的方法。虚拟机和容器通过打包整个计算环境提供了一种清晰、可靠且能明确责任划分的解决方案使得复现实验变得像执行几条命令一样简单。107复杂虚拟化场景 ️https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa624356e363ef66a52b89166957a153_1.png在本节课中我们将探讨在数据密集型科学实验中如何超越单一虚拟机的限制实现复杂、多组件环境的可复现性。我们将理解为何简单的“代码数据”打包方式已不足以应对现代大规模数据分析的需求。从单一虚拟机到复杂环境上一节我们介绍了将代码、数据、环境和运行平台打包在一起的基本理念。本节中我们来看看当实验架构变得复杂时这种单一虚拟机的方案为何会失效。随着数据集变得越来越大建议他人仅仅为了复现你的实验就去下载数百TB的数据例如300TB的MRI图像变得越来越不切实际。因此你需要提供的远不止代码本身。你需要提供一个可以运行的环境以及对其所依赖数据的访问权限。在商业环境中你可能可以假设大家共享访问一个通用的基础设施资源。例如你可以说“这是我的Python脚本它调用了共享环境中的各种东西但不用担心因为你也能访问同一个共享环境”。在这种情况下实现可复现性的门槛对你来说就降低了。然而如果你需要跨越机构边界进行共享公共云在我看来就成为了唯一可行的选择。当然在公司内部情况可能有所不同。多组件协调架构正如我们之前提到的有些架构尤其是围绕数据密集型实验的架构需要多种不同类型的资源协调一致地共同工作。以下是这类架构中常见的组件应用服务器负责运行业务逻辑。数据库服务器存储和管理结构化数据。安装有Hadoop等工具的集群用于处理大规模数据。因此一个虚拟机通常是不够的。一个科学案例环境观测与预报系统为了具体说明这一点我们来看一个来自科学领域的例子这个例子与我之前提到的“海洋设备”案例大约处于同一时期。这是一个环境观测与预报系统它被设置为运行每日预报。其工作流程非常复杂涉及多个步骤和外部依赖。以下是该系统的工作流程与组件数据输入系统整合来自多方的数据包括本机构管理的传感器、他人管理的传感器、卫星图像以及其他机构运行的大尺度、低分辨率模型例如覆盖地球西半球的模型的输出。数据处理与存储这些预报输入数据被存入一个大型文件系统同时用一个关系型数据库来管理元数据。模型执行一系列由Perl脚本、配置脚本和其他遗留管理基础设施组成的系统会启动Fortran模型。这些模型是海洋学现场模型用于模拟水体的运动并观察其变化。结果后处理模型运行结果输出后会触发另一系列脚本从结果中提取统计数据、生成可视化图表并将这些可视化结果发布到网络上。整个基础设施提供了一个在许多情况下都可复现的实验。但要想象将这一切都塞进一个虚拟机里是行不通的。数字产物的多样性在这样的复杂实验中会产生多种数字产物远不止最终结果。以下是一些关键的数字产物类型模拟结果本身模型运行产生的核心数据。配置与日志文件记录运行环境和过程的文件。注释数据产品对原始数据进行标注和解释后生成的数据。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa624356e363ef66a52b89166957a153_3.png本节课中我们一起学习了复杂虚拟化场景的挑战。我们认识到对于依赖多种资源如专用服务器、数据库、集群和外部数据源的现代数据科学工作流单一虚拟机的封装方式已不再适用。通过一个环境预报系统的具体案例我们看到了一个可复现实验如何由多个协调工作的组件构成并产生了多样化的数字产物。这为理解更高级的虚拟化和容器化技术如Docker Compose、Kubernetes的必要性奠定了基础。108共享实验室https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_1.png概述在本节课中我们将探讨数据科学协作中的一个核心挑战如何快速建立共享、可复现的开发环境。我们将了解传统协作方式的痛点并学习如何利用现代云基础设施和“基础设施即代码”的理念来解决这些问题。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_3.png共享开发环境的挑战与解决方案问题的普遍性这个问题已被广泛观察到。在数据科学项目中跨团队或跨机构协作时经常需要共享代码、数据和计算环境。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_5.png解决方案基础设施即代码上一节我们提到了协作的挑战本节中我们来看看一种核心解决方案基础设施即代码。其核心思想是使用脚本或配置文件来定义和启动整个计算基础设施。亚马逊的CloudFormation是此类解决方案之一。它允许你通过脚本启动和配置一组协调工作的虚拟机集群这些虚拟机作为一个单元被部署并扮演不同的角色。公式/代码示例基础设施即代码# 一个简化的 CloudFormation 模板示例用于定义资源Resources:MyEC2Instance:Type:AWS::EC2::InstanceProperties:InstanceType:t2.microImageId:ami-0abcdef1234567890同类工具在 DevOps 环境中也有像Chef这样的工具可以实现类似功能。它们都致力于将基础设施作为代码来管理。以下是此类工具的核心价值你可以编写脚本来启动、设置和操作基础设施。共享这些脚本如 Chef 脚本能为他人提供相同的能力使其能够启动一个大型、复杂、异构的架构来运行实验。这些问题正在被解决而涌现出的解决方案如 Chef通常与公有云、商业云服务紧密耦合。云环境开发者的“Google Docs”协作的本质需求数据科学本质上是一项协作性工作而可复现性是协作的一部分。同时协作也意味着当我们需要尝试一个大胆的想法或者需要与另一个部门具有类似专业知识的同事合作时能有一个高效的共同工作空间。传统协作方式的瓶颈当两个人需要一起工作时启动一个双方都能访问的“Google 文档”非常有意义但这仅限于文档工作。如果你们需要一起进行一些共享开发就需要一个共享的开发环境。我们在大学环境中观察到现在几乎每个项目本质上都是协作的经常需要跨越机构边界一起工作。一个临时的、不受任何特定系统管理员管辖的共享开发环境变得非常重要。一个具体案例例如在跨机构协作时我们曾经需要等待两周让对方的系统管理员在我们的机器上提供账户或者让我们的系统管理员在他们的机器上提供账户。我们当时觉得这很荒谬。于是我们转而启动了一个共享虚拟机为所有人提供访问权限让大家可以并肩工作完成后便将其关闭、拆除。这是一个极佳的解决方案。共享环境的优势这不仅降低了协作的摩擦更重要的是解决了沟通效率问题。你不再需要通过电子邮件互相发送错误信息并试图描述问题以便对方在自己的环境中复现。你可以直接说“运行这个命令你就会看到错误信息。”因为你们访问的是完全相同的环境。我们不可能轻易地互相访问对方私有的内部环境至少在没有让系统管理员相当不满的情况下是不可能的。正如这里总结的没有“无法复现”的漏洞。因为如果我看到了问题那么你也能看到同样的问题。我们放弃了等待两周建立凭证转而启动了一个 EC2 实例在一小时内就开始了工作。我认为这在部门环境或商业环境中也同样适用。即使由于某些原因你使用的云不一定是公有云一个能够支持启动新虚拟机、允许不同人员访问、并在完成后可拆除的共享环境仍然是支持协作性、可复现数据科学的一个非常有用的方面。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_7.png总结本节课中我们一起学习了数据科学协作中关于环境共享的核心挑战。我们探讨了“基础设施即代码”的理念及其工具如 AWS CloudFormation 和 Chef它们通过脚本化方式管理复杂环境。更重要的是我们认识到云平台能够提供类似“Google Docs”的共享开发环境这种环境极大地提升了协作效率消除了“环境不一致”导致的沟通障碍使得跨团队、跨机构的协同数据科学工作变得更加流畅和可复现。109协作与可复现性中的成本与规模经济https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_1.png在本节课中我们将探讨在协作、可复现的数据科学工作中成本如何产生以及如何分担。我们还将分析为何大型公共云服务商能够提供更经济的解决方案。成本分担谁为可复现性付费在协作和可复现的数据科学背景下一个核心问题是谁为可复现性付费当处理数百TB数据或运行复杂计算模型时成本会显著增加。这些成本并非免费主要包括代码托管、数据托管和代码执行三个方面。以下是各项成本的分担方式代码托管成本这部分成本通常由代码提供者你承担。你需要将代码托管在某个地方如GitHub、GitLab或内部服务器并确保组织内外的协作者能够访问。这部分费用相对较低。数据托管成本这部分成本传统上由数据所有者他们承担。在科研或商业环境中公开托管大规模数据以供他人复现研究曾因高昂的存储和带宽费用而难以实现。代码执行成本在云环境中这部分成本总是由代码执行者他们承担。他们使用自己的云账户启动计算实例来运行你的代码你无需为此付费。上一节我们讨论了成本的基本分担原则本节中我们来看看云服务商如何改变了数据托管的经济模型。云服务如何改变数据托管经济云服务特别是亚马逊AWS等提供商正在通过创新的商业模式解决数据托管的成本难题。以下是关键机制转移带宽成本数据提供者可以配置数据集使得数据流出egress产生的网络带宽费用由数据消费者支付而非提供者。公共数据集计划对于使用率高且愿意公开的数据集云服务商如AWS可能会提供免费托管。其商业逻辑在于用户为了使用这些数据会在该云平台上启动EC2实例并购买其他付费服务从而为云商带来收入。内部成本核算即使在公司内部使用私有云或公有云环境也能清晰地将计算资源成本分配给实际使用的部门如市场部避免了因预算归属问题阻碍协作。然而如果托管了海量数据却无人使用存储账单仍需有人支付这仍然是一个待解决的挑战。但值得注意的是即使不公开数据长期存储海量数据本身也是一个成本难题。规模经济为何云服务更便宜你可能会问为什么公共商业云这类高度集中的服务能够节省成本它们为何更便宜答案是规模经济。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_3.png下图展示了一份2009年的早期报告揭示了超大规模数据中心在几个关键方面的规模经济效益。虽然具体数字在今天2015年录制时已发生巨大变化但其揭示的原理依然成立。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_5.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_5.png报告主要对比了网络、存储和管理三个类别网络小型数据中心的网络成本约为$95 / (Mbps·月)而超大规模数据中心的成本可低至$13 / (Mbps·月)成本比约为7.1。存储存储成本的比例约为5.7大规模集中采购和管理能显著降低单价。管理在传统数据中心约每140台服务器需要一名管理员。在超大规模数据中心一名管理员可以管理1000台甚至更多的服务器。随着自动化程度的提高这一比例还在持续上升。这些因规模效应产生的成本节约可以传递给用户。从长远来看试图通过维护众多小型服务器机房或集群来追赶这种效率是非常困难的。本节课中我们一起学习了在可复现数据科学工作中的成本分担模式以及云服务商如何通过商业模式创新如转移带宽成本、公共数据集计划来降低数据托管门槛。更重要的是我们探讨了其背后的根本驱动力——规模经济它使得超大规模数据中心在网络、存储和管理效率上远超小型部署从而能够为用户提供更具成本效益的服务。110为峰值负载配置资源https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_1.png概述在本节课中我们将探讨在数据科学和IT基础设施管理中如何为系统负载配置计算资源。我们将分析传统的“按峰值负载配置”方法的局限性并理解资源不足配置带来的隐性成本最终了解集中化云资源如何为解决此问题提供方案。传统配置逻辑瞄准峰值上一节我们讨论了资源管理的基本挑战本节中我们来看看一个常见的资源配置策略。在传统模式下为系统负载配置资源的唯一合理选择就是尝试为峰值负载做准备。以下是按峰值负载配置的典型场景薪资处理例如在月末薪资处理时你必须购买足够多的机器来支持该级别的活动量。数据分析在数据科学部门分析任务可能偶尔会变得非常集中和繁忙。为了应对这种情况并避免大家因集群过于繁忙而感到沮丧常见的做法是购买一个更大的集群。理想情况下你购买的资源量恰好能满足峰值容量。但现实往往更为复杂。现实困境资源不足配置然而我认为他们提出的一个更现实的观点是你很可能无法精确匹配峰值。实际情况是你会购买一定的资源容量但需求有时会超过这个容量。这里一个隐蔽的问题是你可能不会意识到自己处于这种资源不足的状态。因为需求会自然地调整以适应有限的容量。以下是需求如何“适应”有限容量的例子内部用户调整行为在数据分析部门数据科学家们会逐渐形成一种认知。例如在月末报告周期截止日期前大家知道集群会很忙。因此他们会选择不去提交某些任务因为他们知道这些任务无法及时完成。外部客户流失如果你在网络上销售产品情况会更糟。客户如果无法从你的服务中获得良好体验他们就会直接去别处购买。因此这种资源不足配置的观点可能更贴近现实。解决方案集中化与云资源的优势那么如何应对这个问题呢论点指出只有极端的集中化才能帮助对抗这种现象。你必须提供一种近乎无限资源的假象而商业云服务正好能够提供这种能力。总结https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_4.png本节课我们一起学习了资源配置的核心挑战。我们了解到传统的按峰值负载配置方法可能导致资源在大部分时间闲置而现实中更常见的资源不足配置则会隐性抑制需求导致内部效率降低或外部客户流失。最后我们认识到通过集中化的商业云平台提供弹性可扩展的资源是解决这一困境的有效途径。111弹性和价格降低 https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_1.png在本节课中我们将探讨云计算的两个核心优势弹性和持续降低的价格。我们将通过具体案例来理解弹性如何帮助企业应对突发的、不可预测的需求并分析云服务价格持续下降背后的经济原理。弹性按需伸缩的能力上一节我们讨论了资源供应不足的问题即需求更可能去适应容量而非容量去适应需求。这促使我们思考为何需要更集中的资源提供方式。亚马逊经常使用的一个经典案例是Anmoto公司。该公司通过一系列图片合成短视频片段。他们原本在亚马逊云上稳定运行着40个实例。然而当他们发布了一个修改版的Facebook应用后该应用在极短时间内变得非常流行。结果在短短几天内他们的实例使用量激增至约5000个的峰值。关键在于当这个需求高峰过去后他们又能迅速将实例数量缩减下来。这种弹性正是使用集中化云服务的优势也是商业云平台已经为我们构建好的核心能力。在数据科学领域这种应对突发需求的能力尤为重要因为正如我们所论证的需求通常是不可预测的。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_3.png弹性的另一种模式可预测的周期性峰值弹性不仅体现在应对突发流行事件上也体现在处理可预测的周期性需求波动上。以下是一个来自金融行业的例子。图中Y轴同样是使用的EC2实例数量波动范围相当大从300到近3000相差近10倍。我们可以清晰地看到模式在工作日的交易时段实例使用量达到高峰在夜间和非交易时段使用量下降而在周末则持续保持在很低的水平约30个CPU。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_5.png能够在这种需求低谷期节省成本并让容量精确追踪需求曲线这种能力非常强大。除了云服务提供商已经构建好的方案几乎没有其他方法可以实现这一点。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_7.png成本优势的另一面持续下降的价格https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_9.png弹性是成本优势的一个方面。另一个方面则是价格本身。如果价格过高弹性带来的好处可能就无关紧要了。关于云服务价格过高的论点在过去两年里实际上已经被大大削弱了这主要归功于亚马逊、微软和谷歌三大巨头之间的激烈竞争。每当一家公司降价其他公司通常会在几周甚至几天内将价格调整到相同水平。即使在亚马逊几乎是唯一玩家的早期其价格也在急剧下降。下图展示了单个EC2计算单元在约三年内其计算和内存资源的价格变化曲线。曲线上的每一个下降点都对应着一次价格调整公告可能是特定类型实例降价也可能是全面的价格削减。价格差异非常显著。在服务刚推出时一个计算单元的价格约为500美元一个内存单元的价格约为1500美元。而到了后期计算单元价格降至原来的三分之一或五分之一内存单元价格降至原来的三分之一。这仅仅是在几年内在几乎没有竞争的情况下仅凭规模经济效应实现的。存储成本的下降趋势存储成本也呈现出类似的大幅下降趋势。无论是按每太字节还是每拍字节计算价格都显著降低。我们过去常常比较云存储和在校内自建存储的成本。有一段时间在原始数据存储的纯经济成本上我们自建方案可能更具优势。但云服务商最近已经跨越了这个门槛。即使我们采取各种捷径比如购买大量廉价硬盘、降低冗余度和安全性这通常是大学环境下的做法我们也无法再在成本上与之竞争。云存储价格正像石头一样快速下落。总结本节课我们一起学习了云计算的弹性和价格降低两大核心优势。弹性允许资源容量精确追踪实际需求既能应对Anmoto那样的突发流量高峰也能适应金融行业那样的周期性波动从而在需求低谷期显著节省成本。持续的价格下降则得益于云服务商的规模经济和激烈的市场竞争使得计算、内存和存储资源的单位成本不断降低让大规模数据处理变得更加经济可行。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_11.png这两点共同构成了在云平台上进行大规模数据科学分析的重要经济和技术基础。112服务器成本与电力成本 ⚡https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_1.png在本节课中我们将探讨数据中心运营成本的核心构成并分析为何在云计算时代单纯为了省电而关闭闲置服务器的传统策略可能并不经济。上一节我们讨论了数据中心的总体成本结构。本节中我们来看看一个由亚马逊数据中心专家詹姆斯·汉密尔顿提出的重要观点。詹姆斯·汉密尔顿曾就职于微软最初以数据库专家闻名。他针对“绿色计算”领域的一项常见研究提出了不同看法。这项研究旨在通过关闭集群或数据中心中的闲置服务器将工作负载集中到更少的机器上以达到节省电力成本的目的。詹姆斯认为这项研究的目标本身意义不大。原因在于拥有一台闲置机器的成本极其高昂。以下是支撑这一观点的几个关键因素服务器硬件成本是主体图表显示服务器本身的购置成本占据了数据中心运营成本的绝大部分图中最大份额部分。购买来的机器如果闲置不做任何有用功本身就是巨大的资本浪费。配套基础设施成本已发生为了支持这些服务器运行企业已经支付了电力供应、冷却系统以及所有相关基础设施的建设成本图中紫色、红色等部分。这些都属于沉没的资本支出。既然已经为机器和基础设施支付了高昂费用现在却要将其关闭这并不划算。亚马逊不需要这样做因为他们有办法避免计算机闲置。一种竭尽全力避免计算机闲置的方法就是降低价格为那台计算机寻找更多的工作。这正是亚马逊能够做到的也是他们推出“竞价型实例”的原因。他们可以通过拍卖机制将计算资源提供给出价最高的用户这可能低于其标定价格。这种策略是你在自己的数据中心内无法实现的。在你的私有数据中心里为了节省一点电力成本图中绿色部分唯一的选择就是关闭设备而此时你已经承担了所有其他成本。因此只有亚马逊这类云服务商能够提供这种规模经济效应。关于云服务成本优势的另一个论据是价格的持续快速下降。其他研究者的数据显示不仅是在亚马逊跨云服务提供商来看成本都在显著降低。以下是2013年一些关键资源成本的下降幅度计算成本下降42%带宽成本下降15%数据库成本下降8%存储成本下降23%这些成本正在迅速下降。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_4.png本节课中我们一起学习了数据中心成本分析的一个重要视角由于服务器硬件和基础设施的资本成本占主导地位单纯为省电而关闭闲置服务器的策略在经济上可能低效。相比之下大型云服务商如亚马逊凭借其规模效应和灵活的资源分配机制如竞价实例能够通过最大化利用率来摊薄固定成本从而实现更优的经济性并推动市场价格持续快速下降。113大数据的可重复性 https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/d726dd178d1d83a88cd84dc27f190a02_1.png在本节课中我们将探讨在大数据背景下进行可重复性研究时面临的挑战与解决方案。核心在于理解为何传统的数据共享和代码执行方式在数据规模巨大时不再适用以及如何通过改变数据处理范式来应对这些挑战。随着数据集变得越来越大移动数据的时代已经结束。通过互联网传输1TB数据可能需要数天并且很可能失败。复制1PB数据在操作上几乎不可能也不应该发生。因此唯一的解决方案是将计算推向数据所在之处而不是将数据移动到计算所在之处。这对于完成工作至关重要尤其是在可重复性研究的背景下要求他人通过将数据集复制到其“本地环境”来复现你的结果是毫无意义的。上一节我们讨论了移动大数据的不可行性本节中我们来看看这如何促使我们寻找新的数据存储和共享方案。这直接促使我们将大型数据集的存储位置设置为可以与全球所有人共享的地方。这些地方就是云服务提供商。虽然我们讨论过供应商锁定等问题但即使你想从一个提供商迁移到另一个他们数据中心之间拥有高速连接的可能性也远高于你的数据中心与他们数据中心之间拥有高速连接的可能性。因此尽管迁移困难但在商业环境下这更有可能实现。当前可重复性研究社区倾向于强调计算层面的可重复性例如是否在提交论文时附上了脚本是否将所有内容都放在了GitHub上等。他们要么不担心数据问题要么假设数据足够小或不重要。这是一个问题。仅仅重新执行预设的实验是不够的。这一点与我之前关于虚拟机是好主意的论点有些相悖我们稍后会再次提及。虚拟机环境确实有助于精确复现他人运行过的内容但它不一定能为你在此工作基础上进行构建提供太多帮助。你有一堆脚本、依赖项和已安装的库可以运行程序但这并不一定意味着你能理解其中的任何部分。随着数据集变大和代码变得更复杂数据库和查询开始扮演更重要的角色。你需要支持对数据进行即席的探索性问答而不仅仅是重新运行代码。要求他人“吃你的狗粮”即仔细研读你的Python脚本是很困难的。相比之下要求他人“重新运行这个查询然后修改查询以运行你自己的查询”这个要求通常更低。因此你需要的是查询而非程序是数据库而非文件以此来减少重新运行实验所需的代码量和认知负担。Python文件中大量与管理文件、解析文件等相关的代码在使用数据库时都会消失。因此为研究提供数据库即服务恰好是我们为那些不一定有丰富编程经验的“长尾”科学家们搭建的一个平台。在那里你可以上传数据、编写查询、与朋友分享查询等真正地将你的计算流程构建为一系列嵌套查询并看看这能带你走多远。我们发现这实际上可以走得很远。大部分逻辑都可以用SQL表达而不需要大量代码。机器学习模型、统计模型可能不适用但很多工作都与表格操作有关。我们这里有一个例子找出所有在至少一个样本中缺失的Tigerfam ID本质上是蛋白质标识符。这三个样本分别来自水域的某个地点、河流或河口的某个点以及海洋的某个点。比较这三个样本中的微生物种群试图理解它们有何不同。问题是找出在至少一个样本中缺失的东西。如果某个东西在三个样本中都很常见那就不太有趣我不关心它。如果有东西不同我想知道。这可以简洁地表达为一个SQL查询但却需要大量的Python代码来构建字典、读取文件、处理数据而查询的实际逻辑很难从这个庞大的程序中剥离出来。我们收集的这类例子表明对于某些任务SQL实际上看起来更好而不是更差。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/d726dd178d1d83a88cd84dc27f190a02_3.png在本节课中我们一起学习了大数据环境下可重复性研究的核心挑战。我们认识到移动海量数据的不切实际从而转向将计算推向数据的云解决方案。我们探讨了仅靠共享代码和虚拟机的局限性并强调了数据库和声明式查询如SQL在降低认知负担、支持探索性分析以及清晰表达数据逻辑方面的重要优势。最终通过将数据处理流程构建为可共享和可修改的查询序列我们可以更有效地实现和传播可重复的大数据科学研究。114反论与总结https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/705325da2606f0e626b6a78314485f7b_1.png 概述在本节课中我们将探讨关于使用虚拟机VM和容器技术来确保研究可重复性的不同观点。我们将介绍一位专家提出的反论分析其核心论点并最终总结云计算平台如何为可重复研究提供一个全面的解决方案。 关于虚拟机使用的反论上一节我们介绍了使用虚拟机来封装研究环境以促进可重复性的优点。本节中我们来看看对此方法的一个主要反对观点。提出这一反论的是Titus Brown他是一位深入思考研究可重复性问题的专家。他的核心论点是仅仅将虚拟机公之于众实际上是在鼓励一种不良行为。他努力说服人们避免这种行为即研究者只是说“这是我的所有代码你自己去弄明白吧。” 这就像提供了一个完整的“犯罪现场”虽然包含了所有信息但缺乏指引。Titus Brown的观点是可重复性更多地关乎在他人的成果基础上进行构建而不仅仅是原封不动地重新运行完全相同的实验。因此研究者需要提供关于如何设置或理解那个环境的说明。透明度不仅仅是访问权限更是关于文档记录。他进一步阐述研究者需要的不是一个杂乱的环境本身而是如何构建那个环境的完整描述。这样其他人才能根据需要修改环境在其他地方建立自己的环境并真正控制不同变量以实现复现。仅仅因为实验在你的虚拟机中能再次运行并不必然意味着当其他人尝试实际操作时也能成功。因此研究者实际上希望改变一些变量希望有独立的实验室来验证结果就像希望两个不同地点的湿实验室实验能运行并得到相同结果一样。如果只是在同一个实验室里重复操作并不能完全确定是否真正实现了复现。 对反论的回应针对上述观点我的回应如下。当前研究可重复性的现状相当糟糕存在巨大问题。在数据科学领域情况类似论文发表了但数据和代码往往被隐藏起来。这是一个亟待解决的问题。我同意Titus的观点即仅分享虚拟机是不够的。然而如果我们能让人们广泛地分享他们的虚拟机或容器在当今时代主要指容器这将是一个巨大的进步。特别是对于数据科学和科学研究中的“长尾”部分指大量的小型、非主流研究要求他们完全掌握使用GitHub管理所有代码、使用亚马逊等平台共享所有数据等技能并成为完美的“科研公民”是尤其困难的。有时被提及的另一个问题是虚拟机本身可能是一个“庞然大物”。如果我为每个不同实验都保存了50个虚拟机当我想结合来自不同实验的想法时可能无法以特定方式将它们合并最终不得不将它们拆解。但这个问题正在逐渐消失因为容器技术正是为解决这类问题而设计的。✅ 总结与核心方案本节课中我们一起学习了关于可重复性方法的辩论。现在我们来总结云计算提供的解决方案。云计算为可重复研究提供了一个相当全面的平台。云计算所代表的集中化模式也许可以通过其他方式复制而不一定非要使用亚马逊等具体服务因为在某些行业或背景下这可能不可行。但我认为它满足了所有关键要求。以下是实现可重复研究需要满足的核心条件云计算平台能够全面支持数据 代码 环境研究的所有组成部分。运行平台用于运行上述数据、代码和环境的完整平台由云服务提供。无论规模大小从MB到PB无论计算类型从长时间运行的计算到简单脚本无论架构复杂度如何大型异构架构云计算都能提供支持。这些都是常见问题并且正在被解决。本质上我的整个实验室资源我的“实验台”就是你的“实验台”。我能在云中访问所有这些强大的工具而根据定义因为是第三方服务你也能访问完全相同的工具。虚拟机和容器或许结合Chef等配置脚本可以被共享和保存。这些数字制品代表了你的研究。它们成为了你实验的可执行证明而不仅仅是环境设置的描述。它们实际上是可执行的单元可以直接运行以重现整个实验环境。最后对于数据密集型的实验除了使用某种大型共享数据平台之外几乎没有其他选择因为在某些数据规模下移动数据是不现实的。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/705325da2606f0e626b6a78314485f7b_3.png本节课中我们一起探讨了关于使用虚拟机确保可重复性的反论理解了透明度与文档的重要性并最终总结了云计算及其容器技术如何为不同规模与复杂度的研究提供了一个强大、共享且可执行的可重复性解决方案。 上一节我们介绍了云计算的基本概念本节中我们来看看其核心的三种服务模式。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_1.png以下是三种主要的云服务模式基础设施即服务提供虚拟化的计算资源如服务器、存储和网络。经典的例子是亚马逊的EC2计算引擎和S3存储服务。平台即服务提供一个平台让开发者可以构建、运行和管理应用程序而无需处理底层基础设施。例如微软的Azure最初就是以此模式起步的。软件即服务通过互联网提供完整的应用程序。例如微软的Office 365。随着服务模式从基础设施向软件演进服务变得更加具体、面向特定领域和任务同时也能引入更多的自动化功能。过去十年间行业的发展正是不断充实这一设计空间的过程。云计算的巨大成功了解了服务模式后我们来看看云计算在实际应用中的巨大成功。云计算的增长是爆炸性的。例如亚马逊全球网站的带宽消耗呈现稳定增长而亚马逊网络服务的带宽消耗则呈爆炸式增长。同样S3中存储的对象数量也经历了指数级增长。这些数据都清晰地展示了云计算的普及和成功。云计算对研究的优势云计算的成功不仅体现在商业领域对于科学研究尤其是数据科学它带来了独特的优势。以下是云计算为研究工作带来的几个关键优势突发性计算能力历史上首次使用1000个处理器运行一天的成本与使用1个处理器运行1000天的成本相同甚至更低。这使得研究人员可以在实验结束后关闭所有资源极大地提高了资源利用的灵活性。支持可重复性研究者可以访问完全相同的工具、数据和计算环境从而让他人能够精确复现实验过程。便于共享与协作将工作环境开放给外部访问通常只需在软件中进行简单设置无需物理移动数据或代码。消除跨部门冗余基础设施无论是在不同大学之间还是在公司内部的不同部门如市场部和分析部集中化的云平台都可以避免重复建设计算集群将资源共享提升到软件操作的层面。对于稳态的数据处理任务云计算的成本优势可能不明显。但对于实验性工作、数据科学和科学研究而言这种突发性计算能力的模式非常适用。公共云与私有云最后我们来谈谈云计算的部署模式。实现上述优势可以通过我们讨论的公共云或者通过某种形式的私有云。在这些情况下集中化程度越高越好因为它能将资源共享从物理硬件层面提升到软件操作层面。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/1d18872ffdc9035fbb6a0423e45aa2e9_3.png本节课中我们一起学习了云计算的三种服务模式IaaS PaaS SaaS见证了其巨大的商业成功并重点探讨了它为科学研究带来的核心优势特别是突发计算能力、可重复性以及便捷的协作共享这些特性使其成为现代数据科学不可或缺的工具。106虚拟化对可重复性的优势https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_1.png在本节课中我们将探讨虚拟化技术如虚拟机和容器如何为数据科学工作流中的可重复性问题提供强大的解决方案。我们将分析数据科学实验的“混乱”现实并理解为什么捕获整个计算环境至关重要。上一节我们讨论了数据科学中可重复性面临的挑战本节中我们来看看虚拟化技术如何提供一种优雅的解决方案。数据科学实验的现实数据科学实验常常发生在受控、受监控的环境之外。总会有一些实验和数据存在于某种便于实现可重复性的、受管理的受保护环境之外。以下是数据科学工作流的典型特点自由实验能够随时打开文本编辑器从头开始编写代码并尝试新想法这是软件和数据科学的一个重要特性不应轻易破坏。流程模糊调试、测试和实验之间的界限非常模糊。同一段代码当它成功时是“实验”当它失败时是“调试”。环境异构实验依赖于复杂的、相互关联的网络包括数据库、外部系统、可视化库及其各自的依赖项。因此我们需要一种能够事后捕获实验环境的方法并且这种方法必须能够容忍数据科学实验混乱、异构的现实。虚拟化的核心优势虚拟化技术虚拟机和容器的核心优势在于它们允许我们捕获并复制整个计算环境。我的卡通版理解是你开发了一个回答特定统计问题的工作流管道并想把它交给你的老板。你不仅可以移交代码还能连同其所有依赖一起打包。代码依赖于某个数据库、某个外部系统、某个可视化库而它们各自又有一系列复杂的库和依赖网络。除了获取整个环境没有更好的切割点。这正是虚拟化和容器所提供的。核心概念通过虚拟化可复现的环境可以打包为一个文件如Dockerfile或虚拟机镜像并通过简单的命令如docker build和docker run来重建。# 示例 Dockerfile FROM python:3.9-slim COPY requirements.txt . RUN pip install -r requirements.txt COPY my_analysis_script.py . CMD [python, ./my_analysis_script.py]责任划分问题在传统湿实验室如化学、生物学中可重复性依赖于研究者对实验步骤的描述由他人在自己的环境中复现。这里存在一个责任划分的问题在多大程度上复现者需要自己填补环境配置的空白随着计算科学的普及这个问题变得更加尖锐。想复现你计算生物学实验的生物学家可能不具备操作你提供的软件、以同样方式设置环境的技能。以下是复现者可能面临的挑战列表能否在系统级、R 或 Python 环境中安装软件包能否编译代码以使用你所依赖的快速 C 库能否解决出现的依赖问题如果涉及数据库能否编写 DDL 语句来建立与你相同的模式能否配置运行这些 DDL 语句所需的数据库服务器能否解决文件权限等问题如果对这些问题的答案是“否”那么即使你提供了“潜在可行”的方法也可能并未真正实现“易于复现”。虚拟化方法有助于解决这种责任划分问题它明确表示“这就是我所做的一切你只需运行这些命令就能获得完全相同的环境。”https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/02b921c884a7371809ab2150532fd4be_4.png本节课中我们一起学习了虚拟化技术如何应对数据科学中的可重复性挑战。我们认识到数据科学自由、模糊的工作特性需要一种能够事后捕获完整环境的方法。虚拟机和容器通过打包整个计算环境提供了一种清晰、可靠且能明确责任划分的解决方案使得复现实验变得像执行几条命令一样简单。107复杂虚拟化场景 ️https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa624356e363ef66a52b89166957a153_1.png在本节课中我们将探讨在数据密集型科学实验中如何超越单一虚拟机的限制实现复杂、多组件环境的可复现性。我们将理解为何简单的“代码数据”打包方式已不足以应对现代大规模数据分析的需求。从单一虚拟机到复杂环境上一节我们介绍了将代码、数据、环境和运行平台打包在一起的基本理念。本节中我们来看看当实验架构变得复杂时这种单一虚拟机的方案为何会失效。随着数据集变得越来越大建议他人仅仅为了复现你的实验就去下载数百TB的数据例如300TB的MRI图像变得越来越不切实际。因此你需要提供的远不止代码本身。你需要提供一个可以运行的环境以及对其所依赖数据的访问权限。在商业环境中你可能可以假设大家共享访问一个通用的基础设施资源。例如你可以说“这是我的Python脚本它调用了共享环境中的各种东西但不用担心因为你也能访问同一个共享环境”。在这种情况下实现可复现性的门槛对你来说就降低了。然而如果你需要跨越机构边界进行共享公共云在我看来就成为了唯一可行的选择。当然在公司内部情况可能有所不同。多组件协调架构正如我们之前提到的有些架构尤其是围绕数据密集型实验的架构需要多种不同类型的资源协调一致地共同工作。以下是这类架构中常见的组件应用服务器负责运行业务逻辑。数据库服务器存储和管理结构化数据。安装有Hadoop等工具的集群用于处理大规模数据。因此一个虚拟机通常是不够的。一个科学案例环境观测与预报系统为了具体说明这一点我们来看一个来自科学领域的例子这个例子与我之前提到的“海洋设备”案例大约处于同一时期。这是一个环境观测与预报系统它被设置为运行每日预报。其工作流程非常复杂涉及多个步骤和外部依赖。以下是该系统的工作流程与组件数据输入系统整合来自多方的数据包括本机构管理的传感器、他人管理的传感器、卫星图像以及其他机构运行的大尺度、低分辨率模型例如覆盖地球西半球的模型的输出。数据处理与存储这些预报输入数据被存入一个大型文件系统同时用一个关系型数据库来管理元数据。模型执行一系列由Perl脚本、配置脚本和其他遗留管理基础设施组成的系统会启动Fortran模型。这些模型是海洋学现场模型用于模拟水体的运动并观察其变化。结果后处理模型运行结果输出后会触发另一系列脚本从结果中提取统计数据、生成可视化图表并将这些可视化结果发布到网络上。整个基础设施提供了一个在许多情况下都可复现的实验。但要想象将这一切都塞进一个虚拟机里是行不通的。数字产物的多样性在这样的复杂实验中会产生多种数字产物远不止最终结果。以下是一些关键的数字产物类型模拟结果本身模型运行产生的核心数据。配置与日志文件记录运行环境和过程的文件。注释数据产品对原始数据进行标注和解释后生成的数据。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa624356e363ef66a52b89166957a153_3.png本节课中我们一起学习了复杂虚拟化场景的挑战。我们认识到对于依赖多种资源如专用服务器、数据库、集群和外部数据源的现代数据科学工作流单一虚拟机的封装方式已不再适用。通过一个环境预报系统的具体案例我们看到了一个可复现实验如何由多个协调工作的组件构成并产生了多样化的数字产物。这为理解更高级的虚拟化和容器化技术如Docker Compose、Kubernetes的必要性奠定了基础。108共享实验室https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_1.png概述在本节课中我们将探讨数据科学协作中的一个核心挑战如何快速建立共享、可复现的开发环境。我们将了解传统协作方式的痛点并学习如何利用现代云基础设施和“基础设施即代码”的理念来解决这些问题。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_3.png共享开发环境的挑战与解决方案问题的普遍性这个问题已被广泛观察到。在数据科学项目中跨团队或跨机构协作时经常需要共享代码、数据和计算环境。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_5.png解决方案基础设施即代码上一节我们提到了协作的挑战本节中我们来看看一种核心解决方案基础设施即代码。其核心思想是使用脚本或配置文件来定义和启动整个计算基础设施。亚马逊的CloudFormation是此类解决方案之一。它允许你通过脚本启动和配置一组协调工作的虚拟机集群这些虚拟机作为一个单元被部署并扮演不同的角色。公式/代码示例基础设施即代码# 一个简化的 CloudFormation 模板示例用于定义资源Resources:MyEC2Instance:Type:AWS::EC2::InstanceProperties:InstanceType:t2.microImageId:ami-0abcdef1234567890同类工具在 DevOps 环境中也有像Chef这样的工具可以实现类似功能。它们都致力于将基础设施作为代码来管理。以下是此类工具的核心价值你可以编写脚本来启动、设置和操作基础设施。共享这些脚本如 Chef 脚本能为他人提供相同的能力使其能够启动一个大型、复杂、异构的架构来运行实验。这些问题正在被解决而涌现出的解决方案如 Chef通常与公有云、商业云服务紧密耦合。云环境开发者的“Google Docs”协作的本质需求数据科学本质上是一项协作性工作而可复现性是协作的一部分。同时协作也意味着当我们需要尝试一个大胆的想法或者需要与另一个部门具有类似专业知识的同事合作时能有一个高效的共同工作空间。传统协作方式的瓶颈当两个人需要一起工作时启动一个双方都能访问的“Google 文档”非常有意义但这仅限于文档工作。如果你们需要一起进行一些共享开发就需要一个共享的开发环境。我们在大学环境中观察到现在几乎每个项目本质上都是协作的经常需要跨越机构边界一起工作。一个临时的、不受任何特定系统管理员管辖的共享开发环境变得非常重要。一个具体案例例如在跨机构协作时我们曾经需要等待两周让对方的系统管理员在我们的机器上提供账户或者让我们的系统管理员在他们的机器上提供账户。我们当时觉得这很荒谬。于是我们转而启动了一个共享虚拟机为所有人提供访问权限让大家可以并肩工作完成后便将其关闭、拆除。这是一个极佳的解决方案。共享环境的优势这不仅降低了协作的摩擦更重要的是解决了沟通效率问题。你不再需要通过电子邮件互相发送错误信息并试图描述问题以便对方在自己的环境中复现。你可以直接说“运行这个命令你就会看到错误信息。”因为你们访问的是完全相同的环境。我们不可能轻易地互相访问对方私有的内部环境至少在没有让系统管理员相当不满的情况下是不可能的。正如这里总结的没有“无法复现”的漏洞。因为如果我看到了问题那么你也能看到同样的问题。我们放弃了等待两周建立凭证转而启动了一个 EC2 实例在一小时内就开始了工作。我认为这在部门环境或商业环境中也同样适用。即使由于某些原因你使用的云不一定是公有云一个能够支持启动新虚拟机、允许不同人员访问、并在完成后可拆除的共享环境仍然是支持协作性、可复现数据科学的一个非常有用的方面。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/6114e625ac74094651c96d217510677c_7.png总结本节课中我们一起学习了数据科学协作中关于环境共享的核心挑战。我们探讨了“基础设施即代码”的理念及其工具如 AWS CloudFormation 和 Chef它们通过脚本化方式管理复杂环境。更重要的是我们认识到云平台能够提供类似“Google Docs”的共享开发环境这种环境极大地提升了协作效率消除了“环境不一致”导致的沟通障碍使得跨团队、跨机构的协同数据科学工作变得更加流畅和可复现。109协作与可复现性中的成本与规模经济https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_1.png在本节课中我们将探讨在协作、可复现的数据科学工作中成本如何产生以及如何分担。我们还将分析为何大型公共云服务商能够提供更经济的解决方案。成本分担谁为可复现性付费在协作和可复现的数据科学背景下一个核心问题是谁为可复现性付费当处理数百TB数据或运行复杂计算模型时成本会显著增加。这些成本并非免费主要包括代码托管、数据托管和代码执行三个方面。以下是各项成本的分担方式代码托管成本这部分成本通常由代码提供者你承担。你需要将代码托管在某个地方如GitHub、GitLab或内部服务器并确保组织内外的协作者能够访问。这部分费用相对较低。数据托管成本这部分成本传统上由数据所有者他们承担。在科研或商业环境中公开托管大规模数据以供他人复现研究曾因高昂的存储和带宽费用而难以实现。代码执行成本在云环境中这部分成本总是由代码执行者他们承担。他们使用自己的云账户启动计算实例来运行你的代码你无需为此付费。上一节我们讨论了成本的基本分担原则本节中我们来看看云服务商如何改变了数据托管的经济模型。云服务如何改变数据托管经济云服务特别是亚马逊AWS等提供商正在通过创新的商业模式解决数据托管的成本难题。以下是关键机制转移带宽成本数据提供者可以配置数据集使得数据流出egress产生的网络带宽费用由数据消费者支付而非提供者。公共数据集计划对于使用率高且愿意公开的数据集云服务商如AWS可能会提供免费托管。其商业逻辑在于用户为了使用这些数据会在该云平台上启动EC2实例并购买其他付费服务从而为云商带来收入。内部成本核算即使在公司内部使用私有云或公有云环境也能清晰地将计算资源成本分配给实际使用的部门如市场部避免了因预算归属问题阻碍协作。然而如果托管了海量数据却无人使用存储账单仍需有人支付这仍然是一个待解决的挑战。但值得注意的是即使不公开数据长期存储海量数据本身也是一个成本难题。规模经济为何云服务更便宜你可能会问为什么公共商业云这类高度集中的服务能够节省成本它们为何更便宜答案是规模经济。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_3.png下图展示了一份2009年的早期报告揭示了超大规模数据中心在几个关键方面的规模经济效益。虽然具体数字在今天2015年录制时已发生巨大变化但其揭示的原理依然成立。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_5.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/b67a86810aa7f679a5ca3cff48276d72_5.png报告主要对比了网络、存储和管理三个类别网络小型数据中心的网络成本约为$95 / (Mbps·月)而超大规模数据中心的成本可低至$13 / (Mbps·月)成本比约为7.1。存储存储成本的比例约为5.7大规模集中采购和管理能显著降低单价。管理在传统数据中心约每140台服务器需要一名管理员。在超大规模数据中心一名管理员可以管理1000台甚至更多的服务器。随着自动化程度的提高这一比例还在持续上升。这些因规模效应产生的成本节约可以传递给用户。从长远来看试图通过维护众多小型服务器机房或集群来追赶这种效率是非常困难的。本节课中我们一起学习了在可复现数据科学工作中的成本分担模式以及云服务商如何通过商业模式创新如转移带宽成本、公共数据集计划来降低数据托管门槛。更重要的是我们探讨了其背后的根本驱动力——规模经济它使得超大规模数据中心在网络、存储和管理效率上远超小型部署从而能够为用户提供更具成本效益的服务。110为峰值负载配置资源https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_1.png概述在本节课中我们将探讨在数据科学和IT基础设施管理中如何为系统负载配置计算资源。我们将分析传统的“按峰值负载配置”方法的局限性并理解资源不足配置带来的隐性成本最终了解集中化云资源如何为解决此问题提供方案。传统配置逻辑瞄准峰值上一节我们讨论了资源管理的基本挑战本节中我们来看看一个常见的资源配置策略。在传统模式下为系统负载配置资源的唯一合理选择就是尝试为峰值负载做准备。以下是按峰值负载配置的典型场景薪资处理例如在月末薪资处理时你必须购买足够多的机器来支持该级别的活动量。数据分析在数据科学部门分析任务可能偶尔会变得非常集中和繁忙。为了应对这种情况并避免大家因集群过于繁忙而感到沮丧常见的做法是购买一个更大的集群。理想情况下你购买的资源量恰好能满足峰值容量。但现实往往更为复杂。现实困境资源不足配置然而我认为他们提出的一个更现实的观点是你很可能无法精确匹配峰值。实际情况是你会购买一定的资源容量但需求有时会超过这个容量。这里一个隐蔽的问题是你可能不会意识到自己处于这种资源不足的状态。因为需求会自然地调整以适应有限的容量。以下是需求如何“适应”有限容量的例子内部用户调整行为在数据分析部门数据科学家们会逐渐形成一种认知。例如在月末报告周期截止日期前大家知道集群会很忙。因此他们会选择不去提交某些任务因为他们知道这些任务无法及时完成。外部客户流失如果你在网络上销售产品情况会更糟。客户如果无法从你的服务中获得良好体验他们就会直接去别处购买。因此这种资源不足配置的观点可能更贴近现实。解决方案集中化与云资源的优势那么如何应对这个问题呢论点指出只有极端的集中化才能帮助对抗这种现象。你必须提供一种近乎无限资源的假象而商业云服务正好能够提供这种能力。总结https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/fa40031d4136264a1238de71d5193a97_4.png本节课我们一起学习了资源配置的核心挑战。我们了解到传统的按峰值负载配置方法可能导致资源在大部分时间闲置而现实中更常见的资源不足配置则会隐性抑制需求导致内部效率降低或外部客户流失。最后我们认识到通过集中化的商业云平台提供弹性可扩展的资源是解决这一困境的有效途径。111弹性和价格降低 https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_1.png在本节课中我们将探讨云计算的两个核心优势弹性和持续降低的价格。我们将通过具体案例来理解弹性如何帮助企业应对突发的、不可预测的需求并分析云服务价格持续下降背后的经济原理。弹性按需伸缩的能力上一节我们讨论了资源供应不足的问题即需求更可能去适应容量而非容量去适应需求。这促使我们思考为何需要更集中的资源提供方式。亚马逊经常使用的一个经典案例是Anmoto公司。该公司通过一系列图片合成短视频片段。他们原本在亚马逊云上稳定运行着40个实例。然而当他们发布了一个修改版的Facebook应用后该应用在极短时间内变得非常流行。结果在短短几天内他们的实例使用量激增至约5000个的峰值。关键在于当这个需求高峰过去后他们又能迅速将实例数量缩减下来。这种弹性正是使用集中化云服务的优势也是商业云平台已经为我们构建好的核心能力。在数据科学领域这种应对突发需求的能力尤为重要因为正如我们所论证的需求通常是不可预测的。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_3.png弹性的另一种模式可预测的周期性峰值弹性不仅体现在应对突发流行事件上也体现在处理可预测的周期性需求波动上。以下是一个来自金融行业的例子。图中Y轴同样是使用的EC2实例数量波动范围相当大从300到近3000相差近10倍。我们可以清晰地看到模式在工作日的交易时段实例使用量达到高峰在夜间和非交易时段使用量下降而在周末则持续保持在很低的水平约30个CPU。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_5.png能够在这种需求低谷期节省成本并让容量精确追踪需求曲线这种能力非常强大。除了云服务提供商已经构建好的方案几乎没有其他方法可以实现这一点。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_7.png成本优势的另一面持续下降的价格https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_9.png弹性是成本优势的一个方面。另一个方面则是价格本身。如果价格过高弹性带来的好处可能就无关紧要了。关于云服务价格过高的论点在过去两年里实际上已经被大大削弱了这主要归功于亚马逊、微软和谷歌三大巨头之间的激烈竞争。每当一家公司降价其他公司通常会在几周甚至几天内将价格调整到相同水平。即使在亚马逊几乎是唯一玩家的早期其价格也在急剧下降。下图展示了单个EC2计算单元在约三年内其计算和内存资源的价格变化曲线。曲线上的每一个下降点都对应着一次价格调整公告可能是特定类型实例降价也可能是全面的价格削减。价格差异非常显著。在服务刚推出时一个计算单元的价格约为500美元一个内存单元的价格约为1500美元。而到了后期计算单元价格降至原来的三分之一或五分之一内存单元价格降至原来的三分之一。这仅仅是在几年内在几乎没有竞争的情况下仅凭规模经济效应实现的。存储成本的下降趋势存储成本也呈现出类似的大幅下降趋势。无论是按每太字节还是每拍字节计算价格都显著降低。我们过去常常比较云存储和在校内自建存储的成本。有一段时间在原始数据存储的纯经济成本上我们自建方案可能更具优势。但云服务商最近已经跨越了这个门槛。即使我们采取各种捷径比如购买大量廉价硬盘、降低冗余度和安全性这通常是大学环境下的做法我们也无法再在成本上与之竞争。云存储价格正像石头一样快速下落。总结本节课我们一起学习了云计算的弹性和价格降低两大核心优势。弹性允许资源容量精确追踪实际需求既能应对Anmoto那样的突发流量高峰也能适应金融行业那样的周期性波动从而在需求低谷期显著节省成本。持续的价格下降则得益于云服务商的规模经济和激烈的市场竞争使得计算、内存和存储资源的单位成本不断降低让大规模数据处理变得更加经济可行。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/c303c4e86603d57adca0c1e2cf194b6d_11.png这两点共同构成了在云平台上进行大规模数据科学分析的重要经济和技术基础。112服务器成本与电力成本 ⚡https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_1.png在本节课中我们将探讨数据中心运营成本的核心构成并分析为何在云计算时代单纯为了省电而关闭闲置服务器的传统策略可能并不经济。上一节我们讨论了数据中心的总体成本结构。本节中我们来看看一个由亚马逊数据中心专家詹姆斯·汉密尔顿提出的重要观点。詹姆斯·汉密尔顿曾就职于微软最初以数据库专家闻名。他针对“绿色计算”领域的一项常见研究提出了不同看法。这项研究旨在通过关闭集群或数据中心中的闲置服务器将工作负载集中到更少的机器上以达到节省电力成本的目的。詹姆斯认为这项研究的目标本身意义不大。原因在于拥有一台闲置机器的成本极其高昂。以下是支撑这一观点的几个关键因素服务器硬件成本是主体图表显示服务器本身的购置成本占据了数据中心运营成本的绝大部分图中最大份额部分。购买来的机器如果闲置不做任何有用功本身就是巨大的资本浪费。配套基础设施成本已发生为了支持这些服务器运行企业已经支付了电力供应、冷却系统以及所有相关基础设施的建设成本图中紫色、红色等部分。这些都属于沉没的资本支出。既然已经为机器和基础设施支付了高昂费用现在却要将其关闭这并不划算。亚马逊不需要这样做因为他们有办法避免计算机闲置。一种竭尽全力避免计算机闲置的方法就是降低价格为那台计算机寻找更多的工作。这正是亚马逊能够做到的也是他们推出“竞价型实例”的原因。他们可以通过拍卖机制将计算资源提供给出价最高的用户这可能低于其标定价格。这种策略是你在自己的数据中心内无法实现的。在你的私有数据中心里为了节省一点电力成本图中绿色部分唯一的选择就是关闭设备而此时你已经承担了所有其他成本。因此只有亚马逊这类云服务商能够提供这种规模经济效应。关于云服务成本优势的另一个论据是价格的持续快速下降。其他研究者的数据显示不仅是在亚马逊跨云服务提供商来看成本都在显著降低。以下是2013年一些关键资源成本的下降幅度计算成本下降42%带宽成本下降15%数据库成本下降8%存储成本下降23%这些成本正在迅速下降。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_3.pnghttps://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/f66cde7ee774fd07f29fd2ad36f60c3d_4.png本节课中我们一起学习了数据中心成本分析的一个重要视角由于服务器硬件和基础设施的资本成本占主导地位单纯为省电而关闭闲置服务器的策略在经济上可能低效。相比之下大型云服务商如亚马逊凭借其规模效应和灵活的资源分配机制如竞价实例能够通过最大化利用率来摊薄固定成本从而实现更优的经济性并推动市场价格持续快速下降。113大数据的可重复性 https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/d726dd178d1d83a88cd84dc27f190a02_1.png在本节课中我们将探讨在大数据背景下进行可重复性研究时面临的挑战与解决方案。核心在于理解为何传统的数据共享和代码执行方式在数据规模巨大时不再适用以及如何通过改变数据处理范式来应对这些挑战。随着数据集变得越来越大移动数据的时代已经结束。通过互联网传输1TB数据可能需要数天并且很可能失败。复制1PB数据在操作上几乎不可能也不应该发生。因此唯一的解决方案是将计算推向数据所在之处而不是将数据移动到计算所在之处。这对于完成工作至关重要尤其是在可重复性研究的背景下要求他人通过将数据集复制到其“本地环境”来复现你的结果是毫无意义的。上一节我们讨论了移动大数据的不可行性本节中我们来看看这如何促使我们寻找新的数据存储和共享方案。这直接促使我们将大型数据集的存储位置设置为可以与全球所有人共享的地方。这些地方就是云服务提供商。虽然我们讨论过供应商锁定等问题但即使你想从一个提供商迁移到另一个他们数据中心之间拥有高速连接的可能性也远高于你的数据中心与他们数据中心之间拥有高速连接的可能性。因此尽管迁移困难但在商业环境下这更有可能实现。当前可重复性研究社区倾向于强调计算层面的可重复性例如是否在提交论文时附上了脚本是否将所有内容都放在了GitHub上等。他们要么不担心数据问题要么假设数据足够小或不重要。这是一个问题。仅仅重新执行预设的实验是不够的。这一点与我之前关于虚拟机是好主意的论点有些相悖我们稍后会再次提及。虚拟机环境确实有助于精确复现他人运行过的内容但它不一定能为你在此工作基础上进行构建提供太多帮助。你有一堆脚本、依赖项和已安装的库可以运行程序但这并不一定意味着你能理解其中的任何部分。随着数据集变大和代码变得更复杂数据库和查询开始扮演更重要的角色。你需要支持对数据进行即席的探索性问答而不仅仅是重新运行代码。要求他人“吃你的狗粮”即仔细研读你的Python脚本是很困难的。相比之下要求他人“重新运行这个查询然后修改查询以运行你自己的查询”这个要求通常更低。因此你需要的是查询而非程序是数据库而非文件以此来减少重新运行实验所需的代码量和认知负担。Python文件中大量与管理文件、解析文件等相关的代码在使用数据库时都会消失。因此为研究提供数据库即服务恰好是我们为那些不一定有丰富编程经验的“长尾”科学家们搭建的一个平台。在那里你可以上传数据、编写查询、与朋友分享查询等真正地将你的计算流程构建为一系列嵌套查询并看看这能带你走多远。我们发现这实际上可以走得很远。大部分逻辑都可以用SQL表达而不需要大量代码。机器学习模型、统计模型可能不适用但很多工作都与表格操作有关。我们这里有一个例子找出所有在至少一个样本中缺失的Tigerfam ID本质上是蛋白质标识符。这三个样本分别来自水域的某个地点、河流或河口的某个点以及海洋的某个点。比较这三个样本中的微生物种群试图理解它们有何不同。问题是找出在至少一个样本中缺失的东西。如果某个东西在三个样本中都很常见那就不太有趣我不关心它。如果有东西不同我想知道。这可以简洁地表达为一个SQL查询但却需要大量的Python代码来构建字典、读取文件、处理数据而查询的实际逻辑很难从这个庞大的程序中剥离出来。我们收集的这类例子表明对于某些任务SQL实际上看起来更好而不是更差。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/d726dd178d1d83a88cd84dc27f190a02_3.png在本节课中我们一起学习了大数据环境下可重复性研究的核心挑战。我们认识到移动海量数据的不切实际从而转向将计算推向数据的云解决方案。我们探讨了仅靠共享代码和虚拟机的局限性并强调了数据库和声明式查询如SQL在降低认知负担、支持探索性分析以及清晰表达数据逻辑方面的重要优势。最终通过将数据处理流程构建为可共享和可修改的查询序列我们可以更有效地实现和传播可重复的大数据科学研究。114反论与总结https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/705325da2606f0e626b6a78314485f7b_1.png 概述在本节课中我们将探讨关于使用虚拟机VM和容器技术来确保研究可重复性的不同观点。我们将介绍一位专家提出的反论分析其核心论点并最终总结云计算平台如何为可重复研究提供一个全面的解决方案。 关于虚拟机使用的反论上一节我们介绍了使用虚拟机来封装研究环境以促进可重复性的优点。本节中我们来看看对此方法的一个主要反对观点。提出这一反论的是Titus Brown他是一位深入思考研究可重复性问题的专家。他的核心论点是仅仅将虚拟机公之于众实际上是在鼓励一种不良行为。他努力说服人们避免这种行为即研究者只是说“这是我的所有代码你自己去弄明白吧。” 这就像提供了一个完整的“犯罪现场”虽然包含了所有信息但缺乏指引。Titus Brown的观点是可重复性更多地关乎在他人的成果基础上进行构建而不仅仅是原封不动地重新运行完全相同的实验。因此研究者需要提供关于如何设置或理解那个环境的说明。透明度不仅仅是访问权限更是关于文档记录。他进一步阐述研究者需要的不是一个杂乱的环境本身而是如何构建那个环境的完整描述。这样其他人才能根据需要修改环境在其他地方建立自己的环境并真正控制不同变量以实现复现。仅仅因为实验在你的虚拟机中能再次运行并不必然意味着当其他人尝试实际操作时也能成功。因此研究者实际上希望改变一些变量希望有独立的实验室来验证结果就像希望两个不同地点的湿实验室实验能运行并得到相同结果一样。如果只是在同一个实验室里重复操作并不能完全确定是否真正实现了复现。 对反论的回应针对上述观点我的回应如下。当前研究可重复性的现状相当糟糕存在巨大问题。在数据科学领域情况类似论文发表了但数据和代码往往被隐藏起来。这是一个亟待解决的问题。我同意Titus的观点即仅分享虚拟机是不够的。然而如果我们能让人们广泛地分享他们的虚拟机或容器在当今时代主要指容器这将是一个巨大的进步。特别是对于数据科学和科学研究中的“长尾”部分指大量的小型、非主流研究要求他们完全掌握使用GitHub管理所有代码、使用亚马逊等平台共享所有数据等技能并成为完美的“科研公民”是尤其困难的。有时被提及的另一个问题是虚拟机本身可能是一个“庞然大物”。如果我为每个不同实验都保存了50个虚拟机当我想结合来自不同实验的想法时可能无法以特定方式将它们合并最终不得不将它们拆解。但这个问题正在逐渐消失因为容器技术正是为解决这类问题而设计的。✅ 总结与核心方案本节课中我们一起学习了关于可重复性方法的辩论。现在我们来总结云计算提供的解决方案。云计算为可重复研究提供了一个相当全面的平台。云计算所代表的集中化模式也许可以通过其他方式复制而不一定非要使用亚马逊等具体服务因为在某些行业或背景下这可能不可行。但我认为它满足了所有关键要求。以下是实现可重复研究需要满足的核心条件云计算平台能够全面支持数据 代码 环境研究的所有组成部分。运行平台用于运行上述数据、代码和环境的完整平台由云服务提供。无论规模大小从MB到PB无论计算类型从长时间运行的计算到简单脚本无论架构复杂度如何大型异构架构云计算都能提供支持。这些都是常见问题并且正在被解决。本质上我的整个实验室资源我的“实验台”就是你的“实验台”。我能在云中访问所有这些强大的工具而根据定义因为是第三方服务你也能访问完全相同的工具。虚拟机和容器或许结合Chef等配置脚本可以被共享和保存。这些数字制品代表了你的研究。它们成为了你实验的可执行证明而不仅仅是环境设置的描述。它们实际上是可执行的单元可以直接运行以重现整个实验环境。最后对于数据密集型的实验除了使用某种大型共享数据平台之外几乎没有其他选择因为在某些数据规模下移动数据是不现实的。https://github.com/OpenDocCN/dsai-notes-pt3-zh/raw/master/docs/duke-lgscl-ds/img/705325da2606f0e626b6a78314485f7b_3.png本节课中我们一起探讨了关于使用虚拟机确保可重复性的反论理解了透明度与文档的重要性并最终总结了云计算及其容器技术如何为不同规模与复杂度的研究提供了一个强大、共享且可执行的可重复性解决方案。 
 和 fallback()异同)
