Hadoopの仲間達

HadoopのサブプロジェクトHive、Pig、Impala、HBase、Hamaの紹介

Hadoopは非常に強力な分散処理のフレームワークを提供しますが、Hadoop単独でできる処理は限られます。また、MapReduceの設計や実装を必要とするために使いにくい面があるのも事実です。そのため、Hadoopを補うサブプロジェクトが登場してエコシステムを形成し、Hadoopの適用先を広げています。これらのサブプロジェクトはHadoopのHDFS及びMapReduce同様にGoogleのプロダクトに影響を受けたものが多く、対応するGoogleのプロダクトが存在します。

以下、この図のうち代表的なサブプロジェクトの一部を紹介します。

Hive

HiveはFacebookで開発されたMapReduceのラッパーで、日本では分散データウェアハウスとも呼ばれます。HiveはHDFS内のデータに対し、SQLによく似た言語であるHive QLでクエリを発行し、このクエリを内部でMapReduceに変換することで処理を実行します。したがって、HDFS内のデータの問い合わせ処理や集計処理を、MapReduceの設計をしなくても、Hive QLで実行できます。

Pig

PigもHiveと同じくMapReduceのラッパーですが、こちらは米Yahoo!により開発されました。Pigは日本ではデータフロー言語とも呼ばれます。PigはPig Latinというスクリプト言語を使い、データフローを定義することで、内部でMapReduceに変換してデータを処理します。PigはGoogleのオープンソースである、ログデータ向けの管理/操作/統計解析言語Sawzallに相当します。

HiveとPigはできる処理も似ていますが、1)SQLユーザには、Hive QLの方がPig Latinより分かりやすい事、2)同じ処理でもHiveの方が速いという理由から、Hiveの方が人気があります。処理速度の差はPigのバージョンが上がるたびに小さくなっています。また、データ変換を何度も繰り返すような処理はPigの方が少ないコード数で実装できるメリットがあります。両者の使い方については、筆者が以前に書いた記事でも紹介しています。

ビッグデータ処理を自宅で体感!「Hive/Pig」徹底解説

Impala/Apache Drill

ImpalaはClouderaで開発され、2012年に登場したサブプロジェクトです。処理用途はHiveと似ていますが、1)SQLで記述が可能、2)MapReduceを使わない独自の分散クエリエンジンを利用し、3)C++で実装しているのでHiveよりも処理が早いという特徴があります。ImpalaはGoogleのDremelに対応します。同じくDremelに影響を受けたApache DrillはApache Foundationの元で開発が進められています。

DremelはSQLに対応したカラム型データストアで、OLAP(Online Analytical Processing)や分散処理を高速に実行し、BigQueryと呼ばれるサービスを提供しています。

HBase

HBaseはPowerset社の開発から始まりました。HBaseはHDFSの上位レイヤに位置し、GoogleのBig tableに相当するカラム型データストアのKVS(Key Value Store)です。KVSは文字通り、データをkey-valueのペア形式で保存し、このkeyがRDBMSのインデックスの役割を果たします。HDFSではランダムアクセス、つまりインデックスを参照したデータアクセスができませんが、HBaseはKeyを指定することでランダムアクセスを可能にしています。また、MapReduceにも対応しているため、HBaseへのデータ投入や集計処理にMapReduceのフレームワークだけでなく前出のPigやHiveも使えます。

補足すると、カラム型は列指向とも言い、列方向にデータをまとめて扱い、特定の列の値をまとめて処理できるため、列毎の集計処理に向いています。列方向にデータをとると、データ型が揃い、その値が似ている、あるいは同じ値が繰り返し表れる頻度が高いために、列方向のデータは非常に圧縮効率が高くなるというメリットもあります。

これに対し、通常のリレーショナルデータベース、例えば、MySQLなどは行指向のデータベースです。行指向ではテーブルの一行を一つのデータとして扱い、データの追加や検索も行単位で実行するため、データの更新追加削除といったトランザクション処理に向きます。

Apache Hama/Giraph

