华为云MapReduce服务MRS实战：集群创建、Spark与Hive作业、存算分离、弹性伸缩与成本控制

一、背景：为什么用MRS跑批处理和查询

很多数据分析还停在“单机脚本能跑、人多了就排队”这一步：数据一变大内存不够，任务失败要手工重跑，计算集群和数据堆在同一批磁盘上，扩容要搬数据，不用的时候机器还在计费。自己在云主机里搭 Hadoop 生态也能用，但要自己盯主节点、资源队列、组件版本和磁盘容量，出了问题排查链路很长。

华为云 MapReduce 服务（下文简称 MRS）把 Hadoop、Spark、Hive 等组件收成可开通的托管集群：先选定组件和节点角色，再把作业提交到集群里跑，数据既可以放在集群本地存储，也可以放到对象存储上做存算分离。它和自己在云主机里装发行版不是一回事——后者操作系统、组件升级和故障恢复都要自己兜底，MRS 把集群生命周期、组件部署和弹性节点收进控制台。本文按“认清角色 → 创建集群 → 跑 Spark 与 Hive 作业 → 落地存算分离 → 弹性伸缩和成本”的顺序实操一遍。菜单名称以控制台当前版本为准。

二、核心概念

集群：一次开通对应一套可提交作业的计算环境，包含管理节点、数据或核心节点、任务节点，以及选中的组件。集群名称建议带环境和用途，例如 mrs-prod-batch。

管理节点：承载集群管理、资源调度和组件主进程，一般不拿来扛大批量计算。这类节点要稳定，不要为了省钱随便停掉。

核心节点：既参与计算，也常常承担集群内的数据存储。如果数据主要放在核心节点磁盘上，缩容或下线前必须先把数据迁走，否则会丢数据。

任务节点：主要承担计算，不持久保存业务数据。适合拿来做弹性伸缩：高峰加上去，低谷再减下来。

作业：一次提交给集群执行的 Spark、Hive 或其他组件任务。程序位置记为 <主程序文件>，主类记为 <主类名>，输入路径记为 <输入路径>，输出路径记为 <输出路径>。

存算分离：数据放在对象存储或其他共享存储上，集群主要提供计算。集群可以按需扩缩甚至在空闲时停掉，数据不必跟着计算节点一起买。对象存储路径记为 <对象存储路径>。

弹性伸缩：按策略增加或减少任务节点。触发条件可以是资源队列积压、定时高峰，或两者结合。伸缩规则要写清楚最小和最大节点数，避免一次性加得太多。

三、创建集群

进入 MRS 控制台，选择与业务相同的区域后创建集群：

1. 选择集群版本和需要的组件。只勾选真正要用的，例如需要批处理就带上 Spark，需要交互查询再带上 Hive，不要把用不到的组件一次性开齐，以免浪费内存和管理复杂度；
2. 填写集群名称，例如 mrs-dev-analysis，测试和生产不要混在同一套集群里；
3. 规划节点角色和规格。管理节点保证稳定，核心节点按是否在集群内留数据来定磁盘，任务节点按峰值计算来定数量上限；
4. 配置网络：虚拟私有云、子网和安全组。安全组只放行运维跳板和必要的组件端口，不要对全部地址完全放开；
5. 配置登录方式与权限。管理员用户记为 <管理员用户>，密钥或密码只通过安全渠道保管，不要写进作业参数或公开文档；
6. 确定数据落在哪里：如果走存算分离，提前准备好 <对象存储路径> 和可读写的委托或访问凭证，不要把长期密钥写进提交界面的明文参数；
7. 打开必要的可靠性和巡检选项，确认计费方式后提交，等待集群状态变为运行中，再记录访问入口和资源队列名称。

创建阶段最容易忽略的是节点角色和网络。集群显示“运行中”只说明组件起来了，不代表你的作业账号有权读写 <对象存储路径>，也不代表业务网段能连上提交入口。

