天天看点

Druid的服务和进程进程类型:服务类型:托管的利弊

进程类型:

Druid有以下几种进程类型:

  • Coordinator
  • Overlord
  • Broker
  • Historical
  • MiddleManager 和 Peons
  • Indexer (可选的)
  • Router (可选的)

服务类型:

Druid进程可以根据我们的喜好进行部署,但是为了部署更简单,我们建议把它们分为三种服务类型:

  • Master
  • Query
  • Data
Druid的服务和进程进程类型:服务类型:托管的利弊

本节我们根据上面的架构图来介绍Druid的进程和Master/Query/Data服务 

Master服务

Master服务管理数据的摄入和可用性:它负责开启一个新的摄入JOB和协调即将讲到的 Data服务的数据可用性

在master服务里面,按功能划分为两个进程:Coordinator 和 Overlord.

Coordinator 进程

coordinator 进程监视 data 服务的historical进程。它们负责分配segment到特定的服务,并确保historical上面的segment的负载均衡。

Overlord 进程

overlord 进程监视 data服务的middlemanager进程,并控制druid的数据摄入。它们负责分配摄入任务给middlemanager并协调segment的发布

Query server

query服务提供用户和客户端的交互,路由查询请求到data服务或者其他的查询服务(可选的代理master服务的请求)

在query服务里面,按功能划分为两个进程:Broker 和 Router

Broker 进程

broker进程接收外部客户端的查询并把这些查询转发到data服务,当broker收到data服务查询的结果以后,它们合并这些结果并将结果返回给调用者。终端用户都是通过连接到broker而不是直接查询data服务的historical或者middlemanager进程。

Router 进程(可选的)

router进程是可选的进程,它在druid broker、overlord和coordinator前面提供统一的api网关,它们是可选的原因是我们可以简单的直接连接到druid broker、overlord和coordinator。

router也运行Druid控制台,一个管理界面用来操作 DataSource,segment,任务,data进程(historical和middlemanager),coordinator的动态配置。用户也可以在控制台上面运行SQL或者原生的druid查询。

Data服务

data服务执行摄入JOB和存储可查询的数据

在Data服务里面,按功能划分为两个进程:Historical 和 MiddleManager

historical进程

historical进程是用来处理存储和查询历史数据(已经提交到系统一定时间的流数据)。historical进程从底层存储加载segment并根据segment的数据相应查询,它们不支持写。

middle manager 进程

middlemanger进程用来处理新数据摄入到集群。它们负责从外部读取数据源并发布新的druid segment。

Peon 进程

peon是一个由middlemanager拉起的任务执行引擎。每一个peon运行一个独立的JVM并负责执行单一的任务。peon是和由拉起它的middlemanager运行在同一个机器上面。

Indexer process (可选)

indexer进程是middlemanager和peon进程的替代品。indexer是在单个JVM进程中使用单个线程运行任务,而不是为每个任务拉起单独的JVM进程。

indexer被设计比middlemanager+peon更容易配置和部署,并且在任务之间能更好的分享资源。indexer是一个新特性,由于其内存管理系统仍在开发中,所以目前被指定为实验性的。在将来将会成为druid的成熟特性。

同样的,你只需要部署middlemanager或者indexer,而不是两个都部署。

托管的利弊

Druid进程可以像上面描述的基于master/data/query服务机制托管。这种机制通常会使大多数集群更好地利用硬件资源。

但是,对于非常大规模的集群,可以把Druid进程分开,使它们在单独的服务器上运行,以避免资源争用。

本节介绍与进程托管相关的指南和配置参数。

Coordinators 和 Overlords

coordinator进程的工作负载随着集群中segment的数量增加而增加,overlord的工作负载也是基于集群中segment的数量,只是程度比coordinator少。

当集群中segment数量非常多的时候,将coordinator进程和overlord进行分开以便为coordinator提供更多的资源来进行segment的负载均衡。

统一进程

coordinator和overlord进程可以以单个联合进程进行运行,通过druid.coordinator.asOverlord.enabled配置项进行设置。详情参考: Coordinator Configuration: Operation

historical和middlemanager

当摄入和查询负载比较高的时候,把historical和middlemanager进行分开部署在不同的主机上,以避免CPU和内存的争用。

historical也需要空闲的内存来进行segment的内存映射,这也是另一一个把historical和middlemanager进行分开部署的理由。

继续阅读