Yahoo的流核算引擎基准测验-Java-优质IT资源分享社区

admin
管理员
管理员
  • UID1
  • 粉丝26
  • 关注4
  • 发帖数581
  • 社区居民
  • 忠实会员
  • 原创写手
阅读:206回复:0

  Yahoo的流核算引擎基准测验

楼主#
更多 发布于:2016-05-31 16:43

Yahoo的流核算引擎比照测验

(yahooStorm团队排名不分先后) Sanket Chintapalli, Derek

Dagit, Bobby Evans, Reza Farivar, Tom Graves, Mark Holderbaugh, Zhuo Liu, Kyle

Nusbaum, Kishorkumar Patil, Boyang Jerry Peng and Paul Poulosky。

免责声明:2015年12月17日的数据,数据团队现已给咱们指出,咱们不小心在Flink基准测验中留下的一些调试代码。

所以Flink基准测验应当不能直接与Storm和Spark对比。 咱们在从头运转和从头发布陈述时现已处理了这个疑问。

更新:2015年12月18日有一个沟通上的误解,咱们运转的Flink的测验代码不是checked

in的代码。 如今调试代码现已删除。数据团队查看了代码,并证明它和如今的运转的测验是共同的。 咱们仍然会在某个时分从头运转它。

摘要-由于缺少实在国际的流基准测验,咱们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支撑高吞吐量,可是具有相对 较高的推迟。

在yahoo,咱们现已在一些日常运用中支撑咱们的商业开源的大数据渠道上投入巨资。

关于流作业负载,咱们的首选渠道一直Apache的Storm,它替代了咱们的内部开发的S4渠道。

咱们一直在广泛运用Storm,如今yahoo运转Storm节点的数量如今现已到达了2300个(而且还在不断添加中)。

由于咱们开端运用 Storm是在2012年决议的,但如今的流处理体系现状现已发生了很大的改动。

如今有几个别的值得重视的竞赛对手包含 Apache Flink,Apache Spark(Spark Streaming),Apache

Samza,Apache Apex和谷歌的Cloud Dataflow。 有不断添加的谈论评论哪个体系可以供给最佳的功用集,哪一个在哪些条件下功用十分好(例如见

这儿 , 这儿 , 这儿 ,还有这儿 )。

为了给咱们的内部客户供给最佳的流核算引擎东西,咱们想知道Storm擅长啥和它与别的体系对比哪些还需求前进。

要做到这一点,咱们就开端寻找那些可以为咱们供给流处理基准测验的材料,但如今的材料都在一些根本领域有所短缺。 首要,他们没有任何挨近实在国际的用例测验。

因而,咱们决议写一个并将它开源https://github.com/yahoo/streaming-benchmarks

在咱们的开端评价中,咱们决议在咱们的测验约束在三个最盛行的和有希望的渠道(Storm,Flink和Spark),但对别的体系,也期待来稿,并扩展基准的规划。

基准规划

基准的使命是从Kafka读取各种JSON事情,断定有关的事情,并存储每个campaigns活动有关的事情转换成Redis的时刻窗口计数。

这些进程试着侦测数据流所进行的一些常用的操作。

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

读取Kafka事情。

反序列化JSON字符串。

过滤掉不有关的事情(根据EVENT_TYPE字段)

取有关字段的快照(ad_id和EVENT_TIME)

ad_id及其相关的campaign_id参加每个事情。 这个信息被存储在Redis中。

每campaign活动一个窗口计数,每窗口计数存储在Redis中,附带终究更新的时刻戳。

此进程有必要可以处理推迟的事情。

输入数据有以下形式:

USER_ID:UUID

PAGE_ID:UUID

ad_id:UUID

ad_type:字符串在{banner,modal,资助查找,邮件,Mobile}

EVENT_TYPE:字符串在{视图,点击,购买}

EVENT_TIME:事情发生时刻戳

IP地址:字符串

生产者创立带有创立时刻戳符号的事情。

截断此刻刻戳到一个特定的数字,这个特定的数字给出了时刻窗口和事情所属的开端时刻

,在Storm和Flink中,尽管更新Redis是定时的,但常常足以满意选定的SLA。 咱们的SLA为1秒,因而咱们每秒一次往Redis写入更新的窗口。

