Bigtop 从零开始搭建大数据集群

news/2025/11/6 18:30:56/文章来源:https://www.cnblogs.com/smiecj/p/19197409

背景

公司目前在线上环境使用的是基于 HDP 2.6.3 搭建的大数据集群，在持续使用4年之后，是否要给集群做个升级成为了一个值得思考的问题

现在集群的 Hadoop 版本是 2.7.3，继续使用倒也没什么问题，但一些使用痛点还是着实存在的，并且每一点都扎根于这套架构，不做大的升级也不可能解决，感受明显的主要有三点:

离线数仓相关组件版本普遍较旧，HDFS 落后一个大版本，Hive 落后两个大版本。想用新的 Hive SQL 函数或者语法，都是不支持的
缺乏上层应用，支持血缘分析、数据质量可视化等功能，所有数据相关的接入和分析需求都是人工对接和实现
组件“各自为战”，部署和维护方式差异很大，升级时仍需要大量的人工操作

带着这些问题，去寻找开源社区的升级解决方案，会找到以 Bigtop 作为部署工具，Ambari 作为管理平台，是目前我们所使用的 HDP 改造成本最小的

那么什么是 Bigtop，它和大数据集群部署有什么关系，需要从 CDH 的发展历史说起

HDP 到 CDP: 从开源到闭源

在大数据和 Hadoop 生态蓬勃发展的十几年前，最流行的部署方案就是 HDP 和 CDH 这两个部署套件

HDP (Hortonworks Data Platform) 最初发展于 2012 年，由几个雅虎工程师共同创立的 Hortonworks 公司，他们旨在打造开源、安全、可扩展的 Hadoop 集群。HDFS 从 2.0 发展到 3.0 的阶段，HDP 对 Hadoop 的核心功能做出了非常大的贡献

来源

CDH (Cloudera Distribution including Apache Hadoop) 和 HDP 一样也是提供大数据成套组件的，它是 2008 年由来自 Google、Yahoo!、Facebook、Oracle 的大数据工程师共同创办的 Cloudera 公司发起的项目，除了为 HDFS 此外还提供了可用于 Hive 加速查询的引擎 impala，以及数据即席查询服务 Hue

来源

不过面对 AWS 及其他公有云厂商的挑战，只往开源方向发力显然是不够的。到了 2018 年，CDH 收购了 HDP，并逐渐停止了对 HDP 和 CDH 的维护，现在 Cloudera 提供的 CDP (Cloudera Data Platform) 也是彻底转向了私有云、定制化和按需收费的模式

HDP 和 CDH 走向商业化，对于大数据开源社区无疑是冲击巨大的，特别是国内中小公司做大数据平台的商用化的这部分业务，大部分就是基于这两个套件做封装和二次开发的。对于使用这些平台的中小厂，为了保证平台的可靠性，也更多转向了公有云的 EMR ( 参考: CDH/HDP 何去何从 )

Ambari

在了解了 HDP 和 CDH 之后，我们来看一个非常重要的开源组件 Ambari，这也是作为大数据平台运维必然会接触的组件

Ambari 是 Hortonworks 公司开发的用来部署和管理大数据集群的服务，它规范了组件的部署流程，通过界面，按照组件选择、节点选择、自定义配置、触发后台安装任务的固定流程，几分钟就可以完成 Hadoop 集群的部署。它还对 Hadoop 组件的配置进行了一定优化，实际安装时需要你手动修改的配置很少。另外它还开放了 restful 接口，在运维上具有一定扩展性，可以基于它再开发上层的大数据平台，对集群和组件进行展示

除了组件安装、组件配置、监控和故障自动重启这些基本功能之外，最大的特点是它还集成了 Hadoop 集群运维的一些复杂的手动操作，假设我们先搭建了 namenode 单点模式的 HDFS，需要把它扩展成 HA 模式，部署两个 namenode，完整的步骤至少需要5步（部署 journalnode -> 启动 secondary namenode -> 初始化 share edits -> 启动集群 -> 启动 ZKFailoverController ），每一步都涉及到配置变更，稍有一步做错可能集群就起不来了，操作风险很大。而 Ambari 会帮你做好大部分的动作，你只需要按它要求执行几条指令就行，就像有一个运维专家在旁边手把手辅助你

