きっと、ずっと、会議は踊る

エンジニアリングとアイドルとロックンロール

愛と偏屈にまみれたHadoopの話(前編)

はじめに:危険なのでマサカリは投げないください

昨年末、久しぶりに技術的なテーマについてのエントリ

shoe116.hatenablog.com

を書いて、個人的には結構自信作だったんだけど案の定そんなにPV*1は伸びなくて、ちょっと拗ねた。でも、まぁ別に多くの人に読んでもらうことを目的に文章を書いてるわけじゃないし(もちろんPVは多ければ多いほど嬉しい)、今回も懲りずに技術的なエントリでも書いてみようと思う。ただし、マサカリを投げる*2のは危険なのでやめてほしい。この文章は僕が僕の理解の中で時分の思考を整理するために書いているのであって、僕が知らないこと・間違ってることもいっぱいあるのは自覚しているので、こちらまでご連絡くだされば謹んで訂正いたします。

1. Hadoopって?

最近*3地上波でも良く耳にするようになったDeep Learningに代表される機械学習には、途方もないほど膨大なデータと、それを扱うためのストレージ、そして計算環境が必要だ。

"Hadoop"はそんな場面で使える、気持ちの悪い黄色いゾウさんが目印の「膨大なデータを扱えるファイルシステム兼計算フレームワーク」で、その実装はインターネットに全公開されている*4。ちなみにその全貌を理解しなくてもとりあえずは使えるし、このエントリを読むのに何の支障もない。ただ、こんな章を作ってなんだが、以降の話は"Hadoop"を知らない人には完全にちんぷんかんぷんな内容になってしまっていると思うので、そのことについては先に謝っておきたい。

2. HDFS(GFS)と広義のMapReduce

Hadoop、つまりHDFS(GFS)とMapReduceとは?」という議論は、ぶっちゃけGoogle様の10年以上前の以下の論文

  1. The Google File System
  2. MapReduce: Simplified Data Processing on Large Clusters

 が全てで、それ以上でも以下でもないのだろうけど、それぞれのAbstractに

We have designed and implemented the Google File System, a scalable distributed file system for large distributed data-intensive applications. 

 MapReduce is a programming model and an associated implementation for processing and generating large data sets. 

と明記されているとおり、これらは実装*5についての論文なので、"そもそもHadoopが、どんな課題をどうやって解いたのか?"というアイディアの部分は(少なくともコンピュータサイエンスを体系的に学んだことのない僕にとっては)それほどわかりやい説明がされていたわけではなかった。なお、このエントリでは以降"MapReduce"と言う言葉を、現在のApache HadoopにおけるMapReduceの実装ではなく、上記論文で述べられた

Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key.

という広義の意味で用い、Apache TezApache SparkのDAGも含む概念とする。

3. Hadoopの解いた課題とアプローチ

さて、「なぜHadoopが必要なのか?」という問いに対してよくなされる返答は

