Edited at

2018年のApache Hadoopを振り返る


概要

そろそろApache Hadoopは終わったのでは? という話がありそうなので、ここ最近の状況を書きます。結論を言うとまだまだ終わってないですが、クラウド事業者が提供するマネージドサービスが充実してきたことにより、直接 Hadoopクラスタ上でジョブを実行したり、Hadoopクラスタを運用したりする人々は特定の企業に集中していくのかなと考えています。


Apache Hadoopとは

Hadoopは、大きく分けてHDFS(Hadoop Distributed FileSystem), Hadoop MapReduce, Hadoop YARN(Yet Another Resource Negotiator)の3つのコンポーネントから構成されており、Hadoopについての発言を見たときには、それらのうち何について語られているか注意が必要です。主語がでかいのはよくないです。


Hadoop MapReduce

Hadoop MapReduceについてはさんざんオワコンと言われていますが、同意です。大人しくApache Spark、Apache Hive on Apache Tez、Prestoなどの、後発の分散処理エンジンを使いましょう。2014年に追加されたTask-level Native Optimization以来、Hadoop MapReduceに大きめの機能は追加されていません。そもそもHadoop MapReduceの開発者がApache Tezに流れたのでお察しな感じです。

最後に、Hadoop MapReduceは、HadoopにおいてMapReduceアルゴリズムを実装するためのフレームワークなので、単純にMapReduceとだけ言うと誤解を招く可能性があります。主語がでかい問題には注意しましょう。

また、Hadoop MapReduceはデータローカリティを活用することで、サーバ間のデータ転送をなるべく省略することで高速にデータを処理できる、という昔話がありましたが、それはスレーブサーバ間のNWが1Gの世界に限った話です。今では世界が変わってNWは10G以上が当たり前になったので、データローカリティは終わりです。


クラウドサービスとHadoop

オワコンの理由として、クラウド事業者が提供してくれるマネージドサービス(Google BigQuery, Amazon Redshift, Amazon Athenaなど)が引き合いに出されているような雰囲気がありますが、


  • クラウドを利用できない何かしらの理由がある

  • データ量が非常に多く、クラウドだと値段が高すぎる

といった事情があればオンプレで戦うしかなく、そういった領域は一定数存在するのでクラウドに全て取って代わられるということはなさそうです。TwitterがHadoopクラスタをGCP上に移行した、という話は衝撃的でしたが、これはきっと、ハードウェアの運用をやめてそれより上のレイヤにリソースを割きたかったものと想像しています。なお、上記のような事情にあてはまらない場合はクラウドサービスを使うのがよいと思います。

また、クラウドのインスタンス上にHadoopクラスタを構築する、あるいは、EMRを利用するというパターンは簡単のため除外していましたが、ざっくり以下のような感じだと思います。


  • ハードウェアの運用はしたくないし、サーバの台数およびスペックは気軽に変更したいが、クラスタ自体はずっと起動していてほしいし、HDFSも利用したい -> インスタンス上のHadoopクラスタ

  • 必要なときだけクラスタを起動させたい -> EMR


HDFS

Amazon S3が使える場合は、HDFSをなるべく利用せずにS3を使うほうが楽だと思います。S3GuardもしくはEMRFSを使っていれば、S3におけるデータの一貫性に関わる問題は解決します。ただし、Directory listingが遅いなど、性能特性の違いには注意が必要です。逆に、オンプレだとおそらく対抗馬はいません。小規模であれば分散ストレージを買ってきたほうが運用管理コストも含めて安くなるかもしれませんが、大規模になればなるほどHDFSのほうがコスパが良いと思います。


Hadoop YARN

現状、 Kubernetes vs Apache Mesos vs YARN みたいな感じで、今一番アツいところだと思います。YARNで出来ることは格段に増えていて、最近では以下の機能が追加されています。

そのため、KubernetesやMesosでできることの多くは、YARNでもできます(NW周りは厳しいと思いますが)。とはいえ、HDFSを利用していない、かつ、YARN上でしか利用できない分散処理を利用していない、という条件ではKubernetesやMesosを使った方が良さそうに思えます。私が言いたかったことは、既にHadoopクラスタを動かしている状況で、機械学習のワークロードのためだけに慌ててKubernetesクラスタを構築してみようとするのはちょっと待った方がいい、それYARNでもできるよ、ということです。


最近のHadoopは何を目指しているのか

主に、以下の2つだと考えています


  • 更なるスケールアウト

  • ML/DL連携

スケールアウトに関しては、YARN FederationHDFS Router-Based Federationが開発されたことで、数万台、あるいは数十万台規模にはスケールするようになりつつあります。複数のクラスタを束ねて見せているだけなので裏技的な感じがするのですが、サブクラスタ跨ぎのジョブを実行できたり、Globalにquotaをかけられたりなど、ただクラスタを並べるよりは便利に使えるようになっています。Yahoo! JAPANでもHDFS 1クラスタだけでのスケールアウトには限界を感じており、すでに通常のクラスタとYARN Log Aggregation専用のクラスタを分けて利用しています(参考資料)。今後、HDFS Router-Based Federationを利用したいと考えており、開発にも加わっています(例: HDFS-13743, HDFS-13750, HDFS-14011)。また、Ozoneについても、HDFSのスケールアウト限界を解決する取り組みの一種と見ることができます。

ML/DL連携については、YARNのセクションで説明した通りです。


開発企業の動向

ざっくりいうと、アジア(というか中国)の開発者が増えて時差問題がましになりました。自分がApache Hadoopの開発に加わった2013年には、日本の昼と夜にはJIRAからの通知メールがまったく流れず、朝起きたら未読メールが大量に溜まっていた、というのを記憶しています。現在では24時間ずっとメールが流れている感じになっていて、面白いです。詳しくは触れませんが、開発企業も多様化してきたと考えています。最近だとASFのJIRAから開発者のメールアドレスを拾えなくなったので、時々LinkedInで調べています。


最後に宣伝

Hadoop/Spark Conference Japan 2019 を 2019/3/14 に東京で開催します。

http://hadoop.apache.jp/hadoop-spark-conference-japan-2019-notice/

発表を考えている方々は、今のうちから準備しておいてください。よろしくお願いいたします。