我来帮你梳理这两个问题的核心关键点：

第一个问题：3GB数据集的repartition策略是否合理？ #

你的思路有可取之处，但也存在可以优化的细节：

• 分区数的核心参考标准应该是数据量/单分区合理大小，你提到的128MB/分区是业界公认的Spark最优阈值之一（对应Spark默认的spark.sql.files.maxPartitionBytes配置）。你的3GB数据集换算后是3072MB，除以128MB的话，理想分区数在24左右。
• 你说“分区数要是核心数的倍数”这个逻辑本身没问题，但得结合总核心数和数据量来看：你用了100个G.8x worker，每个32vCPU，总核心数是3200，但你的数据量只有3GB——如果设成3200个分区，每个分区才不到1MB，这会让Spark花大量时间在调度这些极小的任务上，反而抵消了并行计算的优势，完全没必要。32个分区其实已经足够覆盖你的数据量，甚至留了冗余空间，是比较合理的；而3200就明显过剩了，这也是为什么你设32和3200没区别的原因——数据量太小，小分区太多，Spark在执行时可能自动做了合并，或者调度开销完全盖过了并行的收益。

主问题：为什么join后分区数变成了随机数？ #

这是Spark（包括Glue）的正常行为，核心原因是绝大多数join操作都会触发shuffle，而shuffle过程会重新调整分区数：

• 当你执行join时，如果是需要shuffle的场景（比如两个大表join，或者其中一个表没法用广播优化），Spark会根据join key的哈希值对数据重新分区，这时候的分区数默认由spark.sql.shuffle.partitions配置决定（Glue 3.0里这个默认值一般是200），完全不受你之前设置的初始分区数影响。
• 另外，如果你join的表本身分区数和当前表不一致，Spark为了保证join时的分区对齐，也会在shuffle过程中自动调整分区数，所以最终的分区数就会和你一开始repartition的数值不一样。

如果想在join后仍控制分区数，你可以在join完成后再执行一次repartition或者coalesce来调整到目标数值；也可以提前修改spark.sql.shuffle.partitions配置，让shuffle后的默认分区数符合你的需求——不过还是要注意，这个数值不要远大于你的数据量对应的合理分区数，不然又会回到小分区过多的问题。

备注：内容来源于stack exchange，提问作者Vijeth Kashyap