1.背景
某业务的3.1的存算一体集群在3副本高可用的架构下面临2个主要的问题:
a.部分列更新的数据导入IO消耗较大
b.数据每日增量TB级别，磁盘空间消耗较大
在我们的业务场景下，扩容主要考虑的因素就是磁盘空间和IO了，随着业务的发展，每个月都要新增至少1台(32C128G NVMe SSD 7T * 2)的机器，业务成本压力较大。
我们希望能够使用3.3 存算分离集群来解决这2个问题。存算分离只需要1副本，可以减少部分列更新的IO消耗，且可以支持datacache，只cache活跃的数据到本地NVMe SSD盘，减少磁盘空间的消耗。
2.测试验证
我们这边的同步任务都是使用Flink去同步MQ的数据写入SR,迁移OLAP表的一般步骤是:
(1) SDM工具同步表的历史数据 one_time_run_mode=true (开启一次性同步模式后，迁移工具只进行全量同步，不进行增量同步。)
(2) 新启动同步任务从MQ topic earliest点位接入表的增量数据到新集群
(3) 观察同步任务对应消费的topic的lag是否正常下降直至延迟正常
a.迁移工具SDM测试
这个工具是基于SR的replication机制开发的，我们早期测试发现过一些问题，反馈给社区的大佬都修复了。
具体迁移的时候需要注意要设置好兼容参数及注意使用限制。
tables using time_slice partitioning do not support partition creation mannually
这条限制在文档中没有提及，特别标注，使用time_slice 表达式分区的表无法通过SDM迁移工具进行迁移。
b.增量数据导入测试
partial update
cloud native index
batch publish
我们主要针对以上3个特性进行了验证测试，早期主要是以跑通为主，跑通后再看是否能持久稳定的跑，在能持久稳定的接入增量的数据后再观察资源使用是否正常(CPU / 内存/ IO / 磁盘空间 / OSS API使用情况等等)，在测试验证过程中发现了一些问题，都反馈给了社区大佬，最终都得到了完美解决。
c.查询性能对比测试
迁移完成后对主要的业务查询进行sql回归测试，与存算一体集群进行对比，确认是否有性能回退或者sql解析等问题，若存在相关问题可以通过explain anlyze 或者查询fe log查看异常信息。
3.迁移规划
a.盘点迁移对象，明确哪些可以使用SDM工具迁移，哪些无法使用工具迁移的。
| 对象 | SDM是否支持 | SDM不支持如何迁移 |
|---|---|---|
| 数据库用户及权限、连接数 | 否 | 提前整理好相关信息在目标库创建。 |
| External table / catalog | 否 | 提前整理好相关信息在目标库创建。 |
| time_slice 表达式分区的表 | 否 | 将源表表结构调整为不带time_slice 表达式分区的表，再同步不带time_slice 表达式分区的表的数据 |
| 内表及其数据 | 是 | - |
| 物化视图表结构及构建语句 | （物化视图中的数据不会被同步。并且如果物化视图对应的基表没有同步到目标集群，则物化视图后台刷新任务报错。） | - |
| 逻辑视图 | 是 | - |
b.规划迁移内表的批次，分批迁移
根据我们在测试期间观察到的各个表对OSS API的使用情况，对消耗较大的表单独创建storage volume, 避免受其他表影响或者影响其他表的数据同步，对用量不大的则进行合并。
下图来自京东物流的分享，可以参考。
c.完成以上2步的规划后可以逐步分批迁移直至完成所有表的迁移
从我们的迁移实践来看，使用SDM迁移200T的数据迁移用了不到12小时。
d.验证
当所有同步任务的增量消费都没有延迟的时候，观察集群资源使用是否正常，在新集群回归业务sql是否正常，验证用户链接是否正常，都没问题了就可以通知业务切流到新集群了。
e.切流
可以通过LB进行FE节点替换进行切流，将旧集群的FE节点下线掉，加入新集群的FE节点。若旧FE节点还有缓存的链接可以kill掉，业务重试会拿到新集群的链接。
4.迁移效果
迁移完成切换流量后，业务查询正常 P99在3s以内，符合业务预期。
且迁移到存算分离集群后，整体IO利用情况较存算一体集群更低，下线了1/4 的BE节点，后续还可以继续下线BE节点。
5.展望
目前的存算分离 3.3版本还不具备backup & restore的能力，在3.4版本有相关的功能，我们后续还会继续验证新版本的相关能力。
我们内部已经上线了多个存算分离集群，其性能已经得到业务的认可，后续有新的业务需要接入SR都会首选存算分离模式。
后续会逐步的把内部的存算一体集群迁移到存算分离集群，协助业务不断提高资源利用率降低业务成本压力。
最后，感谢StarRocks社区大佬们持之以恒的贡献，使得社区用户可以方便快捷的使用先进的存算分离架构来为业务提供极速的数据分析体验。Respect!
