Databricks 实时能源交易与分析方案：毫秒级流处理与 Lakebase 统一数据底座

Databricks：Blog·2026-10-24 03:00· 36 分钟前AI 评分23

在 Databricks 上实现实时能源交易与分析

AI 导读

Databricks 展示了一套实时能源交易与分析方案，用 Spark Structured Streaming Real-Time Mode 以毫秒级延迟处理市场数据并写入 Lakebase，供交易台应用直接读取。

正文 · 原文

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

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

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

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

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

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

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

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

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

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

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

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

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

该演示展示了布伦特原油、德国和法国电力现货、欧元兑美元汇率、欧盟碳排放配额（EUA）以及 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 使用运营数据来呈现实时价格、持仓、损益、风险、告警和模型输出。
嵌入式仪表板和 Genie One 支持历史分析以及关于交易活动的问题。
机器学习模型使用相同的数据来生成价格预测和交易信号。
Unity Catalog 在应用、分析和机器学习工作流中统一实施治理。

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

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

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

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

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

如需了解更多入门方式，请访问：

常见问题

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

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

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

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

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

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

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

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

如何通过 Unity Catalog 治理数据？

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

来源：Databricks：Blog · databricks.com