加拿大大型铁路用Databricks Genie Code将管道创建自动化率提至90%

加拿大最大的铁路网络之一，横跨加拿大并延伸至美国，总里程约2万英里，每年支持超过2500亿加元的货物运输。对于如此规模的组织而言，对已有数十年历史的数据资产进行现代化改造，绝非一次只处理一张表那么简单。

面对数百条正在运行的管道、对实时分析和AI日益增长的需求，以及遗留系统中嵌入的深厚机构知识，公司需要一种能够扩展现代化改造规模的方式，而不必同步增加手动开发的工作量。

利用 Databricks Genie Code、Unity Catalog、自定义Agent Skills以及基于 Databricks Apps 构建的Streamlit应用，团队将管道开发本身转化为可重复的工厂流程。简短的YAML提示现在就能生成可直接用于生产的摄取代码，这些代码基于实时目录元数据，并默认符合企业规范，包括表定义、历史加载逻辑、流式摄取逻辑、增量合并逻辑和自动化测试。

结果是新表摄取实现了超过90%的自动化，管道交付从数天压缩至数分钟，现代化计划得以随业务扩展，而不再受限于开发人员的带宽。

在企业规模下对复杂数据资产进行现代化改造

与许多大型企业一样，公司在数十年间，在大型机系统、遗留数据仓库、企业ETL平台和专用设备上构建了其分析资产。随着公司转向现代湖仓架构，挑战不仅仅是迁移本身：团队需要在保留大型遗留足迹中关键业务逻辑的同时，简化并标准化管道的构建方式。

在自动化之前，为单个表构建管道需要多日努力。团队必须检查源模式，在源到目标映射电子表格中定义业务逻辑，构建历史加载和流式摄取逻辑，编写增量合并管道，实现下游转换，并为模式演变、列重命名、类型转换和软删除等情况创建测试覆盖。

这项工作对于一张表来说尚可管理；但对于数百张表则难以应付。真正的瓶颈在于，将遗留逻辑重复且一致地转化为湖仓管道所需的手动工作量。

公司需要现代化的不仅仅是其管道，更是构建数百条管道的过程本身。

Databricks 作为现代化改造引擎

解决方案围绕两个协同工作的核心能力展开：Genie Code配合自定义Agent Skills生成可直接用于生产的摄取工件，以及用于将源字段映射到目标湖仓表并生成转换逻辑的Databricks App。

两者结合，在Databricks内部创建了一条从元数据发现到代码生成的端到端工作流。Genie Code充当自主AI伙伴，而自定义Agent Skill则编码了公司的摄取模式和合并逻辑。Unity Catalog提供跨原始层、历史层和预备层的模式检查，而Databricks Apps支持源到目标的映射体验。生成的管道使用PySpark、Spark SQL和Delta Lake，并设计为通过Lakeflow Jobs运行。

这种方法使团队能够将自己的摄取标准和管道规范扩展至Genie Code。审计规范、去重逻辑、变更序列合并保护、软删除对账以及测试模式直接嵌入到生成过程中，而不是依赖每个开发人员手动应用。

在概率性工作流中增加确定性是关键。我们选择自动化那些我们确信正确的内容，并将解释层保留为可选项。LLM在思考过程中提供帮助。框架确保证明能力内建。——Dinesh Chandrasekaran，加拿大领先运输与物流公司数据与AI负责人

这一理念贯穿了整个方法的核心：在需要推理和发现的地方使用AI，在一致性和可重复性至关重要的地方使用严格模式。

从简短提示到可直接用于生产的管道

开发人员从紧凑的YAML提示开始。在最简单的情况下，该提示可以小到只有两行用于原始摄取。对于完整的表管道，它包含核心输入，如源和目标表名、主键、去重逻辑和刷新行为。

随后，Genie Code遵循结构化工作流。它解析并验证提示，通过Unity Catalog元数据发现历史层和可信层模式，自动将列与源匹配，识别类型转换和重命名需求，解析转换模式，使用公司标准模式生成请求的工件，并根据要求的企业不变量验证每个输出。这些不变量包括主键覆盖、审计列放置、变更序列保护的合并、考虑REFRESH的去重以及测试套件覆盖。

根据模式，该工作流支持单表、单次请求中的多表，或由存储在Unity Catalog卷中的CSV或Excel文件驱动的批量运行。实践中，该工作流可生成六项可直接用于生产的输出：DDL、历史加载、原始流式摄取、首次增量合并、持续增量合并以及自动化测试套件。

每个生成的笔记本都遵循相同的企业规范，涉及审计列、去重、感知变更序列的合并和软删除对账。

Agent Skills使企业标准可重用

