EMR Serverless Storage：本地盘缓存让Spark成本直降55%

先说说我自己的感受。搞数据平台这么多年，最烦的就是Spark跑批这件事：集群要提前养、内存要反复调、S3请求费像抽血一样一点点流失，等跑批稳定了，运维的活儿还没完。Amazon EMR Serverless Storage 这个新特性，算是把“无服务器Spark+分层存储”这条路彻底打通了，我实际迁移了一个日志ETL作业之后，账单相比传统EMR集群省了接近一半，官网口径更是直接说最高省55%。这篇东西我打算把当时折腾的完整思路、配置步骤、踩坑记录都整理出来，给正在纠结“要不要迁EMR Serverless”的同学一个参考。

先说清楚这个内容到底适合谁：团队正在用Amazon EMR自建集群跑Spark批处理，或者被S3请求费用折腾到怀疑人生，又或者压根不想再管主节点、核心节点、弹性伸缩这些基础设施，那么EMR Serverless Storage值得仔细看一遍。就算是刚接触AWS的朋友，只要对Spark有基本概念，这篇文章也能帮你少走弯路。

1. EMR Serverless Storage 到底解决了什么问题

1.1 传统Spark跑批：钱花在哪了，人累在哪了

先拆一下自建EMR集群的成本结构。假设你按需开一个10节点r5.2xlarge的集群，每节点4 vCPU、16GB内存，按区域价格折合每小时大约3到5美元，一个月跑300小时，光计算费用就是900到1500美元。这还只是“机器开着”的钱，实际跑批期间资源利用率能到70%就算烧高香了，因为Spark作业提交前后有启动和收尾阶段，节点空转是常态，不是你想省就能省的。

第二种成本更隐蔽，就是S3请求费。Spark跑ETL，最典型的就是读取源数据、shuffle中间结果、写最终结果。shuffle这个东西特别讨厌——reduce阶段要从所有mapper节点拉取中间数据，在传统EMR集群里，中间数据先写本地磁盘或内存，然后再网络传输，如果配置不当，大面积shuffle会瞬间打满磁盘IO，而EMR Serverless早期版本因为是无状态的，中间数据被迫落到S3，每次shuffle都是一堆GET/PUT请求，量一大账单立刻起飞。

第三种成本是运维人力。自建集群得盯版本升级、节点故障替换、Spark参数调优、安全组配置、IAM角色。就算任务都跑在EMR上，监控告警、扩容计划、资源争抢这些事也足够让一个数据团队疲于奔命。很多团队嘴上说“我们用Spark很顺利”，实际上日常都在给基础设施“擦屁股”。

1.2 Storage的核心思路：把“中间数据”从S3搬到本地

EMR Serverless Storage的关键变化，是给无服务器计算环境引入了本地磁盘缓存。听起来很基础对吧？但底层逻辑完全是针对上面那些痛点设计的。

传统EMR集群里，Spark的shuffle中间数据可以写本地磁盘，因为节点是固定的、生命周期长。而EMR Serverless的executor是动态创建销毁的，没有固定“本地盘”可以依赖，所以早期架构只能把所有中间数据flush到S3，保证executor哪怕被杀了数据也不丢。这个保守设计换来的是无状态弹性，代价就是shuffle延迟高、S3请求多、存储成本大。

Storage特性做的事情是：在每台计算实例上启用高性能NVMe本地盘，让Spark的shuffle数据、临时文件、部分RDD缓存可以优先写本地，而不是一上来就去S3。这样既保留了无服务器的弹性调度，又让数据在节点生命周期内尽量留在“热区”。从架构上看，数据不再全部走远端对象存储，而是“本地缓存为主，S3兜底”。

那为什么不彻底不用S3？因为本地盘是易失的，executor一旦被回收，上面的shuffle数据就没了，这时候上游必须从S3重新拉取。所以Storage并不是推翻S3，而是把存储分成了“热”“温”“冷”三层，让中间数据这种短生命周期数据尽量留在热层，S3只负责最终落盘和容灾。这个设计跟大数据的cache语义一脉相承，但放在无服务器环境里就是质变。