来源

不过 Ambari 的不足也是很明显的。首先是它对大数据组件的支持比较限定于 Hadoop 生态下的组件，像 HDFS、YARN、Hive、HBase、Zookeeper 等组件的安装和维护功能支持是很好的，但是 Flink，Spark 这些比较年轻的组件，除了部署之外就没有任何管理相关的功能了。独立于 Hadoop 生态的 Jupyter 、Hue 这些就完全没集成，要是想用 Ambari 去部署和管理这些组件，就只能按照 Ambari 的组件规范自己开发安装脚本，工作量不小，而且这些脚本的扩展价值也不高

其次，它基于虚拟机的部署架构，也基本不可能去融合 kubernetes 的生态。对于 Hadoop 传统组件来说，其服务架构特点决定了上云本来就是比较困难的事情，基于虚拟机部署也没什么问题，但是放到 Flink 和 Spark 这类容错度比较高，也可以跑在 k8s 的任务引擎，通常在前期部署架构的选型上，运维就会直接选择 on k8s, 这也会进一步造成大数据集群部署架构上的割裂

现在只考虑部署 Hadoop 集群的话，选择 Ambari 作为管理服务还是没什么问题的，功能和稳定性都有基本保障

关于 Ambari 还有一段小历史比较有趣: HDP 和 CDH 合并之后，随着开发者投入商用版本，Ambari 在2年多的时间都是停止维护的状态，甚至面临从 Apache “退役”。但奈何 Ambari 实在是没有很好的替代品。于是在众多大数据开发者的呼声之下，2022 年 Apache 社区投入了几个人力，总算是重启了 Ambari 项目，并于今年4月发布了合并众多修复的 3.0 版本

Ambari 有两年多处于停止维护状态

Bigtop 和 Ambari

Apache Bigtop 项目最初是由 Cloudera 的几个开发者在 2011 年发起，后续捐赠给 Apache 的一个开源项目，目的是开发一套大数据组件编译、构建、部署的流程工具。它的机制是通过 gradle、shell 和 puppet 等脚本语言（其中 puppet 本身就是组件安装和管理编排工具，在基础设施运维、大数据和openstack中都有用到）定义每个组件的编译构建启动行为流程，让你可以在 centos、ubuntu、debian、openeuler 等操作系统上，使用相同的指令就可以完成相同的动作。为了确保编译过程的顺利，它还将官方补丁 patch 文件保存在自己项目中，这样所有的代码都来自开源，所有改动都是可见的

没有 Bigtop 的时候，如果你接了一个“构建大数据编译部署流水线”的需求，由于每个项目之间的编译方式和系统依赖都各有不同，基本还没踩完编译的坑就已经打退堂鼓了。如今有了 Bigtop 帮我们封装编译的所有过程，实现这个需求终于不再是一个难题

来源: Bigtop 与 Bigtop Manager — 新一代大数据集群管理平台

开源大数据底座平台对比

再纵观其他的开源大数据部署和管理平台，会发现它们的设计思想和 Ambari+Bigtop 基本无异，因此就不针对每个平台做详细介绍了，直接看我们最关注的一些对比点

这些平台目前都还不能作为 Ambari 的成熟替代品，但还是有值得关注的地方

bigtop manager 定位就是 Ambari 的替代品，为了让 Bigtop 摆脱对 Ambari 的依赖，有自己的集群部署可视化服务。虽然它的活跃开发者不多，而且现在的基础功能还是不完善状态，但这个项目毕竟是在 apache 组织下，至少不会完全停止维护吧

来源

国内开发者贡献的 CloudEon 和 datasophon 也同样值得尝试，它们的贡献者主力还是来自国内开发者的用爱发电。最近更新频率比较低。但它们的架构设计上比 Ambari 要轻量许多。如果你是大数据的初学者，想先快速搭建集群，它们或许是比 Ambari 更好的选择

