› › ›

理解分组

理解分组编辑

在 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 作业必须有一个具有定义时间间隔的 date histogram 组。Elasticsearch 同时理解日历时间间隔和固定时间间隔。固定时间间隔很容易理解；60s 表示六十秒。但是1M 表示什么？一个月的时间取决于我们谈论的是哪个月，有些月份比其他月份长或短。这是一个日历时间的例子，该单位的持续时间取决于上下文。日历单位也会受到闰秒、闰年等的影响。

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

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

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

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

对于某些既有固定时间间隔又有日历时间间隔的单位，您可能需要用下一个较小的单位来表示数量。例如，如果您想要一个固定的天（而不是日历天），您应该指定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 聚合限制 »