hadoop summit 2016 san jose ストリーム処理関連の報告 #streamctjp

2016年7月22日

1

ヤフー株式会社 D&S データプラットフォーム本部 森谷 大輔

Hadoop Summit 2016 @San Jose

ストリーム処理関連の報告

自己紹介

• 氏名• 森谷 大輔

• 業務• 社内ストリーム処理PFの構築

• ストリームなアプリケーションの開発

• ストリーム周りで使う• Kafka, Storm,

Cassandra, Elasticsearch

2

アジェンダに入る前に

ストリーム処理復習

• バッチ処理：データをためて、まとめて、一気に処理• 処理に終わりがある

• 高スループット、データが生まれてから結果が出るまでの時間遅

• ストリーム処理：生まれ続けるデータを継続的に逐次処理• 処理に終わりがない

• 低スループット、データが生まれてから結果が出るまでの時間速

4

なんでストリーム処理？

•速い。以上。 ※個人の見解です

• ストリーム処理をしたくなる例• 不意にものすごく人気が出たTV番組をユーザに通知できたのが番組が終わった後だった

• ログから故障しそうなサーバを予見、通知されたがもう既に故障している

• ユーザがこの商品に興味があるのは恐らくここ数分だけだ

• Webページのこのモジュールのクリック率、急激に悪くなってたからすぐ差し替えたかった

5

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

6

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

7

Hadoop Summit 2016 @San Jose

• 日時： 2016/6/28 – 30

• 場所： San Jose McEneryConvention Center

• 参加者数： 4000人+

• セッション数： 170+

• ホスト： Hortonworks,Yahoo! Inc.

8

• 午前キーノート午後セッションが3日間

• Hadoop 10周年

• 2016/10月 Hadoop Summit Tokyo

9

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

10

Hadoop Summitにおけるストリーム処理

• ストリーム関連のセッションは想像以上に多かった• 実績話、チューニング、deep dive• keynoteではメインテーマの1つとして”Data at Rest”と”Data in Motion”の扱いについて言及

11

確認した171セッション中 abstract で言及しているセッション数

Kafka 24

Storm 21

Flink 8

Spark Streaming 5

Samza 2

Beam 2

Apex 2

↑を全てOR 44

参考

Spark 47

Hive 22

NiFi 21

HBase 18

全体の4分の1くらい

肌感• Kafka + Storm は現状のプロダクション実績においてほとんどデファクトスタンダードのよ

うだ

• Storm、最近旗色悪そうな気がしていたが予想以上に使われている

• Spark StreamingはStormほどではないが使われている• ただしlatencyの問題がある、latency要件が高いユーザはStormに戻る例も

• 分散キューとしては聞いた中ではKafka以外の名前は聞かなかった

• FlinkやApexといったところは注目されている、がまだ実績は多くない

12

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

13

The Future of Apache Storm

• P. Taylor Goetz @Hortonworks• StormのPMC chair、他ApexやKylinのPMC

• Stormの過去と今年4月にリリースした1.0と今後の話

• 0.10.x まで

• 1.0の新機能

• 2.xに向けて

• よもやま話

14

0.10.xまで• Storm 0.9.x

• StormがApacheのトップレベルプロジェクトに

• workerの内部通信が0mqからNettyに

• 連携系に拡張・改良（Kafka, HDFS, HBase）

• dependencyのコンフリクト防止施策

• Storm 0.10.x• セキュリティ追加、マルチテナントのための機能追加

• ローリングアップグレード可能に

• Partial Key Groupings

• Flux（便利トポロジデプロイツール）

• 連携系拡張（Hive, Redis, JDBC）

15

1.0の新機能• 2016年4月リリース

• Pacemaker• ZooKeeperに流していたハートビートの置き換え

• スケールのボトルネックだったがこれによって2, 3千ノードのスケールが可能に

• Distributed Cache API• トポロジ間でファイル共有できる仕組み（設定ファイルや辞書ファイル等）

• トポロジと一緒にデプロイする方法では、ファイルが小さいと問題にならなかったが巨大だとデプロイに時間がかかる問題を解消