1.3 55%的成本节省是怎么算出来的

官网能给出55%这个数字，不是拍脑袋。我拆解一下这个数字可能的构成，方便你自己评估迁移收益。

最大的一块，是S3请求费用的消失。以我自己的日志ETL为例，数据量大约每天1.2TB，源文件按小时分片存在S3，SQL里涉及大量join和groupBy，shuffle量很大。之前跑在EMR集群上，每天光S3的GET/PUT/POST请求费用在25到35美元之间浮动，因为shuffle中间数据每次都写到S3，一天下来几十万次请求很正常。迁到EMR Serverless Storage之后，shuffle写S3的路径被本地NVMe盘接管了，S3请求量直接降了90%以上，每天这块成本肉眼可见地掉到5美元以内。

第二块，是集群空转费用。EMR Serverless按任务实际消耗的vCPU和内存计费，没有“集群开着等任务”的概念。传统集群即使凌晨没有作业，或者作业之间有空档，只要机器开着就在烧钱。我那个场景每周作业总时长约35小时，但集群从创建到销毁一共开机190小时，剩下155小时全在空转。Serverless模式下只按任务实际执行时间算，这部分省下来非常夸张。

第三块是存储副本相关的费用。新版Storage特性在上线后，对部分场景移除了数据冗余存储相关的额外计费，这直接影响那些需要大量复用中间结果的作业。如果你的作业大量使用persist(StorageLevel.DISK_ONLY)或checkpoint，这块节省会特别明显。

综合下来，55%这个数字在“重shuffle、多中间结果、作业时间集中但集群必须常开”的场景里完全可以出现。如果你的作业本身就是轻量级的，读一次S3算完就写回，那节省比例会低一些，大概20%到30%。所以迁移之前，先把自己作业的“shuffle体重”摸一遍，再决定是不是值得动手。

2. 存储架构与核心细节拆解

2.1 分层存储：热数据、中间数据、最终数据各归其位

EMR Serverless Storage的存储体系可以理解成三个层级。

第一层是计算节点的本地NVMe盘，这是Storage特性的核心。你可以把它当成Spark的专用暂存区：shuffle中间文件、sort的溢出文件、序列化以后的临时结果，都优先往这里塞。这一层的特征是快、贵、易失，生命周期跟executor一致，作业结束或者节点被回收，数据就没了。

第二层是作业级缓存层。这个层级不一定对应具体的物理设备，更像是Spark应用在运行期间维护的“数据状态”。比如cache到内存或者磁盘的DataFrame、流式作业的state，它们依赖本地盘的存在，但语义上是Spark执行引擎的一部分。

第三层才是S3。它承担两件事：第一，源数据和最终结果的持久化存储；第二，executor异常重启后的数据恢复来源。S3的吞吐和持久性全世界有目共睹，但它的延迟和请求成本不适合高频小文件读写，所以分层存储的目的就是把对S3的“高频小请求”转成“低频大请求”。

我刚开始接触这个架构时，容易把Storage想复杂，其实类比一下就通了：你做饭时案板上放一块砧板，切好的菜先放砧板旁边的碗里，下锅前再端过去，而不是每切一刀就往冰箱里塞。计算机里的shuffle就是那“切菜过程”，本地盘就是“碗”，S3是“冰箱”。早先的无服务器版Spark相当于没有碗，每一刀都拉一次冰箱门，费时费力还费电。

2.2 磁盘缓存机制：什么时候命中，什么时候失效

本地盘不是无限大的。EMR Serverless的executor每台实例配备的NVMe空间上限跟实例规格有关，默认情况下，Spark会把本地盘用作shuffle的临时目录，但不会傻乎乎地把所有数据都留在上面。具体分几档：

