我正在考虑使用Flink或Apache Beam(带Flink runner)用于不同的流处理应用程序。我试着比较两种选择，做出更好的选择。以下是我正在寻找的标准，我正在努力寻找flink运行器的信息(我已经找到了flink独立的基本所有信息):
- 易于使用
- <
- 吞吐量/gh>
- 多才多艺
- 指标生成
- 可以与Kubernetes(轻松)部署
以下是我认为我也已经知道答案的其他标准:
- 执行有状态操作的能力:是
- 一次保证:是
- 与Kafka很好地集成:两者都是(可能对beam有点困难)
- 语言支持:
- Flink: Java, Scala, Python, SQL
- Beam: Java, Python, GO
如果您对flink runner的这些标准有任何见解，请告诉我!如果我找到答案，我会更新帖子!
更新:我发现的关于使用Beam的优点的好文章(不要看气流部分):https://www.astronomer.io/blog/airflow-vs-apache-beam/
与OneCricketeer的评论类似，比较这两者是相当主观的。
如果你绝对确定你要使用FlinkRunner，你可以直接跳过中间人，直接使用Flink。如果Beam与你将来想要使用的特定FlinkRunner版本不兼容(或者存在bug)，它可以为你省去麻烦。如果你确定你要使用的I/o支持Flink你知道/如何设置FlinkRunner(在不同的模式),可以只使用Flink。
如果你考虑在未来转向其他语言/运行程序，Beam提供语言和运行程序的可移植性，让你编写一次管道并在任何地方运行。
Beam不仅支持Java、Python和Go:
- JavaScript: https://github.com/robertwb/beam-javascript
- Scala: https://github.com/spotify/scio <
- 兴奋API/gh>SQL
跑步者:
- DataflowRunner
- FlinkRunner
- NemoRunner
- SparkRunner
- SamzaRunner
- Twister2Runner
详细信息可在https://beam.apache.org/roadmap/上找到。
从Flink网站的一个博客回复，这可能会有帮助
将Beam与Flink一起使用的原因#为什么要将Beam与Flink而不是直接使用Flink?
最终，Beam和Flink相互补充，为用户提供额外的价值。的使用带有Flink的Beam的主要原因如下:
- Beam为批处理和流场景提供了统一的API。
- Beam自带对不同编程语言的本地支持，比如Python或Go，以及它们的库，比如Numpy, Pandas，Tensorflow，或TFX。
- 你得到Apache Flink的力量就像它精确一次语义，强内存管理和鲁棒性。
- 梁程序在现有的Flink基础结构或基础结构上运行其他支持的runner，如Spark或Google Cloud Dataflow。
- 你获得额外的功能，如侧输入和跨语言管道在Flink中不支持，但只有在使用时才支持带Flink的光束。