Hadoop Summit 2016 San Jose ストリーム処理関連の報告 #streamctjp

>100 Views

July 21, 16

スライド概要

Stream Processing Casual Talks #1 at Yahoo! JAPAN の発表資料です
http://connpass.com/event/35264/

profile-image

2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Hadoop Summit 2016 @San Jose ストリーム処理関連の報告 2016年7月22日 ヤフー株式会社 D&S データプラットフォーム本部 森谷 大輔 1

2.

自己紹介 • 氏名 • • 業務 • • • 社内ストリーム処理PFの構築 ストリームなアプリケーションの開発 ストリーム周りで使う • 2 森谷 大輔 Kafka, Storm, Cassandra, Elasticsearch

3.

アジェンダに入る前に

4.

ストリーム処理復習 • バッチ処理:データをためて、まとめて、一気に処理 • • • ストリーム処理:生まれ続けるデータを継続的に逐次処理 • • 4 処理に終わりがある 高スループット、データが生まれてから結果が出るまでの時間遅 処理に終わりがない 低スループット、データが生まれてから結果が出るまでの時間速

5.

なんでストリーム処理? •速い。 • ストリーム処理をしたくなる例 • • • • 5 以上。 ※個人の見解です 不意にものすごく人気が出たTV番組をユーザに通知できたのが番組が終わった後だった ログから故障しそうなサーバを予見、通知されたがもう既に故障している ユーザがこの商品に興味があるのは恐らくここ数分だけだ Webページのこのモジュールのクリック率、急激に悪くなってたからすぐ差し替えたかった

6.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 6 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

7.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 7 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

8.

Hadoop Summit 2016 @San Jose • • • • • 8 日時: 2016/6/28 – 30 場所: San Jose McEnery Convention Center 参加者数: 4000人+ セッション数: 170+ ホスト: Hortonworks, Yahoo! Inc.

9.

• • • 9 午前キーノート午後セッションが3日間 Hadoop 10周年 2016/10月 Hadoop Summit Tokyo

10.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 10 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

11.

Hadoop Summitにおける ストリーム処理 • ストリーム関連のセッションは想像以上に多かった • 実績話、チューニング、deep dive • keynoteではメインテーマの1つとして”Data at Rest”と”Data in Motion”の扱いについて言及 確認した171セッション中 abstract で言及しているセッション数 11 参考 Kafka 24 Spark 47 Storm 21 Hive 22 Flink 8 NiFi 21 Spark Streaming 5 HBase 18 Samza 2 Beam 2 Apex 2 ↑を全てOR 44 全体の4分の1くらい

12.

肌感 • Kafka + Storm は現状のプロダクション実績においてほとんどデファクトスタンダードのよ うだ Storm、最近旗色悪そうな気がしていたが予想以上に使われている Spark StreamingはStormほどではないが使われている • • • • • ただしlatencyの問題がある、latency要件が高いユーザはStormに戻る例も 分散キューとしては聞いた中ではKafka以外の名前は聞かなかった FlinkやApexといったところは注目されている、がまだ実績は多くない 12

13.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 13 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

14.

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

15.

0.10.xまで • Storm 0.9.x • • • • • StormがApacheのトップレベルプロジェクトに workerの内部通信が0mqからNettyに 連携系に拡張・改良(Kafka, HDFS, HBase) dependencyのコンフリクト防止施策 Storm 0.10.x • • • • • 15 セキュリティ追加、マルチテナントのための機能追加 ローリングアップグレード可能に Partial Key Groupings Flux(便利トポロジデプロイツール) 連携系拡張(Hive, Redis, JDBC)

16.

1.0の新機能 • 2016年4月リリース • Pacemaker • • • ZooKeeperに流していたハートビートの置き換え スケールのボトルネックだったがこれによって2, 3千ノードのスケールが可能に Distributed Cache API • • • • • トポロジ間でファイル共有できる仕組み(設定ファイルや辞書ファイル等) トポロジと一緒にデプロイする方法では、ファイルが小さいと問題にならなかったが巨大だとデプロイに時間が かかる問題を解消 ファイルはコマンドラインからアップデートでき、KBから数GBのサイズ、圧縮をサポート High Availability Nimbus Native Streaming Windows • 16 Window処理がやりやすくなるAPI

17.

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

18.

2.xに向けて • Storm 1.1.0 • • • • • Storm 2.x • • 18 メトリクスAPIの改良 ユーザ定義のメトリクス Storm UIで見れるメトリクスを増やす メトリクスのAmbari連携を強化 Clojure to Java Streaming SQL

19.

よもやま話 • • パフォーマンスはユースケースによって全く異なる 外部のベンチマークを鵜呑みにしてはならない、自分でやるのが一番 • Heron vs Storm • 当時Heronが解決した課題は現在ではStormでもほぼ解決してしまった • 機能面でもパフォーマンスでもStormに分がある • Q. Stormは死ぬ? • • A. ライバルがそう言ってるだけ 数百のプロダクション実績とデベロッパコミュニティの活発さが本当の答えだ 19

20.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 20 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

21.

Ingest and Stream Processing – What Will You Choose? • Ted Malaska @Cloudera • ストリーム処理のシステムを構築する上で各コンポーネントのセマンティクスや、実装に は何を選ぶべきかの指針を与える話 1個前の話とかなり違うことを言っている • 21

22.

ストリームの構成とセマンティクス At Least Once Ordered Partitioned At Least Once Producer • Kafka モノによる Engine セマンティクス? 22 At Most Once 重複はしないけど損失はするかも At Least Once 損失はしないけど重複はするかも Exactly Once 損失も重複もしない モノによる Destination

23.

Destinations モノ セマンティクス 備考 向いている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 23

24.

Streaming Engines モノ セマンティクス 特徴 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ヶ月) ・低レイテンシ ・高スループット 24

25.

アジェンダ • • • イベント概要 Hadoop Summitにおけるストリーム処理 セッション紹介 • • • 25 ① The Future of Apache Storm ② Ingest and Stream Processing - What Will You Choose? まとめ

26.

まとめ • Hadoop Summitにおけるストリーム処理についての肌感 • • • • Stormの未来 • • • 1.0の機能群が強い ポジショントークに注意、試してみるのが一番かも ストリーム処理システム構成のヒント • 26 注目されている Stormのプロダクション実績の多さ FlinkやApexはこれから 要件に合わせたStream EngineやDestination選択を