标签：
Druid 是一个开源的，分布式的，列存储的，适用于实时数据分析的存储系统，能够快速聚合、灵活过滤、毫秒级查询、和低延迟数据导入。
Druid在设计时充分考虑到了高可用性，各种节点挂掉都不会使得druid停止工作（但是状态会无法更新）；
Druid中的各个组成部分之间耦合性低，如果不需要实时数据完全可以忽略实时节点；
Druid使用Bitmap indexing加速列存储的查询速度，并使用CONCISE算法来对bitmap indexing进行压缩，使得生成的segments比原始文本文件小很多；
Druid集群包含不同类型的节点，而每种节点都被设计来做好某组事情。这样的设计可以隔离关注并简化整个系统的复杂度。
不同节点的运转几乎都是独立的并且和其他的节点有着最小化的交互，因此集群内的通信故障对于数据可用性的影响非常小。
Druid集群的构成和数据流向如图1所示：
（图1）
Druid 本身包含了五种节点 ： Realtime、Historical、Coordinator、Broker、Indexer
Historical 历史节点是进行存储和查询的“历史”数据（非实时）的工作区，它会从深存储区(Deep Storage)中加载数据段(Data/Segments)，响应 Broker 节点的查询请求并返回结果。历史节点通常会在本机同步深存储区上的部分数据段，所以即使深存储区不可访问了，历史节点还是能查询到已经同步的数据段。
Realtime 实时节点是进行存储和查询实时数据的工作区，它也会响应Broker节点的查询请求并返回结果 。实时节点会定期地将数据建立成数据段移到历史节点中。
Coordinator 协调节点可以认为是Druid中的master，它通过Zookeeper管理历史节点和实时节点，且通过Mysql中的metadata管理数据段。
Broker节点负责响应外部的查询请求，通过查询Zookeeper将请求分别转发给历史节点和实时节点，最终合并并返回查询结果给外部， 由Broker节点通过zookeeper决定哪些历史节点和实时节点提供服务。
Indexer 索引节点负责数据导入，加载批次和实时数据到系统中，并可以修改存储到系统中的数据 。
Druid 包含3个外部依赖 ：Mysql、Deep storage、Zookeeper
Mysql：存储关于Druid中的metadata而不是存储实际数据，包含3张表：”druid_config”（通常是空的）, “druid_rules”（协作节点使用的一些规则信息，比如哪个segment从哪个node去load）和“druid_segments”（存储每个segment的metadata信息）；
Deep storage: 存储segments，Druid目前已经支持本地磁盘，NFS挂载磁盘，HDFS，S3等。Deep Storage的数据有2个来源，一个是批数据摄入, 另一个来自实时节点；
ZooKeeper: 被Druid用于管理当前cluster的状态，比如记录哪些segments从实时节点移到了历史节点；
实时节点封装了导入和查询事件数据的功能，经由这些节点导入的事件数据可以立刻被查询。实时节点只关心一小段时间内的事件数据，并定期把这段时间内收集的这批数据导入到深存储区里。实时节点通过Zookeeper来宣布它们的在线状态和它们提供的数据。
（图2）
如图2，实时节点缓存事件数据到内存中的索引上，然后有规律的持久化到磁盘上。在转移之前，持久化的索引会周期性地合并在一起。查询会同时命中内存中的和已持久化的索引。所有的实时节点都会周期性的启动后台的计划任务搜索本地的持久化索引，后台计划任务将这些持久化的索引合并到一起并生成一块不可变的数据，这些数据块包含了一段时间内的所有已经由实时节点导入的事件数据，称这些数据块为”Segment”。在传送阶段，实时节点将这些segment上传到一个永久持久化的备份存储中，通常是一个分布式文件系统，例如S3或者HDFS，称之为”Deep Storage”(深存储区)。
历史节点遵循shared-nothing的架构，因此节点间没有单点问题。节点间是相互独立的并且提供的服务也是简单的，它们只需要知道如何加载、删除和处理Segment。类似于实时节点，历史节点在Zookeeper中通告它们的在线状态和为哪些数据提供服务。加载和删除segment的指令会通过Zookeeper来进行发布，指令会包含segment保存在deep storage的什么地方和怎么解压、处理这些segment的相关信息。
（图3）
如图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）
如图4，每次Broker节点接收到查询请求时，都会先将查询映射到一组segment中去。这一组确定的segment的结果可能已经存在于缓存中，而不需要重新计算。对于那些不存在于缓存的结果，Broker节点会将查询转发到正确的历史节点和实时节点中去，一旦历史节点返回结果，Broker节点会将这些结果缓存起来以供以后使用，这个过程如图6所示。实时数据永远不会被缓存，因此查询实时节点的数据的查询请求总是会被转发到实时节点上去。实时数据是不断变化的，因此缓存实时数据是不可靠的。
索引服务是运行索引任务相关的高可用性，分布式的服务。索引服务创建（有时破坏）Druid的Segment。索引服务有一个类似主/从的架构。
（图5）
索引服务是由三个主要部分组成：可以运行单个任务的peon组件，用于管理peon的中层管理组件，以及管理任务分配到中层管理组件的overlord组件。overlord组件和中层管理组件可以在同一节点上或跨多个节点上运行，而中层管理组件和peon组件总是相同的节点上运行。
Druid 使用ZooKeeper（ZK）管理当前集群状态，在ZK上发生的操作有：
1.协调节点的leader选举
2.历史和实时节点发布segment协议
3.协调节点和历史节点之间的segment Load/Drop协议
4.overlord的leader选举
5.索引服务任务管理
Druid和Impala、Shark 的比较基本上可以归结为需要设计什么样的系统
Druid被设计用于：
一直在线的服务
获取实时数据
处理slice-n-dice式的即时查询
查询速度不同：
Druid是列存储方式，数据经过压缩加入到索引结构中，压缩增加了RAM中的数据存储能力，能够使RAM适应更多的数据快速存取。索引结构意味着，当添加过滤器来查询，Druid少做一些处理，将会查询的更快。
Impala/Shark可以认为是HDFS之上的后台程序缓存层。 但是他们没有超越缓存功能，真正的提高查询速度。
数据的获取不同：
Druid可以获取实时数据。
Impala/Shark是基于HDFS或者其他后备存储，限制了数据获取的速度。
查询的形式不同：
Druid支持时间序列和groupby样式的查询，但不支持join。
Impala/Shark支持SQL样式的查询。
Elasticsearch(ES) 是基于Apache Lucene的搜索服务器。它提供了全文搜索的模式，并提供了访问原始事件级数据。 Elasticsearch还提供了分析和汇总支持。根据研究，ES在数据获取和聚集用的资源比在Druid高。
Druid侧重于OLAP工作流程。Druid是高性能（快速聚集和获取）以较低的成本进行了优化，并支持广泛的分析操作。Druid提供了结构化的事件数据的一些基本的搜索支持。
Spark是围绕弹性分布式数据集（ RDDS ）的概念，建立了一个集群计算框架，可以被看作是一个后台分析平台。 RDDS启用数据复用保持中间结果存在内存中，给Spark提供快速计算的迭代算法。这对于某些工作流程，如机器学习，相同的操作可应用一遍又一遍，直到有结果后收敛尤其有益。Spark提供分析师与不同算法各种各样运行查询和分析大量数据的能力。
Druid重点是数据获取和提供查询数据的服务，如果建立一个web界面，用户可以随意查看数据。
论文： Druid A Real-time Analytical Data Store
官方文档：http://druid.io/docs/0.8.1/design/index.html
标签：
原文地址：http://my.oschina.net/betaoo/blog/530088
