ClickHouse BUILD シリーズ

動きを追う。
理由を語る。

2 時間で、公開されている予測市場のデータを自分の ClickHouse Cloud サービスへストリーミングし、1 分単位の中値シリーズを挿入時に維持し、マーケットパルスのダッシュボードを公開します — そして、その値動きがスプレッドの拡大によるものか、取引の加速によるものかを言えるようになります。

2h30 · ハンズオン9 モジュール5 市場 · 10 トークン公開 API · ウォレット不要

取引のチュートリアルではありません。 ライブなデータの問題です。

公開されている予測市場は、本当にライブで、本当に雑然としていて、しかも無料で読める数少ないデータセットのひとつです。このワークショップが使うのは公開の Gamma、CLOB、Data API だけ: ウォレットも入金も注文も、Polymarket のシークレットも 一切必要ありません。

面白いのはフィードそのものではなく、フィードが設計に何を要求するかです。WebSocket は速いものの永続的なログではないので、コレクターは静かなソケットや停滞したソケットを検知して再接続し、劣化している間は公開の CLOB ブックをポーリングします。別のループが 5 秒の重なりで取引を突き合わせ、ID は決定的なので、同じ取引が二度届いても記録は一度だけです。

すべてのテーブルは実際に実行するクエリのためにキー設計されています — まず時間バケット、次にグループ化に使うトークンまたは condition — そして 1 分単位の中値シリーズは、ダッシュボードの更新ごとに再計算するのではなく挿入時に維持されます。

ハードコードしたトークン ID起動時の Gamma による探索
WebSocket をログ代わりに停滞検知、再接続、REST フォールバック
更新ごとに再計算挿入時に 1 分足 OHLC
動いた価格だけスプレッド、鮮度、出来高の文脈

持ち帰るもの

終わりに動いているもの、すべて。

自分の ClickHouse Cloud サービス上で、公開 API から供給されます。ローカルで動くのは、ステートレスな Docker コンテナ 1 つだけです。

01

クエリ起点のデータモデル

ClickHouse Cloud 上の 6 つのオブジェクト: markets、price_ticks、trades、それらに対する FINAL ビュー、1 分単位の集計、そしてその materialized view — UInt256 のトークン ID、正確な小数、enum で型付け。

02

フィードに耐えるコレクター

ハートビートと停滞検知、再接続、劣化中の CLOB REST ブックへのフォールバック、そして degraded を失敗ではなく正直な状態として返すヘルスエンドポイント。

03

推測ではなく突き合わせた取引

5 秒の重なり で走る公開取引のループと決定的な ID、その後ろに 2 段目の安全網としての ReplacingMergeTree。

04

挿入時に作る 1 分足 OHLC

argMin、argMax、min、max、count の状態を保持する AggregatingMergeTree を、対応する Merge 関数で確定 — 読み取り行数を生スキャンと比べます。

05

答えられるようになる 4 つの問い

現在の確率、5 分間の変動が大きい銘柄、スプレッドと鮮度、そして出来高の加速 — 値動きが見出しではなく、確信か疑いを伴うようになります。

+

Cloud のダッシュボード

Polymarket market pulse — 1 分単位の折れ線チャートを含む 5 つの保存済みクエリを、すべて ClickHouse Cloud のコンソールだけで構築。ローカルの BI 製品は使いません。

行程 · ハンズオン 2h30

9 モジュールを、順番に。

