本文由 ImportNew - 唐尤华 翻译自 apmblog.compuware.com。如需转载本文，请先参见文章末尾处的转载要求。 最近几周里，我和同事参加了在旧金山港湾区的Hadoop和Cassandra高峰论坛。如此密集地与众多有经验的大数据专家进行探讨是一件非常享受的事情。感谢
本文由 ImportNew - 唐尤华 翻译自 apmblog.compuware.com。如需转载本文，请先参见文章末尾处的转载要求。最近几周里，我和同事参加了在旧金山港湾区的Hadoop和Cassandra高峰论坛。如此密集地与众多有经验的大数据专家进行探讨是一件非常享受的事情。感谢我们的合作伙伴DataStax和Hortonworks主办了这场盛会！与此同时，我也看到性能问题已经成为了社区里讨论的主要内容。我们搜集了很多典型大数据性能问题的反馈，也惊讶于性能问题带来的挑战。因为与会者都是专家，因此通用性问题和基础的集群监控方法不在讨论之列。本文会介绍关于Hadoop和Cassandra的高级问题。
我整理了最有意思和最常见的Hadoop和Cassandra部署问题：
数据本地性是Hadoop Map/Reduce的核心优势，map代码会在数据所处的节点上执行。然而有意思的是，很多人在实践中发现情况并非总是如此。他们发现了以下例外情况：
这些问题在大集群里出现更加频繁，也就是说数据节点越多本地化数据就越少。由于越大的集群完全相同的可能性就越小，一些节点的更新速度会比其他节点更快导致计算比例失衡。预测执行即使没有本地数据也会占用计算能力。问题数据节点可能会计算其他内容，这会导致另一个节点执行非本地处理。问题的根源可能在数据布局和输入分流上。无论如何，处理非本地数据会造成网络的扩展性问题，使得网络成为瓶颈。不仅如此，由于数据本地性不容易观察诊断这些问题非常困难。
为了提高数据本地性，你首先需要检测你的任务（job）中哪些有数据本地性问题或者会随着时间性能下降。通过APM（每分钟操作次数）方案，你可以知道哪些任务访问了什么数据节点。解决本地性问题更为复杂，包括更改数据位置和数据布局、使用不同的调度器或者简单改变任务的映射器（mapper）和减速器槽（reducer slot）。接下来，通过执行同样的工作你可以验证新方案是否能带来更好的本地数据比率。
接着我们又证实了一个有趣的观点：很多Hadoop工作量非常低效。请注意，这不是Hadoop的问题而是执行任务的问题。然而，在更大的Hadoop集群里“分析”任务是最主要的痛点。仅仅黑盒方式的监控是不够的，传统的分析器不能应对Hadoop集群的分布式特点。针对这个问题，我们的解决方案得到了很多资深Hadoop开发者的认可。我们还收到了很多关于如何让我们的Hadoop任务“分析”更加有效的有趣反馈。
众所周知，置乱是Haddop Job中对性能影响最主要的因素。在很多Hadoop性能调优的文章里都描述了优化图中间的数据（比如使用组合其）、（使用拆分器）置乱分布和纯粹的读/合并性能（线程个数、管理低端内存）。但是很少有文章谈及降低特定TaskTracker速度，这种方案在很多资深“Hadooper”中间已经得到了广泛地讨论。
当计算节点处于高压状态、硬件能力不足或者进入层叠效果时，本地的TaskTracker就会受到负面影响。更简单地说，在大集群中的一些节点会因此降低性能！
结果就是TaskTracker节点不能为还原器提供快速置乱数据，或者可能在进行操作时发生错误。基本上所有还原器都会出现该问题，因为置乱是整个任务执行时间的瓶颈而且会不断增加。在小集群上我们可以监控一组运行的TaskTracker性能，然而在现实中的集群上这是不可行的。监控基于中枢的平均值会掩盖触发该问题的任务，所以不能确定究竟是哪个TaskTracker造成的问题以及背后的原因。
解决方法是采用基线方式，配置PurePath/PureStack模型。对TaskTracker请求做基线能够解决平均值和监控问题，通过这种方法，如果发生TaskTracker mapOutput性能问题我们可以得到即时通知，而且能够及时确认是哪个TaskTracker出现的问题。接下来，我们能够通过通过JVM主机的健康状况定位究竟是基础设施、Hadoop配置或是新操作系统造成了问题。最后，通过追踪所有任务、作业（task）以及mapOutput请求各自的任务，我们可以知道究竟是哪个任务触发了TaskTracker性能问题以及哪些任务受其影响。
与TaskTracker类似，NameNode和DataNode也会对任务性能产生影响。NameNode或特定DataNode变慢会对整个集群产生显著的影响。解决的办法可以对请求建立基线，进行检测并自动检测性能退化。同样地我们也可以知道哪些任务和客户端受到NameNode和DataNode减速的影响，并判断是基础设施、高使用率还是服务发生的错误。
Spotify在Cassandra高峰论坛上的演讲是最棒的。如果你正在使用或者计划使用Cassandra强烈向你推荐！
在第一次部署Cassandra时运行速度非常快，但是读操作用时随着时间不断增加。实际上所有的操作随着时间推移都会有类似的问题，对跨SStable的读取和删除行操作都会导致死节点。所有问题都可以归咎于访问模式和模式设计错误，而且通常都与数据相关。如果你向同一行（row）长时间（几个月）不断写数据，那么这一行会扩散到很多SStable。读取该行数据将变得缓慢，然而访问更“新”的行（位于同一个SSTable）还是很快的 。对同一行不断进行删除和插入情况会更糟糕，不仅这一行的数据会到处扩散而且会充满很多死节点，读取时效率会非常恐怖。然而，平均值数据只是缓慢地增加（这就是均值效应）。实际上“老”行的性能会急剧下降，而“新”行的速度仍然很快。
为了避免这种情况的发生，在应用程序中绝不要经常删除数据，也绝对不要长时间向同一行写入数据。要发现这个问题你应当首先为Cassandra一组列（column）的读请求制作基线。与均值相比基线方法能够在分布式环境下检测变化，并通知你哪些请求会性能退化哪些仍然保持快速。除此之外，为实际终端用户的Cassandra请求进行分类能够助你快速定位问题。
与很多真实世界的应用程序一样，Cassandra节点会因为各种因素变慢（硬件、压缩、GC、网络、磁盘等）。?Cassandra是一个集群化数据库，每一行都在集群里存在很多次，每次写请求都会发送给包含该行的所有节点（甚至是级别相同的节点）。单个节点失效不是大问题，因为其他节点包含了相同的数据所有读写请求都能够继续正常进行。理论上一个超级慢的节点不会带来问题，除非我们明确指定向同一级别的“所有”节点请求数据。然而在内部，每个节点都有一个协调队列等待所有请求完成，即使他应当在请求完成时就马上向客户端作出回应。该队列能够应对一个超级慢的节点，并且迅速地指出单个节点不能响应请求。然而这会让这个集群不能响应任何请求。
这个问题的解决包含两方面。如果可以，使用一个类似Astyanax的令牌客户端。通过直接与包含数据的节点沟通，该客户端能够高效地跳过协调队列问题。除此之外，你应当对服务器节点的Cassandra请求建立基线，当节点变慢时给出警告。说起来奇怪，关闭问题节点也可以暂时解决问题，因为Cassandra能够几乎立刻处理该问题。
Cassandra的另一个典型性能问题来自我们习惯了SQL，这个问题对于Cassandra入门者尤其典型。这是一个数据库设计问题，事务中包含了太多请求或读取大量数据。这不是Cassandra本身的问题，事实是进行太多请求或者读取大量数据会减慢实际事务的处理速度。这个问题可以很容易检测并且通过APM方法发现，而解决办法往往需要对代码和数据模型进行改动。
Hadoop和Cassandra都是扩展性非常好的系统！但是通常这种可扩展性不能解决性能问题，二者都不能避免而且简单的误用也不能解决。
这些系统上出现的特定问题都不会在其他系统上出现。其他虽然不是新问题但是从未有在这样大规模的分布式系统上出现。由于可扩展性和规模的问题，这些问题都难于诊断（尤其是Hadoop）而且会产生巨大的影响（比如Cassandra集群停止）。性能分析专家可以举杯庆祝了，未来的很长一段时间他们都会有做不完的工作。
原文地址：关于Hadoop和Cassandra性能问题的讨论, 感谢原作者分享。