テラバイト(1兆バイト以上)からペタバイト(1,000兆バイト)におよぶデータを高速・効率的に処理するために、新たな手法が必要となりました。(中略)そこで考えられたのがデータを分散並列処理する手法です。つまり、データを複数のサーバに分散させ、各サーバに計算処理させることで、1台のコンピュータでは難しい大容量データの高速分析処理を行おうというものです。  (ストレージ Hadoopとは - Fujitsu Japan

というものだが、この「そこで考えられた」というのが、「何を、どう考えたのか」というのを僕は恥ずかしながら最近まで全く理解できないでいた。ここではそれについ僕の理解を書いておく。

まず、上記論文が発表された2003年当時、Google様が見ていた課題やそのアプローチは「データ量が増えすぎて既存のストレージだと、もうどうにもならない」というような、(一般的な企業でのHadoop導入事例でよく見られる)対処療法的なものではないと僕は思っていて、おそらく以下の2点だと推測している。

  1. ムーアの法則は終焉が近く、集積回路の進化はサチる
  2. 処理すべきデータは、指数関数的に増え続ける

つまり、「計算リソースの進歩のスピードが処理すべきデータ量の伸びに追いつかない」という状況が避けられない中、そのソリューションとして作られたのがGFSとMapReduceだ(当然これは僕の憶測で、ソースを出せと言われても困る)。

Hadoopが採った方法は非常にシンプルで、上記の通り並列分散処理なのだが、結局これはどういうことなのか?というのはあまり語られていない気がしている。これはあくまでも僕*6の独断と偏見に基づく解釈だけれど、すごく簡単に言うと「単体の計算リソースの伸びはもう期待できそうにないから、ネットワークでなんとかする」ということなんだと思う。もう少しエンジニアっぽくかっこよく言えば、「短期的には解決しそうのないCPUバウンドの課題を、ネットワークを含めたI/Oバウンドに置き換える」というアプローチだ。

こう考えてみると、Hadoop上のファイルが都度圧縮・解凍するのを前提に作られている一方で、RAIDより保存効率の悪い3レプリカがデフォルトになっているのもしっくりくる。圧縮の目的はストレージの節約というよりI/Oの削減で、3レプリカは出来る限りネットワークを介したファイルの転送を抑える工夫だ(もちろん冗長性の確保もあるが、それだけならRAIDでいいはずだ)。Hadoopは「ネットワークは常に詰まっているが、CPUは暇している」前提で設計・実装されていて、逆に言えばシステムのボトルネックを意図的にI/Oに寄せてあるのではないだろうか。

さいごに:後編のプロミス

泣く子も黙るSIerの雄、NTTデータ様の解説ページ「分散処理技術「Hadoop」とは:NTTデータのHadoopソリューション」に記載されているHadoopの特長は

  • 単純なサーバの追加によってスケーラビリティを実現
  • 非定型データの格納を想定した処理の柔軟性を実現
  • コモディティ品を利用した基盤構成・対象外性

 で、この手の説明を見たり聞いたりすることがとても多いのだけれど、たぶんこれは2011年(Apache Hadoop 1.0.0の時代)当時の話であって、今ではもう時代遅れなものだと思っている。最近そのことについて結構大掛かりなイベント*7で話す機会があって、資料もわりとちゃんとつくったから、後編はその話を書こうと思う。

ただ、昨日見に行ったツアーファイナルがあまりに良くて、頭の中が完全にBiSHにそまっていて、心の底からのプロミスはできないのだけれど。

www.youtube.com

 後編書きました

 半年かかったけど後編も書きました。

shoe116.hatenablog.com

注釈等

*1:Page Viewsのこと。細かいことを言わなければ、つまり“何回に読まれたか”

e-words.jp

 

*2:「技術的に鋭いツッコミをすること」と説明されることが多いが、無駄なマウンティングが含まれない限り、そうは呼ばれない気がしている。投げられたマサカリは大抵無益な2次災害を引き起こすので、周りの安全が確認できない場合(当然オンラインの場合は全てそうだ)は自重したほうが世界のためだとは思う。

*3:それほど最近でもない気がするが、僕みたいな機械系卒のWeb系という畑違いも良いとこのエンジニアがDeep Learningの“破壊的イノベーション”っぷりを知ったのがILSVRC2012なので、かれこれ5年くらいか・・・

*4:いわゆるOSSというやつで、気になる人はGitHubを御覧いただきたい

*5:この「実装」という言葉に馴染みが無くて、かつ興味がある稀有な方は是非以下のエントリを読んでいただければと思う。

shoe116.hatenablog.com

*6:一応、事前に友人のカイ君

twitter.com

にレビューをお願いしたが、文責は全て僕にある

*7:"Battle Conference U30"なる、若手エンジニア向けのイベント。かってに緩いLT大会だと思いこんでゆるふわなフォントでスライド作って持っていったら、サイバーエージェントと社長とかも話すすごいちゃんとした会で、少々反省した。

battleconference-u30.connpass.com