読者です 読者をやめる 読者になる 読者になる

once upon a time,

Iris Tradをビール片手に聞くのが好きなエンジニアが、機械学習やRubyにまつわる話を書きます

PDFの表をpandasのDataFrameにできる tabula-py 作った

python rubykaigi

RubyKaigiに参加するとコード書きたいという気持ちが高まって良いのですが、今回はPDFの表を読み込んで pandas の DataFrame に変換できる tabula-pyを作りました。 これをもってRubyKaigiの参加報告とさせていただければと思います。

tabula-pyとは

tabula というJavaで書かれたPDFから表を抽出するライブラリをPythonでうすーくラップしたものです。実装を見てもらえばわかると思いますが、本当にsubprocessでJavaのプログラムを叩いて標準出力で受け取るというだけしかやっていません。

もともとは、Rのtabula実装がかなり色々できるのを知ってPythonがないらしいというので作りました。Rの実装はマジでJavaをごりごり書いていて尊敬の念を抱いています。

tabulizerパッケージによるPDF表データからのデータ取得

github.com

使い方

インストールはpipで入ります。

pip install tabula-py

こんな感じで使えます。

from tabula import read_pdf_table

df = read_pdf_table("data.pdf")

詳細はnotebookを見てください。

RubyKaigiの成果と感想

  • rubyist.clubで@mirakuiさんをゲストに収録した
  • tabula-pyを作った
  • 個人的には、JulianのMIDIをdRubyで制御する話が一番おもしろかった。事前にまつださんに聞いていたからこそ辿りつけたのであった
  • daru周りは色々と頑張っているけど、visualization周りをどうするかが肝だろうなと思いながら作者と飲めたので良かった
  • 機械学習の話は個人的には、sklearnのモデルを読み込んでpredictするとかが良いのかなと思っているので、Apache Arrowとかfeatherとかみたいにinter-languageな方向を強化していくのがいいんじゃないかなと思いながら聞いていた

今後の展望

Py4jを使えばRと同じことができるのは確認ができたのですが、JavaPythonの上で書かされている感が半端無いので困ったら考えようと思います。

川崎Ruby会議 01を開催しました #kwsk01

Ruby regional

さる 8/20 に川崎Ruby会議01を開催しました。

regional.rubykaigi.org

川崎Ruby会議は、kawasaki.rbの主催する地域Ruby会議です。 ちゃんとしたまとめはるびまに出ると思うので、ここでは開催の経緯なんかを簡単に書こうと思います。

なお、発表内容が気になる方はタイムテーブルにあるスライドや動画へのリンクを見ると良いと思います。

togetter

きっかけは Ruby Kaigi 2015

  1. 日本酒が事実上無限に飲める会に参加したところ、咳さんに「次のregionalはやらないの」と言われ、基調講演者が決まればありかもと答える
  2. 翌日、miyagawaさんと飲んでるかくたにさんと話して、「2回以上続くregionalはやっぱり特定の地域コミュニティがやってるね」と言われる
  3. さらに翌朝、帰る直前のmameさんに会って「川崎のregionalやるとしたら、基調講演とかしていただけます?」「いいよ」と快諾いただく
  4. 次のミートアップで、kawasaki.rbのメンバーに「発表してみたい?やってみたい?」と聞いたら思いの外反応が良かった

というようにトントン拍子でした。

自分としては、やるならいつもの地域コミュニティの皆が話せる場をつくりたい、と思っていたので、これはこれで良かったです。

とにかく楽をする

神奈川の時はペアプロあり、パネルディスカッションありのもりもりだったのですが、今回は「できるだけ楽をする」ということに徹しました。 東京Ruby会議11はかなりの額を動かすのでかなり重い感じだったのと対象的に、我々は

  • 手間を掛けない*1
  • お金をかけない

という方式で行きました。

なので、どうしてもやりたい!という人が現れないかぎりは、「やれたら良いよね」はやらないという方針のもと進めてきました。

当初はサイトロゴもなしで行こうとしていました。スタッフTシャツも皆大好きミュートンTシャツで行こうとしていました。そしたら、ロゴを作るよと実行委員のぺらさんの奥さんが言ってくださり、更にはミュートンの可愛さが理解できないためかTシャツもデザインをしていただくという流れになりました。TMIXさまいつもありがとうございます!

