impala 的资源管理

深碍√TFBOYSˉ_ 2023-06-28 06:07 6阅读 0赞

impala的资源管理并不依赖yarn，对于MPP架构的系统，它的查询响应时间由最慢的节点运行时间决定，而为了提升查询性能，又需要尽可能多的节点参与计算，而YARN上的任务每次都是启动一个新的进程，启动进程的时间对于批处理任务是可以接受的，毕竟这种任务运行时间比较久，而对于追求低延迟的Ad-hoc查询而言代价有点大了，很可能出现进程启动+初始化时间大于真正运行的时间。

impala有一套自己的资源管理模块Admission Control，这是个去中心化的资源管理系统，它嵌入到了集群中的每个impala daemon中发挥作用。尽管Admission Control对整个impala集群的资源使用作出限制，每个impala daemon还是会自己决定它上面的查询是立即执行还是进入等待队列。

# Admission Control 与查询队列 #

Admission control 是impala的一个功能，它的作用是给SQL查询加限制，防止集群繁忙的时候资源使用到达峰值或者内存溢出。Admission control为查询设置并发上限以及内存使用限制。在限制之外的查询将会进入等待队列，等正在执行的查询结束之后，队列中的查询才会启动。

在2.5及2.5以上的版本中，可以为每个队列设置限制，而不是只能为全局设置限制。通过这种方式可以在稳定的负载和密集型查询之间平衡资源使用和吞吐量。

除了能设置正在执行的查询个数的限制，还可以设置队列中等待执行的查询个数的限制，设置查询在队列中等待的超时时间。这些设置能够保证查询不会在队列中永久等待。

查询，DML语句，以及包括CREATE TABLE AS SELECT 和 COMPUTE  
STATS在内的部分DDL语句都受Admission control的控制。

在一个繁忙的集成上，需要找到一个最优的查询并发数。比如，当集群的IO资源被IO密集型的查询占满之后，加大查询的并发数并不能提高查询性能。我们需要让部分查询全速执行的同时，让其他的查询在队列中等待。而不是让所有查询同时执行，竞争资源，从而导致每个查询都很慢。因此Admission control能够带来更高的吞吐量。

再举个例子，我们考虑join,聚合这种消耗内存资源的查询。每个这种查询都会短暂地占用很多G的内存去处理中间结果。默认情况下，当查询使用的内存查过了限制的阈值，Impala会取消查询。因此，如果同时起很多这种查询，如果超过内存限制，可能需要重跑那些被取消的查询。  
在这种场景下，Admission control 会在保证不超出内存限制的前提下，尽可能跑多的查询，从而保证查询的可靠性和稳定性。

## Concurrent Queries and Admission Control ##

一种通过Admission Control限制资源使用的方法是设置一个并发数量的上限，可以为每个动态资源池分别指定设置。

#### Max Running Queries ####

资源池上允许的最大查询并发数，impala2.5及2.5版本以上默认是不限制的。该池子上的任何超过最大并发查询数的查询都会进入队列中等待，直到其他查询结束才会启动执行。当Max Running Queries Multiple有设置时，这个配置不生效。

#### Max Running Queries Multiple ####

这个配置是一个float类型，它的值乘以executors 的个数就是Max Running Queries。executors 就是一个impalad。因此这个配置的影响与executors的数量有关。相乘的结果是向上取整的，因此结果至少为1。如果这个配置被设置为0或者负数，则无效。

#### Max Queued Queries ####

资源池上允许的最大队列大小。在impala2.1及以上版本，这个配置的默认值是200，小于2.1的版本默认值是50。当Max Queued Queries Multiple有设置时，这个配置不生效。

#### Max Queued Queries Multiple ####

这个配置是一个float类型，它的值乘以executors 的个数就是Max Queued Queries。executors 就是一个impalad。因此这个配置的影响与executors的数量有关。相乘的结果是向上取整的，因此结果至少为1。如果这个配置被设置为0或者负数，则无效。

#### Queue Timeout ####

这个配置是时间的值，单位是毫秒，它控制队列中等待的查询的超时时间。等待的时间超过这个值查询将会被取消。默认值是60000毫秒。

# Memory Limits and Admission Control #

每个动态资源池都可以为查询使用的群集范围的内存设置一个上限。通过下列的配置可以管理基于内存的Admission Control。

#### Max Memory ####

资源池上所有查询能够使用集群中的最大内存数量。为这个配置设置一个非零的值就启动了基于内存的Admission Control。如果有查询执行后内存的使用量会超过这个值，那么这个查询将不会执行。在fair-scheduler.xml中通过maxResources标签设置Max Memory。例如：

如果设置了Max Memory，也应该设置每个查询使用的内存。可以通过以下两种方法设置：

*  设置Maximum Query Memory Limit 和 Minimum Query Memory Limit
 *  设置Default Query Memory Limit

如果Max Memory Multiple被设置了，Max Memory的设置将会被忽略。

#### Max Memory Multiple ####

这个配置的值的单位是bytes,它的值乘以executors 的个数就是Max Memory,因此这个配置的影响与executors的数量有关。如果这个配置被设置为0或者负数，则无效。

