Hadoopの時代は終わった、という言説をたまに見かけるようになりました。
もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。
本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。
DISCLAIMER
私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。
中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。
以上をご了承の上、読み進めてください。
要約
データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。
Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが一体となっていたため、データ基盤向けのソフトウェアとしての地位を確立していきました。
しかし、2010年代に入ると、ハードウェア、処理エンジン、ストレージの進化により、Hadoopは大規模なデータ基盤として唯一の選択肢ではなくなっていきます。
特に処理エンジンは、MapReduce以外にも優れた処理エンジンが登場してきたため、現在MapReduceはその役割を終えようとし始めています。
一方HDFSは、以前としてオンプレ環境におけるOSSの大規模分散ストレージとして高い地位を占めています。
Hadoopがカバーする範囲も拡大し、新しい処理エンジンやクラウドストレージに対応し、順調に進化を続けています。
よって、Hadoopの時代が終わった、という言葉は正確ではなく、MapReduceの時代が終わった、というのが正しい理解です。
用語の定義
本記事での用語を定義しておきます。
ストレージとは、データを格納する基盤のことを指します。本来はメタデータ(DBスキーマなど)のストアと区別しなければいけないのですが、簡略化のためにストレージとしています。
暗黙的に、その時代における大量のデータを保存することを想定しています。
処理エンジンとは、ストレージからデータを取り出して何らかの処理を行うためのシステムです。ここでは、簡略化のために、SQLなどの、処理エンジンにアクセスするためのインタフェースも処理エンジンの一部として含めて紹介します。
こちらも暗黙的に、その時代における大量のデータを処理することを想定しています。
データ基盤とは、ストレージに格納されたデータを、処理エンジンを利用して、ビジネスにおけるデータ活用を行う基盤のことを指します。バッチ処理、DWH、機械学習など、データを取り扱うものを全て含みます。
なぜ本記事においてビッグデータ基盤と言わないかというと、既に大量のデータを扱うことが当たり前になってきた今日において、ビッグデータブームが始まる前と後で区別することにそれほど意味がないからです。
アプリケーションとは、データ基盤を利用することで新しい価値を提供するソフトウェアを指します。例えば、BIツールやETLツールなどです。ここでは内製ではなく商用ソフトウェアを中心とします。
データ基盤の歴史(1): Hadoopの登場から発展まで(2000年代～2010年代前半)
Hadoop以前(～2006年)
2000年代に入るまで、データ基盤は非常に高価なシステムでした。そのために、本当に重要な一部のデータだけを活用することが常識でした。
データ基盤は、主にメインフレーム、商用RDBMS、商用データウェアハウスなどで構成されていました。
これらは全て、処理エンジンとストレージが垂直統合されていました。
非分散型・スケールアップ型が当たり前の時代だったので、垂直統合しておいた方が効率的だったのです。
しかし、Googleは自社の検索ビジネスにおいて、Webサイトのデータという大量の非構造データを、より安価に処理するための基盤を必要としていました。
そこで開発されたのがMapReduceというアルゴリズムとGFSというストレージシステムでした。
この2つの技術に関する論文をGoogleが発表したのは2003から2004年ですが、これを読んだDoug Cuttingがオープンソースで同様のシステムを実装します。
これが、後のHadoop MapReduce (以下MapReduce)と Hadoop Distributed Filesystem (HDFS) となります。 *1
NoSQLの台頭とHadoop一択の時代(2008～2012年)
Hadoop登場と同時に、NoSQLブームが発生しました。NoSQLをどう定義するかは人によって違いますが、一言でいうと「RDBMSが持っていた機能を限定することで、性能のスケーラビリティを重視したストレージ」です。
処理エンジンを内包したストレージも一部ありましたが、価値の根本部分は「スケーラブルなストレージ」という点になります。
多くの人が、そのNoSQLという文字内容から「これからの時代はRDBMSでもSQLでもないんだ」と勘違いしてしまいましたが、NoSQLはあくまでストレージの進化であり、処理エンジンの進化ではありません。
この時代に成功したNoSQLも数多くありますが、同時期におけるデータ基盤向けストレージの勝者は間違いなくHDFSです。
なぜなら、この時代にほぼ唯一の処理エンジンの選択肢だったMapReduceが、HDFSに密結合していた(ように見えていた)からです。
Hadoopは、MapReduce (処理エンジン) + ストレージ(HDFS) が密結合しているように見えてしまっていたため、ほとんどの人がこれらが一体となっていると思い込んでしまいました。
このことは、この時期においては有効に働きましたが、これこそが今回のテーマである「Hadoopは終わった」論の遠因となっていったと私は見ています。
ともかく、Hadoopは、こうした背景から、大規模なデータ基盤としてのこの時代唯一の選択肢として発展していったのです。
データ基盤の歴史(2): Hadoop一択の時代を超える(2010年代)
2010年代に入ると、当たり前のように大量のデータを扱う時代が到来し、様々なユースケースにおいて大量データの処理が求められるようになってきました。
元々用途を限定して作られたシステムだった当時のHadoopに対し、新しいユースケースに対応した処理エンジンやストレージが登場し始めます。
そして、古き良きHadoop、すなわちMapReduce + HDFSは唯一の選択肢ではなくなっていきます。
この変化には、複数の領域における発展・変化が関係していきます。
ハードウェアの進化
Hadoopが登場した背景には、ハードウェアの進化の限界がありました。
2000年代においてはまだメモリが高価で、CPUもディスクも性能が鈍化していて、データ基盤を構成するにあたって単一のサーバでのスケールアップでは限界があったために、GoogleのMapReduceアルゴリズムとGFSは分散アーキテクチャを採用しました。
しかし、2010年代に入ると、CPUの性能はあまり変わらないものの、メモリが以前よりもはるかに大容量・安価になり、こうしたアーキテクチャの変化を前提にしてインフラ全体が変わっていきました。
処理エンジンの進化
MapReduceが出た当時は、他の技術と比較すると確かにシンプルで理解しやすく、書きやすいと思われていましたが、2010年代に入ると逆に複雑なフレームワークとみなされるようになってきました。
また、MapReduceはバッチ処理に限定したフレームワークである上に、処理手法が効率よく働くケースが限定的でした。
こうした課題を解決するため、Apache Sparkが登場しました。効率のよいメモリ活用による高速化と、格段に書きやすくなった記述形式、そしてバッチ処理だけでなく、ストリーム処理や機械学習などもカバーする幅広い用途により、2012年の登場してから急速に注目が集まり、2014年の1.0リリースから一気に広まっていきました。この普及の背景には、先述のハードウェアの進化によるメモリの大容量・低価格化も大きな一因となっています。
データ基盤におけるデファクトスタンダードのインタフェースであるSQLにも大きな変化が起こりました。
MapReduceを使ったSQLエンジンとしては既に2008年にHiveが登場していました。
しかし、大量の非構造データを処理する性質を備えつつも、既存のRDBMSやDWHのような低レイテンシを満たせるような新しいSQLエンジンが求められるようになっていきました。
そして、2012年にApache Impala(当初の名称はCloudera Impalaだが、2016年にASFに寄贈)が登場したのを皮切りに、様々な新世代のSQLエンジンが登場しました。
2012年には、Google BigQueryのような、クラウド上にしか存在しない処理エンジンも登場してきました。ストレージの選択肢が事実上Googleだけになってしまうという欠点があるものの、クエリ毎の課金という革新的な価格体系と高速性から、GCPを代表するサービスとして広く普及していきました。
このように、2010年代中頃になってくると、MapReduce以外の処理エンジンが増えていき、MapReduceはあくまで処理エンジンの選択肢の一つとなっていきました。
ストレージの進化
2010年代前半に、処理エンジンの選択肢が多様化しても、ストレージとしてはまだまだHDFS一強の時代でした。大量のデータを処理する基盤に適した、安価でスケーラブルなストレージシステムがHDFSしかなかったのです。
Amazon S3 をはじめとしたクラウドストレージを使うと、ストレージシステムの運用から解放され、初期投資が極めて安価でしかも簡単にスケール可能という多くの利点がありますが、2010年代前後はまだ値段も高く、信頼性・実績ともに乏しかったため、メインのストレージにしようという企業はわずかでした。
しかし、クラウドストレージが進化を続け、信頼性の向上と価格の低下が進むと、インターネット系企業を中心にストレージの中核をクラウド上に持つ企業が数多く登場していきました。こうした企業は、もはやHDFSを自前で持つこともなく、クラウドストレージを中心としてデータ基盤を構築していきました。
ストレージのトレンドの変化を受けて、処理エンジンの側にも変化が発生します。
HDFSを持たずにデータ処理を行いたいというニーズに応えるために、処理エンジンもクラウド対応への変化が進んでいきました。
Amazon EMR は S3上のデータを直接 MapReduce で処理することができる、Hadoop をフォークして開発されたサービスですが、後に Apache本家でも別個にAmazon S3への対応が進み、高速にデータを処理できるようになっていきました。
また、Sparkや、Impala / PrestoなどのSQLエンジンもクラウドストレージへの対応が当然のように行われるようになり、オープンソースの処理エンジンはHDFSだけではなくクラウドストレージへ対応することが求められるようになってきました。
RDBMS・DWHの進化
RDBMSやDWHも着々と進化を続け、データ基盤のニーズに応えるよう変化しています。例えば、商用DWHでは既にjsonサポートが当たり前になっており、非構造データへの対応が進んでいます。OSSのRDBMSにおいても、PostgreSQLは2012年(9.2)からjsonをサポートし、続くバージョンでjson対応を強化していっています。また、扱えるデータ量も増えていっており、商用DWHでは1PB以上のデータのサポートは当たり前となっています。
DWHそのものもクラウド化が進みます。Amazon Redshiftはクラウド上で安価に利用できるサービスであり、従来のDWHを購入するだけの予算がなかったような企業でも簡単にデータ基盤を持つことができるようになりました。
現代におけるデータ基盤
現代においては、データ基盤で利用する処理エンジンとストレージの組み合わせは実に多様化しています。
処理エンジンに重きを置く人はまずSparkやBigQueryを前提にストレージエンジンを探すでしょうし、ストレージに重きを置く人はまずHDFSやS3というストレージ選定から始めて処理エンジンを探すでしょう。
あるいは、使っているアプリケーションが対応している処理エンジン・ストレージを選択していくという過程を選ぶ人もいるかもしれませんし、オンプレミスかクラウドか、あるいは両方を使うべきかという、インフラを中心に選択する人もいるでしょう。
そして、これらのうちどれか一つを選ぶのではなく、複数を組み合わせるというのも当たり前になりました。
ストレージとしてオンプレミスのHDFSとクラウドのS3を同時に持つシステムは多数存在しますし、既存の MapReduce ジョブを走らせ続けながら新規開発にはSparkを使い、BIツールからの接続にImpalaを使うという企業はますます増えています。
データ基盤を選ぶのではなく、データ基盤を構成する処理エンジンとストレージの組み合わせを選ぶ時代なのです。
Hadoopの時代は本当に終わったのか？
Hadoopは、MapReduceという処理エンジンとHDFSというストレージの二つを組み合わせたものであることは説明しました。
これらのコンポーネントは、それぞれ異なる変遷を辿っていきます。
処理エンジンは、バッチ処理だけに特化していたMapReduceから、ストリーム処理、低レイテンシなSQL、機械学習など、様々な用途に対応するための処理エンジンが登場してきました。
バッチ処理についても、より高速で書きやすいフレームワークであるSparkの登場により、MapReduceは既存のプログラムへの後方互換という用途以外の役目を終え始めています。
しかし、Sparkを始めとした新しい処理エンジンは、様々なデータ基盤で採用されています。
そして、Hadoopという名称が指す領域は、MapReduceだけでなくだけでなくSparkやSQLエンジン、さらにはSolrなどの検索エンジンに拡大していっています。
HDFSは、クラウドストレージを選択する組織が増えてきたものの、データ基盤のストレージとして依然大きな存在感を持っています。
HDFSほどスケーラブルで、かつ実績のあるオープンソースのストレージシステムは他にありません。
自社に十分なインフラ資源(人・モノ・金全て含む)が整っている場合、クラウドストレージを使うよりも圧倒的に安価になるため、HDFSは有力な選択肢となります。
また、オンプレミスからクラウドに移行する際にも、クラウド上でそのままHDFSを動かしてしまえば、既存のコード資産をほぼ変更せずに移行できるため、処理エンジン同様ポータビリティが高いという特性があります。
こうした利点を考えると、HDFSはまだまだ活用され、発展していくと言えます。
このように見ていくと、MapReduceは確かに新しい処理エンジンにバトンを渡して静かにフェードアウトし始めていますが、新たな処理エンジンとHDFSを携えて、Hadoopそのものは進化を続けていっていることがわかります。
Hadoopの時代は終わってなどいないのです。
では、なぜHadoopは終わったと言われてしまうのでしょう？
私の見解では、HadoopはMapReduce + HDFSがセットになっているというイメージが強すぎて、そこからの転換が進んでいないことが原因と見ています。
多くの人が未だにHadoopはバッチ処理のためだけの基盤だという誤解をしています。
2014年前後に、Google BigQueryやAmazon Redshiftのような、安価なデータ分析のための基盤の普及が進みましたが、そのユーザの多くはHadoopが既にそうしたデータ分析が可能になっていることを知らず、古き良きHadoopとBigQuery/Redshiftの間に大きな知識の断裂があるように感じます。
2010年前後に有利に働いたイメージが、逆に今は足かせになっている、というのが私の意見です。
まとめ
Hadoopの時代は終わった、という言説を見かけますが、MapReduceの時代が終わった、というのが正しい理解です。
Hadoopは、従来のRDBMSやDWHに比べ、大容量かつ非構造データを処理可能でしかも安価な基盤として2000年代後半から2010年代前半にかけて普及しました。
しかし、2010年代中頃には、Sparkを始めとした新しい処理エンジン、クラウドの台頭、ハードウェアの進化、そしてRDBMSやDWHの性能向上に伴い、初期のHadoopのアーキテクチャの必要性が失われていきました。
現在のHadoopは新しい処理エンジンやクラウドへの対応が進んでいるものの、初期のHadoopのイメージが残り続け、Hadoopの時代が終わったという言説につながっていっている、というのが「Hadoopの時代は終わった」という主張の原因と私は推測します。
