← 2026-11-03 の一覧へ戻るホーム
DuckDB から倉庫システムを移行します

2026/11/03 1:02

DuckDB から倉庫システムを移行します

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

PostHog は最近、データ基盤を大幅に刷新し、まず ClickHouse から DuckDB（DuckLake 拡張機能経由）への移行を行って、モデリングクエリのレイテンシーとコストベースの最適化不足の問題に対処しました。しかし、ワークロードがペタバイト規模へと拡大するにつれて、シングルノードの制約が重要な課題となりました：予測不可能なリソース使用、カタログ統計の完全再読み込みによるスローな書き込み速度、エンジン固有の最適化を阻止するスキーマ互換性の制限、多数の直接 Postgres 接続の管理によるパフォーマンス問題などです。これらのボトルネックを解消するために、アップストリームの修正やコミュニティからの貢献を待つことなく、PostHog は DuckDB をフォークして HogLake という独自のテーブル形式を持つカスタム Trino ベースのシステムを作成しました。このプロプライエタリな設定により、予測可能なコスト、複雑なデータモデリングにおけるクエレイテンシーの高速化、そして大規模におけるパフォーマンスチューニングに対する完全なコントロールが実現されています。現在、ペタバイト規模で厳格な内部テストが行われており、設計パートナーによる検証を経て一般生産展開が行われる予定ですが、これはオープンソースプロジェクトをフォークすることが、大規模において必要な特定のパフォーマンスとコントロールを実現するために必要となることが示された事例です。

本文

PostHog のデータウェアハウス再構築：DuckDB から Trino と HogLake へ

5 ヶ月前、PostHog は ClickHouse を代替する倉庫として DuckDB を採用しました。しかし、運用の複雑化に伴い方針を転換し、現在は**Trino の独自版と独自の表形式「HogLake」**に移行しています。

移行の背景：なぜ DuckDB から撤退したか

当初は ClickHouse クラスターのコスト最適化やモデリングクエリの高速化のために DuckDB を選定しましたが、以下の課題が発生しました。

  • スケーラビリティとコストの矛盾
    • 共有クラスターでは長時間実行されるクエリが処理できず、個別インスタンス割り当てへの移行が必要になりました。
    • ローカル環境で優秀な機能をクラウドでも再現しようとした結果、複雑なクエリに巨大なインスタンス追加が求められ、ディスクスワップによるパフォーマンス低下が発生しました。
  • リソース予測の難しさ
    • クエリの到達前にワーカーサイズを設定する必要があり、CPU やメモリの需要を正確に予測することが困難でした。
    • ユーザーはリソース心配から解放されるべきであり、その負荷処理と予測可能性をプラットフォーム側が担う必要があります。
  • DuckLake のボトルネック
    • S3 から非同期 Fetching を利用できず、大量データ取得に時間がかかりました。
    • デフォルトでインストールしていた DuckLake は、カタログ統計情報の再読み込みにより単一テーブルへの書き込みが 3 分以上かかるなどの遅延が発生しました。
    • 既存スキーマとの 100% 互換性維持のため、必要なチューニング（インデックスなど）が制限されました。
  • メタデータ接続数の問題
    • DuckLake は多数の統計情報行を管理しており、それらの約99% が存在しないテーブルに属する行が含まれていました。
    • これらの不要な行をクリーンアップすることで書き込み速度は 30〜50 倍向上しましたが、再び増加してしまう循環が発生しました。
    • メタデータ DB への接続数が増加し、共有 PostgreSQL インスタンスにおいて各接続に実質的なコストがかかる状況となりました。
  • コミュニティ支援の限界（Dogfooding の失敗）
    • PostHog は自社の 2 ピタバイト規模データを DuckLake に移行して Dogfooding（社内テスト）を試行しましたが、システムは頻繁に壊れました。
    • 必要な速度で修正を適用できず、フォーク版でのパッチ維持に追い込まれました。これにより「コミュニティ」という最大の利点を損なう結果となりました。

PostgreSQL ネイティブ接続の課題

