seri::diary::graduate_school

大学院修士課程での研究生活について書いています

近況

2017年12月29日

継続して Expert Hadoop Administration: Managing, Tuning, and Securing Spark, YARN, and HDFS を読み続けてるのだが、如何せんページサイズが多いのでなかなか進んでいない。
しかも1/4ぐらい読んで気づいたのだが、序盤はHadoopの基礎的な説明に終始していて、完全に飛ばしていい部分だった。それを頑張って1か月ぐらいかけて読んでいたのだが、結局全部知ってることだった。自分が知りたいのはHDFSの内部アーキテクチャMapReduceの処理の詳細(できればHadoop2.x以降のYARN版)だったが、それらは後半以降にならないと出てこない内容だった。

英語の文書の場合、どうしても読むスピードが遅い関係で、自分にとって必要かどうかを判断するのが日本語の書籍と比べて相当遅くなるということを実感した。逆に、だからこそ目次を見て各章の最初だけをちょろっと読んで必要かどうかを判断していく読み方の方がいいのかもしれない。英語の勉強も兼ねて頭から読んでいたつもりだったが時間効率は非常によくなかった。しかもこの本は平易な語彙や表現だけを使うように意識してくれているのか、語彙力のない自分でもスラスラ読めてしまうので、勉強という面でもあまり向いてなかったかもしれない。

また、MapReduceの理解のために自分でRubyMapReduceフレームワークを実装してみた。まだ完全ではないが、Map taskとReduce taskのソースコードの文字列をhttpでPOSTしてjobを登録し、map taskを1node, reduce taskを2nodeで実行して、結果をS3(またはS3互換ストレージ)に格納できるようになった。1

qiita.com

分散ファイルシステムのdata localityを無視すれば作るのは割と簡単だと思っていたが、node管理がなかなかに面倒だったり状態遷移が必要なことをすっかり忘れてたりして思ったより時間がかかった。(実作業時間で多分50時間ぐらい。当初は30時間ぐらいだと思ってた。)しかし1回作ってみることで分散システムにおける必要な要素を身をもって勉強できたので良かったと思う。

また、map taskを分散させるためには結局jobのinputとなる分散ファイルシステム上のファイルを分割して読み込む仕組みが必要だと気付いた。当たり前なのだが、これってHadoopではどうやってやってるんだろと疑問に思った。 例えば、HDFS中の1blockが128MBだとして、そこに1GBの単一ファイルを格納するとなると1000MB / 128MB = 7.8125 であり、8blockに分割されて格納される。しかし、MapReduceにおけるinputの1recordはdelimiter区切りであるため、blockの境界部分で1recordが2つのblockに分断されてしまうことになる。こうなると、境界部分のrecordは2つのblockをreadする必要があり、場合によっては別のdata nodeに格納されているdata blockをreadしにいかなくてはならなくなる。逆に、この処置をしない場合は境界部分の不完全なrecordは無視せざるを得ない。これをHadoop MapReduceではどのように解消しているのか気になったので調べてみた。

なお、HadoopMapReduceのClientに関するソースのpackageは2種類存在する。mapredmapreduceである。 詳細は下記のStackoverFlowの回答が詳しいが、mapredの方が古いpackageであり、commit logを見てみも現在積極的に機能追加されてるのもmapreduceのようだ。

stackoverflow.com


  1. 開発中はS3の代わりにminioを使っている