在今年2月份的时候，Cloudera宣布，从CDH 6.3.3版本开始，将不会再提供免费版（Cloudera Express）：
其实现在来看，完全就是一个温水煮青蛙的过程：
免费版不限制节点数量 -> CDH 6.x 免费版限制节点数量 -> CDH 6.3.3 “没有免费版，只能试用90天，最终就是要花钱”
而另一个免费午餐，Hortonworks 的 HDP，在 Cloudera 和 Hortonworks 合并之后，恐怕是危矣，虽然目前没有什么确切的消息指明 HDP 的更新一定会停止，但事实上现在所有指向 HDP 的官方链接，都在无时无刻的向你推销，告诉你赶紧升级到 CDP / CDP DC。
从商业的角度看，合并之后如果还继续更新 HDP，是增加自己的内耗，毕竟，本来就是为了报团取暖才进行的合并啊！
CDH 6.3 的支持结束日期为 2022 年 3 月，HDP 3.1的支持结束日期为 2021 年 12 月，也就是说，在这个日期之前，这些最后的“免费午餐”依然是主流的版本。但过了这个日期之后呢？虽然我所处的行业，都是商业版不差钱随便买买买的 … 但今天还是来聊聊之后吃免费午餐的办法吧，毕竟总会有人需要这些信息的。
（当然有人说，我不升级不就完事了吗 … 好吧，如果一直连续好多年也不想升级组件版本，倒也不是什么问题，哈哈）
免费部署的未来？
1、彻底回到 Apache 原生版本
其实有很多地方一直就是这么做的，非常的具有挑战性（当然，后续成本比买个商业版可能还要高）。
对于喜欢研究技术的来说，可能会感觉美滋滋。当然对于不喜欢的来说，那就是噩梦了…
2、使用 Cloudera 的“社区版”
Cloudera 的发行版中包含的组件的源码，一直是在 GitHub 上公开的，这意味着你完全可以使用其源码来进行编译和部署。但是事实上，还是没有办法达到很好的效果，因为在商业发行版中最重要的组件，其实是 Cloudera Manager，正是 Cloudera Manager 降低了集群的安装、部署、运维的难度，虽然 Cloudera 承诺会将 Cloudera Manager “开源”，但其实是一个有限制的“开源”，源代码只会向具有许可证的客户开放，所以不想花费金钱的话，是没有办法得到 Cloudera Manager 的。如果只是用 Cloudera 版本的源码编译和部署组件，然后在繁琐的命令行下进行操作，那和使用 Apache 社区版本又有什么区别呢 ？
3、使用 Apache Ambari + Apache BigTop Stack
Apache Ambari 应该是大部分人比较熟悉的。作为 Hortonworks 贡献给社区的项目，Apache Ambari 本身默认集成的就是 HDP 的 Stack，网上的 “ Ambari 安装 Hadoop 教程 ”，实际上都是安装 Apache Ambari + HDP 教程。
什么是 Stack 呢？实际上就是一组预定义好的组件服务和命令脚本的集合。而 Apache Ambari 和 Cloudera Manager 一样，都属于一个“管理界面工具”，在 Apache Ambari 的架构中，实际上 Ambari Stack 是完全可以将 HDP Stack 替换为第三方提供的 Stack，或者是你自己定义的 Stack 的。
Hadoop 生态圈的项目众多，各种编译依赖又特别复杂，并且不同组件版本之间还有乱作一团麻的版本兼容性问题，如果你再考虑到目标硬件平台的话，那就是乱的不得了… 个人开发者肯定是没有办法从头去构建一个自定义的 Stack 的。
这个时候就需要使用到 Apache BigTop （https://bigtop.apache.org/）了。
Big Top，意思是马戏团帐篷，它的logo长成这样：
Apache BigTop 是由 Cloudera 贡献给社区的。它的功能就是对 Hadoop 生态圈的开源项目进行集成、打包、虚拟化、部署和测试。不得不说这个名字和logo还是挺有梗的，因为 Hadoop 生态圈确实到处都是动物名和动物LOGO（程序员迷之爱好？？？）…. 作为一个打包构建工具，把动物都放进去演马戏了，没毛病。
这个项目在最初期的时候，其实并不是特别令人满意，因为早期它身上 Cloudera 的影子太多了，打包时有些依赖直接就是引用 Cloudera 的库的，导致打出来的包里面还有 Cloudera 的玩意，并不是纯正的 “ Apache ” 版本，并且由于当时 Cloudera 和 Hortonworks 的竞争关系，初期这东西和 Ambari 很难进行集成。不过经过多年的发展，现在这些问题都得到了有效的解决。
BigTop 本身是实现了自己的 Stack 的，包含的都是 100% 纯正的 Apache 原生组件，这个 Stack 你可以理解为是一种“公版”发行版方案。
目前 BigTop 1.4.0 Stack 包含了如下组件：
bigtop 1.4.0 stack includes the following components alluxio 1.8.1 ambari 2.6.1 apex 3.6.0 bigtop_groovy 2.4.10 bigtop_jsvc 1.0.15 bigtop_tomcat 6.0.45 bigtop_utils 1.3.0 flink 1.6.4 flume 1.8.0 giraph 1.1.0 gpdb 5.10.0 hadoop 2.8.5 hama 0.7.1 hbase 1.3.2 hive 2.3.3 ignite_hadoop 1.9.0 kafka 0.10.2.2 mahout 0.13.0 oozie 4.3.0 phoenix 4.13.1-HBase-1.3 qfs 2.0.0 solr 6.6.0 spark 2.2.3 sqoop 1.4.6 sqoop2 1.99.4 tajo 0.11.1 tez 0.9.1 ycsb 0.12.0 zeppelin 0.7.3 zookeeper 3.4.6
当然 BigTop 的 Stack 构建和商业发行版比较起来，进度并不算快，目前基于 hadoop 3 的 Stack 构建还尚未完成。在 BigTop 的项目声明中，它是无意与任何发行版去做竞争的，并且也欢迎大家来使用 BigTop 作为自己发行版打包的基础工具。例如 Cloudera 自己就是基于 BigTop 来打包 CDH 的。
在去年的 Linaro Connect San Diego 2019 上，Yuqi Gu （现为 Apache BigTop 项目的 Committer）就分享了基于这套体系在 Arm64 上成功编译和部署 Hadoop 集群的实践（https://static.linaro.org/connect/san19/presentations/san19-405.pdf）。
其实基于 Apache Ambari + Apache BigTop 来构建发行版，早就不是什么新鲜事儿了。国内不少发行版都利用了这两个开源组件，当然，有些是绝口不提，有些是换皮隐瞒，有些是大方承认 …… （当然，这不是本文的重点，国产发行版的那些东西不想说太多，万一人家说你诽谤，像笔者这种穷人可是吃不起官司的…）这里就说说大方承认的，国内的红象云腾，旗下的发行版“ CRH ”，就是基于 Apache Ambari + Apache BigTop 来构建的，当然，商业化公司的进度做的都是很快的，远远超过社区，CRH 实际上是为 Ambari 提供了支持五大指令集硬件的 Stack，所以在国产的芯片和操作系统上安装都是没有问题的，这也是他们的商业生存策略，因为直接和有 Intel 投资的 Cloudera 硬刚 x86/x64 架构这块肯定是玩不过嘛，所以他们的客户基本都是非常依赖完全国产化的，比如航天和军事领域的客户。
4、杀出个程咬金？
虽然 Cloudera 对开源做出了自己的承诺，但是还是有很多开发者忧心忡忡，当心万一被“资本主义”切断了“安全绳”怎么办，万一“Cloudera 背叛了社区怎么办”。所以在一些讨论邮件中，甚至会有开发者提议，要不我们自己花钱组点人再弄一套开源发行版吧 ！（国外开发者还是太有钱有闲了…）。对于这种行为，你要问我支持不支持，我肯定是（精神）支持的啦，多点选择，永远是好的嘛。
↓扫码关注 咕噜咕噜大数据 公众号↓
本文分享自微信公众号 - 咕噜咕噜大数据（gulugulu_bigdata）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
