Sparkによる GISデータを題材とした時系列データ処理（Hadoop / Spark Conference Japan 2016 講演資料）

Sparkによる
GISデータを題材とした時系列データ処理
Copyright © 2016 IHI Corporation All Rights Reserved.
2016.02.08 鈴木由宇 (株式会社IHI)
土橋昌 (株式会社NTTデータ)
Hadoop / Spark Conference Japan 2016

Copyright © 2016 IHI Corporation All Rights Reserved. 2
鈴木由宇（株式会社ＩＨＩ）
 異常診断アルゴリズム開発など製品
データ利活用に従事
 情報システム部情報科学技術グ
ループ所属
土橋昌（株式会社ＮＴＴデータ）
 Hadoop、Spark、Stormなど分散処
理を中心とした開発、研究に従事
 OSSプロフェッショナルサービス
Strata + Hadoop
World Singapore
でも登壇しました
自己紹介

AGENDA
3
1. 背景と目的
2. Sparkを用いた時系列データ処理
3. 結果の概要
4. 結果の詳細
5. まとめと今後の予定

AGENDA
4
1. 背景と目的
3. 結果の概要
4. 結果の詳細

1. 背景と目的
IHIにおけるデータ収集・データ解析
5
主な利用目的 :
 メンテナンス (異常診断を含む)
 製品設計へのフィードバック
製品のセンサデータ GISデータ
主な利用目的:
 新サービス開発
Control
System
Mobile
phone
Customer
IHI
ＰＣ
ＰＣ
ＰＤＡ
User sideDevice side Common Platform
Server
DB
・Inter net
・Private network
Control
System
Sensor
unit
CU
DCU : Data Collection Unit
CU : Communication Unit
DCU
CUDCU
CUDCU
共通PF

1. 背景と目的
6
センサデータおよびGISデータ = 多変量時系列データ
GISデータ
移動体A
移動体B
移動体A
移動体B
• 経度
• 緯度
• 速度
…
センサデータ
製品A
製品B
製品A
製品B
• 圧力
• 温度
• 流量
…

1. 背景と目的
7
ILIPSによりデータの収集・蓄積は進展
データの蓄積 ⇒ 大規模データの分析・活用
大規模データの分析・活用のための基盤が必要

1. 背景と目的
HadoopおよびSparkに対する期待
8
スケーラビリティ
オンメモリ処理により，実用的
な処理時間で計算を行う (特
に機械システムの異常診断)。
性能
DataFrame，MLlib(機械
学習)など豊富なライブラリによ
り，IHI既存のアルゴリズム実
装が容易になる。
 IHIでは，分析にはPython
およびRを使用。
柔軟性

時刻
1. 背景と目的
IHIにおける時系列データ処理の重要性
9
 本検討の目的 : Sparkを用いて時系列データを処理する際の特徴
を確認する。
 本検討では，GISデータを用いて評価を行った。
(多変量)時系列データ Spark
...
 データの並び順が非常に重要。
 Sparkにおけるいくつかの処理
(shuffleなど)は，データの並び順を
保証しない。
 並び順を担保するには，ソートなどの
APIが必要。

AGENDA
10
1. 背景と目的
3. 結果の概要
4. 結果の詳細

使用したGISデータ
11
GISデータの主な項目 :
 動的な情報
 データ受信時刻
 座標(緯度・経度)
 速度
 静的な情報
 移動体ID
 移動体の大きさ・種別
 目的地
 到着予想時刻
図 : GISデータ(ダミーデータ)

問題設定
12
港湾の混雑予測にGISデータを活用する。

問題設定
13
学習フェーズ
1. 移動体ごとにデータをソートする。
2. 時刻や座標の差分を計算する。
3. 累積和計算を用いて，目的地港
湾までの所要時間を算出する。
4. メッシュごとに所要時間を集計し，
所要時間マップを作成する。
5. 港湾ごとに滞在時間を集計し，滞
在時間分布を作成する。
目的地港湾

