查看详细_0587-6.1.0-CM 管理界面中Impala 的查看SQL查询详细异常问题分析

作者：唐辉

1.文档编写目的

本篇文章主要介绍在Cloudera Manager 界面中Impala 查询详细界面显示无法检索此查询的详细信息问题的原因和解决办法

• 内容概述

1.文档说明

2.问题描述

3.问题分析

4.解决办法

• 测试环境

1.CM和CDH版本为CDH 6.1.0

2.操作系统版本为RedHat7.2

2.问题描述

在Cloudera Manager (以下简称CM)的管理界面有提供快速查看到Impala SQL 执行的界面，在CM主页面, 点击 群集>Impala个查询 或者 选择Impala>查询 都可以快速到该页面。如下

点击查询详细信息可以查看到明细，包括查询计划和详细信息等

但是查看时间更久之前的SQL明细显示异常如下：

3.问题分析

在分析上述问题之前，我们需要知道CM上显示的Impala的查询明细的数据来源，默认是存放在/var/lib/cloudera-service-monitor/impala目录下, firehose_impala_storage_bytes默认存储大小为1GB。在CM 界面点击Clouera Manager Service >实例>Service Monitor >配置>搜索 Impala

work_details 目录存的是查询明细，如果该目录没有数据，那么Impala 查看明细就会出现上述异常信息，目录下的该数据是加密的，这里不具体查看。

work_summary 目录存的是汇总，如果该目录没有数据，那么Impala 查询中将看不到数据，因为该目录下的数据是加密的，这里不具体查看。

为了验证上述说明，验证如下，移走work_summary 目录

mv work_summary work_summarybak

重启Service Monitor后查看，发现近30天的数据都没有了。

然后将work_summary 目录还原，用来恢复数据

rm -rf work_summarymv work_summarybak work_summary

重启Service Monitor后再查看，Impala查询列表数据恢复

接下来重现Impala 查询详细界面显示无法检索此查询的详细信息异常

mv work_details work_ detailsbak

重启Service Monitor后再再点击查询详细信息

上述异常重现，到这里基本可以验证我们上面的说法。

rm -rf work_detailsmv work_ detailsbak work_ details

再重现还原目录用来恢复数据，重启Service Monitor后再点击查询详细信息

然后验证firehose_impala_storage_bytes默认存储大小为1GB的问题，将/var/lib/cloudera-service-monitor/impala/work_details/partitions目录下的profiles_2019-02-24T18:25:26.774Z 目录大小占用大于1GB

然后重启Service Monitor后，执行SQL，再去查看明细

SELECT * FROM default.wk_test_client LIMIT 5;DESCRIBE wk_test_client;

发现刚刚执行的SQL的是明细是可以正常查看的

而之前的点击查看明细已经没有反应，鼠标已经无法选中查看查询详细信息

再去查看该目录下已经重新生成了一个目录，发现之前的用于存放SQL明细的数据的 profiles_2019-02-24T18:25:26.774Z 目录除了拷贝过来占用空间的包，已经没有其他数据了，只有profiles_2019-03-28T09:20:33.317Z 目录下有SQL明细的数据

4.解决方法

根据上面的分析，我们已经确认在CM界面Impala的查询明细的数据来源默认是存放在/var/lib/cloudera-service-monitor/impala目录下,而无法查询明细是由于数据不存在造成的，所以如果想保存更久的数据，那么将firehose_impala_storage_bytes 这个参数值默认1GB调更大一些，并且不要随意删除该目录下的数据。