Apache Druid 高性能的实时分析型数据库( 二 ) _Apache

四、Druid架构图如图所示，分为三种服务器类型：主服务器（Master）、查询服务器（Query）和数据服务器（Data）。
Master：运行Coordinator和Overlord进程，管理数据可用性和摄取。
Query：运行Broker和可选的Router进程，处理来自外部客户端的查询。
Data：运行Historical和MiddleManager进程，运行数据的采集以及存储所有历史查询数据负载。

文章插图

Druid有若干不同类型的进程，简单描述如下：
Coordinator 进程：负责集群 Segment 的管理和发布，并确保 Segment 在 Historical 集群中的负载均衡。
Overlord 进程：负责接受任务、协调任务的分配、创建任务锁以及收集、返回任务运行状态给客户端；通过设置 druid.Coordinator.asOverlord.enabled 属性， Coordinator进程和Overlord进程可以作为单个组合进程运行。让 Coordinator 具备 Overlord 功能，这样可以减少一个组件的部署和运维。
Broker 进程：负责从客户端接收查询请求，并将查询请求转发给 Historical 节点和 MiddleManager 节点。Broker 节点需要感知 Segment 信息在集群上的分布。
Router 进程：是一个可选进程，可以将请求路由到Brokers、Coordinators和Overlords 。
Historical 进程：主要负责加载索引文件，同时提供历史数据的查询服务。
MiddleManager 进程：主要是负责数据索引，生成索引文件，并把索引文件先发布到一个共享的存储系统里，如普遍采用的 HDFS 系统。

在架构图中，最下面的部分是外部依赖。除了内置的进程类型外， Druid同时有三个外部依赖，它们旨在利用现有的基础设施。
（1）Metadata Storage
存储关于Druid中的Metadata ，规则数据、配置数据等，主要包含以下几张表：
druid_config（通常是空的）， druid_rules（协作节点使用的一些规则信息，比如哪个segment从哪个node去load）， druid_segments（存储每个segment的metadata信息）。
生产环境中可以使用MySQL 。

（2）Zookeeper
分布式协调服务，用于节点管理和事件监控。
查询节点通过Zookeeper来感知实时节点和历史节点的存在，提供查询服务。
协调节点通过Zookeeper感知历史节点，实现负载均衡。
统治节点、协调节点的leader选举。

（2）Deep Storage
用于存储 Segment 文件供 Historical 节点下载。Deep Storage 不属于 Druid 内部组件，用户可根据系统规模来自定义配置。单节点可用本地磁盘，分布式可用 HDFS 。

五、Druid的数据源和分段Druid的数据存储在DataSource中， DataSource 是一个逻辑概念，表示 Druid 的基本数据结构，可以理解为关系型数据库中的表。它包含时间、维度和指标三列。
时间（TimeStamp）：表明每行数据的时间值，默认使用 UTC 时间格式且精确到毫秒级别。这个列是数据聚合与范围查询的重要维度。
维度（Dimension）：标识数据行的各个类别信息。
指标（Metric）：用于聚合计算的列，这些指标列通常是一些数字，主要操作包括 Count、Sum 和 Mean 等。

每一个数据源按照时间进行分段，当然你还可以选择其他属性进行分段。
每一个时间区间被称为一个"Chunk" 。举个例子，如果以天分区，则一个Chunk为一天。在一个Chunk内，数据被分成一个或者多个"segments" 。每个segment是一个单独的文件，它由数以百万的数据行构成。因为segment是组织在时间Chunk里的，所以按照时间曲线有助于理解segments 。

文章插图

这些segment是按照时间组织成的Chunk ，所以在按照时间查询数据时，效率非常高。

segment 是 Druid 中数据的实际物理存储格式， Druid 正是通过 segment 实现了对数据的横纵向切割（Slice and Dice）操作：
横向：通过参数 segmentGranularity 的设置，将不同时间范围内的数据存储在不同的 segment 数据块中。这样在指定时间范围内查询时，可以不用扫全表。