引っ越し準備進捗

2018年2月4日

現時点での引っ越し進捗

• つくば市の不動産屋に何度か出向いて部屋を決めて契約した
• 今の部屋の退去の手続きをした
• 今の部屋の火災保険の解約手続きをした
• 引っ越し業者の手配をした
• 不用品を処分するための粗大ごみ回収の手続きをした
• 直前だと引っ越し用の段ボールの在庫がなくなるのが怖かったので段ボールを買った
• 電気と水道以外の各種インフラの引っ越し手続きをした（幸いなことに全部webで完結できている）
• 今使ってるジムの解約手続きをした（そういえばつくば行くと近所にジム無いなー）
• 研究室に手続きに必要な書類をいくつか書いて返送した

これからやる

• ベッドと照明器具を粗大ごみに出す
• アコギとサイレントギターを売る
• WiiUを売る
• いらない本を売ったりオフィスに置いて来たり人にあげたりして減らす

引っ越す度に物が減ってどんどん身軽になってきつつある。身軽になっていった方が何かと都合がよいと分かったのは３年前に半年の間に２回引っ越しをしたときだ。

身軽であることの良さは累積的に大きくなる。 一度ものが減ってスッキリした経験をすると、普段からいかにものを買わずに過ごそうかという気持ちになって、余計な出費は減るし、部屋は狭くならない。いらないものはすぐに捨てる。そうなるとますますスッキリする。ミニマリストを志向する人の気持ちが少しは分かるが、自分はスマホとmacbook proとHHKBとipodとkindleだけは何があっても手放せないので、真のミニマリストから見たら爆笑される程度のレベルにしか到達できないだろう。ミニマリスト道は厳しい。

自分の部屋は自分がPCをいじるための机と椅子が全ての中心で、そこで１日中過ごせるように設計されている。大学時代に一人暮らしをしていた時はこたつとか置いてたが、6畳程度の1kに住むようになってからはすっかりこのスタイルに慣れ親しんでいる。 本もなるべくkindleで買うようになってからあまりスペースを取らなくなった。服も靴も同じブランドのものしか身に着けなくなったが何も問題がない。

シンプルでよいのだ。多様性は自分のアウトプットだけにあればよい。

引っ越しに向けた準備を始めた

2018年1月3日

引っ越しはいつもgithubのissueでタスクを管理しているのだが、つくば市への引っ越しが近づいてきたので今回も立てた。

社会人になってからの引っ越しもかれこれ５回目ぐらいか。２～３年ぐらいで転職したり、転職せずとも地方でリモートワークしてみるとか色々と変なことをしていると引っ越しの回数が増える。面倒だが引っ越しはいろいろとリフレッシュできて良いものだ。

流石に慣れてきたもので、今回も引っ越す日から逆算して各タスクの手順とスケジュール感のメドがついている。しかし、今回は追加で国民年金加入手続きと関東ITSの任意継続もしなければならない。これは初めての経験だが、国民年金は市役所で手続きし、関東ITSの任意継続は書面をシュッと送ればシュッとやってくれるらしい。

近況

2017年12月29日

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

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

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

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ではどのように解消しているのか気になったので調べてみた。

3は頻繁に発生すると別のdatanodeへのアクセスが頻発してパフォーマンスが低下するので、厳密な精度が要求されないなら2みたいな感じで中途半端なとこで切られるinputは捨てる前提でjobを設計するのが現実的な気がする。

— Kazuhiro Serizawa (@seri_k) 2017年12月23日

https://t.co/swi2qKGVsM 4年前なのでhadoop1.x時代の話だと思うけど、MapReduceはHFDSのdata blockとは別に論理的な分割単位であるInput Splitsを定義し、data blockの末尾のレコードが1block内に収まって無ければ次のblockの情報をInput Splitsに保持するらしい。なので3のようだ。

— Kazuhiro Serizawa (@seri_k) 2017年12月24日

mapreduce packageにあるLineRecordReaderは https://t.co/M1On0AgaQm を使って実装されてるがまたFileSplitに対するreadlineのアプローチが違う模様。明日読んでみるか。

— Kazuhiro Serizawa (@seri_k) 2017年12月25日

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

stackoverflow.com

---

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

MapReduceむずい

2017年10月30日

MapReduce実装としてHadoopの論文を2個ぐらい読んでMapReduce少しぐらいは理解できたかなーと思ってたけど、よく考えるとあれってどうなってんだ？とか俺の理解だと矛盾してるっぽい？みたいな箇所がちょこちょこ出てくることが多く、なんだかんだで「Hadoop MapReduceのこと、分かってるつもりだったけどよく分かってなかった」という結論になってきた。

