エコノミスト誌「使える統計学」：ビッグデータを真面目に考える
数年前から「ビッグデータ」という言葉をよくきく。
Googleの影響が大きいことことに加え、Amazon Web Service(AWS)や、GFSやMapReduceのオープンソースソフトウェア（Apache Hadoop）といった実行環境が使えるものになってきて、「Googleが実現したことを身近に体験できる」環境になってきたことが、その一因だと思う。（データが幾何級数的に増えていく、という見出しも見かけるが、実現手段がみえてこなければ、流行はしないであろう）
そして、突然、『統計学は最強の学問である』がベストセラーとなり、『統計学』という学問が脚光を浴びた。
追記（2013/7/26) ; 7/18の読売新聞夕刊の一面に「JR東日本がSuica情報を売り出した」と出ていた。翌7/19の朝刊でも大きく２面で報じられた。ビッグデータの持つ意味について、シミュレーションを用いて解説記事「JR東日本がSuica情報を売り出したことと、Hadoop MapReduceの実力」を書きました。
応用統計学を修めているが、統計学がこれほど社会的な注目を浴びた記憶はない。機械学習分野（協調フィルタリング、クラスタリング、分類など）も同様に注目を浴びているが、これらも数学的、数値解析（アルゴリズム）的には、統計学でカバーされている分野や、それに近しいエリアである。
「そもそも統計学はビッグデータを扱わないために生まれたのではないか」という議論がある。
たしかに、無作為抽出という手段によって、計算可能なサイズの「適切な（ビッグデータの）代表選手」を抽出する、サンプルを得た母集団に対して分布を仮定して（モデリングして）それを検定する、パラメータを推定する、というのは、統計学の主要なアプローチである。
しかしながら、一方で強/弱大数の法則、漸近理論を発達させてきたのも統計学・確立の理論であるから、先の指摘は必ずしも適切とは思えない。
逆に、ビッグデータといっても、「加算有限の対象を扱うデータ分析」であって、先に述べたようなコンピュータの利用環境が整ってきたきたことに後押しされて、「サンプリング数の増加にコンピュータが耐えられるようになってきた（らしい）という捉え方」が適切なのではなかろうかと思う。
しかも、サンプリングサイズが大きくなることで、推定精度があがる、（漸近的な理論によって）モデルそのものを単純化できる可能性がある。これは、パラメータ推定や検定のエリアにとっては朗報である。個人的には、こちらの立場をとりたい。
こういった様々な変化に対して、統計学を修めてから20年以上もコンピュータを生業にしてきた者として「きっちり考えたい」と思って、しばらく前からビッグデータ関連をいろいろ試してきた。
しかしながら、メモやノートをまとめていくのは時間のかかる作業で、どうしても積んだままになってしまう。今からでも、まとめていかないと埋もれたままになってしまうので、連載形式のブログで書こうと思う。
2013/6/4号の「エコノミスト」誌に『使える統計学』という特集が組まれていたので、それを取っ掛かりとして、ストーリーを作っていこうと思う。エコノミストのような雑誌に掲載されるのであるから、よほど流行っているということだ。
特集記事では、Twitterのつぶやきから、景気動向指数を予測する、というAdhocな解析が取り上げられていた。
ブログは適当な長さに切って公開していくが、「在野の学者」として、以下のようなことに注意していきたいと思う。
- 抽象的な議論に終わらせずに、現実問題に即した視点をぶらさない。（工学的、実用的な立場）
- コンピュータ・統計学のいずれかにも過度に偏らない。（バランス）
- 現実視点とはいえ、アカデミックな部分についてはきちんと考察する。（理論家としての立場）
- Webよりも、学術論文や書籍の情報に重点をおく。（情報の正確性）
さて、「Hadoop」や「統計学」、「データサイエンス」という言葉は有名になったが、
- さて、これらを自分のビジネスにどう使っていくのか
- どんな困難なことが待ち受けているのか
- なぜ、データサイエンティストなどという職種が注目されているのか（そんなに特別な知識が必要なのか
と思っている方もたくさんいらっしゃるのではないかと思う。
たとえば、「エコノミスト」誌でも利用された、Apache Hadoopについての記事や書籍は比較的たくさんあるが、同じことを試みようとした場合、以下のような疑問（一部の表面的な疑問ではあるが）に突き当たり、これらを明らかにしなければ、記事をフォローすることすらできない。
エコノミスト誌では、「回帰分析」とだけ書かれているが、重回帰分析を行う計算には、密な行列の加算や乗算、転置、逆行列の算出といった「線形代数の基本演算」が含まれている。
これらの演算を、「MapReduceというパラダイムに落とすことができるのか？」という疑問がある。重回帰分析に限っていえば、初頭的な線形代数の知識によって説明と演算が可能である。
ただし、直感的にMapReduce（今後のログで紹介したいと思う）は限定的な演算に特化したパラダイムに思われ、これらの演算ができる保証がない。
パラレルコンピューティングも古くから数値解析の分野で扱われてきた（昔の限られた計算機の能力では、行列演算をどう行うかは、極めて切実かつ学問的な課題であった。この分野だけでまるまる１冊の本になる）。
これらを実装した場合に、どの程度のサイズのデータに対して、どの程度のコストと実行時間がかかるのか、ということも、ビジネス面で非常に興味があるところだと思う。
- 日本語の構文解析について。
Tweetから語句を拾うには、Tweet本文の構文解析（形態素解析）を行わなくてはならない。
Web検索の実装やテキストマイニングが盛んになってきたことを背景に、現時点でも、複数のオープンソースの形態素解析エンジンが利用できる。よく知られているように、Hadoopは、Lucene（全文検索エンジン）プロジェクトから派生している。Luceneは歴史のあるソフトウェアであるが、「単語の区切りにスペースがない」という日本語の特徴（中国語や韓国語もそうであろうが）が故に、テキストをマイニングする際には、「分かち書き」という品詞分解が行われるのが一般的である。このエリアにどのようなソフトウェアを、どのように配備したらいいかという課題がある。
- データのクレンジングについて。
記事の中にも「スパム」について軽く触れられているが、スパムをどうやって判断するのか、という問題である。実際に、Tweetを分析した経験では馬鹿にならないほど、多くのスパムが紛れ込む。これについても今後紹介していきたい。これは、学問的には機械学習（分類やクラスタリング）、統計学のエリアとなるだろう。
- サーバー構成について。
エコノミスト誌は経済誌であるから、演算を行うサーバー、ソフトウェアの配置（アーキテクチャ）については言及していない。
サーバーは、Hadoopの特性を考慮にいれ、適切に配置しなくてはならない。
先にも述べたが、ビッグデータという言葉がはやっている背景には、AWSを始めとするパブリッククラウド、ベンダーが提供するプライベートクラウドという実行基盤の整備が進んだことが存在している。
ブログではAWS（Amazon Web Service）を使っていきたいと思う（プライベートクラウドを使える立場にないため）。使い方についても、書籍などを参考にして、実際に確認できた内容を具体的に紹介していきたい。
また、ビッグデータというエリアで考えれば、複合イベント処理（CEP）といったエリア、ソフトウェア構成的には、NoSQL（Not Only SQL）といった話題もある。高速化の手段としてみれば、ノンブロッキングI/O、非同期I/Oなども含まれてくるかもしれない。
CEPはマイナーではあるが非常に興味深いエリアである。しかしながら、（NoSQLもそうなのだが）「道具立て（ソフトウェア）の利用ノウハウが中心的な話題」になると思われる。
ただし、ルールをバックエンドの（Hadoopから生成した）データと連携させるといった意味では、上の課題と無関係ではない。CEPとオンライン処理とは、レイテンシーの違いで区別されるが、オンライン処理でも同様の事が言える。これに対して、エコノミスト誌でも取り上げたHadoop MapReduceと、それをベースにした分析の殆どは、オンライン処理でなく、バッチ処理（もしくは、オンラインバッチ）である。
NoSQL分野では、Apache Cassandra, CouchDB, HBASEなど相当に充実している。（Google App Engineでも当初から採用されていたので、概要は古いログを参照ください。）
CEPのオープンソースには、JBOSSのDroolsしか見つけることができていないが、これらも話題に入れていきたいと思う。（いつになるか。。。）
長い連載になるように思われるが、これらの問題に対して、理論的な部分をフォローしつつ、コンピュータの道具立て（開発環境やクラウドの使い方）の説明や、実際のプログラムを行いつつ、具体的な実装とそれによる考察をおこなっていきたい。
間違いなどあったら是非、指摘をお願いしたい。
尚、普段は全然別の仕事をしている身のため、遅延など発生すると思うが、そこはご勘弁いただきたい。
