实时统计分析系统-Apache Druid

前言

Druid.io(以下简称Druid)是2013年底开源出来的, 主要解决的是对实时数据以及较近时间的历史数据的多维查询提供高并发(多用户),低延时,高可靠性的问题。


正文

Druid简介

Druid是一个为在大数据集之上做实时统计分析而设计的开源数据存储。这个系统集合了一个面向列存储的层,一个分布式、shared-nothing的架构,和一个高级的索引结构,来达成在秒级以内对十亿行级别的表进行任意的探索分析。互联网技术的快速增长催生了各类大体量的数据,Hadoop很大的贡献在于帮助企业将他们那些低价值的事件流数据转化为高价值的聚合数据,这适用于各种应用。

但Hadoop擅长的是存储和获取大规模数据,但是它并不提供任何性能上的保证它能多快获取到数据。此外,虽然Hadoop是一个高可用的系统,但是在高并发负载下性能会下降。Hadoop是一个很好的后端、批量处理和数据仓库系统。在一个需要高并发并且保证查询性能和数据可用性的并需要提供产品级别的保证的需求,Hadoop并不能满足,因此创建了Druid,一个开源的、分布式、列存储、实时分析的数据存储。在许多方面,Druid和其他OLAP系统有很多相似之处,交互式查询系统,内存数据库(MMDB),众所周知的分布式数据存储。其中的分布式和查询模型都参考了当前的一些搜索引擎的基础架构。


Druid的一些特点

Druid是一个开源的,分布式的,列存储的,适用于实时数据分析的系统,文档详细,易于上手,Druid的一些特性总结如下:

  • Druid支持亚秒级的OLAP查询分析,Druid采用了列式存储/倒排索引/位图索引等关键技术,能够在亚秒级别内完成海量数据的过滤/聚合以及多位分析等操作。Druid使用Bitmap indexing加速column-store的查询速度,使用了一个叫做CONCISE的算法来对bitmap indexing进行压缩,使得生成的segments比原始文本文件小很多;
  • Druid的高可用性和高扩展性,Druid采用分布式,SN(share-nothing)架构,管理类节点可配置HA,工作节点功能单一,不互相依赖,耦合性低,各种节点挂掉都不会使Druid停止工作,例如如果不需要streaming data ingestion完全可以忽略realtime node,这些都是的Druid在集群的管理,容灾,容错,扩容等方面变得非常容易;
  • 实时流数据分析。区别于传统分析型数据库采用的批量导入数据进行分析的方式,Druid提供了实时流数据分析,采用LSM(Long structure merge)-Tree结构使Druid拥有极高的实时写入性能;同时实现了实时数据在亚秒级内的可视化。
  • 丰富的数据分析功能。针对不同用户群体,Druid提供了友好的可视化界面、类SQL查询语言以及REST 查询接口。

Durid的一些局限性

1、 Segment的不可修改性简化了Druid的实现,但是如果你有修改数据的需求,必须重新创建segment,而bitmap indexing的过程是比较耗时的;

2、Druid能接受的数据的格式相对简单,比如不能处理嵌套结构的数据

Druid使用场景

  • 1:适用于清洗好的记录实时录入,但不需要更新操作

  • 2:支持宽表,不用join的方式(换句话说就是一张单表)

  • 3:可以总结出基础的统计指标,可以用一个字段表示

  • 4:对时区和时间维度(year、month、week、day、hour等)要求高的(甚至到分钟级别)

  • 5:实时性很重要

  • 6:对数据质量的敏感度不高

  • 7:用于定位效果分析和策略决策参考


Druid的架构模型


在这里插入图片描述

1、Broker nodes

负责响应外部的查询请求,通过查询Zookeeper将请求划分成segments分别转发给Historical和Real-time nodes,最终合并并返回查询结果给外部;

2、Historial nodes

负责’Historical’ segments的存储和查询。其会从deep storage中load segments,并响应Broder nodes的请求。Historical nodes通常会在本机同步deep storage上的部分segments,所以即使deep storage不可访问了,Historical nodes还是能serve其同步的segments的查询;

3、Real-time nodes

用于存储和查询热数据,会定期地将数据build成segments移到Historical nodes。一般会使用外部依赖kafka来提高realtime data ingestion的可用性。如果不需要实时ingest数据到cluter中,可以舍弃Real-time nodes,只定时地batch ingestion数据到deep storage;