正直、この方法はやる気のある人に負荷がかかってしまうというデメリットはあるものの、手を動かす人が一番推進力はあるかなとも思うので、悩ましいところです。

なお、ぺらさんの奥様経由で重要なリンクが届いているので共有させていただきますね。

川崎Ruby会議01のスタッフTシャツ、デザイン素敵です! #tmix #kwsk01

igaigaさん(@igaiga555)が投稿した写真 -

やってみた感想

コンセプトの「kwskバザー」は、多分なんのこっちゃわからんだろうなぁと思いながら提示しましたが、大江戸Ruby会議の「生活発表会」からヒントを得ました。 始めた3年前の当初からPythonの話もあり、ずっと「kawasaki.rbはkawasaki.pyなのでは!?」というご指摘をいただき続けてきたので、いつもどおりやっていれば多様性がでるだろうな、という思いもあり、それを全面に出してみました。

都内だと特定の言語でも人が集まるかもしれませんが、川崎まで来ると遠い人は来ないのとRalisやってる人口も相対的に都内より少ないので、地域に根ざしたテックコミュニティとしてやってきました。なので、C#Scala、はてはサーバーレスアーキテクチャの話が出てきたわけです。

実際にその多様性について、簡単にまとめたリストが以下になります。気になる方は是非スライドや動画で確認してみてください。

  • Rubyファミコンの仕様
  • C#C++/CLI
  • Scala
  • Rubyと思ったら猫動画
  • Rails
  • Railsから気がつけばPHPに変わっていたでござる
  • "Railsエンジニア"はただの枕詞のサーバーレス
  • Python
  • Elixer本の宣伝
  • 世界をまたにかける話
  • Rubyと思ったら数学の話で終わってしまったでござる

プログラミングElixir

プログラミングElixir

また、パーフェクトRubyの読書会も続けているためか、「Ruby初心者です」という方もちょこちょこ来ていただいています。kawasaki.rbがきっかけで今回発表された蓑島さんのように一人エンジニアの環境で独学で業務でコードを書くようになった人、転職した人、Herokuのイベントに登壇した人、Railsを学び始めて起業した人など様々な人がいるのも特徴です。 正直、Rubyにとても詳しい人には物足りない側面もあるのかもしれないとは思うのですが、asakusa.rbなどとはまた違った路線で来ているのかなと思っています。 「ここに来れば困ったことを質問できる」とか「ここに来れば自分の知見を気軽に発表できる」という場所を続けてきたかいがあって、今回のregionalにつながったのだと思います。

パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby (PERFECT SERIES 6)

個人的には、mameさんの発表中にも言われていた「最適化の心構え」のうち、

効果を検証せよ:実行平均時間の単純比較ではなく統計的検定とか使うといい。有意差がなかったら変更を捨てろ。

がとても印象的でした。普段検定というと限定された時にしか使われないという偏見があったのですが、ソフトウェア開発にも生きてくるというのは目から鱗が落ちました。

発表・参加いただいた皆様、どうもありがとうございました。そして、実行委員の皆様、本当に何もしない実行委員長でしたが全力でサポートいただきありがとうございました。

なお、明日はいつものkawasaki.rbを開催しますので、興味を持たれた方は是非ご参加ください :)

*1:Tokyuリスペクト

「夏真っ盛り!Spark + Python + Data Science祭り」を開催しました&Ibisを紹介しました #summerDS

2016/07/25に「夏真っ盛り!Spark + Python + Data Science祭り」を開催しました。

connpass.com

今回はClouderaに入って初めてのコミュニティイベントということでしたが、なんと400人を超える応募をいただいてとてもありがたい限りです。 会場をご提供いただいたDMM.comラボ様、発表いただいたサイバーエージェントの内藤さん、DMM.comラボの加嵜さん、LTの皆様ありがとうございました。

togetter.com

pandasを大規模データにつなぐIbis

www.slideshare.net

