除了共享hive的metastore之外没什么太大的关系。
hive是Java写的,由Facebook开源,目的是将特定的SQL语句编译为MapReduce jar包扔给hadoop去执行,本质上是一个代码转换编译的工具,简化mr的开发,因为pig hive出现以前,mr都需要由熟悉Java或Python和hadoop架构熟悉的比较高级的程序员来写,这就限制了hadoop的使用广度。所以擅长语言翻译的facebook搞了一个hive,来把sql语言翻译成java再跑mr。
impala是spark萌芽时期cdh开源的c++编写的sql执行引擎,也用到了有向无环图和RDD的思路,我想当初可能是CDH想跟spark竞争一下内存计算这块的市场,后来发现争不过spark,现在也就处于半开发半维护的状态了,从核心上来说,执行原理跟hive完全不一样,hive是把sql转译成java,编译了jar包提交给hadoop,剩下的事情就是hadoop的mr的事了,hive只需要等着获取结果就好了。而impala则调用C语言层的libhdfs来直接访问HDFS,从NN获取到数据块信息后,直接将数据块读入内存,会使用hadoop的一个配置项叫dfs.client.short.read.circuit。看得出来,这是一个client端配置,作用是直接读取本地的数据块而不是通过HDFS读取整合后的文件。所以impala需要在每个dn节点都安装impalad去完成本地读取的工作。数据块读进内存之后就开始做有向无环图,完成计算之后会将热数据保存在内存里供下次读取。
CDH不开发单独的metastore是因为没有必要,当时hive已经是主流分析工具了,hadoop的使用者经过几年的积累,已经在hive上建立了成千上万个表。你再单独开发一个metastore纯属浪费,难道客户还要再给impala建一个单独的schema吗?再把那成千上万的分析表重建一遍?为什么不直接用以前hive建好的?
在我的认知范围内,impala不能脱离hive的metastore独立存在,而且catalogd有时还需要手工刷新hive的metastore缓存。