版权声明：本文为博主原创文章，未经博主允许不得转载。https://www.jianshu.com/p/00af5eec08da
一、分析过程
1、节点“存储等待”时间长
发起一个查询job，查看该查询语句的profile文件，发现各节点的TotalStoreageWaitTime时长不一，大量节点花费较多时间在“存储等待”。
图1 imapal查询sql的TotalStoreageWaitTime
2、磁盘使用率达100%
观察集群磁盘IO使用率，如下图所示，大部分节点的磁盘使用率较高，多个节点磁盘使用率达100%。对于一个节点的单块磁盘来说，读速率峰值可达100MB/s左右，排除一些性能损耗，单节点的磁盘I/O在繁忙时预期应在70MB/s~80MB/s之间。
图2 多个磁盘使用率达100%
3、磁盘使用率高而读速率低
在运行查询作业时，执行iostat -x -m 2，单台节点磁盘I/O实时数据如下图所示，有三列需要关注：
第4列r/s列：磁盘读操作/s
第6列rMB/s：磁盘读速率
最右侧一列%util：磁盘I/O使用率
随机挑选一台节点A，在执行query时部分磁盘使用率达到了99%，对应的磁盘读操作在300次/s~500次/s，但磁盘读速率在20MB/s左右，与预期峰值70~80MB/s相距甚远，推测为有进程在频繁对该盘进行读操作，占满了磁盘使用率，导致磁盘读速率上不去。
图3 磁盘存在频繁读操作
4、top发现该节点在存在大量du进程
hdfs会定期（默认10分钟）使用du -sk命令统计BP的大小，在小文件或目录数量较多时，该操作耗时将会变长（超过10分钟），这会导致iowait以及load的提升。
图4 top发现有du进程
图5 du -sk进程在计算磁盘block信息
二、问题原因——ut_mgmas用户下存在大量小文件导致
查看HDFS使用情况，ut_mgmas用户占用文件和目录数量共计1242万个，而逻辑大小只有9.4TB，9.4T/12428786=0.75M，可知平均一个文件大小不到1M，HDFS上存在巨大数量的小文件，这是导致du耗时变长的直接原因。
目录字节原始字节文件和目录计数
图6 ut_mgmas用户存在大量小文件
图7 ut_mgmas用户目录
三、建议
1、控制单个文件大小在100MB左右
一方面：每个文件和目录会占用NameNode的内存15KB，大量的小文件很有可能造成NameNode节点的内存不足，对集群造成严重隐患影响；
另一方面：hdfs存在du机制，du时间与该盘上小文件数量呈正比，当小文件数量巨多时，du耗时也越久，磁盘使用率也就持续维持在一个很高的状态，读速率就无法上去。而impala在执行查询时，需要做全表扫描，读取hdfs上的数据，因为磁盘使用率因du进程占用，因而发生文章伊始提到的TotalStoreageWaitTime存储等待时间较长。
2、清理或合并小文件
3、更改数据存储方式
当前应用系统在HDFS上底层数据存储格式为txt，这是很不合理的一种数据存储方案，一般建议采用rcfile或parquet+snappy方式存储。一是因为txt格式存储空间占用大，数据扫描耗时很长；二是rcfile或parquet方式存储采用行列相结合的存储方式，有利于数据快速存取。三是采用snappy压缩方式，数据存储方面能节约30%以上空间，减少每次查询扫描hdfs时间。
4、通过细粒度的数据分区，较精确定位数据范围。目前业务系统是按日进行分区的，每日数据量4T，即便查询几分钟的数据还是需要扫描整个表4T的数据，建议以小时为分区键，这样可大幅提升查询性能。
网友评论