問題設定
14
予測フェーズ
1. 予測開始時刻を設定する。
2. 所要時間マップ・滞在時間分布を
用いて，移動体ごとの目的地港
湾への到着予想時刻・出発予想
時刻を算出する。
3. 移動体ごとの到着予想時刻・出発
予想時刻を集計し，移動体の数
の時間変化を予測する。
時刻
港湾における移動体の数
目的地港湾
予測開始時刻

検証項目: 移動体ごとの処理
15
 今回の発表では，「学習
フェーズのステップ1-3」(移動
体ごとの処理)に着目した。
 この処理では，データの並び
順が重要になる。
1. 移動体ごとにデータをソートする。
2. 時刻や座標の差分を計算する。
3. 累積和計算を用いて，目的地港
湾までの所要時間を算出する。

検証項目: 移動体ごとの処理
16
基本方針 : 移動体ごとのレコードを，1つのnumpy.arrayにセットする。
 主な長所
 移動体ごとのレコードの並び順は，ランダムにならない(移動体IDの並び順はラ
ンダムになる可能性がある)。
 NumPyの関数を処理に用いることができる。
 主な短所
 移動体ごとのレコード長については，スケーラビリティが少ない。
RDD
...
時系列
データ
numpy
.array
start goalID1
start goalID2
start goalID3
時刻

検証項目における3つの評価ポイント
17
vs. vs. vs.
移動体ごとのレコード長
に関する比較
移動体ごとのレコード長
を，150, 1,500,
15,000, および
150,000に変化させて
比較した。
レコード長の偏りの有無
に関する比較
移動体ごとのレコード長が
 一定(15,000)
 ばらつきあり(10 ~
30,000)
の2パターンで比較した。
データ保持方式(RDDと
DataFrame)の比較
データ保持方式を
 PySpark & RDD
 PySpark &
DataFrame (※)
の場合で比較した。
Point 1. Point 2. Point3.
RDDRDD RDD RDD RDD
評価ポイント : 以下の3つの条件において，処理時間を評価した。
Data-
Frame
※一部RDDが残存

DataFrameの概要
18
出典 : NTTデータ「Apache Spark入門」，翔泳社
DataFrame : RDBMSのテーブルのように行と名前とデータ型が付与さ
れた列の概念を持つデータ構造。
[“ship01”, “00:00:00”, ...]
[“ship01”, “00:01:00”, ...]
RDD
…
RDDと比べると…
1. 短くて可読性の高いコードでデータ
操作が記述できる。
2. オプティマイザによる最適化が働く。
コードが書きやすく，読みやすい。
実装の詳細より，分析ロジックに集
中できる。
...
...
...
“ship01”
“ship01”
...
00:00:00
00:01:00
...
shipID
(StringType)
time
(TimestampType)
…
...
DataFrame
列名
データ型

AGENDA
19
1. 背景と目的
3. 結果の概要
4. 結果の詳細

3. 結果の概要 / Point 1 : 移動体ごとのレコード長の増加
処理時間
20
45
372
3774
40980
0.06
0.65
6.57
65.8
0.01
0.10
1.00
10.00
100.00
1000.00
1
10
100
1000
10000
100000
150 1500 15000 150000
データサイズ[GB]
処理時間[sec]
1航路あたりのレコード数
処理時間
x 8.3
x 10.1
x 10.9
: 処理時間
[sec]
: データ
サイズ[GB]
 データサイズが線形に増加した際に，計算時間はやや非線形に増加
した。
処理時間
データサイズ

3. 結果の概要 / Point 1 : 移動体ごとのレコード長の増加
21
結果の概要
 計算時間はやや非線形に増加したが，移動体ごとのレコード長が15,000以下の場
合は，計算時間のオーダーが極端に大きくなることは無かった。
 IHIにおいて，一度に処理する移動体ごとのレコード数は15,000以下のこ
とが多いため，現状ではNumPyによる処理は実用的であると言える。
 「複数の移動体にまたがる処理」など，より複雑な処理を行う場合は，
