Cray、HPCのためにHadoopを発展

Tiffany Trader

Cray社のHadoopプロダクトマーケティングマネージャ、Mike Borosの最近のブログエントリーで、科学的なビッグデータのためのHadoopの同社の位置付けについて書いている。古い格言のように、「あなたが持っている唯一のツールがハンマーであれば、すべての問題が釘に似始めます。」Borosは、ビッグデータツール(Hadoop)で最もよく知られたものを査定する技術計算の専門家にとってインストルメントの法則は、真実であるだろうと示唆する。

Borosは、「科学的なビッグデータにとって適合しない不適切に組み入れられた技術を使用したとき、Hadoopを使う事で実際に大きくて重いハンマーを振るうように感じることがあるかも知れません。しかし、適切に使った場合、そして科学的なビッグデータの現実に特に合っている技術の積み重ねで、Hadoopは、物事の広い範囲で行うことが可能な多目的ツールであるSwiss Armyナイフのように感じることができます。」と書いている。

「もちろん、HadoopがSwiss Armyナイフのように感じるか否かは、ユーザーの経験レベルについてだけに依存するのではなく、それは科学的ビッグデータのために設計され、実装されているかどうかでもあります。そして科学的ビッグデータは、世界の残りの多くが対処しているビッグデータとは異なります。 」と彼は付け加えた。

それは目下抱えている仕事のための適合性に全て要約される。Hadoopは、大きなファイルに集約され、その後その全体が分析されたデータのひと口大の部分を扱うように開発された。これは、ソーシャルメディア配信システムでユーザの感情を評価するための理想的なアプローチであり、多数のセンサデータを組み込むビッグデータ科学アプリケーションにも適用することができる。しかし、それがビッグデータアプリケーションの一部として、地震波や気象モデルファイルを分析することになると、Hadoopの有用性が破綻し始める。

「データの不必要なブロックを分析するこの非効率的なプロセスは、一日数十から数百回繰り繰り返すとき、Hadoopが鈍感で不適切なハンマーのように実際感じることができます。」とBorosは書いている。「これは、ファイルへのランダムアクセスが必要とされている場合であり、率直に言って、それはHDFS(Hadoop分散ファイルシステム)で制御出来るものではありません。」

しかし、そのSwiss Armyナイフのようなデザインのために、Hadoopはいくつかの興味深い回避策や修正に適している。MapReduceを活用し、LustreのようなPOSIX準拠のファイル·システムと共にHDFSを包含することによって、ユーザーは簡単に大規模な階層的なファイルを分析することに向けてより多くの資源を割くために、余分なまたは興味のないデータブロックを簡単にスキップすりことができる。これは実際にHadoopではないが、POSIX準拠なファイルシステム上のMapReduceであることを指摘しようとする人たちに、そのアプローチはHadoopの他の操作に影響しない方法で行われていることをBorosは説明し、MapReduceエコシステムが依然手つかずであることを意味する。「言い換えれば、ストレージは、他のファイルシステムがその下側に横たわっているにもかかわらず、それはHDFSであるかのようにMapReduceとその構成成分に提供されなければなりません。そして、はい、それはここCrayで私たちのHadoopソリューションを設計するために考えている方法の1つです。」とBoros書いている。

Borosは、標準的なHadoopの実装が従来のHPCアプリケーションに最適ではないことを理解しているが、彼はツールがビッグデータ/ビッグコンピュートの格差を埋めるために固有の柔軟性を持っていると思っている。科学的な環境が、POSIXファイルアクセスを中心に構築された標準的なファイルシステムでうまく機能している一方、MapReduceと共にPOSIX準拠のボリュームをマウントすることが理想的な状況であるとBorosは示唆している。そこに元に戻すべき幾つかのよじれがまだあるが、Crayはこれらに取り組んでおり、そしてBorosによると、 「殆どの組織で最もミッションクリティカルなデータでさえも適切であることがわかる15〜20％のRAIDパリティが求められるだろうファイルシステムを使用して、あなたが200％の可用性のオーバーヘッド税を負う義務は無いでしょう。 」

ここでのメッセージは、ひとつの環境が分析とCPU負荷の高いワークロードの両方に優れることができるということである。Crayにとって、Hadoopスタックの柔軟性とこのビジョンにおける主要な役割を演ずる基盤をサポートしている。同社は、分散型のインフラストラクチャを使用するよりもより効果的で、おそらくよりコスト効率的とするためにHadoopを変更するためのステップを取っている。

組織がこの方法で二重の任務を行うシステムを欲しがる理由については、Borosは柔軟な基盤とワークフローの利益を強調する。複数のジョブタイプによって同じ基盤を使用できることは、ユーザーが異なる時点でプロジェクトの異なる部分に焦点を当てることを可能にする。彼らはまた、標準的なアプリケーションの範疇に簡単に分類することが出来ないグランドチャレンジ問題に取り組むためのオプションがある。そして、アプローチの実装方法に依存して、リソース管理とジョブスケジューリング技術を採用することによって並列に異種のワークロードやワークフローを管理することができるであろう。このようなマシンは、予算や人員リソースの公正な分担を達成するために支援し、部門間での共有に力を貸すだろう。

Borosは、それが社内で開発することを意味したとしても、HPCが与えられた仕事のために最良で可能なツールを歴史的に選択したように、Swiss Armyナイフの類推のための幾つかの後退させられることを予想している。しかし、そのパラダイムが変化している。コモディティ化は、HPCに定着している – そして、象徴的なCray-1のメーカーがこの局面の収束についての進撃の先頭に立っている。

ここでのBorosは、Hadoopの進化を説明する：「それがDevOps相当のダクトテープとPerlスクリプトとRubyでワイヤーを巻き取ることを適用し、その日を費やすことによって大規模なスタッフが何千もの安価なホワイトボックスを維持しているサービスプロバイダーの世界が想像されました。」と彼は書いている。「それは、幾らか緑で、まだ正しいことを得るためににいじるの多くを必要とします。そして、それは箱のデザインから離れて、HPCが表す如何なるものと完全に180度反対であるように思われます。しかし、私はそれがそう遠くない将来、データセンター内の重要な役割を持つようになるだろうと信じています。 」