Spark由于其规划的无穷区别,操作上略有不一样,

有一个关于在Spark有些的更多细节是咱们与数据一同记载时刻,并在Redis中记载每个窗口的终究更新时刻。

每次运转时,程序会读取Redis的Windows和Windows的时刻窗口并对比它们的last_updated_at次数、发生的推迟数据点。

由于假如前次事情窗口不能被发送(emit),该窗口将封闭,一个窗口的时刻,其last_updated_at时刻减去其持续时刻之差标明是在窗口从给Kafka到Redis时期通过应用程序的时刻。

window.final_event_latency

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

这一个有点粗糙,但这个基准测验并没有对这些引擎界说窗口数据粒度的粗细,而是供给了他们行为的更高级视图。

基准设置

10秒时刻窗口

1秒SLA

100 个 campaigns 活动

每次campaigns 活动有10个事情

5 个 Kafka与5个分区节点

1 个 Redis节点

10个作业节点(不包含像Storm的Nimbus和谐节点)

5-10 个Kafka生产者节点

3 个ZooKeeper节点

由于在咱们的架构中,Redis的节点运用一个精心优化的散列计划,仅履行内存查找,它并不会变成瓶颈。

节点被均匀装备,每一个节点有两个英特尔E5530 2.4GHz处理器,总共16个中心(8物理中心,16超线程)每节点。

每个节点具有24GB的内存,机器都坐落同一机架内,通过千兆以太网交换机相连。 集群共具有40个节点。

由于单个生产者最大每秒发生约一万七千事情,咱们跑了Kafka生产者的多个实例,以创立所需的负载。咱们运用在这个基准测验中利用了20到25个节点(作为生产者实例)。

每个topology运用10个worker,挨近咱们看到的yahoo内部正在运用的topology的均匀数目。

当然,yahoo内部的Storm集群更大,可是它们是多租户并运转着很多的topology。

Kafka开端基准测验时会被清空数据,Redis填充了初始数据(ad_id到campaign_id映射),流作业开端后会等候一段时刻,让作业完结发动,让生产者的生产活动稳定在一个特定的速率,并取得所需的总吞吐量。

该体系在生产者被封闭之前会运转30分钟。中止前允许有几秒钟的滞后以让流作业引擎处理完一切事情。

基准测验东西运转会生成富含window.last_updated_at的列表的文件– window.timestamp数据。

这些文件被保存为咱们测验各个引擎的吞吐量并用来生成这份测验陈述中的图表。

Flink

该基准测验中, 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中值得留意的装备列表如下:

taskmanager.heap.mb:15360

taskmanager.numberOfTaskSlots:16

该Flink版别的基准测验运用FlinkKafkaConsumer从Kafka读取数据。

数据在Kafka中是一个JSON格局的字符串,然后由一个定制的flatMap operator 反序列化并解析。 一旦反序列化,数据通过自界说的过滤器过滤。

今后,通过滤的数据,通过运用project 投影(projected )。

从那里,将数据由自界说的flapMap函数发生Redis的数据,终究的数据核算成果写入Redis。

在该Kafka宣布的数据事情到Flink基准速率从50,000个事情/秒到17万次/秒改变。

关于每个Kafka发射(emit)率,Flink彻底处理元组的百分比与推迟时刻的基准示于下图。

推迟在一切Kafka 发射(emit)率是相对共同的。

等候时刻线性上升,直到大概第99百分位数时(约1%的数据处理时刻),推迟呈现成倍的添加(1%的数据处理推迟远远大于99%的数据)。

Spark

Spark基准代码用Scala编写。

由于Spark的微批处理办法和Storm的纯流核算引擎性质不一样,咱们需求从头思考基准完结的有些。 为了满意SLA,

Storm和Flink每秒更新一次Redis,并在本地缓存中保存中心值。按此规划,Spark Streaming

的时刻批次被设置为1秒,这会致使较小的吞吐量,为此咱们不得不扩展批次的时刻窗口以保证更大的吞吐量。

基准用的是典型Spark个性的DStreams。

DStreams是流数据,相当于一般RDDs,并为每个微批次创立一个独自的RDD。

留意,在随后的评论中,咱们运用术语“RDD”而不是“DSTREAM”来标明在当时活动micro batch中的RDD。 处理直接运用Kafka Consumer

