コマンドラインツールはHadoopクラスタより235倍高速になりうる（2014年）

 (adamdrake.com)
9 ポイント 投稿者 GN⁺ 2026-01-19 | 2件のコメント | WhatsAppで共有
  • 約1.75GBのチェス対局データをHadoopではなくコマンドラインツールで処理した結果、わずか12秒で完了し、Hadoopの26分と比べて235倍以上高速な性能を示した
  • grep, sort, uniq, awk, xargs, mawk などの基本的なシェルコマンドを組み合わせてストリーミング処理パイプラインを構築し、メモリ使用量をほぼ0に維持
  • xargsによる並列処理とmawk最適化によってCPUコアの活用率を高め、I/Oボトルネックを最小化
  • 同じデータセットをHadoopクラスタ（c1.mediumインスタンス7台）で処理する場合と比べて、コストと保守負担が大幅に低い
  • 単一マシンでも効率的なデータ分析が可能であることを示し、不要なBig Dataツール利用への警鐘を鳴らす

序論: Hadoopより高速なコマンドライン処理

  • 約200万件のチェス対局データをAmazon EMRとmrjobで分析した事例を見て、同じデータをコマンドラインベースのストリーミング処理で再現
    • Hadoopクラスタ（c1.medium 7台）では26分かかり、処理速度は1.14MB/sec
    • ローカルノートPCでは12秒で完了し、処理速度は270MB/sec
  • 単純な結果集計作業では、Hadoopよりシェルパイプラインのほうがはるかに効率的であることを実証
  • シェルコマンドを組み合わせれば、Stormに似た並列ストリーム処理構造を単一マシン上で実装可能

データ構造と準備

  • データはPGN(Portable Game Notation) 形式のチェス対局記録で、各対局の結果は "Result" 行に表示される
    • "1-0" は白の勝ち、"0-1" は黒の勝ち、"1/2-1/2" は引き分け
  • GitHubのrozim/ChessData リポジトリから約3.46GBのデータセットを確保
    • Tom Haydenの実験データ（1.75GB）の約2倍の規模

基本パイプラインの構築

  • I/O限界を測るために cat *.pgn > /dev/null を実行すると、約13秒(272MB/sec) を要した
  • 基本的な分析パイプライン: 
    cat *.pgn | grep "Result" | sort | uniq -c
    • 実行時間は約70秒で、Hadoop比で約47倍高速
  • sort | uniq の代わりにAWKを使って結果を直接集計
    • 実行時間は65秒、メモリ使用量はほぼゼロ
    • grep が単一CPUコアを占有し、ボトルネックが発生

並列化と最適化

  • xargs を使って grep を並列化 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
    • 実行時間は38秒、約77倍の高速化
  • grep を削除し、AWK単独フィルタリングで段階を単純化
    • 各ファイルごとの結果を統合するため、二重AWKパイプラインを構成
    • 実行時間は18秒、約174倍高速
  • mawk に置き換えるとさらに最適化 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
    • 実行時間は12秒、Hadoop比で235倍高速、処理速度は270MB/sec

結論: シンプルさの効率

  • 大規模な分散処理が必要な場合を除けば、単一マシン上のシェルツールの組み合わせのほうが速く、経済的
  • Hadoopはしばしば、リレーショナルDBや単純なスクリプトで十分な作業に対しても過剰に使われている
  • コマンドラインベースのストリーミング分析は、性能、実装コスト、保守性の面で優れた代替手段である

関連記事

2件のコメント

 
dongho42 2026-01-20

昔、タコベル・プログラミングという言葉がありましたが、似たような哲学ですね
 
