Hadoopの使い方のまとめ(2016年5月版)

　Apache Hadoop (以下Hadoop) が登場して10年が経ち、その間にHadoopとそのエコシステムも誰も予想できないほど大きく進化してきた。当初バッチ処理専用と言われていたHadoopも、今やSQLエンジンや機械学習など様々なアプリケーションを動作させることができる汎用基盤となっている。しかし、「Hadoopとは何か？」「Hadoop入門」のような初心者向け記事は未だに初期の頃のHadoopを想定した説明しかしておらず、現在のHadoopについて正しい情報を伝えていないように見える。一方、「最新のHadoop」といった類の記事は新機能や性能向上ばかりに着目し、それらの進化がどのような意味をもたらしているかについて説明をしていないように感じる。この記事では、10年に渡る進化を遂げたHadoopが現在どのような使われ方をしているのかについて簡単にまとめる。

　「Linuxはこう使うべきだ」などという説明がナンセンスであることと同様、Hadoopについても「こう使うべき」などと説明することはあまり適切ではない。あくまで私の観点で、現在どのような形でHadoopが使われているのかについてまとめたものであることに留意していただきたい。

　この記事は2016年5月現在の情報を元にして記載したものであり、日々進化していくHadoopエコシステムの世界において、一年後もこの記事が陳腐化しない保証はどこにもない。トレンドを調査する場合は常に最新の情報にあたること。

バッチ処理

　Hadoopといえばバッチ処理、というのはここ10年で最も頻繁に行われた説明であるだろう。この説明は適切ではないが、現在においてもバッチ処理が主要な使い方の一つということに間違いはない。

バッチ処理の目的は主に3つある。

• ETL
• ビジネスレポート
• 機械学習のモデリング

　ETLは、いわゆる「データの前処理」とか「クレンジング」とか言われる類の処理で、もともとはデータウェアハウス(以下DWH)の世界から持ち込まれた概念である。ビジネスレポートは、たとえば「月次レポート」「日次レポート」のような、大規模なデータの集計処理のようなものが該当する。機械学習のモデリングは、パーソナライズされたリコメンドを作成するときなど、やはり大規模なデータをまとめて処理することを前提とした機械学習のアルゴリズムを適用することを指す。

クラウド上の一時クラスタとバッチ処理

　バッチ処理に限って言う場合、クラウド上で一時的にクラスタを立ち上げて分散処理するという手法はコストパフォーマンスの観点から非常に優れている。実際、クラウド上でのHadoopサービスを利用しているユーザはこの用途しか思い浮かばないという人も多いだろう。こうした用途は年々増加傾向にありつつも、Hadoop全体として見た場合まだ現時点では主流とは言えないように思う。しかし、向こう1、2年で一番大きく変化するポイントではないかと思われる。クラウドとHadoopについての詳細は本記事では説明しないが、そのうち別途記事にするかもしれない。

大規模データ向け分析基盤

　2012年に Apache Impala (incubating) (以下Impala)¹ がリリースされたことをきっかけに、アドホッククエリ向けの SQL-on-Hadoop の開発が活発化した。これにより、既存のDWHの一部の処理をHadoop側にオフロードしていくという流れが本格化した。このオフロードの流れの詳細については本記事では説明しない。

　先のバッチ処理とアドホッククエリ向けSQL-on-Hadoopの組み合わせにより、ETL + DWH (+分析用RDBMS) という高価な基盤の一部をHadoopで代替できるようになってきた。2016年現在は、この使い方が主流と言って間違いない。

　注意しなければいけないのは、全てのDWHを置き換えることは少なくとも当分の間は難しいということだ。なぜなら、現在の技術ではHadoop上では完全なトランザクション処理は実現できないからだ。

業務システムのバックエンド(NoSQL、検索エンジン、ストリーム処理)

