[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向

Copyright©2017 NTT corp. All Rights Reserved.
分散並列処理の基本と
分散並列処理系の最近の動向について
小沢健史
NTT Software Innovation Center
2017/5/24

4Copyright©2017 NTT corp. All Rights Reserved.
•小沢健史(Ozawa Tsuyoshi)
•Apache Hadoop Committer/PMC
•Hadoop 徹底入門第2版 Chapter 22(YARN)
•gihyo.jp “Hadoopはどのように動くのか”
Hadoop，Tez，YARN
自己紹介

分析で Excel・DB を
使っている方

•処理するデータがどんどん増える…
•HDD からデータの読み込み
→ データ量に応じて時間がかかってしまう
困ったことはありませんか？
100MB
100GB 100TB
1秒
1000秒
(=16分半)
読み込みで1000000秒!
(=約11日)

•処理するデータがどんどん増える…
•HDD からデータの読み込み
→ データ量に応じて時間がかかってしまう
困ったことはありませんか？
100MB
100GB 100TB
1秒
10000秒
(=1分半)
読み込みで1000000秒!
(=約11日)そこで並列処理！

•計算資源を並べることで速く処理すること
•例
•HDD を10個並べる
並列処理 (Parallel processing)
100 MB/sec
x 10個 = 最大1GB/sec

並列処理の注意どころ (1)
並列処理の効果は処理依存
•ディスクI/Oの割合が
99%
99
1

99%
99
1
1
1
99倍
効果:50倍

99%
99
1
1
1
効果:50倍
99倍
50%
50
50
0.599倍
50

99%
99
1
1
1
99倍
50%
50
50
0.5
効果:約2倍
99倍
50
効果:50倍

拡張性の限界
•値段的限界
L4 L8 L16 L32
$0.5
$1
$2
$4
https://azure.microsoft.com/en-
us/pricing/details/virtual-machines/windows/

拡張性の限界
•値段的限界 •物理的限界
一台の計算機に足せる
ドライブ数に限界
L4 L8 L16 L32
$0.5
$1
$2
$4
https://azure.microsoft.com/en-
us/pricing/details/virtual-machines/windows/

•故障確率が向上
•1日に1%の確率で1つのHDDが壊れると仮定
•64個ドライブのある計算機の場合，
1日に1つ以上ドライブが壊れる確率は
約48%=1 – (0.99 ** 64)

•性能向上率はワークロード次第
•拡張性に限界
並列処理の注意どころまとめ

並列処理の特性

そこで分散処理！

•複数の計算機をまたがって処理すること
•目的は処理の高速化に限らない
分散処理 (Distributed processing)

•例
•異なる計算機2台に同じ計算をさせる
→ 故障しなかった方を採用
計算機1
計算機2
依頼主
投入

•例
計算機1
計算機2
故障
依頼主

•例
計算機1
計算機2
無事回答!依頼主

•データのコピーを複数持つ
•目的
•データへアクセスできる確率を向上させるため
•処理が無事に終わる確率を向上させるため
分散処理でよく行われること

•目的
計算機1
計算機2
書き手
保存しといて
データ

•目的
計算機1
計算機2
書き手コピー
データ
データ

•目的
計算機1
計算機2
データ
データ

•目的
計算機1
計算機2
データ
データ
故障

•目的
計算機1
計算機2
データ
データ
読み手
読みたい

•目的
計算機1
計算機2
データ
データ
読み手
成功！
データ

分散処理の注意どころ (1)
分散のためにオーバヘッドが発生
•1台にコピー •2台にコピー
通信量増大
書き手
計算機
書き手
計算機1 計算機2

•故障時のエラーハンドリング
書き手
データ

書き手
データ
書込要求

書き手
データ
書込応答応答なし

書き手
データ
過負荷で
書き込みに失敗

データ

データ
読み手

データ
読み手
過負荷で
アクセスできず
読込要求

データ
読み手
過負荷で
データがないように
見える！

データ
読み手
過負荷で
見える！
自分でケアするのは大変

データ
読み手
過負荷で
見える！
とても大変！

データ
読み手
過負荷で
見える！
そこで
並列分散処理
基盤

並列処理と分散処理を組み合わせた処理基盤
→ 高速に，故障を意識せずに使える！
並列分散処理基盤

•データを溜めるファイルシステム
データを処理する処理系
•Spark/MapReduce + HDFS など
•データベース
•SQL Server・Amazon Redshift など
最近の並列分散処理基盤
の組み合わせ

なぜFSとDBは分かれているか？

大量のデータを永続的に格納する手段としては，(中略)
OS により提供されるファイルがある．
しかし，ファイルシステムには(中略)問題点があり，こ
れらがデータベースの開発の動機となっている．
データベースシステム・北川博之著 p.2-p.3 より抜粋

大量のデータを永続的に格納する手段としては，(中略)
OS により提供されるファイルがある．
しかし，ファイルシステムには(中略)問題点があり，こ
れらがデータベースの開発の動機となっている．
データベースシステム・北川博之著 p.2-p.3 より抜粋
思想から異なる

ファイルシステムベース
の並列分散処理基盤

•処理系を柔軟に変更可能
ファイルシステムベースの処理系の利点
ファイルシステム
処理系1 処理系2

Hadoop エコシステムで起きていること
FileSystem API
Spark
HDFS
MapReduce

FileSystem API
Spark
HDFS
MapReduce

FileSystem API
Spark
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3

•ファイルシステムの実装が変更可能に
→ クラウドとの相性良い
FileSystem API
Spark
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3

•処理系とファイルシステムが疎結合
→最適化度合いが限定的
ファイルシステムベースの処理系の欠点
FileSystem API
Spark
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3

FileSystem API
Spark
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3

FileSystem API
Spark
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3
最適化のために
やりとりできる
情報が
限られる

代表的な処理系
MapReduce と Spark

•データを分散ファイルシステムから読む
MapReduce
FileSystem API
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3
読出

•ユーザが指定した処理をする
MapReduce
FileSystem API
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3
処理

•ユーザが指定した処理をする
•分散ファイルシステムに結果を書き出し
MapReduce
FileSystem API
HDFS
MapReduce
Azure Data
Lake Store
Amazon S3
書出

•基本は同じ
Spark
FileSystem API
HDFS Azure Data
Lake Store
Amazon S3
Spark
読出

•基本は同じ
Spark
FileSystem API
HDFS Azure Data
Lake Store
Amazon S3
Spark
処理

•基本は同じ
•毎回も書き出さずに，Spark の世界の中で
最適化されたデータ形式で保持が可能
Spark
FileSystem API
HDFS Azure Data
Lake Store
Amazon S3
Spark
結果
保持

•基本は同じ
•毎回も書き出さずに，Spark の世界の中で
最適化されたデータ形式で保持が可能
•最終的には書出
Spark
FileSystem API
HDFS Azure Data
Lake Store
Amazon S3
Spark
書出

データベース

•データ処理とデータ保持部が密結合
データベース
保持部
処理部
データベース

•密結合により，最適化がしやすい
•プログラミングしやすい特性(ACID)をもつ
データベースの利点
保持部
処理部
データベース

•スキーマ(型情報)を予め定義し、それを
並列処理のヒント情報として利用
•分析用DBの場合、列数がかなり多い傾向(30以上)
分析用データベースの概要

→列方向にデータを分割
必要な列のみにアクセス

userId username project …
1 Tsuyoshi Hadoop …
2 Neo Azure …
… … … …

2 Neo Azure …
… … … …
計算機1

2 Neo Azure …
… … … …

•スキーマ変更をする際にはシステムが
しばらく停止しうる
→ データの移動を伴うため
分析用データベースの注意どころ

•スキーマが激しく変化する
•クエリの変化が激しい
→ MapReduce や Spark など
ファイルシステムベースの処理系
•スキーマ変化がまれ
•性能要求が非常に高い
•クエリがある程度決まっている
→ データベース
FSベース処理系/データベースの使い分け

•NTT DATA の例
MapReduce/データベースの使い分け
秒
分
時間
日
Big Data
Processing
応
答
時
間
Size
Online Processing
GB TB PB
Online Batch
Processing
データ
ベース
分析データベース
Hadoop/
Spark
Query & Search
Processing
Enterprise Batch
Processing

最近の動向

•処理速度に対する要求の多様化
•ミドルウェアの増加からくるデータ同期の複雑化
最近の動向 : Hadoop への不満からくる改善

•処理速度に対する要求の多様化
→特化した処理系が出てきた
•ミドルウェアの増加からくるデータ同期の複雑化
→ ハブを担うミドルウェアが出てきた
最近の動向 : Hadoop への不満からくる改善

•超巨大なバッチ処理が「安定して動けば良い」
処理速度に対する要求の多様化

•超巨大なバッチ処理が「安定して動けば良い」
→ もっと色々やりたい！

•速く結果を受け取って，試行錯誤やアクションの
回数を増やしたい
インタラクティブ
クエリ系
• Apache Impala
• Presto
• Hive(LLAP)

•深層学習を高速に動作させたい
クエリ系
• Apache Impala
• Presto
• Hive(LLAP)
深層学習特化
• TensorFlow
• MXNet
• CNTK
• Chainer

•バッチではなく，ストリーミング処理を
高速に動作させたい
クエリ系
• Apache Impala
• Presto
• Hive(LLAP)
深層学習特化
• TensorFlow
• MXNet
• CNTK
• Chainer
ストリーミング
処理系
• Apache Storm
• Spark
Streaming

•ワークロードによる使い分けが普通に
クエリ系
• Apache Impala
• Presto
• Hive(LLAP)
深層学習特化
• TensorFlow
• MXNet
• CNTK
• Chainer
処理系
• Apache Storm
• Spark
Streaming

•ワークロードによる使い分けが普通に
クエリ系
• Apache Impala
• Presto
• Hive(LLAP)
深層学習特化
• TensorFlow
• MXNet
• CNTK
処理系
• Apache Storm
• Spark
Streaming
データ同期が
大変に…

•実際の運用の中で，処理系やサービスの間で
データの同期を複雑に行う必要
ミドルウェアの増加に伴う同期複雑化
推薦エンジン
分析DB Hadoop
検索エンジン

推薦エンジン
分析DB Hadoop
メール通知

推薦エンジン
分析DB Hadoop
メール通知
そこで
Apache
Kafka

•データの「ハブ」の役割
•分散並列の特性を上手く利用し
ボトルネックにならないよう設計されている
Apache Kafka
推薦エンジン
分析DB Hadoop
メール通知
Apache Kafka

•並列処理
•分散処理
•MapReduce系統の処理の特徴
•データベースの特徴
•最近の動向
まとめ

•並列処理
•分散処理
•最近の動向
まとめ

•並列処理
•分散処理
•最近の動向
まとめ
さいごに

•並列処理
•分散処理
•最近の動向
まとめ
分散並列処理が身近に
なってきた

•並列処理
•分散処理
•最近の動向
まとめ
何が何でも
分散処理？

•並列処理
•分散処理
•最近の動向
まとめ
効果が出るかは
問題次第

•並列処理
•分散処理
•最近の動向
まとめ
上手く使いこなして
ビジネスの役に
立ててください

•並列処理
•分散処理
•最近の動向
まとめ
エンジニアの
みなさまの力量に
かかっています！

Azure HDInsight
佐藤直生 (NEO) - @satonaoki

データソース
アプリ
センサー/
デバイス
人
モバイルアプリ
自律
システム
インテリジェンス
データの管理データの蓄積データの分析データの予知
データの可視化
• 多様な種類、
サイズの
データ蓄積
• PB クラスの
データに
対するデータ
ウエアハウス
• 機械学習
• Spark ベース
の分析
• Hadoop
Map
Reduce
活用
• リアルタイム・
イベント処理
• ダッシュボード
データアクション
• オンプレミス/
クラウド間、
クラウド間の
データ移動
• クラウド上に
蓄積した
データの管理
• データ/メッセージ
ストリームの
処理
• ディープ
ラーニング
• ボット
• AI

データソース
アプリ
センサー/
デバイス
人
モバイルアプリ
自律
システム
インテリジェンス
データの管理データの蓄積データの分析データの予知
データの可視化
データアクション

分析
ストレージ
Azure HDInsight
Machine
Learning
Azure Blob Storage
または
Azure Data Lake Store

REALTIME ANALYTICS
BATCH ANALYTICS
INTERACTIVE ANALYTICS
Data Sources Ingest Prepare
(normalize, clean, etc.)
Analyze
(stat analysis, ML, etc.)
Publish
(for programmatic
consumption, BI/visualization)
Consume
(Alerts, Operational Stats,
Insights)
Machine Learning
(Spark + Azure ML)
(Failure and RCA
Predictions)
HDI + ISVs
OLAP for Data
Warehousing
HDI Custom ETL
Aggregate /Partition
Big Data Storage
PowerBI
dashboard
Hive, Spark processing
(Big Data Processing)
Big Data Storage
(Shared with field
Ops, customers,
MIS, and Engineers)
Realtime Machine Learning
(Anomaly Detection)
Azure Data
Lake Store
CosmosDB Azure Blob
Storage
CosmosDB
HDI + ISVs
OLAP for Data
Warehousing

セッションアンケートにご協力ください
➢ 専用アプリからご回答いただけます。
decode 2017
➢ スケジュールビルダーで受講セッションを
登録後、アンケート画面からご回答ください。
➢ アンケートの回答時間はたったの 15 秒です!

Ask the Speaker のご案内
本セッションの詳細は『Ask the Speaker Room』各コーナーカウンタにて
ご説明させていただきます。是非、お立ち寄りください。

[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向

More Related Content

What's hot

Similar to [de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向

More from Naoki (Neo) SATO

[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向