以及Spark1.5。 由于在咱们的基准中Kafka输入的数据被存储在5个分区,Kafka消费者创立具有5个分区的DSTREAM。

在此今后,一些改换施加在DStreams,包含maps 和 filters。

触及与Redis的交互数据的改换是一种特殊状况,由于咱们不想每次记载Redis就创立一个独自的衔接,咱们运用一个mapPartitions操作,可以给RDD代码全部分区的操控权。

通过这种方法,咱们创立一个衔接到Redis的单一衔接,并通过该衔接从Redis中查询在RDD分区中的一切事情信息。

相同的办法在今后咱们往Redis写入终究成果的时分运用。

应当指出的是,咱们的写入Redis的方法被完结为RDD改换,以坚持基准测验的简练,尽管这不会与刚好一次的语义兼容。

咱们发现,Spark没能坚持主满足的高吞吐量。 在每秒到达100000音讯时推迟大大添加了。

咱们认为需求沿着两个方面进行调整,以协助Spark敷衍添加的吞吐量。

榜首是microbatch持续时刻。 这个操控维度不存于像Storm纯流核算引擎体系中。

添加持续时刻一起也添加了等候时刻,这么就削减(调度)开支并因而添加了最大吞吐量。 应战是,在处理吞吐量推迟最小化和最优批持续时刻之间调整是一个耗时的进程。

从本质上讲,咱们要选择一个批处理时刻,运转基准30分钟,查看成果,并削减/添加批持续时刻。

第二个是并行度。 添加并行度似乎简略,但对Spark来说做起来难。

关于一个真实的流核算引擎体系像Storm,一个bolt 实例可以运用随机洗牌(reshuffling)方法发送它的成果到其它任何数量的bolt 实例。

要扩展规划,添加第二bolt 的并行度就可以。 Spark在一样的状况下,咱们需求履行相似于Hadoop的MapReduce的程序决议全部集群兼并洗牌操作,

但reshuffling 本身引进了值得思考的开支。

起初,咱们认为咱们的操作是核算密集型(CPU-bound)的,为较多分区做reshuffling相对reshuffling

本身的开支是利大于弊,但实际上瓶颈在于调度,所以reshuffling 只添加开支。 咱们置疑高吞吐率的操作(对spark来说)都是核算密集型的。

终究的成果很风趣。 不一样的窗口持续时刻下Spark有三种不一样的成果。

首要,假如批处理的窗口持续时刻设定得满足大,大有些事情都将在当时微批处理中完结处理。下图显现了这种状况下,得到百分比加工图(100K事情/10秒窗口持续时刻)。

90%的事情在榜首个微批处理中被处理,这就有了改善推迟的也许性。

通过削减批处理窗口持续时刻,事情被组织至3到4个批次进行处理。

这带来了第二个疑问,每批次的持续时刻内无法处理完一切组织到该时刻窗口中的事情,但仍是可控的,更小的批处理窗口持续时刻带来了更低的推迟。这种状况示于下图(100K事情/3秒窗口持续时刻)。

终究,第三个现象是当Spark Streaming

处理速度跟不上时,基准测验的输入数据需求入行列并等候几分钟以让Spark 完结处理一切的事情。 这种状况示于下图。

在这种不良的作业方法,Spark溢出很多的数据到磁盘上,在极端的状况下,咱们终究也许呈现磁盘空间缺乏的状况。

终究要阐明的是,咱们企图在Spark1.5中引进的新背压(back pressure)功用。

假如体系是在榜首作业区域,背压没有作用。 在第二操作区域,背压致使更长的推迟。 第三操作区域成果显现背压带了副作用。

它改动了批次的长度,此刻Spark处理速度仍然跟不上, 示于下图。 咱们的测验标明,如今的背压功用并没有协助咱们的基准,因而咱们禁用了它。

无背压(上图)的功用,以及与背压启用(下图)。 启用背压后推迟功用较差(70秒VS 120秒)。 留意,这两种的成果对流处理体系是不可承受的,由于数据处理速度都落后于 输入数据的速度。 批处理的时刻窗口设定为2秒时,具有130000的吞吐量。

Storm

Storm的基准测验运用Java API编写。 咱们测验了Apache的Storm 0.10.0 和

