IoT時代におけるストリームデータ処理と急成長の Apache Flink

2016/10/25

Acroquest Technology 株式会社

鈴木貴典

ビッグデータのリアルタイム処理技術勉強会

#futureofdata

Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2

自己紹介

所属

• Acroquest Technology Co., Ltd.

• 「働きがいのある会社」（GPTW）従業員25～99人部門 2年連続1位

主な業務分野

• テクニカルアーキテクト

• SEPG

• IoTサービス開発

• ビッグデータ処理プラットフォーム

最近の興味

• サーバーレス

• DevOps

• Elasticsearch

鈴木貴典

Twitter : @takanorig Qiita : http://qiita.com/takanorig


本日お話する内容

＃1 ビッグデータ × リアルタイム

＃2 ストリームデータ処理エンジン

＃3 ストリームデータ処理のシステムアーキテクチャ


ビッグデータ ×

リアルタイム

1. IoTでのデータの扱いの変化


2016年 229億デバイス



× 重要なのは

デバイス数の増加ではない



新しいビジネスのニーズへの対応

全量分析による AIの活用

データの即時有効活用

過去は、リアルタイムの情報は、サンプリングでしか扱えなかった。 IoTにより、利用できる情報が増え、全量分析することで、リアルタイムで、精度の高い学習・活用が可能になった。

生データをそのまま蓄積するのではなく、様々な手段で読み書きできる状態で保管する「データレイク」の考え方が広まっている。そのためには、リアルタイムにデータを加工・変換していく必要がある。

リアルタイムリコメンド、セキュリティリスクの検知、防災・異常検知、など、時間によってコストや人命への影響が大きい内容に関するニーズが増えてきた。

2. ビッグデータ処理プラットフォームのパラダイム


2002 2004 2006 2008 2010 2012 2014

Google GFS論文発表

(2003)

Google GigTable論文発表 (2006)

Google MapRedue論文発表 (2004)

Google Percolator・ Dremel(BigQuery) 論文発表 (2010)

Twitter Storm公開 (2011)

Hadoop 1st Release

(2007)

HBase 1st Release (2008)

よりリアルタイム性が求められる時代へ

2016

Spark Summit(1st) Spark0.8 Release (2013)

Drill公開(2013)

Storm1.0 Release Spark2.0 Release (2016)

Google MillWheel 論文発表 (2013)

Google Cloud Dataflow (2014)

3. ビッグデータ処理の3つのタイプ


Batch Stream Query

高低

Latency



バッチ処理インタラクティブ

クエリ処理ストリームデータ

処理

実行タイミングユーザの指定や定期的な実行

ユーザの指定や定期的な実行

常時連続実行

処理単位蓄積データを一括で処理

蓄積データを一括で処理

1～少数のフローデータを処理

実行時間分～時間秒～分ミリ秒～秒

処理モデル MapReduce 検索, 集計, OLTP Stream processing

要件に応じて、単体 or 組み合わせて利用



バッチ処理インタラクティブ

クエリ処理ストリームデータ

処理

タイプごとの代表的なプロダクト

Apache

Storm

Apache

Spark Streaming

Hadoop

CDH Cloudera's Distribution Including Apache Hadoop

Apache

Drill

Cloudera

Impala

Facebook

Presto

Spark

HDP Hortonworks Data Platform

CDP Converged Data Platform

Tez

Apache

Flink Elastic

Elasticsearch

https://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwiBmP-VpO7PAhVLFJQKHSLODcEQjRwIBw&url=http://www.cloudera.com/&psig=AFQjCNEG4s-8XJPxo3-XSdQ9I42PsJuOVQ&ust=1477221259897356

4. （改めて）ストリームデータ処理とは何か？


連続的に発生し続けるデータ（ストリームデータ）をリアルタイムに、解析・分析等の処理を行い続ける

センサーデバイス

テレマティクス

HEMS BEMS

ストリームデータ処理

設備

通知

可視化・分析

蓄積

5. ストリームデータ処理エンジンに求められる要素


1.Low Latency & High Throughput 低レイテンシ、高スループット

イベント到着から数十～数百ミリ秒のレイテンシで、毎秒、数十～数百万の処理を要求されることがあり、低レイテンシ、高スループットを実現する必要がある。

