2017年12月14日更新：由于工具包的数据生成器修复，Apache Flink在10个节点的集群上的性能，多核集群从比Apache Spark慢6倍降到3倍。Apache Flink的帖子中没有讨论这个配置。在大多数情况下，您需要在集群环境中运行流式应用程序，而不是在一台计算机上运行。此外，图像也进行了更新，以反映这些变化。标杆管理是评估系统性能的一个重要而常见的过程。使基准可信的是它的可重复性。由于以下几个原因，许多现有基准很难重现：用于某些生成结果的代码不公开。用于生成某些结果的硬件不易访问或可用。在Databricks，我们使用Databricks笔记本电脑和集群管理来建立一个可复制的基准测试工具，它将运行在Databricks统一分析平台上的Apache Spark结构化流媒体与其他开源流媒体系统（如Apache Kafka Streams和Apache Flink）的性能进行比较。特别是，我们在基准测试中使用了以下系统和版本：Databricks运行时3.1阿帕奇·弗林克1.2.1卡夫卡河0.10.2.1Yahoo流媒体基准是业界用于评估流媒体系统的著名基准。在设置我们的基准时，我们希望将每个流媒体系统推到其绝对极限，同时保持业务逻辑与Yahoo流媒体基准相同。我们在Spark Summit West 2017年主题演讲中分享了我们从这些基准中获得的一些结果，结果表明Spark的吞吐量可以达到其他流行流媒体系统的4倍或更高。在这个博客中，我们将更详细地讨论我们如何执行这个基准测试，以及如何自己复制结果。设置和配置只需几次单击和命令，就可以在Databricks Community Edition中并行运行所有这些系统。你需要做的就是：登录到Databricks社区版。您可以在此处创建帐户。使用GitHub URL导入基准测试启动群集按照主笔记本中有关库的安装和如何运行基准测试的说明进行操作。如果您有一个Databricks企业订阅，您可以使用已经在主笔记本中注释掉的附加配置集在规模上运行基准测试。背景最初的Yahoo基准测试模拟了一个简单的广告应用程序。卡夫卡消费了一系列的广告事件。目标是计算"查看"的广告活动的事件时间窗口计数。具体来说，操作顺序如下：从Kafka读取JSON数据。输入数据具有以下架构：用户标识：UUID页面编号：UUID广告id:UUID广告类型：{banner，modal，赞助搜索，mail，mobile}中的字符串事件类型：{view，click，purchase}中的字符串事件时间：时间戳ip地址：字符串根据事件类型字段筛选我们感兴趣的事件（查看）对相关字段进行投影（广告id和事件时间）将每个活动按广告id与其关联的活动标识关联起来。此信息以静态表的形式存储在Redis中。对每个活动的视图进行窗口化计数，并将每个窗口存储在Redis中，同时将窗口最后一次在Redis中更新的时间戳存储在Redis中。此步骤必须能够处理延迟事件。方法论我们希望确保我们正在进行基准测试的系统是瓶颈，而不是与外部服务的某些交互；因此，我们进行了以下更改，正如数据技术人员在Flink上发布的基准测试所做的那样：为了不混淆连接性能，删除了Redis。相反，我们使用静态表连接流，如下所示：在Kafka流中，我们将Kafka中的静态表作为KTable读取。我们确保静态表和事件流都被等价地分区，以避免Kafka流中的额外洗牌。Flink不支持数据流与数据集的联接（在版本1.2.1中）。因此，我们执行hashmap查找。在Spark中，我们连接一个静态的本地数据集。数据生成如下：对于Flink和Spark，我们在内存中生成数据Kafka流要求数据持久地存储在Kafka中，因此我们使用Spark生成数据并将其写入Kafka数据被写入Kafka而不是Redis。我们使用Kafka时间戳来确定窗口最后一次更新的时间戳。我们也没有生成"延迟数据"，因为每个系统都处理延迟的数据为了计算延迟，我们计算了在窗口计数阶段为给定（活动、事件时间窗口）对接收的最新记录的时间戳。然后我们使用这个时间戳和输出的Kafka摄取时间戳之间的差异来计算延迟。自动计算吞吐量有点困难。我们使用的方法如下：对于Spark，我们使用StreamingQueryListener来记录开始和结束时间戳以及处理的记录数。我们将在长期运行的Spark任务中启动Kafka流。在启动流之后，我们向Kafka发送一条记录来标记开始的时间戳，一旦流停止，我们也将每个任务中处理的记录数发送给Kafka。然后我们取记录计数的总和，最小起始时间戳，最大结束时间戳，然后用记录总数除以持续时间。我们没有一个好的方法来自动检查Flink作业，所以我们定期将处理的记录数记录到日志中。我们使用该日志来计算开始和结束时间戳以及处理的总记录数。这个计算是近似的，但是在我们运行基准的天平上，误差可以忽略不计。Apache Spark vs.Flink vs.Kafka结果我们试图复制Flink在这篇博文中发布的1500万个记录/秒的性能结果。我们能够使用商品云硬件（AWS上的c3.2xlarge实例）在Databricks上获得大约1600万条记录/秒的数据。然而，我们注意到，当我们为每个广告活动生成一个广告而不是每个广告活动生成十个广告时，我们可以使用Flink实现1600万个记录/秒的吞吐量。改变每场广告的数量并不会影响Spark或Kafka Streams的表现，但会导致Flink的吞吐量下降一个数量级。在Databricks Community Edition上运行的最终基准设置中，我们发现Spark的吞吐量是Flink的1.5倍：在为每个系统按比例（10个工作节点）运行基准测试后，我们观察到以下结果：回顾一下，我们运行了Yahoo流基准测试，以比较ApacheSpark在Databricks运行时上的结构化流媒体与其他开源流引擎：ApacheFlink和ApacheKafka流。结果表明，Spark可以达到2.9倍甚至更高的吞吐量。本着可重复实验和方法论的精神，我们已经为您发布了所有的脚本来重现这些基准。我们期待您的反馈！请将它们作为问题提交到我们的基准GitHub存储库免费试用Databricks。今天就开始吧