使用Spark在S3存储数据最新状态及Delta Lake应用相关问题

问题1：Spark在S3上实现数据upsert的最优方案、高基数列分区合理性问题 #

你当前场景下最优方案是直接使用Delta Lake原生的MERGE INTO语法实现按主键更新，不需要依赖分区覆写的方案，参考实现逻辑如下：

MERGE INTO delta.`s3a://your-delta-path` target
USING your_update_df source
ON target.machineid = source.machineid
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

按唯一值（高基数）列做分区绝对不是最优解，你目前遇到的小文件过多、Athena查询性能退化都是高基数分区的典型问题。
其他可行替代方案：可以选择时间维度（比如按天/按小时）这类低基数字段做分区，再针对machine-id字段开启Delta的Z-Order排序优化、布隆过滤器索引，既能加快更新时的数据定位效率，也能避免高基数分区带来的各类问题。

问题2：切换Delta格式后是否要保留原machine-id分区结构 #

不需要保留。你之前按machine-id分区的核心目的是为了实现动态覆写对应设备的数据，本质是绕开原生Parquet不支持行级更新的限制。
Delta本身已经支持行级ACID更新，你只需要把machine-id设为merge操作的匹配主键，Delta会自动定位到对应数据文件做增量更新，不需要靠分区做数据隔离。保留高基数分区反而会继续存在小文件、元数据膨胀的问题，得不偿失。

问题3：高基数分区超过5万时的性能表现 #

不管用什么存储格式，高基数分区（5万+分区）都会带来明显的性能问题：

• 读写阶段的元数据遍历开销会显著上涨，Spark Driver、Delta元数据管理的内存占用会随分区数线性增长，严重时会导致任务稳定性问题
• 即便Delta优化了元数据处理逻辑，使用Athena查询时，仍需要先加载所有分区的元数据信息，几万条分区的加载本身就会产生数秒的额外开销，加上大量小文件的扫描开销，查询性能不会有明显改善
  这种设计的收益远低于带来的额外开销，完全不推荐。

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