• ファイルはコマンドラインからアップデートでき、KBから数GBのサイズ、圧縮をサポート

• High Availability Nimbus

• Native Streaming Windows• Window処理がやりやすくなるAPI

16

1.0の新機能• State Management

• ステートフルなboltをサポート

• checkpointが定期的に更新されて、bolt再開時はそこからstateを復帰

• インメモリのstate実装かRedisが使える

• Automatic Back Pressure• バッファサイズの貯まり具合でSpoutのスピードを絞ったり戻したりする

• High/Low Watermarkによって指定

• Resource Aware Scheduler• トポロジ毎に必要リソース(メモリ/CPU)を指定して効率的にタスクを割り振れるようになるスケジューラ

• クラスタ内のサーバ性能が統一じゃない場合にも有効

• Dynamic Log Levels、お手軽タプルサンプリング、Distributed Log Search...

• 最大スループット向上16倍、60%レイテンシ低減

17

2.xに向けて• Storm 1.1.0

• メトリクスAPIの改良

• ユーザ定義のメトリクス

• Storm UIで見れるメトリクスを増やす

• メトリクスのAmbari連携を強化

• Storm 2.x• Clojure to Java

• Streaming SQL

18

よもやま話• パフォーマンスはユースケースによって全く異なる

• 外部のベンチマークを鵜呑みにしてはならない、自分でやるのが一番

• Heron vs Storm

• 当時Heronが解決した課題は現在ではStormでもほぼ解決してしまった

• 機能面でもパフォーマンスでもStormに分がある

• Q. Stormは死ぬ？

• A. ライバルがそう言ってるだけ

• 数百のプロダクション実績とデベロッパコミュニティの活発さが本当の答えだ

19

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

20

Ingest and Stream Processing– What Will You Choose?

• Ted Malaska @Cloudera

• ストリーム処理のシステムを構築する上で各コンポーネントのセマンティクスや、実装には何を選ぶべきかの指針を与える話

• 1個前の話とかなり違うことを言っている

21

ストリームの構成とセマンティクス

• セマンティクス？

22

At Most Once 重複はしないけど損失はするかも

At Least Once 損失はしないけど重複はするかも

Exactly Once 損失も重複もしない

Producer Kafka Engine Destination

At Least Once

At Least OnceOrdered

Partitioned モノによる モノによる

Destinations

23

モノ セマンティクス 備考 向いているIngestion

ファイルシステム（HDFS等）

Exactly Once可 scanに良い Flume, Kafka Connect

Solr Exactly Once可 search queryに良い Flume, Any Streaming Engine

NoSQL（HBase等） Exactly Once可 getやputするのに良い Flume, Any Streaming Engine

Kudu Exactly Once可 get, put, scanに良い Flume, Kafka Connect,Any Streaming Engine

Streaming Engines

24

モノ セマンティクス 特徴

Consumer: Flume,KafkaConnect

- ・シンプルだがtransformationはできない・低レイテンシ・高スループット

Storm At Least Once ・低レイテンシ・低スループット・「直に歴史の1ページとなるだろう」

Spark Streaming Exactly Once可 ・最近すごい勢い・（Stormよりは）高レイテンシ・高スループット・SQL, MlLib・デバッグやユニットテストがしやすい

Flink Exactly Once可 ・Sparkに似ている・（Spark Streamingよりは）低レイテンシ・実績少

Kafka Streams - ・若い（0歳2ヶ月）・低レイテンシ・高スループット

アジェンダ

• イベント概要

• Hadoop Summitにおけるストリーム処理

• セッション紹介• ① The Future of Apache Storm

• ② Ingest and Stream Processing - What Will You Choose?

• まとめ

25

まとめ

• Hadoop Summitにおけるストリーム処理についての肌感• 注目されている

• Stormのプロダクション実績の多さ

• FlinkやApexはこれから

• Stormの未来• 1.0の機能群が強い

• ポジショントークに注意、試してみるのが一番かも

• ストリーム処理システム構成のヒント• 要件に合わせたStream EngineやDestination選択を

26