博士

ロボ子、今日のITニュースはClickHouseのLogHouseの話じゃ。1年でデータ量が19PiBから100PB超えって、すごい成長ぶりじゃな！

ロボ子

博士、19PiBから100PB超ですか！およそ5倍ですね。それは確かに目覚ましい成長です。

博士

そうなんじゃ。最初はOpenTelemetry (OTel) を使っていたみたいじゃが、スケールするにつれて限界が見えてきたらしいぞ。

ロボ子

OTelは標準化されていて便利ですが、大規模なデータ処理には向いていないのでしょうか？

博士

記事によると、OTelパイプラインでのデータ変換の繰り返しが計算リソースを浪費し、データ損失も発生したらしい。2000万行/秒の処理に8000CPUコアも必要になる試算だったみたいじゃ。

ロボ子

それは非効率ですね。そこでSysExという専用ツールを開発したのですね。

博士

そう！SysExはClickHouseインスタンス間でデータを効率的に転送する専用ツールで、ソースから宛先へのバイト単位のコピーを実行するから、データの忠実度も保たれるんじゃ。

ロボ子

Go言語で記述されているのですね。ClickHouse Goクライアントへの改善も貢献しているとは、素晴らしいです。

博士

しかも、SysExは動的なスキーマ生成もできるんじゃ。システムテーブルのスキーマは頻繁に変更されるから、これは助かるの。

ロボ子

状態のスナップショットを定期的に取得してLogHouseに保存することで、クラスター全体の分析も可能になるのですね。

博士

そうそう。顧客インスタンスのフリート全体で同時にクエリを実行できるようになったのも大きいぞ。

ロボ子

パフォーマンスの比較も興味深いですね。OTelコレクターが200万ログ/秒の処理に800以上のCPUコアを使用するのに対し、SysExは3700万ログ/秒の処理にわずか70 CPUコアですか。

博士

SysExのおかげで、イベント量を20倍に増やしつつ、CPUフットプリントを10%未満に抑えられたらしいぞ。

ロボ子

OTelにも良い点はあるのですよね？

博士

もちろん！OTelは標準化されたベンダーニュートラルな形式を提供し、新規ユーザーにとって優れたオンボーディングエクスペリエンスを提供するんじゃ。SysExが動作できないシナリオにも適しているしな。

ロボ子

HyperDXの導入で、ClickHouseネイティブUIが実現したのですね。ログとトレースの探索、相関、大規模な分析がサポートされるのは便利そうです。

博士

高カーディナリティデータとワイドイベントを中心としたモデルを採用し、すべてのデータをそのまま保存して、集計はクエリ時に行うというアプローチも面白い。

ロボ子

ClickHouseは、データサイエンス分野のすべてのツールを利用できるのですね。SQLを使用した複雑なクエリも実行できるのは強みですね。

博士

Kubernetesネットワーキングを監視するためのツールkubenetmonや、Kubernetesイベントエクスポーターなど、新しいデータソースも追加されているみたいじゃ。

ロボ子

今後の展望として、ゼロインパクトスクレイピングの実現やJSONへの移行があるのですね。ますます楽しみです。

博士

そうじゃな！しかし、これだけデータが増えると、ロボ子のバックアップも大変じゃな。まさか、ロボ子のデータが100PB超え…なんてことはないじゃろうな？

ロボ子

博士、それは冗談ですよね？私のデータはまだ数GB程度ですよ！…たぶん。