https://connpass.com/event/94361/

1. SAIS/SIGMOD参加報告
SAIS/DWS2018報告会@Yahoo! JAPAN
2018/07/20
Shingo Furuyama

2. 1. 自己紹介
2. 出張の模様
3. Spark+AI Summitから
4. SIGMOD/PODSから
5. 所感など

3. 2007 Simplex Technology で金融まわりのいろいろ
2011 ノーチラステクノロジーズで業務バッチ on Hadoop
-- ここからYahoo! JAPAN
2014 金融まわりのエンジニア&BD/DDなどいろいろ
2016 データプラットフォーム周りの部長などいろいろ
2018 データプラットフォーム周りのリサーチなどいろいろ
http://jp.linkedin.com/in/shingofuruyama
自己紹介

4. 1. 自己紹介
2. 出張の模様
3. Spark+AI Summitから
4. SIGMOD/PODSから
5. 所感など

5. 出張の模様 - SAIS

6. 出張の模様 - SIDMOD/PODS

7. 1. 自己紹介
2. 出張の模様
3. Spark+AI Summitから
4. SIGMOD/PODSから
5. 所感など

8. 1. Understanding Parallelization of Machine Learning Algorithms in Apache Spark
2. 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
Spark+AI Summitから

9. Understanding Parallelization of Machine Learning
Algorithms in Apache Spark(1/2)
https://databricks.com/session/bay-area-apache-spark-meetup

10. 戦略1
データ並列で頑張って並列化
できないところはあきらめる
戦略2
全部データ並列で頑張る
戦略3
タスク並列で頑張る
• 並列化できないアルゴリズムを使うときもこれ
• DataFrameをPandasにするのは簡単なので、
前処理Sparkで抽出したデータを1ノードに
もってって好きなアルゴリズムで戦う
• Horovod/XGBoost/H2Oあたりをつかって
る場合はパイプライン全体を並列化できる
• キャッシュをうまく使うほうが効率がいいこ
とが多い
• 2.3でCV並列が簡単になったのでそれをつか
うとか（のちのセッションで紹介）
Understanding Parallelization of Machine Learning
Algorithms in Apache Spark(2/2)

11. Horovod: Uber’s Open Source Distributed Deep Learning
Framework for TensorFlow(1/4)
https://databricks.com/session/bay-area-apache-spark-meetup

12. • mxnetとかKerasにならぶくらいには
メジャーになってるっぽい
• トレーニングでも軽く触れられてて
「それ全員知ってる」みたいな位置づ
け
• 「Uberの分散学習はHorovodだけで
やっていて、一日かかかってた学習が
一時間になるくらいのインパクトがあ
る」とのこと
• https://www.slideshare.net/databri
cks/horovod-ubers-open-source-
distributed-deep-learning-
framework-for-tensorflow
Horovod: Uber’s Open Source Distributed Deep Learning
Framework for TensorFlow(2/4)

13. • TensorFlow/Kerasなどを使ったシン
グルノードでの学習を行うコードを、
プログラムを書き換えずに
（Parameter Serverを使わずに）分散
学習をできるように変換してくれる
• MPIのアナロジーが使われている（パ
ラメーター交換でMPIを使うこともで
きるが、なくても動く）
Horovod: Uber’s Open Source Distributed Deep Learning
Framework for TensorFlow(3/4)

14. • 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本
Horovod: Uber’s Open Source Distributed Deep Learning
Framework for TensorFlow(4/4)

15. Project Hydrogen: Unifying State-of-the-art AI and Big
Data in Apache Spark(1/2)
https://databricks.com/session/databricks-keynote-2

16. • PrepとAIのワークロードを同じ環境で扱えるようにしたい
– これまでのSparkとかで普通にやると筋が悪い
– AIのワークロードは自明に並列化できない
– タスク並列というかタスク間で勾配を交換したりするのでリ
カバリが複雑
• それ用のスケジューラーがHydrogen
– タスク並列をいい感じに扱うGang Schedulerというのをつ
くった
– タスク並列のあとのデータフレームにバリアをいれて境界を
表現するとそのままいい感じにやってくれるようにしている
– https://issues.apache.org/jira/browse/SPARK-24374
Project Hydrogen: Unifying State-of-the-art AI and Big
Data in Apache Spark(2/2)

