【发布时间】：2016-01-27 12:35:14
【问题描述】：
我们在特定表上遇到了 Impala 计算统计信息的问题。问题详情如下：
问题
有时 Impala 的计算统计语句需要花费太多时间才能完成，或者只是在特定表上失败
表格详情
大小：45 GB Parquet，采用 Snappy 压缩
记录数：41 亿
分区：分为两列。
观察结果
每次在此特定表上运行计算统计信息时，我们都会观察到来自 impala 的不同行为。有时它会在 8-10 分钟内完成，而有时它会卡住并持续运行 2 小时，然后抛出异常。
当计算统计信息在 Impala 中成功运行时，后端 impala 查询统计信息集合包含表中每一列的 NDV。但是在所有其他情况下，后端查询仅计算分区列的 count(*)。 （有关更多详细信息，请参阅随附的屏幕截图）
深入研究 impalad 错误，我看到一些节点同时与 ip-xxx-xxx-x-xxx 通信时出现问题。但是，除了这些节点之外，其他节点都运行良好。 ./i-2f58f021/apps/impalad.ip-xxx-xxx-x-xxx.us-west-2.compute.internal.hadoop.log.INFO.20150128-053250.3948.gz:I0128 06:11:26.943601 7420 状态.cc:44] 无法打开 ip-xxx-xxx-x-xxx.us-west-2.compute.internal:22000 的传输（connect() failed: Connection timed out）
已尝试解决方案
设置 NUM_SCANNER_THREAD=2，然后运行计算统计查询。发布我们重置 NUM_SCANNER_THREAD 的消息。这没有帮助。
集群大小
1 r3.2xlarge 名称节点 | AWS 上的 39 个 r3.2xlarge 数据节点
问题
impala 计算统计逻辑背后的背景是什么？
是否有更多会话级属性可用于优化计算统计语句？
节点之间通过端口 22000 进行的 Impalad 通信连接超时是否会导致计算统计信息失败？
任何帮助将不胜感激。
【问题讨论】：
标签： impala