我有一个ETL作业,我想将.csv文件中的数据附加到Impala表中。目前,我通过使用新数据(.csv.lzo格式)创建临时外部.csv表来执行此操作,之后将其插入主表中。
我使用的查询如下所示:
INSERT INTO TABLE main_table
PARTITION(yr, mth)
SELECT
*,
CAST(extract(ts, "year") AS SMALLINT) AS yr,
CAST(extract(ts, "month") AS TINYINT) AS mth
FROM csv_table
其中main_table
定义如下(几列被截断):
CREATE TABLE IF NOT EXISTS main_table (
tid INT,
s1 VARCHAR,
s2 VARCHAR,
status TINYINT,
ts TIMESTAMP,
n1 DOUBLE,
n2 DOUBLE,
p DECIMAL(3,2),
mins SMALLINT,
temp DOUBLE
)
PARTITIONED BY (yr SMALLINT, mth TINYINT)
STORED AS PARQUET
数据大约为几GB(5500万行,大约30列),这需要一个多小时才能运行。我很好奇为什么会出现这种情况(因为这对于一些本质上是附加操作的东西来说似乎相当长),并且在查询计划中遇到了这个问题:
F01:PLAN FRAGMENT [HASH(CAST(extract(ts, 'year') AS SMALLINT),CAST(extract(ts, 'month') AS TINYINT))] hosts=2 instances=2
| Per-Host Resources: mem-estimate=1.01GB mem-reservation=12.00MB thread-reservation=1
WRITE TO HDFS [default.main_table, OVERWRITE=false, PARTITION-KEYS=(CAST(extract(ts, 'year') AS SMALLINT),CAST(extract(ts, 'month') AS TINYINT))]
| partitions=unavailable
| mem-estimate=1.00GB mem-reservation=0B thread-reservation=0
|
02:SORT
| order by: CAST(extract(ts, 'year') AS SMALLINT) ASC NULLS LAST, CAST(extract(ts, 'month') AS TINYINT) ASC NULLS LAST
| materialized: CAST(extract(ts, 'year') AS SMALLINT), CAST(extract(ts, 'month') AS TINYINT)
| mem-estimate=12.00MB mem-reservation=12.00MB spill-buffer=2.00MB thread-reservation=0
| tuple-ids=1 row-size=1.29KB cardinality=unavailable
| in pipelines: 02(GETNEXT), 00(OPEN)
|
01:EXCHANGE [HASH(CAST(extract(ts, 'year') AS SMALLINT),CAST(extract(ts, 'month') AS TINYINT))]
| mem-estimate=2.57MB mem-reservation=0B thread-reservation=0
| tuple-ids=0 row-size=1.28KB cardinality=unavailable
| in pipelines: 00(GETNEXT)
|
显然,大部分时间和资源都用于对分区键进行排序:
Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
02:SORT 2 17m16s 30m50s 55.05M -1 25.60 GB 12.00 MB
01:EXCHANGE 2 9s493ms 12s822ms 55.05M -1 26.98 MB 2.90 MB HASH(CAST(extract(ts, 'year') AS SMALLINT),CAST(extract(ts, 'month') AS TINYINT))
00:SCAN HDFS 2 51s958ms 1m10s 55.05M -1 76.06 MB 704.00 MB default.csv_table
为什么Impala必须这样做?有没有办法分区表而不必对分区键进行排序,或者在我的情况下加速它的方式,我试图追加的整个.csv文件只有1或2个分区键?
编辑:事实证明,这很可能是因为我使用的是Parquet文件格式。我的问题仍然适用:当我知道实际上几乎不需要排序时,有没有办法加快排序速度?
相比之下,像SELECT COUNT(*) FROM csv_table WHERE extract(ts, "year") = 2018 AND extract(ts, "month") = 1
这样的操作需要大约2-3分钟,而ORDER BY
(在插入期间完成)需要一个多小时。该示例仅具有键(2018,1)和(2018,2)。
Impala执行排序,因为您使用动态分区。特别是对于具有计算机统计数据的表格,impala在动态分区方面表现不佳。我建议你在动态分区的情况下使用配置单元。如果您不打算使用配置单元,我的建议是:
INSERT INTO TABLE main_table PARTITION(yr=2019, mth=2) SELECT * FROM csv_table where CAST(extract(ts, "year") AS SMALLINT)=2019 and CAST(extract(ts, "month") AS TINYINT)=2; INSERT INTO TABLE main_table PARTITION(yr, mth) SELECT *, CAST(extract(ts, "year") AS SMALLINT), CAST(extract(ts, "month") AS TINYINT) FROM csv_table where CAST(extract(ts, "year") AS SMALLINT)!=2019 and CAST(extract(ts, "month") AS TINYINT)!=2;
这些语句缩小了动态分区处理的集合。并且预计会减少花费的总时间。