前言
现今Hadoop版本已经release到了Hadoop 3.x版本了，社区迭代更新的速度还是很快的。新的版本相对旧版本来说，能够给我们带来很多益处，诸如新的功能feature，众多bug fix以及一些大的performance的改进。始终维护运行一个陈旧的系统，意味着后期可能会遇到许多许多社区已fix的bug，这个将会消耗掉系统管理员日常相当多的工作时间。尤其当我们维护的是一个具有庞大规模的分布式系统。所以对于复杂系统来说，性价比最高的一种系统优化途径就是升级它，将它升级到新的稳定的版本。本文笔者来聊聊Hadoop升级前需要考虑和做的一些事情。
Hadoop升级的目标版本的选择
首先我们在进行Hadoop升级之前，第一个要十分明确的一个问题：我们要升级到哪个Hadoop版本。Hadoop社区每年都会发布很多大大小小的不同的Hadoop版本，我们到底要选择哪个版本作为升级后的版本呢？
这里一般会有如下几方面的考虑：
- 1）目标版本中带有我们期望中的某一个重要的功能，比如 HDFS的Standby NN Read，又或者是HDFS EC功能。
- 2）目标版本是一个相对发布了有一段时间，可以确认是一个稳定运行而且还算较新的版本。
上面1） 属于目标性十分明确的一个选择的，但是笔者个人偏向于上面的第二种做法，选择一个相对较新的版本作为目标升级版本会是一个更为稳妥的选择。毕竟谁也不想升级到一个最新社区的版本，然后不幸地遇到了别人都没遇到过的一个问题，这个时候修问题的成本就很高了。
Hadoop升级过程需要做的准备工作
当我们明确我们想要到的目标版本之后，随后我们就可以开始着手升级前的准备工作了。这个准备工作做的越细，到时升级过程出问题的概率将会越小。
可能有部分同学认为，这个准备工作不就是测试的时候把新版本替换旧版本，然后重启服务，检查下系统是否正常，不就OK了吗？对于简单的服务系统来说，采用这里说的几个简单的步骤或许是可行的。但是对于比如Hadoop这样的复杂分布式系统来说，显然前面说的测试过程是不够完善的。
这里笔者简单列出以下几点Hadoop升级前需要考虑和做的事情（也同样适用于其它复杂系统）：
第一点，新旧版本之间的兼容性测试，兼容性毫无疑问是首当其冲我们要去做的测试。对于复杂系统来说，升级的过程是要分阶段逐步升级的，比如先升级master service，再升级slave service，然后如果有必要client端那边再进行client包的升级替换。在这个过程中就会存在master service，slave service以及client三者之间新旧版本混合部署的情况。这个组合情况会很多，所以在测试时，我们要能够模拟出可能出现的所有混部的场景，然后进行测试。如果其中确实遇到了兼容性的问题，则进行对应问题的解决，比如可能会需要进行额外配置的修改或者数据状态的清理等等。升级的兼容性问题往往存在于不停服的升级模式，如果我们用停服务升级的方式进行，这种情况出问题的概率会小很多。
这里再额外说说系统的兼容性测试，不同类型系统的兼容性体现略有不同。对于无状态的分布式系统，比如分布式计算系统，他们的兼容性可以体现诸如RPC通信，API接口调用上等方面。而对于拥有状态数据的分布式存储系统而言，他们兼容性的一大特点就是体现在数据的兼容性上。新的系统是否能够load老系统的状态数据，又或者老的系统是否能够在升级rollback过程中加载新系统产生的状态数据。
第二点，新旧版本之间的配置，代码逻辑的检查和同步。有的时候我们会在老的版本内做一些内部版本特有的优化，然而这种优化在社区官方发布的版本中是没有的。这个时候我们在获取到新版本之后，要进行代码上的对比，要backport内部的做的优化在新版本内。另外新版本中，会有部分的配置的更新，例如一些新增功能的配置，以及一些配置名称的修改(一般新的配置名是可以兼容老名称的)。
第三点，灰度测试过程。除了在测试环境中进行新版本的升级测试之外，在正式升级前，最好能够提前在生成环境进行一定的灰度测试。一来灰度测试，是在真实生产环境里进行的，能够发现在测试环境里被掩盖掉的隐藏问题。二来灰度测试也能够也是一个正式升级操作前的预演过程。
第四点，升级前的用户沟通协调。用户沟通这块其实已经不属于系统升级本身范畴之内的事情了，但是这件事情依然十分十分的重要。减少升级对用户的影响本身是我们最为看重的点。这个沟通的过程中，要让用户清楚的知道这次升级的背景缘由是什么，对于他们的影响是什么，以及他们需要对应做哪些事情来配合这次升级。同时，最后能够提供给用户一个相关的文档，把这里提到的几个为什么全部写到文档上。做到最好的一种情况是说，一个新的用户看到文档后，能够明白他所需要做的所有事情。
第五点，分阶段的正式升级过程。在前面升级前的测试都完成之后，就来到了最后的升级操作。我们在最终升级的时候应该怎么升级呢？笔者的个人建议是将整个升级过程进行细粒度的拆分，一点一点升，每升级一步，观察一到两天。这种方式的好处在于，1）每次升级的change操作较少，不会操作失误。2）升级中间如若出现问题也比较容易回滚。那么我们可以怎么分阶段升级呢？一个简单的例子，比如现在我们有一个待升级的系统，我们可以先升级master service，观察若干天，然后再升级1个rack的slave service，再观察若干天。如果期间都没问题的话，则继续升级后续service。
另外还有是升级操作的人员角色工作的分配。升级过程是一个大的系统change，会涉及到众多的服务，所以我们需要更多的人一起加入，需要相互协调，配合完成好整个升级过程。
以上就是本文的全部内容，主要是笔者在工作中升级Hadoop版本时所想到的一些点，这部分内容也同样适用于其它类似Hadoop这类的复杂分布式系统。