Yahoo的流计算引擎基准测试

  • 时间:
  • 浏览:0

除了对Storm进一步优化,让让我们 想扩大在功能方面的测试,并在测试中包括像Samza和Apex 等一点流解决系统,未来也会把容错性,解决担保和资源利用率作为测试的基准。

让让我们 发现,Spark没能保持主足够的高吞吐量。 在每秒达到1000000消息波特率迟大大增加了。 让让我们 认为并能 沿着另一个 方面进行调整,以帮助Spark应付增长的吞吐量。

(雅虎Storm团队排名不分先后) Sanket Chintapalli, Derek Dagit, Bobby Evans, Reza Farivar, Tom Graves, Mark Holderbaugh, Zhuo Liu, Kyle Nusbaum, Kishorkumar Patil, Boyang Jerry Peng and Paul Poulosky

操作的流程如下(和在下面的图中示出):

Storm的基准测试使用Java API编写。 让让我们 测试了Apache的Storm 0.10.0 和 0.11.0-Snapshot版本。 Snapshot commit hash是a8d253a。 每个主机分配另一个 工作应用程序,每个worker给予16 tasks 以运行16个executors ,也却说 每个cpu核心另一个 executor。

该基准测试中, Flink 使用Java的DataStream的API实现。 该Flink的DataStream中的API和Storm的API有一点同类于之处。 对于这有一种Flink和Storm,数据流并能 被表示为另一个 有向图。 每个顶点是另一个 用户定义的运算,每向边表示数据的流动。 Storm的API使用spout bolts 作为其运算器,而Flink使用map,flatMap,以及一点预建的operators ,如filter, project, 和 reduce Flink使用有一种叫做检查点,以保证解决它提供同类于Storm的ACKING担保机制。 让让我们 跑你这个基准测试时Flink已默认关闭检查点。在Flink中值得注意的配置列表如下:

输入数据有以下模式:

不可能 让让我们 最初使用 Storm是在2012年决定的,但目前的流解决系统现状不可能 处在了很大的改变。 现在有几条一点值得关注的竞争对手包括 Apache Flink,Apache Spark(Spark Streaming),Apache Samza,Apache Apex和谷歌的Cloud Dataflow 有太少的议论探讨哪个系统并能 提供最佳的功能集,哪另一个 在你这个条件下性能更好(同类于见  这里 , 这里 ,  这里 ,还有这里 )。

超过每秒13100000的事件中不包括 Storm0.10.0和0.11.0在ACKING启用时的结果,不可能 让让我们 解决波特率无法跟上吞吐量。 由此产生的图形中Storm0.10.0 在4100000毫秒时刚开始了了测试, topology 跑的时间越长,得到越高的延迟,这表明它性能在降低。

摘要-不可能 处在问题真实世界的流基准测试,让让我们 1比较了Apache Flink,Apache Storm和 Apache Spark Streaming。 Storm 0.10.0/0.11.0-SNAPSHOT和 Flink 0.10.1 测试表明具有亚秒级的延迟和相对 较高的吞吐量, Storm 99%请况下具有最低的延迟。 Spark Streaming 1.5.1支持高吞吐量,之后具有相对 较高的延迟。

该Flink版本的基准测试使用FlinkKafkaConsumer从Kafka读取数据。 数据在Kafka中是另一个 JSON格式的字符串,之后由另一个 定制的flatMap operator 反序列化并解析。 一旦反序列化,数据通过自定义的过滤器过滤。 之后,经过滤的数据,通过使用project 投影(projected ) 从那里,将数据由自定义的flapMap函数产生Redis的数据,最终的数据计算结果写入Redis。

基准设置

应当指出的是,让让我们 的写入Redis的辦法 被实现为RDD变换,以维持基准测试的简洁,我实在这不不与恰好一次的语义兼容。

在雅虎,让让我们 不可能 在一点日常使用中支持让让我们 的商业开源的大数据平台上投入巨资。 对于流工作负载,让让我们 的首选平台总是Apache的Storm,它取代了让让我们 的內部开发的S4平台。 让让我们 总是在广泛使用Storm,目前雅虎运行Storm节点的数量现在不可能 达到了21000个(之后还在不断增加中)。

