对于daya在生成时立即被送到德鲁伊的情况，一切都很好并且花花公子（如在物联网中） . 爱它 .
但现在我有不同的情况，源于迟到的数据录入 .
最终用户可以离线（失去互联网连接），数据存储在她的手机中，只有在她重新上线后才会被发送给德鲁伊 .
这意味着，当她恢复她的互联网时，发送给德鲁伊的数据（例如通过Tranquility服务器）将被德鲁伊拒绝（因为德鲁伊实时不接受过去的数据） .
当然，我可以将时间戳设置为数据发送到服务器的时间 . 但这会扭曲报告......，除非......，如果我添加另一个字段（比方说：generated_ts），并将其声明为另一个维度 .
但是，我不会受益于您在德鲁伊（？）中免费获得的基于时间的自动汇总 . 我必须使用groupBy（将generated_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作为inserted_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
说的是：
我们在Metamarkets的方法是通过Tranquility实时发送我们的所有数据，但也可以通过在S3中存储副本并跟进每晚Hadoop批量索引作业来重新获取数据来缓解这些风险 . 这使我们能够保证最终每个事件在德鲁伊都只有一次 .
所以...这是一次重新摄入，其意义（我猜）是完全替代的，对吗？
1 回答
我们遇到了类似的问题，我们使用lambda架构解决了这个问题 . 我们的设置中有2个管道：
我们的实时管道来自Kafka Spark并摄入德鲁伊 . 这将是实时数据 . 早于德鲁伊所期望的粒度的数据将被拒绝 . 因此，对于迟到的数据到达，这会导致数据丢失 .
我们的批处理管道每小时都会将数据提取到Hadoop中，然后我们会在Druid中触发批量提取工作 . 这将为密钥中提到的时间戳创建段，执行聚合并使用相同的时间戳替换旧段 . 在实践中，德鲁伊的存储原理基于不变性，MVCC和日志结构存储 . 因此，当新版本的段出现在相同的时间戳中时，较旧的段会被垃圾收集 .
有关批量提取的更多详细信息：我们的批处理作业操作来自HDFS的数据，这些数据被组织成每小时文件夹 . 我们得到的任何迟到的事件都被放入正确的每小时桶中 . 我们将晚期数据的SLA设置为XXX小时（如果您已阅读great article，则称为水印） . 因此，我们取当前小时，减去XXX并获取相应的每小时文件夹文件，并在德鲁伊上针对该特定小时触发批量摄取作业 . 请注意，如果事件在水印之前到达，这仍然可能导致数据丢失，但我们需要做出妥协，因为德鲁伊不支持特定时段的段的就地更新，我们也不能有任意长的水印，因为我们的HDFS方面的存储空间非常有限 .