Druid对比Impala/Shark

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