海量数据迁移：Elasticsearch到OpenSearch的无缝迁移策略与实践

一．迁移背景

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

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

总结：

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

步骤：

将业务应用程序写入es断开
将业务应用程序的写入指向新的os集群
使用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" } } } } } }"

优势：

劣势：

步骤：

为什么需要kafka呢？

解耦合
使用程序可以实现从elasticsearch集群中抽取数据直接写入到opensearch集群中，但会增加opensearch集群的压力，所以中间加上kafka消息中间件进行解耦合。
多版本共存
若是使用的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开发脚本进行数据迁移。