简介这是一份华为云大数据实验报告hhu面向需要系统掌握云上大数据部署的高校学生、实验课学习者及备考华为云认证的入门人群完整浓缩了云主机与云服务两条实践路径。报告收录实验一至实验四基于ECS弹性云服务器和OBS对象存储搭建Hadoop集群涉及访问密钥配置、SSH节点互信、防火墙关闭、OpenJDK安装等关键环节进一步使用华为云服务完成数据存储与分析并在BigData Pro中部署Hadoop/Spark协同集群最后借助交互式查询工具开展大规模数据探索。资源仅1个docx文档压缩包大小4.36MB内容按实验目录组织含详细的命令记录、配置截图与验证过程读者可对照步骤自行复现。已有2368人学习下载适合作为实验参考、考前梳理或报告撰写的落地模板。1. 华为云大数据实验报告先搞清楚这门实验到底在做什么很多课程实验和入职练手项目都会选“华为云大数据”作为题目但真正动手的人往往卡在同一个地方云平台上的组件太多MRS、OBS、DLI、DWS 混在一起不知道哪个是实验主线也不知道最后交上去的报告该长什么样。这篇笔记想讲清楚的就是一条能复现的华为云大数据实验路径——从创建对象存储桶开始到拉起一个 MRS 集群把数据传上去用 Hive 建表、用 Spark SQL 做分析最后产出一份能通过验收的实验报告。它适合正在写课程报告的学生也适合想快速建立华为云大数据全链路认知的开发者整条链路做完你手里的不是一堆截图而是一套别人照着能做出来的方案。2. 实验前先把环境铺好账号、OBS桶与MRS集群的参数选型2.1 大数据实验的常见形态离线分析、实时流处理和数据仓库三类方向怎么选拿到“华为云大数据”这个题目第一件事不是急着点“创建集群”而是先把实验形态定下来。华为云上常见的大数据实验方向大致有三类离线批处理、实时流处理、数据仓库分析。离线批处理的主线是 OBS 存数据、MRS 跑 Hive/Spark 作业优点是链路完整、步骤直观、每一步都能截图作为报告素材实时流处理要接数据接入服务涉及 Kafka 和 Flink 的配合实验周期长而且流式任务的排队和资源占用对初学阶段不太友好数据仓库方向偏 SQL 建模和查询调优如果课程要求里没有明确点出“数仓建模”容易把报告写成数据库作业反而偏离大数据平台实验的本意。我一般会建议实验者优先选离线批处理这条线理由很朴素第一MRS 集群里 Hive 和 Spark 是开箱即用的不需要自己搭建分布式环境第二离线的数据链路是“上传 → 建表 → 分析 → 取结果”每一步的输入输出都是可见的写报告时有天然的行文顺序第三成本可控按需计费跑一两个小时就能释放。实时流处理和数仓建模作为“进阶对比”写进报告的展望部分即可不必作为主线。2.2 创建OBS桶存储路径规划与权限绑定的一次性正确做法OBS 是整个实验的数据底座它的配置失误往往会在后面集群作业阶段集中爆发。创建桶时有几个选项必须一次选对。区域必须和后续的 MRS 集群在同一区域否则跨区域访问会产生额外流量费而且延迟明显变高桶的存储类别选“标准存储”不要贪便宜选“低频访问存储”因为实验数据会被反复读取低频存储每次读都有取回费用桶策略保持“私有读写”权限统一交给委托去控制而不是直接把桶开放成公共读。# 通过华为云命令行工具检查桶是否创建成功 hcloud OBS ListBuckets --region cn-north-4这段命令用于确认桶在指定区域下可见输出的桶列表里应该能看到刚创建的那个名称。如果列表为空优先检查命令行工具的账号是否绑定了该区域的访问权限而不是怀疑桶创建失败。创建桶时还要顺手规划好内部路径常见的做法是建三个前缀data/raw放原始上传文件data/clean放清洗后的数据result放分析结果。这样后面 Hive 建表时外部表的位置直接指向data/clean分析结果写到result层次清楚报告里画数据流向图也省事。2.3 MRS集群创建三个必调参数与计费模式的关键判断MRS 集群是实验的“计算大脑”参数选型的核心不是追求高配置而是让实验在合理时间内跑完。创建集群时计费模式选“按需计费”不要选包年包月实验做完立即释放成本通常控制在几十元以内。集群类型选“分析集群”组件勾选 Hadoop、Hive、Spark这三个是离线链路的主力不需要勾选 Flink、Kafka、HBase避免集群启动时做多余的健康检查、延长“启动中”的时间。规格选择上三个参数最关键。一是分析节点的实例规格选通用型即可4 核 8G 起步数据集在几百 MB 级别时 4 核 8G 完全够用二是 Core 节点数量建议 2 到 3 个太少会导致 Hive 的 Map 端并发上不来查询时明显卡顿三是数据盘类型选通用型 SSD容量 100G 足够不要选高IO型实验数据量根本到不了那个吞吐需求。这里还有一个玄学坑同一规格在不同可用区的资源池占用情况不一样如果集群一直卡在“启动中”换个可用区重建往往就好了后面避坑章节会展开讲。表格对比一下三个方向的选型理由实验方向核心服务适合报告的程度成本区间按需上手门槛离线批处理OBS MRS Hive/Spark高链路完整可截图较低低实时流处理数据接入 MRS-Flink中调试耗时较高高数据仓库DWS SQL中偏数据库应用中等中3. 把数据送进云数据格式选择、obsutil命令行上传与完整性校验3.1 实验数据该用什么格式CSV、Parquet还是JSON别凭感觉选数据的格式直接影响后续建表和查询效率。很多实验者喜欢直接找一个 JSON 文件上传理由是“JSON 看起来更真实”但在 Hive 里建表时JSON 的嵌套结构解析要写额外的 SerDe实验报告的篇幅会被序列化配置占掉一大块而且嵌套字段的查询语法容易踩坑。相比之下CSV 是最稳的入门格式一行数据对应表里一行记录字段分隔符明确Hive 建表语句直接指定ROW FORMAT DELIMITED FIELDS TERMINATED BY ,就能读它的缺点是没有压缩文件大了之后查询变慢但这正好可以作为实验报告里的“优化对比”素材。Parquet 是进阶选项。如果实验报告想体现“我做了性能对比”可以准备两份数据一份 CSV、一份 Parquet然后在报告里用一条同样 SQL 的查询时间做对比。Parquet 的列式存储和压缩特性在华为云 MRS 上表现稳定用 Spark 读取时能明显感受到扫描速度快。JSON 格式我不建议作为主线它更适合出现在“数据清洗”的章节里作为反面案例——让学生展示嵌套字段如何被解析成本地表。一句话总结主线数据用 CSV对比实验用 ParquetJSON 作为清洗练习材料。3.2 用obsutil命令行批量上传数据并校验完整性数据文件准备好之后用浏览器在 OBS 控制台挨个上传是效率最低的做法。obsutil 是华为云对象存储的命令行工具支持批量上传、增量同步和断点续传是实验场景下最顺手的工具。安装和配置的过程不再赘述重点看上传命令的写法# 先把本地 data/ 目录下所有 csv 文件上传到 obs://bucket-name/data/raw/ obsutil cp ./data/ obs://bucket-name/data/raw/ -r -f -u -t8命令拆开说明-r表示递归上传整个目录-f是强制覆盖同名对象-u是增量上传、只传本地新增或修改过的文件-t8控制并发任务数为 8。批量上传大量小文件时并发数是影响速度的第一因素-t可以按文件数量调整几百个小文件用 8 到 16 的并发比较合适再往上提升有限反而可能触发 OBS 的频率限制。上传完成后用obsutil ls obs://bucket-name/data/raw/ -s查看对象数量和总大小确认与本地一致。# 对比本地文件和 OBS 对象的 MD5确认没有传输损坏 obsutil cp ./data/obs_original.csv obs://bucket-name/temp/check.csv --dryRun--dryRun参数很关键它只做演练、不实际传输文件用于打印将要执行的操作。配合 OBS 控制台里的对象属性查看 ETag可以快速核对文件上传前后是否一致。这个校验动作在实验报告里也很加分属于“过程严谨性”的体现印象很深的是曾经有一次上传后没有校验Hive 建表查询时发现某些行字段错位排查了半天才发现是本地文件在传输前就有损坏从那以后每次上传前先算本地 MD5上传后再对一次基本没再出过数据错乱。3.3 实验数据的字段设计与日期字段的坑数据字段设计决定了建表语句和后续 SQL 的写法。如果实验题目没有指定数据源常见的做法是生成一份销售订单模拟数据字段至少包含订单ID、用户ID、商品ID、订单金额、下单时间。这里有个高频翻车点时间字段的存储格式。很多人把时间直接写成2024-03-01 12:30:45然后在 Hive 里用 STRING 类型存查询时用 LIKE 匹配日期这种写法在数据量小的时候没感觉一旦做聚合分析日期函数的处理就会变得别扭。我一般会在数据准备阶段就把下单时间拆成两个字段一个order_date存日期格式2024-03-01一个order_time存完整时间戳前者用于分区后者用于时间区间分析各司其职。分区字段的格式建议统一用yyyy-MM-dd避免后续动态分区时出现 Hive 无法识别的分区目录名。4. 核心实验操作Hive建表、Spark SQL分析与结果导出的一条链路4.1 Hive分区表建表语句与数据类型选择陷阱数据上传到 OBS 之后需要在 Hive 里建表让数据“可被查询”。建表方式上实验报告场景强烈建议用外部表。内部表和外部表的差别在于内部表删除表时数据文件也会被删外部表只删元数据、数据文件保留。实验场景下数据存在 OBS 里如果误删内部表重新上传数据要花不少时间而外部表能提供一次后悔药。建表语句如下CREATE EXTERNAL TABLE IF NOT EXISTS ods_sales ( order_id STRING, user_id STRING, product_id STRING, amount DECIMAL(10,2), order_date STRING, order_time STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY , STORED AS TEXTFILE LOCATION obs://bucket-name/data/clean/sales;注意几个细节。amount字段用DECIMAL(10,2)而不是 FLOAT 或 DOUBLE因为浮点数在聚合累加时会产生误差用 DECIMAL 能保证报告里的金额汇总结果精确到分。PARTITIONED BY (dt STRING)里的dt是分区列它在逻辑上也是表的一个字段但物理上对应 OBS 路径里的目录层级。数据文件必须放在形如obs://bucket-name/data/clean/sales/dt2024-03-01/这样的子目录下Hive 才能识别分区。如果文件直接放在sales/根目录下查询时用SELECT * FROM ods_sales查不到任何数据这是一类典型的“建表成功但查不到数据”的翻车现场。数据文件放到分区目录后还要执行一次修复命令让 Hive 感知新分区MSCK REPAIR TABLE ods_sales;这一步在实验报告里值得单独提一句因为很多新手在 OBS 上传文件后直接查表发现没有数据就以为是集群坏了。MSCK REPAIR TABLE的机制是扫描表指定路径下的所有子目录把符合分区列值格式的目录注册到元数据中在 MRS 的 Hive 组件里有时还需要配合ALTER TABLE ods_sales ADD PARTITION (dt2024-03-01)手动指定单个分区这取决于你用的是哪种提交方式两种方法在报告中写清楚一种即可。4.2 用Spark SQL做聚合分析并导出结果到OBS数据表建好之后实验的重头戏是分析环节。在华为云 MRS 上跑 Spark 作业有两种常见方式一种是直接用 MRS 控制台的“作业管理”提交 SQL 文件另一种是写好 Scala 或 Python 脚本打 jar 包提交。对于实验报告来说前者更合适因为 SQL 语句可以直接贴在报告里评审人员一眼就能看懂逻辑。下面这条 SQL 完成的事情是统计每个商品在当天订单中的销售总额以及购买用户数并用窗口函数给商品销售额排名。SELECT product_id, dt, total_amount, user_cnt, ROW_NUMBER() OVER (PARTITION BY dt ORDER BY total_amount DESC) AS rank FROM ( SELECT product_id, dt, SUM(amount) AS total_amount, COUNT(DISTINCT user_id) AS user_cnt FROM ods_sales GROUP BY product_id, dt ) t WHERE dt 2024-03-01 ORDER BY rank LIMIT 50;这段 SQL 分两层内层做聚合计算按商品和日期分组算出每个商品当天的总销售额和购买人数外层用窗口函数对同一天内的商品按金额降序排名。窗口函数ROW_NUMBER()在 Spark SQL 中是稳定的不会出现 MySQL 里那种排序并列导致排名跳号的问题。实验报告里建议把底层聚合和上层排名分开截图展示能清楚体现出“先聚合、再排序”的分析思路。Spark 作业的资源配置是报告里容易被追问的点。提交作业时executor 内存、cpu 数量和并行度三个参数是评委最常问的。参考配置如下表参数推荐值说明executor 内存2G 至 4G数据集在几百 MB 时 2G 即可超过 1GB 再往上加executor cpu1 至 2分析型 SQL 吃内存多于吃 CPU并行度与分区数匹配观察 Spark UI 中 Stage 的输入数据量来调整数据集就几十 MB 时给 Spark 配了 8 个 executor 并不会让 SQL 跑得更快反而因为任务调度开销让总耗时增加。我一般先用默认参数跑一遍记录基线时间再调整参数跑第二遍把两个时间都写进报告做对比既体现了调优思路又不会让实验成本失控。结果导出也很关键。分析结果默认打印在控制台日志里实验报告要的是可以反复查看的结果文件。在 Spark SQL 里用INSERT OVERWRITE DIRECTORY或者通过 DataFrame 的write方法把结果写到 OBS 的result路径下# 用 PySpark 将结果 DataFrame 写入 OBS df.write.mode(overwrite) \ .format(csv) \ .option(header, true) \ .option(delimiter, ,) \ .save(obs://bucket-name/result/sales_rank/dt2024-03-01)这里有一个“目录陷阱”save到 OBS 路径时Spark 会认为该路径是表目录如果路径已存在且非空写入会报错。mode(overwrite)处理的是文件冲突但如果目标路径下存在不是 Spark 生成的临时文件仍然可能失败。踩过这个坑之后我的习惯是每次导出前先用obsutil rm obs://bucket-name/result/sales_rank/ -r -f清理目标路径再执行写入保证幂等。5. 华为云大数据实验避坑指南5个高频现场与排查路径5.1 集群创建后一直处于“启动中”进度条卡了大半小时现象新建的分析集群状态停在“启动中”等了半小时还是这个状态。原因通常是三种情况所选可用区的计算资源池不足安全组规则限制了集群节点之间的内部通信或者子网的 DHCP 地址不足。解决路径是先到 VPC 控制台确认安全组的入方向规则是否放通了集群内部通信端口确认配置没问题后最直接的办法是删除集群换一个可用区重新创建多数情况下会恢复正常。值得说明的是集群创建过程中反复“启动中”不会产生额外计费但会占用实验时间所以不要在一个可用区上死磕及时止损换区。5.2 作业提交后秒失败日志里全是权限拒绝现象Hive 查询或 Spark 作业提交后秒失败查看日志看到AccessDenied或NoSuchObject异常。排查后发现是账户的 OBS 委托没有绑定到 MRS 集群导致集群的 ECS 实例没有权限读取桶对象。解决路径是在 MRS 控制台集群详情页的“权限配置”里绑定OBS OperateAccess委托然后在集群的“高级配置”中勾选“让集群拥有 OBS 访问权限”保存后重启作业。另一个隐蔽原因桶策略是私有读写但委托绑定的是子账号而子账号又没有继承桶的读写权限所以一条龙的做法是在 OBS 桶的“策略”里显式添加一条对委托对象的读写授权。5.3 Hive 查询慢得离谱几百万行的表聚合要跑十几分钟现象表数据量不大但同一个GROUP BY查询在 Spark SQL 里几十秒就跑完在 Hive 上却要十几分钟。原因是数据文件数量过多每个文件都很小Map 端启动 task 的调度开销远大于计算开销。解决方法是数据上传前先在本地对 CSV 做合并把几十个 1MB 级别的文件合并成 3 到 5 个几百 MB 的文件如果数据已经在 OBS 上可以用 Hive 的INSERT OVERWRITE ... SELECT配合DISTRIBUTE BY做一次重分区写入来合并小文件。实验报告里把小文件合并前后的查询时间对比放进去比任何文字说明都有说服力。5.4 实验报告写到一半发现集群没关账单超了预算现象实验做完后没有释放集群第二天发现账户余额被扣掉不少。原因是 MRS 按需计费模式下只要集群状态是“运行中”即使没有作业在执行也会按节点规格持续计费。解决方法是给集群设置“空闲自动释放”策略或在实验收尾阶段记得手动释放集群。写报告时也建议把集群的运行时间段和对应费用记录成一个表格既能体现成本意识也能避免被质疑“做完实验不释放资源”。5.5 作业日志里找不到关键报错排查不知道该看哪个日志文件现象Spark 作业失败在 MRS 控制台作业列表里点击“查看日志”只看到一行Application exited with error真正的异常栈看不到。原因是控制台展示的是作业提交器的输出而 Spark 任务的运行日志在 YARN 的 ApplicationMaster 里。解决方法是进入 YARN 的 ResourceManager 界面找到对应 application 的 logs点击stdout和stderr标签页查看完整异常栈如果日志量大先在本地用grep -i exception过滤再定位具体类名。这个习惯很重要——学会看 YARN 日志是华为云大数据实验从“能跑通”迈向“能排查”的分水岭。6. 把实验报告做得像交付物验证方法、成本记录与复盘技巧6.1 验证实验结果的三个手段元数据核对、抽样比对与重跑一致性实验报告最怕的就是只贴结果截图、没有任何验证痕迹。我用过的三个验证手段都可以写进报告作为附件。第一个是元数据核对用SELECT COUNT(*) FROM ods_sales查出的行数与源文件行数比对确认没有数据丢失。第二个是抽样比对在结果表中随机抽 5 条记录与源文件中对应的原始记录手动核对金额计算逻辑确认聚合算法没有偏差。第三个是重跑一致性对同一份结果路径重复执行两次导出任务用diff或 MD5 对比两次文件内容是否一致验证分析过程是否可复现。这三个手段分别对应“数据完整、计算正确、过程稳定”三个维度凑齐了评委就没法从流程上挑毛病。6.2 成本与资源记录把集群费用写进报告实验类报告中成本记录往往被忽略但恰恰是这个细节最能让报告显得专业。记录内容不必复杂一张表格就能说清资源类型、规格、运行时长、按需单价、实际费用。例如分析节点 4 核 8G 一台、Core 节点 4 核 8G 两台运行 2 小时OBS 存储费用按小时计费。把这些数据从费用中心复制出来填进表格再附一句“实验结束后已立即释放集群并删除临时数据”整个实验的闭环感就出来了。我自己给报告补上这部分之后收到的反馈明显从“跑通了”变成“做得很完整”。一个更实际的技巧是把失败过程和调试记录单独写一节。第一次跑实验时因为委托没绑定导致的权限问题我把报错截图、排查步骤、解决命令完整记录下来这比展示十张成功截图更让人信服。很多实验报告“看起来假”就是因为只写了顺利路径把翻车过程写清楚反而说明实验是真实做过的。这是我踩过无数坑之后最想分享的一条习惯报告不是给别人看你的成功而是证明你能在真实约束下解决问题。希望帮到你。本文还有配套的精品资源点击获取
