ハクソク

世界を動かす技術を、日本語で。

データ分析のための分散アーキテクチャ追求における失われた10年？

371日前原文(duckdb.org)

概要

  • 2012年製MacBook ProでDuckDBの性能を検証し、分散アーキテクチャの必要性を再考する提案。
  • 古いハードウェアでも現代的なSQL分析が十分に実行可能であることを示す確認。
  • 2023年モデルとの比較で約20倍の速度向上を記録するも、絶対的な差はユーザー体験に大きな影響を与えない指摘。
  • DuckDBの移植性と依存性の少なさが、古いOS上での動作を容易にする利点を強調。
  • 分散処理への過度な投資が本当に必要だったのか、歴史的観点から再評価することを推奨。

2012年製MacBook ProでDuckDBをベンチマーク：分散アーキテクチャの10年は無駄だったのか？

データ分析基盤の進化に関する背景

  • データ量の成長よりも ハードウェア性能の進化 が速い現状を指摘すること
  • ほとんどの有用なデータセットは 単一ノードで処理可能 になる「データ特異点」の到来を予測する提案
  • Amazon RedshiftやSnowflakeの実測値では、 中央値100MB、99.9パーセンタイルでも300GB未満 のデータ読み込みである確認
  • 2012年当時の MacBook Pro の性能に着目し、データ分析革命が既に可能だったのではないかという疑問を提示すること

2012年製Retina MacBook Proの特徴

  • 初の内蔵SSD搭載 モデルであり、4コア2.6GHz Core i7 CPUを装備する確認
  • 16GB RAMへのアップグレードが可能で、当時としては高性能ノートPCであった説明
  • 現在もDuckDB Labsオフィスで現役稼働していることを紹介すること

ソフトウェア環境とDuckDBの移植性

  • OSを OS X 10.8.5 “Mountain Lion” にダウングレードし、当時の環境を再現すること
  • DuckDBは 依存性が少なく高い移植性 を持つため、最小限の変更で古いOS上で動作可能である確認
  • C++11対応のコンパイラ不足等、当時のビルド環境の制約も考慮すること

TPC-Hベンチマークによる性能測定

  • TPC-Hベンチマーク（スケールファクタ1000） を用い、lineitemとordersテーブルでそれぞれ60億・15億行を処理すること
  • DuckDBデータベースサイズは約265GBで、16GB RAMでは キャッシュによる高速化が限定的 となる説明
  • 22クエリを5回ずつ実行し、中央値を測定することでノイズを除去する手法を採用すること
  • すべてのクエリが完了し、1分～30分程度の待ち時間で現実的な分析が可能である実証

2023年製MacBook Pro（M3 Max）との比較

  • GeekBench 5スコアで CPU性能約7倍（全コア）、シングルコアでも約3倍 の差を示すこと
  • RAM・SSD速度も大幅に向上しているが、 ディスプレイのサイズ・解像度はほぼ同等 である確認
  • 各クエリの実行時間は7～53倍高速化、 幾何平均で約20倍の改善 を記録すること

再現性と公開リソース

  • GitHubでバイナリ・スクリプト・クエリ・結果を公開 し、再現性を担保すること
  • TPC-H SF1000のデータベースファイルもダウンロード可能である案内

考察と歴史的再評価

  • 2012年製ノートPCでも 6億行規模の分析クエリが現実的な時間で完了 することを確認
  • 新旧マシンの差は 定量的なものであり、ユーザー体験としては許容範囲 である主張
  • DuckDBの アウトオブコア処理機能 により、メモリ不足でもディスク利用で大規模データ分析が可能である説明
  • 2012年時点で既に 単一ノードSQLエンジンによる分析基盤構築が可能だった のではないかという歴史的仮説を提示すること
  • ベクトル化クエリ処理技術も2005年には登場しており、分散システムへの過度な投資が本当に必要だったのか再考する提案

結論

  • 2012年の高性能ノートPCと現代的なSQLエンジン（DuckDB）があれば、 分散アーキテクチャに頼らず大規模分析が可能 であった提案
  • この10年間で失われた可能性や、 今後のデータ分析基盤の設計方針 を再検討すること

Hackerたちの意見

俺の2014年のMBP、先週やっと引退させたんだ！最初はたまに起動しなくなって、数週間後にはもうたまにしか起動しなくなったから、そろそろ引退の時かなって思った。新しいノートパソコンは実はかなり安い買い物で、Macじゃないし、いろんな面で古いMBPよりちょっと遅い。でも、古いノートパソコンは仕事で使う「大きな」VMと同じくらいの性能なんだ。今の流れは、BigQueryでボックスに収まらないような0.001%のクエリをやって、ちょっとだけ準備して中間結果をボックスに収まるように整えてる。それをVMに保存したparquetに抽出して、PythonノートブックからDuckDBを使って分析してる。DuckDBは、できることだけじゃなくて、やり方を根本的に変えてくれた。必要な要素は前からあったけど、DuckDBがそれをまとめて、使いやすさが全然違う。結合とかするのが、pandasでやるよりずっと楽になったよ。