#### Minimum Query Memory Limit and Maximum Query Memory Limit ####

这两个配置确定每个主机分配给资源池上的查询的内存限制的最小值和最大值。如果设置了，Admission Control就会在最大值和最小值之间选一个值作为查询的内存限制。在节点上的查询使用的内存如果即将超过这个内存限制，后面的查询将会进入等待队列。

Minimum Query Memory Limit 必须小于Maximum Query Memory Limit。

用户可以通过设置 MEM\_LIMIT 查询参数来覆盖Minimum Query Memory Limit and Maximum Query Memory Limit。如果 Clamp MEM\_LIMIT Query Option 配置为TRUE，并且用户查询时设置MEM\_LIMIT的值超出了Minimum Query Memory Limit and Maximum Query Memory Limit的范围，那么节点的内存限制值将会变成Minimum Query Memory Limit或者Maximum Query Memory Limit。

举个例子，假设一个资源池的配置如下：  
• Minimum Query Memory Limit = 2GB  
• Maximum Query Memory Limit = 10GB

一个用户在这个资源池上提交查询，并且MEM\_LIMIT设置为14G，就会发生下面两种情况：

*  如果Clamp MEM\_LIMIT Query Option = true，admission controller 会将MEM\_LIMIT覆盖为10G。
 *  如果Clamp MEM\_LIMIT Query Option = false，admission controller 会将MEM\_LIMIT保留为14G

#### Default Query Memory Limit ####

当查询不指定MEM\_LIMIT时，默认使用Default Query Memory Limit的值。如果Maximum Query Memory Limit 或者 Minimum Query Memory Limit已经设置了，不要设置这个配置。

#### Clamp MEM\_LIMIT Query Option ####

如果这个配置为false, 查询时MEM\_LIMIT的配置不会受限于Minimum Query Memory Limit 和 Maximum Query Memory Limit。在impala3.1及以上版本中这个配置默认为true。

为了便于理解上面的配置，举个例子：

*  集群有5个节点，每个节点上都运行了impalad daemons
 *  一个动态资源池的Max Memory=100G
 *  Maximum Query Memory Limit=10G，Minimum Query Memory Limit=2G。因此任何一个在这个资源池上的查询最多可以使用50G的内存 (Maximum Query Memory Limit \*节点数)
 *  由于集群的内存使用量最多不超过100G,5个节点，平均每个节点内存使用量最多不超过20G。由于每个查询使用的内存大小限制介于2~10G之间。因此，两种极端的情况是一个节点能够同时跑10个2G的查询，或者2个10G的查询。

我们可以将基于并发数的限制和基于内存的限制配合起来使用，查询超过任一限制都会进入等待队列。

# 设置单个查询的内存限制 #

设置单个查询的内存限制可以防止查询使用过多内存，影响其他的查询。建议任何时候都尽可能设置单个查询的内存限制。通过

set MEM_LIMIT=10g；

这样的语句可以设置单个查询的内存限制

# 动态资源池的配置 #

配置动态资源池可以在impala中队列多个资源池，为每个资源池分配资源限制，以及用户访问权限。  
动态资源池的配置通过

*  fair-scheduler.xml
 *  llama-site.xml

两个配置文件实现。其中fair-scheduler.xml 负责配置允许访问资源池的有户和用户组，以及给资源池分配的最大内存与核数。下面是一个fair-scheduler.xml的例子：

<allocations>
            <queue name="root">
                    <aclSubmitApps> </aclSubmitApps>
                    <queue name="default">
                            <maxResources>50000 mb, 0 vcores</maxResources>
                            <aclSubmitApps>*</aclSubmitApps>
                    </queue>
                    <queue name="development">
                            <maxResources>200000 mb, 0 vcores</maxResources>
                            <aclSubmitApps>user1,user2 group1,group2</aclSubmitApps>
                    </queue>
            </queue>
            <queuePlacementPolicy>
                    <rule name="specified" create="false"/>
                    <rule name="default" />
            </queuePlacementPolicy>
    </allocations>

以上配置中，我们配置了两个资源池，名称分别为default,development。

*  default队列中分配了50000mb的最大使用内存（就是上面提到的Max Memory）；o vcores则表示不对核数使用做限制。aclSubmitApps标签控制可以访问该资源池的用户与用户组，\*表示任何用户与用户组都可以访问default资源池。
 *  development队列中分配了200000 mb的Max Memory，同样不对核数做限制。只对用户user1,user2;用户组group1,group2开放使用。该表达式的规则是用户组和用户用空格号隔开，前面是用户，后面是用户组。用户与用户之间用“,”隔开，用户组与用户组之间用“,”隔开。

fair-scheduler.xml中只划分了一个资源池的最大内存使用，对于前面提到更细粒度的内存限制以及队列的限制的配置则没有设置。这些细粒度的配置都是在llama-site.xml中完成的，例子如下：

