Revenir au contenu principal
Industries

Trading d'énergie en temps réel et analyses sur Databricks

Découvrez comment Databricks combine le trading d'énergie en temps réel, la surveillance des risques, le machine learning et les analyses historiques au sein d'une seule plateforme et d'un seul modèle de gouvernance.

par Victoria Sicking et Jack Yallop

  • Les équipes de négoce d'énergie utilisent souvent des systèmes distincts pour le trading en direct et l'analytique, ce qui entraîne des données de risque obsolètes, une gouvernance dupliquée et une charge de synchronisation.
  • Databricks exécute le tout sur une seule plateforme. Spark Structured Streaming Real-Time Mode diffuse en continu les données de marché dans Lakebase, un serveur PostgreSQL sans serveur pour les applications et les agents. Ces données alimentent l'application de trading en direct, les modèles de machine learning, les tableaux de bord et Genie One, un outil de requête en langage naturel.
  • Unity Catalog, la couche de gouvernance de Databricks, contrôle l'ensemble depuis un emplacement unique. Les autorisations, le lignage et l'audit sont configurés une seule fois au lieu de l'être pour chaque système.

Pourquoi le trading d'énergie en temps réel a-t-il besoin de plus que de simples données plus rapides ?

Les services de trading d'énergie opèrent sur des marchés où les conditions changent rapidement et où les décisions se prennent en quelques millisecondes. Deux évolutions compliquent la tâche : une plus forte volatilité des prix et le passage du marché journalier de l'électricité de l'UE d'intervalles horaires à des intervalles de 15 minutes. Cette unité de temps de 15 minutes fait partie du couplage d'un jour à l'avance (Single-Day Ahead Coupling ou SDAC), le système qui relie les marchés de l'électricité de la veille pour le lendemain dans tous les pays de l'UE. Cela multiplie par quatre le nombre de périodes de marché par heure et augmente le volume des enregistrements, des ordres et des recalculs de risques. Pour garantir la précision de ces calculs, il faut des données actualisées, ce qui dépend directement de la manière dont elles sont stockées et gouvernées, et pas seulement de leur vitesse d'arrivée.

Pour un service de trading, des données obsolètes ne sont pas qu'un simple inconvénient. Elles peuvent fausser les contrôles de risques en les basant sur un état antérieur du marché, contribuer à rater des mouvements intrajournaliers et désynchroniser les limites du desk par rapport aux positions actuelles.

De nombreuses organisations optent pour deux environnements distincts. Un système opérationnel prend en charge le desk en direct et les transactions à la milliseconde. Un système analytique séparé gère le backtesting des stratégies, le machine learning et les rapports réglementaires. Cette séparation répond à deux charges de travail différentes, mais elle génère quatre problèmes récurrents :

  • Deux versions de la vérité
  • Un décalage de fraîcheur dans les contrôles de risques
  • Une gouvernance et une traçabilité en double
  • De multiples pipelines de synchronisation entre les différents systèmes

Le machine learning ajoute une dépendance supplémentaire. Les modèles ont besoin de données historiques pour l'entraînement, mais leurs résultats doivent être disponibles dans le flux de trading en direct. Transférer des modèles et des données entre des systèmes séparés complexifie un processus déjà soumis à des contraintes de temps. L'alternative consiste à adopter une plateforme unifiée pour les données, l'analytique et l'IA – une plateforme qui diffuse les données en temps réel avec une latence de l'ordre de la milliseconde via Real-Time Mode streams et que Lakebase Postgres tient prêtes – afin que le desk en direct et le pipeline de modèles puisent dans la même source sans étape de transfert supplémentaire.

Comment exécuter des charges de travail opérationnelles et analytiques conjointement sur Databricks ?

