应用性能管理的本质就是通过对业务数据和IT系统性能数据的准确抓取和深度分析，为企业业务和IT的可持续发展提供平台支撑。而云智慧透视宝产品在得到越来越多客户认可的同时，业务数据也在急剧增加，无论是数据存储还是数据查询，都会给原有透视宝架构带来较大压力。
经过反复挑选，云智慧透视宝选择了用于大数据实时查询和分析的高容错、高性能开源分布式系统Druid，接下来就由透视宝开发工程师lucky为我们详细解读，云智慧是如何利用Druid实现数据聚合的。
大数据的挑战—
由于数据量的激增，云智慧透视宝后端数据处理系统主要面临两方面问题：
首先，在数据存储方面，因为系统需要保存所有原始数据，每天十几TB，甚至几十TB的数据量，直接导致了资源需求和运营成本的增加；
其次，在数据查询方面，如果查询是建立在所有原始数据集的基础上，那么对机器的cpu和内存要求就会非常高。
那么Druid会帮我们解决这些问题吗？！答案是肯定的，使用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工作流程—
一个Druid集群有各种类型的节点（Node）组成，每种节点都被设计来做某组事情，这样的设计可以隔离关注并简化整个系统的复杂度。Druid包含如下节点：overlord节点，middlemanager节点，broker节点，historical节点和coordinator节点，在设计时充分考虑到了高可用性，各种节点挂掉都不会使Druid停止工作。
下面简单介绍下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，大大节省了透视宝的数据存储的空间，提升了数据查询的效率，更好的满足客户大数据分析的需求。今天的分享也到此结束，希望能给你的工作带来一点帮助。