Ibisはpandasの作者でもある Wes McKinney(@wesmckinn) の作っているライブラリです。 ひとことで言うと、pandasのプログラマブルな処理を大規模データにもできるようにします。 大規模データは高速なSQLエンジンにまかせて、pandas likeなDSLでpandasと連携できるようにしており、データがTB以上のデータに対してもSQLを書かずに試行錯誤できます。

なお、日本語の情報はかなり少ないのですが*1、こちらのブログが参考になると思います。 もし、Impalaを試すのであればQuick Start VMか、Cloudera Directorを使うとブラウザでポチポチするだけでAWS, GCP, Azureに簡単にImpalaクラスターが立てれるのでおすすめです。Director導入方法はこちらが参考になります。

Ibisの詳細は資料を見ていただければと思いますが、いくつか補足をしたいと思います。

SQLじゃなくてプログラマブルなのは何が嬉しいの?

pandasをお使いの方はわかると思いますが、SQLに比べると試行錯誤がやりやすいと思います。例えば、SQLの途中結果を変数に格納できるので、途中までの処理は共通でそこから先を複数パターン作るというのも同じ変数に格納して、後段のメソッドチェーンを変えれば楽にできるというメリットが有ります。使っている感覚はRailsのActive Recordみたいなイメージです。

Sparkより7倍速いのは嬉しいの?

大事なのは15TBのデータを4.4秒で処理できる*2というスピード感です。処理を投げて帰ってくるまでの時間が短いと、思考の中断が減ります。 例えば、ビルドやテストに時間がかかってコーヒーをいれにいく、みたいな経験はあるんじゃないかと思います。その断絶がなくなるので、考えを継続できますし、ポッと思いついたことをどんどん試行錯誤できます。

Sparkとの住み分けは?

Ibisは、WesがPythonでend to endでPythonを使って分析をしたいという想いでスタートしています。 個人的にはJupyterとともに対話的に試行錯誤をする強力なツールになっていると思います。 もともとImpalaとPython/pandasをつなぐものとしてスタートしたのですが、RedshiftやPrestoなども今後対応していきたいということも言及されています。 なので、プロトタイピングにJupyterとIbisを使うというのが良いと思います。プロトタイプ後にSparkSQL*3でバッチとして安定化をはかるということもできるでしょう。

もう一つの方向性としては、NetflixがグローバルモデルをSparkで、国・地域のモデルをRで学習しているように、大規模な機械学習はSpark + MLlibで、絞った後のデータはIbis + scikit-learnでみたいな使い分けは可能だと思います。

サイバーエージェント内藤さん: Amebaにおけるレコメンデーションシステムの紹介

www.slideshare.net

Amebaでの協調フィルタリングによるHBaseを使ったリアルタイムレコメンドの話。 Hadoopスタックだとリアルタイム性を出すのにはHBaseを使うのが多いのですが*4、更にClick数を取得してバンディットアルゴリズムも使っているというのは凄いですね。

単純なA/Bテストをするという話はDMM.comラボの加嵜さんもお話されていましたが、バンディットアルゴリズムを組み合わせることで、レコメンド結果が複数のロジックの中でも良い物に動的に改善されていくという仕組みが入っています。 僕個人としてはこうした取り組みを聞いたことがなかったので、とても驚きました。

DMM.comラボ加嵜さん:Sparkを活用したレコメンドエンジンのパフォーマンスチューニング&自動化

www.slideshare.net

チューニングの話もインパクトが大きかったですが、jsonで「レシピ」を書けば、自分のサービスのレコメンドモデルができるという話はとても驚きました。 これを使えば、レコメンドに詳しくない人でも簡単にサービスに導入できそうです。 おそらく、ログフォーマットをきちんと統一して横展開をしているのでしょうね。

LT

horiken4 さん:初めてのSparkでハマったこと

Google Data ProcでSparkを使ったら/tmpにjarが貯まるなど、いろいろハマった話を紹介いただきました。

uryyyyyyyさん:EMR上でPython3系でpysparkする話

qiita.com

EMRにAnacondaをいれてPySparkでモデルを作る話でした。逆質問でJuliaを使ってると答えた人が2人くらいだったとのことで寂しかったです。

suthio さん:Sparkで実装しているレコメンドエンジンの基本的なパフォーマンスチューニング について

