作者：Syn良子 出处：https://www.cnblogs.com/cssdongl/p/9608812.html 转载请注明出处

Druid架构

Druid原本就设计为一个容易操作的面向云的多进程分布式的架构.druid的每个不同的进程类型都能够独立的扩展和配置,这会给你的集群带来最大化的自由度.这种设计也会提供加强版的容错机制:一个组件的挂掉不会立即影响其他组件的运行.

Druid的节点进程类型包含以下这些:

• Historical 节点作为主力来负责处理历史数据的存储和查询(包含那些已经在系统中存活了很久的实时数据需要提交到历史节点),历史节点从Deep Storage下载Segment，然后响应Broker对于Segment的查询将查询结果返回给Broker节点.历史节点不接受直接的写入
• MiddleManager 节点负责摄取新的数据到集群里面.这些节点负责从外部数据源读取数据然后发布到本地segments中去.
• Broker节点接收外部客户端的查询，并且将查询路由到historical节点和middle manger节点。当Broker收到返回的结果的时候，它将结果merge起来然后返回给调用者.终端用户通过Broker来查询而不是直接通过查询historical和middle manager节点.
• Coordinator节点一般用来检测一组historical节点进程.这些节点负责分配和加载segments到一些servers上，它们能够保证这些segments在historicals节点上是分布均匀的.
• Overlord节点用来监控middle manager进程，控制数据的摄取到druid集群.他们负责分配摄取任务给相应的middle manager以及协调segment的发布.
• Router节点是可选的进程，它能够给broker,overlord,coordinator提供一个统一的网关api来进行访问.这个节点是可选的，因为你可以直接访问broker,overlord以及coordinator.

Druid这些进程都能够单独的部署(可以部署在物理机,虚拟机,或者其他容器上),也可以托管在共享服务器上.一个常见的托管计划包含以下3种类型:

1. 数据节点负责运行historical以及middle manager这些进程
2. 查询节点负责运行broker和router进程(可选)
3. master节点负责运行coordinator和overlord进程.当然他们上面还可以跑zookeeper.

在这些进程之外,druid还提供另外3个外部依赖.这些依赖会影响现有集群的基础建设.

• Deep storage对druid服务器之间提供文件共享的访问功能.当然这些都是分布式的文件存储系统比如像S3,HDFS以及一些网络文件系统.Druid利用这种文件系统来存储那些已经被摄取到系统的数据.
• Metadata store负责元数据的存储.一般用传统的RDBMS比如postgreSQL或者MySql来存储.
• Zookeeper用来协调druid不同组件的内部的服务发现以及leader选举.

这种架构的本意是为了在生产坏境中大规模使用Druid集群更加简单化.比如,deep storage和metadata store存储分离意味着druid集群有极强的容错能力:即使单个druid服务节点跪了,仍然能够通过deep storage和metadata store来快速启动和恢复.

下面这个图展示了查询和数据流如何通过这个架构来实现的

参考文档:http://druid.io/docs/latest/design/index.html#architecture