NumPyの関数以外の処理方法を検討する必要がある。
IHIにおけるセンサデータ・GISデータ分析の観点

3. 結果の概要 / Point 2 : レコード長の偏りに関する比較
処理時間
22
 今回のユースケースでは，レコード長の偏りの有無に関係なく，処理
時間はほぼ同じだった。
3774 3762
6.57 6.59
0
2
4
6
8
10
0
1000
2000
3000
4000
5000
15000 30000
(with skew)
処理時間[sec]
処理時間 : 処理時間
[sec]
: データ
サイズ[GB]
近しい値処理時間処理時間
データサイズデータサイズ

3. 結果の概要 / Point 2 : レコード長の偏りに関する比較
23
結果の概要
 レコード長の偏りの有無に関係なく，処理時間はほぼ同じだった。
 最も大きなレコード長の移動体に関する処理は，処理全体のボトルネックには
ならなかった。
 「今回用いたデータセットの偏りが小さかったこと」が原因である可能性がある。
 分析対象製品データのレコード長は必ずしも全て同じではないが，偏りは小
さい傾向があるので，今回検討した処理方針は実用的であると言える。
 メッシュごとの集計処理を行った場合，ある特定のメッシュにレコードが集中し
て偏りが極端になった。この場合，このメッシュに関する処理は，処理全体
のボトルネックになった。

3. 結果の概要 / Point 3 : RDD vs. DataFrame
処理時間
24
 DataFrameによる計算時間の方が，RDDによる計算時間より短
かった。
処理時間[sec]
処理時間
0
5
10
15
20
25
30
35
40
45
50
150
0
50
100
150
200
250
300
350
400
450
500
1500
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
15000
-13%
-46% -39%
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
150000
: PySpark & RDD
: PySpark & DataFrame
(一部RDD)
-16%

3. 結果の概要 / Point 3 : RDD vs. DataFrame
25
結果の概要
 DataFrameによる計算時間の方が，RDDによる計算時間より短かった。
※現実的な問題設定による検証だったため，計算が高速化された要因は複合的
であると考えられる。
⇒計算実行状況を確認しつつ，プログラム開発を進めるべきである。
 SparkのDataFrameは，有用な分析ツールとなりうる。
 DataFrameは，PythonやRユーザにとってなじみ深い。
 DataFrameにより，処理時間は短縮された。
 DataFrameにより，分析用のソースコードが見やすくなった。
 レコード長が大きいデータを処理する際に，DataFrameによる計算が中断
することがあった。
 メモリに関するパラメータを調整する必要があった。

AGENDA
26
1. 背景と目的
3. 結果の概要
4. 結果の詳細

Copyright © 2015 NTT DATA Corporation 27Copyright © 2016 NTT DATA Corporation 27
Sparkによるデータ処理の詳細

28Copyright © 2016 NTT DATA Corporation
CPUインテンシブ
NumPyなどのPythonライブ
ラリとの連携
行指向、列指向の計算
本アプリケーションのワークロード

ラリとの連携
• レコード件数が多い
• ソートされたレコードについて
レコード間の関係を計算す
る処理が多い

ラリとの連携
• 本のアプリケーションがPython
実装だったため
• Pythonだと効率的に記載できる箇所
もあるため

ラリとの連携
多変量データを様々な軸で処理したい
ため、行/列方向の片方だけで閉じない

 アプローチ1: PySpark + RDD
 アプローチ2: PySpark + DataFrame（一部RDD部分が残存）
データフォーマットに対する2種類のアプローチ
RDD
RDD’s record
DataFrame
t
t1 t2 tn
t1
t2
tn
• RDDのレコードにはあるセンサから得られた特定の
期間の時系列データを丸々保持
• 「時刻」は左図の横軸として表現される
• DataFrameのレコードにはある時刻に挙げられた
ひとつのレコードを保持
• DataFrameの各列には、レコードの時刻や
様々な属性情報が保持される
• 「時刻」は左図の縦軸として表現される
NumPy配列内の時系列データ
DataFrameのレコードに時系列データの
レコードを保持
Column Column Column
t