DAGを見よう!という話でした。そして、ポケモンGO仲間を募集しているとのことです。

終わりに

やはり、自社で手を動かして取り組まれているという話は、様々な知見が含まれていてとても楽しかったです。 AmebaのHBaseを使ったリアルタイムレコメンド+バンディットアルゴリズムという構成や、DMM.comラボさんのレコメンドの「レシピ」を書くだけで新規サービスのレコメンドモデルができるという話は衝撃的でした。

自分がホストしたイベントの中では過去最大の募集人数だったのですが、大盛況のうちに終わりました。ご協力・ご参加いただいた皆様ありがとうございました。 今回参加できなかった方もたくさんいらっしゃると思いますので、また次回もこういったイベントをできればと考えています。 乞うご期待ください。

*1:しかし、日本でIbisというと某研究会しか出てこないので非常につらい

*2:http://blog.cloudera.com/blog/2016/02/new-sql-benchmarks-apache-impala-incubating-2-3-uniquely-delivers-analytic-database-performance/

*3:こちらもIbisのスコープに入っています

*4:リクルートさんもHBaseを使ったリアルタイムレコメンドをしています

JupyterからSpark clusterを操作できるlivy + sparkmagicを試してみた

spark jupyter

Spark Summit 2016でもトークがあったSparkのREST serverであるlivyですが、MicrosoftがHDInsight上のSpark clusterとJupyterをlivyを使って繋げられるようにしたと聞いて、早速試してみました。

Jupyterって何?という方は簡単に言うと、ブラウザで各種言語のREPLが動くものと思ってもらえばいいです。 詳細は過去に書いた以下の記事を読んでみてください。

techlife.cookpad.com

livyとは

livyはSpark clusterをコントロールするためのREST Serverです。 Microsoftはこれとjupyter notebookのsparkmagicを使ってHDInsightとjupyterをつなげるようにしているそうです。

MSの取り組みはSpark Summit 2016のトークがわかりやすいです。 Livy: A REST Web Service For Apache Spark | Schedule | Spark Summit 2016

このsparkmagicの構成図がわかりやすいですね。

https://github.com/jupyter-incubator/sparkmagic/raw/master/screenshots/diagram.png

なぜlivyがいるのか?

Sparkは通常gatewayにつないで処理をするが、ユーザー管理は通常のHadoopと同じ形になります。つまり、localにsparkユーザーみたいなのが必要とかになってちょっと面倒。 とはいえ、jupyter server立ててそこのユーザーと同期するというのも面倒くさい。 livyを使えばREST server経由でSparkの処理を行うことが可能になります。

livyのサイトで言われている利点としては以下のとおりです。

  • 複数のSpark job、複数のクライアントから使える長時間動くSparkContextを持てる
  • cacheしたRDDやDataFramesを複数のジョブやクライアントで共有できる
  • 複数のSparkContextを同時に管理でき、YARN/Mesosで動くクラスターがLivy Serverの代わりにfault toleranceとconcurrencyを実現する
  • JobはprecompileされたjarやコードスニペットJava/Scala client API経由でsubmitされる
  • Apache Licenseで100% オープンソース

それだけだと僕にはあまり嬉しさがわかりにくかったのですが、手元で管理したJupyterと繋げられるようになるというのが個人的には最大のヒットでした。 Jupyterはcookpadのblogにも書きましたが、データエンジニアリングや機械学習系の取り組みをメモして共有するのにはとても便利なので、クラスターのSparkがあたかもlocalにあるように操作できるのはとてもありがたいですね。

予め用意するもの

準備

重要なレポジトリは以下の2つ。

まずはlivyからいれていきます。

Rをインストールする

requirementsに書かれているので一応用意しました。

$ sudo yum install -y epel-release
$ sudo yum install -y R

livyをbuildする

$ git clone git@github.com:cloudera/livy.git
$ cd livy
$ mvn -Dspark.version=1.6.0 -DskipTests clean package

今回試した時はtestがこけたので、-DskipTestsをつけました

livyを起動する

今回はCloudera Manager経由でsparkを入れたので、環境変数をこんな感じでセットします。

