Upgrade to Pro — share decks privately, control downloads, hide ads and more …

イベントストリーミング入門 〜Apache Kafkaを活用した大規模リアルタイムデータ処理〜

イベントストリーミング入門 〜Apache Kafkaを活用した大規模リアルタイムデータ処理〜

OSC 2022 Online Fallの発表資料です。初心者向けにApache Kafkaの概要を解説しています。

Akio SHIMIZU

October 29, 2022
Tweet

More Decks by Akio SHIMIZU

Other Decks in Technology

Transcript

  1. Data at RestはData in Motionに変わっていく 輸送機関 リアルタイムのセンサー 診断 運転手-乗客のマッチング 到着予想時刻のリアル

    タイム更新 銀行 不正使用の検出 取引・リスクの管理 モバイルアプリ / 顧客体験の向上 小売 リアルタイム在庫管理 リアルタイムPOS レポート パーソナライゼーション 娯楽 リアルタイムの リコメンデーション パーソナライズされた お薦め アプリ内決済
  2. Data in Motionによるお客様価値 あらゆる データソースから DB、ログ、メトリクス、 モバイルアプリ、マイク ロサービス、IoTセンサー など In-Transit

    Processing 仕入/販売データ 在庫/流通データ トランザクション データ 顧客行動/興味 データ あらゆる データ活用先へ DB、モバイルアプリ、マ イクロサービス、APIエン ドポイント、アナリティ クス、BIツール、MLなど In-Transit ガバナンス セキュリティと一貫性のためにフ ローを一元的に管理 - アクセスコン トロール、データ保護、スキーマの 一貫性、DR、BC、など データを最適変換 データは移動中に必要に応じて形を 変えます- すべてのソースからの データは平等に扱われ、違いは Confluentによって抽象化されます 14
  3. 15 Data in Motionは 消費者が日常的に 使用するアプリを 動かす基盤に不可欠な データインフラです Acme Retailerから$1000の請求がありました

    この取引を確認してください。 Jun Raoがアプリから100ドルを 送ってきました ご注文のドライバーが来ました 待機料金は3分後にスタートします ご注文いただいた商品がまもなく お手元に届きます
  4. 16 “あなたのドライバーは何分後に到着する?” これはData in Motionなしでは実現できません 運転手評価 乗車運賃 支払い 位置情報 利用者情報

    複数のリアルタイムイベントを取得 利用者の位置情報に基づき複数の車両情報を取 得して最適な車両をアサインします 過去数年のデータから同条件のみ抽出・融合 距離・都市・天候・時間帯などを組み合わせて 同条件での到着時間を抽出します 課金情報の”確実に一度だけ”の送信保証 重要なトランザクションデータをexactly once で届ける事が可能です
  5. 18 
 
 
 
 
 
 
 
 スマートアナリティク

    ス (AI/ML)
 
 
 
 
 
 
 
 
 異常検出
 アプリケーションの
 モダナイゼーション
 データ
 交換
 IT の可観測性と
 SIEM の最適化
 コンプライアンスと
 規制
 マイクロサービス/
 イベントソーシング
 ストリーミング
 ETL
 ログ
 集計
 IoT / Edge 
 アナリティクス
 サイバー
 セキュリティ
 データインフラストラクチャのユースケース ビジネスアプリケーションのユースケース データ
 パイプライン
 ハイブリッドとマルチクラ ウドの統合
 Customer
 360
 メインフレームの強化
 データウェアハウスのモ ダナイゼーション
 メッセージングの
 モダナイゼーション
 データベースの
 モダナイゼーション
 Apache Kafkaの代表的なユースケース
  6. Topic • 類似イベントを格納する名前付きコンテナ ◦ システムには多くのTopicが存在する ◦ Topic間でデータが重複することもできる • イベントの耐久性のあるログ ◦

    追記(Append)のみ ◦ オフセットによるシークのみ可能で、インデックス化はされない • イベントは不変 (immutable)
  7. Topic • 一連の「関連した」 イベント 33 • 同じような頻度と サイズ • より洗練させられる

    顧客プロファイルの更新 更新要求 課金情報の更新 claims-updates new-claims new-claims-O H
  8. Topicのリテンション・ポリシー イベントをどれだけの期間保持する必要があるか ? • どれだけの期間 (デフォルト: 1週間) • Topic単位で設定 ◦

    もしくはBorokerのデフォルト値を使用 • 業務要件による決定 • コスト要因 • コンプライアンス要因 (例: GDPR)
  9. ストリーム処理のアーキテクチャをシンプルに DB CONNECTOR CONNECTOR APP APP DB STREAM PROCESSING CONNECTOR

    APP DB 2 3 4 現状では、3から5にわたる分散システムの構築・インテグレーション・管理が必要 1
  10. イベントとステート- Pull QueryとPush Query Seven Eleven payment: 500 JPY CREATE

    STREAM payments AS SELECT Account_id, store, amount FROM transactions EMIT CHANGES; CREATE TABLE payment_sum AS SELECT account_id, SUM (amount) FROM transactions GROUP BY account_id TUMBLING WINDOW (1 DAY) EMIT CHANGES; Yoshinoya payment: 800 JPY AEON payment: 2,400 JPY hashi: 3700 JPY PULL hashi: Seven Eleven, 500 JPY hashi: Yoshinoya, 800 JPY hashi: AEON, 2400 JPY PUSH hashi: 500 JPY hashi: 1300 JPY hashi: 3700 JPY PUSH
  11. -- pq1 CREATE STREAM high_readings AS SELECT sensor, reading, UCASE(location)

    AS location FROM readings WHERE reading > 41 EMIT CHANGES;