稼働デモのご紹介
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周りはまだ固まっていないものが多い その１
元々KafkaUtils.createStream()が一般的に良く使われていたが、v1.3.0からKafkaUtils.createDirectStreamが追加された。
より効率的な処理ができる！ → 利用した → 動作しない → しかもバグ…（SPARK-9780） → 1.5.0で修正されたらしい → 1.5.0出てない → 全米が泣いた
＞＃MultiPartitionやめてSinglePartitionに変更した
ハマりどころ 2/6Kafka&SparkStreaming周りはまだ固まっていないものが多い その２
SparkUIにKafkaのReceiverStatisticsが出てこない。
＞Streaming側である程度情報を収集するようにプログラム変更した
ハマりどころ 3/6Kafka&SparkStreaming周りはまだ固まっていないものが多い その３
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_922337059660945100２
ハマりどころ 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処理へ！
まとめ
「いい意味で、何でもあり」な会社
プレゼンを読み込み中…
リモートでプレゼン
次のリンクをメールかテキストで送信。
プレゼンする
- オンラインでのプレゼンに参加者を招待。参加者はプレゼンターの動きを追えます。
- プレゼン参加者が、Preziのアカウントを持っている必要はありません。
- このリンクは、オーナーがPreziを閉じて 10分後 に無効になります。
- 最大 30ユーザー がプレゼンに参加、プレゼンターの動きを追うことができます。
- この機能の詳細については マニュアルをご参照ください。
PreziのいいねをFacebookでシェアしますか？
FacebookアカウントをPreziに接続して、あなたのタイムラインを公開しましょう。
設定とアカウントはいつでも変更可能です。
DMMのビッグデータ収集のご紹介
Kafka, HBase, SparkStreamingによる大規模情報収集解析
作成者 :
ツイート