Computer Weekly製品導入ガイド
自社に合ったビッグデータアプライアンスの選定
ビッグデータ分析の分野はまだ比較的成熟度が低い。支出に見合った価値を保証するため、ビッグデータアプライアンスは慎重に選ぶ必要がある。
ビッグデータへのアプローチは、単一の出来の良いアーキテクチャを採用するのがよいらしい。専用に構築されたハードウェアとソフトウェアの組み合わせは、個々のコンポーネントを寄せ集めて手作業で組み立てるよりも、優れているに違いない――。
Computer Weekly日本語版 1月20日号無料ダウンロード
本記事は、プレミアムコンテンツ「Computer Weekly日本語版 1月20日号」(PDF)掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。
なお、同コンテンツのEPUB版およびKindle(MOBI)版も提供しています。
以上の論理は、データ管理分野のベンダーの多くが用いてきた。例えば、米OracleはExadataを買収して「Oracle Big Data Appliance」と呼ぶシステムを構築した。同製品は米Sun Microsystemsのハードウェアに多様なソフトウェアを組み合わせたもので、1つのアプライアンスでさまざまな種類のデータに対応する。米IBMもNetezzaを買収して同様のアプローチを採り、「PureData」と呼ぶ一連のアプライアンスを構築した。
他には、米Dellや米HPにもビッグデータアプライアンスがあり、米TeradataはAsterを買収して「Integrated Big Data Platform」を立ち上げた。日立データシステムズは「Hyper Scale-Out Platform」を、米EMCは「Data Computing Appliance」を、米DataDirect Networksはしゃれた名称の「SFA12K Big Data Appliances」をそれぞれ擁している。
ビッグデータの分析には多くの異なる方法がある、幾つか挙げただけでも、自前で構築する方法やサービスとしてのビッグデータなどがある。だが、避けたい問題も多数ある。サプライヤーはそれを支援することに力を入れる。ビッグデータに対してはアプライアンスのアプローチが流行しているが、果たしてそれは見かけ通りの単純な選択肢なのだろうか。
ビッグデータの5つの「V」
さらに深く掘り下げるためには、ビッグデータの本質を理解しなければならない。大抵の場合、これは量(volume)だけの問題と見なされがちだ。だがこれは、ビッグデータというよりは、大量のデータの問題の側面が大きい。ボリュームはビッグデータの5つの「V」の1つにすぎない。ビッグデータが提示する問題について理解するためには、問題を生じさせ、ビッグデータの世界でチャンスをもたらす他の「V」にも目を向けなければならない。
前述の通り、処理すべきデータは大量にある。だがそれが全て定型の構造化データであれば、それなりの規模の処理能力を持つ標準的なデータベースとストレージ、ネットワークがあれば事足りる。
しかしデータの多様性(variety)に目を向けると、真の問題が表面化する。構造化されたデータと、構造化されていないデータが混在している状況に対応しなければならない場合がそれに当たる。ほとんどのデータは、「Microsoft Word」用フォーマットであれ、M2M(マシン・ツー・マシン)データのカンマ区切り文字列であれ、画像やビデオや音声データのヘッダであれ、ある程度の構造を持つ。
次に来るのは速度(velocity)だ。これには2つの側面がある。第1に、分析環境に提示されるデータの速度。例えばモノのインターネット(IoT)のデータを扱うリアルタイムデータ分析では時として、人間の介入で減速させることなく、小さなデータのパッケージを大量に通過させなければならない。第2に、分析の結果を出すスピードが挙げられる。
例えば、金融取引で結果を受け取る側の人物は、結果を入手するまでの時間を他のトレーダーよりもミリ秒単位で縮めたいと思う。製造ラインでは支障が出る前に問題を見つけ出し、接続を切断せずにラインの業務を継続できるよう、対応を可能にする必要がある。
正確さ(veracity)も鍵となる。分析するデータの質が低ければ、結果の質も低くなる。従って、ビッグデータシステムではどんなものであれ、分析するデータの品質をチェックするか、ソースから上がってくるデータの品質を保証できなければならない。
最後の「V」は価値(value)を指す。どんなビッグデータ活動においても原動力となるのはこの要因であり、実際にはこれが第1の「V」になるはずだ。ビッグデータ分析を行うという意思決定は、結果から導き出される価値に基づいて判断しなければならない。この分析は行う価値があるのか? 事業活動や成功に及ぼす真の影響は? 英調査会社Quocircaによると、中には「いいアイデアに思える」という理由でビッグデータ分析が行われているケースもある。だが、ITリソースを利用するためには事業上の確固たる理由がなければならない。
従って、自分の組織にビッグデータシステムを売り込んでくるサプライヤーは、それぞれの「V」について伝えたいことがあるはずだ。全てのデータを何もかもリレーショナルデータベースに送って、構造化されていないデータもBLOB(バイナリラージオブジェクト)として無理やり取り込むやり方は、ビッグデータの対応としてふさわしくない。
同様に、現実を知らない相手は、リレーショナルデータベースの時代は終わったとか、今や何もかもHadoopストアかNoSQLデータベースで処理できると主張する。だが現時点でそれは間違っている。
一方で、個々に切り離された専用のデータシステムのアプローチもうまくいかない。例えばMapReduceを使ってデータを減らすための非永続Hadoopシステムと、リレーショナルおよび非リレーショナル永続ストアが別々にある場合、ビッグデータで求められる速度のニーズに対応できない。
分析に対する単一のアプローチ
真のビッグデータ分析を可能にするためには、それぞれの「V」に対応し、実際のビジネス分析に対する単一のアプローチを実現できるやり方でデータを取りまとめる必要がある。
そこで登場するのがアプライアンスのアプローチだ。同じアプライアンスの中でHadoop環境をリレーショナルおよび非リレーショナルデータストアと混在させることにより、インテリジェンスをシステム全体に組み込んで、適切なデータが適切なストアに適切なタイミングで存在することを保証できる。分析に必要な層は最適化して、用途に合わせた性能を保証できる。前述したサプライヤーは全てこの戦場で戦っている。
それでもまだ、ビッグデータアプライアンスの導入を検討する場合に注意すべき点はある。
ほとんどの組織にとって、ビッグデータは大量のデータを伴う。望ましい分析速度を提供するために、大半のビッグデータアプライアンスは大容量メモリを搭載し、インメモリ分析に対応している。
従って、導入を検討する場合はアプライアンスに十分なメモリがあるかどうか確認することが重要だ。アプライアンスはいずれ拡張が必要になる。導入時の搭載メモリが少なすぎるとシステムが想定よりも低速になり、速度の遅いストレージシステムとの間でデータを交換しなければならなくなる。
純粋なHDDベースのアプライアンスは注意を要する。データを取り出す速度は大幅に向上したものの、依然としてインメモリシステムに比べればはるかに下回る。
最上級のSSDと下位のHDDを組み合わせたハイブリッドシステムにも気を付けた方がいい。データの保存場所を管理するインテリジェントソフトウェアがない限り、分析システムがメモリからデータを引き出そうとする際に、メモリにデータがなければSSDに行き、そこにもなければHDDに行って、そこからデータを引き出してメモリに取り込むことになり、パフォーマンス上の重大な問題が生じるかもしれない。
今後の展望
目を向けるべきは「Hadoop」とNoSQL、リレーショナルのアプローチを組み合わせたシステムだが、同時に未来にも目を向ける必要がある。Quocircaは、以前からHadoopを持続ストアとしては使わないよう助言してきた。それよりも、あらゆる環境でMapReduceの機能を活用してデータフィルターの機能を持たせ、分析するデータの量を減らすようアドバイスしている。「MapR」は「Apache Drill」プロジェクトをリードし、米Hortonworksには「Hive Stinger」がある。いずれもHadoopストアに対してSQLクエリを実行することの有望性を示している。
IBMや、「Vortex」を擁する米Actianといったサプライヤーの商用Hadoop・SQL製品は、持続ストアとしてのHadoopが現時点で抱える速度の問題にある程度対応している。
データストアのNoSQL側では、米Basho Technologiesが他社とは違うアプローチを採る。NoSQLデータベース「Riak」のノードのメッシュを有効にして、それぞれビッグデータの違う局面に対応させることで「リング1つで全てを支配」、すなわち多様な種類のデータに対して高速でデータ量の削減に対応できるデータベースの構築を目指している。
最後に、特定の作業方法に縛られないシステムを探す必要がある。今あるビジネスインテリジェンス(BI)システムの利用を前提として確立されたスキルを捨て、新しいスキルを習得する事態は避けなければならない。選定するビッグデータシステムは、今あるBIツールの層をかぶせることに対応できる必要がある。
ビッグデータ分析の世界はまだ比較的成熟度が低い。自分で構築するアプローチでは費用対効果が得られる公算は小さく、専用アプライアンスでは短期的な問題しか解決できない可能性がある。支出に見合った十分な価値が確実にもたらされるよう、アプライアンスは慎重に選ぶ必要がある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社フィックスターズ] 組み込み開発特有の課題も解消できる「AI活用」の秘訣とは? -
事例
[株式会社ビザスク] 「新規事業」事例集:大手企業はどのように想定顧客ヒアリングを行っているのか -
市場調査・トレンド
[株式会社ビザスク] 質の高い「仮説検証インタビュー」を実施するためのポイント -
事例
[株式会社ビザスク] 富士フイルムの新領域参入に学ぶ事業創出 「畑違い」でもビジネス化できる方法 -
事例
[株式会社ビザスク] 三菱電機 上席執行役員に学ぶ、未来を切り開く「新事業創出」の実践方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
3
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
4
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
5
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
6
「IBM i(AS/400)はクローズドなシステム」という誤解 DXに寄与する一歩
-
7
長年の蓄積は利点にも弱点にもなる 「脱レガシー」実行前に解決すべき課題とは
-
8
AI時代のITインフラ戦略とは? 販売代理店が知っておきたい最新トレンド
-
9
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
10
「GitHub Copilot」3000人に配布も基本機能しか使われない 保険大手が得た教訓
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
3
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
8
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー