在技术架构与选型时,首先调研市面上常见的解决方案,然后从各方面进行比较,选择适合公司应用场景的技术。本文截取了文章Hadoop vs Spark vs Flink – Big Data Frameworks Comparison 中的比较表格。
各项比较
文章来源:【 DataFlair: Hadoop vs Spark vs Flink – Big Data Frameworks Comparison 】
比较指标 | Apache Spark | Apache Flink |
---|---|---|
数据处理 | Hadoop生态:基于批处理,流批均可 | 基于流处理的流批处理,独立运行库 |
流引擎 | 微批处理:不足以处理实时数据与计算结果 | 真正的流处理引擎:基于流,构建流程里\SQL\微批等 |
数据流 | 基于DAG | 基于运行时CDG(Cyclic Dependency Graph) |
计算模型 | 收集并计算 | 实时流,基于算子的流处理模型 |
性能 | 成熟的社区背景,基于微批的流处理没有Flink优秀 | 与其他框架相比,性能优异,特别是在机器学习和图处理方面 |
内存管理 | 提供自主内存管理,Spark1.6之后逐渐转向自动内存管理 | 自动内存管理:拥有自己的内存管理系统,独立于Java GC |
容错性 | Exactly-Once语义 | 基于Chandy-Lamport分布式快照:轻量级,强一致性 |
扩展性 | 高扩展性,最大可扩展到8000个节点 | 高扩展性:已知的最大集群达到了几千个节点 |
迭代处理 | 基于批的迭代:每个迭代独立处理与调度 | 基于流的迭代数据:只处理改变的数据,挺高任务的性能 |
支持语言 | 基于Scala语言:Scala/Java/Python/R | 基于Java语言:Java/Scala/Python/R |
优化点 | 任务手动优化。最新的优化器是基于Catalyst的函数式算子优化器:1、增加新的优化手段;2、使开发者可以自定义扩展优化器 | 根据实际程序接口进行独立优化。Flink的优化器类似于RDMS的优化过程,但优化对象为Flink程序,而不是SQL查询。 |
延迟性 | 基于内存以及RDD,低延迟 | 低延迟、高吞吐 |
处理速度 | 处理速度很快 | 大部分场景下,速度快于Spark。Flink通过去重,增加处理速度 |
可视化 | 提供了Web接口可以提交/执行任务,执行计划可视化。Spark/Flink都集成到了Zeppelin中。 | 同样提供了Web接口,可以提交和执行任务,结果的执行计划同样可以在这个接口查看 |
回复性 | 根据DAG失败重试,Checkpoint机制 | Checkpoint机制保存数据源、中间状态 |
安全性 | Spark的安全管理一般,目前仅支持密码授权。Spark可以重用Yarn/HDFS的ACLs、Kerberos等管理方式 | 通过Hadoop、Yarn框架的授权方式来给用户授权。 |
资源使用 | 大量RAM,逐渐增加 | 大量RAM,逐渐增加 |
兼容性 | 兼容与Hadoop,能够处理HDFS、YARN、Cassandra、HIve等数据源 | 完全兼容与Hadoop,提供了兼容性包 |
抽象性 | 基于RDD的封装 | Dataset抽象的封装 |
易用性 | 非常丰富的高级算子 | 同样具有高级算子 |
交互模式 | 提供交互Shell,可以执行AD-HOC查询 | 跟Scala交互集成,既可以是本地模式,也可以是集群模式 |
实时分析 | 每秒百万级数据处理 | 主要用于实时流处理,虽然它也提供了较快的批处理 |
调度器 | 基于内存,自己处理流调度 | 可以使用Yarn调度,也有自己的调度器 |
SQL支持 | Spark-SQL:提供了HSQL,以及Dataframe的DSL | 提供了Table API和SQL类似的语言,Dataframe类似的DSL还在实验阶段,SQL接口落地时间未知 |
缓存 | 缓存到内存,加快提升后续性能 | 缓存到内存,加快提升后续性能 |
硬件要求 | 中高级硬件 | 中高级硬件 |
机器学习 | 基于内存缓存以及其他手段,Spark是机器学习的强大平台 | 与DAG相比,Flink基于CDG更有效的表现算法 |
代码量 | 远小于Hadoop的代码量,更加容易执行 | 远小于Hadoop的代码量,更加容易执行 |
高可用 | HA | HA |
S3支持 | 支持 | 支持 |
部署 | 独立部署、Mesos、Yarn | 独立部署、Yarn |
承压性 | 手动设置 | 基于系统架构的承压性 |
多重消除 | exactly once | exactly once |
窗口属性 | 基于时间的窗口 | 基于记录,或其他用于自定义的窗口 |
许可 | Apache License 2. | Apache License 2. |
指导性原则
对比了Flink与Spark的一些特性,那么在实际项目中,如何选择合适的处理框架呢?
-
Ivan Mushketyk : “Apache Flink vs. Apache Spark”, 2017年
如果你需要处理复杂的流计算,那么建议选择Flink,因为Flink对流处理的支持与性能有明显的提升。如果你不需要流计算,想要最好选择Spark。因为Spark是一个更加成熟的项目,拥有庞大的社区以及用户群体,更多的训练材料以及第三方类库。但应该记住,Flink将来临。另一边,如果你喜欢实验性的最新技术,Flink肯定是最佳选择。
是不是意味着几年之内,我们会使用Flink?答案惊人。尽管Flink拥有很多惊奇的特性,Spark同样也具有。自从2015年引入Tungsten项目之后,Spark逐渐引入了许多特性。输赢尚未可知。 -
Melanie Däschinger: “Apache Spark vs. Apache Flink”, 2017年
如果高吞吐量、低延迟和良好的容错性的数据流处理需求是开发的驱动因素,那么Flink提供了一个优秀的应用程序框架[1]。如果应用程序应该嵌入到Hadoop发行版中,比如Hortonworks或Cloudera,那么Spark将是一个更好的选择,因为它已经很好地集成到各自的平台中,并得到了供应商的支持。Flink和Spark都在不断改进,以提供更简单、更快和更智能的数据处理特性。
最终,最佳框架的决定取决于这样一个问题:“哪一个更适合我的需求?”即使是开发团队最喜欢的编程语言也可能是一个关键因素——Spark的Java API源自Scala API:这有时会导致不吸引人的Java代码。数据工程师通常更喜欢Python或Scala, Spark支持更成熟、功能更完备、速度更快的api。Spark与R的紧密集成——“数据科学的黄金之子”——在R中提供了Spark,从而很好地集成到现有的数据科学工具箱中。
参考博文
Apache Flink vs Apache Spark
Apache Flink vs. Apache Spark
Apache Flink vs Apache Spark – A comparison guide
个人见解
Spark目前比较成熟,对各种数据源的支持也比较友好,特别是与Hadoop生态的耦合以及对Hive的支持。Flink目前操作Hive比较困难,通过HadoopInputFormat/HadoopoutputFormat来操作比较原始,或者JDBC来操作限制较多。
从稳定性以及社区支持来看,目前Spark资源比较丰富,技术比较成熟;Flink目前社区同样比较活跃,具有较多的前瞻技术
相对而言,对实时性要求不是很好的应用场景(微秒级),Spark可以优先考虑。
从安装以及编程角度考虑,两者安装都比较方便,且编程语言为java/Scala,比较友好。由于Flink目前处于快速成长阶段,对算子的支持没有Spark多。
两者相似性较多,属于竞对工具,合理选择最切合应用场景的工具。