测试环境可以先用较小规格、较少任务节点，把作业提交、日志查看和权限跑通，再在生产按峰值放大。生产集群的管理节点不要用过于拮据的规格，管理进程不稳，后面所有作业都会受影响。

如果团队里已有统一的虚拟私有云规划，集群要放进与数据源、调度机能互通的网段，而不是另开一套孤立网络再补一堆对等连接。安全组入方向按角色收口：提交作业的机器访问提交入口，运维跳板访问管理入口，分析师如果走 Hive 查询，也只开放查询入口，不要把所有节点的所有端口都暴露给同一条规则。

开通前还要确认配额是否够：节点数量、CPU、内存和磁盘都可能被账号配额挡住。与其创建到一半失败，不如先在控制台或配额页面看清楚，再点提交。磁盘类型和容量按数据落盘方式选择：数据主要在对象存储上时，核心节点磁盘以组件运行和日志为主，不必按全量业务数据来买；数据要落在集群内时，磁盘一定要留出增长、中间结果和修复用的余量。

四、提交 Spark 作业

集群运行后，先用一个小数据集把提交路径跑通，再上正式数据。不要第一次就把全量历史数据打进去，失败时既难看日志，也浪费计算时长。

在控制台创建 Spark 作业时，按下面的顺序核对：

1. 选择作业类型为 Spark，填写作业名称，名称里带上数据和用途，例如 spark-order-daily，方便和日志对应；
2. 指定程序位置为 <主程序文件>，主类为 <主类名>，不要在不同环境里引用到旧文件；
3. 程序参数里传入输入和输出，例如 --input <输入路径> --output <输出路径>，不要在程序里写死某台机器上的本地目录；
4. 配置执行器内存、执行器个数、驱动内存等资源。先用接近调试时的小规格跑通，再按数据量上调；
5. 选择资源队列和执行用户。执行用户要对 <输入路径> 可读、对 <输出路径> 可写；
6. 提交后立即看作业状态和日志：是否找到主类、是否读到数据、是否在写输出、内存是否不够。

一种比较稳妥的参数写法如下，路径全部用占位符：

作业类型 = Spark
作业名称 = spark-order-daily
主程序文件 = <主程序文件>
主类名 = <主类名>
程序参数 = --input <输入路径> --output <输出路径>
执行器内存 = 4g
执行器个数 = 2
驱动内存 = 2g
资源队列 = <队列名>
执行用户 = <作业用户>

常见失败原因包括：<主程序文件> 路径或权限不对、主类名写错、输出目录已经存在且程序没有处理好覆盖、输入分区为空、执行器内存不足、以及对象存储的委托未授权。先读日志再加资源，不要一失败就加倍节点。

作业成功后，先抽查 <输出路径> 的分区和记录数，再交给下游。需要重跑某一天时，输出路径按日期分区，例如在 <输出路径> 下按统计日分目录，避免一次重跑覆盖全部历史结果。长时间作业要能从上游分区断点继续，而不是每次从头扫全量。

如果用 Spark SQL 做汇总，语句里不要写死库地址，把表位置放到事先建好的库表上。示例只演示字段逻辑，不出现具体文件名或访问地址：

INSERT OVERWRITE TABLE 日汇总
SELECT
  统计日,
  COUNT(1) AS 订单数,
  SUM(金额) AS 金额合计
FROM 订单明细
WHERE 统计日 = '<统计日>'
GROUP BY 统计日

对比实验时，一次只改少量参数，作业名称带上参数摘要，方便事后对照。不要用同一个作业名称反复覆盖，出了问题会找不到到底是哪一次提交。

提交前还可以先在小范围做语法校验，确认字段名、分区条件和输出表一致。校验用的数据要覆盖空分区、重复主键和金额为空这些边界，不然正式作业跑了很久才在写结果时失败。资源方面优先观察执行器内存和并行度是否匹配分区数：并行度过大，启动开销会很明显；过小则少数任务拖住整个作业。调整时一次只改一类参数，并在作业说明里记下这次改了什么。

