ここから本文です

もし、あなたが「“ビッグデータプロジェクト”を任せる。何とかするように」と言われたら

@IT 8月26日(金)7時10分配信

 「わが社でもこれからビッグデータに力を入れていくことにした。キミ、ちょっとやってくれないか」──。

【その他の画像】ビッグデータ基盤構築の道筋

 もし、あなたがこのような業務命令を受けたら、どうしますか? 「ビッグデータ」、昨今の流行ワードでは「機械学習」「IoT(Internet of Things)」「AI/人工知能」といった単語も並べられて、「自社のビジネス成長に必要なんだ。だから、やってくれ」と言われたところで、何をどう始めたらいいのか……と途方に暮れてしまうことでしょう。

 Web検索で少し調査をすれば、ビッグデータを活用した華々しい成功事例がいくつも見つかります。「顧客への商品リコメンド機能の最適化」「さまざまな不正の予測検知」といった事例は枚挙にいとまがありません。しかし、それをどのようにして成功させたのか、といった「過程」の情報はほとんど書かれていません。

 IT担当者ならば、ビッグデータ関連技術の書籍や文献などでも情報を探ろうとするでしょう。しかし、技術の概念やツール/ソフトウェアの使い方についての情報は詳細に説明されているものの、「具体的に、どのようにプロジェクトを進めていくのか」の情報は少ないようです。「Getting Started」といったチュートリアルは書かれていても、そのチュートリアルから先へ進む具体的な方法はうまく見つかりません。

 「チュートリアルから“先”へ行くには、具体的に何をすればいいのか?」

 本連載は、この疑問を解決するために展開します。「ビッグデータプロジェクトを実務として担当するエンジニアやIT部門」を対象に、ビッグデータの概要から、「PoC(Proof of Concept:導入前実機検証)(*1)」の進め方、本番稼働に向けた具体的な作業手順、ビッグデータ基盤における「マルチテナント環境の構築方法」や「第2、第3のプロジェクト」の進め方を解説していきます。なお、主な対象はエンジニアやIT部門の方ですが、ビッグデータプロジェクトを進めていく課程では、必然的にビジネス視点で考えるべきことも多くあります。そのため、併せて業務部門や経営層の方も参考にできる内容にもなっています。

*1:PoC:新規システムの本番導入に先駆けて、小規模なシステムを試験的に導入し、ビジネスにおける有効性を調査・検証することです。フィージビリティスタディなどともいわれます

 本連載におけるビッグデータ基盤の説明には、業界標準であるオープンソースの分散処理基盤である「Apache Hadoop(以下、Hadoop。とりわけ、Clouderaが提供する「Cloudera Enterprise」)を用いますが、考え方そのものは基盤に依存することなく共通なので、Hadoopではない他の基盤を使っていても活用できることでしょう。

 第1回目は、「ビッグデータプロジェクトを開始する前に確認しておくべき、事前知識」編として、ビッグデータおよびビッグデータ基盤の概要とその利点を解説します。

●本連載における「ビッグデータ」の定義

 「ビッグデータ」については、実は厳密な定義が存在せず、その概念の解釈には諸説あります。そこで本稿では、「単一のコモディティサーバで処理できない量のデータ」をビッグデータとして話を進めることにします。

 「コモディティ」サーバとは、特定のベンダーに依存せずに調達できるサーバのことです。2016年現在は、「IAサーバ」とほぼ同義として差し支えありません。「処理」とは、システムが行うデータの蓄積処理と計算処理の全てを指します。

 「計算処理」とは、どのような処理なのでしょう。かつてHadoopはバッチ処理しかできなかったために、ここでいう計算処理は「バッチ処理」とほぼ同義でした。しかし、2016年現在では「Apache Impala(incubating)(以下、Impala)」による双方向/対話的な分析や、「Apache Spark(以下、Spark)」による機械学習やストリーム処理、「Apache Solr(以下、Solr)」による全文検索など、ビッグデータはさまざまな形で取り扱われるようになってきました。

 では、単一のコモディティサーバはどのくらいの量のデータを処理できるのでしょうか。2016年現在、比較的安価に調達できる、「20コアのCPU、256GBのメモリ、ストレージ36TB(HDD 3TB×12個)」といった仕様のコモディティサーバを例に考えてみます。このサーバには、約36TB分のデータを格納できます。ミラーリングなどで冗長化するならば、約18TBほどとなります。これを勘案すると、このシステムでは筆者の経験上、多少時間はかかるものの「5TB程度のデータのバッチ処理」ならば実行できます(*2)。しかし同時に、オンメモリでの機械学習処理などを行うならば、その処理量はせいぜい「200GBぐらいが限度」になります。

*2:出力結果や中間データの格納領域も考慮しなければならないため、18TBを全て入力データとすることはできません。5TBという数値はあくまで参考値であることにご注意ください

 前置きが長くなりましたが、本連載における「ビッグデータ」は、「保存用途ならば18TB、バッチ処理ならば5TB、オンメモリ処理ならば200GBを超えるサイズ/量のデータ」とすることにしましょう。

