问题导读
1.根据下文hadoop2.1.1客户端与hadoop2.4.0集群是否可以通信？
2.hadoop2.4.0客户端与hadoop2.3.0集群【服务器】是否可以通信？
3.升级后集群，hdfs,mapreduce，yarn程序是否需要修改？
4.hadoop单独组建是否可以升级？
5.hadoop主版本升级后，如flume是否受影响？
目的
这个文档介绍了 Apache Hadoop 项目的兼容性，在hadoop发布版之间的兼容性，影响了hadoop开发者，hadoop相关项目，终端用户。
描述了hadoop终端用户及相关项目的影响
Hadoop开发人员采用的政策为了适用，不兼容的改变是允许的
兼容类型
Java API
- hadoop接口和类都是有注释的，描述了使用者和稳定性，来保持与以前的版本兼容。更多细节查看 Hadoop Interface Classification
- InterfaceAudience：描述了什么类型是允许改变的，可能的值是 Stable, Evolving, Unstable, 和 Deprecated.
用例
- Public-Stable API兼容性，从而确保最终用户的方案和下游项目继续不加修改工作。
- LimitedPrivate-Stable API 兼容性，需要允许跨越小版本单个组件升级。
- Private-Stable API 兼容性，需要滚动升级
Policy
Public-Stable APIs在一个主要版本发布前，从版本中移除，必须被弃用。
LimitedPrivate-Stable APIs在主版本中可以改变，但是仅在发布的主版本之内。
Private-Stable APIs在主版本中可以改变，但是仅在发布的主版本之内。
没有注解的类为“Private”.类成员没有注释继承封闭类的注释。
注意：从原始文件生成API需要兼容滚动升级，更多细节 查看wire-compatibility 部分.
语义兼容
Hadoop努力确保API behavior版本保持稳定，尽管改变可能导致behavior改变
测试和Javadoc指定API的behavior。hadoop社区指定API的过程更加严格，加强测试套件，以验证符合规范。有效地产生正式规范行为，可以容易地测试的子集。
Policy
API behavior可以改变，以解决不正确的行为，比如伴随着升级已存在的bug修改等。
Wire 兼容性
Wire 兼容性相关数据通过wire 传播在hadoop进程之间。hadoop使用协议缓存区【大多数使用RPC通信】
保护兼容性需要禁止修改，如下描述。非RPC通信也应考虑。比如使用HTTP传输HDFS镜像作为快照或则传输MapTask输出。潜在的通信可以分类如下：
- Client-Server: hadoop客户端和server通信（等HDFS客户端与NameNode协议，或则YARN客户端与ResourceManager协议）
- Client-Server (Admin):它是值得区分的一个子集的 Client-Server协议仅由管理员命令使用（等HAAdmin协议）。由于这些协议只影响管理员（可以容忍的变化），最终用户（使用一般的 Client-Server 协议）不能。
- Server-Server:服务器之间的通信
Use Cases【用例】
- Client-Server兼容性需要允许用户继续使用旧版本客户端，甚至是升级后的集群到新的版本【反之亦然】。比如hadoop2.1.0客户端与hadoop2.3.0集群通信【这里只是整理自官网，升级时许谨慎】这里附上原文【Client-Server compatibility is required to allow users to continue using the old clients even after upgrading the server (cluster) to a later version (or vice versa). For example, a Hadoop 2.1.0 client talking to a Hadoop 2.3.0 cluster.】
- Client-Server 兼容性也需要允许用户在升级服务器（集群）之前升级客户端。例如，hadoop2.4.0客户端与hadoop2.3.0集群【服务器】通信。这允许客户端在集群升级之前修复bug.请注意，新的客户端的API或shell命令调用新的集群功能将无法使用。YARN应用程序尝试使用新的APIs(包括数据结构的新领域),APIs尚未部署到集群可以预期 link exceptions.
- Client-Server兼容性需要允许单独组件升级，其它组件不升级。例如hdfs从版本 2.1.0到 2.2.0，MapReduce不需要升级
- Server-Server兼容性需要允许在一个集群中存在混合版本，因此集群需要在不停止的情况下滚动升级
Policy
- 在一个主要版本中保留了Client-Server 和 Server-Server的兼容性。（不同的类型不同的Policy尚待考虑）
- 在主要版本中可以打破兼容性，但是打破兼容性会有严重后果，因此需要在hadoop社区讨论
- Hadoop的协议在.proto（ProtocolBuffers）文件中定义。Client-Server和Server-protocol .proto文件被标记为稳定的。当一个.proto标记为稳定这意味着变化应兼容的方式如下所述:
下列变化是兼容的，并且在任何时间都可以被允许：
- 添加一个可选字段，期望代码处理由于与旧版本通信丢失的字段
- 添加一个新的RPC/方法到服务
- 向消息添加新的可选请求
- 重命名字段
- 重命名 .proto 文件
- 改变 .proto注释影响代码生成（如Java包名称）
下面改变是不兼容的，但仅在主版本中考虑
- 改变rpc/method名
- 改变rpc/method参数类型和返回类型
- 移除 rpc/method
- 改变service名称
- 改变消息名称
- 以不兼容的方式修改字段类型（递归定义）
- 改变一个可选的必须字段
- 改变或则删除一个必须字段
- 删除一个可选的字段,只要可选字段允许删除合理的默认值
下面改变不兼容，因此不允许
- 改变一个字段的id
- 重新使用以前删除的字段
- 字段是非常便宜的，改变和重用是不好的
Java二进制兼容性最终用户应用程序即Apache Hadoop的ABI
作为hadoop修订升级终端用户期望它们的程序不做任何修改继续工作。为满足这一期望，因此支持API 兼容, Semantic 兼容 和 Wire 兼容.
尽管如此， Hadoop是非常复杂的,分布式系统和服务各种类型的用户案例。特别是 map/reduce 是一个非常广泛的API；在某种意义上终端用户有非常大的空间，比如当运行mapreduce任务，本地磁盘的分配，任务的环境变量【配置】等。在这种情况下，它变得非常难以完全指定，支持，绝对兼容性。
用例
- 现有的mapreduce程序，包括现有jars 最终用户应用程序和项目比如Apache Pig, Apache Hive, Cascading 等当指向在一个主版本中升级的Hadoop集群，可以无修改的工作。
- 现有的Yarn程序，包括现有jars 最终用户应用程序和项目比如 Apache Tez 等当指向在一个主版本中升级的Hadoop集群，可以无修改的工作。
- 现有的传输数据（输入/输出hdfs文件）应用程序，包括已存在的终端用户jar包应用程序比如Apache Flume,在主版本内当指向升级的Apache Hadoop 集群应该无修改的工作。
Policy
- 现在有的MapReduce, YARN & HDFS 应用程序和框架应该在一个主版本内，不做任何修改就可以工作。 Apache Hadoop ABI 是支持的。
应用程序很小的一部分可能影响到磁盘的分布等。开发者社区将努力减少这些变化，不会使他们在一个小版本。更糟糕的情况，我们将考虑强还原这些重大更改，如果有必要将取消版本发布。
- 尤其是MapReduce应用，开发者社区将尽力支持提供二进制兼容性在各主要版本如应用org.apache.hadoop.mapred。
APIs支持兼容性hadoop-1.x 和 hadoop-2.x.查看在hadoop-1.x 和 hadoop-2.x MapReduce应用程序，更多细节点此
REST APIs
REST API兼容性对应于两个请求（URL）的和响应于每个请求（内容，其可含有其它URL）。
Policy
API 注释稳定，至少在一个主版本中保存兼容，可能在主版本的新版本的REST API 被弃用
Metrics/JMX
尽管 Metrics API由Java API兼容管理，实际metrics暴露给hadoop为用户实现自动化使用它们（脚本等）。添加额外的metrics是兼容的。修改（例如，改变单位或测量）或则移除已存在的metrics破坏兼容性，类似的改变 JMX MBean对象名称也破坏兼容性。
Policy
在一个主版本内容Metrics应保持兼容性。
文件格式和元数据
用户和系统级数据（包括元数据）存储在不同格式的文件。改变元数据或则存储数据/元数据的文件格式将导致版本间不兼容。
用户级文件格式
改变终端用户存储数据的格式阻碍了后面版本的访问，因此非常重要保持文件格式的的兼容性。人们总是在现有的格式上添加一个“新”的格式改进。这些格式例子包括har, war, SequenceFileFormat 等.
Policy
不向前兼容的用户文件格式改变是非常严格的在主版本。新发布版本期望读取已有格式，但写入数据的格式可能与先前版本不兼容。社区更倾向于创建一个新的格式，来代替对现有格式的不兼容的改变。
系统内部文件格式
hadoop内部数据以文件的方式存储，改变这些格式会导致不兼容。这种改变不像用户级别文件具有毁灭性，兼容性可以被打破的policy是重要的。
MapReduce
MapReduce使用格式如 I-File 存储MapReduce指定数据
Policy
MapReduce内部是格式如IFile在一个版本内保持通用性。改变这些格式会引发运行中的jobs失败，因此我们应该确保新的客户端以兼容的方式能够取shuffle数据从旧的服务端
HDFS Metadata
HDFS元数据（镜像和edit logs）在一个指定的格式。无论是格式还是元数据改变会阻止后面版本读取旧版本元数据。这种不兼容的变化可能需要hdfs升级转换元数据使它能访问。一些改变需要更多的升级。取决于不相容的变化的程度：
自动：image自动升级，无需显示升级
直接：image是可升级的，但可能需要一个显式发布“升级”。
间接：image是可升级的，但是可能首先升级到中间的发布版
不可升级：image不可升级的
Policy
一个发布版升级必须允许集群回滚到旧版本和他的旧的磁盘格式。回滚需要还原原始数据，但是不需要恢复更新的数据
HDFS元数据改变必须升级通过任一升级方式--- automatic【自动】, direct 【直接】或则 indirect【间接】.
更多的细节policies在各种升级方式中还有待考虑
命令行界面 (CLI)
Hadoop的命令行程序，可以使用可直接通过系统shell或通过shell脚本。改变一个命令的路径，删除或重命名的命令行选项，参数的顺序，或则命令返回代码和打破输出兼容性，可能对用户造成不利影响。
Policy
在随后的主版本中将被移除或则不兼容的修改之前，在主要版本中，CLI命令被弃用（当使用时会有警告）
Web UI Web UI,web页面的详细内容和页面布局，改变潜在的接口可能会影响页面信息
Policy
Web pages在任何时候允许不兼容性改变。用户期望使用 REST APIs 获取任何信息
Hadoop 配置文件
用户使用（1）hadoop定义属性配置和提供暗示,以hadoop（2）定制属性传递信息给job.因此配置属性的兼容性是双重的：
- 修改key-names, values的单位, 和hadoop自定义属性的默认值
- 自定义配置属性keys不能与hadoop定义属性命名空间冲突。通常情况下，用户应该避免使用hadoop前缀: hadoop, io, ipc, fs, net, file, ftp, s3, kfs, ha, file, dfs, mapred, mapreduce, yarn.
Policy
Hadoop定义的属性是被弃用的至少一个主要发布之前被删除。修改单位现有属性是不允许的。
在主要版本或则小版本中，hadoop自定义属性值可以被改变
当前没有明确的policy规则，当新的前缀被添加或则删除。前缀应该避免自定义配置属性。尽管如此，如上所述，用户应避免使用使用Hadoop的前缀：hadoop, io, ipc, fs, net, file, ftp, s3, kfs, ha, file, dfs, mapred, mapreduce, yarn.
目录结构
源代码,工具（源和测试），用户日志，配置文件，output 和 job history ，存储在本地磁盘或则hdfs.改变。改变用户访问文件的目录结构破坏兼容性，即使源路径通过 symbolic links保存。（如果，例如servlet访问路径，被配置为不遵循符号链接）
Policy
布局的源代码和生成的构件可以随时更改，特别是跨主要版本。在主要版本中，开发者尝试（没有保证）保存目录结构；尽管如此，独立的文件可以被添加/移除/删除。最好的方式是补丁与提交的Apache源码树的源码保持同步。
目录结构，配置文件，用户日志，job history被保存在一个主版本内跨越小版本和发布点（point releases）
Java Classpath
用户应用程序构建可能添加所有的hadoop jars(包括hadoop 库依赖)到应用程序classpath。添加新的依赖或则升级已存在的依赖可能影响这些应用程序的classpaths
Policy
当前没有策略，hadoop依赖可以改变。
环境变量
用户和相关项目经常使用导出的环境变量（如HADOOP_CONF_DIR），因此，删除或重命名的环境变量是一个不相容的改变。
Policy
当环境变量改变，没有Policy。开发者在版本中尝试限制改变。
构建构件
hadoop使用maven管理项目，更改构件会影响现在的用户工作流。
Policy
测试构件：测试jars产生内部使用非常严格的，不希望在hadoop外部使用，类似APIs注释@Private, @Unstable.
构建构件：hadoop客户端构件 (maven groupId:artifactId)在主版本中保持兼容性，其它构件可以以不兼容的方式改变。
硬件/软件需求
跟上硬件的最新进展，操作系统，JVMs,和其他软件，新的hadoop发行版或则他们的一些新的功能需要同样的更高版本。对于特定的环境，升级Hadoop可能需要升级相关的软件组件。
Policies
硬件：
1.结构：社区有没有计划对Hadoop的具体结构，但可以有家族特定的优化。
2.最少资源：在hadoop守护进程所需的资源没有保证期间，社区尝试不增加需求在发布的小版本内。
操作系统：在小版本中，社区将试图保持相同的操作系统的要求（OS内核版本）。当前GNU/Linux和Microsoft Windows 是官方支持的，社区hadoop工作的相当不错也在其它操作系统比如Apple MacOSX, Solaris 等.
JVM不会改变跨点发布的同一个小版本内，除非如果JVM版本变的不支持。Minor/major版本以后可能需要一些/所有的支持的操作系统的JVM。
其它软件：社区试图保持由Hadoop的所需的额外软件的最低版本。例如，SSH，Kerberos身份等。
参考：
下面是与主题相关的一些相关JIRAs和pages：
Here are some relevant JIRAs and pages related to the topic:
版本：hadoop2.7.1
相关文章
hadoop入门-第一章General：第一节单节点伪分布
hadoop入门-第一章General：第二节集群配置
hadoop入门-第一章General：第三节Hadoop初级入门之命令指南
hadoop入门-第一章General：第四节文件系统shell
hadoop入门-第一章General：第五节hadoop的兼容性说明
hadoop入门-第一章General：第六节开发人员和用户接口指南：hadoop接口分类
hadoop入门-第一章General：第七节Hadoop 文件系统 API ：概述
hadoop入门-第二章common：第一节hadoop 本地库 指南
hadoop入门-第二章common：第二节hadoop代理用户 -超级用户代理其它用户
hadoop入门-第二章common：第三节机架智能感知
hadoop入门-第二章common：第四节安全模式说明
hadoop入门-第二章common：第五节服务级别授权指南
hadoop入门-第二章common：第六节Hadoop HTTP web-consoles认证机制
hadoop入门-第二章common：第七节Hadoop Key管理服务器(KMS) - 文档集
hadoop入门:第三章HDFS文档概述（一）
hadoop入门:第三章HDFS文档概述（二）
hadoop入门:第四章mapreduce文档概述
hadoop入门:第五章MapReduce REST APIs文档概述
hadoop入门:第六章YARN文档概述
hadoop入门:第七章YARN REST APIs
hadoop入门:第八章hadoop兼容文件系统
hadoop入门:第九章hadoop认证
hadoop入门:第十章hadoop工具
hadoop入门:第十一章hadoop配置
|
/2 
京ICP备2020039040号
简书网举报电话：021-34700000
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
