海量数据迁移：Elasticsearch到OpenSearch的无缝迁移计谋与实践 ...

一．迁移背景

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

二．迁移分析

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

• 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，但现实测试无法迁移。
  

总结：

• 5.2.2 版本需要开在os版本中验证数据格式和数据类型是否可以，以确定是否可以迁移。
  
• 700T 数据量较大，需要思量迁移时间和数据一致性的保证。
  
• 由于数据量较大，发起os利用商业版存储或SSD固态硬盘，以提拔存储效率和查询效率。
  

三．方案制定

3.1 利用工具迁移

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

步骤：

• 将业务应用步伐写入es断开
  
• 将业务应用步伐的写入指向新的os集群
  
• 利用elasticdump将数据分批次导出/导入集群
  

1. 比如导出1年数据
2. 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" } } } } } }"

复制代码

上风：

• 开源步伐，无需思量自研
  
• 通过查询条件实现的类似断点续传的功能
  

劣势：

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

3.2 脚本迁移

步骤：

• 将业务应用步伐写入es断开
  
• 将业务应用步伐的写入指向新的os集群
  
• 开启数据抽取脚本，并写入kafka
  
• 开启数据写入脚本，读取kafka消息，写入os中
  

为什么需要kafka呢？

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

1.         "query": {
2.             "bool": {
3.                 "must": [
4.                     {
5.                         "range": {
6.                             "access_time.keyword": {
7.                                 "gte": 2023-01-01 00:00:00,
8. "lt": 2023-01-01 00:00:00,
9.                                 "format": "yyyy-MM-dd HH:mm:ss"
10.                             }
11.                         }
12.                     }
14.                 ],
15.                 "filter": {
16.                     "term": {
17.                         "loglevel.keyword": "ERROR"
18.                     }
19.                 }
20.             }
21.         }
22. }

复制代码

这样每次只需改动数据抽取时间范围即可，同时将数据写入kafka中。若步伐停止，可让写入脚本将消息斲丧完成，确定末了一条数据的写入时间，改动抽取脚本的时间范围即可再次启动抽取脚本，无需进行数据清理工作，只需等待写入完成即可。
数据写入脚本只需订阅相关topic即可，将数据写入到opensearch中，若脚本异常退出或网络停止，可重新进行消息的斲丧，无需思量数据一致性问题。
上风：
1.自研脚本操作数据无需思量版本兼容问题
2.可控数据传输(如：停息，开始)
3.支持断点续传功能
4.无需停机迁移，业务可正常写入
5.支持性较好
劣势：
1.迁移过程应用步伐读取数据问题，一段时间内无法读取到历史数据，因为在做数据同步过程，也可修改应用步伐读取es集群中的历史数据
四．方案发起

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。