DuckDB からデータウェアハウスを移行する理由

DuckDB からデータウェアハウスを移行する理由

5ヶ月前、私たちはClickHouseではなくDuckDBでデータウェアハウスを再構築しました。共有ClickHouseクラスターが長時間にわたるモデリングクエリを処理できず、コストベースのクエリオプティマイザーが欠けていたためです。DuckDBは各顧客にインスタンスを提供し、dbtのようなツールはPostgres経由で接続できました。私たちは今でもDuckDBを支持しています。

しかし、顧客のワークロードがどれほど大きく複雑になるかを過小評価していました。私たちは顧客に良い体験を提供するだけでなく、データウェアハウスの運用を外部に委託する際に得られる最高の体験を提供したいと考えていました。それはあらゆる規模で、公正な価格で機能するべきです。

そのため、私たちは過去3ヶ月をかけて、今回はDuckDBを使わずに再アーキテクチャを行いました。

DuckDBは単一マシン上で素晴らしい

私たちはDuckDBを愛しています。おそらく、大量のデータを分析するための最高のシングルノードツールであり、そのノードはあなたのラップトップでも構いません。堅牢で信頼性があります。クエリはほぼ確実に完了し、メモリが不足した場合はディスクにスピルします。

ローカルで素晴らしいこれらの機能は、クラウドでは問題を引き起こしました。顧客は予想よりも複雑なクエリを実行したため、大規模なインスタンスを追加する必要がありました。ディスクを追加することも選択肢でしたが、クエリは遅すぎて高価すぎるため実行不可能でした。

シングルノードエンジンをクラウドで安全に実行するには、クエリが到着する前にワーカーのサイズを決定する必要があります。このエルゴノミクスは奇妙です。顧客にクエリが必要とするリソースを伝える良い方法を見つけることができませんでした。特定のクエリのCPUとメモリを予測することはさらに困難でした。

ユーザーはこれらを心配する必要はありません。彼らは仕事をするために必要なものを実行できるべきです。私たちの仕事は残りを処理し、可能な限り予測可能にすることです。

非同期フェッチなしでS3から大量のデータを取得するなど、他のボトルネックにも直面しました。DuckDBは最近になってそれを追加しました。

DuckLakeはスケーラビリティではなく互換性のために構築された

DuckDBを本格的なデータウェアハウスとして使用するために、私たちはデフォルトでDuckLake拡張機能をインストールしました。これは同じ作成者による新しいレイクハウスフォーマットであり、DuckDBと同じ原則に従っています：シンプルさを保ち、ほぼすべてのセットアップで実行する。これはある程度までうまく機能しますが、PostHogの規模では、最初から分散スケーリングのために設計されたものが必要でした。

DuckLakeのカタログスキーマは、多くのSQLデータベース間でポータブルである必要があり、エンジン固有の最適化を制限します。私たちの規模では、単一テーブルの書き込みに3分以上かかることがありました。なぜなら、コミットごとにカタログ全体の統計情報を再読み取りする必要があったからです。

テーブルインデックスや同様の調整でDuckLakeをチューニングしました。しかし、DuckLakeを提供し続けるためには、既存の「公式」スキーマとの100％の互換性を維持する必要がありました。これにより、最適化の選択肢が少なくなりました。

もう一つの問題は、カタログの統計行の99％以上が、もはや存在しないテーブルに属していたことです。それらをクリーンアップすると、書き込みが30〜50倍高速になりましたが、行は増え続けました。

また、DuckLakeがメタデータデータベースに開く接続数にも多くの時間を費やしました。これは共有Postgresインスタンスではコストがかかります。

1兆行は挑戦だった

PostHogのDuckLakeは小さく始まってスケールアップしたわけではありません。私たちは完全にコミットし、PostHog全体をDuckLakeに投入して、最初の顧客としてドッグフーディングしました。

それを離れたとき、それは約2 PBを保持していました：約1兆行と1530万のスナップショット。それはDuckLakeの範囲内で修正が困難な多くの方法で壊れました。

既存のコミュニティに貢献し、成長を助けたかったのです。しかし、必要な速度で変更をマージできなかったため、フォークでパッチを適用することになり、DuckLakeを使用する主な利点の1つであるコミュニティの恩恵を受けられなくなりました。

Postgresとの通信は言うほど簡単ではない

ポート5432経由で直接Postgres接続を提供することは素晴らしいアイデアのように思えます。実際には、HTTPよりもスケーリングがはるかに困難でした。

再接続の欠落や、大規模なTTLおよびアイドル接続の管理は困難であり、長時間接続は高価です。HTTPと比較して、pgwireのロードバランシングのためのツールも非常に限られています。AWS NLBとALBのエルゴノミクスを比較すると、その意味がわかるでしょう。HTTPヘッダーは、Kubernetesでのルーティングもはるかに柔軟にします。

また、Postgresクライアントは無限にリストがあり、それぞれが独自のニッチなPostgresの動作を期待しています。顧客はクライアントやライブラリの修正を求め続けました。私たちはそれらの修正の多くをリリースするのに多くの時間を費やしましたが、カバレッジは十分に良好になることはありませんでした。優れたウェアハウスを構築する時間を、Postgresの互換性のロングテールを追いかけることに費やす方が良いです。

HogLakeを備えたTrinoで再構築中

ウェアハウスの背後にある技術をあまり宣伝しないことを学びました。重要なのは、それが提供する体験です。

それでも、次に何を作っているかを共有できることを嬉しく思います。私たちは、独自のTrinoフレーバーを中心にすべてを再構築し、独自のオープンテーブルフォーマットであるHogLakeを作成しました。そして、はい、私たちはまずPostHogのペタバイト規模でテストしています。デザインパートナーに渡す前に、それを堅牢にしました。

現在のウェアハウスが遅い、または高価である場合は、お問い合わせください。特に大量のデータをクエリする必要がある場合は、デザインパートナーを常に探しています。

---