Ir para o conteúdo principal
Setores

Comércio de energia em tempo real e análise de dados no Databricks

Veja como o Databricks combina comércio de energia em tempo real, monitoramento de riscos, machine learning e análises históricas com uma única plataforma e um modelo de governança.

por Victoria Sicking e Jack Yallop

  • As equipes de negociação de energia geralmente executam sistemas separados para negociação ao vivo e análise, o que cria dados de risco desatualizados, governança duplicada e sobrecarga de sincronização.
  • O Databricks executa isso em uma única plataforma. O Spark Structured Streaming no modo em tempo real transmite dados de mercado para o Lakebase, um Postgres Serverless para aplicativos e agentes. Esses dados alimentam o aplicativo de negociação ao vivo, modelos de machine learning, painéis e o Genie One, uma ferramenta de consulta em linguagem natural.
  • O Unity Catalog, a camada de governança do Databricks, controla tudo em um só lugar. Permissões, linhagem e auditoria são configuradas uma única vez, em vez de em cada sistema.

Por que o comércio de energia em tempo real precisa de mais do que apenas dados mais rápidos?

As mesas de negociação de energia operam em mercados onde as condições mudam rapidamente e as decisões são medidas em milissegundos. Duas mudanças tornam isso mais difícil: maior volatilidade de preços e a transição da mudança no mercado de eletricidade de véspera (day-ahead) da UE de intervalos horários para 15 minutos. A unidade de tempo de mercado de 15 minutos faz parte do acoplamento único de mercado de véspera (SDAC), o sistema que conecta os mercados de eletricidade de véspera em todos os países da UE. Isso cria quatro vezes mais períodos de mercado por hora e aumenta o volume de registros, pedidos e recálculos de risco. Manter esses cálculos precisos exige dados atuais – o que aponta diretamente para a forma como os dados são armazenados e governados, e não apenas para a rapidez com que chegam.

Dados desatualizados são mais do que um inconveniente para uma mesa de negociação. Eles podem fazer com que os controles de risco reflitam um estado anterior do mercado, contribuir para a perda de movimentos intradiários e deixar os limites da mesa dessincronizados com as posições atuais.

Muitas organizações respondem com duas pilhas de tecnologia. Um sistema operacional dá suporte à mesa ao vivo e a transições em milissegundos. Um sistema analítico separado dá suporte ao backtesting de estratégias, aprendizado de máquina e relatórios regulatórios. A divisão atende a duas cargas de trabalho diferentes, mas cria quatro problemas recorrentes:

  • Duas versões da verdade
  • Uma lacuna de frescor nos controles de risco
  • Governança e linhagem duplicadas
  • Múltiplos pipelines de sincronização entre os diferentes sistemas

O aprendizado de máquina adiciona outra dependência. Os modelos precisam de dados históricos para treinamento, mas suas saídas devem estar disponíveis no fluxo de trabalho de negociação ao vivo. Mover modelos e dados entre sistemas separados adiciona complexidade a um processo que já é sensível ao fator tempo. A alternativa é uma plataforma unificada para dados, análises e IA – uma em que o Real-Time Mode do Apache Spark transmite dados com latência de milissegundos e o Lakebase mantém prontos, para que tanto a mesa ao vivo quanto o pipeline de modelos utilizem a mesma fonte sem uma etapa extra de transferência.

Como cargas de trabalho operacionais e analíticas podem ser executadas juntas no Databricks?

Cargas de trabalho operacionais e analíticas são executadas juntas compartilhando uma única fundação de dados. A solução apresentada abaixo por Victoria Sicking, Solutions Architect no Databricks, descrita em 'Executar negociação, risco e análises de energia ao vivo no Databricks' abaixo combina seis componentes na Databricks Data + AI Platform, e a principal escolha de design é que nenhum componente mantém sua própria cópia separada dos dados. Todos eles funcionam com base no que o Spark Structured Streaming Real-Time Mode gravou no Lakebase e no lakehouse.

  • Spark Structured Streaming Real-Time Mode para processamento contínuo de eventos com latência de milissegundos
  • Lakebase, um Postgres sem servidor para aplicativos e agentes, para o banco de dados operacional
  • Databricks Apps para a interface de negociação ao vivo.
  • Modelos de aprendizado de máquina para previsões de preços e sinais de negociação em tempo real.
  • Genie One para análises históricas.
  • Unity Catalog para governança em todo o fluxo de trabalho.

O Spark Structured Streaming Real-Time Mode recebe dados de mercado e os transmite para o Lakebase, usado aqui como o banco de dados operacional (OLTP) para leituras, transações e upserts em milissegundos. Os mesmos dados podem então dar suporte às cargas de trabalho analíticas construídas no lakehouse.

