关于flinkspark的信息

本篇文章给大家谈谈flinkspark，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Storm，Spark，Flink对比
• 2、Hadoop、Spark、Flink概要
• 3、Spark和Flink的区别?
• 4、Apache Flink和Apache Spark有什么异同？它们的发展前景分别怎样
• 5、聊聊批计算、流计算、Hadoop、Spark、Storm、Flink等等
• 6、Spark+Flink+Iceberg打造湖仓一体架构实践探索

Storm，Spark，Flink对比

一、容错性（Fault Tolerance）

spark依赖checkpoint机制来进行容错，只要batch执行到doCheckpoint操作前挂了，那么该batch就会被完整的重新计算。spark可以保证计算过程的exactly once（不包含sink的exactly once）。

storm的容错通过ack机制实现，每个bolt或spout处理完成一条data后会发送一条ack消息给acker bolt。当该条data被所有节点都处理过后，它会收到来自所有节点ack， 这样一条data处理就是成功的。storm可以保证数据不丢失，但是只能达到at least once语义。此外，因为需要每条data都做ack，所以容错的开销很大。storm trident是基于micro¬batched实现了旁橡exactly once语义。

flink使用Chandy-Chandy-Lamport Algorithm 来做Asynchronous Distributed Snapshots（异步分布式快照），其本质也是checkpoint。如下图，flink定时往流里插入一个barrier（隔栏），这些barriers把数据分割成若干个小的部分，当barrier流到某个operator时，operator立即会对barrier对应的一小部分数据做checkpoint并且把barrier传给下游（checkpoint操作是异步的，并不会打断数据的处理），直到所有的sink operator做完自己checkpoint后，一个完整的checkpoint才算完成。当出现failure时，flink会从最新完整的checkpoint点开始恢复。

flink的checkpoint机制非常轻量，barrier不会打断streaming的流动，而且做checkpoint操作也是异步的。其次，相比storm需要ack每条data，flink做的是small batch的checkpoint，容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。

二、吞吐量和延迟（Throughputs Latency）

01 吞吐量（throughputs）

spark是mirco-batch级别的计算，各种优化做的也很好，它的throughputs是最大的。但是需要提一下，有状态计算（如updateStateByKey算子）需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响也较大。

storm的容错机制需要对每条data进行ack，因此仿仿容错开销对throughputs影响巨大运大旁，throughputs下降甚至可以达到70%。storm trident是基于micro-batch实现的，throughput中等。

flink的容错机制较为轻量，对throughputs影响较小，而且拥有图和调度上的一些优化机制，使得flink可以达到很高 throughputs。

下图是flink官网给出的storm和flink的benchmark，我们可以看出storm在打开ack容错机制后，throughputs下降非常明显。而flink在开启checkpoint和关闭的情况下throughputs变化不大，说明flink的容错机制确实代价不高。对比官网的benchmark，我们也进行了throughputs的测试，实测结果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的带宽瓶颈后，flink自身又提高了1.6倍。

02 延迟（latency）

spark基于micro-batch实现，提高了throughputs，但是付出了latency的代价。一般spark的latency是秒级别的。

storm是native streaming实现，可以轻松的达到几十毫秒级别的latency，在几款框架中它的latency是最低的。storm trident是基于micro-batch实现的，latency较高。

flink也是native streaming实现，也可以达到百毫秒级别的latency。

下图是flink官网给出的和storm的latency对比benchmark。storm可以达到平均5毫秒以内的latency，而flink的平均latency也在30毫秒以内。两者的99%的data都在55毫秒latency内处理完成，表现都很优秀。

三、 总 结

综合对比spark、storm和flink的功能、容错和性能（总结如下图）

[img]

Hadoop、Spark、Flink概要

当前大数据的数据量已达PB级别（1PB=1024TB），可以说是庞大无比。同时数据还有 结构化 （如数字、符号等）、 非结构化 （如文本、图像、声音、视频等）之分，兼具大量、复杂的特点，使得如何又快又好又便宜得进行大数据的存储，管理和处理变成一个亟待解决的问题。

于是 分布式计算 作为一种低成本的方案被提出来了。原理就是把一组计算机通过网络相互连接组成分散系统，尽管分散系统内的单个计算机的计算能力不强，但是每个计算机只计算一部分数据，多台计算机同时计算，最后将这些计算结果合并得到最终的结果。就整个分散系统而言，处理数据的速度远高于单个计算机，且比集中式计算的大型机要划算的多。

为什么是他们，这要从谷歌的三篇论文说起...

2003年到2004年间，Google发表了三篇技术论文，提出了一套分布式计算理论，分别是：

但由于Google没有开源，所以其他互联网公司根据Google三篇论文中提到的原理，对照MapReduce搭建了 Hadoop ， 对照GFS搭建了 HDFS ，对照BigTable搭建了 HBase.

即：

而 Spark 分布式计算是在Hadoop分布式计算的基础上进行的一些架构上的改良。目前也是Hadoop生态圈的成员之一。

Spark与Hadoop最大的不同点在于，Hadoop用 硬盘 存储数据，而Spark用 内存 存储数据,所以Spark能提供超过Hadoop100倍的运算速度。但因为内存断电后会丢失数据，所以Spark不能用于处理需要长期保存的数据。

Flink是目前唯一同时支持高吞吐、低延迟、高性能岩纯段的分布式流式数据处理框架。一般需要实时处理的场景都有他的身影，比如：实时智能推荐、实时复杂事件处理、实时欺诈检测、实时数仓与ETL、实时报表分析等

广义的Hadoop不再是单指一个分布式计算系统，而是一套生态系统。

那么，这套生态圈是如何产生的呢？

在有了Hadoop之类计算系统的基础上，人们希望用更友好的语言来做计算，于是产生了Hive、Pig、SparkSQL等。计算问题解决了，还能在什么地方进一步优化呢？于是人们想到给不同的任务分配资源，于是就有了Yarn、Oozie等。渐渐裤祥地，随着各种各样的工具出现，就慢慢演变成一个包含了文件系统、计算框架、调度系统的Hadoop大数据生态圈。

附：一些其他的组件示意

Kafka：是一种高吞吐量的分布式发布订阅消息系统，它可以处理各大网站或者App中用户的动作流数据。用户行为数据是后续进行业务分析和优化的重要数据资产，这些数据通常以处理日志和日志聚合的方式解决。

Kafka集群上的消息是有时效性的，可以对发布上来的消息设置一个过期时间，不管有没有被消费，超过过期时间的消息都会被清空。例如，如果过期时间设置为一周，那么消息发布上来一周内，它们都是可以被消费的，如果过了过期时间，这条消息就会被丢弃以释放更多空间。

Oozie：是一个工作流调度系统，统一管理工作流的调度顺序、安排任务的执行粗誉时间等，用来管理Hadoop的任务。Oozie集成了Hadoop的MapReduce、Pig、Hive等协议以及Java、Shell脚本等任务，底层仍然是一个MapReduce程序。

ZooKeeper：是Hadoop和HBase的重要组件，是一个分布式开放的应用程序协调服务，主要为应用提供配置维护、域名服务、分布式同步、组服务等一致性服务。

YARN：Hadoop生态有很多工具，为了保证这些工具有序地运行在同一个集群上，需要有一个调度系统进行协调指挥，YARN就是基于此背景诞生的资源统一管理平台。

Spark和Flink的区别?

Flink 和 Spark 都是基于内存计算、支持实时/批处理等多种计算模式的统一框架

Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据誉颂集RDD进行批量处理,是一种伪实时。

而Flink是基于事件驱动的，它是一个面向流的处理框架, Flink基于每个事件一行一行地流式处理，是真正的流式计算. 另外他也可以基于流来模拟批进行计算实现批处理,所以他在技术上具有更好的扩展性,未来可能会成为一个统一的大数据处理引擎

因为他们技术理念的不同,也就导致了性能相关的指标的差别,spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他改虚做能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;

SparkStreaming只支持处理时间, 折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差， 特别是在产生数据堆积的时候，误差则更明显，甚至导致计算结果不可用

Structured streaming 支持处理时间和事件时间，同时支持 watermark 机制处理滞后数据

Flink 支持三种时间机制：事件时间，注入时间，处理时间，同时支持 watermark 机核衡制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,优势比较大

其实和Kafka结合的区别还是跟他们的设计理念有关,SparkStreaming是基于微批处理的,所以他采用DirectDstream的方式根据计算出的每个partition要取数据的Offset范围,拉取一批数据形成Rdd进行批量处理,而且该Rdd和kafka的分区是一一对应的;

Flink是真正的流处理,他是基于事件触发机制进行处理,在KafkaConsumer拉取一批数据以后,Flink将其经过处理之后变成,逐个Record发送的事件触发式的流处理

另外,Flink支持动态发现新增topic或者新增partition,而SparkStreaming和0.8版本的kafka结合是不支持的,后来跟0.10版本的kafka结合的时候,支持了,看了源码;

Apache Flink和Apache Spark有什么异同？它们的发展前景分别怎样