GN⁺ 2026-01-19
Hacker Newsのコメント

  • この記事が2014年のものだというのが一番悲しい点だ。
    今では Airflow, dbt, Snowflake のような抽象化レイヤーがさらに増え、実質的にRAMに全部収まるようなデータセットにまでこうしたものを被せる状況になっている。
    スタートアップが1日10GBにも満たないログを処理するために、分散クラスタへ月5,000ドルを燃やしている。理由は、「Modern Data Stack」を使えば昇進につながる一方、bashスクリプトで解決すると「スケールしない」と言われて軽視されるからだ。効率とインセンティブが完全にずれている

    • 最近の面接でも「スケーリングの問題」として話していたが、実際には1台のマシンに十分収まるケースが多かった。
      1日1GBのJSONを ingest する事例もあったが、私が「1台で十分だ」と説明したところ、「技術的には正しいが、私たちが求めている答えではない」と言われて落とされた。
      今どきのマシンは TB級のRAM と数百コアを備えている。1台のマシンはすでにとてつもなく大きい
    • これは単なる昇進の問題ではなく、採用の仕組みの問題でもある。
      DevOps経験者を採るときに派手なフレームワーク経験を重視するので、結局その人たちが会社に来ても同じことを繰り返す。
      誰も異を唱えないので、最終的にはデスクトップ1台で十分な仕事を複雑にしてしまう
    • この20年、「かっこよく見える技術」ではなく「適切な技術」を使ってきたが、結局レイオフされた。
      最新フレームワーク がほとんどない職務経歴書のまま1年以上求職中で、自分がバカみたいに思えてくる
    • 会社でも似たようなことを見ている。1日に数GBのデータを複数システムで回すために、以前ならPythonスクリプトで1週間で終わっていたものが、今では何カ月もかかり、しかもよく壊れる
    • 今では 128GB RAMのノートPC も珍しくなく、サーバーははるかに大きい。
      2014年には4GBが一般的だったが、今はSSDのストリーミング速度も速いので、ローカルSSDから読む方がクラスタより良いことさえある

  • 筆者です！
    昔の記事が今でも役に立っていると聞けてうれしい。
    状況がさらに悪化したという意見には同意するが、その一方で microservices への盲信 から離れつつある動きも見えていて、それは救いだ。
    性能改善に取り組むすべての方を応援している。まだ 希望 はある

    • Adam、ありがとう！
      記事を何度も読み返し、刺激を受けて Waters-Series をJavaScriptに移植し、ストリームパイプライニングを実装した

  • 最近の業界では、Sparkや分散ツール がデータエンジニアリングの正解だという認識が強すぎる。
    Web開発でSPAフレームワークを過剰に使う現象と似ている。
    私の助言はこうだ。

    • マネージャーは特定技術（Spark, React）を要求せず、問題解決能力 のあるエンジニアに任せること
    • テックリードは「このパイプラインは20GBまでは処理でき、それ以上になったらX/Y/Zで拡張する計画です」と正直に言うこと。
      マネージャーが聞きたいのは「すべてが無限にスケールする」ではなく、「安定して動く」という確信だ
    • ほとんどの会社は 小規模データ を扱っている。
      データサイズはべき乗則に従うので、ペタバイト級データを扱うエンジニアはごく少数だ。
      それでも年収を上げるためにそうした経験を職務経歴書に書こうとするので、過剰なエンジニアリング が生まれる
    • 以前、有名ユニコーン企業で働いていたとき、マネージャーが「次の四半期にはSparkを使わないといけない」と言った。
      理由を聞くと「とにかく使わないといけない」だった。たぶん 職務経歴書向け か、誰かの政治的な理由だったのだろう

  • この記事に関連する歴史の話。
    mrjob というツールはHadoopなしでもローカルモードで実行できた。
    小さなデータセットではクラスタよりずっと速い。特にAWS EMRのような一時クラスタよりも速く終わった。
    ただ、著者のアプローチはそれよりさらに効率的だった気がする。
    MapReduce は大規模スケールを容易にする一方で、小さなデータには 非効率な制約 が多かった。
    2010年代前半には mrjob でペタバイト級データを処理していたが、今ではほとんど使われない

  • データエンジニアとして働いていたとき、Bash/Pythonスクリプト をC#に書き直してJSON処理速度を1GB/sまで引き上げた。
    単に ストリーミングパース のような最適化だけでも大きな差が出た。
    だから気になる — いったいどの程度のデータ量からクラスタ化が本当に意味を持つのだろう？

    • 逆に15年前には、複雑なC#システムを bash + Python に置き換えて、ずっと速くなったこともある。
      私の基準では、1日以上かかる処理なら分散処理を検討する価値がある
    • 以前のPyConパネルで、有名なデータサイエンティストが「Excelの方がPandasより良い」と言っていた。
      データが大きいときはサンプリングしてExcelで分析していたそうだ。今はLLMのおかげで、簡単なPython/Bashスクリプトも簡単に書ける
    • 処理時間以外では、ローカルディスクに収まらないデータ も別の基準になる。
      S3のようなオブジェクトストレージから直接読み書きすることもでき、今では100GB/sの速度も可能だ
    • このコメント に出ているチェスのデータセットは約14TBだ。
      ディスクには入るが、一般的なノートPCには無理なサイズだ
    • JSONをストリーミングでパースする方法が気になる。多くのパーサーは構文検証のために全体を読む必要があるが、これをどう解決したのか知りたい

  • データの「大きさ」は 何をするか によって変わる。
    たとえば手術データでは単純な統計ならbashで十分だが、医師の経験と成功率の相関を計算しようとすると複雑さが急激に増す。
    だから企業の立場では、「うちはSparkを使っています」と言う方が、「質問ごとに適したエンジンを作ります」と言うよりずっと簡単なのだ

    • それでも SQLite だけで50GB〜2TBのデータを処理できる。
      言及されているすべての問題は、単一サーバー上の単純なツールで解決可能だ

  • この記事は以前にもHNに何度も投稿されている。
    2018年版、2022年版、2024年版 はいずれも同じ投稿者によるものだ

  • 昔の Shakti ウェブサイトの紹介文句を思い出す。
    “1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
    出典

  • 多くの開発者は Windows環境 で学んだため、CLIツールに慣れていない。
    しかしCLIは暗黙のループ、フィールドの自動分割、正規表現の並列適用など、強力な機能を提供する。
    そのおかげで素早く ad-hocソリューション を作れ、大規模システムを使う前の良い出発点になる

  • チェスデータをさらに大きくしてベンチマークをやり直したらどうなるだろうと思う。
    今では Lichessデータセット は約70億局、圧縮で2.34TB（非圧縮で14TB）だ。
    この規模でHadoopが勝てるのか気になる

    • 高速SSDを何台も1台のサーバーに積めば、今でもEMR+S3より速い気がする。
      ただし、その分だけ 専用サーバーの運用管理 が必要になる。
      EMRはデータアクセス頻度が低いとき（1日1〜10回）に並列処理するために設計されたモデルだ
    • 圧縮データはローカルSSDに十分収まり、ストリーミング展開 も可能だ
    • こういうデータで何を計算するのか気になる。NVL72で試してみたら面白そうだ