做数据仓库的谁没有被内存问题折腾过几回前阵子刚把一套离线数仓的 Spark 任务调到稳定集群的内存压力还是居高不下一到月末全量跑批就提心吊胆生怕哪个环节 OOM 把整个流程拖垮。后来花了整整两周把执行引擎的参数、数据模型、存储格式、队列资源挨个捋了一遍才算找到一套真正能落地、可复制、效果肉眼可见的优化方案。这篇文章就是把这些经验整理出来从内存预算、Spark 调优、SQL 与数据模型优化、实时与 OLAP 引擎策略到问题排查和踩坑记录全部铺开讲清楚希望对正在跟数据仓库内存死磕的同行有点帮助。1. 数据仓库内存优化先看清问题在哪1.1 数据仓库为什么对内存这么敏感很多人一开始接触数仓以为瓶颈无非就是磁盘 IO 和网络带宽内存够用就行。真正上了生产环境跑了几轮全量任务之后才会明白内存才是最容易先爆掉的那块短板。原因其实不复杂数据仓库天然要处理海量数据的聚合、关联、排序、去重这些操作在计算引擎里几乎都是内存密集型的。拿 Spark 举例一个 Shuffle 操作要把中间结果落到内存或磁盘再做二次聚合一个 Join 要构建哈希表数据量一大内存立刻吃紧。Hive 虽然模型稍重但 Map 端的缓冲和 Reduce 端的 GroupBy 同样离不开内存兜底。再加上多个任务并发抢资源、YARN 队列配置不合理、小文件太多导致的任务调度开销内存在数仓场景里总是显得怎么都不够用。还有一个容易被忽视的点数据仓库不是单一组件而是一整套生态。HDFS 负责存储YARN 负责资源调度Spark、Hive、HiveServer2、Presto/Trino、Flink 各司其职每一层都吃内存。HDFS NameNode 需要管理元数据DataNode 有读写缓存YARN 的 ResourceManager 要维护应用状态HiveServer2 要为每个 Session 分配堆内存Spark Executor 要划分执行内存和存储内存Flink TaskManager 还要额外算上网络缓冲和托管内存。这么多组件叠在一起如果不做全局内存预算很容易出现某个组件内存配置过大把其他组件的份额挤占掉最后整个集群在高峰期集体趴窝。1.2 内存优化的核心思路预算、隔离、调参我在实际推动内存优化时习惯把它拆成三个层面来看第一是预算也就是先搞清楚这个集群总共多少内存、要跑多少业务、每类任务大概吃多少内存先算账再分钱。第二是隔离让不同优先级、不同资源特征的作业互相不干扰避免一个大任务把整个集群拖垮。第三才是调参针对具体引擎做参数层面的精细调整。很多人一上来就改spark.executor.memory和spark.executor.cores结果改了之后本地跑得好好的一到集群上反而更慢甚至频繁 OOM多半就是因为前面预算和隔离没有做好参数之间互相冲突。我见过不少团队做内存优化本质上是在拆东墙补西墙看到 Spark 任务 OOM就把 Executor 内存调大结果集群总内存不够YARN 把任务排队时间拉长又把并发度调低结果数据倾斜更严重单个 Task 处理的数据量更大反而更容易爆。所以说内存优化不是单点调参更像是在总预算约束下做资源最优化分配。后面我写的所有策略都会围绕总内存有限如何让每一块内存都花在刀刃上这一条主线展开。2. 基础优化内存预算与组件规划2.1 给每个组件算一笔内存账内存优化的第一步不是开调参文档而是先对整个集群的内存使用现状做一次全面盘点。我习惯的做法是先列一张集群资源清单统计每个节点有多少物理内存操作系统本身要预留多少一般建议预留 10% 到 15%剩余可用内存又该怎么分给 HDFS、YARN、HiveServer2 等常驻服务。这一步做扎实了后面再改参数心里才有底。举个例子假设一个数据节点有 256GB 物理内存操作系统和基础监控进程预留 32GB那么理论上可以交给大数据组件使用的只有 224GB。HDFS DataNode 建议最多给 8GB 到 16GB因为它的物理存储缓存主要靠 Page Cache没必要把堆内存拉得太大YARN 的 NodeManager 本体预留 4GB 左右就够了更多内存应该交给它管理的容器去用。如果还要在同节点部署 HiveServer2那又是一个 20GB 起的堆内存需求。这样一层层减下来真正能分配给 Spark Executor 的资源就没剩多少了。很多生产环境的问题其实就出在账没算清每个组件单独看都觉得内存不够使劲加合在一起就爆了。2.2 YARN 队列与内存隔离策略资源隔离这件事单独靠运维纪律很难持久必须靠框架层面的配置来保证。YARN 的 Capacity Scheduler 是用的最多的调度器核心玩法就是配置多个队列每个队列设置capacity和maximum-capacity不同业务组走不同队列。比如把数据开发同学的批量任务放在dev_queue把正式调度任务放在prod_queue两个队列一个占 40%一个占 60%并且各自限制最大占用不能超过 70% 和 90%这样即使开发同学半夜跑了个内存疯子任务也不至于把生产队列的资源全部挤占掉。队列配置之外还有一个容易被忽略的细节YARN 容器在执行任务时默认不会主动回收已经分配但暂时不用的内存而是等到容器销毁才释放。所以经常出现任务明明跑完了集群可用内存还是没回来的现象。针对这种情况可以在yarn-site.xml里开启容器的内存紧张回收比如设置yarn.nodemanager.vmem-check-enabled为 true让 NodeManager 定期检查虚拟内存使用超过比例直接 kill 掉容器。这个参数实际操作中要非常小心因为虚拟内存的判定标准有时会误杀正常任务建议先在测试环境验证好阈值再上生产。2.3 常见组件内存参数对照表下面这张表是我在做集群内存规划时常用的一份参考清单按组件-关键参数-推荐设置-备注整理方便团队在对内存做全局预算时有一个统一的抓手。参数数值不是死的要根据具体业务调整但这份对照表可以帮助避免最明显的拍脑袋配置。组件关键参数推荐设置备注YARNyarn.nodemanager.resource.memory-mb节点可用总内存的 80% 左右留出足够系统与 HDFS 余量YARNyarn.scheduler.maximum-allocation-mb单容器最大内存上限防止单个任务申请过多Sparkspark.executor.memory单 Executor 堆内存 8GB-32GB结合数据量和并行度Sparkspark.executor.memoryOverhead堆内存的 10%-20%不能设置得太大Hivehive.auto.convert.jointrue开启 MapJoin 可以显著降低 Reduce 阶段内存Hivehive.tez.container.size4GB-16GBTez 执行引擎时调优HDFSdfs.datanode.max.transfer.threads4096 或更高提高 DataNode 吞吐并不需过多堆内存Flinktaskmanager.memory.process.size根据实际并行度计算Flink 1.10 建议直接指定进程大小Prestoquery.max-memory-per-node节点物理内存的 50%-60%防止 Query 吃光节点内存3. 离线数仓核心Spark 内存调优实践实录3.1 Spark 内存模型的底层逻辑Spark 的内存调优绕不开它的内存模型。在 Spark 1.6 之后内存被明确划分为 Execution执行和 Storage存储两大区域通过spark.memory.fraction控制这两块合计占 Executor JVM 堆的比例默认 0.6剩下的 0.4 留给用户代码、内部元数据和异常处理等。Execution 区域和 Storage 区域之间可以互相借用但 Execution 在需要时有权强制回收 Storage 占用的内存。这个设计容易导致一个现象如果缓存了大量 DataFrame执行阶段内存不足时Spark 会强制把缓存数据块溢写到磁盘反而比不缓存更慢。我去年排查过一个案例业务方为了加速重复查询用.cache()缓存了一张 200GB 左右的拉链表结果后续做多表 Join 时一直报Container killed by YARN for exceeding memory limits。后来看 Executor 日志才发现Storage 内存被缓存占得太满广播变量和哈希表都没地方放了Spark 反复尝试自行消化最终容器内存超限被 YARN 杀掉。解决思路是缓存的确可以考虑但优先用序列化存储级别比如MEMORY_AND_DISK_SER同时检查是否真有必要缓存全表很多时候只需要缓存经过列裁剪和过滤后的中间结果占用内存能缩小好几倍。3.2 关键的 Spark 参数如何选Spark 调参里最容易让人犯迷糊的是spark.executor.memory、spark.executor.cores和spark.executor.instances这三个参数之间的配合。直觉上会觉得内存开得越大、Executor 数量越多任务一定跑得越快。真实情况往往不是这样。一个 Executor 的内存越大JVM 的 GC 压力就越大Full GC 时整个 Executor 会停顿很久任务反而卡住Executor 数量开太多又会造成任务调度和 Shuffle 的网络开销成倍增长。我一般建议先算好总 Executor 内存预算再反过来推导单 Executor 的规格。假设 YARN 队列可用内存在 256GB 左右我会先把单 Executor 内存定在 16GB堆内memoryOverhead给到 2GB 到 3GB核数给 4 个这样单 Executor 的内存合计约 19GB。同节点 Executor 数量 节点可用内存 / 19GB向上取整后再去调整实例总数尽量让总并发度Executor 数 x 核数和 Shuffle 分区数匹配。如果阶段 Shuffle 分区数远大于并发度大量 Task 会排队等待如果远小于并发度CPU 资源又会浪费Spark 会提前把还没处理完的分区合并也能跑但效率不高需要根据日志和数据量再微调spark.sql.shuffle.partitions。下面是踩过几轮坑之后整理出来的一套常用起步参数实际项目可以在这个基础上微调spark.executor.instances32 spark.executor.cores4 spark.executor.memory16g spark.executor.memoryOverhead3g spark.sql.shuffle.partitions256 spark.sql.autoBroadcastJoinThreshold104857600 spark.sql.broadcastTimeout600spark.sql.autoBroadcastJoinThreshold如果设置得太大比如超过 512MB调度端会频繁尝试构建广播变量反而给 Driver 带来很大的序列化压力。这个参数适合小表广播不适合把大表硬塞进去否则只是把压力从 Executor 转嫁到了 Driver照样会 OOM。3.3 并行度与动态资源分配并行度和内存看似是两个维度实际上相互影响非常深。并行度太低每个 Task 处理的数据量太大单 Task 内存需求剧增OOM 概率直线上升并行度太高元数据开销和 Shuffle 文件数暴增Task 调度和序列化消耗大量内存。所以我通常先看输入数据量如果单次处理的表在 500GB 到 1TB 这个量级Shuffle 分区数在 512 到 1024 比较合适。数据量不是越大分区数就需要越多还需要考虑下游 Reduce 阶段每个 Task 是否能把内存开销控制住。Spark 3.0 以后有一个spark.dynamicAllocation.enabled参数可以让 Executor 根据阶段负载动态伸缩空闲的 Executor 会自动释放回来继续跑时再申请一批新的。离线数仓如果 cron 任务很多不同时间点负载波动大这个参数很实用。但要注意开启了动态分配后spark.executor.instances会被当作初始值而不是硬上限需要同时设置spark.dynamicAllocation.maxExecutors避免资源被某些任务无限扩张吸干。实测下来对于调度时间固定的批处理任务我会保守一点把动态分配关掉手动指定实例数效果更可预测。对于临时跑数和探索性分析动态分配就很好用能显著降低闲时资源浪费。4. 数仓 SQL 与数据模型层面降内存这一步一定要做4.1 存储格式与压缩内存压力的隐形开关很多人优化内存只知道改引擎参数忽略了一个更前置的问题底层数据以什么格式存储、以什么压缩算法落盘直接影响扫描进内存的数据量。如果 Hive 表还是纯 TextFile 格式没做压缩跑一个简单的 select 聚合扫描层可能就已经吃掉了好几倍于实际有效数据的内存和带宽。而如果采用 Parquet 或 ORC 格式配合 Snappy 或 ZSTD 压缩扫描阶段会启动谓词下推和列裁剪只读取用到的列内存占用完全是另一个数量级。我在项目里做过一次对比同一张订单明细表TextFile 存储时跑一次月度汇总Spark 读取阶段 Input 约 3.4TB转换成 Parquet Snappy 后同样的汇总任务 Input 降到 860GB 左右整体执行时间缩短了接近 60%Executor 的峰值内存也下降了一半以上。这里面的原理一方面来自列式存储的压缩比另一方面得益于 Parquet/ORC 内置的统计信息能跳过大量不需要读的数据块。如果你还没有对核心大表做列式存储改造先把这件事做了内存优化等于白捡一半收益。4.2 大宽表与笛卡尔积内存杀手的两大元凶数仓建模时最怕两种操作一是制造超大宽表把几十甚至上百个字段堆在一张表里下游任务只要取其中几个字段扫描层仍然要把整行数据全部读进内存按列裁剪的技术优势荡然无存二是 SQL 里出现隐式笛卡尔积比如关联条件写错或者真的全外连接这种查询到了 Shuffle 阶段需要构建巨大的哈希表内存直接原地爆炸。有一次我们线上一个报表任务突然连续三天 OOM看了 SQL 才发现开发同学把两张宽表按日期范围做了非等值关联Spark 无法走 Broadcast Join只能走 SortMergeJoin两个大表全量参与排序和聚合分配的内存全被撑满。最终优化方案很简单把大表拆小先按最新分区把日期范围过滤掉 90% 的数据再做等值关联任务五分钟之内就跑完了。这个案例给我的启发是数仓开发不能只看功能正确还要养成每次写 Join 先估算一下两边数据量、再决定用什么关联策略的习惯。4.3 分区剪枝与谓词下推让引擎少碰无用数据数据仓库里有一句老话最贵的操作是把不需要的数据读进内存。 分区剪枝和谓词下推就是专门用来减少内存和 IO 压力的手段。分区剪枝的意思是如果表按日期分区查询条件里带上where event_date2026-03-01扫描层就能跳过其他所有分区目录直接从元数据层面砍掉 99% 的文件。谓词下推则是指过滤条件下推到存储层让 Parquet/ORC 格式基于统计信息提前跳过不符合条件的行组和条带。两者叠加扫描阶段的内存占用可以降到极低。实际操作中我最常见的一个问题是开发同学习惯写where dt from_unixtime(unix_timestamp(),yyyy-MM-dd)这样的动态条件看起来能取当天但因为在函数外面包了一层Spark/Hive 很难做分区裁剪会扫描全部分区。正确写法是让动态条件不进函数套层例如where dt date_sub(${date}, 1)或者提前在代码里把日期算好再拼到 SQL 里。细节不复杂但直接影响内存消耗和任务时长值得专门在代码评审里提醒所有开发。5. 实时计算与 OLAP 引擎的内存策略5.1 Flink 内存配置的实践经验实时数仓越来越普及Flink 任务的内存管理也成了避不开的课题。Flink 1.10 之后的内存模型分得比较细JVM 堆内存里有框架内存和任务内存堆外又有托管内存、网络内存、JVM Overhead 等。默认配置能用但高负载下容易出问题。我最常踩的坑是任务跑一周后状态越来越大Checkpoint 持久化时内存被吃掉一块过段时间直接TM OOM。后来排查发现 Flink 的 RocksDB 状态后端用到的托管内存默认只占进程内存的 70%如果状态量增长过快这块配置容易被撑满需要按实际状态大小调整。Flink 的内存参数建议直接设置进程总内存而不是手动拆一堆内部参数。比如一个 TaskManager 进程规划 8GB那就设taskmanager.memory.process.size: 8192m让 Flink 自己分配堆内、托管、网络和 Overhead。如果任务里用到了窗口聚合可以把taskmanager.memory.managed.fraction稍微调高一点给 RocksDB 更多空间如果任务主要是消息转发和简单 ETL托管内存可以调低把省下来的留给 JVM 堆。实时任务调内存比离线还要谨慎因为改完参数重启任务会丢状态通常需要从最近 Checkpoint 恢复窗口数据会有一段空窗期所以每次调整前我都会在沙箱环境模拟跑两天再动生产。5.2 Presto/Trino 与 ClickHouse交互式查询引擎的内存控制交互式查询和 BI 报表场景很多人会引入 Presto/Trino 或 ClickHouse。Presto 的模型是无状态查询完全吃内存一个超大 GroupBy 或者 Cross Join 就可能把一个 Worker 的内存耗尽进而影响其他查询。针对这类引擎我的做法是三层限制全局内存、单查询内存、单节点内存。比如query.max-total-memory-per-node设置成节点内存的 50%query.max-memory设置成整个集群可用查询内存的 80%超过阈值直接拒绝新查询而不是等到 OOM 全部失败。这个超限即拒绝的思路很多运维不敢用担心影响业务但实际上它换来的是集群整体可用性日常绝大多数查询的内存占用远低于上限只有那些没写好 SQL 的家伙才需要被拦下来。ClickHouse 的内存优化路径完全不同它是单机性能怪兽但分布式集群也吃内存。我最关注的是max_memory_usage和max_bytes_before_external_group_by这两个参数前者帮你在单查询超限时自动降级到磁盘后者确保 GroupBy 在内存数据超过阈值时先把部分状态溢写到磁盘。给这两兄弟设好值之后ClickHouse 再也没因为几个大查询把节点搞挂过。5.3 查询引擎选型对整体内存预算的影响如果说前面聊的都是怎么让已有引擎更省内存那引擎选型就是最根本的内存省不省的决策。现在的数仓生态基本支持同一份 HDFS/Hive 数据既可以用 Spark 跑批也可以用 Presto 跑交互式查询还可以用 ClickHouse 承接高并发单表聚合。如果团队需求主要是千万到亿级别的多维分析想靠 Spark SQL 硬扛那内存开销会非常大如果切到 ClickHouse 或者 Doris 这类 AP 引擎同样的查询内存开销只有几分之一速度还快得多。选引擎时要算的账不只是软件本身的 License 和运维成本还有内存账。我自己做过一个对比同样的日活报表聚合在 Spark 上调优后需要给 30 个 Executor每个 16GB才能把响应时间控制在 40 秒以内换成 ClickHouse 后3 节点 64GB 内存的集群就能满足 P95 在 3 秒以内的查询要求。内存总量差出一个量级。当然ClickHouse 也有自己的短板比如 update/delete 性能差、多表关联不如传统数仓方便所以也不是说选了它就把 Spark 全扔了而是在架构上把批处理和交互式查询分流各用各的最优引擎内存开支最划算。6. 常见问题与排查技巧实录6.1 任务 OOM 与容器被 YARN 杀掉这是数仓工程师每天都要面对的经典问题。报错信息大多长这样Container killed by YARN for exceeding memory limits. XGB of XGB physical memory used。很多人第一反应是加内存但更科学的做法是先看日志、分析是哪块内存出问题。如果 Executor 堆 OOM通常是数据量超过预期或 Join/GroupBy 出现倾斜如果堆内正常、堆外超限多见于memoryOverhead或 Direct Memory 吃紧比如某些算子大量使用堆外内存。我的排查套路是先打开 Executor 的 GC 日志看老年代使用率是不是持续满。再到 Spark UI 页面看每个 Stage 的 Shuffle Read/Write 大小确认哪个 Stage 内存压力最大。检查数据分布看看是不是有某个 Key 的数据量特别庞大导致单个 Task 内存爆掉。如果确认是数据倾斜优先考虑加盐拆分、广播小表、两阶段聚合等方式处理单纯加内存只是治标不治本。6.2 查询慢但内存不高资源利用不平衡有一种情况很让人头疼任务没有 OOM但就是跑得很慢看监控内存使用率也不高。这种往往是并行度不够或者 Shuffle 溢写太多。比如spark.sql.shuffle.partitions设置太小每个 Task 处理的数据量过大需要把中间结果溢写到磁盘频繁 IO 导致内存虽然不高但任务卡死。如果 Executor CPU 也没用满那大概率就是并行度的问题。遇到这种情况把分区数往上调让每个 Task 的数据量降下来内存波动会明显改善整个任务性能也会随之提升。还有一个小细节当大表和小表做 Join 时小表如果不合适被广播优化器会选择 SortMergeJoin双方都可能做全表排序内存压力陡增。检查 Spark UI 的物理计划里是不是出现SortMergeJoin如果是确认能否通过spark.sql.autoBroadcastJoinThreshold把小表兜住这样就能把 Join 直接改成 Broadcast Join整个 Stage 的内存需求会下降一个档次。6.3 内存泄漏与 GC 问题数仓场景里内存泄漏不是没有但很多时候是应用代码写法有问题而不是框架的 bug。比如在 PySpark 里 collect 了一个超大的 RDD 到 Driver或者在一个循环里反复创建 SparkSession这些都会导致内存暴涨。Java/Scala 开发的任务里如果在 map 算子内部创建了不释放的对象也会加剧 GC 压力。处理这类问题我会优先考虑数据是否必须在 Driver 端汇总、能否用累加器代替以及是否在循环外复用 SparkSession。GC 问题的判断最直观的办法是在提交 Spark 任务时加上-XX:PrintGCDetails -XX:PrintGCDateStamps配合日志检索Full GC的次数和耗时。如果 Full GC 频繁且老年代内存迟迟降不下来我通常会把spark.executor.memoryOverhead调整下并检查是否存在大对象分配。如果确认是任务本身就要消耗这么多内存再考虑增大 Executor 内存或减少单 Executor 的并发核数让每个 Task 有更宽裕的 JVM 空间。6.4 常见问题速查表下面把我在生产环境里遇到的高频问题整理成一份速查表方便遇到同类情况时快速定位方向现象可能原因排查思路与建议容器被 YARN 杀堆内 OOM单 Task 数据量太大 / 数据倾斜检查 Spark UI Shuffle 大小做两阶段聚合或加盐容器被 YARN 杀堆外超限memoryOverhead 或 Direct Memory 不够适当调大spark.executor.memoryOverhead任务慢但内存不高Shuffle 溢写频繁 / 并行度不足提高spark.sql.shuffle.partitions缓存数据后反而更慢Storage 占用过多Execution 被挤压改用序列化存储级别减少缓存范围Hive 任务频繁 OOMMapJoin 未生效 / 小表被当大表处理检查hive.auto.convert.join与阈值夜间批处理时段集群卡死大任务占满队列资源配置队列maximum-capacity强制隔离Flink 状态增长导致内存爆RocksDB 托管内存太小调大taskmanager.memory.managed.fractionPresto 单 Query 影响全局缺少单查询内存限制配置query.max-memory-per-node硬上限6.5 先缩小数据再谈内存优化一个万能起点最后想聊一个我特别推荐的优化起点。很多内存问题表面上是参数不够本质上是数据量太大或数据质量太差。所以我在每一轮调优之前都会先做一次数据瘦身能用分区的用分区能裁剪列的裁剪列能过滤空值的过滤空值先让引擎读进去的数据量少 30% 到 50%再来看要不要调 Executor 内存。这个顺序对新手尤其重要因为改参数容易看到立竿见影的效果但很可能掩盖了更根本的数据模型问题。先缩小数据量再优化内存配置整个过程会顺畅得多最后的集群稳定性也会更好。按照这个思路我后来把团队里所有核心任务的 SQL 都过了一遍强制要求核心大表统一走 Parquet 存储、必须按日期分区、不允许全表扫描、小表关联必须带上小表条件、大表 Join 前先做聚合。这些规则看起来很基础但它们给集群带来的内存收益比任何单点参数调优都来得实在。我个人的建议是把这些数据规范固化成代码评审项和 CI 检查规则再配合参数调优数仓内存问题才能真正做到长期可控而不是每个季度疲于救火。