Druid官方文档翻译-节点类型（IndexingService）

由于学习Druid的中文资料很少，所以决定翻译官方文档，希望能帮助更多的小伙伴学习Druid，自己英语水平有限，哪里有翻译错的地方请联系我，我会及时修改。谢谢。

感谢优酷土豆张海雷技术大牛的帮助

节点类型（Node Type）

IndexingService

原文链接：http://druid.io/docs/0.9.0/design/indexing-service.html

Indexing service的配置请查看链接Indexing Service Configuration.

Indexing service是一种高可用、分布式的服务，该服务将运行索引相关的任务。Indexing service的任务是创建（有时需要销毁）Druid segments。Indexing service采用主/从服务就架构。

Indexing service主要由三个组件构成，一个peon运行一个任务，一个middle manager负责管理多个peon，overlord负责接收新的任务分配给middle manager，overlord和middle manager可以运行在同一节点或跨多个节点,而middle manager和peon一般运行在同一个节点。

Indexing service架构

三个关键组件的介绍：

Overlord节点

Overlord节点负责接收任务，协调和分配任务，为任务创建锁，并返回任务状态给任务发送方，Overlord有两种运行模式：本地模式或者远程模式（默认本地模式）。在本地模式下Overlord负责创建peon用于执行任务。本地模式运行Overlord时，必须提供middle manager和peon的配置。本地模式通常用于简单的工作流程。在远程模式中，overlord和middle manager运行在单独的进程，并且可以部署在不同的服务器上单独运行。如果想使用Indexing service为druid只提供所有的索引服务，推荐使用远程模式。

提交任务和查询任务状态

任务以JSON Object的方式提交到Overlord节点，任务通过http post的方式提交：

任务提交之后会返回任务id（taskId）

可以通过http post的方式结束任务：

可以通过http get方式查看任务运行状态：

Task segments也可以通过http get的方式获得：

Overlord控制台

Overlord控制台可以查看等待的任务、运行的任务、可用的worker，最近创建和结束的worker。Overlord控制台访问方式：

自动缩放

自动缩放机制现在已经和我们的调度框架整合到了一起，但是这个框架也可以有其他的实现，我们是高度开放的，可以进行其他新的实现或者扩展现有的机制。在我们自己的部署中middle manager被部署在亚马逊AWS EC2节点，middle manager可以将自己配置成为一个galaxy环境（galaxy参考https://github.com/ning/galaxy）

如果自动缩放被启用，一个任务等待时间太长就会添加新的middle manager，如果middle manager一段时间没有运行任务，middle manager会被终止。

Middle Manager Node

原文链接http://druid.io/docs/0.9.0/design/middlemanager.html

Middle Manager的配置请查看Indexing Service

Configuration.

middle manager节点是执行提交任务的工作节点。middle manager将任务分发到peons运行，一个peon在一个单独的jvm中运行。原因是我们通过单独的jvm对任务做资源隔离和日志隔离。一个peon在一个时间只能运行一个任务，然而，一个middle manager可以管理多个peon。

运行middle manager

Peons

原文链接http://druid.io/docs/0.9.0/design/peons.html

查看peon的配置：http://druid.io/docs/0.9.0/configuration/indexing-service.html

Peon在一个单独的jvm中运行任务，MiddleManager负责创建peons用于运行任务。Peons应该很少是手动单独启动运行（除非是为了测试）。

启动方式：

task_file文件是一个包含任务信息的JSON对象，status_file文件指定任务状态输出到哪里