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 的使用者。

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

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

• 模型：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的吞吐量是比较高的。