• shuffle write阶段：map任务计算结果直接写本地盘，整个shuffle过程不碰S3。这是最大的优化点，绝大多数节省利益来源。
• shuffle read阶段：reduce任务优先从远端executor的本地盘拉数据，数据拉不到（比如executor已死）才回S3补。因为EMR Serverless的executor在task执行期间稳定存活，实际“补数据”的概率不高。
• RDD cache / DataFrame cache：如果你在代码里执行cache()，Storage会尽量cache到本地盘。如果本地盘空间不足，也不会抛错，而是退回S3或者内存，Spark的存储层级里有完整的退化链。

关于缓存失效，有几个关键触发点需要铭记。第一，executor因为空闲被回收，或因为OOM被干掉，那它本地盘上的所有shuffle数据和cache全部失效，后续task需要重新计算或回S3读。第二，应用结束，所有本地盘都被回收，不存在跨任务复用。第三，本地盘满了之后，Spark的MemoryManager会控制分配给storage的内存，防止storage挤占execution内存。

这里有一个实操中很重要的调优点：很多作业在迁移前的代码里习惯用df.write.save("s3://bucket/中间结果")这种显式落S3的方式做断点。迁移到Serverless Storage之后，这种写法等于主动放弃了本地盘优化，自己又把数据推回S3。如果你在跑批里做过类似的操作，建议改成df.persist(StorageLevel.DISK_ONLY)，让它走本地盘，成本立刻下来。

2.3 运维简化的关键：不用再“养”集群

Storage特性给运维带来的简化，其实和底层存储机制是同一套逻辑：无状态、按需资源、自动清理。之前用EMR集群时，每次发布新版本的Spark依赖都要做一次AMI定制，节点故障要写替换脚本，集群空闲要记得缩容，忘了就会收到巨额账单。到了Serverless身上，这些问题的答案统统变成“你不用管”。

具体到日常操作，发生了三点变化。第一，不需要再管理集群生命周期。EMR Serverless应用创建后一直存在，本质是一个配置模板，本身不占资源、不计费。只有提交作业时，平台才拉起计算资源，作业结束自动回收。第二，应用的版本升级由AWS托管，你只需要选择Runtime版本，Spark、Hive、Oozie这些组件的补丁和兼容性由服务侧保证，不用自己打补丁或重做AMI。第三，资源控制以作业为单位，可以针对不同作业设定最大CPU和内存，避免一个作业吃光所有资源，也不用再人为划分队列。

我自己的实际体验是，迁移后运维工作量大约减少了70%。以前每天早上的第一件事是看集群YARN界面，确认没有作业失败，偶尔还要处理节点失联、磁盘写满的问题。现在统一用EventBridge监听EMR Serverless的作业状态，失败了直接触发告警，剩下时间都花在业务逻辑本身。

3. 实操：一个完整配置示例与参数说明

3.1 创建EMR Serverless应用的完整步骤

先说明一下操作前置条件：你需要一个AWS账号，安装了AWS CLI并配置好凭证，使用区域要确认支持EMR Serverless和Storage特性。当前该功能在大部分主流区域已经开放，具体以官方文档为准。

创建应用，我推荐直接用CLI，比在控制台点半天更可控。下面是创建应用的命令：

bash复制aws emr-serverless create-application \
    --name "etl-log-storage-app" \
    --type SPARK \
    --release-label "emr-7.5.0" \
    --architecture X86_64 \
    --initial-capacity '{
        "DRIVER": {
            "workerCount": 1,
            "workerConfiguration": {
                "cpu": "4vCPU",
                "memory": "16GB"
            }
        },
        "EXECUTOR": {
            "workerCount": 2,
            "workerConfiguration": {
                "cpu": "8vCPU",
                "memory": "32GB"
            }
        }
    }' \
    --maximum-capacity '{
        "cpu": "400vCPU",
        "memory": "1600GB"
    }' \
    --auto-start-configuration '{"enabled": true}' \
    --auto-stop-configuration '{"enabled": true, "idleTimeoutMinutes": 15}' \
    --region us-east-1

这个命令里几个参数值得展开讲。

