Execute trading de energia ao vivo, gestão de risco e análises no Databricks

Autoria: Databricks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Run Live Energy Trading, Risk, and Analytics in Databricks · Canal: Databricks · 09:13 · Assistir no YouTube

Tópicos: Dados, bancos de dados e embeddings, Modelos de IA

Resumo

O vídeo apresenta como o Databricks pode reunir sistemas operacionais e analíticos para trading de energia em tempo real. Spark real-time mode e Lakebase permitem processar eventos com baixa latência e oferecer recursos transacionais, enquanto os dados são governados pelo Unity Catalog. Uma demonstração mostra preços, posições, P&L e riscos atualizados ao vivo, além de previsões de modelos de machine learning e análises históricas com Genie. A proposta é manter uma única cópia dos dados e reduzir a manutenção de sistemas e pipelines separados.

Pontos-chave

A volatilidade dos mercados de energia e a liquidação em intervalos de 15 minutos aumentam a necessidade de processar dados e recalcular riscos rapidamente.
Manter sistemas separados para operações e análises pode gerar versões divergentes dos dados, atrasos nos controles de risco e custos adicionais de manutenção e sincronização.
Spark real-time mode processa eventos continuamente; no exemplo citado, foram processados mais de 260 mil eventos por segundo com latência P99 inferior a 100 ms.
Lakebase é apresentado como um Postgres gerenciado no Databricks, voltado a leituras em milissegundos, transações e upserts.
O Unity Catalog governa os dados usados pelo aplicativo, pelas análises e pelo machine learning.
O aplicativo demonstra preços, P&L, posições, limites de risco, alertas e previsões atualizados em tempo real.
Genie permite consultar dados históricos em linguagem natural, como comparar volumes de compra e venda das principais contrapartes.
A arquitetura reúne feeds de mercado, processamento de streams, armazenamento operacional, análises e modelos em uma plataforma.

Capítulos

Início	Capítulo	Resumo
00:00	Desafios dos mercados de energia	A apresentadora descreve o aumento da volatilidade, a liquidação mais frequente e os riscos de manter sistemas operacionais e analíticos separados.
02:11	Arquitetura de baixa latência no Databricks	São apresentados Spark real-time mode e Lakebase como componentes para combinar processamento de streams e operações transacionais.
04:56	Demonstração de análises e Genie	A demonstração passa do painel histórico para uma consulta em linguagem natural sobre volumes negociados por contraparte.
07:04	Arquitetura completa e principais benefícios	O vídeo percorre o fluxo desde os feeds de mercado até aplicativos, análises e modelos, e conclui com os benefícios de uma plataforma unificada.

Citações

Os SLAs da mesa são medidos em milissegundos. — 00:35

Processamos mais de 260 mil eventos por segundo, com P99 abaixo de 100 ms. — 02:43

Podemos ver esse risco se movendo ao vivo em relação aos limites da mesa. — 03:49

Você tem uma única cópia dos dados e apenas uma plataforma para manter. — 08:42

Conceitos e entidades

Databricks (empresa): Plataforma apresentada para combinar processamento operacional, análises, aplicativos e machine learning.
Spark real-time mode (ferramenta): Modo de processamento contínuo de eventos usado com Spark Structured Streaming para obter baixa latência.
Spark Structured Streaming (ferramenta): Tecnologia de streaming usada na arquitetura para processar feeds de mercado.
Lakebase (ferramenta): Postgres gerenciado no Databricks, apresentado como banco operacional para leituras, transações e upserts.
Unity Catalog (ferramenta): Sistema de governança que aplica controles aos dados usados em aplicativos, BI e machine learning.
Genie (ferramenta): Recurso do Databricks que permite fazer perguntas sobre dados e obter análises em linguagem natural.
OLTP (conceito): Processamento transacional associado, no vídeo, ao caminho operacional e ao trading ao vivo.
OLAP (conceito): Processamento analítico usado para análises históricas, backtesting e relatórios.
Victoria (pessoa): Arquiteta de soluções da Databricks e apresentadora da demonstração.

