企业官网建设流程全解析

简介：面向高校大数据课程实验与华为云平台入门实践，这份实验报告围绕云上大数据环境的搭建、管理与查询展开，适合需要完成课程实验、熟悉云端集群部署的读者参考。压缩包内为1个docx文档，约4.36MB，按实验模块组织，便于连续阅读和对照操作。内容覆盖四条主线：借助ECS与OBS搭建Hadoop集群，完成OpenJDK安装、防火墙关闭、节点SSH互信及与对象存储的连通验证；利用云服务组合实现数据收集、存储、分析与可视化；通过BigData Pro配置ECS、OBS并搭建Hadoop与Spark集群；使用Spark SQL或Flink SQL开展大规模数据交互式查询。报告保留了环境准备、节点配置、集群测试与结果查看等环节，可帮助读者理解云端大数据平台的部署流程、资源组织方式和常见配置要点。目前已有2607人学习，适合作为实验复盘与操作参照。

1. 用云主机凑四个节点，比在机房抢机器实在

带大数据实验最常遇到的难题不是算法，而是硬件。四个节点的 Hadoop 集群，宿舍里那台 16G 内存的笔记本最多开三台虚拟机，第三台一起来风扇就开始长时间高负载，而实验报告里要写的恰恰是 node1 到 node4 的完整互信和集群状态。这份云平台大数据实验报告给出的思路很直接：把节点搬到云上，用弹性云服务器按小时开四台，用完就释放，把对象存储当共享数据盘，再在上面依次完成 Hadoop 集群搭建、Spark 集群搭建和交互式查询。它适合三类人：要交大数据课程设计的学生、需要一套可复现实验流程的助教，以及想快速验证集群配置是否正确的开发者。整套流程的核心不是某个高深算法，而是「四台机器 + 一个桶 + 一份配置」能不能稳定跑通。

2. 实验环境规划：四台 ECS 与一个对象存储桶的角色划分

动手买机器之前，先把角色定下来。这套实验最容易出问题的地方不在装软件，而在地址和路径没有提前统一：node2 记成了公网 IP，node3 的 hosts 少写一行，结果 SSH 免密测试时好时坏，排查半天才发现是映射不一致。所以规划阶段要定死三件事：节点叫什么、桶怎么建、软件装在哪。

2.1 节点角色与内网地址的固定方式

四个节点里，node1 兼做主节点和 NameNode，node2 做 SecondaryNameNode 与 ResourceManager 的备份角色，node3、node4 做 DataNode 与 NodeManager。规格上不必追求高配，2 核 4G 起步、系统盘 40G 就够跑通全流程，真正吃资源的是后面 Spark 提交任务那一步，如果预算允许，把 node1 提到 4 核 8G 会舒服很多。

地址是重点。云上每台机器都有公网 IP 和内网 IP 两套地址，集群内部通信必须用内网地址，公网地址只用来从本地 SSH 登录。买机器时把它们抄在一张表里，后面所有配置都从这张表取：

买完之后第一件事是给每台机器改主机名，而不是急着装 JDK。云主机的默认主机名通常是一串自动生成的编号，四个节点看起来几乎一样，登录错机器是高频事故。用hostnamectl set-hostname node1逐台改掉，重新登录生效，之后所有的命令行提示符本身就是一种校验。

提示：ECS 的安全组要放开实验用到的端口段。集群内部走内网，通常不受安全组限制，但从本地用浏览器看 8088、9870 这类管理页面时，安全组没放行会一直转圈，很容易被误判成服务没起来。

2.2 对象存储桶与访问密钥的准备颗粒度

对象存储在这套实验里承担两个职责：一是当作集群的外部数据源，验证 Hadoop 和 Spark 能不能直接读写云端存储；二是当共享盘，把输入数据放一份，四个节点都能访问，不必在每台机器上重复 scp。

建桶的时候有几个细节值得提前定。桶名全局唯一，用「项目缩写 + 学号尾号 + 用途」这种组合最省事，比如bd-lab-0713-input。区域要和 ECS 选在同一个区域，跨区域访问会额外产生流量开销，速度也慢。如果实验要求里出现了「并行文件系统」这个说法，说明要建的是面向大数据场景优化的桶类型，它的读写语义更接近文件系统，对 Hadoop 兼容性更好，创建入口和普通桶不在同一个位置，别找错。

