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 Streamingを活用したシステムの検証結果と設計時のノウハウ

2,081 views

Published on

Spark Streamingを活用したシステムの検証結果と設計時のノウハウ

Published in: Technology
  • Be the first to comment

Spark Streamingを活用したシステムの検証結果と設計時のノウハウ

  1. 1. © Hitachi, Ltd. 2016. All rights reserved. Spark Streamingを活用したシステムの検証結果と 設計時のノウハウ 2016年12月14日 日立製作所 OSSソリューションセンタ 伊藤雅博
  2. 2. 1© Hitachi, Ltd. 2016. All rights reserved. 自己紹介 • 伊藤 雅博 (いとう まさひろ)  所属: 日立製作所 OSSソリューションセンタ  業務: Hadoop/Sparkを中心としたビッグデータ関連 OSSの検証やテクニカルサポート  趣味: ロードバイク Think ITの連載記事: ユースケースで徹底検証! Sparkのビッグデータ処理機能を試す https://thinkit.co.jp/series/5747
  3. 3. 2© Hitachi, Ltd. 2016. All rights reserved. 目次 1. Spark と Spark Streaming の概要 2. Spark Streamingを活用したシステムの検証結果
  4. 4. 3© Hitachi, Ltd. 2016. All rights reserved. 1. Spark と Spark Streaming の概要
  5. 5. 4© Hitachi, Ltd. 2016. All rights reserved. Node Node Stage (インメモリ処理)Stage (インメモリ処理) Job HDFS 1-1. Sparkは並列分散処理フレームワーク • 複数ノードでクラスタを構成し、並列なデータ読み出し・変換/集約処理・書き込みを行う  MapReduceと違い、処理の大半がインメモリで行われるため高速である  分散処理するデータをRDD (Resilient Distributed Dataset: 耐障害性分散データセット) と呼ぶ Task Partition Partition Task Partition Partition Task Partition Partition Task Partition Partition Task Partition Partition Task Partition Partition Partition Partition Partition Partition HDFS Block Block Block Block Block Block データ ソース データ ストア RDDRDD RDD RDD RDD 結合 / 集約 出力 Partition間のデータ交換 (シャッフル) 変換 変換入力 FilesFiles
  6. 6. 5© Hitachi, Ltd. 2016. All rights reserved. 1-2. Sparkを構成するコンポーネント / アプリケーション / 実行基盤 Sparkを構成するコンポーネント Sparkアプリケーション (Scala, Java, Python, R などの言語で記述) Spark Core [インメモリ分散処理エンジン] Spark SQL [SQLクエリエンジン] Spark Streaming [ストリームデータ処理] GraphX [グラフ構造データ処理] MLlib (spark.ml) [機械学習ライブラリ] YARN (Yet Another Resource Negotiator) [クラスタリソース管理] HDFS (Hadoop Distributed File System) [分散ファイルシステム] Hadoop 並列分散処理 フレームワーク 実行基盤 アプリケーション  Sparkは既存のHadoopクラスタ上で動作可能  Spark単体やMesos上での動作も可能
  7. 7. 6© Hitachi, Ltd. 2016. All rights reserved. 1-3. Spark Streaming はストリームデータ処理機能を提供するコンポーネント • マイクロバッチ方式によるストリームデータ処理を実現  数秒から数分ほどの短い間隔で、繰り返しバッチ処理を行ことで、 ニアリアルタイムなデータ処理を実現する • 入力データを一定時間ごとに区切ってRDDとして扱う  時系列に並んだRDDをDStream(Discretized Stream)という呼ぶ  DStream内の各RDDに対して一定時間ごとにバッチ処理を行うことで、 擬似的なストリームデータ処理を実現する DStream RDD RDD RDDRDD 00:00 - 00:01 のデータ 00:01 - 00:02 のデータ 00:02 - 00:03 のデータ データ ソース … 最新1分間の データ 例: 1分間隔でデータを読み込み+各RDDに対するバッチ処理を実行
  8. 8. 7© Hitachi, Ltd. 2016. All rights reserved. Windowオペレーションの例 1-4. Spark Streaming には2種類のオペレーションがある DStream RDD RDD RDD 00:00 - 00:01 のデータ 00:01 - 00:02 のデータ 00:02 - 00:03 のデータ データ ソース RDD 00:03 - 00:04 のデータ データ ストア 最新3分のデータの平均値を計算 状態更新オペレーションの例 DStream RDD RDD RDD 00:00 - 00:01 のデータ 00:01 - 00:02 のデータ 00:02 - 00:03 のデータ データ ソース RDD 00:03 - 00:04 のデータ 過去データの合計値に、最新データの値を加算 平均値 データ ストア 過去の合計値 合計値 追加 更新
  9. 9. 8© Hitachi, Ltd. 2016. All rights reserved. 2. Spark Streamingを活用したシステムの検証結果
  10. 10. 9© Hitachi, Ltd. 2016. All rights reserved. 2-1. 検証シナリオ • 運動リズムにあった音楽を自動選曲する音楽配信サービスを想定  利用者の運動状態に合わせて曲を再生  利用者は身体と音楽の一体感を楽しみながら活動できる 音楽配信サービスモバイルから加速度 などの情報を収集 運動リズムにあった お気に入り曲を配信 検証 範囲 データ収集 運動状態の判定(5秒間隔) 選曲 歩いてる、 走ってる、 階段を上っている、 など6種類 音楽配信
  11. 11. 10© Hitachi, Ltd. 2016. All rights reserved. データ可視化/分析 データ蓄積 2-2. 検証システムをどのようなOSSで構築するか? データソース 並列分散処理FW データ逐次収集 ・Fluentd ・Fluent Bit ・Logstash ・Beats ・Flume-NG クエリエンジン ・Hive ・Impala ・Drill ・SparkSQL ・Presto ・HAWQ データ分析 ・R ・Python バッチ処理 ・Spark ・MapReduce ・Tez ・Flink ファイルシステム ・HDFS 列指向DB ・HBase ・Cassandra ・Kudu 検索エンジン ・Elasticsearch ・Solr データ一括収集(ETL) • Sqoop • Talend • Informatica • Pentaho DI • Embulk システム 管理者 リアルタイム処理 ・Spark Streaming ・Flink ・Storm 時系列DB ・InfluxDB ・Prometheus ・Graphite ・OpenTSDB ドキュメントDB ・MongoDB ・CouchDB 生成データ ・センサデータ ・システムログ ・性能メトリクス ・Webデータ ・業務データ データストア ・RDBMS ・CSVファイル キュー ・Kafka ・ActiveMQ ・RabbitMQ ・Redis データ変換/転送 ・Fluentd ・Logstash ・Kafka Streams 既存システム ダッシュボード ・Kibana ・Grafana ・Tableau ・Pentaho BA ノートブック ・Zeppelin ・Jupyter Note ・Hue OLAPエンジン ・Kylin ・Druid 機械学習ライブラリ • Mahout • MLlib クラスタリソース管理 • YARN • Mesos
  12. 12. 11© Hitachi, Ltd. 2016. All rights reserved. 並列分散処理FW データ可視化/分析 データ蓄積 2-3. 今回の検証で選定したOSS データソース データ逐次収集 ・Fluentd ・Fluent Bit ・Logstash ・Beats ・Flume-NG クエリエンジン ・Hive ・Impala ・Drill ・SparkSQL ・Presto ・HAWQ データ分析 ・R ・Python バッチ処理 ・Spark ・MapReduce ・Tez ・Flink ファイルシステム ・HDFS 列指向DB ・HBase ・Cassandra ・Kudu 検索エンジン ・Elasticsearch ・Solr データ一括収集(ETL) • Sqoop • Talend • Informatica • Pentaho DI • Embulk リアルタイム処理 ・Spark Streaming ・Flink ・Storm 時系列DB ・InfluxDB ・Prometheus ・Graphite ・OpenTSDB ドキュメントDB ・MongoDB ・CouchDB 生成データ ・センサデータ ・システムログ ・性能メトリクス ・Webデータ ・業務データ データストア ・RDBMS ・CSVファイル キュー ・Kafka ・ActiveMQ ・RabbitMQ ・Redis データ変換/転送 ・Fluentd ・Logstash ・Kafka Streams 既存システム ノートブック ・Zeppelin ・Jupyter Note ・Hue OLAPエンジン ・Kylin ・Druid 機械学習ライブラリ • Mahout • MLlib クラスタリソース管理 • YARN • Mesos ソフトウェアバージョン Kafka: 0.9.0.0 Spark(Spark Streaming/MLlib): 1.6.0 Hadoop(YARN/HDFS): 2.6.3 Elasticsearch: 1.7.5 運動状態をリアルタイム に判定処理 データ量の急激な増加に対応 するためキューイング 判定結果の データを蓄積 機械学習モデルでセンサデータ から運動状態を判定 SparkをHadoopクラスタ上で実行 するためにYARN/HDFSを活用 SparkをHadoopクラスタ上で実行 するためにYARN/HDFSを活用 ダッシュボード ・Kibana ・Grafana ・Tableau ・Pentaho BA システム 管理者
  13. 13. 12© Hitachi, Ltd. 2016. All rights reserved. 2-4. 検証システムの処理の流れ • テキストファイルのセンサデータをKafkaへ擬似的にストリーム配信 • Spark Streamingが5秒間隔で運動状態を判定 ストリームデータ処理 Spark Streaming データ配信サーバ Kafka Producer 機械学習ライブラリ MLlib クラスタリソース管理 YARN ファイルシステム HDFS データ配信プログラム(Java)  Kafkaへの配信には書き込み用ライブラリ (Kafka Producer)を使用 運動状態判定Sparkアプリケーション(Scala)  Kafkaからセンサデータを読み出し  センサデータから運動状態を判定  判定には学習済みの機械学習モデルを使用  判定結果はElasticsearchに格納 キュー Kafka Broker 検索エンジン Elasticsearch UCIリポジトリの オープンデータを使用※ センサデータの テキストファイル ※ http://archive.ics.uci.edu/ml/datasets/Human+Activity+Recognition+Using+Smartphones
  14. 14. 13© Hitachi, Ltd. 2016. All rights reserved. Worker Node 2-5. Kafka と Spark Streaming の接続時の注意点(DirectStream方式の場合) SparkはKafkaのPartition数と同数の Taskを自動生成する  Partition単位で並列読み出しが可能  デフォルトは1TaskをCPU1コアで処理 注意点  KafkaのPartition数を、SparkのExecutorに 割り当てたCPUコア数以上に設定すること  Kafkaのパーティション数 = Sparkのタスク数 = Sparkが使用するコア数 となるため、 Kafkaのパーティション数が少ないと、 Sparkに割り当てたコアを使いきれない Partition Partition Partition Partition Topic Broker Node Partition Partition Partition Partition Broker Node Task Partition Kafka Cluster Spark ClusterKafkaクラスタ Topic(仮想的な1個のキュー) を複数のPartitionで構成 Sparkクラスタ TopicをPartition単位で 並列読み出しして処理 Executor Task Partition Worker Node Task Partition Executor Task Partition Worker Node Task Partition Executor Task Partition Worker Node Task Partition Executor Task Partition 各Executorは2Task(2コア)で処理
  15. 15. 14© Hitachi, Ltd. 2016. All rights reserved. 2-6. 測定内容 1. Kafkaの格納性能(秒間格納メッセージ数)  データ配信サーバが、センサデータを読みだして、Kafkaにデータを格納するまで 2. Sparkの処理性能(秒間処理メッセージ数)  Kafkaからデータを取り出して、運動状態を判定し、Elasticsearchに格納するまで 取得 判定 格納 ストリームデータ処理 Spark Streaming キュー Kafka Broker 検索エンジン Elasticsearch 2.Sparkの処理性能 (取得+運動状態判定+格納)1.Kafkaの格納性能 運動状態データ (1メッセージ 75byte) データ配信サーバ Kafka Producer センサデータの テキストファイル (1メッセージ 9,028byte)
  16. 16. 15© Hitachi, Ltd. 2016. All rights reserved. 配信ノード:1台  CPU:4コア  メモリ:8GB Spark Masterノード 2-7. 測定環境とパラメータ設定 仮想化環境で全9ノード Spark+Elasticsearchクラスタ:5台  CPU:8コア(計40コア)  メモリ:16GB(計80GB) Kafkaクラスタ:2台  CPU:4コア(計8コア)  メモリ:8GB(計16GB) Kafka Producer ノード Spark + Elasticsearchノード Spark + Elasticsearchノード Spark + Elasticsearchノード Spark + Elasticsearchノード Spark + Elasticsearchノード Sparkマスタノード1台  CPU:4コア  メモリ:8GB センサデータの テキストファイル Kafka Brokerノード Kafka Brokerノード Kafkaの設定: パーティション数: 32個 レプリカ作成数: 1個 Sparkの設定: バッチ処理間隔: 5秒 ドライバコア数:8個 ドライバメモリ量:12GB エグゼキュータ数: 4個 エグゼキュータコア数:8個 エグゼキュータメモリ量: 12GB ⇒ エグゼキュータは計32コア Elasticsearchの設定: レプリカ作成数: 1個
  17. 17. 16© Hitachi, Ltd. 2016. All rights reserved. 2-8. 初期構成における測定結果 Kafkaの格納性能がボトルネックとなり、システム全体でリアルタイムに処理できるのは 秒間8,026メッセージが限界 ※ 5秒間分のデータを平均2.44秒で処理したため 取得 判定 格納 ストリームデータ処理 Spark Streaming キュー Kafka Broker 検索エンジン Elasticsearch 運動状態データ (1メッセージ 75byte) データ配信サーバ Kafka Producer センサデータの テキストファイル (1メッセージ 9,028byte) 2.Sparkの処理性能(取得+判定+格納) 処理数 :約 19,346 メッセージ/秒 ※ 取得速度:約 167 MB/sec 格納速度:約 1.38 MB/sec 1.Kafkaの格納性能 処理数 :8,026 メッセージ/秒 格納速度:約 69 MB/sec
  18. 18. 17© Hitachi, Ltd. 2016. All rights reserved. 2-9. 各OSSのパラメータをチューニングした結果 • Kafka Producer (データ配信サーバの送信プログラムで使用)  1回あたりの送信データ量を大きくする  リクエストサイズを増やす (1MB → 2MB)  送信バッチサイズを増やす (16KB → 112KB)  送信待機時間を延長 (0ms → 50ms) • Elasticsearch  リフレッシュ(データのインデクシング)間隔を延長(1 → 60秒) 取得 判定 格納 ストリームデータ処理 Spark Streaming キュー Kafka Broker 検索エンジン Elasticsearch データ配信サーバ Kafka Producer 1.Kafkaの格納性能 8,026 → 10,112 メッセージ/秒 2.Sparkの処理性能(取得+判定+格納) 19,346 → 20,746 メッセージ/秒 +7% +26%
  19. 19. 18© Hitachi, Ltd. 2016. All rights reserved. 2-9. 各OSSのパラメータをチューニングした結果 • Kafka Producer (データ配信サーバの送信プログラムで使用)  1回あたりの送信データ量を大きくする  リクエストサイズを増やす (1MB → 2MB)  送信バッチサイズを増やす (16KB → 112KB)  送信待機時間を延長 (0ms → 50ms) • Elasticsearch  リフレッシュ(データのインデクシング)間隔を延長(1 → 60秒) 取得 判定 格納 ストリームデータ処理 Spark Streaming キュー Kafka Broker 検索エンジン Elasticsearch データ配信サーバ Kafka Producer 1.Kafkaの格納性能 8,026 → 10,112 メッセージ/秒 2.Sparkの処理性能(取得+判定+格納) 19,346 → 20,746 メッセージ/秒 +7% +26% KafkaとSparkの性能には約2倍の差がある ⇒ 各OSSに割り当てるノード台数を調整してみる
  20. 20. 19© Hitachi, Ltd. 2016. All rights reserved. 2-10. Spark + Elasticsearchノード: 5台 → 4, 3台 • ノード台数を3台まで減らすと…  KafkaとSparkの処理性能が逆転する  Kafkaの格納性能は若干向上する 配信ノード:1台 Spark+Elasticsearchクラスタ:5→4→3台 Kafkaクラスタ:2台 Kafka Producerノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + Elasticsearchノード Spark + Elasticsearchノード Spark + Elasticsearchノード Kafka Brokerノード 5,731 16,783 20,746 10,831 10,054 10,112 0 5,000 10,000 15,000 20,000 25,000 3台 (16パーティション) 4台 (24パーティション) 5台 (32パーティション) (デフォルト) 処理メッセージ数/秒 Sparkノード台数 Spark処理性能 Kafka格納性能
  21. 21. 20© Hitachi, Ltd. 2016. All rights reserved. 2-11. Kafka Producerノード: 1台 → 2台 • Kafkaの格納性能は11%向上したが Sparkの処理性能は13%低下した 配信ノード:1→2台 Spark+Elasticsearchクラスタ:5台 Kafkaクラスタ:2台 Kafka Producerノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + Elasticsearchノード Kafka Brokerノード 20,746 18,147 10,112 11,207 0 5,000 10,000 15,000 20,000 25,000 1台 (デフォルト) 2台 処理メッセージ数/秒 Kafka Producerノード台数 Spark処理性能 Kafka格納性能 効果小 Spark + Elasticsearchノード Spark + ElasticsearchノードKafka Producerノード
  22. 22. 21© Hitachi, Ltd. 2016. All rights reserved. 2-12. Kafka Producerノード: 1台 → 2台 + Kafka Brokerノード: 2台 → 3台 • Kafkaの格納性能は56%向上したが Sparkの処理性能は7%低下した 配信ノード:1→2台 Spark+Elasticsearchクラスタ:5台 Kafkaクラスタ:2→3台 Kafka Producerノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + ElasticsearchノードKafka Producerノード Kafka Brokerノード 20,746 19,357 10,112 15,732 0 5,000 10,000 15,000 20,000 25,000 Producer1台 /Broker2台 (デフォルト) Producer2台 /Broker3台 処理メッセージ数/秒 Kafka Producer/Brokerノード台数 Spark処理性能 Kafka格納性能 効果大
  23. 23. 22© Hitachi, Ltd. 2016. All rights reserved. 2-12. Kafka Producerノード: 1台 → 2台 + Kafka Brokerノード: 2台 → 3台 • Kafkaの格納性能は56%向上したが Sparkの処理性能は7%低下した 配信ノード:1→2台 Spark+Elasticsearchクラスタ:5台 Kafkaクラスタ:2→3台 Kafka Producerノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + Elasticsearchノード Kafka Brokerノード Spark + Elasticsearchノード Spark + ElasticsearchノードKafka Producerノード Kafka Brokerノード 20,746 19,357 10,112 15,732 0 5,000 10,000 15,000 20,000 25,000 Producer1台 /Broker2台 (デフォルト) Producer2台 /Broker3台 処理メッセージ数/秒 Kafka Producer/Brokerノード台数 Spark処理性能 Kafka格納性能 Kafkaの格納性能とSparkの処理性能はトレードオフ? 効果大
  24. 24. 23© Hitachi, Ltd. 2016. All rights reserved. 2-13. Kafka と Spark Streaming の性能はなぜ反比例したのか? • 処理データ量からノード間の通信量を計算すると… ⇒ Kafkaクラスタ(Broker)のネットワーク帯域がボトルネックと推測できる  Kafka Broker1ノードあたり 受信87.1MB/秒, 送信132.8MB/秒となる  今回のネットワーク環境は1Gbps回線(実質速度112MB/秒程度)を使用 ⇒ ネットワーク帯域を超えている!  通信量を測定すると、Broker間のレプリケーションが遅延実行されるため、112MBに収まっていた 43.5 Kafka送信データ量 87.1 MB/sec (10,112 msg/秒) Sparkは1秒あたり178.6MBを取得 負荷が高まると レプリケーションは 遅延実行される Spark処理データ量(4ノード合計) 178.6 MB/sec (20,746 msg/秒) Kafka Producer Kafka Broker Kafka Broker Spark+ Elasticsearch Spark+ Elasticsearch In : 44.6 MB/秒 Out: 0 MB/秒 Spark+ Elasticsearch In : 44.6 MB/秒 Out: 0 MB/秒 Spark+ Elasticsearch In : 44.6 MB/秒 Out: 0 MB/秒 Spark+ Elasticsearch In : 44.6 MB/秒 Out: 0 MB/秒 In : 87.1 MB/秒 Out: 132.8 MB/秒 In : 87.1 MB/秒 Out: 132.8 MB/秒 43.5 43.5 43.5 22.3 22.3 22.3 22.3 22.3 22.3 22.3 22.3 タスク実行管理するドライバのみ初期設定のマシン台数の場合
  25. 25. 24© Hitachi, Ltd. 2016. All rights reserved. 2-14. Kafka Producer/Brokerのノード台数を増やした場合 • Kafka Producerノードを1→2台、Brokerノードを2→3台に増やした場合… ⇒ Broker間でデータが分散され、1ノードあたり 受信90.3MB/秒, 送信100.7MB/秒  通信量が1Gbp回線(実質速度112MB/秒程度)に収まる  そのためネットワークのボトルネック解消 ⇒ Kafkaの格納性能は大きく向上(56%)したと考えられる Kafka送信データ量(2ノード合計) 135.4 MB/sec (15,732 msg/秒) Spark処理データ量(4ノード合計) 166.7 MB/sec (19,357 msg/秒) Kafka Producer Kafka Broker Kafka Broker Spark+ Elasticsearch Spark+ Elasticsearch Spark+ Elasticsearch Spark+ Elasticsearch Spark+ Elasticsearch 22.6 1ノードあたり In : 0 MB/秒 Out: 67.7 MB/秒 タスク実行管理するドライバのみ Kafka Producer Kafka Broker 22.6 22.6 22.6 22.6 22.6 1ノードあたり In : 67.7 MB/秒 Out: 0 MB/秒 1ノードあたり In : 90.3 MB/秒 Out:100.7 MB/秒 22.6 22.6 22.6 22.6 22.6 22.6 13.9×12
  26. 26. 25© Hitachi, Ltd. 2016. All rights reserved. 2-15. まとめ: Kafka + Spark Streamingでシステムを構築する際の注意点 1. Kafkaのパーティション数 > Sparkが使用するCPUコア数 に設定すること  Kafkaのパーティション数 = Sparkのタスク数 = Sparkの使用するコア数となるため、 Kafkaのパーティション数が少ないと、Sparkがコアを使いきれない 2. Kafkaのレプリケーションでネットワーク帯域がボトルネックとなりやすい  レプリカ2個ならBroker間の通信量も2倍、3個なら通信量も3倍…  解決策 • ネットワークを1G回線から10G回線にする (Hadoopクラスタではよくやること) • Brokerノードの台数を増やして通信量を分散させる 3. Kafkaはメッセージをディスクに保存するため、ディスク性能がボトルネックと なる場合もある (特にネットワークを10G回線にした場合は注意すること)  レプリカ2個なら各Brokerのディスク書き込み量も2倍、3個なら書き込み量も3倍…  解決策 • Brokerノードに搭載するディスク台数を増やす • Brokerノードに高速なディスク(SSDなど)を搭載する
  27. 27. 26© Hitachi, Ltd. 2016. All rights reserved. 他社所有商標に関する表示 • Apache Spark, Apache Hadoop, Apache Kafkaは、Apache Software Foundationの米国およびその他の国における登録商標または商標です。 • Elasticsearchは、 Elasticsearch BVの米国およびその他の国における登録商標または商標です。 • その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

×