最后的结果很有趣。 不同的窗口持续时间下Spark有有一种不同的结果。 首先,不可能 批解决的窗口持续时间设定得足够大,大要素事件都将在当前微批解决中完成解决。 下图显示了你这个请况下,得到百分比加工图(1000K事件/10秒窗口持续时间)。

无背压(上图)的性能,以及与背压启用(下图)。 启用背压后延迟性能较差(70秒VS 120秒)。 注意,这有一种的结果对流解决系统是不可接受的,不可能 数据解决波特率都落后于 输入数据的波特率。 批解决的时间窗口设定为2秒时,具有1100000的吞吐量。

生产者创建所含创建时间戳标记的事件。 截断此时间戳到另一个 特定的数字,你这个特定的数字给出了时间窗口和事件所属的刚开始了了时间 ,在Storm和Flink中,我实在更新Redis是定期的,但常常足以满足选定的SLA。 让让我们 的SLA为1秒,之后让让我们 每秒一次往Redis写入更新的窗口。 Spark不可能 其设计的巨大差异,操作上略有不同, 有另一个 关于在Spark要素的更多细节是让让我们 与数据同时记录时间,并在Redis中记录每个窗口的最后更新时间。

免责声明:2015年12月17日的数据,数据团队不可能 给让让我们 指出,让让我们 不小心在Flink基准测试中留下的一点调试代码。 统统有Flink基准测试应该非要直接与Storm和Spark比较。 让让我们 在重新运行和重新发布报告时不可能 解决了你这个问题图片。

与Flink和Spark Streaming相比,Storm毫不逊色。 Storm 0.11.0 优于 Storm 0.10.0,显然0.11.0对0.10.0版本做了优化。 然而,在高吞吐量上Storm的另一个 版本依旧捉襟见肘, 其中Storm 0.10.0 无法解决超过每秒13100000事件的吞吐量。

基准用的是典型Spark风格的DStreams。 DStreams是流数据,大概普通RDDs,并为每个微批次创建另一个 单独的RDD。 注意,在之后的讨论中,让让我们 使用术语“RDD”而后该 “DSTREAM”来表示在当前活动micro batch中的RDD。 解决直接使用Kafka Consumer 以及Spark1.5。 不可能 在让让我们 的基准中Kafka输入的数据被存储在十个 分区,Kafka消费者创建具有十个 分区的DSTREAM。 在此之后,一点变换施去掉 DStreams,包括maps 和 filters 涉及与Redis的交互数据的变换是有一种特殊请况,不可能 让让我们 不不每次记录Redis就创建另一个 单独的连接,让让我们 使用另一个 mapPartitions操作,并能 给RDD代码整个分区的控制权。 通过你这个辦法 ,让让我们 创建另一个 连接到Redis的单一连接,并通过该连接从Redis中查询在RDD分区中的所有事件信息。 同样的辦法 在之后让让我们 往Redis写入最终结果的之后使用。

所有你这个标准,除非另有说明, Storm,Spark,和Flink均采用默认设置进行,让让我们 专注于撰写正确的,容易理解,不不每次优化的,以充整理挥其潜力的方案。 不可能 你这个每十个 步骤后该 另一个 单独的boltspout Flink和Spark的aggregation合并操作是自动的,但Storm(非trident)非要 。 这意味对Storm来说,事件经过更多的步骤,相比于一点系统具有更高的开销。

Storm 0.11.0同样遇到了瓶颈,直到让让我们 禁用ACKING。 在基准测试Topology中,ACKING用于流量控制而后该 解决担保。 在0.11.0中,Storm增加了另一个 简单的背压控制,使让让我们 并能解决ACKING的开销。 随着ACKING启用,0.11.0 版本在在1000,000/s的吞吐量测试上 /比0.10.0 -稍好,但依然很糟糕。 随着ACKING被禁用,Storm在高吞吐量上比Flink的延迟性能要好。 不过注意的是,随着ACKING被禁用,报告和解决的元组故障的功能也被禁用。