release-label选择非常关键，Storage特性依赖新版Runtime提供的本地盘管理能力，建议至少使用emr-7.x版本。如果你沿用老旧的6.x版本，部分参数不会生效。

initial-capacity不是传统集群里的“固定节点数”，而是应用被唤醒时的初始资源池，你可以理解为预热容量。我建议不要设太大，因为Serverless会弹性扩缩容，初始容量只影响冷启动速度，设置过大反而增加无效占用时间。

maximum-capacity是作业可用的资源上限。注意这里限的是整个应用并行运行作业的总资源，不是单个作业。如果你多个作业并发提交，共享这个池子会互相挤压，建议根据团队并发量合理规划。

auto-start-configuration和auto-stop-configuration是运维省心的关键。打开auto-start后，只要提交作业，应用自动启动；设置auto-stop为15分钟，作业结束后空闲15分钟自动回收资源。以前用集群时的“忘关集群”问题从此消失。

创建完成后，记下返回的applicationId，后面提交作业都要用到。

3.2 提交Spark作业：日志ETL的完整示例

接下来用一个日志ETL作业演示Storage的实际使用。场景是每小时从S3读一批日志文件，做清洗、按IP聚合，落回S3。这个作业shuffle量适中，很适合演示配置。

先写作业代码。以下是一个简化的PySpark脚本：

python复制from pyspark.sql import SparkSession
from pyspark.sql import functions as F

spark = SparkSession.builder \
    .appName("log-etl-storage") \
    .config("spark.sql.shuffle.partitions", "200") \
    .getOrCreate()

input_path = "s3://my-bucket/raw-logs/2025/01/01/*.gz"
output_path = "s3://my-bucket/processed-logs/2025/01/01/"
checkpoint_path = "s3://my-bucket/checkpoints/etl-log/2025/01/01/"

df = spark.read.json(input_path)

cleaned = df.filter(F.col("event_type").isNotNull()) \
    .withColumn("event_date", F.to_date(F.col("event_time"))) \
    .select("ip", "event_type", "event_time", "device", "duration_ms")

result = cleaned.groupBy("ip", "event_type", "event_date") \
    .agg(
        F.count("*").alias("event_count"),
        F.avg("duration_ms").alias("avg_duration_ms")
    )

# 关键点：中间结果持久化到本地盘，而不是显式写S3
cached = result.persist(StorageLevel.DISK_ONLY)

# 这里模拟一个需要复用中间结果的分支写最终结果
cached.write.mode("overwrite").parquet(output_path + "summary")

# 清理缓存
cached.unpersist()

注意persist(StorageLevel.DISK_ONLY)。在传统EMR集群上，这个操作会把数据写到节点磁盘；在Serverless Storage上，它利用的就是本地NVMe盘。以前很多人因为怕本地盘易失，习惯用checkpoint把中间结果写S3，但在Serverless Storage场景下，作业正常结束前的DISK_ONLY缓存都是安全的，因为executor直到作业完成才会被回收。如果你非要checkpoint，路径放到S3没问题，但是要意识到checkpoint本身会产生S3写请求，影响成本和速度。

然后是提交作业。我用的命令：

bash复制aws emr-serverless start-job-run \
    --application-id "00abcdef1234567890" \
    --execution-role-arn "arn:aws:iam::123456789012:role/EMRServerlessJobRole" \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "s3://my-bucket/scripts/log-etl.py",
            "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=8g --conf spark.sql.shuffle.partitions=200 --conf spark.serializer=org.apache.spark.serializer.KryoSerializer"
        }
    }' \
    --configuration-overrides '{
        "monitoringConfiguration": {
            "s3MonitoringConfiguration": {
                "logUri": "s3://my-bucket/logs/emr-serverless/"
            }
        }
    }' \
    --region us-east-1

几个需要特别注意的地方：

第一，execution-role-arn指向的IAM角色必须有S3读写权限、CloudWatch日志权限，以及EMR Serverless要求的trust policy允许服务主体emr-serverless.amazonaws.com代入。我见过太多人卡在这里，明明账户有权限，但作业一提交就失败，其实就是没配信任策略。

