编辑文章 - 博客频道 - CSDN.NET

1目的

本篇文档介绍Apache Hadoop项目的目标：相容性。hadoop的发布影响Hadoop的开发者，以前的项目。Hadoop的发布和最终用户之间的兼容性的不同类型是可列举的。对于每一种兼容性：描述了以前项目和最终用户的影响，在使用的情况下，呼喊在改变的不相容性在Hadoop的开发者是能够允许的的策略。

2兼容类型

2.1Java API

Hadoop的接口和类的注释描述了预期的观众和稳定性为了保持和以前版本的兼容性。看Hadoop的Interface和Classification获得更多内容。

InterfaceAudience：获得了预期的观众，值可能是Public（为最终用户和外围的项目），LimitedPrivate （为其他的Hadoop构成，和相关的项目，比如YARN,MapReduce,HBase,等)和Private（为内部构成使用）。

InterfaceStability：描述了接口改变成什么类型是允许的。可能的值是Stable,Evolving,Unstable,和Deprecated。

2.2Use Cases

1.Public-Stable API 兼容性被要求保证最终用户的项目和下游项目能够继续工作，不需要修改。

2.LimitedPrivate-Stable API兼容性被要求允许单独构件通过镜像发布可以升级。

3.Private-Stable API兼容性被要求滚动升级。

2.3Policy

1.Public-Stable APIs反对在一个重要的发布移走前至少有一个重要的发布。

2LimitedPrivate-Stable APIs 可以通过重要的发布改变，而不是在一个主要版本。

3.Public-Stable APIs可以通过重要的发布改变，而不是在一个主要的版本。

4.注意：APIs从源文件生成需要兼容滚动升级。通过wire-compatibility章节获得更多的描述。APIs和wire-communication的兼容性策略需要手牵手的去解决。

3.Semantic compatibility

 apache hadoop 努力保证APIs的行为和以前版本保持一致，虽然改变的正确性可能导致行为的改变。测试和Java文档确定了API的行为。社区在确定一些API的处理中更严谨，提高测试单元来验证规范，为行为的子集有效的创建一个正式的规范可以很容易的被测试。

Policy

API的行为可以被改变以修复错误的行为，这种变化伴随着更新现有的试验或者添加在案例中的测试这些在之前是没有变化的。

4.Wire compatibility

Wire compatibility关心数据在hadoop处理过程中通过电线被传播。对于大多数的RPC通信Hadoop使用Protocol Buffers。Preserving compatibility要求禁止就像以下的描述。Non-RPC通信也应该被考虑，比如使用HTTP传输一个HDFS图像作为简介的一部分或者传输MapTask的输出。潜在的通信可以被分为：

（1）.Client-Server：在Hadoop的客户端和服务器端的通信。

（2）.Client-Server（Admin）:分辨Client-Server 协议的子集是值得的，Client-Server协议使用单一管理命令行就像这些协议仅仅影响管理者，管理者能够忍受改变，而最终用户不会。

（3）.Server-Server：servers之间的通信。

4.2Use Cases

(1)Client-Server 兼容性被要求允许用户继续使用老的客户端即使升级了Server以后。比如，一个Hadoop 2.1.0客户端和一个Hadoop 2.3.0集群的通信。

(2)Client-Server 兼容性也被要求允许升级个人版组件而不升级其他的。比如，把HDFS从版本2.1.0升级到2.2.0而不升级MapReduce。

(3)Server-Server 兼容性被要求允许最大的版本在一个活跃的集群，所以这个集群可能被升级在回滚方法中没有停止。

4.3Policy

(1)Client-Server和Server-Server的兼容性在一个重要的版本中是被保护的。

(2)兼容性可以被损坏仅仅在一个重要的发布中，尽管破坏了兼容性甚至在重要版本有严重的后果，应该在Hadoop社区中被讨论。

(3)Hadoop协议在.proto文件中被定义。Client-Server协议和Server-Server协议 .proto文件被标记为稳定的。当一个.proto文件被标记为稳定的，它意味着改变应该在一个兼容性的版本中被制定就像以下描述：

 。。。。以下的改变是兼容的，也是在任何时间都被允许的：

。。。。。。添加一个可选字段，与预期的代码处理字段丢失，由于和老版本的代码通信。

。。。。。。添加一个新的rpc/method到服务器。

。。。。。。添加一个新的可选请求到一个Message。

。。。。。。重命名一个字段。

。。。。。。重命名一个.proto文件。

。。。。。以下的改变是不兼容的，但是可以被考虑仅仅在一个重要的发布中：

。。。。。。。改变rpc/method的名称。

。。。。。。。改变rpc/method参数类型或者返回类型。

。。。。。。。移除一个rpc/method。

。。。。。。。改变一个service的名称。

。。。。。。。改变一个Message的名称。

。。。。。。。修改一个字段的类型以一个不兼容的方法。

。。。。。。。改变一个可选的字段为必须的。

。。。。。。。添加或者删除一个必须的字段。

。。。。。。。删除一个可选的字段就像可选的字段有合理的默认的允许删除。

