druid-docs-cn/Design/Design.md

11 KiB
Raw Blame History

架构设计

Druid有一个多进程、分布式的架构该架构设计为云友好且易于操作。每个Druid进程都可以独立配置和扩展在集群上提供最大的灵活性。这种设计还提供了增强的容错能力一个组件的中断不会立即影响其他组件。

进程与服务

Druid有若干不同类型的进程简单描述如下

  • Coordinator 进程管理集群中数据的可用性
  • Overlord 进程控制数据摄取负载的分配
  • Broker 进程处理来自外部客户端的查询请求
  • Router 进程是一个可选进程可以将请求路由到Brokers、Coordinators和Overlords
  • Historical 进程存储可查询的数据
  • MiddleManager 进程负责摄取数据

Druid进程可以按照您喜欢的方式部署但是为了便于部署我们建议将它们组织成三种服务器类型Master、Query和Data。

  • Master: 运行Coordinator和Overlord进程管理数据可用性和摄取
  • Query: 运行Broker和可选的Router进程处理来自外部客户端的请求
  • Data: 运行Historical和MiddleManager进程执行摄取负载和存储所有可查询的数据

关于进程和服务组织的更多信息,可以查看Druid进程与服务

外部依赖

除了内置的进程类型外Druid同时有三个外部依赖它们旨在利用现有的基础设施如果有的话

深度存储

每个Druid服务器都可以访问的共享文件存储。在集群部署中通常使用一个像S3或HDFS这样的分布式对象存储或者是一个网络挂载的文件系统。在单服务器部署中通常使用本地磁盘。Druid使用深度存储来存储任何已被系统接收的数据。

Druid只使用深度存储作为数据备份并作为在后台Druid进程之间传输数据的一种方式。为了响应查询Historical进程不会从深层存储中读取数据而是从本地磁盘读取在执行任何查询之前预缓存的段这意味着Druid在查询期间不需要访问深层存储这有助于它提供尽可能最好的查询延迟。这也意味着您必须在深层存储和所有Historical进程中都有足够的磁盘空间来存储计划加载的数据。

深度存储是Druid弹性、容错设计的重要组成部分。即使每个数据服务器都丢失并重新配置Druid也可以从深层存储启动。

有关更多详细信息,请参见深度存储

元数据存储

元数据存储包含各种共享的系统元数据如段可用性信息和任务信息。在集群部署中通常使用像PostgreSQL或MySQL这样的传统RDBMS。在单服务器部署中通常使用本地存储的Apache Derby数据库。

有关更多详细信息,请参见元数据存储

Zookeeper

用于内部服务发现、协调和领导选举。

有关更多详细信息,请参见Zookeeper

架构图

下图显示了使用建议的Master/Query/Data服务组织查询和数据如何通过此体系结构流动

存储设计

数据源和段

Druid数据被存储在"datasources"中类似于传统RDBMS中的表。每一个数据源可以根据时间进行分区可选地还可以进一步根据其他属性进行分区。每一个时间范围称为一个"块chunk"(例如,如果数据源按天分区,则为一天)。在一个块中,数据被分为一个或者多个"段segments"。每个段是一个单独的文件,一般情况下由数百万条数据组成。由于段被组织成时间块,因此有时将段视为存在于如下时间线上是有帮助的:

一个数据源可能有几个段到几十万甚至几百万个段。每个段都是在MiddleManager上创建的但此时段是可变的和未提交的。段构建过程包括以下步骤旨在生成一个紧凑且支持快速查询的数据文件

  • 转换为列格式
  • 构建位图索引
  • 使用不同的算法进行压缩
    • 字符串列id存储最小化的字典编码
    • 对位图索引做压缩
    • 所有列的类型感知压缩

周期性地段被提交和发布此时它们将被写入到深度存储且变得不可更改同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中这个信息是一个自描述的信息包括段的schema、大小以及在深度存储中的位置Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的

有关段文件格式的信息,请参见段文件

有关数据在Druid的建模请参见schema设计

索引和切换(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, Broker首先鉴别哪些段可能与本次查询有关。 段的列表总是按照时间进行筛选和修剪的当然也可能由其他属性具体取决于数据源的分区方式。然后Broker将确定哪些HistoricalMiddleManager为这些段提供服务、并向每个进程发送一个子查询。 Historical和MiddleManager进程接收查询、处理查询并返回结果Broker将接收到的结果合并到一起形成最后的结果集返回给调用者。

Broker精简是Druid限制每个查询扫描数据量的一个重要方法但不是唯一的方法。对于比Broker更细粒度级别的精简筛选器每个段中的索引结构允许Druid在查看任何数据行之前找出哪些行如果有的话与筛选器集匹配。一旦Druid知道哪些行与特定查询匹配它就只访问该查询所需的特定列。在这些列中Druid可以从一行跳到另一行避免读取与查询过滤器不匹配的数据。

因此Druid使用三种不同的技术来最大化查询性能

  • 精简每个查询访问的段
  • 在每个段中,使用索引标识必须访问哪些行
  • 在每个段中,只读取与特定查询相关的特定行和列