time-series - 非时间序列数据的德鲁伊

Question

对于数据在生成时立即发送到 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.

所以......这是一个重新摄取，其含义(我猜)是一个完整的替代，对吧？

Answer 1

我们遇到了类似的问题，我们使用 lambda 架构解决了它。我们的设置中有 2 个管道:

我们的实时管道从 Kafka+Spark 获取信息并摄取到德鲁伊中。这将是实时数据。但是，比德鲁伊期望的粒度更旧的数据将被拒绝。因此，这会导致延迟数据到达的数据丢失。

我们的批处理管道每小时将数据摄取到 Hadoop 中，然后我们触发一个批处理摄取作业到 Druid。这将为键中提到的时间戳创建段，进行聚合并用相同的时间戳替换旧段。在实践中，druid 的存储原则是基于不变性、MVCC 和日志结构存储。因此，随着具有相同时间戳的新版本段出现，旧段将被垃圾收集。

有关批量摄取的更多详细信息:
我们的批处理作业操作来自 HDFS 的数据，这些数据被组织到每小时文件夹中。我们得到的任何迟到事件都被放入正确的每小时桶中。我们有 XXX 小时延迟数据的 SLA(如果您已阅读 great article，则称为水印)。因此，我们取当前小时，减去 XXX 并取相应的每小时文件夹文件，并在该特定小时内在德鲁伊上触发批处理摄取作业。请注意，如果事件在水印之前到达，这仍然​​会导致数据丢失，但我们需要做出妥协，因为德鲁伊不支持在特定小时内对段进行就地更新，而且我们也不能拥有任意长的水印，因为我们的HDFS 端的存储非常有限。