データサイエンティスト

前に、ビッグデータで日本が敗戦する日を書いたとき、こんなブログを発見！


Data Scientist: a unicorn?
http://blog.treasure-data.com/post/29496343559/data-scientist-a-unicorn


そこに、データサイエンティストっていうのは、


Data Scientist (n.): Person who is better at statistics than any software engineer and better at software engineering than any statistician. [1]


なひとで、


How many software engineers do you know that understand what Student’s t-test means? How many statistician do you know who has heard of Dependency Injection?


ってある。
うぃりあむのいたずらは、大学は、教育心理系なので、もちろん、t検定は知っている。宿題につかってたぞ。
ＤＩも、まあまあ、しってる。Ｓ２フレームワークの仕事はやったことないけど・・

っていうことで、データサイエンティスト（＾＾；）
お～、なんか、ＳＥっていうより、かっちょいいかもお・・・

そこに

To be honest, I know a couple, but that’s a couple out of 100+ software engineers and statisticians that I know.

ってあるけど、自分のほかに、もうひとり知っている。
その人も、「大学は心理系」＋「お仕事でＤＩ」のパターン。

心理＆教育系は、データサイエンティストに向いているかも・・・

HBaseを読む（２）ビッグデータの夜明け、ＲＤＢの問題点

ＮＨＮカンファレンスでもらったHBaseの本を、ざっと斜め読みして、適当にまとめるシリーズ「HBaseを読む」の続きです。
ちゃんとした情報を知りたい人は、HBaseの本を見てください。

今回は、１．１、１．２章

---

■１章　HBaseの紹介
・なぜまた別のストレージアーキテクチャを扱う必要があるのか
　　→ＲＤＢＭＳ：いまでも有効
　　→このモデルがあまりうまくは適合しない、特定の課題もありそう

■１．１　ビッグデータの夜明け
・Ｈａｄｏｏｐ　数ペタバイトに及ぶデータを収集
　　→それ以上のデータを収集する必要性
　　　　　：機械学習などで、さらに増大
　　→これまで：すべての情報を保存するコスト効率のよい方法なし
　　　　　特定のデータソース無視してよかった
　　　　　→いまや、そういった企業は競争に敗れそう
　　　　　→期間全体にわたる数学モデルの構築：機会を失う
　　　　　　Ralph Kimball
　　　　　　　データ資産はバランスシート状の主要な構成要素
　　　　　　　２０世紀における既存の物理的な資産を置き換える
　　　　　　　データの価値が広く認識

・Ｇｏｏｇｌｅ，Ａｍａｚｏｎ：データの価値を理解
　　Ｇｏｏｇｌｅ：スケーラブルなストレージとデータ処理
　　　→Ｇｏｏｇｌｅの外部で、オープンソースのHadoop
　　　　　　HDFSとMapReduce

・Ｈａｄｏｏｐの強み
　　任意のあるいは半構造化された、あるいはまったく構造化されて
　　いないフォーマットのデータの保存
　　　　→データの解釈を分析の時点で決められる
　　既存のデータベースシステムを補完
　　　　無限データを保存
　　　　適切タイミングでデータ取り出し
　　　　巨大なファイルの保存やバッチ処理、ストリーミング型アクセス
　　　　　に最適化されている

・ユーザー：バッチでなく、ランダムアクセスも
　→構造化されたデータのランダムアクセス：ＤＢへクエリに慣れている
　　　ＲＤＢＭＳ：Ｃｏｄｄの１２のルール
　　　　　→非常に厳格な要求
　　　　　　大きな変化はない
　　　近年：列指向、あるいは大規模分散処理データベース

・列指向データベース
　　データを列でグループ化
　　　　ある列の値は非常に良く似た性質
　　　　　→行指向のレコード構造に比べて、圧縮しやすい
　　HBase:列指向データベースではなく
　　　　　列指向のフォーマットを利用しているだけ

・地球サイズのＷｅｂアプリケーション
　　例：Ｆａｃｅｂｏｏｋなど
　ある主要な産業界のそれほどＷｅｂを主体としない企業でも
　収集データの量は増加（以下に例）
　　　金融
　　　バイオセマンティックス
　　　スマートグリッド（ＯｐｅｎＰＤＣ）
　　　販売
　　　ゲノム学
　　　携帯電話、軍隊、環境問題
　数ペタバイトに及ぶデータを効率的に保存、更新
　　　→容易ではない。

---

■１．２　リレーショナルシステムの問題点

たとえば、HBaseのＵＲＬ短縮サービスHushのサービスを考える

・はじめ：ＬＡＭＰで実装
　　　データを正規化
　　　インデックス
　　　ストアドプロシジャ
　　　強い一貫性

・データ数増加：負荷増大
　　→読み出しを並列＝スレーブのＤＢサーバー追加

