碍补蹿办补を活用するためのストリーム処理の基本
Download as PPTX, PDF24 likes8,482 views
2016/05/31 Apache Kafka Meetup Japan #1 での発表資料
More Related Content
What's hot (20)
Similar to 碍补蹿办补を活用するためのストリーム処理の基本 (20)
More from Sotaro Kimura (11)
碍补蹿办补を活用するためのストリーム処理の基本
- 1. Kafkaを活用するための ストリーム処理の基本 2016/05/31 Apache Kafka Meetup Japan #1 木村宗太郎（@kimutansk） https://www.flickr.com/photos/gruenewiese/13194312524
- 2. 自己紹介 ? 木村 宗太郎（Sotaro Kimura） ? ビッグデータ界隈に生息する何でも屋 ? バックエンドからフロントエンド、技術検証から運用、 ドキュメント書きまで色々 ? Kafkaとの出会いは3年程前に Stormとの連携を試したのがキッカケ。 ? だが、その後大規模なものをやる機会には恵まれず... ? 自宅サーバには常に入っています。 ? Twitter他 : @kimutansk 1
- 3. アジェンダ 1. Kafkaのデータ活用モデル 2. ストリーム処理とは？ 3. ストリーム処理プロダクト概況 4. ストリーム処理で考えるべきこと 2
- 4. 3 1. Kafkaのデータ活用モデル ? Kafkaのデータの用い方は大きく２つある。 1. 一気にまとめて取得するモデル 2. 常時取得し続けるモデル
- 5. 4 1. Kafkaのデータ活用モデル 1. 一気にまとめて取得するモデル Log Log Log Log Log Log Log Log Log Log Log Log Log Log Log
- 6. 5 1. Kafkaのデータ活用モデル 1. 一気にまとめて取得するモデル Log LogLog Log Log Log Log Log LogLog Log Log LogLog Log
- 7. 6 1. Kafkaのデータ活用モデル 2. 常時取得し続けるモデル Log Log Log Log Log Log Log Log Log Log Log Log Log Log Log
- 8. 7 1. Kafkaのデータ活用モデル 2. 常時取得し続けるモデル Log Log Log Log Log Log Log Log Log Log Log LogLog Log
- 9. 8 2. ストリーム処理とは？ バッチ処理 対話型クエリ ストリーム処理 実行タイミング 手動起動 定期実行 手動起動 定期実行 常時実行 処理単位 保存済みデータを 一括処理 保存済みデータを 一括処理 １～少数の フローデータを処理 実行時間 分～時間 秒～分 永続実行 データサイズ TBs～PBs GBs～TBs Bs～KBs（1件あたり） 処理時間 分～時間 秒～分 ミリ秒～秒 主な用途 ETL ビジネスレポート生成 機械学習モデリング インタラクティブBI 分析 異常／不正検知 レコメンド 可視化 代表的 OSSプロダクト MapReduce Spark Tez Impala Drill Presto （後述） ? ビッグデータの処理モデルは主に３つある。
- 10. 9 2. ストリーム処理とは？ ? バッチ処理 ? データストアに蓄積したデータを 一括変換、レポート／モデル生成を行うモデル 生成したデータの出力先は 主にデータストア
- 11. 10 2. ストリーム処理とは？ ? 対話型クエリ ? データストアに蓄積したデータに 対してクエリを実行し、結果を取得するモデル クエリの実行結果は実行元 で取得するケースが多い
- 12. 11 2. ストリーム処理とは？ ? ストリーム処理 ? 「連続発生データを常時処理し続ける」モデル ? データの発生元は多岐にわたる センサー データ ログ アプリ 履歴 データ発生元 メッセージキュー ストリーム処理部 データ利用先 Kafkaの主な利用先
- 13. 12 2. ストリーム処理とは？ バッチ処理 対話型クエリ ストリーム処理 実行タイミング 手動起動 定期実行 手動起動 定期実行 常時実行 処理単位 保存済みデータを 一括処理 保存済みデータを 一括処理 １～少数の フローデータを処理 実行時間 分～時間 秒～分 永続実行 データサイズ TBs～PBs GBs～TBs Bs～KBs（1件あたり） 処理時間 分～時間 秒～分 ミリ秒～秒 主な用途 ETL ビジネスレポート生成 機械学習モデリング インタラクティブBI 分析 異常／不正検知 レコメンド 可視化 代表的 OSSプロダクト MapReduce Spark Tez Impala Drill Presto （後述） ? 今回の対象となるのは「ストリーム処理」
- 14. 13 3. ストリーム処理プロダクト概況 ? ストリーム処理を実現するプロダクトは多彩 ? 元は2011年のStorm公開を機に広く（？）発展 ? 以降のプロダクトにいい意味でも悪い意味でも影響 ? 最近多数のプロダクトが公開 ? 下記のような派生パターン有 ? UIでDataflow定義 ? 処理を定義可能なUIを保持するパターン ? DSL ? 同一の記述で複数のストリーム処理エンジン上で アプリケーションが実行可能
- 15. 14 3. ストリーム処理プロダクト概況 古 新公開時期 DSL UIで Dataflow定義 純ストリーム処理エンジン Storm Summingbird NiFi Spring Cloud Data Flow Cask Hydrator Beam Heron SensorBee Kafka Streams Ignite Streaming
- 16. 15 3. ストリーム処理プロダクト概況 古 新公開時期 DSL UIで Dataflow定義 純ストリーム処理エンジン Storm Summingbird NiFi Spring Cloud Data Flow Cask Hydrator Beam Heron SensorBee Kafka Streams Ignite Streaming 最近多くプロダクトが公開 正直、追いきれない状況 そのため、どれがいい、とは現状言えない。 （公開される資料はバイアスが???） かつ、今良くてもすぐ陳腐化???
- 17. 4. ストリーム処理で考えるべきこと ? ストリーム処理を構築する上で 考えるべきことについて説明します。 ? プロダクト選定時 ? サービス開発時 ? この項目自体も Storm、Spark Streamingから挙げたものです。 ? もしFlink、Apex、Gearpump等他プロダクトの 経験者がいれば、是非とも補足を。 16
- 18. 4. ストリーム処理で考えるべきこと ? プロダクト選定時に考えるべき主要観点 1. 実装言語は何か？ → 未成熟なまま開発するため、解析必須 2. インストールの際に何が必要？ → 各ホストにインストールするのは困難 3. サービス動作中にどこまで更新可能か？ → 常時動作する関係上、止められないため。 4. 接続用コンポーネントが揃っているか？ → Kafkaはほぼすべてのプロダクトと接続可能 そのため他コンポーネントの充実度が重要 17
- 19. 4. ストリーム処理で考えるべきこと ? サービス開発時に考えるべき主要観点 1. 【必要な場合】Exactly Onceの実現方法 → データストアを用いて冪等性を実現 ストリーム処理単体では実現できない。 2. データがプロセスをまたがないように配置 → シリアライズの遅延も大きな影響になる。 3. 極力メモリ上に収めるか、並列度を調整 → 基本、ディスクに同期的に書かない。 4. ログを集約する機構を準備 → 分散処理ではないとまともに解析できない。 18
- 20. まとめ ? Kafkaの活用方法には大きく2モデルある 1. 一気にまとめて取得するモデル→バッチ処理 2. 常時取得し続けるモデル→ ストリーム処理 ? ストリーム処理ベストプロダクトは選べない ? プロダクトは異なっても共通点は多い 1. 性能特性／ボトルネックとなるポイント 2. データ設計 3. 解析を行うための準備 etc ? 上記とプロダクト成熟度を踏まえ構築 19
- 22. Enjoy stream processing! and share knowledge! https://www.flickr.com/photos/elf-8/15276069760