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

ストリーム処理の活用を考える

ストリーム処理の活用を考える

ストリーム処理ってなんやねんということで、頭の中身を整理したい。ついでにポエムとして公開しておこう。

ストリーム処理の特徴

なぜわざわざストリーム処理の環境を構築してまでストリーム処理を使いたいのか。 ただ単にサービスに使うためのデータを秒オーダーで処理したいだけであれば、サービス内に処理を埋め込みDBと直接疎通してもらった方がはるかに高速なシステムができる。

しかしそうではなく、ストリーム処理を導入する利点はいくつか思いつく。

  • サービスと切り離したログの処理環境を作成することができる
  • 他サービスのログを同じストリーム処理環境に投入することができる
  • データ処理リソースの均一化への貢献

単なる秒オーダーでのデータ処理環境ではなく、これらの要素と組み合わせることで初めてストリーム処理を活用しているといえることができるだろう。 もうちょっと整理する。

サービスと切り離したログの処理環境を作成することができる

実は私はサービスというものを直接開発したことがないので実感は持ってないのだけれど、サービス開発者からするとこれはかなりの利点になると思う。 分析とかやりたいけど、サービス内に処理を組み込んでしまうとちょっとした改修が入るだけでもリリース作業が発生してしまう。 サービスに直結した箇所にリリースが発生するなんて考えるとサービス断の可能性やらリリース判断やらめっちゃめんどい。

中間形態としてログという形式をとってサービスから切り離したものであればちょっとした集計をしたければ好きにやればいいのでやったー感。 ビッグデータと言われて久しい世の中なので、すでにHadoopへの回収経路が整っていたりすれば、うまくいけば横に流すだけでストリーム処理環境を構築することができる。

リアルタイムに何を分析するのか? よくあるのはA/Bテスト。 可視化環境と組み合わせておけばいい感じだよね。ここをもっとちゃんとアピールしたい。

サービスと切り離したログの処理環境を作成することができる

ビッグデータビッグデータたる所以の1つがここに関係する。3Vとか5Vとかの1つ、Variety。 意識高い感じに言うとシナジー効果を望める。 たいていの場合はHadoopとか大規模集約環境の方が使い勝手がいいんだろうけど、ユーザ行動分析とかの領域に行くとこの領域が超大事。 「どこで誰が何をしたのか?」 この情報を、リアルタイムに、集約することで、今よりもさらにユーザの目的に合致した情報提供が可能となるかもしれない。 長期的な興味やら感震やらについてはHadoopで頑張ればいいけれど、「今」ユーザが何をしているのかはこの領域で頑張らないといけない。 たぶんここが肝

どうやるの? (´・ω・`)知らんがな

データ処理リソースの均一化への貢献

ちょっと話がそれる感じするけれど、この領域はストリーム処理ならではな感じの箇所。 バッチ処理って基本1日に1回とかよくて1時間に1回とか。 どうしても計算資源を使うタイミングがどこかにまとまってしまう。 自分が知ってる限りだと、前日のデータを早期に集計せよ っていうことで深夜~朝にかけてピークが集中してる。 これを解消する1つの手段がストリーム処理。とくにData Flow Model?とかに忠実な処理エンジンができると素晴らしい。

処理によってできるできないが別れたりはするのだけれど、データが発生したそばから集計に回し、適切な集約単位にまとめ上げることで計算資源のピークタイムを、実アクセスのピークタイムまで落とすことができる。まぁ理想論な感じだけれど。

まとめ。

ちょっとすっきりした。