読者です 読者をやめる 読者になる 読者になる

JAWS-UG Meguro #2 に行ってきた

だいぶ前になってしまいましたが、9/25に行われたJAWS-UG Meguro #2に行ってきました。その時のメモです。

jawsug-meguro.connpass.com

Stream処理(SparkStreaming + Kafka)とOffline処理(Hive)の統合

資料: http://www.slideshare.net/smartnews/stremspark-streaming-kinesisofflinehive

  • Smartnewsの記事ランキングをSparkStreamingで計算する話
    • 記事分析基盤とログ解析基盤が統合されたおかげで、一箇所で生成できるようになった
  • ランキングに必要なデータ
    • リアルタイムデータ
      • ユーザーの行動ログ
      • 記事情報
    • オフラインデータ
      • 長期的なログデータ
        • ユーザーや記事の特徴ベクトル
  • 昔はモノリシックなアプリケーションになっていて、検索だけを柔軟にしたりすることができなかった
  • ログ解析基盤
    • Hive / Presto / Sparkの使い分け(on EMR)
    • メタデータはRDS, ログはS3へ保存
  • Kinesisでログを流してSparkStreamingで処理。
    • 必要なデータはSparkSQLを適宜利用。
    • S3に学習モデルを保存しておいたり。
    • ランキングはDynamoDBへ保存。
      • 複数のランキングを保存しておいてABテストができたり。
  • ストリームとオフライン処理をJOINできる
    • 事前にユーザークラスタリングしておいて、その結果ごとのランキングを作ったり。

Kinesis vs. Kafka -- Kinesisと比較しながらKafkaのガチな話

資料: http://www.slideshare.net/uprush/kinesis-vskafkaandkafkadeepdive-53191809

  • Hortonworks
  • KinesisとKafka
    • 似ているところ
      • メッセージシステム
      • リアルタイム処理
      • 対障害性・パフォーマンスが高い。
    • 違うところ
      • サービス / OSS
      • Kinesisは耐久性重視、Kafkaはパフォーマンス重視
      • REST API / Native API
      • AWS integration / single integration
      • Oneclick deploy, cloudwatch monitoring, auto rebalance / Ambariを使うとOneclick deployできる, monitoringもできる, リバランスもできる
  • Kafkaの構成
    • Producer → Broker → Consumer
    • Replicaを増やしてもパフォーマンスは上がらない。
    • パーティションに分割してLeaderパーティションにだけ送信。
    • データをConsumerにpushすることはない。poolのみ。
    • OffsetをKafkaかZookeeperのどちらかに保存できる。
    • パーティションの数以上のConsumerは利用してもパフォーマンスはあがらない

教育系のアプリで学習ログをKinesisに流してみてリアルタイム分析を始めてみた

  • Recruit Marketing Partners
    • 英単語アプリのログ収集
  • ユーザーごとの個の属性を分析
    • どの英単語を正解して、間違えたのか
  • リアルタイムな不正解ランキング
  • fluentd → Kinesis → TD, S3 etc.
  • DynamoDBでシーケンスナンバーを保存
  • すべてDocker上で管理(ECSで管理)

今更聞けないストリーム処理の"あれ"とか"これ"

資料: http://www.slideshare.net/myfinder/ss-53267492

  • あれ・・・どの基盤を選択するか
  • これ・・・どの技術を選択するか
  • 目的/事情によって異なる
    • PaaSでやりたい - 自前でやりたい
    • SQLでやりたい - プログラムでやりたい
  • crontabに * * * * * とかくような似非ストリームはやめよう
  • 自分で構築してプログラムでやりたい → Spark
  • PaaSにまかせてプログラムは書きたい → Kinesis + Lambda / GCP pubsub
  • 自分で構築してSQL → fluentd + Norikra
    • スケーラビリティが問題
    • Kafka + SparkStreaming SQL を使う手も
  • PaaSを使ってSQLでやる → Kinesis + SparkStreaming SQL
    • Azureもあり

SparkStreaming on AWS - S3からKinesisへ -

  • ビズリーチ
  • 検索エンジンはElasticsearch, それ以外はAWSサービスで構築
  • SparkStreamingからElasticsearchに求人データを投入
  • Stormほどの本当のリアルタイムなストリーミングは必要ないので、SparkStreamingを利用
  • ロストが許されないデータが合ったので取り込み元はS3を選択
  • SparkStreamingはファイルから読み込む場合は1コアでも動く
  • サイズが小さいファイルが多数ある場合はスキャン時間がボトルネックになってしまう
    • ファイルが多くなるとタスクが追いつかなくなる
  • ロストが許されないデータは別で担保するとしてKinesisへ変更
  • Kinesis + SparkStreamingで再起動も必要もないくらい安定している
  • 監視はMackerel
    • StreamingListnerから独自で収集している情報もある。

Amazon Kinesis + Apache Spark on Amazon EMR

資料: http://www.slideshare.net/RecruitLifestyle/ss-53400381

  • リクルートライフスタイルの横断ログ収集基盤の構築
  • データ収集のシステムは構築済。今はデータ活用段階。
  • fluentd → es / BQ / S3
  • 用途: Airレジ
    • コールセンター向けに操作ログ可視化
      • 戸惑いポイントの発見などに活用
  • fluentd → kinesis → SparkStreaming → DynamoDB → APIとして提供
  • リアルタイムなレコメンドや異常検知
  • SQS使った自前アプリケーションからSparkStreamingでDynamoDBにINSERTする仕組みへ移行した
    • 書き込み制限を気にしなくてよい感じに