Athena Iceberg 比通常的外部表要慢大约10倍?

0

【以下的问题经过翻译处理】 我们有时间序列数据。我们通常只需要某个ID的最后一项。 当收集数据时,我们通常根据ID提取单个记录。

我们每天有大约5亿个记录,每个批次大约1000个。数据的月度大小压缩后大约为100TB。 我曾认为如果我们对每个新数据部分使用MERGE INTO,Iceberg会是一个完美的选择。

然而,在基本的基准测试之后,我发现Iceberg大约比通常的外部表慢10倍。出于简单起见,我尽量将基准测试最小化。即使是在12行表上,我的假设似乎也是正确的。

以下是基准测试:

**Iceberg**

CREATE TABLE my_test (
   my_partition bigint,
   my_data string
) 
PARTITIONED BY (
  my_partition
)
LOCATION
    's3://my-data/iceberg'
TBLPROPERTIES ( 
    'table_type' = 'ICEBERG',
    'format'='parquet'
)


insert into my_test 
values 
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(1, '一些数据'),
(2, '一些数据'),
(2, '一些数据'),
(2, '一些数据'),
(2, '匹配数据')
-- 运行时间:3.586秒


select count(*) from my_test
-- 运行时间:8.293秒

select count(*)
from my_test
where my_partition = 2
-- 运行时间:7.485秒

select *
from my_test
where my_partition = 2 and my_data = '匹配数据'
-- 运行时间:7.766秒

**外部表**

CREATE EXTERNAL TABLE my_test_non_ice (
   my_data string
) 
PARTITION
profile picture
专家
已提问 4 个月前16 查看次数
1 回答
0

【以下的回答经过翻译处理】 “ICEBERG”表使用快照和元数据文件进行操作。

在全局范围内,它以与标准的EXTERNAL表不同的方式分发文件,甚至复制数据,并且通过一组json+avro元数据知道如何正确查询数据。(因此,读取所有这些文件比通过简单的Parquet Serde读取简单的EXTERNAL TABLE要复杂。后者仅读取Parquet文件的内部元数据以进行查询。)

对于单个示例数据集,这并不太明显,但您必须考虑到,使用ICEBERG存储会根据使用快速增加。 如果执行应用多个更新和一些删除的MERGE操作,则可以快速将S3上的磁盘空间增加一倍,并且性能将变得更不高效(因为数据将被分成多个快照/文件)。

(但是,使用OPTIMIZE命令...可以将性能恢复到ICEBERG表的初始状态,通过将文件合并成一个新文件并更新元数据来忽略旧文件)

使用ICEBERG有优点(简化维护,查询分区数据而不显式条件这些分区等)和缺点(读取效率不高,存储空间迅速增加等)。

尽管我不知道如何使用个人的VACUUM和OPTIMIZE自动磁盘空间优化,但是我知道它之后使用的文件更少,并且删除不再使用的文件不会破坏我的ICEBERG表。

如果目标是尝试获得一些性能,我建议设置PARQUET的压缩方式不同...但是这可能不会改变一切。(此外,如果您已经在表上执行了多个删除/插入,请尝试优化以修复性能)

profile picture
专家
已回答 4 个月前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则