小编Mic*_*ust的帖子

我们有以下场景:

• 我们有一个包含约的现有表.150亿条记录.它没有在创建时明确分区.
• 我们正在使用分区创建此表的副本,希望在某些类型的查询上更快地读取时间.
• 我们的表位于Databricks Cloud,我们使用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个小时.

这个答案似乎部分承认使用太多分区可能会导致问题,但是在过去几年中,潜在原因似乎发生了很大变化,因此我们试图了解当前的问题可能是什么.在 …

将我的 Azure Databricks 从标准升级到主要，尝试开始使用 Databricks Delta：

create table t
using delta
as select * from test_db.src_data;

您的帐户中未启用 Databricks Delta。请联系您的客户经理，讨论如何使用 Delta；

我是客户经理，但找不到此设置。它在哪里？