　Apache HBase (以下HBase)、Apache Solr (以下Solr)、Apach Spark (以下Spark) のサブプロジェクトである Spark StreamingはHadoopエコシステムの中でも特異な存在である。Hadoopエコシステムの本流は間違いなく分析基盤であり、業務システムと同等のSLAは通常求められないのであるが、こうしたソフトウェアを活用する場合は業務システムの一部として稼働するため、要求されるSLAが非常に厳しくなる。想定要件が分析基盤とは全く異なるので注意しなければならない。

データサイエンティスト用基盤

　Sparkの登場により、データサイエンティストがHadoop上の大規模データに対する高速処理を気軽に記述することができるようになった。また、Pythonによるデータ処理のためのツールも充実してきており、大量のデータを使って研究、調査、開発などを行いたい人達にとっての基盤の利便性が向上してきている。

　「データサイエンティスト」という言葉だけ聞くと、人工知能やディープラーニングといった言葉を思い浮かべたり、あるいはSFの世界のようなことを実現できる魔法使いのような存在を想像するかもしれないが、実際の業務の多くは手元にあるデータを操作して様々な角度から集計・分析していくことであり、その作業は、少なくとも人工知能などの華々しい言葉からイメージできるものに比べれば地味なものである。しかし、現実にはデータサイエンティストはこうした地味な作業に時間の大半を費やしていて、しかも処理に時間がかかる、データのロードに時間がかかるなど、基盤側が原因となって思考のボトルネックになってしまうケースが非常に多い。現在のHadoopは、こうしたデータサイエンティスト達の課題を解決するための基盤を提供することができるようになっている。

エンタープライズデータハブ

　上述のような使い方は、どれか一つだけの使い方しかしないのであれば、代替の選択肢はいくつもあるだろう。たとえばNoSQLであればApache Cassandra(以下Cassandra)があるし、Elasticsearchを使えば大規模データの検索基盤を作ることは可能だろう。しかし、Hadoopの最大の価値は、上述のような使い方を「単一の基盤」で行うことができることにある。データをコピーすることなく、アドホッククエリの実行から、検索のインデクシング、機械学習のモデリングまで全てを行うことができる。これを、エンタープライズデータハブという。

　詳細な統計がないため推測ではあるが、おそらく現在の使い方の主流は以下のようなものの組み合わせではないかと思う。

• ほぼ全てのユーザが実施する
• 大量のデータを取り込んでETL処理を行う
• 定期的なビジネスレポートを出力する
• BIのバックエンドDBの一つとしてHadoopを選択し、アドホッククエリを投げる
• 必要なユーザのみ実施する
• ETL処理が終わっていない生データや、BIでは調査が難しいデータに対し、Hadoop上で直接アドホックな分析処理を行う
• 警察対応、経営陣からの特命などによる、急ぎでのアドホックなレポート作成
• システム連携
• 集計データ参照用のバックエンドDB
• ユーザに紐づくメトリクス(ゲームのスコア等)
• マシンに紐づくメトリクス(IoTや監視システムなど)
• リコメンド結果の参照用
• 大量データに対する検索バックエンド、特に警察対応、エンドカスタマー対応など(頻繁に問い合わせがくる場合、アドホックでなくシステム化する必要がある)
• リアルタイム異常検知

　この中でも特に多いのが「大量のデータに対してバッチ処理を行い、SQLでアドホッククエリを実行し、同時にSpark / Pythonでデータ分析を行う」というパターンであると思う。まずはこの使い方だけ覚えておけばいいだろう。

まとめ

　本記事では、2016年5月現在におけるHadoopの使い方として、バッチ処理、分析基盤、業務システムバックエンド、データサイエンティスト向け基盤、そしてエンタープライズデータハブの5つについて紹介した。もちろん、こうした使い方が全てではないし、上記に当てはまらないものの非常に先進的かつユニークな事例もたくさんある。この記事の目的は、「Hadoopはバッチ処理だけではない」ということを理解してもらうことにある。是非、皆様の手で新しい使い方を開拓していただきたい。

1. 発表当時は Cloudera Impala だったが、2015年に Apache Software Foundation に寄贈され、Apache プロジェクトとなった ↩