› › ›

理解分组

8.11.0 版本中已弃用。

卷起功能将在未来版本中移除。请迁移到降采样。

为了保持灵活性，卷起作业的定义基于未来查询可能需要如何使用数据。传统上，系统强制管理员决定要卷起哪些指标以及以什么间隔进行卷起。例如，每小时计算一次cpu_time的平均值。这是有限制的；如果将来管理员希望查看每小时cpu_time的平均值 *以及* 按host_name进行分区，那么他们就无法做到。

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

与其强迫管理员提前决定哪些单个元组应该被卷起，Elasticsearch 的卷起作业是基于哪些组对未来的查询可能有用而进行配置的。例如，此配置

"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聚合的位置，这说明聚合的顺序对卷起并不重要。同样，虽然date_histogram对于卷起数据是必需的，但在查询时并不需要（尽管经常使用）。例如，这是卷起搜索可以执行的有效聚合

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

最终，在为作业配置groups时，请考虑您将来可能希望如何在查询中划分数据……然后将这些包含在配置中。因为卷起搜索允许任何顺序或组合的分组字段，您只需要决定一个字段是否对以后的聚合有用，以及您可能希望如何使用它（terms、histogram 等）。

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

编辑

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

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

我们建议坚持使用固定时间间隔，因为它们更容易理解，并且在查询时更灵活。这会在闰事件期间引入一些数据漂移，您必须考虑固定数量的月份（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。这是因为单个数量包含日历时间，并限制您将来按日历时间进行查询。

异构索引的分组限制

编辑

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

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

此限制现已得到缓解。从 6.4.0 开始，现在建议将所有卷起配置组合到一个作业中。

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

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

和

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

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

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" ]
    }
  ]
}

文档计数和重叠作业

编辑

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

此问题在 6.4.0 中也已消除。

« 卷起数据的入门指南卷起聚合的限制 »