Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

DMM.comでSpark+Kafkaを使ったアーキテクチャ事例

DMM.com Labo - Cloudera World Tokyo 2015
by

DMM Tokyo-des

on 10 November 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of DMM.comでSpark+Kafkaを使ったアーキテクチャ事例

DMM.comでSpark+Kafkaを使ったアーキテクチャ事例
DMM.com Labo - Cloudera World Tokyo 2015
【アジェンダ】
・ちょっとだけDMMのご紹介
・DMMのSparkへの取り組み
・DMMのBigData基盤

■ちょっとだけDMMのご紹介
現在約40のサービスを展開しています。
■DMMのSparkへの取り組み
・艦これbot解析(Slideあり)
・SparkStreamingによるリアルタイムレコメンド(Slideあり)
・Kafka+Sparkによる大規模ログ収集基盤(Slideあり)
⇒Spark(特にStreaming,GraphX)のナレッジが多い、意外とちゃんと「技術」の会社です。
DMMのBigData基盤(Spark,Kafka前)
ベースはHadoop(HDFS,YARN)とエコシステムで構成

−その基盤で何をやってたか
・主に行動ログの集約
・行動ログからの施策効果の可視化とか
・GAだと難しいサービスの利用深度の可視化

−目標としていた事
・行動ログ以外もキチンと収集して行きたい
・サーバーの情報
・サーバーのアクセスログ
・IoTデータ
・セキュリティデータ
・ログの反映時間の短縮
・可視化時間の短縮
・ログをストアするまでの時間の短縮
・リアルタイムなレコメンドを作る
・より高精度なレコメンド
・レコメンド計算時間の短縮
・ユーザーの行動の即時反映(リタゲ的な)
・新しいレコメンドの形の模索
・パーソナライズ検索
・個々のニーズにあった1to1の検索結果の提供
・検索精度の向上

−既存基盤での課題
・Hiveでの集計時間の増大
・アーキテクチャ上即時のログのストアが難しい
・各プロダクト毎のログの個別設計の負荷

⇒そこでKafka,Sparkの投入

−Kafkaの概要
DMMでの今回の事例を使った概要
#Kafkaの俯瞰
#KafkaのTopicとConsumerGroupの関係

−SparkStreamingの概要
SparkStreamingの処理のおさらい
SparkStreamingはデータを小さく分割してマイクロバッチ処理

−Streaming処理系の俯瞰
代表的なStreaming処理系
・SparkStreaming
・Flink
・Storm
・Samza

−SparkとFlink,Storm,Samzaの違う点
・SparkStreamingはデータを小さく分割してマイクロバッチ処理
・Flink,Storm,Samzaは基本的にdata-to-dataの処理

#元々の基盤で行っていた集計等の処理をStream処理するのは良さそう!
#他にも「リアルタイム」に処理したい所でも使い勝手が良さそう!

⇒と言う事でSparkStreamingを採用

−基盤の拡張
Kafka,Spark,HBaseを引く

−基盤を拡張して出来る様になった事
・多様なデータの終端が可能
「とりあえず」Kafkaに全データを終端、不要なデータはExpireで消えてく
・ログの反映時間の短縮
HBaseに流し込む事で2時間(HDFSへの反映)が10~20秒程度に
・可視化の時間短縮
一部集計処理をSparkStreamingに移す事で2時間(HDFSへの反映)+集計処理(数十分)が5秒に

■SparkStreamingを使ってみて
−良かったこと
・Sparkと同じような感覚でプログラミング可能なのでプログラムの敷居は低い(但しScala)
・Hadoopと相性がよく、すんなりと既存の基盤(HDFS+YARN)の上に敷くことが出来る
 CDH使ってれば30分もあれば準備は出来る

−気をつけたいこと
・Streamingは他のSparkアプリと違ってCPUやメモリを長時間占有
 当たり前と言えば当たり前だけど既存処理に影響出ないように注意は必要
・Streaming処理自体のチューニングは必須
 動かすだけなら問題なく動かす事が可能
 でもマイクロバッチ処理を恒常的にn秒以内で処理を完了させるのは難しい

■Kafkaを使ってみて
■KafkaとSaprkStreamingを組み合わせてみて
・KafkaとSparkStreamingを組み合わせる事でStreaming処理をきれいに分離可能になる
・モジュール単位にStreaming処理を分離する事で可読性、再利用性を向上させる事が出来る
・小さく処理を分離する事でStreaming処理のチューニングもしやすくなる

■SparkStreamingを使ってみて、ダメだった事
・インシデント管理(特定データをフックした際の即時発報)
・シビアなセキュリティ処理(特定データをフックしたロック処理)
・行動の即時反映(一つ前に見ていたページや行動を、今のページに反映させる)
要するに、1秒以下のレイテンシを必要とする処理はSparkStreamingでは無理(#当たり前
SparkStreaming(【ニア】リアルタイム)で何をやりたいかは重要(#反省の意を込めて
SparkStreamingに限らず、Spark全体でも何が得意で、何が苦手なのか?はアーキテクチャを作る際に考えるべき。
Full transcript