HUE配置Impala队列提交SQL

本文主要是介绍HUE配置Impala队列提交SQL，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目前，我们可以通过HUE连接到impala集群来提交SQL，进行一些数据分析和测试验证工作，非常方便，不用再额外配置beeline环境或者在java代码里面通过jdbc调用。但是，在hue上面提交SQL的时候，默认是会提交到default队列上，而线上集群往往都会根据业务设置相应的队列。因此，default上预留的资源一般不会很多，当需要跑一些比较大的SQL的时候，就需要选择相应业务的队列，否则可能会出现资源不足的问题。本文主要就是介绍了几种，在hue里面配置队列的方式，下面就一起来看一下：

Impala自动识别队列

当集群中配置了与用户名同名的队列，在提交SQL的时候，impala会优先提交到同名的队列上，而不是default上。这种情况下，我们就不需要显示地设置队列了。但是这种情况相对比较少，一般线上使用kerberos认证的时候，往往一个kerberos用户，会对应多个队列，这个时候就需要我们进行手动设置了。

通过SQL指定队列

这种方式主要就是利用了同一个session里面进行队列设置的原理，我们可以在HUE里面同时执行多条SQL来实现队列的设置功能，如下所示：

set request_pool=impala_test;
select 1;

我们只要同时执行上面的两条SQL，就可以将select 1提交到impala_test队列上。关于如何同时在HUE里面执行多条SQL，可以参考：使用HUE执行多条SQL。

但是，在实际使用过程中发现一个问题：如果多个HUE连接，都是使用同一个用户名／密码进行登录。那么，其中一个session如果进行了队列设置，其他的session在之后执行的时候，也会收到影响，会把sql提交到刚刚那个session设置的队列上，这就很有问题。为了进行测试验证，我们分别在两台电脑上用同一个用户登录，分别连接至HUE，然后在一个页面提交了set request_pool=impala_test，而在另外一个页面提交了select 2，先后执行这两条SQL，我们可以在对应的impalad页面上看到，select 2这条SQL的确是被提交到了impala_test这个队列上：

在sessions的页面也可以看到，目前确实是有两个session连接到了impalad：

通过搜索HUE的日志，我们可以发现，一开始当我们执行set操作的时候，发现日志中出现了两条相关的信息：

[17/Jul/2019 11:53:53 +0000] thrift_util DEBUG Thrift call: <class 'ImpalaService.ImpalaHiveServer2Service.Client'>.ExecuteStatement(args=(TExecuteStatementReq(confOverlay={'impala.resultset.cache.size': '50000', 'QUERY_TIMEOUT_S': '10'}, sessionHandle=TSessionHandle(
sessionId=THandleIdentifier(secret=374a10ce97565a27:a9d7cd6720c27ca0, guid=444a85f6b3bb9d61:96522b5892d4b08d)), runAsync=True, statement='set request_pool=impala_test'),), kwargs={})[17/Jul/2019 11:53:53 +0000] thrift_util DEBUG Thrift call: <class 'ImpalaService.ImpalaHiveServer2Service.Client'>.ExecuteStatement(args=(TExecuteStatementReq(confOverlay={'impala.resultset.cache.size': '50000', 'QUERY_TIMEOUT_S': '10'}, sessionHandle=TSessionHandle(
sessionId=THandleIdentifier(secret=9844668962cdce9c:decddf6b573fea83, guid=d64c1fc35fcaab49:1fff06564ec937bf)), runAsync=True, statement='set request_pool=impala_test'),), kwargs={})

也就是说，当我们同一个HUE执行一个set操作的时候，另外的一个session也一起执行了这个SQL，这可能是由于HUE本身的设计导致的，当我们执行select 2的时候，也会有相关的日志：

[17/Jul/2019 11:53:57 +0000] thrift_util DEBUG Thrift call: <class 'ImpalaService.ImpalaHiveServer2Service.Client'>.ExecuteStatement(args=(TExecuteStatementReq(confOverlay={'impala.resultset.cache.size': '50000', 'QUERY_TIMEOUT_S': '10'}, sessionHandle=TSessionHandle(
sessionId=THandleIdentifier(secret=9844668962cdce9c:decddf6b573fea83, guid=d64c1fc35fcaab49:1fff06564ec937bf)), runAsync=True, statement='select 2'),), kwargs={})

通过这个日志可以看到，select 2执行的session（就是guid），跟上面的其中一条日志的session是同一个session。但是这个语句只执行了一次，也就是说，可能只有set属性参数的时候，才会有这种问题。不仅仅是配置队列会有这样的问题，其他的属性set也会有同样的问题。为了避免这种问题，这里就需要另外一种设置队列的方式。

通过配置项指定队列

除了以上两种方式之外，我们还可以通过配置项来指定队列，具体操作方式如下所示，在HUE的impala连接页面点击配置按钮：

然后在弹出的页面填入相应的参数以及参数值，可以配置多个，这里只配置了队列选项：

配置完成之后，我们点击尖按钮，就可以收回配置页面，提交相应的SQL了，此时提交的SQL就会使用刚刚配置的若干属性值。通过这种方式指定队列，我们可以在HUE的日志中查看相应的请求信息，如下所示，这种配置方式跟上面的是截然不同的：

[17/Jul/2019 15:00:25 +0000] thrift_util DEBUG Thrift call: <class 'ImpalaService.ImpalaHiveServer2Service.Client'>.ExecuteStatement(args=(TExecuteStatementReq(confOverlay={u'request_pool': u'impala_test', 'impala.resultset.cache.size': '50000', 'QUERY_TIMEOUT_S': '10
'}, sessionHandle=TSessionHandle(sessionId=THandleIdentifier(secret=874f0be612344f6b:d03880523b05deae, guid=c2413b82dd331239:e0343e14325f1282)), runAsync=True, statement='select 1'),), kwargs={})

我们可以看到，日志中多了一个confOverlay的选项，该参数项主要传递我们在配置项中设置的参数，而且不会对其他的session产生影响，只对当前的页面有效。但是这种方式也有一定的缺点，就是退出当前登录用户或者关闭页面之后，属性就会失效，需要重新配置。不过优点就是，即使是多个客户端使用相同的用户进行登录，也不会影响。

本文主要介绍了三种方式，可以在HUE里面配置指定的impala队列来执行SQL，每种方式都有各自的优缺点。后续如果有其他更好的办法进行相应的配置，也会第一时间更新分享给大家，希望能够对大家有所帮助。

这篇关于HUE配置Impala队列提交SQL的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---