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

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

5. Copyright © 2016 IHI Corporation All Rights Reserved. 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

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

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

11. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理使用したGISデータ 11 GISデータの主な項目 :  動的な情報  データ受信時刻  座標(緯度・経度)  速度  静的な情報  移動体ID  移動体の大きさ・種別  目的地  到着予想時刻図 : GISデータ(ダミーデータ)

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

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

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

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

17. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理検証項目における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が残存

18. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 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 列名データ型

20. Copyright © 2016 IHI Corporation All Rights Reserved. 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]  データサイズが線形に増加した際に，計算時間はやや非線形に増加した。処理時間データサイズ

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

22. Copyright © 2016 IHI Corporation All Rights Reserved. 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) データサイズ[GB] 処理時間[sec] 1航路あたりのレコード数処理時間 : 処理時間 [sec] : データサイズ[GB] 近しい値処理時間処理時間データサイズデータサイズ

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

24. Copyright © 2016 IHI Corporation All Rights Reserved. 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 1航路あたりのレコード数 -13% -46% -39% 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 150000 : PySpark & RDD : PySpark & DataFrame (一部RDD) -16%

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

32. 32Copyright © 2016 NTT DATA Corporation  アプローチ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

33. 33Copyright © 2016 NTT DATA Corporation •良い点 •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（列指向）両アプローチの主な特徴

35. 35Copyright © 2016 NTT DATA Corporation ポイント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 データサイズ[GB] 処理時間[sec] 1航路あたりのレコード数処理時間 x 8.3 x 10.1 x 10.9 : 処理時間 [sec] : データサイズ[GB] 処理時間データサイズ

36. 36Copyright © 2016 NTT DATA Corporation  代表例としてあるスレーブノードのリソース使用量を例示  タスクのタイムライン  リソース消費傾向のまとめ  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コアを計算リソースとして割り当てた

37. 37Copyright © 2016 NTT DATA Corporation  背景：なぜ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 yarn 19638 48.1 0.3 382612 232648 ? S 19:28 2:02 python -m pyspark.daemon (snip) yarn 20614 7.1 0.0 166404 16304 ? S 19:32 0:02 python -m pyspark.daemon yarn 20617 7.0 0.0 166404 16304 ? S 19:32 0:02 python -m pyspark.daemon yarn 20626 0.0 0.0 166252 15660 ? S 19:33 0:00 python -m pyspark.daemon

38. 38Copyright © 2016 NTT DATA Corporation ポイント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) データサイズ[GB] 処理時間[sec] 1航路あたりのレコード数処理時間 : 処理時間 [sec] : データサイズ [GB] 近しい値処理時間処理時間データサイズデータサイズ

39. 39Copyright © 2016 NTT DATA Corporation ポイント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) データサイズ[GB] 処理時間[sec] 1航路あたりのレコード数処理時間 : 処理時間 [sec] : データサイズ [GB] 近しい値処理時間処理時間データサイズデータサイズ Almost the sameProcessing time Data size Skewの影響が小さかったのは1タスクあたりの処理時間が全体の処理時間に対して十分短く、処理の終わったエグゼキュータが順次タスクを実施することで待ち時間がすくなかったため。エグゼキュータのタスクタイムライン

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

42. 42Copyright © 2016 NTT DATA Corporation インプットデータサイズに関する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 1航路あたりのレコード数 -13% -46% -39% 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 150000 : PySpark + RDD : PySpark + DataFrame （一部RDD） -16%

43. 43Copyright © 2016 NTT DATA Corporation  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

44. 44Copyright © 2016 NTT DATA Corporation  今回時系列データ処理に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などを確認することを推奨

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

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

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

Hadoop Conference Japan