Rill と ClickHouse: メータリング時代のリアルタイム運用 BI

現代のビジネスは、ますます粒度の細かいものになりつつあります。クラウドプロバイダーは個々の操作レベルまで使用量を記録し、決済プラットフォームはトランザクションをリアルタイムで追跡し、AIシステムはトークン、リクエスト、コンピュート消費量を計測しています。かつてはITシステムの内部における可観測性として始まったものが、外側に広がり、ビジネスの他の領域までもがイベントの生きたストリームへと変わりつつあるのです。

「私たちは鏡のようなデジタル世界を手にしていて、私たちが行うすべてのことがイベントになっています」と語るのは、リアルタイム分析に特化したオペレーショナルBI-as-CodeツールRillの共同創業者兼CEOであるMike Driscollです。「そして、このデータが手元にあるなら、それを理解したいと思うわけです」

Mikeが言うように、課題はデータを集めること自体ではなく、それらがどのように繋がり合うかを理解することにあります。ある企業はAWSやGoogle Cloudでクラウドコストを把握し、Stripeで売上を見て、プロダクトの利用状況はまったく別の場所で追跡しているかもしれません。しかし、そのどれもが、ビジネス全体としてどう動いているかを説明してくれるわけではありません。「他社のダッシュボードに頼って自社のビジネスを理解することはできません」と彼は言います。「結局のところ、自分たちですべてのデータを統合する必要があるのです」

Rillのようなビジネスインテリジェンス(BI)ツールは、このギャップを埋める手段として登場し、オペレーショナルデータと財務データを統合することで、何にいくら使っているのか、その理由は何かをチームが理解できるようにしてきました。しかし、このアプローチには、膨大なデータを高速かつ効率的に集計できる分析システムが必要です。「ClickHouseは大規模な集計を行うのに驚くほど優れています」とMikeは語ります。

2025年12月のサンフランシスコでのClickHouseミートアップでは、Mikeが、dltによる宣言的な取り込み、ClickHouseでの高性能な集計、そしてメトリクスファーストなオペレーショナルBIレイヤーを組み合わせ、計測化された世界を理解するためのシステムをどう構築しているかを共有しました。

リアルタイムデータベース向けの高速BIツール #

Rillの分析へのアプローチは、大規模なリアルタイムイベントデータに取り組んできた10年以上の経験から生まれました。2010年、MikeはMetamarketsを共同創業しました。これはApache Druidの開発元であり、ストリーミングデータに対するインタラクティブ分析向けに構築された最初のデータベースのひとつです。2017年にMetamarketsがSnapに買収された後、MikeはNishant Bangarwaとともに2020年にRillを設立し、分析インフラを構築してきた経験を活かして、リアルタイム時代に向けてBIを再考しました。

現在、Rillは数千人のユーザーにわたり、1日あたり1,000億件を超えるイベントを処理しており、BloombergやComcastといったデジタルメディア大手、AT&Tのような大規模エンタープライズ、さらには増加しつつあるフィンテックやEコマース企業にサービスを提供しています。「私たちの顧客の多くは、ClickHouseを愛用しているような顧客と似ています」とMikeは言います。「ですから、ClickHouseをデータベースとして採用してフィットしたのは偶然ではないんです」

Rillは、BI-as-code、開発者フレンドリー、エージェントファーストというアプローチを取っています。データソース、変換、ビジネスロジックはコードとして定義され、Cursorのようなモダンなツールで開発し、Gitで変更をバージョン管理し、ソフトウェアを出荷するのと同じ要領で分析をデプロイできます。「私たちは本当にこの宣言的なデータスタックの支持者なんです」とMikeは語ります。「SQLとYAMLがあれば、ダッシュボードだけでなくデータアプリケーションも作れるんです」

この哲学はRillのメトリクスファースト設計にも及んでいます。チームはSQL式を使ってメトリクスを宣言し、ダッシュボードはそこから生成されるものであり、作られるものではない、という共有のセマンティックレイヤーを構築します。Mikeが言うように、これはAIや会話型分析がワークフローに加わるにつれて、ますます重要性を増しています。「SQLは価値がありますが」と彼は説明します。「結局のところ、エージェントはセマンティックレイヤーのようなものとやり取りできた方がずっとうまく機能することがわかってきました」

そのすべての基盤にあるのが、リアルタイムのパフォーマンスです。従来のBIツールは、しばしば重いクエリを避けるべきものとして扱い、ダッシュボードのレスポンスを維持するためにキャッシュに頼ってきました。「しかしClickHouseのようなものを使っていれば」とMikeは言います。「ダッシュボードに何百回、何千回もヒットするのを避ける必要はありません」。Rillの顧客にとって、これは即座のドリル、スライス、ダイスを意味し、ライブデータに対して直接動作する高速な会話エージェントも実現します。

Mikeはこう表現します。「ClickHouseのようなリアルタイムデータベースを中心に構築したからこそ、他のダッシュボードでは試みすらしないようなことができるのです」

RillのClickHouseベースのアーキテクチャ #

Rillのアーキテクチャは、分析をデータベース近くに保ちつつ、それ以外のすべてをコードとして定義します。取り込み、モデリング、分析の間に新しいレイヤーを差し込むのではなく、それらを宣言的な構成を中心とした単一のワークフローへと繋ぎ合わせます。

Rillのアーキテクチャ:宣言的なデータ取り込み、ClickHouseによる集計、そしてオペレーショナルBI。

データの取り込みは、宣言的なデータロードのためのオープンソースPythonフレームワークであるdlt (data load tool) のようなソフトウェアを使ってオーケストレーションされます。オペレーショナルデータベース、オブジェクトストア、データレイク、データウェアハウスは再利用可能なコネクタを通じて抽出され、変換とソース認証情報はSQLとYAMLで定義されます。チームはカスタムパイプラインを維持する代わりに、データがどう移動すべきかを記述し、dltが抽出とClickHouseへのロードを自動で処理します。

ロードされたデータに対し、ClickHouseが分析エンジンとして機能し、大規模なイベントデータに対してクエリが直接実行されます。ビジネスロジックは、メジャー式とディメンションメタデータで表現され、クエリ時に集計を行うSQLモデルへとコンパイルされます。これらの定義が共有メトリクスレイヤーを形成し、ダッシュボード、API、プログラムによるアクセスのすべてが同じロジックに依拠することを保証します。

この基盤の上に、Rillのオペレーショナル BIレイヤーが乗っています。ここではロールベースのセキュリティポリシーやダッシュボードの構成もコードとして定義されます。ダッシュボードは手作業で構築するのではなく、メトリクス定義から生成されるため、分析アプリケーションはClickHouseをリアルタイムでクエリする軽量なインターフェースのままに保たれます。

その結果、ツール間でビジネスロジックを重複させることなく、ソースシステムからClickHouseへとデータが流れ、プロダクト、運用、財務の各チーム、さらには外部パートナーへもインタラクティブな分析を届けるコンポーザブルなシステムが実現します。

BI-as-codeは実際にどう機能するのか #

サンフランシスコでのミートアップで、Mikeはノートパソコンを起動し、ライブデモを行いました。「ClickHouseがローカルマシン上でいかに簡単に起動できるかにインスパイアされました」と彼は述べ、ClickHouseと同様に、Rillでも開発者がローカルインスタンスをブラウザで起動し、ローカルのClickHouseデータベースまたはClickHouse Cloudのどちらにも接続できるようになっていることを指摘しました。

デモはRill内部の3つの主要なビルディングブロック、すなわちソース、メトリクス、ダッシュボードを中心に行われました。Mikeはまず、Parquetファイルから約100万行のGoogle Cloud使用量データをロードしました。次に、エージェント支援のワークフローを使って、このデータセットをClickHouseに取り込むのに必要なYAML設定を生成しました。