访问密钥就是 AK/SK 那一对，创建后会生成一个 csv 文件，里面是用户名、Access Key Id 和 Secret Access Key 三列。这个文件只在下发时能看到一次，关掉页面就再也拿不到明文 SK。我一般要求学生把 csv 改名成「节点名-日期」的格式存好，同时把 AK/SK 写进集群配置文件，而不是每次临时查。

这里有个必须说清的安全边界：AK/SK 等同于账号密码，任何人都不能把它们贴进实验报告正文、截图或代码仓库。报告里展示配置时，一律用占位符替代：

# 写入环境变量，实际值从 credentials.csv 读取，不要硬编码在脚本里 export OBS_AK="<your-access-key-id>" export OBS_SK="<your-secret-access-key>" export OBS_ENDPOINT="obs.<region-id>.example-cloud.com"

占位符不是偷懒，是为了让报告可以公开传阅。评审看到的是配置结构对不对，而不是你的密钥是多少。

2.3 组件版本与安装路径的统一约定

四个节点装同样的东西，路径必须一字不差，否则后面写配置文件时每一行都要检查节点。约定两条：所有组件解压到/opt/module/下，环境变量统一写进/etc/profile.d/bigdata.sh。

/opt/module/ ├── jdk1.8.0_xxx ├── hadoop-3.x.x └── spark-3.x.x

路径里带版本号是为了将来换版本时能并行装，但环境变量里的JAVA_HOME、HADOOP_HOME不要写死带版本号的完整路径，改成软链接/opt/module/jdk指向实际目录，升级时只改软链接，四个节点的配置文件一行都不用动。这个习惯在云上尤其值钱，因为重装节点是常事。

JDK 用系统源里的 OpenJDK 就行，yum install -y java-1.8.0-openjdk-devel，装完用readlink -f $(which java)找到真实路径，再往环境变量里写。Hadoop 和 Spark 的安装包提前在一台机器上下好，用scp分发到其余三台，比每台机器各自下载快得多，也避免某台机器网络抖动导致版本不一致。

# 在 node1 上统一分发，保证四台机器的组件完全一致 for host in node2 node3 node4; do scp /opt/module/hadoop-3.x.x.tar.gz root@$host:/opt/module/ done

分发完别急着解压，先用md5sum对一遍四个包，云主机偶尔会出现传输截断，解压时报「不可预料的文件末尾」基本就是这个原因。

3. Hadoop 集群落地：从 hosts 映射到 wordcount 跑通

环境铺好之后，Hadoop 的搭建其实是一串确定性动作：改主机名、写 hosts、关防火墙、做互信、改四个 XML、格式化、启动、跑例子。每一步单独看都不难，难在顺序不能乱——先格式化再改配置，NameNode 的元数据就和配置对不上了，只能删掉数据目录重来。

3.1 主机名、hosts 与防火墙的前置处理

hosts 文件是这套集群的基础。四台机器都要写入同样的四行映射，用内网地址，不用公网：

# 四个节点分别执行，内容完全一致 cat >> /etc/hosts <<'EOF' 192.168.0.10 node1 192.168.0.53 node2 192.168.0.169 node3 192.168.0.77 node4 EOF

写完用ping node2验证一下，能通说明映射生效。如果 ping 不通，先看安全组里的内网互通规则，再看两台机器是不是真的在同一个子网里，跨子网的内网地址是 ping 不通的。

防火墙在实验环境里建议直接关掉，而不是逐条加规则。原因是 Hadoop 和 Spark 之间互相通信的端口太多，NameNode 的 8020、9870，ResourceManager 的 8032、8088，DataNode 的数据传输端口还是随机的，一条条放行既费时又容易漏。关掉之后记得设为开机不启动，否则重启机器后又要排查一遍。

# 关闭并禁用防火墙，实验环境专用，生产环境请改为精确放行端口 systemctl stop firewalld systemctl disable firewalld systemctl status firewalld # 状态应为 inactive (dead)