2.Scalable スケーラブル

複数ノードで構成されるクラスタ上で、並列分散的に動作し、膨大な数のメッセージに対しても低レイテンシを維持しつつ、水平スケールする。

3.Fault tolerant 耐障害性

障害が発生し、処理中のノードがダウンした場合でも、必要に応じてタスクの再割り当てやノードの再起動を行い、処理が完全に停止してしまうようなことがない。

5. ストリームデータ処理エンジンに求められる要素


4.Message guarantees メッセージ到達性保証

何らかの理由により、イベントの処理に失敗したり、タイムアウトが発生したりした場合でも、それを検知し、再処理するしくみが必要となる。エンジンによって、サポートする信頼性のレベルは異なるが、すべてのイベントが処理されることを担保可能とする。

5.Flow Control フロー制御

データの流れを許可したり、禁止したりすることが可能であること。エンジンで処理した結果のデータを受信する側で、処理が間に合わない場合に、データの送信をエンジン側で止められることを指す。TCP/IPのパケット通信に用いられている制御方式である。現時点では、Backpressureの機構が用いられることが多い。

6.Windowing ウィンドウ処理

ストリームデータを、一定の区間で区切り、単一のイベントではなく、複数のイベントに対して処理を行う。過去のイベントと比較したり、集計等の演算をするのに有用な機能であり、エンジン自体でサポートするケースが増えている。

【5. ストリームデータ処理エンジンに求められる要素】

5-1. メッセージ処理モデル


ストリームデータ処理

Event at a time

Micro-batch

Time-Based Count-Based

ストリームデータ処理も、大きく分けて２つの方式がある。

イベント毎に逐次処理真のストリーム処理

イベントのかたまり毎に処理 CEP※1の処理が可能

time time count count

一定時間毎に処理

さらに細かく分類すると・データ発生時間

・データ処理時間に基づくものがある

一定回数毎に処理

※1 CEP(Complex Event Processing)：複数イベントに対する処理。


5-2. メッセージ到達性保証


At most once （0回もしくは1回）

At least once （少なくとも1回）

Exactly once （正確に1回）

損失するかも損失しない損失しない

重複しない重複するかも重複しない

信頼性

性能

低

高

高

低

信頼性レベルに応じて、3つの分類がある。エンジンによって、どのレベルをサポートしているかは異なる。


5-3. Backpressure


送信側受信側 × バッファが溢れて処理できなくなる。

処理が速い 100メッセージ／秒

処理が遅い 80メッセージ／秒

送信側受信側

③バッファが溢れずに処理可能 80メッセージ／秒 80メッセージ／秒

①ペース落として！

②ペースダウン

ストリームデータ処理における課題

受信側の処理能力を超えるデータを送信し続けると、いずれキャパシティを超えてオーバーフローが発生してしまう。一方、送信側が常に遅く処理をすれば、無駄が大きくなる。

Backpressureによるペースの制御

受信側が自分が処理できる量だけのデータを、送信側に対して要求するようにして、オーバーフローの発生を防ぐ。


5-4. ウィンドウ処理


Tumbling Windows

Sliding Windows

集計や演算の内容に応じて、適したウィンド処理を検討する必要がある。

• 一定時間、もしくは、カウント毎に処理を行う。

• 処理対象のイベントのオーバーラップはなし。

• 「直近の○○」のように、現在から指定したイベント分だけさかのぼって処理を行う。

• 処理対象のイベントのオーバーラップはあり。


ストリームデータ処理エンジン

1. ストリームデータ処理エンジンの戦国時代


2011 2012 2013 2014 2015 2016

Storm 0.5

Spark Streaming 0.7

Flink 0.6

samza 0.7

Apex 3.2

Gearpump 0.8

Ignite 1.0

Beam 0.1

2014年以降、新プロダクトのリリースや、有償プロダクトのOSS化により競争激化

Heron 0.13



現時点では以下の3つがメジャーな存在となっている



Googeトレンド

「apache storm」「apache spark streaming」「apache flink」で検索

storm（青）

flink（黄）

spark streaming（赤）

Flinkが伸びてきている



念のため、”spark streaming” -> “spark” に変更して検索「apache storm」「apache spark」「apache flink」で検索

storm（青）

flink（黄）

