上期我们讲到了高校数据中台“要不要迁移”和“怎么迁移”的问题，因为篇幅限制，“怎么迁移”只介绍到了数据湖集成的部分。其实数据湖集成的关键在于梳理业务系统入湖的需求（范围要求、实时性要求）和按需进行入湖策略的设置，这部分因为在开发过程中我们就把复杂的代码过程转换成了可供选择的配置项，所以操作起来难度应该不大。
之后的标准层迁移、下行接口迁移、质量规则迁移和A尸l接口迁移因为涉及到代码标准&数据标准升级、集成工具替换、质量规则优化、无感知接口迁移等很多对标和优化工作，需要人工＋智能化辅助工具结合的方式进行“又快又好”双管齐下的迁移。这期我们就来详细聊聊这些工作怎么做。
标准层迁移
将学校原数据中心的代码标准和数据标准模型迁移至迪塔维数据中台4.0中，重新进行代码的比对、确认、转标，完成代码标准的迭代升级，并以八大域数据目录进行数据的重新归类。
◆ 确认需要迁移的标准模型范围及优先级
◆ 数据标准模型迁移
迁移方式有批量导入、自动反向和人工新建三种，需注意新建时PG数据库对大小写敏感，需以小写的方式进行字段命名，并按八大域目录进行模型的划分。
◆ 模型主键设置
◆ 集成接口的迁移
l 批量迁移
批量迁移来源可选择ODI、DDI、KETTLE等常见的第三方工具，填写数据库连接信息后，按需对迁移接口进行勾选，即可一键生成相应的接口信息，再进行人工调优。
l 人工新建
注意以下几点：
【多表关联】：多表关联集成时，需确认好主外键关系及关联方式，在数据库中测试无误后方可进行配置，以防出现关联后数据量不一致的情况；
【数据转标】：若代码标准确认且已完成数据对标及映射，则可在集成时进行转标操作，确保进入到标准层数据的准确性。
◆ 无主键接口的迁移
同数据入湖，无主键表需通过集成工具（或通用集成方式）进行接口的迁移，集成工具仅支持低频调度的方式进行任务调度设置。
◆ 任务调度的配置
同入湖调度，分为实时流和高频轮询两种模式。具体操作已在上篇说明，不再赘述。
◆ 标准层视图的迁移
视图的迁移是标准层迁移中的重、难点。如果新旧数据中心所使用的数据库类型不同，将造成很多函数的不可用，人工迁移又会耗费大量成本。别担心，我们有聪明又高效的SQL翻译机工具，能快速进行异构数据库视图的翻译和迁移，极大地提升迁移效率。
下行接口迁移
完成原集成工具（如ODI）中的下行接口1:1迁移，在不影响学校第三方业务的情况下，进行临摹式的下发接口迁移工作。
◆ 下行ETL接口信息梳理（下发源表、目标表信息、代理执行时间，目标库连接信息）
◆ 下行ETL接口迁移
l 有中间库
按照原有下行接口在集成工具中进行接口制作。流程为：
l 无中间库
需跟学校沟通，要求业务厂商提供中间库后再进行下发。若不能提供，则需通过新数据中台开放中间库用户，再依照上述流程进行数据下发。
注意两个“严禁”：
（1）严禁对业务系统直接推送数据；
（2）严禁业务厂商直接读取标准层的表或视图。
◆ 做好下行ETL接口迁移的文档记录和交付
质量规则迁移
对标准层的数据质量检测配置进行迁移及优化，确保数据的准确性。
◆ 原数据中心数据质量检测规则梳理
◆ 数据质量检测规则调整
需按照PG数据库的语法要求将质量检测规则进行重构（可借助SQL翻译机）。
◆ 空数据表及空字段信息梳理
◆ 数据质量检测新需求收集
例如：人员相关数据的检测一律添加过滤条件，只检测在职教职工。
◆ 数据质量检测规则配置
质量检测在数据湖层进行还是在标准层进行以学校意见为主，建议在数据湖层进行，因为这样可以发现数据源头的更多问题，而标准层是经过清洗转换的，不能真实表达业务系统的数据质量情况。
注意过滤条件有两种添加方式，一种是在新建规则时将过滤条件加入到规则语句中，另一种是在字段规则配置时填写过滤条件。前者会造成规则重复且难以区分，建议以第二种方式进行处理。
配置规则时，需设置标识字段，用于辨别违规数据，例如人事信息的标识字段一般设置为姓名和职工号，如下图所示：
◆ 在线数据调试
◆ 配置任务调度周期
一般开始时间设置在标准层集成任务之后，检测周期根据数据变化情况可选择每日、每周或每月等。
◆ 质量检测报告输出
我们会分业务系统输出质量检测报告，对比检测结果与学校沟通，进一步优化检测规则。
◆ 质量检测提醒
质量检测报告经优化确认后，可以配置质量检测提醒，定期发送给各业务部门进行质量问题确认，我们支持对接邮箱、企业微信、钉钉等主流渠道发送消息提醒。
API接口迁移
标准层切换完成后，将开放的API接口进行迁移，要求在不改变域、调用地址、出入参、过滤方式、调用方法的前提下进行无感知迁移。
◆ 原API接口梳理（接口名称、接口地址、数据源、出入参字段、APPID、密钥、TOKEN、调用次数、应用名称、申请人等）
◆ 原API接口测试，排除僵尸接口、测试接口。
◆ API接口迁移
API接口迁移涉及复杂的接口调用、解析工作，这里我们提供一键迁移功能，可快速实现第三方接口的无感知迁移。自动化完成接口在开放平台上的注册、解析、申请、认证信息对比、可调用API生成及批量测试，最后我们配合学校将开放平台IP切换或域名指向调整，完成对第三方API接口的无感知切换。
◆ 中台API接口测试
为保证中台切换上线后数据交换的平稳流畅，中台API接口要经过多轮严格的测试，包括平台一键测试、外部工具测试和负载压力测试、网页端适配测试（GET方式）等，并进行持续调优。
注意以下几点：
l 一轮测试需详细梳理测试结果，并进行分类分析和接口修复。
l 接口负载测试（压力测试）需至少对500并发、1000并发、1500并发进行测试，根据压测结果及学校使用场景的需求，可对API负载节点进行新增。
◆ 第三方厂商协助联调
打通接口测试的“最后一公里”，可以联系使用频率较高的厂商进行真实场景模拟测试。
◆ 域名切换验证
所有测试均通过后，可与学校协调一个使用频率相对较低的时间进行域名的映射切换。我们会做好充分的风险预案，并配备技术人员进行现场切换保障，随时响应突发问题。
若切换后发现问题且无法在短时间内处理完成，则会马上将域名切换回原开放平台服务器，待问题处理完成后再重复上述域名切换操作，直至平稳切换。
迁移工作的总结
❖ 检查与确认
核对环境：根据实施计划，核对各服务器的环境配置情况；
检查部署：检查各平台的部署完成情况；
确认数据：确认数据迁移的完整性，验证数据传输的稳定性；
测试验证：测试验证数据中台的功能，判断数据的使用状况；
验证运行：验证迁移后的各平台、工具、业务的运行情况。
❖ 归档与交接
文档归档：指定负责人整理文档，迁移完成后交付给学校留存；
知识沉淀：新知识、新经验更新至迪塔维知识库，完成知识共享。
❖ 风险和策略
迁移过程中可能发生的平台、网络、数据等方面故障，应及时检查，尽快恢复正常运行；
对数据迁移过程中可能出现的数据丢失情况，应及时做好备份，确保数据的完整；
API迁移过程中，可能因调用方式不兼容而引发故障，应提前测试API接口的兼容性，避免出现事故。
特别强调：备份预案牢记心间，迁移安全防线共建！
数据中台“怎么迁移”的问题就介绍到这里了，不知道有没有打消老师的一些疑虑呢？这里也请各位老师放心，我们会为每个现场配备技术支持，在迁移过程中出现任何异常情况时都可以及时响应。迁移切换期间，我们会提前协调好开发、运维等同事的支持，做好备份工作和回退方案，保证您的迁移工作安全无虞。