当前位置: X-MOL 学术IEEE Trans. Parallel Distrib. Syst. › 论文详情
Our official English website, www.x-mol.net, welcomes your feedback! (Note: you will need to create a separate account there.)
Evaluation of Stream Processing Frameworks
IEEE Transactions on Parallel and Distributed Systems ( IF 5.6 ) Pub Date : 2020-08-01 , DOI: 10.1109/tpds.2020.2978480
Giselle van Dongen , Dirk Van den Poel

The increasing need for real-time insights in data sparked the development of multiple stream processing frameworks. Several benchmarking studies were conducted in an effort to form guidelines for identifying the most appropriate framework for a use case. In this article, we extend this research and present the results gathered. In addition to Spark Streaming and Flink, we also include the emerging frameworks Structured Streaming and Kafka Streams. We define four workloads with custom parameter tuning. Each of these is optimized for a certain metric or for measuring performance under specific scenarios such as bursty workloads. We analyze the relationship between latency, throughput, and resource consumption and we measure the performance impact of adding different common operations to the pipeline. To ensure correct latency measurements, we use a single Kafka broker. Our results show that the latency disadvantages of using a micro-batch system are most apparent for stateless operations. With more complex pipelines, customized implementations can give event-driven frameworks a large latency advantage. Due to its micro-batch architecture, Structured Streaming can handle very high throughput at the cost of high latency. Under tight latency SLAs, Flink sustains the highest throughput. Additionally, Flink shows the least performance degradation when confronted with periodic bursts of data. When a burst of data needs to be processed right after startup, however, micro-batch systems catch up faster while event-driven systems output the first events sooner.

中文翻译:

流处理框架评估

对数据实时洞察的日益增长的需求引发了多个流处理框架的发展。进行了几项基准研究,以形成确定用例最合适框架的指南。在本文中,我们扩展了这项研究并展示了收集到的结果。除了 Spark Streaming 和 Flink,我们还包括新兴框架 Structured Streaming 和 Kafka Streams。我们通过自定义参数调整定义了四个工作负载。其中每一个都针对特定指标或在特定场景(如突发工作负载)下测量性能进行了优化。我们分析了延迟、吞吐量和资源消耗之间的关系,并测量了向管道添加不同常见操作的性能影响。为确保正确的延迟测量,我们使用单个 Kafka 代理。我们的结果表明,对于无状态操作,使用微批处理系统的延迟缺点最为明显。对于更复杂的管道,定制的实现可以为事件驱动的框架提供很大的延迟优势。由于其微批处理架构,Structured Streaming 可以以高延迟为代价处理非常高的吞吐量。在严格的延迟 SLA 下,Flink 保持最高的吞吐量。此外,Flink 在面对周期性数据突发时表现出的性能下降最少。然而,当需要在启动后立即处理大量数据时,微批处理系统会更快地赶上,而事件驱动系统会更快地输出第一个事件。我们的结果表明,对于无状态操作,使用微批处理系统的延迟缺点最为明显。对于更复杂的管道,定制的实现可以为事件驱动的框架提供很大的延迟优势。由于其微批处理架构,Structured Streaming 可以以高延迟为代价处理非常高的吞吐量。在严格的延迟 SLA 下,Flink 保持最高的吞吐量。此外,Flink 在面对周期性数据突发时表现出的性能下降最少。然而,当需要在启动后立即处理大量数据时,微批处理系统会更快地赶上,而事件驱动系统会更快地输出第一个事件。我们的结果表明,对于无状态操作,使用微批处理系统的延迟缺点最为明显。对于更复杂的管道,定制的实现可以为事件驱动的框架提供很大的延迟优势。由于其微批处理架构,Structured Streaming 可以以高延迟为代价处理非常高的吞吐量。在严格的延迟 SLA 下,Flink 保持最高的吞吐量。此外,Flink 在面对周期性数据突发时表现出的性能下降最少。然而,当需要在启动后立即处理大量数据时,微批处理系统会更快地赶上,而事件驱动系统会更快地输出第一个事件。结构化流可以以高延迟为代价处理非常高的吞吐量。在严格的延迟 SLA 下,Flink 保持最高的吞吐量。此外,Flink 在面对周期性数据突发时表现出的性能下降最少。然而,当需要在启动后立即处理大量数据时,微批处理系统会更快地赶上,而事件驱动系统会更快地输出第一个事件。结构化流可以以高延迟为代价处理非常高的吞吐量。在严格的延迟 SLA 下,Flink 保持最高的吞吐量。此外,Flink 在面对周期性数据突发时表现出的性能下降最少。然而,当需要在启动后立即处理大量数据时,微批处理系统会更快地赶上,而事件驱动系统会更快地输出第一个事件。
更新日期:2020-08-01
down
wechat
bug