spark（赤） Spark全体としてみると人気が高い

2. Storm


• 2011年、Twitter社がオープンソースとして公開。

• 耐障害性を持つ分散型として、最初に世界的に認知されたストリームデータ処理エンジン。

• 入力部、出力部共に、他の多くのOSSやクラウドサービスと連携。

• 2016年4月にv1.0がリリースされ、課題となっていたSlidingWindow、Backpressureなどの機能が追加され、性能も、従来と比較して16倍の処理高速化を実現。

2. Storm - データ処理コンセプト


Spout

Spout

Bolt

Bolt

Bolt

Bolt

Bolt

Topology

Spout：

StreamのデータソースとしてTupleを送出する

Bolt：

StreamからTupleを受信し、変換・加工する

Tuple：

Stormで処理されるメッセージを保持する、単一のデータ

Stream：

途切れずに連続するTupleの流れ

Spout＋Boltからなるネットワーク構造。Stormにおける処理の単位となる

2. Storm - Word Count Exampe


TopologyBuilder builder = new TopologyBuilder();

builder.setSpout("spout", new RandomSentenceSpout(), 5);

builder.setBolt("split", new SplitSentence(), 8).shuffleGrouping("spout");

builder.setBolt("count", new WordCount(), 12).fieldsGrouping("split", new Fields("word"));

Config conf = new Config();

conf.setNumWorkers(3);

StormSubmitter.submitTopology(args[0], conf, builder.createTopology());

※一部

2. Storm - Word Count Exampe


public static class WordCount extends BaseBasicBolt {

Map<String, Integer> counts = new HashMap<String, Integer>();

@Override public void execute(Tuple tuple, BasicOutputCollector collector) {

String word = tuple.getString(0);

Integer count = counts.get(word);

if (count == null)

count = 0;

count++;

counts.put(word, count);

collector.emit(new Values(word, count));

}

@Override public void declareOutputFields(OutputFieldsDeclarer declarer) {

declarer.declare(new Fields("word", "count"));

}

}

※一部

3. Spark／Spark Streaming


Spark Core コアエンジン

Spark SQL

クエリ

Spark Streaming

ストリーム

MLlib

機械学習

GraphX グラフ分析

• カリフォルニア大学バークレー校で開発を開始。2013年に公開。

• インメモリ処理により、バッチ処理を高速化。Spark Stack として、バッチだけでなく、ストリームデータ処理やSQLクエリ、機械学習の処理も可能。

• Spark Streamingでは、ストリームデータを一定時間で区切り、小さいデータの固まり毎にバッチとして処理を実行する。

• 2016年7月にv2.0がリリースされ、 2～10倍の高速化。

3. Spark Streaming - データ処理コンセプト


一連の入力データを、小さなデータセット（RDD:Resilient Distributed Dataset）に区切って、

そのデータセット毎に処理を実行していく

3. Spark Streaming - Word Count Exampe


JavaReceiverInputDStream<String> lines = jssc.socketTextStream("localhost", 9999);

JavaDStream<String> words = lines.flatMap(new FlatMapFunction<String, String>() {

@Override public Iterable<String> call(String x) {

return Arrays.asList(x.split(" "));

}

});

JavaPairDStream<String, Integer> pairs = words.mapToPair(new PairFunction<String, String, Integer>() {

@Override public Tuple2<String, Integer> call(String s) {

return new Tuple2<String, Integer>(s, 1);

}

});

JavaPairDStream<String, Integer> wordCounts = pairs.reduceByKey(

new Function2<Integer, Integer, Integer>() {

@Override public Integer call(Integer i1, Integer i2) {

return i1 + i2;

}

});

4. Flink


• ベルリン工科大学および欧州のいくつかの大学とともに発足した成層圏研究プロジェクトが元となっており、2014年にOSSとして公開。

• バッチ、および、ストリームデータ処理の両方をサポートする。

• Flink Stackとして、機械学習やグラフ分析のライブラリも統合されていることもあり、Sparkと比較されることが多いが、Flinkは”真”のストリーム処理を実現している。

• 高速ながら耐障害性にも優れ、ステートフルな機構を持ち、障害が発生しても自動復旧して処理を継続可能。

• 一貫性と低レイテンシの両方を実現している。

4. Flink - データ処理コンセプト


