分佈式流處理引擎的時代中，各家爭雄。

有了越来越多的分布式平台来实现流处理。我们不能一概而论什么是好的或坏的，这取决于对平台的需求和相关生态系统的影响。然而，Apache提供的开源软件涵盖了一些信息，我想整理一下关键点。

Apache流媒体技术概览

特殊才能

尽管被称为流处理，但由于涉及不同的定位，因此我们需要对其进行分类并梳理其特点。

数据收集系统 (shù jí xì

收集日志和事件的类型。

Flume

分散データ収集の元祖的なプロダクト。Fluentdと近い内容。
Hadoopエコシステムとして登場したが、最近は、あまり聞かない。

Kafka Streams

元々、LinkedInが開発したメッセージングシステム。Pub-Sub型のメッセージングをサポートするが、キューとしての機能も持つ。
高速、かつ、耐障害性に強く、動的なスケールアウトも可能。

数据流ETL（提取/转换/加载）系统

对于事件数据进行实时处理的类型。

Nifi

米国家安全保障局（NSA）がOSSとして公開。
WebUIで、データフローを定義可能で、信頼性と性能のトレードオフ、動的な変更などが可能。
双方向のフローが可能。

流式处理系统

一种能够进行通用流处理的类型。

Storm

Twitter社が公開したOSS。分散ストリーム処理プラットフォームの火付け役的な存在。
大規模な活用事例も多い。YahooやSpotifyの他、SalesforceのIoTプラットフォームであるThunderでも利用されえている。Hortonworks、Microsoft Azureなどでもプラットフォームとして利用できるようになっている。
Singleイベントとして処理するSpout／Bolt構成の Storm Core と、Micro-batchとして動作する Storm Trident のタイプがある。
Storm Core は At Least Once、Storm Trident は Exactly Once。

Spark Streaming

Sparkのリアルタイム処理エンジン。Hadoopが（バッチ処理の）Sparkと連携することが増えているため、Hadoopファミリとしての利用例が増えている。
Micro-batchとして動作する。Exactly Once に対応しているとあるが、耐障害性を考慮すると At Least Once。
Stormと比較されることが多かったが、最近では、競合となるのはFlinkだと思っている。

Apex

DataTorrent社が公開したOSS。
YARNベースで、Hadoopと連携する。
Exactly Once。

Samza

Kafkaと同様、LinkedInで開発された。そのため、Kafkaとの統合が容易。

Flink

耐障害性に優れており、ダウンしても自動で復旧し、処理を継続することが可能。
ストリーム処理だけでなく、バッチ処理をサポートしていたり、機械学習のライブラリも存在する。
Exactly Once。

Ignite

インメモリ・データグリッドとしての特性をもつ。Sparkなどとも連携可能。
Scanクエリ、SQLクエリ、テキストクエリなど、多彩なクエリに対応する。
At Least Once。

Gearpump

高スループット、低レイテンシを意識。
StormやSamzaと互換性を持つ。
At Least Once、Exactly Onceの両方に対応可。

Beam

Google Cloud Dataflow のモデルをOSS化したもの。ストリーム処理とバッチ処理の両モードに対応する。
バックエンドとして、Flink、Spark、Google Cloud Dataflow を利用できる。Googleが、ストリーム処理エンジンの統合を狙ったものを考えられる。
Auto-scalingに対応する。
Exactly Once。

选择时的重点

尽管我无法完全调查所有产品的内容，但在开发流处理系统的过程中，我总结了一些我认为重要的要点。

性能と耐障害性

ストリーム処理は、リアルタイムの処理となるため、性能が重要視されるのは間違いありません。ただ、それと同様に、耐障害性は重要となります。どのプロダクトも、耐障害性をうたっていますが、At Least Once（少なくとも1度は処理する）なのか、Exactly Once（必ず1度だけ処理する）といったメッセージの信頼性が異なったり、障害が発生したときのプログラミングモデルもプロダクトによって異なりますが、データ収集や保存の方式によって、どこで信頼性を担保するのかも変わってくるので、システム全体のアーキテクチャをふまえて、検討する必要があるでしょう。

Single-Event vs Micro-Batch

Stormのように、プログラミングモデルの違いにより、両方をサポートするケースもありますし、Spark Streamingのように、Micro-Batchに特化しているようなモノもあります。
Single-Event方式では、1メッセージ毎の遅延は少なくなりますが、Micro-Batchでは、短い時間スパンでの集計処理などを行うことが可能になったりします。

Streaming + Batch

Spark／Spark Streamingにより、ストリーム処理とバッチ処理の両方に対応します。また、FlinkやBeamのように、ひとつのプロダクトで、両方をサポートするケースもあります。
システム全体を考えた場合、ストリーム処理とバッチ処理の両方を利用するケースは多いため、そのような要件も踏まえて、選択するのもありでしょう。

プログラミングモデル

Stormなどは、低レベルのAPIで処理を実現しますが、Spark Streaming／Flinkでは、高レベルのAPIが提供されており、分散処理をあまり意識せずに、実装を行えます（その分、障害発生時の切り分けは難しくなる傾向もある）。

運用性

大量のデータをストリーム処理するとなると、ログを出力して動作を確認する、というわけにはいかなくなります（ログが大量に出力されることになる）。
そのため、管理コンソール画面の存在は大きいです。スループットやエラー情報など、管理コンソール画面で確認できると、運用が楽になります。
また、障害発生時に、他システムへ通知を行えるなどの機能も重要です。

个人观点

在数据收集领域，日本以Fluentd而闻名，但海外似乎越来越多地使用Kafka的案例。目前，无论是Hortonworks还是Cloudera，都已经开始支持Kafka。由于LinkedIn被微软收购，其未来的动向备受关注，但我认为Kafka的普及将继续扩大。

由于我们并没有尝试所有的流处理系统，因此很难做出判断，但现在的案例中，我认为Storm/Spark Streaming是最多的。
然而，虽然Flink在日本的知名度较低，但它也有一些优势，未来可能会增加使用的情况。