什么是Apache Apex？
你好。
最近流行的流处理产品之一是Apache Apex，我从演示文稿中摘录了一些要点，现在整理如下。
不过，在此之前，为什么我会尝试做这样的事情呢，这个经过……
最新的流处理产品概况
因为我从很早以前就喜欢流处理产品并一直关注着，所以我时刻保持着对松散的信息的追踪。
但是，用一句话来概括最近的状况，说实话，太多事情发生了，让人有点摸不着头脑。
暂时来看，在我（有限的）观察范围内，已经出现了这么多的产品。
由于发布时间是大致的，所以只需要您对有很多产品的情况有这样的一个印象即可。
另外，Kafka Streams没有图标，可以使用confluent的图标。如果有人知道的话，也可以使用这个。
所以，在上述的选项中，我个人最感兴趣的是在分布式集群上以分布式JVM运行的以下产品：
– Apache Flink（data Artisans）
– Apache Apex（DataTorrent）
– Apache Gearpump（Intel/Lightbend）
– Heron（Twitter）
最近我也在想，虽然Apache的产品很多，但是把一切都变成Apache的产品真的好吗？实际上会怎样呢？
不过，无论如何，至于上面提到的Flink，已经有人使用过或者打算使用它，并且有相应的信息。
至于Gearpump和Heron，我自己也稍微调查了一下，并且大致了解它们的概要。
总之，参考资料先放在下面。
阿帕奇·弗林克
-
- Apache Flinkを試している
http://ogibayashi.github.io/blog/2016/02/26/trying-apache-flink/
Apache Flinkを試してみての感想
http://ogibayashi.github.io/blog/2016/05/13/thoughts-on-apache-flink/
Apache Flink とは
http://x1.inkenkun.com/archives/5406
Apache Flinkをインストール
http://x1.inkenkun.com/archives/5415
Apache Gearpump 是一个开源的实时大数据流处理框架。
-
- リアルタイム処理エンジンGearpumpって？
http://qiita.com/kimutansk/items/bd4d3a3b5556a4d4b107
リアルタイム処理基盤Gearpumpの概要構成はどうなっているの？
http://qiita.com/kimutansk/items/4b99fb2fc1e63e366066
Gearpumpのローカル環境の起動方法＆デプロイ方法
http://qiita.com/kimutansk/items/dd27fd0329174a9a1b09
鸟种
-
- Twitter HeronはStormに比べてどう進化しているのか？
Twitter Heronの論文でのStormの問題とHeronの利点は？（サマリ
Twitter Heronの論文でのStormの問題点は？（詳細
Twitterの新ストリーム処理基盤、Heronのアーキテクチャは？（詳細
然而，关于Apex的实际情况和概述我几乎一无所知。因此，首先我需要查看一些资料来了解其概要，这就是背景的由来。
Apache Apex的文档在哪里？
稍微查询一下，发现了很多资料（汗
不过因为有很多重叠内容，所以挑选了一些能相对全面地涵盖的资料
结果如下所示。
-
- Apache Apex Fault Tolerance and Processing Semantics
Apache Apex as a YARN Apllication
Apache Apex Introduction with PubMatic
尽管如此，由于接下来的资料也存在相应的重复，我们将尝试提取特征。
从数据中提取特征的结果
在进行抽样后，我们发现有以下组成和特点…
-
- OperatorでDAGを組んで、アプリケーションを構築
Operatorは基本はメッセージのウィンドウを常時管理して処理を行う。
ウィンドウの最後にメッセージを送るということも可能
コードの組み方はStormに非常に似ている。
YARNを用い、HDFSに状態を保持するためHadoopクラスタ上で運用しやすい。
そのため、デフォルトの状態保持機構が充実
アプリケーションマスタもHDFSに状態保存
手法としてはシリアライズしたOperatorを保存するもの。
メッセージの処理結果をバッファリングし、下流側が取得しに来るモデル
そのため、BackPressureの機構を明示的に盛り込む必要はない。
ただ、つまりはPullモデルになるため、速度的には疑問符あり。
局所性設定をラック単位、ノード単位、コンテナ単位、スレッド単位で設定可能
アプリケーション起動中にコンポーネントの更新や追加が可能
アプリケーション起動中に並列度の更新が可能で、オートスケール機構を有する
UIからPipeline builderでストリーム処理が記述可能
管理UIに論理ビュー、物理ビュー、クラスタダッシュボードを有する
据看来，还需要使用HDHT（Hadoop分布式哈希表）机制将操作者的状态快速保存到HDFS上。
-
- Data Store for Scalable Stream Processing
https://www.datatorrent.com/data-store-for-scalable-stream-processing/
然而，从外观上看，似乎是在客户端上缓冲写入，并以异步方式将其刷新到HDFS。
相比于HBase等其他存储层，能够构建简易且响应迅速的保存层是一件好事，但由于不是同步保存，所以可靠性仍然存在疑问。
然而，在流处理中每次都使用同步写入HDFS来保存每个状态是不可取的，虽然可以说我们能理解对此进行处理的必要性。
因此，如果您希望高速且可靠，那么应该使用HBase或分布式缓存系统产品来解决问题，而不是使用HDHT。
可以将HDHT仅视为一种简易缓存，可以将状态保存在HDFS上，这样来看可能更好。
如果有人能够提供更多补充信息的话，那就非常感谢了…
总结
如上所述，我简要地概述了Apex的构成和特点。
简单来说，可能会形成一个适应 YARN 和 HDFS、可以方便地进行状态保存并在运行时进行配置更新的流处理引擎。
Flink无法在运行时进行配置更新，而Gearpump在状态保存方面的便利性不足。相比这两者，这个产品功能更加完善，从使用情况和实例来看，它似乎也更成熟。
在这之后，我会同时学习Gearpump和Heron，并且阅读各种文档，尝试实际操作来进行试验。
那么好吧。
