Flink靠什么征服饿了么工程师?

  • 时间:
  • 浏览:4

比如说这上端会有八个task,就会有有2个并发守护进程去跑,chain起来说说装进一一八个多守护进程去跑就需要提升数据传输性能。Spark是黑盒的,每个operator无法设并发度,而Flink需要对每个operator设并发度,原来需要更灵活有些,作业运行起来对资源利用率也更高有些。

上端本来让用户描述pipeline。 SQL本来kafka的多个topic,输出选折 一一八个多输出表,SQL把上端消费的kafka DStream注册成表,否则写一串pipeline,最后亲戚亲戚朋友帮用户封装了有些对外sink(但是提到的各种存储都支持,可能存储能实现upsert语义说说,亲戚亲戚朋友都是支持了的)。

来源于多个数据源的数据写到kafka里,计算引擎主本来Storm,Spark和Flink,计算引擎出来的结果数据再落地到各种存储上。

Flink1.4但是有两阶段提交来支持exactly-once.它的概念是从上游kafka消费数据后,每一步后会发起一次投票,来记录清况 ,通过checkpoint的屏障来避免标记,必须最后再写到kafka(0.11但是的版本),必须最后完成但是,才会把每一步的清况 让jobmanager中的cordinator去通知需要固化下来,原来实现exactly-once。

下面是目前饿了么平台现状架构图:

Spark 一般通过Spark.default.parallelism来调整并行度,有shuffle操作说说,并行度一般是通Spark.sql.shuffle.partitions参数来调整,实时计算说说真是应该调小有些,比如亲戚亲戚朋友生产中和kafka的partition数调的差不要 ,batch在生产上会调得大有些,亲戚亲戚朋友设为10000,左边的图亲戚亲戚朋友设并发度为2,最大是10,原来首先分一一八个多并发去跑,另外根据key做一一八个多分组的概念,最大分为10组,就需要做到把数据尽量的打散。

目前Storm任务要花费有1000多个,Spark任务有1000个左右,Flink暂时还比较少。

目前亲戚亲戚朋友集群规模每天数据量有1000TB,计算次数有10000000000,节点有1000个。这里要提一下,Spark和Flink都是on yarn的,其中Flink onyarn主本来用作任务间jobmanager隔离, Storm是standalone模式。

饿了么早期都是使用Storm,16年但是还是Storm,17年才现在始于了了有Sparkstreaming, Structed-streaming。Storm用的比较早,主要有下面有2个概念:

亲戚亲戚朋友调研否则并去使用了Spark2.X但是带清况 的增量计算。下面你这名 图是官方网站的:

于是基于以上有2个Spark structuredstreaming的特点和缺点,亲戚亲戚朋友考虑使用Flink来做你这名 事情。

下面给亲戚亲戚朋友大致展示一下亲戚亲戚朋友平台用户快速发布一一八个多实时任务的操作页面,它需要你这名 步骤。亲戚亲戚朋友这里都是写DDL和DML说说,本来ui展示页面的方法。

所有的流计算都参照了Google的 data flow,上端有个重要的概念:数据的processing time和event time,即数据的避免时间和真正的占据 时间有个gap。于是流计算领域还有个watermark,当前进来的事件水位需要watermark来维持,watermark需要指定时间delay的范围,在延迟窗口之外的数据是需要丢弃的,在业务上晚到的数据也是那末意义的。

图中左半帕累托图的红色节点占据 了failover,可能是at-least-once,则其最上游把数据重发一次就好;但可能是exactly-once,则需要每个计算节点从上一次失败的时机重放。

本文转自Apache Flink China博客,作者:易伟平,原文链接:Flink靠你这名 征服饿了么工程师?

这上端本来把刚才Sparkstreaming讲exactly-once的步骤1,2,3都实现了,它本质上还是分批的batch方法,offset当事人维护,清况 存储用的hdfs,对外的sink那末做之类的幂等操作,也那末写完但是再去commit offset,它本来再保证容错的同時 去实现组织组织结构引擎的exactly-once。

可能Flink的数据是第十根条过来避免,有些Flink中的每条数据避免完了立马发给下游,而不像spark,需要等该operator所在的stage所有的task都完成了再往埋点。

亲戚亲戚朋友需要要求数据sink到组织组织结构存储后,offset可不还里能commit,不管是到zk,还是mysql上端,你最好保证它在一一八个多transaction上端,否则需要在输出到组织组织结构存储(这里最好保证一一八个多upsert语义,根据unique key来实现upset语义)但是,否则这边源头driver再根据存储的offeset去产生kafka RDD,executor再根据kafka每个分区的offset去消费数据。可能满足这第十根件,就需要实现端到端的exactly-once. 这是一一八个多大前提。

