Revolution R Open
Revolution RのOpenSource版
Revolution Analytics社の商用版Rである、Revolution R。
本体は改良したRと、幾つかのLibraryで構成されている。
その、改良したRと、一部のLibraryを、"Revolution R Open"という名称で公開してくれている。
以前はLinuxとWindows用Binaryしか提供されていなかったのだが、ちゃんとMacOSX用Binaryも提供されている(!) というわけで、おうちの手元環境はこちらに入れ替え。
DLはこちら。
拡張の詳細
ヨサゲな点など
特徴は、(1)Intel Math Kernel Library(MKL)とリンクをしている点、(2)Reproducible R Toolkitという仕組みを導入しているという点。
MKLのおかげで、BLAS/LAPACKに依存している部分を、multi threadで並列化が行えるため、お手軽に高速化が行える様に。
また、このReproducible R Toolkitというのは、要はpackageのVersion管理を行い、Rのコードのポータビリティをあげるというもの。要は、CRANのTime Machineみたいな仕組み。
これを実現するために、日次でCRANのSnapShotを取得しており、checkpoint()という仕組みで、ある任意のその日のLibraryを呼び出せるようになっている。これにより、packageのversionに依存せずに、Rのコードの移植性を保証している。
彼らが立ち上げているcheckpoint serverは、MRAN(Managed R archived network)というらしい。
大規模データのマイニング/ "Mining of Massive Datasets"
- 作者: Anand Rajaraman,Jeffrey David Ullman,岩野和生,浦本直彦
- 出版社/メーカー: 共立出版
- 発売日: 2014/07/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
邦訳が出るようで。広く俯瞰するという意味で、分かりやすい本です。
目次
目次を見てみると、以下の10章以降は邦訳には含まれていないようなのでご留意を。
10 Mining Social-Network Graphs
11 Dimensionality Reduction
12 Large-Scale Machine Learning
階層Tree構造のRDBでの表現について。
計算済のItem間距離のデータを元に、Itemから近傍Itemを返すことをしたいわけですが。 実務的な制約もありRDB構造で表現できる方法はないかとちょっと検討。
階層型クラスタリングを行い、その近傍を返す仕組みをRDBで表現できないものかと思ってみたり。(こんな時のためのGraphDBかもしれませんが。)
先人の知恵
みんな同じような課題に直面するよね。
Tree表現の整理*1
- (1)Hierarchical/Recursive SQL extensions
- (2)Tree encodings
- (2-1)Materialized Path
- (2-2)Nested Sets
(1) Hierarchical/Recursive SQL extensions
ノードのリンク構造をそのまま表現し、探索をする方法。素直ながら効率は悪い。
実際の用途ではItemから検索をしていくので、下層のNodeから、そのNodeが所属する上位Nodeに所属するNodeを参照するLookup tableを予め用意しておけば、実行時の計算を軽減できるかもしれないけれど、やっぱり効率は悪そう。
(2-1) Materialized Path
Path文字列表現にてTree構造を表現する方法。
PostgreSQLあたりなら、こういうのとか使えるかも。Path表現を行いLtreeで探索。
(2-2) Nested Sets
概要としては、こういうのとか。
入れ子集合モデル(Nested Sets MODEL)という、木構造を集合として扱う方法。
なんとスマートな。しかし驚きなのが、この木構造を集合として扱うこの方法自体は、元々はThe Art of Computer Programmingで紹介されているとのこと(!)。 Knuth先生、パナい。*2
Nested Setsの問題点
- ノードの追加に弱い
- あるノードを含むintervalをみつけるのが難しい
"Nested Intervals Tree Encoding in SQL"
- Tropashko, V. 2005. Nested intervals tree encoding in SQL. 34, 2 (Jun. 2005), 47–52.(http://sigmod.acm.org/publications/sigmod-record/0506/p47-article-tropashko.pdf)
上記を解決する方法。有理数で表現。
時間が取れたら読む。
SQLiteのコードリーディングとか。
社内の若手(20代)のエンジニアと話をしていたら、マジメにソフトウェアのお勉強をしたい、とのこと。
色々とオススメしつつ、実装を読んでみると得るもの多いよとかいうお話ついでに、「RDBMSの実装を読んでみたら?」と無責任サジェスチョン(!)。
ちょうど探索アルゴリズムがという話が出たり、彼はDB周りにからむことも多そうなので、RDBMSのコードならOSに近いlayerも見えるし、B-treeとかlogicも分かるし、SQLの言語処理系も見えるしと、幅も広いし実用的だし、役に立ちやすいという意味でも良いかな、と。..
さて、お勉強という用途なら何が良いかな、、とさくっと探してみて、SQLiteあたりなら、量も現実的だし、ドキュメントもコード内のコメントも比較的キレイにまとまっていたので、薦めてみる。:)
テスト用のコード
ちなみに、SQLiteはテストコードが本体より長い、それくらいQualityに気をつかっているんだよーという話はさくっときいたことあったのだけれど、、、
As of version 3.8.0, the SQLite library consists of approximately 84.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1084 times as much test code and test scripts - 91452.5 KSLOC.
「長い」というか、1000倍だった。
分析者としてのプロフェッショナリズムを突き通したら、不遇になったという話。
1行でまとめると、上司の意向に会わない分析結果を出したら、フルボッコされた、というだけの話なのだけれども。
むかし、あるカタカナ系の金融機関の、法人営業本部で分析者をしていた頃のお話。 当時の部署も、そもそもラインも、いわゆるリーマンショックでぶっ飛んでいるので、関係者もいるようでいないので、うん、まぁ。
当時は、銀行や証券会社をお客さんとしたホールセールの統括部門で分析をやっていた関係で、ありとあらゆるオペレーションにまつわる分析をしていたり。
現場側での分析者ならではの面白い経験もできて、新らしい金融商品がローンチしたばかりの時なんかはホールセラーの数が足りないので、午前中はRでプログラムを書いて分析しつつも、そのまま午後は銀行の本部で銀行員を相手に新商品の説明をする、とか。（数字を握っていない営業は楽しいね。）
外国人役員が「データで判断」という方針を明確に打ち出してくれていたおかげで、分析を出来る対象は広く、例えば、営業の行動履歴データや経費データから最適な営業活動パターンの発見、大規模プロモーションのROI計測、地域別の投信残高と競合金融機関からポテンシャルを割り出したり、Expense、Budgetの両面での予算案策定、さらには日本中にいる営業の人員配置案までまで。（たまに、分析の過程で、営業部の不正経理を発見もしてしまったり。オペレーションのExpenseデータはいろいろ見えるのだ。）
一方で営業企画とかの中での位置付けゆえに、日々の仕事で笑顔が無くなるくらいしんどいことが8割くらいなだけれども、一方で何が楽しいって、分析結果が組織に対して直接的な影響があるというインパクトの大きさ。 まれにある、金融機関との交渉のための資料といったようなかなりセンシティブな分析なんかだと、提出物はたったパワポ2枚だけれども、でもそれが外部との交渉において重要な材料となるという、この1枚、数字1つに込められた重圧感の裏返しの楽しさ。 数字は言霊として一人歩きをして、そして意思決定を変化させていく。
そんな一方で、意思決定に直結している故に、「色を付ける」という「圧力」がかかる。 つまり「過去の意思決定を正当化するための材料としての分析」。
大々的なプロモーションのROIがプラスである結果を求められる分析結果とか、分析の本来の価値を考えたら分析ではない。 レポーティングが絶対の外資、特に金融において、上司のマーケティング施策がマイナスなんて出せない。 絶対に出せない。 申し訳なさそうに出してみても、暗にやり直し。
分析者なら誰もがもつ、それに対して抵抗したい気持ちの表現として、そういう類いの分析という名目のレポートでは、あえて表紙に自分の名前を入れなかった。 ちゃんとやった分析結果は、もちろんしっかりと名前を入れてクレジットを明確にするけれど、そんな結果ありきのレポートには名前を入れたくない。というか、内容に責任を取れないから。後は知らん。
でも、一度だけ大きな抵抗をしたことがある。
人員配置の最適化をもとに、新しい配置人数案を作る、というオーダー。 しかし、予定調和を求められた。 「Aエリアに人材を増強したい」という、意向アリキの分析。 一方で「Bエリアの営業部はダメだから、人をはがしたい」というような意向。
でも本当の分析の結果は、、、、 Bエリアは合計のセールス金額は比較的劣るが、実はホールセラーあたりの生産性は非常に高い状態。地方で移動時間がかかるということ、そしてただの思い込みから、Bエリアは過小に評価されているだけなのだ。 意向と逆に、むしろ、Bエリアにこそ人を配置するべきなのだ。 少なくとも、人をはがすべきではない。
全国のエリアの営業同行も多々していたので、Bエリアの営業部隊が本部から評価されないながらもモチベーション高く頑張っているのも知っていて（本部の評価がおかしいという直訴も個人的にはされており）、彼ら彼女らの顔を思い出すと、今回ばかりは、そんなレポート出せないな、と。
今日中と言われるも、本来の結果を出したら、受け取ってもらえない。むしろ、話を聞いているのかと怒られる。。はてはて。
…というわけで苦肉の策として。。。。 まず、逃げ回る。上司の視界から逃げる。 で、当日中だけれども出さない。 ダメ社員。
で、、、 上司が帰った後の深夜に、上司、さらに上のえらい人を相手に、「本日中に結果を送れなくて申し訳ございません、 今までかかってしまいました。 朝に間に合うようにレビュー前ですが、人員最適化の計算結果です。」と、さくっとメール。
…次の日は、もちろん、フルボッコ。
直属の上司から人の話を聞いていないことを怒られ、その上からは「おまえのせいで営業戦略がめちゃめちゃなった」まで言われ、でもその上はレポートには満足しているものの、勤怠管理の厳しい金融機関ということで「なんていう時間まで残っているんだ」と予想外の方向から怒られ、あげくたまたまトイレで横に並んだ外国人役員から「働き過ぎは、ヨクナイですねー」と、カタコト日本語で遠回しに注意される、という。
何で、直属上司から役員以下まで、ありとあらゆる角度で怒られてるんだ、オレ、みたいな。
んでもね、ちゃんと、自分の名前入りでレポートを出すくらいの責任感もあり、誰にも言ってないからBエリアの営業部から感謝をされるわけでもなく、立場的にも直属らへんからの風当たりはきつくなったりも。
今、もしもあの当時になったら、、どうするのかなー?
追記：
- 直属グループ内だとこういうことがありながらも、それより上の、本部長、役員クラスは、常に客観的なデータを知りたがるわけです。 途中から役員直下レポーティングになったのですが、実際、そうしたらかなりやりやすくなったのでした。
- 本部長以上に対しても良かれというつもりながらも、勤怠という斜め右上から刺されて、切ない、というのがオチです。
- ちなみに大モメしたわけでもないので、元部長から元役員まで、今でも飲みに行ったりする関係ですよ。基本、円満なので。
