国产化大数据，Hadoop该如何应对

由于Apache版本的组件兼容性和部署复杂性，绝大部分公司在当时产品选型时选择了某种Hadoop发行版，据信通院在2019年6月数据整理，当时国内有39家基于Hadoop的平台供应商，这些供应商里面有70%多是基于Cloudera的CDH和HDP的社区版封装成产品来提供给用户的，有24%是基于Apache封装，还有一家自研的产品。大部分供应商基本都是在CDH/HDP社区版进一步封装，同时替换掉CDH/HDP的Logo，就发布出来自己的版本。也就是说CDH/HDP的发行版基本上“垄断”了Hadoop市场，分析其原因，主要是免费（CDH分为免费版和商业版，HDP为开源免费版），很多公司并没有像互联网大厂那样的技术能力，使用免费的Hadoop发行版无疑是“最佳”选择。

估计很多人觉得直接采用Apache开源版本是一件很简单的事情，毕竟源码和大部分二进制包都摆在那里，但是其实真正做起来，就哭爹喊娘了，因为各个组件是存在很多版本依赖关系的，当所有组件都放在一起的时候，必然存在兼容性的问题，尤其是当以官宣首个支持ARM的Hadoop3.3.*为主进行其他组件集成的时候，你会很快发现其他组件在拖后腿！下图为一个简单的分析（实际上比这个复杂多了，跟所有组件有关系的线条没有画）。

分析了组件之间的关系，还有一个更麻烦的事情，就是繁杂的Jar包依赖。由于很多组件使用很多相同的基础Jar包（例如Log4j等），但是Jar包版本不一致，这些组件在单独运行的时候，可能没有问题，集成在一起的时候问题就暴露了。这就需要根据Jar包依赖进行分析，有的Jar包版本能够向上向下兼容，这种情况还好，碰到那种不考虑版本兼容（“不负责任“）的Jar包，你就脑袋大了（这也估计是很多Java程序员最不想干的事情了）。简单列举几个兼容性存在问题的jar如下：

解决这个问题，大致有两种思路：

• 选择合适的组件版本：不一定选择最新的，要选择合适的版本，但是绝对不能选择EOL的。

• 自行修改代码适配：一些不太活跃但是常用的组件，例如Hive，目前3.1系列已经好几年了，最新的4.0还在alpha阶段，如果采用稳定的Hive3.1.*版本，将面临zookeeper、hadoop、guava、curator、nettey相关的代码修改（虽然社区有解决办法，但是很多是针对4.0的），需要对组件源代码有足够的熟悉。

Ambari作为Hadoop集群管理的开源软件，目前尚没有较好的替换软件，有很多号称有自己发行版的公司都是把Ambari换个UI售卖的。

在Hadoop3.3.4这个主版本选定后，首先，Ambari自身的编译就需要调整很多jar包版本，没有一定技术能力，其实也难以搞定。其次，虽然Ambari目前已经集成了很多组件，但是还需要根据版本特性调整相关的配置。最后，对于尚未支持的Ozone、Kyuubi、Flink等组件，虽然可以找到一些公开资料和样例，但是很多开源项目都是最多算“学习版本"，例如某电信领域的技术公司公开的Kyuubi组件集成到Ambari的资料和代码，就是残缺不全的，所以，只有自己动手实践才会发现问题，但也确实需要足够的技术能力。

按照目前Ambari的包管理方式，需要将各个组件打包成rpm包或deb包，这也是Ambari适配不同操作系统、管理不同版本管理的基础。

有些Hadoop集成商宣称放弃了这种方式，改用了tar包方式，看起来是简单了，实际上是应该是不太了解Ambari使用这种方式的深层次原因，当然Ambari开源社区也讨论过使用类似Cloudera Manager的parcel方式，但该特性至今还没有完成。所以目前还是沿续rpm包这种方式可能更靠谱些。

对于打包rpm的方式，开源社区有个Bigtop的项目是专门做这个的，但是国内关于Bigtop资料很少，使用起来也有一定难度，之前华为鲲鹏大数据给出过另外两种方式：

• 使用Maven，编写Pom：目前Ambari使用的这种方式，优点是便于统一管理。
• 使用rpmbuild，编写Spec：打包rpm关键是spec文件的编写。

听起来好像挺简单的，但实际上有个问题被忽略了，那就是Apache版本编译完成的二进制文件与rpm包的目录组织方式不一样！这就需要花大量时间去逆向拆解（老组件）或重新设计目录结构（新组件）。同时，这个目录结构需要遵循Ambari一定的”规范“（没找到相关说明），这也是Ambari管理组件版本及版本升级的关键设计，所以，同样需要对Ambari非常的熟悉，也需要一定的逆向工程能力。

如果成功走到这个环节，恭喜您万里长征可能才走了一半，因为很多问题是这个环节才充分暴露出来的，一定会出现“卡脖子”问题（除非运气爆棚），往往需要把前面的工作重复很多次，直至完成这个环节。

对于HDFS这种Ambari已经集成的组件，只要别乱动组件自身源代码，一般没什么大问题，但也不排除有动态加载类的这种情况，可能会出现类不匹配等问题，所以全面的功能测试必不可少，至少反复几轮回归测试。

对与Ozone、Kuubi这种Ambari没有集成的组件，如果对新增组件的自身功能不熟悉，可能就存在特别多的工作量（学习、反复实践、测试等，最终取决于技术能力）。

通过上面所述的10个方面的简要描述，您还感觉使用Apache开源组件攒一个Hadoop发行版是一件容易的事情吗？

如果再有人告诉你这事儿不难，一定要留心，别被忽悠了，事出蹊跷必有妖，可能只是欺负你不太了解技术内幕，等你进坑了再收拾你！

目前支持的操作系统：

有人很好奇，为什么还有免费这种好事儿？！

没错，确实免费（无论公司或者个人），我们主要基于以下考虑：

• 自我实现需求：团队成员均已不再年轻，想做些对社会有价值的事情，也想为国产化贡献点力量，也看到很多做Hadoop发行版的公司都很难盈利（例如刚刚科创版上市的星环，翻开财务报表，利润都是负的），不靠点理想是撑不下去的。
• 产品推广考虑：免费的版本就会有更多的用户使用，更多用户使用就会有更多的问题反馈，就会帮助我们把产品做的更好。换句话讲，我们其实也不是不想收费，是因为国内很多公司就喜欢使用免费的，收费就没人用了。
• 寻求资源合作：目前虽然我们支持了很多国产操作系统，但是因为相关的资源较少（尤其是ARM服务器和国产操作系统），测试进度较为缓慢，我们也非常希望通过免费使用，让有资源的公司可以跟我们合作，帮助我们把这个事情做得更好，例如硬件厂商能提供些测试用的国产服务器，软件厂商提供些国产操作系统，业务公司提供应用场景测试，这些也都是我们欠缺的，也是我们很亟需的！

也可以关注HidataPlus公众号，留言“下载”获取最新网盘链接，有新版本发布我们也会通过公众号通知。

部署方式跟之前使用Ambari部署一样，网上找找资源一大堆，暂时不提供了。

最后，我们期望有资源的公司或个人跟我们联系（扫一扫上面的二维码，公众号留言），众人拾柴火焰高，大家一起合作，可以把这个事情做得更好！^-^.