Apache Beam - 我应该了解编写高效数据处理管道的关键概念是什么? [英] Apache Beam - What are the key concepts for writing efficient data processing pipelines I should be aware of?
问题描述
我已经使用 Beam 一段时间了，我想知道编写高效和优化的 Beam 管道的关键概念是什么.
I've been using Beam for some time now and I'd like to know what are the key concepts for writing efficient and optimized Beam pipelines.
我有一点 Spark 背景，我知道我们可能更喜欢使用 reduceByKey 而不是 groupByKey 来避免改组和优化网络流量.
I have a little Spark background and I know that we may prefer to use a reduceByKey instead of a groupByKey to avoid shuffling and optimise network traffic.
Beam 的情况是否相同?
Is it the same case for Beam?
如果您提供一些提示或材料/最佳实践，我将不胜感激.
I'd appreciate some tips or materials/best pratices.
推荐答案
一些需要考虑的事项:
文件优先；在 DAG 中尽可能高地放置过滤器操作)
Filer first; place filter operations as high in the DAG as possible)
早点结合；如果可以选择何时合并，请尽早进行.
Combine early; If there is a choice as to when to combine, do this as early as possible.
如果可能的话，通过在大滑动窗口之前使用较小的固定窗口来减少大滑动窗口的影响.FixedWindow.of(1m) |结合 |SlidingWindow.of(6 小时)
If possible reduce the effect of large sliding windows by using smaller fixed windows before the large sliding window. FixedWindow.of(1m) | Combine | SlidingWindow.of( 6 Hour)
大多数跑步者将支持图融合，这在 99% 的情况下都是正确的.但在大规模扇出变换的情况下，您应该打破融合.
Most runners will support graph fusion, which is the right thing 99% of the time. But in the case of a massive fanout transform you should break fusion.
- 选择提供良好性能的编码器，例如在 Java 中使用 Proto 或 Avro 编码器之类的东西，而不是默认的 Java 序列化.
- 高级提示:编码/解码是一个很大的开销来源.因此，如果您有一个大的 blob 但只需要其中的一部分结构化，您可以选择性地仅解码该部分.
- 避免在每个元素级别使用 Log.info，这几乎没有什么价值，并且是许多与性能相关的问题的根本原因.
- 了解数据集和热键的含义.用作可空键的字段通常是罪魁祸首......如果需要，请使用并行提示 withFanOut
对于一般的键
- Understand the data set and the implications of Hot keys. Fields that are used as Keys which are Nullable are often culprits... Make use of parallelism hints if needed withFanOut
For keys in general
- 键太少:不好 - 难以分片工作负载和按键排序会影响性能
- 键太多:也可能很糟糕 - 开销开始蔓延.
高级关键提示:
- 有时您可以将一个键与元素 {key,Window} 的窗口结合起来，以帮助更多地分配工作
- 不是必需的，但如果您有能力并希望进入这种优化级别；瞄准 ~ O(10K) 到 O(100K) 个键.如果键空间大得多，您可以考虑使用散列在内部将键分开.如果键带有日期/时间信息，这尤其有用.在这种情况下，您可以免费重新使用"过去不再有效的处理密钥.
使用选项标志可以轻松读取压缩文件，但是如果没有 Offset TextIO 无法分发此任务.如果您有非常大的文件要读取，则在启动管道之前解压缩文件可以提供很好的性能提升.还要考虑使用压缩 Avro 等格式.
Compressed files can be easily read with an option flag, however without an Offset TextIO can not distribute this task. If you have very large files to read uncompressing the file before starting the pipeline can provide a nice performance boost. Also look at using formats like compressed Avro.
BackPressure:光束转轮旨在能够快速完成并行工作.他们可以在多台机器上启动许多线程来实现这个目标.这很容易淹没外部系统，尤其是在您进行每元素 RPC 调用时.如果外部系统无法扩展，请使用 startBundle/finishBundle 创建批处理以帮助提升每秒调用次数
BackPressure: Beam runners are designed to be able to rapidly chew through parallel work. They can spin up many threads across many machines to achieve this goal. This can easily swamp external systems, especially if you are making a per element RPC call. If the external system can not be made to scale, create batches using startBundle / finishBundle to help elevate the invocations per second
光速，仍然是光速.. :-) 避免使用远离工作人员的接收器和源.
Speed of light, is well still the speed of light.. :-) Avoid using sinks and sources which are far apart from your workers.
- 利用 Beam 指标来检测您的管道.
这篇关于Apache Beam - 我应该了解编写高效数据处理管道的关键概念是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
