--- title: "Jump TradingがClickHouseとIcebergを組み合わせて分析に活用する方法" date: "2026-08-19T08:41:27.458Z" author: "ClickHouse" category: "User stories" excerpt: "Jump Tradingは、自社運用のClickHouseプラットフォーム上でペタバイト規模の金融取引ログを取り込んでおり、データロスゼロと低レイテンシが必須要件となっています。" --- # Jump TradingがClickHouseとIcebergを組み合わせて分析に活用する方法 ## 概要 * Jump Tradingは、金融取引ログをペタバイト規模で自社運用のClickHouseプラットフォームにキャプチャしており、データ損失ゼロと低レイテンシーが業界要件となっています。 * ClickHouseクラスターは1日あたり数百TBをp99でサブ20秒以内に取り込み、1日あたり数千億件のイベントにわたるリアルタイム分析を提供しています。 * Jumpは、ビジネスクリティカルなユースケース向けのリアルタイムクラスターから、バッチ分析(レポーティング、リサーチなど)を分離するために、並列のIcebergパイプラインでプラットフォームを拡張しました。 「ログは可観測性のためのものだと思われがちですが、私たちの場合はそれをはるかに超えたものなんです」と語るのは、シカゴを拠点とするトレーディング企業[Jump Trading](https://www.jumptrading.com/)のデータベースチームリードを務めるArnaud Adant氏だ。 Jumpは、シカゴを拠点に世界各地にオフィスを構える、データとリサーチを起点としたトレーディングビジネスのリーディングカンパニーである。同社にとってロギングプラットフォームはデバッグツールというよりも、むしろビジネスの正式な記録システム(system of record)として機能している。 [Open House SF 2026](https://clickhouse.com/openhouse/san-francisco)にて、Arnaud氏は、Jumpがどのようにセルフマネージドなクリックハウスプラットフォームを構築し、フルスケールのバッチエクスポートに対する需要をきっかけに、ユーザーが慣れ親しんだ高速な体験を損なうことなくApache Icebergで拡張していったのかを語った。 [Watch on YouTube](https://youtube.com/watch?v=UqN1y_ZLMcI) ## ペタバイト規模での低レイテンシ・ロスレスロギング Jumpにとって、膨大な量のログを保持することは、多くのリサーチや運用目的で不可欠ですが、そのスケールは大きな課題となります。単一のパーティションだけで、非圧縮で1日に数百TBを消費します。最大のテーブルでは、1日あたり1,000億件規模のイベントが保存されます。Jumpは分析のために長期の履歴をオンラインで保持しており、その結果、圧縮後でもペタバイト規模のデータになります。 さらにプラットフォームには速度も求められます。Jumpはp99を20秒未満に維持しており、これはイベントの99%がその時間内にデータベースに到達することを意味します。そして何一つ欠落が許されないため、ログは日次でソースと突合されます。 ## ClickHouseとの7年以上にわたる成功 7年以上にわたり、Jumpはオープンソースとしてのメリットを享受してきました。ClickHouseの絶え間ないパフォーマンス改善、[DateTime64](https://clickhouse.com/docs/sql-reference/data-types/datetime64) のような新しいデータ型、[Bloomフィルター](https://clickhouse.com/docs/optimize/skipping-indexes#bloom-filter-types) といった機能は、Jumpに大きな影響を与えてきました。「ClickHouseは速いだけではありません」と彼は言います。「その開発速度も時とともに加速していて、AIの登場によってそれをさらに実感しています。」 >「ClickHouseはオープンソースで、非常に高速です。テクノロジーから優れたパフォーマンスを引き出せると、少ないハードウェアでより多くのことができるので、多くのコストを節約できます。」 >— Arnaud Adant、Database Team Lead、JumpTrading Jumpのチームは、ClickHouseのユーザーであるだけでなく、ClickHouseオープンソースプロジェクトの積極的なコントリビューターでもあり、長年にわたり数多くの改善をアップストリームに貢献してきました。「商用の代替品ではそんなことはできなかったでしょう」とArnaudは語り、[ClickHouseコミュニティ](https://clickhouse.com/community) に還元しながら、自分たちのニーズに合わせてClickHouseをカスタマイズしていると強調します。 ## 「リアルタイム分析の教科書的な事例」 Jumpは大規模なノードを数十台備えたオンプレミスのClickHouseクラスタを運用しており、これはリアルタイム分析の教科書的な事例です。同チームは、高速なNVMeストレージ、SIMD命令をサポートするCPU、高速なメモリといったハードウェアを最大限に活用しながら、デフォルトで低レイテンシの取り込みを実現しています。「PostgresやMySQLのような他のデータベースでは、こうはいきません」とArnaudは述べています。 彼は、ClickHouseの2つの機能を挙げています。ひとつは、大量のファクトテーブルのシャーディングを処理する [分散テーブル](https://clickhouse.com/docs/engines/table-engines/special/distributed)、もうひとつは、参照データをクラスタの各ノードで利用可能にする [レプリケートテーブル](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replication) です。 生データは、数千のノードからのログが集まるRedpandaクラスタに投入されます。シャードされたベアメタルのインジェスタ群がそのストリームから読み取り、対応するClickHouseシャードに書き込みます。読み取り側では、ユーザーはロードバランサーを経由し、ランダムに選ばれたノードに対してクエリが実行されます。 以下の図は、JumpのClickHouse実装の概略を示しています。RedpandaがシャードされたインジェスタにデータをフィードしClickHouseに書き込み、読み取りはロードバランサー経由でルーティングされ、Keeperがレプリケーションとノード登録を担当します。 ![jump-clickhouse-implementation 1.jpg](https://clickhouse.com/uploads/jump_clickhouse_implementation_1_1c06fd00a1.jpg) ## Jump全体でデータ要件が拡大 このアーキテクチャはリアルタイム分析には十分機能していましたが、新たなエクスポート要件によって当初のスコープを超える必要が生じました。バッチジョブや、JumpのHPCインフラで動作するハイパフォーマンスコンピューティングのワークロードなど、他のリーダーからもリアルタイムでデータを利用できるようにする必要があったのです。 こうしたワークロードを同じリアルタイムクラスタから提供するのは適切ではありませんでした。スケールを実現するため、Jumpはコンピュートとストレージを分離し、オブジェクトストレージ上のParquetファイルへ移行して、各レイヤーを独立してスケーリングできるようにする必要がありました。 現在、プラットフォームでは異なる2種類のワークロードがサポートされています。ひとつは、高速なリーダーとライター、ピーク時に毎秒1,000万行の取り込み、20秒未満のp99を実現するリアルタイム分析。もうひとつは、より低速で重いリーダーが大量の結果セットを高スループットで取得する、レイテンシに対する許容度が高いバッチ処理です。 ## なぜIcebergなのか この第2のワークロードの追加により、JumpはIcebergを採用することになりました。Parquet上に構築されたオープンテーブルフォーマットであるIcebergは、スケーラブルな長期保持を提供し、Spark、Polars、DuckDBを含む複数のリーダーからデータにアクセスできるようにします。 Icebergが特にJumpのユースケースに魅力的だったのは、ClickHouseサーバーに似た振る舞いをするからです。テーブルはREST APIカタログに存在し、パーティション、ソートキー、統計情報、削除、Bloomフィルターといった馴染みのある概念を備え、圧縮も類似しています。 Jumpのチームは、新しいアーキテクチャをシンプルに保ちたいと考えました。[Netflixのダブルライトパイプライン](https://clickhouse.com/blog/netflix-petabyte-scale-logging) からインスピレーションを得て、Kafkaを唯一のエントリポイントとし、そこから並列パスに分岐する構成にしました。ひとつのコンシューマ群はリアルタイムのClickHouseクラスタに書き込み、もうひとつはIceberg Parquetファイルをオブジェクトストレージに書き出します。 このIcebergへの書き込みパスの多くは、ClickHouse自身が処理します。たとえば、[clickhouse-local](https://clickhouse.com/docs/operations/utilities/clickhouse-local) やClickHouse ServerはParquetファイルを直接S3に出力できます。さらに、[ClickHouseはIcebergの読み取りを完全にサポート](https://clickhouse.com/docs/engines/table-engines/integrations/iceberg) しているため、低レイテンシの取り込みを行うのと同じクラスタで、Icebergテーブルへのクエリも実行でき、ユーザーに統一されたデータビューを提供します。 次の図は、Jumpのダブルライトパイプラインを示しています。Kafkaが並列のコンシューマにデータをフィードし、IcebergとClickHouseに書き込むと同時に、ClickHouseがIcebergを直接読み取ります。 ![jump-double-write-pipeline 1.jpg](https://clickhouse.com/uploads/jump_double_write_pipeline_1_35ef929405.jpg) この統合は必須要件でした。Jumpは、チームがIcebergとClickHouseの間をシームレスに切り替えて、同じクエリを両方のシステムで実行しつつ、ビジネス要件に応じて異なるレイテンシとパフォーマンス特性を得られるようにしたいと考えていました。 >「ClickHouseなら、その最高の機能がすべてIcebergにも持ち込まれます。」 >— Arnaud Adant、Database Team Lead、Jump Trading IcebergをClickHouseと統合することで、Jumpは [Keeper](https://clickhouse.com/docs/guides/sre/keeper/clickhouse-keeper)、[レプリケーション](https://clickhouse.com/docs/architecture/replication)、[ディクショナリ](https://clickhouse.com/docs/dictionary)、[分散テーブル](https://clickhouse.com/docs/engines/table-engines/special/distributed) といったClickHouseのコア機能を引き続き利用できます。Icebergテーブルはシャーディングでき、必要に応じて単一の分散ビューを通じて公開できます。[アクセス制御](https://clickhouse.com/docs/operations/access-rights) は、同じユーザー、ロール、行ポリシーで両システム間で一貫性を保ちます。ClickHouseの [システムテーブル](https://clickhouse.com/docs/operations/system-tables) や [オブザーバビリティ](https://clickhouse.com/docs/use-cases/observability) 機能も引き継がれます。 このデモでは、Jump が ClickHouse と、Iceberg を読み取る ClickHouse の両方でクエリを実行する様子を示しています。上部では、Jump が 18兆行と 40 ノードで ClickHouse クラスタを稼働させている様子が、下部では、最新の Iceberg バージョンと 20 ノードで ClickHouse を稼働させている様子が示されています。 ## ClickHouse は高速で、その進化はさらに加速している 20 ノードの Iceberg 環境で行ったある実験では、`GROUP BY` クエリ(意図的にメタデータのショートカットを使わないもの)が 3,760 億行、109.5 TB のデータを 9.6 秒で処理しました。これはおよそ毎秒 400 億行に相当します。 ベンチマークは、ClickHouse が時間の経過とともに高速化していくという Jump の実感も裏付けました。さまざまなクエリのコールドランおよびホットランを通じて、ClickHouse の各バージョンでは実行時間が着実に短縮される傾向が見られました。たとえば、あるクォンタイルクエリでは、[ClickHouse 25.12](https://clickhouse.com/blog/clickhouse-release-25-12) の 13.5 秒から 26.2 では 8.5 秒へと性能が向上しました。このロードマップは、[ClickHouse と Iceberg を組み合わせる](https://clickhouse.com/blog/climbing-the-iceberg-with-clickhouse)ことで、現在および将来において何が可能になるかを垣間見せてくれます。 >「ClickHouse から Iceberg にクエリを実行するのは非常に高性能です。ClickHouse が今日単一プロセスで実行していることを、Iceberg 上で分散的に実行できるようになると考えています。Iceberg はどこでも採用されている標準なので、それは素晴らしいことになるでしょう。」 — Arnaud Adant、Database Team Lead、Jump Trading *Jump Trading のようなデータドリブンなチームが、リアルタイム分析とバッチワークロードのために ClickHouse と Iceberg を組み合わせている理由をぜひご確認ください。[ClickHouse Cloud を 30 日間無料で試す](https://clickhouse.com/cloud)。* --- ## 今すぐ始める ClickHouseが実際のデータでどのように動作するか興味がありますか？ClickHouse Cloudなら数分で始められ、$300の無料クレジットも受け取れます。 [サインアップ](https://console.clickhouse.cloud/signUp?loc=blog-cta-1592&utm_blogctaid=1592) ---