Les charges de travail opérationnelles et analytiques s'exécutent ensemble en partageant un socle de données unique. La solution présentée ci-dessous par Victoria Sicking, architecte de solutions chez Databricks, décrite dans 'Run Live Energy Trading, Risk, and Analytics in Databricks', combine six composants sur la plateforme Databricks Data + AI Platform. Le choix de conception clé réside dans le fait qu'aucun composant ne conserve sa propre copie isolée des données. Tous fonctionnent à partir de ce que Spark Structured Streaming Real-Time Mode a écrit dans Lakebase et le lakehouse.

  • Spark Structured Streaming Real-Time Mode pour le traitement d'événements continus avec une latence de l'ordre de la milliseconde
  • Lakebase, un service Postgres sans serveur pour les applications et les agents, servant de base de données opérationnelle
  • Databricks Apps pour l'interface de trading en direct.
  • Des modèles de machine learning pour les prévisions de prix en temps réel et les signaux de trading.
  • Genie One pour l'analyse historique.
  • Unity Catalog pour la gouvernance de l'ensemble du workflow.

Spark Structured Streaming Real-Time Mode reçoit les données de marché et les diffuse en streaming dans Lakebase, utilisé ici comme base de données opérationnelle (OLTP) pour des lectures, des transactions et des mises à jour (upserts) en millisecondes. Ces mêmes données peuvent ensuite alimenter les charges de travail analytiques basées sur le lakehouse.

Les équipes n'ont plus besoin de coordonner des pipelines parallèles, l'un pour le desk en direct et l'autre pour le backtesting et le reporting. Le temps auparavant consacré à la réconciliation et à la coordination est libéré grâce à la création d'un point d'ingestion unique dans votre patrimoine de données pour les informations de marché et de position. Unity Catalog – la couche de gouvernance Databricks pour les autorisations, la traçabilité et l'audit – applique cette gouvernance aux applications, à la Business Intelligence et aux charges de travail de machine learning, évitant ainsi de les configurer indépendamment dans plusieurs systèmes.

À quoi ressemble un desk de trading d'énergie en direct dans Databricks Apps ?

Il se présente sous la forme d'une application unique affichant les prix, les positions, les profits et pertes (P&L) et les risques, le tout se mettant à jour au rythme des mouvements du marché. L'expérience en direct s'appuie sur Databricks Apps – la solution pour créer et héberger des applications de données, telles qu'une interface de trading en direct, sur la plateforme. Elle rassemble tout ce dont un desk a besoin pour surveiller le marché et réagir aux conditions changeantes, les données étant servies directement depuis Lakebase. Le desk lit ainsi en permanence les mêmes données gouvernées qui alimentent les charges de travail analytiques, sans nécessiter de copie opérationnelle séparée.

La démo affiche les prix des instruments pour le brut Brent, les marchés spot de l'électricité en Allemagne et en France, le taux de change EUR/USD, les quotas d'émission de l'UE (quotas d'émission de gaz à effet de serre ou EUA) et le gaz TTF.

Le risque est surveillé par rapport aux limites du desk au sein du même workflow. Lorsqu'une mesure s'approche d'un seuil critique, l'application génère une alerte de risque afin que le desk puisse voir le changement et réagir immédiatement. Cela remplace un processus par lots nocturne qui calculait le risque à partir d'un instantané antérieur des données.

L'application n'est pas une surface de reporting déconnectée de la plateforme de données. Lakebase fournit la couche opérationnelle sous l'application, et le pipeline de streaming maintient les informations à jour.

Comment générer des signaux de trading à partir des mêmes données ?

Entraînez des modèles de machine learning sur les mêmes données gouvernées qui alimentent le desk en direct, suivez leur développement et leur traçabilité avec MLflow, et déployez les versions validées via Databricks Model Serving. Leurs résultats peuvent ensuite s'afficher directement dans l'application.

Les équipes de trading d'énergie ont besoin de modèles capables d'anticiper les risques et d'identifier des signaux de trading potentiels. Centraliser l'ensemble sur une copie de données unique, gouvernée et unifiée supprime les frictions de transfert entre un système d'entraînement et un système de production : le modèle voit exactement la même chose que le desk.

