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のビッグデータ収集のご紹介

Kafka, HBase, SparkStreamingによる大規模情報収集解析
by

DMM Tokyo-des

on 6 November 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of DMMのビッグデータ収集のご紹介

稼働デモのご紹介

DMM.com Labo
DMMのビッグデータ収集のご紹介 ~Kafka+HBase+SparkStreamingによる大規模情報収集解析~

自己紹介
田中 裕一 (Yuichi Tanaka)
株式会社DMM.com ラボ
CTO室

CTO室とは?
新しい技術の検証や研究開発をしています。
事業とは切り離した技術先行の部署です。

以前からこのようなことをやっていました
・大規模分析 x リアルタイム x cutting edge 〜twitterの数ある艦これBot、なりきりアカウントの解析〜
・DMMビッグデータ分析のご紹介 〜Sparkによるリアルタイムレコメンド〜
ビッグデータの基礎ができた!→社内のデータをどんどん集めよう!→リアルタイムにどんどん処理したい!

DMMでは現在39のサービスを運営しています。
以前できあがった基盤では、SparkStreaming, GraphX, Solr, SparkMLibを利用した
ビッグデータの収集を行っていました。
リアルタイム処理系で、Apache Kafkaが流行っているそうなので、これの活用方法を考えました。

今回使ったもの
・Apache Kafka
・SparkStreaming
・HBase

今回説明することしないこと
説明すること
・各ミドルウェアの概要
・DMMでの各ミドルウェアを使った事例

説明しないこと
・Scala/Javaの文法
・各ミドルウェアの詳しい仕組み

Apache Kafkaとは
分散メッセージングシステム
高速に高負荷な書き込み・読み込みが可能。
Cluster構成でスケール可能なメッセージングシステム。
投入されたメッセージはDiskに保存され、レプリカを持つ事で障害時にも安定的に稼働。
Pull型でメッセージを処理する事で、メッセージの消費側の都合に合わせた処理が可能。

SparkStreamingとは
HDFS上で動作するストリーミング処理システム。
データの流れからn秒分のデータをRDDとして扱い複数のRDDを纏めたDstreamの単位でも処理が可能です。

HBaseとは
HDFS上で動作する大規模分散データストア。
MasterとRegionServerで構成され、高速なアクセスと巨大なデータセットの保持を両立しています。

できあがった基盤
データの種類を増やす→リアルタイム保存→リアルタイム処理→データの可視化

データの種類を増やす
集めるデータは
1.DMMサービス上でのユーザーの行動ログ ←今回はここの話
2.IoTデータ
3.セキュリティデータ
4.サーバーのアプリケーションログ
5.サーバーのアクセスデータ
6.ソーシャルデータ

ハマりどころ 1/6
Kafka&SparkStreaming周りはまだ固まっていないものが多い その1
元々KafkaUtils.createStream()が一般的に良く使われていたが、v1.3.0からKafkaUtils.createDirectStreamが追加された。
より効率的な処理ができる! → 利用した → 動作しない → しかもバグ…(SPARK-9780) → 1.5.0で修正されたらしい → 1.5.0出てない → 全米が泣いた
>#MultiPartitionやめてSinglePartitionに変更した

ハマりどころ 2/6Kafka&SparkStreaming周りはまだ固まっていないものが多い その2
SparkUIにKafkaのReceiverStatisticsが出てこない。
>Streaming側である程度情報を収集するようにプログラム変更した

ハマりどころ 3/6Kafka&SparkStreaming周りはまだ固まっていないものが多い その3
SparkStreamingのチューニングでKafka周りだけなぜか分かれている。
spark.streaming.receiver.maxRateを設定したつもりだったが、kafkaの場合だけspark.streaming.kafka.maxRatePerPartitionと分離している。
しかもVersion上がるとしれっと増える。
>spark.streaming.kafka.maxRetries(1.4で追加)。Documentは毎回しっかり読もう。

ハマりどころ 4/6HBaseのKey設計は重要
HBaseのRowKeyにReverseDomainを設定したら負荷が偏った。
RowKey: com.dmm(.comドメインサーバ)
RowKey: jp.co.dmm(co.jpドメインサーバ)
全体アクセスの大半が単一サーバに負荷が集中していた。
>事業部(アプリケーション)単位にユニークIDを振り、ReverseTimeStampを割り当てた。
>RowKey:i3_XXXXXX_9223370596609451002

ハマりどころ 5/6Flumeの設定は重要
高負荷になるとchannelがすぐに溢れてしまう。
channelの例外が出始めるとどんどん処理が溜まって取り返しがつかなくなる。
>capacityとtransaction_capacityをディフォルト100から100000まで広げて、一旦解決。

ハマりどころ 6/6Flumeは別サーバーにする
SparkのCluster上にFlumeを同居させていた。
その結果、Flumeが不具合を起こした場合、SparkStreamingの性能を引っ張ってしまう。
CGroupで分ける事も可能だが、HDFS,YARN,HBase等リソース配分を考えるのは非常に難しい。
>可能ならFlumeだけサーバーを分けておいた方が良い。

Apache Kafka + SparkStreamingを使ってみて
1.Pull型で処理するため、メッセージの消費をConsumer側で制御可能
Inputされたメッセージに対して複数の処理を別に行う事が可能。
2.分散でメッセージをストアさせる事ができるため、後方の処理と分離しメンテナンス性を上げる事ができる。
3.メッセージの消費側でキューの消費量をコントロールできるため、「とりあえず」データを終端して後で処理を考えることもできる。
4.SparkStreamingのデータロスト問題をKafka側で巧くカバーできる。
5.Jobフロー的にSparkStreamingを繋げる事もできる。

夢が広がる。時代はStream処理へ!

まとめ
「いい意味で、何でもあり」な会社
Full transcript