版權聲明：本文為博主原創(chuàng)文章揭绑，未經(jīng)博主允許不得轉(zhuǎn)載站绪。http://www.reibang.com/p/979eca668755

生產(chǎn)在線集群impala查詢爬坑，多個作業(yè)超時

現(xiàn)象：

1、業(yè)務方反饋impala查詢失敗忧陪，未返回結果怯疤；

2浆洗、可看到CM頁面上大量impala查詢語句正在運行，持續(xù)時間>5m（已超時集峦，該值為impala admission control的timeout參數(shù)伏社，可設置）

【分析過程】

對于一條超時語句抠刺，在default隊列上進行測試，

名稱 ? ? ? ? ? ?最大內(nèi)存 ? ? ? ? ? ?最大運行查詢 ? ? 最大隊列查詢 ? ? ?Queue Timeout ? Default Query Memory Limit

default ? ? ? ?100 吉字節(jié) ? ? ? ? ? ? ? ? ? 2 ? ? ? ? ? ? ? ? ? ? ? ? 200 ? ? ? ? ? ? ? ? ? ? ? ? ?1 分鐘 ? ? ? ? ? ? ? ? ? ? ? 2 吉字節(jié)

執(zhí)行

[IP:21000] > set request_pool=default;

REQUEST_POOL set to default

對其中一張表做compute stats摘昌，得到該表的分區(qū)和列數(shù)——【COMPUTE STATS可用來收集涉及到的所有表的統(tǒng)計信息速妖，并讓Impala基于每一個表的大小、每一個列不同值的個數(shù)聪黎、等等信息自動的優(yōu)化查詢买优，impala查詢時計算內(nèi)存消耗會更加準確】

[IP:21000] > compute stats gl_hisdb.tbl_orhis_trans_log;

Query: compute stats gl_hisdb.tbl_orhis_trans_log

+--------------------------------------------+

| summary? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

+--------------------------------------------+

| Updated 143 partition(s) and 61 column(s). |

+--------------------------------------------+

Fetched 1 row(s) in 74.17s

[IP:21000] > show table stats gl_hisdb.tbl_orhis_trans_log;? ? （做了compute stats之后的表）

Query: show table stats gl_hisdb.tbl_orhis_trans_log

+--------------+----------+--------+----------+--------------+-------------------+---------+-------------------+----

| hp_settle_dt | #Rows? ? | #Files | Size? ? | Bytes Cached | Cache Replication | Format? | Incremental stats | Location? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

+--------------+----------+--------+----------+--------------+-------------------+---------+-------------------+----

| 20180813? ? | 338489? | 1? ? ? | 28.92MB? | NOT CACHED? | NOT CACHED? ? ? ? | RC_FILE | false? ? ? ? ? ? | hdfs://nameservice/user/dw_hbkal/db/gl_hisdb/tbl_orhis_trans_log/hp_settle_dt=20180813 |

…………………………………………

【同時可以做show column stats 表名】

查看執(zhí)行計劃

[IP:21000] > explain SELECT COUNT(*), hp_settle_dt FROM gl_hisdb.tbl_orhis_trans_log GROUP BY hp_settle_dt;

Query: explain SELECT COUNT(*), hp_settle_dt FROM gl_hisdb.tbl_orhis_trans_log GROUP BY hp_settle_dt

+-----------------------------------------------------------+

| Explain String? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

+-----------------------------------------------------------+

| Estimated Per-Host Requirements: Memory=132.00MB VCores=2 |

|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |

…………

| 00:SCAN HDFS [gl_hisdb.tbl_orhis_trans_log]? ? ? ? ? ? ? |

|? ? partitions=143/143 files=144 size=6.35GB? ? ? ? ? ? ? |

+-----------------------------------------------------------+

Fetched 16 row(s) in 0.02s

可知，該語句運行所需單節(jié)點內(nèi)存大小132M

手工執(zhí)行查詢語句：

[IP:21000] > SELECT COUNT(*), hp_settle_dt FROM gl_hisdb.tbl_orhis_trans_log GROUP BY hp_settle_dt;

Query: select COUNT(*), hp_settle_dt FROM gl_hisdb.tbl_orhis_trans_log GROUP BY hp_settle_dt

