企业官网建设流程全解析

简介：这是一份华为云大数据实验报告（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型，实验数据量根本到不了那个吞吐需求。这里还有一个玄学坑：同一规格在不同可用区的资源池占用情况不一样，如果集群一直卡在“启动中”，换个可用区重建往往就好了，后面避坑章节会展开讲。

表格对比一下三个方向的选型理由：

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，对比实验用 Parquet，JSON 作为清洗练习材料。

3.2 用obsutil命令行批量上传数据并校验完整性

数据文件准备好之后，用浏览器在 OBS 控制台挨个上传是效率最低的做法。obsutil 是华为云对象存储的命令行工具，支持批量上传、增量同步和断点续传，是实验场景下最顺手的工具。安装和配置的过程不再赘述，重点看上传命令的写法：

# 先把本地 data/ 目录下所有 csv 文件上传到 obs://bucket-name/data/raw/ obsutil cp ./data/ obs://bucket-name/data/raw/ -r -f -u -t=8

命令拆开说明：-r表示递归上传整个目录，-f是强制覆盖同名对象，-u是增量上传、只传本地新增或修改过的文件，-t=8控制并发任务数为 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/dt=2024-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 (dt='2024-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 数量和并行度三个参数是评委最常问的。参考配置如下表：

数据集就几十 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/dt=2024-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 存储费用按小时计费。把这些数据从费用中心复制出来填进表格，再附一句“实验结束后已立即释放集群并删除临时数据”，整个实验的闭环感就出来了。我自己给报告补上这部分之后，收到的反馈明显从“跑通了”变成“做得很完整”。

一个更实际的技巧是：把失败过程和调试记录单独写一节。第一次跑实验时因为委托没绑定导致的权限问题，我把报错截图、排查步骤、解决命令完整记录下来，这比展示十张成功截图更让人信服。很多实验报告“看起来假”，就是因为只写了顺利路径；把翻车过程写清楚，反而说明实验是真实做过的。这是我踩过无数坑之后最想分享的一条习惯：报告不是给别人看你的成功，而是证明你能在真实约束下解决问题。希望帮到你。

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