138 lines
11 KiB
Markdown
138 lines
11 KiB
Markdown
<!-- toc -->
|
||
|
||
## 架构设计
|
||
Druid有一个多进程、分布式的架构，该架构设计为云友好且易于操作。每个Druid进程都可以独立配置和扩展，在集群上提供最大的灵活性。这种设计还提供了增强的容错能力：一个组件的中断不会立即影响其他组件。
|
||
|
||
### 进程与服务
|
||
Druid有若干不同类型的进程，简单描述如下：
|
||
|
||
* [Coordinator](Coordinator.md) 进程管理集群中数据的可用性
|
||
* [Overlord](Overlord.md) 进程控制数据摄取负载的分配
|
||
* [Broker](Broker.md) 进程处理来自外部客户端的查询请求
|
||
* [Router](Router.md) 进程是一个可选进程，可以将请求路由到Brokers、Coordinators和Overlords
|
||
* [Historical](Historical.md) 进程存储可查询的数据
|
||
* [MiddleManager](MiddleManager.md) 进程负责摄取数据
|
||
|
||
Druid进程可以按照您喜欢的方式部署，但是为了便于部署，我们建议将它们组织成三种服务器类型：Master、Query和Data。
|
||
|
||
* **Master**: 运行Coordinator和Overlord进程，管理数据可用性和摄取
|
||
* **Query**: 运行Broker和可选的Router进程，处理来自外部客户端的请求
|
||
* **Data**: 运行Historical和MiddleManager进程，执行摄取负载和存储所有可查询的数据
|
||
|
||
关于进程和服务组织的更多信息，可以查看[Druid进程与服务](Processes.md)
|
||
|
||
### 外部依赖
|
||
除了内置的进程类型外，Druid同时有三个外部依赖，它们旨在利用现有的基础设施（如果有的话）。
|
||
|
||
#### 深度存储
|
||
|
||
每个Druid服务器都可以访问的共享文件存储。在集群部署中，通常使用一个像S3或HDFS这样的分布式对象存储，或者是一个网络挂载的文件系统。在单服务器部署中，通常使用本地磁盘。Druid使用深度存储来存储任何已被系统接收的数据。
|
||
|
||
Druid只使用深度存储作为数据备份，并作为在后台Druid进程之间传输数据的一种方式。为了响应查询，Historical进程不会从深层存储中读取数据，而是从本地磁盘读取在执行任何查询之前预缓存的段，这意味着Druid在查询期间不需要访问深层存储，这有助于它提供尽可能最好的查询延迟。这也意味着您必须在深层存储和所有Historical进程中都有足够的磁盘空间来存储计划加载的数据。
|
||
|
||
深度存储是Druid弹性、容错设计的重要组成部分。即使每个数据服务器都丢失并重新配置，Druid也可以从深层存储启动。
|
||
|
||
有关更多详细信息，请参见[深度存储](Deepstorage.md)
|
||
|
||
#### 元数据存储
|
||
元数据存储包含各种共享的系统元数据，如段可用性信息和任务信息。在集群部署中，通常使用像PostgreSQL或MySQL这样的传统RDBMS。在单服务器部署中，通常使用本地存储的Apache Derby数据库。
|
||
|
||
有关更多详细信息，请参见[元数据存储](Metadata.md)
|
||
|
||
#### Zookeeper
|
||
用于内部服务发现、协调和领导选举。
|
||
|
||
有关更多详细信息，请参见[Zookeeper](Zookeeper.md)
|
||
|
||
### 架构图
|
||
下图显示了使用建议的Master/Query/Data服务组织，查询和数据如何通过此体系结构流动：
|
||
|
||
|
||
|
||
### 存储设计
|
||
#### 数据源和段
|
||
Druid数据被存储在"datasources"中，类似于传统RDBMS中的表。每一个数据源可以根据时间进行分区，可选地还可以进一步根据其他属性进行分区。每一个时间范围称为一个"块（chunk）"(例如，如果数据源按天分区，则为一天)。在一个块中，数据被分为一个或者多个"段（segments）"。每个段是一个单独的文件，一般情况下由数百万条数据组成。由于段被组织成时间块，因此有时将段视为存在于如下时间线上是有帮助的：
|
||
|
||
|
||
|
||
一个数据源可能有几个段到几十万甚至几百万个段。每个段都是在MiddleManager上创建的，但此时段是可变的和未提交的。段构建过程包括以下步骤，旨在生成一个紧凑且支持快速查询的数据文件：
|
||
* 转换为列格式
|
||
* 构建位图索引
|
||
* 使用不同的算法进行压缩
|
||
* 字符串列id存储最小化的字典编码
|
||
* 对位图索引做压缩
|
||
* 所有列的类型感知压缩
|
||
|
||
周期性地，段被提交和发布，此时，它们将被写入到深度存储且变得不可更改，同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中，这个信息是一个自描述的信息，包括段的schema、大小以及在深度存储中的位置，Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的
|
||
|
||
有关段文件格式的信息，请参见[段文件](Segments.md)
|
||
|
||
有关数据在Druid的建模，请参见[schema设计](../DataIngestion/schemadesign.md)
|
||
|
||
#### 索引和切换(Indexing and handoff)
|
||
|
||
*索引(Indexing)*是创建新段的一种机制，*切换(handoff)*是发布新段并开始由Historical进程提供服务的机制。该机制在索引端的工作方式如下：
|
||
|
||
1. 索引任务开始运行并生成新段。必须先在索引任务构建段之前确定段的标识符，对于一个追加数据类型的任务（例如Kafka任务或者其他追加模式的索引任务），这将通过调用Overlord的"allocate" API来在现有的段集合中添加一个新的分区。对于一个重写类型的任务（例如Hadoop任务，或者一个非追加模式的索引任务）这是通过锁定间隔并创建新的版本号和新的段集来完成的。
|
||
2. 如果一个索引任务是实时任务（像kafka任务），那么段在此刻可以被立即查询，它是可用的，但是未发布。
|
||
3. 索引任务完成对段的数据读取后，会将其推送到深层存储，然后通过将记录写入元数据存储来发布。
|
||
4. 如果索引任务是实时任务，则此时它将等待Historical进程加载段。如果索引任务不是实时任务，它将立即退出。
|
||
|
||
在Coordinator和Historical方面：
|
||
1. 对于新发布的段，Coordinator会周期性（默认是1分钟）的拉取元数据存储信息
|
||
2. 当Coordinator发现一个段是发布且可以被使用的、但是不可用的状态时，它会选个一个Historical进程来加载这个段
|
||
3. Historical加载这个段并开始为其服务
|
||
4. 此时，如果索引任务正在等待切换，它将退出
|
||
|
||
|
||
#### 段标识符
|
||
段都有一个由四部分组成的标识符，包含以下组件：
|
||
* 数据源名称
|
||
* 时间间隔（包含段的时间块，这与摄取时指定的 `segmentGranularity` 有关）
|
||
* 版本号（通常是ISO8601时间戳，对应于段集首次启动的时间）
|
||
* 分区号（整数，在datasource+interval+version中是唯一的,不一定是连续的）。
|
||
|
||
例如这个一个段标识符，数据源为 `clarity-cloud0`, 时间块为 `2018-05-21T16:00:00.000Z/2018-05-21T17:00:00.000Z`, 版本为 `2018-05-21T15:56:09.909Z` 以及分区编号为 `1`:
|
||
|
||
```
|
||
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z_1
|
||
```
|
||
分区号为0的段（块中的第一个分区）忽略分区号，如下例所示，该段与上一个时间块位于同一时间块中，但分区号为0而不是1：
|
||
|
||
```
|
||
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z
|
||
```
|
||
|
||
#### 段版本
|
||
|
||
您可能想知道上一节中描述的“版本号”是用来做什么的。或者，你可能不想知道，在这种情况下对你有好处，你可以跳过这一节！
|
||
|
||
它支持批处理模式覆盖。在Druid中，如果您所做的只是附加数据，那么每个时间块只有一个版本。但是当您覆盖数据时，幕后发生的事情是，使用相同的数据源、相同的时间间隔、但更高的版本号创建一组新的段。这向Druid系统的其他部分发出了一个信号：旧版本应该从集群中删除，新版本应该替换它。
|
||
|
||
这个切换对用户来说似乎是瞬间发生的，因为Druid通过首先加载新数据（但不允许查询它）来处理这个问题，然后在新数据全部加载后，将所有新查询切换为使用这些新段。几分钟后，它会把旧的段卸载下来。
|
||
|
||
#### 段生命周期
|
||
|
||
每个段都有一个生命周期，涉及以下三个主要领域：
|
||
1. **元数据存储**：段的元数据（一个小的JSON，通常不超过几个KB）在段构建完成后存储在元数据存储中，将段的记录插入到元数据存储中称为**发布(Publishing)**。这些元数据记录中有一个 `used` 的布尔标识，控制着段是否可查询。被实时任务创建的段在发布之前是可用的，因为它们仅在完成之时发布，并且不再接受额外的数据行
|
||
2. **深度存储**：一旦构建了一个段，在将元数据发布到元数据存储之前就立刻将段数据文件推送到深度存储
|
||
3. **可查询性**：在某些Druid数据服务器上段是可以进行查询的，如实时任务或Historical进程
|
||
|
||
可以使用Druid SQL查询 `sys.segments` 表检查当前活动段的状态，它包括以下标志：
|
||
|
||
* `is_published`: 如果段元数据已发布到元数据存储且 `used` 是true的话，则为true
|
||
* `is_available`: 如果段当前可用于查询（实时任务或Historical进程），则为true
|
||
* `is_realtime`: 如果段仅在实时任务上可用，则为true。对于使用实时摄取的数据源，这通常从true开始，然后在发布和切换段时变为false
|
||
* `is_overshadowed`: 如果段已发布（ `used` 设置为true），并且被某些其他已发布段完全覆盖，则为true。一般来说，这是一个过渡状态，处于该状态的段很快将其 `used` 标志自动设置为false
|
||
|
||
### 查询处理
|
||
|
||
查询首先进入[Broker](../Design/Broker.md), Broker首先鉴别哪些段可能与本次查询有关。 段的列表总是按照时间进行筛选和修剪的，当然也可能由其他属性，具体取决于数据源的分区方式。然后，Broker将确定哪些[Historical](../Design/Historical.md)和[MiddleManager](../Design/MiddleManager.md)为这些段提供服务、并向每个进程发送一个子查询。 Historical和MiddleManager进程接收查询、处理查询并返回结果，Broker将接收到的结果合并到一起形成最后的结果集返回给调用者。
|
||
|
||
Broker精简是Druid限制每个查询扫描数据量的一个重要方法，但不是唯一的方法。对于比Broker更细粒度级别的精简筛选器，每个段中的索引结构允许Druid在查看任何数据行之前，找出哪些行（如果有的话）与筛选器集匹配。一旦Druid知道哪些行与特定查询匹配，它就只访问该查询所需的特定列。在这些列中，Druid可以从一行跳到另一行，避免读取与查询过滤器不匹配的数据。
|
||
|
||
因此，Druid使用三种不同的技术来最大化查询性能：
|
||
|
||
* 精简每个查询访问的段
|
||
* 在每个段中，使用索引标识必须访问哪些行
|
||
* 在每个段中，只读取与特定查询相关的特定行和列 |