https://community.cloudera.com/t5/Product-Announcements/ANNOUNCE-Cloudera-Enterprise-6-3-3-Released/td-p/289016
其实现在来看,完全就是一个温水煮青蛙的过程:
免费版不限制节点数量 -> 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 背叛了社区怎么办”。所以在一些讨论邮件中,甚至会有开发者提议,要不我们自己花钱组点人再弄一套开源发行版吧 !(国外开发者还是太有钱有闲了…)。对于这种行为,你要问我支持不支持,我肯定是(精神)支持的啦,多点选择,永远是好的嘛。