不可能 单个生产者最大每秒产生约一万七千事件,让让我们 跑了Kafka生产者的多个实例,以创建所需的负载。让让我们 使用在你这个基准测试中利用了20到2十个 节点(作为生产者实例)。

最后该说明的是,让让我们 试图在Spark1.5中引入的新背压(back pressure)功能。 不可能 系统是在第一工作区域,背压非要 效果。 在第二操作区域,背压意味更长的延迟。 第三操作区域结果显示背压带了副作用。 它改变了批次的长度,此时Spark解决波特率仍然跟不上, 示于下图。 让让我们 的测试表明,目前的背压功能并非要 帮助让让我们 的基准,之后让让我们 禁用了它。

Storm0.10.0:

对让让我们 来说 Storm 足够满足要求。 拓扑行态写起来简单,很容易获得低延迟, 和Flink相比能得到更高的吞吐量。不可能 非要 ACKING,Storm甚至在非常高的吞吐量时击败Flink,让让我们 期望进一步优化bolts组合,更智能的tuples路由和改进ACKING,让Storm ACKING启用时并能 在非常高的吞吐量时与Flink相竞争。

为了给让让我们 的內部客户提供最好的流计算引擎工具,让让我们 想知道Storm擅长你这个和它与一点系统相比你这个还并能 提高。 要做到你这个点,让让我们 就刚开始了了寻找你这个并能 为让让我们 提供流解决基准测试的资料,但目前的资料后该 一点基本领域有所处在问题。 首先,让让我们 非要 任何接近真实世界的用例测试。 之后,让让我们 决定写另一个 并将它开源https://github.com/yahoo/streaming-benchmarks。 在让让我们 的初步评估中,让让我们 决定在让让我们 的测试限制在另一个 最流行的和有希望的平台(Storm,Flink和Spark),但对一点系统,也欢迎来稿,并扩大基准的范围。

window.final_event_latency =(window.last_updated_at – window.timestamp) – window.duration

第一是microbatch持续时间。 你这个控制维度不存于像Storm纯流计算引擎系统中。 增加持续时间同时也增加了听候时间,曾经就减少(调度)开销并之后增加了最大吞吐量。 挑战是,在解决吞吐量延迟最小化和最优批持续时间之间调整是另一个 耗时的过程。 从本质上讲,让让我们 要选则另一个 批解决时间,运行基准1000分钟,检查结果,并减少/增加批持续时间。

下图比较这另一个 系统的测试结果, 让让我们 并能 看出,Storm和Flink两者具有线性响应。 这是不可能 这另一个 系统是另一个 另一个 的解决传入事件。 一点人面,在Spark Streaming  辦法 微批解决设计, 解决是逐步的辦法 得到结果。

基准的任务是从Kafka读取各种JSON事件,选则相关的事件,并存储每个campaigns活动相关的事件转去掉 Redis的时间窗口计数。 你这个步骤试着侦测数据流所进行的一点常用的操作。

在该Kafka发出的数据事件到Flink基准波特率从1000,000个事件/秒到18万次/秒变化。 对于每个Kafka发射(emit)率,Flink详细解决元组的百分比与延迟时间的基准示于下图。

Kafka刚开始了了基准测试后该被清空数据,Redis填充了初始数据(ad_idcampaign_id映射),流作业刚开始了了后该听候一段时间,让工作完成启动,让生产者的生产活动稳定在另一个 特定的波特率,并获得所需的总吞吐量。 该系统在生产者被关闭之后该运行1000分钟。停止前允许有几秒钟的滞后以让流工作引擎解决完所有事件。 基准测试工具运行会生成所含window.last_updated_at的列表的文件– window.timestamp数据。 你这个文件被保存为让让我们 测试各个引擎的吞吐量并用来生成这份测试报告中的图表。

Spark基准代码用Scala编写。 不可能 Spark的微批解决辦法 和Storm的纯流计算引擎性质不同,让让我们 并能 重新考虑基准实现的要素。 为了满足SLA, Storm和Flink每秒更新一次Redis,并在本地缓存中保留上面值。按此设计,Spark Streaming 的时间批次被设置为1秒,这会意味较小的吞吐量,为此让让我们 不得不扩大批次的时间窗口以保证更大的吞吐量。

