Constellation 如何在 Databricks 上构建受治理的数据基础

Constellation 运营着美国最大的核电机组群。对他们而言，为 AI 做准备最困难的部分之一并不是选择模型，而是就数据的含义达成一致。Constellation 的团队正在 Databricks 上构建一个受治理的企业数据平台（EDP），以使数据在整个业务范围内保持一致且可用，其方法为其他企业提供了一条切实可行的路线图。

Constellation 是谁

Constellation 是美国最大的清洁可靠能源生产商，其发电能力相当于 2700 万户家庭的用电需求，并拥有约 250 万个零售客户账户。正是这种运营广度和客户关系，使得共享定义和治理对其数据工作至关重要。

Constellation 从资产管理、供应链、商业与交易系统以及整个机组的运营中收集数据。这些数据为从近实时市场模型到核遥测的一切提供支撑。在一个安全与可靠性至上的业务中，把定义和治理做对至关重要。这种风险特征驱动了后续的每一个架构选择。

问题：高质量数据，却没有共享语义

Constellation 各团队为自身工作构建了强大的数据能力。然而，跨这些团队的问题仍然需要额外努力来连接信息，并调和数据定义上的差异。数据分散在数十个地方，没有共享的语义层来定义其跨领域的含义。

Constellation 面临着一个许多组织仍在挣扎的问题：一个简单的问题却没有单一答案：“我们有多少客户？”零售业务以计费电表为准，批发业务以交易对手为准，而 CRM 以账户或用户为准。三个正确答案，三种不同含义。随着 Constellation 通过收购实现增长，这个问题只会更加复杂，包括 2026 年收购的 Calpine，后者在 22 个州拥有 79 座电厂和 27 GW 的装机容量。这是一个完全独立的堆栈，有自己的定义、数据仓库和建模惯例。EDP 突然不得不吸收一个规模大致与 Constellation 自身相当的实体。在 Databricks 上开发 EDP 的过程中，为数据赋予含义并实施治理，正是 Constellation 正在进行的转变。

基础：Databricks 上的企业数据平台

Constellation 的答案是构建在 Databricks 上的受治理 EDP。 EDP 是共享基础，连接了此前孤立的系统，并为业务提供对其数据的单一共享理解。这是从众多互不相连但构建良好的系统，向一个数据在整个企业内承载共享含义的受治理基础的有意转变。

平台决策本身只花了几周时间。Constellation 选择 Databricks，是因为它为他们提供了实验、成长和逐步成熟的空间，同样重要的是，因为它能与现有架构互操作，而不是强制推倒重来。三大架构支柱脱颖而出：

• 共享语义即一致性语义。Constellation 的 EDP 团队没有强行让每个领域套用同一定义，而是与业务负责人共同定义受治理的一致性实体——就“客户”在零售、批发、燃气和 CRM 中的含义达成一致——并在整个企业范围内复制这些定义。在此基础上，Constellation 构建了一个语义知识层，用于映射业务关系——客户、合同、资产以及它们如何跨领域关联。
  该团队采用 Data Vault 作为建模方法，并有选择地将其用于需要随系统变化而灵活调整的关键、可复用实体。并非每个数据集都会采用 Data Vault 建模。建模选择是经过深思熟虑的，取决于该实体是否会被复用、审计或随时间演进。
• 治理是所有权模型，而不仅仅是访问控制。Constellation 的一个主要决策因素是选择一项超越传统访问控制、能向利益相关者传达语义含义的服务。明确这一标准后，Unity Catalog 成为显而易见的选择。Unity Catalog 提供血缘、细粒度访问和单一权限模型。Constellation 超越了技术层面，回答了其他平台难以应对的问题：谁拥有语义？借助 Unity Catalog 的指标视图，这变得更加容易。不同的数据领域需要不同的访问和治理控制。Constellation 的团队在设计平台时支持这些需求，同时将新的用例引入基础平台。建立内部审批和治理机制成为信任的锚点。
• 一个受治理基础平台上的多工作区。相同的受治理数据集呈现在不同的工作区中，业务语义一次定义、多次使用。

对 Constellation 而言，Databricks 同时支持数据工程和治理，为团队构建 AI 提供了受控环境。

基于同一基础平台构建的三个示例用例：

在同一受治理的基础平台上，三个早期用例展示了在业务中截然不同的领域里可以实现什么。

1. 核工程助手

Constellation 正在开发一个助手，使用 Databricks Genie 构建，并通过 Unity Catalog 进行治理，帮助工程团队更轻松地查找和使用经批准的技术信息，减少回答复杂问题所需的工作量。

2. 停运规划：计划性核维护管理

计划性停运是 Constellation 运营中最复杂的操作之一。停运用于换料、大修、监管检查和设备作业。每次停运都会在紧张的时间安排下，将大量人员和许多工作订单集中到一个站点。协调这些工作需要来自不同系统的调度、工作执行和资产健康数据。该团队正在将这些数据汇集到 Databricks 中，帮助规划人员分析日程和协调工作，决策仍由停运团队负责。

3. 销售智能：机会优先级排序与最佳下一步行动

在销售领域，整合相关的客户与商业信息有助于团队为对话做好准备并发现增长机会。该团队正在 Databricks 上开发 AI 能力，使这些信息更加一致、易于获取且可付诸行动——支持诸如优先处理高价值机会和推荐最佳下一步行动等成果。所有这些都构建在 Databricks 中同一受治理的数据基础之上，并配有适当的数据防护措施。

主要要点

Constellation 的经验凸显出，企业数据平台不仅关乎技术，同样关乎含义与治理。其团队正在构建所需的定义、控制和可复用的数据基础，以支持业务不同部门开展有用的分析与 AI。借助 Unity Catalog，Databricks 使数据对业务用户而言可信且易于发现。

这一受治理的基础还使数据科学家能够利用 Databricks 构建机器学习和代理式 AI 解决方案，包括 Genie One 和 Genie Agents。该团队在开发销售、维护规划和工程支持等用例时正在使用这些能力。

展望未来

Constellation 正在探索 Genie Ontology——一个自学习知识图谱，可添加业务上下文——以及 Unity Catalog Pages，后者在 Unity Catalog 中集中管理业务定义。这些能力共同扩展了语义层，使数据更有意义、更一致且更易于使用。

在 Constellation 负责人、高级副总裁兼 CIO Jay Cavalcanto 和 IT 业务管理办公室副总裁 Vineeth Vijaykumar 撰写的博客文章中了解更多关于他们的故事。

观看Constellation 在 Databricks Data + AI Summit 上的演讲（第 56.23 分钟处）