3.2 四节点 SSH 互信的分发流程

Hadoop 启动时，主节点要通过 SSH 去拉起其他节点上的守护进程，所以 node1 必须能免密登录 node2、node3、node4，反过来其他节点也要能免密登录 node1，实现结果就是四台机器两两之间都能不带密码跳转。

标准做法是每台机器各自生成一对密钥，然后把公钥汇总。先生成：

# 四个节点都执行，一路回车，不设密码短语 ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa

-P ''表示空密码短语，这是关键。如果设了密码短语，免密登录时会卡在输入密码这一步，脚本化的启动流程就会失败。生成之后每台机器把自己的公钥cat ~/.ssh/id_rsa.pub打出来，汇总到一个文本文件里，四段公钥拼在一起，再分发到每台机器的~/.ssh/authorized_keys。

# 在 node1 上把四台机器的公钥合并后分发 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys # 把 node2~node4 的公钥追加进来（此处省略具体公钥内容） cat node2.pub node3.pub node4.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys # 分发到其余节点 for host in node2 node3 node4; do scp ~/.ssh/authorized_keys root@$host:~/.ssh/ done

分发完成后逐台验证，ssh node2能直接进去、exit能退出，四个节点两两组合都要试。这一步偷懒，后面start-all.sh会出现「node3 上的 DataNode 没起来」这种一半成功一半失败的状态，很容易被误判成配置写错。

注意：authorized_keys的权限必须是 600，家目录不能是 777。权限过宽时 SSH 会静默忽略这个文件，表现就是「密钥明明放进去了，还是让我输密码」。

3.3 四个 XML 配置文件的关键项

Hadoop 的配置集中在$HADOOP_HOME/etc/hadoop/下，四个文件各管一摊。这一节把真正影响集群能不能跑起来的项列出来，其余保持默认。

core-site.xml决定文件系统的入口地址，同时是接入对象存储的地方：

<configuration> <!-- HDFS 的访问入口，必须和 node1 的地址一致 --> <property> <name>fs.defaultFS</name> <value>hdfs://node1:8020</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/hadoop-3.x.x/data/tmp</value> </property> <!-- 对象存储作为额外文件系统接入，前缀 obs:// --> <property> <name>fs.obs.impl</name> <value>org.apache.hadoop.fs.obs.OBSFileSystem</value> </property> <property> <name>fs.obs.access.key</name> <value>${OBS_AK}</value> </property> <property> <name>fs.obs.secret.key</name> <value>${OBS_SK}</value> </property> <property> <name>fs.obs.endpoint</name> <value>${OBS_ENDPOINT}</value> </property> </configuration>

hadoop.tmp.dir这一项很多人不写，默认值落在/tmp下，云主机重启后/tmp可能被清理，NameNode 的元数据跟着没了，集群起来就报「目录不存在」。写成/opt/module/下的固定路径，重启不掉数据。

hdfs-site.xml管副本和目录：

<configuration> <!-- 四节点实验环境设 2 就够，设 3 会占满系统盘 --> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/module/hadoop-3.x.x/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/module/hadoop-3.x.x/data/datanode</value> </property> <!-- 关闭权限检查，避免 root 启动后其他用户访问被拒 --> <property> <name>dfs.permissions.enabled</name> <value>false</value> </property> </configuration>

副本数设 2 是实验环境的现实选择。四台机器的系统盘普遍是 40G，副本 3 加上中间数据，跑两轮 wordcount 就剩不下多少空间，之后上传输入文件直接失败。

mapred-site.xml指定计算框架走 YARN，yarn-site.xml配置资源管理和节点管理器地址：

<!-- mapred-site.xml --> <configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>yarn.app.mapreduce.am.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value> </property> <property> <name>mapreduce.map.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value> </property> <property> <name>mapreduce.reduce.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value> </property> </configuration>

那两个${HADOOP_HOME}展开的变量是最常见的失败原因。不写的话容器启动时找不到 Hadoop 的类路径，任务日志里会出现Could not find or load main class，而start-all.sh一切正常，很容易让人困惑。

