druid 是一个开源的，分布式的，列存储的，适用于实时数据分析的存储系统，能够快速聚合、灵活过滤、毫秒级查询、和低延迟数据导入。
druid集群包含不同类型的节点，而每种节点都被设计来做好某组事情。这样的设计可以隔离关注并简化整个系统的复杂度。
不同节点的运转几乎都是独立的并且和其他的节点有着最小化的交互，因此集群内的通信故障对于数据可用性的影响非常小。
druid集群的构成和数据流向如图1所示：
（图1）
druid 包含3个外部依赖 ：mysql、deep storage、zookeeper
实时节点封装了导入和查询事件数据的功能，经由这些节点导入的事件数据可以立刻被查询。实时节点只关心一小段时间内的事件数据，并定期把这段时间内收集的这批数据导入到深存储区里。实时节点通过zookeeper来宣布它们的在线状态和它们提供的数据。
如图2，实时节点缓存事件数据到内存中的索引上，然后有规律的持久化到磁盘上。在转移之前，持久化的索引会周期性地合并在一起。查询会同时命中内存中的和已持久化的索引。所有的实时节点都会周期性的启动后台的计划任务搜索本地的持久化索引，后台计划任务将这些持久化的索引合并到一起并生成一块不可变的数据，这些数据块包含了一段时间内的所有已经由实时节点导入的事件数据，称这些数据块为”segment”。在传送阶段，实时节点将这些segment上传到一个永久持久化的备份存储中，通常是一个分布式文件系统，例如s3或者hdfs，称之为”deep storage”(深存储区)。
历史节点遵循shared-nothing的架构，因此节点间没有单点问题。节点间是相互独立的并且提供的服务也是简单的，它们只需要知道如何加载、删除和处理segment。类似于实时节点，历史节点在zookeeper中通告它们的在线状态和为哪些数据提供服务。加载和删除segment的指令会通过zookeeper来进行发布，指令会包含segment保存在deep storage的什么地方和怎么解压、处理这些segment的相关信息。
如图3，在历史节点从深存储区下载某一segment之前，它会先检查本地缓存信息中看segment是否已经存在于节点中，如果segment还不存在缓存中，历史节点会从深存储区下载segment到本地。这阶段处理完成，这个segment就会在zookeeper中进行通告。此时，这个segment就可以被查询了，查询之前需要将segment加载到内存中。
协调节点主要负责segment的管理和在历史节点上的分布。协调节点告诉历史节点加载新数据、卸载过期数据、复制数据、和为了负载均衡移动数据。druid为了维持稳定的视图，使用一个多版本的并发控制交换协议来管理不可变的segment。如果任何不可变的segment包含的数据已经被新的segment完全淘汰了，则过期的segment会从集群中卸载掉。协调节点会经历一个leader选举的过程，来决定由一个独立的节点来执行协调功能，其余的协调节点则作为冗余备份节点。
broker节点是历史节点和实时节点的查询路由。broker节点知道发布于zookeeper中的segment的信息，broker节点就可以将到来的查询请求路由到正确的历史节点或者是实时节点，broker节点也会将历史节点和实时节点的局部结果进行合并，然后返回最终的合并后的结果给调用者。broker节点包含一个支持lru失效策略的缓存。
如图4，每次broker节点接收到查询请求时，都会先将查询映射到一组segment中去。这一组确定的segment的结果可能已经存在于缓存中，而不需要重新计算。对于那些不存在于缓存的结果，broker节点会将查询转发到正确的历史节点和实时节点中去，一旦历史节点返回结果，broker节点会将这些结果缓存起来以供以后使用，这个过程如图6所示。实时数据永远不会被缓存，因此查询实时节点的数据的查询请求总是会被转发到实时节点上去。实时数据是不断变化的，因此缓存实时数据是不可靠的。
索引服务是运行索引任务相关的高可用性，分布式的服务。索引服务创建（有时破坏）druid的segment。索引服务有一个类似主/从的架构。
索引服务是由三个主要部分组成：可以运行单个任务的peon组件，用于管理peon的中层管理组件，以及管理任务分配到中层管理组件的overlord组件。overlord组件和中层管理组件可以在同一节点上或跨多个节点上运行，而中层管理组件和peon组件总是相同的节点上运行。
druid 使用zookeeper（zk）管理当前集群状态，在zk上发生的操作有：
1.协调节点的leader选举
2.历史和实时节点发布segment协议
3.协调节点和历史节点之间的segment load/drop协议
4.overlord的leader选举
5.索引服务任务管理
druid vs impala/shark
druid和impala、shark 的比较基本上可以归结为需要设计什么样的系统
druid被设计用于：
一直在线的服务
获取实时数据
处理slice-n-dice式的即时查询
elasticsearch(es) 是基于apache lucene的搜索服务器。它提供了全文搜索的模式，并提供了访问原始事件级数据。 elasticsearch还提供了分析和汇总支持。根据研究，es在数据获取和聚集用的资源比在druid高。
druid侧重于olap工作流程。druid是高性能（快速聚集和获取）以较低的成本进行了优化，并支持广泛的分析操作。druid提供了结构化的事件数据的一些基本的搜索支持。
spark是围绕弹性分布式数据集（ rdd ）的概念，建立了一个集群计算框架，可以被看作是一个后台分析平台。 rdd启用数据复用保持中间结果存在内存中，给spark提供快速计算的迭代算法。这对于某些工作流程，如机器学习，相同的操作可应用一遍又一遍，直到有结果后收敛尤其有益。spark提供分析师与不同算法各种各样运行查询和分析大量数据的能力。
druid重点是数据获取和提供查询数据的服务，如果建立一个web界面，用户可以随意查看数据。
论文： druid a real-time analytical data store