> 7.x 到 8.x 迁移时，`.data-frame-notifications-1` 这个 Transform 通知索引被 `.transform-notifications-000002` 取代。为了兼容，会在旧索引上建别名让读操作还能读到历史数据。9.0 起这个别名**不再自动创建**——已有集群保留，新建集群没有。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845)。

来源和边界先交代：本文的依据出自 v9.4.2 标签下的官方文件（`9.0.0.yml`、`Transform.java`），文中引用的原文均来自这些文件。我没有启动集群、也没有跑测试，示例取自官方示例；哪些是文档写明、哪些是我的推断，正文里逐处标注。

![01-9.0.0](https://developer.qcloudimg.com/http-save/yehe-7348459/407ff466a90ba08dd75a626be2a45443.png)

*图 1：官方文件 9.0.0.yml（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 9.0.0.yml*


## 官方条目

9.0 的 changelog 标为 deprecation（[9.0.0.yml 第 670–680 行 @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.0.0.yml#L670-L680)），PR 117583，`area: Machine Learning`。

details 讲了一段完整的迁移史：

> As part of the migration from 7.x to 8.x, the `.data-frame-notifications-1` index was deprecated and replaced with the `.transform-notifications-000002` index. The index is no longer created by default, all writes are directed to the new index, and any clusters with the deprecated index will have an alias created to ensure that reads are still retrieving data that was written to the index before the migration to 8.x. **This change removes the alias from the deprecated index in 9.x. Any clusters with the alias present will retain it, but it will not be created on new clusters.**

impact 一句：

> No known end user impact.

![02-Transform](https://developer.qcloudimg.com/http-save/yehe-7348459/95816b8371c4966ee133a5ef3a7de6a0.png)

*图 2：官方文件 Transform.java（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 Transform.java*


## 把这段历史拆开

官方 details 信息量不小，按时间线重排一下：

第一步（7.x → 8.x 迁移时）：

* 旧索引 `.data-frame-notifications-1` 被弃用；
* 新索引 `.transform-notifications-000002` 取代它；
* 写入全部指向新索引；
* 但旧索引里还有迁移前写的数据——为了能读到，在旧索引上建一个别名。

第二步（9.0 本次改动）：

* 别名不再自动创建；
* 已有别名的集群保留（不会被删）；
* 新建的集群不再有这个别名。


## 这个别名解决什么问题

值得说清楚，因为它是理解"为什么现在能删"的关键。

迁移过程中有个典型难题：数据在两个地方。

* 迁移**前**写的数据 → 在旧索引里；
* 迁移**后**写的数据 → 在新索引里。

读的时候要**两边都读**才能拿到完整历史。别名的做法就是：让一个名字同时指向两个索引，读操作用这个名字就自动覆盖了两边。

**代价是**：这个兼容状态要一直维护——每次读都要查两个索引，而且新集群也得保留这套逻辑（哪怕它们根本没有旧索引）。

什么时候可以去掉：当旧数据不再需要、或者已经被合并到新索引时。到 9.0，距离 8.x 已经隔了一个大版本——官方判断这个兼容层可以收掉了。

从维护者的角度看这个决定很合理：一个为了兼容 7.x 而存在的逻辑，在 9.x 里还要为所有新集群保留，成本是持续的。而收益只对极少数还有旧索引的集群存在。收掉它是把成本从"所有人的常态开销"变回"极少数人的特殊情况"。

![03-PR--117583](https://developer.qcloudimg.com/http-save/yehe-7348459/d131b0b35471f70342c4a69b7fa78700.png)

*图 3：官方页面 PR #117583。来源：GitHub elastic/elasticsearch pull/117583*


## 为什么"没有已知影响"

官方说没有已知影响，逻辑和 单数据节点水位线开关移除 里分析过的那条一样：

* 别名只在旧索引存在时才需要；
* 而旧索引是 7.x 时代的产物——能升到 9.0 的集群，要么早就没有这个索引了，要么已经处理过；
* 已经存在的别名不会被删除，所以存量集群的读取行为不变。

三条合起来：没有集群会因为这次改动而读不到东西。

这个推理是完整的。不过和上次一样，把推理过程写出来——impact 说"没影响"时自己确认一遍前提，是读 breaking/deprecation 时的好习惯。


## 源码里能看到什么

Transform 模块的代码里保留着这几个索引模板名的处理（`Transform.java` @ v9.4.2，[第 436–438 行](https://github.com/elastic/elasticsearch/blob/v9.4.2/x-pack/plugin/transform/src/main/java/org/elasticsearch/xpack/transform/Transform.java#L436-L438)）：

```java
templates.remove(".data-frame-notifications-1");
templates.remove(".transform-notifications-000001");
templates.remove(".transform-notifications-000002");
```

三个索引名都在：

* `.data-frame-notifications-1`——7.x 的；
* `.transform-notifications-000001`——8.x 早期的一版；
* `.transform-notifications-000002`——8.x 之后的。

能看到这个通知索引换了三代名字：7.x 的 `.data-frame-notifications-1`、8.x 早期的 `.transform-notifications-000001`、之后的 `.transform-notifications-000002`。这也解释了为什么需要兼容层——改名改了不止一次，每次都要照顾上一代的数据。

三代名字还说明一件事：以 `.` 开头的内部索引，其命名和结构都不保证稳定。这对使用者是个提醒，正文后面会再提。

（说明：这段代码上下文未完整看，不清楚 `templates.remove(...)` 是在做什么具体操作——是清理旧模板、还是排除它们。**不确定**，所以不做进一步推断。）


## 谁需要关心

按判断，绝大多数人不用管。理由是：

* 不用 Transform → 完全无关；
* 用 Transform 但集群是 8.x 之后建的 → 根本没用过旧索引，无关；
* 8.x 之前建的集群 → 别名已经存在且会保留，读取行为不变。

唯一需要处理的情况：你自己写了代码直接读那个旧索引名（`.data-frame-notifications-1`），而不是通过别名或新索引名。这种情况下——

* 存量集群：别名还在，能读；
* 新建集群：没有别名，读不到。

不过这种写法本来就少见（谁会直接读一个内部索引的旧名字呢）。真正可能受影响的是自己开发了 Transform 监控面板、且硬编码了索引名的团队——但这属于极少数。

这里说一条通用的做法：我的建议是不要直接读 ES 的内部索引。它们的前缀（`.`）就表示内部用途，名字和结构都可能随版本变化。要拿数据就走官方 API 或者 Kibana。这条建议不限于本例。


## 通知索引是干什么的

既然说到 Transform 的通知索引，把它是什么讲清楚——不然"读不到通知数据"这句话没有分量。

Transform 是 ES 的**数据转换**功能：把源索引的数据按配置做聚合（pivot）或者最新值（latest）处理，写到目标索引。常用于把原始明细预聚合成分析用的宽表。

**通知索引**（notifications index）记录的则是 Transform 任务运行过程中的异常信息——比如某次运行失败了、某个文档处理出错了。它相当于 Transform 的运行日志/错误记录。

所以它的实际用途是：

* 排查"为什么这个 transform 没跑出预期结果"；
* 查看历史上有哪些处理失败的文档。

这是运维排查用的数据，不是业务数据。这也解释了为什么官方判断"没有已知影响"——很少有人直接读它，多数情况是通过 Kibana 的 Transform 界面查看（那个界面会读新索引）。


## 旧索引还有数据时还能不能读到

想确认"旧索引还有数据时，9.0 之后读操作还能不能读到"。

按 details 的说法：别名的目的是"确保读操作仍能取到迁移前写的数据"。9.0 起不自动创建别名，那么——

* 如果集群里既有旧索引又有别名（存量情况）→ 能读到；
* 如果集群里有旧索引但没别名（理论上可能吗？）→ 读不到。

第二种情况是否存在，不确定。按官方说法，只要有旧索引就会建别名，所以理论上不该出现"有索引没别名"的状态。但如果有集群因为某些原因没建成别名，那 9.0 之后读旧数据就会有问题。

这个边界无法确认。如果你依赖读取 Transform 的历史通知数据，建议直接查一下那个索引是否还能访问。


## 和别的"兼容层收口"放一起看

这是 9.x 里写过的第三条同类改动，模式已经很清楚了：

| 条目 | 兼容什么 | 收口方式 |
|---|---|---|
| 单数据节点水位线开关移除 | 单节点水位线旧行为 | 移除设置 |
| REST API V7 兼容移除 | 7.x REST 响应格式 | 移除 V_7 分支 |
| Transform 通知索引别名（本篇） | 旧通知索引的读取 | 不再建别名 |

三者的共同节奏：

1. 上一代迁移时留一个兼容层；
2. 隔一个主版本后收掉；
3. 存量保留、增量不再创建——这次的"已有集群保留，新建集群没有"就是这个模式的标准表述。

第 3 点特别值得记：这是 ES 处理兼容性的一贯做法——不破坏存量，只改变新增。理解这一点，就能对这类改动的影响有准确预期：现有环境不会突然坏掉，但新环境的默认形态变了。

这个原则的实际价值在于判断 urgency：这类改动几乎从不需要紧急处理，因为存量是安全的。它属于"知道就行、按计划更新"那一类，而不是"必须在本轮升级中解决"。把这类条目和真正会破坏存量的 breaking 区分开，能显著减少升级时的无谓紧张。

区分方法也简单：看 changelog 里有没有"已有…保留"这类表述。有就是安全的兼容层收口，没有就要认真评估。


## 怎么确认自己的集群是哪种情况

如果想实际确认一下，可以这么查：

```sh
# 看有没有旧的通知索引
curl -s 'localhost:9200/_cat/indices/.data-frame-notifications-1?v'

# 看有没有新的
curl -s 'localhost:9200/_cat/indices/.transform-notifications-000002?v'

# 看别名情况
curl -s 'localhost:9200/_alias/.transform-notifications-read?pretty'
```

（说明：最后那个别名名字是按命名习惯猜的，具体别名名未核实。更可靠的办法是查索引自己的别名信息。）

几条命令的结果组合起来判断：

* 只有新索引 → 正常，本次改动和你无关；
* **新旧都有** → 检查旧索引上有没有别名（有的话读取正常）；
* 只有旧索引 → 这种情况值得留意，说明迁移可能没走完。

第一种居多。8.x 之后建的集群根本没经历过那次迁移，自然也没有旧索引。


## 写在最后

这条 deprecation 影响极小——官方说没有已知影响，这个判断成立（推理见上）。

我的判断是：这条值得写是因为它示范了"兼容层收口"的标准模式：

> **存量保留，增量不再创建。**

这个模式在 ES 的版本演进里反复出现。看到它就能立刻判断影响范围——现有环境安全，但要按新形态规划。

一，绝大多数人不用处理。 存量集群的别名会保留，读取行为不变。这条属于"知道就行"，不需要排进本轮升级的必做清单。

二，"存量保留、增量不再创建"是 ES 收兼容层的标准方式。 看到类似表述就知道：不会破坏现有环境，但新建的东西要按新形态来。这也是判断紧急程度的信号——这类改动几乎从不需要紧急处理。


## 参考

- [changelog 9.0.0：Removing index alias creation for deprecated transforms notification index（第 670–680 行）@ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.0.0.yml#L670-L680)
- [`Transform.java`：三代通知索引模板名的处理（第 436–438 行）@ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/x-pack/plugin/transform/src/main/java/org/elasticsearch/xpack/transform/Transform.java#L436-L438)
- [PR 117583](https://github.com/elastic/elasticsearch/pull/117583)

> 本文对照 Elasticsearch `v9.4.2` 标签的 changelog 与源码核对，引文与代码逐字取自原文。`templates.remove(...)` 所在代码段的完整上下文未查看，其具体操作目的本文不做推断；"有旧索引但无别名的集群是否存在"这一边界未确认，已在正文标注。撰写时未启动集群、未运行测试。


7.x 到 8.x 迁移时，.data-frame-notifications-1 这个 Transform 通知索引被 .transform-notifications-000002 取代。为了兼容，会在旧索引上建别名让读操作还能读到历史数据。9.0 起这个别名不再自动创建——已有集群保留，新建集群没有。

ES 的 Transform 通知别名不再自动建，那条数据本来也不该直接读

7.x 到 8.x 迁移时，.data-frame-notifications-1 这个 Trans……

官方产研

云计算

后端

大数据

Elasticsearch 9.0移除Transform通知索引兼容别名，存量集群保留，新建集群不再自动创建。本文解析该deprecation的迁移背景、影响范围，并提供验证方法，帮助判断是否需要处理。

Elasticsearch Service

Elasticsearch 

数据转换

文档处理

代码解释

GitHub

Java

让每一个 Agent，都跑在云上

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ES 的 Transform 通知别名不再自动建，那条数据本来也不该直接读-腾讯云开发者社区-腾讯云

ES 的 Transform 通知别名不再自动建，那条数据本来也不该直接读

ES 的 Transform 通知别名不再自动建，那条数据本来也不该直接读

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