└

まだ持ってるけど、放置されてる感じ。どうしたらいいかわからないし、捨てるのももったいない気がする。Appleストアでは返品できるけど、これに関しては何ももらえない。「はい、こちらで処理します」って感じ。画面の端が剥がれ始めて、後継機（タッチバー付きのMBP）の画面は完全に壊れてる（たぶんコネクタケーブルのせい）。使い道がないけど、捨てるのはもったいない気がするんだよね。

データベースは、ディスクサイズやクエリパフォーマンスだけじゃないんだ。データベースは会社の文化やプロセス、ワークフロー、コラボレーションを反映してる。周りにはマスターデータ、ビジネスプロセス、トランザクション、分散アプリケーション、規制要件、レジリエンシー、運用、レポート、ツールなどのエコシステムがある。データベースの役割は、クエリパフォーマンスを提供するだけじゃない。エコシステムにフィットして、いろんな面で全体的な役割を果たし、技術的な期待と非技術的な期待の幅広い範囲に応える必要がある。役に立つデータセット自体がハードウェアの進化に追いつかなくても、エコシステムの複雑さはハードウェアやAIの進化を確実に上回る。エコシステムへの全体的な適応がデータベースの選択を決めるんだ、クエリパフォーマンスじゃない。技術は孤立して動作するわけじゃない。

└

いや、データベースは自分がどう使うかによって変わるんだ。レポートは結局クエリに過ぎないし。他の名前を挙げたものがデータベースと直接関係あるとは思えない。データベースの唯一の目的はデータを保存して読み取ること、それが全てだ。だから、クエリパフォーマンスは最も重要な指標の一つなんだよ。

└

そして、会社の技術選択に影響を与えるのは、やっぱり広い意味での技術文化なんだ。ピカピカのものを追いかけて、自分の仕事に無理やり押し込もうとする技術者たち - たぶん自分の履歴書を膨らませるために皮肉っぽくやってるか、実際に正しいことだと思ってるか - が、技術チームが技術についてどう考えるか、そして自分の仕事が何だと思っているかに大きな影響を与えてる。2012年には、XML全盛期から回復しつつあって、NoSQLブームの真っ只中で、すべてがウェブスケールで分散ファーストのマイクロサービスだったりして。で、あの混乱の後、前にあったものを愛することを学んだんだ：つまり、お願いだからSQLをくれ！ :D

└

データを大きくするのは、ディスクスペースを増やしたりパフォーマンスを下げたりせずに、フォントサイズを大きくすることでいつでもできるよ！

うわ、ビッグデータチームに入っちゃった。99%のフィードが数GB以下なのに、ScalaとSparkを使わなきゃいけない。開発も実行も遅くてたまらない。

└

a) ScalaはJVM言語だから、周りで一番速い言語の一つだよ。Pythonよりもずっと速い。b) フィードの1%はどれくらいの大きさで、全体の結合データセットのサイズはどれくらいなの？結局、それがプラットフォームを作る理由なんだよね。単純なユースケースのためじゃない。

└

今の時点で誰かがScalaを書くなんて信じられない。

└

1年後、チームを説得して、最もホットなデータセット（約150万レコード）をDynamoDBからRedisに移行することができた。マジで、みんなでDynamoDBの使い方を誤ったり悪用したりするのに、すごく時間をかけてしまったよ。

Rコミュニティは小さなデータに一生懸命取り組んでる。俺はまだRのdplyrでメモリデータを扱うのが大好きだ。DataTableはエレガントで速いし。CRANのパッケージはどれも高品質で、メンテナーが2ヶ月間メールに返信しなかったら、そのパッケージは自動的に削除される。ほとんどのパッケージは、キャリアのほとんどをこれに捧げてきた大学の教授から来てるんだ。

└

インメモリのデータフレーム中心のワークフローの大きな部分は、一度に一ステップずつ進めて結果を確認するのがどれだけ簡単かってことだよ。データベースだと、クエリを実行して結果を見てから、その結果に対してクエリを実行するのが難しい。私にとっては、DuckDBでpandasやdplyr、polarsを置き換える際に欠けている部分なんだ。

