情報処理学会のIT実務を扱う論文誌「デジタルプラクティス」Vol.4, No.1 は、ビッグデータ特集号。会員登録をすれば、無料で電子版（PDF)を読むことができる。
この論文誌は、実システムでの経験・ノウハウの紹介・体系化をテーマに実務家向けに編集されており、今回の「ビッグデータに備える」特集号では、楽天のような BtoC ネットサービスや、金融・ヘルスケアといった BtoB ソリューションでのビッグデータ処理・分析の一端が紹介されるとともに、いくつかのビッグデータ処理のための分散処理ソフトウェア基盤についても知ることができる。
また IBM Smarter Planet と Zynga のオンライン・ソーシャルゲームでのビッグデータについて、IBM 東京基礎研究所 森本所長、ジンガジャパン 松原社長を招いて、東大・喜連川先生・近山先生が行っている議論も興味深い。
実践（プラクティス）という観点では、楽天と Zynga の例がコンシューマ相手に大規模なデータ処理を行い、それを実業でのマネタイズにつなげているので迫力がある。
一方、技術という観点ではどうだろうか。データ・インテンシブなこの分野はドメインやアプリケーションに依存する部分と非依存（独立）の部分との境界線が引きにくい。この号で紹介されているようなビッグデータ分析の事例の手法・知見が、さらに一般化されて他に適用できるのだろうか。自分たちの問題を解決するためには、どの手法とどの手法をどのように組み合わせればよいのだろうか。アプリケーション固有・ドメイン依存のやり方がまだまだ多い印象である。
分散処理としての MapReduce、および CEP（Complex Event Processing）のようなストリーム処理のように、いくつかの汎用的な計算モデル・手法はあるものの、それは基盤を提供するに過ぎず、その上でどのような処理を行うかは、かなりの部分、個別の問題・領域に依存すると感じる。せいぜい準備できるのは、プリミティブな手法のライブラリ化、その組み合わせのテンプレート化といったメニューを用意することではないだろうか。
ビッグデータ分析をビジネスとしていくならば、この領域依存の部分を組織的に共有化して、必要に応じて、再利用したり組み合わせたりできるフレームワークが求められると思う。そのためには、どんどん実際の問題に取り組んでみて、一歩づつノウハウを貯めていくしかない気がする。そうやって貯まった知見・ノウハウが本当にライブラリ化できるのか、あるいはテンプレートないしデザイン・パターンのようなものが作れるのか、僕にはまだよくわからない。
以下、主な論文について、簡単にメモをまとめた。
ビッグデータ応用
楽天におけるビッグデータの収集・解析基盤の構築（PDF）
- 数ある楽天サービスのユーザの属性・行動情報をまとめて扱う「楽天スーパーDB」
- サービスを横断した解析を可能とする。
- 多様なサービスからのログをリアルタイムに収集し、ストレージ・分散処理システムに渡す「グローバルイベント解析プラットフォーム」
技術的にそんなに大きな工夫がある訳ではないが、日々増加するビッグデータとの戦いの一端を見ることができる。
インタビュー：「ビッグデータが何をイネーブルするか？その本質を議論しよう」（PDF）
- IBM 東京基礎研究所 森本所長、ジンガ 松原社長を招いて、東大・喜連川先生・近山先生と一緒に、ビッグデータの現実・未来について議論する。
- IBM Smarter Planet
- データを集めて処理してアクションとして役立てる、その PDCA ループが Smarter xx
- 今後、各種 Smarter xx ドメインが横につながっていく。
- 計算量が爆発しないための、データの組み合わせが重要、目的やニーズに基づいたシナリオベースの分析になる。
- データのオーナーシップ、プライバシーが課題。
- オンライン・ソーシャルゲームに見るビッグデータ解析
- ゲームの至るところにデータ採取ポイントを埋め込んで分析。アイテム課金の機会を狙う。
- 次のステップはユーザ・プロファイリング
- ゲームを含むすべてのコンテンツにユーザの気持ちを煽る中毒性が必要。ガチャ（福引）のようなランダム性がアジア市場で好まれ、欧米では時間を短縮するためのアイテム課金の市場がある。
- データを提供しあうエコシステムが作れるか
- 個々の企業がデータを独占する時代になる可能性
- データを提供しあうインセンティブの必要性
- データの信頼性を提示する必要性
かたや BtoB、かたや BtoC とビジネスモデルは違うが、ビッグデータの先駆者である IBM と Zynga の事例は興味深い。
金融分野におけるビッグデータ分析（PDF）
- IBM による非構造化データ処理研究の事例紹介。
- ビッグデータ分析の主要技術を、テキスト解析・データマイニング・分散処理の3つに分類。自然言語のような非構造化データからの情報抽出・分析、それを従来からある構造化データ・数値データと組み合わせたアプローチについて、3つの事例で紹介する。
- Twitter 情報のキーワードマッチング
- 企業にかかわるトピックを Twitter から取り出し相関性を見る。
- Twitter 上は日々の生活に身近な情報が多いということで、B2B よりも B2C 企業に向いている。というのは、まぁ当たり前といえば当たり前の結論ではある。
- 経済指標の予測に報道情報の自然言語分析を利用した際の予測性能を評価
- 過去データから学習した統計モデルが、経済の専門家と同等の予測性能を持つ。
- 報道情報を用いたほうが誤差は下がる。その一方で予測パフォーマンスでは劣るという結果がでた。
- ニュース記事からのセンチメント表現（ポジティブ、ネガティブ）の抽出
- 大量のテキスト、分野非依存の辞書をもとに、分野に特化した表現(例：寄与する、底堅い、冷え込むなど）を抽出する。
- 情報量が大きければ語彙の獲得数は増えるが、正解率は下がる。
自然言語のような非構造データをどう扱うか、それを数値データと組み合わせるとどういう分析ができるかの研究。
ビッグデータ価値化への挑戦 薬剤副作用分析と航空機着陸システムの安全性設計から（PDF）
- NEC から二つの事例紹介。
- 重要性が強調されているのは、対象領域の専門家とデータ分析の専門家との密接な協働。互いのテリトリーまで踏み込んで活動する必要がある。
- レセプトデータ（診療報酬明細）からの薬剤副作用事象の検出
- 次世代航空機着陸システムにおいて、GPS信号の誤差・信頼性を推定
前の IBM の事例も、NEC の事例も、提案されている分析手法・問題解決法は、アプリケーションに依存すると思われる。こういうことを一つ一つ積み重ねていくしかないのかもしれない。
ビッグデータ処理ツール・ソフトウェア基盤
ビッグデータ時代のビジネス・インテリジェンス 〜 次世代ビジネス・インテリジェンス 〜（PDF）
- NTTデータが提唱する次世代のビッグデータ分析基盤の説明。
- 上記で構成されるビッグデータ分析基盤の技術を、必要に応じて連携させる。たとえば：
- 関係データベースはアドホックな集計、NoSQL はバッチ・ベースの集計
- リアルタイムのデータ処理は CEP(Complex Event Processing)、数時間前の時系列データ処理はインメモリDBやKVS、数日から数か月前のデータ処理は DWH アプライアンス、それ以上の時間をさかのぼる時は Hadoop(Map/Reduce)の並列分散処理
- 事例として取り上げたのは、橋梁の異常検知をリアルタイムに行うもの、およびクロスドメインのレコメンデーション。
商用サービス適用のための大規模分散処理システムの性能評価（PDF）
- NTT の分散 KVS の評価。
- YCSB(Yahoo! Cloud Serving Benchmark)が測定する単位時間当たりのリクエスト数、それに対する遅延、スケールアウト性能、可用性のほかに、商用サービスとしては、長時間運用の安定性、故障からの復旧、経済性といった性能評価が必要になる。
- Web検索システムをユースケースとして、長時間運用した際の性能低下、その原因となる分散ファイルの増加の抑制、故障によるフェイルオーバーでのスループット低下、サーバ数の抑制などを論じている。
大規模分散処理システムのソフトウェア試験とその実践（PDF）
- 上記 NTT の同じ分散 KVS システムを材料に、大規模分散処理システムのシステム品質検証について紹介する。
- スケールアウト性、耐障害性の観点から、障害許容性、回復性、資源効率性の視点が重要で、それに基づいて検証項目の抽出を行い、システム検証を実施した。
上記二つの論文において、大規模 KVS で有効な性能評価・試験を挙げており、Hadoop の大規模安定運用を考えている人には参考になると思われる。
大規模リアルタイム解析エンジン Jubatus の創り方（PDF）
トライ＆エラーを早く回すというと恰好はいいが、アドホックな設計・開発という印象は否めない。よく言えば若々しくて元気がある。しかしもう少し、本基盤ソフトがどのような応用に使われるのかを考えてから、設計・実装にとりかかってもよいのではないかと感じる。MapReduce の向こうを張る分散計算モデルの処理系を作りたかった、というのが本当のところなのではないか？応用の実装が先にあって、そこからの抽象化として基盤ソフトが設計されたという印象は受けない。