Tradução completa (pt-BR)

00:00 [música] >> Olá a todos. Sou Victoria. Sou arquiteta de soluções na Databricks e hoje quero falar com vocês sobre negociação de energia na Databricks. Então, vamos dar uma olhada nos mercados de energia. [limpa a garganta] Houve muitas mudanças nos últimos anos. Para começar, a volatilidade aumentou bastante. Em 2025, houve mais de 500 horas de preços negativos tanto nos Países Baixos quanto na Bélgica. Além disso, em 2025, o mercado diário da UE passou de intervalos de 1 hora para liquidações a cada 15 minutos

00:35 o que significa que agora há quatro vezes mais registros, ordens e recálculos de risco. Além disso, os SLAs da mesa de negociação são medidos em milissegundos. Se os dados estiverem desatualizados, você ultrapassa seus limites de risco, o que leva a proteções mal dimensionadas e a oportunidades intradiárias perdidas. Por isso, as empresas construíram duas pilhas independentes. Uma para as mesas de negociação ao vivo: esse é o caminho de dados de alta prioridade, seus dados operacionais, ou OLTP. E depois há o caminho de baixa prioridade para qualquer

01:07 backtesting de risco, machine learning e relatórios regulatórios. Ou seja, seu sistema OLAP. Manter dois sistemas traz vários desafios. Para começar, você tem duas versões da verdade. Seus dados entre o caminho de alta prioridade e o de baixa prioridade podem não corresponder. Há uma defasagem na atualização dos controles de risco. Eles normalmente são executados em um processo em lote, talvez durante a noite, e não refletem o estado atual dos dados.

01:38 A governança e a linhagem ficam fragmentadas entre os dois sistemas, porque você precisa configurá-las duas vezes. E é preciso manter dois sistemas, o que significa o dobro do esforço de manutenção e pipelines de sincronização caros entre eles. Por fim, o machine learning fica em algum lugar entre esses dois sistemas. Ele precisa dos dados do caminho de baixa prioridade, mas é executado ao vivo no caminho de alta prioridade. E fica bem difícil manter esses dois sistemas, além de ser bastante caro. Então, a solução que propomos é que

02:11 agora você pode fazer isso diretamente na Databricks. Historicamente, você executaria seu sistema analítico, ou OLAP, na Databricks. E, com duas tecnologias lançadas recentemente, agora também podemos oferecer suporte aos seus bancos de dados transacionais, ou seja, à sua pilha operacional OLTP. Isso é possível graças a estas duas coisas: o modo em tempo real do Spark e o Lakehouse. O modo em tempo real do Spark permite transmitir dados continuamente por meio do Spark Structured Streaming

02:43 no modo em tempo real. Isso nos permite processar eventos em menos de 100 ms. Recentemente, por exemplo, fizemos isso com um cliente: processamos mais de 260.000 eventos por segundo, com latência P99 inferior a 100 ms, e isso é escalável. O Lakehouse é então o seu destino de gravação, um Postgres totalmente gerenciado na Databricks, nativo da plataforma. Esse é o seu sistema OLTP, onde você tem leituras em milissegundos, transações e operações de inserção ou atualização. Todos esses dados são governados pelo Unity Catalog.

03:15 É assim que trazemos a parte operacional para a Databricks, onde você já tem a parte analítica. Agora, vou mostrar como isso fica em um app da Databricks que criamos. Vou abrir este app. Esta é a sua mesa de negociação ao vivo. Você pode ver os preços, o P&L, as posições e o risco, tudo sendo atualizado várias vezes por segundo conforme o mercado se movimenta. Você pode rolar um pouco para baixo. Temos os preços dos instrumentos, como o petróleo Brent, os preços à vista de energia da Alemanha e da França

