Impala如何在查询处理中实现比Hive更低的延迟？
我正在经历http://impala.apache.org/overview.html，其中声明：
为避免延迟，Impala绕过MapReduce直接访问 数据通过专门的分布式查询引擎非常 类似于商业并行RDBMS中的那些。结果是 比Hive更快的性能，具体取决于类型 查询和配置。
Impala如何在没有MapReduce的情况下获取数据（如在Hive中）？
我们可以说Impala更接近HBase，应该与HBase进行比较，而不是与Hive进行比较吗？
修改
或者我们可以说，经典的是，Hive位于MapReduce之上并且需要更少的内存来处理，而Impala会在内存中完成所有操作，因此需要更多的内存才能将数据缓存在内存中并采取行动根据要求？
答案 0 :(得分：4)
请阅读Impala Architecture and Components
Impala是一个大规模并行处理（MPP）数据库引擎。它由在特定主机上运行的不同守护程序进程组成.... Impala与Hive和Pig不同，因为它使用自己的守护程序遍布集群进行查询。
它通过在每个能够接受查询请求的节点上运行一个长时间守护进程来绕过MapReduce容器。处理像HiveServer2这样的请求没有单一的失败点;所有impala引擎都能够立即响应查询请求，而不是排队MapReduce YARN容器。
然而，Impala确实依赖于Hive Metastore服务，因为它只是将存储在RDBMS中的元数据映射到Hadoop文件系统的有用服务。 Pig，Spark，PrestoDB和其他查询引擎也可以共享Hive Metastore而无需通过HiveServer进行通信。
数据不是已经缓存的＃34;在Impala。与Spark类似，您必须将数据读入大部分内存，以便快速进行操作。与Spark不同，守护进程和statestore服务保持活动状态以处理后续查询。
Impala可以查询HBase，但它在架构上并不相似，根据我的经验，设计良好的HBase表比Impala更快查询。 Impala可能更接近Kudu。
另外值得一提的是，我们不再推荐使用MapReduce Hive了。 Tez要好得多，Hortonworks states Hive LLAP is better than Impala虽然如你所说的那样，它主要取决于查询和配置的类型。＆＃34;
答案 1 :(得分：0)
Impala使用＆＃34; Impala Daemon＆＃34;服务直接从dataNode读取数据（它必须与dataNode的相同主机一起安装）。它只缓存文件的位置和内存中的一些统计信息而不是数据本身。
为什么impala无法读取表中创建的新文件。你必须让无效或刷新（取决于你的情况）告诉impala缓存新文件并能够直接阅读它们
因为impala在内存中，你需要有足够的内存用于查询读取的数据，如果你查询将使用比你的内存更多的数据（在巨大的表上使用聚合的复杂查询），使用带有spark引擎的hive而不是默认地图缩小
在查询之前 set hive.execution.engine=spark;
您可以在带有spark引擎的配置单元中使用相同的查询
impala是cloudera产品，你不会为hortonworks和MapR（或其他人）找到它。
例如，tez不包含在cloudera中。
一切都取决于您使用的平台