As equipes não precisam mais coordenar pipelines paralelos, um para a mesa ao vivo e outro para backtesting e relatórios. O tempo antes gasto em reconciliação e coordenação é liberado criando um único caminho de ingestão em seu patrimônio de dados para dados de mercado e de posição. O Unity Catalog – a camada de governança do Databricks para permissões, linhagem e auditoria – aplica essa governança em todas as cargas de trabalho de aplicativos, inteligência de negócios e aprendizado de máquina, para que elas não sejam configuradas independentemente em vários sistemas.

Como é uma mesa de negociação de energia ao vivo no Databricks Apps?

Parece um único aplicativo que exibe preços, posições, lucro e prejuízo (P&L) e risco, tudo sendo atualizado conforme o mercado se movimenta. A experiência ao vivo é construída no Databricks Apps – a forma de criar e hospedar aplicativos de dados, como uma interface de negociação ao vivo, na plataforma – reunindo o que uma mesa precisa para monitorar o mercado e agir diante de condições em mudança, servidos diretamente do Lakebase para que a mesa esteja sempre lendo os mesmos dados governados que alimentam as cargas de trabalho analíticas, sem necessidade de uma cópia operacional separada.

A demonstração exibe preços de instrumentos para petróleo Brent, pontos de energia da Alemanha e da França, conversão de EUR para USD, licenças de emissão da UE (EUAs) e gás TTF.

O risco é monitorado em relação aos limites da mesa no mesmo fluxo de trabalho. Quando uma métrica se aproxima de um limite, o aplicativo emite um alerta de risco para que a mesa possa ver a alteração e responder imediatamente. Isso substitui um processo em lote (batch) noturno que calcula o risco a partir de um instantâneo anterior dos dados.

O aplicativo não é uma superfície de relatórios desconectada da plataforma de dados. O Lakebase fornece a camada operacional por trás do aplicativo, e o pipeline de streaming mantém as informações atualizadas.

Como você gera sinais de negociação a partir dos mesmos dados?

Treine modelos de aprendizado de máquina com os mesmos dados governados que dão suporte à mesa ao vivo, rastreie seu desenvolvimento e linhagem com o MLflow e implante versões aprovadas por meio do Model Serving do Databricks. Suas saídas podem então aparecer diretamente no aplicativo.

As equipes de negociação de energia precisam de modelos que possam antecipar riscos e identificar potenciais sinais de negociação, e executar tudo em uma única cópia governada e unificada dos dados elimina a transferência entre um sistema de treinamento e um sistema ao vivo – o modelo vê exatamente o que a mesa vê.

A demonstração mostra uma previsão de preços em tempo real que pode contribuir para um sinal de negociação. O caminho entre os dados usados para treinar um modelo e o fluxo de trabalho que consome sua saída fica mais curto. O aprendizado de máquina se torna parte do fluxo de trabalho de negociação de ponta a ponta, em vez de um sistema separado situado entre as pilhas ao vivo e analítica.

Os mesmos dados governados também podem dar suporte à análise de risco e ao desenvolvimento de modelos. As cargas de trabalho operacionais e analíticas permanecem conectadas, e as equipes não precisam reconciliar versões separadas dos dados posteriormente.

Como os analistas podem obter uma visão histórica sem outra cópia de dados?

Os analistas usam um painel incorporado e o Genie One, ambos construídos sobre a mesma fundação de dados do aplicativo ao vivo. O painel incorporado apresenta dados históricos de negociação, incluindo o total de negociações, o volume negociado e comparações entre traders.

Para análises mais profundas, os analistas podem usar SQL, Python ou Spark. Eles também podem usar o Genie One – a interface de linguagem natural do Databricks para fazer perguntas sobre dados governados – sem precisar escrever a consulta por conta própria. Na demonstração, o analista pede ao Genie One para identificar as cinco principais contrapartes por número de negociações e comparar o volume total de compra com o volume de venda para cada uma.

O Genie One funciona dentro do espaço de trabalho do Databricks e usa o contexto de dados disponível e a semântica definida para responder. Os analistas podem passar de uma visão de painel que gera insights fixos para uma análise personalizada dos dados, permanecendo no mesmo ambiente governado. Uma cópia unificada dos dados significa que os resultados concordam entre a mesa ao vivo e o back-office de análises.

Qual é a arquitetura desde o feed de mercado até o insight governado?

