从传统数据仓库架构化迁移到云

企业数据的遗留挑战

几十年来，企业数据平台建立在 Teradata、Oracle 等遗留系统之上。它们曾是分析业务的支柱，提供了可靠性和可扩展性，但随着时间的推移，它们变得僵化、成本高昂且难以演进。如今，许多此类平台承载着 PB 级的数据，支持数千份报告，并处于数百个依赖流程的中心。曾经的赋能者已成为瓶颈。

挑战不仅在于技术。多年来，企业积累了成千上万个嵌入这些系统的存储过程、ETL 管道和报告脚本。业务规则和定义通常硬编码在 SQL、报告层或应用程序逻辑中。迁移到云不能被视为简单的复制粘贴工作。如果没有深思熟虑的策略，公司可能会在现代平台上重蹈过去的低效和不一致的覆辙。

数据与分析环境的复杂性

大多数企业并非只运行一个数据仓库。它们运营着复杂的生态系统，其中包含分布在财务、风险、人力资源、市场营销和运营等多个领域的多个数据仓库、数据集市和 BI 工具。

跨这些环境的谱系分析通常会揭示一个令人惊讶的事实：只有一小部分可用数据被真正使用。在我参与过的大型项目中，大约 25% 的数据元素持续为业务关键报告提供支持，而其余部分要么是冗余的，要么是遗留残余。这一发现塑造了我们的方法。重点不是将所有内容都迁移到云，而是关注对业务最重要的数据子集。

迁移技术：选择正确路径

当企业面临多重遗留数据仓库和业务分析师拥有的不同分析数据资产模型的极端复杂性时，决定向基于云的数据系统进行转型和迁移的决策就变得具有挑战性。这两种方案都具有挑战性，因此没有放之四海而皆准的解决方案，在决策时需要仔细考虑，因为这涉及数百万美元和数年的关键工作。

直接迁移 (Lift-and-Shift)

将数据直接迁移到云端涉及将现有数据资产移动到云基础设施，同时对其结构和功能进行最小化更改。这意味着所有表名、列名和命名规则都将保持不变，分析师迁移报告时无需大幅更改代码逻辑。

适用直接迁移的场景：

• 数据系统和分析资产不太复杂，分析团队较少依赖工程支持时，此策略效果良好。
• 如果业务稳定，看不到扩展需求或可能不会增长到引入新的复杂性，直接迁移也有帮助。
• 业务团队展现出强大的技术能力，能够快速适应新环境且更加敏捷。
• 由于数据中心关闭或许可证到期等因素，时间限制要求更快的过渡。
• 遗留系统中的数据系统缺陷最少，并对迁移数据的质量有信心。

即使数据是按原样迁移的，成功也取决于信任。这需要严格的验证。在企业规模上，迁移通常涉及数十亿行数据，因此手动检查是不可行的。根据我在一家大型金融科技公司的经验，使用基于 Python 的自动化框架来验证每条记录。在源系统（Teradata 或 Oracle）和目标系统（Snowflake）上生成哈希键以确认一致性。模式一致性检查验证列数、数据类型和空值阈值。聚合比较、记录计数、总和及平均值可以捕捉到可能被遗漏的不匹配情况。所有这些都嵌入到由 Airflow 编排的 CI/CD 管道中，确保对账作为加载过程的一部分实现自动化。

现代化/转型

转型涉及重新构想和重构数据生态系统的整个堆栈，从而形成一个更精简、更集成的数据和分析基础设施。重新架构将导致更新的、更精炼的表结构和度量/列名，这将需要业务团队更多的培训和知识才能采用。这种更全面的策略通常能带来更好的长期效果。

适用转型的场景：

• 如果业务经历了显著增长并需要随着需求的增长而扩展，则有必要对数据系统进行重新构想和重构。
• 复杂的遗留数据系统在变更管理方面造成了重大困难，业务用户通常更依赖工程师进行修复。经过翻新的现代架构可以推动更高的自助服务分析水平。
• 业务团队更专注于分析而非数据管理，并需要更简单的架构来大规模驱动分析。
• 致力于推进 AI 并需要更以企业为中心的架构的公司，可以通过转型获得更强大的集中治理和更好的数据质量。
• 在数据定义和指标对齐方面遇到问题，并需要更集中的方法来提高效率和规模的企业，可以通过转型获得显著收益。

在一家大型金融公司，通过实施奖牌架构，明确定义了用于数据摄取（青铜层）、最小化企业整合（白银层）和业务语义（黄金层）的三个数据层，从而构建了一个服务于高级分析和 AI 的现代数据仓库。

青铜层构成第一层，包含从源系统通过变更数据捕获 (CDC) 摄取的所有原始数据，此处的数据模型遵循源中心化模型。这是全部的数据捕获层，将形成企业的数据湖。

在白银层，我们实现了事实表和维度模型。事实表存储业务事件，如贷款、付款或客户互动。维度表标准化了实体，如客户、产品、地区和渠道。这种集中化的业务上下文消除了部门间的不一致，确保财务、风险和市场营销基于相同的“客户”或“贷款产品”定义开展工作。