$ export SPARK_HOME=/opt/cloudera/parcels/CDH-5.7.1-1.cdh5.7.1.p0.11/lib/spark
$ export HADOOP_CONF_DIR=/etc/hadoop/conf

livy.confに以下の1行を追加しないとYARN modeで起動しない

livy.server.session.factory = yarn

ここまでできたら、livy serverを起動します

$ ./bin/livy-server

別のterminalで動作確認をする

$ curl localhost:8998/sessions
{"from":0,"total":0,"sessions":[]}

デフォルトで8998番のportが使われるので、必要に応じてportを開けるなりsshでport forwardingしてください。

jupyter側のsparkmagicの準備

sparkmagicにあるとおりにinstallします。

$ pip install sparkmagic
$ jupyter nbextension enable --py --sys-prefix widgetsnbextension 

wrapper kernelを入れます。 pip show sparkmagicのLocation以下で実行します。以下の場合だと /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages になります。

$ pip show sparkmagic
---
Metadata-Version: 2.0
Name: sparkmagic
Version: 0.2.3
Summary: SparkMagic: Spark execution via Livy
Home-page: https://github.com/jupyter-incubator/sparkmagic/sparkmagic
Author: Jupyter Development Team
Author-email: jupyter@googlegroups.org
Installer: pip
License: BSD 3-clause
Location: /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages
Requires: ipywidgets, pandas, ipython, requests, mock, autovizwidget, numpy, nose, ipykernel, notebook, hdijupyterutils
Classifiers:
  Development Status :: 4 - Beta
  Environment :: Console
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Natural Language :: English
  Programming Language :: Python :: 2.6
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
$ cd /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages
$ jupyter-kernelspec install sparkmagic/kernels/sparkkernel
$ jupyter-kernelspec install sparkmagic/kernels/pysparkkernel

~/.sparkmagic/config.jsonexampleをもとに入れます。

jupyter notebookの起動

起動する前に、curlでlocalからlivyに通信できるか確認しましょう。

$ curl YOUR_HOSTNAME:8998/sessions

jupyter notebookでいつもどおり起動をしてPySparkを選べばOK

notebookの例はこちら

gist.github.com

gistには出てませんが、こんな感じでSparkに対してSQLで処理した結果を簡単にvisualiseできます。sparkmagicすごい!

f:id:chezou:20160712155306p:plain

%%localでlocalのcontextに行ったりするのがまだなれないですが、magic commandの %%sqlで実行した結果をDataFrameで受け取れたりと、いろいろ便利そうです。

参考URL

そのモデル、過学習してるの?未学習なの?と困ったら

machine learning

Q: うわっ...ワタシのモデル過学習してる…?

機械学習をしていると、「やったほぼ100%の性能でました!」みたいな話がちょこちょこでて、その度に「あー、はいはい過学習乙」とか「leakageじゃね?」とかいう話になると思います。

過学習というのは、とても雑に言うと「学習に使ったデータに対してはバッチリ正解できるけど、知らないデータに対しては全然当たらない」というモデルのことを指します。 昔センター試験の英語を受けた年に突如出題傾向が変わったのですが、塾でバッチリ対策をしていた人々が「うわー、今年傾向変わって全然解けなかったー。きっと他の人も解けなかったよね」という話をしていたのですが、今思うとこれもある意味過学習ですね。

この辺は、PRMLなんかから伝統的に説明される、回帰モデルに対して高次のモデルをフィットさせていくと、やり過ぎになるよねみたいな話が書いてあります。

パターン認識と機械学習 上

パターン認識と機械学習 上

では、どういう時に過学習が起こるかというと、これもざっくり言うと以下の時に起こります。

  • データが少ない時
  • モデル*1が、問題に対して複雑すぎる時

書いていて表裏一体な気がしましたが、「じゃあこれどうやって気づけばいいの?」ということを思うと思います。 その答えが、今度日本語版が出る"Python Machine Learning"に分かりやすく書いてありました。日本語版も6月に出るので楽しみですね!

Python Machine Learning

Python Machine Learning

Python機械学習プログラミング 達人データサイエンティストによる理論と実践 (impress top gear)

Python機械学習プログラミング 達人データサイエンティストによる理論と実践 (impress top gear)

A: learning curveとvalidation curveを見よう

