Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

7,761 views

Published on

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

鈴木 由宇 (株式会社IHI)
土橋 昌 (株式会社NTTデータ)

▼イベントページ
http://hadoop.apache.jp/hcj2016-program/
http://hcj2016.eventbrite.com/

Published in: Technology
  • Be the first to comment

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

  1. 1. Sparkによる GISデータを題材とした時系列データ処理 Copyright © 2016 IHI Corporation All Rights Reserved. 2016.02.08 鈴木 由宇 (株式会社IHI) 土橋 昌 (株式会社NTTデータ) Hadoop / Spark Conference Japan 2016
  2. 2. Copyright © 2016 IHI Corporation All Rights Reserved. 2 鈴木 由宇(株式会社IHI)  異常診断アルゴリズム開発など製品 データ利活用に従事  情報システム部 情報科学技術グ ループ所属 土橋 昌(株式会社NTTデータ)  Hadoop、Spark、Stormなど分散処 理を中心とした開発、研究に従事  OSSプロフェッショナルサービス Strata + Hadoop World Singapore でも登壇しました 自己紹介
  3. 3. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 3 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  4. 4. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 4 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  5. 5. Copyright © 2016 IHI Corporation All Rights Reserved. 1. 背景と目的 IHIにおけるデータ収集・データ解析 5 主な利用目的 :  メンテナンス (異常診断を含む)  製品設計へのフィードバック 製品のセンサデータ GISデータ 主な利用目的:  新サービス開発 Control System Mobile phone Customer IHI PC PC PDA 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
  6. 6. Copyright © 2016 IHI Corporation All Rights Reserved. 1. 背景と目的 IHIにおけるデータ収集・データ解析 6 センサデータおよびGISデータ = 多変量時系列データ GISデータ 移動体A 移動体B 移動体A 移動体B • 経度 • 緯度 • 速度 … センサデータ 製品A 製品B 製品A 製品B • 圧力 • 温度 • 流量 …
  7. 7. Copyright © 2016 IHI Corporation All Rights Reserved. 1. 背景と目的 IHIにおけるデータ収集・データ解析 7 ILIPSによりデータの収集・蓄積は進展 データの蓄積 ⇒ 大規模データの分析・活用 大規模データの分析・活用のための基盤が必要
  8. 8. Copyright © 2016 IHI Corporation All Rights Reserved. 1. 背景と目的 HadoopおよびSparkに対する期待 8 スケーラビリティ オンメモリ処理により,実用的 な処理時間で計算を行う (特 に機械システムの異常診断)。 性能 DataFrame,MLlib(機械 学習)など豊富なライブラリによ り,IHI既存のアルゴリズム実 装が容易になる。  IHIでは,分析にはPython およびRを使用。 柔軟性
  9. 9. 時刻 Copyright © 2016 IHI Corporation All Rights Reserved. 1. 背景と目的 IHIにおける時系列データ処理の重要性 9  本検討の目的 : Sparkを用いて時系列データを処理する際の特徴 を確認する。  本検討では,GISデータを用いて評価を行った。 (多変量)時系列データ Spark ...  データの並び順が非常に重要。  Sparkにおけるいくつかの処理 (shuffleなど)は,データの並び順を 保証しない。  並び順を担保するには,ソートなどの APIが必要。
  10. 10. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 10 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  11. 11. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 使用したGISデータ 11 GISデータの主な項目 :  動的な情報  データ受信時刻  座標(緯度・経度)  速度  静的な情報  移動体ID  移動体の大きさ・種別  目的地  到着予想時刻 図 : GISデータ(ダミーデータ)
  12. 12. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 問題設定 12 港湾の混雑予測にGISデータを活用する。
  13. 13. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 問題設定 13 学習フェーズ 1. 移動体ごとにデータをソートする。 2. 時刻や座標の差分を計算する。 3. 累積和計算を用いて,目的地港 湾までの所要時間を算出する。 4. メッシュごとに所要時間を集計し, 所要時間マップを作成する。 5. 港湾ごとに滞在時間を集計し,滞 在時間分布を作成する。 目的地港湾
  14. 14. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 問題設定 14 予測フェーズ 1. 予測開始時刻を設定する。 2. 所要時間マップ・滞在時間分布を 用いて,移動体ごとの目的地港 湾への到着予想時刻・出発予想 時刻を算出する。 3. 移動体ごとの到着予想時刻・出発 予想時刻を集計し,移動体の数 の時間変化を予測する。 時刻 港湾における移動体の数 目的地港湾 予測開始時刻
  15. 15. Copyright © 2016 IHI Corporation All Rights Reserved. 2. Sparkを用いた時系列データ処理 検証項目: 移動体ごとの処理 15  今回の発表では,「学習 フェーズのステップ1-3」(移動 体ごとの処理)に着目した。  この処理では,データの並び 順が重要になる。 1. 移動体ごとにデータをソートする。 2. 時刻や座標の差分を計算する。 3. 累積和計算を用いて,目的地港 湾までの所要時間を算出する。
  16. 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. 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. 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 列名 データ型
  19. 19. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 19 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  20. 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. 21. Copyright © 2016 IHI Corporation All Rights Reserved. 3. 結果の概要 / Point 1 : 移動体ごとのレコード長の増加 21 結果の概要  計算時間はやや非線形に増加したが,移動体ごとのレコード長が15,000以下の場 合は,計算時間のオーダーが極端に大きくなることは無かった。  IHIにおいて,一度に処理する移動体ごとのレコード数は15,000以下のこ とが多いため,現状ではNumPyによる処理は実用的であると言える。  「複数の移動体にまたがる処理」など,より複雑な処理を行う場合は, NumPyの関数以外の処理方法を検討する必要がある。 IHIにおけるセンサデータ・GISデータ分析の観点
  22. 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. 23. Copyright © 2016 IHI Corporation All Rights Reserved. 3. 結果の概要 / Point 2 : レコード長の偏りに関する比較 23 結果の概要  レコード長の偏りの有無に関係なく,処理時間はほぼ同じだった。  最も大きなレコード長の移動体に関する処理は,処理全体のボトルネックには ならなかった。  「今回用いたデータセットの偏りが小さかったこと」が原因である可能性がある。  分析対象製品データのレコード長は必ずしも全て同じではないが,偏りは小 さい傾向があるので,今回検討した処理方針は実用的であると言える。  メッシュごとの集計処理を行った場合,ある特定のメッシュにレコードが集中し て偏りが極端になった。この場合,このメッシュに関する処理は,処理全体 のボトルネックになった。 IHIにおけるセンサデータ・GISデータ分析の観点
  24. 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. 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データ分析の観点
  26. 26. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 26 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  27. 27. Copyright © 2015 NTT DATA Corporation 27Copyright © 2016 NTT DATA Corporation 27 Sparkによるデータ処理の詳細
  28. 28. 28Copyright © 2016 NTT DATA Corporation CPUインテンシブ NumPyなどのPythonライブ ラリとの連携 行指向、列指向の計算 本アプリケーションのワークロード
  29. 29. 29Copyright © 2016 NTT DATA Corporation CPUインテンシブ NumPyなどのPythonライブ ラリとの連携 行指向、列指向の計算 本アプリケーションのワークロード • レコード件数が多い • ソートされたレコードについて レコード間の関係を計算す る処理が多い
  30. 30. 30Copyright © 2016 NTT DATA Corporation CPUインテンシブ NumPyなどのPythonライブ ラリとの連携 行指向、列指向の計算 本アプリケーションのワークロード • 本のアプリケーションがPython 実装だったため • Pythonだと効率的に記載できる箇所 もあるため
  31. 31. 31Copyright © 2016 NTT DATA Corporation CPUインテンシブ NumPyなどのPythonライブ ラリとの連携 行指向、列指向の計算 本アプリケーションのワークロード 多変量データを様々な軸で処理したい ため、行/列方向の片方だけで閉じない
  32. 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. 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(列指向) 両アプローチの主な特徴
  34. 34. Copyright © 2015 NTT DATA Corporation 34Copyright © 2016 NTT DATA Corporation 34 アプローチ1に関する実施結果
  35. 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. 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. 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. 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. 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. 40. 40Copyright © 2016 NTT DATA Corporation  本ユースケースのロジックの中には、著しいSkewを生じるロジックが一部含まれていた  例えば船舶が通過するエリアごとに集計処理を実施したい場合、今回のユースケースでは 「船舶がよく通るエリア」というものがあり、エリアの分け方やキーを工夫しないとSkewが生じ る。  Skewによる悪影響が生じていることを確認する簡単な方法は?  SparkのUIから確認できるメトリクスやタイムラインビューが便利  対策例  混雑するエリアを分割して扱う 極端にSkewが生じた場合の挙動 時刻 並 列 実 行 さ れ る タ ス ク 群 少数の時間のかかるタスクに引きずられて 全体の処理時間が長時間化している状態
  41. 41. Copyright © 2015 NTT DATA Corporation 41Copyright © 2016 NTT DATA Corporation 41 アプローチ2に関する実施結果
  42. 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. 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. 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. 45. 45Copyright © 2016 NTT DATA Corporation 現実的なユースケースに則ったフィードバックを 実施する。また本プロジェクトでは特に時系列 データの取り扱いに着目する。 Sparkは機能追加の多い活発なプロダクトだ が、安心して利用できるようにする活動も重 要。他の開発者と協力して不具合解消や安 定化に向けた取り組みを積極実施する。 開発コミュニティのメンバとしての貢献方針
  46. 46. Copyright © 2016 IHI Corporation All Rights Reserved. AGENDA 46 1. 背景と目的 2. Sparkを用いた時系列データ処理 3. 結果の概要 4. 結果の詳細 5. まとめと今後の予定
  47. 47. Copyright © 2016 IHI Corporation All Rights Reserved. 5. まとめと今後の予定 まとめ 47  特に,移動体ごとのレコード長が短く,偏りが小さい場合は,NumPyなど Pythonのライブラリで処理が行えた。  ただし,高サンプリングレートのデータなど,レコード長が極端に大きい場合は, 今回検討した手法以外の手法を検討する必要がある。  Sparkは,IHIのGISデータ処理には有用であることが確認できた。  処理時間は短縮され,ソースコードの可読性が高くなった。  ただし,DataFrameの利用を判断する前に,アルゴリズムやデータの保持方 式を考慮することがより重要である。  DataFrameは,IHIにおける分析では有用である可能性が確認できた。  基本的な時系列データ処理について,Sparkの処理能力と特徴を評 価した。  将来のサービス(GISデータを用いた港湾の混雑予測)を想定して,実 装・評価を行った。
  48. 48. Copyright © 2016 IHI Corporation All Rights Reserved. 5. まとめと今後の予定 今後の予定 48 今後は,データ処理基盤としてSparkの活用をさらに加速させ, 各種製品・サービスの高度化,ものづくりの高度化の実現を目指す。

×