0.11.0-Snapshot版别。 Snapshot commit hash是a8d253a。 每个主机分配一个作业进程,每个worker给予16 tasks

以运转16个executors ,也即是每个cpu中心一个executor。

Storm0.10.0:

Storm0.11.0:

与Flink和Spark Streaming对比,Storm毫不逊色。 Storm 0.11.0

优于 Storm 0.10.0,显着0.11.0对0.10.0版别做了优化。 但是,在高吞吐量上Storm的两个版别照旧绰绰有余, 其间Storm 0.10.0

无法处理超越每秒135000事情的吞吐量。

Storm 0.11.0相同遇到了瓶颈,直到咱们禁用ACKING。

在基准测验Topology中,ACKING用于流量操控而不是处理担保。 在0.11.0中,Storm添加了一个简略的背压操控,使咱们可以避免ACKING的开支。

跟着ACKING启用,0.11.0 版别在在150,000/s的吞吐量测验上 /比0.10.0 -稍好,但仍然很糟糕。

跟着ACKING被禁用,Storm在高吞吐量上比Flink的推迟功用要好。 不过留意的是,跟着ACKING被禁用,陈述和处理的元组毛病的功用也被禁用。

结论和将来作业

下图对比这三个体系的测验成果, 咱们可以看出,Storm和Flink两者具有线性呼应。

这是由于这两个体系是一个一个的处理传入事情。 另一方面,在Spark Streaming  根据微批处理规划, 处理是逐渐的方法得到成果。

吞吐量VS推迟曲线图在体系比照中区别也许是最显着的,由于它总结了咱们的研究成果。

Flink和Storm具有十分相似的功用,而Spark Streaming,需求高得多的等候时刻,但可以处理更高的吞吐量。

超越每秒135000的事情中不包含

Storm0.10.0和0.11.0在ACKING启用时的成果,由于他们处理速度无法跟上吞吐量。 由此发生的图形中Storm0.10.0

在45000毫秒时完毕测验, topology 跑的时刻越长,得到越高的推迟,这标明它功用在下降。

一切这些规范,除非另有阐明,

Storm,Spark,和Flink均选用默许设置进行,咱们专心于编撰准确的,简略了解,无需每次优化的,以充分发挥其潜力的计划。

由于这种每六个进程都是一个独自的bolt或spout。 Flink和Spark的aggregation兼并操作是主动的,但Storm(非trident)没有。

这意味着对Storm来说,事情通过更多的进程,对比于别的体系具有更高的开支。

除了对Storm进一步优化,咱们想扩展在功用方面的测验,并在测验中包含像Samza和Apex

等别的流处理体系,将来也会把容错性,处理担保和资本利用率作为测验的基准。

对咱们来说 Storm 满足满意要求。 拓扑构造写起来简略,很简略取得低推迟,

和Flink对比能得到更高的吞吐量。假如没有ACKING,Storm甚至在十分高的吞吐量时打败Flink,咱们希望进一步优化bolts组合,更智能的tuples路由和改善ACKING,让Storm

ACKING启用时可以在十分高的吞吐量时与Flink相竞赛。

近期实时流核算引擎体系之间的竞赛日趋白热化,但并没有显着的赢家, 每个渠道都有各自的长处和缺陷。

功用仅仅其间之一,别的如安全、东西集也是衡量要素。 活跃的社区为这些和别的大数据处理项目进行不断的创新,不断从对方的前进中获益。

咱们期待着扩展这个基准测验并测验这些体系的新版别。

优质IT资源分享社区为你提供此文。

本站有大量优质Java教程视频,资料等资源,包含java基础教程,高级进阶教程等等,教程视频资源涵盖传智播客,极客学院,达内,北大青鸟,猎豹网校等等IT职业培训机构的培训教学视频,价值巨大。欢迎点击下方链接查看。

java教程视频

优质IT资源分享社区(www.itziyuan.top)
一个免费,自由,开放,共享,平等,互助的优质IT资源分享网站。
专注免费分享各大IT培训机构最新培训教学视频,为你的IT学习助力!

!!!回帖受限制请看点击这里!!!
!!!资源失效请在此版块发帖说明!!!

[PS:按 CTRL+D收藏本站网址~]

——“优质IT资源分享社区”管理员专用签名~

本版相似帖子

游客