Databricks 实时能源交易与分析方案：用统一数据底座打通交易台与模型流水线

为什么实时能源交易需要的不只是更快的数据？

能源交易台所处的市场环境变化迅速，决策以毫秒计。有两个变化让这件事更难：价格波动性上升，以及欧盟日前电力市场从小时级交易时段转向15分钟级交易时段。15分钟市场时间单位是单一日前耦合（SDAC）的一部分，该系统连接欧盟各国的日前电力市场。这使得每小时的市场时段数量增至四倍，记录、订单和风险重算的数据量也随之增加。要保持这些计算准确，就需要最新的数据——这直接指向数据的存储和治理方式，而不仅仅是数据到达的速度。

对交易台而言，过期数据不只是不便。它可能使风险控制反映市场的较早状态，导致错失日内行情，并使交易台限额与当前持仓不同步。

许多组织的应对方式是采用两套系统。一套运营系统支持实时交易台和毫秒级交易。一套独立的分析系统支持策略回测、机器学习和监管报告。这种拆分匹配了两种不同的工作负载，但带来了四个反复出现的问题：

两个版本的真相
风险控制中的新鲜度差距
重复的治理与血缘
不同系统之间的多条同步管道

机器学习又增加了一层依赖。模型需要历史数据进行训练，但其输出必须能在实时交易工作流中使用。在独立系统之间迁移模型和数据，会给本已时间敏感的过程增加复杂性。替代方案是一个统一的数据、分析和AI平台——Real-Time Mode以毫秒级延迟流式写入，由Lakebase Postgres持有就绪数据——这样实时交易台和模型管道都从同一来源取数，无需额外的传输步骤。

运营和分析工作负载如何在Databricks上协同运行？

运营和分析工作负载通过共享一个数据基础来协同运行。下面由Databricks解决方案架构师Victoria Sicking介绍、在'在Databricks中运行实时能源交易、风险和分析'中描述的解决方案，在Databricks Data + AI平台上组合了六个组件，关键设计选择是没有任何组件维护自己独立的数据副本。所有组件都基于Spark Structured Streaming Real-Time Mode写入Lakebase和湖仓的数据工作。

Spark Structured Streaming Real-Time Mode，用于毫秒级延迟的持续事件处理
Lakebase，面向应用和代理的无服务器Postgres，用作运营数据库
Databricks Apps，用于实时交易界面。
机器学习模型，用于实时价格预测和交易信号。
Genie One，用于历史分析。
Unity Catalog，用于整个工作流的治理。

Spark Structured Streaming Real-Time Mode接收市场数据并将其流式写入Lakebase，此处用作运营（OLTP）数据库，支持毫秒级读取、事务和upsert。随后同一数据可支持构建在湖仓之上的分析工作负载。

团队不再需要协调并行管道，一条用于实时交易台，另一条用于回测和报告。通过为市场数据和持仓数据创建单一摄取路径进入数据资产，此前耗费在核对与协调上的时间得以释放。Unity Catalog——Databricks 用于权限、血缘和审计的治理层——将这一治理应用于应用、商业智能和机器学习工作负载，因此它们无需在多个系统中独立配置。

Databricks Apps 中的实时能源交易台是什么样子？

它看起来像一个单一应用，展示价格、持仓、损益（P&L）和风险，全部随市场变动实时更新。实时体验构建在 Databricks Apps 之上——这是在平台上构建和托管数据应用（例如实时交易界面）的方式——将交易台监控市场和应对变化条件所需的一切汇集在一起，直接由 Lakebase 提供服务，因此交易台始终读取的是为分析工作负载提供数据的同一份受治理数据，无需单独的操作副本。

该演示展示了布伦特原油、德国和法国电力现货、欧元兑美元汇率、欧盟碳排放配额（EUAs）和 TTF 天然气的价格。

风险在同一工作流中对照交易台的限额进行监控。当某项指标接近限额时，应用会发出风险警报，使交易台能够看到变化并立即响应。这取代了此前从较早数据快照计算风险的夜间批处理流程。

该应用并非与数据平台脱节的报告界面。Lakebase 提供应用背后的操作层，流式管道则保持信息实时更新。

如何从同一份数据生成交易信号？

在支持实时交易台的同一份受治理数据上训练机器学习模型，使用 MLflow 跟踪其开发和血缘，并通过 Databricks Model Serving 部署已批准的版本。它们的输出随后可以直接在应用中呈现。

能源交易团队需要能够预判风险并识别潜在交易信号的模型，而在同一份受治理的统一数据副本上运行一切，消除了训练系统与实时系统之间的交接——模型看到的正是交易台所看到的。

该演示展示了一个可贡献于交易信号的实时价格预测。用于训练模型的数据与消费其输出的工作流之间的路径变得更短。机器学习成为端到端交易工作流的一部分，而不是位于实时栈和分析栈之间的独立系统。

