概述

设计原则

• 快速查询：部分数据的聚合 + 内存化 + 索引
• 水平扩展能力：分布式数据 + 并行化处理
• 实时分析：不可变的过去 + 只追加的未来

实时分析

Druid 提供了包含基于时间维度数据的存储服务，并且任何一行都是历史真实事件。所以设计之初约定事件一旦进入系统，就不可改变。

历史数据存储以segment数据文件的方式存储在深度存储系统（S3、HDFS）中。当需要查询时，Druid在再把数据从深度存储系统中装载到内存中查询使用。

技术特点

• 数据吞吐量大
• 支持流式数据摄入和实时索引服务
• 查询灵活且快
• 社区支持力度大

基本概念

数据格式

• 数据源（DataSource）：类似数据库中表的概念
  • 时间列（TimeStamp）
  • 维度列（Dimension）
  • 指标列（Metric）

如下表，时间是时间列，国家、平台、语言是维度列，激活数、充值金额是指标列

数据摄入

• 实时数据摄入
• 批处理数据摄入

数据查询

• 原生查询是采用JSON格式，通过HTTP传送；
• 不支持标准的SQL语言查询；
• 的社区也为我们提供了多种查询方式（Python接口pydruid、R接口RDruid、JavaScript接口plywood、类SQL接口plyql、PHP接口druid-php等）

扩展性

• 分布式系统，采用Lambda架构，实时数据和批处理数据解耦；
• 实时处理面向写多读少优化
• 批处理面向读多写少优化
• Shared nothing架构，各个节点有自己的存储和计算能力
• 使用zookeeper协调，使用mysql/postgresql提供元数据存储

架构

总体架构

• 实时节点（Realtime Mode）：即时摄入实时数据，及生成Segment数据文件；
• 历史节点（Historical Mode）：负责处理历史数据存储和查询历史数据（非实时），历史节点从“deep storage”下载segments，将结果数据返回给查询节点，历史节点加载完segment通知Zookeeper，历史节点使用Zookeeper监控需要加载或者删除哪些新的；
• 查询节点（Broker Mode）：对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后返回给调用方；
• 协调节点（Coordinator Mode）：负责劣势节点的数据负载均衡，以及通过规则（Rule）管理数据的生命周期；
• 索引服务（Indexing Service）： 索引服务节点由多个worker组成的集群，负责为加载批量的和实时的数据创建索引，并且允许对已经存在的数据进行修改。

索引服务：

• 统治节点（Overlord Node）：索引服务的主节点，对外负责接受任务请求，对内负责将任务分解下去并下发到从节点（中间管理者）上；
• 中间管理者（Middle Managers）：索引服务的工作节点，负责接收通知节点分配的任务，然后启动相关的苦工接独立的JVM完成具体的任务；
• 苦工（Peons）：独立的JVM，完成具体的任务。

索引服务的结构类似Hadoop Yarn 架构。

外部依赖

• 元数据库（MetaStore）：存储Druid集群的原始数据信息，如：Segment相关信息（Msyql、PostgreSQL）；
• 分布式协调服务（Zookeeper）：帮助群集服务发现和维护当前数据的拓扑结构；
• 数据文件存储库（DeepStorage）: 存放生成的Segement文件，并供历史节点下载。

druid数据流程：

druid数据流程

druid管理流程：

druid管理流程

数据结构

DataSource

Druid的DataSource类似RDBMS中的表

• 时间列（TimeStamp）：表明每行数据的时间值，默认使用UTC时间且精确到毫秒；
• 维度列（Dimension）：用于标识数据行的各个类别信息；
• 指标列（Metric）：用于聚合和计算的列。

DataSource结构

Druid基于DataSource结构存储数据时即可选择对任意的指标进行聚合（Roll Up）操作。该操作主要基于维度列与时间范围：

• 同维度列的值做聚合
• 对指定时间粒度内的值做聚合

DataSource聚合后数据：

DataSource聚合后数据

Segment

