Realtime Node
Realtime Node 可以直接配置Firehose从Kafka，RabbitMQ等消息队列中获取数据，数据一旦被摄入，很快就可以被查询到， 同时Realtime Node还会周期性的将摄入的数据合并成Segment，提交给DeepStorage并交由Historical Node加载，以达到提供实时数据的查询的功能。
缺点
Kafka 摄入缺陷
一旦Realtime Node宕机，那么该节点上未提交的数据将全部丢失。
数据丢失风险
假设你当前正在执行一个任务计算今日每个小时的数据汇总，同时你有一个批处理任务从离线集群获取数据重做Segment，并覆盖当前的Segment。
如果你在执行计算任务期间发生了Segment覆盖，那么在这个场景下很可能出现数据丢失。
Schema更新需重启节点
在Schema更新的时候，你需要重启Realtime Node以生效新的配置，这在大规模集群管理上效率非常低。
Tranquility
Tranquility 是在 Indexing Service 封装的一个类库，帮助我们从Kafka，Hadoop，HTTP，Storm，Samza，Spark Streaming或者自己的JVM程序发送数据给Indexing Service。
实现原理
Tranquility基于Indexing Service的EventReceiverFirehose来实现，该Firehose会暴露一个HTTP API供Tranquility实时Push数据给Indexing Service。
在解决分区与副本问题上，Tranquility会给每一个Segment+ partitionNum指派一个Task来进行数据摄入，在超过Window Period后，Task将会停止接收数据并合并Segment，然后提交到Deep Storage。
而副本的实现上，Tranquility将每个副本创建不同Task，相同的Segment与partitionNum，相同Segment与partitionNum的数据将会同事发给相同的副本的Task，副本的Task之间乎不通讯。
当Schema发生改变的时候，在 Indexing Service 必须重启任务才生效。 而Tranquility的做法是只会应用到新的时间段生成的Segment，旧的Segment讲保持不变。由此时间不停机修改Schema。
最后，我们通常需要启动实例进行数据处理并发送给Druid，Tranquility使用Zookeeper管理不同实例的任务协调，保证数据被正确想到相应的Task中。
缺点
- 超过Window Period的数据将会被丢弃，必须定时从离线集群中重做Segment来实现数据互补。
- Tranquility与Indexing Service的通讯异常会导致重试，无论是重试成功或失败，都可能导致数据丢失或者重复数据
Kafka Indexing Service
Kafka Indexing Service 是在Indexing Service上封装的一个扩展，使用Kafka自己的分区和偏移机制来读取数据，因此能够提供准确一次的服务保证。 解决Realtime Node摄入Kafka数据的缺陷。
与 Tranquility 对比的好处是，他能够读取来自Kafka的非近期的数据，并且不受窗口期(window period )对其他摄取机制的影响。支持管理索引任务的状态，以协调切换，管理故障，并确保维护可扩展性和复制要求。
网友评论