<!-- yarn-site.xml --> <configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>node1</value> </property> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <!-- 关闭虚拟内存检查，云主机 swap 小，不关容易报容器超内存 --> <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> </configuration>

四个文件改完之后，把整个hadoop目录同步到其余三台，避免手工改漏：

for host in node2 node3 node4; do rsync -av /opt/module/hadoop-3.x.x/ root@$host:/opt/module/hadoop-3.x.x/ done

3.4 格式化、启动与 wordcount 结果判读

配置同步完，第一次启动前必须格式化 NameNode，且只格式化一次：

# 只在 node1 执行，且仅限首次 hdfs namenode -format

格式化日志里出现Storage directory ... has been successfully formatted才算成功。如果之前格式化过又改了集群 ID，会提示目录非空，这时候要把dfs.namenode.name.dir和dfs.datanode.data.dir指向的目录删掉再格式化，不要硬着头皮继续。

启动分两步，先 HDFS 再 YARN：

start-dfs.sh # 在 node1 执行，会通过 SSH 拉起各节点 DataNode start-yarn.sh jps # 逐台检查进程

jps是最直观的健康检查。node1 上应该看到 NameNode、ResourceManager，node2 上看到 SecondaryNameNode，node3 和 node4 上看到 DataNode 和 NodeManager。少哪个进程，就去对应机器的logs目录看那个组件的日志，最后几行通常直接写着原因。

最后用官方自带的例子验证整条链路：

# 造输入数据并上传到 HDFS hdfs dfs -mkdir -p /input echo "hello hadoop hello spark hello obs" > /opt/word.txt hdfs dfs -put /opt/word.txt /input/ # 提交 wordcount 作业 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.x.x.jar \ wordcount /input /output # 查看结果 hdfs dfs -cat /output/part-r-00000

输出里出现hello 3、hadoop 1这样的统计，说明 HDFS 存储、YARN 调度、MapReduce 计算三条链路全通了。这一步跑通的意义不只是「有个结果」，它是后面 Spark 和交互式查询的地基——如果 wordcount 都要重试三次，先别往 Spark 走。

4. Spark 与对象存储互联：从 obs:// 读数据到交互式 SQL 出结果

Hadoop 跑通只证明了集群自身能转，实验报告里真正拉开差距的是后面两块：Spark 能不能和 Hadoop 共存并直接读云端对象存储，以及能不能用 SQL 的方式对数据做交互式查询。这两块恰好也是云上大数据和纯本地集群的区别所在。

4.1 Spark 集群模式与环境变量配置

Spark 装在哪台机器上是个选择题。三种模式里，Local 模式只在一台机器上跑，体现不出集群；Standalone 模式自带资源调度，和 YARN 并存会争抢内存；On YARN 模式复用已有的 Hadoop 资源管理，最省资源，也最贴近真实使用方式。这套实验选 On YARN，装完不用额外起 Master 和 Worker 进程。

解压到/opt/module/spark-3.x.x后，先配spark-env.sh：

# 复制模板 cp $SPARK_HOME/conf/spark-env.sh.template $SPARK_HOME/conf/spark-env.sh # 在 spark-env.sh 中追加 export JAVA_HOME=/opt/module/jdk export HADOOP_CONF_DIR=/opt/module/hadoop-3.x.x/etc/hadoop export YARN_CONF_DIR=/opt/module/hadoop-3.x.x/etc/hadoop export SPARK_HISTORY_OPTS="-Dspark.history.ui.port=18080 -Dspark.history.fs.logDirectory=hdfs://node1:8020/spark-logs"

HADOOP_CONF_DIR是关键项。不配这一行，Spark 就不知道 NameNode 地址和 YARN 的 ResourceManager 在哪，提交任务时报Cannot initialize Cluster，错误信息含糊，排查费时。指向 Hadoop 的配置目录后，Spark 直接复用里面的core-site.xml和yarn-site.xml，包括对象存储的 AK/SK 配置也一并继承，不用在 Spark 侧重复写一遍。

历史服务器建议开。不开启时，任务跑完 Web UI 就没了，答辩现场想回看某次作业的 DAG 图只能重跑。日志目录指向 HDFS，四个节点都能访问，比落在本地磁盘可靠。