第二，sparkSubmitParameters里的内存和core参数要与创建应用时的workerConfiguration对应。如果你在application层设置了DRIVER/EXECUTOR容量，又在job-driver里覆盖，Serverless会按照job-driver为准。我一般建议在application层设置默认值，在job层只覆盖个别作业的特殊需求，维护起来更清晰。

第三，关于Storage特性，不需要额外传开关参数。只要Runtime版本支持、应用层没有显式禁用本地盘，Spark的shuffle和cache会自动落到本地NVMe。这一点很方便，但也很容易让人误以为没生效。想确认，可以看运行日志里是否有类似“Using local disk for shuffle”的字样。

3.3 验证成本与性能的检查清单

作业跑完之后，别急着看账单，先做一轮验证，确认Storage优化真的生效了。

第一，打开Spark History UI。在EMR Serverless控制台的作业详情里，找到Spark UI链接。重点看Shuffle的“Shuffle Bytes Written”和“Shuffle Bytes Read”指标。如果中间数据量非常大，但S3请求费用没有同步增大，说明本地盘缓存生效了。反过来说，如果Shuffle量巨大且S3费用也大，那就要查是不是Spark运行参数把数据又导回了S3。

第二，看作业的Duration和资源消耗。同样的作业，在传统EMR集群可能跑30分钟，在Serverless Storage上如果shuffle本地化生效，时间通常会缩短15%~30%。因为本地NVMe的带宽和延迟远优于S3，尤其是大量小文件的shuffle。如果你跑出来速度反而更慢了，大概率是并行度设置不合理，或者数据倾斜。

第三，用AWS Cost Explorer看按天粒度的S3请求费。在过滤条件里选择服务为“S3”，查看作业运行前后请求费的变化。如果你看到GET/PUT请求的曲线有一个明显的高峰，而作业日志里shuffle量又很大，说明中间数据还是走了S3，需要回到代码层面排查。

第四，对比整体账单。取迁移前一个月的EMR相关费用（EC2、EMR、S3请求费，再加数据盘快照费），和迁移后相同业务周期的EMR Serverless账单做对比。我自己的对比结果是总成本下降47%左右，最接近官网宣传的那个55%的，是shuffle最重的那个作业，单独看下降了61%。

4. 常见问题与排查技巧实录

4.1 磁盘缓存不生效，S3请求费还是高

这是大家问得最多的问题。先说结论：绝大多数情况不是Storage功能没开，而是你的代码和应用配置主动绕过了它。

三种典型原因。第一，代码里显式写了df.write.save("s3://.../临时目录")，这会直接把数据推回S3，Storage再聪明也不知道你想省。第二，作业使用了checkpoint()，这是Spark流式作业和长作业里常见的操作，checkpoint本身就会写S3，如果用的频率太高，会产生大量请求费用。第三，并行度设置得太低，导致每个task处理的数据量特别大，本地盘放不下，Spark只能降级到S3。这个在shuffle量特别大的场景里非常常见。

排查思路很简单：打开Spark UI，看Storage页面，里面会清楚展示每个RDD的存储位置、容错级别。如果RDD显示为Disk Serialized 1x Replicated，那是存到了本地盘；如果显示为External BlockStore，那数据在S3。另外，查看Executor页面的“Disk Used”指标，如果Executor运行期间DiskUsed长期为零，那基本可以确认本地盘没有被使用。

我遇到过一个很隐晦的问题：作业本身没毛病，但application的maximum-capacity配得太小，导致executor频繁被kill再重建，每次重建都触发上游数据从S3重新拉取。这种场景下S3请求费不降反升。解决办法是把maximum-capacity调到真实峰值需求的1.2倍以上，同时降低auto-stop-configuration的超时时间，避免资源长期占用。

4.2 作业跑得慢，Shuffle卡在某个阶段

