もし、あなたが「“ビッグデータプロジェクト”を任せる。何とかするように」と言われたら：「ビッグデータプロジェクト」の進め方（1）（3/3 ページ）

[嶋内翔，Cloudera株式会社]

ビッグデータ基盤の利点

　ビッグデータ基盤を導入するメリットは、まず「システム統合が容易になること」が挙げられます。

　古くなった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　ビッグデータ基盤構築の道筋の例

　「まずやること」をまとめます。最初に手掛けるプロジェクトを「2、3個ほど」リストアップし、それらを全て導入するまでを一連のゴールとする短期計画を立てます。ビッグデータ基盤の適用範囲は「少しづつ拡大できます」から、焦らずに1つ1つ確実に適用し、社内の味方を少しづつ増やしていきましょう。

「今回の主な内容」に戻る

次回予告：「最初の一歩」を踏み出す方法

　ここまでで、ビッグデータそのものと「ビッグデータ基盤の概要とメリット」の基礎が理解できたかと思います。

　次回より、いよいよビッグデータ基盤を作るための第一歩を踏み出していくことにします。次のステップとして、「1つの活用方法について概念実証（PoC）を行い、ビッグデータ基盤の導入の有効性を示す」までのノウハウをお届けする予定です。

筆者紹介

嶋内翔（しまうち しょう）

Cloudera株式会社所属。京都大学工学部卒業後、NECでエンタープライズOSSのSI支援業務に従事。2011年にClouderaの最初の日本人社員として入社。サポートエンジニアとして3年務めた後、セールスエンジニアとしてHadoopを中心としたビッグデータ基盤に関する豊富な経験を積む。監訳書に「Apache Sqoop クックブック」。