我们有以下场景：
我们有一个包含大约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进行分区。我们选择的日期几乎正好包含旧表数据的4%，我想指出这一点，因为它远远超过了1/31。当然，由于我们是通过一个值来选择的，而这个值恰好是我们划分的同一个对象，因此实际上我们只编写了一个分区，而可能是十几万个分区。
使用相同数量的工作节点创建这个测试表需要16分钟，因此我们预计（基于此）创建一个大25倍的表只需要7小时左右。
这个答案似乎部分承认使用过多的分区可能会导致问题，但是潜在的原因在过去几年中似乎已经发生了很大的变化，因此我们试图了解当前的问题可能是什么；databricks文档并没有特别说明问题。
根据s3发布的请求率准则，增加分区（密钥前缀）的数量似乎可以提高性能。分区有害似乎违反直觉。
总而言之：我们期望在成千上万个分区中的每个分区中写入成千上万条记录。似乎减少分区的数量可以显著减少写入表数据所需的时间。为什么这是真的？对于为特定大小的数据创建的分区的数量，有什么通用的指导原则吗？