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

© Hitachi, Ltd. 2016. All rights reserved.
Spark Streamingを活用したシステムの検証結果と
設計時のノウハウ
2016年12月14日
日立製作所 OSSソリューションセンタ
伊藤雅博

1© Hitachi, Ltd. 2016. All rights reserved.
自己紹介
• 伊藤雅博 (いとうまさひろ)
 所属：日立製作所 OSSソリューションセンタ
 業務： Hadoop/Sparkを中心としたビッグデータ関連
OSSの検証やテクニカルサポート
 趣味：ロードバイク
Think ITの連載記事：
ユースケースで徹底検証！ Sparkのビッグデータ処理機能を試す
https://thinkit.co.jp/series/5747

目次
1. Spark と Spark Streaming の概要
2. Spark Streamingを活用したシステムの検証結果

1. Spark と Spark Streaming の概要

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

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上での動作も可能

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に対するバッチ処理を実行

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
のデータ
過去データの合計値に、最新データの値を加算
平均値
データ
ストア
過去の合計値合計値
追加
更新

2. Spark Streamingを活用したシステムの検証結果

2-1. 検証シナリオ
• 運動リズムにあった音楽を自動選曲する音楽配信サービスを想定
 利用者の運動状態に合わせて曲を再生
 利用者は身体と音楽の一体感を楽しみながら活動できる
音楽配信サービスモバイルから加速度
などの情報を収集
運動リズムにあった
お気に入り曲を配信
検証
範囲
データ収集
運動状態の判定（5秒間隔）
選曲
歩いてる、
走ってる、
階段を上っている、
など6種類
音楽配信

データ可視化/分析
データ蓄積
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

並列分散処理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
システム
管理者

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

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コア)で処理

2-6. 測定内容
1. Kafkaの格納性能（秒間格納メッセージ数）
 データ配信サーバが、センサデータを読みだして、Kafkaにデータを格納するまで
2. Sparkの処理性能（秒間処理メッセージ数）
 Kafkaからデータを取り出して、運動状態を判定し、Elasticsearchに格納するまで
取得判定格納
Spark Streaming
キュー
Kafka Broker
検索エンジン
Elasticsearch
２．Sparkの処理性能 (取得＋運動状態判定＋格納)１．Kafkaの格納性能
運動状態データ
(1メッセージ 75byte)
Kafka Producer
(1メッセージ 9,028byte)

配信ノード：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マスタノード1台
 CPU：4コア
 メモリ：8GB
テキストファイル Kafka Brokerノード
Kafka Brokerノード
Kafkaの設定：
パーティション数: 32個
レプリカ作成数: 1個
Sparkの設定：
バッチ処理間隔: 5秒
ドライバコア数：8個
ドライバメモリ量：12GB
エグゼキュータ数: 4個
エグゼキュータコア数：8個
エグゼキュータメモリ量: 12GB
⇒ エグゼキュータは計32コア
Elasticsearchの設定：
レプリカ作成数: 1個

2-8. 初期構成における測定結果
Kafkaの格納性能がボトルネックとなり、システム全体でリアルタイムに処理できるのは
秒間8,026メッセージが限界
※ 5秒間分のデータを平均2.44秒で処理したため
取得判定格納
Spark Streaming
キュー
Kafka Broker
検索エンジン
Elasticsearch
運動状態データ
(1メッセージ 75byte)
Kafka Producer
(1メッセージ 9,028byte)
２．Sparkの処理性能（取得＋判定＋格納)
処理数：約 19,346 メッセージ/秒 ※
取得速度：約 167 MB/sec
格納速度：約 1.38 MB/sec
１．Kafkaの格納性能
処理数：8,026 メッセージ/秒
格納速度：約 69 MB/sec

2-9. 各OSSのパラメータをチューニングした結果
• Kafka Producer (データ配信サーバの送信プログラムで使用)
 1回あたりの送信データ量を大きくする
 リクエストサイズを増やす（1MB → 2MB）
 送信バッチサイズを増やす（16KB → 112KB）
 送信待機時間を延長（0ms → 50ms）
• Elasticsearch
 リフレッシュ（データのインデクシング）間隔を延長（1 → 60秒）
取得判定格納
Spark Streaming
キュー
Kafka Broker
検索エンジン
Elasticsearch
Kafka Producer
8,026 → 10,112 メッセージ/秒
19,346 → 20,746 メッセージ/秒
+7%
+26%

2-9. 各OSSのパラメータをチューニングした結果
• Kafka Producer (データ配信サーバの送信プログラムで使用)
 1回あたりの送信データ量を大きくする
 リクエストサイズを増やす（1MB → 2MB）
 送信バッチサイズを増やす（16KB → 112KB）
 送信待機時間を延長（0ms → 50ms）
• Elasticsearch
 リフレッシュ（データのインデクシング）間隔を延長（1 → 60秒）
取得判定格納
Spark Streaming
キュー
Kafka Broker
検索エンジン
Elasticsearch
Kafka Producer
8,026 → 10,112 メッセージ/秒
19,346 → 20,746 メッセージ/秒
+7%
+26%
KafkaとSparkの性能には約2倍の差がある
⇒ 各OSSに割り当てるノード台数を調整してみる

2-10. Spark + Elasticsearchノード： 5台 → 4, 3台
• ノード台数を3台まで減らすと…
 KafkaとSparkの処理性能が逆転する
 Kafkaの格納性能は若干向上する
配信ノード：1台
Spark＋Elasticsearchクラスタ：5→4→3台
Kafka Producerノード
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台
5台
（デフォルト）
処理メッセージ数/秒
Sparkノード台数
Spark処理性能
Kafka格納性能

2-11. Kafka Producerノード： 1台 → 2台
• Kafkaの格納性能は11%向上したが
Sparkの処理性能は13%低下した
配信ノード：1→2台
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ノードKafka Producerノード

2-12. Kafka Producerノード： 1台 → 2台 + Kafka Brokerノード： 2台 → 3台
Kafkaクラスタ：2→3台
Kafka Brokerノード Spark + Elasticsearchノード
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格納性能効果大

2-12. Kafka Producerノード： 1台 → 2台 + Kafka Brokerノード： 2台 → 3台
Kafkaクラスタ：2→3台
Kafka Brokerノード Spark + Elasticsearchノード
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の処理性能はトレードオフ？
効果大

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
タスク実行管理するドライバのみ初期設定のマシン台数の場合

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

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など）を搭載する

他社所有商標に関する表示
• Apache Spark, Apache Hadoop, Apache Kafkaは、Apache Software Foundationの米国およびその他の国における登録商標または商標です。
• Elasticsearchは、 Elasticsearch BVの米国およびその他の国における登録商標または商標です。
• その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

Recently uploaded

Recently uploaded (8)

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