應該不會，Impala是相當專注於傳統企業客戶和OLAP和資料倉庫工作負載。Shark支援傳統OLAP。比較：
一、總體上 Shark擴充套件了Apache Hive，大大加快在記憶體和磁碟上的查詢。而Impala是企業級資料倉庫系統, 可以很好地使用Hive/ HDFS，從架構層來說，類似於傳統的並行資料庫。這兩個系統有著很多共同的目標，但也有很大差異。
二、與現有系統的相容性 Shark直接建立在Apache/Hive程式碼庫上，所以它自然支援幾乎所有Hive特點。它支援現有的Hive SQL語言，Hive資料格式（SerDes），使用者自定義函式（UDF），呼叫外部指令碼查詢。因為Impala使用自定義的C++執行，它不支援Hive UDF。這兩個系統將會與許多BI工具整合，這一直是Impala的主要目標。Shark正在被用於一些BI工具，如Tableau，不過這並沒有被探索更多。
三、記憶體中的資料處理 Shark允許使用者顯式地載入在記憶體中的資料，以加快查詢處理，其記憶體使用有效率的，壓縮的面向列的格式。Impala還沒有提供在記憶體中的儲存。
四、容錯 Shark被設計為支援短期和長時間執行的查詢。它可以從查詢故障恢復(感謝底層Spark引擎)。Impala目前是更側重於短查詢，不容錯（如果節點發生故障，查詢必須重新啟動，對短查詢來說這無疑是可以接受的）。
五、效能 做全面的比較太早了點。Shark和Impala都報告比Hive快10-100倍，但這都依賴具體情況和系統負載。兩個專案也都在未來6個月內會做重要最佳化。以我們的經驗來看，Sharkr當前版本，如果是記憶體的資料一般比Hive快100倍，如果是磁碟上的資料一般快5-10倍，這取決於查詢（帶關聯連線的查詢，能比Hive快很多）。
應該不會，Impala是相當專注於傳統企業客戶和OLAP和資料倉庫工作負載。Shark支援傳統OLAP。比較：
一、總體上 Shark擴充套件了Apache Hive，大大加快在記憶體和磁碟上的查詢。而Impala是企業級資料倉庫系統, 可以很好地使用Hive/ HDFS，從架構層來說，類似於傳統的並行資料庫。這兩個系統有著很多共同的目標，但也有很大差異。
二、與現有系統的相容性 Shark直接建立在Apache/Hive程式碼庫上，所以它自然支援幾乎所有Hive特點。它支援現有的Hive SQL語言，Hive資料格式（SerDes），使用者自定義函式（UDF），呼叫外部指令碼查詢。因為Impala使用自定義的C++執行，它不支援Hive UDF。這兩個系統將會與許多BI工具整合，這一直是Impala的主要目標。Shark正在被用於一些BI工具，如Tableau，不過這並沒有被探索更多。
三、記憶體中的資料處理 Shark允許使用者顯式地載入在記憶體中的資料，以加快查詢處理，其記憶體使用有效率的，壓縮的面向列的格式。Impala還沒有提供在記憶體中的儲存。
四、容錯 Shark被設計為支援短期和長時間執行的查詢。它可以從查詢故障恢復(感謝底層Spark引擎)。Impala目前是更側重於短查詢，不容錯（如果節點發生故障，查詢必須重新啟動，對短查詢來說這無疑是可以接受的）。
五、效能 做全面的比較太早了點。Shark和Impala都報告比Hive快10-100倍，但這都依賴具體情況和系統負載。兩個專案也都在未來6個月內會做重要最佳化。以我們的經驗來看，Sharkr當前版本，如果是記憶體的資料一般比Hive快100倍，如果是磁碟上的資料一般快5-10倍，這取決於查詢（帶關聯連線的查詢，能比Hive快很多）。