製品分析およびデータインフラストラクチャプラットフォームであるPostHogは、最近、データウェアハウスにおける重要なアーキテクチャの転換を発表しました。マルチテナンシーの問題を解決し、コストベースのクエリ最適化へのアクセスを得るためにClickHouseからDuckDBへ移行したのに対し、同社は現在DuckDBから離脱しようとしています。この移行は、クラウド環境におけるシングルノードエンジンの実用的な限界を超える、より複雑で大規模なワークロードをサポートする必要性に起因しています。
この画像は、シングルノードのDuckDBセットアップから分散アーキテクチャへの移行という、記事の核心的なトピックの主要なビジュアルとして機能します。
DuckDBはローカル分析やシングルノードのクエリには非常に効果的ですが、PostHogは企業レベルのワークロードに合わせてスケールさせるには大きな障害があることを発見しました。DuckDBはシングルノードツールであるため、会社はクエリが到着する前にワーカーインスタンスのサイズを決定する必要がありましたが、予測不可能な顧客のクエリに対するCPUおよびメモリ要件を予測するプロセスは困難であることが判明しました。さらに、DuckDBはメモリが枯渇した際にディスクに溢れ出す（spill）ことができますが、これはユーザーにとって実行可能ではないほど遅く、高コストなクエリを招りました。また、標準的なレイクハウス形式との互換性を維持するために使用されていたDuckLake拡張機能にもボトルネックが生じました。約1兆行、2ペタバイトのデータを含むPostHogの規模では、DuckLakeのカタログスキーマがボトルネックとなり、すべてのコミットにカタログ全体の統計の再読み込みが必要であったため、単一テーブルの書き込みに3分以上かかる原因となりました。
これらの制限に対処するため、PostHogは分散SQLクエリエンジンであるTrinoを使用し、HogLakeと呼ばれるカスタムのオープンテーブル形式と組み合わせてウェアハウスを再構築しています。この移行は、シングルノードのセットアップよりも予測可能な形でペタバイト規模のデータを処理できる分散アーキテクチャを提供することを目的としています。さらに、この移行はツールとの互換性のためのPostgres Wireプロトコルの維持の難しさにも対応しています。PostHogは、長時間実行されるPostgres接続の管理や、さまざまなクライアントの多様な要件への対応が、HTTPベースのルーティングを使用するよりもスケールさせるのが難しいことを発見しました。新しいTrinoベースのアーキテクチャは現在PostHogの規模でテスト中ですが、同社は以前のDuckDBの実装と比較した新しいシステムの具体的なパフォーマンスベンチマークはまだ公開していません。