•良い点
•NumPyなどのPythonライブラリを使用しやすい。
•時系列データがひとつのローカルなNumPy配列の変数に含まれるため、並び順が保証される
•RDDによる処理を直接的に記述可能
•注意が必要な点
•長い時刻のデータを扱うのが難しい
•スキーマがないため、複雑なデータ構造を扱う際にリーダビリティが低い
アプローチ1: PySpark + RDD（行指向）
•良い点
•PythonからDataFrameを使用しても実施の処理はJVMから呼び出されるため高速
•Project Tungstenに関する最適化の恩恵を受けられる
•時刻方向のスケーラビリティ
•DataFrameにビルトインの関数（数学的関数や時刻を扱うためのデータ型など）
•注意が必要な点
•DataFrame APIは、NumPyのAPIとかなり形式が異なる
•本プロジェクト実施時点でExperimental扱いのAPIを使用した。SparkにおいてExperimentalは
API仕様が変更される可能性があるため注意が必要。今回は一部不具合にも遭遇した。
アプローチ2: PySpark + DataFrame（列指向）
両アプローチの主な特徴

アプローチ1に関する実施結果

ポイント1: 航路長に関するスケーラビリティ（再掲）
データ処理基盤の観点からのまとめ
• 本ユースケースで目標としていたパフォーマンスは得られた
• データサイズに対する処理時間伸びは、完全に線形とは言い難い
• 処理時間の多くは、NumPy配列などを利用した処理自体に割かれており、
I/Oなどのリソースはあまり使用していなかった
45
372
3774
40980
0.06
0.65
6.57
65.8
0.01
0.10
1.00
10.00
100.00
1000.00
1
10
100
1000
10000
100000
150 1500 15000 150000
処理時間[sec]
処理時間
x 8.3
x 10.1
x 10.9
: 処理時間
[sec]
: データ
サイズ[GB]
処理時間
データサイズ

 代表例としてあるスレーブノードのリソース使用量を例示
 タスクのタイムライン
 リソース消費傾向のまとめ
 Pythonによる演算時にCPUリソースを著しく使用し、計算リソースはよく使用された印象
 PySparkのRDDを用いた計算ではpython.daemonによって使用されるメモリ量の調整に注意
- DataFrameを用いる場合は挙動が異なり、JVMやSpark独自管理のオフヒープ領域を使用
Sparkによる処理を実行中のリソース使用傾向
Metric Min 25th percentile
Media
n
75th percentile Max
Duration 2 s 8 s 11 s 14 s 19 s
Scheduler Delay 3 ms 4 ms 4 ms 5 ms 39 ms
Task Deserialization Time 1 ms 2 ms 2 ms 2 ms 20 ms
GC Time 0 ms 0 ms 0 ms 0 ms 0.1 s
Result Serialization Time 0 ms 0 ms 0 ms 0 ms 1 ms
Getting Result Time 0 ms 0 ms 0 ms 0 ms 0 ms
CPU all CPU io wait Network
タスク実行のメトリクス表
今回は8コア中7コアを計算リソースとして割り当てた

 背景：なぜPythonRDDを最初に利用したのか？
 DataFrameが利用可能な状態になる前に、すでにRDDに慣れていたため
 RDDはコレクションAPIとして考えと直感的であり、RDDレコード内で自由にPythonの処理を記述
できるため、データ分析者にとってはリーズナブルだったため
 PythonRDDを利用して処理を実装すると、スレーブノードでPython向けに起動する
pyspark.daemonというデーモン内で処理される
 pyspark.daemonの例
 オフヒープ領域のための予約しておくspark.yarn.executor.memoryOverhead の値をScala利用
時よりもかなり大きく設定して実行させた
 DataFrameを利用するときはこの限りではない。
PythonRDD利用時のPythonコード実行状況に注意
yarn 19633 0.1 0.0 166252 19528 ? S 19:28 0:00 python -m pyspark.daemon
yarn 19636 49.1 0.3 400336 250372 ? R 19:28 2:05 python -m pyspark.daemon
(snip)

