小编hbr*_*gnr的帖子

问题

我们在 ADLS Gen2 之上有一个 Delta Lake 设置，其中包含下表：

• bronze.DeviceData: 按到达日期划分 ( Partition_Date)
• silver.DeviceData：按事件日期和时间（Partition_Date和Partition_Hour）分区

我们从事件中心摄取大量数据（每天超过 6 亿条记录）到bronze.DeviceData（仅追加）。然后我们以流方式处理新文件，并silver.DeviceData使用 delta MERGE 命令将它们更新插入（见下文）。

到达铜牌表的数据可以包含来自任何银牌分区的数据（例如，设备可以发送它在本地缓存的历史数据）。但是，任何一天到达的>90% 的数据都来自分区Partition_Date IN (CURRENT_DATE(), CURRENT_DATE() - INTERVAL 1 DAYS, CURRENT_DATE() + INTERVAL 1 DAYS)。因此，为了更新数据，我们有以下两个 spark 作业：

• “快速”：处理来自上述三个日期分区的数据。延迟在这里很重要，所以我们优先考虑这些数据
• “慢”：处理其余部分（什么，但是这三个日期的分区）。延迟并不重要，但它应该在“合理”的时间内（我会说不超过一周）

现在我们来解决这个问题：虽然在“慢”工作中数据量少了很多，但它运行数天只是为了处理一天的慢青铜数据，有一个大集群。原因很简单：它必须读取和更新许多银分区（有时> 1000 个日期分区），并且由于更新很小但日期分区可能是千兆字节，因此这些合并命令效率低下。

而且，随着时间的推移，这个缓慢的工作会变得越来越慢，因为它接触到的银色分区会增长。

问题

1. 我们的分区方案和快速/慢速 Spark 作业设置通常是解决这个问题的好方法吗？
2. 可以做些什么来改进这种设置？我们希望降低缓慢作业的成本和延迟，并找到一种方法，使其随着每天到达的数据量以青铜级而不是银级表的大小而增长

附加信息

• 我们需要 MERGE 命令，因为某些上游服务可以重新处理历史数据，然后也应该更新 Silver 表
• 银桌的架构：

CREATE TABLE silver.DeviceData (
  DeviceID LONG NOT NULL, -- the …