我们正面临一个特定表上的 Impala 计算统计数据的问题。发行详情如下：
问题
有时impala的computestats语句需要花费太多的时间来完成，或者只是在特定的表上失败
表详细信息
尺寸：45 gbParquet地板
记录数：41亿
分区：在两列上分区。
观察结果
每次在这个特定的表上运行computestats时，我们都会观察到来自impala的不同行为。有时它会在8-10分钟内完成，而有时它会卡住并持续运行2小时，然后抛出异常。
当computestats在impala中成功工作时，stats集合的后端impala查询包含表中每列的ndv。但是，在所有其他情况下，后端查询只计算分区列的count（*）(有关更多详细信息，请参阅随附的屏幕截图）
深入研究impalad错误，我看到一些节点同时与ip---x-通信时出现问题。但是，除了这些节点，其他节点工作正常/i-2f58f021/apps/impalad.ip---x-.us-west-2.compute.internal.hadoop.log.info.20150128-053250.3948.gz:i0128 06:11:26.943601 7420 status.cc:44]无法为ip---x-us-west-2.compute打开传输。internal:22000（connect（）失败：连接超时）
已尝试解决方案选项
设置num\u scanner\u thread=2，然后运行compute stats查询。我们重置num\u scanner\u线程。这没有帮助。
簇大小
aws上的1 r3.2xlarge namenode | 39 r3.2xlarge datanode
问题
Impala 计算统计逻辑背后的背景是什么？
是否有更多会话级属性可用于优化compute stats语句？
节点之间通过端口22000的impalad通信连接超时是否是计算统计失败的原因？
任何帮助都将不胜感激。