Druid架构分析
一、基本概念
Datasource：Druid中的Datasource可以理解为Mysql中的表，但Druid对“表”中的”列”进行了分类，其包含下面三个重要的概念：
1. 时间列(Timestamp):每行数据的时间值，默认使用UTC时间格式，保存到毫秒级别，本列是数据聚合以及范围查询的重要指标
2. 维度列（Dimension）：标识数据行的列，可以是一列，也可以是多列
3. 指标列(Metric):用来做计算或是统计的列，可以是一列，也可以是多列
Segment： Druid中数据的实际物理存储格式，Druid在数据摄入时，会对数据以时间维度进行分片存储，最小存储单位即为Segment。
二、Druid架构组成
实时节点（Realtime Node）：即时摄入实时数据以及生成Segment数据文件
历史节点（Historical Node）：加载已生成好的数据文件，以供数据查询。
查询节点（Broker Node）：对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后放回给调用方。
协调节点（Coordinator Node）：负责历史节点的数据负载均衡，以及通过规则管理数据的生命周期
同时，集群还包括以下三类外部依赖
元数据库（MetaStorage）：存储Driud集群的元数据信息，比如Segment的相关信息，支持使用MySQL和PostgreSQL
分布式协调服务（Coordination）：为Druid集群提供一致性协调服务的组件，通常为Zookeeper
数据文件存储库（DeepStorage）:存放生成的Segment数据文件，并供历史节点下载。对于单节点集群可以是本地磁盘，而对于分布式集群一般是HDFS或NFS。
三、Druid高性能原理
1.相对于其他数据库，Druid Datasource最大的特点是在输入存储时，就可以对数据进行聚合操作，该特性不仅可以节省存储的空间，而且可以提高聚合查询的效率。
2. Druid中通过Segment实现了对数据的横众向切割操作。横向切割主要只指站在时间范围的角度，将不同时间段的数据存储在不同的Segment文件中，查询时只需要根据时间条件遍历对应的Segment文件即可；数据的纵向切割即面向列进行进行数据压缩和存储。
3.Druid中Segment采用类LSM-Tree（日志结构合并树）写入模型保证写入性能，同时数据分级存储（最近2小时的数据存储在内存中，最近一天的数据存储在SSD中，一天以后的数据存储在HDD中）保证查询性能以及存储成本。
对于可以摄取实时数据的实时节点而言，涉及操作大致如下：
a. 实时数据首先会被加载到实时节点内存中的堆结构缓冲区
b. 当条件满足时，缓冲区的数据会被flush到磁盘上变成一个数据块
c. 将磁盘上的数据块加载到内存中的非堆区
d. 查询节点可以同时从堆缓冲区与非堆区进行数据查询
对于已经落地到实时节点的磁盘的数据块，还会进行如下处理：
a. 实时节点周期性的将统一时间段内的数据块文件合并成一个大的文件
b. 生成好的大文件会立即被上传到Deep Storage
c. 协调节点感知到有新的数据块文件被上传到DeepStorage后，会协调某个历史节点对相关文件进行下载
d. 历史节点加载完相关数据后，会通过协调节点对外声明对于该文件内容的查询，都由自己提供。产生该文件的实时节点也会对外声明，不再负责对应数据的查询
4.Segment中使用了Bitmap索引技术，大大加快了数据聚合查询性能。
例如：
select click from datasource where Gender = ‘女’ and City = ‘武汉’
很显然，如果不使用任何技术手段的话，在原始表上根据如上两个维度的过滤条件进行查询需要遍历整个原始表，并对相应维度列进行过滤，这个代价很显然是非常可观的。
使用Bitmap索引的基本原理是将这两列上的数值映射到bitmap上，再去执行and、or等这种查询谓词。在上述示例中，将Gender以及City两列映射成bitmap如下图所示：
执行 Gender = ‘女’ and City = ‘武汉’的结果是：
最后就直接查询第二行和第四行的click值即可
5.数据的高度压缩（索引压缩，数据文件压缩）
A. 预聚合中，对摄入数据进行聚合汇总
B.在每个维度列的bitmap结构中，实际上每个维度列会构建维度字典，例如上表中的Gender列，则会维护<’男’，0>、<’女’，1>的维度列，而后续bitmap索引构建中则为下右图所示
C. 每个维度列位图数据都会存在大量的连续的0或者连续的1，非常适合压缩编码，减小存储空间
D. 除了数据的压缩，还有存储文件上的压缩
参考：
《Druid实时大数据分析》
Druid官网：http://druid.io/