雄关漫道真如铁，而今迈步从头越
高校数据治理是一项长期而庞杂的工程，早期由于建设经验不足，大家普遍经历了共享数据库、主数据平台、大数据平台等“边走边建”的过程，因为建设年代不同、承建厂商不同、数据库类型不同、代码标准不一造成了数据治理“看似全、实则乱”的局面。
“数据中台”因其高度规范集约的特性大火之后，很多高校便面临了新的选择困境：数据中台要不要迁移升级？怎么迁移？
对于“要不要升级”这个问题，无论是使用我们2.0、3.0产品的老朋友，还是正在观望4.0的新朋友，迪小数都可以说一句：“放心升！大胆升！”。为啥这么有底气呢？不妨看看下面几条理由：
1. 底层架构足够健壮：迪塔维数据中台4.0采用的是成熟稳定的分布式数据存储与计算技术，可弹性扩展、平滑升级。搭载自研的批流一体数据集成引擎，实现海量异构数据源的实时入湖、秒级计算，同时兼容国产数据库、操作系统。在系统性能、计算效率、自主可控、实时性等方面都有质的提升，能为学校构建足够强大健壮的数据底座。
2. 治理流程足够规范：“知行合一”，我们将历练多年的高校数据治理方法论全部融入到了4.0产品中；“芥子纳须弥”，同时将分散的产品进行高度整合，统一收归，并紧跟政策导向不断迭代。我们可以按照中台内置的方法论流程进行引导式操作，从数据源连接、数据识别、数据湖集成、标准层集成最后到应用层建设，每一步都有清晰的指引和KPI指标展示，让数据治理工作更加规范透明。
3. 治理效果足够可见：4.0产品的开发是从用户视角出发，以引导式和低代码思路进行界面功能的设计，多为选择性、拖拽化操作，且加入智能辅助化工具，如自动识别、自动映射、智能sql转换等，真正降低使用门槛。同时治理成效更可见，有建设进度看板、数据血缘流向、集成任务监控、问题质量报告、数据资源门户等多种渠道展示治理成效，让数据治理工作不再是“黑盒”。
4. 升级风险足够可控：目前4.0是公司拳头产品，技术投入有保障，且在开发时便规划了适应升级的相关功能模块，3.0升级到4.0几乎无风险。如果是从其他厂商产品迁移，主要风险接口迁移的适配和数据库语法的兼容也均有完善的智能工具支持和技术解决方案，API接口迁移可做到第三方应用零调整、无感知。另外，数据中台升级是接口和脚本的迁移，不是重复建设，实施成本有但相比升级带来的优势，迪小数相信是值得投入的。
对于第二个问题“怎么迁移”，涉及的内容就比较多了，待我们细细道来。
数据中台的迁移涉及到大量的数据迁移、系统重建和调整，通常包含平台工具、标准层及数据迁移工作。为保证不影响学校业务的正常运行，新旧系统的切换需要在最短的时间内完成，且应用不能中断，并要做好超时未完成的倒退方案。无论对信息办的统筹协调能力，还是中台产品的稳定性、实施人员操作的规范性都是一项考验。
下面我们就以迪塔维数据中台4.0的升级迁移为例，从实施的角度介绍数据中台迁移的方法和注意事项。
迁移前的准备工作
1、计划：详细分析学校数据中台的设备、软件、数据等情况，制定迁移计划。重点关注迁移成本、网络连接、临时平台和人员配备问题。
2、资源：准备好数据湖、批流一体数据集成引擎、数据中台及按需集成工具所需的服务器资源（资源要求可详询项目经理）。
3、验证：对服务器资源配置、网络环境、对时信息等进行检测验证，确保环境符合平台部署要求。
4、部署：完成迪塔维数据中台4.0、集成工具、批流一体引擎、分布式数据库的部署工作，并对照《系统信息验证自检表》进行功能性验证（由实施人员完成）。
数据中台的迁移需要完成数据湖集成、标准层迁移、下行接口迁移、质量规则迁移、API接口迁移几项工作。因篇幅限制，本文首先介绍数据湖集成的操作，后续步骤将在下篇进行详细说明。
数据湖集成是将原本数据源->标准层的数据集成方式转换为数据源->数据湖->标准层的方式，调整策略，保障数据实时入湖。具体步骤如下：
◆ 确认需要入湖的业务系统信息
◆ 入湖的业务系统连接信息梳理
◆ 业务系统数据库连接测试
◆ 确定入湖方式
入湖的方式分为实时入湖和T+1周期调度，需提前确认需实时入湖的系统、表及周期调度的频率。
◆ 数据库开启日志权限
对于需要实时入湖的业务系统，需开启日志权限并进行验证测试。
◆ 各业务系统入湖表范围的确认
非必要入湖的表会占用一定的服务器资源和性能，也加大了后期的管理维护成本，因此需提前确认需要入湖的表级别范围，若后续有需要仍可进行新增表入湖。
◆ 数据模型反向
根据已确认的入湖范围，在迪塔维数据中台4.0上进行业务数据库模型的导入，并完成资源信息的识别。
数据库模型获取方式推荐：【自动反向】+【批量导入】≥【资源识别】
◆ 模型主键设置
对已反向的模型进行主键设置，若没有物理主键，但可以组合出联合主键的，可在模型中勾选多个字段设置成逻辑主键。
◆ 无主键数据表入湖
对于无物理主键及逻辑主键的表，需采用集成工具（或通用集成方式）进行全量数据的入湖抽取，通用集成支持低频调度的方式进行任务调度设置。
◆ 入湖调度任务设置
根据现场实际情况，对有物理主键或逻辑主键的表进行不同的任务设置。
l 实时流
确认业务源头数据库开启归档日志且数据库表具备主键属性的，可选用实时流方式。实时流提供三种更新策略，可根据现场数据情况进行选择。
l 批处理
根据调度周期分为高频轮询和低频调度两种。对有实时性要求，但是源头不具备开启数据库日志条件，但具备自增字段或时间戳字段的，可采用高频轮询的方式创建集成任务。
l 低频调度
传统的“T+1”调度方式，调度周期最小颗粒度可以到分钟。
◆ 任务执行状态监控
关注入湖任务的执行状态，对执行失败的任务进行日志查看与分析，确保入湖任务的正常运行。
◆ 代码数据入湖
代码表入湖与数据入湖操作类似，需要注意的是业务源在进行模型反向时分为数据表和代码表，反向后需区分出数据表和代码表，如下图所示，调整平台中模型的数据类别为：代码表，后续操作可参考上文数据入湖的操作流程。
