1.5 错误容忍机制

由于不能避免系统和用户代码的Bug、节点宕机、网络异常、磁盘损坏等软硬件可靠性问题，分布式文件系统在设计时一般都会考虑错误容忍机制，在实现时也会针对各种失效情况采取相应措施。分布式大数据并行处理框架也不例外，设计了各种针对Master节点失效、task执行失败等问题的错误容忍机制。然而，对于task的执行失败问题，框架的错误容忍机制比较简单，只是选择合适节点重新运行该task。对于某些可靠性问题引起的task执行失败，如内存溢出等，简单地重新运行task并不能解决问题，因为内存溢出的问题很有可能会重复出现。现有框架的另一个局限是，一般用户在出错时很难找到真正的出错原因，即使是十分熟悉框架运行细节的用户，在缺乏分析诊断工具的情况下，也难以快速找到出错原因。下面我们总结分析一下在错误容忍机制方面的前沿工作。

在大数据应用错误分析方面：Li等[53]研究了250个SCOPE作业（运行在微软的Dryad框架之上）的故障错误，发现错误发生的主要原因是未定义的列、错误的数据模式、不正确的行格式等。Kavulya等[54]分析了4100个在Yahoo！管理的集群上执行失败的Hadoop作业，发现36%的故障是数组访问越界造成的，还有23%的故障是因为I/O异常。Xu等[55]研究了123个Hadoop/Spark应用中的内存溢出错误，发现内存溢出的主要原因包括应用配置异常、数据流异常、代码空间复杂度过高和框架内存管理缺陷等。

在大数据应用错误诊断方面：Titian[56]通过记录Spark应用中全部中间数据和数据依赖关系来追踪出错的数据路径。BigDebug[57]为Spark应用提供了断点、观察点、细粒度数据追踪等调试功能。Xu等[58]设计实现了Hadoop MapReduce的内存溢出错误诊断工具Mprof，它可以建立执行任务内存用量与数据流量的定量关系。在此基础上，Mprof 设计了多种内存溢出错误诊断规则，这些规则根据应用配置、数据流量与任务内存用量的关联关系来定位内存溢出错误的相关代码、数据，以及不恰当的配置参数。

在大数据应用错误修复方面：Interruptile Tasks[59]改进了现有的task，使得task具备一定的错误容忍能力。当task在运行时遇到内存用量过大或者内存溢出的问题时，Interruptile Tasks会暂停当前task的运行，回收部分运行数据及中间结果，并将不能回收的结果溢写（spill）到磁盘上，然后执行用户定义的interrupt逻辑，等到内存用量下降到一定程度后，再让task继续运行。