亲戚亲戚朋友期待和你同時 ,把Flink建设得更好,帮助更多开发者。

Flink的框架图:

在讲述亲戚亲戚朋友应用场景但是,先强调实时计算一一八个多重要概念, 一致性语义:

Backend默认是维护在jobmanager内存,亲戚亲戚朋友更多使用的的是写到hdfs上,每个operator的清况 写到rocksdb上,否则异步周期增量同步到组织组织结构存储。

真是但是满足一般无清况 批次内的计算要求,但都是用户想说, 我就要做流的join为什么会么会办, 早期的Spark1.5需要参考Spark-streamingsql你这名 开源项目把 DStream注册为一一八个多表,否则对你这名 表做join的操作,但这只支持1.5但是的版本,Spark2.0推出structured streaming但是项目就废弃了。亲戚亲戚朋友一一八个多多tricky的方法:

###4. STRUCTUREDSTREAMING

Task中operatorchain,是比较好的概念。可能上下游数据分布需要重新shuffle说说,比如图中source是kafka source,上端跟的map本来一一八个多简单的数据filter,亲戚亲戚朋友把它装进一一八个多守护进程上端,就需要减少守护进程上下文切换的代价。

Flink目标是对标Spark,流这块是领先比较多,它野心也比较大,图计算,机器学习等它都是,底层也是支持yarn,tez等。对于社区用的比较多的存储,Flink社区官方都支持比较好,相对来说。

还有有些Flink比较好的本来,基于它的checkpoint来实现savepoint功能。业务方需要每个应用恢复节点不一样,希望恢复到的版本也是需要指定的,这是比较好的。你这名 savepoint不本来数据的恢复,都是计算清况 的恢复。

Flink中的JobManager,要花费Spark的driver角色,taskManger要花费executor,上端的task就很糙之类Spark的你这名 task。 不过Flink用的rpc是akka,同時 Flink core自定义了内存序列化框架,另外task不用像Spark每个stage的task需要相互守候本来避免但是即往下游发送数据。

Spark的序列化用户一般会使用kryo可能java默认的序列化,同時 都是Tungsten项目对Spark守护进程做一jvm层面以及代码生成方面的优化。相对于Spark,Flink当事人实现了基于内存的序列化框架,上端维护着key和pointer的概念,它的key是连续存储,在cpu层面会做有些优化,cache miss概率极低。比较和排序的但是需要比较真正的数据,先通过你这名 key比较,必须当它相等的但是,才会从内存中把你这名 数据反序列化出来,再去对比具体的数据,这是个不错的性能优化点。

很糙说一下,Structuredstreaming和原生的streaming的api有有些区别,它create表的Dataframe的但是,是需要指定表的schema的,意味着着你需要提前指定schema。另外它的watermark是不支持SQL的,于是亲戚亲戚朋友加了一一八个多扩展,实现删剪写sql,需要从左边到右边的转换(下图),亲戚亲戚朋友希望用户不止是守护进程员,也希望不用写守护进程的数据分析师等同学可不还里能用到。

让Sparkstreaming去消费多个topic,否则我根据有些条件把消费的DStream上端的每个批次RDD转化为DataFrame,原来就需要注册为一张表,根据特定的条件,切分为两张表,就需要简单的做个join,你这名 join的你这名 的问题图片删剪依赖于本次消费的数据,它们join的条件是不可控的,是比较tricky的方法。比如说下面你这名 例子,消费一一八个多topic,否则简单通过filer条件,拆成一一八个多表,否则就需要做个两张表的join,但它本质是一一八个多流。

exactly-once需要很糙注意一一八个多点:

Flink有粗粒度的checkpoint机制,以非常小的代价为每个元素赋予一一八个多snapshot概念,必须当属于本次snapshot的所有数据都进来后才会触发计算,计算但是,才把buffer数据往埋点,目前Flink sql那末提供控制buffer timeout的接口,即我的数据要buffer多久才往埋点。需要在构建Flink context时,指定buffer timeout为0,避免完的数据才会立马发下去,需要等达到一定阈值后再往埋点。

Flink task chain:

有一天有个业务方过来提需求说 亲戚亲戚朋友需要写个sql,几分钟内就需要发布一一八个多实时计算任务。 于是亲戚亲戚朋友现在始于了了做Sparkstreaming。它的主要概念如下:

Flink binary data避免operator:

页面上端会让用户选有些必要的参数, 首先会选哪一一八个多kafka集群,每个分区消费有2个,反压也是默认开启的。消费位置需要让用户每次去指定,有可能用户下一次重写实时任务的但是,需要根据业务需求去选折 offset消费点。

下面是structuredstreaming的架构图: