Druid架构理解

Druid架构

1. 数据源：kafka，awsS3等

2. dataSource 和 segement概念解析：

dataSource&segement

Druid数据存储在“dataSources ”中，类似于传统RDBMS中的表。每个dataSource按时间划分，并可选择进一步按其他属性划分。每个时间范围称为“chunk”（例如，如果您的数据源按天分区，则为一天）。在chunk内，数据被划分为一个或多个 “segement”。每个segement都是单个文件，通常包含多达几百万行数据。由于segement被组织成时间chunk，因此我们可以将segement看作在如图所示的时间轴上存在。

dataSource可能只有几个segement，最多可达数十万甚至数百万个segement。每个segment都开始在MiddleManager上创建生命，并且在那时，它是可变的和未提交的。segment的构建过程包括以下步骤，旨在生成紧凑的数据文件并支持快速查询：

• Conversion to columnar format 转换为柱状格式
• Indexing with bitmap indexes 使用位图索引进行索引
• Compression using various algorithms 使用各种算法进行压缩(如：bitmap压缩)

定期提交和发布 segments。此时，它们被写入Deep Storage，成为不可变真实文件，并从MiddleManagers转移到Historicals（有关详细信息，请参阅 Architecture ）。关于该segment的记录也被写入metadata store.。此记录是关于segment的在metadata里的描述，包括segment的schema、size以及它在Deep Store上的存储位置。这些记录是Coordinator 用于了解群集上有哪些数据可用。

dataSource和segement

因为Druid数据按照时间排序的(时序)，dataSource中会记录时间列。
数据横向切割：按照时间横向切割数据
数据纵向切割：按照列纵向切割数据

3架构解析

Druid架构

1. 我们的流式数据（Streaming Data）和块数据（Batch Data）先通过Middle Managers，Middle Manager定期提交和发布 segments，并将这些segments写入导Deep Storage，Deep Storage的作用就是存储Segment数据文件，并且对Segment进行合并，此时，该记录(元数据信息）会被写入到Metadata Storage，并将Segments转移到Historicals上。

2. 查询请求会先到Broker上，Broker去找哪些Segments有相关的数据，Segments的总是按时间进行修剪，也可能根据数据源的分区方式由其他属性进行修剪，然后Broker会去查找哪些Historicals和MiddleManagers上有这些Segments并对它们发送重写的子查询，Historicals和MiddleManagers根据子查询返回结果，Broker拿到结果并对结果进行合并最终获得最后的结果，并将结果返回最初查询者。

3. 将Deep storage和metadata Storage分开也就使得Druid完全容错
   4.zookeeper的作用是：内部服务，协调和leader的选举。