Druid 和 Impala Shark 的對比取決於產品要求， 取決於系統是設計成做什么的
Druid 被設計成
一直在線， 高可用性
實時插入數據
分片分塊形式的任意查詢
據我所知 Impala 和 Shark 起初關心的是用更快的查詢模塊換Hadoop MapReduce, 查詢模塊是完全通用的， 和現有的Hadoop生態系統打成一片. 請注意我不是Impala or Shark專家, 也不熟悉Impala和Shark的路線圖. 如果有什么錯誤， 我會更改， 請發郵件到郵件列表.
這是什么意思呢， 我們可以從以下四個通用的方面看
容錯性
查詢速度
數據插入
查詢靈活性
容錯性
druid在查詢之前從深存儲(Deep Storage) 拉取segment。 這意味着集群中的數據在一定在歷史節點(historical node)的本地副本之中。 如果deep storage 出了問題， 新的segment不會加載， 集群可以繼續支持查詢深存儲出現問題之前的數據。
Impala and Shark, 使用另外一種方式， 從HDFS拉取數據， 這意味着需要需要將程序下載加載。 當支持的文件系統出了問題， 被cache的數據仍可用。我不確定。
這只是一個例子， Druid 被設計成任何地方出錯后仍能夠繼續提供服務, 設計文檔中描述了更多的詳細信息
查詢速度
Druid 操控注入的數據， 將數據保存成列式存儲並壓縮添並加索引結構, 這些都提高查詢速度。 列式存儲只需查看查詢的數據列. 壓縮提高了RAM的容量讓我們在內存之中保存更多的數據。 索引結構相當於添加了boolean filter, 使查詢更快， 這樣可以做更多的查詢.
Impala/Shark 可以被認為是HDFS的緩存守護進程. 沒有查詢的時候守護進程依然存在(這就消除了Map Reduce的JVM啟動時間), 而且利用了本地Cache, 這樣數據可以被快速度訪問和修改。 但是我認為這不會超越Cache的能力. 所以， 直到現在， 他們沒有改變這種無理性暴力行為方式， 沒有改變掃描所有的東西的方式
[注： 作者對Impala了解不夠, 只舉一例， impala也支持列式存儲]
數據插入
[Druid本來就支持實時消費數據, 可以實時注入數據並查詢剛剛注入的數據， 時間延遲很小， 取決於這些數據什么時候到達Druid
Impala/Shark 基於HDFS或者其他存儲, 被后面的存儲限制注入頻率。 一般來講， 后面的存儲有很大的瓶頸。
查詢靈活性
Druid 支持時間序列和group by 查詢. 不支持join， 這點有一些不靈活.
Impala/Shark 支持SQL類型的full join