4、Coordinator nodes

可以认为是Druid中的master,其通过Zookeeper管理Historical和Real-time nodes,且通过Mysql中的metadata管理Segments

5、indexing services

用于数据导入,batch data和streaming data都可以通过给indexing services发请求来导入数据。


Durid数据存储

Druid中的数据存储在被称为datasource的文件中,类似关系型数据库中的table
在这里插入图片描述
每个datasource按照时间划分。每个时间范围称为一个chunk(一般都是以天分区,则一个chunk为一天)!!! //也可以按其他属性划分

在chunk中数据被分为一个或多个segment,每个segment都是一个单独的文件,通常包含几百万行数据

:这些segment是按照时间组织成的chunk,所以在按照时间查询数据时,效率非常高。

Durid数据分区

任何分布式存储/计算系统,都需要对数据进行合理的分区,从而实现存储和计算的均衡,以及数据并行化。

而Druid本身处理的是事件数据,每条数据都会带有一个时间戳,所以很自然的就可以使用时间进行分区。

Druid 数据流动

  1. 实时节点(中间管理者)会周期性的将同一时间段生成的数据合并成一个Segment数据文件,并上传到DeepStorage中。

  2. Segment数据文件的相关元数据信息保存到MetaStore中(如mysql,derby等)。

  3. 节点定时(默认1分钟)从MetaSotre中获取到Segment数据文件的相关元信息后,将按配置的规则分配到符合条件的历史节点中。

  4. 协调节点会通知一个历史节点去读

  5. 历史节点收到协调节点的通知后,会从DeepStorage中拉取该Segment数据文件到本地磁盘,并通过zookeeper向集群声明可以提供查询了。

  6. 实时节点会丢弃该Segment数据文件,并通过zookeeper向集群声明不在提供该Sgment的查询服务。(其实第四步已经可以提供查询服务了)

  7. 而对于全局数据来说,查询节点(Broker Node)会同时从实时节点与历史节点分别查询,对结果整合后返回用户。


Durid与Zookeeper

在这里插入图片描述

  • Druid的集群依赖ZooKeeper来维护数据拓扑,实时节点在转存Segment到DeepStorage, 会写入自己转存了什么Segment。

  • 协调节点管理历史节点,它负责从ZooKeeper中获取要同步/下载的Segment,并指派任务给具体的历史节点去完成。

  • 历史节点从ZooKeeper中领取任务,任务完成后要将ZooKeeper条目删除表示完成了任务。

  • Broker节点根据ZooKeeper中的Segment所在的节点, 将查询请求路由到指定的节点。

MetadataStorage与Zookeeper

  • MetaStore和ZooKeeper中保存的信息是不一样的. ZooKeeper中保存的是Segment属于哪些节点. 而MetaStore则是保存Segment的元数据信息

  • 为了使得一个Segment存在于集群中,MetaStore存储的记录是关于Segment的自描述元数据: Segment的元数据,大小,所在的DeepStorage

  • 元数据存储的数据会被协调节点用来获取集群中可用的数据应该有哪些(Segment可以通过实时节点转存或者批量数据直接写入).


Durid的三个外部依赖

在这里插入图片描述

  • Mysql:存储Druid中的各种metadata(里面的数据都是Druid自身创建和插入的),在Druid_0.9.1.1版本中,元信息库druid主要包含十张表,均以“druid_”开头,例如张表:”druid_config”(通常是空的), “druid_rules”(coordinator nodes使用的一些规则信息,比如哪个segment从哪个node去load)和“druid_segments”(存储每个segment的metadata信息);

  • Deep storage: 存储segments,Druid目前已经支持本地磁盘,NFS挂载磁盘,HDFS,S3等。Deep Storage的数据有2个来源,一个是batch Ingestion, 另一个是real-time nodes;

  • ZooKeeper: Druid使用Zookeeper作为分布式集群内部的通信组件,各类节点通过Curator Framework将实例与服务注册到Zookeeper上,同时将集群内需要共享的信息也存储在Zookeeper目录下,从而简化集群内部自动连接管理、leader选举、分布式锁、path缓存以及分布式队列等复杂逻辑。

猜你喜欢

转载自blog.csdn.net/qq_37163925/article/details/106470972