DataSource是一个逻辑概念，Segment是数据的实际物理存储格式。
Druid正是通过 Segment实现了对数据的横纵向切割（ Slice and Dice）操作。从数据按时间分布的角度来看，通过参数 segmentGranularity的设置， Druid将不同时间范围内的数据存储在不同的 Segment数据块中，这便是所谓的数据横向切割。这种设计为 Druid带来一个显而易见的优点：按时间范围查询数据时，仅需要访问对应时间段内的这些 Segment数据块，而不需要进行全表数据范围查询，这使效率得到了极大的提高。

Segment存储

同时，在 Segment中也面向列进行数据压缩存储，这便是所谓的数据纵向切割。而且在 Segment中使用了 Bitmap等技术对数据的访问进行了优化

扩展系统

实时节点（Realtime Mode）

实时节点（Realtime Node） 负责即时摄入实时数据，以及生成Segment数据文件，并提供实时数据的查询。

• 存储：metadata(元数据)写入MySQL，在ZooKeeper中新增一条记录S。egment定期会转存到DeepStorage；
• 查询：提供实时查询索引，响应broker的查询。

master即为协调节点（coordinator）

实时节点Segment生成流程

• 实时节点缓存事件数据到内存中的索引上，然后有规律的持久化到磁盘上。在转移之前，持久化的索引会周期性地合并在一起。（查询会同时命中内存中的和已持久化的索引。）
• 实时节点周期性的启动后台的计划任务搜索本地的持久化索引，后台计划任务将这些持久化的索引合并到一起并生成一块不可变的数据，这些数据块包含了
• 一段时间内的所有已经由实时节点导入的事件数据，称这些数据块为”Segment”。
• 在传送阶段，实时节点将这些segment上传到一个永久持久化的备份存储中,即Deep Storage

历史节点（Historical Mode）

历史节点负责加载已生成好的数据文件以及提供数据查询。

历史节点加载Segment数据文件

历史节点在从下载segment前，会从本地缓存检查是否存在，如果不存在才从hdfs下载。下载完成之后，会根据zk获取到的压缩信息进行解压处理并加载到内存，提供查询服务。

数据分层

可以通过配置给历史节点划分不同的层（Tier），然后在coordinator配置规则来加载指定数据源到某个层。这样可以实现冷热数据划分处理，热数据查询多存量小，采用更好的cpu和内存机型配置，冷数据查询少存量大，采用更大的硬盘机型配置

查询节点（Broker Mode）

查询节点对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后返回调用方。

缓存使用

Druid使用Cache机制提高查询效率。

• 外部缓存，如：Memcached
• 本地缓存，如：查询节点或历史节点的内存

协调节点（Coordinator Mode）

协调节点负责 历史节点的负载均衡，并通过规则管理数据的生命周期。

• 规则（Rules）：每分钟从mysql拉取druid_rules和druid_segments，rules用来告知historical将如何load和drop索引文件，coordinator会读取这些rules，然后修改zk，通知historical加载删除指定的segment，这些都可以在coordinator的UI配置；
• 负载均衡：根据zk中每个historical node负责的segment量，做负载均衡；
• 副本（replication）：在coordinator的UI中配置rules时，可以同时配置加载segment的备份数量，这些备份数量会以load balance的形式，分配到多个historical上面。这个备份数量与hdfs的segment备份数量不一样，hdfs那个保证深度存储的数据不会丢失，historical上面备份是为了保证当某个historical挂掉的时候，其他存储了备份segment的节点能接着提供查询服务。

索引服务

索引服务包含一组组件，并以主从结构作为其架构方式。其中统治节点（Overlord Node）为主节点，中间管理者（Middle Manager）为从节点。

索引服务流程

• 统治节点：接收tranquility请求的实时索引task，选择slot空闲最多的middle-manager，通过zk将task分配给middle-manager，填满为止；
• 中间管理者：通过zk获取task，启动本地进程peon执行task；
• 苦工（peon）：执行task，完成索引建立。peon本身还负责索引查询服务。