・そのつぎに
　　キャッシュの追加(Memcachedなど）
　　　→一貫性の保証失われつつある

・書き込みの負荷が厳しい場合
　　ＣＰＵ，メモリ、ディスクを強力に→スケールアップ
　　→コストかかる
　　→スレーブもマスタ同様強力にしないと

・アプリケーションに機能追加
　　ＳＱＬのＪＯＩＮ速度急速に低下
　　　　スキーマの非正規化
　　　　最もコストの高いクエリの事前マテリアライズ化
　　　　セカンダリインデックス：メンテナンス負荷
　　　　　　→主キーのみに
　　　　データをシャーディング
　　　　　　→運用上の悪夢

シャーディング
　　レコードを水平なパーティションに論理的に分割すること
　　シャードのやりなおし：時間かかる
　　→仮想シャード

多くの企業はＲＤＢＭＳを使ってうまくいっている
　　新しい製品の実装を始めるにあたって、
　　利用可能なあらゆる選択肢を持っておいたほうがいい

---

次回は１．３章から

ビッグデータで日本が敗戦する日

最近話題？の「とれじゃーでーた」について調べてみた。


Treasure Data
http://www.treasure-data.com/


アメリカにある、クラウドのデータウェアハウスの提供会社
（Ｈａｄｏｏｐベース）
・・・なんだけど、どうもそれだけでなく、解析用のツール
（Treasure Data Toolbelt）っていうのもあって、
それを使って、いろいろ操作できるようだ・・

---

日本のビッグデータのアプローチというと、富士通の場合、

富士通、ビッグデータ活用のためのクラウドサービスとキュレーション提供
http://news.mynavi.jp/news/2012/01/17/027/index.html


のように、ビッグデータのプラットフォームと解析サービス（キュレーション）
を提供している。

ちょっと古いけど、他社の動向についても


国内ベンダーの「ビッグデータ」動向--富士通、日立、NTTデータ
http://japan.zdnet.com/cio/sp_bigdata2011/35011587/


に載っているけど、高速バッチ処理とかそんなのも手がけているけど、
ビッグデータを最新のマーケティング理論（ベイズとか）で解析してやろう！
なんていう、やんちゃなことは、してないかんじ。

---

富士通の言う、キュレーションサービス(一般的な言葉で使うキュレーション
とは違う。ビッグデータの解析に限定した言葉として使っている）の場合、
１時間、２時間ごとに変化する市場に対して、的確に分析、アドバイスする
というわけには行かない。

リアルタイムとは言わないが、短時間にビッグデータ分析を行うには、その分析理論と、それを支えるツールがいる。
Treasure Data Toolbeltは見ていないけれど、どうも、それを支えるツールらしい。

---

つまり、基本的なツールは、Treasure Dataにはある。
ってことは、あとは理論になる。

何が売れている・・・なんていうのを、単純に見るＢＩツールなら、
そりゃ、理論はいらないが、多量な変数から、有益な関係を得るには、
ふつう、データマイニングになってくるわけで、

すぐに思い浮かぶのは、Ｊａｖａのデータマイニング（ＪＤＭ）の
５つのアルゴリズム操作

１）属性重要度・・出力変数を予測するときに、重要度となる属性をランク付けする。
２）相関ルール・・同時に起こるアイテムを考察し、関係を発見する。
３）クラスタリング・・類似したデータ点のクラスタを見つけ出す。
４）回帰・・入力属性にもとづいて、出力変数の値を予測する。
５）分類・・離散属性を列挙値のひとつに分類する。

JDMについて（１）より引用


だけど、現実的には、単純に相関ルールを出されても困るわけで、儲かるかどうかが
知りたい（判別したい）わけだから、ＳＶＭとかが中心になってくるのかもしれない


まあ、それはさておき、単純なＢＩツールで、よいわけはなくて、

ＢＩツールから仮説を出したんなら、それを検証するために、
共分散構造分析に掛けてみるとか、
逆にＢＩツールよりも有効な販売における「勝利の方程式」
を出してきたいのなら、
まあ、因子分析で因子をだすとか、クラスター調べてみるとかもあるけど、
最近は、ベイズだよねえ～
ってことになってくる。

---

いま、この辺の理論がちょっと整理されてないけど（＝ＢＩで止まっちゃってるけど）
このへんが、一気にかたづけば。。。

（といっても、Wekaでやらせようとすると、WekaはJavaで動くので、すぐにメモリー
　たらなくなるし、おそいし、Ｒは、共分散分析弱いし、Ｈａｄｏｏｐで共分散分析
　やってるやつは、まだいないし・・・）

ってことで、一気にかたづくには、時間がかかると思うけど、かりに誰かが片付けちゃえば、
あとは、その理論に従って、ツールを動かすだけになる。

---

このとき・・・だ、
理論をTreasure Data Toolbeltに落とす部分ができれば、
それこそ、Treasure Dataは、データをリアルタイムで処理する機能をワンストップで
提供できることになる。

ところが、日本のビッグデータは、プラットフォームと解析部分をサポートする
だけで、ノウハウをツール化する部分ができていない。


アメリカで、そのようなものができてきて、日本に売り込みに来たとき、
日本の企業は、それに対応するとしても・・ビッグデータをやっているのが
大企業だから、対応するのには時間がかかり、アメリカに席巻されてしまうだろう。

その日こそ、「ビッグデータで日本が敗戦する日」といえる。

それは、間近かもしれない。



Ｐ．Ｓ　
共分散分析ソフトのAmosが動くＳＰＳＳを買収しているＩＢＭは、
ＨａｄｏｏｐのＭａｐＲｅｄｕｃｅで動く共分散のオープンソースを出して
くれないんでしょうか？
出ると、マーケティングの世界で、一挙に便利だと思うんですけど・・