ポイント2: 航路長に関してSkewがある場合の挙動（再掲）
• 今回のワークロードにおいて考えうるSkewの程度では、処理時間全体への影響は小さかった
• 一方で1航路あたりのレコード件数がより大きくなるとSkewによる影響が大きくなる
• 今回はGISデータを取り扱ったが、他のセンサデータを扱う場合、ひとつの時系列データの
件数が今回のユースケースよりも大きくなることもあるので注意が必要
3774 3762
6.57 6.59
0
2
4
6
8
10
0
1000
2000
3000
4000
5000
15000 30000
(with skew)
処理時間[sec]
[sec]
: データサイズ
[GB]

ポイント2: 航路長に関してSkewがある場合の挙動（再掲）
• 今回のワークロードにおいて考えうるSkewの程度では、処理時間全体への影響は小さかった
• 一方で1航路あたりのレコード件数がより大きくなるとSkewによる影響が大きくなる
• 今回はGISデータを取り扱ったが、他のセンサデータを扱う場合、ひとつの時系列データの
件数が今回のユースケースよりも大きくなることもあるので注意が必要
3774 3762
6.57 6.59
0
2
4
6
8
10
0
1000
2000
3000
4000
5000
15000 30000
(with skew)
処理時間[sec]
[sec]
: データサイズ
[GB]
Almost the sameProcessing time
Data size
Skewの影響が小さかったのは1タスクあたりの処理時間が全体
の処理時間に対して十分短く、処理の終わったエグゼキュータ
が順次タスクを実施することで待ち時間がすくなかったため。
エグゼキュータのタスクタイムライン

 本ユースケースのロジックの中には、著しいSkewを生じるロジックが一部含まれていた
 例えば船舶が通過するエリアごとに集計処理を実施したい場合、今回のユースケースでは
「船舶がよく通るエリア」というものがあり、エリアの分け方やキーを工夫しないとSkewが生じ
る。
 Skewによる悪影響が生じていることを確認する簡単な方法は？
 SparkのUIから確認できるメトリクスやタイムラインビューが便利
 対策例
 混雑するエリアを分割して扱う
極端にSkewが生じた場合の挙動
時刻
並
列
実
行
さ
れ
る
タ
ス
ク
群
少数の時間のかかるタスクに引きずられて
全体の処理時間が長時間化している状態

アプローチ2に関する実施結果

インプットデータサイズに関するRDDとDataFrameの処理時間の差異（再掲）
• 多くのケースについてDataFrame、列指向データ形式、および一部Project Tungstenの組み合わせのほうが
性能が良い結果が得られた
• DataFrameの方がアプリケーションのソースコードの可読性が高い
• RDDベースの処理からDataFrameベースの処理に段階的にマイグレート可能だった
• ただしデータフォーマットを行指向から列指向に変えたことにより、ロジック変更を必要とすることもあり、
行指向では不要だったシャッフルによる悪影響もあると考えられる
• Spark1.5時点ではExperimentalの実装を中心に、Spark1.6で改修されたバグ（SPARK-10309、10474）があった
• 新しく追加された機能周りは他のプロダクト同様、自分のユースケースで問題が起きないか注意が必要
処理時間[sec]
処理時間
0
5
10
15
20
25
30
35
40
45
50
150
0
50
100
150
200
250
300
350
400
450
500
1500
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
15000
-13%
-46% -39%
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
150000
: PySpark + RDD
: PySpark + DataFrame （一部RDD）
-16%

 CPU利用傾向は明確に変化（以下、似たような処理をしている箇所）
 PythonRDDの実装とDataFrameの実装を併用する場合はメモリのチューニングに注意
処理実行中のあるスレーブノードリソース消費傾向
3.9min
Python
DataFrame
Tungsten
Pythonデーモンのメモリ領域
を使用する
DataFrameから利用される
JVMヒープやオフヒープ領域
が使用される
6.7min
 アプローチ1: PySpark + RDD  アプローチ2: PySpark + DataFrame
