资讯动态

云上大数据实验全链路:从ECS、OBS到Hadoop与Spark交互式查询

发布时间:2026/10/27 10:43:37 来源:尧图企业网站定制
简介这份华为云大数据实验报告面向高校大数据、云计算相关课程的学习者与实验者围绕在华为云上部署和管理大数据平台的关键技术展开帮助读者打通从云主机到云服务、再到一站式大数据方案的实践路径。压缩包内共1个docx文档约4.36MB以图文实验记录形式呈现内容涵盖Hadoop集群搭建、OBS对象存储配置、节点间SSH通信、Spark集群部署及交互式查询等环节。报告按实验一云主机实现大数据、实验二云服务实现大数据、综合实验一BigData Pro、综合实验四大数据交互式查询四个模块组织目录层级清晰便于按实验顺序对照操作与复盘。目前已有2490人学习下载适合需要完成课程实验、理解云上大数据处理流程或准备相关实践考核的读者参考可据此掌握集群搭建、服务配置与查询分析的基本技能。1. 云上大数据实验的全景地图从 ECS 到交互式查询很多人第一次接触云上大数据实验会把它当成一堆互不相干的命令买机器、传密钥、改 hosts、跑 wordcount做完就忘。真正梳理下来会发现这四个实验其实是一条完整的链路——先用弹性云服务器 ECS 把 Hadoop 集群立起来再用对象存储 OBS 把存储从计算里剥出去接着用 BigData Pro 把 Hadoop 与 Spark 两套集群拼成一套可协同的环境最后用交互式查询把前面攒下的数据真正查出来。这条链路对应的是「计算资源 → 存储资源 → 集群协同 → 数据消费」四层任何一层没打通后面的实验都会卡住。这份实验报告的价值就在于它把四层都走了一遍适合正在系统学云上大数据部署、或者准备实验考核的人拿来当复习地图重点不在背命令而在搞清楚每一步为什么必须这么做。2. 云主机与集群底座ECS、OBS 与 Hadoop 的搭建要点2.1 弹性云服务器与对象存储的准备工作整个实验的起点是资源准备这一步看起来最没技术含量却决定了后面所有节点能不能互相看见。实验里先购买弹性云服务器 ECS再购买对象存储服务 OBS并且专门创建了一个并行文件系统。这里有个容易被忽略的细节OBS 不是普通桶并行文件系统才是给大数据场景用的它允许 Hadoop 通过特定接口把对象存储当成文件系统挂载从而把存储和计算解耦。报告里给出的访问域名是obs.cn-north-4.myhuaweicloud.com双栈地址是obs.dualstack.cn-north-4.myhuaweicloud.com这两个地址在配置 Hadoop 连接 OBS 时必须对得上写错一个字母就是连接超时。访问凭证来自操作完成后下载的credentials.csv里面包含 User Name、Access Key Id、Secret Access Key 三列。报告里出现的形如roy_yuki,S8RSFKYBTOSPA9YX92XB,...的记录就是这套凭证的样例格式。复习时要记住AK/SK 是成对使用的Access Key Id 相当于用户名Secret Access Key 相当于密码任何一端泄露都等于把桶交出去。实验里还出现了「新增 User Name、Access Key Id、Secret Access Key」的操作说明凭证是可以按用户维度管理的这在多节点共享存储时很关键——不要让所有节点共用一个高权限密钥。提示凭证文件下载后只出现一次Secret Access Key 无法再次查看实验过程中要第一时间保存到本地不要留在节点上明文存放。节点规划上报告用了 node1 到 node4 四台机器并在/etc/hosts里写入了固定映射形如# /etc/hosts 片段四台节点统一写入保证主机名可解析 192.168.0.10 ecs-ca89-0001 ecs-ca89-0001 192.168.0.53 ecs-ca89-0002 ecs-ca89-0002 192.168.0.169 ecs-ca89-0003 ecs-ca89-0003 192.168.0.77 ecs-ca89-0004 ecs-ca89-0004这段配置的作用是让集群内部用主机名互相访问而不是记 IP。参数说明第一列是内网地址第二、三列是主机名与别名四台机器必须写成完全一致的内容否则会出现「node1 能 ping 通 node2、node2 却解析不了 node1」的单向故障。很多实验卡在启动 DataNode 时只起来一半根因就是 hosts 没对齐。2.2 节点互信与基础环境配置Hadoop 集群启动时主节点需要免密登录到所有从节点去拉起进程所以 SSH 互信是硬门槛。报告的做法是每个节点执行cat /root/.ssh/id_rsa.pub拿到公钥再把四台节点的公钥汇总到同一个文件里分别写入各节点的authorized_keys。公钥内容形如ssh-rsaAAAAB3NzaC1yc2E...rootecs-ca89-0001注意这里公钥和注释之间没有空格是排版问题实际写入时要保证ssh-rsa与密钥体之间有空格否则认证直接失败。汇总完成后在 node1 到 node4 上分别执行ssh node1、ssh node2等命令第一次会提示确认指纹输入 yes 后应当无需密码直接进入。报告里明确写了「确保能够无密码跳转到目的节点」这一步是后面所有远程分发和启动脚本的前提。复习时可以把互信检查做成一个固定动作# 在任意节点上批量验证互信全部返回主机名才算通过 for n in node1 node2 node3 node4; do ssh -o BatchModeyes $n hostname doneBatchModeyes的作用是禁止交互式输入密码一旦互信没配好会立刻报错而不是卡住等输入适合用来做批量自检。基础环境还包括安装 OpenJDK 和关闭防火墙报告里把这两步放在集群搭建之前顺序不能反——JDK 没装好Hadoop 的启动脚本会直接报找不到 java防火墙没关节点间的 RPC 端口会被拦表现为进程起来了但互相连不上。2.3 Hadoop 集群搭建与 wordcount 验证环境就绪后进入正式搭建。报告在 node1 上在线下载安装包配置完成后启动集群最后用 hadoop wordcount 做端到端验证。wordcount 之所以成为标准验证用例是因为它同时压到了 HDFS 读写和 MapReduce 调度两条链路输入文件要先上传到 HDFSMap 阶段分片读取Reduce 阶段汇总输出任何一环配置错误都会在作业日志里暴露出来。实验里还专门做了「测试与 OBS 互联」也就是让 Hadoop 直接读写 OBS 上的数据这一步是把存储层从本地磁盘换成对象存储的关键验证。复习这个模块时建议把「集群能起来」和「集群能算」分开看。能起来看的是进程和端口能算看的是作业是否成功。报告里 wordcount 成功实现说明 NameNode、DataNode、ResourceManager、NodeManager 都正常且 OBS 的连接配置也生效了。最容易翻车的地方是 OBS 的 endpoint 和 AK/SK 写错报错往往是一长串连接异常看不出根因所以要养成先单独验证 OBS 连通性、再跑作业的习惯。3. 云服务化的大数据BigData Pro 与 Spark 集群协同3.1 BigData Pro 的定位与 ECS、OBS 的衔接综合实验一引入的 BigData Pro 是一站式大数据解决方案它的意义在于把前面手工搭的那套东西产品化。报告里的顺序是先准备云环境、购买 ECS、购买 OBS再搭建 Hadoop 集群、搭建 Spark 集群。这个顺序说明 BigData Pro 并不是替代手工搭建而是在同样的资源底座上把 Hadoop 和 Spark 两套计算框架组织到一起。复习时要理解三者的分工ECS 提供算力OBS 提供持久化存储BigData Pro 负责把集群管理和框架集成包起来让使用者不用每台机器手动装一遍。这里有个容易混淆的点实验一里 OBS 是用来给 Hadoop 做外部存储的到了 BigData Pro 里 OBS 依然是存储底座但角色更明确——它是集群之外独立存在的一层计算节点可以随时增减数据不动。这种存算分离的思路是云上大数据和传统本地集群最大的差别也是复习时最该抓住的主线。报告里 1.2 购买 ECS、1.3 购买 OBS、1.3.1 选取对象存储服务 OBS、创建并行文件系统、创建完成进入桶这一串步骤本质上就是在把存储层先固定下来。3.2 Spark 集群搭建与 Hadoop 的协同关系Spark 集群搭建排在 Hadoop 集群之后这个顺序不是随意的。Spark 本身可以独立运行但在大数据实验场景里它通常依赖 Hadoop 的 HDFS 或 OBS 作为数据源同时复用 YARN 做资源调度。报告里把 Spark 集群搭建放在「测试与 OBS 互联」之后说明此时存储链路已经验证通过Spark 接进来就能直接读数据。复习时要能说清楚两者的关系Hadoop 提供存储和批处理底座Spark 提供更快的内存计算二者共享同一份数据而不是各存一份。配置 Spark 时最常改的是spark-env.sh里的环境变量典型写法如下# spark-env.sh 关键项指向已装好的 JDK 与 Hadoop 配置 export JAVA_HOME/usr/lib/jvm/java-openjdk export HADOOP_CONF_DIR/usr/local/hadoop/etc/hadoop export SPARK_MASTER_HOSTnode1 export SPARK_WORKER_MEMORY2g参数说明JAVA_HOME必须和 Hadoop 用的是同一个 JDK版本不一致会出现类加载冲突HADOOP_CONF_DIR让 Spark 复用 Hadoop 的 core-site 和 hdfs-site 配置从而直接识别 OBS 的访问参数SPARK_MASTER_HOST指定主节点写主机名而不是 IP 更稳SPARK_WORKER_MEMORY按实际机器内存调设太大在实验环境里容易把节点压垮。这几项配错表现是 Spark 能启动但提交作业时报找不到文件系统或连接被拒。3.3 云服务化带来的复习重点变化把实验一和综合实验一放在一起看会发现复习重点从「怎么装」转向了「怎么连」。手工搭 Hadoop 时关注的是配置文件路径、进程是否起来到了 BigData Pro 阶段关注的是 ECS、OBS、Hadoop、Spark 四者之间的凭证、地址、端口是否对齐。报告里反复出现的 endpoint、AK/SK、hosts 映射本质上都是连接信息。复习时建议把每个组件的「输入连接信息」和「输出连接信息」列成一张表比死记命令有效得多。注意云服务化之后很多配置项由平台托管但底层仍然是同一套 Hadoop 与 Spark实验报告里手工搭建的步骤不能跳过否则遇到连接类报错时无从排查。4. 交互式查询把数据真正用起来的一步4.1 交互式查询在整条链路中的位置综合实验四是大数据交互式查询报告提到可能使用 Spark SQL 或 Flink SQL 这类工具对大规模数据做快速分析和探索内容包括创建数据表、编写 SQL 查询、运行复杂分析任务并实时查看结果。放在整条链路里看这一步是数据消费层——前面三章解决的是「数据存得下、算得动」这一章解决的是「查得快、看得懂」。复习时要把交互式查询和批处理区分开wordcount 是提交作业等结果交互式查询是低延迟地反复试探数据对响应时间敏感。从技术栈看交互式查询依赖前面搭好的 Spark 集群和 OBS 上的数据。表通常建在 OBS 路径之上查询时由 Spark SQL 解析成执行计划再分发到集群执行。报告里没有给出具体 SQL但复习时可以按「建表 → 导入 → 查询 → 验证」四步来准备建表时要指定存储路径和格式导入时确认数据确实落在 OBS 上查询时先用简单聚合验证连通再上复杂分析。4.2 查询实验的复习抓手交互式查询最容易出问题的地方不在 SQL 语法而在元数据和权限。表建在 OBS 上时Spark 需要能读到对应路径AK/SK 或委托权限没配好查询会报权限拒绝而不是语法错误。另一个抓手是数据格式报告没有展开但复习时要清楚文本格式易读但慢列式格式适合分析型查询实验环境里通常先用简单格式跑通再考虑优化。把这两点抓住交互式查询这一章就不会只剩「跑过一条 SQL」的印象。5. 易错点排查四个实验里最容易翻车的地方5.1 凭证与地址类错误易漏点一AK/SK 与 endpoint 不匹配。为什么漏——凭证是从credentials.csv里抄的地址是从桶页面看的两处来源不同抄错一位很难肉眼发现。怎么补——把 endpoint、AK、SK 三项写进一个临时配置文件先用最简单的命令验证连通再往 Hadoop 或 Spark 里填。易漏点二hosts 映射四台机器不一致。为什么漏——每台机器单独编辑容易漏行或写错别名。怎么补——在一台机器上写好完整内容用 scp 分发到其余节点分发后逐台cat确认。5.2 互信与防火墙类错误易漏点三公钥汇总时格式被破坏。为什么漏——复制粘贴时换行或空格丢失ssh-rsa和密钥体粘在一起。怎么补——用ssh-keygen -l -f校验每个公钥文件格式不对会直接报错比等到登录失败再查快得多。易漏点四防火墙关了但安全组没放行。为什么漏——实验报告强调关闭节点内防火墙容易以为网络全通。怎么补——云上还有一层安全组规则节点间 RPC 端口要在安全组里放行排查时先看安全组再看系统防火墙。5.3 集群协同类错误易漏点五Spark 与 Hadoop 的 JDK 版本不一致。为什么漏——两套环境分开安装各自用了不同的 OpenJDK。怎么补——统一JAVA_HOME在 Spark 提交作业前先echo $JAVA_HOME和 Hadoop 节点对比不一致就改spark-env.sh。6. 复习清单按链路自检而不是按命令背复习这份实验报告最有效的方式不是把命令从头敲一遍而是按「资源 → 存储 → 集群 → 查询」四条链路做自检。下面这张表可以直接当查漏补缺的清单用每一行对应一个必须能独立说清楚的点说不清就回到对应章节补。链路环节自检问题通过标准资源准备ECS 与 OBS 是否都已创建并行文件系统是否建好桶可访问endpoint 可解析凭证管理AK/SK 是否成对保存是否按用户区分能用凭证独立访问 OBS节点基础hosts 是否四台一致JDK 是否统一主机名互 ping 通java 版本一致节点互信四台公钥是否汇总免密是否双向批量 ssh 全部返回主机名Hadoop集群进程是否齐全wordcount 是否成功作业输出正确计数OBS 互联Hadoop 能否直接读写 OBS 路径读写无权限与连接报错Spark环境变量是否指向同一 JDK 与 Hadoop 配置提交作业能读到 OBS 数据交互式查询表能否建在 OBS 上并查出结果简单聚合返回正确数据这张表的使用方法是逐行过任何一行卡住就停下来定位不要跳过去继续往下做因为后面的环节都依赖前面的连通性。梳理下来会发现四个实验真正难的不是某个命令而是连接信息的对齐——endpoint、AK/SK、hosts、JAVA_HOME 这几项只要有一处不一致表现出的报错往往和根因隔了好几层这也是血泪经验里最常见的一类翻车。从那以后我每次做这类云上集群实验都会在动手前先把连接信息表填完跑完一个环节就回到表里打勾而不是等最后一起验证。这个习惯让我少走了很多「进程都起着但就是算不出结果」的弯路。希望这份梳理能帮到你把四个实验当成一条链路来复习而不是四份互不相干的报告。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