<?xml version="1.0" encoding="UTF-8"?>
    <configuration>
            <property>
                    <name>llama.am.throttling.maximum.placed.reservations.root.default</name>
                    <value>10</value>
            </property>
            <property>
                    <name>llama.am.throttling.maximum.queued.reservations.root.default</name>
                    <value>50</value>
            </property>
            <property>
                    <name>impala.admission-control.pool-default-query-options.root.default</name>
                    <value>mem_limit=128m,query_timeout_s=20,max_io_buffers=10</value>
            </property>
            <property>
                    <name>impala.admission-control.pool-queue-timeout-ms.root.default</name>
                    <value>30000</value>
            </property>
            <property>
                    <name>impala.admission-control.max-query-mem-limit.root.development</name>
                    <value>1610612736</value>
            </property>
            <property>
                    <name>impala.admission-control.min-query-mem-limit.root.development</name>
                    <value>52428800</value>
            </property>
            <property>
                    <name>impala.admission-control.clamp-mem-limit-query-option.root.development</name>
                    <value>true</value>
            </property>
    </configuration>

以上配置的末尾都跟着资源池名称，以表示该配置作用于哪个资源池。下面对这些配置的作用一一说明：

*  llama.am.throttling.maximum.placed.reservations.root.default：default资源池上最大并发查询数的默认值
 *  llama.am.throttling.maximum.queued.reservations.root.default：default资源池上队列的最大值的默认值
 *  impala.admission-control.pool-default-query-options.root.default：default资源池上查询的默认配置参数，可以配置多个参数，用“,”隔开
 *  impala.admission-control.pool-queue-timeout-ms.root.default：default资源池上查询排队的超时时间，对应上面提到的 **Queue Timeout**
 *  impala.admission-control.max-query-mem-limit.root.development：development资源池上，查询内存使用上限的最大值，对应上面提到的**Maximum Query Memory Limit**
 *  impala.admission-control.min-query-mem-limit.root.development：development资源池上，查询内存使用上限的最小值，对应上面提到的**Minimum Query Memory Limit**
 *  impala.admission-control.clamp-mem-limit-query-option.root.development：development的Clamp MEM\_LIMIT Query Option配置

下面列的是上面提到过的配置对应的llama-site.xml中的配置

<table> 
 <thead> 
  <tr> 
   <th>术语</th> 
   <th>llama-site</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Max Running Queries</td> 
   <td>llama.am.throttling.maximum.placed.reservations</td> 
  </tr> 
  <tr> 
   <td>Max Running Queries Multiple</td> 
   <td>impala.admission-control.max-running-queries-multiple</td> 
  </tr> 
  <tr> 
   <td>Max Queued Queries</td> 
   <td>llama.am.throttling.maximum.queued.reservations</td> 
  </tr> 
  <tr> 
   <td>Max Queued Queries Multiple</td> 
   <td>impala.admission-control.max-queued-queries-multiple</td> 
  </tr> 
  <tr> 
   <td>Queue Timeout</td> 
   <td>impala.admission-control.pool-queue-timeout-ms</td> 
  </tr> 
  <tr> 
   <td>Max Memory Multiple</td> 
   <td>impala.admission-control.max-memory-multiple</td> 
  </tr> 
  <tr> 
   <td>Minimum Query Memory Limit</td> 
   <td>impala.admission-control.min-query-mem-limit</td> 
  </tr> 
  <tr> 
   <td>Maximum Query Memory Limit</td> 
   <td>impala.admission-control.max-query-mem-limit</td> 
  </tr> 
  <tr> 
   <td>Clamp MEM_LIMIT Query Option</td> 
   <td>impala.admission-control.clamp-mem-limit-query-option</td> 
  </tr> 
  <tr> 
   <td>Default Query Memory Limit</td> 
   <td>impala.admission-control.pool-default-query-options</td> 
  </tr> 
 </tbody> 
</table>

## 动态资源池的配置步骤 ##

1.  编辑fair-scheduler.xml，llama-site.xml配置文件，假设文件存在/etc/cluster001/SERVICE-IMPALA-retro-1/ 目录下
2.  配置 impalad的启动指向步骤1的配置文件参数如下

-fair_scheduler_allocation_path=/etc/cluster001/SERVICE-IMPALA-retro-1/fair-scheduler.xml
    -llama_site_path=/etc/cluster001/SERVICE-IMPALA-retro-1/llama-site.xml

1.  重启impalad，验证动态资源池的配置是否生效
2.  在impala上执行 set request\_pool=development 现在资源池
3.  提交任意查询请求
4.  打开impala的 admission control的web 页面查看配置 http://ip:25000/admission  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxcXEwMTk5MTgx_size_16_color_FFFFFF_t_70]  
    从页面中可以看出资源配置已经生效。

# 参考 #

[Impala源码之资源管理与资源隔离][Impala]

[CDH5.14 Impala的静态资源和动态资源设置][CDH5.14 Impala]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxcXEwMTk5MTgx_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200115162912707.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxcXEwMTk5MTgx,size_16,color_FFFFFF,t_70
[Impala]: https://www.cnblogs.com/163yun/p/9004109.html
[CDH5.14 Impala]: https://blog.csdn.net/silentwolfyh/article/details/83549202