03:49 a conversão de euros para dólares americanos, o carbono da UE, o gás TTF e outros. Podemos descer mais. Vemos todas as nossas posições sendo atualizadas ao vivo. E aqui embaixo vemos o risco. Assim, temos o risco novamente no mesmo sistema. Podemos ver como ele se movimenta ao vivo em relação aos limites da mesa de negociação. Quando se aproxima do limite, isso dispara nossos alertas de risco. Assim, recebemos atualizações ao vivo sobre qualquer risco que enfrentamos e podemos agir imediatamente.

04:23 Além disso, você precisa de machine learning para, por exemplo, gerar sinais de negociação, antecipar riscos e agir de forma proativa. Esses modelos serão treinados, é claro, com os mesmos dados que são usados aqui. Depois, você os coloca em produção na Databricks e pode disponibilizá-los diretamente aqui. Ao clicar nisto, por exemplo — ou isso pode estar integrado diretamente ao seu fluxo de trabalho — você também pode ver a previsão de preços em tempo real. E isso pode gerar, por exemplo, seu sinal de negociação.

04:56 Certo. Essa é a nossa mesa de negociação. Agora também queremos fazer algumas análises. É claro que você pode acessar a Databricks e analisar todos os seus dados em detalhes; pode usar SQL, Python ou Spark. Talvez nem todos consigam usar essas ferramentas, e nem todos saibam escrever nessas linguagens. Então, vamos subir e acessar a aba de análises e Genie. Aqui vemos um dashboard incorporado que mostra mais dados do caminho de baixa prioridade, ou dados históricos.

05:28 Isso pode ser atualizado com a frequência que você quiser, é claro, mas aqui temos uma visão mais histórica, que talvez queiramos analisar e usar para backtesting, entre outras coisas. Por exemplo, você pode ver o total de negociações e o volume negociado. Talvez queiramos comparar o desempenho dos traders. Agora, talvez eu queira fazer análises adicionais. Posso ir diretamente aqui e fazer uma pergunta ao Genie. Ele vai sugerir algumas perguntas. Vou simplesmente

06:00 perguntar: “Para nossas cinco principais contrapartes por número de negociações, compare nosso volume total de compras com o volume total de vendas de cada uma.” O Genie fica diretamente no seu workspace da Databricks e entende os dados que você tem, porque entende como eles fluem pelo seu sistema, em quais dashboards aparecem e assim por diante. Você também pode definir semânticas por cima desses dados. Então, o Genie analisa os dados e, como acabou de fazer, nos dá uma resposta. Assim,

06:32 podemos ver que está muito equilibrado, o que faz sentido, porque, obviamente, estou simulando os dados originais aqui, e temos uma distribuição bastante uniforme entre os volumes de compra e venda. Podemos ver pequenas diferenças. A ANBV lidera, com 410.000 negociações, e está quase equilibrada, com uma leve tendência para vendas. E podemos ver os números exatos aqui. Ótimo. Vimos como tanto a mesa de negociação quanto qualquer analista interagiriam com esses

07:04 dados. Vamos voltar e ver a arquitetura por trás disso. No início, temos a fonte, que é o feed do mercado. Pode ser o ICE, o Apex ou qualquer fluxo do Kafka, por exemplo. Isso alimenta o fluxo do Spark Structured Streaming no modo em tempo real, que é basicamente uma implementação muito simples do modo em tempo real. E isso tem um destino de gravação: o Lakehouse. O Lakehouse, novamente, é o Postgres gerenciado, que funciona como seu banco de dados operacional. O Lakehouse, é claro, faz parte do seu

07:38 Lakehouse. Assim, você tem novamente uma única cópia dos dados, toda em um só lugar, onde pode então construir as camadas bronze, silver, gold e assim por diante. Depois, você pode seguir para as análises. Ao mesmo tempo, o Lakebase alimenta o backend do app. É de lá que vêm as visualizações em tempo real. Sobre o Lakehouse, você vai construir suas análises. No app, como vimos antes, temos o dashboard incorporado. Você tem o Genie do AI/BI e pode criar sua camada semântica

