数据键键中的显式表分区如何影响写入性能

我们有以下方案：

• 我们有一个大约包含的现有表。150亿记录。它没有在创建上明确分区。
• 我们正在创建带有分区的该表的副本，希望在某些类型的查询上阅读时间更快。
• 我们的表位于Databricks云上，我们使用Databricks delta。
• 我们通常通过两列过滤，其中之一是实体的ID（350k不同的值），其中一个是事件发生的日期（到目前为止31个不同的值，但每天都在增加！）。

因此，在创建我们的新表格时，我们进行了这样的查询：

CREATE TABLE the_new_table
USING DELTA
PARTITIONED BY (entity_id, date)
AS SELECT
  entity_id,
  another_id,
  from_unixtime(timestamp) AS timestamp,
  CAST(from_unixtime(timestamp) AS DATE) AS date
FROM the_old_table

此查询已运行48小时并计数。我们知道这正在取得进步，因为我们发现了与相关S3前缀中第一个分区密钥相对应的250k前缀，并且存在的前缀中肯定有一些大文件。

但是，我们很难准确地监视已经取得了多少进展，以及我们可以期望这会花费的时间。

我们等待时，我们尝试了这样的查询：

CREATE TABLE a_test_table (
  entity_id STRING,
  another_id STRING,
  timestamp TIMESTAMP,
  date DATE
)
USING DELTA
PARTITIONED BY (date);
INSERT INTO a_test_table
SELECT
  entity_id,
  another_id,
  from_unixtime(timestamp) AS timestamp,
  CAST(from_unixtime(timestamp) AS DATE) AS date
FROM the_old_table
  WHERE CAST(from_unixtime(timestamp) AS DATE) = '2018-12-01'

请注意，新表格的主要区别在于我们仅在日期进行分区，而不是在实体ID上进行分区。我们选择的日期几乎包含旧表数据的四个％，我想指出的是，因为它超过1/31。当然，由于我们是通过单个值选择的，而单个值恰好是我们所划分的东西，所以我们实际上只编写一个分区，大约十万左右。

使用相同数量的工人节点，该测试表的创建花费了16分钟，因此我们希望（基于此）的创建表25x较大只能围绕 7小时

这个答案似乎部分地承认，使用过多的分区可能会导致问题，但是在过去的几年中，基本原因似乎发生了很大变化，因此我们试图了解当前的问题可能是什么。Databricks文档并没有特别启发。

基于S3的发布请求费率指南，似乎增加了分区数量（关键前缀）应改进性能。有害的分区似乎是违反直觉的。

总而言之：我们期望为成千上万的分区中的每个分区中的每个记录编写成千上万的记录。看来，减少分区的数量大大减少了编写表数据所需的时间。为什么这是真的？是否有有关应为特定大小的数据创建的分区数量的一般准则？