17. The Future of AI and Security(1/3)
https://databricks.com/session/keynote-from-dawn-song

18. • 自動運転に対する
Adversarial Attackみた
いなのもセキュリティ的
な問題になる
• ←は、ちょっとしたノイ
ズを入れると人間の認知
とモデルの出力が乖離す
る結果を生み出すことが
できることを応用した攻
撃の例
The Future of AI and Security(2/3)

19. • コードの検証・秘密計算・差分
プライバシーでプラットフォー
ムをつくればよい
• Uberが差分プライバシーを検
証してたりする
– https://github.com/uber
/sql-differential-privacy
– NNに適用した例も？
• 他にもいくつかのプロジェクト
が紹介されているので、ここか
ら色々辿るのも良さそう
The Future of AI and Security(3/3)

20. Infrastructure for the Complete ML Lifecycle(1/5)
https://databricks.com/session/unifying-data-and-ai-for-better-data-products

21. • これまでのソフトウェア開発とML/モ
デル開発の違い
– Prep/Training/Deploy/Raw
Dataのサイクルからなる
– データがいろんな場所がある、い
ろんなツールを組み合わせる必要
がある
– おおむねすべてのプロセスでス
ケーラビリティが問題になる
• 課題感の例
– モデルになった元のデータをあと
から確認する方法がない
– 別のチームがやった結果を追試す
る方法がない
Infrastructure for the Complete ML Lifecycle(2/5)

22. • 各社そういう問題意識でそれぞれ
MLaaSとかPlatformをつくってい
る
• だいたいはPrep/Training/Deploy
の標準化をやっている
• が、アルゴリズムやフレームワー
クに制約があるし、その会社でし
かつかえない
Infrastructure for the Complete ML Lifecycle(3/5)

23. • そこでMLFlow
– ML PlatformをOSSにしたやつ
– プロセスを支援する力の向き
のニュアンスはJenkinsっぽい
• 「一人からでも使えてエンタープ
ライズのユースケースにも適合さ
せられる」のがいいところ
– これもJenkinsっぽさ
• Tracking/Project/Modelの3つの
コンポーネントで構成されている
Infrastructure for the Complete ML Lifecycle(4/5)

24. • Tracking
– どのソースがどういうパラメーターで結果を
だしたのか記録できる
– Plotの画像とかModelとかも残せる
• Project
– 実行環境を抽象化してくれる（ローカルでも
クラウドでも動かせるようになる設定ファイ
ルコンパイラ的なもの）ので、追試が簡単に
なる
– “mlflow run gitのURL”で実行することができ
る
– 実装とチューニングの役割を分離できるとい
う効果もありそうだが、実用的か？
• Model
– いろんなフォーマットにモデルを出力できる
DockerとかSpark（Batch/Streaming）とか
– 配信環境へのモデルファイルのデプロイを支
援してくれるもの（モデルに対するAPIをそろ
えてくれる）
Infrastructure for the Complete ML Lifecycle(5/5)

25. 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

26. • 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をつかっている
– 試行回数を増やせる問題設定ではないのでそこそこ安定するし収束
も早いのが採用理由
TuneIn: How to Get Your Hadoop/Spark Jobs Tuned
While You’re Sleeping(2/2)

27. 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

28. • ArrayをあつかうUDFをたくさん作っ
たという話、SPARK-23736 など
（2.4.xで入るとのこと）
• データレイクはいってきてしまうJSON
の入れ子が複雑だとステージが爆発し
て死ぬのを防ぎたいというモチベー
ション
• MDS( https://github.com/yahoojap
an/multiple-dimension-spread )は読
まない方法を考えてるのに対して、読
んだ後の効率化を考えてるので相互補
完的でもなさそう
• 日本人コミッタ
（ueshin/kiszk/maropu）がレビュー
したようでありがとうって言われてた
Extending Spark SQL API with Easier to Use Array Types
Operations(2/2)