Apache Fink是一种大规模的数据处理工具，它以大数据量的低数据延迟和高容错性快速处理大数据。它的定义特征是它能够实时处理流数据。

Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎，是一种与 Hadoop 相似的开源集群计算环境。

相同点：

都是apache 软件基金会（ASF）旗下顶级项目，都是通用数据处理平台。它们可以应册宽改用在很多的大数据应用和处理环境。两者均可在不依赖于其他环境的情况下运行于standalone模式，或是运行在基于hadoop（YARN,HDFS)之上，由于它们均是运行于内存，所以他们表现的都比hadoop要好很多。州判

二者的不同：

Flink在进行集合的迭代转换时可以是循环或是迭代计算处理。flink的流式处理的是真正巧蔽的流处理。流式数据一旦进入就实时进行处理，这就允许流数据灵活地在操作窗口。

Spark 在另一方面是基于弹性分布式数据集（RDD），这（主要的）给于spark基于内存内数据结构的函数式编程。它可以通过固定的内存给于大批量的计算。

聊聊批计算、流计算、Hadoop、Spark、Storm、Flink等等

批：处理离线数据，冷数据。单个处理数据量大，处理速度比流慢。

流：处理在线，实时产生的数据。单次处理的数据量小，但处理速度更快。

Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架。

Spark，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

Spark 是一种与 Hadoop 相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越，换句话说， Spark 启用了RDD（弹性分布式数据集），除了能够提供交互式查询外，它还可以优化迭代工作负载。RDD可以常驻内存的属性，大大简化了迭代计算所需的开销，Spark任务可以立马利用上一次计算出来的RDD来进行下次迭代。

Apache Hadoop中的MapReduce是属于离线计算技术；

Spark中Spark Core属于离线计算技术，只不过它基于内存存储中间结果，速度上比MapReduce 快很多倍，又离实时计算技术很近；

Spark中Spark Streaming 子项目属于实时计算技术，类似于Storm；

Spark中SparkSQL属于离线计算技术，只不过它基于内存存储中间结果，速度上比Hive快很多倍。

Spark并不是要成为一个大数猜兆滚据领域的“独裁者”，一个人霸占大数据领域所有的“地盘”，而是与Hadoop进行了高度的集成，两者可以完美的配合使用。Hadoop的HDFS、Hive、HBase负穗余责存储，YARN负责资源调度；Spark负责大数据计算。实际上，Hadoop+Spark的组合，可以解决绝大部分大数据的场景。

Spark逐渐形成了一套完整的生态系统，既能够提供内存计算框架，也可以支持SQL 即席查询、实时流计算、机器学习和图计算等。

Spark所提供的生态，可以支持如下3中场景：

一栈式解决方案（one stack to rule them all）

Spark包含了大数据领域常见的各种计算框架：

Spark streaming批量读取数据源中的数据，然后把每个batch转化成内部的RDD。Spark streaming以batch为单位进行计算（默猜岩认1s产生一个batch），而不是以Tuple为单位，大大减少了ack所需的开销，显著提高了吞吐。

但也因为处理数据的粒度变大，导致Spark streaming的数据延时不如Storm，Spark streaming是秒级返回结果（与设置的batch间隔有关），Storm则是毫秒级。

Storm提供了低延迟的计算，但是吞吐较低，并且无法保证exactly once（Storm trident采用batch的方式改善了这两点），Spark streaming通过小批量的方式保证了吞吐的情况下，同时提供了exactly once语义，但是实时性不如Storm，而且由于采用micro-batch的方式，对window和event time的支持比较有限（Spark streaming 2.0中引入了window和event time，还在起步阶段）。

Flink采用分布式快照的方式实现了一个高吞吐、低延迟、支持exactly once的流式系统，流式处理的方式也能更优雅的支持window和event time。

当然也不是说Flink一定就比Storm、Spark streaming好， 没有最好的框架，只有最合适的框架 。根据自身的业务、公司的技术储备选择最合适的框架才是正确的选择。

Spark+Flink+Iceberg打造湖仓一体架构实践探索

Iceberg 0.11 新特性，支持了流式小文件合并。通过分区/存团键历储桶键使用哈希混洗方式写数据、从源头直接合并文件，这样的好处在于，一个 task 会处理某个分区的数据，提交自己的 Datafile 文件，比如一个 task 只处理对应分区的数据。这样避免了多个 task 处理提交很多小文塌搜件的问题，且不需要额外亮庆的维护代码，只需在建表的时候指定属性 write.distribution-mode，该参数与其它引擎是通用的，比如 Spark 等。

关于flinkspark和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。