同一份受治理数据还可以支持风险分析和模型开发。操作工作负载和分析工作负载保持连接，团队无需事后核对不同版本的数据。

分析师如何在不增加数据副本的情况下获得历史视图？

分析师使用嵌入式仪表板和 Genie One，二者均构建在与实时应用相同的数据基础之上。嵌入式仪表板呈现历史交易数据，包括总交易笔数、交易量以及交易员之间的对比。

如需更深入的分析，分析师可以使用 SQL、Python 或 Spark。他们也可以使用 Genie One——Databricks 用于对受治理数据提问的自然语言界面——而无需自己编写查询。在演示中，分析师要求 Genie One 按交易数量找出前五大交易对手，并比较每个对手的总买入量与卖出量。

Genie One 在 Databricks 工作区内运行，利用可用的数据上下文和已定义的语义来作答。分析师可以从提供固定洞察的仪表板视图转向对数据的定制化分析，同时仍处于同一个受治理的环境中。统一的数据副本意味着实时交易台与分析后台的结果一致。

从市场数据源到受治理洞察的架构是怎样的？

数据从市场数据源流出，经过流式处理和 Lakebase，到达应用、分析和机器学习，全程处于 Unity Catalog 治理之下。由于 Unity Catalog 覆盖每个组件，适用于实时交易台的权限、血缘和审计也同样适用于仪表板、Genie One 和机器学习——只需配置一次，无需在每个系统中重复配置。步骤如下：

市场数据源（例如 ICE、APEX 或 Kafka 流）提供源事件。
Spark Structured Streaming 实时模式持续处理传入的数据。
Lakebase 作为托管 Postgres 接收端和实时交易台的运营数据库。
希望构建分析层并运行历史分析或回测的团队，现在可以在 Lakehouse 中基于这些数据构建。
Databricks Apps 使用运营数据来呈现实时价格、头寸、P&L、风险、警报和模型输出。
嵌入式仪表板和 Genie One 支持历史分析以及关于交易活动的问题。
机器学习模型使用相同的数据来生成价格预测和交易信号。
Unity Catalog 在应用、分析和机器学习工作流中实施治理。

实时交易台、分析和机器学习工作负载并不是需要反复移动数据的独立目的地。它们是以不同方式使用同一份受治理数据。

团队在评估这一架构时应考虑什么？

问题在于，运营和分析需求是否必须由彼此分离的系统来满足，而这些系统拥有各自的数据副本、治理模型和同步逻辑。它们确实有不同的需求，但一个平台可以同时服务两者，并且整合到一份受治理的数据副本上意味着交易台、风险模型和报告层永远不会彼此不同步。

当这些工作负载运行在分离的系统上时，风险控制可能依赖批量数据，模型可能基于与实时系统不匹配的信息进行训练，并且治理、血缘和同步管道必须维护不止一次。

Databricks 能源交易解决方案将这些能力汇聚在一个受治理的数据基础上。借助这一设置，团队可以在市场变动时评估风险，同时将同一份受治理数据用于 P&L、敞口、回测、机器学习、仪表板和自然语言分析。

如需了解更多入门信息，请访问：

常见问题

分离的系统会给能源交易带来哪些问题？

分离的系统可能造成两个版本的真相、风险控制中的新鲜度缺口、重复的治理与血缘、额外的维护工作，以及系统之间额外的同步管道。当模型在一个系统上训练却必须在另一个系统上运行时，机器学习也变得更难管理。维护一份受治理的统一数据副本，并配以单一的控制集，可以消除其中大部分成本。

为什么要将运营和分析工作负载整合到一个平台上进行能源交易？

能源交易团队可以在 Databricks 中基于一份受治理的统一数据副本运行实时交易台、风险、机器学习和历史分析。Spark Structured Streaming 实时模式、Lakebase、Databricks Apps 和 Unity Catalog 取代了第二个系统和重复的控制。

Lakebase 在能源交易中扮演什么角色？

Lakebase 是 Databricks 数据 + AI 平台原生的全托管 Postgres 数据库，在此用作运营（OLTP）数据库，支持毫秒级读取、事务和 upsert。由于它与湖仓位于同一平台内，它将运营数据与分析工作负载连接在一份受治理的统一数据副本上，而无需在平台之外单独使用一个数据库。

交易员如何随着市场状况变化监控风险？

基于 Databricks Apps 构建的实时交易应用——这是在平台上构建和托管数据应用（例如实时交易界面）的方式——可以显示价格、头寸、损益和风险的最新更新。当指标接近交易台限额时触发风险警报，因此交易员可以针对当前状况做出响应，而不是仅依赖批量计算。

Unity Catalog 如何治理数据？

Unity Catalog 是 Databricks 的治理层，负责权限、血缘和审计，在运营应用、分析和机器学习工作流之间提供统一的治理层。它端到端地维护集中式权限、血缘和审计，因此团队只需为单一数据副本配置一次控制，而无需为每个系统分别复制治理。