为什么 druid roll up 没有按预期工作？答案

【问题标题】：Why is druid roll up not working as expected?为什么 druid roll up 没有按预期工作？
【发布时间】：2022-12-11 12:07:49
【问题描述】：

我有以下德鲁伊摄取规范，它从卡夫卡读取数据并生成一些聚合。现在我只对伯爵感兴趣。它有两个维度 PURCHASE_STATUS 和 STORE_ID。现在我希望数据以分钟级别的粒度汇总和分桶。

  "type": "kafka",
  "spec": {
    "dataSchema": {
      "dataSource": "purchase",
      "timestampSpec": {
        "column": "timestamp",
        "format": "millis",
        "missingValue": "1970-01-01T00:00:00.000Z"
      },
      "dimensionsSpec": {
        "dimensions": [
          {
            "type": "string",
            "name": "PURCHASE_STATUS",
            "multiValueHandling": "SORTED_ARRAY",
            "createBitmapIndex": true
          },
          {
            "type": "string",
            "name": "STORE_ID",
            "multiValueHandling": "SORTED_ARRAY",
            "createBitmapIndex": true
          }
        ],
        "dimensionExclusions": [
          "__time",
          "total_count",
          "timestamp",
        ],
        "includeAllDimensions": false
      },
      "metricsSpec": [
        {
          "type": "count",
          "name": "total_count"
        }
      ],
      "granularitySpec": {
        "type": "uniform",
        "segmentGranularity": "TEN_MINUTE",
        "queryGranularity": "MINUTE",
        "rollup": true,
        "intervals": []
      },

现在，当我使用以下查询查询德鲁伊时

SELECT
__time, STORE_ID, PURCHASE_STATUS, total_count
FROM mz_purchase
WHERE __time >= CURRENT_TIMESTAMP - INTERVAL '30' MINUTE ORDER BY __time DESC

我得到以下结果

2022-12-07T06:37:00.000Z    1   Status1 3
2022-12-07T06:37:00.000Z    1   Status2 2
2022-12-07T06:37:00.000Z    1   Status1 1
2022-12-07T06:37:00.000Z    1   Status3 23

I am confused why we are getting multiple aggregates for the same timestamp bucket and combination of dimensions.

【问题讨论】：

发现了问题。汇总不适合实时摄取rilldata.com/blog/seeking-the-perfect-apache-druid-rollup

标签： druid

【解决方案1】：

你是对的。解释是实时摄取无法提供完美的汇总。原因如下：

实时摄取是可扩展的，因为它可以端到端地进行分区
多个摄取任务可用于从使用流分区的流中消费，从而实现端到端的可扩展性
这会导致不完美的汇总，因为流分区由不同的任务处理并且每个任务独立构建聚合，
共享汇总维度值但在单独任务中处理的流消息将在不同的汇总行和单独的段文件中结束

为了查询不完美的汇总摄取数据，您需要在查询时再次聚合以最终确定汇总。使用 compaction 任务跟进实时摄取也是一种最佳做法，这些任务可以通过完成汇总并可能应用 secondary partitioning 策略来进一步优化查询段以提高历史时间范围的查询性能。

【讨论】：