pyspark + hive 表分区列多时的性能

Question

我试图了解使用 Spark 查询 hive 表时对分区方案的性能影响。 举个例子：

Table 1有 3 个分区列，数据存储在如下路径中

year=2021/month=01/day=01/...data...

Table 2有 1 个分区列

date=20210101/...data...

有趣的是，我发现对第二种类型的表的查询更快，但我不知道为什么，我也不知道为什么。 我想了解这一点，所以我知道如何设计可能有更多分区的更大表的分区。

正在测试的查询：

select * from table limit 1

我意识到这不会从任何类型的查询修剪中受益。

---

以上是作为示例查询来演示我想要理解的内容。 但如果细节很重要

• 这是使用 s3 而不是 HDFS
• 表中的数据很小，没有大量的partitons
• 在第一个表上运行查询的时间约为 2 分钟，第二个约为 10 秒
• 数据存储为镶木地板

Answer 1

您能否在此处指定更多详细信息，例如使用哪种压缩类型，是否为压缩类型启用修剪等。如果是这样 pyspark + hive 通常在启用修剪的 orc 时提供良好的性能。 发生这种情况的原因也是因为最终分区中有很多文件，导致创建了大量任务。 在这种情况下，通常建议检查和合并分区，在读取数据时还建议增加 shuffle 分区和 shuffle 溢出，一般默认值为 200，可以增加该值以获得更好的并行性。 检查以下链接以获取可用于优化的选项。 火花配置

Answer 2

除了您未提及的所有其他因素：存储类型、配置、集群容量、每种情况下的文件数量外，您的分区模式与用例不对应。

应该根据如何选择数据或如何写入数据或两者来选择分区模式。 在您的情况下，分别按年、月、日进行分区是过度分区。 Hive 中的分区是分层文件夹，应遍历所有文件夹（即使仅使用元数据）以确定数据路径，在单个日期分区的情况下，仅读取一个目录级别。 另外两个文件夹： year+month+day而不是date对分区修剪没有帮助，因为所有列都是相关的并且总是在哪里一起使用。

如果您在大多数查询中的WHERE子句中还有一列，例如category ，它与date无关并且数据很大，那么附加分区是有意义的，那么您将从分区修剪中受益。