ちょっとした話なんだけど。2010年に、当時人気だったトレント技術に触発されて、完全に分散したDBのアイデアを考えていたのを覚えてる。この場合、クライアントはサーバーと違わないんだ、持っているデータの量だけが違う。おそらくトレントのようにデータを受け取ることになるだろう。私が不思議だったのは、クライアントが他の人に自分のクエリを実行してほしいと思っているのに、全てのデータをロードして他の人のためにクエリを実行したくないってことだった。そして、異なるシードに送られた競合する更新クエリをどうやって防ぐか。Crockfordの分散ウェブのアイデア（すべてのページがトレントのようにホスティングされる）も良いと思ったけど、深く考えたわけではなかった。ウェブ3の議論を見て、誰かが一つのサーバーにデータをアップロードすると、多くのホストがその一部をホスティングする仕事をすることになり、ちょっとした動きでもウェブ全体に膨大な作業を引き起こすって指摘していたのを見て、なるほどと思った。

最近の示されたところによると、Amazon RedshiftとSnowflakeの中央値スキャンは、実行可能な100MBのデータを読み取って、99.9パーセンタイルは300GB未満を読み取る。だから、特異点は思っているよりも近いかもしれない。これってあまり言ってることがないよね。99.9%の嵐に対して1:1000年の嵐の堤防が過剰に作られているって言ってるようなもんだ。堤防が作られた嵐のためのものじゃないんだから、わかるでしょ。データベースは1日に1000のクエリを実行するかもしれない。設計目的の焦点は、尾の部分にあるクエリに本当にあるべきなんだ - それらは小さなデータベースで実行できるのか？どれだけの価値を加えるのか？データベースはそれらを処理するためにどんな機能が必要なのか？などなど。それがRedshiftデータベースを正当化するべきことなんだ。もしくは、赤いものは速いから、1TBのデータを保持するためにプロビジョニングすることもできるよね、みんな知ってるし :/

└

これってあまり言ってることがないよね。逆に、単にデータサイズについて多くを語っているだけだよ。それに関して言えば、Redshiftやその仲間が選ばれた理由は重要かもしれない（私の組織ではRedshiftが標準として使われていたので、小さなデータセットでも管理側が標準化を望んでいたため、良くも悪くもそれに入れられていた）、でも、もし常に小さなデータセットを扱っているなら、使っているソリューションを再考した方がいいかもしれないね。

└

1/1000の仕事に対して別のアプローチを取ることもできるよ。例えば、それをやらないとか、近似するっていう方法。昔、終わるのに100年かかるプログラムを書いたことがあって、それを約20分で終わらせる近似を開発したことを覚えてる。

└

もし1TBのデータしかないなら、現代のサーバーではRAMに載せられるよ。

これ、2015年のクラシックな論文「スケーラビリティ！でも、どんなコストで？」の仲間みたいだね。https://www.usenix.org/system/files/conference/hotos15/hotos...

これ、「コマンドラインツールはあなたのHadoopクラスターより235倍速い」っていう記事と同じエネルギーを持ってるね。[1] [1] - https://adamdrake.com/command-line-tools-can-be-235x-faster-...

歴史は「もしも」で溢れてるけど、2012年にDuckDBみたいなのがあったらどうなってたんだろう？主要な要素は揃ってたし、ベクトル化されたクエリ処理は2005年にはもう発明されてた。データ分析のために分散システムに移行するっていう、今見るとちょっとバカみたいな流れは果たして起こったのかな？記事の要点は好きだけど、結論は後から考えたように聞こえる。すべての要素は揃ってたし、著者はそれをうまく捉えてるけど、実現するための適切なインセンティブ構造がなかったのかもしれない。2010年から2015年の間、業界のほとんどが「大量のデータに収束するだろう」って本気で感じてた。なぜなら、この時期まで、業界はデータキャプチャやセンサーをあちこちに設置することの豊富さに直面したことがなかったから。こういうシナリオでは、ほとんどの場合「同じ容量で効率的にやる方法を探そう」っていうよりも「持てるボリュームに関係なく、分散処理できるように投資しよう」ってなるはず。OpenAI/ChatGPTとDeepSeekの関係も同じで、数学はいつでもそこにあったけど、最初に走り出したのはOpenAIで、効率は劣るけど異なるインセンティブ構造を持ってた。

└

それは起こらないよ。問題は、人々が自分のアプリがすぐにウェブスケールになると信じていて、だから早急に問題を解決する必要があると思ってることだよ。何度も痛い目に遭った後に、シンプルさの必要性が生まれるんだ。NoSQLも同じで、苦しんで初めて戻ることの大切さがわかる。つまり、こういうツールはバブルの痛みを経験した後にしか戻ってこない。内部では実現できないんだ。

BigQueryに大きな分析データセットがあって、その上にインタラクティブな探索UIを作ったんだけど、どんなクエリもだいたい2秒以内で終わったよ。これのおかげで、無限の分析の洗練ができるすごくシンプルなアプリができたし、しかも速い。事前計算された分析アプローチと交換するなんて絶対にしたくないね。リアルタイムで探索する自由は、啓発的で解放感がある。固定された分析に再計算を制限してると思うけど、リアルタイムのインタラクティブな分析も面白い分野だよ。