2021年4月27日终于完成了李宁项目的数据割接和系统割接工作，系统切换后数据正常，李宁的各项线上业务正常，悬着的一颗心终于落了地，智慧零售的小伙伴又一次突破了自己，2个月不到的时间，完成了李宁运行长达10年数据异构割接到云mall中台，并沉淀出了云mall数据割接系统。
李宁项目的成功落地意味着智慧零售3次成功地将客户（沃尔玛、山姆和李宁）飞速发展的网上商城换成了云mall引擎，最惊心动魄的莫过于将业务运行10多年的数据库全部异构到云mall系统，数据不少不错，并且支持历史数据的逆向流程（退款、退货等），作为两次主导数据割接的工作的我来说，特别能体会其中的艰难和压力，有必要做个数据割接实战总结，希望这个总结也能对想了解数据割接流程同学起到抛砖引玉的作用。
背景描述
在描述数据割接之前，可能大家对数据割接比较陌生，我先介绍一下项目的背景以及数据割接的含义，让大家能快速了解接下来要详细描述的数据割接是什么。
首先描述一下项目背景，目前有很多客户本身很希望能构建线上销售渠道，但是本身的技术能力又做不到，因此我们智慧零售凭借云mall中台多年商城项目的经验和技术实力并整合公司的各项资源（微信支持、营销广告、小程序、腾讯云和智慧零售云mall中台等），帮助客户快速构建线上交易平台，实现销售收入倍增。
什么是数据割接？
数据割接就是将客户运行了很多年系统沉淀的数据平滑迁移到云mall中台，因为我们接触的客户本身也有网上渠道，并且系统已经运行了甚至超过10年，积累了大量的数据。由于库表结构都完全不一样，所涉及到的数据改造会非常多，数据校验也面临比较大的考验。
数据割接的难点
数据割接和数据迁移有很大不同，数据迁移只是将迁移到不同的机房或者实例中，而数据割接则不仅需要将数据迁移过来，而且还要对数据做异构，使得割接后云mall系统能完全兼容，因此面临比较多的难点，总结主要有如下几个难点：
1、数据量大，如何能实现快速割接？
客户的系统经历了多年的沉淀，包括订单、用户、商品、评论、资产以及优惠券等，部分数据单表记录数超过千万。线上系统切换分为数据割接、系统割接和测试验收等环节，整个过程大概8小时左右，因此留给数据割接的时间只有2个小时左右，所以必须在2个小时内完成所有数据的割接工作。
2、涉及到客户的核心数据，如何保障数据安全？
3、数据异构后写入云mall中台，没有现成工具，如何实现效率和准确定？
4、数据迁移的时候有顺序依赖，如何做好流程编排？
5、如何做好数据校验，保证数据一致性？
以上这些难点在后面的经验总结部分再做详细解析；
数据割接实战演进
在沃尔玛和山姆的割接中，完成整个数据割接流程的探索，由于时间关系但没有落地成数据割接系统，采用直接加工到后端DB的方式。而在李宁的数据割接过程中，我们把数据割接提升为智慧零售云mall中台基础能力，构建了云mall数据割接系统，为以后大批量业务割接打好基础。下面就来介绍一下数据割接的演进。
山姆会员店数据割接
山姆会员店的数据割接流程架构如下图所示：
山姆的数据割接主要分为如下几个流程：
1、山姆侧做的数据第一轮加工，这些加工可以理解为粗加工，包括状态映射、异常数据过滤、增量数据获取等；
2、山姆侧将加工后的数据导出并上传到腾讯云分布式存储，导出的数据为保证数据一致、安全以及高效，使用了校验码、数据加密以及数据压缩；
3、腾讯侧从分布式存储下载数据，并做解压缩、解密以及数据校验后倒入到中转DB中；
4、腾讯侧对中转DB的数据进行异构加工，并存储到云mall中台DB中；
可以看出，山姆会员店数据割接整体比较简单，两边都有做数据加工工作，但这种方式不通用，需要耗费比较多的人力，沟通同成本也非常高；
李宁数据割接
由于时间关系，山姆割接的时候没有做系统的沉淀，只是把整个数据割接流程跑通，并确认好各个数据加工的细节。到了李宁数据割接的时候，我们将数据割接能力作为云mall中台的基础能力来打造，使得后面再做数据割接的时候能减少人力的投入，并提升整个数据割接的效率；下图是李宁数据割接的整体流程架构：
由上图可以看出业务侧只负责的导出和原始数据核对，所有的数据加工工作都由腾讯侧来完成，这些数据加工能力全部沉淀到云mall中。数据割接已成为云mall中台的基础能力，后续再做数据割接的时候，即可节约大量人力和实现效率提升。
李宁（通用）的数据割接主要分为如下几个流程：
1、李宁侧通过导出中心导出原始DB里的数据，经过校验码、加密和压缩后传输腾讯云分布式存储中；
2、腾讯侧通过数据中转中心，将数据做解压、解密并进行数据校验后存储到中转DB中；
3、定开层从中转DB中获取数据后对各类数据进行清洗（数据过滤、状态转换、图片地址转换、数据统计、增量数据提取等），并将清洗后的数据调用数据割接中台的接口传输到清洗后的数据存储中心；
4、依托于数据割接中台的强大流程编排能力，对各类数据加工顺序做编排，然后由数据割接中台调用中台割接中心的各类接口直接将数据通过流程接口将数据最终落地到中台DB集群；
数据割接经验总结
通过几轮的数据割接，积累了不少经验，除了将数据割接的流程沉淀为工具和系统以外，还有很多细节会直接影响数据割接的成败，需要重点关注。也一并总结一下，希望能给需要做数据割接的朋友一些指导，下面就来描述一下需要重点关注的点和解决办法
细节对齐很重要
在做数据割接之前，需要和业务侧详细对齐好相关问题，并做好邮件确认，尤其是涉及的库表割接范围和时间范围以及列含义等，避免后面出现数据问题后做对照校验以及防止扯皮（你懂的😄）。这些问题主要包括：
1、哪些数据需要割接？
2、数据是全量割接还是只割接部分数据？
3、迁移的数据涉及到哪些库表？
4、对应库表的存储介质是什么？
5、对应库表的数据量大小（占用空间、记录数等）
6、对应表每个字段的具体含义，使用场景，哪些字段不需要割接等（确保核心字段都正确割接）
7、对应库表原来的业务场景和逻辑是什么？
以上这些需要产品、研发、DBA还有测试的同学通力合作，确保需求理解正确、信息确认无误以及后续的测试验收环境能和需求保持一致。
下图是我们对齐中的部分对齐文档的sheet：
所有数据可重录机制
为了提升割接的效率以及割接过程出现问题能随时重试，必须支持数据的重录机制，那就有两个环节必须做到如下要求：
1、割接中台支持重试，并支持相同数据加工后的中台ID保持一致；
在割接中台保留一份ID映射列表，对于已经加工过的数据，直接使用已经映射好的ID列表，这样每次加工都能获得相同的ID，到后端就对应了相同的记录；
2、割接中心接口支持幂等；
接口和DB交互的时候，如果DB存在对应的ID就进行replace操作，如果不存在就直接插入；
数据迁移效率如何提升
这里说的数据迁移是李宁侧将数据从源实例中导出、生成校验、压缩加密，然后上传到分布是存储，最后到腾讯侧将这些数据下载后倒入到中转DB，如下图所示：
由于整个数据割接的时间大概是2个小时左右，那么数据导出和传输的时间不会超过40分钟，因此这部分如何优化就特别关键，下图是大致优化的流程：
针对数据迁移部分做的几个优化罗列如下：
1、提升机房上传的带宽，分布式存储所在机房和李宁机房保持一致；
因为主要瓶颈在上传速度上，机房保持一致上传速度能他提升4倍左右；
2、数据导出和数据上传走异步流程，导出和上传不冲突，效率提升40%；
3、增加cos桶的监听逻辑，当李宁侧一个文件传输完，就立即进行下载和导入；
4、导出和导入使用多线程方式；
5、对于不会变更的数据提前传输和导入；
以上优化完成后整个流程从234分钟下降为26分钟；
如何从割接模式提升数据加工速度
由于后端数据加工涉及到各种校验逻辑和数据加工逻辑的制约，再加上有的表上亿的数据量，加工速度再怎么优化也难以在2个小时内完成，因此我们采用了全量割接+增量割接的模式。
在正式割接的前几天就将截止到目前的全量数据做好割接，这部分数据不受时间的制约，从容地加工数据，从容地测试验证，并且可以把业务方也卷入进来做验收。
做完全量数据割接后，到了正式割接的时候，只需要割接几天的数据就OK。这里有个前提是必需具备增量数据的割接能力
增量数据如何提取
关于增量数据提取，之前我们采用业务侧的timestamp字段发现有一些场景客户侧会不更新timestamp字段，大家可以采用如下解决方案：
1、业务侧将时间字段进行修改，加上default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP属性；
2、增加一个default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP属性的时间字段；
数据导出工具如何选择
由于业务侧使用的版本和腾讯侧不一样，单都是MySQL，因此全量数据导出我们选择mydumper多线程导出，myloader多线程导入，增量数据使用mysqldump加上-w指定时间导出
数据校验非常重要
关于数据校验部分是保障后续数据准确性最重要的一环，因此对于数据校验格外重视，中间的数据流转如下图所示：
从上图可以看出数据流转氛围4个环节，根据流转的环节，数据校验也主要分为源数据校验，迁移过程中的校验、清理数据校验以及加工后数据的校验等4个环节，如下图所示：
下面就分别来描述：
1、源数据校验
源数据主要是客户侧本身的数据校验，客户侧一般是直接从从机导出数据，根据我们的经验，客户侧的主从数据有较大概率的不一致问题，因此为保障数据一致性，客户侧必须用工具做好主从数据的校验，工具推荐使用：pt-table-checksum
备注：之前做数据割接在测试场景发现客户侧主从数据不一致问题，后面我们统一加上客户侧的源数据校验环节
2、迁移过程中的数据校验
数据迁移是李宁侧导出数据到腾讯侧导入到中转DB中，为了保障李宁侧导出的数据和腾讯侧导入到中转DB的数据一致，我们增加了如下两个数据校验环节：
a、数据文件的校验码必须一致，防止文件不全的情况（李宁传输数据到分布式存储前会生成md5校验码）
b、导入后数据行数必须和导出的数据行数一致；
备注：李宁割接当天晚上就出现行数校验不一致的问题，发现是有一个大表导出一般就退出了，因此校验工作前置很重要，避免后面做无用功。
3、清洗数据比对
这里的清洗数据是指定开层做数据清洗后，将数据调用割接中台的接口录入到清洗后的数据存储中心，这部分数据的数量必须和割接中台加工的数量一样。比如清洗后传递给割接中台的数据为10000条，那么割接中台加工的数据也必须为10000条（成功和失败的总量，失败的需要确定具体的原因，做好修复）。
4、加工后的数据校验
加工后的数据需要多维度的校验，尤其是资产类数据，我们校验的维度比较多，这里只列举一些主要的维度，这些维度包括：记录数校验、金额校验、不同状态的记录数和金额校验（这些状态包括订单支付状态、订单发货状态、订单状态、会员等级、资产使用状态和商品状态等等）、明细数据抽查校验等等。
数据安全如何实现
由于数据中包含了诸如会员信息、订单信息等敏感数据，需要保障迁移过程中的数据安全，我们主要作了如下几个方面的工作来应对数据安全问题：
1、传输前对数据进行加密；
2、分布式存储设置为私有读写，并设置好私有读写用户的秘钥和证书；
3、中转DB接入DB管控平台，只允许相关同事查询，限制导出；
数据割接中的割接顺序如何确认
关于割接顺序部分基本没有什么技巧，唯一的技巧就是了解各个业务场景和数据逻辑，确认好各个数据的依赖关系，核心逻辑就是基础数据先行，比如会员、商品、优惠券等大部分数据都需要依赖这些基础数据。然后最复杂的是订单部分的依赖关系，下面是部分流程编排的批次顺序：
数据割接系统沉淀
通过几轮的数据割接实践，沉淀出智慧零售数据割接平台，使得云mall中台具备异构数据割接的基础能力，为后续云mall大规模接入打下基础。由于数据割接系统整体提比较复杂，限于篇幅，这里不做详细介绍，后续会梳理文档再做详细介绍。
鸣谢
最后，要感谢智慧零售研发、运维、测试、pm以及产品的同学（由于人员涉及比较多，就不一一罗列了），凭借靠谱的精神，实现了几个月就将客户运行超过十年的系统割接过来，平稳运行在云mall中台上，打造一个又一个标杆。我们一直在路上，相信云mall中台一定会在智慧零售的道路上发挥越来越重要的作用。
