Druid 实时数据分析存储系统


简介

Druid 是一个开源的,分布式的,列存储的,适用于实时数据分析的存储系统,可以快速聚合、灵活过滤、毫秒级查询、和低延迟数据导入html

 

  • Druid在设计时充分考虑到了高可用性,各类节点挂掉都不会使得druid中止工做(可是状态会没法更新);node

  • Druid中的各个组成部分之间耦合性低,若是不须要实时数据彻底能够忽略实时节点;web

  • Druid使用Bitmap indexing加速列存储的查询速度,并使用CONCISE算法来对bitmap indexing进行压缩,使得生成的segments比原始文本文件小不少;算法


架构

总体架构

Druid集群包含不一样类型的节点,而每种节点都被设计来作好某组事情。这样的设计能够隔离关注并简化整个系统的复杂度。sql

不一样节点的运转几乎都是独立的而且和其余的节点有着最小化的交互,所以集群内的通讯故障对于数据可用性的影响很是小。缓存

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节点是历史节点和实时节点的查询路由。Broker节点知道发布于Zookeeper中的segment的信息,Broker节点就能够将到来的查询请求路由到正确的历史节点或者是实时节点,Broker节点也会将历史节点和实时节点的局部结果进行合并,而后返回最终的合并后的结果给调用者。Broker节点包含一个支持LRU失效策略的缓存。

(图4)

如图4,每次Broker节点接收到查询请求时,都会先将查询映射到一组segment中去。这一组肯定的segment的结果可能已经存在于缓存中,而不须要从新计算。对于那些不存在于缓存的结果,Broker节点会将查询转发到正确的历史节点和实时节点中去,一旦历史节点返回结果,Broker节点会将这些结果缓存起来以供之后使用,这个过程如图6所示。实时数据永远不会被缓存,所以查询实时节点的数据的查询请求老是会被转发到实时节点上去。实时数据是不断变化的,所以缓存实时数据是不可靠的。


Indexer节点

索引服务是运行索引任务相关的高可用性,分布式的服务。索引服务建立(有时破坏)Druid的Segment。索引服务有一个相似主/从的架构。

 

(图5)

 

索引服务是由三个主要部分组成:能够运行单个任务的peon组件,用于管理peon的中层管理组件,以及管理任务分配到中层管理组件的overlord组件。overlord组件和中层管理组件能够在同一节点上或跨多个节点上运行,而中层管理组件和peon组件老是相同的节点上运行。


ZooKeeper 

Druid 使用ZooKeeper(ZK)管理当前集群状态,在ZK上发生的操做有:

 

1.协调节点的leader选举

2.历史和实时节点发布segment协议

3.协调节点和历史节点之间的segment Load/Drop协议

4.overlord的leader选举

5.索引服务任务管理


 

Druid vs 其余系统

 

Druid vs Impala/Shark

Druid和Impala、Shark 的比较基本上能够归结为须要设计什么样的系统

Druid被设计用于:

  1. 一直在线的服务

  2. 获取实时数据

  3. 处理slice-n-dice式的即时查询

查询速度不一样:

  • Druid是列存储方式,数据通过压缩加入到索引结构中,压缩增长了RAM中的数据存储能力,可以使RAM适应更多的数据快速存取。索引结构意味着,当添加过滤器来查询,Druid少作一些处理,将会查询的更快。

  • Impala/Shark能够认为是HDFS之上的后台程序缓存层。 可是他们没有超越缓存功能,真正的提升查询速度。

数据的获取不一样:

  • Druid能够获取实时数据。

  • Impala/Shark是基于HDFS或者其余后备存储,限制了数据获取的速度。

查询的形式不一样:

  • Druid支持时间序列和groupby样式的查询,但不支持join。

  • Impala/Shark支持SQL样式的查询。


 

Druid vs Elasticsearch

Elasticsearch(ES) 是基于Apache Lucene的搜索服务器。它提供了全文搜索的模式,并提供了访问原始事件级数据。 Elasticsearch还提供了分析和汇总支持。根据研究,ES在数据获取和汇集用的资源比在Druid高。

Druid侧重于OLAP工做流程。Druid是高性能(快速汇集和获取)以较低的成本进行了优化,并支持普遍的分析操做。Druid提供告终构化的事件数据的一些基本的搜索支持。

 

Druid vs Spark

Spark是围绕弹性分布式数据集( RDD )的概念,创建了一个集群计算框架,能够被看做是一个后台分析平台。 RDD启用数据复用保持中间结果存在内存中,给Spark提供快速计算的迭代算法。这对于某些工做流程,如机器学习,相同的操做可应用一遍又一遍,直到有结果后收敛尤为有益。Spark提供分析师与不一样算法各类各样运行查询和分析大量数据的能力。

Druid重点是数据获取和提供查询数据的服务,若是创建一个web界面,用户能够随意查看数据。

 

引用

论文: Druid A Real-time Analytical Data Store 

官方文档:http://druid.io/docs/0.8.1/design/index.html

相关文章
相关标签/搜索