大数据Flink进阶(四):Flink应用场景以及其他实时计算框架对比

举报
Lansonli 发表于 2023/03/19 11:51:31 2023/03/19
【摘要】 Flink应用场景以及其他实时计算框架对比一、Flink应用场景在实际生产的过程中,大量数据在不断地产生,例如金融交易数据、互联网订单数据、GPS定位数 据、传感器信号、移动终端产生的数据、通信信号数据等,以及我们熟悉的网络流量监控、服务器产生的日志数据,这些数据最大的共同点就是实时从不同的数据源中产生,然后再传输到下游的分析系统。针对这些数据类型主要包括实时智能推荐、复杂事件处理、实时欺诈...
Flink应用场景以及其他实时计算框架对比

一、Flink应用场景

在实际生产的过程中,大量数据在不断地产生,例如金融交易数据、互联网订单数据、GPS定位数 据、传感器信号、移动终端产生的数据、通信信号数据等,以及我们熟悉的网络流量监控、服务器产生的日志数据,这些数据最大的共同点就是实时从不同的数据源中产生,然后再传输到下游的分析系统。针对这些数据类型主要包括实时智能推荐、复杂事件处理、实时欺诈检测、实时数仓与ETL类型、流数据分析类型、实时报表类型等实时业务场景,而Flink对于这些类型的场景都有着非常好的支持。

1、实时智能推荐

智能推荐会根据用户历史的购买行为,通过推荐算法训练模型,预测用户未来可能会购买的物品。对个人来说,推荐系统起着信息过滤的作用,对Web/App服务端来说,推荐系统起着满足用户个性化需求,提升用户满意度的作用。推荐系统本身也在飞速发展,除了算法越来越完善,对时延的要求也越来越苛刻和实时化。利用Flink流计算帮助用户构建更加实时的智能推荐系统,对用户行为指标进行实时计算,对模型进行实时更新,对用户指标进行实时预测,并将预测的信息推送给Wep/App端,帮助用户获取想要的商品信息,另一方面也帮助企业提升销售额,创造更大的商业价值。

2、复杂事件处理

对于复杂事件处理,比较常见的案例主要集中于工业领域,例如对车载传感器、机械设备等实时故障检测,这些业务类型通常数据量都非常大,且对数据处理的时效性要求非常高。通过利用Flink提供的CEP(复杂事件处理)进行事件模式的抽取,同时应用Flink的Sql进行事件数据的转换,在流式系统中构建实时规则引擎,一旦事件触发报警规则,便立即将告警结果传输至下游通知系统,从而实现对设备故障快速预警监测,车辆状态监控等目的。

3、实时欺诈检测

在金融领域的业务中,常常出现各种类型的欺诈行为,例如信用卡欺诈、信贷申请欺诈等,而如何保证用户和公司的资金安全,是来近年来许多金融公司及银行共同面对的挑战。随着不法分子欺诈手段的不断升级,传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标,然后通过规则判别出具有欺诈行为嫌疑的用户,再进行案件调查处理,在这种情况下资金可能早已被不法分子转移,从而给企业和用户造成大量的经济损失。而运用Flink流式计算技术能够在毫秒内就完成对欺诈判断行为指标的计算,然后实时对交易流水进行规则判断或者模型预测,这样一旦检测出交易中存在欺诈嫌疑,则直接对交易进行实时拦截,避免因为处理不及时而导致的经济损失。

4、实时数仓与ETL

结合离线数仓,通过利用流计算诸多优势和SQL灵活的加工能力,对流式数据进行实时清洗、归并、结构化处理,为离线数仓进行补充和优化。另一方面结合实时数据ETL处理能力,利用有状态流式计算技术,可以尽可能降低企业由于在离线数据计算过程中调度逻辑的复杂度,高效快速地处理企业需要的统计结果,帮助企业更好地应用实时数据所分析出来的结果。

5、流数据分析

实时计算各类数据指标,并利用实时结果及时调整在线系统相关策略,在各类内容投放、无线智能推送领域有大量的应用。流式计算技术将数据分析场景实时化,帮助企业做到实时化分析Web应用或者App应用的各项指标,包括App版本分布情况、Crash检测和分布等,同时提供多维度用户行为分析,支持日志自主分析,助力开发者实现基于大数据技术的精细化运营、提升产品质量和体验、增强用户黏性。

6、实时报表分析

