我使用spark-streaming每5分钟摄取一次实时事件流，并附加到delta或apache iceberg表中。该表可以由下游数据管道摄取和处理，也可以直接由最终消费者使用来进行数据分析。
每个事件都有publish_time，event_time，在某个点有ingestions_time和store_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 live表将扫描整个表，因为它没有被ingestion_time分区。
我想到的一些解决方案是：1）我可以为每个模式创建两组表。一组按event_time分区，另一组按ingestion_time分区。然而，这更难维护。2）我可以按ingestion_time分区，在查询过程中，我可以使用足够大的时间范围来容纳迟到的数据。然而，这不是消费者友好的查询。
有什么更好的建议吗？
示例用例：
管道A将处理后的事件写入表A管道B，C分别从表A读取并写入表B和表C。
我希望表A、表B和表C可以通过event_time有效地查询，即使它是一个时间序列数据。在这种情况下，通过event_time划分它们是有意义的。
问题是，许多事件来得很晚，最多6个月的旧.我们仍然处理它们，并写入正确的事件_时间为基础的分区在所有表.警告是需要重新处理任何任意分区数据到这最后6个月.例如，我们需要修复数据表B和表C之间08-30-2023和09-07-2023，因为我们知道一些错误发生后08- 30.但是，由于我们允许在该时间范围内进行后期数据处理，因此我们也可以处理03-2023数据。因此，我们需要重新处理该数据。因此，我们需要收集所有event_time分区，并从TableA重新摄取它们进行重新处理。