- 能源交易团队通常为实时交易和分析分别运行独立系统，这会造成风险数据陈旧、治理重复以及同步开销。
- Databricks 在同一个平台上运行这一切。Spark Structured Streaming 实时模式将市场数据流式写入 Lakebase——一个面向应用和代理的无服务器 Postgres。这些数据随后供给实时交易应用、机器学习模型、仪表盘以及自然语言查询工具 Genie One。
- Databricks 的治理层 Unity Catalog 在一个地方统一管控这一切。权限、血缘和审计只需设置一次，而无需为每个系统分别配置。
为什么实时能源交易需要的不仅仅是更快的数据？
能源交易台所处的市场环境变化迅速，决策以毫秒计。有两项变化让这变得更加困难：更高的价格波动性，以及 欧盟日前电力市场从小时级交易间隔改为 15 分钟交易间隔这一转变。15 分钟市场时间单位是单一日前耦合（SDAC）的一部分，该系统连接欧盟各国的日前电力市场。这使得每小时的市场时段数量增至四倍，并增加了记录、订单和风险重算的数据量。要保持这些计算的准确性，就需要最新的数据——这直接指向数据的存储和治理方式，而不仅仅是数据到达的速度。
对交易台而言，数据陈旧不只是不便。它可能使风险控制反映市场的较早状态，导致错失日内行情，并使交易台限额与当前持仓不同步。
许多组织的应对方式是采用两套技术栈。一套运营系统支撑实时交易台和毫秒级交易。一套独立的分析系统支撑策略回测、机器学习和监管报告。这种拆分对应两种不同的工作负载，但会带来四个反复出现的问题：
- 两个版本的真相
- 风险控制中的新鲜度缺口
- 治理和血缘重复
- 不同系统之间的多条同步管道
机器学习还带来另一项依赖。模型需要历史数据进行训练，但其输出必须能在实时交易工作流中使用。在独立系统之间迁移模型和数据，会给本已对时间敏感的流程增加复杂性。替代方案是一个统一的数据、分析和 AI 平台——一个让 实时模式流式处理 以毫秒级延迟写入、并由 Lakebase Postgres 保存就绪数据的平台——这样实时交易台和模型管道都从同一来源取数，无需额外的传输步骤。
运营和分析工作负载如何在 Databricks 上协同运行？
运营和分析工作负载通过共享同一数据基础来协同运行。下面由 Databricks 解决方案架构师 Victoria Sicking 展示的解决方案，在 '在 Databricks 中运行实时能源交易、风险和分析' 中有所描述，它在 Databricks 数据 + AI 平台上组合了六个组件，而关键的设计选择是没有任何组件维护自己独立的数据副本。所有组件都基于 Spark Structured Streaming 实时模式写入 Lakebase 和湖仓的数据工作。
- Spark Structured Streaming 实时模式，用于以毫秒级延迟进行连续事件处理
- Lakebase, 一个面向应用和代理的无服务器 Postgres，用作运营数据库
- Databricks Apps 用于实时交易界面。
- 机器学习 模型用于实时价格预测和交易信号。
- Genie One 用于历史分析。
- Unity Catalog 用于整个工作流的治理。
Spark Structured Streaming 实时模式接收市场数据并将其流式写入 Lakebase, 在这里用作运营（OLTP）数据库，支持毫秒级读取、事务和 upsert。随后，同一数据可以支撑构建在 湖仓.
上的分析工作负载。团队不再需要协调并行管道——一条用于实时交易台，另一条用于回测和报告。此前耗费在核对和协调上的时间得以释放，因为市场数据和持仓数据通过单一摄取路径进入你的数据资产。 Unity Catalog ——Databricks 用于权限、血缘和审计的治理层——将这一治理应用于应用、商业智能和机器学习工作负载，因此它们无需在多个系统中分别配置。
Databricks Apps 中的实时能源交易台是什么样子？
它看起来是一个单一应用，显示价格、持仓、损益（P&L）和风险，并随市场变动全部实时更新。这一实时体验构建在 Databricks Apps 之上——这是在平台上构建和托管数据应用（例如实时交易界面）的方式——它汇集了交易台监控市场和应对变化所需的一切，并直接从 Lakebase 提供服务，因此交易台始终读取的是供给分析工作负载的同一份受治理数据，无需单独的运营副本。
该演示显示布伦特原油、德国和法国电力现货、欧元兑美元汇率、欧盟碳排放配额（EUA）和 TTF 天然气的合约价格。
风险在同一工作流中对照交易台限额进行监控。当某项指标接近限额时，应用会发出风险警报，使交易台能够看到变化并立即响应。这取代了此前根据较早数据快照计算风险的夜间批处理流程。
该应用并非与数据平台脱节的报告界面。Lakebase 提供应用背后的运营层，流式管道则保持信息实时更新。
如何从同一数据生成交易信号？
在支撑实时交易台的同一份受治理数据上训练机器学习模型，使用 MLflow, 跟踪其开发和血缘，并通过 Databricks 模型服务部署已批准的版本。随后，其输出可以直接在应用中呈现。
能源交易团队需要能够预判风险并识别潜在交易信号的模型，而在单一受治理的统一数据副本上运行一切，消除了训练系统与实时系统之间的交接——模型看到的正是交易台所看到的。
该演示展示了一个可助力生成交易信号的实时价格预测。用于训练模型的数据与消费其输出的工作流之间的路径变得更短。机器学习成为端到端交易工作流的一部分，而不是横亘在实时栈与分析栈之间的独立系统。
同一份受治理数据还可支持风险分析和模型开发。运营工作负载与分析工作负载保持连接，团队无需事后核对不同版本的数据。
分析师如何在不增加数据副本的情况下获得历史视图？
分析师使用嵌入式仪表盘和 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 接收端和实时交易台的运营数据库。
- 希望构建分析层并运行历史分析或回测的团队，现在可以在湖仓中的该数据之上进行构建。
- Databricks Apps 使用运营数据呈现实时价格、持仓、损益、风险、警报和模型输出。
- 嵌入式仪表盘和 Genie One 支持历史分析以及关于交易活动的问题。
- 机器学习模型使用同一数据生成价格预测和交易信号。
- Unity Catalog 对应用、分析和机器学习工作流实施治理。
实时交易台、分析和机器学习工作负载并非需要反复移动数据的独立目的地。它们是以不同方式使用同一份受治理数据。
团队在评估这一架构时应考虑什么？
问题在于，运营和分析需求是否必须由彼此断开的系统来满足，这些系统拥有各自的数据副本、治理模型和同步逻辑。它们确实有不同需求，但一个平台可以同时服务两者，而整合到一份受治理的数据副本上意味着交易台、风险模型和报告层永远不会彼此不同步。
当这些工作负载运行在独立系统上时，风险控制可能依赖批处理数据，模型可能基于与实时系统不匹配的信息进行训练，并且治理、血缘和同步管道必须维护不止一次。
Databricks 能源交易解决方案将这些能力汇聚在一个受治理的数据基础上。借助这一设置，团队可以在市场变动时评估风险，同时将同一份受治理数据用于损益、敞口、回测、机器学习、仪表盘和自然语言分析。
如需了解更多入门方法，请访问：
- 能源团队如何将盗窃检测转化为受治理的行动
- Quantum Capital Group：借助 Lakebase 变革能源交易评估
- 文档：将自定义 Databricks 应用连接到 Lakebase
- Apache Spark Structured Streaming 实时模式——延迟演示
常见问题
独立系统会给能源交易带来哪些问题？
独立系统可能造成两个版本的真相、风险控制中的新鲜度差距、重复的治理和血缘、额外的维护工作，以及系统之间额外的同步管道。当模型在一个系统上训练却必须在另一个系统上运行时，机器学习也变得更难管理。维护一份受治理的统一数据副本，并配以单一控制集，可以消除其中大部分成本。
为什么能源交易要将运营和分析工作负载整合到一个平台？
能源交易团队可以在 Databricks 中基于一份受治理的数据副本运行实时交易台、风险、机器学习和历史分析。Spark Structured Streaming 实时模式、Lakebase、Databricks Apps 和 Unity Catalog 取代了第二个系统和重复的控制。
Lakebase 在能源交易中扮演什么角色？
Lakebase 是 Databricks 数据 + AI 平台原生的全托管 Postgres 数据库，在此用作运营（OLTP）数据库，支持毫秒级读取、事务和 upsert。由于它与湖仓处于同一平台，它将运营数据与分析工作负载连接在一份受治理的统一数据副本上，而无需在平台之外单独设置数据库。
交易员如何随着市场状况变化监控风险？
一个构建在 Databricks Apps 上的实时交易应用——Databricks Apps 是在该平台上构建和托管数据应用（例如实时交易界面）的方式——可以在价格、头寸、损益和风险更新时实时显示这些信息。当各项指标接近交易台限额时，风险警报会被触发，因此交易员能够根据当前状况做出反应，而不是仅依赖批量计算。
Unity Catalog 如何治理数据？
Unity Catalog 是 Databricks 的治理层，负责权限、血缘和审计，在运营应用、分析和机器学习工作流之间提供统一的治理层。它端到端地集中维护权限、血缘和审计，因此团队只需为单一数据副本配置一次控制措施，而无需为每个系统分别复制一套治理。
相关标签：在收件箱中获取最新文章
订阅我们的博客，最新文章将直接发送到您的收件箱。