简介《华为云大数据实验报告》面向大数据课程学习者及华为云实践入门者围绕云上大数据平台的部署、管理与查询展开可用于课程实验、课后复现和技能梳理。压缩包内共1个docx文档约4.36MB以图文实验报告形式组织便于按模块查阅与对照操作。内容覆盖四个实验利用ECS与OBS搭建Hadoop集群的云主机实验、借助云服务完成数据收集存储与分析、BigData Pro一站式方案中的环境准备及Hadoop/Spark集群搭建以及基于Spark SQL或Flink SQL的交互式查询。报告涉及节点通信、OBS互联测试、集群配置和查询任务等关键环节可帮助读者理解华为云基础设施与服务组件的配合方式掌握云环境中的集群搭建、资源管理与数据分析流程。目前已有2607人学习适合作为大数据实验课程参考与上机实践辅助材料。1. 从先买四台机器开始这套云上大数据实验要解决什么很多人第一次做云上大数据实验习惯先在控制台点开一台云主机装完 Hadoop再想办法把另外几台机器接进来结果卡在节点互相不认识、DataNode 起不来、任务只在一台机器上跑。这套方案反过来推进先用弹性云服务器 ECS 申请四台同子网实例用对象存储 OBS 做数据的落地和归档再按网络互通、免密互信、分布式存储、分布式计算、交互式查询的顺序一层层往上搭。它面向的是要交一份大数据课程设计或综合实验报告的人也适合需要在一周内把 Hadoop、Spark 集群从零跑通的从业者。整套链路对应四个实验环节云主机实现大数据、云服务实现大数据、托管集群套餐、大数据交互式查询下面按能复现的顺序拆开讲。2. 环境底座设计四台 ECS、一个 OBS 桶和一套访问密钥怎么规划集群跑不起来八成不是代码问题而是底座没规划好。四台机器的规格、子网、桶的选型、密钥的存放方式这些在控制台上点几下就过去的步骤恰恰决定了后面能不能一次性把 WordCount 跑通。这一章把底座拆成三块节点角色、存储与密钥、网络放通。2.1 节点角色划分与规格选型四节点是这套实验的标准配置node1 兼作主节点同时承担 NameNode、ResourceManager 和 Spark Master 三个角色node2 到 node4 是从节点承担 DataNode、NodeManager 和 Spark Worker。把它写成表更清楚节点规格主要角色常驻进程node14 vCPU / 8 GB / 40 GB主节点NameNode、SecondaryNameNode、ResourceManager、Spark Masternode24 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Workernode34 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Workernode44 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Worker为什么不干脆开三台省点资源因为 HDFS 默认三副本三台机器里任何一台挂掉某个块的三份副本有可能同时不可用恢复过程会很被动四台机器给了副本放置策略一个周转余地也正好对应实验报告里node1 到 node4的叙述。规格上 4 vCPU / 8 GB 是下限低于这个数YARN 给单个容器分配的可用内存会小到让 MapReduce 任务反复重试看着像卡死其实是资源不够。创建实例时有三个选项必须统一否则后面全是坑同一个 VPC、同一个子网、同一个安全组。同一子网保证了内网地址可以直连不用做任何路由配置同一安全组保证了节点之间默认互访省去逐条加规则的麻烦。可用区AZ也尽量选同一个跨可用区的内网时延虽然也能跑但数据块传输会慢一个量级实验体感很差。操作系统选公共镜像里的主流 Linux 发行版即可重点确认镜像里是否自带 OpenJDK 8。Hadoop 3.x 对 JDK 8 兼容性最好JDK 11 在某些版本上会遇到模块访问权限的报错。如果镜像不带就在后面统一用包管理器装java-1.8.0-openjdk-devel注意是 devel 版本只有运行时没有开发包的话编译相关组件会缺头文件。计费方式按需即可实验周期通常在一到两周做完把实例和桶一起释放。这里有个血泪经验释放实例前一定先把写好的配置文件和实验结果打包存到本地云主机的系统盘跟着实例一起销毁格式化过的数据目录不会给你留后悔药。2.2 对象存储桶与访问密钥的最小化管理对象存储这块第一件事是选桶类型。普通对象桶适合存日志和备份但大数据场景要的是并行文件系统类型的桶它提供类 POSIX 的语义多客户端并发读写时吞吐更高Hadoop 的 s3a 客户端打上去也不会出现大量小文件写入超时。桶名在服务范围内全局唯一建议用项目名 随机后缀的形式避免和别人撞名。创建完桶拿到端点地址格式大致是https://obs.region.example-cloud.comregion要换成自己实际所在的区域。端点写错是最常见的 403 来源之一因为请求会被路由到错误区域的入口签名校验对不上。访问密钥的生成入口在控制台的我的凭证里下载下来是一个credentials.csv文件里面三列User Name、Access Key Id、Secret Access Key。这个文件只提供一次下载关掉页面就再也拿不到 Secret Key只能重新生成一对。所以第一件事是把它存到本地密码管理器或者加密压缩包里不要截图发群更不要直接贴进要提交的实验报告。密钥的使用方式决定了这份作业安不安全。直接写进 Java 代码或者提交到代码仓库是最差的做法稍微好一点是写进配置文件更稳妥的是走环境变量让配置文件去引用变量名。在每台节点上建一个统一的环境变量文件# /etc/profile.d/bigdata.sh # 所有节点保持一致权限设为 600只允许 root 读取 export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME/opt/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_HOME/opt/spark export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin # 对象存储接入信息用变量占位避免硬编码进 XML export OBS_ENDPOINThttps://obs.region.example-cloud.com export OBS_BUCKETbigdata-lab-xxxx export OBS_AK你的 Access Key Id export OBS_SK你的 Secret Access Key执行source /etc/profile.d/bigdata.sh之后Hadoop 的配置文件里就可以写${env.OBS_AK}这样的占位符Hadoop 在解析配置时会自动做环境变量替换。这样一来core-site.xml里看不到明文密钥配置文件可以放心分发到四个节点也不怕误传到公开仓库。注意这个文件要chmod 600并且不要给非 root 用户读权限。权限最小化还有一层如果控制台支持给密钥绑定策略就只授予这一个桶的读写权限不要图省事给管理员权限。实验环境里无所谓但养成习惯之后换到真实项目上能少一次事故。2.3 安全组与端口放通别用全放通糊过去同一安全组内的实例默认可以互访全部端口这一点省了很多事。但公网入口必须收窄只放通 22 端口的 SSH而且源地址限制成本机公网 IP。其余端口一个都不要对公网开放包括 9870 和 8088 这两个 Web 页面它们没有强认证暴露出去等于把集群状态和任务日志公开。集群内部需要放通的端口列一下方便在自建安全组或者排查连通性时对照端口所属服务用途22SSH节点间跳转与配置分发8020NameNode RPC客户端读写 HDFS9870NameNode Web集群状态查看9864 / 9866DataNode数据块传输与状态上报8032ResourceManager应用提交与资源申请8088YARN Web任务进度查看7077Spark MasterSpark 任务提交8080Spark Master WebSpark 集群状态18080History Server历史任务回溯排查连通性别用ping很多云环境默认禁 ICMPping不通不代表网络有问题。用telnet node1 8020或者nc -zv node1 8020才是有效验证。这一步在做跨节点测试时很关键能提前把到底是网络不通还是服务没起这个二选一判断清楚后面排错会省掉大量时间。3. 集群通信前置hosts 映射、四节点免密互信与连通自检分布式集群的第一道门槛不是 Hadoop是让四台机器互相认得出、进得去。这一步做完后面所有批量分发配置、批量启动进程才有基础这一步没做扎实后面每次启动都要手输四次密码而且进程会因为拿不到对端地址而莫名其妙退出。3.1 主机名与 hosts集群里不该出现 IP云主机创建后默认主机名通常是一串带实例 ID 的字符串配置文件里写这种名字既难记又容易写错。第一件事是把四台机器的主机名改成 node1 到 node4# 在每台节点上分别执行对应改成 node1 / node2 / node3 / node4 hostnamectl set-hostname node1 # 让当前会话立即生效避免要重新登录 exec bash然后把四行映射写进每台机器的/etc/hosts。注意用内网地址不要用公网地址公网流量走网关带宽和时延都不可控跨节点传数据块会慢到怀疑人生。# /etc/hosts 追加以下四行四台节点内容完全一致 # 以下地址为示例务必替换成控制台里实际的内网地址 192.168.1.11 node1 192.168.1.12 node2 192.168.1.13 node3 192.168.1.14 node4为什么强调内容完全一致因为 Hadoop 的从节点在启动时会把自己的主机名上报给主节点主节点再用这个名字反查地址。如果某台机器的 hosts 少了一行反查失败这个节点就会在 Web 页面上显示为Dead或者干脆不出现。我在实验里见过一次四台机器里有一台的 hosts 只写了三行结果那个节点上的 DataNode 一直在重启日志里全是UnknownHostException翻了半小时才定位到。改完 hosts 之后用hostname -f确认每台机器返回的是短名而不是localhost再用getent hosts node2验证解析能通。3.2 公钥分发一次汇总四台同步免密登录的原理很简单把四台机器的公钥汇总起来每台机器的authorized_keys里都放上这份汇总。这样任意两台之间互跳都不需要密码。第一步每台节点生成自己的密钥对。参数里-N 表示不设密码短语实验环境够用真实环境建议设短语并配合 ssh-agent。# 四台节点都执行一次已存在则跳过 ssh-keygen -t rsa -b 4096 -N -f /root/.ssh/id_rsa第二步在 node1 上把四台的公钥汇总到一个文件。这个过程需要临时输一次对端密码属于正常的首次信任建立。# 在 node1 上执行汇总四台机器的公钥 cat /root/.ssh/id_rsa.pub /root/.ssh/all_keys for n in node2 node3 node4; do ssh $n cat /root/.ssh/id_rsa.pub /root/.ssh/all_keys done # 确认文件里有四行 ssh-rsa 开头的内容 wc -l /root/.ssh/all_keys第三步把汇总文件推回四台机器覆盖各自的authorized_keys并把权限收紧# 在 node1 上执行分发并修正权限 for n in node1 node2 node3 node4; do scp /root/.ssh/all_keys $n:/root/.ssh/authorized_keys ssh $n chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys done权限这两行是重点。SSH 对权限极其敏感.ssh目录必须是 700authorized_keys必须是 600而且属主必须是当前用户。只要权限松一格SSH 就会静默忽略这个文件然后继续要密码报错信息里还不会明说原因属于典型的黑匣子式故障。3.3 免密自检与失败定位分发完不要急着装 Hadoop先跑一轮全量自检。用循环把四台机器各跳一遍看是否都能直接返回主机名# 在 node1 上执行四台全部返回名字才算通过 for n in node1 node2 node3 node4; do echo -n $n - ssh -o BatchModeyes -o ConnectTimeout5 $n hostname doneBatchModeyes的作用是禁用交互式密码输入一旦需要密码就直接失败退出而不是卡在那里等人输。这样脚本能立刻暴露问题不会误判成通过。ConnectTimeout5防止某台机器不可达时长时间挂起。如果某台机器仍然提示要密码按这个顺序查先看/root/.ssh/authorized_keys里是不是真的有四行且没有多余的空行或换行错位再看权限是不是 700/600然后看sshd的配置里PubkeyAuthentication是不是yes、AuthorizedKeysFile是不是指向了.ssh/authorized_keys最后看 SELinux 是否处于 enforcing 状态它会阻止 SSH 读取非标准上下文的密钥文件临时用setenforce 0验证一下就能确认。还有一个容易被忽略的点首次 SSH 到某台新机器会提示确认指纹如果脚本里没有处理就会卡在这一步。上面脚本里的BatchMode会在这种情况下直接失败解决办法是提前跑一遍手动 ssh 把指纹写进known_hosts或者在脚本里加-o StrictHostKeyCheckingno。实验环境可以这么做生产环境不建议关掉正确做法是提前分发known_hosts。4. Hadoop 与 Spark 集群落地四个配置文件、启动顺序和两个验收用例前置条件通了接下来才是主体工程。这一章按装包、改配置、启动、验证、接存储、跑查询的顺序走每一步都给出可以直接抄的片段和对应的判断依据。4.1 安装包与目录规范四个节点的软件版本必须完全一致包括小版本号。混合版本在 RPC 通信时会报序列化不兼容错误信息通常只说版本不匹配不告诉你是哪台机器排查成本很高。统一装到/opt下用软链接指向具体版本目录这样以后升级只改软链接所有环境变量不用动# 四台节点都执行以 Hadoop 3.3.x 为例 cd /opt # 从镜像站下载链接用实际可用地址替换 wget -c 镜像站地址/hadoop/common/hadoop-3.3.4/hadoop-3.3.4.tar.gz tar -zxvf hadoop-3.3.4.tar.gz ln -s /opt/hadoop-3.3.4 /opt/hadoop # Spark 同理注意选带 hadoop 依赖的预编译包 wget -c 镜像站地址/spark/spark-3.3.2/spark-3.3.2-bin-hadoop3.tgz tar -zxvf spark-3.3.2-bin-hadoop3.tgz ln -s /opt/spark-3.3.2-bin-hadoop3 /opt/sparkSpark 的预编译包一定要选-bin-hadoop3后缀的不带后缀的版本不含 Hadoop 客户端库跑起来会提示找不到org.apache.hadoop.*类。这个细节在下载页面上不显眼但选错了要重新下一遍几百兆的包。装完之后在 node1 上验证hadoop version和spark-submit --version能正常输出版本号再继续往下走。如果hadoop version报JAVA_HOME is not set说明环境变量文件没生效重新source一次或者检查是否有语法错误。4.2 四个 XML 与 workers 文件Hadoop 的配置集中在$HADOOP_CONF_DIR下的四个文件里。下面只贴关键项其余保持默认。core-site.xml定义默认文件系统和临时目录同时把对象存储的接入参数挂进去configuration !-- 默认文件系统指向主节点的 NameNode RPC 端口 -- property namefs.defaultFS/name valuehdfs://node1:8020/value /property !-- 临时目录放在数据盘避免系统盘被写满 -- property namehadoop.tmp.dir/name value/opt/hadoop/data/tmp/value /property !-- 以下是对象存储接入参数密钥走环境变量不落盘 -- property namefs.s3a.endpoint/name value${env.OBS_ENDPOINT}/value /property property namefs.s3a.access.key/name value${env.OBS_AK}/value /property property namefs.s3a.secret.key/name value${env.OBS_SK}/value /property !-- 桶以路径风格访问兼容性更好 -- property namefs.s3a.path.style.access/name valuetrue/value /property /configurationhdfs-site.xml决定副本数、元数据和数据块目录configuration !-- 四节点环境取 3兼顾可靠性和磁盘占用 -- property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/name/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/data/value /property !-- 从节点 Web 端口方便在页面上看块分布 -- property namedfs.datanode.http.address/name value0.0.0.0:9864/value /property /configurationyarn-site.xml管资源调度内存参数要和机器规格对得上configuration property nameyarn.resourcemanager.hostname/name valuenode1/value /property !-- shuffle 服务必须声明否则 reduce 阶段拿不到数据 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 8 GB 机器留 2 GB 给系统其余给 YARN -- property nameyarn.nodemanager.resource.memory-mb/name value6144/value /property property nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property !-- 实验环境关闭虚拟内存检查否则容器容易因 vmem 超限被杀 -- property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property /configurationmapred-site.xml指定计算框架跑在 YARN 上并且必须显式给出 classpathconfiguration property namemapreduce.framework.name/name valueyarn/value /property !-- 不配这一项任务会卡在 ACCEPTED 或报 ClassNotFound -- property namemapreduce.application.classpath/name value$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/*:$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/lib/*/value /property /configuration最后一个文件是workersHadoop 3 里叫这个名字2.x 叫slaves内容就是四行主机名node1 node2 node3 node4改完这几个文件用scp把整个$HADOOP_CONF_DIR目录同步到 node2 到 node4保证四个节点的配置完全一致。这里翻车的典型场景是只改了 node1启动后从节点的进程能起来但连不上主节点因为它们的fs.defaultFS还是默认的file:///。4.3 格式化、启动与 WordCount 验收格式化只做一次而且只在 node1 上做# 在 node1 执行且只执行一次 hdfs namenode -format -clusterId bigdata-lab-clusterId指定固定值是为了让后续如果重装某个节点时可以复用同一个集群标识减少clusterID 不一致这类问题。格式化之前确认dfs.namenode.name.dir指向的目录是空的格式化之后再执行一次会生成新的 clusterID而 DataNode 还记着旧的直接导致 DataNode 拒绝启动。启动顺序是先 HDFS 再 YARN# 在 node1 上执行 start-dfs.sh start-yarn.sh # 到每台节点上确认进程node1 应看到 3 个node2~4 各 2 个 jps期望的进程分布是node1 上有 NameNode、SecondaryNameNode、ResourceManagernode2 到 node4 上各有 DataNode 和 NodeManager。少一个都不行缺 DataNode 说明该节点没连上主节点缺 NodeManager 说明 YARN 配置没同步过去。跑 WordCount 是这套实验的标准验收动作它同时验证了 HDFS 读写、YARN 调度和 MapReduce 执行三件事# 在 node1 上执行 hdfs dfs -mkdir -p /input # 用 Hadoop 自带的 XML 文件当输入不用额外准备数据 hdfs dfs -put $HADOOP_HOME/etc/hadoop/*.xml /input # 提交作业jar 包版本号按实际下载的写 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar \ wordcount /input /output # 查看结果前 10 行 hdfs dfs -cat /output/part-r-00000 | head -10输出目录必须不存在否则作业会直接报FileAlreadyExistsException退出。这是 MapReduce 的保护机制防止误覆盖。重跑之前先hdfs dfs -rm -r /output。验收看三个点作业输出里Map input records和Reduce output records都不为 0/output/part-r-00000里能看到正常的词频统计YARN 的 8088 页面上这个应用状态是 FINISHED。三个都满足说明分布式存储和分布式计算这条链路是通的。4.4 Spark 集群与 OBS 互联Spark 部署比 Hadoop 简单核心是三个文件。spark-env.sh里指定主节点和 Java 环境# $SPARK_HOME/conf/spark-env.sh export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR/opt/hadoop/etc/hadoop export SPARK_MASTER_HOSTnode1 export SPARK_MASTER_PORT7077 export SPARK_WORKER_MEMORY4g export SPARK_WORKER_CORES2HADOOP_CONF_DIR这一行是打通 OBS 的关键Spark 会复用 Hadoop 的core-site.xml里面的fs.s3a.*参数自动生效不需要在 Spark 里再配一遍。workers文件写从节点node2 node3 node4spark-defaults.conf里补上访问对象存储需要的 jar 和序列化设置spark.jars.packages org.apache.hadoop:hadoop-aws:3.3.4 spark.hadoop.fs.s3a.fast.upload true spark.serializer org.apache.spark.serializer.KryoSerializerhadoop-aws的版本必须和 Hadoop 主版本对齐3.3.4 的 Hadoop 配 3.3.4 的 hadoop-aws配 3.2.x 会在运行时抛NoSuchMethodError错误栈指向 SDK 内部很难一眼看出是版本问题。启动集群# 注意用绝对路径避免和 Hadoop 的 start-all.sh 撞名 $SPARK_HOME/sbin/start-all.sh这里有个很隐蔽的坑Hadoop 和 Spark 的 sbin 目录下都有start-all.sh如果两个目录都在PATH里执行时可能起错脚本表现是命令跑完了但 Spark 进程没起来。稳妥做法是始终写全路径或者把两个 sbin 从 PATH 里去掉只保留 bin。验证 OBS 连通性用 Spark 读一个桶里的路径就行# 在 node1 执行bucket 名字换成自己的 spark-shell --master spark://node1:7077// 在 spark-shell 里执行验证 s3a 通道是否打通 val path s3a://你的桶名/test/hello.txt val rdd sc.textFile(path) println(行数: rdd.count())能打印出行数说明从计算节点到对象存储的链路完整。如果报403 Forbidden先核对 AK/SK 是否抄错、桶名和端点区域是否匹配如果报No FileSystem for scheme: s3a说明hadoop-aws的 jar 没加载上检查spark.jars.packages那一行是否生效。4.5 交互式查询把 SQL 跑到对象存储上最后一个环节是把前面搭好的存储和计算用 SQL 用起来。用spark-sql建外部表数据直接落在对象存储上不搬进 HDFS# 以 YARN 模式启动交互式 SQLwarehouse 指向桶 spark-sql --master yarn \ --conf spark.sql.warehouse.dirs3a://你的桶名/warehouse-- 建一张指向对象存储的外部表字段按实际日志结构调整 CREATE EXTERNAL TABLE access_log ( log_date STRING, user_id STRING, page_url STRING, stay_ms BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY , LOCATION s3a://你的桶名/logs/access/; -- 按天统计访问量验证聚合查询能跑通 SELECT log_date, COUNT(*) AS pv, AVG(stay_ms) AS avg_stay FROM access_log GROUP BY log_date ORDER BY pv DESC LIMIT 10;外部表的特点是删表不删数据DROP TABLE之后桶里的文件还在这一点在做重复实验时很省事改一下LOCATION就能换一份数据源不用反复上传。查询结果要落盘的话用INSERT OVERWRITE DIRECTORY写回桶里INSERT OVERWRITE DIRECTORY s3a://你的桶名/result/pv_by_day USING csv SELECT log_date, COUNT(*) FROM access_log GROUP BY log_date;这一步的验收标准是三条SHOW TABLES能看到建好的表聚合查询能在合理时间内返回结果结果目录在桶里真实存在且内容非空。三条都过说明存储计算分离 交互式查询这条链路是通的也是整个实验里技术含量最高的一段。5. 排查手册五类最容易翻车的现象、原因与处置实验做不下来绝大多数不是不会配而是报错信息指向不明确。这一章按现象、原因、解决三段式整理五类高频故障覆盖进程、通信、调度和存储四个方面。5.1 进程与节点类问题现象一jps里只有 node1 有进程node2 到 node4 空空如也。原因通常有两个workers文件没改还是默认的localhost或者$HADOOP_CONF_DIR只同步到了 node1其他节点的core-site.xml里fs.defaultFS还是本地文件系统进程起来后立刻退出。解决方式是核对workers内容并重新分发整个配置目录# 在 node1 执行确认四个节点都在列表里 cat $HADOOP_CONF_DIR/workers # 重新同步配置到三台从节点 for n in node2 node3 node4; do scp -r $HADOOP_CONF_DIR/* $n:$HADOOP_CONF_DIR/ done分发完再stop-dfs.sh然后start-dfs.sh不要只重启单点因为主节点缓存了旧的节点列表。现象二DataNode 起不来日志里写着 clusterID 不一致。原因是重复执行了hdfs namenode -format。格式化会生成新的集群标识写进 NameNode 的元数据目录而 DataNode 的VERSION文件里还是旧标识两者对不上就拒绝加入。解决时不要急着重装。先看 NameNode 的data/name/current/VERSION里的clusterID再对比 DataNode 的data/data/current/VERSION。如果只是某个节点的标识不同把该节点的 data 目录清空重启即可它会重新向主节点注册如果全部对不上就把所有节点的 data 目录清空重新格式化一次然后立刻开始跑数据不要再来第二次。5.2 通信与权限类问题现象三脚本里ssh node2 hostname仍然提示输入密码。常见原因按概率排序authorized_keys权限不是 600.ssh目录权限不是 700汇总时漏了某台机器的公钥SELinux 拦截。排查用一条命令快速定位# 在目标节点上执行看权限和内容行数 ls -ld /root/.ssh /root/.ssh/authorized_keys wc -l /root/.ssh/authorized_keys # 检查 SELinux 状态Enforcing 时先临时关掉验证 getenforce如果权限都正确、四行公钥也都在还是不通就切到目标节点上看sshd日志一般在/var/log/secure或/var/log/auth.log里面会明确写出拒绝原因比在客户端猜快得多。现象四WordCount 提交后一直停在 ACCEPTED或者 map 到 0% 就不动了。停在 ACCEPTED 说明资源申请不下来通常是yarn.nodemanager.resource.memory-mb设得比机器实际可用内存还大或者 NodeManager 根本没起来。map 到 0% 不动多数是mapreduce.application.classpath没配容器里找不到 MapReduce 的类。先用 8088 页面确认可用资源总量对不对再检查 classpath 配置。如果日志里出现Container killed on request. Exit code is 143那是容器被内存限制杀掉把yarn.nodemanager.vmem-check-enabled设为 false、把mapreduce.map.memory.mb调大一些再试。现象五访问对象存储报 403 或InvalidAccessKeyId。三个方向查AK/SK 抄错或前后有空格尤其是从 csv 复制时容易带上引号桶名和端点区域不匹配比如桶在 A 区域而端点写的是 B 区域机器时间偏差过大签名校验对时间敏感偏差超过 15 分钟就会失败。# 检查时间同步状态偏差大就同步一下 timedatectl status # 快速验证密钥是否有效能列桶说明配置没问题 hadoop fs -ls s3a://你的桶名/第三条最容易被忽略因为机器刚创建时时间通常正常但长时间挂起恢复后会漂移表现就是昨天还好好的今天全部 403。6. 验收与答辩一份清单把四个实验串成一条链路很多人的实验报告写到最后一页才发现四个实验看起来各做各的第一个讲买机器搭 Hadoop第二个讲建桶第三个讲 Spark第四个讲 SQL彼此没有因果关系。答辩时被问一句这四个环节之间是什么关系就答不上来了。我的建议是先把验收清单做成一张表一条一条打勾答辩时直接照着这张表讲逻辑自然就串起来了。验收项验证命令期望结果四节点免密互通ssh -o BatchModeyes node3 hostname直接返回 node3HDFS 正常hdfs dfsadmin -reportLive datanodes 为 4YARN 正常yarn node -list4 个节点状态 RUNNINGMapReduce 可跑hadoop jar ... wordcount /input /output输出词频且状态 FINISHEDSpark 集群$SPARK_HOME/sbin/start-all.sh后看 8080 页面3 个 Worker 注册成功对象存储连通hadoop fs -ls s3a://桶名/正常列出目录交互式查询spark-sql里执行聚合 SQL返回非空结果集结果落盘hadoop fs -ls s3a://桶名/result/目录存在且文件非空表格填满之后答辩的讲法就有了骨架。我一般会按三段讲第一段讲资源规划为什么是四台、为什么同子网、为什么桶要选并行文件系统这一段体现的是设计能力而不是操作能力第二段讲链路打通从免密互信到 HDFS 到 YARN 到 Spark每一层用什么命令验证过这一段体现的是工程严谨性第三段讲存储计算分离把数据放在对象存储上、用 Spark SQL 直接查说明为什么这种方式比把数据搬进 HDFS 更适合做分析型查询这一段是整个实验里最有含量的部分也是最容易被追问的地方。被追问时最忌讳说教程上就是这么写的。每个参数都要能说出为什么副本数为什么是 3 不是 2hadoop.tmp.dir为什么不能放在系统盘fs.s3a.path.style.access为什么设成 true。答不上来的参数就老老实实说这个值是按默认配的还没深入验证过比硬编一个理由可信得多。还有一个小技巧提前把每个实验的关键截图存成一组命名规范一点比如01-ecs-list、02-hosts、03-jps、04-wordcount、05-spark-ui、06-sql-result。答辩翻页的时候不用现场找临时切控制台去截图很容易在等待加载的几十秒里把节奏打乱。从那以后我每次带人做这类集群实验都会在动手之前先把这张验收清单写出来贴在文档最前面做完一项勾一项绝不允许先跑起来再说。因为集群这东西跑起来和跑对是两回事跑对了和讲得清楚又是两回事。希望帮到你。本文还有配套的精品资源点击获取
简介《华为云大数据实验报告》面向大数据课程学习者及华为云实践入门者围绕云上大数据平台的部署、管理与查询展开可用于课程实验、课后复现和技能梳理。压缩包内共1个docx文档约4.36MB以图文实验报告形式组织便于按模块查阅与对照操作。内容覆盖四个实验利用ECS与OBS搭建Hadoop集群的云主机实验、借助云服务完成数据收集存储与分析、BigData Pro一站式方案中的环境准备及Hadoop/Spark集群搭建以及基于Spark SQL或Flink SQL的交互式查询。报告涉及节点通信、OBS互联测试、集群配置和查询任务等关键环节可帮助读者理解华为云基础设施与服务组件的配合方式掌握云环境中的集群搭建、资源管理与数据分析流程。目前已有2607人学习适合作为大数据实验课程参考与上机实践辅助材料。1. 从先买四台机器开始这套云上大数据实验要解决什么很多人第一次做云上大数据实验习惯先在控制台点开一台云主机装完 Hadoop再想办法把另外几台机器接进来结果卡在节点互相不认识、DataNode 起不来、任务只在一台机器上跑。这套方案反过来推进先用弹性云服务器 ECS 申请四台同子网实例用对象存储 OBS 做数据的落地和归档再按网络互通、免密互信、分布式存储、分布式计算、交互式查询的顺序一层层往上搭。它面向的是要交一份大数据课程设计或综合实验报告的人也适合需要在一周内把 Hadoop、Spark 集群从零跑通的从业者。整套链路对应四个实验环节云主机实现大数据、云服务实现大数据、托管集群套餐、大数据交互式查询下面按能复现的顺序拆开讲。2. 环境底座设计四台 ECS、一个 OBS 桶和一套访问密钥怎么规划集群跑不起来八成不是代码问题而是底座没规划好。四台机器的规格、子网、桶的选型、密钥的存放方式这些在控制台上点几下就过去的步骤恰恰决定了后面能不能一次性把 WordCount 跑通。这一章把底座拆成三块节点角色、存储与密钥、网络放通。2.1 节点角色划分与规格选型四节点是这套实验的标准配置node1 兼作主节点同时承担 NameNode、ResourceManager 和 Spark Master 三个角色node2 到 node4 是从节点承担 DataNode、NodeManager 和 Spark Worker。把它写成表更清楚节点规格主要角色常驻进程node14 vCPU / 8 GB / 40 GB主节点NameNode、SecondaryNameNode、ResourceManager、Spark Masternode24 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Workernode34 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Workernode44 vCPU / 8 GB / 40 GB从节点DataNode、NodeManager、Spark Worker为什么不干脆开三台省点资源因为 HDFS 默认三副本三台机器里任何一台挂掉某个块的三份副本有可能同时不可用恢复过程会很被动四台机器给了副本放置策略一个周转余地也正好对应实验报告里node1 到 node4的叙述。规格上 4 vCPU / 8 GB 是下限低于这个数YARN 给单个容器分配的可用内存会小到让 MapReduce 任务反复重试看着像卡死其实是资源不够。创建实例时有三个选项必须统一否则后面全是坑同一个 VPC、同一个子网、同一个安全组。同一子网保证了内网地址可以直连不用做任何路由配置同一安全组保证了节点之间默认互访省去逐条加规则的麻烦。可用区AZ也尽量选同一个跨可用区的内网时延虽然也能跑但数据块传输会慢一个量级实验体感很差。操作系统选公共镜像里的主流 Linux 发行版即可重点确认镜像里是否自带 OpenJDK 8。Hadoop 3.x 对 JDK 8 兼容性最好JDK 11 在某些版本上会遇到模块访问权限的报错。如果镜像不带就在后面统一用包管理器装java-1.8.0-openjdk-devel注意是 devel 版本只有运行时没有开发包的话编译相关组件会缺头文件。计费方式按需即可实验周期通常在一到两周做完把实例和桶一起释放。这里有个血泪经验释放实例前一定先把写好的配置文件和实验结果打包存到本地云主机的系统盘跟着实例一起销毁格式化过的数据目录不会给你留后悔药。2.2 对象存储桶与访问密钥的最小化管理对象存储这块第一件事是选桶类型。普通对象桶适合存日志和备份但大数据场景要的是并行文件系统类型的桶它提供类 POSIX 的语义多客户端并发读写时吞吐更高Hadoop 的 s3a 客户端打上去也不会出现大量小文件写入超时。桶名在服务范围内全局唯一建议用项目名 随机后缀的形式避免和别人撞名。创建完桶拿到端点地址格式大致是https://obs.region.example-cloud.comregion要换成自己实际所在的区域。端点写错是最常见的 403 来源之一因为请求会被路由到错误区域的入口签名校验对不上。访问密钥的生成入口在控制台的我的凭证里下载下来是一个credentials.csv文件里面三列User Name、Access Key Id、Secret Access Key。这个文件只提供一次下载关掉页面就再也拿不到 Secret Key只能重新生成一对。所以第一件事是把它存到本地密码管理器或者加密压缩包里不要截图发群更不要直接贴进要提交的实验报告。密钥的使用方式决定了这份作业安不安全。直接写进 Java 代码或者提交到代码仓库是最差的做法稍微好一点是写进配置文件更稳妥的是走环境变量让配置文件去引用变量名。在每台节点上建一个统一的环境变量文件# /etc/profile.d/bigdata.sh # 所有节点保持一致权限设为 600只允许 root 读取 export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME/opt/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_HOME/opt/spark export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin # 对象存储接入信息用变量占位避免硬编码进 XML export OBS_ENDPOINThttps://obs.region.example-cloud.com export OBS_BUCKETbigdata-lab-xxxx export OBS_AK你的 Access Key Id export OBS_SK你的 Secret Access Key执行source /etc/profile.d/bigdata.sh之后Hadoop 的配置文件里就可以写${env.OBS_AK}这样的占位符Hadoop 在解析配置时会自动做环境变量替换。这样一来core-site.xml里看不到明文密钥配置文件可以放心分发到四个节点也不怕误传到公开仓库。注意这个文件要chmod 600并且不要给非 root 用户读权限。权限最小化还有一层如果控制台支持给密钥绑定策略就只授予这一个桶的读写权限不要图省事给管理员权限。实验环境里无所谓但养成习惯之后换到真实项目上能少一次事故。2.3 安全组与端口放通别用全放通糊过去同一安全组内的实例默认可以互访全部端口这一点省了很多事。但公网入口必须收窄只放通 22 端口的 SSH而且源地址限制成本机公网 IP。其余端口一个都不要对公网开放包括 9870 和 8088 这两个 Web 页面它们没有强认证暴露出去等于把集群状态和任务日志公开。集群内部需要放通的端口列一下方便在自建安全组或者排查连通性时对照端口所属服务用途22SSH节点间跳转与配置分发8020NameNode RPC客户端读写 HDFS9870NameNode Web集群状态查看9864 / 9866DataNode数据块传输与状态上报8032ResourceManager应用提交与资源申请8088YARN Web任务进度查看7077Spark MasterSpark 任务提交8080Spark Master WebSpark 集群状态18080History Server历史任务回溯排查连通性别用ping很多云环境默认禁 ICMPping不通不代表网络有问题。用telnet node1 8020或者nc -zv node1 8020才是有效验证。这一步在做跨节点测试时很关键能提前把到底是网络不通还是服务没起这个二选一判断清楚后面排错会省掉大量时间。3. 集群通信前置hosts 映射、四节点免密互信与连通自检分布式集群的第一道门槛不是 Hadoop是让四台机器互相认得出、进得去。这一步做完后面所有批量分发配置、批量启动进程才有基础这一步没做扎实后面每次启动都要手输四次密码而且进程会因为拿不到对端地址而莫名其妙退出。3.1 主机名与 hosts集群里不该出现 IP云主机创建后默认主机名通常是一串带实例 ID 的字符串配置文件里写这种名字既难记又容易写错。第一件事是把四台机器的主机名改成 node1 到 node4# 在每台节点上分别执行对应改成 node1 / node2 / node3 / node4 hostnamectl set-hostname node1 # 让当前会话立即生效避免要重新登录 exec bash然后把四行映射写进每台机器的/etc/hosts。注意用内网地址不要用公网地址公网流量走网关带宽和时延都不可控跨节点传数据块会慢到怀疑人生。# /etc/hosts 追加以下四行四台节点内容完全一致 # 以下地址为示例务必替换成控制台里实际的内网地址 192.168.1.11 node1 192.168.1.12 node2 192.168.1.13 node3 192.168.1.14 node4为什么强调内容完全一致因为 Hadoop 的从节点在启动时会把自己的主机名上报给主节点主节点再用这个名字反查地址。如果某台机器的 hosts 少了一行反查失败这个节点就会在 Web 页面上显示为Dead或者干脆不出现。我在实验里见过一次四台机器里有一台的 hosts 只写了三行结果那个节点上的 DataNode 一直在重启日志里全是UnknownHostException翻了半小时才定位到。改完 hosts 之后用hostname -f确认每台机器返回的是短名而不是localhost再用getent hosts node2验证解析能通。3.2 公钥分发一次汇总四台同步免密登录的原理很简单把四台机器的公钥汇总起来每台机器的authorized_keys里都放上这份汇总。这样任意两台之间互跳都不需要密码。第一步每台节点生成自己的密钥对。参数里-N 表示不设密码短语实验环境够用真实环境建议设短语并配合 ssh-agent。# 四台节点都执行一次已存在则跳过 ssh-keygen -t rsa -b 4096 -N -f /root/.ssh/id_rsa第二步在 node1 上把四台的公钥汇总到一个文件。这个过程需要临时输一次对端密码属于正常的首次信任建立。# 在 node1 上执行汇总四台机器的公钥 cat /root/.ssh/id_rsa.pub /root/.ssh/all_keys for n in node2 node3 node4; do ssh $n cat /root/.ssh/id_rsa.pub /root/.ssh/all_keys done # 确认文件里有四行 ssh-rsa 开头的内容 wc -l /root/.ssh/all_keys第三步把汇总文件推回四台机器覆盖各自的authorized_keys并把权限收紧# 在 node1 上执行分发并修正权限 for n in node1 node2 node3 node4; do scp /root/.ssh/all_keys $n:/root/.ssh/authorized_keys ssh $n chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys done权限这两行是重点。SSH 对权限极其敏感.ssh目录必须是 700authorized_keys必须是 600而且属主必须是当前用户。只要权限松一格SSH 就会静默忽略这个文件然后继续要密码报错信息里还不会明说原因属于典型的黑匣子式故障。3.3 免密自检与失败定位分发完不要急着装 Hadoop先跑一轮全量自检。用循环把四台机器各跳一遍看是否都能直接返回主机名# 在 node1 上执行四台全部返回名字才算通过 for n in node1 node2 node3 node4; do echo -n $n - ssh -o BatchModeyes -o ConnectTimeout5 $n hostname doneBatchModeyes的作用是禁用交互式密码输入一旦需要密码就直接失败退出而不是卡在那里等人输。这样脚本能立刻暴露问题不会误判成通过。ConnectTimeout5防止某台机器不可达时长时间挂起。如果某台机器仍然提示要密码按这个顺序查先看/root/.ssh/authorized_keys里是不是真的有四行且没有多余的空行或换行错位再看权限是不是 700/600然后看sshd的配置里PubkeyAuthentication是不是yes、AuthorizedKeysFile是不是指向了.ssh/authorized_keys最后看 SELinux 是否处于 enforcing 状态它会阻止 SSH 读取非标准上下文的密钥文件临时用setenforce 0验证一下就能确认。还有一个容易被忽略的点首次 SSH 到某台新机器会提示确认指纹如果脚本里没有处理就会卡在这一步。上面脚本里的BatchMode会在这种情况下直接失败解决办法是提前跑一遍手动 ssh 把指纹写进known_hosts或者在脚本里加-o StrictHostKeyCheckingno。实验环境可以这么做生产环境不建议关掉正确做法是提前分发known_hosts。4. Hadoop 与 Spark 集群落地四个配置文件、启动顺序和两个验收用例前置条件通了接下来才是主体工程。这一章按装包、改配置、启动、验证、接存储、跑查询的顺序走每一步都给出可以直接抄的片段和对应的判断依据。4.1 安装包与目录规范四个节点的软件版本必须完全一致包括小版本号。混合版本在 RPC 通信时会报序列化不兼容错误信息通常只说版本不匹配不告诉你是哪台机器排查成本很高。统一装到/opt下用软链接指向具体版本目录这样以后升级只改软链接所有环境变量不用动# 四台节点都执行以 Hadoop 3.3.x 为例 cd /opt # 从镜像站下载链接用实际可用地址替换 wget -c 镜像站地址/hadoop/common/hadoop-3.3.4/hadoop-3.3.4.tar.gz tar -zxvf hadoop-3.3.4.tar.gz ln -s /opt/hadoop-3.3.4 /opt/hadoop # Spark 同理注意选带 hadoop 依赖的预编译包 wget -c 镜像站地址/spark/spark-3.3.2/spark-3.3.2-bin-hadoop3.tgz tar -zxvf spark-3.3.2-bin-hadoop3.tgz ln -s /opt/spark-3.3.2-bin-hadoop3 /opt/sparkSpark 的预编译包一定要选-bin-hadoop3后缀的不带后缀的版本不含 Hadoop 客户端库跑起来会提示找不到org.apache.hadoop.*类。这个细节在下载页面上不显眼但选错了要重新下一遍几百兆的包。装完之后在 node1 上验证hadoop version和spark-submit --version能正常输出版本号再继续往下走。如果hadoop version报JAVA_HOME is not set说明环境变量文件没生效重新source一次或者检查是否有语法错误。4.2 四个 XML 与 workers 文件Hadoop 的配置集中在$HADOOP_CONF_DIR下的四个文件里。下面只贴关键项其余保持默认。core-site.xml定义默认文件系统和临时目录同时把对象存储的接入参数挂进去configuration !-- 默认文件系统指向主节点的 NameNode RPC 端口 -- property namefs.defaultFS/name valuehdfs://node1:8020/value /property !-- 临时目录放在数据盘避免系统盘被写满 -- property namehadoop.tmp.dir/name value/opt/hadoop/data/tmp/value /property !-- 以下是对象存储接入参数密钥走环境变量不落盘 -- property namefs.s3a.endpoint/name value${env.OBS_ENDPOINT}/value /property property namefs.s3a.access.key/name value${env.OBS_AK}/value /property property namefs.s3a.secret.key/name value${env.OBS_SK}/value /property !-- 桶以路径风格访问兼容性更好 -- property namefs.s3a.path.style.access/name valuetrue/value /property /configurationhdfs-site.xml决定副本数、元数据和数据块目录configuration !-- 四节点环境取 3兼顾可靠性和磁盘占用 -- property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/name/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/data/value /property !-- 从节点 Web 端口方便在页面上看块分布 -- property namedfs.datanode.http.address/name value0.0.0.0:9864/value /property /configurationyarn-site.xml管资源调度内存参数要和机器规格对得上configuration property nameyarn.resourcemanager.hostname/name valuenode1/value /property !-- shuffle 服务必须声明否则 reduce 阶段拿不到数据 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 8 GB 机器留 2 GB 给系统其余给 YARN -- property nameyarn.nodemanager.resource.memory-mb/name value6144/value /property property nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property !-- 实验环境关闭虚拟内存检查否则容器容易因 vmem 超限被杀 -- property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property /configurationmapred-site.xml指定计算框架跑在 YARN 上并且必须显式给出 classpathconfiguration property namemapreduce.framework.name/name valueyarn/value /property !-- 不配这一项任务会卡在 ACCEPTED 或报 ClassNotFound -- property namemapreduce.application.classpath/name value$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/*:$HADOOP_MAPRED_HOME/share/hadoop/mapreduce/lib/*/value /property /configuration最后一个文件是workersHadoop 3 里叫这个名字2.x 叫slaves内容就是四行主机名node1 node2 node3 node4改完这几个文件用scp把整个$HADOOP_CONF_DIR目录同步到 node2 到 node4保证四个节点的配置完全一致。这里翻车的典型场景是只改了 node1启动后从节点的进程能起来但连不上主节点因为它们的fs.defaultFS还是默认的file:///。4.3 格式化、启动与 WordCount 验收格式化只做一次而且只在 node1 上做# 在 node1 执行且只执行一次 hdfs namenode -format -clusterId bigdata-lab-clusterId指定固定值是为了让后续如果重装某个节点时可以复用同一个集群标识减少clusterID 不一致这类问题。格式化之前确认dfs.namenode.name.dir指向的目录是空的格式化之后再执行一次会生成新的 clusterID而 DataNode 还记着旧的直接导致 DataNode 拒绝启动。启动顺序是先 HDFS 再 YARN# 在 node1 上执行 start-dfs.sh start-yarn.sh # 到每台节点上确认进程node1 应看到 3 个node2~4 各 2 个 jps期望的进程分布是node1 上有 NameNode、SecondaryNameNode、ResourceManagernode2 到 node4 上各有 DataNode 和 NodeManager。少一个都不行缺 DataNode 说明该节点没连上主节点缺 NodeManager 说明 YARN 配置没同步过去。跑 WordCount 是这套实验的标准验收动作它同时验证了 HDFS 读写、YARN 调度和 MapReduce 执行三件事# 在 node1 上执行 hdfs dfs -mkdir -p /input # 用 Hadoop 自带的 XML 文件当输入不用额外准备数据 hdfs dfs -put $HADOOP_HOME/etc/hadoop/*.xml /input # 提交作业jar 包版本号按实际下载的写 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar \ wordcount /input /output # 查看结果前 10 行 hdfs dfs -cat /output/part-r-00000 | head -10输出目录必须不存在否则作业会直接报FileAlreadyExistsException退出。这是 MapReduce 的保护机制防止误覆盖。重跑之前先hdfs dfs -rm -r /output。验收看三个点作业输出里Map input records和Reduce output records都不为 0/output/part-r-00000里能看到正常的词频统计YARN 的 8088 页面上这个应用状态是 FINISHED。三个都满足说明分布式存储和分布式计算这条链路是通的。4.4 Spark 集群与 OBS 互联Spark 部署比 Hadoop 简单核心是三个文件。spark-env.sh里指定主节点和 Java 环境# $SPARK_HOME/conf/spark-env.sh export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR/opt/hadoop/etc/hadoop export SPARK_MASTER_HOSTnode1 export SPARK_MASTER_PORT7077 export SPARK_WORKER_MEMORY4g export SPARK_WORKER_CORES2HADOOP_CONF_DIR这一行是打通 OBS 的关键Spark 会复用 Hadoop 的core-site.xml里面的fs.s3a.*参数自动生效不需要在 Spark 里再配一遍。workers文件写从节点node2 node3 node4spark-defaults.conf里补上访问对象存储需要的 jar 和序列化设置spark.jars.packages org.apache.hadoop:hadoop-aws:3.3.4 spark.hadoop.fs.s3a.fast.upload true spark.serializer org.apache.spark.serializer.KryoSerializerhadoop-aws的版本必须和 Hadoop 主版本对齐3.3.4 的 Hadoop 配 3.3.4 的 hadoop-aws配 3.2.x 会在运行时抛NoSuchMethodError错误栈指向 SDK 内部很难一眼看出是版本问题。启动集群# 注意用绝对路径避免和 Hadoop 的 start-all.sh 撞名 $SPARK_HOME/sbin/start-all.sh这里有个很隐蔽的坑Hadoop 和 Spark 的 sbin 目录下都有start-all.sh如果两个目录都在PATH里执行时可能起错脚本表现是命令跑完了但 Spark 进程没起来。稳妥做法是始终写全路径或者把两个 sbin 从 PATH 里去掉只保留 bin。验证 OBS 连通性用 Spark 读一个桶里的路径就行# 在 node1 执行bucket 名字换成自己的 spark-shell --master spark://node1:7077// 在 spark-shell 里执行验证 s3a 通道是否打通 val path s3a://你的桶名/test/hello.txt val rdd sc.textFile(path) println(行数: rdd.count())能打印出行数说明从计算节点到对象存储的链路完整。如果报403 Forbidden先核对 AK/SK 是否抄错、桶名和端点区域是否匹配如果报No FileSystem for scheme: s3a说明hadoop-aws的 jar 没加载上检查spark.jars.packages那一行是否生效。4.5 交互式查询把 SQL 跑到对象存储上最后一个环节是把前面搭好的存储和计算用 SQL 用起来。用spark-sql建外部表数据直接落在对象存储上不搬进 HDFS# 以 YARN 模式启动交互式 SQLwarehouse 指向桶 spark-sql --master yarn \ --conf spark.sql.warehouse.dirs3a://你的桶名/warehouse-- 建一张指向对象存储的外部表字段按实际日志结构调整 CREATE EXTERNAL TABLE access_log ( log_date STRING, user_id STRING, page_url STRING, stay_ms BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY , LOCATION s3a://你的桶名/logs/access/; -- 按天统计访问量验证聚合查询能跑通 SELECT log_date, COUNT(*) AS pv, AVG(stay_ms) AS avg_stay FROM access_log GROUP BY log_date ORDER BY pv DESC LIMIT 10;外部表的特点是删表不删数据DROP TABLE之后桶里的文件还在这一点在做重复实验时很省事改一下LOCATION就能换一份数据源不用反复上传。查询结果要落盘的话用INSERT OVERWRITE DIRECTORY写回桶里INSERT OVERWRITE DIRECTORY s3a://你的桶名/result/pv_by_day USING csv SELECT log_date, COUNT(*) FROM access_log GROUP BY log_date;这一步的验收标准是三条SHOW TABLES能看到建好的表聚合查询能在合理时间内返回结果结果目录在桶里真实存在且内容非空。三条都过说明存储计算分离 交互式查询这条链路是通的也是整个实验里技术含量最高的一段。5. 排查手册五类最容易翻车的现象、原因与处置实验做不下来绝大多数不是不会配而是报错信息指向不明确。这一章按现象、原因、解决三段式整理五类高频故障覆盖进程、通信、调度和存储四个方面。5.1 进程与节点类问题现象一jps里只有 node1 有进程node2 到 node4 空空如也。原因通常有两个workers文件没改还是默认的localhost或者$HADOOP_CONF_DIR只同步到了 node1其他节点的core-site.xml里fs.defaultFS还是本地文件系统进程起来后立刻退出。解决方式是核对workers内容并重新分发整个配置目录# 在 node1 执行确认四个节点都在列表里 cat $HADOOP_CONF_DIR/workers # 重新同步配置到三台从节点 for n in node2 node3 node4; do scp -r $HADOOP_CONF_DIR/* $n:$HADOOP_CONF_DIR/ done分发完再stop-dfs.sh然后start-dfs.sh不要只重启单点因为主节点缓存了旧的节点列表。现象二DataNode 起不来日志里写着 clusterID 不一致。原因是重复执行了hdfs namenode -format。格式化会生成新的集群标识写进 NameNode 的元数据目录而 DataNode 的VERSION文件里还是旧标识两者对不上就拒绝加入。解决时不要急着重装。先看 NameNode 的data/name/current/VERSION里的clusterID再对比 DataNode 的data/data/current/VERSION。如果只是某个节点的标识不同把该节点的 data 目录清空重启即可它会重新向主节点注册如果全部对不上就把所有节点的 data 目录清空重新格式化一次然后立刻开始跑数据不要再来第二次。5.2 通信与权限类问题现象三脚本里ssh node2 hostname仍然提示输入密码。常见原因按概率排序authorized_keys权限不是 600.ssh目录权限不是 700汇总时漏了某台机器的公钥SELinux 拦截。排查用一条命令快速定位# 在目标节点上执行看权限和内容行数 ls -ld /root/.ssh /root/.ssh/authorized_keys wc -l /root/.ssh/authorized_keys # 检查 SELinux 状态Enforcing 时先临时关掉验证 getenforce如果权限都正确、四行公钥也都在还是不通就切到目标节点上看sshd日志一般在/var/log/secure或/var/log/auth.log里面会明确写出拒绝原因比在客户端猜快得多。现象四WordCount 提交后一直停在 ACCEPTED或者 map 到 0% 就不动了。停在 ACCEPTED 说明资源申请不下来通常是yarn.nodemanager.resource.memory-mb设得比机器实际可用内存还大或者 NodeManager 根本没起来。map 到 0% 不动多数是mapreduce.application.classpath没配容器里找不到 MapReduce 的类。先用 8088 页面确认可用资源总量对不对再检查 classpath 配置。如果日志里出现Container killed on request. Exit code is 143那是容器被内存限制杀掉把yarn.nodemanager.vmem-check-enabled设为 false、把mapreduce.map.memory.mb调大一些再试。现象五访问对象存储报 403 或InvalidAccessKeyId。三个方向查AK/SK 抄错或前后有空格尤其是从 csv 复制时容易带上引号桶名和端点区域不匹配比如桶在 A 区域而端点写的是 B 区域机器时间偏差过大签名校验对时间敏感偏差超过 15 分钟就会失败。# 检查时间同步状态偏差大就同步一下 timedatectl status # 快速验证密钥是否有效能列桶说明配置没问题 hadoop fs -ls s3a://你的桶名/第三条最容易被忽略因为机器刚创建时时间通常正常但长时间挂起恢复后会漂移表现就是昨天还好好的今天全部 403。6. 验收与答辩一份清单把四个实验串成一条链路很多人的实验报告写到最后一页才发现四个实验看起来各做各的第一个讲买机器搭 Hadoop第二个讲建桶第三个讲 Spark第四个讲 SQL彼此没有因果关系。答辩时被问一句这四个环节之间是什么关系就答不上来了。我的建议是先把验收清单做成一张表一条一条打勾答辩时直接照着这张表讲逻辑自然就串起来了。验收项验证命令期望结果四节点免密互通ssh -o BatchModeyes node3 hostname直接返回 node3HDFS 正常hdfs dfsadmin -reportLive datanodes 为 4YARN 正常yarn node -list4 个节点状态 RUNNINGMapReduce 可跑hadoop jar ... wordcount /input /output输出词频且状态 FINISHEDSpark 集群$SPARK_HOME/sbin/start-all.sh后看 8080 页面3 个 Worker 注册成功对象存储连通hadoop fs -ls s3a://桶名/正常列出目录交互式查询spark-sql里执行聚合 SQL返回非空结果集结果落盘hadoop fs -ls s3a://桶名/result/目录存在且文件非空表格填满之后答辩的讲法就有了骨架。我一般会按三段讲第一段讲资源规划为什么是四台、为什么同子网、为什么桶要选并行文件系统这一段体现的是设计能力而不是操作能力第二段讲链路打通从免密互信到 HDFS 到 YARN 到 Spark每一层用什么命令验证过这一段体现的是工程严谨性第三段讲存储计算分离把数据放在对象存储上、用 Spark SQL 直接查说明为什么这种方式比把数据搬进 HDFS 更适合做分析型查询这一段是整个实验里最有含量的部分也是最容易被追问的地方。被追问时最忌讳说教程上就是这么写的。每个参数都要能说出为什么副本数为什么是 3 不是 2hadoop.tmp.dir为什么不能放在系统盘fs.s3a.path.style.access为什么设成 true。答不上来的参数就老老实实说这个值是按默认配的还没深入验证过比硬编一个理由可信得多。还有一个小技巧提前把每个实验的关键截图存成一组命名规范一点比如01-ecs-list、02-hosts、03-jps、04-wordcount、05-spark-ui、06-sql-result。答辩翻页的时候不用现场找临时切控制台去截图很容易在等待加载的几十秒里把节奏打乱。从那以后我每次带人做这类集群实验都会在动手之前先把这张验收清单写出来贴在文档最前面做完一项勾一项绝不允许先跑起来再说。因为集群这东西跑起来和跑对是两回事跑对了和讲得清楚又是两回事。希望帮到你。本文还有配套的精品资源点击获取