Data Stream

Operation Data

Stream Source Sink

State

ストリームデータ処理：DataStream API

4. Flink - データ処理コンセプト


バッチ処理：DataSet API

Data Set

Operation Data Set

Source Sink

State

4. Flink - Word Count Exampe


StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

DataStream<String> text = env.readTextFile(textPath);

DataStream<Tuple2<String, Integer>> counts =

text.map(line -> line.toLowerCase().split("¥¥W+"))

.flatMap((String[] tokens, Collector<Tuple2<String, Integer>> out) -> {

Arrays.stream(tokens)

.filter(t -> t.length() > 0)

.forEach(t -> out.collect(new Tuple2<>(t, 1)));

})

.keyBy(0)

.sum(1);

5. 比較


Storm Spark Streaming

Flink Core Trident

処理モデル Event at a Time Micro-batch Micro-batch

（処理時間のみ） Event at a Time

Micro-batch

到達性保証 At least once Exactly once Exactly once Exactly once

レイテンシとても低低低とても低

スループット高高中高

実装言語 Clojure Clojure Scala Scala

開発言語 Java, Clojure, Scala,

Python, Ruby Java, Clojure, Scala,

Python Java, Scala, Python, R

Java, Scala, Python

API 低レベル

Compositional

高レベル

Declarative

高レベル

Declarative

高レベル

Declarative

ウィンドウ処理

Sliding, Tumbling Sliding, Tumbling Sliding Sliding, Tumbling


ストリームデータ処理のシステムアーキテクチャ

1. 検討ポイント


① 大量データの収集方法 • Pull or Push、プロトコル、データ形式

② 増減するストリームデータへの対応 • ピーク性能、時間のズレに対する配慮

③ 分散処理、および、分散の単位 • 集約キーの設計、集計、ウィンドウ処理、データ欠損への配慮

④ 中間データの扱い • マスタデータ、一時データ

⑤ 運用 • ログの管理、ノードの管理、モニタリング、障害対応

https://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=&url=http://fasttracksuccess.co/&psig=AFQjCNFolUXOBYK6HX7mV18I3fvHY1OHOg&ust=1477461474066905

解析結果用データストア

ダッシュボード分析ツール

ユーザ通知

2. ストリームデータ処理の基本アーキテクチャ


センサーデータ

ログ

データ受信メッセージキュー

通信データ

データ発生元

SNS データ

データ受信部データ処理部

データ収集

永続化用データストア

取得解析出力

出力取得

保存

解析

キャッシュ用データストア

データ活用部

典型的なアーキテクチャ

3. 運用


• エンジンが問題になるとは限らない。データ収集やデータの保存先なども重要。

• 様々なOSSに対して、クラスタの構築からモニタリングまで行えるのが便利。

システム全体の管理には Ambariが便利

ストリーム処理エンジンの管理コンソールを活用

• 各エンジンには、専用の管理コンソールが付属しているケースが多い（それがないと死ぬ）。

• ボトルネックや障害の確認に役立つ。

Spark WebUI

Fink Dashbord

Ambari

https://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwinnaWPp_XPAhUBfrwKHV7lAz4QjRwIBw&url=http://stackoverflow.com/questions/32271475/apache-flink-streaming-in-cluster-does-not-split-jobs-with-workers&psig=AFQjCNH3GWZsd5aw3WcbsT1ZYPQY6sbfow&ust=1477462564483714


本日のまとめ

1. ストリームデータ処理エンジンに求められる内容も高機能になってきている。

① スケーラブル、耐障害性は必須になっている。

② Backpressureによるフロー制御、ウィンドウ処理なども必要性が高い。

2. ストリーム処理エンジンは、戦国時代になっている。

① Storm、Spark Streaming、Flinkが代表格。

② Spark、Flink は、バッチとストリームの両方をサポートし、かつ、クエリ処理や機械学習などのエコシステムを統合して提供しているのは有用。

③ どれを利用するかは、そのエンジンの特性や強みを理解して選ぶしかない。

3. エンジンだけでなくシステム全体のアーキテクチャを考慮しよう。

① データ収集やキュー処理、データの永続化など、一連の流れを検討する必要がある。

② 運用のツールも揃ってきているので、うまく活用しよう。


Thank you

Infrastructures Evolution