某烟草集团，集卷烟生产销售、烟草物资配套供应、科研以及多元化经营等为一体，在卷烟产销总量、全国市场覆盖率、国际市场销量等多项指标上均位居行业前列。

该集团基于微信服务号运营，策划了以烟包二维码为载体，通过单品活动项目探索了烟草互联网营销的转化路径，初步建立了与渠道、终端、消费者的连接。

随着营销活动场景的不断丰富，业务结构复杂性不断提升，预计未来5-10年，每日独立访客将达到目前的5-7倍，为了支撑未来业务的高速增长和多业态经营，需要从业务、技术和管理多个方面，对集团的互联网营销平台进行重构升级。

迁移需求

建设新一代互联网营销公共服务平台，进行业务创新，需要根据新系统的设计，将原有分散的用户基础数据、用户行为数据、活动模型数据、资源类目数据、积分数据、交互事件数据、二维码数据等数据进行整理、补充、完善后，迁移整合至新营销平台的共享服务中心。以便前端应用灵活调用，达到业务快速迭代创新的目的。

主要难点

1. 异构迁移

        数据模型是数据迁移的重要基础，新平台各服务中心重新设计了数据模型。需要根据数据模型的变化情况，从不同的源库获取数据，进行拆分重组，形成新的目标数据库。

      新老平台数据模型的巨大差异，增加了整个迁移复杂度，主要涉及以下方面：

• 多表合并：老平台多个系统的多张表，按照业务逻辑合并为一张表。

• 多表拆分：多个系统的核心业务大表与其他表关联，在新平台拆分为多张表。

• 字段转换规则：目标表的新增字段由源数据表的特殊字段(JSON)转换而来，确认对应的转换规则。

• 字段默认赋值：目标表的新增字段在源数据表中并不存在，要按照具体的业务逻辑规则计算出字段的默认值。

2. 业务逻辑复杂

        原平台建设初期，业务仍在探索阶段，不同开发服务商的建设标准不统一，导致系统孤立建设，功能重复、且存在数据结构设置不合理的情况。随着用户体量的增加，用户体验变差。新平台从融合统一的角度进行深度设计，业务结构重组必然带来底层数据的合并治理，让数据迁移难度大幅增加。以用户身份不一致问题为例，用户与账号、角色之间存在一对多的关系。在数据迁移的过程中，需要梳理多个系统中同一个真实用户的多个账号，多个账号对应的不同角色，角色相关的积分、订单、兑奖等数据信息，进行组合、重构，变为新系统中的一个账号体系。

3.数据体量大

        原平台有上亿用户量，用户积分数据量达10亿。数据迁移量大，要进行大量的计算重组，而可停机时间短，毫不夸张的说每一个系统的数据迁移都是一场与时间赛跑的战役。考验迁移流程的可控程度，更考验迁移团队的风险应对能力。

解决方案

云掣数据库专家对现有的各业务系统数据做了详细的调研与分析，制定数据迁移方案，并完成整体的数据迁移任务。

1.数据调研 

盘点待迁移数据源端数据库实例数量、类型、数据架构、各系统的数据模型。确定本次迁移涉及的阿里云产品主要包含：

• 云数据库MySQL

• 表格存储Tablestore(OTS)

• 实时分布式搜索与分析引擎Elasticsearch

• 云原生数据仓库AnalyticDB(ADS)

2.方案设计

数据备份方案

在迁移前，配置合理的数据备份策略，确保数据备份的有效性。

• 云数据库MySQL使用产品默认备份功能，配置合理的备份策略，实现全量数据和binlog日志增量备份。

• 表格存储Tablestore通过将全部数据同步到数据中台实现备份。

• AnalyticDB使用产品自动备份功能，通过数据快照实现集群全量备份，Redo日志实现增量备份。

• Elasticsearch使用snapshot API进行对集群打快照，实现备份。

从MySQL迁移到Elasticsearch需要先从业务逻辑上梳理来自于两个不同系统数据表中字段的对应和融合关系，将源数据同步到数据平台。