日志要按作业名称和提交时间保留一段时间，至少能回答三个问题：这次读了哪些分区、每个阶段花了多久、失败时卡在读数据、计算还是写结果。只有状态码、没有这些信息，下次还是只能盲猜。若同一作业昨天成功、今天失败，先对比输入分区是否变大、输出路径是否被别人占用、集群是否正在缩容，再怀疑程序本身。

五、用 Hive 做查询与表管理

Hive 适合把已经落好的数据登记成表，供分析和作业复用。表位置同样建议指向 <对象存储路径> 或统一的数据目录，而不是某个会随节点替换而消失的本地盘。

建表时把分区和格式约定写清楚：

CREATE TABLE 日汇总 (
  统计日 STRING,
  订单数 BIGINT,
  金额合计 DECIMAL
)
PARTITIONED BY (业务线 STRING)
STORED AS PARQUET
LOCATION '<表数据路径>'

使用上有几条建议：

1. 明细表和汇总表分开，不要把临时查询结果直接写进正式明细表；
2. 分区字段选查询几乎总会带上的维度，例如统计日，避免每次全表扫描；
3. 新增分区后确认分区目录和元数据一致，出现“表能看到、路径是空的”时先核对此项；
4. 查询账号与作业账号权限分离，分析人员可以读汇总表，不必拥有改表结构或删分区的权限；
5. 大查询先在抽样或单分区上试，确认条件写对再放到全量。

从客户端查询时，连接信息一律用占位符：

服务地址 = <Hive服务地址>
端口 = <端口>
数据库 = <数据库名>
用户 = <查询用户>

不要把真实地址、账号和密码写进博客、截图或代码仓库。连不上时按顺序查：集群组件是否健康、网络和安全组是否放行 <端口>、用户是否有库表权限、表路径是否可读。不要一连不上就重建集群。

Hive 作业也可以在控制台以脚本方式提交，适合定时汇总。脚本同样不要写死地址，只引用库表名和分区值。调度时间要避开集群弹性缩容的窗口，以及对象存储侧可能的维护窗口，以免任务在节点增减过程中失败。若同一张表既有 Spark 作业在写、又有人在 Hive 里改分区，要约定好写入窗口，避免一边写一边被删分区。

元数据要有备份和变更记录。误删一张外部表时，如果数据还在 <表数据路径>，通常可以按同样的位置重建表并把分区重新登记上；如果建成了内部表又随手删除，数据可能一起被清掉。创建前先分清表是只登记位置，还是连数据生命周期一起交给组件管理。对生产表，删除和移动分区最好走工单或双人确认，而不是在查询窗口里直接执行。

六、存算分离怎么落地

存算分离的目标很简单：数据活得比集群久，计算按需要出现。适合批量入仓、定时汇总、按需分析和开发测试集群。也适合把同一份数据交给不同规模的集群或不同作业引擎读取，而不用把数据复制到每套集群的本地盘。

落地时按这条线来：

1. 约定统一的 <对象存储路径> 分层，例如原始数据、清洗后数据和汇总数据分开目录，互不覆盖；
2. 集群创建或作业提交时配置对对象存储的访问，使用委托或临时凭证，不把长期密钥写进作业参数；
3. 建表和作业的输入输出都指向这些目录，程序里不再假设某个核心节点本地盘永远在；
4. 核心节点磁盘只保留组件运行、日志和必要的本地临时文件，不把正式数据只放在这些盘上；
5. 测试集群用完可以缩小甚至停止，只要对象存储里的数据和元数据约定还在，再拉起一套计算就能接上。

要注意几件事。第一，临时文件和正式结果不要混在同一目录，作业失败留下的半成品会干扰下次重跑。第二，对象存储的权限要按目录收口，开发、生产和备份路径不要共用同一个可写凭证。第三，小文件过多会拖慢作业，入仓时尽量按分区合并，而不是每天留下大量细碎文件。第四，删除集群不会自动清理对象存储，不用的数据要有生命周期策略，否则存储费用会持续增加。

