除了共享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緩存。