ひと続きの流れ: 市場を見つけ、モデル化し、ストリーミングし、集計し、そして値動きを説明して公開します。

  1. 00

    macOS または WSL 2 上の Ubuntu を準備し、clickhousectl と ClickHouse クライアントをインストールし、Cloud サービスを作成して、プリフライトに READY を出させます。

  2. 01

    Gamma に最も活発なアクティブ市場を問い合わせ、condition ID とアウトカムのトークン ID が別物である理由を学びます。

  3. 02

    market、tick、trade のテーブルを、実際に使うフィルターに合わせて型付きで作成し、1 分単位の中値集計とその materialized view も用意します。

  4. 03

    コレクターを起動し、そのヘルス契約を読み、行が Cloud に着地していることを確認 — フィードが止まったり遮断された場合のテスト済みフォールバックとして fixture モードも使います。

  5. 04

    集計の状態を確定し、読み取り行数を生の同等クエリと比べ、更新ジョブなしで最新の 1 分が進んでいくことを確認します。

  6. 05

    4 つの明示的なクエリ: 現在の確率、最も動いたアウトカム、スプレッドが広いのかクォートが古いのか、そして取引量が加速したのか。

  7. 06

    5 つのクエリを決められた名前で保存し、4 つの現況ビューと 1 分単位の折れ線チャートで Polymarket market pulse を組み立てます。

  8. 07

    ClickHouse Agent にライブのテーブルを渡して値動きを検知させ、スプレッド、鮮度、出来高と照らして調査させ、その判断を決定的な SQL で審判して、間違えた点を記録します。

  9. 08

    まとめ

    10 分

    最後の確認クエリを取得し、コレクターを停止して、すでにストリームへ配信している本番リレーに向けた ClickPipes への道筋を描きます。

既定は自習形式です。 どのモジュールにも開始地点があり、自分で実行できる完了チェックで終わります。live、新しい REST タイムスタンプを伴う degraded、そして fixture はいずれも有効な教材上の状態です — 講師トラックは会場がどの状態にいるかを明示し、fixture のデータをライブと呼ぶことは決してありません。

参加する前に

対象者と、持ち物。

こんな方に 対象者

  • ライブなフィードをダッシュボードの背後に初めて置くエンジニア
  • 「なぜあの数字が動いたのか」 と聞かれて、推測ではなくクエリで答えたい方
  • 集計を再計算するか、挿入時に維持するかで迷っているチーム
  • SQL、ターミナル、Docker に慣れていれば十分 — マーケットデータの経験は不要です

持ち物 前提条件

  • macOS のノート PC、または Docker Desktop の WSL 連携を有効にした Ubuntu on WSL 2
  • パスの通った Docker、Git、Python 3
  • サービス作成、SQL 実行、クエリ保存、ダッシュボード作成の権限がある ClickHouse Cloud の組織と API キー
  • Polymarket 側の準備は不要: 探索、クォート、取引はすべて公開の読み取りです

進め方 形式

  • 9 モジュールすべて 100% ハンズオン — コマンドとクエリはすべてコピー&ペースト
  • 自習でも講師ありでも。各モジュールに対応した講師トラックがあります
  • データベースは ClickHouse Cloud だけ。ローカルの ClickHouse サーバー はどの時点でも動かしません
  • 市場が静かなのは普通のことなので、fixture モードは即興ではなくテスト済みです

このワークショップではないもの 範囲

  • 取引ではありません。 ウォレット、入金、注文、ポジション、投資助言はなし — 公開のマーケットデータだけです
  • ブローカーの演習でもありません。 コレクターは直接書き込みます。Kafka を挟んでも小さなフィードが分散システムのように見えるだけです。ClickPipes が正解になる場面はモジュール 07 で扱います
  • 戦略でもありません。 クォート中値は最良買値と最良売値からの目安の確率であり、実際に取引できる価格ではありません
  • ローカルスタックでもありません。 収集するのはステートレスなコンテナ 1 つ、それ以外はすべて ClickHouse Cloud にあります

動きを追う準備はできましたか?

Docker が入ったノート PC と ClickHouse Cloud の組織を用意してください。ライブなフィード、挿入時に維持される 1 分単位の集計、そしてどの公開市場にも向けられるマーケットパルスのダッシュボードを持ち帰れます。

2h309 モジュール、それぞれ自分で実行できるチェックで終わります。
1 分中値の OHLC は挿入時に維持され、更新ごとに再計算されません。
0Polymarket の認証情報: 探索、クォート、取引はすべて公開の読み取りです。
JA