DuckDB では PostgreSQL を経由して接続を提供しましたが、以下の理由からHTTP 越しの接続の方が有利でした。

  • スケーリングの困難さ
    • ポート 5432 での直接接続は、再接続欠落や TTL（生存期間）管理、アイドル接続制御が難しく、長時間接続のコストが高くなりました。
  • 負荷分散ツールの不足
    • pgwire の負荷分散ツール類は HTTP に比べて極めて乏しく、AWS NLB/ALB と比較すると操作性に劣ります。
  • クライアント互換性の維持コスト
    • PostgreSQL クライアントの種類は無限に近く、それぞれ固有の挙動を要求します。
    • 顧客からのカスタムクライアント・ライブラリ修正要望に対応するための時間を消費し、カバー率は十分ではなかったため、倉庫構築の本質的な価値創造に時間を割くべきと考えました。

新しいアーキテクチャ：Trino と HogLake

重要なのは技術そのものではなく、ユーザーにどのような体験を提供できるかです。そこで以下の新ソリューションを構築しました。

  • Trino の独自版の採用
    • すべてを再構築し、分散処理能力を活用しています。
  • HogLake（独自のオープンな表形式）の開発
    • データ永続化のために新しい表形式を開発し、DuckLake における互換性の問題を回避しました。
  • 堅牢性の検証
    • 設計パートナーに渡す前に、PostHog の自社のピタバイト規模データをテストし、安定性を確保しました。

まとめと展望

現在の倉庫が低速または高価であればお問い合わせください。特に大量データのクエリが必要なケースで強くお勧めします。私たちは常に最適な設計パートナーをお探しのところです。

同じ日のほかのニュース

一覧に戻る →

2026/11/03 3:21

Astra は、Qwen の改善のために重みを読み書きできます。

## Japanese Translation: このテキストにおける最も重大な突破は、「Weight-Space Programming（ウェイトスペースプログラミング）」という技術の導入であり、GPT-6 Astra によって具現化されたものであり、自然言語プロンプトを通じてニューラルネットワークのウェイトを直接読み書きすることを可能にする。この機能は従来の手法とは異なり、重み行列をコードとして扱い、従来のトレーニングデータや勾配を用いないで編集できるようにする。 8 つの実験からのエビデンスがこの技術の力を裏付けている： 1. **解釈可能性:** Astra は、Atari ネットワーク（例：Breakout、Pong）におけるゲームの目標を、生ウェイトのみを解析することで特定したほか、拡散モデルの出力形状を予測し、小型トランスフォーマーモデルにおいてフォワードパスを実行せずに言語や「コピーヘッド」を検出することに成功した。 2. **修復と生成:** カート制御ネットワークにおけるローカル最小値の失敗を、ウェイトの一部を編集することで是正し、Atari ゲームおよび将棋（Go）に対して、ゼロから高パフォーマンスのアルゴリズムを生成した（百万ステップ以上トレーニングされた PPO モデルを凌駕）。 3. **診断と改善:** Astra は、既存モデル（Qwen3.5）に潜むシコフィアンシー（sycophancy）や数学的推論の弱点といった隠れた問題を成功裏に診断し、失敗を引き起こす特定の内部方向性を特定して除去することで、パフォーマンススコアを大幅に向上させた。 この技術は「ゼロデータ能力ステアリング」、recursive self-improvement（自己改善）、およびバックドアなどのリスクに対する徹底的な監査を可能にする一方で、明確な限界が存在する：それは、基礎的な能力を欠くシステムに対して新たにそのような能力を自動的に付与することはできない（例：Gemma 3 の数学的性能の向上には失敗）。結局のところ、ウェイトスペースプログラミングは、特定の修復のために大規模なデータセットへの依存を迂回させつつ、厳格な内部監査を可能にすることで、AI の開発を根本的に変革する。

2026/11/02 22:25

愛するウェブサイトならバックアップを取っておくべきです。