Query submitted at: 2019-01-03 10:27:55 (Coordinator: http://hostname:25000)

ERROR: Rejected query from pool root.default : request memory needed 234.00 GB is greater than pool max mem resources 100.00 GB.

Use the MEM_LIMIT query option to indicate how much memory is required per node. The total memory needed is the per-node MEM_LIMIT times the number of nodes executing the query. See the Admission Control documentation for more information.

[IP:21000] >

查詢失敗的提示為 request memory needed 234.00 GB is greater than pool max mem resources 100.00 GB.

該查詢語句估算需消耗隊列234G內(nèi)存資源挺举，大于該隊列內(nèi)存資源上限100G，因此提示可用資源不足而報錯烘跺。

應用方在執(zhí)行該查詢前指定了tqueue湘纵，該資源隊列資源上限為300g，是大于234G的滤淳，因此該查詢作業(yè)可被提交梧喷，在impala頁面顯示為運行狀態(tài)，但由于tqueue隊列上運行的作業(yè)往往多個脖咐，因此會出現(xiàn)排隊現(xiàn)象铺敌，而后續(xù)作業(yè)等待時間在超過queue timeout時間（5分鐘）后便會失敗。依次類推屁擅。

ps：default的Default Query Memory Limit為2G偿凭，因此可推算出該查詢是分配在234/2=117個節(jié)點上運行。集群中共有145個impala daemon派歌，而該表的partitions是143個弯囊，非均勻分布在117個節(jié)點上。

在動態(tài)資源池impala中胶果，有兩個參數(shù)需關注：第一個參數(shù)是資源隊列的最大內(nèi)存匾嘱；第二個參數(shù)是Default Query Memory Limit

第一個參數(shù)是對整個資源池進行資源限定，是一個集群范圍的限制早抠，它根據(jù)每個主機的Default Query Memory Limit（查詢內(nèi)存上限）乘以集群中的IMPALA節(jié)點數(shù)來確定可以同時安全運行多少查詢霎烙。

第二個參數(shù)引用cloudera官網(wǎng)的一段話：

"That value affects the execution of each query, preventing it from overallocating memory on each host, and potentially activating the spill-to-disk mechanism or cancelling the query when necessary."——該值將會影響每個query的運行，它能盡可能地降低在單個主機上過度的內(nèi)存分配蕊连，還能觸發(fā)溢寫磁盤機制悬垃，并在必要時取消query。

簡單來說甘苍，該值的含義是：每臺節(jié)點上盗忱，每個query的內(nèi)存限定。

兩者需滿足如下關系：Default Query Memory Limit*運行impala查詢節(jié)點數(shù)量<資源隊列的可用最大內(nèi)存羊赵，這是顯然的趟佃。

eg：impala daemon節(jié)點數(shù)有150個扇谣，Default Query Memory Limit的值設置為2g，那么分配的query資源隊列大小需大于2*150=300g闲昭。

若隊列資源<300g,該查詢可能會提交不上（query需要資源大于資源隊列可用內(nèi)存上限）或處于等待狀態(tài)（query需要資源雖然小于資源隊列可用內(nèi)存上限罐寨，但由于有前序查詢，需等待資源釋放）序矩。

根據(jù)以上鸯绿，為確保在impala的某個資源池中，能并發(fā)運行多個impala作業(yè)簸淀，需注意兩點：

1瓶蝴、指定合適的最大內(nèi)存設置，即第一個參數(shù)值租幕，這是一個集群范圍的限制舷手，它根據(jù)每個主機的Default Query Memory Limit（查詢內(nèi)存上限）乘以集群中的IMPALA節(jié)點數(shù)來確定可以同時安全運行多少查詢。

2劲绪、指定合適的Default Query Memory Limit（根據(jù)實際query所需的單節(jié)點內(nèi)存可適當降低）

以生產(chǎn)集群為例男窟，資源隊列tqueue的最大內(nèi)存上限為300g，設置的可同時并行運行的作業(yè)數(shù)量為50贾富，impala daemon節(jié)點數(shù)145個歉眷，Default Query Memory Limit為2g。

在該設置的情形下颤枪，對于一個大表來說汗捡，假設查詢運行在145個impala daemon節(jié)點上，impala估算所需的資源為145*2=290g畏纲，臨界該資源隊列上限凉唐，可保證該作業(yè)提交；由于設置了并行作業(yè)數(shù)50霍骄，后續(xù)提交的作業(yè)大概率會因為資源不足而發(fā)生等待台囱，當?shù)却龝r間超過5分鐘，作業(yè)將會失敗读整。

從之前的執(zhí)行計劃可看出簿训，Estimated Per-Host Requirements: Memory=132.00MB VCores=2 一個查詢大約消耗132M內(nèi)存，設置2g的Default Query Memory Limit偏大米间，將其調(diào)整為1g强品，那么為保證并行50個作業(yè)運行，需設置隊列最大內(nèi)存為1g*145*50=7250g屈糊〉拈唬考慮到實際并行作業(yè)并沒有這么多，且集群內(nèi)存還需給到其他服務逻锐，可適當降低該值夫晌。