【Druid】Historical Node

历史节点负责加载历史segment，使segment数据能够被查询。

Running

io.druid.cli.Main server historical

Loading and Serving Segments

每一个历史节点维护着一个与ZK的长连接，监控着新segment加入的消息。历史节点彼此之间以及与协调节点（coordinator nodes）之间不会直接通信，所有的通信过程只依赖于ZK。

协调节点负责分配新的segment给历史节点，分配的过程是通过在ZK中对应某个历史节点的加载队列路径下创建临时znode完成的。

当某个历史节点在ZK中属于自身的加载队列路径下发现一个新的segment分配信息时，它首先会去本地cache中检查是否有该segment的信息。如果确认本地cache中不存在该segment的信息，即从ZK中下载该segment的元数据信息到本地。segment的元数据信息中包含该segment在底层存储的路径以及解压缩和处理该segment的方法。一旦某个历史节点完成对一个新segment的处理，历史节点会通知ZK将该segment以“已服务”的状态标记在该历史节点对应的已服务segment列表中。至此，我们就可以从这个新的segment中查询到数据了。

Loading and Serving Segments From Cache

回想一下上一节提到的当历史节点发现一个需要加载的新segment信息时，首先会去自身本地cache中检查该segment是否存在。如果该segment已在本地cache中存在时，历史节点会直接读取该segment的二进制文件并加载。

在重新启动时，历史节点会查询本地cache目录，加载它查询到的segment。这个机制能够保证历史节点上线时可以尽早地服务于查询。

历史节点能够通过配置对它服务的每个查询请求记录日志和上报metrics信息。

HTTP Endpoints

历史节点提供的接口：

GET

• /status
  返回Druid的版本信息、加载扩展、使用内存、全部内存和该节点其他有用的信息
• /druid/historical/v1/loadstatus
  返回历史节点是否已经加载本地cache中全部segment的标记。该接口可以用来确认在历史节点重启后是否能够提供查询服务。