## Japanese Translation: 最も重要な教訓は、ウェブサイトが消滅する前に個人がアーカイブ化の責任を引き受ける必要があるという点です。元のホストに依存することは、デジタル上の記憶をハイジャックや削除に対して脆弱にさせるためです。この緊急な必要性は、2004 年から活動していたアニメおよび Ochaken トイラインのファンサイトである teapuppies.com の突然の消滅によって強調されました。著者はアーカイブ化を行わなかったため、同サイトがオフラインになり、後にギャンブル広告に置き換えられました。投稿では、ウェブサイトが消える前に保存について個人の制御を維持するために、標準形式（WARC/WACZ）を用いた個人ウェブアーカイブ化を推奨しています。具体的な 3 つの主なワークフローは以下の通りです。(1) ArchiveWeb.page Chrome 拡張機能：この拡張機能をインストールし、ページにアクセスし、「Start Archiving」をクリックしてコンテンツと対話し、ツールバーから停止することで、単一ページ、サイト全体、または SNS プロフィールを保存できます。アーカイブはダッシュボードでプレビューでき、WARC ファイルとしてローカルでの表示や共有のためにダウンロード可能です。(2) 独立した ArchiveWeb.page アプリ：ブラウザ拡張機能と同様に機能しますが、独自のウェブブラウザを含み、直接アーカイブメニューに開きます。(3) Browsertrix：開始 URL（例：teapuppies.mistys-internet.website）からリンクをたどりながら大きなウェブサイトや SNS プロフィールを自動的にクロールするために推奨されます。設定を通じて /episodes/ セクションや単一ページ（関連する全コンテンツを含む）など特定のセクションを対象としてカスタマイズできます。アーカイブされたコンテンツは、内蔵インターフェースを使用してブラウザで再生するか、WARC/WACZ ファイルを ArchiveWeb.page アプリまたは ReplayWeb.page ウェブサイトに読み込んでプライベートに共有できます。公開共有については、オープンソースの ReplayWeb.page インプット機能を使用することで、アップロードしたアーカイブファイルと JavaScript のみを必要としてウェブページに再生ビューアを追加できます。バックアップデータは単一の WACZ ファイルにまとめられており、複数のコピーで安全に保存したり、友人間で配布したりすることが容易になります。著者はこれらのツールが雇用主によって開発されたことを開示し、ほとんどが無料（Browsertrix は有料サービスを提供しており、7 日間の試用期間があり、その後は使用回数による課金制）であることを注記し、それらを個人ウェブアーカイブ化のための最良の選択肢として推奨しています。

2026/11/03 2:05

Launch HN: Momentic（YC W24）– ユーザーのアプリを利用してバグを検知するエージェント

## Japanese Translation: Mo は、エンドツーエンドのテストを自動化し、リリース前にバグを捕捉する、一般利用可能な AI エージェントとして、ソフトウェア品質保証における大きな飛躍を表します。従来のツールとは異なり、Mo は動的な知識基盤とアプリグラフマッピングを活用して複雑な画面フローを理解することで、検証を開発ループに直接統合します。これは、「代理型品質プラットフォーム」として機能し、検証がエージェントループに内在しています。 该系统は大幅な効率向上を実現します：ユーザーはテストの作成/維持において **3 倍の高速化** を報告しており（日常サイクルを数時間から数分に短縮）、また **6.3 倍のパラレルテスト実行** を達成しています。Mo は UI 変化を自動的に修復し、800 万回以上の自動修復が確認されており、Notion や Webflow などの大手企業向けに約 7,070 万回のテスト実行を完了させています。数百の手動ケースを取り替え、CI パイプライン内でステップ単位の失敗エビデンスを提供することでデバッグを簡素化します。 ベンチマークにおいて、Mo は他のエージェントよりも顕著に優れており、例えば多様なプロジェクトを対象とした QA ベンチテストでは、次点のエージェントが約 86 件のバグを検出したのに対し、Mo は 60 分間に約 269 件のバグを特定しました。具体的な成果には、2 段階認証のプロンプトスキップや破損したモバイルフローなどの重要なロジックエラーの捕捉が含まれます。该平台は簡素化されたワークフローを提供し、ユーザーが自然言語（YAML）でテストを記述でき、AI 駆動のトリアージと修復を開発パイプラインにシームレスに統合することを可能にします。