●ビッグデータ基盤の用途

 ビッグデータ基盤とは、その名の通りビッグデータを扱う基盤です。多くの場合、コモディティサーバを複数並べた「分散処理の基盤」となります。ビッグデータを扱うプロジェクトには、当然ですがこのビッグデータ基盤が不可欠です。

 ビッグデータ基盤の構成要素は、大きく分けて「ストレージ」「リソース管理」「アプリケーション」の3種類です。そしてこれらは、「分散したシステム」として稼働させます。ビッグデータ基盤は、大きく分けて以下の4つの活用用途があります。

ビッグデータ基盤の用途

・(1)バッチ処理基盤として
・(2)業務システムのバックエンドデータベースとして
・(3)データ分析基盤として
・(4)データサイエンティスト用の基盤として

(1)バッチ処理基盤

 バッチ処理基盤としての典型的な利用例は、データの整形やクレンジングなどのいわゆる「ETL(Extract/Transform/Load:抽出、変換、ロード)処理」や、日次データの集計などの「ビジネスレポートの作成」、そして「機械学習のモデリング」などでしょう。

 ここ数年、クラウド上でHadoopを利用できるサービスが普及してきています。その大半はこうしたバッチ処理の基盤としての利用を想定しています。

(2)業務システムのバックエンドデータベース

 業務システムのバックエンドデータベースとしての利用例は、IoTシステムにおける「リアルタイム異常検知」や、ECサイトにおける「リアルタイムリコメンドのための基盤」などです。

(3)データ分析基盤

 データ分析基盤としての利用例は、大規模データに特化したBI(Business Intelligence)のためのバックエンドデータベースでしょう。

 例えば今日のHadoopでは、ImpalaなどのインタラクティブSQLエンジンを活用することで、BIツールに直接接続してSQLを発行しても高速に動作させることが可能になっています。

(4)データサイエンティスト用の基盤

 データサイエンティスト向けの基盤は少し特殊です。データサイエンティストは、社内で活用可能なあらゆるデータにアクセスし、それらを試行錯誤して分析して、ビジネスの知見を見つけ出すスペシャリストです。従って、アドホックなクエリを流すこともあれば、バッチ処理を行うこともあり、その行動や活用手段はさまざまです。彼らが自由にデータを扱い、知見を得られるようにするために必要な基盤を用意してあげる必要があります。

 もっとも、1つの基盤=1つの用途と絞る必要はありません。むしろ、複数の用途を1つの基盤で行う=マルチテナント環境にすることによって、コストメリットが出てきます。これがビッグデータ活用の価値となります。

 ただし、このように幾つかの用途が相乗りするマルチテナント環境となると、リソースの分離やセキュリティなどの課題も発生してきます。こういった課題をどのように解決するかは、連載の後半で説明する予定です。活用例の詳細は、筆者の執筆した記事「Hadoopの使い方のまとめ(2016年5月版)」もご覧ください。