08:09 com o Metric Fuse e a ontologia. Com os mesmos dados, você vai treinar seus modelos de machine learning e colocá-los em produção ali mesmo, tanto para as visualizações no app quanto para a geração de sinais de negociação. E, mais uma vez, isso alimenta o app, onde tudo se reúne. Então, qual é a conclusão? Com a Databricks, você pode combinar seus sistemas analíticos e operacionais. Você pode acompanhar o risco em tempo real, seu P&L, seu valor em risco, sua exposição e tudo isso. Nada precisa ser

08:42 como um job em lote noturno. Tudo pode acontecer aqui, em um só lugar. Você tem uma única cópia dos dados, então só precisa manter uma plataforma, com menos esforço. Você não precisa ter pipelines de sincronização caros e tem apenas uma versão da verdade. E, o melhor de tudo, só precisa governar isso uma vez pelo Unity Catalog, que se aplica a tudo: seu app, seu BI e seu machine learning. E, durante todo esse processo, a linhagem, as permissões e a auditoria são mantidas de ponta a ponta em um único sistema que

09:13 você precisa manter. Muito obrigado. >> [música]

Transcrição original

[00:00] [music] >> Hi everyone. I’m Victoria. I’m a solutions architect at Databricks, and today I want to talk to you about energy trading on Databricks. So, let’s have a look at the energy markets. [clears throat] Um, there’s been a bunch of changes over the last years. So, first off, volatility has highly increased. In 2025, there were over 500 hours of negative prices in both the Netherlands and Belgium. Additionally, in 2025, the EU day-ahead market moved from 1 hour to 15-minute

[00:35] settlements, which means you now have four times records, orders, and risk recalculations. And then also, the SLAs at the desk are measured in milliseconds. Now, if you have stale data, that means you breach your risk limits, it leads to mis-hedges, and missed intraday moves. So, what companies have done is that they have built two independent stacks. One stack for your live trading desks. So, this is your hot path data, your operational data, or OLTP. And then you have your cold path for any

[01:07] risk backtesting, machine learning, and regulatory reporting. So, your OLAP system. Now, um, maintaining two systems here comes with a bunch of challenges. So, first off is you have two versions of the truth. Your data between your hot path and cold path might not match. Um, you have a freshness gap for the risk control. This typically run in a batch job, maybe overnight. Uh, and it doesn’t reflect the current state of the data.

[01:38] You have fragmented governance and lineage between the two systems because you need to set it up twice. And then you need to maintain two systems, which means you have double the maintenance effort, and you have expensive sync pipelines between the two. Finally, you have your machine learning, which lives somewhere in the middle between these two systems. It needs the data from the cold path, but it runs live on the hot path. And yeah, it becomes quite difficult to maintain these two systems and quite expensive. So, what we propose as solution is that

[02:11] now you can do this actually directly on Databricks. So, historically you would have run your analytical or your OLAP system on Databricks. And with two recently released technologies, we can now also support your uh transactional databases, so your OLTP operational stack. Um what makes this possible are these two things. So, you have your Spark real-time mode and Lakehouse. So, Spark real-time mode allows you to continuously continuously stream data uh via Spark structured streaming

[02:43] real-time mode. And this allows us to get sub-100 ms event processing. Recently, for example, we did this with a customer where we processed over 260,000 events per second at sub-100 ms P99, and this is scalable. Lakehouse then is your sync, and this is your fully managed Postgres on Databricks, which is native to the platform. Um so, this is your OLTP system where you really have your millisecond reads, transactions, and upserts. And all of this data is governed by Unity Catalog.

[03:15] So, this is how we bring in the operational part into Databricks where you have your analytical part. Now, let me show you what this actually looks like in a Databricks app that we created. Now, just open this app here. And this is now your live desk. You can see your prices, your P&L, your positions, your risk, all updating several times a second as the market moves. You can scroll down here a bit. We have our instrument prices, so for example, our Brent crude, our German and French