# 启动历史服务器 $SPARK_HOME/sbin/start-history-server.sh

4.2 OBS 接入的 jar 包与 fs.obs.* 参数

Hadoop 原生不认识obs://这个协议，需要额外的连接器 jar 包。这个包一般由云厂商提供，放进$HADOOP_HOME/share/hadoop/common/lib/和$SPARK_HOME/jars/两个位置，然后在core-site.xml里声明fs.obs.impl指向它的实现类。上一章的配置已经写了这一项，这里补充它真正生效时的验证方法。

验证不必启动整个集群，单机跑一条命令就能试：

# 列出桶内对象，能列出文件名说明 AK/SK 和 endpoint 都对 hadoop fs -ls obs://bd-lab-0713-input/

这一步失败的情况有三种，症状不一样：

# 写测试：往桶里写一个文件，再读回来比对 echo "obs connectivity test" > /tmp/t.txt hadoop fs -put /tmp/t.txt obs://bd-lab-0713-input/test/ hadoop fs -cat obs://bd-lab-0713-input/test/t.txt

写进去再读出来，内容一致，才叫真正打通。只做-ls是不够的——列举操作走的是元数据接口，读写才走数据通道，权限配一半的情况很常见。

4.3 外表映射与交互式查询的组织方式

数据在桶里，查询在 Spark 里，中间靠外部表把两者接起来。这里推荐直接用spark-sql交互式客户端，一条条敲 SQL，结果立刻返回，比写完整的 Scala 程序更适合实验和演示。

先把一份结构化数据传到桶里，比如一个简单的访问日志 CSV：

hadoop fs -put /opt/access.log obs://bd-lab-0713-input/logs/

然后进入交互式客户端建外表：

