处理1TB Parquet数据时如何计算AWS Glue G.1x工作节点数量？

现有配置计算正误校验 #

你整理的G.1x worker单节点规格是准确的：单worker对应1个executor，分配10GB内存、8核CPU，挂载64GB EBS卷的参数符合Glue G.1x的标准定义。
但你的可用节点计数存在错误：按照Glue实际资源预留规则，Master节点服务和Driver/ApplicationMaster服务运行在同一个预留DPU上，不需要单独占用2个worker。如果配置50个G.1x worker，实际只会预留1个worker运行Driver和AM服务，剩余49个为计算worker，对应总计算内存为49*10=490GB，总EBS空间为49*64=3136GB≈3.06TB。

适配1TB Parquet数据的worker数量建议 #

Parquet为列式压缩存储，通用场景压缩比在3:1到5:1区间，1TB压缩Parquet解压后原始体量约3TB-5TB，结合Spark计算特性分场景判断：

• 如果是常规ETL作业（仅做列裁剪、过滤、简单聚合、小表关联），无超大shuffle操作，配置41-46个总G.1x worker即可（扣1个driver预留后可用计算worker为40-45个），你之前规划的50个总worker配置完全可以支撑运行，甚至有一定冗余。
• 如果作业包含全表重分区、大表Join、全局排序这类会产生大量shuffle溢出的操作，3TB左右的总EBS空间会比较紧张——shuffle临时文件加溢写数据通常会达到解压后数据量的1-2倍，建议把总worker数提升到60-65个，此时可用计算worker为59-64个，总EBS空间可达3776GB-4096GB，总计算内存可达590GB-640GB，能完全覆盖溢写落盘和计算需求，避免磁盘写满、OOM问题。

大量collect操作下的driver内存调整方案 #

collect操作会把所有executor端的计算结果全量拉取到driver节点内存汇总，默认16GB driver内存很容易触发OOM，可按以下优先级调整：

• 优先升级driver节点规格：不要使用G.1x作为driver，在Glue作业配置中单独将driver类型调整为G.2x（默认20GB内存），如果collect拉取的结果集在50GB以内，可直接选G.4x作为driver（默认40GB内存），足够支撑常规collect需求。
• 自定义内存参数：如果不更换driver DPU规格，可在Glue作业参数中添加配置--conf spark.driver.memory=24g，注意配置的内存值需要预留2-4GB给系统和进程开销，不能超过对应DPU的物理内存上限。比如G.2x driver最大可配置到16-18GB，G.4x driver最大可配置到36-38GB。
• 逻辑优化提示：collect本身不适合拉取超大规模结果集，如果拉取的结果集超过100GB，不建议强行调大driver内存，应该先在executor端完成聚合、裁剪，把结果集缩小到driver可承载的范围再拉取，否则就算调大内存也会出现长时间Full GC甚至作业超时失败。

内容的提问来源于stack exchange，提问作者RushHour