大数据-155 Apache Druid 架构与原理详解数据存储索引服务压缩机制

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka（已更完）
Spark（已更完）
Flink（已更完）
ClickHouse（已更完）
Kudu（已更完）
Druid（正在更新…）

章节内容

上节我们完成了如下的内容：

Apache Druid 基础架构详解
Apache Druid 架构演进详解

在这里插入图片描述

数据存储

Druid中的数据存储在被称为DataSource中，DataSource类似RDBMS中的Tablet
每个DataSource按照时间划分，每个时间范围成为一个Chunk（比如按天分区，则一个Chunk为一天）
在Chunk中数据被分为一个或多个Segment，Segment是数据实际存储结构，Datasource、Chunk只是一个逻辑概念
Segment是按照时间组织称Chunk，所以在按照时间查询数据时，效率非常高。
每个Segment都是一个单独的文件，通过包含几百万行的数据

在这里插入图片描述

数据分区

Druid处理的是事件数据，每条数据都会带有一个时间戳，可以使用时间进行分区
上图指定了分区粒度为天，那么每天的数据都会被单独存储和查询

Segment内部存储

Druid采用列式存储，每列数据都是在独立的结构中存储
Segment中的数据类型主要分为三种：
类型1 时间戳：每一行数据，都必须有一个TimeStamp，Druid一定会基于事件戳来分片
类型2 维度列：用来过滤Fliter或者组合GroupBY的列，通过是String、Float、Double、Int类型
类型3 指标列：用来进行聚合计算的列，指定的聚合函数 sum、average等

在这里插入图片描述
MiddleManger节点接受到Ingestion的任务之后，开始创建Segment：

转换成列式存储格式
用bitmap来建立索引（对所有的dimension列建立索引）
使用各种压缩算法
算法1：所有的使用 LZ4 压缩
算法2：所有的字符串采用字典编码、标识以达到最小化存储
算法3：对位图索引使用位图压缩

Segment创建完成之后，Segment文件就是不可更改的，被写入到深度存储（目的是为了防止MiddleManager节点宕机后，Segment丢失）。然后Segment加载到Historicaljiedian，Historical节点可以直接加载到内存中。
同时，Metadata store 也会记录下这个新创建的Segment的信息，如结构、尺寸、深度存储的位置等等
Coordinator节点需要这些元数据来协调数据的查找。

索引服务

索引服务是数据导入并创建Segment数据文件的服务
索引服务是一个高可用的分布式服务，采用主从结构作为架构模式，索引服务由三大组件构成：

overlord 作为主节点
MiddleManage作为从节点
peon用于运行一个Task

索引服务架构图如下图所示：
在这里插入图片描述

服务构成

Overlord组件

负责创建Task、分发Task到MiddleManger上运行，为Task创建锁以及跟踪Task运行状态并反馈给用户

MiddleManager组件

作为从节点，负责接收主节点分配的任务，然后为每个Task启动一个独立的JVM进程来完成具体的任务

Peon（劳工）组件

由 MiddleManager 启动的一个进程用于一个Task任务的运行

对比YARN

Overlord 类似 ResourceManager 负责集群资源管理和任务分配
MiddleManager 类似 NodeManager 负责接收任务和管理本节点的资源
Peon 类似 Container 执行节点上具体的任务

Task类型

index hadoop task：Hadoop索引任务，利用Hadoop集群执行MapReduce任务以完成Segment数据文件的创建，适合体量较大的Segments数据文件的创建任务
index kafka task：用于Kafka数据的实时摄入，通过Kafka索引任务可以在Overlord上配置一个KafkaSupervisor，通过管理Kafka索引任务的创建和生命周期来完成Kafka数据的摄取
merge task：合并索引任务，将多个Segment数据文件按照指定的聚合方法合并为一个segments数据文件
kill task：销毁索引任务，将执行时间范围内的数据从Druid集群的深度存储中删除

索引及压缩机制

Druid的查询时延低性能好的主要原因是采用了五个技术点：

数据预聚合
列式存储、数据压缩
Bitmap索引
mmap（内存文件映射方式）
查询结果的中间缓存

数据预聚合

Druid 通过一恶搞RollUp的处理，将原始数据在注入的时候就进行了汇总处理
RollUp可以压缩我们需要保存的数据量
Druid会把选定的相同维度的数据进行聚合操作，可以存储的大小
Druid可以通过queryGranularity来控制注入数据的粒度，最小的queryGranularity是millisecond（毫秒级别）

Roll-Up

聚合前：
在这里插入图片描述
聚合后：

位图索引

Druid在摄入的数据示例：
在这里插入图片描述

第一列为时间，Appkey和Area都是维度列，Value为指标列
Druid会在导入阶段自动对数据进行RollUp，将维度相同组合的数据进行聚合处理
数据聚合的粒度根据业务需要确定

按天聚合后的数据如下：
在这里插入图片描述
Druid通过建立位图索引，实现快速数据查找。
BitMap索引主要为了加速查询时有条件过滤的场景，Druid生成索引文件的时候，对每个列的每个取值生成对应的BitMap集合：

索引位图可以看作是：HashMap<String, BitMap>

Key就是维度的值
Value就是该表中对应的行是否有该维度的值

在这里插入图片描述

SQL查询

SELECT sum(value) FROM tab1
WHERE time='2020-01-01'
AND appkey in ('appkey1', 'appkey2')
AND area='北京'

执行过程分析：

根据时间段定位到Segment
appkey in (‘appkey1’, ‘appkey2’) and area=‘北京’ 查到各自的bitmap
（appkey1 or appkey2）and 北京
(110000 or 001100) and 101010 = 111100 and 101010 = 101000
符合条件的列为：第一行 & 第三行，这几行 sum(value)的和为40

GroupBy查询

SELECT area, sum(value)
FROM tab1
WHERE time='2020-01-01'
AND appkey in ('appkey1', 'appkey2')
GROUP BY area

该查询与上面的查询不同之处在与将符合条件的列：

appkey1 or appkey2
110000 or 001100 = 111100
将第一行到第四行取出来
在内存中做分组聚合，结果为：北京40、深圳60