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

「ビッグデータプロジェクトを始めることになった」ら、具体的に何をするのか。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から体系的に理解し、具体的に実践していく方のためのナレッジアーカイブです。第1回目は、「ビッグデータとは何か」の基礎と、「ビッグデータ基盤の概要とメリット」を解説します。

[嶋内翔，Cloudera株式会社]

今回の主な内容

• はじめに
• 参考：Hadoopについて
• 第1章-1　「ビッグデータ」の定義
• 第1章-2　ビッグデータ基盤の「用途」
  • 第1章-2a　バッチ処理基盤
  • 第1章-2b　業務システムのバックエンドデータベース
  • 第1章-2c　データ分析基盤
  • 第1章-2d　データサイエンティスト用の基盤
• 参考：Clouderaのビッグデータ基盤について
• 第1章-3　「ビッグデータ基盤」の利点とは
• 第1章-4　「ビッグデータ基盤を成功させる」までの最初の考え方
• 次回予告

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

　もし、あなたがこのような業務命令を受けたら、どうしますか？ 「ビッグデータ」、昨今の流行ワードでは「機械学習」「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回目は、「ビッグデータプロジェクトを開始する前に確認しておくべき、事前知識」編として、ビッグデータおよびビッグデータ基盤の概要とその利点を解説します。

Hadoopについて

　Hadoopは今から10年前の2006年、オープンソースの検索ライブラリの開発者であった米Cloudera チーフアーキテクトのダグ・カッティング氏が開発した、一般的なIAサーバを並べるだけでスケールアウトできる分散処理基盤です。Hadoopが持つ分散ストレージ／分散ファイルシステム「HDFS（Hadoop Distributed File System）」と、分散バッチ処理である「MapReduce」の強力な機能は、インターネットの急速な普及によるデータ量の爆発的増加に伴う「ストレージのコスト増」「バッチ処理の遅延」に悩まされていた世界中の企業に次々に受け入れられていきました。安価に大量のデータを扱う時代、すなわちビッグデータ時代の幕開けとなりました。

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

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

　「コモディティ」サーバとは、特定のベンダーに依存せずに調達できるサーバのことです。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を超えるサイズ／量のデータ」とすることにしましょう。

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