29. Continuous Processing in Structured Streaming(1/3)
https://databricks.com/session/continuous-processing-in-structured-streaming

30. • イントロダクション的な感じ
– https://databricks.com/blog/2018/03/20/low-
latency-continuous-processing-mode-in-
structured-streaming-in-apache-spark-2-3-0.html
とだいたい同じ
• DStreamとStructured Streamingの違いを説明するとい
うようなニュアンスが強かった
• 大部屋だけど結構盛況していた
Continuous Processing in Structured Streaming(2/3)

31. • Microbatch
– DStreamの設計
– 小さいバッチでまとめて処理
– Event Time vs Arrival Time
の差が大きくなることがある
• Continuous
– Structured Streamingの設計
– 逐次で処理
– CheckpointingはChandy-
Lamport
Continuous Processing in Structured Streaming(3/3)

32. A Deep Dive into Stateful Stream Processing in
Structured Streaming
https://databricks.com/session/a-deep-dive-into-stateful-stream-processing-in-structured-streaming

33. • モダンなストリーム処理エンジン（1.0以降のStormを含
む）とそんなに変わらない感じ
• その辺との違いでいうと、基本的にSQLで表現できるアプ
リケーションを作らせる感じ
– 表現力的にSQLだとダメなやつはmapGroupWithState
https://databricks.com/blog/2017/10/17/arbitrary
-stateful-processing-in-apache-sparks-structured-
streaming.html で戦う
– イメージ的にはPigとかAsakusa Frameworkの
CoGroup
A Deep Dive into Stateful Stream Processing in
Structured Streaming

34. 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

35. • SparkでDataFrameをつくるところ実行時コード生成が遅
いのを解消するよう再実装したもの
– ベンチで使ってるハードウェアは1TBメモリ
/64threadsとかでモダンな感じ
– NUMA-awareでもあるのでナウい
• TFよりもDataFrameを置き換えて普通にSparkSQLがはや
くなるのがよさげにみえた
– いまのところResearch ProductでSingle Nodeでしか
うごかないので、データ量が十分小さいなら、ではある
– 雑にいうとHiveに対するImpalaみたいな感動があった
Flare and TensorFlare: Native Compilation for Spark and
TensorFlow Pipelines(2/2)

36. Model Parallelism in Spark ML Cross-Validation(1/2)
https://databricks.com/session/model-parallelism-in-spark-ml-cross-validation

37. • 2.3でCV並列を書きやすくしたやつ
– https://developer.ibm.com/code/2018/04/11/mod
el-parallelism-for-ml-tuning-with-apache-spark/
• 計算機資源が十分に余ってるならうれしい系（なくても細
く長く動かすんだろうけど）
– パラメーターの探索順序を木構造にして枝刈りするやつ
を実装中
Model Parallelism in Spark ML Cross-Validation(1/2)

38. Deploying and Monitoring Heterogeneous Machine
Learning Applications with Clipper
https://databricks.com/session/deploying-and-monitoring-heterogeneous-machine-learning-applications-with-clipper

39. • DBにモデルを入れておくアプローチに
は良し悪しがある
– オンラインアプリケーションに
とっては普通の構成でレイテンシ
も低くできる
– モデル全体をDBとかに入れ込んで
おくのでいちいちつくらないとい
けないし、モデルの更新も大変
• モデル（ファイル）をコンテナに入れ
るアプローチにも良し悪しがある
– 割と簡単にできる
– モデル（ファイル）を理解してい
る人がコードを書かないといけな
いとかがつらみ
Deploying and Monitoring Heterogeneous Machine
Learning Applications with Clipper