来源

Bigtop 构建大数据集群安装包

接下来的内容主要是介绍 Bigtop 和 Ambari 的编译构建方式，如何从零开始搭建一套基于 Bigtop 的大数据集群

官方 repo 源

Bigtop 有两种获得安装包的方式，一种是直接使用官方 yum/apt 源，还有一种是自行编译。前者提供的最新 3.5.0 版本支持 debian, ubuntu, openeuler 等系统（3.3.0 支持 centos），直接在系统上配置软件源，就可以安装 Hadoop 等组件了，这也是你最快的使用 Bigtop 的方式

# 添加 ubuntu 源
wget -O /etc/apt/sources.list.d/bigtop-3.5.0.list https://dlcdn.apache.org/bigtop/bigtop-3.5.0/repos/ubuntu-24.04/bigtop.list
wget -O- https://dlcdn.apache.org/bigtop/stable/repos/GPG-KEY-Bigtop | sudo apt-key add -# openeuler 源地址
https://dlcdn.apache.org/bigtop/bigtop-3.5.0/repos/openeuler-22.03/bigtop.repo# centos (3.3.0) 源地址
https://mirrors.huaweicloud.com/apache/bigtop/bigtop-3.3.0/repos/centos-7/bigtop.repo

编译 Bigtop 组件

Compiling Components for Ambari Bigtop Stack

如果你是个好奇宝宝，不想直接用官方提供的安装包，就是想体验一下大数据组件是怎么编译的，那么恭喜你选择了一条最有意思（最漫长）的路，你会了解到 Hadoop 生态下的一众组件 hdfs, hive, hbase, zookeeper, ranger 等等的编译过程（当然还有各种踩坑）

（可能为数不多的好处就是可以了解到 Bigtop 的编译脚本如何设计的了，对你写运维脚本还是有点帮助的 .. ）

前面提到 Bigtop 对编译脚本做了封装，就在每个组件目录下的 do-component-build 。从 Hive 的编译脚本来看，其实编译指令就是mvn package ，和你手动编译没什么区别

在项目根路径，通过 gradlew 指令即可开始每个组件的编译

# 列出所有操作
./gradlew tasks# 初始化编译环境（安装 jdk, maven, python3 等）
# 比较费时，更建议使用官方 slave 镜像，省略这一步
./gradlew toolchain# 在 output 目录下创建 yum / apt 源目录 (下面的编译指令也会自动创建)
./gradlew yum
./gradlew apt# 以下是各个组件的编译指令
# parentDir: 组件安装父目录
# pkgSuffix: 组件名称中是否添加 Bigtop 的版本，比如 hive 的安装包名字为 hive_3_3_0
# buildThreads: 是否并发编译，将在 mvn 编译参数中加上 -T 2C
# repo: 编译完成后更新 yum / apt repo 
# Bigtop 相关工具链编译
./gradlew bigtop-select-clean bigtop-select-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo./gradlew bigtop-utils-clean bigtop-utils-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo./gradlew bigtop-jsvc-clean bigtop-jsvc-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo./gradlew bigtop-groovy-clean bigtop-groovy-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# Hadoop
./gradlew Hadoop-clean Hadoop-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# hive
./gradlew hive-clean hive-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# zookeeper
./gradlew zookeeper-clean zookeeper-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# kafka
./gradlew kafka-clean kafka-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# hbase
./gradlew hbase-clean hbase-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo# ranger
./gradlew ranger-clean ranger-pkg -PparentDir=/usr/bigtop -PpkgSuffix -PbuildThreads=2C repo

注意到所有组件的编译指令，除了组件名其余部分都是一样的，这就是 Bigtop 对编译脚本的封装起到的作用

比如 "pkg" 这个命令，从 packages.gradle 可以看到识别操作系统的逻辑，包含了执行 patches 、编译和最后打包的动作，打包时centos 系统就执行 rpmbuild，ubuntu 就执行 debuild