(以降の図は"Python Machine Learning"英語版の本より引用です)

f:id:chezou:20160529204510j:plain

この図は、わりと有名なbias-variance tradeoffの図です。 bias-varianceのトレードオフこちらのquoraのArjunさんの回答を見るとわかりやすいのですが、とても端折って書くとHigh varianceの状態が過学習(overfitting)で、High biasの状態が未学習(underfitting)です。

これだけだと、ナンノコッチャって感じなので言葉で説明すると、横軸をデータサイズとした時に、過学習(High Variance (+ Low bias))の時は訓練データに対する精度( 図中のtraining accuracy。なお、ここでの精度とは?という話は詳しく言及しないですが、詳しくは朱鷺の杜の記事参照。個人的には、accuracyでもprecisionでも指標はケースバイケースで良いと思います)がとても高く、検証データに対する精度(図中のvalidation accuracy)は低いです。なお、訓練データは学習に使ったデータ、検証データは元のデータから訓練データを除いておいた検証用のデータと思ってください。

それに対して未学習(High bias (+Low variance))の時は、データサイズを増やしても訓練データと検証データに対する精度が共に低い状況です。*2

ポイントとなるのは

  • desired accuracy、つまり求める精度に対して低すぎないか
  • 訓練データの性能だけ高すぎないか

ということです。

learning curveを描く

では、どうやってこれらの状況に気づけば良いのでしょうか?もう既に少し書いていますが、learning curve(学習曲線)とvalidation curve*3を書けば良いのです。

f:id:chezou:20160529212335j:plain

これは、learning curveの例です。先ほど少し簡単に説明を書いてしまいましたが、横軸をデータサイズとして持っているデータをサンプリングして増やした時に、どのように訓練データと検証データの精度が推移するかを描いたグラフです。幅があるのはCross Validationした際の精度の最大値と最小値です。learning curveを描いた時に、訓練データに対する精度だけ高かった場合は過学習を疑いましょう。(この例は、原著では少し過学習の気があるけど、訓練データと検証データの精度の差が小さいので許容範囲だよね、って書いてあります) 対処法としては、データ量を増やすかモデルが複雑すぎるのでもっと簡単なものを使うかのいずれかです。(もちろん、正則化を入れるというのもありです)

また、データサイズを増やしても精度があがらなければ(accuracyが0.3らへんでさまようとか)、未学習と思えばよいでしょう。この場合は、モデルをもっと複雑なものを使うのが良いでしょう。

validation curveを描く

もう一つの方法としては、validation curveを描きます。以下はその例です。

f:id:chezou:20160529214644j:plain

この例は、ロジスティック回帰の正則化項の逆比であるCパラメータを横軸にとっています。右に行けば行くほど正則化項の意味が弱くなり(つまり過学習しやすくなり)、左に行けば行くほど正則化項が強くなり(遊びが強くなりすぎる)ます。

このように、パラメータに対するfitting具合を見るのがvalidation curveです。これを描くことで、適切なパラメータを見つけることができるでしょう。

まとめみたいなもの

以上のように、learning curveやvalidation curveを描くことで、そのモデルが過学習しているか未学習なのかを判別できます。

いろいろ書きましたが、解決方法としては、cross validationするとか、正則化を使って遊びを持たせるとか色々あります。それについてはさまざまな書籍やブログで記述されていると思うので今回は書きませんでした。

また、この辺の話はPython Machine Learningに丁寧にコードとともに書かれているので、是非発売されたら買うといいと思います。訳の監督もsfchaosさんなので期待が高まりますね!

*1:学習アルゴリズムと読み替えてもOK

*2:以前、AI学会の研究会で@shima__shima先生が「それは未学習なのでは?」というツッコミをしていたのが、意外と未学習を気にしないのではという思いに至った端緒です

*3:訳語わからない⇨検証曲線と訳しているそうです

機械学習の分類の話を損失関数と決定境界を中心に整理してみた

machine learning

機械学習の分類の話を、主に決定境界と損失関数の観点から整理してみました。 とはいっても、k-NNとか損失関数関係ないのもいます。

最初ははてなブログに書こうとしたのですが、数式を埋め込むのが辛かったのでjupyter notebookにしました。