La démo présente une prévision de prix en temps réel susceptible de contribuer à un signal de trading. Le chemin entre les données utilisées pour entraîner un modèle et le workflow qui consomme ses résultats s'en trouve raccourci. Le machine learning devient partie intégrante du workflow de trading de bout en bout, plutôt qu'un système tiers intercalé entre les environnements en direct et analytiques.

Ces mêmes données gouvernées peuvent également alimenter l'analyse des risques et le développement de modèles. Les charges de travail opérationnelles et analytiques restent connectées, et les équipes n'ont pas besoin de réconcilier des versions de données divergentes a posteriori.

Comment les analystes peuvent-ils obtenir une vue historique sans multiplier les copies de données ?

Les analystes utilisent un tableau de bord intégré et Genie One, tous deux construits sur le même socle de données que l'application en direct. Le tableau de bord intégré présente les données de trading historiques, y compris le nombre total de transactions, le volume échangé et des comparaisons entre traders.

Pour aller plus loin, les analystes peuvent utiliser SQL, Python ou Spark. Ils peuvent aussi utiliser Genie One – l'interface en langage naturel de Databricks pour interroger les données gouvernées – sans avoir à écrire eux-mêmes les requêtes. Dans la démo, l'analyste demande à Genie One d'identifier les cinq principales contreparties par nombre de transactions et de comparer le volume d'achat total au volume de vente pour chacune d'elles.

Genie One fonctionne au sein du workspace Databricks et s'appuie sur le contexte des données disponibles ainsi que sur la sémantique définie pour répondre. Les analystes peuvent passer d'une vue de tableau de bord offrant des insights figés à une analyse sur mesure des données tout en restant dans le même environnement gouverné. Une copie unifiée des données garantit que les résultats concordent entre le desk en direct et le back-office analytique.

Quelle est l'architecture, du flux de marché aux insights gouvernés ?

Les données circulent d'un flux de marché vers l'application, l'analytique et le machine learning en passant par le streaming et Lakebase, le tout sous la gouvernance d'Unity Catalog. Comme Unity Catalog s'étend à tous les composants, les autorisations, la traçabilité et l'audit applicables au desk en direct s'appliquent également aux tableaux de bord, à Genie One et au machine learning. Tout est configuré une seule fois, sans qu'il soit nécessaire de le dupliquer dans chaque système. Les étapes sont les suivantes :

  1. Un flux de marché, tel que ICE, APEX ou un flux Kafka, fournit les événements source.
  2. Spark Structured Streaming Real-Time Mode traite les données entrantes en continu.
  3. Lakebase fait office de récepteur Postgres géré et de base de données opérationnelle pour le desk en direct.
  4. Les équipes qui souhaitent créer des couches analytiques et exécuter des analyses historiques ou du backtesting peuvent désormais s'appuyer sur ces données dans le lakehouse.
  5. Databricks Apps utilise les données opérationnelles pour présenter les prix en direct, les positions, les profits et pertes (P&L), les risques, les alertes et les résultats des modèles.
  6. Les tableaux de bord intégrés et Genie One prennent en charge l'analyse historique et les questions relatives à l'activité de trading.
  7. Les modèles de machine learning utilisent les mêmes données pour produire des prévisions de prix et des signaux de trading.
  8. Unity Catalog applique la gouvernance à l'ensemble des flux de travail des applications, des analyses et du machine learning.

Le desk en direct, les analyses et les charges de travail de machine learning ne constituent pas des destinations distinctes nécessitant des transferts répétés de données. Il s'agit de différentes manières de travailler avec les mêmes données gouvernées.

Que doivent prendre en compte les équipes lors de l'évaluation de cette architecture ?

