最近，我们应用了Impala准入控制，其中针对特定国家/地区的某些查询将消耗所有资源，并关闭所有impala守护程序，从而导致其他查询超时或失败。
这些是长时间运行的查询，这些查询是同时触发的，最终导致排队或超时，因为POOL我们将最大运行查询设置为1，将最大排队查询设置为50。
根据与Cloudera的讨论，我们知道将查询放入que或运行取决于它的守护进程，所以这是一个妨碍客户端的限制。
这仅在特定查询中发生，我们正在为其进行查询优化（当前，我们有4个UNION ALL和11个TABLES JOINS）。
但是，我们从1.3 PB的估计扫描（现在只有500 GB）减少了时间并提高了查询性能，我们仍然有这样的印象，Impala不支持故障转移机制。
因此，如果查询在一段时间后失败，则需要再次触发。 这些查询是通过BI工具（Spotfire Tibco）触发的。
我们拥有的总数据为3.5 TB，仅针对该特定国家/地区进行复制。 配置了101个运行的Impala守护程序，总共有9.9 TiB的内存。
如果我们一次执行1个查询，则此过程将在2分钟内完成，但是如果触发了并行查询，而不是要求它们排队，则它们将在不同的协调器中排队，并且两个都不会运行。
我们正在考虑KUDU或DRILL。 有关通过故障转移机制对长时间运行的查询使用哪个建议。
Kudu有局限性，因此不适合生产。 DRILL，对于固定查询而言，这是个好地方，但是即时进行计算还是个好主意。
任何建议都值得赞赏！