该架构的一个关键部分是自定义Agent Skill，它为Genie Code提供了一种可重用的方式，以应用公司的摄取标准、命名规范和管道模式。

该技能与其他代码库一样进行版本管理。它包含一个 SKILL.md 入口点，以及用于目录发现、约定、原始摄取、历史加载、增量合并和测试生成的辅助模式文件。这种结构使公司能够集中维护其生成逻辑，同时通过 Genie Code 向开发人员提供该逻辑。

该技能是一个上传到workspace/.assistant/skills/lakehouse-ingestion/。

它包含一个SKILL.md入口点加上七个模式文件，每种工件类型一个：

该SKILL.md的前置元数据是 Genie Code 决定何时加载该技能的依据：

团队没有将标准记录在一个地方并要求每个开发人员手动解读，而是将这些标准编码到工作流本身中。代理处理上下文收集和编排。该技能确保生成的工件每次都遵循相同的模式。

开发人员在 Genie Code 会话中通过简短的 YAML 提示开始代码生成。仅原始摄取最少需要两行。完整管道需要六行。

最小示例，仅生成原始摄取笔记本：

完整示例，为一个表生成完整的六工件管道：

六个工件在运行时按此顺序执行：

基于 Unity Catalog，受默认

另一个关键设计原则是将代码生成锚定在实时元数据上，而不是静态假设上。

Genie Code 使用 Unity Catalog 实时检查原始、历史和预处理表中的模式。这种元数据驱动的方法消除了对单独发现层的需求，并为代理提供了在生成代码之前生成映射、推断转换和验证必填字段所需的上下文。

同样重要的是，所有生成的工件都保留在 Databricks 工作区内，并遵循与数据平台其余部分相同的治理模型。访问控制、元数据策略和修订历史保持为 Databricks 原生功能。元数据锚定和受治理执行的结合帮助团队弥补了企业 AI 采用中的常见差距：在加快速度的同时不引入不一致或削弱控制。

在关键环节引入人工审查

公司并未将此事视为完全无人参与的生成问题。在生成代码之前，数据设计师使用 Databricks 应用来检查遗留源系统中的字段应如何映射到目标湖仓表。

这一步称为源到目标映射，捕获了不应盲目猜测或自动化的业务逻辑。该应用使用基于 Streamlit 的 Databricks Apps 构建，可扫描源系统表，预填充列映射，并允许数据设计师在浏览器中审查和优化转换逻辑。

每次编辑都记录在变更日志中，最终映射可以导出并用作生成工作流的输入。这使得流程更快，同时没有从工作流中仍需业务解读的环节中移除专家审查。数据设计师可以专注于转换意图和业务逻辑，而 Genie Code 和生成框架则处理可重复的实现模式。

设计上具有确定性

架构中最重要的决策之一是保持推理层智能且自适应，同时使生成的管道代码具有确定性。

Genie Code 处理工作流中受益于代理推理的部分：解释提示、发现模式、选择正确的生成路径以及拼接正确的操作序列。但生成的 PySpark 代码本身是规则驱动且可重现的。合并语句、去重窗口、审计列放置、类型转换和测试模式均通过显式模板和不变量定义。

对公司而言，这至关重要。在生产管道生成中，合并逻辑、去重窗口或审计列放置的微小变化可能造成下游数据质量风险。确定性输出使系统足够可信以在企业规模下使用，并且足够一致以保持来之不易的工程标准。

成果：从开发者生产力到现代化吞吐量

影响立竿见影且实际：

• 新表摄取的自动化率超过 90% 进入 Databricks Lakehouse
• 管道开发时间从每个表数天缩短至数分钟
• 支持单件、多件和批量生成模式，适用于临时请求、批量迁移和冲刺规模现代化工作
• 企业标准一致应用于每个生成的工件，无需手动合规审查

改变的不仅仅是开发者的生产力。公司提高了现代化项目本身的吞吐量。

团队没有将每次表迁移视为定制工程项目，而是创建了一个可重复的系统，用于大规模将遗留资产转换为受治理的湖仓管道。

展望未来

公司认为这是更广泛现代化自动化的基础。团队目前正在探索更模块化的技能架构，涵盖编排、转换、业务逻辑和可观测性；将发现范围从 Unity Catalog 扩展到更广泛的企业数据目录；评估将遗留 DataStage、COBOL 和存储过程逻辑 AI 辅助转换为 PySpark；并利用新兴的后台代理能力支持日常管道分流、DBR 升级和模式不匹配修复。

长期目标不仅仅是更快的代码生成。它是创建一个能够持续扩展的现代化模型，即使遗留复杂性、业务需求和平台范围持续增长。