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

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

データソース

データストア

RDD

RDD

RDD

RDD

RDD

結合 / 集約出力

Partition間のデータ交換（シャッフル）

変換変換入力

Files

Files


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 RDD RDD

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 Cluster Kafkaクラスタ 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秒で処理したため

取得判定格納



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秒）

取得判定格納



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秒）

取得判定格納



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クラスタ：2台

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台

Spark＋Elasticsearchクラスタ：5台

Kafkaクラスタ：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


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






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

Technology