ImpalaD节点服务启动失败分析

版权声明：本文为博主原创文章，未经博主允许不得转载。https://www.jianshu.com/p/bb542b116a4b

现象描述：

生产环境老离线集群（CDH5.2）的一台impalaD节点服务异常，CM页面显示该节点的服务并无异常。

然而无论是客户端通过jdbc/odbc方式还是直接在该impala节点通过impala-shell来连接该节点都会报错（该集群impala未使用hiveserver2+haproxy+keepalive方案，客户端直连impalad节点）：

hostname:/tmp# impala-shell

StartingImpala Shell without Kerberos authentication

Errorconnecting: TTransportException, Could not connect to hostname:21000

Welcome tothe Impala shell. Press TAB twice to see a list of available commands.

Copyright(c) 2012 Cloudera, Inc. All rights reserved.

(Shell buildversion: Impala Shell v2.0.1-cdh5 (cc09df0) built on Wed Nov 19 10:57:34 PST2014)

查看该节点，21000端口未被监听

hostname:/tmp# netstat -anp|grep -i 21000

由此判断，该节点impalaD服务异常，实际上启动失败，然而CM未探测到该异常。

问题排查：

1、分析该节点的impalaD日志，可知ImpalaD卡在了注册Statestore上：

I0312 10:10:56.865545 10818 statestore-subscriber.cc:189] Registering with statestore

I0312 10:10:56.865583 10818 client-cache.cc:107] CreateClient(): creating new client for hostname1:24000

2、分析Statestore日志，从日志中可以看到不断有主机反复的registration：

I022818:10:54.77777 11375 statestore.cc:352] Subscriber 'impalad@hostnameB:22000'registered (registration id: 6b408b3e39f17195:e0f91842fba7cb8a) ...

I022818:11:24.81176 11375 statestore.cc:352] Subscriber 'impalad@ hostnameB:22000'registered (registration id: 7242b00906a6721e:271b78b01a3dedb9) ...

以及, 最后 Statestore 进入deadlock状态，再也无法注册 ImpalaD，这是导致 ImpalaD 启动时无法注册到Statestore的原因：

I0309 21:34:02.6713561958 statestore.cc:321] Registering:impalad@hostname:22000 

I031210:10:56.866513 17489 statestore.cc:321] Registering: impalad@hostname:22000

I031210:15:19.278779 22550 statestore.cc:321] Registering: impalad@hostname:22000

原因定位：

本质上是由于早期版本的 Impala 架构的局限性所导致的。在CDH5.3之前的版本中, Statestore通过heartbeat来发送catalog update的消息，这对于规模较小的 metadata问题不大，因为此时catalog update 通常不会很大，不至于影响到传送heartbeat。但随着数据量不断增多(文件和partition数量增长)，catalog update 也变大，此时，传输延迟就会影响到heartbeat，导致 Impalad 认为 Statestore 不可达，从而尝试重新连接注册。而如果主机数量很多，就会进一步扩大影响，造成不断有Impala重新注册，从而造成 Statestore 内部 queue 溢出，最终出现本次问题。

解决方案：

禁止Catalog自动加载 metadata, 这可以有效减少catalog更新数据, 从而延缓节点通讯的问题。

在impala文档中有一个参数load_catalog_in_background，介绍如下:

参数load_catalog_in_background介绍

翻译过来为：

使用“--load_catalog_in_background” 选项来控制何时加载一个表的元数据。

如果设置为false，则当第一次引用表时，将加载该表的元数据。这意味着特定查询的第一次运行可能比后续运行慢。从IMPRA 2.2开始，对于load_catalog_in_background的默认值是false。

如果设置为true，即使没有查询需要元数据，目录服务也会尝试加载表的元数据。因此，当运行第一个查询时，可能已经加载了元数据。但是，由于以下原因，我们建议不要将选项设置为true。

1）后台负载会干扰查询特定的元数据加载。这可以在invalidating metadata启动时或之后发生，持续时间取决于元数据的数量，并且可能导致随机的长时间的运行查询，这很难诊断。

2） 导致Impala加载可能从未使用过的表的元数据，从而可能增加目录大小，从而增加目录服务和Impala守护进程的内存使用。

 由此可知，设置--load_catalog_in_background=false (默认是true) 将防止 Statestore 在启动时加载全部的 metadata，从而加快启动进程，并且， 每个表的metadata 只有在访问到时才加载，因此减少内存占用。

从Cloudera Manager—>Catalog service —>Configuration—>Catalog Server Command Line Argument Advanced Configuration Snippet (Safety Valve) ，配置以下参数--load_catalog_in_background=false，然后重启Impala服务使设置生效。

load_catalog_in_background 参数配置

影响性：

设置为false 只在首次使用到表时有影响，并且，该参数在较新的 Impala 版本中已经被默认设置为false以提高 Impala 的整体性能。