ソーシャルネットワーク企業のAddThisは先日，Hydraを
Hadoopのエコシステムが活況を呈しているが，Hadoopそれ自体の代替となると，いまだ確定したものがない状態だ。最近ではHadoopの作者であるDong Cutting氏でさえ，Hadoopのようなシステムが複数現れることを期待しているが，何もないのは残念なことだ，という意見を述べている。
AddThisのCTOで，HydraのHello Worldプログラムを概説しているMatt Abrams氏と，同社のエンジニアであるIan Barfield氏のふたりがInfoQに対して，HydraとHadoopとの比較に関して説明してくれた。
InfoQ: Hydraが提供する汎用的なフレームワークは，MapReduceと同じようなパラダイムによるソリューションを表現しているのでしょうか？ 開発者の視点から見た場合，重要と言える違いは何ですか？
Hydraの背景にあるのは，"データはたくさんある，そこから得られそうな情報もたくさんある – たくさんありすぎて，何を知りたいのかさえ分からない"といった感覚です。いわゆる"次元の呪い(Curse of Dimensionality)" – 次元が増えることで，十分な分析を行うためのコストが指数関数的に増大する，という現象ですね。Hydraはこの次元の数，あるいはそれを見るためのコストを，(確率論的なデータ構造を通じて)容易に削減できるようにします。ユーザが関心を持つであろう質問の大部分に答えながら，すべての処理の高速化を実現するポイントまで，です。
Hydraの処理はMapReduceとほぼ同じですが，MapReduceほど制限は多くありません。ジョブ状態の管理は難しいのですが，高いパフォーマンスと高度な柔軟性を備えています。データは完全にソートされている必要はありません(必要だと思うのであれば，もちろんそれも可能ですが)し，ジョブにおいて"すべてのデータの再処理"が必要になることはほとんどありません。コンポーネント(これはHydra特有ですが)で，ファイルを書き込む場合のネットワークプロトコルを気にする必要はありません 。ローカルファイルシステムとまったく同じです。
辞書順で語数を数える例はまさにそれです。Hydraのこのサンプルは，キーによる断片化を行う分割ジョブと，非常に簡単なツリー構造(ヒットした文字列のデータベース)を生成するツリージョブ，この２つで構成されています。
Hydraが柔軟だといっても，分割ジョブまでは必要ないかも知れません。直接ツリーを作ることにして，分割の問題は問合せ時に処理すれば十分でしょう (頻度に伴うコストがトレードオフに影響しなければですが – いずれの方法にもHydraは対応可能です)。このような機能が重要なのは，分割ジョブの開発や実行が(時間やリソースを浪費したとしても)難しいからというよりも，単に大量の値を分割や並べ替え可能だから(タプルを許容するか，あるいはキーに厳密な相関関係があるのでない限りはただひとつですが)なのです。
InfoQ: Hydraは常にアウトプットとしてツリーを生成するのですか？ そうなっている理由は何でしょう？
いいえ。Hydraは高度にコンポーネント化されたジョブシステムを備えています。追加機能としてログファイルへの書き込みや，あるいはKafraやCassandra, HDFSといった，もっとエキゾチックな場所へのエクスポートが可能です。
高レベルのコンポーネントは，可能な限りお互いを知らなくてもよい構造になっています。もっぱら自分の仕事だけを行うのみで，その結果が相互にフィットするのです。抽象化として全体の調整を保つための詰め木のような部分もありますが，柔軟性は確保されています。
例えばジョブ設定のテキストをPythonコードに置き換えて，コマンドをexec python job.configに変更することに，何の障害もありません –– タイマはPythonプロセスの起動/停止をしてくれますし，ローカルデータの更新，クラスタメッシュ上のアウトプット，サーバフェールからのリカバリなどといった機能も，すべて問題なく動作します。
InfoQ: Hadoopと比較した場合，Hydraがより適しているユースケースはどのようなものでしょう？ 逆にHadoopを選択した方がよいのはどのような場合ですか？
Hydraが優れているのはデータ検索です。たったひとつの，おそらくは比較的高速なマップジョブの結果から，たくさんの手がかりを得ることができるはずです。結果ツリーに対するクエリは通常，秒(あるいはミリ秒)のオーダで動作します。
プログラマでなくても簡単なガイダンスを受けるだけで，実用的な製品を開発することができます。必要になりそうなものはほとんどすべて，Web UIが提供してくれます。既存のジョブのコピーを作って，いくつか違う機能を使うようにツリーを修正したら，あとは実行するのみ，というくらい簡単なのです。数分もすれば新しいURLエンドポイントが出来上がって，企業のホームページに印象的なKPIが新たに表示されるようになります。
Hadoopにもアドバンテージがあります。非常に大規模で単発的なジョインが，強力にネイティブサポートされています。これを技術的に言えば，ファイルの暗黙的なソート処理が強力だ，ということになります。多数のデータのソート処理は高価なので，それを回避するために多くの努力をしています。その結果として，この種の処理のサポートは不足気味の傾向があります。その一方で，完全なジョインは実際には必要でなく，ブルームフィルタ(Bloom-Filter)ベースの確率論的ハイブリッドを持ったコンテントで事足りる場合もあるでしょう – このケースでもHydraは，ある種のスイートサイクルからの救いになります。
InfoQ: HadoopとHydraは併用可能なのでしょうか？ この方法がよいアイデアになりそうな例をあげて頂けますか？
併用可能です。HydraはHDFSを読み書きできます。HDFSを利用できるツールやフォーマット，サービスは他にもたくさんあります。あなたの周りにも，HDFSを使用したドリルクエリ，あるいは低～中優先度の製品に長けたデータ科学者が，一人くらいはいるでしょう。彼らに何かを教えるよりも，データの特定のサブセットをエクスポートして彼らに与えるほうが手っ取り早いこともあるはずです。
InfoQ: Hydraのオープンソース化にはどのような目的があるのでしょう？ Hydraに重要な貢献をしたのはどのような企業ですか？
Hydraは6年以上にわたって，AddThisで開発が続けられてきました。非常にパワフルで，分散データ処理製品の分野では傑出した製品だと自負しています。Hydraをオープンソース化することで私たちは，製品をさらに前進させるためのユーザと開発者によるコミュニティの創出を期待しています。
私たちはまた，オープンソースコミュニティに対して恩義を感じてもいます。企業としてのAddThisは，オープンソースプロジェクトの徹底した利用なしには成り立たないでしょう。Hydraのオープンソース化は，その恩義を返すひとつの方法でもあるのです。Hydraを実運用して，プロジェクトにコントリビューションを返してくれる企業の数は多くありませんが，その名前を挙げることは，現時点では許されていません。
InfoQ: 最後になりましたが，現在の状況を考えたとき，HydraをHadoopの代替として位置付けるのは合理的なことでしょうか？
もちろんです。Hydraの方がより適している作業に対してHadoopを使用しているユーザが，かなりの数に上ることは間違いありません。簡単な変更ではないので，それに見合った，適切なデータサイズと制約との交点が必要だろうと想像します。