Computer Weekly製品導入ガイド

課題はビッグデータ管理のためのプラットフォーム選定

無数のソースから得た多様な形態のデータ分析を目指すビッグデータでは、思考と技術の両方の切り替えが要求される。

公開 2013年10月28日 08時02分

更新 2013年10月31日 15時59分

著者

Clive Longbottom

[Computer Weekly]

印刷する Googleで優先するソースとして追加

　少なくとも主要ソフトウェアとハードウェアの供給に関する限り、2012年はビッグデータの年だった。この市場のほぼあらゆるサプライヤーが、ビッグデータ用ソリューションとして取りあえず売り込める製品を投入した。そうした的外れのテクノロジーが多数出回ったことで、データから価値を引き出すために真に必要なものは何かという点について、誤解が生まれた。

　だが、2013年はビッグデータが合理性を持つ年となるだろう。多くのサプライヤーが提供するシステムは、他社に遅れまいと既存の製品を手っ取り早く組み合わせて市場に投入したゴタ混ぜではなく、ビッグデータの問題の多くに対応すべく構築されるようになったからだ。

ビッグデータの課題

　では、ビッグデータにはどんな問題があるのか。まず多くが思い浮かべるのは「量」だ。では大量のデータが存在すれば、それはビッグデータ問題と呼べるのか。そう呼べる場合もあれば、呼べない場合もある。単なる「大量データ」の問題であれば、OracleやIBM、Microsoftなどが提供する拡張性の高いデータベースに、これら各社やSAS Instituteなどの独立系サプライヤーが提供する優れたビジネス分析ソリューションを組み合わせれば済む。

　問題なのは量だけではない。ビッグデータにはもっと多くの可変要素がある。まずは情報源の多様性を考慮しなければならない。全てのデータが平等だという考えに基づき、情報の流れを単なる1と0の流れと見なすことはもはやできなくなった。今後はデータベースの中に何もかも保存することはできなくなる。

　各種のファイル形式、Webを巡回する検索エンジンから集めた情報、そしてその他の情報源も全て含めて、基本素材として利用できるようにしなければならない。IBM、Oracle、Teradata、EMCなどの各社も、各種の技術を集約して混在データに対応できるシステムを構築したり、個々の種類のデータを最適かつ一貫した方法で管理・分析するのに適したシステムを提供できるようになった。

　画像、音声、動画、さらにはリアルタイムの製造ラインデータやスマートビルディング、環境システムのような標準化されていないデータソースの利用増加に伴い、データはコンテキストに添って扱わなければならなくなった。そのためには、優先順位を付けたデータストリームに対応でき、そうしたストリームをラインスピードで、あるいは十分なストリームを複製し、必要に応じてライブストリームの外で対応することによって分析できる機能を持ったネットワーク機器を使う必要がある。Cisco、Juniper、Dell、HPといった各社が提供するネットワーク機器の大半は、802.1p／Qプライオリティとサービス品質設定に対応でき、外部的にはMPLS（Multiprotocol Labelling Service）のタグを使ったパケットに対応できる。

　次に来るのは速度だ。小売業務であれば、翌日の供給業務のために日ごとの取引を分析する必要はあっても、リアルタイムのデータ分析は必要としない。一方、投資銀行は、商品価格など変化の速い生のデータを参照しながら投資を決定しており、できる限りリアルタムに近い分析が必要になる。同様に、政府の安全保障システムや、オンライン詐欺検知、マルウェア対策システムなどの効果を出すためには、大量のデータをリアルタイムに近い速度で分析する必要がある。そうした分野でIBMの「PureData」やOracleの「Exadata」、Teradataなどの最新システムは、大量のデータをリアルタイムで処理できるよう設計したソリューションを提供している。

データの正確性

　データの正確性も考慮しなければならない。これには2つの要素がある。1つはその組織の管理下にあるデータの品質。氏名、住所、電話番号など個人に固有の情報は、UKC hangesやPCA、Equifaxといった企業のデータクレンジングを通じて扱うことができる。一方、例えばマッピングデータなどの情報は、GoogleやBing Mapsなどのクラウドサービスを通じて扱うことが可能だ。従って、データが正確で最新状態にあることを保証するという問題は、その分野のエキスパートとされる組織に委託できる。