如果短期内还做不到完全分离，至少让任务节点不保存业务数据，先把弹性计算和数据安全分开。等路径和权限稳定后，再把核心节点上的历史数据迁到 <对象存储路径>。迁移过程中保留校验：记录数、分区数和抽样字段都要对上，再切换作业的输入路径。切换时最好先让新路径走只读对照，确认结果一致后再把写入也切过去，避免两套目录长期同时写、事后对不上。

元数据也不要只放在某一套即将拆除的测试集群里。库表位置、分区规则和字段含义应能在集群重建后恢复，否则计算集群可以很快开通，分析师却会面对“表不见了”。把建表语句和分层约定一起纳入变更记录，和作业程序同样看待。

七、弹性伸缩与成本控制

MRS 的费用通常来自三块：一直开着的管理节点和核心节点、高峰时加上去却忘了减下来的任务节点、以及对象存储里越积越多的数据和中间结果。弹性伸缩能削减第二块，但规则写不好也会在高峰时加不上去，或在作业还没结束时把节点减掉。

设置弹性伸缩时建议：

1. 只对任务节点做自动增减，不要对管理节点做自动销毁；
2. 明确最小节点数和最大节点数。最小要能撑住常规作业，最大要能挡住误触发和预算；
3. 用资源队列积压作为加节点的条件，用持续空闲作为减节点的条件，并设置冷却时间，避免节点频繁上下线；
4. 若业务有固定高峰，可叠加定时规则，在高峰前加好节点，在作业窗口结束后再降下来；
5. 缩容时避开仍在跑的大作业，或把大作业指定到稳定的资源队列，防止任务被中途打断。

成本上还可以做这些事：

1. 开发测试集群下班后停止或缩到最小，数据以 <对象存储路径> 为准，不要靠集群本地盘“先放着”；
2. 作业先在小数据、小规格上调通，再按分区扩到全量，避免用生产规格反复试错；
3. 队列和优先级分开，临时查询不要把定时作业的资源挤光，反过来也不要用定时作业占满全部临时查询能力；
4. 定期清理失败作业的输出目录、过期临时数据和无用的历史分区；
5. 账单要能对应到集群名称和作业高峰，说不清费用来源时，先看任务节点是否整周停在上限。

把“集群是否在跑、任务节点是否停在上限、存储里有哪些过期分区”做成每周核对项，比只在账单出来后找原因更有效。多人共用同一套集群时，约定作业命名、队列和负责人，避免有人提交了长期占用资源的测试作业却没人认领。

还可以给每个项目设一个简单上限：本周计算时长和存储增量大概是多少，超出就先停低优先级的测试作业，而不是继续往上加节点。包周期和按需可以搭配：长期存在的管理节点和少量核心节点用更稳定的计费方式，任务节点按需弹性。具体资费以控制台当时展示为准，这里只强调“常驻部分要少而稳，弹性部分要有上限”。

如果某段时间没有作业，除了缩任务节点，也要评估整集群是否还需要保持运行。完全走存算分离的分析集群，空闲几天就停掉，往往比留着最小节点更省。再次启用时，先检查组件健康、对象存储权限和表位置，再提交正式作业，不要假设停了很久的集群能立刻接住高峰。

八、小结

MRS 的关键不是把集群创建页面点一遍，而是三件事能够重复：按角色建好稳定的管理和核心节点、用 <主程序文件> 和明确的输入输出路径提交 Spark 与 Hive 作业、把正式数据放在 <对象存储路径> 上并用任务节点做弹性伸缩。先把路径、队列、权限和伸缩上下限写在一张表上，再跑作业，这样比在单机里处理大数据更易交接，也比让高峰规格整周挂着更省钱。

上线后还要关注作业成功率、排队时长、任务节点利用率和存储增量。若新作业导致队列长期积压，要能分清是数据量变了、程序变慢了，还是伸缩规则没有及时加节点。发布变更前把程序版本、数据分区和输出表的对应关系写进记录，避免出问题后找不到是哪一次提交写坏了分区。路径、地址和凭证只放在内部配置里，不要出现在公开博客或代码仓库中。