我试图优化合并的性能在Databricks（DBR 12.2 -所以低 Shuffle 合并启用）。目标表有~ 700米行和增量有100- 200 k行。这个操作似乎很慢，需要大约30分钟与两个工人（Standard_D4s_v5 - 4核心，16 GB RAM）。
问题似乎是合并ID，这是一个很长的数字字符串，e.x 060372015102700977000。我甚至用Z-顺序，但分布是这样的，几乎所有的基础文件都被触及。几乎所有的目标行都被复制以进行处理。减小每个文件的大小确实减少了被触及的文件的比例，但性能相似。
我还创建了一个新的列，其中只有合并键的前5个字符，并使用该列对表进行分区。这确实导致了文件大小的倾斜（以及更多的文件），但源表和目标表之间的分区匹配度约为60%。使用此方法进行合并也导致了目标行的数量减少。但这花费了两倍多的时间。
为什么分区会降低性能？还有，有没有一种方法可以在不增加计算资源的情况下提高性能？
编辑：合并指标的快照x1c 0d1xx 1c 1d 1xx 1c 2d 1x
1条答案
按热度按时间vuktfyat1#
正如你在评论中所指出的，并且被跳过的目标文件支持为0，所有文件分区部分/块都被更新命中。除非你能找到一种方法来打破源和目标文件沿着一个有用的分区，否则你可能无法提高性能。
6.57亿行未被修改，但必须再次写入，只有86 k更新和94 k插入。
如果它的更新比读取更重（并且由于没有有用的分区，您必须读取每个文件），则可以移动到SCD样式模型并始终追加会更好（即添加操作列并使用接收到的时间戳或另一个表来生成操作id等）。