勉強会メモ - Machine Learning with Apache Spark
どうも!今日も勉強会に参加していますーので、勉強会メモを公開します。@yamakatu さんがお休みで残念!
「はじめまして、Spark&MLlib 」
株式会社 NTT データ 土橋さん
- hadoop はスループットを重視しているため、レイテンシの低さが求められる処理や、複雑で繰り返しが多い処理は苦手だった。
- すなわち、統計処理、機械学習、複雑な業務処理などの中には上記のような類の処理が含まれていることがあった。
- OSS は使いドコロ。適材適所
- Spark はレスポンスとスループットのバランスがとれている、Storm はレスポンス重視。
Sparkの特徴
- IOコストを減らして、メモリを使って素早く処理する。
- Sparkは「柔軟な」分散処理基盤 -> MapReduce の隠蔽による普通っぽいプログラミング
- データを上手く扱うための抽象化の仕組みがある -> RDD による、普通っぽいコレクションAPIで分散したデータの処理
- コアを中心に成り立つエコシステム -> SQL / Streaming / MLLib / GraphX など、ライブラリが色々ある。
チュートリアル&デモ
寿司データを K-Means でクラスタリングする流れをデモ。
よくやる作業の流れ
- HDFS にデータを入れる
- Spark シェルを使ってデータを加工&処理する
- 流れが決まったらアプリ化する
Spark Shell の起動時の引数に jar を渡すと、クラスパスに通してくれるので、自作のツールとかをシェルで使うことができる。
RDD のメソッドには種類がある。action に当たるメソッドを実行すると、transforme を含め実際の処理も実行される。(いわゆる遅延評価)
- transforme : RDD のデータに何か加工をする処理。
- action : RDD のデータを HDFS などへ出力するなど、外部に影響を与える処理。
アプリケーション化したときのコードと、Spark シェルのコードはほぼ同じなので楽ちん。
- 注意点としては、作成するクラスは Serialilzeable を implements して作成すること。
「Spark MLlib でやってみる協調フィルタリング」
@soonraah さん
- 協調フィルタリングとは、レコメンを実現する手法の一つ
- MLlib における協調フィルタリングは、ALS のみ。 (行列因子分解モデル)
- 普通はスパースな(疎な、穴だらけの)データが元になる。穴になっている箇所を推測することで、レコメンドを実現する。
- ALS - 2つ(商品と、ユーザー)の特徴行列に分解する。2つの特徴量行列を交互に学習し、誤差を小さくする。
実は純粋な ALS ではなく、ALS-WR を実装している。
- Overfitting を防ぐため
- ラムダが頑健性と精度のバランスを司るパラメータを指定することができる
- ラムダが大きいとモデルの凸凹を、より小さくする
特徴量数(rank) を増やせば増やすほど、性能が改善する。大体 10 ぐらいでそれほど変わらなくなる
- ラムダは値を増やしていくと、下に凸のグラフになる。
- 値が小さいと overfitting している、だんだん値を上げると精度が改善してくる、上げ過ぎると境界面がのっぺりしてくるので精度が悪くなる。
- ラムダの値が小さい状態で rank の値を増やすと、オーバーフィッティングしやすくなる。なので、rank の値を増やすと精度が悪くなる。
システム適用時の課題
- EMR 上で実行するには、Bootstrap スクリプトを自分で用意する必要があるので面倒くさい。
- ラムダの実験的な決定。データ次第なので、繰り返しトライエラーして値を決めないと行けない。
- 速度の問題
- ユーザー、商品の数が大きくなると辛くなってくる。ユーザー数と商品数の掛け算のような状態になるので、すごく時間がかかる。
- 一つの解として、商品の行列データを list に分解してノードごとに broadcast で配り、個別に計算するように改造して高速化した。
「Spark ベストプラクティスと Logistic Regression with MLlib のチュートリアル」
株式会社リクルートテクノロジーズ 石川
Spark の基礎知識
RDD
- DAG型実行計画:処理の経路を保持しておくことで、途中で障害が起きても、再度同じ処理を行うことで復旧する。
- map や filter などの処理は遅延評価、count などの action が実行された段階で処理される
Partition in RDD
- RDDの分割数 = 利用できるCPUコア
- 一般的に利用できる CPU のコア数 ☓ 1〜3倍がベストと言われている。増やしすぎると遅くなるし、アルゴリズムによって適切な数は依存する。
Cache
- クラスタ横断でメモリ上に処理データをキャッシュすることができる。
- 繰り返し再利用されるデータに活用すると効率化できる
- cache されるタイミングについて、 cache は action の処理をしながら行われる
Spark のベストプラクティス
- Cache の活用ポイント
- Cache は Web UI で確認できる。
- 適宜キャッシュする、キャッシュされた箇所で DAG をたどって処理されるので最初期だけでキャッシュされると遅い。
- Gzip で圧縮されたデータに注意
- 分割出来ないので、いくらパーティション数を増やしても 1 プロセスでしか処理されない
- Data Locality
- データと処理が同じ箇所で事項されているのが速い。Web UI でローカリティが働いているかどうかを確認できる。
- Master (Driver) に負荷をかけない
- RDD の collect メソッドなど、巨大なデータを Driver のメモリに全てロードする処理になる。take メソッドなのでできるだけ代替する。
- collect 以外にも同様のメソッドがある
Spark 1.2 MLlib
現状の課題
- Kmeans などで使う距離関数はユークリッド距離のみ
- Top-Level API が一貫していない
- アルゴリズムによって実装品質がバラバラ・・
注目の issue
- API の一貫性の統一
- ランダムフォレストの実装
- PySpark 用の word2vec サポート
まとめ
- RDD のパーティション数とキャッシュ
- キャッシュはタイミングが重要
Advanced Analytics With Spark: Patterns for Learning from Data at Scale
- 作者: Sandy Ryza,Uri Laserson,Sean Owen,Josh Wills
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2015/04/20
- メディア: ペーパーバック
- この商品を含むブログを見る