2-Druid 系统框架

druid (http://druid.io/)是设计用来分析时序数据，对OLAP提供支持。设计的时候就考虑到分布式的一些基本问题，比如扩展性，可靠性等问题。

druid 的设计思想是 把时序数据分析这个任务分成几个处理步骤，建立相关的组件，每个组件只集中精力处理自己的任务。 那么我们也根据一个时序数据的处理流程来了解一下druid的主要几个组件。

背景

时序数据因为从产生的那一刻起就需求被查询，所以时序数据的索引应该是数据注入到系统的同时生成，在druid里，完成这部分功能的组件叫 indexer。

用户提交一个任务（task）给indexer，告诉indexer一些基本信息，比如数据来源，数据的结构（schema），数据如何分片等信息。如果是指定数据来源于kafka 这样的消息服务， indexer 可以自己从kafka 里拉取数据到自己内存，并且在内存里建立相关索引。

数据也可以通过应用程序直接发送给 indexer，从 kafka 拉取这种方式是druid早期的方式，那个时候， indexer 这个角色是由 realtime node 来扮演，这种方式因为高可靠性的考虑（以后另写文章来解释）已经废弃不用，目前实时数据主要采用通过应用程序推的方式 push 到 indexer node。

indexer node 也可以接受批量数据注入的task，比如从hdfs里读取大量数据，并且使用Hadoop的MR来建立索引。

数据注入 indexer node（早期使用方式是realtime node）后就可以响应查询了。所以indexer node具有响应查询的能力，而且indexer node内所有数据都在内存中。

在适当时候， indexer node会把这些数据持久化到 deep storage 中。这个deep storage 一般配置成 amazone S3 或者hdfs，当然也可以配置成nas之类。indexer node把数据持久化的过程叫hand off。被持久化的数据以 segment 的形式存在，这些 segment 的元数据被发布到 metadata storage（一般是MySQL）中
Segment

segment 是个 包含数据的独立的容器，内部的数据以时间分割。 segment 为聚合的列做索引，数据依赖索引，按列方式存储。所以druid得查询就转为了如何扫描segments了。

segment 由datasource， interval, version, 和一个可选的分区号唯一的确定。
```
Segment sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0 contains
```
druid 在注入的数据的时候，就已经将索引按照指定的格式处理好，并保存在 DeepStore 中，其余的查询都转换为了对数据的扫描过程。所以druid是典型的 MOLAP.
Druid Cluster:

Druid集群包含多种节点类型，分别是 Historical Node 、Coordinator Node、Broker Node、Indexing Service Node（包括Overlord、MiddleManager和Peon）以及Realtime Node（包括Firehose和Plumber）。

Druid将整个集群切分成上述角色，有两个目的：第一，划分Historical Node和Realtime Node，是将历史数据的加载与实时流数据处理切割开来，因为二者都需要占用大量内存与CPU；第二，划分Coordinator Node和Broker Node，将查询需求与数据如何在集群内分布的需求切割开来，确保用户的查询请求不会影响数据在集群内的分布情况，从而不会造成数据“冷热不均”，局部过热，影响查询性能的问题。
1. Historical Nodes：
  
  historical nodes 可以看做是druid集群的脊椎，它将 segment 固化到本地，供集群查询时使用。 historical nodes 采用了一个无共享架构设计，它知道如何去加载segment, 删除segment以及如果基于segment查询。
  
  historical 将从 DeepStore 中下载数据，并解压文件，在查询之前，数据要首先放入内存中。
2. Broker Nodes：
  
  Broker Nodes 是客户端和相关应用从druid集群上查询数据的节点，它的职责是对客户端过来的查询做负载，聚集和合并查询结果。 broker节点知道每个segment都在哪儿
3. Coordinator Nodes：
  
  coordinator nodes 用来管理druid集群放在historical nodes上的segment。coordinatenodes 告诉historical nodes去加载新的segment，移除旧的segment，对节点上的segment做均衡.
4. Real-time Node：
  
  实时摄取数据，它们负责监听输入数据流并让其在内部的Druid系统立即获取，Realtime节点同样只响应broker节点的查询请求，返回查询结果到broker节点。旧数据会被从Realtime节点转存至Historical节点。
  
  Stream Pull
  如果Druid以Stream Pull方式自主地从外部数据源拉取数据从而生成Indexing Service Tasks，我们则需要建立Real-Time Node。Real-Time Node主要包含两大“工厂”：一个是连接流式数据源、负责数据接入的Firehose（中文翻译为水管，很形象地描述了该组件的职责）；另一个是负责Segment发布与转移的Plumber（中文翻译为搬运工，同样也十分形象地描述了该组件的职责）。在Druid源代码中，这两个组件都是抽象工厂方法，使用者可以根据自己的需求创建不同类型的Firehose或者Plumber。Firehose和Plumber给我的感觉，更类似于Kafka_0.9.0版本后发布的Kafka Connect框架，Firehose类似于Kafka Connect Source，定义了数据的入口，但并不关心接入数据源的类型；而Plumber类似于Kafka Connect Sink，定义了数据的出口，也不关心最终输出到哪里。
  
  Stream Push 如果采用Stream Push策略，我们需要建立一个“copy service”，负责从数据源中拉取数据并生成Indexing Service Tasks，从而将数据“推入”到Druid中，我们在druid_0.9.1版本之前一直使用的是这种模式，不过这种模式需要外部服务Tranquility，Tranquility组件可以连接多种流式数据源，比如Spark-Streaming、Storm以及Kafka等，所以也产生了Tranquility-Storm、Tranquility-Kafka等外部组件。Tranquility-Kafka的原理与使用将在3.4节中进行详细介绍。
5. Indexing Service:
  
  Indexing Service是负责“生产” Segment的高可用、分布式、Master/Slave架构服务 。主要由三类组件构成：==负责运行索引任务(indexing task)的Peon== ，==负责控制Peon的MiddleManager==，==负责任务分发给MiddleManager的Overlord== ；三者的关系可以解释为：Overlord是MiddleManager的Master，而MiddleManager又是Peon的Master。其中，Overlord和MiddleManager可以分布式部署，但是Peon和MiddleManager默认在同一台机器上。
  1. Overlord
    
    Overlord负责接受任务、协调任务的分配、创建任务锁以及收集、返回任务运行状态给调用者。当集群中有多个Overlord时，则通过选举算法产生Leader，其他Follower作为备份。
    
    Overlord可以运行在local（默认）和remote两种模式下，如果运行在local模式下，则Overlord也负责Peon的创建与运行工作，当运行在remote模式下时，Overlord和MiddleManager各司其职，Overlord接受实时/批量数据流产生的索引任务，将任务信息注册到Zookeeper的/task目录下所有在线的MiddleManager对应的目录中，由MiddleManager去感知产生的新任务，同时每个索引任务的状态又会由Peon定期同步到Zookeeper中/Status目录，供Overlord感知当前所有索引任务的运行状况。
    
    Overlord对外提供可视化界面，通过访问http:// : /console.html，我们可以观察到集群内目前正在运行的所有索引任务、可用的Peon以及近期Peon完成的所有成功或者失败的索引任务。
  2. MiddleManager
    
    MiddleManager负责接收Overlord分配的索引任务，同时创建新的进程用于启动Peon来执行索引任务，每一个MiddleManager可以运行多个Peon实例。
    
    在运行MiddleManager实例的机器上，我们可以在${ java.io.tmpdir}目录下观察到以XXX_index_XXX开头的目录，每一个目录都对应一个Peon实例；同时restore.json文件中保存着当前所有运行着的索引任务信息，一方面用于记录任务状态，另一方面如果MiddleManager崩溃，可以利用该文件重启索引任务。
  3. Peon
    
    Peon是Indexing Service的最小工作单元，也是索引任务的具体执行者，所有当前正在运行的Peon任务都可以通过Overlord提供的web可视化界面进行访问。
6. 外部依赖:
  1. DeepStorage:
    
    deepstorage作为segments一种持久的备份。服务创建segments后，上传到deepstore。 coordinatenode从deepstorage下载segments。查询的时候也不会用到deepstorage。常用的deepstorage有S3和hdfs。
  2. Metadata Storage
    
    用于存储segment，configuration 等的metadata信息；服务创建segments后，会向metadatastore中写一个新的标记， coordinatenode监控metadatastore来获取有哪些新的数据需要被重新load，或者有哪些旧的数据需要被去除。查询的时候并不需要metadatastor的数据。在生产集群中，mysql 和postgresql是比较常用的metadatastor， derby可以用于单机测试环境
  3. Zookeeper
    
    用于集群内部通讯
说明：

druid的设计中不同的节点类型能够在不影响其他节点类型的服务的情况下失败.。运行一个高可用集群druid，你应该每个组建至少运行个2节点的服务模型。
数据的查询过程：

上图给出了Druid集群内部的实时/批量数据流以及查询请求过程：
1. 实时数据到达Realtime Node，经过Indexing Service，在时间窗口内的数据会停留在Realtime Node内存中，而时间窗口外的数据会组织成Segment存储到Deep Storage中；
2. 批量数据经过Indexing Service也会被组织成Segment存储到Deep Storage中;
3. Segment的元信息都会被注册到元信息库中;
4. Coordinator Nodes会定期（默认为1分钟）去同步元信息库，感知新生成的Segment，并通知在线的Historical Node去加载Segment.
5. Zookeeper也会更新整个集群内部数据分布拓扑图。

2-Druid 系统框架相关推荐

Java电商秒杀系统性能优化(一)——电商秒杀系统框架回顾
电商秒杀系统框架回顾项目简介外部依赖框架回顾项目要点项目中存在的问题小结课程是免费的,课程地址如下:SpringBoot搭建电商秒杀项目,课程真的很棒,作者的思路很清晰,建议各位读者可以 ...
跨链(8)跨链双雄Cosmos“系统框架”
1. 系统框架 Cosmos是tendermint团队推出的一个支持跨链交互的异构网络, 一个分布式的独立并行区块链公链. 1.1 核心模块 tendermint core 简称tendermint, ...
跨链(6)波卡Polkadot “系统框架”
1. 系统框架 Polkadot是一种集成平行链和中继链的多层多链架构. 多层中继链多个平行链 1.1 三种链角色中继链(Relay chain) 主要通信枢纽,提供统一的共识和安全保障平行链( ...
usb 系统消息_4. Autoware 系统框架概揽
Autoware 系统架构如下图所示,非常的简洁和清晰.包括传感(sensing),计算(computering)和执行(aucuation)三个部分.在计算部分,包括感知(perception),决 ...
rola物联网框架_如何搭建一个物联网系统框架？
下面将谈到几个关键问题: 设备如何接入网络? 设备间如何通信? 物联网数据的用途? 如何搭建起一个物联网系统框架呢?它的技术架构又是怎么样呢? 物联网终端软件系统架构? 物联网云平台系统架构? 1.物 ...
android系统框架()
Android系统框架介绍: 1.大体框架: -src目录: 主要是完成java代码的编写 -assets目录: 资源目录 -res目录: 存储图片,布局文件和字符串,菜单等文件 -bin目录: ...
基于EasyDarwin流媒体云平台的智能视频监控系统框架
基于EasyDarwin流媒体云平台的智能视频监控系统框架 EasyDarwin云平台作为国内较有影响力的开源流媒体平台,集流媒体分发,录像,信令交互为一体,目前已经被广泛应用到监控互联网各个领域:从 ...
IOT(5)---物联网系统框架介绍
转载: https://blog.csdn.net/robert_tin 物联网系统框架介绍下面将谈到几个关键问题: 设备如何接入网络? 设备间如何通信? 物联网数据的用途? 如何搭建起一个物联网系 ...
基于 SIP 的会议系统框架(草稿)
基于 SIP 的会议系统框架第一章前言众所周知, SIP 作为一个会议初始协议, 提供了对多媒体会话的建立,修改和终止等控制能力, 因此完全能胜任建立双方对话, 但是对于有多方参 ...

2-Druid 系统框架

背景

Segment

Druid Cluster:

Historical Nodes：

Broker Nodes：

Coordinator Nodes：

Real-time Node：

Indexing Service:

Overlord

MiddleManager

Peon

外部依赖:

DeepStorage:

Metadata Storage

Zookeeper

说明：

数据的查询过程：

2-Druid 系统框架相关推荐

最新文章

热门文章