更新:2015年12月18日有另一个 沟通上的误解,让让我们 运行的Flink的测试代码后该 checked in的代码。 现在调试代码不可能 删除。数据团队检查了代码,并证实它和目前的运行的测试是一致的。 让让我们 仍然会在某个之后重新运行它。

不可能 在让让我们 的架构中,Redis的节点使用另一个 精心优化的散列方案,仅执行内存查找,它暂且会成为瓶颈。 节点被均匀配置,每另一个 节点有另一个 英特尔E551000 2.4GHz解决器,总共16个核心(8物理核心,16超应用程序)每节点。 每个节点具有24GB的内存,机器都处在同一机架内,通过千兆以太网交换机相连。 集群共拥有40个节点。

原文链接  译者:andy huang

这另一个 不得劲粗糙,但你这个基准测试并非要 对你这个引擎定义窗口数据粒度的粗细,却说 提供了让让我们 行为的更高级视图。

吞吐量VS延迟曲线图在系统对比中差异我说是最明显的,不可能 它总结了让让我们 的研究结果。 Flink和Storm具有非常同类于的性能,而Spark Streaming,并能 高得多的听候时间,但并能解决更高的吞吐量。

Storm0.11.0:

近来实时流计算引擎系统之间的竞争日趋白热化,但并非要 明显的赢家, 每个平台后该 个人所有所有 的优点和缺点。 性能却说 其中之一,一点如安全、工具集也是衡量因素。 活跃的社区为你这个和一点大数据解决项目进行不断的创新,不断从对方的进步中受益。 让让我们 期待着扩大你这个基准测试并测试你这个系统的新版本。

每次运行时,应用程序会读取Redis的Windows和Windows的时间窗口并比较它们的last_updated_at次数、产生的延迟数据点。 不可能 不可能 上次事件窗口非要被发送(emit),该窗口将关闭,另一个 窗口的时间,其last_updated_at时间减去其持续时间之差表示是在窗口从给Kafka到Redis期间通过应用应用程序的时间。

延迟在所有Kafka 发射(emit)率是相对一致的。 听候时间线性上升,直到大概第99百分位数时(约1%的数据解决时间),延迟出現 成倍的增加(1%的数据解决延迟远远大于99%的数据)。

最后,第另一个 问题图片是当Spark Streaming 解决波特率跟不上时,基准测试的输入数据并能 入队列并听候几分钟以让Spark 完成解决所有的事件。 你这个请况示于下图。 在你这个不良的工作辦法 ,Spark溢出大量的数据到磁盘上,在极端的请况下,让让我们 最终不可能 出現 磁盘空间处在问题的请况。

每个topology使用10个worker,接近让让我们 看过的雅虎內部正在使用的topology的平均数目。 当然,雅虎內部的Storm集群更大,之后它们是多租户并运行着一点的 topology

第十个 是并行度。 增加并行度似乎简单,但对Spark来说做起来难。 对于另一个 真正的流计算引擎系统像Storm,另一个 bolt 实例并能 使用随机洗牌(reshuffling)辦法 发送它的结果到其它任何数量的bolt 实例。 要扩大规模,增加第二bolt 的并行度就并能 。 Spark在一样的请况下,让让我们 并能 执行同类于于Hadoop的MapReduce的应用程序决定整个集群合并洗牌操作, reshuffling 有一种引入了值得考虑的开销。 起初,让让我们 以为让让我们 的操作是计算密集型(CPU-bound)的,为较多分区做reshuffling相对reshuffling 自身的开销是利大于弊,但实际上瓶颈在于调度,统统有reshuffling 只增加开销。 让让我们 怀疑高吞吐率的操作(对spark来说)后该 计算密集型的。

90%的事件在第另一个 微批解决中被解决,这后该 了改善延迟的不可能 性。 通过减少批解决窗口持续时间,事件被安排至3到另一个 批次进行解决。 这带来了第十个 问题图片,每批次的持续时间内无法解决完所有安排到该时间窗口中的事件,但仍是可控的,更小的批解决窗口持续时间带来了更低的延迟。你这个请况示于下图(1000K事件/3秒窗口持续时间)。