黄金层围绕业务 KPI 进行精心设计。这些数据集仅包含来自青铜层所有数据元素中关键的 25-30%，并直接与净新增客户、拖欠率、流失率和获客成本等指标挂钩。重要的是，报告工具不再包含嵌入式业务逻辑。仪表板和报告直接消费黄金层数据，确保了整个企业的一致性。

采用过程需要广泛的业务测试。黄金数据集通过结构化的用户验收测试，分析师将其与遗留报告进行核对。这个过程并不快；许多 KPI 多年来在各个团队中的定义都不同，但这建立了信任。到切换时，利益相关者已经签署并拥有了这些定义。

工具选择很重要。引入了 dbt，将转换模块化为代码，而不是维护冗长、脆弱的 SQL 脚本。Great Expectations 提供了自动化的质量检查，比手动对账更能有效扩展。像 Collibra 和 Alation 这样的治理目录早期就被集成，以记录跨数百太字节数据和数千份报告的谱系和定义。在这些工具上的前期投入减缓了早期进展，但在可维护性和透明度方面获得了回报。

混合路径

大多数企业采用混合方法。稳定的、受监管的工作负载通常保持直接迁移，其中连续性比重新发明更重要。战略性的、以增长为重点的工作负载，如客户分析、贷款和劳动力洞察，则受益于现代化，因为治理、可扩展性和业务对齐最为重要。这种平衡使企业能够在建立长期分析基础的同时，实现短期收益。

执行：一场马拉松，而非冲刺

企业迁移是漫长的旅程，而非短期项目。此类项目通常持续 18 到 24 个月，覆盖数百太字节的数据，涉及数十个业务领域。单一的切换风险太大，而无休止的试点则会浪费资源。分阶段执行是唯一可持续的方法。

优先处理高价值领域以展示进展。在验证完成之前，遗留系统和云系统通常并行运行。自动化验证、DevOps 管道和 AI 辅助的 SQL 转换加速了进展。为避免倦怠，团队结构由与业务用户密切合作的全职员工和提供技术规模的管理服务混合组成。

切换后的稳定与迁移本身同样重要。需要六到十二个月的持续资金用于监控、微调和采用。过早削减资金的团队通常会失去对平台的信任，而那些持续投入的团队则会看到长期的成功。

治理必不可少

没有治理的迁移是不完整的。将数据迁移到云端而不解决谱系、所有权和质量问题，只是将问题从一个系统转移到另一个系统。

治理必须从一开始就嵌入其中。元数据目录跟踪谱系和所有权。自动化验证确保每个阶段的质量，而不仅仅是在切换时。基于角色的访问控制、加密和掩码强制执行合规性。与黄金数据集绑定的业务术语表确保了客户流失或收入等指标的定义唯一且随处可信。

治理不是一次性活动。它必须随着新领域的迁移和新业务需求的产生而演进。将治理视为持续改进的循环，是技术迁移与真正转型之间的区别。

挑战与经验教训

没有任何迁移项目会一帆风顺。反复出现了几个挑战。

• 低估用户验收测试工作量：业务主导的测试通常比计划花费更长时间。即使数据集在技术上是正确的，跨部门协调定义也需要时间和对话。建立一致性需要研讨会和协调，而不仅仅是技术修复。
• 对变革的抗拒：过去在 SQL 或报告中嵌入逻辑的分析师最初抵触黄金数据集。他们感觉灵活性降低了。只有当价值被证明时，采用率才有所提高：核对时间缩短了，重复报告被淘汰了，高管可以依赖单一版本的事实。
• 管理范围：利益相关者常常将迁移视为一次修复所有问题的机会。如果没有重点，项目就有可能变得难以管理。优先处理最关键的数据元素保持了范围的现实性。

主要的经验教训是，仅靠技术是不够的。业务参与度、采用策略和治理成熟度与架构和管道同等重要。在这些领域同等投入的项目获得了更强的信任和更快的采用。

结论

现代云数据平台在许多方面优于遗留的本地系统。迁移不仅仅是将模式从 Teradata 或 Oracle 复制到 Snowflake。它是在为连续性而进行的直接迁移和为可扩展性而进行的现代化之间做出深思熟虑的选择，并以严谨的态度执行。验证框架、奖牌分层、事实和维度建模、精心设计的黄金数据集以及嵌入式治理提供了基础。

以此方式处理迁移的企业构建的平台是可信的、可持续的，并能够支持长期竞争力。

从业者的要点

成功的迁移不在于更快地移动数据，而在于更智能地移动数据。首先识别真正被使用的数据集，通过奖牌框架对所有迁移进行分层，使用自动化验证每一步，并从第一天起就嵌入治理。最重要的是，通过用户验收测试和 KPI 的明确所有权，让业务用户保持参与。将技术执行与业务协调相结合的项目能够实现采用、信任和持久的价值。