処理時間長い処理時間短い
sysが出ているのがやや気になるが、同じデータサイズでは
DataFrameを活用した方がリソースに余裕が見られた。
これよりも大きなデータサイズでは、DataFrameでもCPUボトルネック再発。
※Spark1.6からメモリ管理機構が大きく変化し、オフヒープ周りのパラメータが追加されている。詳しくは公式ドキュメント、リリースノートを参照
http://spark.apache.org/docs/latest/configuration.html#memory-management

 今回時系列データ処理にSparkを用いてみて現実的な使用感だったか？
 答えはYes. 大規模なデータを処理できる上にAPIが優れていることが特に大きなポイント
 総じて、気に止めておくべき点
Sparkを大規模な時系列データ処理に用いるときのポイント
RDDとDataFrameは、プログラマや分析者から見ると異なる使用感を得る
• RDD APIはコレクションAPIライク、DataFrameはPandas DataFrame APIライク（あるいはSQLライク）こ
れらのAPIは組み合わせて利用可能だが、PySparkの場合は特にメモリ管理に注意が必要
• Spark1.6で追加されたDatasetが成熟すると、より組み合わせやすくなる。
Project TungstenやDataFrameのウィンドウ関数などの新しく追加された機能はパ
ワフルだが、Spark1.5時点ではプロダクション適用に向けて改善が必要だった
• Spark1.6で解決された問題もあるためTungstenやDataFrameの機能を十分に生かすのあらば、なるべく
新しいバージョン利用がオススメ。
Sparkは便利なAPIを多数持っているが、本格的なユースケースには自前でのロ
ジック実装が必要。
• Spark本体に機能追加されることで対応されるもの（時刻を表す型など）もあるが、サードパーティが開発
する関連プロジェクトもあるのでSpark Packagesなどを確認することを推奨

現実的なユースケースに則ったフィードバックを
実施する。また本プロジェクトでは特に時系列
データの取り扱いに着目する。
Sparkは機能追加の多い活発なプロダクトだ
が、安心して利用できるようにする活動も重
要。他の開発者と協力して不具合解消や安
定化に向けた取り組みを積極実施する。
開発コミュニティのメンバとしての貢献方針

AGENDA
46
1. 背景と目的
3. 結果の概要
4. 結果の詳細

まとめ
47
 特に，移動体ごとのレコード長が短く，偏りが小さい場合は，NumPyなど
Pythonのライブラリで処理が行えた。
 ただし，高サンプリングレートのデータなど，レコード長が極端に大きい場合は，
今回検討した手法以外の手法を検討する必要がある。
 Sparkは，IHIのGISデータ処理には有用であることが確認できた。
 処理時間は短縮され，ソースコードの可読性が高くなった。
 ただし，DataFrameの利用を判断する前に，アルゴリズムやデータの保持方
式を考慮することがより重要である。
 DataFrameは，IHIにおける分析では有用である可能性が確認できた。
 基本的な時系列データ処理について，Sparkの処理能力と特徴を評
価した。
 将来のサービス(GISデータを用いた港湾の混雑予測)を想定して，実
装・評価を行った。

今後の予定
48
今後は，データ処理基盤としてSparkの活用をさらに加速させ，
各種製品・サービスの高度化，ものづくりの高度化の実現を目指す。

Sparkによる GISデータを題材とした時系列データ処理（Hadoop / Spark Conference Japan 2016 講演資料）

Sparkによる GISデータを題材とした時系列データ処理（Hadoop / Spark Conference Japan 2016 講演資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Sparkによる GISデータを題材とした時系列データ処理（Hadoop / Spark Conference Japan 2016 講演資料）

Similar to Sparkによる GISデータを題材とした時系列データ処理（Hadoop / Spark Conference Japan 2016 講演資料） (20)

More from Hadoop / Spark Conference Japan

More from Hadoop / Spark Conference Japan (13)

Recently uploaded

Recently uploaded (8)