实时报表分析是近年来很多公司采用的报表统计方案之一,其中最主要的应用便是实时大屏展示。利用流式计算实时得出的结果直接被推送到前端应用,实时显示出重要指标的变换情况。最典型的案例便是淘宝的双十一活动,每年双十一购物节,除疯狂购物外,最引人注目的就是天猫双十一大屏不停跳跃的成交总额。在整个计算链路中包括从天猫交易下单购买到数据采集、数据计算、数据校验,最终落到双十一大屏上展现的全链路时间压缩在5秒以内,顶峰计算性能高达数三十万笔订单/秒,通过多条链路流计算备份确保万无一失。而在其他行业,企业也在构建自己的实时报表系统,让企业能够依托于自身的业务数据,快速提取出更多的数据价值,从而更好地服务于企业运行过程中。

自2019年1月起,阿里巴巴逐步将内部维护的Blink回馈给Flink开源社区,目前贡献代码数量已超过100万行,在最新的Flink1.15版本中Blink和Flink也进行了合并。国内包括腾讯、小米、华为、字节跳动等公司,国外包括Uber、ebay、Netflix 等公司都是Flink 的使用者。

d8bcdbb4b2ceeff868a8cd9150b8b980.png


二、其他实时计算框架对比

根据前文描述我们知道Flink主要处理的是流数据,针对的是实时计算领域,在Flink之前,大数据实时领域中还有Storm、SparkStreaming。Storm是比较早的流式计算框架,后来又出现了SparkStreaming,为了支持SQL Spark后期又推出StructuredStreamig,现在又出现了Flink这种优秀的实时计算框架,那么这几种计算框架到底有什么区别呢?下面我们从不同角度来对比下三个实时计算框架:

产品

模型

API

SQL支持

EventTime

保证次数

容错机制

状态管理

延时

吞吐

Storm

Native(数据进入立即处理)

组合式API(基础API)

早期不支持后期版本支持

早期不支持后期版本支持

At-least-once(至少一次)

ACK机制

SparkStreaming

Mico-Batching(划分小批次数据)

声明式API(有封装好的高级API)

不支持

不支持

Exactly-once(精准一次)

基于SparkCheckpoint容错

基于DStream

中等

Structured Streaming

Native/Mico-Batching

声明式API(有封装好的高级API)

支持

支持

Exactly-once(精准一次)

基于SparkCheckpoint容错

基于Dataset/DataFrame

中等

Flink

Native(数据进入立即处理)

声明式(有封装好的高级API)

支持

支持

Exactly-once(精准一次)

基于FlinkCheckpoint容错

基于操作

  • 模型:Storm和Flink是真正的一条一条处理数据,而SparkStreaming是微批批处理,一次处理一批数据(小批量),后期Spark推出的StructuredStreaming支持微批处理也支持连续处理(Continuous),目前还处于实验性,实时性不如Flink。
  • API :Storm使用基础API进行开发,比如实现一个简单的sum求和操作需要自己编写很多业务逻辑;而SparkStreaming、StructuredStreaming和Flink中都提供封装后的高阶函数,可以直接来使用,非常方便。
  • SQL 支持:早期Storm处理流数据不支持SQL,最新版本支持SQL处理流数据, SparkStreaming不支持SQL处理,后期Spark推出的StructuredStreaming支持SQL处理流式数据,Flink也是支持SQL处理实时数据。
  • EventTime 支持:Storm早期和SparkStreaming实时数据处理不支持事件时间,Storm后期实时数据处理支持事件时间,同样Spark后期推出的StructuredStreaming处理流数据也是支持事件时间,Flink诞生开始处理实时数据就支持事件时间。
  • 保证次数:在数据处理方面,Storm可以实现至少处理一次,但不能保证仅处理一次,这样就会导致数据重复处理问题,所以针对计数类的需求,可能会产生一些误差,SparkStreaming、StructuredStreaming和Flink支持Exactly-once数据处理语义。
  • 容错机制:Storm可以通过ACK机制实现数据的容错机制,而SparkStreaming、StructuredStreaming和Flink可以通过CheckPoint机制实现容错机制。
  • 状态管理:Storm中没有实现状态管理,SparkStreaming实现了基于DStream的状态管理, StructuredStreaming支持基于Dataset/DataFrame的状态管理,而Flink实现了基于操作的状态管理。
  • 延时:表示数据处理的延时情况,Storm和Flink接收到一条数据就处理一条数据,其数据处理的延时性是很低的;SparkStreaming和StructuredStreaming都支持微批处理,数据处理的延时性相对会偏高,虽然StructuredStreaming支持Continuous连续处理,但是目前处于实验阶段,数据处理延迟性相对Flink偏高,Flink实时数据处理延迟最低。
  • 吞吐量:Storm的吞吐量其实也不低,只是相对于其他几个框架而言较低;SparkStreaming、StructuredStreaming和Flink的吞吐量是比较高的。
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。