Bigtop 还提供了几个辅助指令，比如 bigtop-select 可以用来查询目前集群中哪些组件可以安装，bigtop-utils 可以查找 java 安装路径等，这两个指令在 Ambari 有用到

当组件编译完成，Bigtop 源码目录下会生成三个目录: dl 是源码压缩包的下载路径，build 是构建中间目录，output 则存放组件安装包和源索引文件

在文件服务器配置自己的源

官方的 Bigtop 源的配置方式刚才提过了，那自己编译生成的安装包怎么配源呢，就把整个 output 目录作为文件服务器指向的目录就可以

比如我直接在 Bigtop 编译机器上启动了 httpd，配置中指定根路径就为 bigtop/output

DocumentRoot "/opt/coding/bigtop/output"
<Directory "/opt/modules/bigtop/output">Options Indexes FollowSymLinksAllowOverride NoneRequire all granted
</Directory>

那么 yum 和 apt 源的配置方式分别为:

# centos: yum 在 output 目录构建索引
createrepo .
# 在安装组件的节点上配置源
echo """[BIGTOP-3.5.0-repo-1]
name=BIGTOP-3.5.0-repo-1
baseurl=http://file_server_host
path=/
enabled=1""" > /etc/yum.repos.d/ambari-bigtop-1.repo
# 刷新
yum -y update# ubuntu: apt 在 output 目录构建索引
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
# 在安装组件的节点上配置源
echo "deb [trusted=yes] http://172.16.205.157:8000/bigtop/3.5.0 ./" > /etc/apt/sources.list.d/bigtop.list
# 刷新
apt -y update

扩展: Bigtop 的工具和容器

最后再介绍一下 Bigtop 提供的容器和编译部署工具，这些可以帮助你快速了解 Bigtop 的生态，加快构建过程

bigtop/slaves - Bigtop 官方提供的编译镜像, 预装了 jdk、maven、ant、python3、以及 Hadoop 组件编译时需要的基础环境（ puppet、protobuf、r-base 等），方便你直接编译 Bigtop。如果你所使用的操作系统镜像没有提供以上的依赖，强烈建议直接使用 slave 镜像来编译

# 运行 bigtol slave 镜像
# 支持编译 Bigtop 3.3.0 的镜像，centos7、ubuntu 和 x86 以及 arm 的架构版本都有，还是挺全的
docker run -itd --hostname dev_Bigtop --name dev_Bigtop -v /opt/coding:/opt/coding Bigtop/slaves:3.3.0-centos-7docker run -itd --hostname dev_Bigtop --name dev_Bigtop -v /opt/coding:/opt/coding Bigtop/slaves:3.3.0-centos-7-aarch64# ubuntu 版本
docker run -itd --hostname dev_Bigtop --name dev_Bigtop -v /opt/coding:/opt/coding Bigtop/slaves:3.5.0-ubuntu-24.04docker run -itd --hostname dev_Bigtop --name dev_Bigtop -v /opt/coding:/opt/coding Bigtop/slaves:3.5.0-ubuntu-24.04-aarch64

bigtop/sandbox: 基于 Bigtop 编译的 Hadoop 单点服务打包成的镜像，可以一键运行单点 HDFS、HBase 和 Spark 等。不过使用方式有限，只能做个展示效果。而且在 Bigtop 1.2.1 之后，镜像就没有再更新了，提供的 HDFS 版本只到 2.7.3

# 启动 hdfs
docker run -d --name dev_Bigtop_hdfs -p 50070:50070 Bigtop/sandbox:1.2.1-ubuntu-16.04-hdfs# 启动 hdfs + hbase
docker run -d --name dev_Bigtop_hbase -p 50070:50070 -p 16010:16010 Bigtop/sandbox:1.2.1-ubuntu-16.04-hdfs_hbase# 启动 hdfs + spark
docker run -d --name dev_Bigtop_spark -p 50070:50070 -p 8080:8080 -p 7077:7077 Bigtop/sandbox:1.2.1-ubuntu-16.04-hdfs_spark-standalone

