5ヶ月前のDuckDB移行をもう撤回 PostHogに海外で疑問の声
姉妹サイトの新着
ソフトウェア企業PostHogが、自社の分析基盤(データウェアハウス)をDuckDBから移行したとブログで報告し、Hacker Newsで議論になった。PostHogは5ヶ月前にClickHouseからDuckDBへ乗り換えたばかりで、今回はTrinoと自社開発のデータレイク「HogLake」へさらに移り変わる。スレッドでは、これを技術的な学習や試行錯誤と見るか、計測や検証を欠いた単なる「右往左往」と見るかで意見が割れた。話題はPostHogのサイトデザインやクッキーバナーへの批判にも広がった。
我々はウェアハウスをDuckDBから移行させた
出典: posthog.com / 元記事はこちら
この記事に書いてある技術的な話って『数兆行なんて大したデータ量だから、今度こそTrinoで上手くいくはず』ってとこだけじゃないの?右往左往してるだけで、ちゃんと計測してエンジニアリングした感じがしないんだけど。
>>2 ここでの本当の『気づき』は、顧客ごとにVMを立ち上げてクエリを振り分けるなら、実行前にクエリのコストを見積もれないと話にならないってことだと思う。Snowflakeは実際それをやってて、実行前にクエリ最適化をして必要なリソース量を把握してる(もちろん外れることもあるけど)。
>>2 『右往左往してるだけでエンジニアリングした感じがしない』というのも驚きじゃないよ。彼らは爆速で安っぽいものを出すのが得意だから。CEOがLinkedInでどんな投稿をしてるか見てみれば分かる。
>>2 自分もこのブログ記事、何が言いたいのか分からない。
『5ヶ月前、我々はClickHouseではなくDuckDBの上にウェアハウスを再構築した』とあるけど、まだ落ち着いてもいないのになぜこの記事を書いたんだろう。勝利宣言をしたい人がいた(あるいは昇進のため?)としか思えない。
>>4 その前の記事の冒頭がひどい。『PostHogの元々のデータウェアハウスには一つの目標しかなかった。企業が最初のデータエンジニアを雇う瞬間を遅らせることだ』って。良質でタイムリーなデータを届けて良い意思決定をすることじゃなくて、特定の職種を雇わずに済ませることが目標だったってことか。ひどすぎる。
>>4 エンジニアは試行錯誤するのが好きだし、その経験から我々も学べる。何にそんなに怒ってるの?
ClickHouseに戻すことは検討したんだろうか。ClickHouseのIceberg対応はここ数ヶ月でかなり良くなってる。Iceberg上でステートレスなClickHouseを簡単に動かせるから、テナントの問題も解決できるし、ペタバイト規模も問題なく扱える。
Posthogのサイト、しばらく見てなかったけど、ひどいデザインになってるな。
>>6 無料のWebアナリティクスとして使ってるけど、UXが悪くて分かりにくい。悪い冗談みたい。
>>6 あの意味不明なクッキーバナーは何なの?機能に必須のクッキーしか使ってないならバナーを出す必要はないし、アナリティクス用なら拒否できないとおかしい。どっちにしても嫌がらせでしかない。
>>6 自分はこのデザイン好きなんだけど、それでもひどいというのには同意する。
これには驚いた。独自フォーマットを選んで、それをTrinoで問い合わせる理由を明かさないまま、ここまでの開発労力をかけるとは。
新しいマーケティング責任者が来て、既存のマーケティングオートメーションを全部壊して自分のものに入れ替える、でも事業への影響はゼロ、みたいな話を思い出す。要は旗を立てたいだけ。
たった5ヶ月前に会社としてDuckDBに移行したばかりなのに、もう別のものに移ろうとしてるのは変な感じがする。誰がデータの増加予測をしたんだろう。計画がまずかった例に見える。
面白いことに、自前のデータレイクを作るのが今のトレンドらしい。うちもやった。もし良ければ、こういう新しいデータレイクが実際どんな形になるか書いた記事があるから貼っておく。
DuckDBのクライアント・サーバープロトコルであるQuackは、彼らが遭遇したスケーリングの問題を助けられたんじゃないか。
6ヶ月後:『Trino + HogLakeからさらに新しい技術XXXへ移行します』ってなるんだろうな。馬鹿げてる。なぜこういう問題を予見できないのか。必要な規模でモックデータを使ったテストをしてないのか。本番環境でスタックを何度も移行するのは、新機能を出せていないということでもある。これは純粋な『やってるふり』の作業だ。
HogLakeって名前、なかなかだな…
3ヶ月後:『フォーク版ClickHouseに戻しました』って記事が出るパターンだ。
翻訳すると: 最先端のAIモデルが優秀すぎて、自前のウェアハウス基盤を書き直せるようになった、ってことだね。
>>2 これは『先に発射して後で聞く』って感じだな。(おいおい)
>>3 ORMを使う人がクエリやインデックスを一度も確認せずに、問題はデータベースのせいだと決めつけるのを思い出す。
他サイトの新着
>>3 ClickHouseの何が問題だったんだっけ?
>>24 去年から変わってなければ、多くのチームがClickHouseの安定性で深刻な問題を抱えてるはず。
>>24 分からない。ブログ記事では書いてるけど、どこまで信じていいのか。結局彼らが選んだ移行先も5ヶ月しか持たずに次の移行になったわけだし。
>>6 自分はあのメニュー、気に入ってるよ。モバイルでもよく動く。デスクトップ時代に積み重ねてきたUIの作法を、Web(とさらに悪いことにElectron)では捨ててしまった。サイトごとに新しい作法を覚えなきゃいけないのは面倒だから、昔のメニューを復活させるのは悪くない選択だと思う。
>>19 Snowflakeはその情報をどう使ってるんだろう。結局どのウェアハウス(インスタンス)を使うかは自分で選ぶ必要があるよね。重いクエリを大きいウェアハウスに自動で振り分けてくれる『伸縮自在のウェアハウス』があったら面白いけど、今のところそういう機能はない。
>>25 皮肉なことに、優秀なデータエンジニアがいれば、1年の間に3つも違うデータウェアハウス基盤を必要とする事態は避けられたはずだ。
>>26 大部分は単なる自己満足にしか見えない。一つ試してみて、それから『自分たちで解決策を作った!』って飛びつくのは、その問題自体がそんなに新しいものでもないのに。こういうのはもう飽き飽きする。
この話題の背景と論点
PostHogはプロダクト分析ツールを提供する企業で、今回話題になっているのは自社サービスの裏側で動く分析用データウェアハウスの選定だ。スレで言及されている通り、同社は以前ClickHouseを使っていたが5ヶ月前にDuckDBへ移行し、今回さらにTrinoと独自開発のデータレイク「HogLake」へ移ろうとしている。1年足らずで基盤を複数回切り替えたことになり、これが「エンジニアとして当然の試行錯誤」なのか「検証不足のまま飛び移っているだけ」なのかでコメント欄の評価が分かれた。批判側は、移行の効果を示す具体的な数値がブログに示されていない点を問題視している。なお以前の移行記事で「データエンジニアを雇う瞬間を遅らせることが目標だった」と書かれていたことも、今回の批判を強める一因になっている。
※本記事は海外掲示板 Hacker News のスレッド「Moving our warehouse off DuckDB」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。