SAIS/SIGMOD参加報告 in SAIS/DWS2018報告会@Yahoo! JAPAN
>100 Views
August 27, 18
スライド概要
https://connpass.com/event/94361/
2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp
関連スライド
各ページのテキスト
SAIS/SIGMOD参加報告 SAIS/DWS2018報告会@Yahoo! JAPAN 2018/07/20 Shingo Furuyama
1. 2. 3. 4. 5. 自己紹介 出張の模様 Spark+AI Summitから SIGMOD/PODSから 所感など
自己紹介 2007 Simplex Technology で金融まわりのいろいろ 2011 ノーチラステクノロジーズで業務バッチ on Hadoop -- ここからYahoo! JAPAN 2014 金融まわりのエンジニア&BD/DDなどいろいろ 2016 データプラットフォーム周りの部長などいろいろ 2018 データプラットフォーム周りのリサーチなどいろいろ http://jp.linkedin.com/in/shingofuruyama
1. 2. 3. 4. 5. 自己紹介 出張の模様 Spark+AI Summitから SIGMOD/PODSから 所感など
出張の模様 - SAIS
出張の模様 - SIDMOD/PODS
1. 2. 3. 4. 5. 自己紹介 出張の模様 Spark+AI Summitから SIGMOD/PODSから 所感など
Spark+AI Summitから 1. 2. Understanding Parallelization of Machine Learning Algorithms in Apache Spark Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow 3. Project Hydrogen: Unifying State-of-the-art AI and Big Data in Apache Spark 4. The Future of AI and Security 5. Infrastructure for the Complete ML Lifecycle 6. TuneIn: How to Get Your Hadoop/Spark Jobs Tuned While You’re Sleeping 7. Extending Spark SQL API with Easier to Use Array Types Operations 8. Continuous Processing in Structured Streaming 9. A Deep Dive into Stateful Stream Processing in Structured Streaming 10. Flare and TensorFlare: Native Compilation for Spark and TensorFlow Pipelines 11. Model Parallelism in Spark ML Cross-Validation 12. Deploying and Monitoring Heterogeneous Machine Learning Applications with Clipper
Understanding Parallelization of Machine Learning Algorithms in Apache Spark(1/2) https://databricks.com/session/bay-area-apache-spark-meetup
Understanding Parallelization of Machine Learning Algorithms in Apache Spark(2/2) 戦略1 データ並列で頑張って並列化 できないところはあきらめる 戦略2 全部データ並列で頑張る 戦略3 タスク並列で頑張る • • 並列化できないアルゴリズムを使うときもこれ DataFrameをPandasにするのは簡単なので、 前処理Sparkで抽出したデータを1ノードに もってって好きなアルゴリズムで戦う • Horovod/XGBoost/H2Oあたりをつかって る場合はパイプライン全体を並列化できる • キャッシュをうまく使うほうが効率がいいこ とが多い • 2.3でCV並列が簡単になったのでそれをつか うとか（のちのセッションで紹介）
Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow(1/4) https://databricks.com/session/bay-area-apache-spark-meetup
Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow(2/4) • • • • mxnetとかKerasにならぶくらいには メジャーになってるっぽい トレーニングでも軽く触れられてて 「それ全員知ってる」みたいな位置づ け 「Uberの分散学習はHorovodだけで やっていて、一日かかかってた学習が 一時間になるくらいのインパクトがあ る」とのこと https://www.slideshare.net /databri cks/horovod-ubers-open-sourcedistributed-deep-learningframework-for-tensorflow
Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow(3/4) • • TensorFlow/Kerasなどを使ったシン グルノードでの学習を行うコードを、 プログラムを書き換えずに （Parameter Serverを使わずに）分散 学習をできるように変換してくれる MPIのアナロジーが使われている（パ ラメーター交換でMPIを使うこともで きるが、なくても動く）
Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow(4/4) • • • • Gradient checkpointingで大きなモデルが扱えるようになった – https://github.com/openai/gradient-checkpointing Parameter Serverを使う並列化の問題 – 同期の問題を部分的に解決、ただ若干コードが複雑になる – さらにRDMA/IBとかハードウェアに頼らないといけなくなることも そこでHorovod – 帯域をつかうのでRDMA/IBは使う前提ではある（なくても動く） – 各ノードが持っている勾配を順繰りに加算して勾配を計算して、終わったら計算した勾配 を互いに交換して同期をとる – MPI AllReduce最強伝説 http://www.cs.fsu.edu/~xyuan/paper/09jpdc.pdf – On Sparkでも動く 実用的な工夫 – 局所最適にならないように初期値をいい感じにばらす – 最初にソートしておく – Learninig Rate Adjustment https://arxiv.org/abs/1706.02677 ほか2本
Project Hydrogen: Unifying State-of-the-art AI and Big Data in Apache Spark(1/2) https://databricks.com/session/databricks-keynote-2
Project Hydrogen: Unifying State-of-the-art AI and Big Data in Apache Spark(2/2) • PrepとAIのワークロードを同じ環境で扱えるようにしたい – これまでのSparkとかで普通にやると筋が悪い – AIのワークロードは自明に並列化できない – タスク並列というかタスク間で勾配を交換したりするのでリ カバリが複雑 • それ用のスケジューラーがHydrogen – タスク並列をいい感じに扱うGang Schedulerというのをつ くった – タスク並列のあとのデータフレームにバリアをいれて境界を 表現するとそのままいい感じにやってくれるようにしている – https://issues.apache.org/jira/browse/SPARK-24374
The Future of AI and Security(1/3) https://databricks.com/session/keynote-from-dawn-song
The Future of AI and Security(2/3) • 自動運転に対する Adversarial Attackみた いなのもセキュリティ的 な問題になる • ←は、ちょっとしたノイ ズを入れると人間の認知 とモデルの出力が乖離す る結果を生み出すことが できることを応用した攻 撃の例
The Future of AI and Security(3/3) • コードの検証・秘密計算・差分 プライバシーでプラットフォー ムをつくればよい • Uberが差分プライバシーを検 証してたりする – https://github.com/uber /sql-differential-privacy – NNに適用した例も？ • 他にもいくつかのプロジェクト が紹介されているので、ここか ら色々辿るのも良さそう
Infrastructure for the Complete ML Lifecycle(1/5) https://databricks.com/session/unifying-data-and-ai-for-better-data-products
Infrastructure for the Complete ML Lifecycle(2/5) • • これまでのソフトウェア開発とML/モ デル開発の違い – Prep/Training/Deploy/Raw Dataのサイクルからなる – データがいろんな場所がある、い ろんなツールを組み合わせる必要 がある – おおむねすべてのプロセスでス ケーラビリティが問題になる 課題感の例 – モデルになった元のデータをあと から確認する方法がない – 別のチームがやった結果を追試す る方法がない
Infrastructure for the Complete ML Lifecycle(3/5) • • • 各社そういう問題意識でそれぞれ MLaaSとかPlatformをつくってい る だいたいはPrep /Training /Deploy の標準化をやっている が、アルゴリズムやフレームワー クに制約があるし、その会社でし かつかえない
Infrastructure for the Complete ML Lifecycle(4/5) • • • そこでMLFlow – ML PlatformをOSSにしたやつ – プロセスを支援する力の向き のニュアンスはJenkinsっぽい 「一人からでも使えてエンタープ ライズのユースケースにも適合さ せられる」のがいいところ – これもJenkinsっぽさ Tracking /Project/Modelの3つの コンポーネントで構成されている
Infrastructure for the Complete ML Lifecycle(5/5) • Tracking – どのソースがどういうパラメーターで結果を だしたのか記録できる – Plotの画像とかModelとかも残せる • Project – 実行環境を抽象化してくれる（ローカルでも クラウドでも動かせるようになる設定ファイ ルコンパイラ的なもの）ので、追試が簡単に なる – “mlflow run gitのURL”で実行することができ る – 実装とチューニングの役割を分離できるとい う効果もありそうだが、実用的か？ • Model – いろんなフォーマットにモデルを出力できる DockerとかSpark（Batch/Streaming）とか – 配信環境へのモデルファイルのデプロイを支 援してくれるもの（モデルに対するAPIをそろ えてくれる）
TuneIn: How to Get Your Hadoop/Spark Jobs Tuned While You’re Sleeping(1/2) https://databricks.com/session/tunein-how-to-get-your-hadoop-spark-jobs-tuned-while-you-are-sleeping
TuneIn: How to Get Your Hadoop/Spark Jobs Tuned While You’re Sleeping(2/2) • Dr.Elephant上に自動チューニングの機能をつくった – https://github.com/linkedin/dr-elephant/wiki/Auto-Tuning – https://github.com/linkedin/dr-elephant/pull/338/ • これまでのDr.Elephantだとアドバイスをみてどうするか考えないとい けないので、 – パフォーマンスチューニングできる/やってくれる高機能な人間が いないとどうしようもない – 動かしたジョブのデータをつかって主にメモリ周りのチューニング をして20%くらいリソース使用量（メモリ）をさげれている • 自動チューニングのアルゴリズムはPSO – Particle Swarm Optimizationをつかっている – 試行回数を増やせる問題設定ではないのでそこそこ安定するし収束 も早いのが採用理由
Extending Spark SQL API with Easier to Use Array Types Operations(1/2) https://databricks.com/session/extending-spark-sql-api-with-easier-to-use-array-types-operations
Extending Spark SQL API with Easier to Use Array Types Operations(2/2) • • • • ArrayをあつかうUDFをたくさん作っ たという話、SPARK-23736 など （2.4.xで入るとのこと） データレイクはいってきてしまうJSON の入れ子が複雑だとステージが爆発し て死ぬのを防ぎたいというモチベー ション MDS( https://github.com/yahoojap an/multiple-dimension-spread )は読 まない方法を考えてるのに対して、読 んだ後の効率化を考えてるので相互補 完的でもなさそう 日本人コミッタ （ueshin/kiszk/maropu）がレビュー したようでありがとうって言われてた
Continuous Processing in Structured Streaming(1/3) https://databricks.com/session/continuous-processing-in-structured-streaming
Continuous Processing in Structured Streaming(2/3) • イントロダクション的な感じ – https://databricks.com/blog/2018/03/20/lowlatency-continuous-processing-mode-instructured-streaming-in-apache-spark-2-3-0.html とだいたい同じ • DStreamとStructured Streamingの違いを説明するとい うようなニュアンスが強かった • 大部屋だけど結構盛況していた
Continuous Processing in Structured Streaming(3/3) • Microbatch – DStreamの設計 – 小さいバッチでまとめて処理 – Event Time vs Arrival Time の差が大きくなることがある • Continuous – Structured Streamingの設計 – 逐次で処理 – CheckpointingはChandyLamport
A Deep Dive into Stateful Stream Processing in Structured Streaming https://databricks.com/session/a-deep-dive-into-stateful-stream-processing-in-structured-streaming
A Deep Dive into Stateful Stream Processing in Structured Streaming • モダンなストリーム処理エンジン（1.0以降のStormを含 む）とそんなに変わらない感じ • その辺との違いでいうと、基本的にSQLで表現できるアプ リケーションを作らせる感じ – 表現力的にSQLだとダメなやつはmapGroupWithState https://databricks.com/blog/2017/10/17/arbitrary -stateful-processing-in-apache-sparks-structuredstreaming.html で戦う – イメージ的にはPigとかAsakusa Frameworkの CoGroup
Flare and TensorFlare: Native Compilation for Spark and TensorFlow Pipelines(1/2) https://databricks.com/session/flare-and-tensorflare-native-compilation-for-spark-and-tensorflow-pipelines
Flare and TensorFlare: Native Compilation for Spark and TensorFlow Pipelines(2/2) • SparkでDataFrameをつくるところ実行時コード生成が遅 いのを解消するよう再実装したもの – ベンチで使ってるハードウェアは1TBメモリ /64threadsとかでモダンな感じ – NUMA-awareでもあるのでナウい • TFよりもDataFrameを置き換えて普通にSparkSQLがはや くなるのがよさげにみえた – いまのところResearch ProductでSingle Nodeでしか うごかないので、データ量が十分小さいなら、ではある – 雑にいうとHiveに対するImpalaみたいな感動があった
Model Parallelism in Spark ML Cross-Validation(1/2) https://databricks.com/session/model-parallelism-in-spark-ml-cross-validation
Model Parallelism in Spark ML Cross-Validation(1/2) • 2.3でCV並列を書きやすくしたやつ – https://developer.ibm.com/code/2018/04/11/mod el-parallelism-for-ml-tuning-with-apache-spark/ • 計算機資源が十分に余ってるならうれしい系（なくても細 く長く動かすんだろうけど） – パラメーターの探索順序を木構造にして枝刈りするやつ を実装中
Deploying and Monitoring Heterogeneous Machine Learning Applications with Clipper https://databricks.com/session/deploying-and-monitoring-heterogeneous-machine-learning-applications-with-clipper
Deploying and Monitoring Heterogeneous Machine Learning Applications with Clipper • • DBにモデルを入れておくアプローチに は良し悪しがある – オンラインアプリケーションに とっては普通の構成でレイテンシ も低くできる – モデル全体をDBとかに入れ込んで おくのでいちいちつくらないとい けないし、モデルの更新も大変 モデル（ファイル）をコンテナに入れ るアプローチにも良し悪しがある – 割と簡単にできる – モデル（ファイル）を理解してい る人がコードを書かないといけな いとかがつらみ
Deploying and Monitoring Heterogeneous Machine Learning Applications with Clipper • • • Clipperはいいとこ取りで、モデルファ イルの差異を吸収する中間層として機 能するのでモデルファイルのフォー マット一般に使えるようにした（アプ ローチはコンテナを使うほうに近い） Prediction実行時の効率は Caching/Batchingでカバーしていて、 スループット・レイテンシ共にTFのモ デルをTF Servingでやるのとそんなに 変わらない結果も出ている 複数のモデルが扱えるおまけとして、 バンディットでモデル選択ができたり もする 下図は https://www.slideshare.net/databricks/clipper-a-lowlatency-online-prediction-serving-system
1. 2. 3. 4. 5. 自己紹介 出張の模様 Spark+AI Summitから SIGMOD/PODSから 所感など
SIGMOD/PODSから 1. 2. 3. 4. SIGMOD/PODSと併催ワークショップで出席したもの How Persistent Memory Changes the Server Environment Kubernetes and the New Cloud P-Store: An Elastic Database System with Predictive Provisioning 5. TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time 6. Query-based Workload Forecasting for Self-Driving Database Management Systems 7. そのほか興味深かったトピック
SIGMOD/PODSと併催ワークショップで出席したもの HILDA （併催ワークショップ） DaMoN （併催ワークショップ） SIGMOD/PODS DEEM （併催ワークショップ） • Workshop on Human-In-the-Loop Data Analytics • http://hilda.io/2018/ • Data Management on New Hardware • https://sites.google.com/view/damon20 18 • is a leading international forum for database researchers, practitioners, developers, and users to explore cutting-edge ideas and results, and to exchange techniques, tools, and experiences. • Data Management for End-to-End ML • http://deem-workshop.org
How Persistent Memory Changes the Server Environment(1/5) https://drive.google.com/file/d/1A-E23uJK_tP-jcnS1iJ-1BojzuF9VQGs/view
How Persistent Memory Changes the Server Environment(2/5) • • • • NAND SSDで4KB/readに 90microsecくらいかかる Driverとかの問題でもない、ハー ドウェアのメディアとしての性質 Optaneは4KB/readで 15microsecくらい、DIMMなら数 mirocosecとか なので、だいたい間くらいのレイ テンシで電源切ってもデータが消 えない性質が手に入る
How Persistent Memory Changes the Server Environment(3/5) • • • • 起動後にDRAMにコピーしなくて もいい DMA/RDMAをやったときに即時 に永続化できる “Warm Cache”になるのでロード しなくてもよい DBの再起動が 2100s->17.5s で できるくらいのインパクト
How Persistent Memory Changes the Server Environment(4/5) • • • • ソフトウェアからの使いかた は、ネイティブなライ ブラリから行くかファイルシステムのエミュレー ションをするレイヤから使う感じ 前者は http://pmem.io/pmdk/ とか https://github.com/memkind/memkind からを 使う – ロックとかトランザクションとかもこのへん のライブラリでサポートしている – 電源が切れた場合とスレッドの原子性を両方 気にして書く必要があって独特の雰囲気があ る模様 – libpmemojbをつかうとRDMAでpersistentな レプリケーションがつくれる 後者は特に工夫はいらないが、低レイテンシのSSD として使える感じになるだけでうまみはなさげ また、Volatileなメモリとして使えるが、メモリ空 間は大きくなる可能性がある（理論上の？最大6TB くらいまではいけるはずらしい）けどレイテンシで 負けるようなのでユースケースあるかは？
How Persistent Memory Changes the Server Environment(5/5) • Cassandraで使えるようにした例 – Cassandraの中身より下をpmemawareにする実装で、上位のAPI は変更なしでいける
P-Store: An Elastic Database System with Predictive Provisioning • 概要 感想 • • E-Store(Elastic-Store)というのを過去に作っていて、ワークロードに あわせてノード数を最適化できるShared-NothingなDB的なものをつ くっていたが、ワークロードが増えるタイミングでレイテンシがスパイ クする問題があった ワークロードを予測してノードをいい感じに増減させるのがP-Store 予測につかってるアルゴリズムは論文を読めというありがたいお言葉を 頂戴した • P-Storeでも使うノード数がワークロードに合わせてスパ イクしてて、うーんって感じもする（ダマシに弱いアル ゴを見たような気分） • 評価モデルが汎用性高く設計されているようにみえて、 統計学の援用に可能性を感じるところ
TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time https://dl.acm.org/citation.cfm?id=3190659
TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time 概要 • Alibaba CloudのデータベースサービスでDBの障害を検 出するシステムを作った話 • 外れ値の扱いがロバストになるので障害の検知にCauchy Distributionをつかっている • 感想 • コーシー分布とかはナイーブにつかってもシステム分析だと 役に立ちそうで、データ集めるのがつらかったとかエンジニ アリングの話も多分にありこの辺の領域では参考になりそう 余談ですがRDBMS関連のサービスはアリババクラウドだと "RDS"とゆってるらしい…
Query-based Workload Forecasting for Self-Driving Database Management Systems https://dl.acm.org/citation.cfm?id=3196908
Query-based Workload Forecasting for Self-Driving Database Management Systems • 概要 • • 感想 到着するクエリを予測することによって、ワークロードの予 測をクエリからやるはなし 実行されるクエリからPrepared Statementになってるよう な感じのやつを生成することによってテンプレート化 テンプレート化したクエリをクラスタリングして、クラスタ ごと予測を分ける • 上記の前処理の工夫とか、本論で述べられている時間軸 と時間の密度で予測精度を比べる検討など実用的にも参 考になる印象
そのほか興味深かったトピック HILDA 1. Evaluating Visual Data Analysis Systems: A Discussion Report （併催ワークショップ） 2. Interactive Visual Analytics for Simpson’s Paradox Detection DaMoN 3. 4. Active Heterogeneous Hardware and its Impact on System Design Make the Most out of Your SIMD Investments: Counter Control Flow Divergence in Compiled Query Pipelines 5. (Keynote) How Can Reasoners Simplify Database Querying (And Why Haven't They Done It Yet)? 6. 7. 8. 9. 10. (Keynote) Machine Learning for Data Management: Problems and Solutions (Keynote) Query Processing and Optimization in Modern Database Systems (Award) The Hive and PIG database System (Award) Serializable Isolation for Snapshot Databases Computation Reuse in Analytics Job Service at Microsoft 11. 12. 13. 14. RUSHMON: Real-time Isolation Anomalies Monitoring Query Processing and Optimizationin Modern Database Systems Bias in OLAP Queries: Detection, Explanation, and Removal (Tutorial) Algorithmic Aspects of Parallel Query Processing 15. Data Science ≠ Machine Learning: Some Thoughts on the Role of Data Management in the new AI-Tsunami 16. Accelerating Human-in-the-loop Machine Learning: Challenges and Opportunities （併催ワークショップ） SIGMOD/PODS DEEM （併催ワークショップ）
1. 2. 3. 4. 5. 自己紹介 出張の模様 Spark+AI Summitから SIGMOD/PODSから 所感など
所感など(1/2) • SAIS • • • SIGMOD • • D社は共同研究やインターンをやっていたり、ドメインエキスパート とデータの人を結びつけたり、 Hyperscale vs HPCギャップを埋め ようとしたり、さすがは”Unified Analytics”って感じ Horovodとかも西海岸コミュニティの強さがありそうで、DNNでさ んざん言われてるけど進化のスピードがとてつもなくはやいと再認 識 pysparkの辛みとかSparkはJSON PerserとかSparkのJava9対応が 凶悪とかいろんなこぼれ話があった 計算論理周りの話題が難しかった（単なる不勉強ではある が・・・） カンファレンスの指向性にあわないトピックがrejectされ る問題（データベースへの計算論理への援用、SysMLっぽ いやつなど）はたいへんそうだなあというかんじ 逆に、ハードウェアについてトレンドフォローなトピック はマーケットは広そう
所感など(2/2) • Software 2.0的な考え方いろんなものの背景になってきそう – ソースコードからアーティファクトをつくるのがこれまでの ソフトウェア – データからモデルをつくるのがMLのソフトウェア • Software 2.0のアナロジーが通りそうな考え方の例 – ソースコードを不正に操作することによるクラッキングに対 して、データを操作することによるAdversarial Attack – DevOps（のプロセスの一部）でよく使われるJenkinsに対し て、MLOps （のプロセスの一部）を支援するMLFlow • 今の状況をモダンなソフトウェア開発のような洗練されたアプ ローチについていま検討しているとみることもできそう
EOP