最后是 bigtop/puppet，这个镜像是 slave 的前身，它的构建代码在 Bigtop 1.3.0 之前的版本还是有的 ( docker/bigtop-puppet/build.sh ) ，但最新代码已经删除了。和 slave 相比，puppet 镜像只是把 puppetize.sh 拷贝到镜像中，还没有实际安装 puppet，也没有执行 puppet apply -e "include Bigtop_toolchain::installer" 安装基础依赖（ slave 镜像提供的所有依赖），所以唯一的作用也许就是让你可以从真正的开头去构建 Bigtop 镜像，以及从 tags 可以知道 Bigtop 目前支持的操作系统，除此之外没有其他作用

扩展: Bigtop 修复了哪些 issue

在 Bigtop 代码中我们会看到一些组件的 patch 补丁文件，Hadoop 的 patch 是最多的（11个），这些补丁大部分来自官方 issue，为了升级或解决编译问题。如果没有这些 patch，编译众多开源服务可以说就是真正的从零开始了，遇到各种编译问题都要自己找 issue 甚至看代码解决

所以这里对 Hadoop 的 patch 稍作整理，看看主要是哪些问题的修复

注意: 带有 issue 数字编号的 patch 都是来自 Hadoop 组件官方的修复，没有编号的则是 Bigtop 为了解决编译问题自己加的，主要关注前者

patch0-HADOOP-18867-branch-3.3.diff: zookeeper 3.6 已经停止维护，升级到 3.6.4 即 3.6 的最后一个小版本，为升级到 3.7 做准备
patch1-HADOOP-19116-3.3.6: 升级 zookeeper 到 3.8.4 以解决 zookeeper 在 watcher 机制的数据安全问题
patch10-HDFS-17754-branch-3.3: 添加 Hadoop native 中用到的 uriparser2 库的相关说明
patch2-HADOOP-18583: native 代码适配 openssl 3.x 版本，替换两个加解密相关的变量名
patch3-fix-broken-dir-detection: Hadoop-functions.sh 脚本中增加对 HADOOP_COMMON_HOME、HADOOP_HDFS_HOME 等环境变量对应的路径是否存在的判断
patch4-HADOOP-19551 & patch9-HDFS-17226.diff: 编译 native 时添加 gcc 参数 implicit-function-declaration，并在4个 .h 头文件中补充 #include 已解决编译问题
patch5-fix-kms-shellprofile: 这个只是把 Hadoop-kms.sh 中创建 ${HADOOP_HOME}/temp 目录的逻辑给去掉了，估计只是为了跳过编译中的 test error ，没有其他实际意义
patch6-fix-httpfs-sh: 同上，httpfs.sh 中用到的 HADOOP_HOME 替换成 HADOOP_HDFS_HOME，无实际意义
patch7-remove-phantomjs-in-yarn-ui: Yarn ui 中移除 phantomjs 模块，解决在缺少 phantomjs 的系统（如 arm 版本的 centos ）编译失败的问题
patch8-YARN-11528-triple-beam: 在 resolutions 中限定 triple-beam 的版本为 1.3 ，解决 1.4.1 版本不兼容 yarn ui 编译使用的 v12 nodejs 的问题
patch9-HDFS-17287: HDFS yarn 模块支持并行编译，实测不指定并发的非首次编译（ maven 依赖在本地都已经下载）的时间大约30分钟，加上4个线程并发后编译时间缩短到15分钟
patch0-KAFKA-14661: 升级 zookeeper 依赖版本从 3.6.4 到 3.8.2
patch3-RANGER-3206-commit-2: 修复 ranger 执行 db 初始化时报字符串变量转换的错误
patch0-RANGER-4952: 支持 hive 4.0

Ambari 编译和大数据集群部署

Bigtop 的安装包我们准备好了，如何结合 Ambari 来部署大数据集群呢