经过清洗后汇聚成多张Elasticsearch所需的宽表，再根据现有数据量和未来预计增量确认好Elasticsearch的分片数。

最后确认清洗后表字段和Elasticsearch字段的对应关系，同步已完成清洗的表到Elasticsearch索引。针对核心业务大表，再进一步进行分表处理。

2、AnalyticDB到Elasticsearch异构迁移

老平台因业务模块分批建设，日志数据的搜索查询，分别采用了云原生企业级数据仓库服务AnalyticDB和Elasticsearch实现，新平台统一使用Elasticsearch，需要对AnalyticDB和Elasticsearch的数据进行合并。

与MySQL到Elasticsearch的异构迁移类似，经过确认字段对应关系，数据清洗，汇聚成宽表，确认分片，数据同步多个环节后，完成迁移过程。

3、Tablestore到MySQL、Elasticsearch异构迁移

老平台部分业务高度依赖阿里云表格存储Tablestore(OTS)，但随着业务的快速发展，出现了明显的性能问题。新平台架构设计做了优化，需要按照新的业务逻辑对OTS的数据进行拆分迁移：

• Elasticsearch：存储需要全文搜索的数据，例如订单数据。

• Tablestore：存储其他用户登录日志等相关。

• MySQL：存储用户强相关的数据，同时做分表处理。

在整个迁移过程中有两个环节涉及数据同步，第一个环节是从源数据库同步数据到DataWorks，在DataWorks中对数据进行加工处理，存储到中间库，第二个环节是从中间库同步数据到目标库。以用户表的拆分为例，整个迁移过程如下图所示：

存量数据同步

1、确定存量数据迁移时间点。

2、使用DataWorks进行数据清洗，将清洗后的数据存入中间数据库。

3、通过数据集成工具将中间数据库的数据同步到目标数据库。

增量数据同步

1、根据存量数据迁移时间戳，筛选出新增需要迁移的数据。

2、采取和存量数据相同的逻辑，对数据进行清洗，存入中间数据库。

3、最后通过数据集成工具按照增量的方式将中间数据库的数据同步到目标数据库。

数据校验方案

迁移操作过程中的任何误差都可能导致数据不一致，影响数据质量，从数据完整性和一致性两个方面进行数据校验。

数据完整性

从数据对应关系，新旧数据在相同时间段内的数据条目数等维度确定对应的约束性原则。

以RDS的完整性校验为例：同构迁移数据使用DTS自带的验证功能抽样验证，重要的表使用脚本取模函数确认无误。异构迁移的数据首先确认清洗重构的逻辑无误，迁移前后数据对比行数对比无误，拆分前后数据量一致，并抽样用户相关所有表在经过清洗加工后符合预期。

数据准确性

依赖于模拟真实的业务场景下的用户行为，由研发、测试、运营共同配合校验。

例如迁移后的订单数据，对应的买家和商品关联数据在迁移之后必须也保持完整，如果迁移的一个订单到新系统之后被拆分为几个子订单，拆分的子订单聚合之后也应该能够完整的复现出旧订单相关数据。

数据回滚方案

针对迁移过程中的增量数据问题以及其他可能的异常情况，制定对应的数据回滚方案。

以MySQL和Elasticsearch的回滚为例，根据新老系统表结构映射关系，进行新系统到老系统的逆向同步。

迁移实施过程

依据标准的迁移流程，按照业务优先级分阶段进行用户、积分、品规、扫码、活动、内容、商城、系统各中心的数据迁移。需要提前准备好拆分和重组脚本，并通过充分的测试保障脚本正确性，完成特殊情况的处理。

数据安全保障

数据安全是数字经济时代下企业高质量发展的首要保障，在数据迁移过程中，从数据备份、访问控制、权限审批、数据审计、安全漏洞多个方面入手，加强对数据的保护。

项目成果

成功完成了单表10亿级数据量的异构迁移，多账号多角色的用户去重去冗余，实现了统一用户标识，为提取用户标签，实现用户画像打牢数据基础。有效的解决了集团不同区域营销系统不统一，用户多重身份的运营难点。