[WIP] 夜明けBrand New Days 2019
はじめに
このエントリはWIPです、多分永遠にWIPです。書きあげる気も特にないです、でもはてなブログは90日以上放置すると余計な広告が出るし、お正月体調が悪くて引きこもっていたので、せっかくなので書いてみる。
2018年の振り返り
意外となんやかんやあった。
お仕事的な
会社変えた
要約すると以下の通り
- 弊オクが御オクに、御フリマが弊フリマになった
- 仕事はほとんど変わってない
- JavaとPythonで生きてたけどScalaとGoも書き始めた
- あいかわらず、怖いけど頼りになるおっさんたちに囲まれてコード書いてる*1
バフェット・コード作った
元投資銀行で死ぬほど勤労していた過去を持つ大学時代の友人と、しこしこバフェット・コードなる、企業分析ツールを作ってた。前の会社の友達とか、Twitterでつぶやいたときにレスくれた後輩も手伝ってくれてて助かる。
なんか、「データ分析には業務知識が一番大事」みたいなデータサイエンティストあるあるあるけど、業務知識みたいな汎用化しにくく、依存が強烈なやつを外部から注入できるようにシステム作るのがこういうデータ分析ツール作るコツな気がしてきている(偉そうに書いたが、すでに日本の会計業務ロジックの闇をそのままハードコードしたような作りになってしまっている)。
推し事的な
なんだかんだCY8ERな1年だった。あと、僕がアイドルを本格的に見始めた当時からいた大御所が立て続けに活動を終了した*2。
CY8ERと苺りなはむ
ももクロから数えたら10年くらい*3アイドル好きでいるけど、ついに定期的にチェキを撮る本格的なアイドルヲタクをはじめた。その相手が、苺りなはむ(元BiS ヨコヤマリナ)になるなんて、あの頃は思いもしなかったな…Yunomiさんの作る曲はどれも本当にかわいくて素敵なのだけど*4、個人的なイチオシはこれ www.youtube.com
// TODO なんかいい感じで話つないでまとめへ
まとめ
ということで、2019年は英語を頑張る年にしたいと思います。英語ができなくて浪人したのに結局全然伸びなくて志望校落ちてから干支も一周したことだし。 おつかれベイビーレイズ JAPAN!
愛と偏屈にまみれたHadoopの話(後編)
はじめに
ものすっごく久しぶりにblogを書こうと思い立ったのは、大好きだったでんぱ組.incの最上もがさんの退職エントリameblo.jp
をようやく受け入れられつつあることときっと無関係ではなくて、でもようやく新しくなったでんぱ組.incのwebサイト*1
からは喪失感しか感じないので、まだまだ立ち直るのには時間がかかるのかもしれない。
さて、そんなこんなで自分のブログみたら
で止まっていて、後編を書くのがBiSHで言うところのプロミスザスター*2なので今日はその後編を書く(下書きに7割くらい書けてたインド旅行記もあったけど、これ日の目見ることあるのかな・・・)。ちなみにこの内容は、半年ほど前に行われたBattle Conference U30というイベントで話したものです。
Hadoopは魔法ではない
ビッグデータ時代をリードするHadoopの世界第4位の開発企業であるNTTデータ様のHadoopの解説ページに記載されているHadoopの特長は
- 単純なサーバの追加によってスケーラビリティを実現
- 非定型データの格納を想定した処理の柔軟性を実現
- コモディティ品を利用した基盤構成・対障害性
で、いろんな資料でこの手の説明を見たり聞いたりすることがあるのだけど、まぁこれはHadoopというか膨大なサーバ群を売りさばくためのセールス文句なので真に受けてはいけない(Hadoopでディスクが沢山売れるようになったのに味をしめたのか、NTTデータに限らずゾウさんベンダー界隈はここ数年、今度は大量のメモリを売ろうとApache Sparkを推すのに夢中だ)。
- 単純にサーバを追加すると、ネットワーク/管理系のノードの処理負荷/予算 のいずれかでサチる
- 結局ためたデータはなんだかんだSQLで使いたくなる(特に分析用途)
- 非定型な大量データだと処理効率が上がらない
- 結果的にニーズに見合う高性能なサーバを並べたほうがトータルで安い
という、考えてみれば至極当然な結果に帰着し、世界中のゾウさん界隈のエンジニアは(能動的な)Hadoopの内部最適化に追われている。Hadoopは音楽と同様に魔法ではない*3のである。
Hadoopの現状と列指向ファイル
前編で考察したように、Hadoopはそもそも意図的にネットワークを含めたI/Oに負荷を寄せたアーキテクチャだ。これを読んでくださっているあなたのHadoopのJobが一向に終わらないのも「CPUが何か頑張る以前の、単なるファイルの読み書き」が原因である可能性が高い。ちなみにこれはHadoopに限った話ではなく、HDDへの読み書きというのはそれだけコストがかかる行為なのだ*4。
ところで、複数人が複数目的に複数回Readすることになる関係上、利用価値の高いデータはWriteよりReadのコストのほうが圧倒的に問題になる(それに対してWriteはどんなデータでも1度だ)。だからHiveやPrestoといった分析目的のSQLでのデータ利用が前提になっている昨今のHadoop界隈では、SequenceFileではなくORCやParquetに代表される列指向のファイルを使うのが常識になっている。
例えば
SELECT col2 FROM foo_table WHERE col2 = “bar”;
というクエリによるファイルアクセスを例に取ると列指向ファイルが圧倒的にREAD時に発生するI/Oを抑えることができることがご理解いただけると思う。
しかし、この列指向のファイルにも
- streamなデータ(無限に発生し続けるデータ)と相性が悪い
- ネストが深い構造のデータだと、効果が薄い
という欠点があり、そしてこれは
- いわゆるビッグデータ(ユーザの行動やサーバのアクセスログ、IoTのセンサデータ等)は典型的なStreamなデータ
- 昨今のHadoopで扱うデータのinputはApache Kafkaに代表されるメッセージ形式
- 業務ロジックを表現できる、ビジネス上活用しやすいデータは多くの場合複雑なネスト構造を持つ
という点で結構致命的だ。今回は特にstreamな入力と列指向データの相性の悪さについて注目してみたいと思う。
Streamな入力とbatch処理
そもそも、streamな入力とHadoopが得意なbatch処理(始まりと終わりのある処理)は相性が悪い。streamな入力はstreamに処理したほうが設計も実装もはるかにシンプルになる。
その一方で、SequenceFileと違い列指向のファイルへの書き込みは純粋な意味でのStreamProcessingで実装し得ない。「列毎に(圧縮しながら)書くためには、複数行をバッファリングして一度に書く」しかないからだ。
そこで、Streamな入力に対して俗に言うMicroBatchというやつが登場してくるわけだが(例えばSpark Streamingがそうだ)、これは「始まりと終りがある」という点では完全にbatchなので、開始・終了処理とかエラー処理で余計な気を回す必要が出てくるうえに、普通のStream Processingと比べlatencyで劣る事が多い。
逆に言えばBatchな入力、例えばすでにHiveのtableとして提供されているデータを加工して分析・集計用のデータマートを作るような場合には、この手の問題を気にせずに列指向フォーマットの恩恵を存分に受けることができるので、その際には積極的に列指向の出力を用いていくべきだと思う。
最後に、愛と偏屈について
結局のところ「こうやればHadoopはもっと便利になる!」みたい特効薬はまだなくて、僕のお仕事も3歩進んで2歩下がる感じがずっと続いていて、だから黄色のゾウさんの一挙一投足に優しくなったりかなしくなったりしちゃう*5んだと思ったりして、そういう意味できいろいゾウさんは最上もがさんに似ている。
ということで今日はこの曲でお別れです、もう2度とライブで聞くことはないであろうでんぱ組.inc『W.W.D 2』。
注釈等
*1:ちなみに長らくこれだった。まじでクソだと思う、21世紀に入ってもう17年も経つのに。
*2:メジャーデビュー以降で一番好きな曲かもしれない。オーケストラの風味も残しながらの、BiSHらしい名曲。このライブ、Zeppで見てたけど最高だったな・・・
*3:正直、最近彼女の歌は僕を卒業しつつある(つまり、より多くの抽象化された観衆に向けて歌っている気がする)が、同時にこれから始まる弾き語りツアーが楽しみで仕方なくはある(中野サンプラザのチケット取った)。
*4:@kumagiさんの資料の5ページ目を見るとがわかりやすいと思うが、HDDからのデータの読み出しは大西洋を往復する通信コストと1桁しか変わらない
愛と偏屈にまみれたHadoopの話(前編)
はじめに:危険なのでマサカリは投げないください
昨年末、久しぶりに技術的なテーマについてのエントリ
を書いて、個人的には結構自信作だったんだけど案の定そんなにPV*1は伸びなくて、ちょっと拗ねた。でも、まぁ別に多くの人に読んでもらうことを目的に文章を書いてるわけじゃないし(もちろんPVは多ければ多いほど嬉しい)、今回も懲りずに技術的なエントリでも書いてみようと思う。ただし、マサカリを投げる*2のは危険なのでやめてほしい。この文章は僕が僕の理解の中で時分の思考を整理するために書いているのであって、僕が知らないこと・間違ってることもいっぱいあるのは自覚しているので、こちらまでご連絡くだされば謹んで訂正いたします。
1. Hadoopって?
最近*3地上波でも良く耳にするようになったDeep Learningに代表される機械学習には、途方もないほど膨大なデータと、それを扱うためのストレージ、そして計算環境が必要だ。
"Hadoop"はそんな場面で使える、気持ちの悪い黄色いゾウさんが目印の「膨大なデータを扱えるファイルシステム兼計算フレームワーク」で、その実装はインターネットに全公開されている*4。ちなみにその全貌を理解しなくてもとりあえずは使えるし、このエントリを読むのに何の支障もない。ただ、こんな章を作ってなんだが、以降の話は"Hadoop"を知らない人には完全にちんぷんかんぷんな内容になってしまっていると思うので、そのことについては先に謝っておきたい。
2. HDFS(GFS)と広義のMapReduce
「Hadoop、つまりHDFS(GFS)とMapReduceとは?」という議論は、ぶっちゃけGoogle様の10年以上前の以下の論文
が全てで、それ以上でも以下でもないのだろうけど、それぞれの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 TezやApache SparkのDAGも含む概念とする。
3. Hadoopの解いた課題とアプローチ
さて、「なぜHadoopが必要なのか?」という問いに対してよくなされる返答は
テラバイト(1兆バイト以上)からペタバイト(1,000兆バイト)におよぶデータを高速・効率的に処理するために、新たな手法が必要となりました。(中略)そこで考えられたのがデータを分散並列処理する手法です。つまり、データを複数のサーバに分散させ、各サーバに計算処理させることで、1台のコンピュータでは難しい大容量データの高速分析処理を行おうというものです。 (ストレージ Hadoopとは - Fujitsu Japan)
というものだが、この「そこで考えられた」というのが、「何を、どう考えたのか」というのを僕は恥ずかしながら最近まで全く理解できないでいた。ここではそれについ僕の理解を書いておく。
まず、上記論文が発表された2003年当時、Google様が見ていた課題やそのアプローチは「データ量が増えすぎて既存のストレージだと、もうどうにもならない」というような、(一般的な企業でのHadoop導入事例でよく見られる)対処療法的なものではないと僕は思っていて、おそらく以下の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にそまっていて、心の底からのプロミスはできないのだけれど。
後編書きました
半年かかったけど後編も書きました。
注釈等
*1:Page Viewsのこと。細かいことを言わなければ、つまり“何回に読まれたか”
*2:「技術的に鋭いツッコミをすること」と説明されることが多いが、無駄なマウンティングが含まれない限り、そうは呼ばれない気がしている。投げられたマサカリは大抵無益な2次災害を引き起こすので、周りの安全が確認できない場合(当然オンラインの場合は全てそうだ)は自重したほうが世界のためだとは思う。
*3:それほど最近でもない気がするが、僕みたいな機械系卒のWeb系という畑違いも良いとこのエンジニアがDeep Learningの“破壊的イノベーション”っぷりを知ったのがILSVRC2012なので、かれこれ5年くらいか・・・
*4:いわゆるOSSというやつで、気になる人はGitHubを御覧いただきたい
*5:この「実装」という言葉に馴染みが無くて、かつ興味がある稀有な方は是非以下のエントリを読んでいただければと思う。
*6:一応、事前に友人のカイ君
にレビューをお願いしたが、文責は全て僕にある
*7:"Battle Conference U30"なる、若手エンジニア向けのイベント。かってに緩いLT大会だと思いこんでゆるふわなフォントでスライド作って持っていったら、サイバーエージェントと社長とかも話すすごいちゃんとした会で、少々反省した。