第一步又是我们最喜欢的编译环节，因为Ambari 官方是没有提供直接的 apt 或者 rpm 安装包的。这里建议编译 3.0 或者最新分支（ 3.0 基本是最后一个大版本了）

Ambari 编译和安装

参考: Building Apache Ambari from Source

Ambari 的编译虽然不像 Bigtop 那样需要安装很多依赖，只需要 java 和 python，但关于 python 版本还是需要特别提一下: 官方文档提到 3.0 脚本是基于 python3 适配的，但其实它的一部分脚本还依赖 python2，所以编译和运行 Ambari 的系统仍需要装有 python2。另外它适配的 python3 版本基于 python 3.9，其用到的 imp 在 3.12 之后被移除了，所以要注意不能用最新版的 python3

# Ambari 3.0 依赖 jdk17
export JAVA_HOME=/usr/java/jdk-17.0.15+6
source /opt/modules/miniconda2/bin/activate py3# ubuntu
mvn -Drat.skip=true -DskipTests -Dcheckstyle.skip=true package jdeb:jdeb
# ./ambari-server/target/ambari-server_3.1.0.0-SNAPSHOT-dist.deb
# ./ambari-agent/target/ambari-agent_3.1.0.0-SNAPSHOT.deb# centos
mvn -Drat.skip=true -DskipTests -Dcheckstyle.skip=true package rpm:rpm
# ambari-server/target/rpm/ambari-server/RPMS/x86_64/ambari-server-3.1.0.0-SNAPSHOT.x86_64.rpm
# ambari-agent/target/rpm/ambari-agent/RPMS/x86_64/ambari-agent-3.1.0.0-SNAPSHOT.x86_64.rpm

编译完成后，server 和 agent 的安装包在各自 module 的target 目录下。然后可以按照一个 server 、多个 agent 节点的分配方式，开始安装 Ambari

# centos
rpm -ivh ambari-server-3.1.0.0-SNAPSHOT.x86_64.rpm
rpm -ivh ambari-agent-3.1.0.0-SNAPSHOT.x86_64.rpm# ubuntu
dpkg -i ambari-server_3.1.0.0-SNAPSHOT-dist.deb
dpkg -i ambari-agent_3.1.0.0-SNAPSHOT.deb# 注: agent 还需要安装 bigtop-select 用于 Ambari 查找组件版本
yum -y install bigtop-select
apt -y install bigtop-select

Ambari 初始化和启动

启动 Ambari 就是启动 server 和 agent，两者之间通过 http 和 websocket 的方式通信，server 负责用户交互和服务状态管理，agent 负责处理来自 server 下发的任务

先对 Ambari server 使用的数据库和配置做初始化

# 1. 手动下载 jdbc jar 到共享 jar 目录
wget -O /usr/share/java/mysql-connector-java-8.0.30.jar https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.30/mysql-connector-java-8.0.30.jar# 2. 手动补充 server.jdbc.driver.path 配置，否则 Ambari server setup 会报错
echo "server.jdbc.driver.path=/usr/share/java/mysql-connector-java-8.0.30.jar" >> /etc/ambari-server/conf/Ambari.properties# 3. 初始化 server
# -s: silent mode
# --ambari-java-home: Ambari server 使用的 jdk
# --stack-java-home: Hadoop 组件使用的 jdk
# 在组件管理 py 代码中会通过 config["AmbariLevelParams"]["java_home"] 获取
ambari-server setup -s --ambari-java-home /usr/java/jdk-17.0.16+8 --stack-java-home=/usr/java/jdk-11.0.28+6 --database=mysql --databasehost=mysql_host --databaseport=mysql_port --databasename=mysql_db --databaseusername=mysql_user --databasepassword=mysql_pwd --jdbc-driver=/usr/share/java/mysql-connector-java-8.0.30.jar --jdbc-db=mysql# 4. 启动 server
systemctl restart ambari-server

启动后打开默认 8080 端口，通过 admin/admin 默认账号登录

给集群起个名字之后，接下来是配置 Bigtop 版本和安装源