接続が完了すると、Rillはテーブル構造を分析し、メトリクス定義とダッシュボードを自動的に生成しました。数秒のうちに、彼はクラウド支出のトレンドを探索でき、サービスにドリルダウンし、時間範囲をズームし、ディメンションでコストをスライスすることが、すべてClickHouseクエリに支えられて可能になりました。「素晴らしいのは、その簡単さと速さです」とMikeは言います。

Rillでは、開発者はAI支援のコーディングツールを使って構成をコードとして定義できます。デモの中で、MikeはCursorを使って取り込みの構文を生成し、フォーマットを調整し、ダッシュボードを変更しました。かつては広範なUI操作を必要としたタスク、たとえばダッシュボード全体の通貨フォーマットの変更などが、数秒で行えるのです。「これがBI-as-clicksとBI-as-codeの違いです」と彼は言います。

Mikeが説明したように、開発はまずローカルで行われます。チームは小さなデータパーティションに対して反復作業を行い、メトリクスを検証し、変更をGitにコミットしてからクラウドにデプロイします。デプロイ後は、同じ定義がデータの上に重ねられた会話型分析を支えます。

Mikeはこれを、クラウドプロバイダー間でのコスト増加について自然言語で質問することで実演しました。会話型BIは「だいぶ一般的になってきて、データの上にチャットボットを貼り付けたデモはみんな見たことがある」と認めつつも、彼は実際に実運用で機能するかを決定づける2つの制約を強調しました。

第一に、Text-to-SQLアプローチは実際のプロダクション環境では必ずしもスケールしません。「数百のテーブルがあるなら、エージェントが迷子になるのが見えるでしょう」とMikeは言います。「データエンジニアに問題を投げて、『クラウドコストが上がっている理由を突き止めてくれ』と言うようなものです」

第二に、インタラクションの速度は正確性と同じくらい重要です。「バックエンドが高性能でなければなりません」と彼は言います。「もしRillをSnowflakeやRedshift、BigQueryにぶつけたら、答えが返ってくるのに永遠にかかってしまうでしょう」

最終的に、信頼は知性と同じくらいトレーサビリティから生まれます。Rillでは、生成された各インサイトは元となるダッシュボードとクエリ結果にリンクされており、ユーザーはAIの応答を不透明な出力として扱うのではなく、結論を検証できるようになっています。「信頼できる結果が必要です」とMikeは言います。「検証可能性が必要なんです」

完全に計測化された世界のための分析 #

Mikeが説明したワークフローが、実際の組織内で継続的に動いている様子を想像してみてください。クラウドの請求エクスポートがオブジェクトストレージに着地し、オペレーショナルデータがAPI経由で流れ込み、宣言的なパイプラインがすべてをClickHouseへとストリームし、そこでリアルタイムに集計が行われます。一度定義したメトリクスは自動的にダッシュボードとなり、プロダクト、運用、財務にまたがる各チームは、共有された分析レイヤーを通じて同じ基盤データを探索します。

かつてはETLジョブ、セマンティックレイヤー、ダッシュボードツールのつぎはぎが必要だったものが、コードとして定義され維持される統一的なワークフローへと集約されるのです。

実践におけるFinOps:Rillでの宣言的取り込み、リアルタイム集計、そしてオペレーショナルBI。

総合すると、RillとClickHouseは、あらゆるビジネスプロセスがイベントを生成する世界に向けて構築された、新しい分析モデルを示しています。チームはライブシステムをクエリし、ローカルで反復し、ソフトウェアを出荷するのと同じ方法で分析ロジックをデプロイすることで、運用状況を常に把握できるのです。

組織がリアルタイムで計測されるようになるにつれ、分析は事後的なレポーティングから運用上の意思決定へとシフトしていきます。宣言的なデータ移動、高性能な集計、メトリクスファーストの設計によって、分析を別個の到達点としてではなく、ビジネスそのものと並走するインフラとして扱うことが可能になるのです。