-- 建外部表，指向对象存储上的数据，删表不删数据 CREATE EXTERNAL TABLE access_log ( ip STRING, url STRING, status INT, bytes BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 'obs://bd-lab-0713-input/logs/'; -- 统计状态码分布，验证数据读进来了 SELECT status, COUNT(*) AS cnt FROM access_log GROUP BY status ORDER BY cnt DESC; -- 找出访问量最大的前十个 URL SELECT url, COUNT(*) AS hits FROM access_log GROUP BY url ORDER BY hits DESC LIMIT 10;

用外部表而不是内部表，是因为数据实际存放在桶里，内部表删表时会连带删数据，实验过程中误删一次就得重传。LOCATION指向桶里的目录而不是具体文件，Spark 会读取该目录下所有文件，这一点和 HDFS 上的分区表行为一致。

查询跑起来之后，可以在 Spark 的 Web UI 里看到每个 SQL 被拆成几个 Stage、每个 Stage 的 shuffle 数据量。答辩时这一页截图比结果表本身更有说服力——它证明你知道任务是怎么执行的，而不只是抄了一条 SQL。

提示：spark-sql里第一次查询会慢一些，因为要初始化会话和加载元数据。别急着按 Ctrl+C，看到Stage进度条开始动就说明在跑。

如果想换成脚本化的方式批量执行，把 SQL 写进文件再提交：

# 批量执行，适合把多条查询固化下来复现 $SPARK_HOME/bin/spark-sql -f /opt/queries.sql

这套组合的价值在于：数据放云端不占本地磁盘，计算跑在集群上不受单机内存限制，查询用 SQL 表达不需要写代码。三件事凑齐，「大数据交互式查询」这个实验目标才算真正落地。

5. 常见问题排查：这套四节点集群最容易翻车的五个地方

实验报告里最有含金量的部分往往是故障记录。下面这五条是这套流程里出现频率最高的问题，按照「现象 → 原因 → 解决」整理，可以直接对照排查。

第一处：start-dfs.sh之后jps少 DataNode。现象是 node1 上 NameNode 起来了，node3、node4 却没有 DataNode 进程，日志里反复出现Connection refused。原因是集群曾多次格式化，每个 DataNode 的VERSION文件里记录的clusterID和当前 NameNode 的不一致，DataNode 主动拒绝加入。解决办法是停掉集群，删掉每台 DataNode 上dfs.datanode.data.dir指向的目录，重新格式化 NameNode 后再启动。血泪经验是：格式化只做一次，改配置前先想清楚。

第二处：wordcount 卡在ACCEPTED不动。现象是作业提交成功，状态一直停在 ACCEPTED，Web UI 上 ResourceManager 显示可用内存为 0。原因是 YARN 的yarn.nodemanager.resource.memory-mb默认值按物理内存推算，四台 4G 的机器上再扣掉系统占用，能分配给容器的额度很小，而 MapReduce 默认的容器内存申请就超过了这个额度。解决办法有两个方向：调大节点的可分配内存，或者调小任务的内存申请。实验环境下我一般两个都做，把mapreduce.map.memory.mb设成 512、mapreduce.reduce.memory.mb设成 1024，同时确认yarn.nodemanager.resource.memory-mb不小于 2048。

第三处：hadoop fs -ls obs://报找不到文件系统。现象是 HDFS 上的操作全部正常，一碰obs://就提示No FileSystem for scheme。原因是连接器 jar 只放进了 Spark 的 jars 目录，没有放进 Hadoop 的 lib 目录，或者放进去了但没重启。hadoop fs命令走的是 Hadoop 自己的类加载路径，和 Spark 互不相干。解决是两边都放同一份 jar，放完重启 HDFS 和 YARN，再用hadoop classpath | grep obs确认 jar 已在类路径里。

第四处：Spark 提交任务报Cannot initialize Cluster。现象是spark-submit一启动就退出，日志里全是这个错误。原因是spark-env.sh里的HADOOP_CONF_DIR没配或路径写错，Spark 找不到core-site.xml。另一种情况是配了但四台机器的路径不一致，node1 上对，node3 上错。解决是把spark-env.sh和 Hadoop 的配置目录同步到所有节点，grep HADOOP_CONF_DIR逐台确认。

第五处：ssh node2仍然要输密码。现象是密钥明明分发过，登录时还是提示输入密码。原因多半是权限：~/.ssh目录是 777 或者authorized_keys是 644，SSH 出于安全考虑会直接忽略。也可能是家目录权限过宽。解决办法是统一收敛权限，.ssh设 700，authorized_keys设 600，用ls -ld逐台核对。这属于典型的玄学问题，配置看起来完全正确，实际只是文件权限不对。

把这五条整理进报告的「问题与解决」章节，比多贴十张成功截图更能体现动手能力。遇到问题时，先看日志最后二十行，再看进程在不在，最后才怀疑配置文件——顺序反了会浪费大量时间。

6. 验收与答辩：四份实验记录怎么组织才经得起追问

四个实验最终会汇成一份报告，评审看的不是排版，而是每一步有没有留下可验证的证据。我的做法是把每个实验固定拆成四块：环境快照、操作命令、结果截图、异常记录。环境快照是jps输出和hosts文件，证明集群真的起来了；操作命令是从登录到出结果的关键几条，不用全贴，但要能串成链路；结果截图只截有信息量的部分，比如 wordcount 的输出内容、SQL 的查询结果、Spark UI 的 Stage 划分；异常记录就是上一章那种三段式，出过什么问题、怎么定位的、怎么解决的。

答辩时最常被追问的三个点，提前把答案准备好：

还有一个容易被忽略的细节：报告里的密钥、公网 IP、桶名要脱敏。我见过把完整 AK/SK 贴进报告的，等于把账号交出去了。统一替换成占位符，评审不会因此扣分，反而说明有基本的安全意识。

最后说一个实操建议。这套实验在云上按小时计费，做完记得把机器停机或释放，桶里的数据如果不需要也一并清掉。有人实验做完忘了关机，月底账单一出来才发现四台机器开了半个月。

从那以后我每次带这套流程，都强制先跑一遍最小闭环：单机 wordcount → 四节点集群 →obs://读写 → 一条 SQL 查询，四步全绿了再往报告里填内容。顺序反过来，前面配置错一处，后面所有截图都要重来。希望帮到你。

本文还有配套的精品资源，点击获取