Hadoop MapReduceは一時期爆発的な人気があったらしく、ネットを漁ると大量のチュートリアルや解説記事が見つかる。しかし、よくよく読んでみると、ある記事はバージョン0.20ぐらいを前提として書いていたり、またある記事は1.xだったりと、情報リソースによって書いてあることが色々と違ってたりする *1 すでにHadoopブームが去った2017年に、ネットの情報だけで体系的にHadoop MapReduceのアーキテクチャについて理解し、最新の情報まで知識を繋げていくのは結構難しいということが分かってきた。こういう時に有料の論文掲載サイトで論文読み放題だとよいのだが。。

なので情報リソースは一旦この本に絞ることにした。

Expert Hadoop Administration: Managing, Tuning, and Securing Spark, YARN, and HDFS (Addison-Wesley Data & Analytics Series)

出版が2016年11月と比較的最近であることと、作者は本を書くためにHadoopを勉強した人とかではなく、実務でHadoop clusterを6年間運用してきた人物であることから、比較的正しい理解が得られそうな気がしたというのが選定理由である。

あとはHadoopの公式tutorialがある。かなり長いがこれ以外に今のところ信用できるhadoopの最新のdocumentはなさそう。

*1:のだが、日付が書いてないことが多くて意外と気づかない

空いた時間で何を勉強するか

2017年10月26日

相変わらず普通に会社員として過ごしている。特に変わったことはない。 シラバスを眺めて何の講義を取ろうかと考えたりしてみても入学はまだまだ先。

だが、そろそろ自分の研究以外の空いた時間に何を勉強するべきか整理しなくてはならない。 せっかくなので、自分が勉強したことがない分野や、普段はAWSやGCPやherokuに任せきりで全く気にしていないような所を勉強したいと思っている。

ざっくり書き出してみる。

• tcp/ip
• http2
• dns
• ssl/tls
• rpc
• n/wレイヤーのsecurity
• osの基本構造
• strage
• 最近のcpuのアーキテクチャについて（パタヘネの続きにあたる部分）
• gpu
  • そういえばCUDA触ったことない
• openmpi
• cpu自作

2018年01月14日追記

• どこで管理するか悩んだが、結局githubのprivate repositoryにまとめてみた
• githubのproject機能を使ってざっくりジャンル分けしてみたが、zenhubと比べるとかなり使いづらいというか機能が足りてないのでkanbanとして使うには結構ビミョーな感じ…
• とはいえzenhubにお金払って使うのもtoo much感あるので一旦これで頑張ってやってみる。がんばれGithub

合格通知書届いた

2017年9月14日

合格通知書が届いた。

9月12日に合格者宛に合格通知を発送する、と大学のサイトには書いてあったのだが、都内にも関わらず翌13日には届かなかったので、自分の目がバグって合格した幻を見ていたのかなと思っていたが、現実でも合格したようだった。

なんかすぐに書類書いて返送するのかなと思ったら、2月16日に入学手続きのための書類一式が送られてくるので、辞退しないのならそのまま何もせずに待っていればよろしいらしい。簡単だ。でも2月は引っ越しの準備とかでバタバタしそうだな。早めにやろう。

院試だと入学まで時間があるのでだいぶ余裕があってよい。学部の時は3月上旬に合格発表で、すぐ入学手続きの書類を書いて返送して、下宿先も探して、4月には入学、という超タイトなスケジュールだった。そう考えると3月、4月頃の入試課の事務対応は相当大変な仕事だろうなぁと思われる。

院試結果発表日

2017年9月12日

ついに来た院試の結果発表日。Jeff Deanに祈りながら恐る恐るwebで確認した。

見間違えでなければ受かったっぽい。

9月入ってから、落ちる夢（最多）とか、落ちた後にやさぐれる夢とか、筑波大学のオンライン出願システムを実装してる夢とか、よくわからない夢を毎日見て夜中に何度も目が覚めるようになってしまい、完全に寝不足になっていた。

結果発表までのこの2週間ぐらいの期間が人生で一番つらかったかもしれない。

大昔の大学（学部）受験の結果発表の時は、センター試験の点数を志望校別にgroup byしてorderした結果をオンラインで見られるサイトがあって、そこを見たらtop5に入ってたので二次は大丈夫だろう（しかも科目は得意な生物だけだったので）という確信があったので全く怖くなかった思い出がある。

しかし今回は全くの逆で、engineer系degreeもなく、業務での研究経験もなく、30過ぎのおっさんという、受かる要素が全く見当たらないおっさんの受験であったため、このブログにも散々書き散らしたけど本当に怖かった。

でも受かってしまえばもう過去のことなので気にはならない。

あとは入学までに今の職場を円満に辞めることと（この業界はとてつもなく狭いので）、英語力を鍛え続けることと、先行研究についての調査を進めておくことが今後の課題になる。

ともあれ、おっさんの無謀な挑戦も、ようやくスタートラインに立つことができた。とりあえず今は素直に喜んでいる。