Os dados fluem de um feed de mercado, passando pelo streaming e pelo Lakebase, para o aplicativo, análises e aprendizado de máquina, tudo sob a governança do Unity Catalog. Como o Unity Catalog abrange todos os componentes, as permissões, a linhagem e a auditoria aplicadas à mesa ao vivo também se aplicam aos painéis, ao Genie One e ao aprendizado de máquina – configurados uma única vez, sem serem reproduzidos em cada sistema. As etapas são:

  1. Um feed de mercado, como ICE, APEX ou um stream do Kafka, fornece os eventos de origem.
  2. O Spark Structured Streaming Real-Time Mode processa os dados recebidos continuamente.
  3. O Lakebase atua como o coletor (sink) Postgres gerenciado e banco de dados operacional para a mesa ao vivo.
  4. Equipes que desejam criar camadas analíticas e executar análises históricas ou backtesting agora podem criar esses dados no Lakehouse.
  5. Databricks Apps usa os dados operacionais para apresentar preços ao vivo, posições, P&L, risco, alertas e saídas de modelos.
  6. Painéis integrados e Genie One oferecem suporte a análises históricas e perguntas sobre a atividade de negociação.
  7. Modelos de machine learning usam os mesmos dados para produzir previsões de preços e sinais de negociação.
  8. Unity Catalog aplica governança aos fluxos de trabalho de aplicativos, análises e machine learning.

A mesa de operações ao vivo, as análises e as cargas de trabalho de machine learning não são destinos separados que precisam de movimentação repetida de dados. Elas são diferentes maneiras de trabalhar com os mesmos dados governados.

O que as equipes devem considerar ao avaliar essa arquitetura?

A questão é se os requisitos operacionais e analíticos devem ser atendidos por sistemas desconectados com cópias separadas, modelos de governança e lógica de sincronização. Eles têm requisitos diferentes, mas uma plataforma pode atender a ambos e consolidar em uma única cópia governada de dados significa que a mesa, os modelos de risco e a camada de relatórios nunca ficam dessincronizados entre si.

Quando essas cargas de trabalho são executadas em sistemas separados, os controles de risco podem depender de dados em lote, os modelos podem ser treinados com informações que não correspondem ao sistema ativo, e os pipelines de governança, linhagem e sincronização devem ser mantidos mais de uma vez.

A solução Databricks Energy Trading reúne esses recursos em uma única base de dados governada. Com essa configuração, as equipes podem avaliar o risco à medida que o mercado se movimenta, usando os mesmos dados governados para P&L, exposição, backtesting, machine learning, painéis e análise em linguagem natural.

Para saber mais sobre como começar, acesse:

Perguntas frequentes

Quais problemas sistemas separados podem criar para a negociação de energia?

Sistemas separados podem criar duas versões da verdade, uma lacuna de atualizabilidade nos controles de risco, governança e linhagem duplicadas, trabalho de manutenção extra e pipelines de sincronização adicionais entre sistemas. O machine learning também se torna mais difícil de gerenciar quando os modelos são treinados em um sistema, mas precisam ser executados em outro. Manter uma cópia única e governada dos dados, com um único conjunto de controles, elimina a maior parte desses custos.

Por que consolidar cargas de trabalho operacionais e analíticas em uma única plataforma para negociação de energia?

As equipes de negociação de energia podem executar a mesa de operações ao vivo, risco, machine learning e análises históricas em uma única cópia governada de dados no Databricks. O Spark Structured Streaming Real-Time Mode, o Lakebase, os Databricks Apps e o Unity Catalog substituem o segundo sistema e os controles duplicados.

Qual é o papel do Lakebase na negociação de energia?

O Lakebase é um banco de dados Postgres totalmente gerenciado e nativo da Databricks Data + AI Platform, usado aqui como o banco de dados operacional (OLTP) para leituras, transações e upserts em milissegundos. Como ele fica na mesma plataforma que o lakehouse, ele conecta dados operacionais a cargas de trabalho analíticas em uma cópia única e governada de dados, em vez de exigir um banco de dados separado fora da plataforma.

Como os traders podem monitorar o risco à medida que as condições de mercado mudam?

Um aplicativo de negociação ativo construído em Databricks Apps, a forma de criar e hospedar aplicativos de dados na plataforma (como uma interface de negociação ativa), pode exibir preços, posições, P&L e risco conforme são atualizados. Alertas de risco são disparados à medida que as medidas se aproximam dos limites da mesa, para que os traders respondam às condições atuais em vez de depender apenas de cálculos em lote.

Como os dados são governados com o Unity Catalog?

O Unity Catalog é a camada de governança da Databricks para permissões, linhagem e auditoria, fornecendo uma única camada de governança em todo o aplicativo operacional, análises e fluxos de trabalho de machine learning. Ele mantém permissões centralizadas, linhagem e auditoria de ponta a ponta, para que as equipes configurem os controles uma vez para a única cópia de dados, em vez de reproduzir uma governança separada para cada sistema.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original

Tags relacionadas:

Energia, Lakebase, Genie, Unity Catalog e Databricks Apps

Receba os posts mais recentes na sua caixa de entrada

Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.