オタク機械学習勉強会#0 LT発表資料

1. この素晴らしい
SQLに祝福を！
オタクML勉強会#0

2. お前誰よ？
これ→じょんすみす(@__john_smith__)
• どこにでもいる普通のアル中
• 願望
• 北海道帰りたい(テンプレ)
• 花澤香菜と高橋李依と南條愛乃
• 謝罪
• 発表にオタク要素があまりはいらなかった

3. 人々の欲望と時代の変遷
• RDB使ってないシステムとかありえないでしょ
• 永続化 == RDB
• 他になんかあるの？時代
• NoSQL自体の到来
• データが多くなってきてRDBとかもう無理でしょw
• これからの時代はNoSQLですよ！
• やっぱSQL必要時代
• RDBじゃなくても結局SQLをインターフェースにしたい
• データ分析で使ってる言語でR, Pythonの次くらいにSQLが現れる
• イマココ

4. AI, 機械学習時代におけるSQL
• ETLとしてのSQL
• 人生とは前処理の辛さとの戦い
• Hiveでデータを取得してSparkで機械学習
• 非プログラマがデータを使うためのSQL
• SQLで機械学習が出来る時代
• Hivemallの出現
• 調べてみると他にもいろいろあった
• Postgresql, Microsoft SQL Server, Oracle
• MySQLにはなさそうw

5. AI, 機械学習時代におけるSQL
• ETLとMLとSQLとつらみ
• 前処理で例外だらけのデータをいじくってる時よりはましだけど。。
• MLのライブラリが必要とするフォーマットをつくるのって
• 地味に作るのが面倒
• 単純にid変換でもメモリに乗らないくらいの特徴数があると。。
• データフレーム大好き
• 単純なSQLとがっつりDF操作でいいんじゃかな？
• 最近の非エンジニアがデータいじるって発想に反してる
• SQLで機械学習の現状
• アルゴリズムは開発者がだいたい実装してる

6. というわけで
• こんなのがあると嬉しいんじゃなかろうか
• よくあるフォーマットに変換する関数
• いわゆるlibsvm formatとか
• 実はライブラリに丸投げしてるだけの関数
• まだまだ、そんなアルゴリズムがあるかで差別化できる領域ですし
• というわけなので
• 作ろうとしてみた
• 需要がありそうなら今後もやるかもしれない
• ようするにただやってみたかっただけ

7. たーげっと
• PostgreSQLを相手にする
• MySQLは分析環境としてはイマイチっぽい
• Oracle, SQL Severを相手にしてる金があったらその分酒を買う
• Hive, Spark SQLなど分散環境は連番のIDを振るのが辛い
• FeatureにID振るのはSQLの機能にお任せすることにしたので
• できなくはないけど分散環境でユニークID振るのは面倒なのはちょっと考えれば
分かっていただけると思われる
• なお、私はそんなにSQLには詳しくない模様

8. 文章の形態素解析
• textsearch_jaとかあるっぽいけど今回の用途ではイマイチなの
で車輪の再発明でもいいや、ってなった

9. 文章の形態素解析
• textsearch_jaとかあるっぽいけど今回の用途ではイマイチなの
で車輪の再発明でもいいや、ってなった
こんな感じで
4種類の凛ちゃんに関する2chのやりとり
を持ってきたデータ

10. 文章の形態素解析
• textsearch_jaとかあるっぽいけど今回の用途ではイマイチなの
で車輪の再発明でもいいや、ってなった
こんな感じで
4種類の凛ちゃんに関する2chのやりとり
を持ってきたデータ

11. 文章の形態素解析
• textsearch_jaとかあるっぽいけど今回の用途ではイマイチなの
で車輪の再発明でもいいや、ってなった
こんな感じで
4種類の凛ちゃんに関する2chのやりとり
を持ってきたデータ
こうなる

12. 文章の形態素解析
• textsearch_jaとかあるっぽいけど今回の用途ではイマイチなの
で車輪の再発明でもいいや、ってなった
こんな感じで
4種類の凛ちゃんに関する2chのやりとり
を持ってきたデータ
こうなる
Longで持たせとく

13. 単語のID化
これを先ほどのテーブルと単語でjoinするとBoWの出来上がり

14. Long形式の特徴データ
同じ感じで文字列のlabelも数値化して
全部joinする
ここまで出来たらあとは
よろしくやってくれると嬉しいですよね？

15. libsvmフォーマットにする関数
この関数1つでおなじみのフォーマットにしてみた
ちなみに全情報でgroup byなcountして、
word_idとcount(word_id)を「:」で文字列結合
それをさらにarray_agg -> array_to_string
でも同じことは一応実現できる
※tmpは
さっきの結果をviewにした

16. で、ようやく機械学習
裏でscikit-learnに投げてるだけ
実装は自分でやる必要が無いので効率よくアルゴリズムを量産できる

17. で、ようやく機械学習
裏でscikit-learnに投げてるだけ
実装は自分でやる必要が無いので効率よくアルゴリズムを量産できる
と思っていた時代が私にもありました

18. で、ようやく機械学習
裏でscikit-learnに投げてるだけ
実装は自分でやる必要が無いので効率よくアルゴリズムを量産できる
と思っていた時代が私にもありました
実際には「文字列(の配列)」としてのこのフォーマットは読めなかった
自分でパースするか、一度tmpファイルに書き出して
ファイルから読み込むという無駄処理が必要だった

19. そして・・・
• predictはどうしたものか
• だいたいこちらの思い通りにはいかない
• 入力として入ってくるフォーマット
• ライブラリが要求する形式
• モデルに含む内容
• predict対象のデータが持ってない特徴どうすんの？
• スパースなデータで必要な特徴しか持ってないと
学習時と同じ特徴に持ってくのをどうするか
• 次元数も引数にするのは美しくない
• longでもwideでも全部0で埋めるのも処理速度が辛いことになりそう
• スクラッチで実装してればその辺意識したモデルの中身にできるけど

20. 結論
• SQLの深みにはまるとアレ
• 素人でもSQLで機械学習まで出来ちゃうように関数を用意するくらいなら、
PipelineをGUIで構築できるようなインターフェースのほうがよくね？
• まぁ、そもそも車輪の再発明ですし
• scikit-learnだけじゃなくgensimに入ってるような処理やdeep learning
系など、pythonさえ知ってればUDFはサクッと量産できるところま
で行きたかったけど、まぁ
• 結局のところ、data frameが最強
• 昨日1日でこのすば3周した
• ソースは整理したらgithubにあげます
• やる気があればライセンスとかも追加してOSSっぽくします

21. 今後の話
• UDFの内外のやりとりはjsonとかで統一してしまったほうがいい
かも
• データの型を考えてやりとりするのが地味に辛い
• complex typeの配列はできないけど、中の要素は配列にできるとか
• 最近のpostgresqlはjsonサポートしてるっぽいからSQLでいじりたい部分
はparseしてとか
• プログラム側はpandasとかに変換してゴリゴリ回せるし
• みんなが苦しみから解放される環境を
• ビジネスサイドにいる人はsqlさえ知ってればudf使うだけ
• 研修者サイドはゴリゴリアルゴリズム実装
• エンジニアがそこの繋ぎこみで病まないインターフェース統一