druid基本理解

最近因为一个项目，所以临时突击学习了一下druid，找了一些书和官网文章搭配，然后就有了下面的这个文章，

Druid基本概念—

Druid是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供低延时(实时)的数据接入，灵活的数据探索以及高速的数据聚合(存储和查询)。

保存到Druid的数据由三部分组成：

♦ Timestamp列：数据的时间戳列，所有的查询都是以时间为中心。

♦ Dimension列：数据的维度列，用于过滤数据。

♦ Metric列：数据的聚合列，用于聚合数据，支持包括sum，count，min和max等计算。

接下来为大家介绍Druid的几个基本概念：

♦ 聚合：数据按照时间戳列、维度列、聚合列和聚合粒度进行归并的过程，称之为聚合。

♦ 聚合粒度：接收到多长时间的数据归并为一条，称之为聚合粒度。

♦ Datasource：数据源，相当于关系型数据库里面表的概念。

♦ Segment：Druid用Segment文件保存数据，Segment包含着某个Datasource一段时间内的数据。

♦ Datasource和Segment之间的关系：Segment=Datasource_interval_version_partitionNumber。

从这个关系中不难发现segment也可以分区(partitonNumber)，就像kafka的topic一样。其实segment不仅可以分区，并且与kafka的topic一样，也有副本的概念。

下面结合透视宝的业务场景举个例子，消化一下上面的概念：我们在Druid上创建了一个叫做cpu的datasource，他的维度列是account_id(用户唯一标识)和host_id（主机唯一标识），聚合列是cpuUser,cpuSys,cpuIdle和cpuWait，聚合计算包括sum和count,聚合粒度是30分钟。

按照如上的方式对cpu数据进行聚合后，每30分钟一组account_id和host_id只会对应一条数据，这条数据记录了我们每个聚合列的sum值和count值。这样，当我们在查询主机数-最近1天(7天)的cpu数据时，可以在这个聚合结果的基础上再次进行聚合查询。元数据数据量大大减小了，查询效率是不是就提高了！

面简单介绍下Druid不同节点的作用：

overlord节点：接收和分发任务。上面说到了在Druid上创建了一个叫做cpu的datasource，其实暂时可以理解为创建了一个任务，目的是告诉overlord节点这个datasource/任务处理的数据描述（模板）是什么，描述包括数据的维度列，聚合列，聚合粒度，segment生成时间等等参数，任务会按照这个描述对接收到的数据进行聚合。overlord节点接到任务后并不会直接处理任务，而是分发给middlemaanger节点。

middlemanager节点：管理任务。middlemanager接收到overlord分发给他的任务，会继续分发任务，分发给谁呢？分发给peon，这才是真正做聚合任务的同志。

从这张图可以看出overlord是如何分发任务给middlemanager的，通过zookeeper（下面会提到，druid的依赖，一些分布式服务都会依赖它，kafka，hbase等等）。peon完成数据聚合任务后，会生成一个segment文件，并且会将segment文件永久保存到deepstorage，deepstroage也是Druid的一个依赖，Druid依赖deepstorage对segment做永久存储，常用的deepstorage有s3和hdfs。

broker节点：响应外部的查询请求。broker节点会根据请求参数（时间段参数等），决定从哪里获取数据。

historical节点：存储历史数据。broker节点响应外部的查询请求，会从某个或者某些historical节点查询数据(如果没有，从deepstorage加载）。

coordinator节点：管理集群中的Segment操作(下载，删除等)。

每个节点都提供了很多api，可以通过api查看各个节点的状态信息等，例如查看overlord节点的状态信息，如下图：

另外，还可以通过overlord节点提供的web页面查看任务的状态，以及middlemanager的数量，

和每个middlemanager可以容纳的peon数量等等。

** 下面是官方提供的Druid工作流程图：**

这个流程图中没有画出overlord和middlemaanger节点，图中的realtime节点我们暂时没有用到，云智慧用的是tranquility（a high level data producer library for Druid）。通过我们自己的程序，对数据进行清洗后，借助tranquility发送数据给overlord，看图：

上面对Druid节点做了一下大概的介绍，要想让Druid正常工作，除了运行Druid自身的这些节点外，还需要借助三个依赖。

♦ deepstorage：用来永久存储segment数据，一般是s3和hdfs。

♦ zookeeper：用来管理集群状态，保证集群内的数据统一。

♦ metadata storage：用来保存一些元数据，规则数据，配置数据等。

deepstorage功能很单一不用多说，那么zookeeper和metadata storage在Druid工作流程中，起着什么样的作用呢？以聚合数据和查询数据简单介绍一下zookeeper和metadata storage在Druid中的工作。

聚合数据： peon在做聚合任务的时候会周期性的告诉zookeeper，正在为哪个datasource，生成哪个时间段的数据，即生成哪个segment，当聚合任务执行完成后，peon会将segment生成到deepstroage，同时会将生成的segment的描述信息保存到metadata storage中，并同时通知zookeeper。

查询数据：broker接收数据的查询请求后，会根据请求参数，通过zookeeper分析请求的segment在哪里：是在peon上(middlemaanger中还没有完全生成一个segment，即热数据/实时数据)，还是在某个或者某些历史节点中，分析出结果后分别向对应节点发出请求，获取数据。broker获取各个节点返回过来的数据，再次进行数据归并并最终返回给请求者。

metadata database的作用又是什么呢？peon完成数据聚合后，首先将其保存到deepstorage中，同时会将聚合的产物segment描述信息(在hdfs中的保存路径)保存到metadata database中，并通知zookeeper。注意：Coordinator和historical节点一直和zookeeper保持着连接，Coordinator还和metadata database保持着连接。当Coordinator发现zookeeper上有一个新的segment生成后，会通知historical节点去加载这个数据，通知方式依然是借助zookeeper。

前文说到Coordinator节点管理segment的下载和删除，是发生在聚合数据的过程中，peon完成数据聚合后会通知zookeeper，而Coordinator一直监控着zookeeper，当发现有一个新的segment生成后，会通过zookeeerp通知某个historical节点去下载segment。而删除是因为Historical节点容量是一定的（可配置的），如果超过了容量，他会删除过期数据或旧数据。

Druid官方提供的流程图如下：

Druid在透视宝的作用—

Druid是如何从透视宝接入数据的呢？如上图所示： 

目前，我们有两个服务，一个服务是连接kafka和Druid，即从kafka消费数据发送给Druid。一个是连接broker，并对外提供api，供前端查询数据做报表展示。通过使用Druid，大大节省了透视宝的数据存储的空间，提升了数据查询的效率，更好的满足客户大数据分析的需求。