ACM通信
实践
Hadoop超线性可扩展性
图片来源:Steve Ball
“我们经常看到超过100%的加速效率!”有人天真地提醒说，任何事情都不能超过100%。这只是软件工程师们在一场关于如何根据加速指标来量化计算机系统可伸缩性的演讲中抛出的第一个问题。在不同的场合，在随后的场合，这种反驳似乎成长为一个真正的合唱，不仅超线性加速是普遍观察到的，而且过去20年用来量化可伸缩性的模型——通用可伸缩性定律(USL)在应用于超线性加速数据时失败了。
事实上，随着新的应用程序部署到分布式体系结构上，超线性加速是一种真正的现象，可以预期在实践中会更频繁地出现。然而，正如这里使用Hadoop MapReduce演示的那样，USL不仅能够以一种令人惊讶的简单方式容纳超线性加速，它还揭示了超线性，尽管诱人，但就像永动机一样虚幻。
精心设计,图1从概念上说明了线性加速(虚线)是在扩展应用程序时通常期望获得的最佳效果。线性意味着你从你的产能中得到了同等的回报，因为可用的产能以100%的效率消耗。然而，更常见的是，其中一些容量被各种形式的开销所消耗(红色区域)。这对应于应用程序可用容量的不断减少，因此它以次线性方式扩展(红色曲线)。另一方面，超线性加速(蓝色曲线)似乎来自某种隐藏的容量提升(绿色区域)。
正如我们将要演示的，超线性是一种真正可测量的效应，4，12，14，19，20.，21，2223因此，重要的是要准确理解它代表什么，以便在调整分布式系统的可伸缩性时解决它。据我们所知，以前没有人这样做过。
尽管可测量性，超线性让人想起永动机索赔。永动机之所以吸引人，是因为人们认为它能产生比消耗更多的功或能量。就计算机性能而言，超线性相当于超出计算机可用容量的加速。对于这个讨论来说，更重要的是，当涉及到永动机时，困难的部分并不在于判断该主张是否违反了能量守恒定律;困难的部分是调试这台机器要找出逻辑上的缺陷。有时这种努力甚至可能是致命的。5
如果，从表面上看，超线性类似于永动机，为什么有些软件工程师会宣称它无处不在，而不是调试它?这种繁荣源于对业绩数据的过度信任。公平地说，这种错位的信任可能来自于性能数据通常在没有任何测量误差迹象的情况下呈现的方式。我们所知道的开源或商业性能工具没有显示测量误差，即使所有的测量都包含误差。简单地说，从定义上看，所有的测量都是“错误的”:唯一的问题是，在多大程度上“错误”是可以容忍的?如果不量化测量误差，就无法回答这个问题。(在本文后面，表2量化Hadoop的测量误差。)
除了确定测量误差之外，所有性能数据都应该在验证方法的上下文中进行评估。其中一种方法是性能模型。在超线性加速的背景下，USL6，7，8，9，10，11，17，18以一种相对简单的方式完成这个角色。
通用可扩展性模型
为了更正式地量化可伸缩性，我们首先在公式1中定义经验加速度量:
在哪里Tp测量的运行时是否打开p= 1,2,3，…处理器或集群节点。14从多模式运行时开始Tp预期比单节点运行时要短T1，加速一般为的离散凹函数p。可以确定以下特殊情况。
- 线性可伸缩性。如果Tp＝T1/p对于每个集群配置，加速都有值年代p= 1,2,3，…为每一个p,分别。加速函数具有线性可伸缩性(在图1)．
- 次线性可伸缩性。如果Tp>T1p对于每个集群配置，后续的加速值将为劣质(红色曲线)与线性可扩展性绑定图1．例如，如果p= 2和T2= 3T1/ 4,然后年代2= 1.33。因为它小于年代2= 2时，加速是次线性的。红色曲线是在单片系统和分布式系统上观察到的最常见的可伸缩性形式。
- 于超线性可伸缩性。如果Tp<T1/p，则连续加速值将优于(蓝色曲线)的线性界图1．例如，如果p= 2和T2＝T1/ 3,然后年代2= 3，大于线性加速。
任何计算机系统的可伸缩性都可以通过比较公式1中的测量加速和这里定义的理论预期加速来验证。
可伸缩性的组成部分。可伸缩性，被视为计算机硬件和软件的集合，可以被认为是由几个物理因素造成的:
- 理想并行或最大并发。
- 共享资源的争夺。
- 主要瓶颈资源导致的饱和。
- 在非本地资源之间交换数据，以达到一致性或数据一致性。
这还没有考虑到超线性。这些因素对可伸缩性的个别影响，如公式1中的加速度量所衡量，如图所示图2．
每一种缩放效应也可以在分析性能模型中表示为单独的术语:USL。在我们通常的符号中，7，8我们将公式2中的理论加速写成:
其中系数表示系统的竞争程度，系数表示分布式数据的不一致性。
的争用方程2中的项随集群节点数线性增长，p，因为它表示等待共享资源(如消息队列)的成本。相干项随的二次增长p因为它表示通过分布式资源(例如，处理器缓存)之间的成对交换使分布式数据一致(或一致)的成本。
解释系数。如果= 0和= 0，则加速简化为年代p =p，对应于图2一个．如果> 0，加速开始偏离线性(图2 b)，即使节点配置相对较小。随着节点数量的持续增长，加速接近上限，年代天花板＝1的水平虚线表示图2 c．的两个三角形图2 c说明这是一个收益递减的区域，因为两个三角形的宽度相同，但右三角形的垂直收益小于左三角形。
如果> 0，加速将最终降级为p1．因此，连续可伸缩性曲线必须经过最大值或峰值，如图2 d．虽然两个三角形都是相等的，但峰值右侧的三角形是相反的，表明斜率已变为负的区域。
从数学的角度来看，USL是一个基于有理函数的参数模型，7可以想象继续把连续的多项式项加进去p取方程2的分母，每个都有相应的系数。然而，对于> 0，存在一个最大值，并且通常没有什么好处来分析描述可伸缩性如何在超过这个点之后下降。如果可能的话，首选的目标是完全去除峰值——因此得名普遍的。
核心思想是将方程1中测量的加速与方程2中定义的USL相匹配。对于给定的节点配置p，这只能通过调整和系数来实现。在实践中，这是通过非线性统计回归来实现的。8，17(Varnish, Memcached和Zookeeper应用的可扩展性在ACM队列本文的版本)。
云中的Hadoop Terasort
为了在受控环境中探索超线性，我们使用了众所周知的工作负载——TeraSort基准测试，15，16运行在Hadoop MapReduce框架上。3.，24但是，我们没有使用物理集群，而是将其安装在Amazon Web Services (AWS)上，以提供重新配置足够多的节点的灵活性，以及以相对于相应物理系统的一小部分成本并行运行多个实验的能力。
Hadoop框架概述。在TeraSort中讨论超线性加速需要熟悉Hadoop框架及其术语。24特别地，本节提供了一个高层次的概述，主要关注那些与后面的性能分析相关的Hadoop组件。
Hadoop框架旨在促进编写大规模的、数据密集型的分布式应用程序，这些应用程序可以以可靠的、容错的方式运行在商品硬件的多节点集群上。这是通过为应用程序开发人员提供两个编程库来实现的:
- MapReduce，一个分布式处理库，通过将整个作业分解为一组独立的任务，可以轻松地编写应用程序以适应并行执行。
- Hadoop分布式文件系统(HDFS)，它允许数据存储在任何节点上，但Hadoop集群中的任何任务仍然可以访问数据。使用MapReduce库编写的应用程序被组织成一组可以并行执行的独立任务。这些任务分为两类:
- 地图的任务。Map任务的功能是获取整个输入数据集的一个片段，并将其转换为键值对，通常用<表示键,值>在MapReduce上下文中。的节点1中详细的Map-tasks数据流图3其中Map任务以示意图的形式表示为一个过程Map(k、v)．除了执行此转换之外，Map任务还按键对数据进行排序，并存储已排序的<k、v>对象，因此它们可以很容易地与Reduce任务交换。
- 减少任务。Reduce任务的功能是收集所有<k、v>对象，并将它们转换为新的<k、v>对象，其中键的值是特定的键，其值是一个列表[v1，v2,……的所有<k, (v1，v2,……>对象，其键是整个输入数据集的特定键。节点1图3显示了详细的Reducetask数据流。
MapReduce应用程序使用以下工作流处理其输入数据集。在启动时，应用程序为输入数据集的每个片创建和调度一个Map任务，并创建用户定义数量的Reduce任务。然后，这些Map任务在输入数据的每个片上并行工作，有效地将其排序并划分到一组文件中，其中所有<k、v对具有相同键值的>对象进行分组。一旦所有Map任务完成，就会通知Reduce任务开始读取分区，将这些中间数据转换并组合为新的<k, (v1，v2,……) >对象。这个过程被称为洗牌交换，图示于图3作为跨越物理节点1、2、…p。
为了方便以分布式方式运行应用程序，MapReduce库提供了一个分布式执行服务器，它由一个名为JobTracker的中心服务和一些名为tasktracker的从服务组成。24JobTracker负责调度任务并将任务传输到驻留在每个集群节点上的tasktracker。JobTracker还可以检测并重新启动可能失败的任务。它提供了一定程度的容错。用户通过一个JobClient组件(如TeraSort)与Hadoop框架交互，该组件提供对MapReduce作业的监视和控制。
为了支持MapReduce任务的执行，Hadoop框架中包含了HDFS, HDFS是一个采用主从架构的存储集群。它提供了一个可靠的分布式文件服务，允许Hadoop应用程序以固定大小块(TeraSort中为128MB)的高吞吐量读写非常大的数据文件3.)跨集群。HDFS集群中的主节点是NameNode，它负责规范客户端对文件的访问，以及通过将文件块映射到其存储位置来管理文件系统命名空间，该存储位置可以驻留在datanode(即NameNode的从节点)上。HDFS的一个关键特性是它对节点磁盘故障的内置弹性，通过跨多个datanode复制块来实现。默认的复制因子是3，但在TeraSort中将其设置为1。
中描述的洗牌交换过程是值得注意的图3涉及Map和Reduce任务之间的交互，这通常会导致数据在不同的物理节点上被“Reduce”。由于这种交换发生在MapReduce对之间，所以它随集群节点的数量成二次增长，这与USL相干项精确对应，p（p1)，式2 (图2 d)．这一点对于以后的超线性加速性能分析是很重要的。此外，尽管排序代表MapReduce工作负载的最坏情况，但在不同的Hadoop应用程序中，相似的一致性阶段会以不同的量级出现。物理一致性效应的实际大小反映在USL对Hadoop性能数据的分析得出的系数值中。
在AWS上运行TeraSort。TeraSort是一个合成的工作负载，最近被用来对Hadoop MapReduce的性能进行基准测试15，16通过测量对1TB随机生成的数据进行排序所花费的时间。一个名为TeraGen的单独程序生成输入数据，包括100字节的记录，其中前10个字节用作键。
在Hadoop集群上设置TeraSort的脚本很容易获得。这里的性能目标是使用TeraSort检查超线性可伸缩性现象，而不是调优集群以产生竞争性基准测试所需的最短运行时间。15，16
Amazon的弹性计算云(EC2)提供了具有各种实例类型和大小的集群的快速和廉价供应(例如，在表1)．为了保持运行多个实验的时间和成本可控，数据生成被限制为100GB，集群配置使用本地实例存储(而不是弹性块存储)保持在少于200个EC2节点。
EC2实例类型m2.2xlarge而且c1.xlarge的区别在于前者具有5倍的内存，但只有一个硬盘，一半的核数和更高的网络延迟，而后者有4个硬盘和更低的网络延迟。我们在这里将它们分别称为BigMem和BigDisk，而不是遵循笨拙的Amazon命名法。这些命名强调了关键的容量差异，这对以后的性能分析非常重要。
Apache心烦1是一组Java库，用于运行支持Amazon EC2的云服务。我们将它与自定义bash脚本一起使用，以:指定集群大小和实例类型;引导EC2集群;安装Hadoop;准备并运行TeraSort;收集性能指标。
Whirr被配置为创建一个由运行Linux CentOS 5.4的EC2实例组成的集群，并安装了Hadoop 1.0的Cloudera CDH 4.7.0发行版。3.该发行版中包括Hadoop-examples.jar该文件包含TeraGen和TeraSort MapReduce作业的代码。Whirr可以从属性文件中读取所需的配置，也可以接收从命令行传递的属性。这允许永久存储不更改的参数(例如，操作系统版本和Amazon凭据)。
我们收集了三组绩效指标:
- TeraSort作业(不包括TeraGen作业)的运行时间。
- hadoop生成的作业数据文件。
- Linux性能指标。
其中，最重要的指标是运行时间，它是使用Posix时间戳以毫秒为单位记录的(因为EC2硬件支持它)，通过shell命令记录的图4．
运行时性能指标(例如内存使用率、磁盘IO率和处理器利用率)是使用Linux性能工具up-time、vmstat和iostat从每个EC2节点捕获的。每两秒钟解析一次性能数据并将其追加到一个文件中。
永恒运动的标志图5显示TeraSort加速数据(点)和拟合的USL可伸缩性曲线(蓝色)。线性界(虚线)被包含以供参考。加速数据位于或高于线性界限提供了直观的证据，证明可伸缩性确实是超线性的。与线性拟合不同，21USL回归曲线在原点附近呈现出凸的趋势，这与一般的超线性剖面一致图1．
完全出乎意料的结果是USL争用系数发展成一个负取值:= 0.0288。这个结果也与断言相矛盾8对于物理一致性，两者都必须是积极的，这可能是批评USL在超线性加速数据上失败的原因。
如前所述，正值的值与共享资源的争用有关。例如，执行用户级任务的同一处理器可能还需要容纳IO请求等操作系统任务。处理器容量是由工作消耗的，而不是应用程序本身。因此，应用程序吞吐量小于预期的容量损失的线性影响。
中容量消耗(> 0)为次线性可伸缩性组件图2 b．相反，< 0可以被认为是某种容量提升。稍后将对此解释。
此外，(正)相干系数= 0.000447意味着在加速中必须有一个峰值，USL预测为年代马克斯= 73.48，发生于p= 48个节点。更重要的是，这也意味着USL曲线必须越过线性界，进入如图所示的回收区图6．
USL模型预测这种从超线性区域到回报区域的交叉必须发生，原因如下。的大小虽然很小，但也要乘以(p1)在方程2中。因此，随着节点数量的增加，差值为1 (p1)，在方程2的分母逐渐变小，以致年代p最终由相干性项所主导，p（p1）.
图7包括额外的加速测量(平方)。拟合的USL系数现在明显小于图5．最大加速，年代马克斯，因此，比用中数据预测的高约30%图5发生在p= 95个节点。加速的测量值与最初的USL预测值不同，不是因为USL是错误的，而是因为现在有比以前更多的可用信息。此外，这证实了USL的关键预测，超线性加速达到最大值，然后迅速下降到回报区域。
根据USL分析，可伸缩性曲线预期在处跨越线性边界px由式3给出的节点:
的虚线曲线图7时，交叉发生在px= 65个节点，而对于实体曲线，它出现在px= 99个节点。像预测年代马克斯，两者的区别px预测来自于两组测量中包含的信息量的差异。
追捕超线性毒蛇
在使用USL模型验证TeraSort数据后，需要进行更深层次的性能分析，以确定超线性的原因。让我们先仔细检查每个EC2集群配置的实际运行时度量。
运行时数据分析。为了对运行时度量中的错误进行统计确定，我们对每个节点配置重复执行了一些运行。根据这个样本量，可以根据标准误差或相对误差计算出不确定度的合理估计，这更直观。
对于每个运行时表2其中，±号前的数为样本均值，±号后的误差项为样本方差。相对误差(r.e)是标准误差与报告的平均值的百分比之比。
从这个数值分析中可以立即看出的是相对误差的显著变化，其范围从3%(名义上的)到9%，这可能需要进一步关注。测量误差的这种变化并不意味着测量技术不可靠;相反，它意味着运行时数据中存在较高程度的分散，其原因在此级别的分析中无法识别。
运行时的这种变化也不是我们EC2测量所特有的。雅虎TeraSort基准测试团队也注意到它们执行时间的显著变化，尽管他们没有量化这些变化。“虽然我拥有910个节点，但网络核心是与另一个活跃的2000个节点集群共享的，所以时间根据其他活动有很大差异。”15
雅虎团队的一些变异来源可能与我们的不同(例如，10倍大的集群大小可能是雅虎的一些变异的原因)。“请注意，在任何大型集群和分布式应用程序中，都有很多移动部件，因此我们看到了执行时间的巨大变化。”16
一个令人惊讶的假设。雅虎基准测试团队使用的物理集群配置包括带有两个四核Xeon处理器(即每个节点共8核)的节点和4个SATA磁盘。16中的BigDisk EC2配置非常类似表1．因此，我们在BigDisk集群上重复了TeraSort可伸缩性度量。结果是p= 2、3、5和10个集群进行比较图8．
符合图5， BigMem加速值图8的BigDisk节点是超线性的，而图8 b意外地显示线性或次线性的加速值。通过将每个集群节点的局部主轴数从1个增加到4个，超线性效应基本上已经被消除了。换句话说，增加节点IO带宽会导致反直觉的结果，即可伸缩性从超线性退化为次线性。
为了解释为什么超线性效应减弱了，我们通过识别BigMem和BigDisk之间的关键性能差异，形成了一个可行的假设。
BigMem有更大的内存配置，这可能为TeraSort数据提供更多的CentOS缓冲区缓存，这可以被认为是与负USL争用系数相关的容量提升的来源。与集群大小成比例的增量内存增长是超线性加速的常见解释。4，14然而，增加内存大小可能不是Hadoop TeraSort中容量提升的来源。如果缓冲区缓存填满到需要写入磁盘的位置，则会花费更长的时间，因为BigMem上的每个节点只有一个本地磁盘。的单盘DataNode图3意味着所有磁盘IO都是序列化的。从这个意义上说，当磁盘写入(包括复制)发生时，TeraSort是IO绑定的，尤其是在单节点情况下。随着集群配置越来越大，这个潜在的IO约束变得不那么严重，因为每个节点必须写入磁盘的数据量与节点数量成比例地减少。因此，连续的集群大小显示出比单节点情况更短的运行时，这导致了中所示的超线性加速值图8．
相反，尽管BigDisk每个节点的物理内存较少，但每个DataNode都有四盘，这意味着每个节点都有更大的磁盘带宽来容纳更多的并发IOs。因此，TeraSort不太可能成为IO约束。由于没有潜在的单节点IO约束，因此没有发挥能力提升的作用。结果，加速值更加正统，落入的次线性区域图8 b．
注意，由于Yahoo基准测试团队使用每个节点有四个SATA磁盘的集群配置，他们可能没有观察到任何超线性效应。此外，他们专注于测量基准竞争的运行时间，而不是加速，因此超线性只能作为执行时间观察到Tp坠落的速度比p1．
控制台堆栈跟踪。下一步是根据每次运行期间收集的Hadoop指标验证IO瓶颈假设。当TeraSort在BigMem上运行时，在与Hadoop JobTracker通信的Hadoop Job-Client控制台中观察到任务失败。以下是失败任务状态消息的缩写形式，其显著标识符以粗体显示图9．
由于TeraSort作业继续进行，并且所有任务最终都成功地完成了，所以我们最初不考虑这些失败报告。后来，考虑到IO瓶颈假设，我们意识到这些故障似乎只发生在Reduce阶段。同时，当控制台中出现故障时，Reduce任务%Complete值立即下降。换句话说，Reduce任务的进度开始倒退。此外，考虑到堆栈跟踪中的失败涉及Java类DFSOutputStream，我们猜测错误发生时，试图写入HDFS。这建议检查服务器端Hadoop日志，以确定为什么Reduce失败与HDFS写操作相关。
Hadoop日志分析。搜索相同的Hadoop集群日志失败TASK_ATTEMPT_ID，显示了对应的记录，如图10．
这个记录表明Hadoop集群上的Reduce任务实际上失败了，而不是JobClient。的调用期间发生的失败DFSOutputStream，这也表明在物理上将数据写入HDFS时出现了问题。
此外，日志中的后续记录具有相同的任务ID，如图11，有一个较新的TASK_ATTEMPT_ID(即，后面的1而不是后面的0)是成功的。
此日志分析表明，如果Reduce任务未能完成当前对磁盘的写操作，它必须重新开始重写相同的数据，直到成功。事实上，可能会有多次失败和重试(参见表3)．前面提到的运行时度量的变化掩盖了Reduce重试在运行时上的潜在差异，这也是10%的量级。
表3显示了对应于12个并行TeraSort作业的12行，每个作业都运行在自己的BigMem单节点集群上。Hadoop作业历史日志中存储了一组指示每次运行如何执行的指标，并使用Hadoop日志工具提取这些指标。13
840 Map任务由TeraSort作业决定，该作业将100(二进制)GB的数据划分为128(十进制)MB的HDFS块。没有发生映射失败。Reduce任务的数量设置为每个集群节点3个。失败的Reduce任务数量在0到4之间随机变化。相比之下，对应的BigDisk用例没有出现Reduce失败。
Hadoop作业的平均运行时为13057078.67 ms，如图所示T1在表2．额外的统计分析揭示了Reduce任务重试次数和较长的运行时间之间的强烈相关性。回想一下加速的定义，如果平均单节点运行时，T1的连续值pTp，则加速将是超线性的。
哪里减少失败了?reduce失败的次数表3表示Reduce任务的写操作失败，导致它重试写操作，可能是多次。此外，由于这些额外的重试，失败的Reduce任务往往会导致更长的运行时间。唯一悬而未决的问题是，首先是什么原因导致写操作失败?我们已经知道在失败期间涉及到写操作，这建议检查HDFS接口。
返回到先前失败的Reduce堆栈跟踪，仔细查看会发现以下行，其中重要的关键字以粗体显示图12．
“所有的datanode都是坏的Java IOException表示HDFS DataNode管道图13已经达到了一种状态setupPipelineForAppendOrRecovery方法，在DFSOutputStreamJava类，写操作无法恢复，Reduce任务无法完成。
当管道畅通时，Reduce任务调用HDFSClient，然后HDFSClient启动HDFS DataNode管道的创建。HDFSClient打开一个DFSOutputStream并为写作做好准备(1.写在图13)，在DataNode上分配HDFS数据块。的DFSOutputStream然后将数据流分解为更小的数据包。在它传送每个数据包之前，要由DataNode (2.写包)，它将该包的副本推到队列中。DFSOutputStream将该包保持在队列中，直到它收到一个确认(3.ACK包)从每个写操作成功完成的DataNode返回。
当抛出异常时(例如，在堆栈跟踪中)DFSOutputStream尝试通过重新处理数据包来补救这种情况，以完成HDFS的写操作。的DFSOutputStream可以进行额外的补救尝试，最多比复制因子少一次。然而，在TeraSort的情况下，由于复制因子被设置为1，缺少单个HDFS包确认将导致整个DFSOutputStream写操作失败。
的DFSOutputStream试图以一种不受约束的方式处理它的数据，假设datanode将能够跟上并响应确认。但是，如果DataNode上的底层IO子系统不能满足这种需求，一个未完成的数据包可能长时间不被确认。由于在TeraSort的情况下只有一个复制，因此不进行补救。相反,DFSOutputStream立即将未完成的写包视为AWOL，并抛出一个异常，该异常传播回Reduce任务图13．
由于Reduce任务不知道如何处理这个IO异常，所以它使用一个TASK_STATUS =“失败”。MapReduce框架最终将重试整个Reduce任务，可能不止一次表3)，这将反映在一个拉伸T1最终负责观察到的超线性加速的值。
这种对减少失败的操作见解可用于构造一个简单策略列表，以避免运行时拉伸。
- 调整缓冲区缓存的大小。
- 调优内核参数以提高IO吞吐量。
- 重新配置Hadoop默认超时。
如果维护bigmemi类型的集群是由非工程需求(例如，预算限制)决定的，那么这些步骤中的任何一个都可能有助于改善超线性效应。
结论
通过在Amazon EC2上运行Hadoop TeraSort执行的大量受控度量暴露了超线性的潜在原因，否则很难在现场解决。将我们的加速数据与USL性能模型进行拟合，产生了一个负的竞争系数，作为BigMem集群上超线性的迹象。
负号的减法效应在凸超线性曲线中引入一个拐点，使其最终变为凹的，从而越过在的线性界px在方程3中。在这一点上，Hadoop TeraSort超线性可伸缩性在回报区域返回为次线性。集群大小px提供了在BigMem集群上改进超线性加速所需的最小节点容量的估计。
尽管超线性是一种真实的现象，但就像永动机一样，它最终只是一种表现幻觉。对于BigMem上的TeraSort，明显的容量提升可以追溯到随着集群规模的增长，每个节点的潜在IO带宽限制不断放松。这个IO瓶颈导致HDFS流水线在Reduce任务中出现随机故障。这将导致Hadoop框架重新启动Reduce任务文件写入，从而拉长测量的运行时。如果运行时拉伸对T1，则连续的加速测量将是超线性的。增加每个节点的IO带宽，就像我们在BigDisk集群中所做的那样，通过减少或消除超线性加速T1伸展运动。
USL的分析表明，超线性可伸缩性不是Hadoop上TeraSort特有的，任何MapReduce应用程序都可能出现这种情况。在关系数据库系统中也观察到超线性加速。2，12然而，对于高性能计算应用程序，超线性加速可能与这里给出的解释不同。4，14，20.
抛开超线性不谈，对于许多读者来说，更重要的收获可能是以下几点。与大多数软件工程项目不同，Hadoop应用程序只需要固定的开发工作。一旦应用程序被证明可以在小型集群上工作，Hadoop框架就可以方便地将其扩展到任意数量的节点，而不需要额外的工作。对于许多MapReduce应用程序来说，由于数据量的增长需要更多的map，所以对磁盘存储的需求可能比计算能力更能驱动向外扩展。这个不幸的词平的可伸缩性已经被用来描述这种效应。25
尽管对于最初的开发过程来说，平坦的可伸缩性可能是一个合理的假设，但它并不能保证不付出大量额外努力就能满足诸如批处理窗口、通信容量或服务级别目标等性能目标。扁平化可伸缩性原则背后没有明确的假设是Hadoop应用程序是线性扩展的(图2一个)或近似线性(图2 b)．然而，任何shuffle-exchange处理都会在可伸缩性概要文件的某个地方引起峰值(图2 d)．峰值发生时的Hadoop集群大小可以通过对小集群测量应用USL来预测。缓和峰值所需的性能工程工作通常会远远超过平面可伸缩性假设。正如本文所努力展示的，USL为软件工程师提供了分析Hadoop可伸缩性的有价值的工具。
致谢
我们感谢Comcast公司支持在这项工作中使用Hadoop数据的获取。
相关文章
在queue.acm.org
Hazy:让构建和维护大数据分析变得更容易
阿伦·库马尔，牛峰，克里斯托弗Ré
http://queue.acm.org/detail.cfm?id=2431055
方式来表述数据并行处理的计算
底盘。博伊德
http://queue.acm.org/detail.cfm?id=1365499
共管公寓与云
帕特Helland
http://queue.acm.org/detail.cfm?id=2398392
参考文献
1.Apache心烦;https://whirr.apache.org．
2.卡尔弗特和库尔卡尼。LINQ至关重要。皮尔逊教育，马萨诸塞州波士顿，2009年。
3.Cloudera Hadoop;http://www.cloudera.com/content/cloudera/en/downloads/cdh/cdh-4-7-0.html/．
4.Eijkhout, V。高性能科学计算导论，“，”Lulu.com, 2014年。
5.费曼，R.P.帕普永动机;http://hoaxes.org/comments/papparticle2.html．
6.大规模并行交易系统的一个简单容量模型。在国际计算机测量小组会议论文集,(1993)。
7.基于有理函数的计算可扩展性的一般理论，2008;http://arxiv.org/abs/0808.1431．
8.冈瑟,新泽西州游击能力规划:为高度可扩展的应用和服务进行规划的战术方法。施普林格，纽约，纽约，2007年。
9.一个高速增长的电子商务网站的性能和可伸缩性模型。性能工程。R.R. Dumke, C. Rautenstrauch, A. Schmietendorf和A. Scholz，编。A.计算机科学2047(2001)课堂讲稿。斯普林格出版社267282年版。
10.PostgreSQL可伸缩性分析解构。绩效的精髓, 2012;http://perfdynamics.blogspot.com/2012/04/postgresqlscalability-analysis.html．
11.Gunther, n.j.， Subramanyam, s和Parvu, s memcached和好友中隐藏的可伸缩性问题。VELOCITY Web性能与操作会议，(2010)。
12.Haas, R.可扩展性，图形形式，分析，2011;http://rhaas.blogspot.com/2011/09/scalability-in-graphical-form-analyzed.html．
13.Hadoop Log Tools;https://github.com/melrief/Hadoop-Log-Tools．
14.轩尼诗，J.L.和帕特森，地方检察官计算机体系结构:定量方法。第二版。摩根·考夫曼，沃尔瑟姆，马萨诸塞州，1996年。
15.O’malley, O. Apache Hadoop上的TeraByte排序，2008;http://sortbenchmark.org/YahooHadoop.pdf．
16.O'Malley, O.， Murthy, a.c. 2009。与黄色大象一起赢得60秒的冲刺;http://sortbenchmark.org/Yahoo2009.pdf．
17.绩效动力公司。如何量化可扩展性，2014;http://www.perfdynamics.com/Manifesto/USLscalability.html．
18.volttdb真的像他们声称的那样可扩展吗?Percona MySQL性能博客;http://www.percona.com/blog/2011/02/28/is-voltdb-really-as-scalable-as-they-claim/．
19.sFlow。SDN分析和sFlow标准超线性控制http://blog.sflow.com/2010/09/superlinear.html．
20.Stackoverflow。超线性加速从何而来?http://stackoverflow.com/questions/4332967/where-does-super-linear-speedup-come-from
21.Sun Fire X2270 M2超线性伸缩Hadoop TeraSort和CloudBurst基准，2010;https://blogs.oracle.com/BestPerf/entry/20090920_x2270m2_hadoop．
22.萨特，h，超线性。多布医生的J. 333 (2008);http://www.drdobbs.com/cpp/going-superlinear/206100542．
23.萨特，h，超线性和更大的机器。多布医生的J. 33， 4 (2008);http://www.drdobbs.com/parallel/super-linearity-and-the-biggermachine/206903306．
24.白色,T。Hadoop:权威指南，第三版。奥莱利媒体，2012年。
25.雅虎Hadoop教程;https://developer.yahoo.com/hadoop/tutorial/module1.html#scalability．
数据
图2。公式2中的USL模型如何描述可伸缩性。
图3。Hadoop MapReduce数据流与节点1展开显示任务细节。
图4。用于记录Terasort运行时间的Bash脚本。
图5。p50 BigMem节点超线性加速的USL分析。
图6。超线性及其相关的回报区域(参见图1)。
图7。p150个BigMem节点的USL分析(蓝色实线)与图4(蓝色虚线曲线)插入进行比较。
图8。通过增加节点磁盘IO带宽消除了Hadoop TeraSort的超线性。
图9。在Hadoop作业-客户端控制台中看到的Reduce任务失败。
图10。Hadoop集群日志消息对应图9。
图11。失败的Reduce任务重试成功。
图12。在Hadoop日志中看到的Reduce任务失败的起源。
图13。HDFS DataNode管道显示单复制(蓝色)和默认的三复制(蓝色和灰色)。
数字图书馆是由计算机协会出版的。版权所有©2015 ACM, Inc.
没有找到条目