

大規模なデータ収集といった話になるときに、よくストリーミング処理が必要になり、  
Amazon KinesisやApatch Streamなどの話題が出ます。

複数台のサーバー -> Amazon Kinesis -> Amazon Redshift

といった具合に。

複数台のサーバー -> Amazon Redshift

といったように、複数台のサーバーから直接DBに保存するのはトランザクションの問題？や処理が追いつかなかったりするため、ストリーミング処理をするのだと私の中では認識しております。

ただ、結局、間にストリーミングサーバーを入れたところで、左から右へデータを流しているだけで、結局、処理が追いつかなかったりするのではないかと思っております。

実際はそんなことはなく、ストリーミングサーバーはそこら辺を上手くやっているのかと思われますが、そのあたりの知見をつけたく、調べているのですが、なかなか良い資料が見当たりませんでした。

※一つ、思い浮かぶのは、ある程度、ストリーミングサーバー側でデータをためて、一定以上貯まるとデータをDBへ入れるといったこととかですかね。

皆様のご経験などを踏まえ、ご教授頂けますと幸いです。

宜しくお願いします。


CC BY-SA 3.0
2016-01-05T16:09:33.357
20634
2017-03-23T05:48:10.773
2017-03-23T05:48:10.773
8000
13175
question
aws
DBに保存する前にAmazon KinesisやApatch Stream などのストリーミングサーバー?に保存する理由がわかりません。


[事例からAmazon Kinesisとは何なのかを学ぶ](http://dev.classmethod.jp/cloud/aws/what-is-
kinesis/)

上記リンクの記事は、 Amazon Kinesisの利点をコンパクトにまとめてあるので、参考にされると良いと思います。  
1年余り前の記事なので、多少情報が古い可能性があります。


CC BY-SA 3.0
2016-01-06T01:26:30.027
20639
2016-01-06T01:26:30.027
217
20634
answer


保存している理由で思いつく点は

  1. 非同期の処理で 入力データの処理量と、出力先の処理能力がイコールで無いなら、どこかで一時的に貯めておくのは 一般的な仕組みだと思います。（キューイング、キャッシュなど）

  2. データの順序性を担保して、大量の入力データに対して並列にバッチ処理を可能にするためには一時的に保存していると思います。

  3. 同じデータを何度でも取り出せるという点もProxy的なデータ転送の仕組みでは難しいのではと思います。

出力処理が追いつかない事があるという点は、リソースは有限であることを考えるとご指摘のとおりだと思います。KinesisにPutされたデータは24時間まで保持するという制限もあるので
それまでに 一度も取り出せず 出力側の処理がされない場合は、取りこぼすことになると思います。

また、Kinesisのスループットに制限はありませんが デフォルトでは10シャードまでしかスケールしません。スループットが足りない場合は
申請で緩和する必要があります。

ご参考）FAQ  
<https://aws.amazon.com/jp/kinesis/streams/faqs/>

ストリーミング処理の役目ということであれば大量発生する入力データをリアルタイムに処理してデータウェアハウス等に出力することだと思いますが。Apache
Spark Stream サイトの資料が概要としてわかりやすかったです。

<http://spark.apache.org/talks/>  
<http://spark.apache.org/talks/strata_spark_streaming.pdf>

この資料によるとストリーム処理フレームワークへの要件を次の５つとしています。  
ストリーミング処理の役目は、これらを実現することと言えるかもしれません。

  * Scalable to large clusters
  * Achieves second-scale latencies
  * Has simple programming model
  * Integrates with batch & interactive workloads
  * Ensures efficient fault-tolerance in stateful computations


CC BY-SA 3.0
2016-01-06T12:23:04.677
20671
2016-01-06T12:30:48.283
2016-01-06T12:30:48.283
5008
5008
20634
answer


大量のデータソースがデータストアに直接アクセスしていると、

  * データストアに変更を加えるのが非常に困難
  * パフォーマンスがデータソース次第になり管理できない
  * 少量のデータを多数回処理するのはオーバーヘッドが大きい
  * データソース側の処理が肥大する
  * 複数ソースのデータをまとめなければならない場合データストア側でも処理が発生する

などなどたくさんの問題生じます。データソースとデータストアの間にバッファとなる何かがあればこれらの問題は解消しやすくなります。

  * データストアのありかを知っているのはバッファ側なのでそこだけ変更すれば良い
  * バッファからの出力によってパフォーマンスが管理できる
  * データストアごとにオーバーヘッドの少ないデータ投入方法が使える
  * データソース側はバッファにデータを送るだけに特化できる
  * データの変形や集計など中間処理が可能

パフォーマンスはポイントではあるのですがそれがすべてではありません。


CC BY-SA 3.0
2016-01-07T01:06:39.613
20685
2016-01-07T01:06:39.613
5793
20634
answer