Hadoop の時代は終わってないけど、使いどころは限定されてきたかもしれない

id:shiumachi さんが書かれてる下記の記事がとても良かったです。 shiumachi.hatenablog.com

私自身もSparkを触る前は「Hadoop == MapReduce」と思ってましたが、どちらかというとYARNやHDFSHadoopファミリの核だと最近は思いますし その意味でのHadoopは全然終わってないと思います。記事の中で書かれてる通り、ある意味ではさらなる進化を遂げて花開いてる状態かな、と。

ただ、Twitterにも少し書いたんですが一方で「猫も杓子もHadoop!」の時代が終わりつつあるのも事実かな、と思います。

もうちょっというとHadoopに限らず巨大スケールの分散システムの用途が収斂してきたのかな、と。

HadoopGoogle MapReduce登場時のと違い、ストレージI/Oは133MB/sとかの単位で争ってたHDDからストレージに代わって、今や3GB/sを超えます。しかもランダムアクセスもHDDよりずっと速くなっている。

ちょうど最近発表されたZenベースのサーバだと64コア/128スレッドで、メモリも4TBです。普通に当時の10倍以上のマシンスペックがある訳です。単純に。

pc.watch.impress.co.jp

また、そういったハードウェアスペックに合わせてインメモリDBやクラスストレージメモリ、あるいはGPUを活用する形にRDBなどのミドルウェアも進化しています。

それこそ2010年からしばらくは「デカいデータ処理(あえてビックデータとは呼ばない)は分散システムでやるべし、すなわちHadoop!」って感じだったと思っています。

これは本来Hadoopがターゲットにしているビックデータ(TB級やPB級)ではなく数百GB級でも普通に組んだら性能足らなくて仕方なく使ってたケースがあるかと。

そういった用途で使われていたHadoopファミリは徐々に利用されない形になっていくんじゃないかと。

例えば、3GB/sのI/O性能が出るなら、1TBのデータ読み込みですら5分と少しです。

数TBのサイズであればインメモリDBにデータがすべて乗ります。

数十から百程度の並列処理なら分散しなくても単体マシンで処理可能です。

こうなってくると機械学習や特大のDWH以外はTB,PBクラスの処理をすることは少ないと思います。特に歴史がある会社だと昔から運用してるので業務的に圧縮してるはずだから、通常業務のデータはそんなにでかくないはずなんですね。日次とか月次でサマったり。じゃないと元々運用できないですし。

なので、そういった業務に対して単純に利用者が増えるとかの線形なデータ増加に対する対応だとHadoopのような巨大な分散システムを運用する必要性は小さくなってきます。

もちろん、冗長性やローリングアップデートのためにもシステムが多重化されてる事は大事なんですが、数百台のクラスタで動かすことを想定した分散システムではなく、 それなりに信頼できる数台のマシンで構成した小さなクラスタを運用する方向性が強まってくるんじゃないかな、と。

ただ、強まってくるんじゃないかと思いつつもRDBに分投げる方はともかく、分散処理エンジンであるSparkに代替するような並列処理エンジン/管理システムがあんまり無いのも困りもの。

自分が知る限りだとそのコンセプトを強く打ち出してるのはAsakusa-on-M3BPくらいですね。

RDBをインメモリで運用できてそっちに処理をオフロード出来るケースなら、あまり問題ないのですがそうじゃない場合は「複数スレッドをマネージするバッチの処理基盤」自体はやはり必要です。

何も考えずに各々のアプリが好きなサイズのスレッドを取得して使うと、ジョブスケジューリングが適切にできなくなってしまいます。

なので、Asakusaのような思想でのミドルがもう少し増えて、運用ノウハウが溜まっていけばな、と思ってます。

あるいはMesosやk8sでリソースを別途管理する基盤を作るかですね。JavaEEのjBatchもそういう方向で活用が出来そうだけど、ぶっちゃけ登場が遅すぎて機能とエコシステムが弱いのがネックですねぇ。

この辺は決定版が無さそうだから管理ツールとか含めて自作する必要があるかも。

まとめ

なんか途中から大分脱線した気がしなくもないけど、Hadoopの時代は終わってなものの「本当はHadoop使うには微妙だけど他に選択しないからHadoop」って用途がHWやMWの進化で、 適切なシステムに移行していくので、結果としてHaoopのような大規模分散クラスタは特定の用途に寄るだろうなってのが言いたい事でした。

それではHappy Hacking!

参考: