Stormによるデータ処理

gistfile1.txt

Stormによるデータ処理
竹内

アジェンダ
・IoTとストリーム処理
・Storm
・事例

[IoTとストリーム処理]
ストリーム処理の定義極力ディスクに着地させないで処理する

ストリームデータはどこにでもある
・log stream
・発生したデータをためたものがファイルやデータベース

・ストリームデータはあふれているがストリーム処理は少ない
　・ファイル、DBのプログラムのほうがわかりやすい
　・そこまでのリアルタイムが求められていない

様々な分野でIoTの流れが加速
・２０２０年に数百億代以上になることが予想されている　
・サムスンは２０１５年にIoTに１億ドルを投資

・業界別にOSSベースのIoTプラットフォームの業界団体が存在
Alljoyなど

・複数のチャネルから情報を統合しなくてはならない
・過去の分析から未来への予測へ

Hadoopとストリーム処理
・Hadoopは強力だがHDFSのレイテンシの大きさが問題
・Hadoopはレイテンシに弱い

・１件あたり数十ミリ秒〜数秒程度のレイテンシをターゲットとしたOSSの処理
Storm Spark Samza

-----
[Storm]
・TwがOSSとしてリリース
・JVM Clojure+Java

４年たってる
Apacheプロジェクトトップサービス


利用事例７０件


Stomのコンセプト
対象外性が高い

--------
Stormが無い世界

分散ストリーム処理の難しさ

継続動作するストリーム処理をジョブ感覚で発行、任意の並列度で実行
ストリーム処理ないのキューイングやルーティングはStormが自動的に設定
リソースがある限り動く

Stromクラスタは動的に増減が可能


Stormの耐障害性
・障害があると自動的に別のサーバーが引き継ぎ
・ストリーム処理内の再ルーティング、失敗したメッセージの再実行も自動で実施

Stormのアーキテクチャ
Nimbus
Supervisor
Zookeeper

N->Z->S


[Stormと他システムの連携]
Stormは純粋なストリーム処理に特化したシンプルなフレームワーク
外部連携のための多数の非公式プラグインが存在
 JMS,Kafka


------------------------

Stormアプリケーションの基本要素


Stormの運用監視
・Stormトポロジの各種統計値の確認がWEBUIで可能


セミナー、早すぎる・・
---------------------

数百〜数千万代規模のセンサーからの入力を想定したPoC


60億件/日
 7万件/sec

Storm->HBASE


事例２；機器のログ収集
リリースしているもの
日本全国で１０万台の機器

４００万件/５分

Strom利用するときは連携するシステム性能がボトルネックになることが多い

１つのBoltの処理を複雑化しすぎない
・Storm自体は複雑な事をするのはむしろ得意

----
社外事例紹介

Ciscoの利用例

120万パケット/病を処理

Spotify(スポッティファイ)音楽サービス
22ノード
20万イベント/sec

リコメンドトポロジ
---------------------------------------------------------
これからの分散処理基板設計のポイント


・ストリーム処理だけですべてをやろうとしない
・ストリームデータをストリームとして流し込む


ロガーコレクター(fluentd/RabittMQ)▶キュー(RabiitMQ,Kafka) ▶ストリーム Storm -> hadoop/HBASE/TEZ/Spark


Kafka
ブローカータイプのメッセージング獅子うテム


面白い特徴

---------------
まとめ

大規模システム処理できるように設計しよう