Upload
future-of-data-japan
View
313
Download
3
Embed Size (px)
Citation preview
© 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
2 © Hitachi, Ltd. 2016. All rights reserved.
目次
1. Spark と Spark Streaming の概要
2. Spark Streamingを活用したシステムの検証結果
3 © Hitachi, Ltd. 2016. All rights reserved.
1. Spark と Spark Streaming の概要
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
データ ソース
データ ストア
RDD
RDD
RDD
RDD
RDD
結合 / 集約 出力
Partition間のデータ交換 (シャッフル)
変換 変換 入力
Files
Files
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上での動作も可能
6 © Hitachi, Ltd. 2016. All rights reserved.
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に対するバッチ処理を実行
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 のデータ
過去データの合計値に、最新データの値を加算
平均値
データ ストア
過去の合計値 合計値
追加
更新
8 © Hitachi, Ltd. 2016. All rights reserved.
2. Spark Streamingを活用したシステムの検証結果
9 © Hitachi, Ltd. 2016. All rights reserved.
2-1. 検証シナリオ
• 運動リズムにあった音楽を自動選曲する音楽配信サービスを想定 利用者の運動状態に合わせて曲を再生
利用者は身体と音楽の一体感を楽しみながら活動できる
音楽配信サービス モバイルから加速度 などの情報を収集
運動リズムにあった お気に入り曲を配信
検証 範囲
データ収集
運動状態の判定(5秒間隔)
選曲
歩いてる、 走ってる、 階段を上っている、 など6種類
音楽配信
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
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
システム 管理者
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
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 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コア)で処理
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)
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個
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
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%
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に割り当てるノード台数を調整してみる
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格納性能
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ノード
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格納性能 効果大
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の処理性能はトレードオフ?
効果大
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
タスク実行管理するドライバのみ 初期設定のマシン台数の場合
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
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など)を搭載する
26 © Hitachi, Ltd. 2016. All rights reserved.
他社所有商標に関する表示
• Apache Spark, Apache Hadoop, Apache Kafkaは、Apache Software Foundationの米国およびその他の国における登録商標または商標です。
• Elasticsearchは、 Elasticsearch BVの米国およびその他の国における登録商標または商標です。
• その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。