Real-time energy trading and analytics on Databricks

Databricks 上的实时能源交易与分析 | Databricks 博客

跳至主要内容

行业

2026年10月23日

Databricks 上的实时能源交易与分析

了解 Databricks 如何通过统一平台和治理模型，将实时能源交易、风险监控、机器学习和历史分析整合在一起。

作者：Victoria Sicking 和 Jack Yallop

摘要

• 能源交易团队通常为实时交易和分析运行独立系统，导致风险数据过时、治理重复和同步开销。

• Databricks 在单一平台上实现这一目标。Spark Structured Streaming Real-Time Mode 将市场数据流式传输到 Lakebase（一种面向应用和代理的无服务器 Postgres），这些数据为实时交易应用、机器学习模型、仪表板和 Genie One（一种自然语言查询工具）提供支持。

• Unity Catalog（Databricks 的治理层）在单一位置统一管理所有内容。权限、血缘关系和审计只需设置一次，而非为每个系统单独配置。

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

能源交易部门在市场条件快速变化的环境中运作，决策以毫秒为单位。两个变化使这一挑战更加复杂：价格波动性增加，以及欧盟日前电力市场从每小时交易转向15分钟交易间隔。15分钟的市场时间单位是单日日前耦合（SDAC）系统的一部分，该系统连接欧盟各国日前电力市场。这导致每小时市场周期数量增加四倍，记录、订单和风险重新计算的体积也随之增加。保持这些计算的准确性需要实时数据——这直接指向数据的存储和治理方式，而不仅仅是数据到达的速度。

过时的数据对交易部门而言不仅是不便，还可能导致风险控制反映市场早期状态、错失日内交易机会，并使部门限额与当前持仓脱节。

许多组织采用双系统架构应对。运营系统支持实时交易和毫秒级交易，而独立的分析系统支持策略回测、机器学习和监管报告。这种分离虽然对应不同工作负载，却带来四个持续性问题：

• 两套相互矛盾的事实版本
• 风险控制存在新鲜度缺口
• 治理和血缘关系重复
• 不同系统间存在多个同步管道

机器学习增加了另一层依赖。模型需要历史数据进行训练，但其输出必须在实时交易流程中可用。在独立系统间转移模型和数据，为本已时间敏感的流程增加了复杂性。替代方案是采用统一平台处理数据、分析和人工智能——Real-Time Mode 以毫秒级延迟流式传输数据，Lakebase Postgres 保持数据随时可用，使实时交易台和模型流水线都能直接从同一数据源获取信息，无需额外传输步骤。

运营和分析工作负载通过共享统一的数据基础协同运行。由 Databricks 解决架构师 Victoria Sicking 在《在 Databricks 中实时运行能源交易、风险和分析》中提出的解决方案，整合了 Databricks Data + AI 平台上的六个组件，其核心设计原则是所有组件均不维护独立的数据副本。所有组件均基于 Spark Structured Streaming 实时模式写入 Lakebase 和湖仓一体架构中的数据进行协作。

• Spark Structured Streaming 实时模式：用于具有毫秒级延迟的持续事件处理
• Lakebase：作为无服务器 PostgreSQL 的操作数据库，用于应用程序和代理
• Databricks Apps：用于实时交易界面
• 机器学习模型：用于实时价格预测和交易信号生成
• Genie One：用于历史分析
• Unity Catalog：用于跨工作流的治理

Spark Structured Streaming 实时模式接收市场数据并将其流式传输至 Lakebase（此处作为操作型数据库，支持毫秒级读取、事务和更新）。相同数据随后可支持基于湖仓一体架构的分析工作负载。

团队无需再为实时交易台和回测/报告的并行流水线进行协调。通过构建单一数据摄入路径处理市场和持仓数据，可节省原本用于对账和协调的时间。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结构化流实时模式持续处理传入数据。
• Lakebase作为实时交易台的托管PostgreSQL数据接收端和操作数据库。
• 希望构建分析层并运行历史分析或回测的团队，现在可以基于Lakehouse中的数据进行构建。
• Databricks应用使用操作数据展示实时价格、持仓、损益、风险、警报和模型输出。
• 嵌入式仪表板和Genie One支持历史分析和交易活动相关问题的查询。
• 机器学习模型使用相同数据生成价格预测和交易信号。
• Unity Catalog对应用、分析和机器学习工作流实施统一治理。

实时交易台、分析和机器学习工作负载并非需要重复数据传输的独立终点，而是基于相同受控数据的不同工作方式。

问题在于，操作和分析需求是否必须由独立系统来满足，这些系统需要维护独立的数据副本、治理模型和同步逻辑。虽然两者的需求存在差异，但一个平台可以同时满足两者的需求。通过将数据统一到一个受控副本上，交易台、风险模型和报告层将始终保持同步。

当这些工作负载运行在独立系统时，风险控制可能依赖于批量数据，模型可能基于与实时系统不一致的信息进行训练，同时治理、数据血缘和同步流水线需要在多个系统中重复维护。

Databricks Energy Trading 解决方案将这些能力整合到统一的受控数据基础之上。通过这种架构，团队可以在市场变化时实时评估风险，同时使用相同的受控数据进行损益分析、敞口计算、回测、机器学习、仪表板和自然语言分析。

了解更多关于如何开始的信息，请访问：

• 能源团队如何将盗窃检测转化为受控行动
• Quantum Capital Group：通过 Lakebase 改变能源交易评估方式
• 文档：将自定义 Databricks 应用连接到 Lakebase
• Apache Spark Structured Streaming 实时模式 - 延迟演示

常见问题

独立系统会对能源交易造成哪些问题？

独立系统可能导致出现两种不同的数据真相，风险控制存在数据新鲜度差距，治理和数据血缘需要重复维护，系统间需要额外的同步流水线。当模型在一个系统上训练却在另一个系统上运行时，机器学习的管理也会变得更加困难。通过维护一个统一受控的数据副本，并采用统一的控制策略，可以消除大部分这些成本。

为什么要在单一平台整合能源交易的操作和分析工作负载？

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

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

Lakebase 是 Databricks 数据 + AI 平台原生的全托管 PostgreSQL 数据库，此处用作支持毫秒级读取、事务和更新操作的 OLTP 数据库。由于 Lakebase 与湖仓一体架构位于同一平台，它能够将操作数据与分析工作负载连接到统一的受控数据副本，而无需在平台外维护独立数据库。

交易员如何在市场条件变化时监控风险？

基于 Databricks Apps 构建的实时交易应用，作为在平台上构建和部署数据应用的方式（例如实时交易界面），可以实时显示价格、持仓、损益和风险数据。当风险指标接近交易台限制时，系统会触发风险预警，使交易员能够根据实时情况做出响应，而不仅仅依赖批量计算结果。

如何通过 Unity Catalog 实现数据治理？

Unity Catalog 是 Databricks 的权限管理、数据血缘和审计治理层，为操作应用、分析和机器学习工作流提供统一的治理框架。它能够端到端地集中管理权限、数据血缘和审计信息，使团队只需为统一数据副本配置一次控制策略，而无需为每个系统重复构建独立的治理机制。

相关标签：

能源

将最新文章发送到您的邮箱

订阅我们的博客，最新文章将直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"