Druid 的 Kafka 索引服务（Kafka indexing service）将会在 Overlord 上启动并配置 supervisors， supervisors 通过管理 Kafka 索引任务的创建和销毁的生命周期以便于从 Kafka 中载入数据。 这些索引任务使用Kafka自己的分区和偏移机制读取事件，因此能够保证只读取一次（exactly-once）。
supervisor 对索引任务的状态进行监控，以便于对任务进行扩展或切换，故障管理等操作。
这个服务是由 druid-kafka-indexing-service 这个 druid 核心扩展（详情请见 扩展列表提供的。
Kafka索引服务支持在 Kafka 0.11.x 中开始使用的事务主题。这些更改使 Druid 使用的 Kafka 消费者与旧的 Kafka brokers 不兼容。 在使用 Druid 从 Kafka中导入数据之前，请确保你的 Kafka 版本为 0.11.x 或更高版本。 如果你使用的是旧版本的 Kafka brokers，请参阅《 Kafka升级指南 》中的内容先进行升级。
教程
针对使用 Apache Kafka 数据导入中的参考文档，请访问 Loading from Apache Kafka 页面中的教程。
exactly-once 语义
从理论上来说，Exactly-once delivery是不可能的，它的代价太高无法实际应用到生产环境，包括业内的大牛Mathias Verroaes也这么认为，它是分布式系统中最难解决的唯二问题：
但现在，我并不认为引入 Exactly-once delivery 并且支持流处理是一个真正难以解决的问题。首先，让我们来概述下消息的精确提交语义。
消息语义概述
在分布式系统中，构成系统的任何节点都是被定义为可以彼此独立失败的。比如在 Kafka中，broker可能会crash，在producer推送数据至topic的过程中也可能会遇到网络问题。根据producer处理此类故障所采取的提交策略类型，我们可以获得不同的语义：
- at-least-once：如果producer收到来自Kafka broker的确认（ack）或者acks = all，则表示该消息已经写入到Kafka。但如果producer ack超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入Kafka。如果broker在发送Ack之前失败，但在消息成功写入Kafka之后，此重试将导致该消息被写入两次，因此消息会被不止一次地传递给最终consumer，这种策略可能导致重复的工作和不正确的结果。
- at-most-once：如果在ack超时或返回错误时producer不重试，则该消息可能最终不会写入Kafka，因此不会传递给consumer。在大多数情况下，这样做是为了避免重复的可能性，业务上必须接收数据传递可能的丢失。
- exactly-once：即使producer重试发送消息，消息也会保证最多一次地传递给最终consumer。该语义是最理想的，但也难以实现，这是因为它需要消息系统本身与生产和消费消息的应用程序进行协作。例如如果在消费消息成功后，将Kafka consumer的偏移量rollback，我们将会再次从该偏移量开始接收消息。这表明消息传递系统和客户端应用程序必须配合调整才能实现excactly-once。
exactly-once 语义是在 Kafka 0.11.x 中引入的，因此 Druid 要求导入的 Kafka 版本需要在 0.11.x 以上，以便于实现 exactly-once 语义。