La question est de savoir si les exigences opérationnelles et analytiques doivent être desservies par des systèmes déconnectés avec des copies distinctes, des modèles de gouvernance et une logique de synchronisation. Ils ont certes des exigences différentes, mais une seule plateforme peut répondre aux deux, et la consolidation sur une copie unique et gouvernée des données garantit que le desk, les modèles de risque et la couche de reporting sont toujours parfaitement synchronisés.

Lorsque ces charges de travail s'exécutent sur des systèmes séparés, les contrôles des risques peuvent dépendre de données par lots, les modèles peuvent être entraînés sur des informations qui ne correspondent pas au système en direct, et la gouvernance, le lignage et les pipelines de synchronisation doivent être maintenus à plusieurs reprises.

La solution Databricks Energy Trading rassemble ces fonctionnalités sur une seule base de données gouvernée. Grâce à cette configuration, les équipes peuvent évaluer les risques à mesure que le marché évolue tout en utilisant les mêmes données gouvernées pour les P&L, l'exposition, le backtesting, le machine learning, les tableaux de bord et l'analyse en langage naturel.

Pour en savoir plus sur la façon de commencer, visitez :

Foire aux questions

Quels problèmes les systèmes séparés peuvent-ils créer pour le trading d'énergie ?

Des systèmes séparés peuvent créer deux versions de la vérité, un décalage de fraîcheur dans les contrôles des risques, une gouvernance et un lignage en double, un travail de maintenance supplémentaire et des pipelines de synchronisation additionnels entre les systèmes. Le machine learning devient également plus difficile à gérer lorsque les modèles sont entraînés sur un système mais doivent s'exécuter sur un autre. Le maintien d'une copie unique, gouvernée et unifiée des données, dotée d'un ensemble unique de contrôles, élimine la plupart de ces coûts.

Pourquoi consolider les charges de travail opérationnelles et analytiques sur une seule plateforme pour le trading d'énergie ?

Les équipes de trading d'énergie peuvent exécuter le desk en direct, les risques, le machine learning et les analyses historiques sur une seule copie gouvernée des données dans Databricks. Spark Structured Streaming Real-Time Mode, Lakebase, Databricks Apps et Unity Catalog remplacent le second système et les contrôles en double.

Quel rôle joue Lakebase dans le trading d'énergie ?

Lakebase est une base de données Postgres entièrement gérée et native de la plateforme Databricks Data + AI Platform, utilisée ici comme base de données opérationnelle (OLTP) pour les lectures en millisecondes, les transactions et les mises à jour (upserts). Comme elle réside au sein de la même plateforme que le lakehouse, elle connecte les données opérationnelles aux charges de travail analytiques sur une copie unique et gouvernée des données, éliminant ainsi le besoin d'une base de données séparée en dehors de la plateforme.

Comment les traders peuvent-ils surveiller les risques à mesure que les conditions du marché évoluent ?

Une application de trading en direct construite sur Databricks Apps, la méthode permettant de créer et d'héberger des applications de données, telles qu'une interface de trading en direct, sur la plateforme, peut afficher les prix, les positions, les P&L et les risques au fur et à mesure de leur mise à jour. Des alertes de risque se déclenchent à mesure que les mesures s'approchent des limites du desk, permettant ainsi aux traders de réagir aux conditions actuelles au lieu de s'en remettre uniquement aux calculs par lots.

Comment les données sont-elles gouvernées avec Unity Catalog ?

Unity Catalog est la couche de gouvernance de Databricks pour les autorisations, le lignage et l'audit, offrant une seule couche de gouvernance à travers l'application opérationnelle, les analyses et les flux de travail de machine learning. Il gère de manière centralisée les autorisations, le lignage et l'audit de bout en bout, de sorte que les équipes configurent les contrôles une seule fois pour la copie unique de données plutôt que de reproduire une gouvernance distincte pour chaque système.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original

Tags associés:

Énergie, Lakebase, Genie, Unity Catalog et Databricks Apps

Recevez les derniers articles dans votre boîte mail

Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.