(参考)Hadoopの使い方のまとめ(2016年5月版)(http://qiita.com/shiumachi/items/c3e609cb919a30e2ea05)



●参考:Clouderaのビッグデータ基盤について
 ビッグデータ基盤について、例えばClouderaでは、Hadoopを中心としたOSSコンポーネントに、管理ソフトウェアを追加したビッグデータ基盤として「Cloudera Enterprise」を用意しています。Cloudera Enterpriseでは、ストレージに「Apache HDFS」「Apache HBase」「Apache Kudu」、リソース管理に「Apache Hadoop YARN(Yet Another Resource Navigator)」を採用しています。

 アプリケーションは、ビッグデータを活用する用途別にさまざまなOSS(オープンソースソフトウェア)がそろっています。例えば、バッチ処理の「MapReduce」「Spark」、低レイテンシのSQLエンジンである「Impala」、全文検索エンジンの「Solr」、ストリーム処理の「Apache Spark Streaming(以下、Spark Streaming)」、機械学習の「Apache Spark MLlib(以下、MLlib)」などがこれに当たります。

 この他、外部連携用のツールとして「Apache Sqoop(以下、Sqoop)」「Apache Flume(以下、Flume)」「Apache Kafka(以下、Kafka)」、クラスタ管理ソフトウェアの「Cloudera Manager」、データ管理ソフトウェアの「Cloudera Navigator」、クラウド管理ソフトウェアの「Cloudera Director」を合わせて、ビッグデータ基盤を構成しています。

●ビッグデータ基盤の利点

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

 古くなったDWH(データウェアハウス)や、分析/レポート用RDBMS(リレーショナルデータベース管理システム)を更改するのではなく、それらもビッグデータ基盤に統合してしまえば、比較的簡単に大幅なコスト削減を実現できるでしょう。

 ビッグデータ基盤は、ほとんど活用しないけれど、業務上/コンプライアンス上の目的で捨てられないデータ(コールドデータ)を格納するのにも向いています。例えば、3年以上前のログファイルを全てDWH上に置いておくのは、リソースがもったいないと感じるでしょう。コストが掛かりすぎます。だからといってテープメディアなどにアーカイブする方法は、いざ必要になったときに迅速に対応できないといった課題が残ります。そこで、このようなコールドデータは、ビッグデータ基盤にアクティブアーカイブとして保管しておき、ファイルのフルスキャンで取り出せるようにするのです。利便性を損ねずにコスト削減を実現できます。

 そして最大のメリットは、「データが1カ所に集まることで、データの転送コストがなくなる」ことでしょう。従来のサイロ化したシステムに慣れていると、「データは、転送コストが掛かるものだ」という常識にとらわれがちですが、実はそうではありません。ビッグデータ基盤に集約してしまえば、そうしたコストも不要となります。

 具体的な例として、今まで転送時間を含めて1時間必要だった処理を「3分で終わらせる」ことができれば、いかがでしょう。単に処理速度が20倍速くなるだけではありません。データサイエンティストが試行錯誤できる回数を20倍増やせるいうことにもなります。つまり、新しい知見を得られる量が変わってくるのです。

 BI分析では、複数のデータセットを組み合わせて、新しいデータの活用/分析を繰り返します。例えば、自社製品サイトのPV(ページビュー)を集計するにしても、単にアクセス数を出すだけでなく、Webアクセスログとユーザーデータベースを組み合わせれば、「年齢別のセッション解析」「時間帯別のアクセス動向」などが行えるようになります。さらに、商品データベースとTwitterのツイート内容や投稿時間などのデータも組み合せれば、「製品ごとの評判分析」といったことも可能かもしれません。こうしてさまざまな視点で分析されたデータがあれば、「次はどうするか」の戦略を立てやすくなるのは言うまでもありません。

 こうして生成/分析されたデータによって、「さらに新しいデータの活用方法」も生み出されます。

 「商品の評判分析を共有ダッシュボードに載せて、チームや経営会議で共有する」「商品の評判分析を、顧客向けWebサイトにリアルタイム表示する」などです。このようなサイクルが回ると、新たなデータセットが追加されるたびに新しい活用方法が次々と生まれるようになります。データサイエンティストは、さまざまなデータセットを組み合わせて分析できるようになることで、はじめて「データから、ビジネス躍進のための知見を得る」ために試行錯誤していけるようになります。

 データ分析の観点で考えた「データの集約の利点」については、こちらのブログ記事も参考にしてください。

(参考)データを一箇所に集めることでデータ活用の民主化が進んだ話(http://chezou.hatenablog.com/entry/2016/05/05/222046)

●「ビッグデータ基盤を成功させる」ために、最初に行うこと

 ビッグデータ基盤は、過去のシステムに比べると、大量のデータに対する費用対効果の高いシステムです。しかし、決して安価なシステムではありません。上層部を納得させて予算を獲得するちょっとしたコツがあります。「小さくても、確実な成功を収める」ことです。

 最初のプロジェクトでは、「Webアプリケーションのログ集計」に取り組むことを推奨します。Webアプリケーションのログをバッチ集計して、KPI(Key Performance Indicator:業績評価指標)を算出するのにHadoop上で高速化する手法は、既に多数の事例があるので、成果を見込めるからです。

 ログ集計の速報性を改善すれば、より鮮度のよい情報を提供できるようになります。つまり、経営層や社内の他のメンバーにビッグデータ基盤の効果を示すのに適する項目です。この最初のプロジェクトで成功を収め、次のプロジェクトの予算を獲得しましょう。

 最初のプロジェクトを成功させたからといって安心してはいけません。ビッグデータ基盤は初期投資がそれなりに発生するので、最初のプロジェクトだけではまだそれなりの費用対効果しか出ていないはずです。ですから重要なのは、第2、第3のプロジェクトへつなぐことです。

 従来のITシステムの考え方ならば、別のプロジェクトは当然別のシステムとして構築していたかもしれません。しかし、ビッグデータ基盤が既にあれば、この基盤に相乗りするだけでいいのです。既にある基盤へデータを格納し、もしリソースが足りなければ、その分のサーバを追加するだけでいい、という考え方ができます。インフラの構築コストも掛からないため、非常に費用対効果が高くなります。

 先ほどの例の続きで言うと、「WebアプリケーションのログをベースとしたBIツールを用いたダッシュボードを用意する」が第2プロジェクトの候補として推奨されます。このテーマならば、既に存在するデータやシステムをそのまま活用するだけなので、インフラの追加投資がほとんど必要ありません。

 この他のプロジェクトとしては、社内のデータベースからデータを新たにロードして「バッチ集計によるKPIの項目を増やす」なども取り掛かりやすいテーマです。新規のデータは増えますが、最初のプロジェクトからバッチ集計の仕組みにほとんど変更が必要ないことから、開発のコストを抑えることが可能です。このように、「同じデータに対して、異なるアプリケーションで」、あるいは「異なるデータに対して、同じアプリケーションで」といった形で新たなプロジェクトを増やしていくのがコツです(図2)。

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

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

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

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

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

最終更新:8月26日(金)7時10分

@IT