Hamaの名前は"Hadoop Matrix"に由来し、大規模グラフ問題に特化したソリューションです。大規模グラフ問題の代表的な例には、Web上でのハイパーリンクの構造解析やソーシャルメディア上での友人関係の強さの計算問題があります。次回で触れる機械学習でも述べますが、この計算では複数回のMapReduce(収束するまで同じ処理を何度も)を実行する必要があるために、処理時間のオーバーヘッドや計算機のリソース消費が無視出来なくなります。そこで、この問題を解決するために、Hamaは並列アルゴリズムを実行するための計算モデルであるBulk Synchronous Parallel (BSP, バルク同期並列)に基づくフレームワークをHadoop上で提供します。BSPもMapReduceと同様に各ノードで並列処理を実行します。MapReduceは全ノードが処理を終了した後に処理結果をReduceでマージするのに対し、BSPでは任意のノード間で処理結果を通信することが可能です。その結果、Hamaはグラフ問題だけでなく行列演算やネットワークの演算のアルゴリズムに対しても適用可能です。勿論、前回記事のユーザ推薦やレコメンドにも適用できます。

Giraph

Giraph はGoogleが開発したPregelのオープンソース実装で、グラフ問題に特化しています。

次にHadoopのサブプロジェクトではありませんが、ビッグデータのリアルタイム処理のフレームワークを紹介します。

S4Apache S4/Storm

リアルタイムMapReduceとも言われるApache S4(Simple Scalable Streaming System)」は、米Yahoo!社により開発されたリアルタイム分散処理のフレームワークです。Yahoo! Labsでは、検索広告のパーソナライゼーション、ニュース性の高い検索結果のランキングやトレンド検知にS4を利用しています。後で紹介するStorm同様にCEP(Complex Event Processing)のシステムの一例に位置づけられます。

Hadoopは、一旦、データをHDFSに取り込んだ後に処理を行うために、処理のデータ(イベント)発生から処理結果を得るまでのタイムラグが発生します。例えば、ニュースをきっかけにWeb上の掲示板やSNSで盛り上がった話題(トレンド)があっても、バッチ処理ではデータを蓄積してから処理するため、そのトレンドを検索結果に反映するまでにタイムラグが発生することを避けられません。その他にも、センサデータやメッセージ処理、サーバの不正アクセスや機器の異常検知などリアルタイム性を要求される分野にはHadoopは向きません。そこで動的かつ間断なく発生するストリームデータを溜め込んでから処理を開始するのではなく、読み込みながら処理を行うためにS4は開発されました。処理対象のデータが指定されるMapReduce 処理はいずれ終了しますが、ストリームデータを対象とするS4はデータが来る限り永遠に処理を続け、連続的に処理結果を出力します。

S4はストリームデータをMapReduceと同様にkey及びValueから構成される形式で非同期に読み込み、処理した結果も同形式で出力する処理のフレームワークを提供しています。その結果、クローリングとほぼ同期する形で処理することができ、先ほどの例と比較すると、Web上で確認されてから、検索結果に反映されるまでのタイムラグを短縮できます。

同様のフレームワークにはTwitter社で開発されたStormがあります。StormもS4同様にトレンド情報の抽出に利用され、ツイートに新しいトピックが出現すると、リアルタイムで識別することができます。Hadoopがデータを一定件数ずつ溜めてブロック単位で処理するのに対し、Stormはデータをオンメモリーベースで1件ずつ処理するため、低レイテンシでの処理を実現します。StormはSpoutとBoltから構成されるネットワーク構造であるTopologyを構成します。Spoutは外部ソースからデータをTopologyに流し込み、Boltは処理を担当します。このBoltを組み合わせることで、高度な処理も可能になります。

Stormもまた、ストリームデータに対してMapReduce に似たフレームワークで処理を実行します。 StormはS4と違い、障害発生時のメッセージ処理を保障できる、つまり、データの欠損が無いことを保障します。従って、ミッションクリティカルな分野への適用も可能です。現時点ではS4と比較すると、利用実績はStormの方に分があります。

Hadoopのサブプロジェクトの多くはGoogleの技術者・研究者が発表した論文に影響を受けてきました。Hadoopの生みの親である、Doug Cutting氏の言葉を借りれば、「Hadoopの進む方向はGoogleが示している」ので、今後はSpanner(Googleで利用しているリアルタイムデータベース、現在は広告配信システムなどに利用)に相当するプロジェクトが出て来るかもしれません。このSpannerに関する論文は公開されています。

川前徳章(かわまえ のりあき)
工学博士、NTTコムウェア 研究開発部 勤務。専門は情報検索、統計的機械学習、マーケティングサイエンス。現在は感性検索とコンテンツジェネレータの研究と開発に従事。東京電機大学 安田研究室協力研究員。
関連記事:Hadoopでレコメンドシステムを作ろう