40. • Clipperはいいとこ取りで、モデルファ
イルの差異を吸収する中間層として機
能するのでモデルファイルのフォー
マット一般に使えるようにした（アプ
ローチはコンテナを使うほうに近い）
• Prediction実行時の効率は
Caching/Batchingでカバーしていて、
スループット・レイテンシ共にTFのモ
デルをTF Servingでやるのとそんなに
変わらない結果も出ている
• 複数のモデルが扱えるおまけとして、
バンディットでモデル選択ができたり
もする
Deploying and Monitoring Heterogeneous Machine
Learning Applications with Clipper
下図は https://www.slideshare.net/databricks/clipper-a-lowlatency-online-prediction-serving-system

41. 1. 自己紹介
2. 出張の模様
3. Spark+AI Summitから
4. SIGMOD/PODSから
5. 所感など

42. 1. SIGMOD/PODSと併催ワークショップで出席したもの
2. How Persistent Memory Changes the Server Environment
3. Kubernetes and the New Cloud
4. 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から

43. HILDA
（併催ワークショップ）
DaMoN
（併催ワークショップ）
SIGMOD/PODS
• 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.
SIGMOD/PODSと併催ワークショップで出席したもの
DEEM
（併催ワークショップ）
• Data Management for End-to-End ML
• http://deem-workshop.org

44. How Persistent Memory Changes the Server
Environment(1/5)
https://drive.google.com/file/d/1A-E23uJK_tP-jcnS1iJ-1BojzuF9VQGs/view

45. How Persistent Memory Changes the Server
Environment(2/5)
• NAND SSDで4KB/readに
90microsecくらいかかる
• Driverとかの問題でもない、ハー
ドウェアのメディアとしての性質
• Optaneは4KB/readで
15microsecくらい、DIMMなら数
mirocosecとか
• なので、だいたい間くらいのレイ
テンシで電源切ってもデータが消
えない性質が手に入る

46. How Persistent Memory Changes the Server
Environment(3/5)
• 起動後にDRAMにコピーしなくて
もいい
• DMA/RDMAをやったときに即時
に永続化できる
• “Warm Cache”になるのでロード
しなくてもよい
• DBの再起動が 2100s->17.5s で
できるくらいのインパクト

47. • ソフトウェアからの使いかた は、ネイティブなライ
ブラリから行くかファイルシステムのエミュレー
ションをするレイヤから使う感じ
• 前者は http://pmem.io/pmdk/ とか
https://github.com/memkind/memkind からを
使う
– ロックとかトランザクションとかもこのへん
のライブラリでサポートしている
– 電源が切れた場合とスレッドの原子性を両方
気にして書く必要があって独特の雰囲気があ
る模様
– libpmemojbをつかうとRDMAでpersistentな
レプリケーションがつくれる
• 後者は特に工夫はいらないが、低レイテンシのSSD
として使える感じになるだけでうまみはなさげ
• また、Volatileなメモリとして使えるが、メモリ空
間は大きくなる可能性がある（理論上の？最大6TB
くらいまではいけるはずらしい）けどレイテンシで
負けるようなのでユースケースあるかは？
How Persistent Memory Changes the Server
Environment(4/5)

48. • Cassandraで使えるようにした例
– Cassandraの中身より下をpmem-
awareにする実装で、上位のAPI
は変更なしでいける
How Persistent Memory Changes the Server
Environment(5/5)

49. 概要
感想
• E-Store(Elastic-Store)というのを過去に作っていて、ワークロードに
あわせてノード数を最適化できるShared-NothingなDB的なものをつ
くっていたが、ワークロードが増えるタイミングでレイテンシがスパイ
クする問題があった
• ワークロードを予測してノードをいい感じに増減させるのがP-Store
• 予測につかってるアルゴリズムは論文を読めというありがたいお言葉を
頂戴した
• P-Storeでも使うノード数がワークロードに合わせてスパ
イクしてて、うーんって感じもする（ダマシに弱いアル
ゴを見たような気分）
• 評価モデルが汎用性高く設計されているようにみえて、
統計学の援用に可能性を感じるところ
P-Store: An Elastic Database System with Predictive
Provisioning

50. 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

