我正在优化 Spark SQL ETL，以频繁地从 S3 上的 1000 亿行、100TB parquet 格式表“event_100B”中选择 0.1% 的数据。
表 event_100B 包含唯一键列 EventId（32 十六进制 uuid）。需要优化的选择查询是加入一个 predicate_set，提供 1 亿个 EventId 键作为谓词，这些键映射到事件表中随机分布的行。无法利用任何聚类模式。
select t1.* from event_100B t1
inner join predicate_set p1 on t1.EventId = p1.EventId
由于谓词由跨越较大最小最大范围的高基数键组成，因此不会发生文件级别或行组级别的修剪。 ETL 花费大量时间下载文件来运行全表扫描。
寻求建议哪些数据库或文件格式可以支持这种类型的批量随机访问查询的有效数据跳过，以及如有必要，寻求 AWS/Azure 存储硬件的类型。
一个初步想法： 将所有 EventId 分配到 1 亿个桶中：BucketId = EventId % 1,000,000，这样每个桶包含平均 1000 个 EventId 值。然后，event_100B 按 BucketId 对表行进行聚类/排序。
BucketId 列需要更少的 IO 和网络带宽来下载并加入 predicate_set：
select t1.* from event_100B t1
inner join predicate_set p1 on t1.BucketId = (p1.EventId % 1,000,000)
我的期望：通过增加存储桶计数，任何谓词 EventId 落入存储桶的概率都会降低，并且可以跳过更高百分比的存储桶（和关联行）。
100TB 的 parquet 文件很容易代表数百万个文件。因此，查询引擎将花费大量时间获取页脚，最糟糕的是在您的上下文中扫描大多数文件的数据。
限制要读取的 parquet 文件数量的一种方法是维护一个辅助索引，告诉您每个 parquet 文件及其包含的 eventid 列表。当然，您可以保留 parquet 来构建此索引，因为在最坏的情况下这只是几百万行的问题。然后知道哪些文件包含您的 100k 事件应该相当快，并且希望您最终会减少要读取的镶木地板文件。
您可以通过尝试其他技术（例如starrocks/apache Doris）来获得更简单的设计。它们非常适合您的用例，因为它们提供与对象存储/hdfs 兼容的本机格式，具有统计、索引、基于成本的优化器，c++ 引擎是高度矢量化的。顺便说一句，我不会考虑 Trino（镶木地板）、clickhouse（糟糕的连接支持）或 elasticsearch（不利于检索大量记录）。
让我们知道您的最终结论！