› › ›

了解分组

在 8.11.0 中已弃用。

Rollup 将在未来的版本中移除。请迁移到降采样。

为了保持灵活性，Rollup 作业是根据未来查询可能需要如何使用数据来定义的。传统上，系统会强制管理员决定要汇总哪些指标以及以什么时间间隔进行汇总。例如，每小时的 cpu_time 的平均值。这是有限制的；如果未来管理员希望查看每小时的 cpu_time 的平均值，并且按 host_name 分区，他们就没办法了。

当然，管理员可以决定按每小时汇总 [hour, host] 元组，但随着分组键数量的增加，管理员需要配置的元组数量也会增加。此外，这些 [hours, host] 元组仅对每小时汇总有用…每日、每周或每月的汇总都需要新的配置。

Elasticsearch 的 Rollup 作业不是强制管理员提前决定应该汇总哪些单独的元组，而是根据哪些组对未来查询可能有用来进行配置。例如，此配置

"groups" : {
  "date_histogram": {
    "field": "timestamp",
    "fixed_interval": "1h",
    "delay": "7d"
  },
  "terms": {
    "fields": ["hostname", "datacenter"]
  },
  "histogram": {
    "fields": ["load", "net_in", "net_out"],
    "interval": 5
  }
}

允许在 "timestamp" 字段上使用 date_histogram，在 "hostname" 和 "datacenter" 字段上使用 terms 聚合，以及在 "load"、"net_in"、"net_out" 字段中的任何一个上使用 histograms。

重要的是，这些聚合/字段可以以任何组合使用。这个聚合

"aggs" : {
  "hourly": {
    "date_histogram": {
      "field": "timestamp",
      "fixed_interval": "1h"
    },
    "aggs": {
      "host_names": {
        "terms": {
          "field": "hostname"
        }
      }
    }
  }
}

与这个聚合同样有效

"aggs" : {
  "hourly": {
    "date_histogram": {
      "field": "timestamp",
      "fixed_interval": "1h"
    },
    "aggs": {
      "data_center": {
        "terms": {
          "field": "datacenter"
        }
      },
      "aggs": {
        "host_names": {
          "terms": {
            "field": "hostname"
          }
        },
        "aggs": {
          "load_values": {
            "histogram": {
              "field": "load",
              "interval": 5
            }
          }
        }
      }
    }
  }
}

你会注意到，第二个聚合不仅大得多，而且还交换了 "hostname" 上 terms 聚合的位置，这说明聚合的顺序对 Rollup 并不重要。同样，虽然 date_histogram 是滚动数据的必要条件，但在查询时不是必需的（尽管经常使用）。例如，这是 Rollup 搜索执行的有效聚合

"aggs" : {
  "host_names": {
    "terms": {
      "field": "hostname"
    }
  }
}

最终，在为作业配置 groups 时，请考虑一下您可能希望在未来某个日期在查询中如何对数据进行分区…然后将其包含在配置中。由于 Rollup 搜索允许分组字段的任何顺序或组合，因此您只需决定一个字段对于稍后聚合是否有用，以及您可能希望如何使用它（terms、histogram 等）。

日历时间间隔与固定时间间隔

编辑

每个 rollup 作业必须有一个具有定义的时间间隔的日期直方图组。Elasticsearch 理解日历和固定时间间隔。固定时间间隔很容易理解；60s 表示 60 秒。但是 1M 是什么意思呢？一个月的时间取决于我们所说的月份，有些月份比其他月份长或短。这是一个日历时间的示例，该单位的持续时间取决于上下文。日历单位还会受到闰秒、闰年等的影响。

这很重要，因为 rollup 生成的存储桶采用日历或固定时间间隔，这限制了您稍后如何查询它们。请参阅请求必须是配置的倍数。

我们建议坚持使用固定时间间隔，因为它们更容易理解，并且在查询时更灵活。它会在闰秒事件期间在您的数据中引入一些漂移，并且您必须以固定的数量（30 天）而不是实际的日历长度来考虑月份。但是，这通常比在查询时处理日历单位更容易。

单位的倍数始终是“固定的”。例如，2h 始终是固定的数量 7200 秒。单个单位可以是固定的或日历的，具体取决于单位

单位	日历	固定
毫秒	不适用	`1ms`、`10ms` 等
秒	不适用	`1s`、`10s` 等
分钟	`1m`	`2m`、`10m` 等
小时	`1h`	`2h`、`10h` 等
天	`1d`	`2d`、`10d` 等
周	`1w`	不适用
月	`1M`	不适用
季度	`1q`	不适用
年	`1y`	不适用

对于某些既有固定又有日历的单位，您可能需要用下一个较小的单位来表示数量。例如，如果您想要固定的一天（而不是日历天），您应该指定 24h 而不是 1d。同样，如果您想要固定的小时数，请指定 60m 而不是 1h。这是因为单个数量表示日历时间，并且限制您将来只能按日历时间进行查询。

异构索引的分组限制

编辑

以前，Rollup 如何处理具有异构映射（多个、不相关/不重叠的映射）的索引存在限制。当时的建议是为每个数据“类型”配置单独的作业。例如，您可能会为启用的每个 Beats 模块配置一个单独的作业（一个用于 process，另一个用于 filesystem 等）。

此建议是由内部实现细节驱动的，如果使用单个“合并”作业，则可能会导致文档计数不正确。

此限制现已缓解。从 6.4.0 开始，现在最佳实践是将所有 rollup 配置组合到一个作业中。

例如，如果您的索引有两种类型的文档

{
  "timestamp": 1516729294000,
  "temperature": 200,
  "voltage": 5.2,
  "node": "a"
}

和

{
  "timestamp": 1516729294000,
  "price": 123,
  "title": "Foo"
}

最佳实践是将它们组合到一个涵盖这两种文档类型的单一 rollup 作业中，如下所示

PUT _rollup/job/combined
{
  "index_pattern": "data-*",
  "rollup_index": "data_rollup",
  "cron": "*/30 * * * * ?",
  "page_size": 1000,
  "groups": {
    "date_histogram": {
      "field": "timestamp",
      "fixed_interval": "1h",
      "delay": "7d"
    },
    "terms": {
      "fields": [ "node", "title" ]
    }
  },
  "metrics": [
    {
      "field": "temperature",
      "metrics": [ "min", "max", "sum" ]
    },
    {
      "field": "price",
      "metrics": [ "avg" ]
    }
  ]
}

文档计数和重叠作业

编辑

以前，由于相同的内部实现细节，在“重叠”作业配置上，文档计数存在问题。如果存在两个保存到同一索引的 Rollup 作业，其中一个作业是另一个作业的“子集”，则在某些聚合安排中，文档计数可能不正确。

此问题也已在 6.4.0 中消除。

« Rollup 入门 Rollup 聚合限制 »