本文作者Raymie Stata是Hadoop即服务公司Altiscale的创始人兼CEO，也是雅虎前任CTO，协助雅虎完成开源策略，并参与Apache Hadoop项目的发起。Hadoop的扩展和运维是非常复杂的过程，在其具体的实施过程中隐藏着潜在的危机，Raymie根据经验罗列了7项危机信号和相应的解决方案，帮助使用者提前避免灾难的发生。
以下为译文：
Hadoop扩展是一个非常复杂的过程，这里罗列了7种常见问题和解决方案。
所有Hadoop实施都存在着潜在的危机，包括一些非常棘手的Hadoop运行问题。这类问题出现在投入生产环境前会导致Hadoop被弃用，但是如果发生在投入生产环境后，则意味着一场“成功的灾难”(其实更有可能是一场纯粹的灾难)。
Hadoop的扩展和实施是非常复杂的。但是如果你能确切的认识到问题根源所在，还是可以避免“灾难”的发生，以下是根据经验总结出的一些危机信号。
危机信号1：无法投入生产环境
从概念验证到生产环境使用是大数据工作流程的重要一步。Hadoop扩展工作充满了挑战，较大的工作量往往不能被及时完成，测试环境不能完全覆盖真实运行环境，例如数据测试中常见的一种问题是：概念验证经常使用不切实际的小型或单一的数据集。
在投入生产环境之前，需要进行规模及压力测试，通过这类测试的应用程序具备可扩展性及容错能力，也可协助开发自身容量规划模型。
危机信号2：开始延期
第一个应用程序投入生产环境标志着你能够轻松实现SLA，但随着Hadoop集群数量增加，其运行时间变得不可预知，首次延期问题很容易被忽略，而随着时间的推移，这种情况变得越来越糟，最终导致危机出现。
千万不要等到危机爆发后再采取行动。在容量遭到挑战之前，可适当的扩展容量或优化程序。调整预期容量模型，尤其注意要在最糟糕的性能环境下进行容量检测，使其具备更加贴近现实的性能。
危机信号3：开始告诉客户不可能保存所有数据
危机爆发的另一征兆是减少数据保留需求。起初你希望为每年的数据分析保留13个月的数据，但由于空间限制，你开始缩减保留数据的时间，这在某种程度上等价于丢失了Hadoop大数据分析能力的优势。
缩减数据保留时间并不能解决问题，要避免这种问题必须要及早行动，重新审视容量模型，寻找预测失败原因，然后调整模型以便更好的追踪问题根源所在。
危机信号4：数据科学家们失去地位
过度使用Hadoop集群会扼杀创新，会导致数据科学家没有足够的资源去运行大型作业，没有足够的空间为科学家们存储大量运算结果。
容量规划经常容易被忽视，数据科学家的作用也经常被忽视。被忽视加上生产环境负载规划不足，意味着数据科学家经常被边缘化。请确定你的需求里包括对数据科学家的需求，并能在容量问题出现早期发挥作用。
危机信号5：数据科学家通过Stack Overflow解决问题
在Hadoop实施初期，运维团队和数据科学家协同工作。随着Hadoop实施的成功，运维团队的维护压力随之增加，科学家们必须自己解决Hadoop的问题，通常会通过Stock Overflow寻找处理方法。
随着Hadoop扩展及关键任务的增加，维护的工作量开始增加，如果想要保证数据专家们集中在数据研究上，则需要重新调整运维团队的大小。
危机信号6：服务器温度升高
分配服务器电力供应时，我们常常假设它们不会满负荷运行，但是大型的Hadoop作业很可能让服务器满载数个小时，严重威胁到你的电网(冷却方面也有类似的问题)。所以请确保你的Hadoop集群可长时间在全功率环境下运行。
危机信号7：开支失控
在基于IaaS部署的Hadoop环境中，排名第一的“成功灾难”是开支失控。你会突然发现账单费用是上个月的三倍，严重超出预算。
容量规划是基于IaaS的Hadoop实施中相当重要的一步，不仅仅是为了管理容量也为了管理成本。但好的容量规划只是一个开始，如果你想要扩展基于Iaas的Hadoop实施，最好要像Netflix那样大力投资系统来追踪并优化成本。
平缓Hadoop扩展
Hadoop计划通常低估了保持Hadoop集群稳定运行所需的工作量，这种误判是可以理解的。传统企业应用程序的初始优化实施成本比后续的维护与支持高出许多个数量级，人们通常误认为Hadoop遵循同样的模式，实际上Hadoop的维护非常困难，需要大量的运维工作。
优质的容量规划是必不可少的;拥有良好容量模型的同时，还需要及时的更新以避免其偏离实际应用场景;不要让创新成为后期问题，给予数据科学家足够的支持;扩容不是解决问题的唯一办法，管理使用情况也同样重要;让用户(及业务所有者)做足够的作业优化，一点点的优化都可以降低现有成本。