企业官网建设流程全解析

1. 为什么我选择用 Docker 来搭 Hadoop 集群

第一次接触 Hadoop 集群部署是在一台老旧的笔记本上，当时用三台虚拟机跑伪分布式，风扇狂转、内存告急，光是装系统、配 SSH、改 hosts 就折腾了整整两天。后来换到 Docker 方案，同样的硬件条件，十分钟内就能拉起一个包含一个主节点和两个从节点的完整分布式集群，而且随时可以推倒重来。这个对比让我彻底转向了容器化部署的思路。

Hadoop 分布式集群部署的核心痛点其实不在 Hadoop 本身，而在于环境一致性。NameNode、DataNode、ResourceManager、NodeManager 这些角色分散在不同机器上，每台机器的 JDK 版本、系统库、网络配置、主机名解析稍有差异，集群就可能起不来。Docker 的价值就在于把每个节点的运行环境打包成镜像，用同一份镜像启动多个容器，环境差异被彻底消除。你不需要再担心“在我机器上是好的”这类问题。

这篇文章适合谁看？如果你正在学习大数据技术，需要频繁搭建和销毁 Hadoop 集群做实验；或者你是运维工程师，想用容器化方式管理大数据组件；又或者你只是好奇 Docker 和 Hadoop 能碰撞出什么火花，这篇文章都会给你一套可以直接复现的方案。我会从镜像构建、网络规划、配置拆分、启动编排到常见故障排查，把整个流程拆开揉碎讲清楚。

需要提前说明的是，我采用的方案是基于 Docker 原生网络和手动编排的方式，不依赖 Docker Compose 或 Kubernetes。原因很简单：学习阶段用最基础的工具能让你看清每个环节的细节，等你理解了底层逻辑，再上编排工具就是水到渠成的事。整个方案在一台 8GB 内存的开发机上就能跑起来，对硬件要求并不高。

2. 集群架构设计与核心思路拆解

2.1 节点角色分配与容器规划

Hadoop 全分布式集群通常包含以下核心角色：NameNode 负责管理文件系统元数据，DataNode 负责实际数据块的存储，ResourceManager 负责集群资源调度，NodeManager 负责单个节点的资源管理，SecondaryNameNode 负责辅助 NameNode 做检查点操作。在最小可用集群中，我习惯把 NameNode 和 ResourceManager 放在同一个容器里作为主节点，两个从节点各自运行 DataNode 和 NodeManager。

这样规划的结果是三个容器：一个主节点容器，两个从节点容器。主节点容器同时承担 NameNode、ResourceManager 和 SecondaryNameNode 三个角色，从节点容器各自承担 DataNode 和 NodeManager 角色。这种分配方式在实验环境中足够用，而且资源占用可控。如果你需要更真实的模拟，可以把 SecondaryNameNode 单独拆出来，但那样就需要第四个容器，对内存的要求会更高。

容器规划确定后，接下来要解决的是网络问题。Docker 默认的 bridge 网络会给每个容器分配一个动态 IP，但 Hadoop 集群配置中需要写死主机名和 IP 的映射关系。如果每次启动容器 IP 都变，配置文件就得跟着改，这显然不可接受。我的做法是创建一个自定义 bridge 网络，并给每个容器指定固定的 IP 地址。这样主机名和 IP 的对应关系就是稳定的，配置文件一次写好，后续反复使用。

2.2 镜像分层设计与基础环境选型

镜像构建是整个方案的地基。我选择从 Ubuntu 22.04 作为基础镜像，原因是它的软件源稳定、社区支持好，遇到问题容易找到解决方案。JDK 选用 OpenJDK 8，这是 Hadoop 3.x 官方推荐的版本，兼容性经过大量验证。Hadoop 版本我选的是 3.3.6，这个版本修复了早期 3.x 的不少 bug，同时保持了较好的稳定性。

镜像分层上，我把 JDK 安装和 Hadoop 安装分成两层。这样做的好处是，如果后续只需要升级 Hadoop 版本，JDK 层可以直接复用缓存，构建速度会快很多。具体来说，第一层安装 JDK 并配置 JAVA_HOME 环境变量，第二层下载并解压 Hadoop，配置 HADOOP_HOME 和 PATH。每一层都尽量把不常变动的操作放在前面，把容易变动的操作放在后面，这是 Docker 镜像构建的基本功。

