PDF应该上传还是寄送大数据到云端？
普遍的认知并非总是正确。
Sachin Date，e-Emphasys Technologies
普遍的认知认为，当您希望移动到云端的数据达到太字节级别及以上时，最好将其寄送给云提供商，而不是上传。本文分析性地探讨了寄送和上传策略的比较、它们所依赖的各种因素，以及在何种情况下您更适合寄送而不是上传数据，反之亦然。鉴于千兆位速度互联网连接的日益普及，以及SAS和PCI Express等较新版本驱动器接口支持的数据传输速度的爆炸性增长，做出这样的分析性决定非常重要。正如本文所揭示的，上述“普遍认知”并非总是正确，并且对于上传与寄送数据到云端，存在有充分理由的实用建议。
以下是决定上传还是寄送时需要考虑的几个关键见解
• 即使通过100-Mbps（兆位/秒）及更快的互联网连接，直接上传大数据到云端也可能需要无法接受的时间。一种便捷的变通方法是将数据复制到存储磁带或硬盘驱动器，然后寄送给云数据中心。
• 然而，随着经济实惠的光纤互联网连接日益普及，从成本和传输速度的角度来看，通过驱动器寄送数据很快变得不具吸引力。
• 只有当您可以非常高的速度将数据复制到（和复制出）存储设备并且您拥有高容量、可重复使用的存储设备时，寄送大数据才是现实可行的。在这种情况下，如果数据大小超过某个阈值，寄送策略可以轻松击败甚至基于光纤的数据上传速度。
• 对于给定的驱动器到驱动器数据传输速度值，这个阈值数据大小（超过这个阈值，寄送数据到云端比上传更快）随着可用上传速度每Mbps的增加而增长。这种增长持续到某个阈值上传速度。如果您的ISP提供的上传速度大于或等于此阈值速度，那么无论数据有多大，上传数据总是比寄送到云端更快。
假设您想将您的视频收藏上传到公共云；或者假设您的公司希望将其数据从私有数据中心迁移到公共云，或从一个数据中心移动到另一个数据中心。在某种程度上，您的个人情况并不重要。鉴于个人和企业必须处理的数字信息量呈爆炸式增长，通过互联网将大数据从一个地方移动到另一个地方的前景比您想象的要近得多。
为了说明，假设您有 1 TB 的业务数据要从您的自管理数据中心迁移到云存储。您与您的 ISP 签订了商业计划，保证您 50 Mbps 的上传速度和 10 倍的下载速度。您所需要做的就是宣布一个短暂的系统停机窗口，然后开始将您的数据上传到云端。对吗？
不太对。
首先，您需要惊人的 47 小时才能以 50 Mbps 的速度完成 1 TB 数据的上传——这还是假设您的连接永远不会掉线或减速。
如果您升级到更快的——比如 100 Mbps——上传计划，您可以在一天内完成这项工作。但是，如果您有 2 TB、4 TB 或 10 TB 的内容要上传怎么办？即使在 100-Mbps 的持续数据传输速率下，您也需要令人难以置信的 233 小时才能移动 10 TB 的内容！
正如您所看到的，传统观念在太字节和拍字节级别上失效了。有必要研究处理如此大量数据的其他非显而易见的方法。
以下是当今可用于移动大数据的两种替代方案
• 将数据本地复制到存储设备，例如 LTO（线性磁带开放）磁带、HDD（硬盘驱动器）或 SSD（固态驱动器），然后将其寄送给云提供商。为方便起见，我们将此策略称为“寄送！”
• 使用来自源云和目标云提供商的 API（应用程序编程接口），通过互联网执行云到云的内容传输。6 我们将此策略称为“传输！”
本文将时间和成本方面比较这些替代方案与使用互联网连接将数据上传到云服务器的基线技术。这种基线技术简称为“上传！”。
真实场景
假设您想将您的内容上传到亚马逊 S3（简单存储服务）云，纯粹为了说明，特别是其位于俄勒冈州的数据中心。2 这很可能是该领域的其他参与者9（例如但不限于微软、谷歌、Rackspace 和 IBM）提供的任何其他云存储服务。此外，让我们假设您的私有数据中心位于密苏里州堪萨斯城，该城市恰好在地理位置上与亚马逊位于美国东部和西部的数据中心2 大致等距。
堪萨斯城也是美国少数几个可以提供千兆位速度光纤服务的地方之一。在这种情况下，它由 Google Fiber 提供。7
截至 2015 年 11 月，Google Fiber 提供美国 ISP 可以提供的最高速度之一：1 Gbps（千兆位/秒），用于上传和下载。13 在无法使用租用的千兆以太网11 线路的情况下，基于光纤的互联网服务是在世界任何地方上下互联网管道中推送比特的非常非常快的方法。
假设在这种基于光纤的连接上平均持续上传速度为 800 Mbps，13（即，其广告宣传的理论最大速度 1 Gbps 的 80%），上传 1 TB 的数据将需要近三个小时才能从堪萨斯城上传到俄勒冈州的 S3 存储。这实际上非常快（当然，假设您的连接永远不会减速）。此外，随着数据大小的增加，上传时间也以相同的比例增加：20 TB 需要 2½ 天上传，50 TB 需要将近一周上传，而 100 TB 需要两倍的时间。在另一端，半拍字节的数据需要两个月才能上传。以 800 Mbps 的速度上传一拍字节应该会让您持续四个月。
是时候考虑替代方案了。
寄送！
另一种选择是将数据复制到存储设备并将其寄送到数据中心，在该数据中心端将数据复制到云存储。这就是寄送！策略。在什么情况下，这是直接将数据上传到云端的切实可行的替代方案？
寄送数据的数学原理
当数据从驱动器中读出时，它从物理驱动器硬件（例如，HDD 盘片）传输到板载磁盘控制器（驱动器上的电子电路）。从那里，数据传输到主机控制器（又名主机总线适配器，又名接口卡），最后传输到主机系统（例如，驱动器与之连接的计算机）。当数据写入驱动器时，它遵循相反的路线。
当数据从服务器复制到存储设备（或反之亦然）时，数据必须通过额外的物理层传输，例如服务器和存储设备之间存在的以太网或 USB 连接。
图 1 是将数据复制到存储设备时数据流的简化视图。当数据从存储设备复制到云服务器时，图中显示的数据流方向在概念上是相反的。
请注意，通常存储设备可能只不过是一个硬盘驱动器，在这种情况下，从服务器到该驱动器的数据流基本上沿着图中的虚线进行。
鉴于这种数据流，使用寄送！策略将数据传输到云端所需时间的简单表达方式如公式 1 所示
其中
Vcontent 是要传输的数据量，以兆字节 (MB) 为单位。
SpeedcopyIn 是数据从源驱动器复制到存储设备的持续速率，单位为 MBps（兆字节/秒）。此速度本质上是三个速度中的最小值：（1）控制器从源驱动器读取数据并将其传输到与之连接的主机计算机的速度；（2）存储设备的控制器从其连接的主机接收数据并将其写入存储设备的速度；以及（3）两台主机之间的数据传输速度。例如，如果两台主机通过千兆以太网或光纤通道连接，并且存储设备能够以 600 MBps 的速度写入数据，但如果源驱动器及其控制器只能以 20 MBps 的速度发出数据，那么有效的复制速度最多只能为 20 MBps。
SpeedcopyOut 类似地是从存储设备复制出数据并写入云存储的持续速率，单位为 MBps。
Ttransit 是通过快递服务从源到目的地的运输时间，单位为小时。
Toverhead 是以小时为单位的开销时间。这可以包括购买存储设备（例如，磁带）、设置它们进行数据传输、包装和创建装运以及将其送到托运人所在地所需的时间。在接收端，它包括处理从托运人处收到的货物、临时存储、拆包和设置它们进行数据传输所需的时间。
持续数据传输速率的使用
存储设备有多种类型，例如 HDD、SSD 和 LTO。每种类型都有不同的配置，例如 HDD 或 SSD 的 RAID（独立磁盘冗余阵列），或 HDD-SSD 组合，其中一个或多个 SSD 用作 HDD 阵列的快速预读缓存。还有许多不同的数据传输接口，例如 SCSI（小型计算机系统接口）、SATA（串行 AT 附件）、SAS（串行连接 SCSI）、USB（通用串行总线）、PCI（外围组件互连）Express、Thunderbolt 等。这些接口中的每一个都支持不同的理论最大数据传输速度。
图 2 列出了其中一些控制器接口的最新版本支持的数据传输速度。
将数据复制到/从存储设备复制时的有效复制/复制出速度取决于许多因素
• 驱动器类型。 例如，SSD 通常比 HDD 快，部分原因是没有任何移动部件。在 HDD 中，较高 RPM 的驱动器比较低 RPM 的驱动器表现出更低的寻道时间。同样，较高面密度（每表面积比特数）的驱动器可以导致更高的数据传输速率。
• 驱动器的配置。 速度受到例如单磁盘与冗余磁盘阵列以及驱动器上是否存在预读缓存的影响。
• 数据在驱动器上的位置。 如果驱动器被碎片化（尤其适用于 HDD），则从驱动器读取数据和向驱动器写入数据可能需要更长的时间。同样，在 HDD 盘片上，靠近盘片外围的数据将比靠近主轴的数据读取得更快。这是因为盘片在外围附近的线速度比在主轴附近高得多。
• 数据传输接口类型。 例如，SAS-3 与 SATA Revision 3 可能会在速度上有所不同。
• 压缩和加密。 源端的压缩和/或加密以及目标端的解压缩和/或解密会降低有效的数据传输速率。
由于这些因素，有效的持续复制速度或复制出速度可能与源驱动器及其接口或目标驱动器及其控制器接口的突发读取/写入速率大相径庭（通常要小得多）。
考虑到这些因素，让我们通过公式 1 运行一些数字，考虑以下场景。您决定使用 LTO-6 磁带复制数据。 LTO-6 磁带盒可以以未压缩形式存储 2.5 TB 的数据。18 LTO-6 支持 160 MBps 的未压缩读/写数据速度。19 让我们做一个重要的简化假设，即源驱动器和目标云存储都可以匹配 LTO-6 磁带驱动器的 160-MBps 传输速度（即，SpeedcopyIn = SpeedcopyOut = 160 MBps）。您选择隔夜寄送选项，托运人需要 16 个小时才能交付货物（即，Ttransit = 16 hours）。最后，让我们考虑 48 小时的开销时间（即，Toverhead = 48 hours）。
将这些值代入公式 1 并使用寄送！策略绘制数据传输时间与数据大小的关系图，生成图 3 中的栗色线。为了进行比较，蓝色线显示了使用基于光纤的互联网连接以 800-Mbps 持续上传速率的上传！策略的数据传输时间。该图显示了以 800 Mbps 上传与将其复制到 LTO-6 磁带并隔夜寄送之间数据传输时间的相对增长。
公式 1 表明，寄送！策略中的大量时间用于将数据复制到存储设备和从存储设备复制数据。运输时间相对较短且恒定（即使您是国际运输），而驱动器到驱动器的复制/复制出时间随着要传输的内容大小的增长而增加到非常大的值。鉴于这一事实，很难在原始数据传输速度上击败基于光纤的连接，尤其是当竞争策略涉及使用以 160 MBps 运行的 LTO-6 磁带驱动器进行复制/复制出时。
然而，通常您可能没有那么幸运能够访问 1-Gbps 上传链接。在世界大多数地区，您可能最多只能获得 100 Mbps，如果能达到这个速度的话，而且很少能持续保持。例如，在 100 Mbps 时，对于大数据量，寄送！具有明显的优势，如图 4 所示，该图显示了以 100 Mbps 上传与将数据复制到 LTO-6 磁带并隔夜寄送之间数据传输时间的相对增长。
图 4 中的栗色线代表使用 LTO-6 磁带的寄送！策略的传输时间，而这次蓝色线代表使用 100-Mbps 上传链接的上传！策略的传输时间。对于低至 4 太字节的数据量，使用 LTO-6 磁带寄送数据是一种比以 100 Mbps 上传数据更快的方式。
如果您有更快的方式将数据复制到存储设备和从存储设备复制数据怎么办？这与以 800 Mbps 运行的基于光纤的互联网链接相比如何？在所有其他参数值保持不变的情况下，并假设驱动器到驱动器的复制/复制出速度为 240 MBps（比 LTO-6 可以支持的速度快 50%），拐点（即，寄送！策略比以 800 Mbps 上传！策略更快的内容大小）约为 132 太字节。对于更快的驱动器到驱动器的复制/复制出速度 320 MBps，拐点急剧下降到 59 太字节。这意味着如果内容大小为 59 TB 或更高，那么将数据寄送给云提供商比使用以 800 Mbps 运行的光纤 ISP 上传数据更快。
图 5 显示了以 800 Mbps 上传与以 320-MBps 传输速率复制并隔夜寄送之间数据传输时间的相对增长。
两个关键问题
此分析提出了以下两个问题
• 如果您知道您希望上传多少数据，那么您的 ISP 必须提供的最小持续上传速度是多少，低于这个速度，您最好通过隔夜快递寄送数据？
• 如果您的 ISP 向您承诺了某个持续上传速度，那么超过什么数据大小，寄送数据将比上传数据更快地将其运送到云端？
公式 1 可以通过估计将数据寄送到数据中心需要多长时间来帮助回答这些问题。这个量是 (传输时间)小时。现在想象一下，并行地通过网络链接上传相同数据量的 (Vcontent 兆字节)。问题是，完成所有数据上传到数据中心所需的最少持续上传速度是多少，时间与将其寄送到那里所需的时间相同。因此，您只需用（a）数据量（Vcontent 兆字节）；和（b）所需的最小互联网连接速度 (Speedupload Mbps) 来表示公式 1 的左侧（即，(传输时间)小时）。换句话说：(传输时间)小时 = 8 × Vcontent/Speedupload。
做出此替换后，让我们继续进行场景：基于 LTO-6 的数据传输以 160-MBps 运行，隔夜寄送 16 小时，以及 48 小时的开销时间。还要假设有 1 TB 的数据要传输到云端。
上述替换表明，除非 ISP 提供至少 34.45 Mbps 的持续上传速度 (Speedupload)，否则使用寄送！策略可以更快地传输数据，该策略涉及以 160 MBps 运行的基于 LTO-6 磁带的数据传输以及 64 小时的运输和处理开销。
图 6 显示了要传输的数据量（以 TB 为单位）与使上传数据与寄送到数据中心一样快所需的最小持续 ISP 上传速度（以 Mbps 为单位）之间的关系。对于非常大的数据量，阈值 ISP 上传速度对数据大小的敏感性降低，而对与之竞争的驱动器到驱动器的复制/复制出速度的敏感性更高。该图显示，上传！策略的数据传输时间与寄送！策略的数据传输时间相匹配的 ISP 上传速度是数据大小和驱动器到驱动器的复制/复制出速度的函数。
现在让我们尝试回答第二个问题。这次，假设 Speedupload （以 Mbps 为单位）是 ISP 可以提供的最大持续上传速度。超过什么最大数据大小，寄送数据到数据中心会更快？再次，回想一下公式 1 有助于估计给定数据大小 (Vcontent MB) 和驱动器到驱动器的复制/复制出速度将数据寄送到数据中心所需的估计时间 (传输时间)小时。如果您改为以 Speedupload Mbps 通过网络链接上传 Vcontent MB，您将需要 8 × Vcontent/Speedupload 小时。在 Vcontent 的某个阈值处，这两种传输时间（寄送与上传）将变得相等。可以重新排列公式 1 以表示此阈值数据大小
图 7 显示了对于不同的驱动器到驱动器的复制/复制出速度值，此阈值数据大小与可用的持续 ISP 上传速度之间的关系。该图显示，在中断数据传输大小（超过此大小，寄送！策略比上传！策略更快）方面的变化是 ISP 提供的上传速度和驱动器到驱动器的复制/复制出速度的函数。
公式 2 还表明，对于给定的驱动器到驱动器的复制/复制出速度值，Vcontent 的上升趋势持续到 Speedupload = 8/ΔTdata copy 的点，超过这个点，Vcontent 变得无限大，这意味着无论数据量有多么庞大，都不可能比简单地将其上传到云端更快地寄送数据。在这种情况下，除非您切换到更快的方式来复制数据进出存储设备，否则您最好只是将其上传到目标云。
同样，在基于 LTO-6 磁带的数据传输以 160-MBps 传输速度运行、隔夜寄送 16 小时和 48 小时开销时间的场景中，超过这个上传速度，总是上传比寄送数据更快的速度是 640 Mbps。如果您可以使用更快的驱动器到驱动器的数据复制方式——比如以 320 MBps 运行——您的 ISP 需要提供超过 1,280 Mbps 的持续上传速度，才能使您上传数据比复制和寄送数据更快。
云到云数据传输
另一种策略是将数据直接从源云传输到目标云。这通常使用来自源云和目标云提供商的 API 完成。数据可以在不同的粒度级别传输，例如逻辑对象、存储桶、字节 Blob、文件或简单的字节流。您还可以将大型数据传输安排为可以无人值守运行的批处理作业，并在完成或失败时提醒您。当以下情况时，尤其要考虑云到云数据传输
• 您的数据已经在一个这样的云存储提供商中，并且您希望将其移动到另一个云存储提供商。
• 源云和目标云存储提供商都提供数据出口和入口 API。
• 您希望利用云提供商已经提供的数据复制和调度基础设施和服务。
请注意，云到云传输在概念上与上传数据到云端相同，因为数据通过互联网连接移动。因此，与先前在将其与寄送数据到数据中心的策略进行比较时解释的速度考虑因素同样适用于它。另请注意，从源云到目标云的互联网连接速度可能与 ISP 提供的上传速度不同。
数据传输成本
与其他选项（如 HDD 或 SSD 存储）相比，LTO-6 磁带以每 GB 0.013 美分18 的价格提供了最低的成本与存储比率之一。然而，很容易看出，磁带盒的总成本对于存储太字节及以上的内容大小来说变得过高。一种选择是以压缩形式存储数据。例如，LTO-6 每盘磁带18 可以以压缩格式存储高达 6.25 TB 的数据，从而减少了磁带盒的数量。然而，在源端压缩数据并在目标端解压缩数据会进一步降低 LTO 磁带或任何其他存储介质的有效复制/复制出速度。如前所述，低复制/复制出速度会使寄送数据不如通过基于光纤的 ISP 链接上传数据有吸引力。
但是如果云存储提供商将存储设备借给您怎么办？这样，提供商有可能负担得起使用更高端的选项，例如高端 SSD 或存储设备中的 HDD-SSD 阵列组合，否则仅为了传输数据而购买这些选项将非常昂贵。事实上，这正是亚马逊似乎在其 AWS（亚马逊网络服务）Snowball3 中采取的方法。亚马逊声称，在不到一天的时间内，可以将高达 50 TB 的数据从您的数据源复制到 Snowball 存储设备中。这种性能特征转化为至少 600 MBps 的持续数据传输速率。只有使用具有预读缓存并以 SATA Revision 3、SAS-3 或 PCI Express 等快速接口以及存储设备千兆以太网链路运行的非常高端的 SSD/HDD 驱动器阵列才有可能实现这种数据传输速率。
事实上，AWS Snowball 的性能特征与高性能 NAS（网络附加存储）设备非常相似，它配备了 CPU、板载 RAM、内置数据加密服务、千兆以太网网络接口和内置控制程序——更不用说坚固耐用、防篡改的结构。Snowball 等服务的效用来自于云提供商向用户提供非常高性能（且昂贵）的类 NAS 设备，以“租用”的方式将文件复制到提供商的云中和从云中复制文件。其他主要的云提供商（如 Google 和 Microsoft）也在不甘落后地提供此类功能。微软要求您寄送 SATA II/III 内部 HDD，以便将数据导入/导出到/从 Azure 云，并提供准备驱动器以进行导入或导出所需的软件。16 另一方面，谷歌似乎已将数据复制服务外包给第三方提供商。8
关于成本的最后一点：除非您的数据位于自管理的数据中心，否则通常源云提供商会对数据出口4,5,12,15 收费，无论您是执行基于磁盘的数据复制出还是云到云数据传输。这些费用通常按每 GB、每 TB 或每次请求收取。目标云提供商通常不收取数据入口费用。
结论
如果您希望通过互联网将大数据从一个位置移动到另一个位置，那么有几种可用的选项——即，使用 ISP 提供的网络连接直接上传，将其复制到存储设备并将设备寄送到新的存储提供商，以及最后的云到云数据传输。
您选择哪种技术取决于许多因素：要传输的数据大小、源服务器和目标服务器之间持续的互联网连接速度、存储设备以及源驱动器和目标驱动器支持的持续驱动器到驱动器的复制/复制出速度、数据传输的货币成本，以及在较小程度上，运输成本和运输时间。其中一些因素导致阈值上传速度和阈值数据大小的出现，这些阈值从根本上影响您将选择哪种策略。驱动器到驱动器的复制/复制出时间对复制和寄送数据是否具有吸引力具有巨大影响，尤其是在与基于光纤的互联网链接竞争时，与通过互联网上传数据相比。
参考文献
1. Apple. 2015. Thunderbolt; http://www.apple.com/thunderbolt/。
2. Amazon Web Services. 2015. 全球基础设施; https://aws.amazon.com/about-aws/global-infrastructure/。
3. Amazon. 2015. AWS Import/Export Snowball; https://aws.amazon.com/importexport/。
4. Amazon. Amazon S3 定价。 https://aws.amazon.com/s3/pricing/。
5. Google. Google 云存储定价; https://cloud.google.com/storage/pricing#network-pricing。
6. Google. 2015. 云存储传输服务; https://cloud.google.com/storage/transfer/。
7. Google. Google fiber 扩展计划; https://fiber.google.com/newcities/。
8. Google. 2015. 离线媒体导入/导出; https://cloud.google.com/storage/docs/offline-media-import-export。
9. Herskowitz, N. 2015. 微软连续第二年被 Gartner 评为公共云存储服务领域的领导者; https://azure.microsoft.com/en-us/blog/microsoft-named-a-leader-in-gartners-public-cloud-storage-services-for-second-consecutive-year/。
10. SCSI Trade Association. 2015 年 10 月 14 日. 串行连接 SCSI 技术路线图; http://www.scsita.org/library/2015/10/serial-attached-scsi-technology-roadmap.html
11. IEEE. 802.3: 以太网标准; http://standards.ieee.org/about/get/802/802.3.html。
12. Microsoft. Microsoft Azure 数据传输定价详情; https://azure.microsoft.com/en-us/pricing/details/data-transfers/。
13. Ookla. 2015. 美国最快的 ISP 和移动网络; http://www.speedtest.net/awards/us/kansas-city-mo。
14. PCI-SIG. 2011. 新闻稿：PCI Express 4.0 演进到 16GT/s，是 PCI Express 3.0 技术吞吐量的两倍; http://kavi.pcisig.com/news_room/Press_Releases/November_29_2011_Press_Release_/。
15. Rackspace. 2015. Rackspace 公共云按需付费定价; http://www.rackspace.com/cloud/public-pricing。
16. Shahan, R. 2015. Microsoft Corp. 使用 Microsoft Azure 导入/导出服务将数据传输到 Blob 存储; https://azure.microsoft.com/en-in/documentation/articles/storage-import-export-service/。
17. The Serial ATA International Organization. 2015. SATA 命名指南; https://www.sata-io.org/sata-naming-guidelines。
18. Ultrium LTO. 2014. LTO-6 容量数据表; http://www.lto.org/wp-content/uploads/2014/06/ValueProp_Capacity.pdf。
19. Ultrium LTO. 2014. LTO-6 性能数据表; http://www.lto.org/wp-content/uploads/2014/06/ValueProp_Performance.pdf。
20. USB Implementers Forum. 2013. 超高速 USB (USB 3.0) 性能将通过新功能翻倍; http://www.businesswire.com/news/home/20130106005027/en/SuperSpeed-USB-USB-3.0-Performance-Double-Capabilities。
萨钦·达特 (Sachin Date) (https://in.linkedin.com/in/sachindate) 负责 e-Emphasys Technologies (e-Emphasys 技术公司) (www.e-emphasys.com) 的微软和云应用产品组合。在过往的职业生涯中，达特曾担任移动技术部门主管、企业软件架构师以及自主软件代理研究员。他在 https://sachinsdate.wordpress.com 上撰写博客。他拥有马萨诸塞大学阿默斯特分校计算机科学硕士学位。
版权 © 2016 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue 杂志第 14 卷，第 2 期 —
在 数字图书馆 中评论这篇文章
更多相关文章
马克·布鲁克 (Marc Brooker), 安库什·德赛 (Ankush Desai) - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法（如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分 - 也许最重要的是，形式化规范作为测试预言机，为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，并且在这些领域的投资已经看到了出色的回报，这加速了这些领域的发展。
阿基里斯·贝内托普洛斯 (Achilles Benetopoulos) - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，只有通过将系统部署为多个冗余组件的集合才能满足这些要求；高持久性要求只能通过数据复制来满足，有时甚至跨越广阔的地理距离。
大卫·R·莫里森 (David R. Morrison) - 模拟：分布式系统中未被充分利用的工具
模拟在人工智能系统的兴起中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练人工智能代理在我们的基础设施中运行，而模拟绝对提供了这种能力。
马特·法塔 (Matt Fata), 菲利普-约瑟夫·阿里达 (Philippe-Joseph Arida), 帕特里克·哈恩 (Patrick Hahn), 贝琪·拜尔 (Betsy Beyer) - 从企业到云端：谷歌的虚拟桌面
超过四分之一的谷歌员工使用内部、数据中心托管的虚拟桌面。这种本地部署的产品位于公司网络中，允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。其中最显著的特点是，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的谷歌员工。直到最近，我们的虚拟桌面都托管在谷歌公司网络上使用名为 Ganeti 的自研开源虚拟集群管理系统的商用硬件上。如今，这项重要且对谷歌至关重要的工作负载在 GCP (Google Compute Platform) 上运行。
© 版权所有。