大的压缩文件对Impala查询性能的影响

3 月，跳不动了？>>>

Hadoop/HDFS/MapReduce/Impala被设计用于存储和处理大量文件的场景，比如TB或者PB级别数据量的文件。大量小文件对查询性能有很大的影响，因为NameNode要保存大量的HDFS文件元数据，一次性查询很多分区或者文件的话，需要获取文件列表并一个个读取文件信息，不仅会对查询性能造成很大的影响，还可能会超过操作系统的文件描述符数量限制而导致查询失败。

因此，这就意味着我们要尽可能让文件保持很大吗？当然不是。大文件对表的性能也会有影响，原因是在大多数情况下，Hadoop用户会压缩存储在HDFS中的数据，这样虽然可以节省磁盘空间，但是如果你有一个大的压缩文件，花费在解压上的时间也会导致查询变慢。

为了证明上面的说法，我在CDH环境中做了以下测试：

1、我准备了一个565M的普通Text格式的文件和一个使用bzip2压缩方式压缩的135M的文件，文件下载链接：Kaggle’s Flight Delay Dataset

2、我用4个这样的bzip2文件创建了一个名为bzip2_smallfiles_4的表，用8个这样的文件创建了另一个名为bzip2_smallfiles_8的表

3、然后，我还将这个文本文件合并4次，生成一个文本文件，使用bzip2对其进行压缩，大小变为大约510MB，并在其上创建了一个名为bzip2_bigfile_4的表

4、和3是一样的。但我将文件合并了8次，使其变大，压缩后文件大小为1.1GB，并创建了一个名为bzip2_bigfile_8的新表

5、然后，我对这4个表逐个运行“SELECT COUNT(*) FROM”查询来比较结果

毫无疑问，我看到对表bzip2_bigfile_8的查询是最慢的。以下是对这四张表的测试数据：

bzip2_smallfiles_4：

a. 4台主机运行查询 b. 查询运行时间大约53秒 c. 最大扫描时间52秒 d. 最大解压时间为49秒

Operator       Hosts  Avg Time  Max Time   #Rows  Est. #Rows  Peak Mem  Est. Peak Mem  Detail 
00:SCAN HDFS        4  26s464ms  52s687ms  23.28M          -1  40.32 MB      160.00 MB  test.bzip2_smallfiles_4

    Query Timeline
...
      Rows available: 53.86s (53861836202)
      First row fetched: 53.87s (53869836178)
      Unregister query: 53.87s (53874836163)

    Fragment F00
      Instance fc48dc3e014eb7a5:7d7a2dc100000004 (host=xxxx:22000)
        AGGREGATION_NODE (id=1)
          HDFS_SCAN_NODE (id=0)
            File Formats: TEXT/BZIP2:2 
            - DecompressionTime: 49.45s (49449847498)

bzip2_smallfiles_8：

a. 4台主机运行查询 b. 查询运行时间大约54.69秒 c. 最大扫描时间54.196秒 d. 最大解压时间为51.18秒

Operator       Hosts  Avg Time  Max Time   #Rows  Est. #Rows  Peak Mem  Est. Peak Mem  Detail 
00:SCAN HDFS        4  52s514ms  54s196ms  46.55M          -1  40.32 MB      160.00 MB  test.bzip2_smallfiles_8 

    Query Timeline
...
      Rows available: 54.36s (54359822792)
      First row fetched: 54.68s (54683821736)
      Unregister query: 54.69s (54688821720)

    Fragment F00
      Instance 5642f67b9a975652:c19438dc00000004 (host=xxxx:22000)
        AGGREGATION_NODE (id=1)
          HDFS_SCAN_NODE (id=0)
            File Formats: TEXT/BZIP2:2 
            - DecompressionTime: 51.18s (51183849937)

bzip2_bigfile_4：

a. 4台主机运行查询 b. 查询运行时间大约1分50秒 c. 最大扫描时间为1分49秒 d. 最大解压时间为1分7秒

Operator       Hosts  Avg Time  Max Time   #Rows  Est. #Rows  Peak Mem  Est. Peak Mem  Detail 
00:SCAN HDFS        4  27s394ms      1m49s  23.28M          -1  40.15 MB      176.00 MB  test.bzip2_bigfile_4 

    Query Timeline
...
      Rows available: 1.8m (109781665214)
      First row fetched: 1.8m (110408663300)
      Unregister query: 1.8m (110413663284)

    Fragment F00
      Instance 4545c110dbca4c9c:6cd1db1100000004 (host=xxxx:22000)
        AGGREGATION_NODE (id=1)
          HDFS_SCAN_NODE (id=0)
            File Formats: TEXT/BZIP2:2 
            - DecompressionTime: 1.7m (104339662922)

bzip2_bigfile_8：

a. 4台主机运行查询 b. 查询运行时间大约3分6秒 c. 最大扫描时间为3分35秒 d. 最大解压时间为3分4秒

Operator       Hosts  Avg Time  Max Time   #Rows  Est. #Rows  Peak Mem  Est. Peak Mem  Detail 
00:SCAN HDFS        4  53s902ms      3m35s  46.55M          -1  40.32 MB      176.00 MB  test.bzip2_bigfile_8 

    Query Timeline
...
      Rows available: 3.6m (215992297509)
      First row fetched: 3.6m (216480295920)
      Unregister query: 3.6m (216484295907)

    Fragment F00
      Instance 8f42a3b6ca6cf1cf:72fd65e100000004 (host=xxxx:22000)
        AGGREGATION_NODE (id=1)
          HDFS_SCAN_NODE (id=0)
            File Formats: TEXT/BZIP2:2
             - DecompressionTime: 3.4m (203596406406)

我选择bzip2压缩格式的原因是因为bzip2是可分割的，我所有的测试查询都是使用4台主机来运行的，即使是对于那两个大的bzip2文件也是如此。

正如我们所看到的，为了让Impala读取最大的1.1GB bzip2文件，解压这个文件几乎需要4分钟。对于表bzip2_smallfiles_8，虽然我们有更多的文件需要解压，但是因为我们可以在多个主机上并行执行解压操作，这也不会对性能造成太大影响。

综上所述，太多的小文件(比如KB或者比较小的MB文件)在Hadoop中是不允许的，然而，文件太少而压缩大小太大也是不好的。理想情况下，我们应该使文件大小尽可能接近块大小(在CDH中默认为256MB)，以便优化性能。

编译自：BIG COMPRESSED FILE WILL AFFECT QUERY PERFORMANCE FOR IMPALA

来源：oschina

链接：https://my.oschina.net/dabird/blog/3207801

标签

HDFS

impala