Robust Large-Scale Machine Learning in the Cloud
•
3 j'aime•1,156 vues
Robust Large-Scale Machine Learning in the Cloud, KDD'16
![Robust Large-Scale Machine
Learning in the Cloud
Steffen Rendle
Dennis Fetterly
Eugene J. Shekita
Bor-yiing Su
Google Inc.
[KDDʼ16]
2017/3/17 Yuto Yamaguchi@CAML 1
機械学習情報交換会](https://image.slidesharecdn.com/paperintrorobustlargescalemachinelearninginthecloud-170318210311/85/Robust-Large-Scale-Machine-Learning-in-the-Cloud-1-320.jpg)
Recommandé
Contenu connexe
Tendances
En vedette
En vedette (20)
Similaire à Robust Large-Scale Machine Learning in the Cloud
Similaire à Robust Large-Scale Machine Learning in the Cloud (20)
Plus de Yuto Yamaguchi
Plus de Yuto Yamaguchi (11)
Dernier
Dernier (10)
Robust Large-Scale Machine Learning in the Cloud
- 1. Robust Large-Scale Machine Learning in the Cloud Steffen Rendle Dennis Fetterly Eugene J. Shekita Bor-yiing Su Google Inc. [KDDʼ16] 2017/3/17 Yuto Yamaguchi@CAML 1 機械学習情報交換会
- 2. ⼀⾔で 2017/3/17 Yuto Yamaguchi - CAML 2 ⼀般化線形モデルの学習を めっちゃスケールするようにしたよ
- 3. 概要 • ⼀般化線形モデルに対する Scalable Coordinate Descent (SCD) を提案 • 通常のCDよりもスケールアウトしやすい • Work loadが均⼀に近い • CDはある特徴次元について更新を逐次繰り返すが、 SCDは複数の特徴次元をまとめて更新 • Google Could上に実装 • システムの詳細について説明 • 実際にGoogleが持っている広告のデータで実験 • Netflix prizeの10000倍でかい（！）データ • ワーカーの数に（ほぼ）線形にスケール 2017/3/17 Yuto Yamaguchi - CAML 3 ALGORITHM SYSTEM EXPERIMENTS
- 4. 問題設定 ー ⼀般化線形モデル 2017/3/17 Yuto Yamaguchi - CAML 4 線形モデル＋好きなリンク関数 好きなロス＋L2正則化（L1でも可） ＊なんでもOKだけど 論⽂中では リンク関数 ＝ identity ロス関数 ＝ squared loss 正則化 ＝ L2 を例に議論
- 5. 問題設定 ー データ • Trillion（１兆）スケールのサンプル数 |S| • メモリに乗り切らない • Billion（10億）スケールの特徴数 p • めちゃくちゃスパース • One-hot encodingをたくさん含むようなデータ • NZ(X) < < |S| x p 2017/3/17 Yuto Yamaguchi - CAML 5 * NZ(X): Design matrix X の中の non-zero 要素数
- 6. 問題設定 ー 計算環境 • Shared Machines: • １つの物理マシンに複数のVM • Distributed File System: • GFSとか使うよ • Preemptible VMs: • Priorityの低いVMを⽌めてpriorityの⾼いVMに計算リソースを割り当てる • AWSのspot instanceとか • Machine Failures: • 計算機は壊れるよ 2017/3/17 Yuto Yamaguchi - CAML 6
- 7. ゴール（何をしたいか） • Robust Distribution: • どれくらいスケールさせても、どういう計算環境でも同じように収束 して欲しい • Linear Scale-out (weak scaling): • 学習サンプル数と分散させるワーカーの数を同じ割合で増やすと、学 習にかかる時間は変わらない • Linear Speed-up (strong scaling): • 学習サンプル数は変えず、ワーカーの数をM倍すると、M倍速くなる 2017/3/17 Yuto Yamaguchi - CAML 7
- 8. ALGORITHM 2017/3/17 Yuto Yamaguchi - CAML 8
- 9. Coordinate Descent (CD) 2017/3/17 Yuto Yamaguchi - CAML 9 θ＼θj が既知（fixed）であると仮定して、 θjを順番に更新する
- 10. CD ー アルゴリズム 2017/3/17 Yuto Yamaguchi - CAML 10 データパラレルにすると ここで同期バリアが発⽣ （Tの集約） めちゃくちゃスパースな設定だと、 各イテレーション（ j ）での各 ワーカのwork loadが⼩さすぎる è オーバヘッドのほうが ⼤きくなりがち（遅い！）
- 11. Proposed Algorithm: Scalable Coordinate Descent (SCD) 2017/3/17 Yuto Yamaguchi - CAML 11 １つの特徴量θjごとにイテレーションを回すとwork loadが⼩さ すぎて分散に向かなかった è 特徴量の集合（ブロック）ごとにイテレーションを回す 特徴量のインデックス {1, …, p} の分割 P を考える ・B ∈ P をBlockと呼ぶ ・どう分割するかはまたあとで考える
- 12. SCD ー アルゴリズム 2017/3/17 Yuto Yamaguchi - CAML 12 データパラレル データパラレル Blockごとにイテレーション 収束保証するために line search α∈[0,1] が⼩さいほど収束は遅い 同期バリアをブロック数（<<p） で抑えられる
- 13. 更新の独⽴性 2017/3/17 Yuto Yamaguchi - CAML 13 LEMMA 1: Block が Pure ならパラメータの更新は独⽴（証明は論⽂参照） è 独⽴に更新しているのと変わらないので、 α=1とできて、CDと同じ結果が得られる。 DEFINITION 1: (Pure Block) Bが Pure であるとは、 全てのサンプル x について、NZ(xB) ≦ 1 つまり、ブロック内では各⾏にnon-zero要素が多くとも１つしかない * xB：xからBに含まれるインデックス のみ取り出したベクトル
- 14. どう分割するか？ • 要件 1. できるだけ Pure にしたい • α＝１とできるので収束が速くなる 2. それぞれの B についてwork loadを均⼀にしたい • 分散の効果が⼤きくなる • Natural Partition • １つの変数を表すインデックスの集合をブロックとする • 例）国を表すOne-hot encoding • Pureだし、work loadも均⼀になる 2017/3/17 Yuto Yamaguchi - CAML 14
- 15. SCDまとめ • ブロックごとに更新しても line search すれば収束を保証 • 完全に Pure なブロックに分割できれば、独⽴に更新している のと等価なので、α＝１とできる • CDと同じ収束速度 • ブロックごとにイテレーションを回すので、１つの特徴ごとに イテレーションを回すCDとくらべてwork loadが⼤きい • 分散に向いている 2017/3/17 Yuto Yamaguchi - CAML 15
- 16. SYSTEM 2017/3/17 Yuto Yamaguchi - CAML 16
- 17. Storage Format 2017/3/17 Yuto Yamaguchi - CAML 17 Feature sharding + Row sharding
- 18. System Flow 2017/3/17 Yuto Yamaguchi - CAML 18 Master１つと Workerたくさん 若⼲の⼯夫 （次スライド）
- 19. 3. Aggregating Sufficient Statistics 2017/3/17 Yuto Yamaguchi - CAML 19 全てのworkerからmasterにそれぞれ送ると バンド幅がボトルネック è“aggregator” worker が ”leaf” worker の データをまず集約して、それをmasterに 送る １つのworkerが aggregator と leaf の⼆役 をやることでバンド幅を使い切る（１つの aggregatorがある範囲のfeatureを担当）
- 20. Straggler Handling • 同期するので、⼀番遅い worker (straggler) に律速される • 解決策（次スライドから） • Dynamic Load Balancing • Caching • Prefetching 2017/3/17 Yuto Yamaguchi - CAML 20
- 21. Dynamic Load Balancing • 処理が終わった worker は master に問い合わせて新たな work load を割り当ててもらう • è Idle状態を極⼒減らす 2017/3/17 Yuto Yamaguchi - CAML 21
- 22. Caching • DFSにアクセスしてデータを持ってくるのは遅い • è キャッシュする • Master はできるだけ同じ row shard を割り当てようとする • キャッシュが効く • キャッシュに乗ってなかった場合、できるだけDFSにアクセス しないで他の worker から取ってくる • Hedged-request：DFSのほうが早いこともあるので両⽅に問い合わせ て早く帰ってきた⽅を使う 2017/3/17 Yuto Yamaguchi - CAML 22
- 23. Prefetching • 各イテレーションで別のブロック B について処理するので、 データ X についてはキャッシュがあまり効かない • è 次のイテレーションで使うブロックに対応するデータを prefetchしておく 2017/3/17 Yuto Yamaguchi - CAML 23
- 24. Dealing with VM Preemptions • Preempt された worker (VM) は処理が終わっても新たな work load をくれと⾔わなくなる • 今持ってるwork loadは最後まで処理する • ⼗分な時間がある • もし Master の VM が preempt されたらMachine Failureとし て扱う（次スライド） 2017/3/17 Yuto Yamaguchi - CAML 24
- 25. Dealing with Machine Failures • 故障によって失われた worker のみが持っていたデータは失わ れるので、やりなおす • Master を持つマシンが故障したときのために、master は適宜 checkpointをDFSに保存しておく 2017/3/17 Yuto Yamaguchi - CAML 25
- 26. EXPERIMENTS 2017/3/17 Yuto Yamaguchi - CAML 26
- 27. 設定 • Adsのデータを使⽤（詳細は書いてない） • 1.7 billion features • 1 trillion examples (10000x more examples than Netflix prize) • 200 trillion non-zero elements • Pureな分割しか扱わない • Google cloud上に実装 2017/3/17 Yuto Yamaguchi - CAML 27
- 28. Scale-out 2017/3/17 Yuto Yamaguchi - CAML 28 Worker の数とサンプルの数を両⽅共 x 倍する 理想は横ばい（完全に スケール）だけどx=50 で35%遅くなった
- 29. Speed-up 2017/3/17 Yuto Yamaguchi - CAML 29 サンプル数はそのままで Worker数をx倍する 線形以上の⾼速化！ 学習全体にかかる コスト（ドル）
- 30. まとめ • Scalable Coordinate Descentを提案 • Pureな分割をすれば通常のCDと同じ結果が得られる • ある程度の⼤きさのwork loadを分散できるため、分散処理の効果が⼤ きい • Google Cloud上に実装 • いろいろ詳細に書いてある • 超⼤規模なデータで実験 • スケールした 2017/3/17 Yuto Yamaguchi - CAML 30