ClickHouseで160億行の市場履歴データを扱う設計

ClickHouseは、金融市場の履歴データベース（HDB）をClickHouseで構成する技術例を公開しました。Binanceの公開データを使い、取引と気配の保存、圧縮、VWAP、ローソク足、時点結合をSQLで処理しています。

要点

• リアルタイム売買経路ではなく、調査、バックテスト、取引費用分析、規制対応に使う履歴層を対象にしています。
• 10カ月分、約162億行の取引・気配データを76GiBまで圧縮したとしています。
• (symbol, ts)の並び順と疎な主索引により、銘柄と時間を限定する問い合わせで大部分のデータを読み飛ばします。
• 公開データを使った技術例であり、実際の市場データ契約、完全性、訂正処理、災害復旧までは扱っていません。

今回のブログ記事で語られていること

記事は、市場データ基盤を当日のライブデータを処理するリアルタイム層と、過去データを長期保存する履歴層に分けます。マイクロ秒単位の応答が求められる売買経路に新しいデータベースを入れるより、用途と問い合わせが既知である履歴層の方が移行検証を始めやすいという立場です。履歴データは、調査、バックテスト、取引費用分析、過去時点の再構成に使われます。例ではBinanceが公開するUSD建て無期限先物の取引と最良気配を取り込み、BTC、ETH、SOL、BNB、XRPの5銘柄を扱っています。

ClickHouseがこの用途に向く理由として、列指向の保存とSQLを挙げています。銘柄のように種類が少ない列はLowCardinalityの辞書で圧縮し、連続して増えるタイムスタンプや取引IDにはDoubleDeltaを使います。価格は緩やかに変化し、銘柄名は大量に反復するため、市場履歴データは列ごとの圧縮が効きやすい構造です。1カ月分では数億件の取引と約20億件の気配をローカル環境へ読み込み、VWAPや時間単位の始値・高値・安値・終値を通常のSQL集計で求めています。

取引と、その直前に観測された気配を結び付ける処理にはASOF JOINを使います。これは取引時刻と完全に同じ行を探すのではなく、その時点以前で最も新しい気配を対応させる結合です。記事では1分間を秒単位に分け、約定価格と提示価格の差であるスリッページを調べています。専用言語ではなくSQLでVWAP、ローソク足、時点結合を書けるため、特定の時系列データベースだけを扱える人へ分析が集中しにくいという主張です。

規模を10カ月へ広げた検証では、元の圧縮ファイル162GiB、CSV換算で約1.46TBのデータから、取引約31億行と気配約130億行、合計約162億行を76GiBへ収めたとしています。銘柄と時刻をORDER BY (symbol, ts)で並べることで、1分間のBTCデータを調べる問い合わせでは、取引側と気配側のごく一部のデータブロックだけを読みます。記事中のストレージ費用計算には金額表記の不一致があるため、費用値はそのまま予算へ使わず、最新料金と実際の圧縮後容量から計算し直す必要があります。

この結果が示すのは、銘柄と時間で絞る典型的な履歴分析で索引と圧縮が機能することです。全銘柄・全期間を走査する問い合わせ、データ訂正、取引所間の時刻同期、配当や銘柄変更などの参照データ、権利契約、可用性は別の設計課題です。既存HDBを置き換える判断には、代表クエリだけでなく、遅延分布、同時実行、追加入力、再計算、バックアップからの復旧も含めた比較が必要です。

今回のブログ記事が関係する人

市場データ基盤の開発者、バックテストや取引費用分析を行うクオンツ・分析担当、時系列データベースの運用費を見直す基盤チーム、大規模履歴データをSQLで開放したいデータ管理者に関係します。

結局、今回のブログ記事をどう読むべきか

ClickHouseがあらゆる市場データ処理を置き換えるという実証ではなく、履歴層から評価を始めるための再現可能な例です。自社評価では、銘柄と時刻で絞る処理だけでなく、広い走査、遅着・訂正データ、同時利用、監査用の再現性まで試す必要があります。