Spark3.0.2 union后orderBy/sort未对全量数据集生效问题咨询

• Spark的sort/orderBy算子执行后，仅保证每个分区内部的数据是有序的，跨分区的全局顺序仅在全量读取所有分区数据时才会生效。你观察到的结果顺序不一致，本质是Palantir Foundry的数据集预览功能仅拉取前若干分区的前若干行展示，不会加载全量数据后再排序，因此你看到的是局部有序的结果，不是全量排序后的真实顺序。
• 仅修改record_status的赋值就出现结果顺序变化，是因为常量值修改会改变Spark分区计算的哈希规则，导致union后的分区数据分布发生变化，排在前面的分区对应的timestamp范围不同，预览时展示的首行内容就会出现差异，并非排序操作执行顺序发生了变化，这也和你观测到的查询计划一致。
• 使用KUBERNETES_NO_EXECUTORS_SMALL配置后排序表现正常，是因为该配置会启动单执行器运行任务，默认并行度为1，排序后所有数据都会写入1个文件，文件内部全量有序，预览读取该文件的内容自然会显示正确的全局顺序。

场景1：仅需下游计算时保证全局有序，不需要预览展示正确顺序 #

无需修改现有代码，下游作业全量读取该数据集时，Spark会自动读取所有分区并按排序规则返回正确的全局顺序，不会影响业务逻辑正确性。

场景2：需要数据集预览也展示正确的全局顺序 #

小数据集场景 #

排序后调用coalesce(1)将全量数据合并到单个分区再写入，示例代码如下：

df = df.sort('timestamp', ascending=False).coalesce(1)

注意：该方案仅适合数据量远小于执行器内存上限的场景，大数据量下使用会出现单分区内存溢出风险。

大数据集场景 #

使用范围分区替代普通排序，保证分区之间全局有序，示例代码如下：

# 按timestamp降序划分范围分区，分区数可根据数据量调整
df = df.repartitionByRange(F.desc('timestamp'))
df = df.sortWithinPartitions('timestamp', ascending=False)

该方案下分区与分区之间是全局有序的，Foundry预览时会按分区顺序拉取数据，展示的结果符合全局排序规则，同时避免了单分区的性能问题。

你当前的增量转换代码中使用了out.set_mode('replace')全量替换输出，本质和全量转换没有区别，无法享受到增量计算的性能优势，如果数据量较大可以调整为增量写入逻辑，避免每次全量重算。

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