一．迁移背景

1. 目前有两个es集群，版本为5.2.2和7.16.0，总数据量为700T。
2. 迁移过程需要不停服务迁移，允许一小时不写数据，但是需要提供数据存储方案。
3. 迁移到opensearch的版本为1.3.4。

二．迁移分析

根据迁移背景中的描述进行分析：

1. Opensearch的版本是基于elasticsearch 7.10版本做的二次开发迭代，因此，7.16的es集群迁移到os 1.3.4属于小版本之间数据迁移，可正常迁移，但 es 5.2.2版本迁移到os 1.3.4属于跨两个大版本迁移，需要开发协助验证数据结构和数据字段类型是否完全符合。
2. 迁移过程不停服务，700T一小时无法迁移完成，需要考虑可以先迁业务，把业务的数据存储先指向os集群，然后历史数据追加到os集群。
3. 历史数据迁移到os过程中，可能由于一些原因失败，需要考虑迁移方案是否具备断点续传的功能。
4. 数据量较大，如果是es迁移到es建议使用snapshot方式，但是es迁移os此工具不行，虽然官方建议使用snapshot迁移es到os，但实际测试无法迁移。

总结：

1. 5.2.2 版本需要开在os版本中验证数据格式和数据类型是否可以，以确定是否可以迁移。
2. 700T 数据量较大，需要考虑迁移时间和数据一致性的保证。
3. 由于数据量较大，建议os使用商业版存储或SSD固态硬盘，以提升存储效率和查询效率。

三．方案制定

3.1 使用工具迁移

由于opensearch官网建议使用snapshot方式迁移，但实际测试过程中并不能迁移数据，使用elasticdump可实现数据迁移。

步骤：

1. 将业务应用程序写入es断开
2. 将业务应用程序的写入指向新的os集群
3. 使用elasticdump将数据分批次导出/导入集群

比如导出1年数据
elasticdump --input ./data_mapping.json --output https://admin:admin@192.168.2.200:32001/test --type=data --searchBody "{ \"query\": { \"bool\": { \"filter\": { \"range\": { \"requestTime\": { \"gt\": \"20200000000000000\", \"lt\": \"20210000000000000\" } } } } } }"

优势：

1. 开源程序，无需考虑自研
2. 通过查询条件实现的类似断点续传的功能

劣势：

1. 支持性不好，若elasticdump工具问题，不能快速解决
2. 需要对es数据很熟悉，并且数据中有可以查询时间范围的字段
3. 对es语法了解，需要会写es查询语句，删除语法
4. 按时间段进行导入导出数据为了较少因导入过程中故障问题，可通过查询条件删除数据在重新导入，风险较大
5. 由于分批次，导入导出周期很长
6. 暂不支持5.2.2的导入导出，需开发先验证数据结构和字段是否支持两个版本
7. 时间不可控，elasticdump工具不适合大数据量导入导出，时间周期会较长

3.2 脚本迁移

步骤：

1. 将业务应用程序写入es断开
2. 将业务应用程序的写入指向新的os集群
3. 开启数据抽取脚本，并写入kafka
4. 开启数据写入脚本，读取kafka消息，写入os中

为什么需要kafka呢？

1. 解耦合
   使用程序可以实现从elasticsearch集群中抽取数据直接写入到opensearch集群中，但会增加opensearch集群的压力，所以中间加上kafka消息中间件进行解耦合。
2. 多版本共存
   若是使用的java程序，elasticsearch的客户端java依赖一般是JDK8，而opensearch官方建议使用的客户端是JDK11, 一个java程序需要解决两个版本的JDK依赖问题，所以将抽取和写入程序分离开来。
   3.降成本
   对于数据抽取脚本，只需要按照数据格式可拆分的进行数据迁移，例如使用按照时间范围以及关键字进行数据查询抽取：

        "query": {
            "bool": {
                "must": [
                    {
                        "range": {
                            "access_time.keyword": {
                                "gte": 2023-01-01 00:00:00,
"lt": 2023-01-01 00:00:00,
                                "format": "yyyy-MM-dd HH:mm:ss"
                            }
                        }
                    }

                ],
                "filter": {
                    "term": {
                        "loglevel.keyword": "ERROR"
                    }
                }
            }
        }
}

这样每次只需改动数据抽取时间范围即可，同时将数据写入kafka中。若程序中断，可让写入脚本将消息消费完成，确定最后一条数据的写入时间，改动抽取脚本的时间范围即可再次启动抽取脚本，无需进行数据清理工作，只需等待写入完成即可。
数据写入脚本只需订阅相关topic即可，将数据写入到opensearch中，若脚本异常退出或网络中断，可重新进行消息的消费，无需考虑数据一致性问题。
优势：
1.自研脚本操作数据无需考虑版本兼容问题
2.可控数据传输(如：暂停，开始)
3.支持断点续传功能
4.无需停机迁移，业务可正常写入
5.支持性较好

劣势：
1.迁移过程应用程序读取数据问题，一段时间内无法读取到历史数据，因为在做数据同步过程，也可修改应用程序读取es集群中的历史数据

四．方案建议

综合以上优劣对比，建议使用方案3.2开发脚本进行数据迁移。