时间戳

首页 > 解决方案 > 在从 s3 到 vertica 的分隔文件上加载 parquet 文件时 Vertica 性能下降

performance - 在从 s3 到 vertica 的分隔文件上加载 parquet 文件时 Vertica 性能下降

问题描述

我有 20 亿条 GZIP 压缩记录的镶木地板文件和 SNAPPY 压缩相同的数据。此外，我有相同的 20 亿条记录的分隔文件。我们在 AWS 产品中有 72 个 Vertica 节点，我们看到 parquet 文件的性能大幅提升，同时使用 COPY 命令将数据从 s3 移动到 Vertica，而不是使用分隔文件。Parquet 比 Delimited 文件多花费 7 倍的时间，尽管分隔文件的大小是 Parquet 的 50 倍。

以下是我们进行的测试的统计数据。

在此处输入图像描述

总文件大小为

镶木地板 GZIP - 6 GB

Parquet Snappy - 9.2 GB

分隔 - 450GB

下面是用于 Parquet 和 Delimited 的复制命令。当我们在复制查询中删除“无提交”时，我们确实看到了大约 2 分钟的改进。

分隔文件

COPY schema.table1 ( col1,col2,col3,col4,col5 ) FROM 's3://path_to_delimited_s3/*' DELIMITER E'\001' NULL AS '\N' NO ESCAPE ABORT ON ERROR DIRECT NO COMMIT;

镶木地板文件

COPY schema.table2 (col1,col2,col3,col4,col5 ) FROM 's3://path_to_parquet_s3/*' PARQUET ABORT ON ERROR DIRECT NO COMMIT;

我们很惊讶地看到这个尖峰 wrt parquet 文件，这是 parquet 副本的预期吗？任何指示，想法都会非常有帮助。

谢谢

标签： performanceamazon-s3bigdatavertica

解决方案

不知道更多，很难回答。您应该再次监视 LOAD_STREAMS 以了解发生了什么。

一个原因可能是s3://path_to_parquet_s3/*CSV 版本中的各种文件在加载过程的节点之间以最佳方式分布，因此大大提高了并行性。

要计算解析线程的数量 - 在您的负载运行时，找到您正在运行的 LOAD_STREAM ( WHERE is_executing...)，然后将其与 LOAD_SOURCES - 连接起来USING(transaction_id,statement_id)。

推荐阅读