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に何を聞いても「汎用的な答え」しか返ってこないのはなぜか? -
製品資料
[サイボウズ株式会社] なぜAIは組織で定着しないのか? 全社活用を阻む「3つの壁」の突破法 -
製品資料
[株式会社スタディスト] 「不適合品率」改善はどこから始める? すぐにできて効果が大きいポイントとは -
製品資料
[株式会社スタディスト] 食品ロスを利益に変える「現場標準化」のすすめ -
技術文書・技術解説
[株式会社スタディスト] チョコ停・ドカ停を防ぐ「事前対策」の進め方
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
いまIBM iエンジニアが直面する「5つの技術的課題」とその解決策
-
2
SAPの負荷増に苦しむZeissが「リアルタイム分析」「安定運用」を両立させた道
-
3
なぜ「Claude Code」拡張は消しても危ないのか? Cursorで不正版配信
-
4
Microsoft 365侵害企業の9割はMFA導入済み 1002人調査で見えた盲点
-
5
【基本情報技術者試験】データ消失リスクを防ぐ3つの「バックアップ手法」を比較
-
6
なぜMicrosoftは「Rust」を標準言語に? AIで進むC/C++書き換えの課題
-
7
8割がアナログに逆戻りする“やっぱりな理由” DXを阻む2つの落とし穴
-
8
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
9
脱VMwareの真実:データセンター大手がNutanixを選んだ「コスト以上の理由」
-
10
“クラウド安全神話”の崩壊 AWS、Azure障害で情シスが直面した「SLAの死角」
ホワイトペーパーランキング PR
-
1
「IT史に名を残すシステム障害」8選
-
2
顧客対応自動化の要点:RAGとデータ連携で“業務で使える生成AI”にする方法
-
3
侵入から横展開まで27秒の脅威にどう立ち向かう? 防御のカギがEDRの理由
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
マンガで解説:情シスの負担を減らす「MDRサービスのインシデント対応」の中身
-
6
有識者が語る、中堅中小企業に求められる最新のサイバーセキュリティ対策とは
-
7
10G回線の真価をフルに享受するには? 導入前にチェックしたいポイント
-
8
なぜAIは組織で定着しないのか? 全社展開を阻む「3つの壁」と突破のヒント
-
9
ランサムウェア攻撃“究極の対策”はこれだ
-
10
パスワードレスへの移行で失敗しないためには? 導入・運用上の注意点を解説
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー