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

Question

我有 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;

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

谢谢

Answer 1

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

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

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