51. 概要
感想
• Alibaba CloudのデータベースサービスでDBの障害を検
出するシステムを作った話
• 外れ値の扱いがロバストになるので障害の検知にCauchy
Distributionをつかっている
• コーシー分布とかはナイーブにつかってもシステム分析だと
役に立ちそうで、データ集めるのがつらかったとかエンジニ
アリングの話も多分にありこの辺の領域では参考になりそう
• 余談ですがRDBMS関連のサービスはアリババクラウドだと
"RDS"とゆってるらしい…
TcpRT: Instrument and Diagnostic Analysis System for Service
Quality of Cloud Databases at Massive Scale in Real-time

52. Query-based Workload Forecasting for Self-Driving
Database Management Systems
https://dl.acm.org/citation.cfm?id=3196908

53. 概要
感想
• 到着するクエリを予測することによって、ワークロードの予
測をクエリからやるはなし
• 実行されるクエリからPrepared Statementになってるよう
な感じのやつを生成することによってテンプレート化
• テンプレート化したクエリをクラスタリングして、クラスタ
ごと予測を分ける
• 上記の前処理の工夫とか、本論で述べられている時間軸
と時間の密度で予測精度を比べる検討など実用的にも参
考になる印象
Query-based Workload Forecasting for Self-Driving
Database Management Systems

54. HILDA
（併催ワークショップ）
DaMoN
（併催ワークショップ）
SIGMOD/PODS
1. Evaluating Visual Data Analysis Systems: A Discussion Report
2. Interactive Visual Analytics for Simpson’s Paradox Detection
3. Active Heterogeneous Hardware and its Impact on System Design
4. 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. (Keynote) Machine Learning for Data Management: Problems and Solutions
7. (Keynote) Query Processing and Optimization in Modern Database Systems
8. (Award) The Hive and PIG database System
9. (Award) Serializable Isolation for Snapshot Databases
10. Computation Reuse in Analytics Job Service at Microsoft
11. RUSHMON: Real-time Isolation Anomalies Monitoring
12. Query Processing and Optimizationin Modern Database Systems
13. Bias in OLAP Queries: Detection, Explanation, and Removal
14. (Tutorial) Algorithmic Aspects of Parallel Query Processing
そのほか興味深かったトピック
DEEM
（併催ワークショップ）
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

55. 1. 自己紹介
2. 出張の模様
3. Spark+AI Summitから
4. SIGMOD/PODSから
5. 所感など

56. SAIS
SIGMOD
• D社は共同研究やインターンをやっていたり、ドメインエキスパート
とデータの人を結びつけたり、 Hyperscale vs HPCギャップを埋め
ようとしたり、さすがは”Unified Analytics”って感じ
• Horovodとかも西海岸コミュニティの強さがありそうで、DNNでさ
んざん言われてるけど進化のスピードがとてつもなくはやいと再認
識
• pysparkの辛みとかSparkはJSON PerserとかSparkのJava9対応が
凶悪とかいろんなこぼれ話があった
• 計算論理周りの話題が難しかった（単なる不勉強ではある
が・・・）
• カンファレンスの指向性にあわないトピックがrejectされ
る問題（データベースへの計算論理への援用、SysMLっぽ
いやつなど）はたいへんそうだなあというかんじ
• 逆に、ハードウェアについてトレンドフォローなトピック
はマーケットは広そう
所感など(1/2)

57. • Software 2.0的な考え方いろんなものの背景になってきそう
– ソースコードからアーティファクトをつくるのがこれまでの
ソフトウェア
– データからモデルをつくるのがMLのソフトウェア
• Software 2.0のアナロジーが通りそうな考え方の例
– ソースコードを不正に操作することによるクラッキングに対
して、データを操作することによるAdversarial Attack
– DevOps（のプロセスの一部）でよく使われるJenkinsに対し
て、MLOps （のプロセスの一部）を支援するMLFlow
• 今の状況をモダンなソフトウェア開発のような洗練されたアプ
ローチについていま検討しているとみることもできそう
所感など(2/2)

58. EOP