github.com

[追記]

githubだと日本語を含む数式のレンダーが壊れるので、nbviewerの方がいいかもしれません。 https://nbviewer.jupyter.org/github/chezou/notebooks/blob/master/classification.ipynb

[/追記]

パーセプトロンが見直されたのはなんでだっけ、SVMってどういう位置づけだっけ、というのを確認できればなぁと思っています。 多層パーセプトロンまでに至るところの流れがうまく伝わればなぁと思っています。 間違いなどがあれば、是非ご指摘いただければ嬉しいです。

本当はcourseraのMachine Learningのコース前の人に届けば嬉しいんですが、きっと修了した人にしか伝わらないかなぁ。 もし、まだNgのコース終わっていない人がいたら、感想聞いてみたいです。

データを一箇所に集めることでデータ活用の民主化が進んだ話

データ分析

先日、この記事を読んで分析のハードルを下げること大事だよね、というのを思い出したのでつらつらと書いてみようと思います。

qiita.com

内容としては正直タイトル詐欺で、SlackからRDSにクエリ発行できるようにして、各種権限を持っているエンジニアでなくても分析できるようになったよ、という話です。

ここでいう「データ活用の民主化」というのはかっこ良く言ってみたかっただけで、「データ分析を生業にしている人以外もデータを活用してビジネスを進められるようになる」というくらいのニュアンスだと思って下さい。 「データ分析」というとアナリストの人がやること、みたいな職務が分かれている環境もあるとは思いますが、そうではない会社(前職)の一例です。

データ活用が広まった流れ

  1. 数秒〜数十秒で対話的にクエリが返ってくると、トライアンドエラーが100倍くらいできる
  2. 今まで実行計画を気にして避けていたことにガンガン挑戦して、新しいメタデータ達が付与される
  3. エンジニアがSQLに慣れ親しむ*1と、ノウハウがチームや社内ブログに蓄積される
  4. 身近なエンジニアがサポートできるようになり、Webディレクターの人もSQLを覚えてKPIを主体的に考え始める

こういう流れでSQLが社内のエンジニアからWebディレクターの人たちに広まっていきました。 また、SQLの苦手意識が減ってきたことで、プロダクトのフェーズに応じて変化するKPIを考える力が、数字が得意ではないWebディレクター*2にも身についてきました。

前提

この流れを支える前提としては、

  • Redshiftに入るデータを整備するいわゆるデータエンジニアリングをしている人*3がいた事
  • @mineroaokiさんが「データの移動は悪だ!必要なテーブルは言えば集める!」*4と一貫して主張し続けて、一箇所でSQL叩けばだいたいなんとかなる(と思える)ようにしてくれていたこと*5
  • 分析をする人が楽できるようにsshやproxyもなしでPosticoみたいなGUIクライアントで直接Redshift叩けるようにしてくれたこと

といった事実があります。 3つめのポイントなんかは、前述のQiitaに書かれていた記事のポイントですよね。

ここでいう「データを一箇所に集める」ということは、分析する人の立場からすると「一箇所でSQL叩けばだいたいなんとかなる」という状況です。 もちろん、処理方法はSQLに限った話ではないですが、

  • 分析のために余計なデータ転送のコストをかけない
  • 一定の前処理はなされており、何かしらの統一した方法でデータを処理すればよい

という状況を想定しています。

ここまでお膳立てされて、最初は面倒くさいと思って僕含むRubyに逃げていたエンジニアたちもWindow関数最高!と言い始めるに至りました。

また、多くのWebディレクターの人たちはRubyなどのスクリプト言語は書けない人がほとんどでしたが、データが一箇所に集まったおかげで「SQLだけ覚えればエンジニアの手を借りること無く色々できる!」と思っていただけたのも良かったのかもしれません。

@mineroaokiさんの思想はこちらのスライドにたっぷり詰まっています。P.12から「一箇所にまとめる」話がありますので、そこだけでも読んでみると良いでしょう。

www.slideshare.net

なお、Airbnbバッチ処理用とアドホッククエリ用とでクラスターをレプリしているようですが、分析に必要なデータが一箇所にまとまっていると言っても差し支え無いでしょう。