Storage不是万能的，它优化的是shuffle路径，但不能替代Spark本身的性能调优。常见的情况是，迁移后作业确实慢了，但原因不是Storage，而是无服务器环境的调度和并行度。

首先看spark.sql.shuffle.partitions设置。在自建集群上很多人习惯设成1000甚至2000，因为觉得reduce task多点快。到了Serverless上，每个task要分配一个container，如果你的作业总资源只有50 vCPU，一个task就分1 vCPU，2000个task会把调度和网络开销拉满。我实测下来，对中等规模的数据集，把shuffle partitions设成200~400往往比2000更快。

其次看数据倾斜。Serverless的executor是按task粒度调度的，一个倾斜task拖慢整个作业的现象比自建集群更明显。解决办法是在SQL里针对倾斜键加skew join hint，或者增加随机盐。不要指望平台自动解决所有倾斜问题。

第三，冷启动延迟。Serverless应用空闲一段时间后，auto-stop会回收资源，下一次提交作业时要从零拉起容器。如果你的作业本身只跑5分钟，冷启动的1~2分钟显得格外刺眼。解决办法是设置一个25分钟左右的idleTimeout，让白天连续提交作业时资源不释放，只在午休或夜间释放。

4.3 账单拆分看不懂，不知道钱花在哪

EMR Serverless的计费项分三块：vCPU时间、内存时间、存储时间。其中存储这部分，早期版本会按照使用到的存储空间按GB-hour计费，新版本引入了本地磁盘之后，本地盘的使用不再单独收费，并且之前冗余存储的额外计费也被移除了。这就导致了一个现象：看起来账单金额下降了，但如果你用旧账单的计费项去对账，会对不上。

我的建议是用Cost Explorer按“usage type”拆分，找到EMRServerless-vCPU-Hours和EMRServerless-GB-Hours这类字段，这些是核心计算费用。至于Storage相关的使用量，如果使用了新版本Runtime，在详细账单里看到的存储相关项会显著减少。如果你在账单里看到S3的请求费用仍然很高，而不是EMR Serverless本身，那大概率是作业代码里还在大量写S3中间结果，需要回到4.1去排查。

另外一个坑是：云上账单是延迟更新的，一般是几小时到一天，不要在作业刚结束时立刻翻账单，看不到最新数据就怀疑没生效。想看实时成本，可以用AWS Cost Explorer的“GetCostAndUsage”API按小时拉取，或者干脆在Spark History UI里对比shuffle数据量，比账单更直观。

还有一个建议共享：如果团队里有FinOps角色，迁移前先跟他把当前EMR+EC2+S3请求的月度基线拉出来。没有基线，迁移后不管省了多少，都说不清楚。我自己就是把基线做成了每周巡检的一部分，后面给老板汇报迁移收益的时候，一页图就讲完了。

4.4 IAM权限和日志排查

EMR Serverless的作业失败时，很多人第一反应是看CloudWatch日志，但没注意到日志默认不是每次都写。如果你没有在configuration-overrides里配置s3MonitoringConfiguration，作业的driver日志和executor日志可能只会发送到CloudWatch Logs，且保留期很短。我建议一律配到S3日志桶，方便长时间排查和接入Athena做日志分析。

权限问题是失败的重灾区。跑一个作业要的角色权限至少包含：S3读写的操作、CloudWatch日志组的写入、EMR Serverless的StartJobRun权限。如果你用自定义KMS加密，还要在KMS key policy里允许Serverless服务使用。我的经验是，先用AWS托管的AmazonEMRServerlessServiceRolePolicy跑通流程，再按最小权限原则收紧，千万别一上来就写精细权限策略，排错成本极高。

最后分享一个排错小技巧：如果作业秒失败且日志什么都查不到，十有八九是IAM对emr-serverless.amazonaws.com的信任策略没配好。打开角色页面看一眼“信任关系”，确认里面有这个服务主体，再加一条sts:AssumeRole的权限。这个问题我帮同事排查过不下五次，每一次都能在5分钟内定位到，但它真的非常容易被忽略。