对于数据在生成时立即发送到 Druid 的情况,一切都很好(就像在 IoT 中一样)。爱它。
但现在我有不同的情况,源于迟到的数据输入。
最终用户可以离线(失去互联网连接),数据将存储在她的手机中,只有在她重新上线后才会发送给 Druid。
这意味着,当她恢复互联网时,发送给 Druid(例如通过 Tranquility 服务器)的数据将被 Druid 拒绝(因为 Druid 实时不接受过去的数据)。
当然,我可以将时间戳设置为数据发送到服务器的时间。但这会扭曲报告......,除非......,如果我添加另一个字段(假设:generated_ts),并将其声明为另一个维度。
但是我不会从你在德鲁伊 (?) 中免费获得的基于时间的自动汇总中受益。我将不得不使用 groupBy (将生成的_ts 作为维度之一),如下所示:
{
"queryType": "groupBy",
"dataSource": "my_datasource",
"granularity": "none",
"dimensions": [
"city",
{
"type" : "extraction",
"dimension" : "generated_ts",
"outputName" : "dayOfWeek",
"extractionFn" : {
"type" : "timeFormat",
"format" : "EEEE"
}
}
],
...
}
我的问题是:
谢谢,
拉卡
——
针对 Ramkumar 的以下回复,后续问题:
我还是不太明白这个批量摄取:
让我们假设事件 A。它在时间戳 3 生成,直到时间戳 15 才发送到服务器。
当它在时间戳 15 发送时,它具有以下值:{ts: 15,generated_ts:3,metric1:12,dimension1:'a'}
他们的时间戳键是“ts”。
这是不准确的,理想情况是 {ts: 3, generated_ts: 3, metric1: 12, dimension1: 'a'},但我必须将 15 指定为 insert_ts 以便 Tranquility 接受它。
现在,在批量摄取期间,我想修复它,现在它具有正确的 ts {ts: 3,generated_ts:3,metric1:12,dimension1:'a'}。
问题:那我会有重复的事件吗?
或者......(我怀疑):指定时间间隔的批量摄取基本上会替换该间隔内的所有数据? (我希望是这样,这样我就可以不用担心数据重复了)
附加说明(就在):我遇到了这个:https://github.com/druid-io/tranquility/blob/master/docs/overview.md#segment-granularity-and-window-period
说的是:
Our approach at Metamarkets is to send all of our data through Tranquility in real-time, but to also mitigate these risks by storing a copy in S3 and following up with a nightly Hadoop batch indexing job to re-ingest the data. This allow us to guarantee that in the end, every event is represented exactly once in Druid.
所以......这是一个重新摄取,其含义(我猜)是一个完整的替代,对吧?
最佳答案
我们遇到了类似的问题,我们使用 lambda 架构解决了它。我们的设置中有 2 个管道:
有关批量摄取的更多详细信息:
我们的批处理作业操作来自 HDFS 的数据,这些数据被组织到每小时文件夹中。我们得到的任何迟到事件都被放入正确的每小时桶中。我们有 XXX 小时延迟数据的 SLA(如果您已阅读 great article,则称为水印)。因此,我们取当前小时,减去 XXX 并取相应的每小时文件夹文件,并在该特定小时内在德鲁伊上触发批处理摄取作业。请注意,如果事件在水印之前到达,这仍然会导致数据丢失,但我们需要做出妥协,因为德鲁伊不支持在特定小时内对段进行就地更新,而且我们也不能拥有任意长的水印,因为我们的HDFS 端的存储非常有限。
关于time-series - 非时间序列数据的德鲁伊,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40005514/