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