pecifically) must be able to
>>>>>discover and issue *RPC queries* against the Sink on the partial
>>>>>data it has accumulated. This puts an extra dynamic load on the Sink
>>>>> jvm,
>>>>>but in my own experience that extra load
ra load is small compared to the load
>>>> of
>>>>indexing the incoming data.
>>>>
>>>> The key desire to use a stream-native framework is that the Druid
>>>> MiddleManager/Peon setup (the streaming task infrastructure for Druid) has
&g
fense.proofpoint.com/v2/url?u=http-3A__druid.io_docs_latest_development_extensions-2Dcore_kafka-2Dingestion.html&d=DwMFaQ&c=ncDTmphkJTvjIDPh0hpF_w&r=HrLGT1qWNhseJBMYABL0GFSZESht5gBoLejor3SqMSo&m=RfzQSR6AU_Kv9ZMfTOpxwcU8ZmBmA0C2qLVOf8mjBFo&s=AlpnfkhLS3u0I-XIe6pzvtds6_n1MkIMfV
AU_Kv9ZMfTOpxwcU8ZmBmA0C2qLVOf8mjBFo&s=AlpnfkhLS3u0I-XIe6pzvtds6_n1MkIMfVl0WrI8v6M&e=>
>> handles some of these things, but still doesn't quite operate like a
>> stream-native solution, and is only available for Kafka.
>>
>> What is not clear to me is if such
quite operate like a
> stream-native solution, and is only available for Kafka.
>
> What is not clear to me is if such a feature set would be in the intended
> scope of Beam as opposed to having some other streaming data catcher
> service that Beam simply feeds into (aka, a Tran
d be in the intended
scope of Beam as opposed to having some other streaming data catcher
service that Beam simply feeds into (aka, a Tranquility
<https://github.com/druid-io/tranquility> sink). Having a customizable,
accessible and stateful sink with good commit semantics seems like it
should