上面的 version definition 是 Ambari 源码中的 Bigtop 组件定义，目前只到 Bigtop 3.3，这个不一定和我们实际编译的（最新到 3.5）一致，但对安装没有影响，实际安装的版本以 bigtop-select 指定的版本为准

下面的 Repositories 配置你自己的文件服务器地址或者是官方源。如果你在之前已经手动添加了 repo 文件，也可以选择 use local repo

下一步是添加 Ambari agent 节点，这里可以用 server 通过 ssh 向 agent 节点主动注册，或者手动启动 agent 来向 server 注册的方式

注: Ambari 可以配置组件的自动重启，但 server 的 agent 本身的自动重启就需要通过系统的 systemctl enable ambari-server / ambari-agent 来开启了

# 设置 Ambari server host 域名地址
sed -i "s#hostname=.*#hostname=Ambari_server_host#g" /etc/ambari-agent/conf/ambari-agent.ini# 启动 agent
systemctl restart ambari-agent

等待 agent 显示注册成功

组件部署

添加了 agent 节点，下一步 choose services 就是正式安装 Bigtop 构建的组件了

第一个组件可以选择 zookeeper。默认会勾选所有组件，但没必要全都安装。zookeeper 是很多服务的依赖组件，选择第一个安装是合理的

zookeeper server 和 agent 的安装节点选择三个

通过 Ambari 安装组件的一大好处就是很多配置它都帮你优化好了，除了一些存储数据路径，或者是需要针对虚拟机规格情况特别调优的配置，需要自行确认

最后等待 zookeeper 在后台安装完成，回到首页的效果

集群安装完整事项

让我们再来回顾一下从零开始部署一套真正可用的大数据集群的所有步骤吧

支持 Bigtop 构建的虚拟机, centos8、ubuntu、rockylinux、debian、openeuler 等
构建 Bigtop 安装包，建议在官方 slave 容器内构建
Ambari 编译
Ambari 安装
系统配置 Bigtop yum/apt 源
Ambari 配置和启动
可按照 zookeeper -> HDFS -> Yarn -> Hive -> Ranger -> 其他组件的顺序安装集群
HDFS 、Hive 等核心组件配置高可用
监控配置（可基于 Ambari metrics 或 prometheus ）
日志采集（solr）
基础功能验证

总结

shall we start now

再回到开头的问题，对已经稳定运行几年的集群再做大升级，这是否有必要。经过这一趟集群部署和体验下来，现在可以明确说，当然有必要。因为这不仅是一次升级，更是可以让我们尽可能乘上还在不断前进的大数据开源列车。不管以后是继续用这套开源架构，还是将大数据 deploy on k8s，又或是选择公有云 EMR，有了这次升级的铺垫，后面再做任何大的架构升级都会更有信心

一颗种子种下的最好时间永远不是未来，而是现在

从 CDH 到 Bigtop 的改进点

组件	版本升级	特性
基础环境	jdk 8 -> 11	性能和功能提升
基础环境	centos 7 -> ubuntu 24	更安全、功能更丰富、性能更好的系统
EMR 组件	Ambari 2.6 -> 3.0	集群管理、维护，可调研 bigtop manager
EMR 组件	HDFS 2.7.3 -> 3.3.6	纠删码、NameNode 多节点高可用、性能提升等
EMR 组件	Hive 2.1 -> 3.1.3	SQL 增加窗口函数、复杂数据类型、性能提升等
EMR 组件	Sqoop -> Datax/seatunnel	支持更多数据源之间同步，sqoop 已停止维护
EMR 组件	Azkaban 3.9 -> 4.0	bug 修复，基本是最后一个 release，可调研 airflow
EMR 组件	Hue 3.9 -> 4.2	界面功能改进、修复编译问题
EMR 组件	Jupyter 3.6 -> 4.3	功能提升
EMR 组件	Flink 1.20, CDC 3.4	目前主要用于实时数据同步 flink cdc
EMR 组件	Starrocks 3.3	实时数仓
集群管理工具	emrtool	ETL任务管理, 血缘关系