。。。。。以下的改变是不兼容的因此从来不被允许：

。。。。。。。改变一个字段的Id。

。。。。。。。重新使用一个老的字段，这个字段是以前被删除的。

。。。。。。。字段的数值廉价的，不断变化的和重用，不是一个好的方法。

5.Java Binary Compatibility for end-user applications i.e. Apahce Hadoop ABI

就像Apache Hadoop版本升级的用户合理的认为他们的应用应该无需任何修改继续工作。这是由于支持API实现语义兼容性，兼容性和线兼容。

然而，Apache Hadoop是一个非常复杂，分布系统和服务非常广泛的使用案例。特别的，Apache Hadoop MapReduce是一个非常非常广泛的API；在某种意义上用户可以进行广泛的假设，例如，本地磁盘布局时，他们的map/reduce任务是执行的，环境变量对于他们的任务等。

5.2Use cases

（1）.已存在的MapReduce应用，包括已存在的成套的最终用户的应用和项目的jar,比如Apache Pig，Apache Hive，Cascading等，应该工作未修订当指出一个升级的Apache Hadoop集群在一个重要的版本中。

（2）已存在的YARN应用，包括已存在的成套的最终用户的应用和项目的jars，比如Apache Tez等，应该在指出一个升级的Apache Hadoop集群在一个重要的发布中工作。

（3）已存在的应用，HDFS的输入/输出数据交换，包括已存在的最终用户应用和框架的jars比如Apache Flume，在指出一个未升级的Apache Hadoop集群在一个主要的版本中工作。

5.3Policy

(1)已有的MapReduce，YARN和HDFS应用和框架应该工作在一个重要的发布版本中，i.e.Apache Hadoop ABI是支持的。

(2)一个应用非常小的一部分可能被磁盘布局的改变而影响，开发者社区努力减少这些变化并不会在他们的小版本中。在大多数极坏的情况下，我们将会考虑强还原这些变化和无效的违规发布必要的话。

(3)特别对于MapReduce应用，开发者社区将会尝试我们最大的努力支持提供二进制的兼容性通过重要的发布，e.g.应用使用org.apache.hadoop.mapred。

(4)APIs支持兼容性从Hadoop-1.x到hadoop-2.x。

6.REST APIs

 REST API兼容性符号了request和response到每一个request。Hadoop REST APIs是专门为客户在发布使用稳定，甚至主要的发行版本。下面是被暴露的REST APIs

（1）WebHDFS-稳定的(2)ResourceManager（3）NodeManager（4）MR Application Master（5）History Server

6.2Policy

APIs在上面的文本注释稳定保持在至少一个主要版本的兼容性，也许不赞成一个主要发布新版本的API。

7.Metrics/JMX

然而Metrics API兼容性是通过Java API兼容性管理的，暴露在Hadoop的实际指标需要兼容的用户能够使用它们的自动化。添加额外的度量是兼容的。修改或者移除已存在的度量打破兼容性。相似的，改变JMX MBean 对象的名称也是破坏兼容性。

7.1Policy

Metrics应该在以前的重要的发布中保护兼容性。

8.File formats 和 Metadata

用户和系统级的数据（包括元数据）存储在不同格式的文件。改变元数据或者文件格式使用存储数据/元数据可以导致版本间的不兼容性。

9.User-level file formats

改变格式最终用户用来存储他们的数据可以防止他们在以后的版本中访问数据，因此，它是高度重要的保存这些文件格式的兼容性。一个能够总是添加一个新的格式改善以前已存在的格式。这些格式的例子包括har、war、SequenceFileFormat等。

9.1Policy

Non-forward-compatible user-file 格式改变对于一个重要的发布是受限制的。当user-file 格式改变时，新的发布是被希望读取已有的格式，但是可能以这种格式写数据不兼容伴随以前的版本。同时，社区应该选择创建一个新的格式，程序必须选择在代替现有的格式制作的不兼容性的改变。

10.System-internal file formates

Hadoop 内部的数据也被存储在文件中，又改变这些格式也导致不兼容性。然而这些改变不像user-level file 格式一样有毁灭性的，一个策略时的兼容性可以打破是重要的。

11MapReduce

MapReduce 使用的格式像I-File来存储MapReduce-specific数据。

11.1Policy

MapReduce-internal格式像IFile在一个重要的发布中保存兼容性。改变这些格式能够引起in-flight工作失败，因此我们应该保证新的客户端能够从老的版本中拿取shuffle-data以一个兼容性的方式。

12.HDFS Metadata

HDFS以一个特殊的格式保持元数据。不兼容性改变了格式或者元数据阻止随后的版本从读取老的元数据。这种不兼容性的改变可能要求一个HDFS“升级”来改变元数据使它可以访问。一些改变要求更多比一个这样的“升级”。

根据变化中的不相容性的程度，以下潜在的情况下可以出现：

（1）Automatic：图片自动升级，不需要明确的“升级”。

（2）Direct：图片不升级，但是应该要求一个明确的版本“升级”。