对于 Delta 或 Iceberg 使用哪种基于时间的分区策略

Question

我正在使用 Spark-streaming 每 5 分钟摄取实时事件流并附加到

delta

或 apache

iceberg

表中。该表可以由下游数据管道摄取和处理，也可以直接由最终消费者用于进行数据分析。

每个事件都有

publish_time

、

event_time

，并且在某个时刻

ingestions_time

和

store_time

。

我可以看到

event_time

对于查询来说是最有用的，因为可能有很多迟到的数据，并且

event_time

将在每次查询时提供更新的值。对于此用例，我可以在 event_time 上对

detla

表进行分区。然而，另一个用例是在发生任何故障、数据不一致时使用

data reprocessing

。对于重新处理，在

store_time

或

ingestion_time

上重新处理更有意义。但如果数据仅按

event_time

分区，则像

select * from table where ingestion_time between date1 and date2

这样查询 detla 实时表将扫描整个表，因为它未按

ingestion_time

分区。

我想到的一些解决方案是：1）我可以为每个模式创建两组表。一个按 event_time 分区，另一个按 ingestion_time 分区。然而，这更难维持。 2）我可以按 ingestion_time 进行分区，并且在查询期间我可以使用足够大的时间范围来容纳后期数据。然而，这不是消费者友好的查询。

还有更好的建议吗？

示例用例：

管道 A 将处理后的事件写入表 A 管道 B、C 分别从表 A 读取数据并写入表 B 和表 C。

我希望TableA、TableB和TableC能够通过event_time高效查询，即使它是时间序列数据。在这种情况下，按 event_time 对它们进行分区是有意义的。

问题是，许多活动来得很晚，长达 6 个月。我们仍然处理它们并写入所有表中基于 event_time 的正确分区。需要注意的是，需要重新处理过去 6 个月内的任何任意分区数据。例如我们需要修复表B和表C在08-30-2023和09-07-2023之间的数据，因为我们知道在08-30之后发生了一些错误。但由于我们允许在该时间范围内进行后期数据处理，因此我们也可以处理 03-2023 年的数据。所以我们也需要重新处理它。所以我们需要收集所有的 event_time 分区并从 TableA 中重新摄取它们以进行重新处理。

Answer 1

你的想法对我来说没问题，但是如果需要第三份副本吗？然后呢？

我会根据查询谓词对最常访问的列进行 Z 排序，否则依赖数据跳过。

但是您关于查询复合过滤器的第二点也可以。