2013年11月号よりビッグデータ解析は大きく分けて同期・非同期の2つのタイプがある。両者ともに膨大なデータを必要とし、特化した需要を持っている。ビッグデータ解析という言葉がIT用語の中に入り込んできた背景には、我々の全ての疑問に対する答えは、データの山の中に埋もれているという考え、即ち「ビッグデータ幻想」とでも言うべきものに対する我々の強い固定観念が存在している。我々が充分なデータポイントを比較し相互参照する事ができれば、我々は競争に打ち克ち、全ての悪者を捕え、世界を災害の危機から救うのに役立つ洞察を手に入れるのだろう。問題は、この解析は大量のデータを必要とする事であり、まさにここにITへの課題が横たわっている。これらの洞察を得るのに必要なデータをどのようにキャプチャーし、保存し、アクセスし、解析するのか、さらにはその仕事を遂行するのに使われたリソースをどうやって正当化するのか。ビッグデータ解析では、従来のコンテンツ形態のかわりに、Webトラフィック、金融取引データ、センサーデータといった情報を使うのが一般的だ。データの価値は、そのデータを他のデータセットと比較し、関連付け、参照することによって決まってくる。ビッグデータの解析は通常、非常に大量の小さいデータオブジェクトを、低いストレージレイテンシ(訳注:即ち高速で)で扱わなければならない。ビッグデータ解析は主に2つの使い方があり、それらはデータの処理方法によって区別される。リアルタイムのビッグデータ解析の初期の事例のひとつとして、スーパーマーケットがあなたの買い物における行動パターンを算出し、レジのレシートにクーポンを印刷する、というものがある。実際のところ、買い物行動パターン算出はおそらく事前に行われ、あなたが支払う時に参照されるだけのものだったのだが、考え方は現在の同期解析と同じだ。他の例としては、ソーシャルメディアサイトが、絶えずあなたの好みやオンラインでの行動を解析し、さらにはその情報を広告会社に売って、次にあなたがそのサイトを訪れると、その広告会社によるポップアップが出てくる仕組みも、そのひとつだ。小売業界においては、いくつかの大手店舗が、顔認識ソフトウェアの利用を始めている。買い物客が駐車場で本人識別され、彼らの買い物に関するプロフィールがアクセスされると、買い物客が店内を歩き回っている間に販促用の資料がメールや(訳注:インスタントメッセージなどの)テキストの形で送られる仕組みだ。このようなリアルタイムの事例では、スピードが決定的な要素であり、ビッグデータのストレージ基盤はレイテンシを最小化するように設計しなければならない。同期解析用ストレージリアルタイム解析アプリケーションは一般的にNoSQLのようなデータベース上で稼動する。これらのデータベースは、巨大な拡張性を持ち、汎用のハードウェアで構築できる。それに対して、Hadoopは非同期のビッグデータ解析作業のようなバッチ処理に向いている。ストレージは通常レイテンシの原因になるため、リアルタイム解析用途として半導体ストレージデバイスが選択されることが多い。半導体ストレージの導入には幾通りかの方法がある。従来のディスクアレイ上のティアとして、またはNASシステムとして、またはアプリケーションサーバー自身に内蔵する形である。サーバーに内蔵する形態は、レイテンシ(CPUに最も近いストレージ)が最小になる点と、数百ギガバイトの容量からでも始められる点で人気を得ている。Express(PCIe)カード型の半導体ストレージが、リアルタイム解析のようなパフォーマンスを重視するアプリケーション用として標準になりつつある。現在、多くの企業がPCIe半導体ストレージを提供している。Digitalに買収される予定)などがその一部である。全ての大手のサーバーベンダーおよびストレージベンダーも同様にPCIeソリューションを販売している。多くは前述の半導体企業とのOEM契約によるものだ。現在のPCIeカードは10TBまでの半導体容量を提供できるが、依然として共有ストレージプールは必要のようだ。Connectソフトウェアのようなテクノロジーを使うことだ。このソフトは複数のPCIeカードをまとめて半導体の容量をプールすることができ、さらにはInfiniBand経由で複数のサーバーのPCIeストレージをプールすることも可能だ。vMotionを使う時に非常に便利だ。多数のサーバーの半導体ストレージをプールすることによって、これらのソリューションはフェールオーバーと高可用性の機能を提供している。ひとつの選択肢は、InfiniBandやファイバーチャネル、さらに高速のPCIe経由で接続された全半導体内蔵ストレージアレイである。これらのシステムの容量は、10TB未満のものから、拡張性のあるモジュラー型アーキテクチャーによって100TBを超えるものまで幅がある。これらのハイエンド・ソリューションは、百万IOPSのパフォーマンスと公称数百マイクロ秒に及ぶ低レイテンシを実現する。Memoryを買収したIBMを除けば、小さな企業の方がより多くの製品を持ち、より長い実績を持っている。非同期型処理を伴うビッグデータ解析は、キャプチャー・保存・解析のワークフローのうち、(センサー、Webサーバー、POS(point-of-sale)端末、モバイル機器、等々によって)データがキャプチャーされるところまでは同期型と同じだが、次にデータはストレージシステムに送られ、それから解析にかけられる。これらのタイプの解析は、従来のリレーショナルデータベース管理システム(RDBMS)を使って行われるため、データは行や列などRDBMSの構造に合わせて、変換あるいは加工しなければならず、また解析が行われている他のデータセットと整合性がとれていなければならない。この処理はETL(Extract:抽出、Transform:加工、Load:ロード(読み込み))と呼ばれる。データはソースシステムから抽出(extract)され、データセットとして標準化(transform)され、しかるのちにデータはデータウェアハウス(倉庫)にロード(load)され、解析されるのを待つ。解析が、金融レポートや、セールス&マーケティング、企業リソース計画などよく知られているものが対象であった時は、従来型のデータベース環境におけるこのETL処理はシンプルなものだった。ビッグデータを扱うようになると、ETLは個々のデータ毎に加工方法が異なるケースや、データ毎にソースが異なるような複雑な処理となるケースが出てくるようになった。解析が行われる時、データは倉庫から取り出されRDBMSに流し込まれる。解析の結果は、レポートの作成やその他のビジネス・インテリジェンス・アプリケーションを支援するために使われる。ビッグデータへの期待に沿うべく、一般にデータは加工されたデータとともに生の形で保存される。将来の仕事において再度加工が必要になるかもしれないからだ。非同期ビッグデータ解析用ストレージ非同期型ビッグデータを使用する際の課題となるのは、容量、拡張性、(規模ごとに)予測可能なパフォーマンス、そして何よりもこれらの機能を実現するためのコストである。データウェアハウスは非常に大きなデータセットを作りだせるものの、テープ型のストレージではレイテンシがあまりにも大きすぎる。従来の「スケールアップ」ディスク・ストレージ・アーキテクチャーは、このレベルの容量になってくると通常、コストパフォーマンスがよくない。スケールアウト・ストレージ:単一のストレージプールとして動作するために、クラスター化されたモジュールやノードを使うスケールアウト・ストレージ・アーキテクチャーは、通常ファイルシステムインターフェースを持っており、ビッグデータ解析に魅力的なソリューションを提供できる。Storage(SONAS)などがある。個々のノードが処理能力とディスクストレージを持っている為、実際に容量に合わせてパフォーマンスも拡張できる。Hadoopは、ストレージのフレームワークとしても使われており、企業が低コストのハードウェアを使って高い拡張性を持つ自社のストレージシステムを構築することを可能にし、最大限の柔軟性を提供している。Hadoopは、ノードのクラスター上で稼動する。個々のノードはストレージ容量と計算能力を持ち、通常データ処理向けに設計されている。他のノードはこれらの処理作業の調整と、分散型ストレージプールの管理に使われる。System(HDFS)が使われるが、他のストレージシステムでもHadoopクラスターシステムと連携することは可能だ。Hadoopでは、厳密に言うとHDFSでは元々そのために設計された高可用性環境をサポートするため、データのコピーを3部作らなければならない。データセットがテラバイトの範囲であればまだいいが、容量がペタバイトクラスになってくると、HDFSにおけるストレージは非常に高価になるケースが出てくる。スケールアウト・ストレージシステムでさえも、その多くがボリュームレベルのデータ保護とシステムレベルのレプリケーションを提供するのにRAIDを使っているために、同様の問題に悩まされる場合がある。オブジェクトベースのストレージ技術は、大規模環境が往々にして陥りがちな、このデータ冗長化の問題に対して、ソリューションを提供できる。オブジェクト・ストレージ:オブジェクトベースのストレージ・アーキテクチャーは、その多くが柔軟なデータオブジェクトとシンプルなインデックスを使っており、スケールストレージの階層的ストレージ・アーキテクチャーと置き換える事によって、そのメリットを大幅に拡大することができる。coding)付きのオブジェクト・ストレージシステムは、データ保護のためにRAIDやレプリケーションを使う必要がなく、結果としてストレージ効率の劇的な増加をもたらしてくれる。coding)つきのオブジェクト・ストレージシステムは、わずか50~60%のオーバーヘッドでより高いレベルのデータ保護を実現できる。ビッグデータストレージ環境においては、このコスト節約は膨大なものになり得る。市場には多くのオブジェクト・ストレージ製品がある。Swift、Cephなどがその一部である。Cleversafeのように、いくつかのオブジェクト・ストレージ製品は、Hadoopとも互換性がある。これらの実装においては、Hadoopのソフトウェアコンポーネントはオブジェクト・ストレージノードのCPU上で稼動し、オブジェクト・ストレージシステムがストレージクラスター内のHDFSと置き換わる。結論:ビッグデータストレージビッグデータ解析が成功をもたらしてくれると信じる企業は増え続けており、ITにおける「特効薬」のような様相を呈している。新しい治療法が往々にしてそうであるように、そこには何らかの副作用が伴う。ビッグデータ解析の場合、現在のストレージ技術の実態が副作用をもたらす。従来のストレージシステムは、非常に低いレイテンシを必要とするリアルタイム・ビッグデータ・アプリケーションにも、巨大なデータウェアハウスを蓄積するデータマイニング・アプリケーションにも、性能が不足している。ビッグデータ解析という獣を飼育するには、ストレージシステムは高速で、拡張性があり、コストパフォーマンスが良くなくてはならないのだ。coding)付きオブジェクトベースのスケールアウトアーキテクチャーは、従来のRAIDやレプリケーション方式に引導を渡し、新しいレベルの効率とより低いギガバイト単価を実現する拡張性の高いストレージシステムを提供する。Switzerlandのアナリスト。表示させるためには、JavaScriptを有効にしてください。