大规模使用数据转换

数据转换将现有的 Elasticsearch 索引转换为汇总索引，从而为新的洞察和分析提供了机会。数据转换执行的搜索和索引操作使用标准的 Elasticsearch 功能，因此在 Elasticsearch 中大规模工作的类似考虑因素通常也适用于数据转换。如果您遇到性能问题，请首先识别瓶颈区域（搜索、索引、处理或存储），然后查看本指南中的相关注意事项以提高性能。了解数据转换的工作原理也有助于改进性能，因为根据您的数据转换是运行在连续模式还是批处理模式，适用的考虑因素会有所不同。

在本指南中，您将学习如何

先决条件

这些指南假设您有一个要调整的数据转换，并且您已经熟悉

以下注意事项不是按顺序排列的——数字有助于在列表项之间导航；您可以按任何顺序对其中一个或多个采取行动。大多数建议都适用于连续和批处理数据转换。如果某个列表项仅适用于一种数据转换类型，则会在描述中突出显示此例外情况。

每个建议标题末尾括号中的关键词表示可以通过遵循给定建议改进的瓶颈区域。

为了优化数据转换性能，请首先确定工作量最大的区域。Kibana 中“数据转换”页面上的统计信息界面包含涵盖三个主要区域的信息：索引、搜索和处理时间（或者，您可以使用数据转换统计信息 API）。例如，如果结果显示大部分时间都花在了搜索上，那么应优先考虑优化数据转换的搜索查询。数据转换还支持Rally，如果需要，可以使用它对数据转换配置进行性能检查。如果您优化了关键因素，但仍然遇到性能问题，您可能还需要考虑改进您的硬件。

在连续数据转换中，frequency 配置选项设置源索引更改之间检查的间隔。如果检测到更改，则搜索源数据并将更改应用于目标索引。根据您的用例，您可能希望减少应用更改的频率。通过将 frequency 设置为更高的值（最大为一小时），可以将工作负载分散到一段时间内，但代价是数据不太及时。

根据目标索引的大小，您可以考虑增加其分片数量。数据转换在创建目标索引时默认使用一个分片。要覆盖索引设置，请在启动数据转换之前创建目标索引。有关分片数量如何影响可扩展性和弹性的更多信息，请参阅准备投入生产

如果您已定义数据转换源索引query，请确保它尽可能高效。使用 Kibana 中开发工具下的搜索分析器获取有关搜索请求中各个组件执行的详细计时信息。或者，您可以使用分析。结果使您能够深入了解搜索请求在底层是如何执行的，以便您了解某些请求缓慢的原因，并采取措施对其进行改进。

数据转换执行标准的 Elasticsearch 搜索请求。编写 Elasticsearch 查询的方法有很多种，其中一些比其他方法更有效。请参阅调整搜索速度，以了解有关 Elasticsearch 性能调整的更多信息。

假设您的连续数据转换配置为按 IP 分组并计算 bytes_sent 的总和。对于每个检查点，连续数据转换都会检测自上一个检查点以来源数据中的更改，识别已摄取新数据的 IP。然后，它执行第二次搜索，过滤这些 IP 组，以便计算 bytes_sent 的总和。如果第二次搜索匹配许多分片，则这可能会占用大量资源。考虑限制源索引模式和查询将匹配的范围。

要限制访问哪些历史索引，请排除某些层（例如 "must_not": { "terms": { "_tier": [ "data_frozen", "data_cold" ] } }）和/或在源查询中使用绝对时间值作为日期范围过滤器（例如，大于 2024-01-01T00:00:00）。如果您使用相对时间值（例如，gte now-30d/d），则确保应用日期舍入以利用查询缓存并确保相对时间远大于 frequency 或 time.sync.delay 或日期直方图桶中的最大值，否则可能会丢失数据。请勿使用小于日期值的日期过滤器（例如，lt：小于或 lte：小于或等于），因为这与每个检查点执行时应用的逻辑冲突，并且可能会丢失数据。

考虑在索引名称中使用日期数学以减少查询中要解析的索引数量。在索引名称中添加日期模式 - 例如，yyyy-MM-dd - 并使用它将查询限制到特定日期。以下示例仅查询昨天和今天的索引

  "source": {
    "index": [
        "<mydata-{now/d-1d{yyyy-MM-dd}}*>",
        "<mydata-{now/d{yyyy-MM-dd}}*>"
    ]
  },

没有一种放之四海而皆准的分片策略。在一种环境中有效的策略在另一种环境中可能无法扩展。良好的分片策略必须考虑您的基础设施、用例和性能预期。

分片太少可能意味着无法实现分配工作负载的好处；但是分片太多可能会影响集群健康状况。要了解有关调整分片大小的更多信息，请阅读本指南。

max_page_search_size 数据转换配置选项定义每个搜索请求返回的桶数。默认值为 500。如果增加此值，则可以提高吞吐量，但代价是更高的延迟和内存使用量。

此参数的理想值高度依赖于您的用例。如果您的数据转换执行内存密集型聚合——例如，基数或百分位数——则增加 max_page_search_size 需要更多可用内存。如果超过内存限制，则会发生断路器异常。

运行时字段和脚本字段不是已索引字段；它们的值仅在搜索时提取或计算。虽然这些字段为访问数据提供了灵活性，但它们会增加搜索时的性能成本。如果使用运行时字段或脚本字段的数据转换性能令人担忧，您可能希望考虑改用已索引字段。出于性能原因，我们不建议使用运行时字段作为同步连续数据转换的时间字段。

索引排序使您能够以特定顺序将文档存储在磁盘上，这可以提高查询效率。理想的排序逻辑取决于您的用例，但经验法则是按降序（高到低基数）排序字段，从基于时间的字段开始。索引排序只能在索引创建时定义一次。如果您尚未在要用作源的索引上进行索引排序，请考虑将其重新索引到新的排序索引中。

_source 字段包含在索引时传递的原始 JSON 文档主体。_source 字段本身未被索引（因此不可搜索），但它仍存储在索引中并产生存储开销。如果您有大型目标索引，请考虑禁用 _source 以节省存储空间。禁用 _source 只能在索引创建期间进行。