有湖有仓，如何升级到湖仓一体
在之前的《湖仓一体概念快问快答》中我们介绍了从湖或仓升级改造到湖仓一体的基本思路，有不少小伙伴对升级迁移这个话题很感兴趣，希望能讲一些比较具体和通用的方法论。所以，本期文章聚焦讨论湖仓一体升级改造的可选方案。
很多企业在过去的 IT 基础建设过程中，都已经搭建了数据仓库或数据湖，或者两者都有。其中数据仓库一般使用的是传统 Oracle 或者传统 MPP 数据库，如 Teradata 和 Greenplum，数据湖使用 Hadoop 大数据平台。所以在考虑湖仓一体升级改造时，就会有一个疑问——假如企业既有数据湖又有数据仓库，该选择基于湖还是仓进行湖仓一体的升级改造呢？
讨论通过湖或者仓进行湖仓一体升级，我们要知道现有的数据湖和数据仓库分别使用的什么架构，然后我们才能知道选择什么路径，使用什么技术。
数据湖采用了什么技术？
数据湖基本都是基于 Hadoop 构建的，底层存储是 HDFS，因此将数据湖改造成湖仓一体理论上是可行的，但是需要注意的是，数据要采用①开放的格式，以及②存算分离改造。之所以对 Hadoop 平台进行存算分离改造，是因为大多数的 Hadoop 部署都是存算耦合的，存算分离改造的最佳方式就是引入支持存算分离、多计算集群架构的分布式数据库来实现数仓/湖/集市的跑批和查询功能，并且可以和其他多个引擎（如Spark/Flink 等）共享同一份数据，数据的存储依然可以使用之前的存储，比如HDFS和对象存储。
数据仓库采用了什么技术？
目前的数据仓库基本都是基于传统Oracle或者MPP 数据库构建的。传统关系型数据库，尤其是 OLTP 数据库在海量数据的存储、查询以及分析方面出现了明显的性能瓶颈。随着分布式技术的产生和发展，出现了以 Teradata 为代表的 MPP 一体机数据库，以及 Greenplum 和 Vertica 等软硬件分离的 MPP 数据库，2000年左右，很多企业开始采用 MPP 数据库支持数据仓库的建设，当然也有一些企业采用了共享存储架构的 Oracle。基于共享存储架构的数据库集群规模通常在几十节点，MPP 基本在百节点级别，支持数据体量有限，很难超过 PB 级别，而且复杂查询并发受限（几十到百级别）。
MPP 存算耦合，扩展能力有限，而湖仓一体架构的本质要求是存算分离，因此要用支持存算分离、多计算集群架构的分布式数据库替换原来的 MPP，并和其他引擎（如 Spark/Flink 等）共享同一份数据。因此基于数仓的湖仓一体改造路径是进行传统MPP产品替换，并对既有模型和应用进行改造。
如何实施升级改造？
实施迁移改造的方法与新建湖仓一体平台的方法相似，通过调研规划、迁移范围分析、迁移实施、迁移割接几个步骤完成。
现状调研
现状调研是对原平台现状调研，通过了解现状，识别差异，便于接下来设计迁移方案。从数据、架构、应用、管理等维度进行分析和评价，同时收集好各维度的既有资料。
数据来源
通常情况下原平台（数据湖或者数据仓库）已经实现了不同数据源的接入，了解源系统（数据来源系统，如业务系统、外部数据源等）的大致情况，可以在实施迁移至湖仓平台前，帮助项目团队更快了解整体数据架构。
数据体量
明确数据湖或者数据仓库的数据体量，以便在接下来的基础设施和扩张需求方面进行合理的设计和规划，•数据总量(GB)•数据增量(GB/天或GB/月)•最大表数据量(GB)
数据类型
从数据仓库迁移至湖仓平台，主要以结构化数据为主，而从数据湖迁移至湖仓平台则还要关注非结构化数据、文本数据等。
数据质量
数据质量通常应该由专门的数据治理项目来负责，但迁移项目的初期仍建议初步了解原数据湖或仓的数据准确性、完整性、一致性的大致水平。
数据模型
企业之前建立了数据仓库就会有数据模型，这里谈到的模型通常是基于业务数据的逻辑模型。从设计到使用至今，数据模型应该经历了很长时间，可能已经不能很好的支撑现有的应用场景，需要确认是否需要升级。升级数据模型需要注意的是，不同的数据层次应该有针对性的使用不同的建模方法。
如果不需要升级，则接下来进行迁移即可；如果需要升级，可以按照原来的模型设计方法进行升级，多数企业明细层的逻辑模型都是采用范式建模的方法，因此升级可以沿用原方式通过调研源系统和业务需求进行数据表和数据字段的分析。
数据ETL
ETL是复杂的数据处理过程，需要了解现有的数据湖或仓库ETL系统的实现方式、技术选型、性能指标等。实现方式要了解数据跑批及加工方式（如Perl、存储过程或者其他方式），最好提供样例参考。性能和响应方面要确认现有平台的跑批时间要求、即席查询时间响应要求、入库时间要求等，此外要盘点系统每日加载作业数量。
数据应用
了解数据应用的具体场景和应用需求，例如数据分析、机器学习等。明确应用对实时分析、即席查询等方面的需求，以及数据可视化方面的需求，例如图表、仪表板、报表等，针对有大量系统报表需求的业务场景，应注意了解报表需求数量和时效。
基础设施
调研原平台基础设施情况，如当前有多少节点、单节点硬件配置。同时调研客户数据存储规划，例如需要保存几年数据、几年后的数据总量规模。调研基础设施规模可以明确新平台的可用资源，为今后扩展做好规划。当然湖仓一体平台的本质要求存算分离、可扩展，使用真正的湖仓平台在未来长期运营过程中可以更容易进行。此外，原平台的CPU利用率、内存利用率、磁盘空间、网络带宽、数据库连接数等情况也应掌握。
平台用户
调研原平台的用户情况，有助于在系统的性能、技术选型和平台管理等方面进行规划，保证迁移后的顺利使用，如用户总体规划情况、系统使用人数、系统访问频次、系统查询的高峰时间等。运维团队作为平台的特殊用户群体，其人员构成、岗位分工和职责也应进行调研。
管理流程
企业数据管理的相关流程通常和整个平台技术路线密切相关，调研原平台管理流程对迁移的规划、实施和运维都有借鉴意义，可以在接下来湖仓平台上进一步改善和提升。以下是几个重要的管理流程。
● 数据需求收集流程；
● 数据开发和测试流程，例如数据采集、处理、分析等；
● 监控和维护流程，如数据质量监测、性能监控、故障排查等；
● 备份和恢复流程，包括备份频率、备份存储、恢复时间等；
● 安全和隐私保护措施，包括数据备份、加密、数据授权等。
资料收集
以上从数据、架构、应用、管理等方面的调研，通常是对应一些原平台既有的标准化文档和清单，以下是典型且有必要收集的资料。文档资料：验收文档、接口规范、ER图、操作手册等；迁移清单：服务器清单、接口清单等比较基础的清单，像ETL作业清单、库、用户、表、视图等清单如果有则收集，没有则将是我们下一步迁移范围分析的重点工作；最新代码：ETL作业及知识库、DDL；流程梳理：系统数据流程、日常运维流程；其他内容：增量接口文件、数据库访问用户。
迁移范围分析
迁移范围分析是根据调研和收集资料内容进行分析和整理，形成原平台迁移范围说明书。迁移内容梳理和分析工作貌似可有可无，实则非常重要，通过许多实际的迁移实施项目，我们发现精确的范围分析非常重要。在范围分析阶段，哪怕是少分析了一张表或是一个视图，都要推进至最终的数据校验阶段才能被发现，这意味着必须有下一轮的迁移迭代，这个成本无疑是巨大的。
作业分析
通过作业依赖关系分析出原平台各层需迁移的作业范围清单。作业范围分析一般可以通过作业依赖血缘图，逆向分析出各层需迁移的相关作业。
脚本分析
由于作业配置与脚本有一定映射关系，所以可以根据前面步骤得到的需迁移作业范围清单，分析出需迁移的脚本范围清单。
模型分析
一般而言，由于各个脚本中使用的数据模型的方式是固定且有限的，所以可以通过关键字匹配识别出脚本中使用的所有数据模型。因此模型范围的分析是通过写脚本工具，实现对上一步骤得到的待迁移脚本范围清单中所有脚本的批量采集，并获得需迁移的模型范围清单。
但这种方式只能识别部分模型，也就是在脚本中有直接使用到的表和视图，至于这些表和视图是怎么加工出来的，脚本工具就没办法获取到。如果是物理表，它的数据血缘可能会体现在作业依赖上，当然也不一定完全准确。还有一些需要迁移的视图、物理表是依赖于其他视图、物理表生成的，这个依赖关系不会体现在作业依赖上，只体现在模型语句中，所以这需要在后续的转换后模型创建步骤中，逐步发现缺失模型，不断明确数据模型迁移内容。
初始化数据分析
初始化数据范围分析其实就是需迁移数据范围分析。这步可能会比较复杂，因为很多原平台负载太高，数据迁移速度不高，所以数据迁移范围需要尽可能的小，同时又要满足应用加工需求。也就是说要在满足应用加工需求的情况下，获取数据迁移范围的最小集。这就需要范围分析人员了解应用加工模型，以及应用加工对各个数据实体精确的使用范围，但通常迁移人员不是很了解应用加工，所以只能深入各个脚本，通过阅读代码去获取精确的数据迁移范围。
通过以上的范围分析，一般能获取需迁移的作业范围、脚本范围、模型范围和数据范围，但可能无法通过一次分析确定准确的迁移范围，大概率需要在后面的迁移过程中不断迭代和完善。范围分析阶段可能会出现的一些常见问题如下。作业依赖不能完全体现原平台实际的加工依赖，导致部分应该迁移的内容不能通过最开始的范围分析梳理出来，有些缺失的范围需在后续的测试、数据验证阶段发现。
除对应用加工模型有经验丰富人员外，初始化数据范围分析通常需要分析人员通过深入脚本阅读代码的方式来分析、确定初始化的数据范围，效率较低，且容易有遗漏、缺失。
迁移实施
模型迁移
模型迁移的“模型”指的是表、视图等结构。要实现整体迁移，首先要把模型迁移到湖仓平台中。在模型迁移范围分析中，我们已经讨论过如何分析出具体有哪些表或者视图，以及我们在迁移前对迁移范围分析准确性的预期。
批量模型转换
根据原平台和湖仓一体新平台的语法差异，通过DDL转换工具将旧数据库中的数据模型转化成新数据库的数据模型，生成相应的建表语句。就是在新数据库中有一套与旧数据库实现的功能一致的表和视图。
转换后模型创建
转换后模型创建通常需要耗费一定的时间去迭代才能最终将转换后的模型都创建成功。视图创建的时候，容易出现该视图所需要的其他视图或者物理表未迁移，而导致该视图创建不成功的情况。这就需要将该视图需要的其他视图或者物理表加入到迁移任务中，再重新梳理更新需要迁移的作业内容、脚本内容、模型内容和数据内容。更新完后，再将新分析并转换完后的模型再进行创建，若发现有模型缺失，则需要再更新各迁移范围，依此类推，不断地迭代更新迁移范围。
脚本空跑
脚本空跑也是验证数据模型迁移范围是否完备的重要一步，只有真正的脚本空跑过了，才能算是数据模型迁移范围的基本确定，即便最后数据验证时发现一些模型的缺失，一般也不会太多。
数据迁移
数据准备
数据迁移需要保证原平台中的数据被无损、快速的装载到湖仓一体平台中，因此我们需要开发数据导出和加载的迁移工具来完成原平台到新湖仓平台的数据迁移工作。
数据迁移前要对表进行梳理，根据表的存储更新策略进行分类。数据存储更新策略可以分为当前周期快照表、全部周期快照表、增量追加表、拉链表、变更日志表。当前周期快照表、全部周期快照表相对较小，采用全量数据抽取的方式；增量追加表、拉链表通常较大，采用分阶段抽取方式。
数据初始化
抽取前首先确定初始化切片日期，即以哪个业务日期作为初始化的切片日期。另外，要备份当前表，因为数据初始化是长期过程，当前表有时点问题，如果某张当前表没有及时备份，那么等当前表开始数据初始化迁移时，可能已经过了那个时点，那么里面的初始化数据就是错误的，所以当前表需要及时备份，初始化时从备份表迁移数据。
数据迁移
数据抽取分三个阶段，第一阶段，截止某一切片日期，完成增量追加表、拉链表数据抽取，通过数据初始化的方式用数据迁移工具，从原平台同步到湖仓平台；第二阶段补充抽取增量追加表、拉链表从上次截止时间点到今天的历史数据，抽取到最新状态，相当于追平原平台生产系统的最新数据；第三阶段接入增量数据到新系统，以满足新系统的ETL处理及应用访问。
数据验证
数据一致性校验是迁移过程中最耗时的一个环节，虽然可以采用人工批量的方式去校验，但也有必要打磨数据一致性校验工具或者借助数据同步工具中的自动数据校验功能，总之要关注和提升数据迁移的效率。数据迁移需要批量进行验证初始化结果、范围是否准确，主要是确认各张表的各个批次是否有丢失，每个批次数据量是否准确。
其他处理
针对拉链表要进行退链，由于初始化截面后的数据需要在初始化数据的基础上进行跑批加工，所以需要将已经闭链的截面数据进行退链处理。另外，初始化数据可能存在有空格等问题需要处理，为了保证数据加工的一致性，需要对迁移后的数据统一做去空格处理。
脚本迁移
脚本迁移在整个迁移中非常重要。脚本的迁移其实就是语法的迁移，相比数据校验，脚本迁移虽然不是耗时最长，但一定是最具技术挑战的。脚本迁移我们按照转换规则整理、工具转换、手工转换、空跑测试、带数测试、数据验证等六个主要步骤实施。
转换规则整理
脚本迁移过程中包含两部分内容。一部分是数据扫描、加载、数据校验、业务逻辑处理的脚本处理；另一部分是脚本中可能包含的对数据库的 INSERT，UPDATE 和DELETE 操作，所以对脚本的迁移称为 DML（Database Manipulation Language）迁移。
数据扫描加载的目的与 DML 用在处理数据仓库内部的转换和加载不同，数据扫描和加载是用于将外部数据源中的数据，如将业务数据库中的数据（如Oracle、MySQL中的数据）加载到湖仓平台的表中，即在 ETL 过程中的数据抽取过程。
假设数据库将数据按T+1的时间周期根据预定义的接口格式将数据导出到数据文件中。我们使用扫描程序定时扫描由业务数据库中发送的数据文件，并且扫描程序会将数据发送给调度工具，通过在自动化调度工具配置的每晚、每月或者在指定的时间驱动由数据文件到湖仓平台的数据加载。
由于原平台的 SQL 在某些细节上可能会和湖仓平台的 SQL 应用有细微的区别，因此我们需要对这些有变化的 SQL 进行改写，在SQL处理过程中主要有三类内容的需要处理：函数转换、事务处理、多表关联处理。
为了保证转换后 DML 脚本转换后的可用性和一致性，我们使用如下原则进行转换：• 保证原有业务逻辑、算法等功能的正确运行• DML脚本和其他程序流程尽少改变• DML脚本或其他文件尽量少进行修改• 转换过程可以模式化
工具转换
在原平台，尤其是传统数仓库各个数据层次之间的 ETL 过程很多是通过脚本来完成的，脚本在自动化调度工具的控制下来完成各数据层次之间的数据抽取、清理和转换。迁移实施团队需要制作脚本自动迁移工具，根据实际经验，脚本迁移工具都能实现90%以上的脚本自动迁移。
手工转换
自动化工具可能无法处理处理复杂的脚本逻辑或者语法间的差异，对于不能实现自动转换的部分，需要根据一定的规则人工转换。当然，手工转换也可能需要更多的时间和精力，容易出现错误，不易管理，这也是为什么在很多大型的迁移项目中自动脚本工具能够完成超过95%的脚本转换。
空跑测试
脚本迁移过程中进行空跑测试是为了在实际运行之前验证迁移后的脚本是否能够在新环境中正常运行。空跑测试是一种在模拟环境中运行脚本，但实际上不会产生实际影响的测试方式。
迁移到新环境后，可能存在语法差异、编程语言版本不同等问题。空跑测试可以帮助验证脚本是否符合新环境的语法和语义规则。同时， 空跑测试能够及早发现潜在的错误，如变量名拼写错误、函数调用问题等，从而减少在实际运行中可能遇到的问题。
带数测试
带数测试可以验证迁移后的脚本是否能够正确处理真实数据，执行期望的逻辑和操作。在带数测试中，可以发现在空跑测试中可能未暴露出的问题。这可能包括数据转换错误、数据格式问题、字段长度等。
数据验证
数据验证可以验证迁移后的脚本是否在处理数据时保持了数据的准确性，确保生成的结果与预期一致。检查迁移后的脚本是否正确地处理了所有数据记录，没有丢失或遗漏任何数据。
作业迁移
调度里最小的单位是作业(JOB)，作业迁移主要是将原本在原数据平台调度系统中的作业配置及作业参数迁移到湖仓一体平台目标调度系统中。作业的范围由第一阶段范围分析及后续迭代版本产生。作业的准确性需要由后续的跑批及数据准确性来验证。为了保证跑批的准确性，项目实施应保证调度组、频度、作业前置依赖等信息要与旧数据库调度完全一致。如果旧调度新增或者变更，需要同步新增或者变更到新的调度中。
应用迁移
应用的迁移其实质是将原平台应用中的标准扩展 SQL 转化成湖仓一体平台的目标SQL，同时还要处理原平台中的存储过程、触发器和用户自定义函数等。应用迁移需要设计开发文件输出功能，对接下游系统。同时适配原有应用接口，使得应用通过JDBC/ODBC接口直接访问湖仓平台。典型的数据应用包括报表、即席查询、数据分析、机器学习等。
任务核对
核对标任务的作业、脚本、报表等任务，单元测试和集成测试过程中进行多维度，多组合条件的任务核对测试。
性能优化
开发阶段针对数据库级优化、DDL 表级优化，在上线后对性较慢 SQL 进行优化。
迁移割接
为了保证迁移实施过程中业务的稳定性和平滑过渡，整个数据迁移实施会经过三个阶段的推进，这三个阶段的划分在数据迁移的部分也已经讨论过。第一个阶段是首先确定时间窗口，完成全量表迁移，之后完成历史数据迁移；第二阶段是数据迁移同步完成后，通过任务追平迁移数据窗口后产生的数据，系统进入并行期，验证迁移后数据的正确及功能的适配；第三阶段是新系统正式上线，原平台下线，实现湖仓平台及应用的完整切换，最终关闭原平台流程，完成整个平台的迁移。下图分别为各阶段过程。
