Databricksがどのように1つのプラットフォームと1つのガバナンスモデルで、リアルタイムのエネルギー取引、リスク監視、機械学習、そして過去のデータ分析を統合するかご覧ください。
によって Victoria Sicking 、 Jack Yallop による投稿
エネルギーのトレーディングデスクは、状況が急速に変化し、ミリ秒単位で意思決定が行われる市場で活動しています。この状況をさらに難しくしている要因として、価格変動の激化と、EUの電力スポット市場における取引間隔の1時間ごとから15分ごとへの移行という2つの変更が挙げられます。15分のマーケットタイムユニットは、EU各国のスポット電力市場を結ぶシステムである単一デーアヘッド・カップリング（SDAC）の一部です。これにより、1時間当たりのマーケット期間が4倍に増え、レコード、注文、リスク再計算のボリュームが増加します。これらの計算を正確に保つためには、データの到着速度だけでなく、データがどのように保存され、ガバナンスがどのように効いているかという点が直接関わってきます。
古いデータは、トレーディングデスクにとって単なる不便以上の問題です。リスク管理が市場の過去の状態を反映してしまったり、イントラデイ（日中）の動きを見逃す原因になったり、デスクのリミットが現行のポジションとズレてしまったりする可能性があります。
多くの組織は2つのシステムスタックでこれに対応しています。1つは、ライブのデスクとミリ秒単位のトランザクションをサポートするオペレーショナルシステムです。もう1つは、戦略のバックテスト、機械学習、規制報告をサポートする別個の分析システムです。この分割は2つの異なるワークロードに対応するものですが、次の4つの繰り返される問題を生み出しています。
機械学習はさらに別の依存関係を追加します。モデルにはトレーニング用の履歴データが必要ですが、その出力はライブの取引ワークフローで利用できなければなりません。別々のシステム間でモデルやデータを移動させると、ただでさえ時間的制約の厳しいプロセスに複雑さが加わります。その代替案となるのが、データ、アナリティクス、AIのための統合プラットフォームです。Real-Time Mode streamsがミリ秒単位のレイテンシーでストリーミングし、Lakebase Postgresが待機させることで、ライブのデスクとモデルパイプラインの両方が、余分な転送ステップなしに同じソースからデータを取得できるようになります。
オペレーショナルワークロードと分析ワークロードは、1つのデータ基盤を共有することで同時に実行できます。DatabricksのソリューションアーキテクトであるVictoria Sicking氏が'Run Live Energy Trading, Risk, and Analytics in Databricks'の中で紹介している以下のソリューションは、Databricks Data + AI Platform上の6つのコンポーネントを組み合わせたものであり、どのコンポーネントもデータの独自のコピーを個別に保持しないという点が重要な設計上の選択となっています。これらはすべて、Spark Structured Streaming Real-Time ModeがLakebaseおよびレイクハウスに書き込んだデータに基づいて動作します。
Spark Structured Streaming Real-Time Modeが市場データを受信し、Lakebaseにストリーミングします。Lakebaseはここではミリ秒単位の読み取り、トランザクション、アップサートを行うオペレーショナル（OLTP）データベースとして使用されます。同じデータを使って、レイクハウス上に構築された分析ワークロードをサポートすることも可能です。
チームは、ライブデスク用とバックテスト・レポート用の並行パイプラインを調整する必要がなくなります。市場データやポジションデータのための単一の取り込みパスウェイをデータエステート内に作成することで、これまで突合せや調整に費やされていた時間を削減できます。Unity Catalog（権限、リネージ、監査のためのDatabricksガバナンスレイヤー）は、アプリ、ビジネスインテリジェンス、機械学習の各ワークロードにガバナンスを適用するため、複数のシステムでそれぞれ個別に設定する必要がなくなります。
価格、ポジション、損益（P&L）、リスクを表示し、市場の動きに合わせてすべてがリアルタイムで更新される単一のアプリケーションとして表示されます。ライブのエクスペリエンスは、ライブ取引インターフェースなどのデータアプリケーションをプラットフォーム上で構築・ホストするための機能であるDatabricks Apps上に構築されています。これにより、デスクが市場を監視し、変化する状況に対応するために必要な機能が統合されます。データはLakebaseから直接提供されるため、分析ワークロードに供給されるのと同じガバナンスの効いたデータソースから常に読み取ることができ、個別のオペレーショナルコピーは必要ありません。
このデモでは、ブレント原油、ドイツおよびフランスの電力スポット、ユーロ/米ドルの換算、EU排出枠（EUA）、TTFガスの商品価格が表示されます。
リスクは、同じワークフロー内でデスクのリミットに対して監視されます。測定値がリミットに近づくと、アプリがリスクアラートを発生させ、デスクが変化を確認して即座に対応できるようにします。これにより、以前のスナップショットデータからリスクを計算する夜間バッチプロセスが置き換えられます。
このアプリケーシ ョンは、データプラットフォームから切り離された単なるレポート画面ではありません。Lakebaseがアプリの背後にあるオペレーショナルレイヤーを提供し、ストリーミングパイプラインが情報を常に最新の状態に保ちます。
ライブデスクをサポートするのと同じガバナンスの効いたデータで機械学習モデルをトレーニングし、MLflowでその開発とリネージを追跡し、承認されたバージョンをDatabricks Model Servingを通じてデプロイします。これにより、その出力をアプリ内に直接表示させることができます。
エネルギー取引チームには、リスクを予測し、潜在的な取引シグナルを特定できるモデルが必要であり、ガバナンスの効いた単一の統合されたデータのコピー上で実行することで、トレーニングシステムとライブシステム間の引き継ぎが不要になります。モデルはデスクが見ているものと全く同じデータを見ることができます。
デモでは、取引シグナルの材料となるリアルタイムの価格予測が示されています。モデルのトレーニングに使用されたデータと、その出力を利用するワークフローとの間のパスが短縮されます。機械学習は、ライブスタックと分析スタックの間に位置する別個のシステムではなく、エンドツーエンドの取引ワークフローの一部となります。
同じガバナンスの効いたデータは、リスク分析やモデル開発もサポートできます。オペレーショナルワークロードと分析ワークロードが接続された状態を維持できるため、チームは後からデータの異なるバージョンを突合せする必要がなくなります。
アナリストは、ライブアプリと同じデータ基盤上に構築された、埋め込みダッシュボードとGenie Oneを使用します。埋め込みダッシュボードには、総取引数、取引量、トレーダー間の比較などの過去の取引データが表示されます。
より詳細な分析を行うために、アナリストはSQL、Python、Sparkを使用できます。また、ガバナンスの効いたデータに対して質問するためのDatabricksの自然言語インターフェースであるGenie Oneを使用すれば、自分でクエリを書く必要がありません。デモでは、アナリストがGenie Oneに取引数上位5社のカウンターパーティを特定し、それぞれについて総買いボリュームと売りボリュームを比較するように依頼しています。
Genie OneはDatabricksワークスペース内で動作し、利用可能なデータのコンテキストと定義されたセマンティクスを使用して回答します。アナリストは、固定されたインサイトを提供するダッシュボードビューから、同じガバナンス環境を維持したまま、データに対するカスタム分析へと移行できます。データのコピーが統合されているため、ライブデスクと分析バックオフィスの間で結果が一致します。
マーケットフィードからガバナンスの効いたインサイトまでのアーキテクチャはどうなっているか？
データは、マーケットフィードから、ストリーミングおよびLakebaseを経由して、アプ リ、アナリティクス、機械学習へと流れ、すべてUnity Catalogのガバナンスのもとで管理されます。Unity Catalogがすべてのコンポーネントにまたがっているため、ライブデスクに適用される権限、リネージ、監査は、ダッシュボード、Genie One、機械学習にも適用されます。これらはシステムごとに個別に設定されるのではなく、1回設定するだけです。手順は以下の通りです。
ライブデスク、分析、機械学習のワークロードは、データのコピーを何度も行う必要がある別々の場所にあるわけではありません。これらは、ガバナンスの効いた同じデータを活用するための異なるアプローチにすぎません。
運用要件と分析要件を、それぞれ異なるデータのコピー、ガバナンスモデル、同期ロジックを持つ分断されたシステムで処理する必要があるかどうかがポイントになります。要件自体は異なりますが、1つのプラットフォームで両方に対応することが可能です。ガバナンスの効いた1つのデータコピーに統合すれば、デスク、リスクモデル、レポートレイヤーの間でデータのズレが生じることはなくなります。
これらのワークロードを別々のシステムで実行すると、リスク管理がバッチデータに依存するようになったり、ライブシステムとは一致しない情報でモデルがトレーニングされたり、ガバナンス、リネージ、同期パイプラインを何度も保守しなければならなくなります。
Databricks Energy Trading ソリューションは、ガバナンスの効いた単一のデータ基盤上でこれらの機能を統合します。このセットアップにより、チームは市場の動きに合わせてリスクを評価しながら、損益、エクスポージャー、バックテスト、機械学習、ダッシュボード、自然言語分析で同じガバナンス済みデータを利用できるようになります。
始め方についての詳細は、以下をご覧ください。
システムを分けると、真実のデータが2つ存在することになり、リスク管理におけるデータの鮮度のギャップ、重複するガバナンスとリネージ、追加の保守作業、システム間の余分な同期パイプラインが生じます。また、一方のシステムでモデルをトレーニングし、別のシステムで実行しなければならない場合、機械学習の管理もより複雑になります。統制の効いた単一のデータのコピーを維持し、一貫したコントロールセットを使用することで、こうしたコストの大部分を削減できます。
エネルギー取引チームは、ライブデスク、リスク、機械学習、履歴分析を、Databricks内のガバナンスの効いた単一のデータコピー上で実行できます。Spark Structured Streamingリアルタイムモード、Lakebase、Databricks Apps、Unity Catalogにより、2つ目のシステムや重複するコントロールが不要になります。
Lakebaseは、Databricks Data + AI Platform ネイティブのフルマネージドPostgresデータベースであり、ここではミリ秒単位の読み取り、トランザクション、アップサートを行うための運用（OLTP）データベースとして使用されます。レイクハウスと同じプラットフォーム内に存在するため、プラットフォーム外に別のデータベースを用意する必要なく、ガバナンスの効いた単一のデータコピー上で運用データを分析ワークロードと結びつけることができます。
Databricks Apps上に構築されたライブ取引アプリケーション（プラットフォーム上でデータアプリを構築およびホストする方法。例えばライブ取引インターフェースなど）を活用すれば、価格、ポジション、損益、リスクの更新内容をリアルタイムで表示できます。測定値がデスクの制限値に近づくとリスクアラートがトリガーされるため、トレーダーはバッチ計算だけに頼ることなく、現在の状況に対応できます。
Unity Catalogは、権限、リネージ、監査を管理するDatabricksのガバナンスレイヤーであり、運用アプリ、 分析、機械学習のワークフロー全体にわたって単一のガバナンスレイヤーを提供します。エンドツーエンドで集中化された権限、リネージ、監査を維持するため、システムごとに個別のガバナンスを再現する必要がなくなり、データの単一コピーに対するコントロールを一度設定するだけで済みます。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。