　データの正確性のもう1つの側面は、その組織の直接的な管理下にないデータにまつわるものだ。社外の情報源から引き出した情報は、その情報源がどの程度信頼できるかを見極めるための判定を行う必要がある。例えば前述したような名のある情報源であれば、信頼できることは明らかだ。そうでない情報源の場合、その情報源が他にどれだけ引用されているか、その情報にかかわる個人や組織の知名度や他者に信頼されているかどうかといった点を調べるために、クロスリファレンスが必要になるかもしれない。この分野では、Wolfram Alpha、LexisNexis、Reutersなどの各社が、単なる直接的なインターネットトラフィックよりも信頼に足ると見なせる、裏付けのある情報を提供している。

　次は価値だ。ここではアップストリームの価値とダウンストリームの価値という2つの側面を考慮する必要がある。

　大部分の組織はこれまで社内のデータに焦点を絞っていたが、今では他のデータソースを求めて組織外に手を伸ばす（アップストリーム）必要が生じている。例えば、新しい化学物質や化合物を研究している医薬品会社は、Webのモニタリングを通じて競合企業の動向にも目を配る必要がある。同時に、その動向とはほとんど無関係な要素は全てふるいにかけて除外しなければならない。

　ダウンストリームの価値は明白だ。それが相手にとってほとんど役に立たないデータであれば、分析結果をその相手に提供する意味はほとんどない。

リレーショナルデータベースとNoSQLの管理

　全般的に、ビッグデータに必要なのは単なる思考の切り替えにとどまらない。違う種類のデータを扱うために使う技術や、それを分析・報告する手段の切り替えも必要だ。

　Oracle、IBM、Microsoftといった各社の典型的なリレーショナルデータベースは現在のところ、表に収められ構造化されたデータを扱う上では役に立っている。だが、バイナリラージオブジェクト（BLOB）として保存される、あまり構造化されていないデータの扱いでは苦戦している。

　NoSQLやMongoDB、Couchbase、Apache Cassandraなどに代表されるスキーマレスデータベース市場の台頭は、構造化されていないデータを分析・報告しやすい形で保持できる方法があることを示している。こうした技術を組み合わせた分野で、IBM、Teradata、EMCなどの各社は真のビッグデータエンジンといえるシステムを構築し始めている。

　だが、構造化されたデータベースと構造化されていないシステムを組み合わせ、各種のデータを全て確実に適切な場所に落ち着かせるニーズは依然として存在する。そうした分野に適しているのがHadoopのような存在だ。HadoopはMapReduceを利用して、入ってくるデータストリームのフィルタとして機能する。出力された情報は、構造化データストア、あるいは非構造化データストアのいずれかに格納される。SAPを導入しているなら、HANAも同様の形で利用できる。

　データインフラの上には分析・リポート機能がなければならない。ハードウェアとデータベースを扱っているメーカーは、自前のシステムを投入する傾向にある。例えばOracleにはHyperionが、IBMにはCognosとSPSSが、SAPにはBusiness Objectsがある。だがそうしたサプライヤー以外の選択肢も豊富に存在する。独立系ではSAS Instituteが依然とし圧倒的な存在感を放っているが、QlikTech、Birst、Panopticon、Pentaho、Splunkといった新規参入組も、混在型データソースの横断的な分析機能を提供できているという点で非常に有望だ。

　2012年はビッグデータの誇大宣伝も飛び交ったが、だからといってビッグデータが重要でないというわけではない。幅広い多様なデータを効果的に分析して真のナレッジを引き出すことができれば、将来的なビジネスの成功に向けた大きな原動力となる。そのためには、模様眺めをしていてライバルに負かされるよりも、今から効果的なプラットフォームの立案に着手した方がいい。

印刷する

この記事の著者

Clive Longbottom

課題はビッグデータ管理のためのプラットフォーム選定

ビッグデータの課題

データの正確性

リレーショナルデータベースとNoSQLの管理

この記事の著者

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