[03:49] power spots, our euro to US dollar conversion, EU carbon, TTF gas, what have you. We can go down here. We can see all of our positions updating live. And then down here we see our risk. Um so we have risk again in the same system. We can see this move live against the desk’s limits. And as this approaches the limit, um this here will fire our risk alerts. So we get live updates about any risk that we are facing and um we can act on it immediately.

[04:23] Now additionally, you need machine learning to like uh generate your trade signals, anticipate risk, and so on, act proactively. And these models uh will be trained, of course, on the same data that runs here. And then you deploy them on Databricks and you can have them directly here. So when you click on this, for example, or this might be integrated directly into your um bull intro and workflow, um you can see here the price forecast happening as well in real time. And this can generate, for example, your trade signal.

[04:56] Yes. So this is our trade desk. And now we also want to perform some analytics. Now, of course, you can go in Databricks, you can analyze all of your data in detail, you can use SQL, you can use Python, you can use Spark. Not everyone might be able to use these and not everyone might know how to write these languages. So let’s go up here and go into our analytics and genie tab. And what we can see here is an embedded dashboard that shows the more um cold path data or historical data.

[05:28] Um this can be updated as uh frequently as you like, of course, but here now we have more of a historic view that we might want to analyze and backtest and so on. So you can see here, for example, our total trades, we can see our volume traded. Um we might want to compare the a um traders, like how well they perform. And now I might want to perform some additional analysis on this. And I can go here directly and ask a question to Genie. Um so it will give me some suggested questions. I’m just going to

[06:00] ask it, “Please for our top five counterparties by number of trades, compare our total buy volume versus sell volume with each.” Now what this does is Genie lives directly in your Databricks workspace, and it understands the data that you have because it understands how it flows through your system, into which dashboards, and so on. And you can define semantics on top. So Genie now goes ahead and analyzes that data, and then as it already has done now, it will give us a response. So

[06:32] we can see here, okay, it’s super balanced, which makes sense because obviously the original data I’m simulating here, um and we have fairly even um distribution between the buy and sell volume. We could see the slight differences. So ANBV is the leader with 410,000 trades, and it’s nearly balanced with a slight sell bias, and we can see the exact numbers right here. Amazing. So we’ve seen how both the Trade Desk and any analyst would interact with this

[07:04] data. Let’s go back and see what the architecture behind this is. So at the very beginning, you have your source, and your source is your market feed. So it could be your eyes, your Apex, or any Kafka stream, for example. And this feeds into Spark structured streaming real-time mode stream, which is basically just a very simple implementation of real-time mode. Um and this uh has a sink, uh the Lakehouse. So Lakehouse again, the managed Postgres, and this is then your operational database. Now Lakehouse is of course part of your

[07:38] Lakehouse, so you have again one copy of the data in all in one place, and this is where you can then build on top your bronze, silver, gold layer and so on. Um to then go ahead to analytics. At the same time lake base is feeding the back end of the app. So if you want these real time visualizations, this is where they come from. Now on top of the lakehouse, you will build your analytics. So what we saw before in the app, we have the embedded dashboard. You have your AI BI genie and then you can build out your semantic

[08:09] layer with metric fuse and ontology. And then on the same data, you will train your machine learning models and deploy them right in place for both the visualizations in your app and your trade signal generation. And then again this feeds back into the app where it all comes together. So what’s the takeaway here is with data bricks, you can combine your analytical and your operational systems. You can see risk as it moves live, your P&L, your value at risk, your exposure, all of this. Nothing needs to be

[08:42] like a nightly batch job. It can all happen here in one place. You have one copy of the data, so only one platform to maintain, less effort. You don’t have to have any expensive sync pipelines and you only have one version of the truth. And best of all, you only have to govern this once through Unity Catalog which will apply to everything, your app, your BI, your machine learning. And throughout all of this, your lineage, permission and audit are maintained end to end in one system that

[09:13] you have to maintain. Thank you very much. >> [music]