ちなみに

実はもう一つの要素として、インフルエンサーとなるディレクターの人が居たのも事実です。 彼女は、今や他のチームにSQLコンサル(!)もしているようですが、昔はSQLができなくてエンジニアに毎回お願いしていたそうです。 その当時一緒に組んでいたエンジニア(SQLはめちゃ得意)が、あまりに面倒くさそうに対応するのが嫌でSQLを覚え始めたと聞きました。 その後、社内のデータ分析相談チャットで質問しまくったり、青木さんに質問したり、使ったクエリを自分のメモとしてストックすることで、他のディレクターに3,4段はネストするサブクエリ含んだSQLを展開するに至っています。

彼女がSQLを武器にできるようになったのはもう一つ、青木さんの本の助けもあったと聞いています。 おそらく、他のWebディレクターの人たちにとっては、同じポジションの人に相談できるのは似たようなところを躓いたりした経験を聞けたりするのが良いのだと思います。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

データを一箇所に集めると民主化が進むのか?

もちろん、ただ集めるだけでは進みません。

「一箇所に集める」とはデータ分析をする人のコストを徹底的に下げる、ということに他なりません。 データ分析基盤を用意する人にとっては正直面倒なことも多いとは思います。 ですが、使ってもらってなんぼのデータ分析基盤は、最大限分析する人にやさしくするのが必須です。 自分より苦手意識を持つ人に、「あちらのDBは実行計画気をつけて、こちらのDBはjoinすると辛いから...」みたいな面倒くさいことやってくれると思いますか?

その上で、そうしたデータをどう料理すればいいのかを、まずはエンジニアを中心とした比較的データやSQLに慣れ親しんでいる人がお手本を見せます。 もちろん、得られた知見を含む、加工したデータも蓄えていきます。

このときに、社内Wikiやブログではコピペで動く状態のクエリ(コメントもできれば付けて)と結果を添えて共有すると良いでしょう。 SQLが苦手な人でも、「コピペではじめるDAUの分析」みたいなタイトルの記事だったらきっと読んでくれます。

良いツールや本を広めていくのと同じように、「何ができるようになるか」という具体例とともに、少しずつ仲間を増やしていくことが大事です。

データ活用の民主化が進むと

定番料理の提案の話でも、「検索セッション」の話が出てきていますが、検索チームなら「検索セッション」を見て仮説を立てて検証するよね、というように、生のデータを見るだけではなく、セッションのような塊で見ることで仮説を立てる、ということがデータに詳しくない人(元のデータやクエリを作った人ではない人)でもできるようになります。

もちろん、Jupyter notebookのようなノートブック系のツールが発展することで、それらが加速することはあると思いますが、本質的に大事なのは「データにどういう切り口を与えて見ればいいのか」ということを、多くの人ができるようになることです。

パソコンやワープロが普及したことで、タイプライター専業の人の職がなくなってしまいましたが、その代わりに何かをしたい人がワープロを道具として新しいことを生み出すことができるようになりました。 SQLやデータも同じで、データ活用の民主化が進むことでドメインに対する知識やパッションを持った人が、道具としてのデータを使って新しいことを生み出すことができるようになると信じています。

この話を他の人にすると「でも、それエンジニアが凄い会社だからできたんでしょ?」と言われるのですが、多分データを一箇所に集めて誰でも分析できるようになった時にどうなるか、というイメージがわかないのがコストを割けない1つの原因なのではないか、と思いこういった記事を書いてみました。 もちろん、特にデータエンジニアリングを中心にいくつかの技術的ハードルはあるとは思いますが、チャレンジする価値はあると思います。

*1:前職はRuby大好きな人が多かったため、アプリケーション用のSQLはかけるけどサブクエリやWindow関数バリバリの分析用クエリ書ける人は最初は少なく、手元でRubyで処理することが多かった

*2:後に、もともと学校の算数・数学大嫌いだったと笑いながら言っていたのが印象的でした

*3:@mineroaokiさんたち

*4:実際に、テラバイト規模のデータを移動するのにN時間とかアホみたいなことも世の中にはあったりしますよね

*5:もちろん、権限ないと見れないスキーマとかもありましたが