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。例如:
<maxResources>2500 mb</maxResources>
如果設置了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中的配置
術語 | llama-site |
---|---|
Max Running Queries | llama.am.throttling.maximum.placed.reservations |
Max Running Queries Multiple | impala.admission-control.max-running-queries-multiple |
Max Queued Queries | llama.am.throttling.maximum.queued.reservations |
Max Queued Queries Multiple | impala.admission-control.max-queued-queries-multiple |
Queue Timeout | impala.admission-control.pool-queue-timeout-ms |
Max Memory Multiple | impala.admission-control.max-memory-multiple |
Minimum Query Memory Limit | impala.admission-control.min-query-mem-limit |
Maximum Query Memory Limit | impala.admission-control.max-query-mem-limit |
Clamp MEM_LIMIT Query Option | impala.admission-control.clamp-mem-limit-query-option |
Default Query Memory Limit | impala.admission-control.pool-default-query-options |
動態資源池的配置步驟
- 編輯fair-scheduler.xml,llama-site.xml配置文件,假設文件存在/etc/cluster001/SERVICE-IMPALA-retro-1/ 目錄下
- 配置 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
- 重啓impalad,驗證動態資源池的配置是否生效
- 在impala上執行 set request_pool=development 現在資源池
- 提交任意查詢請求
- 打開impala的 admission control的web 頁面查看配置 http://ip:25000/admission
從頁面中可以看出資源配置已經生效。