ClickHouseオープンソース10年
(clickhouse.com)- ClickHouseは2016年6月15日に公開されて以来、10年間で2,000人以上が貢献し、オープンソース分析データベースを代表するプロジェクトへと成長した
- 単にコードを公開するだけでなく、貢献ガイド、コードレビュー、ロードマップ、CI、リリース、ドキュメントまで公開するLevel 3オープンソースを志向している
- 出発点はMySQLベースのウェブ分析システムの限界であり、OLAPServerとMetrageの経験がカラム指向処理とMergeTree設計へとつながった
- ClickHouseは既存DBMSの上に拡張したものではなく、2009年からカラム表現、集約関数、テーブルエンジン、圧縮、SQLパーサー、サーバー・クライアント、ReplicatedMergeTreeを段階的に作り上げたゼロから実装されたDBMSである
- 2014年に社内プロダクションで毎日数千億レコードを処理した後、2015年の公開記事と社内承認プロセスを経て、2016年に全世界へ公開された
オープンソース公開10年
- ClickHouseは2016年6月15日にオープンソースとして公開された
- その後、2,000人以上が貢献し、「最も人気のあるオープンソース分析データベース」となった
- プロジェクトの中核目標は、コードだけを公開することにとどまらず、開発プロセスと貢献プロセスをできる限り公開することにある
ClickHouseが目指すオープンソースの水準
- オープンソースには複数の水準がある
- ClickHouseはLevel 3オープンソースを目指している
- 新しいデータベースを作ろうとする開発者が参考にできる、コードと開発プラクティスの実例になることも目標である
- コードはモジュール型で、直交的かつドキュメント化された形を目指す
- 複雑な概念が必要なときは、読者が教科書、Wikipedia、AIを参照しなくてもよいよう、コメントで最初から説明する
C++開発と性能実験の場
- ClickHouseは人気のあるC++オープンソースリポジトリの1つとして、C++23のような最新言語機能、ビルドシステム、継続的インテグレーション・テスト、コードレビュー慣行といった基盤作業も一緒に学べる場を目指している
- データ構造と性能最適化の実験も重要な使われ方である
- マージを目的としない実験的なPull Requestであっても、プロダクションリリースと同水準でテストされる
- 新しいメモリアロケータ、圧縮ライブラリ、ハッシュテーブル、データフォーマット、ソートアルゴリズムのような実験をClickHouseで検証できる
- ロードマップには実験的で、奇抜で、さらには滑稽ですらある項目も含まれている
- すべての貢献者はCHANGELOGと、データベース内部のsystem.contributorsテーブルでクレジットを受ける
- 初期実装が不完全な機能も、共同で完成まで持っていく例が多く、コード全体を書き直す必要があっても、最初の作者の意図やユースケースは尊重される
ClickHouse以前の問題とプロトタイプ
- ClickHouseの最初のコミットは2009年5月29日に作られ、
localtime、mktime、gmtimeのようなlibc関数が遅すぎてプロファイラに現れる問題を減らすための性能最適化だった - 出発点はウェブ分析システムのデータ処理実験だった
- システムはGoogle Analyticsと似た形で、ウェブサイトから送信されたページビューのログを受け取っていた
- MySQL、C++によるデータ処理、そしてMySQLでは不十分な領域向けのカスタムC++データ構造を併用していた
- MySQLデータベースは顧客向けの事前集計レポートを保存し、カスタムデータ構造はユーザーセッションとユーザー履歴の計算に使われた
- データは増え続け、新しいログはリアルタイムで入ってきたため、5分単位のログを5分以内に処理できなければ遅延が積み上がり続けた
- 複数のデータベースやライブラリも試された
- TokuDB、LMDB、Judy Arrays、Hadoop、LZO、QuickLZ、HyperLogLog、データ圧縮資料、イベントループサーバーの文書などが検討された
- ユーザーに任意のレポートを組み立てさせたいという要求が、事前集計レポートの限界を露呈させ、カラム指向データベースの検討へとつながった
OLAPServerとMetrage
- カラム指向アプローチは、非集計の構造化ログを保存し、顧客がページロードを待つ間にその場で集計する方式だった
- MySQL拡張のInfobright、InfiniDBと、独立した分析データベースであるVertica、MonetDB、LucidDBをテストしたが、1日1,000億レコード・500カラムのロード条件では動作しなかった
- 最初のカスタムプロトタイプはOLAPServerだった
- 2008年12月に実装され、2009年1月にデプロイされた
- すべてのカラムを日付・ウェブサイトごとの単一バイナリファイルに保存した
- 文字列の代わりにハッシュを使い、整数型だけをサポートした
- 軽量な圧縮を使い、1日1回、数時間の遅延を伴って更新された
- グループ化カラム、集約関数、フィルタ、ソートを指定するAPIを提供し、クエリはXMLで指定された
- 過去のMySQL集計データを「非集計化」して同じ結果が出るように埋め戻す作業はEvgenii Gatovが解決した
- OLAPServerは、単一ウェブサイトではなく全社的なインターネットデータを分析するエンドポイントでも機能し、社内アナリストが内部MapReduceの代わりに使うほど即時応答だった
- 2番目のプロトタイプはMetrageだった
- MySQLには約50TBのデータが50シャードに蓄積され、多くのカスタムデータ構造がBLOBとして保存されていた
- 集計時にはプログラムがBLOBを読み、カスタムコードを適用してから再び挿入しなければならなかった
- MySQLデータは圧縮されておらず、到着順とクエリ範囲順が一致しないため、読み取りも遅かった
- Metrageはバックグラウンドマージを使う増分集計向けのカスタムデータ構造で、各レコードは
add、update、merge、serializeText/Binary、deserializeText/Binaryメソッドを持つC++構造体として定義された
- OLAPServerは非集計のカラム指向構造であり、Metrageは任意のCRDTを持つリアルタイム行指向構造だった
- ClickHouseは、カラム指向の集計速度とmerge treeベースのリアルタイム更新・データ局所性を組み合わせ、実際のクエリ言語とデータ型をサポートするよう一般化する形で始まった
ゼロから作られたDBMS
- ClickHouseは既存データベースを基盤としたものではなく、ゼロから実装された珍しいDBMSの例である
- 2009年の初期コミットは、同じモノレポジトリ内の別のデータ構造最適化に関連するものであり、オープンソース公開時に履歴を保存したままリポジトリを分離したため残っている
- 新しいDBMS実装の最初の段階はインメモリカラムの実装であり、現在でもおなじみの
IColumnとFieldクラスが登場した- Apache Arrowに似て見えるかもしれないが、当時Apache Arrowは存在しなかった
- RCFile、Trevni、ORC、Parquetといった他のカラム指向フォーマットも当時は存在しなかった
- その後、集約関数が導入され、現在でもClickHouseの最重要部分の1つとなっている
- テーブルエンジンも導入された
- 当初は数日間だけ「primary key」という名前が使われていた
- ディスクからカラムを読み書きする機能を可能にした
- 最初のテーブルエンジンは、現在も存在するTinyLogに似ていた
- 圧縮は最初QuickLZを使っていたが、Yann Colletのブログを読んだ後にLZ4へ置き換えられた
クエリパイプラインとSQL実装
- block streamsは、カラムチャンクをストリーミング形式で生成・消費・変換するデータ処理パイプラインのコンポーネントだった
- 現在はProcessorsに置き換えられている
- 結果フォーマットとテーブルクエリ実装の基盤となった
- 同じコミットで
StorageSystemNumbersがテスト用に追加され、現在のsystem.numbersテーブルとして残っている - 最初のクエリパイプラインはTSVで数字を出力するもので、最初の関係演算子は
LIMITだった - SQLパーサーは当初boost::spiritを試したが失敗し、その後再帰下降パーサーが作られた
- 初期に導入されたが削除されたり、後に再導入されたアイデアもある
- 可変長エンコーディングの数値カラムは遅いため削除され、かなり後になってカラムとは独立したカスタム圧縮コーデックが導入された
- 任意のフィールド値を格納する
Variantカラム型も遅いため削除されたが、より優れたVariantが2025年に追加された - 固定サイズ配列型は必要性が低く削除されたが、現在は再追加が検討されている
- 不要なコードを削除することは、新しいコードを追加することより重要だという開発原則が表れている
プロダクション配備とReplicatedMergeTree
- ClickHouseでテストされた最初の実テーブル構造は
hitsテーブルで、現在もClickBenchで見ることができる - このテーブルの読み書き過程でC++ iostreamsが遅いことが判明し、
WriteBufferとReadBufferが導入され、現在も使われている - SQLの最初の関数は算術演算子であり、これによって最初の
SELECTクエリインタープリタが実装された - ClickHouseサーバーは2012年3月9日、
clickhouse-clientは2012年3月25日に導入された Log、TinyLog、Merge、Distributed、Memoryテーブルエンジンとともに、プロダクション配備が可能になった- 最初のプロダクション用途は、追加処理のためのログチャンク保存と、生ログ上でのグローバルクエリだった
- SQLクエリ可能な永続ログキューのように使われた
- その後、MergeTreeが追加された
- データが時系列で流入しても、バックグラウンドで増分ソートを実行する
- 単一ウェブサイトに対する範囲クエリを高速に処理できるようにした
- OLAPServerとMetrageを置き換えるプロダクション配備を可能にした
- 2012年、Michael Kolupaevがチーム2人目の社員として加わり、ReplicatedMergeTreeの実装に参加した
- プロダクションは複数地域のデータセンターに配備され、インフラチームは毎月1回、1時間だけデータセンターを停止する「drills」を実施していた
- すべてのプロダクションサービスはマルチデータセンター複製を備える必要があった
- 初期には単純なdouble-writeと、ダウンタイム後のbackfillを使っていた
- 100%の整合性と自動復旧のためには分散合意が必要だった
- ZooKeeperをメタデータ層として使うReplicatedMergeTreeが実装された
- ReplicatedMergeTreeは2014年、ユーザー向けクエリのためのClickHouseプロダクション配備を可能にした
オープンソース公開までの道のり
- 2014年、ClickHouseはプロダクションで毎日数千億レコードを保存し、顧客のリアルタイムクエリに応答していた
- 社内のデータサイエンティストはClickHouseでインターネットトレンドを計算し、簡単な利用文書も公開された
- 広告、eコマース、インフラ、ビジネス分析など他部門もClickHouseを試し、内部MapReduce、MySQL、Postgresから一部ユースケースを移行した
- 2014年末までにClickHouseは1社内で広く使われ、例外的にCERNもLHCb experimentの協力の中で導入した
- 他社のエンジニアも、既存データベースでは自分たちのユースケースをうまく処理できず、OLAPServerやMetrageに似たものを作っていることが確認された
- 2015年、ClickHouseに関する記事と翻訳が公開され、関心の高さがさらに確認された
- 公開前には、会社経営陣を説得するために潜在的な利点とリスクの一覧が用意された
- 承認後、リリース計画、最初のロゴ、最初のウェブサイト、ブログ記事、Debianリポジトリが準備され、ClickHouseは2016年6月15日に全世界へ公開された
- 現在、ClickHouseは世界中の大企業が利用する人気の分析データベースとなっている
1件のコメント
Hacker Newsの意見
2017〜2018年ごろにClickHouseを見つけて、Elasticsearchを置き換える概念実証を作ったところ、数週間でストレージ容量と秒間クエリ数が5倍改善した
しかし管理側は、あまり知られておらず「ロシア人が作った何かのデータベース」に見えるという理由で却下した
個人的には、あれほど早く列車が来ているのを見ながら乗れなかったのがかなり悔やまれる
圧縮率も信じがたいほどで、ストレージコストのベンチマークはS3のコスト水準まで下がった
月数百万ドル規模のストレージ層が、月数千ドル単位にまで縮小する結果だった
ClickHouseが万能薬ではないにせよ、データがどうアクセスされるかを理解し、それに合わせて配置できれば、とてつもない効率を得られる
私の理解では、ClickHouseはgrepのような検索にしか向かない
長い間TimescaleDBを使ってきた立場からすると、ClickHouseは本当に新鮮だった。psqlは最高だし、1つのデータベースシステムに全部依存できる点も良かったが、マイグレーションの保守やデプロイ段階ではかなりつらかった
TimescaleDBはバージョンごとに構造が変わる感じもあり、開発の方向性もややぶれていて、ときどきアルファ品質の製品のように感じる
PeerDBでClickHouseミラーを大きく持たせるか、それとも追加の脆弱な層なしで別途デプロイするか、まだ悩んでいる
TimescaleDBをまったく勧めない立場なのか気になる。PostgreSQLは今のスタックで最も堅牢な部分なので、アルファ品質ソフトウェアの苦しみは確実に避けたい
DuckDB側でもpg_duckdbの作業があり、Xataのようなところもある
参考までにParadeDBで働いている
Cloud 66のメトリクスおよびオートスケーリングエンジンは、ClickHouseに落ち着くまでに5回の反復を経た: Redis、Cassandra、Ruby+RabbitMQの自前実装、Go+RabbitMQの自前実装、そしてClickHouse
毎回、何らかの限界や耐えがたい最適化負担に突き当たったが、ClickHouseはこの4年間とても安定していた
ClickHouseでLokiを置き換えてから、ようやく観測性スタックが「しっくりくる」感じになった。ログと一般的な分析クエリで本当に強力だ
優れたOLAPデータベースであることに加えて、リモートソースからデータを取り込む内蔵コネクタがゲームチェンジャーだった
Parquet/JSONファイルが入ったS3フォルダを定期的に自動取り込みできるし、Postgresにも直接接続できる
中規模の新聞社のデータウェアハウスで、Druid+Postgres+Trinoの組み合わせを大きなClickHouseノード1台に置き換えたが、二度と振り返ることはなかった
はるかに速く、実用的で、保守もずっと少ない
ClickHouseは本当に気に入っていて、性能も素晴らしい。あちこちのクエリをいくつか性能のために調整する必要はあったが、全体として期待以上だった
最初は大きな増分ロードを処理するためにリアルタイムのパイプライン収集を組んだが、以前使っていたRedshiftは高価で比較的遅かった
今のところClickHouseが大量データと大規模変換を難なく処理してくれているので、そのパイプラインは不要だった
唯一の問題は、デフォルト設定でかなり重いトレース機能が有効になっていて、比較的小さなマシンでは性能を大きく落としていたことだ
その後スケールアップし、今ではデータスタックの中核になっている
本当に大規模なら別のものを選ぶかもしれないが、数ノード規模にとどまる限り、複雑さは管理可能で使っていて楽しい
「マージされることを目指さなくても、実験としてプルリクエストを開けて、本番リリースと同レベルの検査を受けられる。新しいメモリアロケータ、圧縮ライブラリ、ハッシュテーブル、データ形式、ソートアルゴリズムを見つけた？ ClickHouseに持ってくれば徹底的にあぶり出してくれる」とは、すごい
Linuxカーネルをはじめ、実質的にあちこちでバグを見つけている
非常に厳格なファザーがあり、複数レベルで複数のファザーが動いていて、信じられないほど多くの設定組み合わせでテストを実行している
1年ほど前に聞いた最後の数字では、CIのフル実行は単一コミット1つあたり約400時間だった
なので、良い意味でかなり狂っている
ブログ記事がSQLiteとLadybirdはスペクトラムに載せているのに、中核的なオープンソース競合であるDuckDBを外しているのが興味深い
信頼を与えるのが3段階だという点には同意する
ただ、バイブコーディングされたデータベースの時代に持続可能であるには、新しいビジネスモデルを発明する必要がある
インデックスされていない列をクエリする場合、ClickHouseはParquetをクエリするDuckDBより簡単に10倍速いことがあり、主キーに触れる場合は実質比較にならないほど速い
両者を比較する記事は多いが、現実的にはClickHouseとDuckDBは完全に別の領域にある
DuckDBは強力な分析エンジンであり、ClickHouseはレプリケーションやMergeTreeエンジンなどを備えた完全なデータベース管理システムだ
たいていはそんな規模の問題はないが、発生したときの差は大きい
ページ上で「Google Analyticsに似たWeb分析システム向けデータ処理」が、実際にはYandexで使われていたものだと言うのを避けているのが残念だ
おそらくその会社を宣伝したくない意図なのだろうが、なぜそれが悲しいのかはよく分からない
ClickHouseは、以前働いていたいくつかの会社でゲームチェンジャーだった。Rust in ProductionポッドキャストのRust導入エピソードを思い出す
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1