还有一个细节值得注意：Hadoop 的配置文件我选择在容器启动时通过挂载卷的方式注入，而不是直接打进镜像。这样做的好处是，同一份镜像可以用于主节点和从节点，只需要在启动时挂载不同的配置文件即可。镜像的复用性提高了，维护成本也降低了。如果你把配置写死在镜像里，每次改配置都要重新构建镜像，那容器化的优势就大打折扣了。

2.3 网络模式选择与固定 IP 方案

Docker 的网络模式有 bridge、host、overlay 等多种选择。对于单机上的 Hadoop 集群，bridge 模式是最合适的。host 模式虽然性能更好，但容器会直接使用宿主机的网络栈，端口冲突问题很难避免。overlay 模式适用于跨主机的容器通信，单机场景下属于杀鸡用牛刀。

我创建自定义 bridge 网络的命令是这样的：docker network create --subnet=172.20.0.0/16 hadoop-net。这个子网范围足够大，不会和常见的家庭或办公网络冲突。然后启动容器时用--ip参数指定固定 IP，比如主节点用 172.20.0.10，两个从节点分别用 172.20.0.11 和 172.20.0.12。这样在 Hadoop 的配置文件中，我可以直接用这些 IP 来指定 NameNode 和 ResourceManager 的地址。

固定 IP 带来的另一个好处是，容器的/etc/hosts文件可以在启动时通过--add-host参数预先写好所有节点的映射。比如启动主节点时加上--add-host=slave1:172.20.0.11 --add-host=slave2:172.20.0.12，这样容器内部就能直接通过主机名访问其他节点，不需要额外配置 DNS。这个细节看似简单，但省去了很多手动改 hosts 文件的麻烦。

3. 镜像构建与基础环境配置实操

3.1 编写 Dockerfile 的完整过程

Dockerfile 是整个镜像构建的蓝图。我先把完整的 Dockerfile 写出来，然后逐段解释每个指令的意图。

