もし、あなたが「“ビッグデータプロジェクト”を任せる。何とかするように」と言われたら:「ビッグデータプロジェクト」の進め方(1)(3/3 ページ)
「ビッグデータプロジェクトを始めることになった」ら、具体的に何をするのか。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点/ビジネス視点の両面から体系的に理解し、具体的に実践していく方のためのナレッジアーカイブです。第1回目は、「ビッグデータとは何か」の基礎と、「ビッグデータ基盤の概要とメリット」を解説します。
ビッグデータ基盤の利点
ビッグデータ基盤を導入するメリットは、まず「システム統合が容易になること」が挙げられます。
古くなったDWH(データウェアハウス)や、分析/レポート用RDBMS(リレーショナルデータベース管理システム)を更改するのではなく、それらもビッグデータ基盤に統合してしまえば、比較的簡単に大幅なコスト削減を実現できるでしょう。
ビッグデータ基盤は、ほとんど活用しないけれど、業務上/コンプライアンス上の目的で捨てられないデータ(コールドデータ)を格納するのにも向いています。例えば、3年以上前のログファイルを全てDWH上に置いておくのは、リソースがもったいないと感じるでしょう。コストが掛かりすぎます。だからといってテープメディアなどにアーカイブする方法は、いざ必要になったときに迅速に対応できないといった課題が残ります。そこで、このようなコールドデータは、ビッグデータ基盤にアクティブアーカイブとして保管しておき、ファイルのフルスキャンで取り出せるようにするのです。利便性を損ねずにコスト削減を実現できます。
そして最大のメリットは、「データが1カ所に集まることで、データの転送コストがなくなる」ことでしょう。従来のサイロ化したシステムに慣れていると、「データは、転送コストが掛かるものだ」という常識にとらわれがちですが、実はそうではありません。ビッグデータ基盤に集約してしまえば、そうしたコストも不要となります。
具体的な例として、今まで転送時間を含めて1時間必要だった処理を「3分で終わらせる」ことができれば、いかがでしょう。単に処理速度が20倍速くなるだけではありません。データサイエンティストが試行錯誤できる回数を20倍増やせるいうことにもなります。つまり、新しい知見を得られる量が変わってくるのです。
BI分析では、複数のデータセットを組み合わせて、新しいデータの活用/分析を繰り返します。例えば、自社製品サイトのPV(ページビュー)を集計するにしても、単にアクセス数を出すだけでなく、Webアクセスログとユーザーデータベースを組み合わせれば、「年齢別のセッション解析」「時間帯別のアクセス動向」などが行えるようになります。さらに、商品データベースとTwitterのツイート内容や投稿時間などのデータも組み合せれば、「製品ごとの評判分析」といったことも可能かもしれません。こうしてさまざまな視点で分析されたデータがあれば、「次はどうするか」の戦略を立てやすくなるのは言うまでもありません。
こうして生成/分析されたデータによって、「さらに新しいデータの活用方法」も生み出されます。
「商品の評判分析を共有ダッシュボードに載せて、チームや経営会議で共有する」「商品の評判分析を、顧客向けWebサイトにリアルタイム表示する」などです。このようなサイクルが回ると、新たなデータセットが追加されるたびに新しい活用方法が次々と生まれるようになります。データサイエンティストは、さまざまなデータセットを組み合わせて分析できるようになることで、はじめて「データから、ビジネス躍進のための知見を得る」ために試行錯誤していけるようになります。
データ分析の観点で考えた「データの集約の利点」については、こちらのブログ記事も参考にしてください。
「ビッグデータ基盤を成功させる」ために、最初に行うこと
ビッグデータ基盤は、過去のシステムに比べると、大量のデータに対する費用対効果の高いシステムです。しかし、決して安価なシステムではありません。上層部を納得させて予算を獲得するちょっとしたコツがあります。「小さくても、確実な成功を収める」ことです。
最初のプロジェクトでは、「Webアプリケーションのログ集計」に取り組むことを推奨します。Webアプリケーションのログをバッチ集計して、KPI(Key Performance Indicator:業績評価指標)を算出するのにHadoop上で高速化する手法は、既に多数の事例があるので、成果を見込めるからです。
ログ集計の速報性を改善すれば、より鮮度のよい情報を提供できるようになります。つまり、経営層や社内の他のメンバーにビッグデータ基盤の効果を示すのに適する項目です。この最初のプロジェクトで成功を収め、次のプロジェクトの予算を獲得しましょう。
最初のプロジェクトを成功させたからといって安心してはいけません。ビッグデータ基盤は初期投資がそれなりに発生するので、最初のプロジェクトだけではまだそれなりの費用対効果しか出ていないはずです。ですから重要なのは、第2、第3のプロジェクトへつなぐことです。
従来のITシステムの考え方ならば、別のプロジェクトは当然別のシステムとして構築していたかもしれません。しかし、ビッグデータ基盤が既にあれば、この基盤に相乗りするだけでいいのです。既にある基盤へデータを格納し、もしリソースが足りなければ、その分のサーバを追加するだけでいい、という考え方ができます。インフラの構築コストも掛からないため、非常に費用対効果が高くなります。
先ほどの例の続きで言うと、「WebアプリケーションのログをベースとしたBIツールを用いたダッシュボードを用意する」が第2プロジェクトの候補として推奨されます。このテーマならば、既に存在するデータやシステムをそのまま活用するだけなので、インフラの追加投資がほとんど必要ありません。
この他のプロジェクトとしては、社内のデータベースからデータを新たにロードして「バッチ集計によるKPIの項目を増やす」なども取り掛かりやすいテーマです。新規のデータは増えますが、最初のプロジェクトからバッチ集計の仕組みにほとんど変更が必要ないことから、開発のコストを抑えることが可能です。このように、「同じデータに対して、異なるアプリケーションで」、あるいは「異なるデータに対して、同じアプリケーションで」といった形で新たなプロジェクトを増やしていくのがコツです(図2)。
「まずやること」をまとめます。最初に手掛けるプロジェクトを「2、3個ほど」リストアップし、それらを全て導入するまでを一連のゴールとする短期計画を立てます。ビッグデータ基盤の適用範囲は「少しづつ拡大できます」から、焦らずに1つ1つ確実に適用し、社内の味方を少しづつ増やしていきましょう。
次回予告:「最初の一歩」を踏み出す方法
ここまでで、ビッグデータそのものと「ビッグデータ基盤の概要とメリット」の基礎が理解できたかと思います。
次回より、いよいよビッグデータ基盤を作るための第一歩を踏み出していくことにします。次のステップとして、「1つの活用方法について概念実証(PoC)を行い、ビッグデータ基盤の導入の有効性を示す」までのノウハウをお届けする予定です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ビジネスアナリティクス、機械学習の進化とSASの新アーキテクチャ
統計解析、予測分析でリーダー的存在の米SASが、同社製品群の大部分を新アーキテクチャに移行すると、2016年4月に発表した。これを、ビジネスアナリティクスの世界全般における動向との関連で探る。 - Sparkのエンタープライズ対応が「成熟」――Clouderaが宣言
HadoopディストリビューターもあらためてSparkへの注力をアピール。既に800ノード超のSparkクラスターを運用するユーザーも存在するという。 - Hadoop用リアルタイムクエリエンジン Impalaのポテンシャルをレビューした
2012年10月24日に発表されたばかりのHadoop用リアルタイムクエリエンジンをいち早くレビュー。次期CDHに組み込まれる予定の新機能をどう使いこなす? - Hadoop用クエリエンジン「Impala」がついに一般公開に
「Hiveの10倍速い」クエリエンジンが一般公開に。最新の列指向データフォーマットなどにも対応している。