金融市場の最前線では、1秒、いやミリ秒の遅れが莫大な機会損失に繋がりかねません。特に、高頻度取引（HFT）の世界では、リアルタイム市場データに基づくいち早い意思決定が成功の鍵を握ります。
本記事では、Databricksが開催したイベントでの講演「Real-Time Market Insights — Powering Optiver’s Live Trading Dashboard with Databricks Apps and Dash」の内容を基に、世界有数のHFT企業であるOptiverが、いかにしてデータ基盤を刷新し、リアルタイム取引ダッシュボードのパフォーマンスを劇的に向上させたか、その技術的な挑戦と解決策を深掘りします。講演者はOptiverのエンジニアとして紹介されました。
リアルタイム市場データと高頻度取引(HFT)の重要性
Optiverはオランダ発祥のグローバルな電子トレーディング企業であり、市場で流動性を提供するマーケットメーカーとして知られています。マーケットメーカーとは、株式や先物などの金融商品に対して常に買い（ビッド）と売り（アスク）の価格を提示し続けることで、市場に流動性を供給する重要な役割を担います。
講演では、Optiverが「あらゆる市場環境で常に取引に応じる」ことを信条とし、市場が乱高下する局面でも、取引が閑散としている局面でも価格を提示し続けることで、他の投資家がいつでも取引相手を見つけられる仕組みを支えている点が強調されました。
このようなビジネスを成功させるためには、データに基づいた迅速かつ正確な意思決定が不可欠です。「どの戦略がどれだけ利益を上げているか」「次のビジネス機会はどこにあるか」「規制を遵守できているか」といった問いに答えるため、彼らはペタバイト規模のデータを活用しています。
Databricks導入前の課題：オンプレミス環境の限界
Databricks導入以前、Optiverのデータ環境は多くの課題を抱えていました。次のような状況がボトルネックとなっていたといいます。
- 分散したデータ: 複数の国やデータセンターにまたがるデータベースに散在し、一元的な分析が困難。
- 分析に不向きなDB: 多くのデータベースは業務処理用途に最適化されており、インサイトを得るためのクエリ実行には向いていない。
- 開発プロセスの断絶: リサーチャーがPythonでプロトタイプを開発しても、本番環境で稼働させるにはC++に書き直す必要があり、イテレーションの速度が著しく低下していた。
この環境では、新しいダッシュボードを作るにも専門エンジニアのサポートが必須で、すべてが遅く、困難に感じられたと振り返っています。
Databricksがもたらした「ダッシュボード革命」
約1年前にDatabricksを導入したことで、状況は一変しました。社内では「ダッシュボード革命」と呼ばれる現象が起こり、これまで専門家でなければ不可能だったダッシュボード構築が、トレーダーやリサーチャー自身の手で簡単に行えるようになったのです。SQLさえ書ければ誰でもデータを探索し、独自のインサイトを可視化できるようになった結果、ダッシュボードの利用は爆発的に増加しました。
しかし、この成功は新たな課題をもたらしました。当初は分析目的だったダッシュボードが徐々に「ライブ用途」で使われるようになり、レイテンシと信頼性が極めて重要な要件となったのです。1秒ごとに更新される多数のダッシュボードがインフラに大きな負荷をかけ、パフォーマンス低下が顕著となり、Optiverはデータパイプラインの抜本的な見直しに着手しました。
データ取り込みの最適化：分単位から秒単位への挑戦
最初の改善対象はデータ取り込み部分です。目標は、エンドツーエンドでのシングルデジット秒（数秒）のレイテンシ実現でした。
従来はC++アプリがKafkaからデータを取得し、S3にファイルを配置、それをDatabricksのAuto Loaderが読み込んでDeltaテーブルに書き込む流れで、スループット重視の構成でした。これを、特にレイテンシが重要なデータセットでは、Apache SparkのStructured StreamingジョブがKafkaから直接データを読み込む構成に変更。中間ステップを省略し、データがDatabricksに到達するまでの時間を大幅に短縮しました。
さらに、Spark性能を引き出すために以下を実施しました。
- パーティション数の最適化: KafkaとSparkのパーティションマッピングを調整し、並列度とリソース活用を向上。
- フェッチサイズ増加: Kafkaから取得するデータ量を増やし、ラウンドトリップ回数を削減。
- Optimized Writeの無効化: 書き込み前の圧縮・結合作業を抑え、Auto Compactionでバランスを最適化。
これにより、データ取り込みレイテンシは数分から数秒へと劇的に改善しました。
ダッシュボードの最適化：Databricks AppsとDashによる高速化
可視化側でも大きなアーキテクチャ変更を実施。OptiverはDatabricks Apps上でPlotly社のDashを用いたカスタムアプリを構築しました。Databricks Appsによりインフラ管理の手間を省きつつ、クラウドのスケーラビリティと統合セキュリティを活用できる点が魅力です。
アドホックSQLを選んだ理由
Optiverはデータを事前集計するのではなく、ダッシュボード上で都度SQLクエリを実行するアドホッククエリ方式を採用しました。その理由はポイント三つです。
- ユーザーフレンドリー: トレーダーやリサーチャーが慣れ親しんだSQLでロジックを記述・変更できる
- 柔軟性: ダッシュボードの入力パラメータに応じて動的にクエリを生成可能
- パフォーマンス: Databricksの強力なキャッシュ機能とPhotonクエリエンジンにより、アドホッククエリでも再実行が高速
Photonは動的フィルタ（Bloom Filterなど）で不要データのスキャンやシャッフルを回避し、巨大なテーブル結合でも必要なデータのみを効率処理します。
ゼロコピー処理を支える最新技術スタック
フロントエンド描画性能向上のため、以下技術も組み合わせました。
- CloudFetch: Databricks SQL Warehouseから大規模結果をストリーミング
- Polars: Rustベースの超高速DataFrameライブラリ、ゼロコピー処理が特徴
- Apache Arrow: コンポーネント間で効率的かつゼロコピーにデータ受け渡し
- Narwals: DashでPolarsなど多様なDataFrameライブラリを扱える抽象化レイヤー
これにより、Arrow形式のデータをPolarsで高速加工し、そのままDashで可視化。変換やメモリコピーのオーバーヘッドがほぼなくなり、高速かつ滑らかなユーザー体験を実現しました。
結果と今後の展望
一連の最適化により、Optiverは目標のシングルデジット秒（数秒）のエンドツーエンドレイテンシを達成。トレーダーは迅速に市場トレンドを把握し、効率的に意思決定できるようになり、ユーザーからも高い評価を得ています。
この事例は、HFTという極めて要求の厳しいドメインにおいて、クラウドネイティブなデータプラットフォームが強力な武器となり得ることを示しています。特に、Photonエンジンによるクエリ最適化、Databricks Appsの柔軟なアプリホスティング、Apache Arrowを中心としたオープンエコシステム連携が成功の鍵でした。リアルタイム分析基盤構築を目指す企業にとって、Optiverの挑戦と得られた知見は貴重な示唆となるでしょう。