FROM ubuntu:22.04 ENV DEBIAN_FRONTEND=noninteractive ENV JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 ENV HADOOP_HOME=/opt/hadoop ENV HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop ENV PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin RUN apt-get update && \ apt-get install -y openjdk-8-jdk ssh pdsh curl wget vim net-tools && \ rm -rf /var/lib/apt/lists/* RUN wget -q https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz -O /tmp/hadoop.tar.gz && \ tar -xzf /tmp/hadoop.tar.gz -C /opt && \ mv /opt/hadoop-3.3.6 /opt/hadoop && \ rm /tmp/hadoop.tar.gz RUN ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa && \ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys && \ chmod 0600 ~/.ssh/authorized_keys EXPOSE 9870 8088 9000 9864 8032 CMD ["/bin/bash"]

第一段设置环境变量，DEBIAN_FRONTEND=noninteractive是为了避免 apt 安装过程中弹出交互式配置界面导致构建卡住。JAVA_HOME 指向 OpenJDK 8 的安装路径，HADOOP_HOME 指向 Hadoop 的解压目录，PATH 把 Java 和 Hadoop 的可执行文件都加进去。

第二段安装依赖包。openjdk-8-jdk是 Java 运行环境，ssh和pdsh是 Hadoop 集群内部通信和批量命令执行需要的工具，curl和wget用于下载文件，vim和net-tools是调试时的常用工具。安装完成后清理 apt 缓存，减小镜像体积。

第三段下载并解压 Hadoop。这里用的是 Apache 官方归档地址，版本 3.3.6。解压后把目录重命名为/opt/hadoop，这样路径更简洁，后续配置引用起来也方便。

第四段生成 SSH 密钥对并配置免密登录。Hadoop 的启动脚本需要通过 SSH 连接到各个节点执行命令，如果每次都要输入密码，自动化就无从谈起。在镜像构建阶段就把密钥生成好，容器启动后直接可用。

最后暴露 Hadoop 常用端口：9870 是 NameNode 的 Web UI 端口，8088 是 ResourceManager 的 Web UI 端口，9000 是 NameNode 的 RPC 端口，9864 是 DataNode 的 Web UI 端口，8032 是 ResourceManager 的 ApplicationMaster 通信端口。

3.2 构建镜像与验证基础环境

Dockerfile 写好后，在它所在的目录执行构建命令：

docker build -t hadoop-base:3.3.6 .

构建过程可能需要几分钟，主要时间花在下载 Hadoop 压缩包上。如果网络条件不理想，可以提前把压缩包下载到本地，用COPY指令代替wget，这样构建速度会快很多。

构建完成后，先启动一个临时容器验证基础环境是否正常：

docker run -it --rm hadoop-base:3.3.6 bash

进入容器后，依次执行java -version和hadoop version，确认 Java 和 Hadoop 都能正常输出版本信息。如果hadoop version报错说找不到命令，多半是 PATH 环境变量没生效，检查 Dockerfile 中的 ENV 指令是否正确。如果 Java 版本不对，检查 JAVA_HOME 是否指向了正确的路径。

还有一个容易忽略的验证点：SSH 免密登录。在容器内执行ssh localhost，如果不需要输入密码就能登录，说明密钥配置正确。这一步很关键，因为后续 Hadoop 启动脚本依赖 SSH，如果这里有问题，集群启动时会出现各种连接失败的错误。

注意：构建镜像时如果遇到 apt 源连接超时，可以更换为国内镜像源。在 Dockerfile 的 apt-get update 之前插入一行sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list即可。这个操作能显著提升构建速度，尤其是在网络条件不稳定的环境下。

3.3 配置文件拆分与挂载策略

Hadoop 的配置文件集中在$HADOOP_CONF_DIR目录下，核心文件包括core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml和workers。我的策略是在宿主机上创建一个配置目录，按节点角色分成master和slave两个子目录，分别存放主节点和从节点需要的配置文件。

主节点的core-site.xml配置如下：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://master:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/data/tmp</value> </property> </configuration>

fs.defaultFS指定 HDFS 的默认文件系统地址，这里用主机名master而不是 IP，因为我们在容器启动时会通过--add-host把主机名和 IP 的映射写进/etc/hosts。hadoop.tmp.dir指定临时文件目录，我习惯把它放在 Hadoop 安装目录下的 data 文件夹里，方便统一管理。

hdfs-site.xml的配置需要区分主节点和从节点。主节点上配置副本数为 2，因为只有两个 DataNode；指定 NameNode 和 SecondaryNameNode 的数据目录；关闭权限检查以便简化实验环境。

<configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/hadoop/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/hadoop/data/datanode</value> </property> <property> <name>dfs.namenode.secondary.http-address</name> <value>master:9868</value> </property> <property> <name>dfs.permissions.enabled</name> <value>false</value> </property> </configuration>

yarn-site.xml中需要指定 ResourceManager 的主机名和 NodeManager 的辅助服务。yarn.resourcemanager.hostname设为主节点的主机名，yarn.nodemanager.aux-services设为mapreduce_shuffle，这是 MapReduce 任务运行的必要配置。

mapred-site.xml中把 MapReduce 的运行框架指定为 YARN，即mapreduce.framework.name设为yarn。workers文件列出所有从节点的主机名，每行一个，Hadoop 的启动脚本会读取这个文件并逐个启动从节点上的服务。

配置文件准备完毕后，启动容器时用-v参数把对应的配置目录挂载到容器的$HADOOP_CONF_DIR。这样容器启动后直接使用挂载进来的配置，不需要进入容器手动修改文件。

4. 集群启动与核心环节实现

4.1 创建网络与启动主节点容器

网络创建命令前面已经提到，这里再强调一下子网选择的原则：避开常见的 172.17.0.0/16（Docker 默认 bridge 网络使用）和 192.168.0.0/16（家庭和办公网络常用）。我用的 172.20.0.0/16 是一个比较安全的选择，冲突概率很低。

docker network create --subnet=172.20.0.0/16 hadoop-net

启动主节点容器：

docker run -d \ --name master \ --hostname master \ --network hadoop-net \ --ip 172.20.0.10 \ --add-host=slave1:172.20.0.11 \ --add-host=slave2:172.20.0.12 \ -v /path/to/config/master:/opt/hadoop/etc/hadoop \ -p 9870:9870 \ -p 8088:8088 \ hadoop-base:3.3.6 \ tail -f /dev/null

这里用tail -f /dev/null作为容器的前台进程，保持容器持续运行。--add-host参数把两个从节点的主机名和 IP 映射写入容器的/etc/hosts，这样主节点就能通过主机名访问从节点。端口映射把 NameNode 和 ResourceManager 的 Web UI 暴露到宿主机，方便在浏览器中查看集群状态。

启动从节点容器的命令类似，只是 IP、主机名和挂载的配置目录不同：

docker run -d \ --name slave1 \ --hostname slave1 \ --network hadoop-net \ --ip 172.20.0.11 \ --add-host=master:172.20.0.10 \ --add-host=slave2:172.20.0.12 \ -v /path/to/config/slave:/opt/hadoop/etc/hadoop \ hadoop-base:3.3.6 \ tail -f /dev/null

两个从节点都按这个模式启动，只需要修改名称、主机名和 IP 即可。三个容器都启动后，用docker ps确认它们都在运行状态。

4.2 格式化 HDFS 与启动集群服务

容器启动后，第一件事是格式化 HDFS。这一步只需要在主节点上执行一次，而且必须在 NameNode 启动之前完成。格式化命令是：

docker exec -it master hdfs namenode -format

执行后会输出大量日志，看到Storage directory /opt/hadoop/data/namenode has been successfully formatted就说明格式化成功。如果重复格式化，会导致 NameNode 的 clusterID 和 DataNode 不一致，集群无法启动。如果不小心格式化了两次，需要把 NameNode 和所有 DataNode 的数据目录清空后重新格式化。

格式化完成后，在主节点上启动 HDFS：

docker exec -it master start-dfs.sh

这个脚本会通过 SSH 连接到workers文件中列出的所有从节点，逐个启动 DataNode。启动过程中会输出每个节点的启动日志，如果某个节点连接失败，日志中会有明确的错误提示。启动完成后，用jps命令检查各节点的 Java 进程：主节点上应该有 NameNode、SecondaryNameNode 和 JVM 进程，从节点上应该有 DataNode。

接着启动 YARN：

docker exec -it master start-yarn.sh

同样，这个脚本会启动 ResourceManager 和所有 NodeManager。启动完成后，主节点上应该有 ResourceManager 进程，从节点上应该有 NodeManager 进程。

提示：如果start-dfs.sh报错说ssh: connect to host slave1 port 22: Connection refused，说明从节点的 SSH 服务没有启动。在从节点容器内执行service ssh start即可。这个问题在容器重启后经常出现，因为容器内的 SSH 服务不会自动启动。可以在 Dockerfile 的 CMD 指令中加上启动 SSH 的命令，或者每次重启容器后手动启动。

4.3 验证集群状态与运行测试任务

集群启动后，先通过 Web UI 确认状态。在浏览器中访问宿主机的 9870 端口，应该能看到 NameNode 的概览页面，其中Live Nodes显示为 2，表示两个 DataNode 都已成功注册。访问 8088 端口，能看到 ResourceManager 的页面，Active Nodes显示为 2，表示两个 NodeManager 都在线。

命令行验证也很重要。在主节点上执行：

docker exec -it master hdfs dfsadmin -report

这个命令会输出 HDFS 的详细报告，包括总容量、已用容量、剩余容量以及每个 DataNode 的状态。如果看到两个 DataNode 都是In Service状态，说明 HDFS 集群正常。

接下来跑一个实际的 MapReduce 任务来验证 YARN 是否工作正常。Hadoop 自带了一些示例程序，其中 wordcount 是最经典的。先在 HDFS 上创建一个测试目录并上传一个文本文件：

docker exec -it master hdfs dfs -mkdir -p /test/input docker exec -it master bash -c "echo 'hello world hello hadoop' > /tmp/test.txt" docker exec -it master hdfs dfs -put /tmp/test.txt /test/input/

然后提交 wordcount 任务：

docker exec -it master hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/input /test/output

任务提交后，可以在 8088 端口的 Web UI 上看到任务的运行状态。任务完成后，查看输出结果：

docker exec -it master hdfs dfs -cat /test/output/part-r-00000

如果能看到每个单词的计数结果，说明整个集群从 HDFS 到 YARN 再到 MapReduce 的链路全部打通。

4.4 数据持久化与容器重启策略

容器化的一个固有问题是：容器删除后，内部的数据也会丢失。对于 Hadoop 集群来说，NameNode 的元数据和 DataNode 的数据块都需要持久化。我的做法是在宿主机上创建数据目录，启动容器时用-v参数挂载到容器内的数据目录。

主节点需要持久化 NameNode 的数据目录，从节点需要持久化 DataNode 的数据目录。挂载命令如下：

-v /path/to/data/master/namenode:/opt/hadoop/data/namenode -v /path/to/data/slave1/datanode:/opt/hadoop/data/datanode

这样即使容器被删除，数据仍然保留在宿主机上。重新启动容器时挂载同一个目录，集群状态就能恢复。需要注意的是，NameNode 的元数据和 DataNode 的数据块必须同时保留，如果只保留其中一个，集群启动时会因为 clusterID 不匹配而失败。

容器重启策略我建议设为--restart=unless-stopped，这样宿主机重启后容器会自动启动。但要注意，容器自动启动后 SSH 服务和 Hadoop 服务不会自动启动，需要手动执行启动命令。如果希望完全自动化，可以写一个启动脚本，在容器启动后自动执行 SSH 启动和 Hadoop 集群启动的命令。

5. 常见问题与排查技巧实录

5.1 集群启动失败的高频原因与解决方案

在实际操作中，集群启动失败的原因五花八门，但高频问题就那么几个。我整理了一张速查表，遇到问题时可以按表排查。

这张表里的每一个问题我都实际遇到过，其中最常见的是 SSH 服务未启动和 clusterID 不一致。SSH 问题在容器重启后几乎必然出现，因为容器内的服务不会自动启动。clusterID 问题则多发生在反复格式化的场景中，新手很容易在这里踩坑。

5.2 内存与资源分配的调优经验

Hadoop 集群对内存的要求不低，尤其是在容器环境中，资源限制更加明显。默认情况下，YARN 的 NodeManager 会尝试使用宿主机的全部内存，这在容器中会导致容器被 OOM Killer 杀掉。必须手动限制 NodeManager 可用的内存。

在yarn-site.xml中设置：

<property> <name>yarn.nodemanager.resource.memory-mb</name> <value>2048</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>2048</value> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>512</value> </property>

yarn.nodemanager.resource.memory-mb限制单个 NodeManager 可用的总内存，我设为 2048MB，因为每个从节点容器我分配了 2GB 内存。yarn.scheduler.maximum-allocation-mb限制单个任务能申请的最大内存，设为和 NodeManager 总内存一致。yarn.scheduler.minimum-allocation-mb是单个任务的最小内存单位，设为 512MB。

启动容器时也要用--memory参数限制容器可用的内存，比如--memory=2g。这样即使容器内的进程试图申请更多内存，也会被 Docker 的 cgroup 限制住，不会影响宿主机和其他容器。

注意：NameNode 和 ResourceManager 对内存的需求比 DataNode 和 NodeManager 更高。主节点容器建议分配 3GB 以上内存，从节点容器各分配 2GB。如果宿主机总内存只有 8GB，三个容器加起来就是 7GB，留给宿主机的内存就不多了。这种情况下可以适当降低从节点的内存分配，但不要低于 1.5GB，否则 NodeManager 可能无法正常启动。

5.3 容器网络与端口冲突的处理技巧

Docker 的端口映射有一个限制：宿主机的同一个端口只能映射到一个容器。如果主节点容器已经映射了 9870 端口，其他容器就不能再映射这个端口。对于 Hadoop 集群来说，只有主节点的 Web UI 需要从宿主机访问，从节点的 Web UI 可以在容器内部访问，不需要映射到宿主机。

如果确实需要从宿主机访问从节点的 Web UI，可以通过主节点容器做端口转发，或者使用docker exec进入容器后用curl访问。另一种方式是把从节点的 Web UI 端口映射到宿主机的不同端口，比如 slave1 的 9864 映射到宿主机的 19864，slave2 的 9864 映射到 29864。

网络排查的常用命令包括docker network inspect hadoop-net查看网络详情，docker exec master ping slave1测试容器间连通性，docker exec master cat /etc/hosts检查主机名解析。这些命令在排查网络问题时非常有用，建议在集群启动后先跑一遍，确认基础网络没有问题。

还有一个隐藏的坑：Docker 的 iptables 规则可能会和宿主机的防火墙规则冲突，导致容器间通信被阻断。如果ping能通但端口连接被拒绝，多半是 iptables 的问题。可以临时关闭防火墙测试，确认问题后再添加相应的放行规则。

5.4 集群日常维护与快速重建方案

实验环境中，集群经常需要推倒重建。如果每次重建都从头开始，效率太低。我的做法是把整个部署过程脚本化，用一个 shell 脚本完成网络创建、容器启动、HDFS 格式化和服务启动的全部操作。

脚本的核心逻辑是：先检查并清理旧容器和网络，然后按顺序启动主节点和从节点，等待几秒让 SSH 服务就绪，接着格式化 HDFS 并启动集群服务，最后输出集群状态。整个脚本不到 50 行，但能把重建时间从手动操作的十几分钟压缩到一分钟以内。

日常维护中，查看日志是最常用的操作。Hadoop 的日志分布在$HADOOP_HOME/logs目录下，每个角色有独立的日志文件。NameNode 的日志在hadoop-<用户名>-namenode-<主机名>.log，DataNode 的日志在hadoop-<用户名>-datanode-<主机名>.log。用docker exec进入容器后，可以用tail -f实时查看日志输出，这对排查运行时问题非常有帮助。

如果需要临时停止集群，用stop-dfs.sh和stop-yarn.sh即可。但要注意，停止顺序应该是先停 YARN 再停 HDFS，因为 YARN 上的任务可能正在读写 HDFS，先停 HDFS 会导致任务失败。启动顺序则相反，先启动 HDFS 再启动 YARN，确保 YARN 启动时 HDFS 已经可用。

6. 个人实操体会与进阶扩展方向

这套 Docker 部署 Hadoop 集群的方案，我在不同配置的机器上反复验证过多次。最深的体会是：容器化确实降低了集群部署的门槛，但也引入了新的复杂度。网络配置、数据持久化、资源限制这些问题在物理机或虚拟机上可能不是问题，在容器里却需要特别关注。不过一旦把这些问题解决清楚，后续的重复部署就变得非常轻松。

有一个细节值得单独提一下：容器内的 SSH 服务。很多 Hadoop 容器化方案会在 Dockerfile 里用ENTRYPOINT或CMD自动启动 SSH，但这样做会导致容器的主进程变成 SSH 守护进程，docker stop时信号传递可能有问题。我选择的做法是让容器主进程保持为tail -f /dev/null，SSH 和 Hadoop 服务都通过docker exec手动启动。这样容器的生命周期管理更清晰，停止容器时也不会有残留进程。

如果后续想进一步扩展，有几个方向可以考虑。一是引入 Docker Compose 来管理多容器编排，把网络定义、容器配置、依赖关系都写进docker-compose.yml，一条命令就能拉起整个集群。二是把 Hadoop 集群迁移到 Kubernetes 上，利用 K8s 的调度和自愈能力，不过这需要把 Hadoop 的配置改造成适合 K8s 的形式，工作量不小。三是尝试用 Docker 部署其他大数据组件，比如 Spark、Hive、HBase，和 Hadoop 集群组成更完整的数据平台。

最后分享一个实用小技巧：在宿主机上给每个容器配置一个别名，比如alias master='docker exec -it master bash'，这样输入master就能直接进入主节点容器的 shell，省去了每次敲完整命令的麻烦。对于需要频繁在多个容器间切换的场景，这个小技巧能节省不少时间。